Exchange Edge Rolle

Die Exchange Edge Rolle ist als Relay-System zwischen einem internen Mailsystem und dem Internet angelegt. Sie filtert z.B. Ungültige Empfänger, kann Adressen umschreiben, und in Grenzen auch Spam blockieren.

Edge und HMC 4.5
Microsoft beschreibt im Paket HMC 4.5 (Anleitung wie man Exchange 2007 als Hostinglösung installiert) genau, warum hier ein gut konfigurierter Hub/Transport am Internet die bessere Lösung ist. Prüfen Sie daher genau, ob Sie überhaupt einen Edge-Server benötigen.

Die Exchange Edge Services geisterten schon einige Zeit durch die Medien und wurden erst als eigenständiges Produkt angekündigt, später dann als Addon für bestehende Exchange Systeme gehandelt (vielleicht wurde daraus dann der Intelligent Message Filter). Es wurden sicher auch einige Nebelkerzen geworfen. Aber mit Exchange 2007 wurde es amtlich, dass diese Rolle Bestandteil des Produkts ist.

Ursprünglich wurde es als "Sendmail Killer" bezeichnet und zielte darauf ab, dass Exchange 2000/2003 nicht gerade optimal dafür eingestellt war, als Mailrouter für große unternehmen zu dienen. Exchange kann zwar wunderbar Nachrichten in Datenbank speichern und den Anwendern bereit stellen, aber für das Routing von großen Nachrichtenmengen zwischen vielen Systemen, wie dies bei Dienstleistern oft benötigt wird, war Exchange nicht optimal aufgestellt. So ist es nur sehr aufwändig  möglich, Nachrichten beim Transport umzuschreiben oder den SMTP-Stack generell zu erweitern. Wenn Sie hier den Windows SMTP-Server (und das ist ja letztlich auch der Exchange SMTP-Dienst) mit Funktionen von PostFix, SendMail und anderen Vergleichen, dann fehlen hier schon einige Funktionen.

Mit Exchange 2007 wird nun alles anders, da sowohl für die Edge-Rolle als auch für die Hub/Brdigehead-Rolle der SMTP-Stack komplett neu entwickelt wurde.

Der Einsatz der Edge-Rolle ist nicht zwingend erforderlich. Sie können Exchange natürlich auch ohne Edge-Rolle betreiben.

Der Einsatz von Edge ist nicht von Exchange 2007 intern abhängig. Sie können Edge auch vor beliebigen anderen Servern installieren. Sinnvoll erscheint diese aber nicht, da Sie zum sinnvollen Einsatz natürlich die Exchange 2007 Enterprise CALs für alle Benutzer benötigen, selbst wenn diese kein Exchange Postfach haben. Wenn Sie nur eine Standardversion und CALs einsetzen, dann können Sie auch nicht die häufigen Antispam Updates nutzen.
Insofern reicht auch eine Standard Lizenz. Dann aber sind Drittprodukte oft di bessere Wahl.

Um auf einem HUB-Transport die Antispam Funktionen zu aktivieren, müssen Sie folgende Befehlszeile aufrufen

install-antispamagents.ps1

Siehe auch E2K7:Antispam

Mit Exchange 2010 "Hosting" ist sogar die Edge-Rolle nicht mehr unterstützt.

Mit Exchange 2013 wurde die Edge-Rolle wieder belegt. Diesmal auch als Gateway zu Office 365. Aber auch andere Systeme können dies bereitstellen.

Die Funktion der Edge-Rolle ist die Verbindung einer Exchange Organisation mit dem Internet. Die Edge-Rolle schützt dabei die Server mit der Hub/Transport-Rolle gesondert ab und übernimmt erste Filterfunktionen bezüglich Spam und Viren. Um dieser Rolle gerecht zu werden, gelten für den Server mit der Edge-Rolle besondere Bedingungen.

Edge Basisfunktion

