Novo filtro de conteúdo para o Postfix

Atualização: 26/06/2012: Script modificado para aceitar o arquivo body_checks do postfix.

Seguindo a base dos meus filtros de conteúdo anteriores, comecei a desenvolver um novo filtro com muitas opções ainda por vir. Inicialmente, ele verifica os emails e descarta as mensagens que contenham apenas uma url e nada mais. Foi o único spam que havia passado pelos meus filtros 😉

Há a possibilidade de permitir as mensagens com apenas 1 url que sejam provenientes de um domínio específico (ou muitos, com uma regra em RegEx). Acho útil essa excessão pois muitas vezes me envio mensagens de apenas uma url como referência ou lembrete (mas o meu email não é da polônia) ^^

Agora também é possível efetuar o body_checks simples em mensagens codificadas com base64! Dispensando manter as palavras codificadas em base64 (e suas inúmeras variações) dentro do body_checks que o postfix utiliza! Contudo é preciso “converter” o seu body_checks para um novo arquivo de regras sem as linhas “REJECT” ou comentários. O que é fácil de se atingir com o comando a seguir (funciona contando que o ‘reject’ não esteja na mesma linha das regras e sim na linha abaixo, qualquer detalhe é só ajustar o arquivo manualmente depois):

# egrep -e "/.*/" body_checks | sed 's/^\///' | sed 's/\/$//' > mail_filter.bc

Um requisito para essa funcionalidade é o software mimencode, que pode ser encontrado no pacote metamail-2.7-i486-2.tgz (utilizei o pacote de instalação do slackware ;)). Com esse filtro, todas as regras que estiverem listadas no body_checks causarão o descarte ou a quarentena do email!

O filtro em seu estágio inicial pode ser visto aqui!

Leia mais artigos sobre o Postfix!

Postfix seguindo as RFC 2111 e 2396 e 2822

Inspecionando as documentações que regulamentam o formato das mensagens de email, percebi alguns detalhes que poderiam ser verificados pelo postfix para garantir a conformidade da mensagem com as definições dos cabeçalhos descritos nas RFC 2111 e 2396 e 2822.

De acordo com as descrições, criei algumas regras em RegEx para que o postfix passe a validar todas as mensagens recebidas. Elas podem ser adicionadas no header_checks.

Siga esse link para visualizar as regras: rfc_checks.txt

Com essas regras podemos assegurar que todos os clientes que nos enviem emails estejam devidamente programados e com o certificado “RFC Compliant”!!! 😀

Leia mais artigos sobre o Postfix!

Postfix verificando Mail From e Header From: contra spams.

Finalmente, depois de muita pesquisa e algum desenvolvimento, construí mais uma poderosa arma na batalha travada contra a disseminação de Spam, virus e pishing em nossos emails! 💡

Com funcionamento simples e objetivo, essa nova ferramenta expande os recursos das verificações do Postfix verificando se o comando de identificação de remetente no smtp (mail from: email.com) corresponde exatamente com o email indicado no cabeçalho do remetente da mensagem enviada (From: email.com)!

É possível instalá-lo mesmo que o seu postfix já utilize algum filtro de conteúdo (content_filter), sendo necessário nesse caso adicionar a verificação adicional dentro do content_filter de re-injeção da mensagem do seu filtro de conteúdo.

O script acompanha instruções simples de instalação e pode ser obtido aqui!

Leia Mais Artigos Relacionados ao Postfix!

Implementando verificações SPF no Postfix.

O Sender Policy Framework (SPF) é um recurso muito interessante em complemento às outras técnicas já conhecidas (gerência da porta 25, RBL’s, antivirus, verificações regex de cabeçalhos e corpos e clientes e emails, etc…) no combate de spams, virus e pishing que trafegam pela rede e funciona de uma forma muito simples e extremamente confiável: Todos os donos de domínios definem quem eles permitem que enviem emails com o seu domínio.

Por exemplo: você tem o domínio seusite.com.br e envia seus emails somente pelos servidores do Terra.com. Então você configura um campo TXT corretamente formatado para o SPF com a informação de que somente os servidores do Terra.com podem enviar emails de @seusite.com.br. Dessa forma, se alguém vier de outro IP alheio ao Terra.com em um servidor de email (com spf) e disser ser você@seusite.com.br terá o envio negado!

Porém.. se a mensagem vier de um domínio que não possui o registro SPF ela será entrege normalmente pois não será possível comprovar a autenticidade da mesma.

Criar esse registro só nos trás vantagens: evita que os servidores que fazem a verificação SPF aceitem quem usar nosso domínio em vão 😉

Para quem tem desenvoltura com o bind, a configuração é simples: basta acrescentar um registro TXT do domínio contendo os valores:

“v=spf1 <registros> –all”

É desejável adicionar também um registro SPF com o mesmo conteúdo do registro TXT.

Os registros podem ser:

mx permissão de envio concedida ao servidor mx desse domínio;

a permissão de envio concedida ao ip desse registro;

ip4:200.200.200.0/25 permissão de envio concedida à rede 200.200.200.0/25;

