Zentrale Anti-Spam-Maßnahmen

Schon lange sind TUNET-Benutzer ein beliebtes Ziel von Spam-Mails aus aller Welt. Mittlerweile nimmt das Ausmaß dieser Form von unverlangt zugestellten E-Mails mitunter unangenehme Dimensionen an. Sowohl für die Benutzer bzw. Empfänger solcher E-Mails als auch die Server-Betreiber. Zudem kommen noch Folgeerscheinungen von nicht unmittelbar die TU Wien betreffenden Spam-Mails, die sich auf andere Weise bemerkbar machen und sich im Wesentlichen in der erhöhten Belastung der Bastionsrechner widerspiegeln (was bisher aber noch keinen Grund zur Besorgnis darstellte).

Die sich aus diesen teils bedrohlichen Entwicklungen ergebenden vier Problemfelder münden derzeit in entsprechenden Strategien, die versuchen, dem E-Mail-Missbrauch (auch unter Berufung auf das Telekommunikationsgesetz, TKG §101, [1]) entgegenzuwirken:

• Das TUNET als Quelle von Spams wird unterbunden: Durch Einsatz von Mailbastionsrechnern wird derzeit erfolgreich das dem Ruf der TU nicht besonders zuträgliche und administrationsintensive 3^rd-Party Relaying verhindert.

• Spam-Mails mit TU-fremdem Ursprung sind mit gefälschtem TU-Absender versehen, und gelangen als Retourmail an die TU: Diese können (als Option) für gewisse Zielbereiche nach gewissen Adressmustern am Mailbastionsrechner blockiert werden.

• Empfänger im Bereich des TUNET werden von Spam-Mails heimgesucht. Mittels Zugriffseinschränkungen von Absender-E-Mailadressen und Serveradressen, basierend auf nicht im DNS auflösbare Adressen, auf konkrete Vorfälle die TU Wien betreffend oder  auf dynamische im Internet angebotene Blackhole-Listen mit globalem Status, werden derartige Spam-Mails blockiert.

• E-Mails werden nach Viren- bzw. Wurmbefall untersucht und gegebenenfalls unterdrückt (bei entsprechender Benachrichtigung des Empfängers). Mehr dazu im Artikel "Zentrale Anti-Viren-Maßnahmen".

Spam Mail Relaying

Maßnahmen zum ersten Problemfeld sind bereits in den letzten zwei Jahren umgesetzt worden, sodass mittlerweile die gesamte TU flächendeckend über den Bas-tionsrechner geleitet wird. Der Zugriff von außerhalb des TUNET auf TCP Port 25 des SMTP-Protokolls ist (im Wesentlichen bis auf die Bastionsrechner) gesperrt. Die Bastionsrechner - wie bereits in [2] vorgestellt - leiten dann die ankommenden E-Mails TU-intern weiter. Interessierte Empfänger können diese zusätzliche Zwischenstation einer erhaltenen E-Mail auch daran erkennen, dass die detaillierte Ansicht des Mail-Headers eine Received-Line mit bzw. von tuvok.kom.tuwien.ac.at oder neelix.kom.tuwien.ac.at enthält.

Beim Mailverkehr innerhalb des TUNET sind die Bastionsrechner nicht involviert, wobei z. B. die Wählleitungszugänge der TU Wien natürlich zum TUNET zu rechnen sind, nicht aber die TU Wien Chello Student Connect-Teilnehmer.

