Relaykonzept - Sicherer Betrieb von Exchange als Maildrehscheibe

Die ganze Welt spricht SMTP. Mit der Welt meine ich aber nun nicht nur das Internet sondern mittlerweile können auch Drucker, Switches, uSV, Bandlaufwerke, NAS-Speicher, Scanner und viele andere Netzwerkgeräte per SMTP eine Meldung versenden. Auch WebServer, Batchdateien oder andere Programme senden wie selbstverständlich heute schon Mails. Während in großen Umgebungen das klassische Monitoring bevorzugt über SYSLOG und SNMP erfolgt, so ist die Meldung per Mail gerate in kleinen Umgebungen eine nicht zu unterschätzende Funktion. Wie sonst könnte ein Drucker fehlenden Toner melden, ein Scanner die Dokumente an das Postfach zustellen oder ein Storage-System einen Festplattendefekt mitteilen ?

Entsprechend ist es erforderlich, dass es auch einen Mailserver gibt, welcher möglichst hoch verfügbar diese Meldungen annimmt und weiter leitet. Die meisten SMTP-Sender haben nämlich weder die Funktion, das Ziel per MX-Record aufzulösen noch verwalten Sie eine eigene Warteschlange um im Fehlerfall die Übermittlung zu wiederholen oder einen alternativen Server zu verwenden. Die Systeme sind eher einfach gestrickt. Aber auch Endanwender, z.B. Smartphones oder so genannte "Legacy Clients" wie Thunderbird, Evolution etc., die per POP3/IMAP4 ihre Mails abholen, senden diese in der Regel per SMTP auch wieder hinaus.

Risikobetrachtung