include:dominio.com.br permissão de envio concedida aos mesmos ips listados como permitidos no dominio.com.br.

Existem diversas opções para o –all, sendo que ele é o mais importante pois nega o envio por quem não estiver listado como permitido nos <registros>.

E outra observação importante, os subdomínios devem conter também um registro TXT, permitindo ou negando o envio de mensagens. Por exemplo, como não envio emails de usuario@www.seusite.com.br devemos negar o envio provindo do subdomínio www com o seguinte registro:

www       TXT         “v=spf1 –all”
www       SPF         “v=spf1 –all”

Dependendo da sua quantidade de domínios e ou subdomínios será um trabalho que tomará seu tempo.. porém só precisa ser efetuado uma única vez e não exige manutenção.

Para concluir, iremos adicionar a verificação dos registros SPF ao nosso Postfix! De maneira simples e fácil: Precisamos da biblioteca spf2 e do servidor policyd (modificado para verificação SPF). Ambos podem ser encontrados em: http://www.libspf2.org/ e cabe uma observação: O policyd só funciona com a versão 1.0 da libspf2, portanto procure efetuar o download da biblioteca antiga mais recente (1.04).

Depois de compilados e instalados, basta acrescentar o policyd no master.cf:

policy    unix  -        n       n       -       -       spawn
          user=nobody argv=/<diretório>/policyd

No main.cf iremos adicionar a verificação do envelope de remetente:

smtpd_sender_restrictions =
  ...
  ...
  check_policy_service unix:private/policy

Depois, torna-se interessante verificar os cabeçalhos de SPF de mensagens enviadas de outros servidores para você, como pode ser lido aqui para aumentar a segurança das mensagens recebidas!

Com mais essa ferramenta e a adoção do SPF os nossos servidores estão dia após dia cada vez mais seguros! 💡

Leia Mais Artigos sobre o Postfix!

Implementação da Gerência da Porta 25, recomendação do CGI: Comitê Gestor de Internet.

Hoje tive a feliz oportunidade de descobrir a resolução Gerência da Porta 25, publicada pelo CGI.br: O Comitê Gestor de Internet no Brasil.

Essa resolução nos aponta um detalhe que já deveria ser implementado como padrão sempre: o fechamento de servidores SMTP de Relay Aberto utilizando autenticação para o envio de mensagens via smtp. Visando assim, obter a identificação da origem das mensagens além de reduzir o grande volume de tráfego de dados gerado por spammers e vírus. Esta idéia existe desde 1998… e com o passar do tempo só aumenta o número de spammers e vírus em computadores desatualizados (cujos donos por negligência ou falta de conhecimento descuidam de atualizar o sistema com correções de segurança e ou de atualizar o anti-vírus). Essas máquinas vem a desperdiçar inúmeros recursos de processamento e de banda de comunicação dos SMTPs que tem o trabalho de receber as mensagens apenas para analisar e apagar as milhares que se tratam de vírus ou spams.

A resolução irá bloquear de maneira autoritária esse tipo de tráfego desnecessário na rede, impedindo a comunicação de toda e qualquer máquina doméstica com destino à uma porta 25, e por conseqüência tornando também inacessíveis os servidores SMTP mal configurados com o relay aberto, além de dificultar a vida dos spammers e criadores de vírus que serão forçados a atualizar suas pragas e perderão o acesso às antigas.

Define-se que todas as mensagens autênticas de email deverão ser enviadas com autenticação pela porta 587. Observe que, a porta 587 não indica arbitrariamente que a comunicação se dará de maneira autenticada pois essa é apenas uma recomendação, o suporte à autenticação precisa ser configurado no servidor de email.

A grande vantagem de se abrir um servidor dedicado aos clientes na porta 587 (submission) é a agilidade e economia de recursos obtidas pelo seu servidor de email! Por exemplo: Os emails nessa porta são aceitos somente quando forem autenticados, conseqüentemente podemos descartar diversas verificações utilizadas previamente na porta 25 (mas que continuarão ativas somente na porta 25) como as header_checks, body_checks, sender_checks, access_list, helo_access, RBL’s, recursos do Anti-Vírus… entre outras! Outra idéia interessante é habilitar o acesso à porta 587 somente para IPs Brasileiros (para a maioria dos servidores seus clientes se encontram somente no Brasil) economizando também alguns kilobytes nos logs que seriam utilizados para a negativa de acesso aos IPs internacionais sem a senha correta para enviar emails pelo seu servidor SMTP. Isso tudo torna o processamento de emails mais rápido e fácil 😀

Configurar o seu postfix para aceitar emails na porta 587, e com todos os recursos citados anteriormente é extremamente simples! Confira a seguir as adições necessárias ao master.cf:

smtp         inet  n       -       n       -       -       smtpd
   -o cleanup_service_name=cleanup25
submission   inet  n       -       n       -       -       smtpd
   -o smtpd_helo_restrictions=
   -o smtpd_sender_restrictions=reject_sender_login_mismatch,permit_sasl_authenticated,reject
   -o smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject
   -o smtpd_client_restrictions=
   -o smtpd_helo_required=no
   -o in_flow_delay=0
