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!

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

  1. Pingback: Protegendo o Postfix contra spam. | Blog do Eduardo Nunes

  2. Olá Eduardo bons seus artigos! Tenho uma duvida liberei a porta 587 no postfix, ou seja a 25 e 587 estão liberadas. sobre o iptables dropando a porta 25 tenho que fazer no meu servidor de e-mail postifx? pq fiz isto e meu servidor não está conseguindo entregar e-mails as outros servidores de e-mail da timed out, quando tiro da regra do servidor consigo entregar normalmente. Pelo que eu entendi entre as mtas a porta continua a 25 e entre mua (thunderbind, outlook) e mta a porta é a 587!

    • Olá Anderson!

      Obrigado pelo comentário!

      Quanto ao iptables só é preciso dropar o tráfego que não seja do smtp, por exemplo o tráfego de forward da sua rede local e não o de output do servidor, pois o servidor smtp sempre irá entregar as mensagens na porta 25. Se não houver máquinas na rede do servidor não é necessário usar nenhuma regra. Agora se o seu servidor smtp está atrás de uma máquina que compartilha a internet e utiliza-se assim das regras de foward do iptables uma solução é limitar o forward na porta 25 apenas para o ip do servidor smtp.

      Por exemplo:
      iptables -t nat -A FORWARD -p tcp –dport 25 -s 192.168.1.55 -j ACCEPT
      iptables -t nat -A FORWARD -p tcp –dport 25 -j DROP

      Assumindo 192.168.1.55 como o ip do seu servidor smtp.

      Algo interessante e possível no linux é limitar o output apenas a um usuário específico (o do postfix) assim qualquer usuário não conseguiria fazer “telnet” para um smtp pela porta 25, apenas o nosso servidor de email conseguiria enviar mensagens para destinos na porta 25.

      Por exemplo:
      iptables -t filter -A OUTPUT -p tcp –dport 25 -p owner –uid-owner postfix -j ACCEPT
      iptables -t filter -A OUTPUT -p tcp –dport 25 -j DROP

      Boa diversão!!

Deixe uma resposta para Eduardo Nunes Cancelar resposta