Détecter les spammeurs sur mon serveur

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" <posteitaliane@test123.it>
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 posteitaliane@test123.itdans 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 test@test.de
250 mail.lotsearch.de
$ MAIL FROM: test@test.com
250 2.1.0 Ok
$ RCPT TO:<realEmail@gmail.com>
454 4.7.1 <realEmail@gmail.com>: 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/ )

— mfuesslin
source

"Si je surveille le trafic sortant sur tous les ports" ... Pourquoi? Quel autre trafic ce serveur de messagerie envoie-t-il? Êtes-vous sûr de ne pas avoir configuré de relais ouvert? Et personne avec un accès pour envoyer du courrier sur le serveur a divulgué des informations d'identification?

— Daniel Widrick

@DanielWidrick Le serveur de messagerie est également utilisé comme serveur Web, donc le trafic à 443 et 80 est également possible. J'ai pensé à une sorte de malware placé sur mon serveur communiquant directement avec des serveurs de messagerie externes (et non via le postfix du serveur de messagerie par défaut). À propos du relais ouvert: J'ai modifié ma question avec la vérification que j'ai effectuée pour m'assurer qu'il n'y a pas de relais ouvert. Il est difficile de répondre à votre dernière question car je ne connais pas la "santé" des ordinateurs de mes clients (où les comptes de messagerie de mon serveur sont configurés) ou s'ils ont été infectés par un malware / keylogger qui a obtenu des informations d'identification, etc.

— mfuesslin

Le disque est bon marché. Dans votre situation, il existe des arguments valables pour conserver la valeur d'un an de journaux. Pensez à utiliser syslog, etc. pour les expédier directement du serveur.

— Criggie

Réponses:

Avant d'arriver à ma suggestion, je voudrais commenter un peu quelque chose que votre fournisseur vous a dit:

 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

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.comsa HELO(ou EHLO) 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:

Received: from mail-io0-f197.google.com (mail-io0-f197.google.com [209.85.223.197])

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:

iptables -I OUTPUT -m owner ! --uid-owner postfix -m tcp -p tcp --dport 25 -j REJECT

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é.

— Michael Hampton
source

Merci pour votre réponse. Comment dois-je spécifier la 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?

— mfuesslin

Je ne sais pas comment faire ça avec Plesk. Nous ne traitons pas les questions concernant Plesk ici de toute façon.

— Michael Hampton

Ok, mais si je veux spécifier plusieurs utilisateurs qui ont permis d'envoyer des données via le port 25, puis-je simplement copier la règle iptables et en ajouter une deuxième avec l'autre utilisateur ou dois-je le spécifier dans une règle?

— mfuesslin

Probablement pas; il faudrait créer une chaîne d'utilisateurs, je pense.

— Michael Hampton

Une chose à propos de la règle iptables fournie: Êtes-vous sûr que nous n'avons pas besoin de définir la règle pour l'utilisateur root? Parce que le processus maître de postfix est exécuté par rootdans la plupart des cas. Ou le processus maître postfix postfixgé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 par postfix-user et un processus maître exécuté par root...

— mfuesslin

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.

— Francisco1844
source

@mfuesslin Mailchimp serait la mauvaise plateforme à utiliser. Mailchimp est un service de marketing par courriel, ce dont vous avez besoin est un service de courriel transactionnel. Regardez dans Mandrill (appartenant aux mêmes personnes qui possèdent Mailchimp). C'est 20 $ par mois pour un bloc de 25 000 courriels. Pas très chère. L'envoi quotidien de ces nombreux e-mails à partir de votre propre adresse IP se traduira uniquement par un taux de spam élevé ... c'est une bataille perdue. Vous pouvez embaucher une équipe entière pour ne rien faire, mais vous occuper de vos taux de délivrabilité toute la journée, et toujours pas aussi bien que d'utiliser un service transactionnel.

— SnakeDoc

Les personnes utilisant serverfault.com doivent être capables d'exécuter un serveur de messagerie; ce n'est pas si difficile à faire. Cela dit, il ne semble pas que le serveur de messagerie soit en faute, il ressemble à une page Web compromise qui envoie directement le spam.

— wurtel

@wurtel juste parce que l'on sait comment faire quelque chose, cela ne signifie pas que cela a du sens de le faire. Si vous pouvez trouver un service pour X / mois pour faire ce dont vous avez besoin et que cela vous prend 4X / mois de temps / effort pour le faire vous-même, cela n'a vraiment aucun sens de le faire vous-même.

— Francisco1844

@wurtel Capable? Oui. Vous livrez régulièrement dans la boîte de réception, envoyez plus de 1500 e-mails par jour? Discutable, et probablement non. - Personne ne dit que vous ne pouvez pas le faire ... seulement que pour bien le faire, de manière cohérente et sur une longue période de temps, cela vous coûtera beaucoup plus de 20 $ par mois .

— SnakeDoc

J'ai entretenu un tel serveur pendant 15 ans, envoyant régulièrement 30 à 50 000 messages de liste de diffusion en plus de centaines de messages par jour pour plusieurs domaines, et je passe rarement plus d'une heure par mois (en plus des mises à niveau régulières d'aptitude). Le serveur dessert de toute façon plusieurs sites Web, il n'y a donc pas d'investissement supplémentaire. Je suis un peu triste que les gens préconisent l'achat de services pour faire des choses que vous pouvez facilement faire vous-même. Rien de mal avec un peu d'apprentissage en cours de route.

— wurtel