Sie befinden sich hier: Themen IT-Grundschutz-Kataloge. Inhalt. Dokumententitel: M 5.56 Sicherer Betrieb eines Mailservers - IT-Grundschutz-Kataloge - Stand 2006
direkt zu der Navigation Servicebereich. direkt zu der Hauptnavigation. direkt zur Themennavigation. direkt zum Seiteninhalt.

M 5.56 Sicherer Betrieb eines Mailservers

Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement

Verantwortlich für Umsetzung: Administrator

Der sichere Betrieb eines Mailservers setzt voraus, dass sowohl die lokale Kommunikation als auch die Kommunikation auf Seiten des öffentlichen Netzes abgesichert wird. Der Mailserver nimmt von anderen Mailservern E-Mails entgegen und leitet sie an die angeschlossenen Benutzer oder Mailserver weiter. Weiterhin reicht der Mailserver die gesendeten E-Mails lokaler Benutzer an externe Mailserver weiter. Der Mailserver muss hierbei sicherstellen, dass lokale E-Mails der angeschlossenen Benutzer nur intern weitergeleitet werden und nicht in das öffentliche Netz gelangen können.

Ein Mailserver speichert die E-Mail bis zur Weitergabe zwischen. Viele Internet-Provider und Administratoren archivieren zusätzlich die ein- und ausgehenden E-Mails. Damit Unbefugte nicht über den Mailserver auf Nachrichteninhalte zugreifen können, muss der Mailserver gegen unbefugten Zugriff gesichert sein. Dafür sollte er gesichert (in einem Serverraum oder Serverschrank) aufgestellt sein. Für den ordnungsgemäßen Betrieb sind ein Administrator und Stellvertreter zu benennen und zum Betrieb des Mailservers und dem zugrunde liegenden Betriebssystems zu schulen. Es muss ein Postmaster-Account eingerichtet werden, an den alle unzustellbaren E-Mails und alle Fehlermeldungen weitergeleitet werden (siehe auch M 2.120 Einrichtung einer Poststelle).

Auf die Mailboxen der lokal angeschlossenen Benutzer dürfen nur diese Zugriff haben. Auf die Bereiche, in denen E-Mails nur temporär für die Weiterleitung zwischengespeichert werden (z. B. Spooldateien), ist der Zugriff auch für die lokalen Benutzer zu unterbinden.

Es muss regelmäßig kontrolliert werden, ob die Verbindung mit den benachbarten Mailservern, insbesondere dem Mailserver des Mailproviders, noch stabil ist. Es muss regelmäßig überprüft werden, ob der für die Zwischenspeicherung der Mail zur Verfügung stehende Plattenplatz noch ausreicht, da ansonsten kein weiterer Nachrichtenaustausch möglich ist.

Umfang und Inhalt der Protokollierung der Aktivitäten des Mailservers sind festzulegen. Die Protokolldaten müssen regelmäßig ausgewertet werden, vor allem um festzustellen, ob Angriffe auf den Mailserver erfolgt sind und welche Auswirkungen diese nach sich gezogen haben.

Von der Verfügbarkeit des Mailservers sollten keine weiteren Dienste abhängig sein, beispielweise sollte der Mailserver nicht gleichzeitig auch als Fileserver dienen. Es sollte jederzeit kurzfristig möglich sein, ihn abzuschalten, z. B. bei Denial-of-Service-Angriffen oder bei Verdacht auf Manipulationen (siehe auch M 4.97 Ein Dienst pro Server).

Die Benutzernamen auf dem Mailserver sollten nicht aus den E-Mailadressen unmittelbar ableitbar sein, um mögliche Angriffe auf Benutzer-Accounts zu erschweren.

Der Status einer E-Mail kann dem Sender mit einer Delivery Status Notification übermittelt werden. Grundsätzlich sind Non Delivery Notifications RFC-konform und sinnvoll. So können beispielsweise

Schreibfehler bei der Empfängeradresse bemerkt werden. Andererseits können Delivery Status Notifications zur Überlastung von E-Mail-Servern beitragen, wenn E-Mails in Massen an nicht existierende Empfänger versendet werden, was beispielsweise durch Spam oder Schadsoftware ausgelöst werden kann.

Um beiden Punkten gerecht zu werden, kann folgendes Vorgehen ratsam sein: Non Delivery Notifications werden grundsätzlich erlaubt. Gleichzeitig wird die Auslastung des eigenen E-Mail-Servers beobachtet. Steigt die Anzahl der Non Delivery Notifications über einen zu definierenden Schwellwert an, wird der Versand von Delivery Status Notifications deaktiviert, da der Verdacht besteht, dass ein neuer Spam- oder Schadsoftware-Vorfall aufgetreten ist.