Die Rolle des Exchange Edge Servers ist die Vermittlung von Mails zwischen der internen Exchange Organisation und dem Internet. Edge kann aber auch als Brücke zu Office 365 (Hybrid Mode) oder intern zu anderen Mailsystemen genutzt werden. Die Edge-Rolle ist die Informationsdrehscheibe mit ein paar Funktionen zur Empfängerfilterung, Spamschutz, Virenschutz und Adress-Rewriting.

Die Server stehen dazu in der Regel in einer eigenen Zone des Netzwerkes mit Verbindung nach Extern und Intern und sind nicht Mitglied des Exchange Forest. Damit der Edge-Server aber weiß, welche Empfänger gültig sind, bekommt er vom internen Exchange Server über einen LDAP-Port seine Konfiguration und eine Liste der gültigen Mailadressen als Hashwerte synchronisiert.

Edge und Firewall

Eine Firewall im Netzwerk schützt die verschiedenen Systeme gegen Angriffe aber auch gegen den Missbrauch eines Systems gegen andere Systeme. Sie arbeitet in beide Richtungen und entsprechend müssen für die Funktion des Edge-Servers bestimmte "Port" geöffnet werden.

Gerade im Bezug auf SMTP können Firewalls oft noch zusätzliche Schutzmechanismen auf Protokoll-Ebene durchführen, z.B. das unterbinden von bestimmten SMTP-Verben. möglich ist das unterbunden einer Authentifizierung oder das Scannen auf Schadcode während der Übertragung. Hier ist zu prüfen, wie solche Funktionen den Betrieb beeinträchtigen können. Folgende Verbindungen sind für einen Edge-Server relevant.

  • DNS-Auflösung
    Der Edge Server muss natürlich zum Versand an System im Internet per DNS die MX-Records auflösen können. Dies erfolgt in der Regel durch die Konfiguration eigener DNS-Server für die externe Namensauflösung, so dass die DNS-Konfiguration des Betriebssystem nach intern zeigen kann
  • Mailflow
    Für die Übertragung von Mails wird Port 25 in jede Richtung benötigt. Nach Intern ist eine Beschränkung auf die internen HubTransport-Server ratsam.
  • EdgeSync
    Der Edge-Server bekommt seine Konfiguration von der internen Exchange Organisation. Nach dem Austausch einer XML-Datei kann der interne Hub-Transport die erforderlichen Daten über einen TCP-Port in den LDAP-Konfigurationsspeicher des Edge Server aktualisieren.
  • System Management
    Auch wenn die Server in der DMZ stehen und nicht Mitglied der Domäne sind, gelten für sie die gleichen Anforderungen bezüglich Backup, Monitoring, Virenscanner und anderer Dienste. Die Ports müssen entsprechend geöffnet werden.
  • ICMP
    Auch wenn viele Firewall-Administratoren die öffnung von "ICMP Echo" kritisch sehen, so ist es doch eine einfache und billige Möglichkeit die Erreichbarkeit eines Hosts zu prüfen. Dies deckt den Host als auch IP-Routen und Zwischenstationen ab.

Diese Ports sind eine allgemeine Übersicht. Je nach Einsatzzweck können weitere Ports erforderlich sein oder die Regeln enger gefasst werden. Wer z.B. den Edge nur zur Office 365 Hybrid-Anbindung nutze, kann das Internet aussperren. Die Mails müssen dann aber z.B. über die Cloud oder einen anderen Antispam-Dienstleister geleitet werden.

Edge Vorarbeiten

Die Edge Rolle selbst ist eigentlich "mal schnell" installiert, wenn denn die Vorarbeiten erledigt sind. Hier eine vereinfachte Checkliste.

Aktion Status

DNS Server und Einträge

Um die neuen Edge Server „finden“ zu können, müssen diese intern und aus dem Internet per DNS erreichbar sein. Ein Name ist auch für die Zertifikate erforderlich.

  • Externer DNS (Internet)
    jeder Edge hat eine eigene public IP gemappt die per DNS auflösbar sein sollte. Einmal mit dem FQDN des Servers und einem Pool für DNS-RR  (es sei denn es gibt einen Loadbalancer). z.B.:

edge1.msxfaq.de  A x.x.x.1
edge2.msxfaq.de  A x.x.x.2
edgepool.msxfaq.de  A x.x.x.1
edgepool.msxfaq.de  A x.x.x.2

  • Interner DNS
    Auch von intern sind die Server mit einem FQDN zu erreichen, Damit die Exchange Hub-Server den „NextHop“ mit einem Namen und per TLS erreichen können. Ideal ist der Einsatz von Split-DNS und der gleichen Namen wie extern mit Ziel auf die internen (privaten) IP-Adressen Alternativ kann man auch mit HOSTS-Einträgen arbeiten
  • Edge-DNS
    Die Edge Server müssen per DNS eine Namensauflösung durchführen können, um sowohl die externen „Gegenstellen“ als auch die internen Hub/Server finden zu können.

 

Zertifikate

Die Kommunikation zwischen internen Servern und Edge als auch Edge zum Internet wird per TLS gesichert. Entsprechend sind Zertifikate für die Server erforderlich. Denkbar sind öffentliche Zertifikate, Zertifikate einer privaten PKI oder SelfSigned-Zertifikate. Allerdings sollten bei CA-Zertifikaten die Nutzer entsprechend die CRLs erreichen können.

Denkbar ist ein Start mit Zertifikaten einer internen PKI.. Ein Ansprechpartner zur Ausstellung der zwei Computerzertifikate muss erreichbar sein.

 

IP-Adressen

Damit die Edge Server auf dem Internet per SMTP angesprochen werden können, müssen Sie über öffentliche Adressen über den Port 25/TCP erreichbar sein. Beim Einsatz von zwei Edge Server ohne Loadbalancer sind daher zwei öffentliche IP-Adressen zuzuweisen, die auf die Edge-Server umgesetzt werden.

 

Firewall

Die beiden Edge Server in der DMZ kommunizieren in verschiedene Richtungen. Die Firewall muss die entsprechenden Ports zulassen und die Pakete routen bzw. per NAT umsetzen. Sobald Sie die IP-Adressen definiert haben, können Sie problemlos die Regeln schon anlegen lassen.

 

Administrative Berechtigungen

Für die Einrichtung eines Edge Servers wird auf dem Edge eine Konfigurationsdatei exportiert, die auf dem Exchange Hub-Transport importiert werden muss. Dazu sind auf der Exchange Organisation entsprechende Berechtigungen erforderlich.

Wenn Sie den Edge Server nutzen, um damit eine Verbindung zu Office 365 einzurichten, dann benötigen Sie natürlich auch die Office 365 Berechtigungen zur Pflege der Connectoren in der Cloud. Natürlich muss dieser Server dann auch "in die Cloud" zugreifen können, also per HTTPS die Office 365-Zugangspunkte erreichen können.

 

Plattform

Ohne Windows Server können Sie natürlich kein Edge installieren. Stellen Sie also die erforderliche Plattform auf physikalischer oder als virtuelle Umgebung mit den entsprechenden Netzwerkverbindungen bereit.

Diese Server können schon vor der Installation der Edge-Dienste in ihre IT-Umgebung (Monitoring, Patch-Management, Backupagent, Antivirus etc.) integriert sein und die zugewiesenen statischen IP-Adressen und IP-Leitwege erhalten.

 

Exchange

Es bietet sich an die aktuellen Exchange Installationsquellen auf dem Edge-Server schon vorzuhalten. Auch wenn der Server in der DMZ steht, kann dies über einen RDP-Zugriff erfolgen.

Beachten Sie, dass die internen Hub/Transport-Server ggfls. ein Update erfordern. Dies ist z.B. der Fall, wenn ein Exchange 2010/2007 Server intern einen Exchange 2013 Edge-Server bedienen soll.

