Connexion Postfix perdue après AUTH


12

En regardant les journaux de mes serveurs de messagerie, j'ai remarqué des messages comme les suivants:

Nov 29 12:09:38 mta postfix/smtpd[8362]: connect from unknown[183.13.165.14]
Nov 29 12:09:39 mta postfix/smtpd[8362]: lost connection after AUTH from unknown[183.13.165.14]
Nov 29 12:09:39 mta postfix/smtpd[8362]: disconnect from unknown[183.13.165.14]
Nov 29 12:09:39 mta postfix/smtpd[8409]: connect from unknown[183.13.165.14]
Nov 29 12:09:40 mta postfix/smtpd[8409]: lost connection after AUTH from unknown[183.13.165.14]
Nov 29 12:09:40 mta postfix/smtpd[8409]: disconnect from unknown[183.13.165.14]

Il n'y a pas de défaillance SASL dans ces cas. Il y a des échecs SASL qui sont enregistrés à d'autres moments, mais jamais avec lost connection after AUTH.

Que se passe-t-il ici et dois-je faire quelque chose à ce sujet?
Ce ne sont pas des MX et ils ont déjà été smtpd_client_connection_rate_limitdéfinis.

Peut-être liés:
Les systèmes nécessitent SMTPS ou STARTTLS avant l'annonce d'AUTH.


Pouvez-vous augmenter le niveau de débogage de postfix?
Khaled

Je peux, mais cela augmentera les fichiers journaux à un rythme considérablement plus élevé, et ces événements sont sporadiques. Qu'est-ce que cette journalisation accrue aidera à lever les ambiguïtés?
84104

1
Donc, vous devez l'augmenter pendant une petite période de temps et lorsque vous prévoyez d'obtenir cette erreur. J'espère que cela donne plus d'indications sur la signification de cette erreur.
Khaled

Réponses:


9

Il s'agit d'un botnet en provenance de Chine qui se connecte à votre box et tente de diffuser du spam. Mais le bot est trop stupide pour savoir quoi faire lorsqu'on lui dit de s'authentifier. Le bot arrête simplement de livrer le courrier, puis se déconnecte pour attaquer la prochaine victime.

Absolument rien à craindre.


3
Assez proche. Il semble que ce soit une sorte de script qui émette AUTH et se termine mal après avoir reçu 503 5.5.1 Error: authentication not enabled. A pu répliquer avec ncat. Mais pourquoi il continue d'essayer jusqu'à ce qu'il atteigne la limite de taux me dépasse. Peut-être essaie-t-il de forcer les paires nom d'utilisateur / mot de passe? De toute façon, trop stupide et trop inquiet.
84104

2
À titre de test, je n'obtiens cette ligne que dans mes journaux et je ne vois jamais d'échecs SASL en utilisant simplement Thunderbird et un mot de passe invalide pour un compte connu. Étant donné que le courrier authentifié passe toujours par Postfix sans entrave, la bonne réponse consiste, si possible, à utiliser le script fail2ban publié pour limiter au minimum le nombre de tentatives de force brute. Les tentatives de mot de passe de force brute sont quelque chose dont il faut absolument s'inquiéter pour éviter de transformer votre boîte en relais ouvert - surtout s'il s'agit de la seule ligne dans vos journaux.
CubicleSoft

Les journaux semblent en avoir un par seconde, ce qui pourrait être quelqu'un qui essaie de forcer le serveur, ce qui EST quelque chose à craindre. Je recommande d'utiliser le fail2ban, au minimum. Il ne résoudra pas complètement un problème de force brute, mais il l'atténuera considérablement.
Severun

21

Mes fichiers journaux se remplissaient, et c'est un gaspillage de CPU pour même autoriser une connexion à partir de ces saccades. J'ai créé une fail2banrègle.

Jul 11 02:35:08 mail postfix/smtpd[16299]: lost connection after AUTH from unknown[196.12.178.73]

Contenu de /etc/fail2ban/jail.conf

[postfix]
# Ban for 10 minutes if it fails 6 times within 10 minutes
enabled  = true
port     = smtp,ssmtp
filter   = postfix
logpath  = /var/log/mail.log
maxretry = 6
bantime  = 600
findtime = 600

Contenu de /etc/fail2ban/filter.d/postfix.conf

# Fail2Ban configuration file
#
# Author: Cyril Jaquier
#
# $Revision$
#

[Definition]

# Option:  failregex
# Notes.:  regex to match the password failures messages in the logfile. The
#          host must be matched by a group named "host". The tag "<HOST>" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P<host>[\w\-.^_]+)
# Values:  TEXT
#

# Jul 11 02:35:08 mail postfix/smtpd[16299]: lost connection after AUTH from unknown[196.12.178.73]

failregex = lost connection after AUTH from unknown\[<HOST>\]

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex = 

2
Cela m'a sauvé la journée. J'ai ajouté la règle suivante: failregex = ^%(__prefix_line)slost connection after AUTH from \S+\[<HOST>\].$. J'ai eu plusieurs centaines de tentatives de connexion en quelques minutes. Je devais y faire quelque chose.
chmike

C'est un peu plus générique:failregex = lost connection after AUTH from (.*)\[<HOST>\]
CubicleSoft

@chmike: Le point avant la fin $doit être supprimé. N'a pas fonctionné ici avec elle dans l'expression régulière.
cweiske

3

En smtpd_recipient_restrictionsjuste reject_unknown_client_hostnamecomme ceci:

smtpd_recipient_restrictions = reject_unknown_client_hostname

et cela entraînera le rejet de clients et de robots zombies errants ou stupides avec des noms d'hôte inconnus. Vos journaux ressembleront à ceci une fois définis:

postfix/smtpd[11111]: NOQUEUE: reject: RCPT from unknown[183.13.165.14]: 450 4.7.1 Client host rejected: cannot find your hostname, [183.13.165.14]

Il existe déjà une réponse acceptée pour cette (très ancienne) question.
BE77Y

1
Le nom d'hôte inconnu n'était / n'est pas le problème. lost connection after AUTHétait / est.
84104

1
Leur problème est "Qu'est-ce qui se passe ici, et dois-je faire quelque chose?" Et c'est une réponse parfaitement valable.
inorganik

2

Je ne sais pas s'il y a de quoi s'inquiéter, essentiellement un client / «quelqu'un» se connecte, émet AUTH et se déconnecte de son propre gré. Cela peut être une tentative de sonder les capacités du serveur à partir d'un client de messagerie - ou une tentative de casse du démon.

Tant que vous avez suffisamment de sécurité en place, c'est juste un autre coup à la porte du monde.


Même si cela se produit 3 ou 4 fois de suite?
Alexis Wilke
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.