29.05.2009 - Fachbeitrag

Brute-Force-Angriffe + Exploit über SMTP-Auth

Seit einiger Zeit sind systematische Brute-Force-Passwortangriffe nicht nur bei Diensten wie SSH oder FTP zu beobachten -- auch über SMTP-AUTH werden systematisch Logins durchprobiert. Gelingt es einem Angreifer die Login-Daten eines Nutzers zu knacken, so lassen sich darüber große Mengen Spam-Mails versenden. Außerdem ist mir kürzlich sehr glaubhaft zugetragen worden, daß es einen bislang nicht-öffentlichen Exploit im Bereich SASL gibt, der jedoch erst nach erfolgtem erfolgreichen SMTP-AUTH-Login ausnutzbar sein soll. Leider konnte ich bislang nicht recherchieren, welche Rechte der Angreifer erlangt und welche Software, bz.w. welche Softwareversionen davon betroffen sind. Die SMTP-Auth-Angriffe sind ebenso wie die SSH-Angriffe zu einem Großteil aus dem Netzbereich von CHINANET, aber auch die üblichen anderen bekanntermaßen spam- und hackerfreundlichen Netzbereiche sind in den Logfiles zu finden. Administratoren sollten überlegen, ob Sie den Zugriff auf die Ports 21 (FTP), 22 (SSH) systematisch für Provider wie Chinanet oder aber auch ggf. ganze Länderblöcke sperren (Listen: http://www.countryipblocks.net). SSH und FTP können recht einfach gesperrt werden, wenn man nicht davon ausgehen muß, daß eigene Kunden von diesen Ländern aus administrieren wollen. Eine Sperre von Port 25 (SMTP) und Port 80/443 (HTTP) hingegen wäre aus Sicht der auch dort erfolgenden Brute Force-Angriffe ebenso wünschenswert, doch sind dann Webseiten ebenso unbenutzbar, wie der Empfang privater oder geschäftlicher E-Mails aus China und den jeweils geblocken Netzbereichen. -Für ISPs dürfte das i.d.R. nicht durchsetzbar sein, Schutz hin oder her. Jedoch zeigt sich auch hier wieder einmal, daß es eine gute Idee ist, den Mailempfang (MX-Records im DNS) auf einen anderen Namen und auch eine andere IP-Adresse zeigen zu lassen, als den SMTP-Relayhost der in den Nutzer-Clients eingetragen ist. Denn wenn MX und SMTP-AUTH auf dem gleichen Server (jedoch mit verschiedenen IPs) abgewickelt werden, läßt sich nun der Zugriff über SMTP-AUTH bequem auch aus den verdächtigen Netzbereichen sperren, während der normale Mailempfang von anderen Mailservern unberührt bleibt. Ich persönlich sehe die Notwendigkeit der Trennung von MX und SMTP-Auth jedoch schon aus der Notwendigkeit eines jeweils eigenen Rate-Limitings für beide Dienste: Nur dann zieht ein Angriff auf einen MX-Server oder eine Spam-/Bounce-Welle nicht auch eine für den Nutzer spürbare Beeinträchtigung dar, wenn dieser seine SMTP-Auth Mails abliefern möchte.