Quelqu'un essaie de forcer (?) Mon serveur de messagerie privé ... très ... lentement ... et avec des adresses IP changeantes
Cela dure depuis environ 1-2 jours maintenant:
heinzi@guybrush:~$ less /var/log/mail.log | grep '^Nov 27 .* postfix/submission.* warning'
[...]
Nov 27 03:36:16 guybrush postfix/submission/smtpd[7523]: warning: hostname bd676a3d.virtua.com.br does not resolve to address 189.103.106.61
Nov 27 03:36:22 guybrush postfix/submission/smtpd[7523]: warning: unknown[189.103.106.61]: SASL PLAIN authentication failed:
Nov 27 03:36:28 guybrush postfix/submission/smtpd[7523]: warning: unknown[189.103.106.61]: SASL LOGIN authentication failed: VXNlcm5hbWU6
Nov 27 04:08:58 guybrush postfix/submission/smtpd[8714]: warning: hostname b3d2f64f.virtua.com.br does not resolve to address 179.210.246.79
Nov 27 04:09:03 guybrush postfix/submission/smtpd[8714]: warning: unknown[179.210.246.79]: SASL PLAIN authentication failed:
Nov 27 04:09:09 guybrush postfix/submission/smtpd[8714]: warning: unknown[179.210.246.79]: SASL LOGIN authentication failed: VXNlcm5hbWU6
Nov 27 05:20:11 guybrush postfix/submission/smtpd[10175]: warning: hostname b3d0600e.virtua.com.br does not resolve to address 179.208.96.14
Nov 27 05:20:16 guybrush postfix/submission/smtpd[10175]: warning: unknown[179.208.96.14]: SASL PLAIN authentication failed:
Nov 27 05:20:22 guybrush postfix/submission/smtpd[10175]: warning: unknown[179.208.96.14]: SASL LOGIN authentication failed: VXNlcm5hbWU6
Nov 27 06:42:43 guybrush postfix/submission/smtpd[12927]: warning: hostname b18d3903.virtua.com.br does not resolve to address 177.141.57.3
Nov 27 06:42:48 guybrush postfix/submission/smtpd[12927]: warning: unknown[177.141.57.3]: SASL PLAIN authentication failed:
Nov 27 06:42:54 guybrush postfix/submission/smtpd[12927]: warning: unknown[177.141.57.3]: SASL LOGIN authentication failed: VXNlcm5hbWU6
Nov 27 08:01:08 guybrush postfix/submission/smtpd[14161]: warning: hostname b3db68ad.virtua.com.br does not resolve to address 179.219.104.173
Nov 27 08:01:13 guybrush postfix/submission/smtpd[14161]: warning: unknown[179.219.104.173]: SASL PLAIN authentication failed:
Nov 27 08:01:19 guybrush postfix/submission/smtpd[14161]: warning: unknown[179.219.104.173]: SASL LOGIN authentication failed: VXNlcm5hbWU6
Il y a une seule tentative de connexion échouée toutes les 1-2 heures, toujours à partir du même domaine, mais à chaque fois à partir d'une adresse IP différente. Ainsi, cela ne déclenchera pas fail2ban et les messages de vérification du journal commencent à m'ennuyer. :-)
Mes questions:
Quel est l'intérêt de ce type "d'attaque"? Le taux est beaucoup trop lent pour effectuer un forçage brutal efficace, et je doute vraiment que quelqu'un cible spécifiquement mon minuscule serveur personnel.
Y a-t-il quelque chose que je puisse faire contre cela, sauf interdire la plage IP complète de ce fournisseur? Je pourrais juste arrêter de m'inquiéter et ajouter ces messages à ma configuration ignorer logcheck (car mes mots de passe sont forts), mais cela pourrait me faire manquer des attaques plus graves.
Quel est l'intérêt de ce type "d'attaque"? Le taux est beaucoup trop lent pour effectuer un forçage brutal efficace, et je doute vraiment que quelqu'un cible spécifiquement mon minuscule serveur personnel.
Le taux est lent, ou le total quantité de données envoyées est-il petit? Vous pouvez voir des connexions très rarement, mais comment savez-vous que les robots faisant le forçage brutal ne saturent pas constamment leurs liaisons montantes, et votre site n'est qu'un des nombreux attaqués? Il n'y a aucun avantage pour un attaquant à passer un peu de temps à rechercher un site à la fois (et à déclencher fail2ban), par rapport à attaquer un grand nombre de serveurs à la fois, où chaque serveur ne voit que des connexions peu fréquentes. Les deux peuvent avoir le même taux de tentatives d'authentification sortantes par seconde.
Y a-t-il quelque chose que je puisse faire contre cela, sauf interdire la plage IP complète de ce fournisseur (ou ignorer les messages, car mes mots de passe sont forts)?
Peu probable. Il y a de fortes chances qu'ils proviennent d'un botnet ou d'un cluster de VPS à faible coût. Il n'est pas possible de déterminer quelles autres plages IP peuvent être utilisées simplement en en voyant quelques-unes. S'ils ne sont pas sur le même sous-réseau, ils ne peuvent pas être prédits. Vous pouvez ignorer ces connexions en toute sécurité. Ce n'est rien de plus que le bruit de fond d'Internet.
Question 1 - Sauf s'il s'agit d'une mauvaise configuration (comme mentionné dans les commentaires), d'après mon expérience, il semble que ce soient des attaques automatisées recherchant des comptes à partir desquels des e-mails commerciaux non sollicités (ou des tentatives de phishing) peuvent être envoyés.
Question 2 - Si la plage d'adresses IP d'où proviennent vos connexions légitimes est connaissable et suffisamment petite, il peut être plus facile de tout bloquer à l'exception de ces plages.
J'administre un serveur de messagerie pour petite entreprise, ce type de sondage se produit presque en continu pour nous.
1 tentative toutes les 1-2 heures? Ce n'est pas une force brute.
Peut-être que c'est l'iPhone de quelqu'un avec un mot de passe expiré. Votre problème! Ou, si vous réutilisez les adresses IP d'une société d'hébergement, l'ancien "propriétaire" pourrait toujours avoir un client de messagerie quelque part, configuré pour accéder à [maintenant] vos adresses IP.
Si vous avez les adresses IP, le moins que vous puissiez faire est de les retrouver.
La pratique standard existante d'interdire les adresses IP qui tentent à plusieurs reprises de pénétrer dans un système ne fonctionne que contre les attaques ciblées.
Un botnet peut trouver une énorme liste de serveurs et distribuer à la fois qui fait l'attaque et qui ils attaquent parmi le botnet. Le symptôme va être un niveau d'arrière-plan de tentatives de connexion infructueuses sur votre système, jusqu'à ce que l'on réussisse, auquel cas ils déploieront un kit qui dégénère en root et ajoutera votre système au botnet.
Vous pouvez vous défendre contre cela de très peu de façons.
Les mots de passe forts sont une défense possible, mais doivent être associés à la protection de votre système contre les attaques sans mot de passe. Supposons qu'il sorte qu'il y ait une attaque de dépassement/dépassement de tampon sur votre système de connexion; le botnet pourrait être commuté pour effectuer cette attaque et rooter des milliers de systèmes par minute, y compris le vôtre.
Une autre défense pourrait être l'obscurité. Ce type d'attaques s'attaque aux fruits à faible pendaison. Modifiez votre système de connexion pour (disons) exiger un ping vers un numéro de port particulier avant de laisser passer les tentatives de connexion. C'est purement de l'obscurité, mais soudain, cela cesse de ressembler à un endroit pour s'y connecter. Le coût est que vous devez maintenant créer un ping spécifique pour vous connecter à distance. Ou vous pouvez ajouter à la liste blanche quelques adresses IP à partir desquelles vous êtes autorisé à vous connecter à distance.
Une dernière approche extrêmement difficile serait de générer un détecteur de système de piratage de mot de passe de botnet distribué. Tout comme les systèmes gardent la trace des adresses IP qui les attaquent, un système distribué pourrait garder la trace des botnets attaquant n'importe qui. Ajoutez un système de confiance et vous pourriez construire une infrastructure capable de détecter de tels botnets de piratage de mot de passe et que tout le monde les bloque.
Un tel effort demanderait des années de travail et échouerait probablement. Mais c'est quelque chose que vous pourriez faire.
Échec de l'authentification SASL PLAIN: et b3db68ad.virtua.com.br ne résout pas l'adresse 179.219.104.173
Tant que l'authentification PLAIN n'est activée pour aucun utilisateur, vous devriez être d'accord. De plus, ceci: b3db68ad.virtua.com.br ne résout pas l'adresse 179.219.104.173 qui vous indique que le (s) domaine (s) est un faux domaine, car il ne résout pas l'IP utilisée. Un autre échec. Donc, il ne vient peut-être même pas de ce domaine. Vous pouvez passer beaucoup de temps avec les règles d'écriture de Postfix pour interdire ce genre de chose, mais au final le temps que vous passez dépasse de loin la charge de votre système.