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.

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.

  • Internet Traffic zwischen den Exchange Servern
    Diese Verbindungen werden immer per TLS und einer Anmeldung der Exchange Server untereinander gesichert. Es ist daher darauf zu achten, dass ein Exchange 2007 Server über die Namensauflösung de s anderen Servers auch einen Connector erreicht, der eine Anmeldung als Exchange Server erlaubt.
  • Bekannte Clients per SMTP
    Normalerweise senden Clients ihr Mails per Outlook, OWA oder ActiveSync von innen und sind Authentifizierung. Aber auch ein Versand per SMTP ist möglich. Der Default Connector zwingt aber auch hier den Anwender zu einer Anmeldung. Exchange Prüft dabei auch, ob der Anwender überhaupt mit der Adresse senden darf, ob er Exchange als Relay verwenden kann und ob seine Mailbox nicht schon über den Grenzwerten ist. Exchange 2007 installiert hierfür einen eigenen Client Connector auf Port 587
  • Eingehende Internet Verbindungen
    Verbindungen aus dem Internet sind per Default immer anonym. Aber vor Exchange stehen in der Regel weitere Gateways, die Missbrauch dieses Wegs unterbinden (Virenschutz, Empfängerfilterung, Spamschutz). Wenn sich das Gateway nicht bei Exchange authentifizieren kann, muss man die anonyme Zustellung zumindest von diesen IP-Adressen erlauben. Damit man nun nicht den gesamten Server für alle (internen) Systeme öffnet, sollte ein eigener Connector für anonyme Verbindungen hierzu geschaffen werden.
  • Anonyme Client
    Auch andere Client können Mails an Exchange senden und sich nicht anmelden, z.B. Scanner, Drucker, Switches oder andere Systeme, die Informationen per SMTP zustellen wollen. Auch hier kann man einen Empfangskonnector für anonyme Clients einrichten.
  • Anonyme Clients mit Relay
    Eine ganz besondere Gruppe sind Clients, die nicht nur anonym an Exchange zustellen, sondern auch über Exchange ins Internet senden sollen. Nur wenn es explizit keine andere Option gibt, kann über einen Receive Connector auch ein anonymes Relay aktiviert werden. Dazu sollten dann die fraglichen Systeme explizit mit IP-Adresse eingetragen werden, so dass nur diese Systeme die Connector Konfiguration verwenden können.

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:

  • Von anonym extern kommen keine Internen Adressen
    Wenn ihre Anwender per VPN, OWA, ActiveSync, RDP o.ä., arbeiten, dann kommen Sie aus Sicht des Exchange Servers "von innen, sind authentifiziert und senden nach Innen oder Außen. Daher kann es nicht sein, dass aus dem Internet jemand eine Mail an ihre System mit ihrer eigenen Domain sendet. Diese Mail ist (fast immer) gefälscht. Lehnen Sie daher Mails mit ihrer eigenen Domäne als Absender ab.
  • Lassen Sie nur gültige Adressen zu
    Wenn Sie Mails in das Internet senden, dann gehört es nicht nur zum guten Ton, gültige Absenderadressen zu verwenden, sondern auch Rückläufer (NDR) anzunehmen. Schließlich wollen Sie es ja wissen, wenn eine Mail nicht ankommt. Ein Exchange Postfach kann die Absenderadresse nicht fälschen, so dass dies nicht so einfach passiert, aber öffentliche Ordner nehmen leider keine NDRs an.
  • SMTP Relay nur mit Authentifizierung
    Wenn Sie intern Systeme haben, die selbst per SMTP eine Mail erstellen und versenden, dann können Exchange 2003 und älter diese Absenderadressen nicht prüfen. Exchange 2007 prüft aber, ob der per SMTP authentifizierte Benutzer auch das "SendAs"-recht für die verwendete SMTP-Adresse besitzt.

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:

  • Port 587 ?
    Dieser Post ist schon seit Jahren öffentlich und sollte zum Versand von Clients an Mailserver genutzt werden. Damit sollte der Verkehr von Anwendern zum Mailserver (die auch POP3 und IMAP4 verwenden) von dem Verkehr zwischen Mailservern (Port 25 MTA) genutzt werden. Klar dass die meisten dies nicht können und leider nicht nutzen, denn es hätte für Provider schon den Vorteil, dass z.B. alle DSL-Anbieter einfach Port 25 von den Kunden sperren könnte und damit alle Mailviren, Trojaner und Bot-Netze nicht mehr Mails direkt versenden können. Einige Provider haben dies schon aktiviert. Allerdings gibt es auch Schadprogramme, die dann einfach Huckepack auf alten Outlook, Outlook Express oder anderen Programmen arbeiten und damit ihren Müll mit Authentifizierung über das Relay des Providers versenden. Aber dann könnte dort schon der Missbrauch (Zu viel Mails/Zeit) geblockt und der bekannte Kunde informiert werden.
    Wann dies im Internet gebräuchlich wird, steht auf einem anderen Blatt aber intern können und sollten Sie dies nutzen.
  • Anmeldung und Klartext über SSL
    Die Standardeinstellung erzwingt, dass Sender sich anmelden und dazu eine sichere Anmeldung nutzen. Eine einfache Klartextanmeldung ist nur mit SSL erlaubt. Damit ist Exchange und das Kennwort zwar sicher aber viele Clients bedürfen damit der Umstellung . Eine Schwächung der Sicherheit durch eine KonfigurationsÄnderung ist möglich aber nicht angeraten, da das Mailkennwort zugleich auch das Active Directory Kennwort ist.
  • Berechtigungen
    Exchange hat fünf Berechtigungsgruppen (Die aber keine Gruppen im Active Directory sind) von denen im Standard Setup aber "Anonym" und "Partner" gar nicht genutzt werden. Die Einstellung "Exchange Benutzer" kennzeichnet alle Exchange Objekte, die nach Anmeldung eine Mail versenden können. Exchange Server trifft für alle Exchange 2007 Server zu und die Gruppe der "Legacy Exchange Server" bedient alle Exchange 2003 Server. Diese Einstellung ist also primär für die Routinggruppenconnectoren zwischen der neuen Exchange 2007 und der alten Exchange 2000/2003-Welt relevant.
  • Timeout
    Im LAN und mit entsprechender Bandbreite auch im WAN sollte ein Timeout von 10 Minuten ausreichend sein. Wer allerdings z.B. nur DSL1000 hat und idealisiert mit 1 Megabit empfangen kann, der wird im Idealfall keine Mails größer als 60MB empfangen können. Und wenn die Bandreite noch geringer ist oder der Absender "langsamer" unterwegs ist, dann schlägt die Grenze schon früher zu. Ausnahmsweise haben hier die Firmen einen Vorteil, die einen POP3-Sauger einsetzen, da hier die Mails per POP3 abgeholt und dann quasi per SMTP über "localhost" nicht mehr den Engpass der Bandbreite durchlaufen müssen. Negatives Beispiel scheint hier aber der SBS2011 POP3-Sauger zu sein, welcher anscheinend jede Mail abholt und gleich sendet und dabei die SMTP-Verbindung offen lässt. Wenn der POP3-Download länger braucht, dann schlägt auf der SMTP-Seite der Inaktivitäts-Timer oder Connection-Timer zu.

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.