Zudem können Sie auf dem zukünftigen Edge-Server schon die erforderlichen "Prerequisites" installieren. Prüfen Sie dazu die eingesetzte Exchange Version und das darunterliegende Betriebssystem.

 

Abgesehen von der Installation und Konfiguration als letzten Schritt können alle anderen Punkte schon vorab abgearbeitet werden.

Edge Installation

Der Server mit der Edge-Rolle steht normalerweise in einer besonders abgeschotteten Zone und übernimmt einfach nur die Weiterleitung der Mails in beide Richtungen und zusätzlich einige Filter.

Damit der Administrator nun nicht allzu viel zu tun tun hat, gibt es aber einen Replikationsmechanismus zwischen dem Edge Server und einem Hubserver. Dazu muss folgendes durchgeführt werden.

  • Edge Installieren
    Durch die Installation wird auf dem Server auch eine ADAM-Datenbank (Siehe ADAM) installiert. Zudem wird eine XML-Datei erstellt, in der die Konfiguration dieses Servers hinterlegt ist. Die Edge-Rolle muss zwingend auf einem eigenständigen PC installiert werden, der nicht Mitglied im internen Active Directory ist. Es kann wohl in einem eigenen Forest betrieben werden. Zudem kann Edge mit keiner anderen Exchange Rolle kombiniert werden. Das sieht man schon beim Setup selbst.

    Durch die Auswahl der Edge-Rolle werden alle anderen Optionen werden abgeblendet. Und natürlich muss man neben dem .NET Framework und der PowerShell auch noch ADAM SP1 selbst installieren. Dafür dürfen natürlich keine NNTP oder SMTP-Dienste installiert sein.
    Edge Warnungen
    Ein ebenfalls installierter IIS hingegen stört nicht, obwohl ich den sicher nicht auf einem Edge installieren würde.

Edge Konfiguration

Eine Edge-Rolle macht nur richtig Sinn, wenn Sie auch Exchange 2007 intern einsetzen, denn als Partnerschaft profitieren beide.

  • Edge Subscription auf dem Edge erstellen
    Damit wird im wesentlichen eine XML-Datei mit Konfigurationsdaten und Verschlüsselungswerten erstellt, die dann auf dem HubTransport importiert wird.
  • XML auf Hubrolle einbinden
    Der nächste Schritt ist die Einrichtung einer "EDGE-Subscription" auf dem HUB-Server. Hier müssen Sie die XML-Date angeben. Über diesen "Trick" weiß der HUB-Server automatisch, wie er die ADAM-Datenbank auf dem Edge-Server erreicht. (Firewall-Einstellungen, IP-Routing, Namensauflösung etc. müssen Sie natürlich selbst sicherstellen)
  • EdgeSync starten
    Nun ist es die Aufgabe des HUB-Servers, regelmäßig die für den Betrieb des EDGE-Servers erforderlichen Daten in das ADAM-Directory zu schreiben.

Ein Bild verdeutlicht noch einmal die Zusammenhänge.

