Mailserver? Nein, danke!

von Peter Marksteiner (Ausgabe 99/3, Oktober 1999)


1) Server im Uni-Datennetz

Die meisten Internet-Provider gestatten ihren Kunden das Betreiben von Servern - wenn überhaupt - nur mit weitgehenden Einschränkungen und unter strengen Auflagen. Das sind keine willkürlichen Schikanen seitens der Provider, sondern notwendige Schutzmaßnahmen: Mangelhaft gewartete Server können leicht von Spammern, Hackern und anderen Menschen mit bösen Absichten mißbraucht werden, was dem Provider alle möglichen Probleme bescheren kann - vom Verlust des guten Rufes in der "Internet Community" bis zu gerichtlichen Klagen und Schadenersatzforderungen.

An der Uni Wien gab es bis jetzt keine besonderen Einschränkungen. Solange sie nicht unangenehm auffielen, konnten an den Instituten beliebige Server betrieben werden. Die schönen Tage sind nun auch hier zu Ende: Nach zahlreichen Fällen von Mißbrauch, vor allem durch Spammer1), ist es unumgänglich geworden, den Betrieb von Servern zu reglementieren, um weiteren Mißbrauch zu verhindern.

Nachdem der Begriff "Server" nicht ganz eindeutig ist, sei hier definiert, was im folgenden damit gemeint ist. Betrachten wir als typisches Beispiel eines Servers einen Webserver: Dieser kommuniziert mit den Browsern ("Klienten") nach festen Regeln ("Protokoll"). Für verschiedene Protokolle sind eigene Kommunikationskanäle ("Ports") vorgesehen. Auf einem Webserver läuft ständig ein Prozeß ("HTTP-Server" oder "HTTP-Daemon"), der bereit ist, Anfragen von Klienten zu beantworten. Server sind demzufolge Rechner, die auf bestimmten Ports ständig Verbindungen von Klienten entgegennehmen und nach dem entsprechenden Protokoll mit dem Klienten kommunizieren. Gängige Server sind z.B. Webserver (HTTP-Server), FTP-Server, Newsserver (NNTP-Server) und Mailserver - aber auch jeder Linux-Rechner, der Telnetzugriff von außen erlaubt, und jede Workstation mit X-Windows ist ein Server. Ob ein PC mit Microsoft Windows NT nach dieser Definition ein Server ist oder nicht, hat nichts damit zu tun, ob die "Workstation"- oder die "Server"-Version von Windows NT verwendet wird: Auch unter der Workstation-Version kann ein Webserver laufen.

Detaillierte Richtlinien betreffend Server im allgemeinen werden noch ausgearbeitet; hier wird lediglich festgelegt, was beim Betrieb eines Mailservers im Datennetz der Universität Wien zu beachten ist. Etliche Leute betreiben einen Mailserver, ohne es zu wissen - gerade solche Server sind besonders anfällig für Mißbrauch durch Spammer. In vielen Fällen ist es wohl die beste Lösung, den Mailserver einfach abzuschalten. Gelegentlich gibt es aber auch triftige Gründe dafür, daß ein Institut oder eine Abteilung einen eigenen Mailserver betreibt. Im folgenden wird beschrieben, welche Maßnahmen erforderlich sind, um einen solchen Server gegen Mißbrauch zu schützen.

2) Wie funktioniert ein Mailserver?

Die Funktionsweise eines Mailservers sei hier am Beispiel des fiktiven Instituts für Hohe Wissenschaft erläutert. Das Institut betreibt einen Mailserver mit dem Hostnamen ASTERIX.IHW.UNIVIE.AC.AT2); die Mitarbeiter des Instituts und vielleicht auch einige Studierende erhalten Mailadressen wie FRANZI@IHW.UNIVIE.AC.AT, ANNA@IHW.UNIVIE.AC.AT oder auch THE_BOSS@IHW.UNIVIE.AC.AT.

Damit Nachrichten an solche Adressen richtig zugestellt werden, ist ein Eintrag in den Nameservern der Universität Wien erforderlich, ein sogenannter MX-Record (MX = Mail Exchange). Dieser MX-Record enthält die Information, daß für eMail an die Domain IHW.UNIVIE.AC.AT der Host ASTERIX.IHW.UNIVIE.AC.AT zuständig ist. Wie alle Nameserver-Einträge können MX-Records nur vom EDV-Zentrum ein- und ausgetragen oder geändert werden.

