J'en ai récemment reçu un Undelivered Mail Returned to Senderen envoyant ma newsletter à l'un de mes 1500 clients. Mon site Web utilise une procédure de double opt-in pour s'assurer que l'utilisateur souhaite explicitement recevoir ma newsletter.
Le message d'erreur:
smtp; 554 ...
Swisscom AG IP: 94.130.34.42, You are not allowed to send us mail. Please
refer to xyz.com if you feel this is in error.
J'ai reçu un exemple de courrier indésirable (du fournisseur de messagerie du serveur de réception):
Received: from mail.com ([94.130.34.42])
by smtp-27.iol.local with SMTP
id itOWeYZ6O42IFitOWe35TR; Tue, 13 Feb 2018 03:54:09 +0100
From: "Servizi online - Poste Italiane" <[email protected]>
Subject: Abbiamo ricevuto una segnalazione di accredito
Date: Mon, 12 Feb 2018 11:32:03 -0500
Le fournisseur a également déclaré que mon serveur semblait piraté. Il a en outre déclaré que "le serveur de messagerie destinataire a simplement enregistré le rDNS qui lui est présenté par l'IP de connexion, dans ce cas mail.com ([94.130.34.42])" - ce qui n'est certainement PAS comme j'ai configuré mon entrée rDNS (mail.lotsearch.de) pour mon adresse IP. Donc, si j'ai bien compris rDNS, le serveur de messagerie receveur interroge l'IP de l'expéditeur pour une entrée rDNS (94.130.34.42 => devrait se résoudre en => mail.lotsearch.de, ce qu'il fait définitivement, lorsque je le teste depuis ma machine locale via $ host 94.130.34.42).
Comment est-il possible d'usurper rDNS? Je ne peux pas imaginer comment cela peut fonctionner techniquement (uniquement avec une attaque man-in-the-middle quelque part dans l'infrastructure entre le serveur de messagerie récepteur et mon serveur).
Le fournisseur a également mentionné qu '"il est probable qu'une machine se connectant à partir de mon IP a été compromise et envoie ces messages via des connexions directes au serveur de messagerie du destinataire (également appelé MX direct)". Que veut direct MXdire? Quelqu'un a volé ou trouvé une fuite d'informations d'identification de messagerie sur l'un de mes comptes de messagerie et les a utilisées pour l'envoi de courrier?
Ce que j'ai fait jusqu'à présent pour m'assurer que mon serveur n'est PAS / ne sera pas piraté:
- recherché les journaux de messagerie (
var/log/mail*): rien de spécial là-dedans - vérifié les journaux de connexion ssh (
last,lastb): rien d'inhabituel - vérifié si postfix fait du relais: non il ne le fait pas (vérifié via telnet)
- vérifié pour les logiciels malveillants via clamav: aucun résultat
- fail2ban installé et configuré pour ssh, postfix et dovecot
- installé les derniers correctifs / mises à jour pour Ubuntu 16.04 (je le fais chaque semaine)
- vérifié si mon adresse IP est sur une liste noire: ce n'est pas
- entrée rDNS vérifiée dans la console de gestion de mon hébergeur: elle est correctement réglée sur
mail.lotsearch.de. - mots de passe modifiés de tous les comptes de messagerie
- clés publiques modifiées pour l'accès au shell
Plus important: il n'y avait aucune information [email protected]dans les journaux. Donc, si mon serveur avait été mal utilisé par un spammeur (par exemple en raison de la fuite d'informations d'identification smtp de l'un des comptes de messagerie), je verrais cela dans les fichiers journaux.
La dernière possibilité à laquelle je peux penser est qu'un intrus a placé un malware sur mon serveur que je n'ai pas encore trouvé.
Comment puis-je surveiller le trafic de courrier sortant (par processus et par port)?
Seule la surveillance du port sortant 25 n'aiderait pas car cela ne ferait que piéger les courriers irréguliers envoyés via postfix, mais pas le trafic de messagerie provoqué par une infection potentielle par un malware (si le malware utilise un autre port que 25 pour envoyer directement des mails / communiquer avec les serveurs de messagerie destinataires) . Si je surveille le trafic sortant sur tous les ports, j'aurai un moyen d'accéder à un énorme fichier journal que je ne peux pas rechercher efficacement pour une activité suspecte.
EDIT - Test ajouté pour relais ouvert:
$ telnet mail.lotsearch.de 25
$ HELO [email protected]
250 mail.lotsearch.de
$ MAIL FROM: [email protected]
250 2.1.0 Ok
$ RCPT TO:<[email protected]>
454 4.7.1 <[email protected]>: Relay access denied
EDIT - Exécution d'applications Web
- Plateforme personnalisée basée sur Zend Framework 3 ( https://framework.zend.com/ )
- Mediawiki ( https://www.mediawiki.org/ )
- Mantis Bug Tracker ( https://www.mantisbt.org/ )
la source
Réponses:
Avant d'arriver à ma suggestion, je voudrais commenter un peu quelque chose que votre fournisseur vous a dit:
Cela n'indique pas que le DNS inverse pour 94.130.34.42 est (ou était) mail.com. Il indique plutôt que le client SMTP a envoyé
mail.comsaHELO(ouEHLO) ligne. (Un serveur de messagerie bien configuré aurait complètement rejeté cette connexion, mais c'est sur Swisscom, pas vous ...) Cette ligne n'indique aucune entrée DNS inversée. Si c'était le cas, il serait apparu entre parenthèses. Par exemple:Dans ce cas, le premier nom d'hôte est ce que le serveur de messagerie s'est identifié comme dans son
EHLO. Le deuxième nom d'hôte est le DNS inversé enregistré au moment de l'établissement de la connexion.La section 4.4 de la RFC 5321 explique le format de la ligne Received:, avec une grammaire formelle.
Dans votre cas, aucun DNS inversé n'a été enregistré. Étant donné que votre adresse IP a un enregistrement PTR, cela peut être dû au fait qu'ils ne l'ont pas recherché ou à une défaillance DNS temporaire.
Maintenant, il semble que vous exécutiez un service d'hébergement Web et que vous disposiez de nombreuses applications Web. Si l'un d'eux est compromis, il peut commencer à envoyer du spam. Ceux-ci établissent souvent des connexions directes avec des serveurs de messagerie distants en recherchant leurs enregistrements MX et en se connectant au port 25, comme s'ils étaient en fait eux-mêmes un serveur de messagerie, plutôt que de livrer du courrier au spouleur de messagerie local ou à un service de messagerie authentifié sur les ports 587 ou 465. comme le font les applications Web légitimes.
Une façon d'arrêter cela est d'implémenter une règle de pare-feu qui empêche les connexions sortantes sur le port 25, sauf si l'utilisateur est l'utilisateur du serveur de messagerie. Par exemple:
Les applications Web ne peuvent plus livrer de courrier directement aux serveurs SMTP distants, mais doivent utiliser le spouleur de courrier local ou un service de messagerie authentifié.
la source
iptablesrègle permettant à postfix et à l'utilisateur de plesk d'envoyer des e-mails (car je pense que le Plesk Panel envoie des e-mails directement et non via postfix). Est-il également possible de configurer crondaemon (mes cronjobs) pour envoyer des e-mails via smtp via postfix? Je ne veux pas ajouter l'utilisateur cron à iptables (comme une autre exception) car il serait plus sûr de laisser le trafic de messagerie dans la mesure du possible passer par postfix. Est-il possible de laisser crontab utiliser postfix pour envoyer des journaux d'erreurs? Dois-je mettre cela dans une nouvelle question ici sur serverfault?root? Parce que le processus maître de postfix est exécuté parrootdans la plupart des cas. Ou le processus maître postfixpostfixgénère-t-il des sous-processus en utilisant -user pour envoyer des e-mails / faire des choses? J'ai essayé votre règle iptables, les e-mails n'ont pas pu être livrés ... Si je le fais,ps -ef | grep "postfix"je vois des sous-processus exécutés parpostfix-user et un processus maître exécuté parroot...De nos jours, essayer de créer son propre serveur de messagerie est, pour la plupart, une bataille perdue et il vaut mieux trouver un service abordable. Ayant dit cela..
Regardez vos journaux chez le fournisseur qui vous a bloqué et voyez si vous pouvez trouver quelque chose de suspect. Il est possible, et cela arrive souvent, que quelqu'un oublie qu'il s'est abonné à votre newsletter et vous marque comme spam. Ensuite, selon le fournisseur, vous pouvez vous inscrire sur la liste noire du fournisseur même si vous n'avez rien fait de mal.
Séparez les envois de masse de tous vos autres e-mails sur deux serveurs.
Gardez les journaux pendant des semaines au minimum et de meilleurs mois. Donc, chaque fois que quelque chose se passe, vous effectuez des recherches.
Vérifiez quotidiennement vos journaux pour des situations similaires de n'importe quel fournisseur et examinez-les quotidiennement ou plus rapidement. La seconde où vous êtes bloqué et si vous continuez à l'envoyer peut empirer. Vous pouvez passer d'un bloc temporaire à un bloc permanent .. pour être signalé sur une liste noire.
Je ne sais pas comment ils l'implémentent, mais une chose que je sais que de nombreux fournisseurs font pour les services de courrier sortant est que la seconde fois qu'un fournisseur / IP bloque un e-mail, aucun autre e-mail n'est tenté d'être envoyé. Idéalement, vous voulez quelque chose comme ça. Parce que le second est bloqué, envoyer plus ne fera qu'aggraver le problème.
la source