Warum verbinden sich Leute wiederholt mit meinem MTA, tun nichts und gehen?

Ich habe einen Sendmail-Server. In regelmäßigen Abständen (dh mehrmals pro Stunde) erhalte ich folgende Protokolleinträge:

Sep  3 10:06:49 lory sendmail[30561]: v8396nsQ030561: [37.49.226.159] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6
Sep  3 10:06:49 lory sendmail[30564]: v8396nmv030564: [37.49.226.159] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6
[29 very similar lines deleted]
Sep  3 10:06:50 lory sendmail[30654]: v8396or0030654: [37.49.226.159] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6
Sep  3 10:06:50 lory sendmail[30657]: v8396ou3030657: [37.49.226.159] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6

Dieser spezielle Server lief ein bisschen mit dieser Geschwindigkeit weiter, wurde dann platzend und erreichte in den 110er Jahren insgesamt 600 Verbindungen. andere sind weniger prolix. Sie verursachen auf meinem Server keine Probleme. fail2banwird ein wenig trainiert, indem die Mail-Protokolldatei auf SMTP-AUTH-Fehler überprüft wird und all diese neuen Einträge ignoriert werden müssen, aber es bringt den Server nicht ins Schwitzen.

Ich bin neugierig und frage, warum jemand so etwas tun würde. Hoffen sie, dass meine Relaying- / Greylisting- / SPF-Engine ein sehr kleines Gehirn hat, und nach 500 Verbindungen sagt sie sich, meine Güte, sie sind wirklich daran interessiert, mit mir zu sprechen. Ich würde besser alles akzeptieren, was sie jetzt senden ? Hoffen sie, dass mein Server keine Ersatz-VM hat und sendmail den OOM-Killer aufbläht und aufruft, also DoSsing me? Ich nehme an, jemand tut so etwas aus einem bestimmten Grund, aber hat jemand die geringste Ahnung, was dieser Grund sein könnte?

security sendmail

— MadHatter
quelle

Niemals der Bosheit das zuschreiben, was durch Dummheit angemessen erklärt wird ;)

— HBruijn

@HBruijn Niemals Dummheit als (offizielle) Entschuldigung für Bosheit unterschätzen :-)

— AnFi

Wahrscheinlich durchsucht jemand das Netzwerk nach anfälligen Softwareversionen.

— ThoriumBR

@ThoriumBR Ich bin nicht überzeugt: Warum sollten sie 600 Mal eine Verbindung herstellen müssen, um die Softwareversion herauszufinden? Entweder erfahren Sie es beim ersten Herstellen einer Verbindung, oder der Dienst ist so konfiguriert, dass er es Ihnen nicht mitteilt - es sei denn, Sie kennen einen MTA, dessen Verhalten sich nach mehreren schnellen seriellen Verbindungen ändert , was sehr nützlich wäre .

— MadHatter

Die sendmail- Warnungen "hat während der Verbindung zu MTA keine MAIL / EXPN / VRFY / ETRN ausgegeben" werden nicht unerwartet durch Authentifizierungsversuche ausgelöst, die abgelehnt werden, aber nicht nur, wenn eine falsche Kombination aus Benutzername und Kennwort angegeben wird, sondern Sie denselben Fehler sehen auch wenn die Authentifizierung nicht unterstützt wird (oder zumindest ohne TLS nicht zulässig ist):

telnet localhost 25
   Trying 127.0.0.1...
   Connected to localhost.
   Escape character is '^]'.
   220 hbruijn ESMTP Sendmail 8.14.4/8.14.4; Fri, 8 Sep 2017 13:06:31 +0200
AUTH LOGIN
   504 5.3.3 AUTH mechanism LOGIN not available
QUIT

Dies generiert den Typ des angezeigten Protokollereignisses:

8. September 13:06:39 hbruijn sendmail [11333]: v88B6VYg011333: localhost [127.0.0.1] hat während der Verbindung zu MTA kein MAIL / EXPN / VRFY / ETRN ausgegeben

Es werden keine tatsächlichen Benutzernamen protokolliert, da die "Angreifer" nicht einmal das Stadium erreichen, in dem sie einen Benutzernamen oder ein Kennwort eingeben können.

Wenn ich mich mit STARTTLS verbinde und eine (falsche) Kombination aus Benutzername und Passwort eingebe, protokolliert sendmail genau den gleichen Fehler.

openssl s_client -starttls smtp -connect localhost:25
   250 HELP
AUTH LOGIN
   334 VXNlcm5hbWU6
bXl1c2VybmFtZUBkb21haW4uY29t
   334 UGFzc3dvcmQ6
d2Vha3Bhc3M=
   535 5.7.0 authentication failed
QUIT
   DONE

Dadurch wird eine zusätzliche Protokollzeile generiert, danach jedoch genau das gleiche Ereignis.

8. September 13:24:22 hbruijn sendmail [11648]: STARTTLS = Server, Relay = localhost [127.0.0.1], Version = TLSv1 / SSLv3, verifizieren = NEIN, Verschlüsselung = DHE-RSA-AES256-GCM-SHA384, Bits = 256/256
8. September 13:24:32 hbruijn sendmail [11648]: v88BOMvW011648: localhost [127.0.0.1] hat während der Verbindung zu MTA kein MAIL / EXPN / VRFY / ETRN ausgegeben

Niemals der Bosheit das zuschreiben, was durch Dummheit angemessen erklärt wird:

Meine eigene Domain erhält nicht viel E-Mail, aber ausreichend Internet-Hintergrundgeräusche in Bezug auf Port-Scans und Brute-Force-Versuche. Ich habe den gesamten SMTP-Verkehr in den letzten Tagen erfasst und zusätzlich zu einigen eindeutigen IP-Adressen, die solche Protokollereignisse auslösen, hatte mein Server zwei IP-Adressen, die nicht zurückgingen, als meine Sendmail antwortete, AUTHdie nicht unterstützt wurde ( ohne TLS), was zu einer großen Anzahl von Warnungen von diesen IPs führt.

Zumindest für diese beiden IP-Adressen war es wie erwartet, sie scheinen nur dumme und dumme Malware-Programme zu sein, die anscheinend eine Liste von Benutzernamen / Passwörtern durcharbeiten, ohne wirklich eine Fehlerkontrolle durchzuführen und nach dem anfänglichen Fehler nicht zurückzutreten (was mich wundert ob sie überhaupt erkennen könnten, ob / wann sie erfolgreich sind ...)

und das zugehörige Protokoll:

10. September 04:04:34 hbruijn sendmail [7558]: v8A24YLM007558: [196.196.27.126] hat während der Verbindung zu MTA keine MAIL / EXPN / VRFY / ETRN
ausgegeben. 10. September 04:04:34 hbruijn sendmail [7561]: v8A24Yi1007561: [ 196.196.27.126] hat während der Verbindung zu MTA kein MAIL / EXPN / VRFY / ETRN
ausgegeben. 10. September 04:04:34 hbruijn sendmail [7564]: v8A24YHM007564: [196.196.27.126] hat während der Verbindung kein MAIL / EXPN / VRFY / ETRN ausgegeben zu MTA
10. September 04:04:35 hbruijn sendmail [7567]: v8A24YSY007567: [196.196.27.126] hat während der Verbindung zu MTA
10. September 04:04:35 hbruijn sendmail [7570]: v8A24ZC2007570 keine MAIL / EXPN / VRFY / ETRN ausgegeben : [196.196.27.126] hat während der Verbindung zu MTA kein MAIL / EXPN / VRFY / ETRN ausgegeben
10. September 04:04:35 hbruijn sendmail [7573]: v8A24ZYo007573: [196.196.27.126] hat während der Verbindung zu MTA keine MAIL / EXPN / VRFY / ETRN
ausgegeben. 10. September 04:04:35 hbruijn sendmail [7576]: v8A24ZLt007576: [ 196.196.27.126] hat während der Verbindung zu MTA keine MAIL / EXPN / VRFY / ETRN
ausgegeben. 10. September 04:04:35 hbruijn sendmail [7579]: v8A24Zva007579: [196.196.27.126] hat während der Verbindung keine MAIL / EXPN / VRFY / ETRN ausgegeben zu MTA

— HBruijn
quelle

Ich verstehe Ihren Standpunkt (nachdem ich ihn anfangs verpasst habe). Oh, das ist elegant, und nachdem es getestet wurde, erzeugt es genau den gleichen Protokoll-Footprint (mein Server benötigt dies auch TLSvor dem Anbieten AUTH). Ich hatte nicht vermutet, authdass bei einem fehlgeschlagenen Authentifizierungsversuch kein Syslog-Footprint vorhanden sein würde , da die Einrichtung zu diesem Zeitpunkt der Transaktion nicht verfügbar war . Ich würde gerne einen meiner eigenen Angreifer im laufenden Betrieb fangen, um dies zu bestätigen, aber diese Erklärung ist sinnvoll - vielen Dank! Wohlverdientes Kopfgeld bei Bestätigung.

— MadHatter

@MadHatter Vielen Dank für Ihr Feedback. Mein Punkt war in der Tat nicht sehr klar und ich habe meine Antwort aktualisiert, um meinen Punkt zu verdeutlichen, dass Sie denselben Fehler sehen, unabhängig davon, ob die Authentifizierung unterstützt wird oder nicht, und dass viele wiederholte Protokollereignisse wahrscheinlich sehr schlecht sind geschriebene Malware, die nicht nach Fehlerantworten sucht.

— HBruijn

Der Unterschied im zweiten Fall (TLS aktiviert, AUTH versucht) besteht darin, dass entsprechende saslauthd-Syslog-Einträge vorhanden sind (Facility authpriv). Mein Rätsel war, dass ich nur die sendmail-Verbindungsprotokolle und keine anderen Protokollaktivitäten erhielt. Ich hätte nie einen Moment lang davon geträumt, dass Leute Brute-Forcing-Code ausführen würden, der nicht einmal prüfte, ob er versuchen könnte, sich vorher anzumelden .

— MadHatter

Gefangen - genau wie bei Ihnen. Das System lässt mich das Kopfgeld noch nicht vergeben, also werde ich versuchen, mich daran zu erinnern, das morgen zu tun. Übrigens war mein einleitender Kommentar zum anfänglichen Fehlen Ihres Standpunkts eine Kritik an mir , da ich Ihre Antwort nicht ausreichend sorgfältig gelesen habe, bevor ich zu dem Schluss kam, dass sie nicht hilfreich war. Nachdem ich es erneut gelesen und verstanden hatte, vermutete ich schnell, dass Sie Recht hatten. Ich denke ehrlich, Ihre Antwort war in ihrer früheren Form besser, aber es liegt natürlich an Ihnen, nach Belieben zu polieren!

— MadHatter