Naturgemäß muss der Mailserver aus dem Internet erreichbar sein. Daher sollte der Server durch entsprechende Maßnahmen auch auf Netzebene abgesichert werden. Dies kann beispielsweise dadurch geschehen, dass von einer vorgeschalteten Firewall Verbindungen von außen nur zu den entsprechenden Ports zugelassen werden. Noch besser ist es, den Mailserver in einer Demilitarisierten Zone (DMZ) anzusiedeln und auch die Verbindungen zum internen Netz auf die notwendigen Protokolle und Dienste zu beschränken.

Es ist festzulegen, welche Protokolle und Dienste am Mailserver erlaubt sind. Beispielsweise ist es meist nötig, SMTP (TCP-Port 25) nach außen und innen zuzulassen. Hingegen sollten die Protokolle POP3 oder IMAP (TCP Ports 110 bzw. 143, je nachdem, auf welche Art und Weise Mails vom Server abgerufen werden) nur für Zugriffe aus dem internen Netz zugelassen werden. Sowohl für POP3 als auch für IMAP existieren Varianten, bei denen Anmeldung und Datenübertragung durch SSL gesichert werden. Falls die eingesetzte Software diese Varianten unterstützt, sollten sie nach Möglichkeit auch eingesetzt werden.

E-Mails sind eines der verbreitesten Medien, um Computer-Viren zu verbreiten. Um sich hiergegen abzusichern, gibt es verschiedene Strategien (siehe auch M 2.156 Auswahl einer geeigneten Computer-Virenschutz-Strategie). Die Erfahrung hat gezeigt, dass E-Mails sowohl an der Firewall oder auf dem Mailserver als auch auf jedem Client-Rechner auf Computer-Viren oder -Würmer und andere schädliche Inhalte wie aktive Inhalte (z. B. eingebetteten JavaScript-Code) überprüft werden sollten (siehe M 5.109 Einsatz eines E-Mail-Scanners auf dem Mailserver). Alle eingesetzten Viren-Schutzprogramme müssen regelmäßig aktualisiert werden.

Über Filterregeln kann der Empfang oder die Weiterleitung von E-Mails für bestimmte E-Mailadressen gesperrt werden. Dies kann beispielsweise sinnvoll sein, um sich vor Spam-Mail zu schützen. Auch über die Filterung anderer Header-Einträge kann versucht werden, Spam auszugrenzen. Hierbei muss allerdings mit Bedacht vorgegangen werden, damit der Filterung keine erwünschten E-Mails zum Opfer fallen. Daher sollten entsprechende Filterregeln sehr genau definiert werden, indem beispielsweise aus jeder Spam-Mail eine neue dedizierte Filterregel abgeleitet wird. Entsprechende Filterlisten sind im Internet verfügbar bzw. können von verschiedenen Herstellern der Kommunikationssoftware bezogen werden.

Durch entsprechende Filterregeln können Datei-Typen (z. B. *.VBS, *.WSH, *.BAT, *.EXE), die im täglichen Arbeitsablauf nicht als Anhänge von E-Mails vorkommen dürfen (siehe auch M 4.199 Vermeidung gefährlicher Dateiformate), zentral blockiert werden.

Das Internet-Namensschema DNS sieht es vor, mittels eines so genannten MX-Eintrags einen bestimmten Server als Mailexchanger zu kennzeichnen. Normalerweise sollten dann E-Mails zwischen Rechnern verschiedener Domains nur über den den jeweils "zuständigen" Mailexchanger weiter geleitet werden. Das Weiterleiten von E-Mails zwischen verschiedenen Domains bezeichnet man als Relaying. Ein Mailserver sollte davor geschützt werden, als Spam-Relay verwendet zu werden. Dafür sollte der Mailserver so konfiguriert sein, dass er E-Mails nur für die eigene Organisation entgegennimmt und nur E-Mails verschickt, die von Mitarbeitern der Organisation stammen. Der Mailserver sollte eingehende E-Mails nur dann annehmen, wenn entweder die IP-Adresse des absendenden Mailservers in einem vom Administrator explizit zugelassenen IP-Netz liegt oder wenn er selbst für die Empfängeradresse als Mail-Exchanger fungiert. Alle anderen E-Mails sollten mit einer Fehlermeldung abgewiesen werden.

Berechtigte Benutzer können trotz dieser Maßnahmen weiterhin E-Mails an beliebige Empfänger versenden, ebenso können sie E-Mails von beliebigen Absendern empfangen. Durch die oben beschriebene Filterung eingehender E-Mails wird jedoch verhindert, dass der Mailserver von externen Nutzern als Spam-Relay missbraucht werden kann.

Sollten versehentlich IP-Netze, aus denen E-Mails angenommen werden sollen, nicht in obiger Liste stehen, muss der Administrator des Mailservers davon in Kenntnis gesetzt werden, damit er diese nachtragen kann.

Wenn eine Organisation keinen eigenen Mailserver betreibt, sondern über einen oder mehrere Mail-Clients direkt auf den Mailserver eines Providers zugreift, sollte mit dem Provider abgeklärt werden, welche Regelungen dort gelten und welche Sicherheitsmaßnahmen ergriffen worden sind (siehe M 2.123 Auswahl eines Mailproviders).