Konzept für den E-Mail-Dienst der Universität Hamburg
-- Vorgaben, Empfehlungen, Richtlinien --

Einstimmig verabschiedet auf der Sitzung der
Planungskommission am 11. Februar 2000

3. April 2000

Inhalt

• Inhalt
• Status
• Motivation
• Betriebskonzept für Mail-Server
  • Grundsätzliches
  • Mögliche Varianten
  • Empfehlung
• Technische Realisierung
• Migration der vorhandenen zur künftigen Struktur
• E-Mails lesen und schreiben
  • E-Mails lesen
  • E-Mails versenden
• Einheitliche E-Mail-Adressen
  • Konzept
  • Migration

Status

Es gibt ca. 150 Mail-Server innerhalb der Domain uni-hamburg.de, die im wesentlichen nebenbei betrieben und überwacht werden und entsprechend unsicher sind.

Motivation

Der E-Mail-Dienst ist neben dem News-Dienst und dem WWW-Dienst nach wie vor einer der wichtigsten Kommunikationsdienste im Internet. Er ist ein für Mitarbeiter und Studierende unverzichtbares Arbeitswerkzeug, das aber mit der breiten Akzeptanz und Kommerzialisierung des Internet mehr und mehr mißbraucht wird, um E-Mail-Accounts mit unerwünschter Werbung (,,Spam``) zu bombardieren. Hierfür werden oft ungeschützte Mailhosts von Dritten als Spam-Relay mißbraucht, wie es auch bereits in der Universität Hamburg passiert ist. E-Mail-Dienste werden von vielen benutzt; gerade deswegen sind sie ,,beliebter`` - und für Angreifer erfolgversprechender - Angriffspunkt zum Eindringen in fremde Systeme.
Daher ist es zwingend erforderlich, eine neue, sicherere Struktur des E-Mail-Dienstes an der Universität Hamburg zu definieren, zu beschließen und umzusetzen. Einige Beispiele sollen die Notwendigkeit der im folgenden erläuterten restriktiven Maßnahmen begründen:

1. Angriffe über den E-Mail-Dienst (SMTP, IP-Port 25) sind häufig deshalb erfolgreich, weil die Systeme, auf denen der E-Mail Daemon läuft, nicht den Erfordernissen entsprechend betrieben werden. Dies bezieht sich auf das Einspielen aktueller Patches zur Erhöhung der Systemsicherheit, Monitoring des Systems usw. Außerdem wird auf vielen Rechner in der gelieferten Default-Konfiguration ein Mail-Server betrieben, auch wenn dies gar nicht notwendig wäre, weil der Rechner z.B. als Büroarbeitsplatz und nicht als Abteilungsserver genutzt wird.
   

2. Schlecht abgesicherte E-Mail-Systeme werden von Versendern von Massen-Spam-Mails als ,,Relays`` mißbraucht, um nicht selbst die erhebliche Netzlast und -kosten tragen zu müssen, die beim mißbrauchten System anfallen. Zudem landen die oft massiven Beschwerden über die Spam-Mails auf diese Weise beim Verwalter des als Relay mißbrauchten Rechners und nicht beim Verursacher.

3. Die Auswirkungen solcher Schadensfälle für die Universität in Hinblick auf Verfügbarkeit des E-Mail-Systems und die Außendarstellung sind äußerst negativ.

Es ist völlig unmöglich, jeden Rechner im Universitätsnetz einzeln gegen Mißbrauch abzusichern. Deshalb ist es zwingend notwendig, das Problem darauf zu reduzieren, daß so wenig wie möglich Rechner direkt per E-Mail von außerhalb des Universitätsnetzes erreichbar sind und trotzdem der E-Mail-Dienst für unsere Benutzer in zufriedenstellender Weise verfügbar ist. Das ganze Problem ist natürlich nicht auf den E-Mail-Dienst allein beschränkt; das im folgenden beschriebene muß in ein allgemeines Absicherungs/Firewall-Konzept für das gesamte Universitätsnetz eingebettet werden.

Betriebskonzept für Mail-Server

Grundsätzliches