Die Connector-Matrix

Auch wenn Exchange 2007 und höher per Default auch keine Mails von anonymen internen Quellen annehmen, schalten die meisten Administratoren diese Funktion frei, weil es einfacher ist anstatt IP-Whitelisten zu pflegen.

Ausgehend von den möglichen Quellen und Zielen ergibt sich folgende Matrix für Systeme die per SMTP einliefern mit ein paar Beispielen für deren Gebrauch:

  Ziel Interner lokale  Empfänger Ausgewählte
externe Empfänger, die über einen MailContact erreichbar sind
Die weite Welt
Absender  
Per IP-Identifizierbare Quelle
  • Monitoring-Systeme
  • Sharepoint
  • Benachrichtigung z.B. Storage-Dienstleister, Druckermanagement
  • Marketing
  • Listserver
Per Authentifizierung bekannte Quelle
  • Scan2Mail
  • Benachrichtigungen
  • Normale Clients
  • "gute Clients"
  • Marketing
  • Listserver
Any
  • Scan2Mail
  • Benachrichtigungen
  • Drucker
Offene Relay !

Der "Default Receive Connector" erlaubt nur per Authentifizierung identifizierbaren Absendern den Versand. Also müssen wir weitere Connectoren vorsehen. Zwei "Probleme" kommen dabei immer wieder hoch:

  • Dynamische IP-Adresse
    Gerade Geräte "im Feld" werden per DHCP mit IP-Adressen versorgt und sind daher nicht al statisch anzunehmen. Zudem können IP-Adressen natürlich "gekapert" werden.
  • Authentifizierung
    Die Konfiguration von Anmeldedaten ist oft nur bei wenigen ausgewählten Systemen (Monitoring, SharePoint, Webservern etc.) sinnvoll anzuwenden, da dazu Postfachbenutzer mit Kennworten anzulegen sind und damit das Risiko besteht, dass Kennworte erspäht und nicht schnell geändert werden können.

