Spam-Versand durch reguläre Accounts
19. Februar 2008
Heise schreibt, daß Spammer erste Testläufe für den Versand von Spam mit geknackten Kunden-Konten machen. Angekündigt habe ich dies schon 2005 auf dem 21C3, nun heißt es Gegenmaßnahmen zu treffen. Tarpitting ist ja sowieso schon Pflicht. Im Gegensatz zu altmodischer Spam besitzen diese Spam-Mails weitgehend korrekte Header, d.h. man könnte alle NDNs in ein Script pipen und den Return-Path herausholen. Sollte die Anzahl NDNs je Return-Path einen Schwellwert überschreiten, könnte man den Account aus dem Return-Path für den Versand sperren. Das reicht aber noch nicht. Immer weniger Mailserver senden überhaupt noch NDNs, einige blockieren zumindest per 5XX-Fehlermeldung beim SMTP-Dialog, wenn der Empfänger nicht existiert. Also müßte man auch die Logfiles in Echtzeit parsen (man bedenke dabei aber, der SMTP-Auth-Login ist ohne Reverse Split Horizon nicht zwingend die Absender-Adresse). Die Spammer werden vielleicht wieder versuchen, die Mails zu personalisieren damit die Bayes-Filter nicht trainiert werden, das würde aber viele Verbindungsaufbauten von wenigen IPs an den Ports 25 bzw. 587 bedeuten, was leicht zu begrenzen wäre.
Auch wollen sie bestimmt wieder von vielen Quell-IPs aus versenden, damit DCC oder Razor/Pyzor nicht anschlagen. Das setzt aber eine entsprechende Anzahl geknackter Konten auf verschiedenen Servern voraus. Und wenn sie (wie derzeit bei den meisten Fällen von Spam-Versand über Schwachstellen in Web-Applikationen) nur ein einziges Mal 1000 oder 3000 Mails je geknacktem Konto versenden, haben wir kaum Gegenmaßnahmen zur Hand. Ich glaube, diese Runde geht erstmal an die Spammer.