Jeder Fachbereich/Institut/Einrichtung betreibt maximal einen Mail-Server (Name: mailhost). Für ihn gibt es einen administrativen und einen technischen Ansprechpartner, die für den sicheren Betrieb verantwortlich sind. Ihre Erreichbarkeit muß sichergestellt sein. Sie werden vom FB/Institut dem RRZ benannt. Das RRZ bietet den Fachbereichen an, den Mail-Service zu übernehmen.
Weitere Rechner innerhalb eines Fachbereichs/Instituts haben keine direkte Verbindung von und zu Mail-Servern außerhalb des Universitätsnetzes. Sie werden bei Bedarf über den zentralen Mail-Server des Fachbereichs/Instituts mit E-Mails versorgt.

Für den Betrieb von Mail-Servern werden die folgenden Voraussetzungen erwartet:

1. Verfügbarkeit der Server in der Regel an sieben Tagen der Woche rund um die Uhr,
2. Grundsätzlicher Schutz vor unbefugtem Zugriff auf den Server (Aufstellung in gesichterten Räumen),
3. Sichere Konfiguration des Mail-Systems: Kein Relaying von fremder Mail, Abblocken von bekannten Spam-Quellen durch Realtime Blackhole List,
4. Regelmäßiges Einspielen notwendiger (Sicherheits-)Patches,
5. Regelmäßiges Backup,
6. Umfassende Kenntnis der Administratoren über E-Mail- und Kommunikationsprotokolle sowie über das eingesetzte Betriebssystem,
7. Besonderer Hinweis an die Administratoren zum Datenschutzgesetz,
8. Ganzjährige Zuständigkeit und Verfügbarkeit der Administratoren (d.h. Administration durch hauptamtliches Personal, nicht durch Hilfskräfte)

Zu den Aufgaben der Administratoren der Mail-Server gehört weiter:

1. Systemüberwachung,
2. Benutzerverwaltung,
3. Mapping von E-Mail-Adressen auf Benutzerkennungen,
4. Pflegen von E-Mail-Verteilern

Mögliche Varianten

Für Versand und Empfang von E-Mails bieten sich zwei Möglichkeiten an:

Zentrales System von Mail-Relays:

Ein Verbund von Mail-Relays auf einigen ausgesuchten Rechnern, der für den gesamten Universitätsbereich als Mail-Relay die ein- wie auch ausgehenden E-Mails der verteilten Server lediglich annimmt und weiterreicht. Die Anforderungen an Verfügbarkeit und Leistungsfähigkeit einer solchen ,,Mail-Firewall`` sind sehr hoch. Die Systeme müssen gegen Ausfall sehr gut abgesichert sein (z.B. USV, gespiegelte Platten, automatisches Failover auf Backupsystem vor Ort).

Durch das Zusammenwirken mehrerer Systeme im zentralen Mail-Relay erhöht sich die Verfügbarkeit des Gesamtsystems. Für den Betrieb eines Backup-Relays gelten die gleichen hohen technischen und administrativen Anforderungen wie für das primäre Mail-Relay.

Pro
einige wenige zentrale Stellen, die sehr gut gegen Angriffe von außen abgesichert und überwacht werden müssen;

zentrales Logging: leichte Nachvollziehbarkeit von Problemen

Kontra
sehr hohe Anforderungen an Verfügbarkeit und Leistungsfähigkeit

Verteilte Mail-Server direkt erreichbar:

Die verteilten Server in den Fachbereichen werden am Internet-Zugang freigeschaltet, d.h. diese zugelassenen Systeme haben die Möglichkeit, direkte Verbindungen zu Einrichtungen außerhalb der Universität aufzubauen. Die Anforderungen an Verfügbarkeit und Leistungsfähigkeit dieser Server sind hoch.

Pro
Lastverteilung und größere Fehlertoleranz

Kontra
eine große Anzahl von Mail-Servern muß sehr gut gegen Angriffe von außen abgesichert und überwacht werden, damit höhere Wahrscheinlichkeit von angreifbaren Systemen;keine zentrale Überwachung und Problemanalyse möglich

Empfehlung

