Gestion d'iptables et des changements de nom de domaine

Un rapide coup d'œil aux adresses IP actuelles de smtp.mailgun.org révèle qu'elles sont toutes sur Amazon AWS. Il faut s'attendre à ce qu'elles changent fréquemment, et donc à ce que leur codage dur dans le pare-feu soit, au mieux, délicat. Vous pouvez très bien perdre du courrier sortant même avec un script dynamique, car l'adresse IP peut changer et vous essayez d'envoyer du courrier avant la prochaine exécution du script. C'est ce qu'on appelle une condition de course. Il n'y a pas grand-chose que vous puissiez faire à ce sujet, à part revoir la conception, et c'est ce que je vais recommander...

En ce qui concerne le pare-feu de sortie, je ne suis pas vraiment préoccupé par le trafic sortant vers le port 587. Ce type de trafic doit de toute façon s'authentifier auprès du serveur de messagerie distant, et ce n'est donc pas un problème important pour moi. Pour le courrier, je m'inquiète du trafic sortant vers le port 25 ; si vous utilisez un service comme mailgun, ce trafic ne devrait pas exister, et s'il existe, c'est presque certainement parce que vous avez été compromis.

Voici quelques éléments que vous pouvez envisager à la place :

• Autoriser tout trafic TCP sortant vers le port de destination 587. Comme expliqué ci-dessus, il s'agit d'un risque relativement faible, mais vous pouvez réduire davantage le risque en...

• Exécutez votre application Web sous un ID utilisateur unique, puis autorisez tout trafic TCP sortant vers le port de destination 587 pour cet ID utilisateur uniquement. (Utilisez l'option -m owner match.) Cela réduit encore le risque en stipulant que seul l'utilisateur de l'application Web peut lancer ce trafic. Notez que si vous faites cela, les autres utilisateurs ne pourront pas établir cette connexion sortante, pas même root (mais root peut modifier les règles du pare-feu pour que cela soit possible).

• Vous pouvez rendre votre installation plus robuste en faisant tourner un serveur de messagerie local uniquement configuré pour utiliser mailgun comme smarthost, relayant tout le courrier qu'il reçoit (comme il n'écoute que localement, il ne devrait provenir que de votre application web). Ensuite, vous autorisez uniquement l'ID utilisateur du serveur de messagerie à établir des connexions sortantes vers le port 587, comme indiqué ci-dessus. Cela vous donne le supplémentaire L'avantage de ne pas perdre de courrier parce que mailgun était inaccessible au moment où votre application web a essayé d'envoyer du courrier. Si mailgun est inaccessible, que ce soit en raison de problèmes de réseau, d'une mauvaise configuration du pare-feu ou de toute autre raison, votre application Web enregistrera une erreur et perdra le courrier, mais le serveur de messagerie local mettra le courrier en file d'attente et le distribuera lorsque le service sera rétabli. Vous configurez alors l'application Web pour qu'elle distribue le courrier localement.