Der Mailserver ASTERIX.IHW.UNIVIE.AC.AT läuft immer (oder zumindest fast immer), und eine geeignete Mailing-Software ist ständig bereit, Verbindungen zum SMTP-Port entgegenzunehmen. SMTP, das "Simple Mail Transfer Protocol", definiert die Regeln, nach denen im Internet eMail verschickt und empfangen wird. Das Mailing-Programm muß so konfiguriert sein, daß es einerseits aus der ganzen Welt Nachrichten an die Domain IHW.UNIVIE.AC.AT in Empfang nimmt und an einer geeigneten Stelle abspeichert, wo sie von den Adressaten gelesen bzw. abgeholt werden können; andererseits sollen alle Rechner in der Domain IHW.UNIVIE.AC.AT die Möglichkeit haben, über diesen Server Nachrichten in alle Welt zu versenden3).

Die meisten Mailserver im Bereich der Uni Wien sind Linux- und sonstige Unix-Rechner, die als Mailing-Software Sendmail verwenden; deshalb wird im folgenden nur auf Sendmail detaillierter eingegangen. Seltener werden Unix-Rechner mit qmail und Novell-Server mit Mercury verwendet. Produkte wie Microsoft Exchange und Lotus Notes von IBM dienen hauptsächlich der Kommunikation innerhalb von geschlossenen Firmennetzwerken ("Intranets"), verfügen jedoch auch über SMTP-Gateways zur Verbindung ins Internet. Diese Programme werden vor allem in der kommerziellen EDV eingesetzt und sind an der Uni Wien nur vereinzelt zu finden.

Sendmail gehört bei praktisch allen Unix-Rechnern zum Basisbetriebssystem. Meistens wird der Sendmail-Daemon automatisch gestartet, und so mancher Rechner, dessen einziger Zweck die Auswertung von Spektren oder die Berechnung von 3D-Modellen ist, ist daher auch ein Mailserver, selbst wenn er noch keine einzige Nachricht verschickt oder empfangen hat. Solche Mailserver bringen keinerlei Nutzen, es kann damit aber genauso Probleme geben wie mit "echten". Hier ist es fast immer angebracht, Sendmail einfach abzudrehen (Näheres dazu siehe Kapitel 6).

3) Probleme beim Betreiben von Mailservern

Das gravierendste Problem, mit dem sich die Betreiber von Mailservern herumschlagen müssen, ist derzeit Spam4). Wer Spam - oder, wie es offiziell heißt, "Unsolicited Commercial Email" (UCE) - verschicken will, bedient sich dazu irgendeines Mailservers auf der weiten Welt, dessen Eigentümer oft gar nichts von dem ungebetenen Gast weiß.

Um das zu unterbinden, muß der Server so konfiguriert werden, daß er kein Relaying für Dritte betreibt, d.h. der Sender oder der Empfänger (oder beide) müssen sich in der lokalen Domain befinden - in unserem Beispiel in IHW.UNIVIE.AC.AT. Alle anderen Verbindungen müssen zurückgewiesen werden. Leider ist das nicht immer ganz einfach: Sendmail ist ein sehr komplexes Programm, das für Nicht-Profis schwer zu handhaben ist und selbst Profis manche Überraschungen bereitet. Das bei O'Reilly erschienene Standardwerk Sendmail von Bryan Costales und Eric Allman, dem Schöpfer von Sendmail, hat mehr als tausend Seiten. Die Konfigurationsdatei sendmail.cf ist für nicht Eingeweihte in einer unverständlichen Geheimsprache geschrieben, und manche "Rewriting Rules" bereiten selbst Spezialisten Kopfzerbrechen. Ältere Versionen von Sendmail bieten überhaupt keinen Schutz gegen Spam, und in der Version 8.8.8 sind umfangreiche Änderungen der Standard-Konfiguration notwendig, um den Server "abzudichten". Erst in der Version 8.9.3 sind alle Maßnahmen gegen Spam-Relaying automatisch aktiviert. Ältere Versionen als 8.8.8 sollten unbedingt durch die neueste ersetzt werden, auch aus Sicherheitsgründen (siehe unten).5) Sendmail gilt als besonders "widerborstiges" Programm; das heißt aber nicht, daß andere Mailserver leichter zu administrieren sind. Hier sind die Schwierigkeiten oft anders geartet: Gerade bei Produkten wie Microsoft Exchange ist das Gateway ins Internet eher ein "Anhängsel", deshalb dauert es oft länger, bis der Hersteller bei Problemen reagiert.