Wir empfehlen aus Sicherheitsgründen das Konzept des zentralen Mailrelays als Verbund einiger weniger Mailsysteme schnellstmöglich umzusetzen.Sollen in einem Fachbereich weitere Mail-Server aufgesetzt und betrieben werden, so sind diese über den zentralen Mailserver des Fachbereichs zu ,,routen``. Die eingangs zusammengestellten Voraussetzungen für den Betrieb gelten ebenfalls für das Betreiben weitere dezentraler Mailserver. Bei auftretenden Störungen im Mail-Betrieb, die durch einen zusätzlich dezentral betriebenen Mailserver verursacht werden, ist der Administrator des ,,zentralen`` Fachbereichs-Mailserver befugt und verpflichtet, durch Abhängen des ,,Störenfriedes`` die Behinderung des universitären Netzbetriebes bis zu deren Beseitigung abzustellen.

Technische Realisierung

Zur Realisierung dieses Konzeptes werden die entsprechenden Maßnahmen an den Systemen der Universität und vor allem der Netzkomponenten getroffen:

1. Am zentralen WiN-Router der Universitätsnetzes werden Zugriffs-Regeln (Accesslists) aufgesetzt, die Zugriff von außen auf Port 25 (SMTP) je nach der obigen Konzeptvariante nur zu dem zentralen Mail-Relay bzw. nur zu den zentralen Mail-Servern der Fachbereiche zulassen sowie zusätzlich vom externen Backup-Mail-Server ws-ham1.win-ip.dfn.de (193.174.75.146) zu allen Rechnern im Universitätsnetz.

   Cisco-Beispiel-Konfiguration für die Informatik alleine; analog muß die Absicherung des gesamten Universitätsnetzes erfolgen:

   <pre>interface FastEthernet1/0/0
   ip address 134.100.5.33 255.255.255.240
   ip access-group 160 out
   no ip directed-broadcast
   full-duplex
   ipx network 866405
   
   access-list 160 permit tcp any host 134.100.9.61 eq smtp
   access-list 160 permit tcp host 134.100.33.12 any eq smtp
   access-list 160 permit tcp host 193.174.75.146 any eq smtp
   access-list 160 deny tcp any any eq smtp
   access-list 160 permit ip any any</pre>

   Das gleiche gilt für die Verbindung von den Mail-Servern nach außen.

2. Alle Rechner, die E-Mail empfangen sollen, müssen mit entsprechende MX-Records im Nameserver eingetragen sein: ein MX 0-Record für den Rechner selbst und Backup-MX-Records für die zentralen Mail-Server des Fachbereichs/Instituts und des RRZ. Damit kann jeder Rechner E-Mail innerhalb des Universitätsnetzes direkt und von außen mit dem Umweg über maximal ein Relay empfangen. Beispiel: <pre>rechner.fb.uni-hamburg.de IN MX 0 rechner.fb.uni-hamburg.de.
   IN MX 10 mailhost.fb.uni-hamburg.de.
   IN MX 20 mailrelay.rrz.uni-hamburg.de.
   IN MX 30 backuprelay.rrz.uni-hamburg.de.
   IN MX 100 ws-ham1.win-ip.dfn.de.</pre> Für die weitaus meisten Rechner im Universitätsnetz, die E-Mail empfangen können, sind diese MX-Records im Nameserver bereits vorhanden. Wo diese Einträge noch fehlen bzw. unvollständig sind, können sie zentral auf den Nameservern der Universität nachgetragen werden. Auf den betroffenen Rechnern selbst ist keine Umkonfigurierung notwendig.

3. Alle Rechner, die E-Mail verschicken wollen, müssen so konfiguriert sein, daß sie abgehende E-Mails nicht direkt an den Empfängerrechner schicken, sondern an den Mail-Server des Fachbereichs/Instituts bzw. an das zentrale Mail-Relay. Von dort wird die Mail dann an die eigentlichen Empfänger weitergeleitet.

   Dies ist das größte Problem für eine schnelle vollständige Umsetzung unseres Konzeptes: In dem Augenblick, in dem am WiN-Router ausgehende E-Mail für alle Rechner bis auf die zentralen Mail-Server abgeschaltet ist, können Arbeitsplatzrechner keine E-Mail mehr verschicken, wenn sie nicht für die geänderten Verhältnisse umkonfiguriert werden. Letztlich ist genau das von uns gewollt, aber in der Übergangszeit wird es damit einige Probleme geben.

