Bundesamt für Sicherheit in der Informationstechnik

M 5.56 Sicherer Betrieb eines Mailservers

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

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 Administratoren und Stellvertreter zu benennen und zum Betrieb des Mailservers und dem zugrunde liegenden Betriebssystems zu schulen. Es muss ein Postmaster- und Abuse-Account eingerichtet werden (siehe auch M 2.456 Sichere Administration von Groupware-Systemen ).

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.

MX-Einträge und Relaying

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 jeweils "zuständigen" Mailexchanger weiter geleitet werden. Das Weiterleiten von E-Mails zwischen verschiedenen Domains wird als Relaying bezeichnet. 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.

Non Delivery Notifications

Grundsätzlich sind Non Delivery Notifications RFC -konform und sinnvoll, um bei temporären Fehlern an den Mailsystemen die Absender von E-Mails zu informieren, dass die E-Mails nicht zugestellt werden konnten. Die Erzeugung von Non Delivery Notifications muss sich aber auf den Fehlerfall beschränken und muss weitestgehend minimiert werden.

So ist es unbedingt zu vermeiden, dass Non Delivery Notifications aufgrund falscher Empfängeradressen erzeugt werden. Vielmehr ist dafür zu sorgen, dass E-Mails, für die die Institution nicht zuständig ist, gar nicht erst angenommen werden. Dabei ist zwingend darauf zu achten, dass ein Dienstleister, der im Vorfeld die E-Mails einer Institution überprüft, auch weiß, welche E-Mails angenommen werden müssen und welche nicht, so dass dieser nicht die Non Delivery Notifications erzeugen muss, falls die E-Mails nicht zustellbar sind. Wird dies nicht beachtet, können Spammer den Versand von Non Delivery Notifications ausnutzen, um Dritte im Namen der Institution mit Spam zu beschicken.

Um die Risiken, die durch Non Delivery Notifications entstehen, zu vermeiden, kann folgendes Vorgehen ratsam sein: Non Delivery Notifications werden grundsätzlich erlaubt. Gleichzeitig werden alle E-Mail übertragenden Systeme der Institution und die E-Mail-Systeme vorgelagerter Dienstleister (bis zu dem Server auf den der MX-Record zeigt) aufeinander abgestimmt, so dass Non Delivery Notifications nur noch in einem Fehlerfall erzeugt werden. Es dürfen unter anderem keine Non Delivery Notifications erzeugt werden, weil ein Empfänger nicht existiert, weil ein Mailsystem eine E-Mail zu groß befindet, obwohl ein vorgelagerter Mailserver diese bereits angenommen hat, oder weil ein Postfach voll ist.

Der Administrator sollte sich eine Alarmierung einrichten, die ihm mitteilt, dass ein System Non Delivery Notifications erzeugt. Er sollte dann prüfen, warum dies geschieht und den Fehler umgehend beseitigen.

Grundsatz: Für eine Domain muss von der ersten Annahme durch die IP-Adresse des MX-Records bis zum Postfach des Benutzers sichergestellt werden, dass die E-Mails transportiert werden und nicht durch widersprüchliche Konfiguration der beteiligten Mailrelays zu Non Delivery Notifications führen.

Die Problematik der Non Delivery Notifications weist auf ein grundsätzliches Problem der E-Mail-Kommunikation hin. Der Absender einer E-Mail ist frei wählbar und kann gefälscht werden. Schickt jemand eine E-Mail mit gefälschtem Absender an ein automatisch antwortendes System, sendet dieses die Nachrichten an die gefälschten Absender-Adressen. Dies kann ein Angreifer nutzen, um einen Dritten im Namen der Institution anzugreifen und mit E-Mails zu fluten. Für dieses Angriffsszenario eignen sich nahezu alle Systeme, die E-Mails automatisch beantworten. Auch Abwesenheitsnachrichten, Eingangsbestätigungen und Weiterleitungen sind aus diesem Grund nur mit äußerster Vorsicht zu betreiben.

Folgende Maßnahmen müssen zum Schutz ergriffen werden:

  • Schon als Spam klassifizierte E-Mails dürfen nicht automatisch beantwortet oder weitergeleitet werden.
  • Die Absenderadresse der Antwort bzw. Weiterleitung muss eine Adresse aus dem Namensraum der Institution sein. Der Absender der eingehenden E-Mail darf nicht verwendet werden.
  • Es muss verhindert werden, dass ein bestimmtes Ziel (Zieladresse oder Zieldomain) unkontrolliert mit einer großen Anzahl von E-Mails beschickt wird. Bei Abwesenheitsassistenten kann dies realisiert werden, indem einen Absender nur einmalig eine Abwesenheitsbenachrichtigung geschickt wird.

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 verbreitetsten Medien, um Spam und Schadsoftware zu verbreiten. Um sich hiergegen abzusichern, gibt es verschiedene Strategien (siehe auch M 2.154 Erstellung eines Sicherheitskonzeptes gegen Schadprogramme ). Die Erfahrung hat gezeigt, dass E-Mails sowohl an der Firewall oder auf dem Mailserver als auch auf jedem Client-Rechner ü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.

Wenn eine Institution 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 Groupware- oder Mailproviders ).

Prüffragen:

  • Ist der Mailserver gegen unbefugten Zugriff gesichert aufgestellt?

  • Gibt es einen für die Verwaltung des Mailservers entsprechend geschulten Administrator und Stellvertreter?

  • Haben nur die lokal angeschlossenen Benutzer Zugriff auf ihre Mailboxen?

  • Ist der Zugriff für die lokalen Benutzer auf die Bereiche, in denen E-Mails nur temporär für die Weiterleitung zwischengespeichert werden ( z. B. Spooldateien), unterbunden?

  • Werden die Aktivitäten auf dem Mailserver regelmäßig protokolliert und diese Protokollierungen regelmäßig ausgewertet?

  • Wird regelmäßig kontrolliert, ob die Verbindung mit den benachbarten Mailservern, insbesondere dem Mailserver des Mailproviders, noch stabil ist, und ob der zur Verfügung stehende Plattenplatz noch ausreicht?

  • Gibt es eine Richtlinie, welche Protokolle und Dienste am Mailserver erlaubt sind?

  • Ist der Mailserver derart konfiguriert, dass er nicht als Spam Relay missbraucht werden kann?

Stand: 13. EL Stand 2013