Verificando as Headers Received-SPF: com RegEx.

Como escrito em um rascunho sobre a requisição de comentário da estrutura de política de remetentes. (Em outras palavras… Como escrito nesse Draft sobre a RFC do SPF). Foi definido que os servidores devem verificar a validade dos cabeçalhos Received-SPF, garantindo que o mesmo tenha um tamanho aceitável e não possua caracteres inválidos e ou dados maliciosos. (SPF clients MUST make sure that the Received-SPF header does not contain invalid characters, is not excessively long, and does not contain malicious data that has been provided by the sender.)

A dúvida porém é o que seria considerado excessivamente longo? O padrão POSIX 1003.1-2001 define que os domínios deverão ter no máximo 64 caracteres (com excessão do ponto de terminação) enquanto a RFC 2181 define um máximo de até 255 caracteres (incluindo o ponto de terminação). Pensando a respeito, acredito que o domínio deva ter limite de 64 caracteres enquanto o domínio com seus subdomínios (inclui ponto de terminação) deva ser 255 caracteres. 😉

Seguindo essa idéia, criei algumas regras com RegEx que verificam e permitem o envio de mensagens com cabeçalhos Received-SPF válidos e nega o que não se encaixa no padrão.

As regras podem ser visualizadas nesse link.

Leia Mais Artigos sobre o 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

Integrando o ClamAV com o Samba e o Postfix e o Squid!

Eis que resolvi, finalmente, trabalhar a idéia de instalar um Anti-Vírus no Linux… algo que eu sempre relutei: tanto pela queda de performance que um Anti-Vírus propicia quanto pela falta de necessidade de se utilizar um Anti-Vírus quando você obtem os seus arquivos somente de fontes extremamente confiáveis (e sabe contudo, analizar o conteúdo dos arquivos e cuidar da manutenção do seu sistema caso algo fora do normal venha a ocorrer). Porém.. como costumo criar backups dos meus clientes em um compartilhamento especial do samba, dedicado a escanear os arquivos com Anti-Vírus, o ClamAV se demonstrou como uma opção adicional ao Avast! e ao AVG.. contando também com a possibilidade de integrá-lo ao Samba, ao Postfix e ao Squid!!

Continuar lendo

Bloqueando spammers no Firewall do Linux.

Uma ferramenta interessante para proteger o seu servidor SMTP é o sshblacklist aplicado para funcionar com smtp… (e também imap, pop3, webmail, etc..!)

Observando o arquivos de log de email do meu servidor pensei em modificar esse script de proteção SSH para bloquear os IPs de servidores e clientes de email que têm suas mensagens rejeitadas pelo meu servidor SMTP por algum motivo, seja email inválido, domínio de spammer conhecido ou mesmo um IP listado em alguma lista RBL, que sempre serão negados pelo servidor SMTP mas continuam voltando insistentemente, e agora, são bloqueados diretamente no Firewall: interrompendo o tráfego de dados desnecessários na rede e nos arquivos de log. Continuar lendo