Insofern muss man abwägen, welcher Sektor dieser Matrix wie gelöst wird und welche Sektoren aus Vereinfachungsgründen zusammengefasst werden. Hier mal ein Beispiel:

  Ziel Interner lokale Empfänger Ausgewählte
externe Empfänger
Die weite Welt
Absender  
Per IP-Identifizierbare Quelle Default Connector erlaubt auch anonyme Clients solange Empfänger intern ist. "Störpotential" durch interne Clients wird toleriert Durch Kontakte ebenfalls möglich. Connector "Anonym Relay
Per Authentifizierung bekannte Quelle Standard Default Receive Connector Standard Default Receive Connector
Any

Durch Kontakte ebenfalls möglich. Störpotential wird toleriert

Offene Relay !

Die Freischaltung von ausgewählten externen Empfänger über "Mailkontakte" in Verbindung mit der Freischaltung für anonyme Annahme erlaubt natürlich jedem internen IP-Client, der Exchange erreichen kann, den Versand. Wer dies nicht möchte, muss auf die Kontakte verzichten oder darf die anonyme Annahme nicht aktivieren und stattdessen IP-Adressen pflegen.

  • SMTP-Relay - SMTP weiter geben
  • Relaykonzept - Sicherer Betrieb von Exchange als Maildrehscheibe
  • Relaysicherheit - Wann sollte ein Mailserver die Nachricht weitergeben und wann nicht ?

Ü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.

  • Default Connector
    Dieser Connector nimmt alle Verbindungen auf Port 25 an, sofern kein anderer Connector besser „passt“. Allerdings ist eine Authentifizierung erforderlich
  • Client Connector
    Diese Connector nimmt Verbindungen auf Port 587 an und erfordert eine Authentifizierung. Er ist primär für Clients gedacht.
  • Anonym Accept
    Dieser Connector nimm“ zusätzlich“ auch Verbindungen ohne Authentifizierung an. Allerdings wird über die Liste der IP-Adressen gesteuert, für welche Clients diese Möglichkeit angeboten wird
  • Anonym Relay
    Über diese Einstellung können die zugelassenen Systeme sogar über Exchange Nachrichten an andere externe System senden (z.B. Internet, Fax, etc.).

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:

  • Relay erlaubt
    Exchange 2007 ist relaysicher, da es nur bekannten Absendern erlaubt, eine Mails durch Exchange zum Internet zu senden. Alle Systeme müssen sich daher anmelden, um über Exchange 2007 eine Mail in das Internet zu senden. Sie können dies aber ändern, indem Sie anonyme Zugriffe erst erlauben und dann über folgenden PowerShell Befehl den Connector "öffnen" (Siehe auch E2K7 POP3/IMAP4).
    Alternativ können Sie auf so einem Connector auch ein "Externally Secured" aktivieren. Tun sie das bitte nur für einen Connector, der von einer klar bekannten und eingegrenzten Anzahl von Client erreichbar ist.

