Frage nach etwas tieferem Knoff-Hoff über SASL Atacken

[Patrick Ben Koetter]

* Patrick Ben Koetter <postfix-users at de.postfix.org>:
> * Denny Hanschke <postmaster at blubbablasen.de>:
> > 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 at 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