4. Die von außerhalb des Uni-Netzes erreichbaren Mail-Server müssen gegen Spam-Relaying gesichert werden: Nur E-Mail an Rechner im Universitätsnetz bzw. von Rechnern im Universitätsnetz verschickte E-Mail wird von den Relay-Rechnern weitergeleitet, aber keinerlei E-Mail von dritten Rechnern an dritte. (siehe www.sendmail.org/tips/relaying.html)

   ,,Rechner im Universitätsnetz`` sind in diesem Zusammenhang Rechner, die in der Domain uni-hamburg.de beheimatet sind oder die von der Universität mit versorgt werden, d.h. für die auf einem Mail-Server in der Universität entsprechende MX-Records eingetragen sind (z.B. bwf-hh.de oder hitec-hh.de)

   Dies wird von der aktuellen Sendmail-Version 8.9.3 von Haus aus unterstützt und muß lediglich aktiviert werden.

   Für andere verwendete Mail-Server-Software wie z.B. den Eudora Mail Server auf Macs müssen äquivalente Maßnahmen getroffen werden, z.B. die Annahme von ,,Post nur von bekannten Benutzern``.

5. Gleichzeitig muß von den zentralen Mail-Servern die ,,Realtime Blackhole List`` (siehe maps.vix.com/rbl/) genutzt werden, sofern dies bei der verwendeten Mail-Software technisch möglich ist. Damit wird keine E-Mail von Rechnern angenommen, die bekanntlich und nachweislich Spam-Mail unterstützen.

   Dies wird von der aktuellen Sendmail-Version 8.9.3 von Haus aus unterstützt und muß lediglich aktiviert werden.

Migration der vorhandenen zur künftigen Struktur

Der jetzige Wildwuchs der E-Mail-Versorgung kann wie folgt in die künftigen Struktur migriert werden:

1. (kurzfristig)
   Benennung der administrativen und technischen Ansprechpartner und der Mail-Server der Fachbereiche/Institute
2. (kurzfristig)
   Einrichten der korrekten MX-Records für die Versorgung der Rechner der Fachbereiche/Institute mit E-Mails
3. (kurzfristig)
   gleichzeitig sichere Konfiguration der Mail-Server gemäß den obigen Anforderungen
4. (kurzfristig)
   Aufsetzen von Accesslists für eingehende E-Mails am WiN-Router: Abschalten der direkten Mail-Versorgung für Nicht-Mail-Server

   Damit ist erreicht, daß kein Rechner im Universitätsnetz mehr von außen für das Versenden von Spam-Mails mißbraucht werden kann.

5. (mittelfristig)
   Unkonfiguration der Mail-Clients derart, daß ausgehende E-Mail an den zuständigen Mail-Server des Fachbereichs/Instituts/RRZ geschickt wird
6. (mittelfristig)
   Aufsetzen von Accesslists für ausgehende E-Mails am WiN-Router: E-Mail kann nur noch über die Mail-Server versendet werden

E-Mails lesen und schreiben

Wenn wir schon ein allgemeines Absicherungs-/Firewall-Konzept für das Universitätsnetz erwähnten: Das bisher geschriebene bezieht sich nur auf den E-Mail-Transport von Rechner zu Rechner über SMTP.

Natürlich wollen unsere Benutzer ihre E-Mails auch lesen und schreiben, z.T. von außerhalb der Universität.

E-Mails lesen

Um E-Mails von außerhalb des Universitätsnetzes lesen zu können, muß ein Benutzer sich entweder mit geeigneten Programmen wie ssh auf einem Rechner im Universitätsnetzes einloggen oder aber mit einem der Mail-Zugriffs-Protokolle POP3 oder IMAP auf seine Mailbox auf seinem Mail-Server zugreifen. Dazu müssten die vier Ports 110 (POP3), 143 (IMAP), 993 (IMAPS) und 995 (POP3S) am WiN-Router freigeschaltet bleiben, zumindest für die Rechner, auf denen die E-Mails tatsächlich zum Lesen vorgehalten werden. Ein Problem bleibt die Übertragung von Username und Passwort im Klartext bei POP3 und IMAP, die von einem Netzwerksniffer abgelauscht werden können (siehe www.informatik.uni-hamburg.de/RZ/netz/pop.html). Die APOP-Erweiterung des POP3-Protokolls zur abhörsicheren Übertragung ist keine Lösung, solange das darunterliegende POP3-Protokoll weiterhin möglich bleibt.

