Exchange 2007/2010 Receiveconnector

Löschen oder ändern Sie bitte NIE den Default Connector ohne Vorkehrungen getroffen zu haben. Auch die Kommunikation zwischen Exchange Servern der gleichen Organisation nutzen diesen Connector. Wer also als kleine Firma einfach einstellt, dass nur noch anonym Mails. empfangen werden dürfen, blockiert auch die interne Kommunikation von anderen HT-Rollen und die Zustellung von Sprachnachrichten durch die UM-Rolle.

In Exchange 5.5 musste extra ein Internet Mail Connector Exchange 5.5 eingerichtet werden, um nicht nur Mails in das Internet senden zu können, sondern auch um Nachrichten auf Port 25 zu akzeptieren. In Exchange 2000/2003 musste schon vor der Exchange Installation der Windows SMTP-Server installiert sein, welcher von Exchange 2000/2003 dann erweitert wurde. Exchange 2000/2003 war dann aber auch ohne Einrichtung eines Internet Mail Connector Exchange 2000/2003 schon bereit, um Mails zu empfangen. Sogar der Versand war möglich, da auch ohne Connector dann eben die Einstellungen des virtuellen SMTP-Servers genutzt wurden.

Mit Exchange 2007 ist alles erst einmal "sicherer", was sich schon daran zeigt, dass Exchange 2007 per Default nur Nachrichten von Systemen annimmt, die sich authentifizieren. Damit ist ein Exchange 2007 Server ohne weitere Konfiguration nicht bereit, um Nachrichten aus dem Internet anzunehmen. Auch für den Versand von Nachrichten muss erst ein E2K7 SendConnector eingerichtet werden.

Beachten Sie dazu auch
Relaykonzept  -Sicherer Betrieb von Exchange als Maildrehscheibe
Relaysicherheit - Wann sollte ein Mailserver die Nachricht weitergeben und wann nicht ?

Empfangskonnectoren

Empfangskonnectoren steuern, von welchen Systemen Verbindungen unter welchen Bedingungen per SMTP angenommen werden. Hier gilt es vier verschiedene Anwendungsfälle zu unterscheiden, da Exchange 2007 per Default keine anonymen Verbindungen zulässt und aus Sicherheitsgründen dies auch nur sehr selektiv geöffnet werden sollte.

Basis-Konnectoren

Daher ein kurzer Ausflug in die Welt des bösen gemeinen Internets, damit Sie die Bedeutung der nachfolgenden Konfiguration verstehen: Mail ist unternehmenskritisch und gefälschte Absender sind ein Problem. Natürlich verwenden Spammer und Viren fast immer "falsch" Absender, aber auch als Firma sollten Sie verhindern, dass über ihren Mailserver Nachrichten ins Internet gehen, die nicht zu ihnen gehören. Als gibt es drei Regeln:

Das wissen um die Gültigkeit der Absenderadresse und die korrekte Verwendung nur durch berechtigte Benutzer ist wichtig, wenn z.B. mit Transportregel Filter aufgebaut, Empfangsbeschränkungen gesteuert oder vielleicht sogar aus dem Server digital signiert werden soll.

Vielleicht wird nun klarer, dass Exchange 2007 in der Standardauslieferung nur authentifizierte Benutzer den Zugriff per SMTP erlaubt und Sie die Konfiguration anpassen müssen.

Defaults und Einstellungen

Wenn Sie Exchange 2007 installieren, dann hat jeder Server zwei Receive Connectoren. Diese Einstellungen sind auf jeden Server mit Hub/Transport-Rolle zu konfigurieren. Nur die Send Connectoren sind "Organisationsweit" einzustellen

Name Listen IP Remote IP Authentifizierung Berechtigung Connection Timeout
Default (Servername) Any:25 Any
  • TLS mit Zertifikat
  • Klartext über SSL
  • Exchange Server Auth
    NTLM
  • Exchange Benutzer
  • Exchange Server
  • Legacy-Exchange-Server
  • 10 Minuten Total
  • 5 Minuten Inaktivität