Einer speziellen Behandlung bedarf es bei so genannten "Externen Domains" (also solchen, die nicht auf tuwien.ac.at enden), die auf TU Nameservern oder auch anderen, externen Nameservern betrieben werden und, was wesentlich ist, einen im TUNET befindlichen Mailserver verwenden wollen. Diese Domains bzw. deren Mailserver sind dann mit Begründung für den Zusammenhang mit den Aufgaben der TU Wien dem ZID zu melden (http://nic.tuwien.ac.at/formulare/domain.pdf), wodurch auch für diese externen Domains die Umleitung über die Bastionsrechner realisiert werden kann und somit dem Sicherheitskonzept genüge getan wird.

Spam Address Faking

Mit der zweiten Maßnahme tritt man einer Problematik entgegen, die mit Spam-Mails zum Vorschein kommen, die weder an der TU ihren Ursprung haben noch dorthin gesendet werden. Dennoch brechen schubweise und zeitlich gehäuft von unterschiedlichsten Mailservern des Internet wahre Mailstürme auf vermeintliche TU- Mailadressen herein. Dabei handelt es um automatisch von Mailservern generierte Nachrichten, die offensichtlich von Spam-Mails herrühren, die an nicht (mehr) existierende oder anderweitig nicht erreichbare Empfänger gegangen sind und nun an den Absender zurück geschickt werden. Dabei agieren die Spam-Mail-Verteiler schon im Vorfeld so geschickt, dass sie als Absendeadresse ihrer Spam-Mails eine existierende Domain (eben eine der TU Wien) heranziehen und irgendwelche automatisch generierte User-Bezeichnungen (die vorab nicht überprüfbar sind) aus Ziffern und Buchstaben verwenden. Damit geht man als Spammer einer statischen Filterung auf die Absenderadresse und einer Blockierung von nicht-auflösbaren Adressen (bezieht sich immer nur auf den Domain-Teil einer E-Mail-Adresse) aus dem Weg. Explizit erwähnt soll hier die Tatsache sein, dass alle im Mail-Header gemachten Angaben, speziell die Adressen, beliebig gefälscht sein können und nicht für die Mail-Zustellung herangezogen werden (für eine Antwort-Mail allerdings dann schon). Die relevanten Zustelladressen werden direkt über das Simple Mail Transfer Protocol (SMTP) - entspricht dem Briefkuvert - gesondert übertragen und sind dann für Empfänger nicht mehr (direkt) sichtbar.

Konsequenzen von Sender Address Faking

Die Tatsache, dass so die TU Wien bzw. deren Bas-tionsrechner von den im Internet verteilten Mailservern mit derartigen Retourmails überschwemmt wird, kann durchaus als Distributed Denial of Service Attack (DDoS) gewertet werden, die zwar nicht auf diesen Effekt hin ausgerichtet ist, aber dennoch den ursprünglichen Spam-Mail-Versendern sehr wohl bewusst sein dürfte.

Da es sich in der Regel um Institutsdomains handelt, die auf diese Art missbraucht werden, sind natürlich auch die entsprechenden Instituts-Mailserver, an die diese Mails dann weitergeleitet werden, betroffen. Auch wenn am Institut die Fantasiebenutzer als Empfänger abgewiesen werden, kommt durch das Zwischenspeichern und das Verarbeiten jeder einzelnen Nachricht eine merkbare Belastung auf den Bastionsrechnern zustande. Aus diesem Grund bietet der ZID eine optionale Blockierung von speziellen Empfängeradressformen (User-Teil beginnt mit einem Buchstaben und endet auf mindestens zwei Ziffern), bezogen auf Hosts oder Subdomains der TU Wien Domain tuwien.ac.at, an. Bei Gefahr im Verzug wird die Errichtung der Blockade vorab durchgeführt und das Institut darüber informiert, um etwaige Konflikte mit der regulären Mailadressierung zu vermeiden. Auf Wunsch kann diese Blockade weiterhin permanent oder auch zeitlich begrenzt weitergeführt werden.

Spam Filtering

Die dritte Maßnahme bedient sich, in Anlehnung an die Empfehlung aus RFC 2505 (Anti-Spam Recommendations [3]), diverser Mechanismen, um direkte, an TU-Adressen gerichtete Spam-Mails abzuweisen.

Spam-Filter Arbeitsweise

Diese erzeugen bis heute zum Teil recht heftige Kontroversen bei Vertretern der Persönlichkeitsrechte, administrativen Organen von Firmen und Einrichtungen, kommerziellen Spam-Versendern und schließlich den eigentlichen E-Mail-Empfängern selbst. Im Falle der TU Wien werden optionale Methoden angeboten, die es erlauben, gewisse Verfahren abhängig von Empfängeradressbereichen auf Antrag zu aktivieren oder zu deaktivieren.

Konkret sind nun folgende Mechanismen implementiert bzw. vorgesehen:

• Nicht auflösbare Absender-Adressen werden standardmäßig abgewiesen, d. h. wenn der Domainteil einer E-Mail-Adresse nicht mit einem Mailserver assoziiert werden kann oder kein Hostname ist (Überprüfung via DNS - Domain Name Service), wird die begonnene Verbindung abgebrochen und eine E-Mail-Übertragung kommt erst gar nicht zustande.
  Dabei können zwei unterschiedliche Situationen auftreten: Kann der Name z. B. wegen eines vorübergehenden Nameserverausfalls nicht überprüft werden, wird ein temporärer Fehler an den absendenden Mailserver retourniert, der es dann eine gewisse Zeit lang (in der Regel fünf Tage) weiter probiert. Hingegen wird bei einer negativen Antwort eines Nameservers die Abweisung durch einen permanenten Fehlerstatus angezeigt (was freilich so mancher Spam-Server ignoriert und dennoch weiter sendet) und an den Absender zurückgemeldet.
  Wenn ein derartiges Verhalten für ein Institut mit einer eigenen Mail-Domain nicht akzeptabel ist, besteht die Möglichkeit, die entsprechende Subdomain von dieser Verfahrensweise auszunehmen.

• Manuelle Blockaden aufgrund lokaler Vorfälle:
  Anzeichen wie die erhöhte Belastung der Bastionsrechner oder steigender Bandbreitenverbrauch bzw. abrupt angestiegene Mailtransferraten werden zum Anlass genommen, nach eingehender Prüfung manuelle Blockaden auf den Bastionsrechnern und den zentralen Mailservern zu errichten. Damit wird der Zugriff nach Kriterien wie
  • IP-Adresse des Absender-Mailservers oder
  • E-Mail-Adresse des Absenders (Benutzer oder die gesamte Domain)
  abgewiesen, wobei der Absender durch einen permanten Fehlerstatus auf das Nichtvorhandensein des gewünschten Empfängers hingewiesen wird (im Rahmen einer Retourmail durch das Mailsystem des Absenders). Wenn sich die Lage nach einiger Zeit stabilisiert hat, werden die Sperren wieder abgebaut.

• Blackhole Listen (MAPS, ORDB, ORBZ, ...)
  Mit so genannten dynamischen Realtime Blackhole Lists (oftmals kurz als RBL bezeichnet), wie z. B. die diversen Listen der Mail Abuse Prevention System Organisation [4], ist eine globale, stets auf dem aktuellen Stand befindliche Datenbank über das normalerweise für die Namensauflösung im Internet zuständige DNS-System realisiert. Damit werden eingehende Mail- verbindungen sofort überprüft, ob sie von gelisteten Mailservern, Dialup-Hosts und ungenutzten Adress- bereichen stammen und gegebenenfalls blockiert. Es existieren einige derartige Systeme, die mit teils sehr unterschiedlichen bis hin zu verwirrenden Kriterien schwarze Schafe (Spammer-Systeme) sammeln, überprüfen und gegebenenfalls aus den entsprechenden Datenbanken wieder entfernen.
  
  Die TU Wien hat vorerst die Nutzung des erst kürzlich kostenpflichtig gewordenen RBL+ von Mail Abuse Prevention System (MAPS) beantragt und wird die Verwendung auf den TU-eigenen Nameservern zur Verfügung stellen. Die dafür notwendigen Nameservice Zonen liegen dort als Replikat vor, sodass entsprechende Anfragen nicht stets auf den externen MAPS-Nameserver zugreifen, was sonst je nach aktueller Erreichbarkeit zeitliche Verzögerungen mit sich bringen kann.
  
  Auf den Mailbastionsrechnern ist ein Service geplant, das wiederum auf Subdomain-Granularität das RBL-Verfahren auswählen lässt, ob und welche RBL-Varianten eingesetzt werden sollen. Mit MAPS als langjährigem Anbieter eines solchen Services (die RBL+ Liste umfasst etwa 470.000 Einträge) wird vorerst ein Anfang gesetzt, wobei durchaus auch andere RBL-Anbieter in Frage kommen können (z. B. ORDB mit etwa 120.000 Einträgen). Deren Verwendung sollte aber stets unter Bedachtnahme auf Konventionen, Bedingungen (wie man z. B. Server von einer Liste wieder weg bekommt) und technische Realisierung des jeweiligen Anbieters abgewogen werden. Dies wirkt sich in weiterer Folge auch auf die Angreifbarkeit solcher Services durch juristische Mittel aus. Kaum eines der länger im Umlauf befindlichen Services ist nicht in gerichtliche Auseinandersetzungen involviert gewesen, wovon man sich in den News-Kanälen der Web-Präsenz der Serviceanbieter überzeugen kann. Prominentestes Opfer in der jüngeren Vergangenheit war sicherlich die ORBS-Liste, die mit der Einstellung ihrer Tätigkeit just etliche Nachahmer (wie etwa ORDB [5] oder ORBZ [6]) gefunden hat.
  Zum Teil arbeiten Spam-Befürworter und sie unterstützende Provider derart eng zusammen, dass Nameserver der RBL-Betreiber aus gewissen Teilen des Internet schlecht oder gar nicht erreichbar sind. Im Internet verteilt agierende Nameserver hingegen unterstreichen hierbei die Stärke und das Durchsetzungsvermögen eines Services.
  
  In den Referenzen [4-9] finden sich einige Verweise auf Seiten diverser RBL-Serviceanbieter und Anti-Spam-Projekte, die hier kaum vollständig zitiert werden können, aber untereinander stark verwoben sind und damit zu allen Ecken der Anti-Spam-Gemeinschaft führen.

Viren

Das vierte und letzte hier genannte Problemfeld ist nicht unmittelbar mit der Spam-Problematik verbunden zu sehen, aber dennoch diesem gewissermaßen verwandt. Natürlich rufen via E-Mail verteilte Viren prinzipiell die gleichen unangenehmen Effekte (in den meisten Fällen noch schlimmere) hervor, die unerwünscht eingelangte Nachrichten zu Spam-Mails machen. Die zuvor erwähnten RBL-Anbieter tragen dieser Situation zum Teil Rechnung, in dem auch sonstige auffällige (etwa virenversendende) Mailserver bzw. allgemein formuliert, absendende Hosts aus dem Internet, in deren schwarze Liste aufnehmen, wobei dieser Ansatz meist mit der Verbreitungsgeschwindigkeit von Viren nicht mithalten bzw. deren Verbreitung effektiv verhindern kann. Ausführlicheres zu diesem Thema ist im Artikel "Zentrale Anti-Viren-Maßnahmen" nachzulesen.

Abschließend muss man dennoch feststellen, dass ganz gleich, welche Strategien auch immer zum Einsatz kommen, stets Lücken und Möglichkeiten für die Verbreitung von Spam-Mails und auch Viren auf E-Mail-Basis existieren werden. Die Dynamik des Internet und die teils starken kommerziellen Interessen hinter der Anwendung von Spam-Mails scheinen auch in Zukunft der Garant dafür zu sein.

Referenzen

[1] Telekommunikationsgesetz: TKG §101 Unerbetene Anrufe, Bgbl. I Nr. 188/1999 vom 20.8.1999

[2] ZIDline 4, Dezember 2000, S. 3, Mailbastionsrechner - eine elegante Lösung der Spam-Problematik, http://www.zid.tuwien.ac.at/zidline/zl04/mailbast.html

[3] RFC 2505 Anti-Spam Recommendations for SMTP MTAs: ftp://ftp.isi.edu/in-notes/rfc2505.txt

[4] MAPS Realtime Blackhole List: www.mail-abuse.org

[5] Open Relay Database: http://ordb.org/

[6] Open Relay Blackhole Zones: http://www.orbz.org/

[7] OsiruSofts Open Relay Spam Stopper: http://relays.osirusoft.com/

[8] Spam Prevention Early Warning System: http://spews.org/

[9] The Spamhaus Project: http://spamhaus.org/

Seitenanfang | ZIDline 6 - Dezember 2001 | ZID | TU Wien