E-Mails versenden

Von Benutzern geschriebene E-Mails werden üblicherweise von ihrem Rechner aus mit dem Mail-Transfer-Protokoll SMTP auf den jeweiligen Mail-Server im Universitätsnetz übertragen. Dies kann zu Problemen führen: Wenn ein Benutzer z.B. von seinem Internet-Provider oder von der Firma aus, in der er als Student arbeitet, E-Mail an einen Empfänger außerhalb der Universität verschicken will, kann er das nach dem neuen Konzept nicht mehr über die Universitäts-Mail-Server tun, weil dieses Mail-Relaying (E-Mail von Rechnern außerhalb an Rechner außerhalb des Universitätsnetzes) nicht mehr zugelassen wird.

Dies betrifft nicht Mitarbeiter und Studierende, die ihre E-Mail über den allgemeinen Modemzugang bearbeiten, weil die RRZ-Modemzugänge innerhalb des Universitätsnetzes liegen. Betroffen sind aber z.B. Mitarbeiter, die sich auch an einer anderen Universität aufhalten und von dort Ihre E-Mail bearbeiten wollen. Ggfs. müsste man im begründeten Einzelfall ihren Rechnern das Verschicken von E-Mails über die Universitäts-Server erlauben.

Im allgemeinen gilt jedoch: Wer seinen Zugang zum Internet über einen anderen Internet-Provider als die Universität Hamburg nutzt, muß seine E-Mail über den dafür zuständigen Mail-Server verschicken. Ggfs. kann man ja als ,,Reply-To``-Adresse seine E-Mail-Adresse in der Universität Hamburg angeben, damit eventuelle Antworten wieder an die Mailbox in der Universität geschickt werden können.

Einheitliche E-Mail-Adressen

Konzept

Zur sicheren E-Mail-Versorgung gehört nicht nur, daß die E-Mail beim Empfänger, z.B. einem Mitarbeiter der Universität ankommt, sondern auch, daß Außenstehende überhaupt die E-Mail-Adressen der Mitarbeiter erfahren können. Dies setzt neben entsprechenden Directory-Services einen klaren, einheitlichen Aufbau von E-Mail-Adressen voraus.

An der Universität Hamburg werden derzeit noch viele Varianten von Mail-Adressen verwendet. Dieser ,,Wildwuchs`` ist zum einen benutzer-unfreundlich, zum anderen entstehen dabei auch Betriebsprobleme. Daher werden folgende Richtlinien bzw. Empfehlungen zur Vergabe von Mail-Adressen festgelegt:

Mail-Adressen sind grundsätzlich von der Form @. Der Domain-Part kennzeichnet den Mail-Server, an den die Mail zu schicken ist, der Local-Part den Benutzer auf diesem Rechner.

Domain-Part

Der Domain-Name der Universität lautet uni-hamburg.de. Subdomains unterhalb dieser Domain sollen Bezeichnungen für den Fachbereich bzw. ein Institut, eine Einrichtung oder ein Projekt enthalten. Es sollte sich um die offiziellen Namen der Fachbereiche oder um eingängige bzw. bekannte Abkürzungen handeln. Es sollen keine Rechnernamen, Bezeichnungen für Rechnerbereiche oder Orte bzw. Straßen verwendet werden. Ausnahmen sollten besonders begründet sein. Treten mehrere Subdomains auf, sind sie durch Punkt voneinander zu trennen. Eine Subdomain muß auf jeden Fall auftreten; Mail-Adressen der Art @uni-hamburg.de sind nicht erlaubt. Die Namen der Subdomains müssen beim RRZ beantragt und mit dem RRZ abgestimmt werden. Folgende Strukturen sind z.B. möglich:

<pre> <name>@<fachbereich>.uni-hamburg.de <name>@<einrichtung>.uni-hamburg.de <name>@<institut>.<fachbereich>.uni-hamburg.de <name>@<gruppe>.<fachbereich>.uni-hamburg.de </fachbereich></gruppe></name></fachbereich></institut></name></einrichtung></name></fachbereich></name></pre>

Local Part

Der Local-Part der Mail-Adresse benennt die Mailbox des Mail-Empfängers. Letztendlich ist dies immer der Login-Name des Benutzers auf dem jeweiligen Rechner; dieser ist deshalb immer ein zulässiger Local-Part einer Mail-Adresse. Login-Namen sind jedoch aufgrund ihrer Kürze - maximal acht Zeichen - und ihrer eventuellen Zuordnung zu Projekten für Dritte nicht sehr aussagekräftig.

Zur klarer Kennzeichnung wird deshalb dringend empfohlen, sofern irgend möglich im Local-Part der Mail-Adressen sowohl in ausgehender wie auch in eingehender E-Mail den richtigen Namen des Benutzers zu verwenden. Die Abbildung von Benutzernamen auf Login-Namen und umgekehrt erfolgt durch geeignete technische Maßnahmen (Stichworte: Alias-Listen, Userdb-Datenbank; Problem: Wie werden vernünftige Mail-Adressen in News-Artikeln erzeugt?).

Im Local-Part sollte als Name des Benutzers sein Vor- und Nachname verwendet werden, getrennt durch einen Punkt wie die Komponenten des Domain-Parts. Ein zusammengesetzter Vorname (z.B. Hans-Georg) wird weiterhin mit einem Bindestrich geschrieben. In Einrichtungen mit einer geringeren Anzahl von Mail-Nutzern kann auch der Nachname alleine gewählt werden, sofern dieser eindeutig ist. Sollten zwei Benutzer der gleichen Subdomain den gleichen Vor- und Nachnamen haben, wird der Initial des zweiten Vornamens - falls vorhanden - zur Unterscheidung herangezogen. Ziffern und weitere Sonderzeichen sollen nicht verwendet werden. Weitere Problemfälle werden beim Auftreten individuell geklärt.

Ferner können als Local-Part natürlich Bezeichnungen für Verteilerlisten oder Funktionen auftreten. Auch diese sollen sprechende Namen oder einschlägige Abkürzungen sein, z.B. fbr, postmaster, webmaster, ftpmaint, news ...

Eine Mail-Adresse sollte künftig z. B. wie folgt aussehen:

henken@rrz.uni-hamburg.de  oder
gerrit.henken@rrz.uni-hamburg.de  oder
gerrit.henken@netgroup.rrz.uni-hamburg.de

Von der Verwendung solcher Adressen wird abgeraten:

henken@uni-hamburg.de (kein Subdomain)
rz7x012@rrz.uni-hamburg.de (Login-Name)
1henken@informatik.uni-hamburg.de (Login-Name)
ghenken@rrz.uni-hamburg.de (unverständliche Zusammensetzung)
henkeng@rrz.uni-hamburg.de (desgl.)
g-henken@rrz.uni-hamburg.de (desgl. und falscher Trenner)
gerrit_henken@rrz.uni-hamburg.de (falscher Trenner)
gerry@rrz.uni-hamburg.de (Phantasiename)
rrzinfo@rzaix52.rrz.uni-hamburg.de (Rechner im Domain-Part)
rrzintern@domo.rrz.uni-hamburg.de (Rechner im Domain-Part)
henken@nw01.rrz.uni-hamburg.de (Rechner im Domain-Part)
henken@cip.chemie.uni-hamburg.de (Rechnerbereich im Domain-Part)

Migration

Eine Umstellung alter dem Konzept nicht entsprechender Mail-Adressen auf das neue verabschiedete Schema soll ,,sanft`` erfolgen. Dies bedeutet, daß bei einer Neuvergabe von Mail-Adressen diese dem verabschiedeten Konzept entsprechen sollen, ,,alte`` Adressen weiterhin in einer längeren Übergangsphase benutzt werden können und eine Änderung nur nach Absprache stattfinden wird.

Autor: , Stand: 13.05.2011 19:31 Uhr