Mail-Bastionsrechner 
- eine elegante Lösung der Spam-Problematik

Udo Linauer

Der Mail-Bastionsrechner ist ein Teil des Firewallkonzepts für die TU Wien. Ungeachtet dessen, dass es sich um eine redundante Konfiguration mit mehreren Servern der Firma SUN handelt, wird in der Folge von dem Mail-Bastionsrechner - als funktionale Einheit - gesprochen. Der Einsatz des Mail-Bastionsrechners macht es Außenstehenden unmöglich, Mailserver an der TU Wien zum Versenden von Spam-Mail 1 zu missbrauchen.  Die gesamte an der TU Wien einlangende Mail wird dazu über den Mail-Bastionsrechner umgeleitet, wo folgende, einfache Überprüfung stattfindet: "Stelle die Mail zu, wenn der Empfänger in der TU Wien ist, sonst lehne sie ab."
Die Benutzer an der TU Wien müssen keine Veränderungen an ihrer Mailsoftware vornehmen. Die Umstellung wird Institut für Institut vorgenommen und soll bis zum Jahresende vollzogen sein. Notwendige zentrale Adaptionen im Domain Name Service werden in Vorgesprächen mit den Ansprechpartnern des ZID an den Instituten erörtert.

Nach einer Einführung in die Problematik von Spam-Mail wird auf die Technologie des Mail-Bastionsrechners und die für den Einsatz nötigen Vorarbeiten eingegangen. In Ergänzung dazu werden für interessierte Leser am Ende des Artikels die technischen Hintergründe genauer beleuchtet.

Spam-Mail

Spam-Mail ist eine Postwurfsendung im Internet. Jede(r) von uns sah sich schon mit der meistens nutzlosen Information konfrontiert, deren Beseitigung zwar nicht allzu viel aber doch zu viel unserer kostbaren Zeit konsumiert. Große Stückzahlen bedeuten für Netze und Mailserver eine enorme Belastung, die Geld kostet und bisweilen sogar zu Abstürzen führt. Um Missbrauch einen Riegel vorzuschieben, behandelt der österreichische Gesetzgeber Spam-Mail im Telekommunikationsgesetz wie Telefonmarketing. Sie ist ohne vorherige - jederzeit widerrufliche - Zustimmung des Empfängers unzulässig (TKG §101 - Unerbetene Anrufe 2). Die meisten anderen Staaten sehen in ihrer Gesetzgebung die Möglichkeit des "Opt-out" vor, das heißt, dass Empfänger sich jederzeit gegen die Zusendung weiterer Mail verwehren können. Auch die Security Policy der TU Wien 3 verbietet das Versenden von elektronischen Massensendungen (Spam-Mail). Den in den letzten Jahren geschaffenen gesetzlichen Bestimmungen zum Trotz steigt die Anzahl von Spam-Mail unablässig. Unterschiedliche nationale Gesetzgebungen, gefälschte Mail-Header (Absenderadressen) und aufgrund schlechter Erfolgsaussichten mangelnde Kooperationsbereitschaft involvierter Provider behindern die Ausforschung der Absender. Bisweilen lässt sich zumindest die Sperre des Absenderaccounts erwirken. Der Erfolg ist jedoch meist nur von kurzer Dauer. Es wäre unrichtig zu behaupten, dass Provider Spammer als gute Kunden schätzen, ganz im Gegenteil. Spammer verbrauchen überdurchschnittlich viel Ressourcen, behindern somit oft andere Benutzer. Die meisten Provider verfügen über Bestimmungen ("Fair Use Policy", "Acceptable Use Policy" etc.), die das Versenden von Spam-Mail untersagen und Spammer von der Benutzung ihrer Services ausschließen. Für den Spammer besteht daher ein guter Grund, seine Tätigkeit nicht unter seinem Namen bei seinem Provider auszuüben, sondern fremde Ressourcen dafür zu verwenden. Dabei kommt ihm eine Eigenschaft des im Internet am häufigsten verwendeten Mail-Protokolls SMTP 4 zugute, nämlich die Funktion des Mail-Relays 5.