Client (Servername) Any:587 Any
  • TLS mit Zertifikat
  • Klartext über SSL
  • NTLM
  • Exchange Benutzer
  • 10 Minuten Total
  • 5 Minuten Inaktivität

Hier sind viele Dinge erst einmal neu und zu erklären:

Tatsächlich ist es nicht möglich, ohne Anmeldung per SMTP an Exchange 2007 abzusetzen. Microsoft geht davon aus, dass alle Kunden einen "Edge"-Server installieren, welcher die Mail anonym aus dem Internet annimmt und nach Viren und Spamschutz authentifiziert an Exchange 2007 übergibt. Nur scheinen nur sehr wenige Firmen einen EDGE-Server einsetzen zu wollen. Sie sollten also ihrem Relay davor (NoSpamProxy, Orangebox, Ironport, Watchguard, u.a. Gateways) beibringen, sich am nachgelagerten Server anzumelden. Alternativ können Sie die IP-Adresse des Gateways den anonymen Zugriff durch eine Konfigurationsänderung erlauben.

Kein Anonymes Relay
Ich bin voll auf einer Linie, dass Exchange 2007 keine Mail ohne Authentifizierung annimmt oder als Relay weiter gibt. Damit ist aber eine Konfigurationsanpassung erforderlich. Vermeiden Sie aber, wann immer möglich, dass interne Systeme anonym Exchange als Relay nutzen können.

Anonymer Empfang
Auch das Anonyme Annehmen an interne Empfänger ist kritisch, da hierbei die Absenderadresse gefälscht sein kann und damit z.B. Transportregeln ausgehebelt werden können. Vielleicht haben Sie ja einen Verteiler "ALLE" der nur von ausgewählten Personen angeschrieben werden darf. Wenn ich dann einfach anonym die Mail mit der passenden erlaubten Absenderadresse einstelle, umgehen ich die Regel.

Anonym und Internet
Daher sollte nur der Weg aus dem Internet anonym zustellen dürfen und hier ein Filter eingehende Mails mit einer internen Mailadresse blockieren, damit sich niemand von außen als vertrauenswürdiger Interner Mitarbeiter ausgeben kann.

Überlegungen zur weiteren Connectoren

Das blinde aktivieren des anonymen Empfangs auf dem Default Connector ist sicher einfach, aber aus Sicherheitsaspekten nicht zu empfehlen. Insofern bietet sich die Einrichtung von bis zu vier Connectoren an.

In einigen Fällen kann es auch bestimmte Absender (z.B. Equalogic Storage-Systeme etc.) geben, die mit der default aktivierten Funktion des Tarpitting nicht zurecht kommen. Exchange 2007/2010 bremsen Sender aus, wenn Sie falsche oder besondere Befehlt (z.B. BDAT) verwenden.

