Comment autoriser le SMTP sortant sur iptables Debian Linux


13

Si je choisis d'autoriser tout le trafic sur la chaîne OUTPUT ( iptables -P OUTPUT ACCEPT), le courrier est bien envoyé. Dès que je verrouille mon serveur avec ces règles, le courrier sortant cesse de fonctionner. Tout le reste fonctionne cependant, ce qui est étrange.

Quelqu'un voit-il quelque chose ici qui empêcherait l'envoi de mon courrier sortant? Je suis perplexe, j'ai regardé ces règles encore et encore et essayé de nombreuses versions différentes.

 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

Réponses:


18

Vous avez une règle pour laisser sortir le trafic, mais vous n'avez pas de règle pour laisser entrer le trafic de retour.

Je suppose que vous vouliez que ces 2 règles soient à la -A INPUTplace:

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

Cependant, l'utilisation du port source comme méthode pour autoriser le trafic de retour est une mauvaise façon de sécuriser le système. Tout ce que quelqu'un a à faire est d'utiliser l'un de ces ports source et votre jeu de règles de pare-feu devient inutile.

Une bien meilleure idée serait de supprimer toutes les -A INPUT ... --sportrègles et d'utiliser à la place cette seule règle:

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

Le fonctionnement de cette règle est que lorsque votre système établit une connexion sortante, le noyau enregistre la connexion dans une table de suivi. Ensuite, lorsque les paquets du système distant reviennent, il cherche à voir si ces paquets sont associés à des connexions dans la table de suivi.
Le ESTABLISHEDbit est celui qui autorise le trafic directement lié à la session. Ce seront des paquets TCP qui reviendront sur le flux.
leRELATEDbit laisse le trafic lié à la connexion, mais ne fait pas partie de la connexion elle-même. Cela peut être des choses comme les paquets ICMP, comme «ICMP ne peut pas se fragmenter». Ces paquets ne font pas partie du flux TCP, mais sont d'une importance vitale pour maintenir le flux en vie (ce qui est également une autre chose que votre ensemble de règles ne couvre pas, et sans lequel vous verrez des problèmes de connexion et des pertes étranges).

Cette règle fonctionne également pour le trafic UDP, mais comme UDP est sans état, ce n'est pas tout à fait la même chose. Au lieu de cela, le noyau doit garder une trace des paquets UDP qui sortent et suppose simplement que lorsque les paquets UDP reviennent sur la même combinaison hôte / port, et c'est dans un court laps de temps, ils sont liés.


Merci pour la réponse. Je pense que je ne veux pas laisser le trafic revenir parce que je fais uniquement une connexion SMTP sortante? Pensais que si j'ajoutais la règle à la chaîne INPUT, j'autoriserais SMTP. Il s'agit d'un serveur Web qui a juste besoin de se connecter à un hôte SMTP externe pour envoyer du courrier .... merci!
916 Networks

Si vous ne laissez pas le trafic de retour, comment votre système va-t-il recevoir tous les messages "oui j'ai reçu vos données" que les protocoles TCP et SMTP utilisent?
Patrick

Ça a du sens. Je viens d'ajouter votre règle et cela a totalement fonctionné. J'apprécie la réponse! J'ai essayé de voter mais je dis que je n'ai pas assez de réputation (nouveau sur Unix StackExchange)
916 Networks

J'ai ajouté une explication du fonctionnement de cette règle.
Patrick
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.