Tatsächlich wird bei weitem mehr Spam-Mail über falsch konfigurierte, so genannte "offene Mail-Relays" Dritter versandt als "unter eigenem Namen". Der Spammer bleibt dabei oft unerkannt, der Zorn der Empfänger entlädt sich auf den Administrator des Servers, der in der Mail als absendender Mail-Server aufscheint. (Warum Mail-Relays benötigt werden und wie sie missbraucht werden, können Sie am Ende des Artikels in den "technischen Hintergründen" nachlesen.)

Die Internetgemeinde begnügte sich aber nicht mit zornigen Verbalattacken gegen säumige Administratoren. Es bildeten sich "Selbsthilfegruppen" (ORBS 6 ist wohl die bekannteste), die Listen von Mailservern mit offenem Mail-Relay führen. Mailserversoftware wurde dahingehend modifiziert, dass solche Listen automatisch herunter geladen werden und Mail von gelisteten Servern nicht zugestellt wird. Diese Maßnahme betrifft natürlich alle Benutzer und nicht nur Versender von Spam-Mail. Ihre Mail kann nicht mehr zugestellt werden.

Die Situation an der TU Wien

Durchschnittlich 10 % der tatsächlich vorhandenen, teilweise auch versehentlich als solche konfigurierten Mailserver (dazu zählen praktisch alle schlampig installierten Linux-Systeme) oder immerhin 6 % der offiziell in der TUNET-Datenbank eingetragenen Mailserver sind auf der ORBS-Liste. Oft sind die verantwortlichen Administratoren völlig ahnungslos, weil die meisten Beschwerden am ZID, dem Betreiber und Kontaktpartner für das TUNET, einlangen. Man kann sich leicht ausmalen, wie die betroffenen Mitarbeiter des ZID reagieren, wenn das Wörtchen Spam fällt. Da immer wiederkehrenden Appelle an die Institute, die Mailserver doch in gutem Zustand zu halten, keinen Erfolg hatten, sahen sich die Verantwortlichen am ZID genötigt, ein Konzept für einen Mail-Bastionsrechner zu entwickeln (Anfang 1999), um dieses Problem ein für alle Mal zu lösen.

Spätestens als auch die zentralen Mailserver der TU Wien (mr.tuwien.ac.at und mail.zserv.tuwien.ac.at) auf die ORBS-Liste gesetzt wurden und damit tatsächlich tausende Kollegen betroffen waren, stand der Entschluss fest, den Mail-Bastionsrechner so schnell wie möglich für die gesamte TU Wien in Betrieb zu nehmen. Grund dafür war übrigens eine besonders kniffelige Art des Mail-Relaying. Manche Mailserver (mit offenem Mail-Relay) auf der TU Wien verwenden zum Absenden der Mail den zentralen Mail-Server der TU Wien. Wenn solch ein Mailserver zum Versenden von Spam-Mail verwendet wird, scheint auch der jeweilige zentrale Mailserver im Mailheader auf und wird folgerichtig auf die Liste gesetzt. Es gelang zwar immer, die zentralen Mailserver schnell wieder von der Liste herunterzubekommen, das Problem ist aber ohne Mail-Bastionsrechner nicht zu lösen. Zentrale Mailserver müssen Mails, die sie aus dem TUNET erhalten, weitersenden. Das ist ihre Aufgabe.

Funktionalität eines Mail-Bastionsrechners

Ein Bastionsrechner (auch application gateway) ist ein Server, über den der gesamte Verkehr zwischen einer Organisation und dem Rest der Welt läuft. Er befindet sich typischerweise in der DMZ (Demilitarisierte Zone), einem Subnetz zwischen internem Netz und Internet, in das man nur über den Firewall gelangt (siehe Abbildung 1). An dieser Stelle können in einfacher Weise Überprüfungen auf Applikationsebene ausgeführt werden. Dazu können Sicherheitsüberprüfungen (Mail-Relaying, Virenscans), das Einschränken der Funktionalität aus Sicherheitsgründen (z. B. Blockieren von Java) und Ähnliches zählen.

Abb. 1
Abbildung 1

