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.
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.
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.
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.
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.
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.)
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).
Fragen zur TUNET-Datenbank: hostmaster@noc.tuwien.ac.at
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.
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.)
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.
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.
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
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)