Como permitir SMTP de saída no iptables Debian Linux

Se eu optar por permitir todo o tráfego na cadeia OUTPUT chain ( iptables -P OUTPUT ACCEPT), enviaremos bem. Assim que bloqueio meu servidor com essas regras, os emails de saída param de funcionar. Tudo o resto funciona, o que é estranho.

Alguém vê aqui alguma coisa que impediria o envio de meus e-mails? Estou perplexo, observei essas regras várias vezes e tentei várias versões diferentes.

 iptables -F
 iptables -P INPUT DROP
 iptables -P FORWARD DROP
 iptables -P OUTPUT DROP


 iptables -A INPUT -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
 iptables -A OUTPUT -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT

 iptables -A INPUT  -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
 iptables -A OUTPUT -p tcp --sport 80 -m state --state NEW,ESTABLISHED -j ACCEPT

 iptables -A INPUT  -p tcp --sport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
 iptables -A OUTPUT -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT

 iptables -A INPUT -p tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT
 iptables -A OUTPUT -p tcp --sport 443 -m state --state NEW,ESTABLISHED -j ACCEPT

 iptables -A OUTPUT -p tcp --dport 25 -j ACCEPT
 iptables -A OUTPUT -p tcp --dport 587 -j ACCEPT

 iptables -A OUTPUT -p tcp --sport 25 -j ACCEPT
 iptables -A OUTPUT -p tcp --sport 587 -j ACCEPT

 iptables -A OUTPUT  -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
 iptables -A INPUT -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT

 iptables -A OUTPUT  -p tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT
 iptables -A INPUT  -p tcp --sport 443 -m state --state ESTABLISHED -j ACCEPT

 iptables -A INPUT -i lo -j ACCEPT
 iptables -A OUTPUT -o lo -j ACCEPT

 iptables -A OUTPUT -p udp  --dport 53 -j ACCEPT
 iptables -A INPUT -p udp  --sport 53 -j ACCEPT

 iptables -A INPUT -p tcp --dport 80 -m limit --limit 25/minute --limit-burst 100 -j ACCEPT
 iptables -A INPUT -p tcp --dport 443 -m limit --limit 25/minute --limit-burst 100 -j ACCEPT


 iptables -N LOGGING
 iptables -A INPUT -j LOGGING
 iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables Packet Dropped: " --log-level 7
 iptables -A LOGGING -j DROP

Você tem uma regra para liberar o tráfego, mas não tem uma regra para permitir que o tráfego retorne.

Suponho que você pretendeu que essas duas regras fossem -A INPUT:

iptables -A OUTPUT -p tcp --sport 25 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 587 -j ACCEPT

No entanto, usar a porta de origem como um método para permitir o tráfego de retorno é uma maneira ruim de proteger o sistema. Tudo o que alguém precisa fazer é usar uma dessas portas de origem e seu conjunto de regras de firewall se torna inútil.

Uma idéia muito melhor seria remover todas as -A INPUT ... --sportregras e usar apenas essa regra:

iptables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

A maneira como essa regra funciona é que, quando o sistema faz uma conexão de saída, o kernel registra a conexão em uma tabela de rastreamento. Então, quando os pacotes do sistema remoto retornam, ele verifica se esses pacotes estão associados a alguma conexão na tabela de rastreamento.
O ESTABLISHEDbit é aquele que permite o tráfego diretamente relacionado à sessão. Serão pacotes TCP retornando ao fluxo.
oRELATEDbit permite o tráfego relacionado à conexão, mas que não faz parte da própria conexão. Isso pode ser algo como pacotes ICMP, como "ICMP não pode fragmentar". Esses pacotes não fazem parte do fluxo TCP, mas são de vital importância para manter o fluxo ativo (o que também é outra coisa que seu conjunto de regras não cobre e sem o qual você verá problemas e perdas estranhas de conexão).

Essa regra também funciona para o tráfego UDP, mas como o UDP é sem estado, não é exatamente o mesmo. Em vez disso, o kernel precisa acompanhar os pacotes UDP que saem, e apenas assume que quando os pacotes UDP retornam na mesma combinação host / porta, e é dentro de um curto espaço de tempo, que eles estão relacionados.