Ein Mail-Bastionsrechner beschränkt sich auf die Überprüfung des Mail-Verkehrs, in unserem Fall auf von außen in das TUNET über das SMTP-Protokoll einlangende Mails. Zu den typischen Aufgaben eines Mail-Bastionsrechners gehören die Verhinderung von Mail-Relaying, Virenscans und das Abweisen von Spam-Mail aufgrund von "schwarzen Listen". An der TU Wien werden wir uns vorerst auf die Verhinderung von Mail-Relaying beschränken. Weitere Funktionalität könnte bei Bedarf und nach Klärung der technischen Umsetzbarkeit folgen. Bastionsrechner werden aus Gründen der Ausfallsicherheit und des Lastausgleichs oft in redundanter Konfiguration (d. h. mit mehr als einer Maschine) ausgelegt.

Implementation des Mail-Bastionsrechners an der TU Wien ( tuvok.kom.tuwien.ac.at )

Die gesamte von außen ins TUNET einlangende Mail mit Ausnahme der generisch adressierten (vorname.nachname+instnummer@tuwien.ac.at) wird über den Mail-Bastionsrechner umgeleitet. Die Umleitung geschieht mittels des Domain Name Service (DNS). (Wenn Sie Interesse an den Details haben, finden Sie diese am Ende des Artikels in den "technischen Hintergründen".) Am Mail-Bastionsrechner läuft die jeweils aktuelle Version des Mailserverprogramms "sendmail", von dem versuchtes Mail-Relaying erkannt und verhindert wird. Mail an Adressaten in der TU Wien wird unverändert an die Empfänger weitergeleitet, Mail an Adressaten außerhalb der TU Wien wird abgelehnt.

Zusätzlich zu dieser Maßnahme muss auch der von SMTP verwendete Port 25/tcp am Firewall gesperrt werden, um zu verhindern, dass Spammer unter Umgehung des DNS direkt Mail versenden.

Diese Sperre betrifft auch Benutzer, die von außerhalb der TU Wien (Ausnahme: bei Verwendung des Einwählservice der TU Wien oder TU Wien-Chello) einen Mailserver an der TU Wien zum Versenden von Mail verwenden wollen. Zum Versenden von Mail müssen sie in Zukunft als "Ausgehenden Mailserver" ("Outgoing Mail Server") den Mailserver des verwendeten Providers angeben. Wenn die im Mail-Client angegebene Mailadresse nicht geändert wird, kommen weiterhin alle Antworten auf den Mailserver an der TU Wien. Um ganz sicher zu gehen, kann zusätzlich im Mail-Client die gewünschte Mailadresse im Feld "Reply-to address" angegeben werden.

Abb. 2
Abbildung 2: Beispiel: Einstellungen in Netscape Messenger

Die Einschränkung beim Absenden kann auch umgangen werden, indem man sich direkt auf den (Instituts-) Mailserver einloggt (z. B. mit SSH) und einen lokalen Mailclient verwendet.

Weiterhin uneingeschränkt möglich ist das Lesen von Mail von (Instituts-)Mailservern auf der TU Wien. (Die Protokolle POP und IMAP sind von der Sperre nicht betroffen.)

Wie erfolgt die Umstellung ?

Wir planen, die Umstellung schrittweise (Subnetz für Subnetz) aber zügig bis zum Jahresende durchzuführen. Die für die IT-Infrastruktur verantwortlichen Ansprechpartner des ZID an den Instituten werden in diesen Wochen von uns mit der Bitte kontaktiert, die Namen der Instituts-Mailserver bekanntzugeben. Nochmals sei darauf hingewiesen, dass Rechner, die nur instituts- oder universitätsweit agieren, oder solche, die Mail nur versenden, nicht aber empfangen sollen (z. B. um Ergebnisse von Berechnungen zu verschicken), nicht auf diese Liste gehören.

Für eine reibungslose Umstellung wäre uns sehr geholfen, wenn die Institute möglichst früh eine Liste der benötigten Rechner erstellen könnten. Wichtig ist dabei auch, alle Aliasnamen für den Mailserver anzugeben, unter denen Mail empfangen wird (z. B. Rechner server.e999.tuwien.ac.at heißt auch www.e999.tuwien.ac.at). Zur Hilfestellung werden wir eine Liste mit den derzeit in der TUNET-Datenbank eingetragenen Mailservern des Instituts und eine Kurzfassung dieses Artikels zur Verfügung stellen. Nachdem diese Änderungen von den Mitarbeitern des ZID in die TUNET-Datenbank eingetragen sein werden, tritt die Umleitung über den Bastionsrechner in Kraft. Institute, die bereits in die Verwendung der TUNET-Datenbank eingeschult worden sind, können durch Eintragung des neuen Attributs "BIND/BASTION" die nötige Adaption selbst vornehmen. Für alle offenen Fragen stehen unsere Mitarbeiter natürlich gerne bereit (Kontakte siehe unten).