Nun ist ein Mailversand natürlich auch mit Risiken verbunden. Nahezu alle Mailserver sind mittlerweile mit Virenschutz und mehr oder minder pfiffigen Spamschutzfiltern ausgestattet. Diese an sich guten Komponenten können bei falscher Konfiguration auch diese internen Sender behindern. Umgekehrt besteht auch ein Risiko für den Betreiber des Mailservers, wenn Sie Mails aus weniger vertrauenswürdigen Quellen mit ihrem Server weiter versenden. Wer im Extremfall ein offenes Relay (Relaymissbrauch) betreibt, muss sich nicht wundern, wenn er bald einen Großteil der Ziele im Internet selbst nicht mehr erreicht. Aber selbst wenn Sie alles abgesichert haben, kann es ja dennoch sein, dass ein legitimierter Absender ihr System missbraucht. Dann kommt die Protokollierung ins Spiel, anhand dieser Sie hoffentlich den Absender Dingfest machen können. Wenn sie keine Anmeldung erfordern, dann sollten Sie zumindest die IP-Adresse des Quellsystems ermitteln können und vieleicht mit ARP-Listen und MAC-Adressen den Port und damit den Raum der Quelle in ihrem unternehmen. (Wohl dem, der die Switches per 802.1x abgesichert hat.

Schutz, Filter und Identifizierung sind also zwingende Voraussetzungen.

Wer bist du ?

Viele Administratoren machen Sich aber gar keine Gedanken, welche verschiedene Kombinationen es heute geben kann. Erst wen Sie all diese Optionen und ihre individuellen Vorteile und Einschränkungen können, können Sie für die jeweilige Aufgabestellung die passende Lösung anbieten. Es gibt nämlich weit mehr als nur "Relay oder nicht".

Zum einen müssen Sie die Identifizierung der Absender unterscheiden. Derer gibt es drei:

Benannte Benutzer, die sich per SMTP am System mit einem gültigen Benutzer und Kennwort anmelden. Dies sind die "angenehmsten" Absender, da Sie in der Regel auf ein Funktionskonto oder eine Person zurückgeführt werden können und damit die Verantwortlichkeit und Zuständigkeit am ehesten klar definiert sind. Anwender, die ihre Mails per OWA, ActiveSync oder Outlook versenden, fallen hier drunter. Allerdings müssen Sie natürlich auch bei anderen Protokollen (IMAP4, SMTP, EWS) sicherstellen, dass die Anmeldedaten auch geheim bleiben, d.h. SSL oder zumindest sichere Kennworte sollten Sie hier fordern.

Eine etwas schwächere aber doch geeignete Möglichkeit ist die Identifizierung anhand der IP-Adresse. Dies ist natürlich für offene Netzwerke, die per DHCP mit Adressen versorgt werden, nicht ausreichend. Wenn Sie aber z.B. das Subnetz für Server oder Drucker, in denen sich keine Clients befinden können, für bestimmte Funktionen freischalten, dann ist das immer noch besser als ein offenes Relay für alle zu betreiben

Zuletzt müssen Sie sich natürlich noch mit SMTP-Sendern beschäftigen, die anonym ihre Mails zustellen wollen. Dies dürfte sogar die Mehrzahl sein, da das gesamte Internet aktuell noch "anonym" sendet. Spamfilter nutzen daher neben der Inhaltsanalyse auch IP-Blocklisten und andere Listen zur besseren Qualifizierung von Absendern.

Wohin willst du ?

Neben den Quellen gibt es natürlich auch verschiedene Aufgabenstellungen, die mit unterschiedlichen Lösungen in Exchange umgesetzt werden können.

Die einfachste Aufgabenstellung ist sicher Empfang von Mails an Exchange selbst. Jede Mail, die Exchange zu Routen hat, wird bezüglich des Empfängers gegen die globale Adressliste geprüft und wenn es einen passenden Empfänger gibt, lokal zugestellt.

Allerdings sollten sie wissen, dass Exchange per Default nicht mal Mails an interne Empfänger von anonymen Absendern annimmt.

Eine erste Anforderung bezüglich einer Weiterleitung an Exchange kann sein, dass nur bestimmte externe Zieladressen z.B. ohne Authentifizierung erreichbar sein sollen. Solch eine Aufgabenstellung können Sie z.B.: mit einem Mailkontakt in Exchange lösen. Dieser kann aber muss nicht im Adressbuch sichtbar sein aber erlaubt, dass jeder, der an Exchange etwas senden kann, eine Mail über den Kontakt als Hilfsmittel nach extern an genau eine Zieladresse senden kann.

Dies ist z.B.: eine Lösung, wenn Drucker ihren Tonerstand per SMTP an einen Dienstleister melden müssen und Sie sich beim Drucker die Pflege von Anmeldedaten oder die Qualifikation über die IP-Adresse (802.1x, VLAN etc.) ersparen wollen.

Nebenbei können Sie hier natürlich wunderbar auf dem Server die Zieladresse auch nachträglich verändern, ohne an den Clients etwas verändern zu müssen, z.B.: beim Wechsel des Anbieters.

Eine zweite legitime Relayanforderung ist die Weitergabe an alle Empfänger einer bestimmten SMTP-Domain. Im Gegensatz zu den Kontakten können so alle Empfönger erreicht werden, solange die Zieldomain in der "erlaubt"-Liste ist.

Dies kann z.B. nützlich sein, wenn Sie ihren Exchange Server als "Provider" für eine nachgelagerte Domain eines Kunden betreiben oder sie mit Partnerfirmen vertrauensvoll zusammenarbeiten wollen. Technisch wird dies über entsprechende Send-Connectoren für diese Domain und "Accepted Domain" realisiert, für die sie dann nicht autoritativ sind.

Das offene Relay ist sicher keine Standardeinstellung für alle. Aber ob ein System ein offenes Relay ist, hängt auch davon ab, wie sie die Clients identifizieren und authentifizieren.

Wer mit wem und über welche Konfiguration

Aus den beiden Tabellen der Absenderidentifikation und der gewünschten Ziele lässt sich natürlich eine Matrix erstellen:

 

Das geht bei Exchange schon per  Default

Jeder angemeldete Benutzer darf von Hause aus schon an Kontakte senden, die dann nach extern weiter leiten

Jeder angemeldete Benutzer darf von Hause aus schon externe Domains senden, auch wenn diese auch als nicht autoritative AcceptedDomain konfiguriert sind.

Jeder angemeldete Benutzer darf von Hause aus ins Internet senden.

Ein einfacher Weg, bestimmte ausgewählt Systeme zuzulassen, wenn diese keine Authentifizierung unterstützen oder dies zu aufwändig wäre.

Dies ist der bevorzugte Weg, wenn die Clients sich nicht anmelden können aber nur bestimmte Ziele erreichen müssen.

Dieser Fall öffnet Türen für bestimmte Zieldomains. Ein Schadprogramm könnte also eine ganze Firma "belästigen". Oft ist dies aber für Partneranbindungen in Prozessketten erforderlich.

Diese Konfiguration macht aus ihrem Exchange ein partielles offenes Relay, da die angegeben IP-Adressen überall hin senden können. In so einem Fall ist es essentiell, die Liste der IP-Adressen sauber zu pflegen.

Intern könnte dies noch toleriert werden, aber aus dem Internet sollten Sie ernsthaft über Spamschutz nachdenken

Sollte die IP-Adresse des Clients nicht festzulegen sein, dann kann diese Option genutzt werden. Das Risiko besteht dann nur darin, dass das der eine Zielempfänger gestört wird.

Sollte die IP-Adresse des Clients nicht festzulegen sein, dann kann diese Option genutzt werden. Das Risiko besteht dann nur darin, dass das die Zieldomäne gestört wird.

Diese Konstallation sollten Sie nie umsetzen, da Sie damit ihr System zu einem offenen Relay machen.

Schon anhand der Farben ist gut zu sehen, dass sie mit einem "authentifizierten Benutzer" in der Regel sehr gut fahren und bis zu einem gewissen Grade auch die Qualifizierung über die Quell-IP-Adresse durchaus geeignet ist. Beim Umgang mit nicht weiter identifizierten Clients sollten Sie aber erhebliche  Vorsicht walten lassen und lieber zweimal fragen, ob dieser SMTP-Sender wirklich das komplette Internet erreichen muss und ob er sich dabei wirklich nicht in irgend einer weise authentifizieren kann.

Sicherheit gibt es nicht ohne einen gewissen Aufwand aber ohne die Einhaltung bestimmter Schutzmaßnahmen setzen Sie ihr Gesamtsystem einen nicht zu unterschätzenden Risiko aus. Zumal die Funktion eines Mailsystems immer mehr as "business critical" angesehen wird.

Weitere Links