Angriff via Mail
Seite 3: Schutz
Schutz
Die primären Opfer -- also die Empfänger der provozierten NDN-Mails -- können sich kaum schützen. Wird Hans.Dampf@alle.gassen.de mit NDN-Mails zugeflutet, kann höchstens der für ihn zuständige Server die Annahme von Mails von bestimmten Servern verweigern, die sich als Multiplikatoren erwiesen haben. Das muss der Adminstrator dann jedoch von Hand einrichten.
Die missbrauchten Mail-Server, die die NDN-Mails versenden, haben ebenfalls unter dem erhöhten Mail-Aufkommen zu leiden und können unter Umständen Kapazitätsprobleme bekommen.
Mittelfristig muss es darum gehen, alle Mail-Server im Internet gegen diese Art von Mißbrauch abzusichern. Die wirksamste Gegenmaßnahme ist es, Mails an ungültige Adressen gar nicht erst anzunehmen. Leider ist dies in vielen konkreten Szenarien nicht einfach möglich, da vorgelagerte Gateways auf Spam und Viren filtern, aber dabei keinen Zugang zu User-Datenbanken haben. Hier lohnt es, darüber nachzudenken, ob und wie man die Informationen über die aktuell gültigen Adressen exportieren und dem Mail-Gateway bereitstellen kann.
Ist dies nicht möglich, gilt es, die Verstärkerfunktion der Gateways abzuschalten. Am besten wäre es, wenn der Mail-Server "All in One"-Notifications versendet, also den Absender in einer einzigen Mail darüber unterrichtet, dass die Zustellung von 1000 E-Mails nicht geklappt hat. Mail-Server wie Exim, Postfix und Sendmail machen das in der Default-Konfiguration ihrer aktuellen Versionen. Wie das im Zusammenspiel mit Antiviren-Software zu realisieren ist, muss man im Einzelfall untersuchen.
Des Weiteren sollte man das Quoting so weit als möglich reduzieren und lediglich die Informationen in die Benachrichtigung einbetten, die notwendig sind, eine Mail eindeutig zu identifizieren.
Kommt keine dieser Optionen in Frage, sollte man zumindest als Sofortmaßnahme den möglichen Verstärkungsfaktor begrenzen, indem man die maximale Zahl der möglichen Empfänger einer Mail festlegt beziehungsweise herabsetzt. RFC 821 empfiehlt zwar, dass ein Server nicht weniger als 100 Empfänger für eine Mail akzeptieren sollte (should). Doch diese Empfehlung stammt aus einer Zeit, als es primär darum ging, Last durch reguläre E-Mails zu reduzieren. Im Licht aktueller DoS-, Spam- und Wurm-Attacken sollte man sie nochmal überdenken. Aus unserer Sicht spricht auch nichts dagegen, schon heute in Einzelfällen mit deutlich niedrigeren Werten zu experimentieren. Die Seite zu Sofortmaßnahmen listet relevante Parameter für diverse Mail-Server.
Ausblick
Wir beobachten, dass diese Art von Angriffen bereits öffentlich diskutiert werden. Es gibt sogar erste Anzeichen, dass sie konkret für Denial-of-Service-Attacken eingesetzt werden. Die Situation ist durchaus ähnlich zu anderen Missständen im Netz wie den offenen Mail-Relays oder den Smurf-Attacken, bei denen falsch konfigurierte Router als Verstärker dienten -- nur dass wir bei den NDN-Angriffen erst die Spitze des Eisbergs sehen. Nur wenn jetzt möglichst schnell die betroffenen Server entsprechende Maßnahmen ergreifen, lässt sich ein Missbrauch in großem Stil vermeiden.
Wichtig ist in diesem Zusammenhang die Mitarbeit der Hersteller von Mail-Servern und Mail-Gateways. Insbesondere im Zusammenspiel mit Antiviren- und Anti-Spam-Software müssen sie verstärkt darauf achten, dass die Vervielfältigung von NDN-Mails unterbleibt. Des Weiteren helfen verbesserte Möglichkeiten, die Maximalgröße von NDNs zu reduzieren. Und schließlich sollte es einfach möglich sein, Listen mit gültigen E-Mail-Adressen aus externen Quellen zu importieren -- sei es als Textfile, über LDAP oder eine Datenbankanbindung.
Literatur
[1] Stefan Frei, Ivo Silvestri, Gunter Ollmann, Mail Non-Delivery Notice Attacks
[2] Sofortmaßnahmen
Stefan Frei arbeitet in Zürich für eine internationale Technologiefirma als Senior Security Consultant im Bereich Security Assessment Services. Schwerpunkte der Arbeit sind Security Research und Application Security Assessments für die größten Finanz-, Handels- und Telecombetriebe in Europa und Middle East. Homepage: www.techzoom.net