Mailserver im TUNET, die nicht in der Domäne tuwien.ac.at liegen

Der ZID der TU Wien als Betreiber des TUNET ist verpflichtet, das Domain Name Service für die Domäne tuwien.ac.at zu unterhalten. Wenn berechtigtes Allgemeininteresse besteht (vor allem für interuniversitäre Belange), kann in Abkommen Organisationen gestattet werden, Services auf Rechnern zu betreiben, die zusätzlich zum Domänennamen tuwien.ac.at auch andere Domänennamen führen (z. B. für den Lehrzielkatalog der Server nexus.lzk.tuwien.ac.at und www.lzk.ac.at). Die verantwortlichen Organisationen sind verpflichtet, für die von ihnen unterhaltenen Domänen das Domain Name Service (DNS) selbst zu betreiben. Aufgrund dieser Tatsache sind solche Server von der Verwendung des Mail-Bastionsrechners ausgeschlossen. Für allfällige Fragen stehen wir dabei natürlich gerne mit Rat und Tat bereit.

Ansprechpartner

Fragen zum Mail-Bastionsrechner:
Elisabeth Donnaberger: Kl. 42042, donnaberger@zid.tuwien.ac.at
Johann Haider: Kl. 42043, jhaider@zid.tuwien.ac.at

Fragen zur TUNET-Datenbank: hostmaster@noc.tuwien.ac.at

Technischer Hintergrund

Mail-Relaying (Routing)

Zum Verständnis der Spam-Problematik betrachten wir die Stationen einer Mail zwischen Absender und Empfängerin an einem Beispiel (siehe Abbildung 3). Hans (hansi@partner.com) möchte eine Mail an Anna (anna.ba@tuwien.ac.at) schicken. Er editiert den Text in seinem Mail-Programm (Mail user agent = MUA, z. B. Eudora) und drückt den Send-Button. Sein MUA kontaktiert den lokalen SMTP-Server (Mail transfer agent = MTA, z. B. sendmail, MS Exchange) - in unserem Fall einen Abteilungs-Mailserver - und überträgt die Mail über das SMTP-Protokoll auf diesen. Der Abteilungs-Mailserver muss jetzt entscheiden, wohin er die Mail weiterschicken soll. Die Auswahl des nächsten MTAs erfolgt über das "Domain Name Service" (DNS) und konkret über ein spezielles Attribut desselbigen, den so genannten Mail eXchanger (MX) Record .

Abb. 3
Abbildung 3: Good Relay

Es können auch mehrere MX-Records für dasselbe Ziel eingetragen werden, um alternative, redundante Routen zum Ziel zu definieren. In der Regel wird die Mail direkt an den "Eingehenden Mailserver" ("Incoming Mail Server") von Anna geschickt und dort in ihrer Mailbox abgelegt. Die Mail kann aber, wie in unserem Beispiel, zuerst an dem zentralen Mailrouter ankommen, wo die Adresse umgeschrieben wird und die Mail an einen Institutsmailserver weiter geschickt wird. Jeder der MTAs in der Kette bis auf den letzten agiert als Mail-Relay. Annas MUA (z. B. MS Outlook) kontaktiert nun ihren "Incoming Mailserver" über eines der gängigen Protokolle (POP, IMAP) und zeigt Hansis Mail an.

So weit, so gut. MTAs werden in der Regel von Organisationen betrieben (z. B. TU Wien). Ihre Aufgabe aus der Sicht der Organisation besteht neben der internen Kommunikation darin, Mail von Absendern in der Organisation an Externe und Mail von externen Absendern an Angehörige der Organisation zuzustellen. Nicht erwünscht ist das Weiterleiten von Mail von Externen an Externe (siehe Abbildung 4). Ganz offensichtlich hat der Serverbetreiber davon keinen Nutzen, obwohl seine Ressourcen verwendet werden. MTAs, die von einem externen Absender zu einem externen Empfänger weiterleiten, nennen wir offene Mail-Relays.

Abb. 4
Abbildung 4: Bad Relay