Der Synchronisationsprozess ist also nicht im SMTP-Protokolle enthalten, sondern von intern wird per LDAP auf die ADAM-Datenbank des EDGE-Servers zugegriffen. Dabei repliziert der Edge-Sync-Prozess, welcher auf einem HUB-Server läuft, periodisch folgende Informationen:

  • Accepted domains
    Die Liste der in Exchange als "eingehend" definierten Domänen. Damit erspart man sich die gesonderte Pflege auf den Edge Servern.
  • Recipients (Hashed SHA-256)
    Die Liste der gültigen Empfänger. Diese wird aber nur als "Hash" eingetragen. Meist werden Daten als Hash gespeichert, um diese schneller zu finden. In dem Fall dürfte aber eher die Verschleierung ein Thema sein, damit niemand, der den Edge-Server "knackt", eine Liste der Empfänger hat. Allerdings finde ich das nur bedingt tauglich. Wenn ich die Daten eines Edge-Servers habe, dann "weiß" ich ja schon anhand der Domains die Empfängerdomänen. Eine "brute force"-Attacke auf die Hashwerte dürfte nicht wirklich lange dauern.
  • Safe Senders Lists (Hashed)
    Ebenfalls extrahiert der Transport Server die "Safe Sender" der Benutzer, um diese als besondere Absenderadressen an Edge zu liefern. Ich persönlich finde aber "Safe Sender" nicht wirklich brauchbar. Gerade "große Verteiler" von Firmen nutzen ja immer die gleiche Absenderadresse, z.B. agb@ebay.de, und solche Adressen werden dann sicher auf der "Safe Sender Liste" landen. Es ist ein einfaches für Spammer solche eine "bessere" Adresse zu nutzen, solange die Absender nicht mit SPF/CallerID ihren Namen schützen.
  • Send Connectors
    Zudem bekommt Edge die Infos der "Send Connectors", d.h. welche Hubserver nach draußen an welche Adressen ihre Mails wie zustellen. Edge kann über diesen Weg dann einfach erkennen, ob eine Verbindung von einer konfigurierten internen Stelle kommt
  • Hub Transport Server List
    Damit kann der Edge dynamisch den Weg nach innen finden.

Dabei handelt es sich immer um eine "Push"-Synchronisation, d.h. die Daten werden vom Hub/Transport-Server von innen nach draußen auf den Edge-Server geschrieben. Es gibt demnach außer der SMTP-Verbindung keine weitere Verbindung von Edge nach intern.

  • 1h ConfigUpdate
    Die Konfiguration wird einmal in der Stunde repliziert
  • 4h Recipient Update
    Die Liste der gültigen Empfänger wird alle 4 Stunden zur ADAM-Datenbank des Edge-Servers geschrieben. Dabei handelt es sich immer um einen Full-Sync !, d.h. es werden keine Deltas geschrieben.

Manuelle Konfiguration

Die Edge-Rolle muss aber nicht zwingend mit Exchange Servern und EdgeSync eingesetzt werden. Über die Management Console können Sie einige der Einstellungen sogar direkt auf dem Edge Server vornehmen:

Edge MMC

Allerdings ist dann z:B. die Empfängerfilterung kniffliger zu lösen, da die gültigen Empfänger nicht über den EdgeSync in die ADAM-Datenbank kommen. Auch wenn Edge ohne Exchange 2007 möglich ist, ist es meiner Ansicht nach keiner weiteren Betrachtung wert. Sie benötigen für den Einsatz von Edge sowieso die Exchange 2007 CALs und zumindest die Serverlizenz für den Edge. Das ist eine ganze Stange Geld, wenn Sie "nur" etwas Spamschutz möchten.

Bewertung

Letztlich ist die Idee von Microsoft bestehend einfach und trivial. Das Schutzsystem liefert eine XML-Datei, die intern einfach importiert wird. Damit "weiß" der HUB-Server zumindest die Daten des EDGE-Servers. Den Send-Connector müssen Sie aber natürlich weiterhin einrichten. Umgekehrt bekommt Edge über die ADAM-Datenbank die wesentlichen Informationen.

Konfiguration Fehlanzeige ?
Aus Gesprächen mit Microsoft habe ich mir auch erläutern lassen, warum Edge nur eingeschränkt konfigurierbar ist. Microsoft erklärt dies so, dass der Spamschutz als "Blackbox" zu betrachten ist und Microsoft über Updates (WSUS etc.) eine hohe gute Erkennung sicherstellen will. Es erscheint nicht sinnvoll, dass Administratoren als eigenständige "Spamfighter" auftreten und Millionen von Administratoren regelmäßig ihr System "nachtunen" müssen.
Das ist für viele Firmen sicher auch zutreffend. Er hier mehr KonfigurationsMöglichkeiten benötigt, wird zu Drittprodukten greifen. (z.B. NoSpamProxy)

Weitere Links