* Patrick Ben Koetter <[email protected]>: > * Denny Hanschke <[email protected]>: > > Am 13.03.19 um 10:43 schrieb Carsten: > > > Moin zusammen. > > > > > > Mein Fail2Ban meldet mir immer mal wieder solche Versuche: > > > "... > > > Mar 12 12:33:03 derdapp004 postfix/smtpd[23102]: connect from > > > 16c13.w.time4vps.cloud[195.181.245.88] > > > Mar 12 12:33:03 derdapp004 postfix/smtpd[23102]: warning: > > > 16c13.w.time4vps.cloud[195.181.245.88]: SASL LOGIN authentication > > > failed: Invalid authentication mechanism > > > Mar 12 12:33:03 derdapp004 postfix/smtpd[23102]: disconnect from > > > 16c13.w.time4vps.cloud[195.181.245.88] > > > ..." > > > > > > Ich würde gerne den Mechanismus hinter dieser Art von Angriff verstehen, > > > da es sich wohl nicht um einen "normalen" Passwort Zugriff handelt. > > > Im Netz finde ich jedoch nichts dazu. > > > Kann mir mal jemand auf die Sprünge helfen? > > > > > > Gruss > > > Carsten > > > > Das ist keine besondere Attacke sondern nur der Versuch den Mechanismus > > LOGIN zu benutzen, den du nicht erlaubt hast. > > > > Mit LOGIN können sich lokale Benutzer unter Verwendung der /etc/shadow > > Datei am smtpd Anmelden um den Dienst in Anspruch zunehmen. > > Nope, das stimmt so nicht bzw. nur in einem ganz speziellen Setup und genau > dieses will $MAN vermeiden, weil für jeden E-Mail User dann auch ein > Systemuser angelegt werden muss. > > > LOGIN ist ein Mechanismus den ein Client nutzen kann, um die Identität seines > Benutzers an einen Server zu senden. (Bei LOGIN wird im ersten Roundtrip der > Benutzername und im Zweiten das Kennwort gesendet. PLAIN sendet, im Vergleich > dazu, beides in einem Rountrip)
s/Rountrip/Roundtrip/g > Der Server nimmt die Identitätsdaten dann und übergibt diese an einen Password > Verification Service (PWS). Der PWS greift dann über eine METHOD auf ein auth > backend zu und überprüft dort, ob die Identität authentifizert werden kann. s/PWS/PVS/g Password Werification Service, genau. Ich geh dann mal Kaffee holen... ;-) > Das Ergebnis liefert der PWS dann an den Server zurück und dieser kann in > Abhängigkeit davon eine Aktion des Client autorisieren oder ablehnen. > > > Ein PWS *kann* auf eine /etc/shadow zugreifen, muss es aber nicht. Er kann > ebenso auf einen SQL-Server, einen LDAP-Server, eine separate, binäre > User-Datenbank (sasldb2) oder noch ganz andere Backends, z.B. Kerberos, > zugreifen. Was da geht, hängt von der Implementierung des PWS ab. > > Setzt ihr cyrus als smtpd_sasl_type ein, geht alles was mit Cyrus SASL möglich > ist. Ist smtpd_sasl_type auf dovecot gesetzt, geht alles was über die > aktivierten /etc/dovecot/auth-* Komponenten eingerichtet wurde. > > p@rick > > Mehr zu Cyrus SASL: https://blog.sys4.de/tag/cyrus-sasl.html > > > -- > [*] sys4 AG > > https://sys4.de, +49 (89) 30 90 46 64 > Schleißheimer Straße 26/MG,80333 München > > Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 > Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief > Aufsichtsratsvorsitzender: Florian Kirstein > -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