Offene Mail-Relays wurden in den letzten Jahren zunehmend für das Versenden von Spam-Mail missbraucht und das Belassen eines solchen Zustandes durch die verantwortlichen Administratoren betrachten die Empfänger von Spam-Mail als Fehlverhalten. Außerdem können, wie bereits erwähnt, Mailserver und Netz durch offene Mail-Relays schwer belastet werden. Prinzipiell kann jeder gebräuchliche SMTP-Server so konfiguriert werden, dass eine Verwendung durch Unbefugte unterbunden ist. Der Aufwand dafür ist jedoch ziemlich hoch, da es sich um hoch komplexe Programme handelt und Spammer immer wieder neue Schwächen entdecken. (Als Beispiel sei der schnelle Versionswechsel bei sendmail genannt.)

Spam-Mail

Was kann man gegen Spam-Mail unternehmen ?

Wie wir wissen, zeitigt weder die Aufforderung zur Unterlassung noch die Androhung von Rechtsmitteln das erwünschte Ergebnis. Ironischerweise sind die Absender oft gar nicht über Mail erreichbar. Erfolgsversprechender sind einige technische Ansätze, die darauf zielen, entweder das Versenden oder die Annahme beziehungsweise die Zustellung von Spam-Mail zu verhindern. Das Verhindern des Versendens ist das bessere Konzept, da der Verkehr minimiert wird. Zum Versenden werden von Spammern meistens "fremde" Server mit offenen Mail Relays verwendet. Um das zu verhindern benötigt jeder Server die aktuelle Version der Mailserversoftware, die darüber hinaus richtig konfiguriert sein muss. Als Alternative bietet sich ein Mail-Bastionsrechner an, der alle Mailserver einer Organisation an zentraler Stelle schützt.

Der Empfang von Spam-Mail kann durch Überprüfung der Absender anhand "schwarzer Listen" verhindert werden. (Die ORBS-Liste führt momentan über 150 000 Mailserver mit offenem Mail-Relay.) Mail von Absendern (Mailservern) auf der Liste wird nicht zugestellt. Natürlich sind nicht nur die Spammer, sondern alle Personen, die diesen Mailserver verwenden, von der Maßnahme betroffen. Eine weitere Methode ist das auto-matische Kopieren der eingehenden Spam-Mail in einen dafür vorgesehenen Mail-Folder mittels eines Filter-Programms (z. B. procmail). Damit erspart man sich zumindest das Lesen der Spam-Mail.

Mail-Bastionsrechner óDomain Name Service (DNS) an der TU Wien

Das Domain Name Service DNS ist ein Dienst, der Rechnernamen bzw. Internet-Adressen im Klartext (z. B. www.tuwien.ac.at) und IP-Adressen (z. B. 128.130.2.9) einander zuordnet. Für jeden Rechner beziehungsweise für jedes Netzwerk im Internet muss ein DNS-Server diese Informationen verwalten. Bevor eine beliebige Verbindung zu einem Server im Internet aufgebaut wird, kontaktiert das Client-Programm einen Domain Name Server. Dieser meldet die entsprechende numerische Adresse zurück, worauf der Client die Verbindung zur IP-Adresse aufbauen kann.

Im Zuge der Implementierung des Firewallkonzepts ist es auch zu Veränderungen im Domain Name Service (DNS) der TU Wien gekommen. Bis vor kurzem (01. 10. 2000) wurden alle Anfragen, gleichgültig, ob aus dem TUNET oder von einem externen Host, von den beiden Nameservern (tunamea.tuwien.ac.at und tunameb.tuwien.ac.at) bearbeitet, deren Datenbestand aus den Einträgen in der TUNET-Datenbank generiert wird. Eine einheitliche Sicht ist die einfachste, in vielen Belangen aber nicht optimale Lösung. So gibt es viele Rechner, die von außen nicht zugänglich sein und damit auch nicht bekanntgegeben werden müssen (mein Windows-PC etwa). Rechner können in der externen Sicht andere Attribute (z. B. MX-Records) haben als in der internen. Und schließlich kann ein Computer in der externen Sicht eine andere IP-Adresse haben als in der internen (NAT, IP-Masquerading), sei es aus Sicherheitsgründen, sei es um teure offizielle IP-Adressen zu sparen. Die Darstellung unterschiedlicher Sichtweisen erreicht man am besten durch die Trennung in Nameserver für externe Anfragen (tunamec.tuwien.ac.at und tunamed.tuwien.ac.at) und solche für interne (tunamea.tuwien.ac.at und tunameb.tuwien.ac.at). Externe Anfragen an die internen Nameserver werden untersagt.