Wenn über einen Server Spam verschickt wird, dann hagelt es Beschwerden an die diversen Postmaster- und Abuse-Adressen (siehe Kapitel 5), und der Server wird auf "Schwarze Listen" gesetzt. Die bekannteste dieser Listen ist ORBS (http://www.orbs.org/); es gibt auch noch etliche andere. Auch ohne Spam kann man auf eine solche Liste kommen - es genügt, daß ein Relay offen ist. Daher sollten alle offenen Relays möglichst schnell geschlossen werden, ohne erst eine Spam-Attacke abzuwarten. Manche Firmen und Organisationen konfigurieren ihre Mailprogramme so, daß sie von Servern, die auf schwarzen Listen stehen, überhaupt keine Mail annehmen. Einige dieser Listen schütten allerdings das Kind mit dem Bade aus: Selbst seriöse Server-Betreiber kommen sehr schnell auf die Liste und nicht so leicht wieder weg, sodaß man Gefahr läuft, auch "echte" Mail nicht zu erhalten, wenn man diese Listen als Spam-Filter verwendet.

Mit Sendmail, besonders mit älteren Versionen, gibt es auch zahlreiche Sicherheitsprobleme. Über "Löcher" im Sendmail ist es schon zahlreichen bösartigen Hackern (auch "Cracker" genannt) gelungen, in fremde Netzwerke einzudringen. Nachdem Sendmail praktisch überall verwendet wird, werden solche Löcher meistens sehr schnell bekannt und bald danach gestopft - bis das nächste Loch auftaucht.

Mit einer aktuellen Linux-Distribution (beispielsweise RedHat 6.0) und Sendmail 8.9.3 ist man zur Zeit ziemlich sicher: Es sind in dieser Sendmail-Version keine gröberen Sicherheitslücken bekannt, und bis jetzt hat sie sich als resistent gegen alle Tricks von Spammern erwiesen. Das ändert aber nichts an der Tatsache, daß auch ein solcher Server gewartet werden muß und ständiger Aufmerksamkeit bedarf - vielleicht werden schon morgen neue Attacken bekannt, und in ein paar Monaten gilt es womöglich als krimineller Leichtsinn, Sendmail 8.9.3 zu verwenden.

4) Die zentralen Mailserver der Universität Wien

Wer einen Mailserver betreibt, sollte sich in jedem Fall fragen, ob das wirklich unbedingt notwendig ist. In den seltensten Fällen können diese Server etwas, das die zentralen Mailserver der Universität Wien (MAILBOX.UNIVIE.AC.AT für Mitarbeiter und Lehrbeauftragte, UNET.UNIVIE.AC.AT für Studierende) nicht können. Insbesondere das Mailbox-Service bietet etliche Vorteile:

  • Nachdem es sich um ein zentrales Service des EDV-Zentrums handelt, sind mehrere Mitarbeiter mit dessen Betreuung beauftragt. Falls Probleme auftreten, können diese üblicherweise sehr schnell behoben werden.
  • Verschiedene Maßnahmen erhöhen die Ausfallsicherheit. Beispielsweise sorgen gespiegelte Filesysteme dafür, daß das System ungehindert weiterläuft, wenn eine Platte defekt ist (während ich diesen Artikel schreibe, läuft der Mailbox-Rechner seit über einem halben Jahr ohne Unterbrechung).
  • Selbst wenn Mailbox- oder Unet-Rechner kurzfristig ausfallen sollten, sorgt ein "secondary MX-Record" dafür, daß eMail-Nachrichten von einem Reserve-Server in Empfang genommen und "zwischengelagert" werden, bis die Betriebsunterbrechung beendet ist.
  • Die einheitlichen Mailadressen der Form VORNAME.NACHNAME@UNIVIE.AC.AT sind allgemein bekannt und tragen zur "Corporate Identity" der Universität Wien bei. Wenn jemand eine Adresse nicht genau weiß, so kann eine Mailbox-Adresse meistens erraten werden, während die Systematik anderer Mailadressen oft nicht leicht herauszufinden ist: Ein Institut verwendet vielleicht Adressen der Form VORNAME@IHW.UNIVIE.AC.AT, ein anderes NACHNAME@IGO.UNIVIE.AC.AT und ein drittes VORNAME.NACHNAME@IMM.UNIVIE.AC.AT.
  • Mailbox-Adressen sind im Online-Personalverzeichnis der Universität Wien und Unet-Adressen - auf Wunsch des Inhabers - im Unet-Adreßbuch zu finden.