# 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"

  • SendAs
    Exchange 2007 prüft aber im Gegensatz zu Exchange 2000/2003 auch die "MAIL FROM"-Adresse. Wer sich anmeldet, kann also nur mit der Absenderadresse eine Mail einliefert, für die er auch berechtigt ist. Ein Fälschen der Absenderadresse ist also nicht mehr möglich
  • Quota
    Neu ist auch, dass Exchange 2007 prüft, ob das Postfach noch unter der Größenbeschränkung ist. Jemand, dessen Postfach über der "Senden verbieten" Grenze ist, kann also nun auch über Exchange 2007 nicht mehr einstellen

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:

  • LocalIP
    Die IP-Adresse, auf der der Connector lauscht. Das kann auch "alle" oder eine Auswahl sein.
  • Port
    Der TCP-Port, (normalerweise 25 oder 587), über den Verbindungen angenommen werden.
  • Remote-IP
    Die IP-Adresse oder das IP-Netz, von dem die Verbindung kommt.

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.

  • Anonym In (Servername)
    Von diesen Systemen nimmt Exchange 2007/2010 jede Mail ohne weitere Anmeldung, solange der Empfänger "lokal" ist. Mails an andere Empfänger werden nicht als Relay weiter gegeben.
  • Anonym Relay (Servername)
    Diese Systeme dürfen Mails ohne Anmeldung an Exchange senden und Exchange 2007 sogar als Relay zum Internet verwenden.
  • Default (Servername) (unverändert)
    Nach einer Anmeldung gelten die Standardberechtigungen und Einschränkungen (Relay, Quota, SendAs)
  • Client (Servername) ( unverändert)
    Nach einer Anmeldung gelten die Standardberechtigungen und Einschränkungen (Relay, Quota, SendAs)

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 undins 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

  • Anonym Relay (Servername) (Neu)
    Diese Systeme dürfen Mails ohne Anmeldung an Exchange senden und Exchange 2007 sogar als Relay zum Internet verwenden.
  • Default (Servername) (+Anonym)
    Nach einer Anmeldung gelten die Standardberechtigungen und Einschränkungen (Relay, Quota, SendAs). Abweichend zum Standard werden auch Verbindungen ohne Anmeldung akzeptiert, solange die Empfänger in der Organisation definiert sind.
  • Client (Servername) ( unverändert)
    Nach einer Anmeldung gelten die Standardberechtigungen und Einschränkungen (Relay, Quota, SendAs)

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 können:

  • MAILFROM: Kurzname
    Während bei Exchange 2000/2003 ein  "MAIL FROM: user"  noch automatisch um "@domain.tld" ergänzt wurde, macht Exchange 2007 dies nicht mehr per Default. Viele Drucker, Scanner, Switches etc., die beim Versand keine vollständige Mailadresse verwenden, werden daher ihre Mail nicht los. Diese Verhalten kann man aber durch das Setzen einer "Default Domain" Mittels PowerShell korrigieren

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

  • 5xx-Bestrafung
    Immer, wenn eine Befehl beim Exchange Server zu einer 5xx-Meldung führt, (also ein Fehler), liefert Exchange die Meldung nicht sofort aus, sondern verzögert die Antwort um 5 Sekunden. Das Ziel ist, das Spammer und andere Prozesse z.B.: es nicht so einfach beim Erraten von gültigen Empfängern haben. Exchange lehnt ungültige Empfänger in der "RCPT TO"-Zeile direkt ab. Hartnäckige Clients werden nach mehreren Fehlerversuchen immer langsamer und letztlich wird die Verbindung beendet. Dies trifft aber nur für anonyme Clients zu

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

  • 10 MB Limit
    Ein dritter Aspekt ist die Default-Beschränkung auf 10 Megabyte beim Empfang einer Mail. Dies kann sowohl über die GUI als auch per PowerShell geändert werden.

Spezielle Receive Connectoren

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

  • Logging
    Sie können je Connector z.B. das Transport Logging einschalten. Wenn Sie also z.B. einen SMTP-Sender in ihrem LAN haben, welches Probleme hat, dann legen Sie einfach einen Receive Connector an und aktivieren auf diesem das Logging. So kann man sehr einfach ausgewälte Systeme überwachen, ohne z.B. alle Kommunikationen aufzuschreiben.
  • Drucker und Scanner
    Mittlerweile gibt es auch immer mehr Drucker und Scanner, die gescannte Dokumente oder Statusmeldungen per Mail versenden. Da ich natürlich ungerne den Default Receive Connector für alle per Anonym öffne, bietet sich auch hie rein eigener Connector. Hier kann man auch abweichende Einstellungen bezüglich der Mailgröße etc. machen
  • Internetempfang
    Ich habe auch schon mal einem Server eine zweite IP-Adresse (offiziell) verpasst und einen eigene Receive Connector für den Empfang aus dem Internet eingerichtet. Die lokale Adresse war dabei diese offizielle IP-Adresse (bzw. die zweite Adresse, auf der der NAT-Router eingehende Verbindungen geleitet hat. Die .Adresse war natürlich von intern nicht erreichbar.
  • Partnern und Migration
    Wenn Sie intern eine "Querverbindung" zu alten oder anderen Mailsystemen in der gleichen Firmengruppe oder zu externen Partnern benötigen, dann ist ein eigener Receive Connector eine sinnvolle Konfiguration.
  • External gesichert
    Ein Connector mit dieser Einstellung ist relativ offen und erwartet, dass eine Firewall davor oder anderen Beschränkungen unerlaubte Zugriffe verhindern. Es ist daher eine alternative zum "anonymen Zugang" eines Connectors.

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:

  • Internal Routing
    Die Exchange HubTransport Server suchen für die Zustellung den nächsten Server und nutzen dabei den FQDN der auf diesem Server vorhandenen Receive Connectoren. Wer hier also "mail.firma.de" einträgt aber der Name per DNS auf das Relay in der DMZ (ohne Authentifizierung) verweist, stört nachhaltig die interne Kommunikation
  • Zertifikatsauswahl
    Wenn der Connector SSL/TLS anbieten soll, dann muss er ein Zertifikat auf dem Server finden, welches zum Namen passt. Ansonsten gibt es im Eventlog eine Warnung, dass er kein TLS anbieten kann

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