Auch bei der Implementierung des Mail-Bastionsrechners spielt das Domain Name Service eine bedeutende Rolle. Es kommt dabei ein ähnlicher Mechanismus zum Einsatz, wie er bereits für die Zustellung von generischen Mail-Adressen (vorname.nachname+instnummer@tuwien.ac.at) verwendet wird. Mail mit generischer Adressierung wird zuerst an den zentralen Mailrouter mr.tuwien.ac.at umgeleitet. Dort wird die Zieladresse anhand der Daten aus den White Pages von der ursprünglichen (allgemeinen oder generischen) in die RFC 822 Mail-Adresse umgeschrieben. Dann wird die Mail an den in der RFC 822 Mail-Adresse angegebenen (Instituts-)Mailserver weitergeleitet.

Eine derartige Umleitung wird in Zukunft auch für den restlichen Mailverkehr vorgenommen. Sie erfolgt über auf den Mail-Bastionsrechner lautende MX-Records. Es muss für jeden Mailserver (eigentlich für jeden Mailnamen, unter dem der Mailserver Mail empfangen soll) das Attribut "BIND/BASTION" in die TUNET-Datenbank eingetragen werden. Damit wird eine alternative Route für die Mailzustellung definiert. Der Wert für den MX-Record wird so gewählt, dass zuerst die Route über den Mail-Bastionsrechner ausprobiert wird (höhere Priorität). Diese Methode gewährleistet die Zustellung unabhängig von der Verfügbarkeit des Mail-Bastionsrech-ners. Diese MX-Records werden nur auf den neu geschaffenen externen Nameservern (tunamec.tuwien.ac.at und tunamed.tuwien.ac.at) eingetragen, das heißt nur von außen einlangende Mail wird über den Mail-Bastionsrechner geleitet.

Literatur

E-mail Explained: http://www.sendmail.org/email-explained.html

Martin Rathmayer: Mißbrauch von Mail-Servern an der TU Wien, Pipeline 24, Februar 1998
http://www.tuwien.ac.at/pipeline/p24/mailmiss.html

Elisabeth Donnaberger, Johann Kainrath: Firewall und Internet Security an der TU Wien, ZIDline 1, Juni 1999, http://www.zid.tuwien.ac.at/zidline/zl01/firewall.html

1 Spam - Spam is unsolicited Mail on the Internet. From the sender's point-of-view, it's a form of bulk mail, often to a list culled from subscribers to a Usenet discussion group or obtained by companies that specialize in creating Mail distribution lists. To the receiver, it usually seems like junk Mail. In general, it's not considered good netiquette to send spam. It's generally equivalent to unsolicited phone marketing calls except that the user pays for part of the message since everyone shares the cost of maintaining the Internet. Some apparently unsolicited Mail is, in fact, Mail people agreed to receive when they registered with a site and checked a box agreeing to receive postings about particular products or interests. This is known as both opt-in Mail and permission-based Mail. A first-hand report indicates that the term is derived from a famous Monty Python sketch ("Well, we have Spam, tomato & Spam, egg & Spam, Egg, bacon & Spam...") that was current when spam first began arriving on the Internet. Spam is a trademarked Hormel meat product that was well-known in the U.S. Armed Forces during World War II.

2 http://www.tkc.at/WWW/RechtsDB.nsf/pages/TKG

3 http://www.zid.tuwien.ac.at/security/policies.html

4 "simple message transfer protocol", siehe http://www.sendmail.org/

5 siehe http://www.sendmail.org/

6 ORBS, or the Open Relay Behaviour-modification System, is a database for tracking SMTP servers that have been confirmed to permit third-party relay. These servers permit spammers to connect to them from anywhere in the world, usually from a modem connection, and then forward the spam to its intended victims. (http://www.orbs.org/)

7 siehe RFC 974 (http://info.internet.isi.edu:80/in-notes/rfc/files/rfc974.txt)

Zum Inhaltsverzeichnis, ZIDline 4, Dezember 2000