Viele lokale Mailserver wurden zu einer Zeit aufgesetzt, als die Qualität der zentralen Mailing-Services vielfach noch zu wünschen übrig ließ: Der erste Mailbox-Rechner hatte des öfteren Performance-Probleme, es gab lange Verzögerungen bei der Vergabe von Mailbox-Adressen usw. Von "Kinderkrankheiten" bei der DCE-Umstellung abgesehen (siehe Artikel Die Hintergründe der Unet-Misere im Comment 99/1) funktionieren die zentralen Mailserver jedoch seit geraumer Zeit sehr zufriedenstellend. Mit der Reform des Mailbox-Service konnte auch die Vergabe von Mailbox-Adressen beschleunigt und weitgehend automatisiert werden, sodaß einer der Hauptgründe wegfällt, der bisher etliche Institute und Abteilungen dazu bewogen hat, eigene Mailserver zu betreiben.

5) Pflichten von Mailserver-Betreibern

Wer im Datennetz der Universität Wien einen Mailserver betreiben will, muß sich an folgende Spielregeln halten:

  • Es muß einen Verantwortlichen geben, der bei Problemen prompt reagiert. Es ist nicht erforderlich, diesen Verantwortlichen dem EDV-Zentrum namentlich bekanntzugeben; er muß aber jederzeit als POSTMASTER@DOMAIN bzw. POSTMASTER@HOST erreichbar sein. Diese Adresse ist im RFC822, in dem das SMTP-Protokoll definiert wird, vorgeschrieben. Mail an den Postmaster muß auch regelmäßig gelesen werden: Bei vielen Mailservern wird sie an <tt>root</tt> weitergeleitet und nie gelesen. Auch die Adresse ABUSE@DOMAIN (laut RFC2142 erforderlich) sollte existieren.
  • Der Postmaster muß bereit sein, eng mit dem EDV-Zentrum zusammenzuarbeiten. Dazu gehört auch die Weitergabe von Informationen (z.B. Logfiles zur Dokumentation von Einbruchsversuchen, Spam-Attacken usw.).
  • Der Server muß laufend gewartet werden. Wenn ein Postmaster das Institut verläßt, muß ein Nachfolger seine Verpflichtungen übernehmen. Bei längeren Abwesenheiten muß es eine Vertretung geben.
  • Der Postmaster muß über ausreichende Kenntnisse verfügen, um den Server zu betreuen. Mail an den Postmaster "Ihr Server ist offen für die Spam-Attacke XY, bitte schließen Sie diese Lücke" sollte mit "Ja, habe ich erledigt" beantwortet werden und nicht mit "Wie mache ich denn das?". Etliche Mitarbeiter des EDV-Zentrums sind kompetent, was Sendmail betrifft, und können daher bei Sendmail-Problemen weiterhelfen, soweit es ihre Zeit erlaubt; wer aber beispielsweise einen Microsoft Exchange-Server betreibt, ist auf sich selbst und den Kundendienst von Microsoft angewiesen.
  • Der Server darf kein Relaying für Dritte betreiben (siehe Kapitel 3).
  • In der Sendmail-Konfiguration sollte kein zentraler Mailserver des EDV-Zentrums (MAILBOX.UNIVIE.AC.AT usw.) als "Smarthost" eingetragen werden. Smarthosts sind meistens ein historisches Relikt aus Zeiten, als es noch eine hohe Kunst war, einen Mailserver so aufzusetzen, daß Mail an Bitnet-, X.400-, UUCP- und sonstige exotische Adressen richtig weitergeleitet wurde; heutzutage sollte jeder Mailserver selbst schlau genug sein. Wenn z.B. über einen mangelhaft konfigurierten Server Spam verschickt wird, so kommt nicht nur der Server, sondern auch der Smarthost als Spam-Relayer in Verruf.

