Mißbrauch von Mail-Servern an der TU Wien

Martin Rathmayer

Seit längerer Zeit nimmt leider eine Unart überhand, die für die Betroffenen eine ziemliche Belästigung darstellt und den Netzbetreibern eine Menge Arbeit bereitet: das sogenannte Mail-Spamming; d.h. das Versenden unerwünschter Mails an eine große Anzahl von Personen.

Die Probleme, die daraus entstehen, sind folgende:

1. Empfänger beschweren sich nicht nur beim „Postmaster“ des Senderechners, sondern auch bei allen beteiligten Mail-Routern oder Servern. Im Falle der TU erfolgt meistens eine Beschwerde an den Postmaster des Mail-Routers der TU Wien. Die Beantwortung der zahlreichen Mails kostet dem Administrator dieses Rechners viel Zeit.

2. Auf Grund der großen Anzahl an Mails, die versendet werden, und diverser Zustellungsprobleme kommt es oft zu Mail-Staus auf allen involvierten Mail-Routern und -Servern, was den normalen Betrieb erheblich beeinträchtigt.

3. User und Betreiber von anderen Mail-Servern sperren ihre Mail-Zugänge gegenüber unerwünschten Sendern. Oftmals werden gleich ganze Domains gesperrt, wodurch auch Unschuldige zum „Handkuß“ kommen. Die abgewiesenen Mails verstärken noch zusätzlich einen vorhandenen Mail-Stau.

4. Spammer, denen bereits auf vielen Rechnern der Zugang gesperrt wurde, umgehen diese Restriktionen, indem sie ihre Mails über andere Mail-Server „routen“ (Mail-Relaying). Leider hat das oft zur Folge, daß dann auch diesen Servern der Zugang gesperrt wird. Wenn solche Server dann auch noch ihre Mails über einen weiteren zentralen Mail-Router verschicken, kommt es nicht nur auch dort zu Mail-Staus, sondern es kann auch diesem Rechner der Zugang verwehrt werden. Besonders im Fall zentraler Mail-Router wie der der TU Wien entstehen durch solche Konsequenzen starke Beeinträchtigungen eines wichtigen Services.

5. Es werden sogenannte „Black Lists“ gehandelt, die Adressen von Spammern oder ganze Rechnernamen enthalten, die bereits einmal beteiligt waren. Leider gelangen manchmal auch „unschuldige“ Rechner auf diese Liste, weil diese in ihrer Funktion als Mail-Server eben als Mail-Relay mißbraucht wurden.

Wie ist dieser Problematik nun entgegen zu wirken bzw. welche Verantwortung haben die Betreiber von Mail-Servern (z.B. Instituts- Mailbox-Rechner oder Arbeitsplatz-Workstation) TUNET gegenüber ?

1. Jeder Betreiber eines Mail-Servers am TUNET hat dafür zu sorgen, daß sein Rechner nicht als Mail-Relay mißbraucht werden kann, d.h. nicht indirekt dazu beiträgt, eine Gruppe von Usern mit Spam-Mails zu belästigen. Lediglich ein Kreis von lokalen Rechnern (z.B. Instituts-PCs) sollten den Server als Mail-Relay verwenden dürfen.

2. Sollte bereits ein Mißbrauch erfolgt sein und aus software-technischen oder anderen Gründen das Mail-Relaying nicht abgedreht werden können, muß der Mail-Zugang zu diesem Server sofort unterbunden werden.

3. Prinzipiell muß jeder Betreiber eines TUNET-Rechners dafür sorgen, daß sein Gerät nicht direkt oder indirekt für einen Mißbrauch herangezogen werden kann und TUNET oder Teile davon in Mißkredit bringt.

Wie hat das EDV-Zentrum auf diese Situation reagiert ?

Im Falle des Mail-Routers der TU Wien wurde die Software sofort umgeschrieben, damit das Mail-Relaying nur mehr in gewünschten Kombinationen möglich ist (von außerhalb der TU in die TU und umgekehrt). Weiters wird gefordert, daß alle Senderechner komplett und korrekt im Domain Name Service eingetragen sind, d.h. jeder Rechner muß außer seinem Namenseintrag noch einen Revers-DNS-Entry besitzen, sonst wird er abgewiesen.

Was kann nun der Betreiber eines Mail-Servers im einzelnen unternehmen, um einen solchen Mißbrauch (unerwünschtes Mail-Relaying) zu verhindern ?

Prinzipiell ist zu sagen, daß auf alle Fälle rechtzeitig etwas unternommen werden sollte und regelmäßig alle relevanten Logfiles durchgesehen werden müssen. Nur so kann einem Mißbrauch vorgebeugt bzw., wenn es dann passiert, so rasch wie möglich darauf reagiert werden.

Die Lösungen sind in der Regel plattform- oder produktspezifisch. Die meisten Unix-basierenden Betriebssysteme verwenden als Mail-Software ein mehr oder weniger herstellerspezifisches Derivat von „sendmail“. Damit diese Software nur eingeschränkt zum Mail-Relaying verwendet werden kann, muß die Konfigurationsdatei modifiziert werden. Außerdem ist eine Version notwendig, die mindestens auf einer Sendmail-Version 8.8.5 basiert. Falls der Hersteller keinen Patch anbietet (für HP gibt es z.B. einen Patch), muß eine aktuelle Version selbst übersetzt werden. Ihr Plattformbetreuer vom EDV-Zentrum hat wahrscheinlich schon eine entsprechende Version fertig bzw. kann Ihnen dabei helfen. Detaillierte Informationen finden Sie außerdem im WWW unter

http://www.sendmail.org/antispam.html
http://www.glenns.org/sendmail.antispam.html
http://www.abuse.net/
http://spam.abuse.net/
http://www.cauce.org/
http://maps.vix.com/tsi/

Die angesprochenen Modifikationen unterbinden nicht nur das unerwünschte Mail-Relaying, sondern bieten auch die Möglichkeit, lästige Spammer bei der lokalen Zustellung auszufiltern.

Es gibt noch einige andere Behelfsmöglichkeiten (z.B. TCP Wrapper), die allerdings einige Nachteile mit sich bringen und oft umständliche Instituts-Konfigurationen mit sich ziehen.

VMS-Rechner mit UCX können Mail-Relaying deaktivieren; für die MX-Software ist ein Patch angeblich in Kürze erhältlich.

Betreiber von Novell-Servern, die das Mercury-Gateway verwenden, müssen auf die neue Version 1.40 aufrüsten.

Betreiber von anderen Produkten bzw. Plattformen (MacOS, Windows-NT, ...) müssen bei ihrem Betreuer oder Hersteller nachfragen, ob eine Lösung verfügbar ist. Da andauernd neue Versionen und Patches angeboten werden, ist es nicht sinnvoll, hier zu versuchen, eine vollständige Liste aller Varianten anzuführen.

An dieser Stelle soll nochmals betont werden, daß jeder Betreiber eines Mail-Servers im Falle eines Mißbrauchs sofort reagieren muß. Also entweder Patch installieren, auf eine andere Software umsteigen oder den Mail-Zugang sperren (nicht nur für den gerade aktiven Spammer).

Bei allgemeinen Fragen zu diesem Thema wenden Sie sich bitte an Herrn Rathmayer des Bereichs Kommunikation bzw. an Ihren zuständigen Plattformbetreuer.

Zum Inhaltsverzeichnis, Pipeline 24, Februar 1998