Um firewall robusto no iptables!

Um firewall stateful oferece um maior controle acerca das conexões que trafegam pelo nosso firewall, ele permite por exemplo que aplicações possam iniciar conexões de dentro para fora da rede em qualquer porta e que a resposta a essa conexão volte para a aplicação que iniciou a conexão sem precisar de uma regra específica para a o ip de destino ou portas envolvidas (que podem ser aleatórias).

Aqui descrevo uma atualização ao meu antigo script de firewall básico, com alguns comentários:

#!/bin/bash
it="/usr/sbin/iptables" #comando do iptables

# permite conexões locais e vindos da rede local
$it -A INPUT -i lo -j ACCEPT
$it -A INPUT -i eth0 -j ACCEPT

# permite conexões no servidor de dns
$it -A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
$it -A INPUT -p udp -m udp --dport 53 -j ACCEPT

# permite apenas ips brasileiros a conectarem por ssh, pop3, imap e smtp
$it -A INPUT -s 177.0.0.0/8 -p tcp -m multiport --dports 22,110,143,587 -j ACCEPT
$it -A INPUT -s 186.0.0.0/7 -p tcp -m multiport --dports 22,110,143,587 -j ACCEPT
$it -A INPUT -s 189.0.0.0/8 -p tcp -m multiport --dports 22,110,143,587 -j ACCEPT
$it -A INPUT -s 200.0.0.0/7 -p tcp -m multiport --dports 22,110,143,587 -j ACCEPT

# bloqueia esses mesmos acessos de todos os outros ips
$it -A INPUT -p tcp -m multiport --dports 22,110,143,587 -j closed

# permite receber emails na porta 25 e acesso web na porta 80
$it -A INPUT -p tcp -m multiport --dports 25,80 -j ACCEPT

# permite o protocolo de informações de rede: icmp
$it -A INPUT -p icmp -j ACCEPT

# permite conexões já iniciadas pelo servidor (permitidas pelas regras output)
$it -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# bloqueia todas as outras conexões não autorizadas anteriormente.
$it -A INPUT -j closed

Para complementar o firewall podemos fazer NAT (popularmente conhecido como compartilhamento da internet), utilizando o SNAT e ip_foward:

#!/bin/bash
 
# interface da conexão de internet
if="eth1"
# ip da conexão de internet
ip="200.0.0.1"

iptables -t nat -A POSTROUTING -o $if -j SNAT --to-source $ip
sysctl -w net.ipv4.ip_forward 1

💡

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!

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

Priorizando o tráfego no iptables!

Acrescentando flags de TOS (Type Of Service, Tipo de Serviço) em seu firewall, voltadas para priorizar o tráfego de informações mais importantes, é interessante como por exemplo para definir o tráfego http com prioridade alta para que os seus downloads de p2p, emails, e outros não atrapalhem sua navegação… ou para que streamings não atrasem… inclusive mensagens instantâneas com prioridade maior que os outros dados poderão se tornar “mais instantâneas”… 😎 Continuar lendo

Agregando links (Load Balance) no Linux.

Como recentemente adquiri a internet via cabo (Ajato), resolvi buscar informações a respeito de como integrar a nova internet ao meu antigo Speedy, para efetivar um powerup na conexão!! E segue aqui o resultado da minha experiência… 😎

Como a conexão Ajato é via dhcp, utilizei uma placa de rede exclusiva para ela (pois não funcionaria o dhcp com a alias de um ip fixo em uma mesma interface de rede).

Essa é uma versão resumida da documentação que você pode encontrar em:
http://www.ssi.bg/~ja/

Continuar lendo

Protegendo o SSH contra ataques de bruteforce.

Para você que já ficou de saco cheio de ver 3092305782 usuários vindos de sei lá quantos ips diferentes e tendo seu login negado nos arquivos de log do sistema, o sshblacklist foi feito para você! 😀

Você pode configurar para bloquear automaticamente no firewall um host que errar a senha tantas vezes seguidas e retirar bloqueio do firewall automaticamente após alguns dias, o sshblacklist roda em perl e quase não tem o que configurar! Continuar lendo