Wenn dem EDV-Zentrum ein Problem mit einem Mailserver bekannt wird (z.B. wenn der Server als Spam-Relay mißbraucht wird oder auf schwarzen Listen steht), werden folgende Maßnahmen ergriffen:

  • Der zuständige Postmaster wird informiert und aufgefordert, das Problem zu beheben.
  • Wenn nach angemessener Frist ("angemessen" ist hier ziemlich kurz - bei akuten Problemen innerhalb eines Tages) keine Reaktion erfolgt, wird der Server auf allen zentralen Mailservern des EDV-Zentrums in die Datei badhosts eingetragen. Das bewirkt, daß Mailbox- und Unet-Rechner von diesem Server keine eMail mehr annehmen. (Erfahrungsgemäß ist diese Maßnahme sehr wirksam: Sobald sich die Benutzer beschweren, daß sie keine Nachrichten mehr verschicken können, tauchen die verschollenen Postmaster sehr schnell auf und fragen, was denn da los sei.) Nach Behebung des Problems werden die Einträge aus badhosts wieder entfernt.
  • Bei fortgesetztem Mißbrauch wird dem Server der Zugang zum Netz eingeschränkt, z.B. durch Sperren des SMTP-Ports im Router.
  • Manchmal sind auch ohne Vorwarnung "harte" Maßnahmen wie das Sperren von IP-Adressen im Router (wodurch der betreffende Rechner überhaupt von der Umwelt abgeschnitten wird) erforderlich. Das betrifft vor allem Rechner, bei denen es Hackern gelungen ist, von außen einzudringen: Die Aktivitäten solcher Hacker müssen ohne Verzug unterbunden werden. Das ist für den Eigentümer des Rechners zwar unangenehm, aber nach einer erfolgreichen Hacker-Attacke bleibt ihm sowieso nichts anderes übrig, als den Rechner neu zu installieren.

Möglicherweise wird das Sperren des SMTP-Ports demnächst generell für alle Rechner eingeführt, die dem EDV-Zentrum nicht als "offizielle" Mailserver bekannt sind. Damit können alle anderen Mailserver nur mehr Mail empfangen, die innerhalb der Uni Wien verschickt wurde. Längerfristig ist eine solche Maßnahme für alle Betreiber von Unix/Linux-Rechnern und sonstigen Servern sogar eine Erleichterung: Niemand braucht sich dann mehr Sorgen zu machen, daß sein Rechner als Spam-Relay mißbraucht werden könnte.

6) Abschalten von Mailservern

Sie betreiben einen Mailserver und haben sich davon überzeugen lassen, daß der Nutzen den Aufwand nicht rechtfertigt? Wenn Sie ihn nun auflassen wollen, stehen Sie wahrscheinlich vor dem Problem, daß die alten Mailadressen an vielen Orten in aller Welt bekannt sind und womöglich als Kontaktadressen in wissenschaftlichen Publikationen angegeben wurden. Wenn man einen Mailserver einfach abdreht und den dazugehörigen MX-Record entfernt, dann werden alle Nachrichten an diese Domain mit dem Vermerk IHW.UNIVIE.AC.AT ... Host unknown an den Absender retourniert.

Zur Lösung dieses Problems empfiehlt sich folgende Vorgangsweise: Schicken Sie an das EDV-Zentrum6) eine Liste sämtlicher alter Mailadressen, die noch weiter funktionieren sollen, sowie der neuen Adressen, wohin die Nachrichten weitergeleitet werden sollen. Dann wird der MX-Record entfernt und ein neuer MX-Record eingetragen, der auf einen der zentralen Mailserver (z.B. MAILBOX.UNIVIE.AC.AT) zeigt. Die alten und die neuen Adressen werden in eine Tabelle, die sogenannte "Virtual User Table", eingetragen, die etwa folgendermaßen aussieht:

  • anna@ihw.univie.ac.at / anna.nemetz@univie.ac.at
  • joe@ihw.univie.ac.at / josef.uher@univie.ac.at
  • ursula@ihw.univie.ac.at / a1234567@unet.univie.ac.at
  • postmaster@ihw.univie.ac.at / karl.turek@univie.ac.at
  • @ihw.univie.ac.at / franz.tschech@univie.ac.at