cleanup25    unix  n       -       n       -       0       cleanup
   -o header_checks=pcre:/etc/postfix/header_checks
   -o body_checks=pcre:/etc/postfix/body_checks

O serviço submission (conforme definido em /etc/services: porta 587) será uma instância especial do Postfix, aceitando apenas mensagens cujos remetentes tenham se autenticado apropriadamente com usuário e senha. Com essas configurações e um reload no postfix, seu servidor otimizado e exclusivo para clientes já estará habilitado e funcional! 😀

O serviço cleanup25 será o cleanup dedicado à porta 25, que fará as verificações de header e body 😉 Nesse caso é interessante remover o header_checks e body_checks do main.cf transferindo-os apenas para esse serviço.

Para habilitar a autenticação do SMTP, caso não esteja habilitada, recomendo esse artigo.

Podemos também liberar o acesso a esse servidor apenas para ips brasileiros com as regras a seguir:

# iptables -A INPUT -p tcp --dport 587 -s 130/8 -j ACCEPT
# iptables -A INPUT -p tcp --dport 587 -s 187/8 -j ACCEPT
# iptables -A INPUT -p tcp --dport 587 -s 189/8 -j ACCEPT
# iptables -A INPUT -p tcp --dport 587 -s 200/7 -j ACCEPT
# iptables -A INPUT -p tcp --dport 587 -s 216/8 -j ACCEPT
# iptables -A INPUT -p tcp --dport 587 -j DROP

Sendo 130 a faixa de IPs da Tim; 187 fornecidas pela Vivo e Claro; 216 utilizada pela NEXTEL; 189, 200 e 201 disponível pora todos os outros provedores adsl, cabo, rádio, etc, nacionais. (Ainda não sei o IP utilizado pela Oi!).

(Observação: o bloco CIDR 200/7 corresponde à faixa de ips de 200.0.0.0 até 201.255.255.255).

Por fim, para concluir a gerência da porta 25 recomendada pelo CGI devemos bloquear toda a saída de tráfego da nossa rede com destino às portas 25, que se pode realizar facilmente com as regras:

# iptables -I OUTPUT -p tcp -m tcp --dport 25 -j DROP
# iptables -I OUTPUT -p udp -m udp --dport 25 -j DROP

Se o seu linux é o roteador em sua rede.. também é necessário adicionar as regras:

# iptables -I FORWARD -p tcp -m tcp --dport 25 -j DROP
# iptables -I FORWARD -p udp -m udp --dport 25 -j DROP

Essas regras irão bloquear a saída de qualquer tráfego de sua rede local com destino às portas 25 e não impedem que o seu servidor SMTP continue recebendo emails na porta de entrada 25! 😀

Comentários finais…

O novo servidor STMP que irá apenas receber as mensagens de outros servidores SMTP já não precisa mais das regras de autenticação definidos na main.cf, conseqüentemente pode-se até remover o delay de reject caso o comando helo contenha um domínio que será rejeitado.

Podemos também criar uma nova regra de header_checks em nosso servidor de emails de porta 25 prevenindo falsidade ideológica dos emails vindos à nossos clientes, pois apesar das regras de sender_login_mismatch e derivadas verificarem o remetente do email ele poderia ser facilmente forjado no cabeçalho do email.

# verificação contra falsidade ideológica
/^(From|Message-ID|Received):.*[^@](seudominio)\.com\.br/
    REJECT forged sender

O ponto interessante é essa regra não ser verificada por nossos clientes autenticados (o servidor submission não faz header_checks), e evitamos que um destinatário qualquer (identificado como email@internet.com.br) defina ser um cliente@seudominio.com.br dentro do cabeçalho do email 🙂

Essa resolução tem tudo para ser útil, bloqueando vírus antigos que ainda estão em circulação, diminuindo o pishing e aniquilando os spammers mais incompetentes… além de nos auxiliar a economizar ainda mais os recursos de nossos servidores de emails 🙂 Mesmo que nada impeça que alguém coloque um servidor SMTP de Relay Aberto na porta 587, estes serão casos raros e difíceis de encontrar em relação à enorme quantidade dos SMTPs abertos existentes hoje na porta 25. Também nada impede que os spammers com conhecimento e recursos continuem a manter seus sistemas criminosos de disseminação de mensagens de marketing e vírus, por outro lado torna-se mais fácil bloquear seus domínios e suas faixas de IPs diretamente no iptables 👿

Leia Mais Artigos sobre o Postfix!

Protegendo ainda mais o seu Postfix contra Spam!

Analizando os arquivos de logs que recebo via email, notei que o mesmo email insistentemente envia mensagens para diversos usuários do meu sistema, sejam os destinatários válidos e ou inválidos… diante disso me partiu a seguinte idéia: bloquear automaticamente quem envia emails para usuários que não existem no meu sistema!! Afinal, se estão chutando para qualquer lado… o goleiro aqui é profissional e cata todas! 💡

Desenvolvi então o seguinte script que adiciona os emails recusados em uma lista negra e informa detalhadamente as origens do email, facilitando reconhecer algum falso-positivo que venha a cair na malha. 😀

Para funcionar Continuar lendo