set-receiveconnector <name> `
  -TarpitInterval xxx
  -MessageRateLimit xxx
  -ChunkingEnabled $true
  -EightBitMimeEnabled $true

Einige System sollen auch z. B: nicht die Funktion "Chunking" angeboten bekommen, wenn deren Implementation damit Probleme hat. Sie sehen also, dass es durchaus noch weitere Connectoren für Sonderfälle geben kann. Auch die gehe ich hier aber nicht weiter ein.

Receive Connectoren einrichten

Es gibt also Bedarf an einer Konfigurationsänderung wenn Sie direkt Mails aus dem Internet (anonym) empfangen müssen, oder interne Sender sich nicht sicher anmelden können und vielleicht noch interne Systeme ohne Anmeldung sogar noch Exchange als Relay verwenden wollen. Entsprechend gibt es Szenarien, die berücksichtigt werden müssen:

Von An Default Connector Funktion
Angemeldeter Sender Interne Empfänger Client (Servername)
  • Relay erlaubt
  • SendAs
  • Quota
  • 10 MB
Angemeldeter Sender Extern (Relay) Client (Servername)
  • Relay erlaubt
  • SendAs
  • Quota
  • 10 MB
Anonymer Sender Interne Empfänger Default (erzwingt Anmeldung) Neinnicht möglich
Anonymer Sender Extern (Relay) Default (erzwingt Anmeldung) Neinnicht möglich

Diese Tabelle gilt übrigens für OWA und Outlook genau so. Auch diese beiden Wege erfordern eine Anmeldung. Nur ist es seit Exchange 2007 auch per SMTP nun Standard. Die Funktion muss aber auch hier erklärt werden:

# Deutsche Server
Get-ReceiveConnector "Anonymous Relay" | Add-ADPermission -User "NT-AUTORITÄT\ANONYMOUS-Anmeldung" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient"

# Englische Server
Get-ReceiveConnector "Anonymous Relay" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"

Es ist aber offensichtlich, dass wir die Konfiguration anpassen müssen, denn die meisten Firmen haben eben den Anspruch, ohne Edge Server die Mails anzunehmen und interne Systeme ohne Authentifizierung zuzulassen oder sogar ein Relay in das Internet zu erlauben. Nur wenn Sie ein SMTP-Gateway zwischen Exchange und dem Internet betreiben, welches sich eingehend an Exchange anmelden kann (SMTPAUTH), kann die Standardkonfiguration belassen werden. Anpassungen sind dann nur für interne Clients nötig, die auch anonym an Exchange oder über Exchange senden wollen.

Welcher Connector greift ?

Ehe nun zwei Beispielkonfigurationen folgen, sollten Sie verstehen, wie Exchange 2007 mehrere Receive Connectoren behandelt. Bei Exchange 2000/2003 war es zwar möglich, mehrere virtuelle SMTP-Server einzurichten, die aber zwingend auf unterschiedlichen IP-Adressen IP-Port-Kombination lauschen mussten. Das ist bei Exchange 2007 anders.

Hier gibt es nur GENAU EINEN Transportdienst, der SMTP anbietet. Er kann aber mehrere Konfigurationen anwenden und nutzt dazu drei Kriterien. Bei jedem Receive Connector werden pro Server drei Einstellungen gepflegt:

Schon beim TCP-Connect hat Exchange die drei Daten und schaut einfach nach, welcher Receive-Connector am besten dazu passt. Es ist also durchaus möglich, dass mehrere Konfigurationen den gleichen IP-Ports und Adresse haben, solange die Remote-IP unterscheidbar ist. Bedient dabei ein Connector. z.B. 10.0.0.0/16 und ein anderer 10.5.0.0/24, dann wird eine Verbindung aus 10.5.2.3 mit der zweiten Konfiguration hergestellt, weil dieser Connector "enger" ist. Vermeiden Sie aber Einstellungen, bei denen eine Connector z.B. 10.0.0.0-15.255.255.255 bedient und ein anderer Connector 12.0.0.0-17.255.255.255. Dies ist nicht zulässig.

Abhängig vom der gewählten Konfiguration wird dem Client dann das Zertifikat und die entsprechende Authentifizierung angeboten. Die Einstellungen unter Authentifizierung und Berechtigungen werden nicht zur Auswahl des passenden Connectors heran gezogen, sondern steuern danach nur die angebotenen Befehle beim EHLO und die Zugriffsberechtigungen. So kann man einem Connector, der vom Internet aus erreichbar ist, explizit nur "ANONYM" erlauben, so dass von außen gar nicht erst ein Kennwort Probing möglich ist. Beachten Sie aber, dass der Connector dann sicher auf "Remote IP:Any" steht und damit eventuell auch eine interne Kommunikation zwischen Exchange Servern (Hier wir Authentifizierung erforderlich) gestört wird, wenn Sie der internen Kommunikation keinen passenden Weg öffnen.

Fallen

Eine Auswahl von Fehlkonfigurationen, die ihnen das Leben schwer machen können. Hier eine Situation als erste Knobelaufgabe

Ihr Ziel Sie möchten Mails aus dem Internet direkt annehmen
Ihre Aktion Sie legen einen "Internetempfang" -Connetor an, der auf allen Adressen:25 lauscht und von jedem Verbindungen annimmt. Sie erlauben NUR anonyme Anmeldung, damit von außen keine Kennworte geprobt werden können.
Ergebnis Das interne Routing bricht zusammen, da auch Verbindung von anderen Exchange Servern in der gleichen Organisation und von Exchange 2003 Servern über Routinggruppen nicht mehr arbeiten. Sie gelangen nicht mehr an den "Default" Connector, sondern an ihren Connector und können sich nicht anmelden.
Lösung 1 Binden Sie den "Internetempfang"-Connector an eine eigene IP-Adresse, die von außen angesprochen wird. Damit nutzen interne Partner den Default Connector über den DNS-Namen
Lösung 2 Pflegen Sie im Default Connector alle internen IP-Adressen. Damit ist dieser Connector wieder "enger" bei Verbindungen von internen Systemen

Man muss also genau aufpassen, wenn Sie einen Connector für "anonym only" einrichten, dass dieser nicht von Kommunikationspartnern genutzt wird, die sich anmelden müssen.

Beispielkonfiguration "Sicher" mit Gateway aus dem Internet"

Die hier beschriebene Beispielkonfiguration deckt eigentlich alle Belange einer Exchange-Nutzung ab, aber scheint auf den ersten Blick etwas aufwändig zu sein. Ich schlage pro Server "vier" Receive-Connectoren vor. Wenn Sie weniger hohe Sicherheitsanforderungen haben, dann können Sie sich den "Anonym Incoming"-Connector weg lassen und auf dem Default Connector einfach den anonymen Zugriff einrichten.

Folgende Einstellungen sind hier gemacht

Name ListenIP Remote-IP Authentifizierung Berechtigung
Anonym Accept (Servername) Any:25
  • IP der Gateways aus dem Internet (Eingehend)
  • IPs interner Systeme, die anonym zustellen aber nicht ins Internet dürfen

Achtung: Hier sollten NICHT die Exchange Server auftauchen
  • TLS mit Zertifikat
  • Klartext über SSL
  • Exchange Server Auth
    NTLM
  • Anonym
  • Exchange Benutzer
  • Exchange Server
  • Legacy-Exchange-Server
Anonym Relay (Servername) Any:25
  • IPs interner Systeme, die anonym zustellen UND ins Internet dürfen. (Relay)
  • TLS mit Zertifikat
  • Klartext über SSL
  • Exchange Server Auth
    NTLM
  • Anonym
  • Exchange Benutzer
  • Exchange Server
  • Legacy-Exchange-Server
  • External Secured
Default (Servername) Any:25  
  • TLS mit Zertifikat
  • Klartext über SSL
  • Exchange Server Auth
    NTLM
  • Exchange Benutzer
  • Exchange Server
  • Legacy-Exchange-Server
Client (Servername) Any:587  
  • TLS mit Zertifikat
  • Klartext über SSL
  • NTLM
  • Exchange Benutzer

Bei dieser Konfiguration nimmt Exchange nur Mails von anonymen Systemen an, die in der Liste von "Anonym In" oder "Anonym relay" gepflegt sind. Alle anderen Verbindungen von Clients müssen authentifiziert werden. Es ist dabei kein Problem, dass auch auf den "ANONYM"-Connectoren eine Authentifizierung angeboten wird. Die Clients müssen sie aber nicht verwenden

Beispielkonfiguration "Klein" mit direktem Empfang aus dem Internet"

Wenn Sie ihre Mails direkt aus dem Internet auf den Exchange Server leiten (Routing/NAT/Portfilter), dann muss sich jede IP-Adresse aus dem Internet anonym mit ihrem Server verbinden können. Insofern macht es auch wenig Sinn, intern mehr Schutz an den Tag zu legen. Auch dürfte es dann kein Problem sein, dass man auch von extern über SMTPAUTH versuchen kann, ein Kennwort zu erraten. Nur würde ich Exchange nie als offenes Relay betreiben wollen. Daher kommen hier drei Connectoren zum Einsatz

Folgende Einstellungen sind hier gemacht

Name ListenIP Remote-IP Authentifizierung Berechtigung Sonstiges
Anonym Relay (Servername) Any:25
  • IPs interner Systeme, die anonym zustellen und als Relay ins Internet dürfen
  • TLS mit Zertifikat
  • Klartext über SSL
  • Exchange Server Auth
    NTLM
  • Anonym
  • Exchange Benutzer
  • Exchange Server
  • Legacy-Exchange-Server
 Relay per Powershell einstellen
Default (Servername) Any:25 Any
  • TLS mit Zertifikat
  • Klartext über SSL
  • Exchange Server Auth
    NTLM
  • ADD: Anonym
  • Exchange Benutzer
  • Exchange Server
  • Legacy-Exchange-Server
  
Client (Servername) Any:587 Any
  • TLS mit Zertifikat
  • Klartext über SSL
  • NTLM
  • Exchange Benutzer
  

Alle Systeme, die in der Liste des "Anonym Relay"-Conector aufgeführt sind, können sich mit dem Exchange Server ohne weitere Authentifizierung verbinden, mit jeder beliebigen Absenderadresse Mails in das Internet senden. Alle anderen Systeme landen auf dem "Default (Servername)"-Connector, welcher zusätzlich anonyme Verbindung akzeptiert. Damit können alle Systeme im Internet oder Intern ihre Mails an Exchange zustellen. Exchange wird diese Mails aber nur innerhalb der Exchange Organisation zustellen und nicht als Relay weiter leiten.

Beispielkonfiguration "Hochsicher"

Vielen ist in den beiden Konfigurationen die Aktivierung von Anmeldeoptionen bei den anonymen Konnectoren ein Dorn im Auge. Schließlich will man vielleicht gar nicht, dass diese Clients eine Authentifizierung ausprobieren können. Dann muss man einen Connector "Anonym Accept" anlegen, der "NUR" anonyme Anmeldungen zulässt. Dann muss man aber sicher stellen, dass Client und vor allem andere Exchange Server in der gleichen Organisation niemals den Einstellungen dieses Konnectors unterworfen werden. Sollte dies doch passieren, dann stauen Sich die Mail in den Queues des anderen Servers, mit der 451 Fehlermeldung, dass die Gegenstelle keine passende Authentifizierung unterstützt.

Name ListenIP Remote-IP Authentifizierung Berechtigung Sonstiges
Anonym Accept (Servername) Any:25
  • IPs der Systeme, die anonym zustellen dürfen

Wichtig: Diese Liste darf keine Systeme enthalten , die zwingend authentifizieren müssen
  • Keine
  • Anonym
 Helo-String z.B.:"anonym.<domain>"
Default (Servername) Any:25 Any
  • TLS mit Zertifikat
  • Klartext über SSL
  • Exchange Server Auth
    NTLM
  • ADD: Anonym
  • Exchange Benutzer
  • Exchange Server
  • Legacy-Exchange-Server
  
Client (Servername) Any:587 Any
  • TLS mit Zertifikat
  • Klartext über SSL
  • NTLM
  • Exchange Benutzer
  

Damit wird verhindert, dass Systeme die anhand der Filterkriterien auf dem "Anonym Accept" landen, zwingend Anonym senden müssen und auch keine Attacke gegen die Authentifizierung (Erraten von Benutzern und Kennworten) fahren können.

Spamschutz und RFC-Enforcement

Speziell im zweiten Fall, bei dem Exchange direkt aus dem Internet erreichbar sein kann, ist ein Spamschutz und Virenschutz sinnvoll. Der Empfangskonnector ist natürlich auch die Stelle an der ein Exchange Server unerwünschte Mails ablehnen sollte. Exchange 2007 hat wie bei Exchange 2003 SP2 den IMF-Filter nicht per Default aktiviert. Bei Exchange 2007 muss die Aktivierung aber per Powershell erfolgen.

install-AntiSpamAgents.ps1

Weitere Details finden Sie auf E2K7 Antispam. Auch ohne die Antispam Agenten hat jeder Exchange 2007 einige Funktionen eingebaut, die wir bei Exchange 2007 so noch nicht kennen:

set-receiveconnector -identity "name" -defaultdomain firma.tld

set-receiveconnector -identity "name" -MaxProtocolErrors 5 -TarpitInterval 5

Spezielle Receive Connectoren

Es kann durchaus sinnvoll sein, noch weitere Receive Connectoren anzulegen. z.B.

Es gibt sicher noch eine Vielzahl von sinnvollen Konfigurationen.

Receive Connector und FQDN

Sie können bei jedem Receive Connector sogar einen eigenen "Full qualified Domain Name" pflegen. Dieser Name ändert aber NICHT den Willkommensstring, den sie bei einem "TELNET Server 25" sehen. Dieser Name hat zwei wichtige Bedeutungen:

Im schlimmsten Fall kann die interne Kommunikation gestört werden.

Don’t modify the FQDN value on the default Receive connector named “Default <Server Name>” that is automatically created on Hub Transport servers. If you have multiple Hub Transport servers in your Exchange organization and you change the FQDN value on the “Default <Server Name>” Receive connector, internal mail flow between Hub Transport servers will fail.
Quelle: http://technet.microsoft.com/en-us/library/aa996395(EXCHG.80).aspx

Receive Connector und Banner

Wenn Sie schon mehrere Receive-Connectoren konfigurieren, dann hilft es bei einem "telnet <ipadresse> 25" schon in der Willkommensmeldung angezeigt zu bekommen, welcher Connector denn gerade wirkt. Normalerweise zeigt Exchange hier den FQDN-Namen an, der auf dem Connector konfiguriert ist und der natürlich auch mit dem Zertifikat übereinstimmen muss.

Sie können aber über "Set-Receiveconnector" aber auch ein "Banner" setzen. Voraussetzung ist allerdings, dass der String mit "220 " beginnt und nur aus ASICC (7bit)-Zeichen besteht. Umlaute o.ä. gehen da also nicht. Das folgende kleine Powershell-Skript übernimmt einfach die Identity des Connector aus der Exchange Konfiguration in das Banner.

foreach ($rc in Get-ReceiveConnector) {
    set-receiveconnector `
        -identity $rc `
        -banner ("220 " + $rc.identity.name ` -replace "[^\x20-\x7F]")}

Wenn Sie also ihre Connectoren sinnvoll benannt haben, dann sehen Sie schon bei einer Verbindung per TELNET, welcher Connector-Konfiguration "gewonnen" hat. Wer also z.B. drei oder vier Receive Connectoren hat, die für unterschiedliche Anwendungsfälle sind und er diese unter verschiedenen DNS-Namen mit unterschiedlichen FQDN-Namen konfiguriert, benötigt auch die entsprechende Anzahl von Namen im SAN-Zertifikat oder mehrere Zertifikate.

Wer nun bei all den FQDN und Banner-Namen sich fragt, wo die "HELO"-Meldung eingestellt wird, mit der sich der Server beim Versand bei der Gegenseite meldet, der muss einfach nur auf der Seite SendConnector weiter lesen.

Weitere Links

Keywords:E2K7 SMTP ReceiveConnector Spam Relay Konzept