Die letzte Zeile ist optional; sie bewirkt, daß Franz Tschech sämtliche Nachrichten an Adressaten in der Domain IHW.UNIVIE.AC.AT erhält, die nicht vorher explizit angeführt sind - auch an solche, die nie existiert haben. Läßt man diese Zeile weg, gehen solche Nachrichten mit dem Vermerk User unknown zurück an den Absender.

Bitte beachten Sie, daß solche Virtual User Tables vom EDV-Zentrum nur einmal erstellt, aber nicht gewartet werden: Sie dienen nur der Beseitigung von Altlasten, nicht aber dazu, einen virtuellen Mailserver zu betreiben, dessen Betreuung man dem EDV-Zentrum überläßt.

Noch ein Wort zu den bereits erwähnten "unabsichtlichen" Mailservern, d.h zu Unix-Rechnern, auf denen Sendmail läuft, obwohl es nicht benötigt wird. Folgende Vorgangsweise empfiehlt sich, um einen solchen Mailserver stillzulegen:

  • Stellen Sie mit dem Befehl telnet localhost smtp fest, ob der Sendmail-Daemon läuft. Wenn nein (d.h. bei connection refused ), ist alles in Ordnung.
  • Ansonsten finden Sie die "Process ID" des Sendmail-Daemons mit dem Befehl ps ax | grep sendmail heraus. Beenden Sie diesen Prozeß mit dem Befehl kill.
  • Stellen Sie sicher, daß bei einem Neustart des Systems der Daemon nicht automatisch gestartet wird. Leider ist die Konfiguration des Systemstarts von System zu System sehr unterschiedlich, sodaß hier kein allgemeines "Kochrezept" gegeben werden kann. Ein Linux-System beispielsweise, das im "Runlevel 3" läuft, hat im Verzeichnis /etc/rc/rc3.d eine Datei namens S40sendmail (die Zahl kann schwanken, wichtig ist jedoch das große S). Löschen Sie diese Datei oder, besser, geben Sie ihr einen neuen Namen, z.B. s40sendmail (mit kleinem s). Auf den meisten anderen Systemen ist die Vorgangsweise ähnlich - studieren Sie die Datei /etc/inittab und durchsuchen Sie alle Dateien und Verzeichnisse mit Namen wie /etc/rc* oder /sbin/rc* nach sendmail.

Auch wenn kein Sendmail-Daemon läuft, kann ein Rechner immer noch eMail verschicken - nur empfangen kann er keine. Wenn Ihre Molekulardynamik-Simulationen Ihnen von Zeit zu Zeit eine Nachricht an Ihre Mailbox-Adresse schicken, um Sie über den Fortgang der Berechnungen zu informieren, braucht Ihr Rechner deswegen kein Mailserver zu sein. In einem solchen Fall ist gegen einen Smarthost nichts einzuwenden: Ohne Sendmail-Daemon könnte es Probleme mit Nachrichten geben, die nicht sofort zugestellt werden können; der lokale Smarthost ist jedoch praktisch immer zu erreichen.


 

1) In fast allen Fällen handelt es sich um Attacken von außen, an denen weder Mitarbeiter noch Studierende der Universität Wien beteiligt sind.

2) Ähnlichkeiten mit bestehenden Hostnamen sind rein zufällig. Neben systematischen Namen wie WWW, FTP, MAIL usw. werden jedoch weltweit Gestalten der griechisch-römischen Mythologie (HELIOS, VENUS usw.) und Comic-Figuren am häufigsten als Hostnamen verwendet.

3) Zum Versenden von Mail ist - anders als zum Empfangen - ein Mailserver nicht unbedingt erforderlich, aber von Vorteil (siehe dazu auch Kapitel 6).

4) Siehe dazu auch:We do not relay (Comment 98/2),We do not relay, Teil II (Comment 98/3),Spam Spam Spam... (Comment 98/1).

5) Nähere Infos findet man unter http://www.sendmail.org/; die aktuelle Sendmail-Version kann auch lokal unter http://univie.linux.tucows.com/files/console/servers/sendmail_8_9_3_tar.gz bezogen werden.

6) Kontaktadresse ist, wie üblich, das Service- und Beratungszentrum (HELPDESK.EDV-ZENTRUM@UNIVIE.AC.AT).