Wird Ihr Server für Mail-Spamming missbraucht?

Unwissenheit mag ja im Allgemeinen nicht unbedingt von Nachteil sein, doch im IT-Bereich kann sie schwerwiegende Probleme verursachen. Es folgt ein aus erster Hand stammender Bericht darüber, wie die Unkenntnis meiner Abteilung bezüglich der Mail-Weiterleitung über Microsoft Exchange 5.5 dazu führte, dass unser Server für das Spamming unerwünschter Junk-Mails missbraucht wurde. Dies endete schließlich damit, dass unser Mail-Server auf eine Blackhole List gesetzt wurde, wodurch wiederum einige unserer versendeten Nachrichten von anderen Unternehmen gesperrt wurden, deren Mail-Server diese Listen zur Vermeidung von Spamming verwenden.

Wie alles anfingVor einigen Monaten fiel mir der folgende Event-Log-Eintrag auf unserem Exchange 5.5-Server auf:

An: Somepoorschnook@bigisp.com
Von: zoosmutz@hooya.com
Betreff: Come have a wild time with us
Nachrichtentext: 550 Relaying not allowed.

Es folgten zahlreiche weitere Nachrichten wie diese. Einige konnten nicht übermittelt werden, da sich die betreffenden Accounts geändert hatten oder die Postfächer voll waren. Dennoch hatten die Nachrichten eines deutlich gemacht: die Spammer hatten das offene Mail-Relay auf unserem Exchange-Mail-Server entdeckt.

Wir wussten durch einen Microsoft Knowledge Base-Artikel zum Thema, wie die Nutzung von Exchange als Mail-Relay für Spamming verhindert werden kann. Das Ganze war rasch installiert und funktionierte hervorragend, bis auf die Tatsache, dass es Servers Alive blockierte, eine wichtige Anwendung zur Überwachung des Netzwerks, welche uns auf Netzwerk-Probleme aufmerksam machen sollte.

Servers Alive ist eine erstklassige Software, die eine Reihe von Überprüfungen auf unseren Servern und Routern ausführt und E-Mail-Benachrichtungen an unseren E-Mail-Account und an unsere Mobiltelefone sendet, so dass wir umgehend auf Ausfälle aufmerksam gemacht werden. Als wir die Überprüfung des Relays in Exchange implementierten, stellte Servers Alive die Versendung der Benachrichtigungen ein. Wir verbrachten Tage damit, herauszufinden, weshalb die Software nicht mehr arbeitete. Dennoch fanden wir keine andere Lösung, als die Überprüfung des Relays in Exchange zu deaktivieren. Nun konnten wir nur noch hoffen, dass uns die Spammer nicht finden würden. Leider war dem nicht so.

Es war ein Donnerstagmorgen, als die erste Event Log-Benachrichtung einging. Wir versuchten es erneut mit dem Blockieren des Relays, in der Hoffnung, dass die Computer-Götter diesmal Servers Alive weiterhin seine Benachrichtigungen senden ließen, doch schließlich standen wir wieder vor demselben Problem. Als nächstes versuchten wir, das Spamming am Firewall einzudämmen. Wir hatten einige Monate zuvor einen neuen Raptor-Firewall installiert, in dessen Handbuch wir genau das Richtige fanden. Eine Reihe von Einstellungen im SMTP-Control würden den Traffic sperren. Zufällig gab es da auch eine Einstellung, durch die Raptor auf eine externe Datenbank unter www.ordb.org zugreifen konnte, was die Blockierung von Spammern unterstützen sollte.

Das Ende der GeschichteDieser Vorfall hatte uns die Augen geöffnet. Bis vor ein paar Monaten hatten wir keine Ahnung davon, dass viele E-Mail-Server als Relay für Nachrichten an andere Mail-Server dienen können, ohne selbst Urheber oder Empfänger der betreffenden Nachrichten zu sein. Tatsächlich waren wir nur durch Zufall auf den in der Microsoft Knowledge Base enthaltenen Artikel über Mail-Weiterleitung gestoßen.

Ein Blick auf die Statistiken in der ORDB-Website belegt, dass wir mit unserer Unwissenheit nicht allein sind. Es scheint, dass die Anzahl der festgestellten offenen Relays schneller wächst, als diese geschlossen werden. Ein Besuch der ORDB-Website lohnt sich auf jeden Fall. Sie finden hier umfassende Informationen zu offenen Relays und wie diese geschlossen werden können, außerdem werden neben Statistiken und Links zu anderen Blackhole-Datenbanken zahlreiche weitere Tipps geboten. Prüfen Sie, ob Sie Ihr Unternehmen und andere Benutzer nicht vor den unerwünschten Nachrichten der Spammer schützen können.

© 2002 TechRepublic, Inc.