Greylisting usando spamd (OpenBSD) em modo bridge - Parte 1

Greylisting é uma técnica usada para combater o Spam, que, atualmente, funciona bem para diminuir o número de propagandas não solicitadas, phishings e vírus na caixa de entrada de e-mail dos usuários. Digo atualmente porque, não tenho dúvidas, que os spammers vão se adaptar a esta técnica. Mas não desanime! Essa é apenas mais uma camada das muitas já implementadas na segurança do seu sistema! :D

Esta técnica se aproveita do fato que, geralmente, os spammers utilizam programas para envio de e-mails em massa ou proxies smtp mal configurados que, ao contrário do que prevê o RFC 821 [1], não reenviam os e-mails caso recebam uma mensagem de falha temporária. Assim, o greylisting exige que uma mensagem seja enviada 1 vez, para que entre na greylist, e, após o tempo mínimo de espera para reenvio configurado no software que fará esse controle de greylisting, mais duas vezes, para que então seja entregue. Uma explicação excelente e didática do funcionamento desta técnica pode ser lida em [2] .

A abordagem que será descrita aqui é útil para que você não precise mudar nada em seu servidor de e-mails. Portanto, caso ele não tenha algum suporte para esta técnica, isso não será problema. O que teremos será uma "caixa preta" que fará todo o controle dos e-mails que chegam aos seus MX (mail exchanger). Todo e-mail que chegar ao MX certamente terá passado pela filtragem do Greylist.
Será necessário um computador com tantas placas de rede quanto forem seus MX mais uma, ligada à internet (Exemplo: Tenho 2 MXs, portanto, precisarei de 3 placas de rede).

Antes de tudo, instale as placas no computador e o sistema operacional OpenBSD (isso foge do escopo deste texto. Vide [3]). Feito isto, mais uma pequena explicação sobre como funcionará o greylisting, agora, utilizando esta implementação.

O greylisting funcionará utilizando a interação entre o daemon spamd (que fará o controle dos e-mails) e o pf (packet filter, o firewall do OpenBSD [4]). O spamd fará o controle do banco de dados citado na referência 2 e atualizará a tabela do packet filter segundo o banco de dados. Ou seja, o IP (fictício) 10.1.2.3 já passou pelos testes e está apto a entregar mensagens no MX, portanto, ele adicionará esse IP na tabela do PF que libera a passagem de pacotes originados deste IP à porta 25. Na próxima vez que este IP enviar e-mails para os meus MXs, o PF verá em suas tabelas que o IP está liberado e permitirá que o pacote siga para o MX correto. Caso um IP não esteja liberado em sua tabela ainda, o PF redirecionará o pedido para o daemon spamd. Este irá responder no lugar do MX (utilizando IP do MX para o qual a mensagem está sendo enviada), como se fosse um servidor SMTP. Pegará os dados, gravará na base de dados e retornará uma falha temporária. Quando for reenviado, checará se o tempo mínimo para reenvio foi satisfeito (digamos, depois de 25 minutos) e, se sim, coloca este IP na whitelist e retorna um erro temporário. Avisa o PF que este IP está liberado, e, no próximo reenvio, o pacote passará pela bridge e chegará de fato ao MX. Agora, vamos às configurações.

Consideremos que o computador tenha três placas: xl0, xl1 e xl2. Consideremos ainda que a placa xl0 será ligada à Internet e as outras duas a cada um dos meus MXs (lembre-se que, para ligar um computador diretamente ao outro, deve-se usar um cabo cross UTP, considerando que está usando uma placa Ethernet com conector RJ-45 :) ). O cenário está ilustrado a seguir (considere os IPs representados com letras IPs válidos na Internet):

Gostou? Bacana? Que tal providenciar uma máquina e iniciar a instalação do OpenBSD? :D
Assim que terminar, volte ao blog para começarmos as configurações! Até logo!

[1] http://www.ietf.org/rfc/rfc0821.txt
[2] http://www.antispam.br/admin/greylisting/
[3] http://www.openbsd.org/faq/faq4.html
[4] http://www.openbsd.org/faq/pf/