Stellen Sie Ihr Unternehmen auf Exchange Online um? Werden Sie Exchange Online Protection (EOP) allein verwenden oder mit Produkten anderer Anbieter kombinieren? Im Artikel betrachten wir verschiedene Lösungen, denn Sicherheit sollte stets an erster Stelle stehen.
Ein typisches Szenario bei der Migration einer Organisation von einer lokalen E-Mail-Lösung zu Exchange Online ist die Frage, wie der E-Mail-Verkehr am Ende des Projekts gehandhabt werden soll, wenn die lokale E-Mail-Lösung nicht mehr vorhanden ist. Einige Unternehmen haben noch nie Exchange Online Protection (EOP) eingesetzt und verwenden eine Lösung eines Drittanbieters wie z. B. ProofPoint, MessageLabs oder Barracuda. In dieser Phase des Projekts muss eine Entscheidung getroffen werden - Umstellung auf EOP oder Beibehaltung des aktuellen Drittanbieterprodukts zur E-Mail-Sicherheit unter Einbindung von EOP in diesen Mix.
Die Umstellung auf EOP mag zwar einfach erscheinen, ist es aber aufgrund der bestehenden Regeln und Konfigurationseinstellungen nicht unbedingt. Egal, welche Unwägbarkeiten es in Ihrem Unternehmen beim Umstieg auf EOP gibt, hier kommen Tipps und einige konkrete Einstellungen, die nützlich sind, wenn Sie EOP (und Defender) einrichten.
Vorher
Nachher
Die Lösung
Damit alles funktioniert, müssen wir einige Änderungen vornehmen, damit EOP (Exchange Online Protection) den Datenverkehr als vertrauenswürdige SMTP-Kommunikation behandeln kann. Wir können diese Aufgabe mit drei verschiedenen Methoden oder Lösungen lösen, die wir im Folgenden vorstellen:
Lösung 1
Die typische Konfiguration für die Verarbeitung von E-Mails eines externen E-Mail-Sicherheitsanbieters bestand früher, bevor Microsoft Änderungen an der Konfiguration von Exchange Online Protection (EOP) vorgenommen hat darin, Verbindungsfiltereinträge für Server Ips zu erstellen. Message Labs hat zum Beispiel eine Dokumentation, die hier zu finden ist. Sie erklärt, wie man dies in einem Tenant macht. Die gleichen Aktionen können auch in PowerShell durchgeführt werden. Als erstes werden wir prüfen, welche Verbindungsfilter jetzt vorhanden sind:
Get-HostedConnectionFilterPolicy
In einer Greenfield-Umgebung sollten wir folgendes sehen:
Im Falle eingehender Mimecast-Nachrichten müssen wir IPs zur "IPAllowList" hinzufügen, damit es funktioniert. Wenn wir (zum Beispiel) die IP-Adressen 207.12.34.4 und 5 hätten, könnten wir sie mit diesem Einzeiler hinzufügen:
Set-HostedConnectionFilterPolicy Default -IPAllowList 207.12.34.4,207.12.34.5
Lösung 2
Eine andere Methode besteht darin, eine Transportregel zu erstellen, die Verbindungen von Drittanbietern akzeptiert und die Spam-Filter-Engine von EOP überspringt. Wir benötigen lediglich die IP-Adressen des Anbieters und einen Parameter namens ExceptIfSCLOver, der gemäß der Microsoft-Dokumentation für Transportregeln auf -1 gesetzt wird, und schon haben wir diesen Einzeiler:
New-TransportRule 'Inbound from Mimecast' -SenderIpRanges 207.12.34.4,207.12.34.5 -ExceptIfSCLOver -1
Auf diese Weise wird jede E-Mail von diesen IP-Adressen die Spam-Filterung umgehen.
Lösung 3
In dieser Lösung werden wir etwas verwenden, dem Microsoft eine neue Fähigkeit namens Enhanced Filtering (Skip Listing) hinzugefügt hat. Mit Hilfe von Skip Listing kann EOP eine E-Mail besser analysieren, wenn sie von einem Sicherheitsdienst eines Drittanbieters kommt, der vor EOP liegt. Diese Konfiguration besteht aus zwei Teilen - dem Inbound Connector und dem Enhanced Filtering.
Neuer Inbound Connector
New-InboundConnector -Name 'Mimecast Inbound' -ConnectorType Partner -SenderDomains '*' -SenderIPAddresses 207.12.34.4,207.12.34.5
Hinzufügen von Skip Listing-Einstellungen
Sobald wir einen Connector haben, können wir dem Connector auch Skip Listing-Einstellungen hinzufügen. Es gibt zwei mögliche Parameter für die Konfiguration des Inbound-Connectors, nämlich EFSkipLastIP und EFSkipIPs. Mit dem Wert EFSkipLastIP wird EOP angewiesen, bei einer Header-Überprüfung die letzte IP vor dem Empfang durch EOP zu überspringen, vorausgesetzt, es handelt sich um die IP des Dienstanbieters. Die andere Eigenschaft, EFSkipIPs, ermöglicht die manuelle Konfiguration von bestimmten IP-Adressen. Nachfolgend ein Beispiel für die Verwendung beider Parameter:
Set-InboundConnector -Identity 'Mimecast Inbound' -EFSkipLastIP $True
Set-InboundConnector -Identity 'Mimecast Inbound' -EFSkipIPs 207.12.34.4,207.12.34.5
Die Liste der zu überspringenden Verbindungen kann auch auf einzelne oder mehrere Benutzer gefiltert werden, falls dies zu Testzwecken gewünscht wird:
Einzelner Benutzer / Single User
Set-InboundConnector -Identity 'Mimecast Inbound' -EFUsers damian@practicalpowershell.com
Mehrere Benutzer (Gruppe)
Set-InboundConnector -Identity 'Mimecast Inbound' -EFUsers it@practicalpowershell.com
VORSICHT!
Ein Wort der Warnung sei angebracht: Es lohnt sich, diese IP-Adressen mit "Sonderstatus" vierteljährlich oder halbjährlich zu überprüfen, falls es hier Änderungen gab oder etwas zu ändern gibt.
Phishing-Simulationen
Einer der häufigsten Angriffsvektoren für E-Mails ist Phishing, und viele Anbieter haben Lösungen entwickelt, um diesen Angriff so weit wie möglich zu eliminieren. Es gibt jedoch immer noch E-Mails, die von diesen Lösungen nicht blockiert werden und in der Mailbox eines Benutzers landen. Um diese E-Mails zu erkennen, haben Unternehmen Dienste entwickelt, mit deren Hilfe Benutzer getestet und geschult werden können, um diese Arten von E-Mails zu erkennen. Zu den Anbietern gehören Microsoft, KnowBe4 und viele andere. Ein inhärentes Problem besteht darin, dass die Testnachricht, wenn sie von einer externen Quelle stammt, in der Regel von EOP blockiert wird und nie in die Mailbox eines Benutzers gelangt. Um dies zu verhindern, haben viele Anbieter die Organisationen angewiesen, Transportregeln zu erstellen, die die Erkennungsfilter in EOP umgehen. Microsoft hat eine neue Funktion hinzugefügt, um diesen Prozess zu vereinfachen. Sie heißt "Advanced Delivery", mit einer Unterfunktion namens "Phishing Simulation". Diese Funktion kann mit PowerShell über das PowerShell-Modul des Security and Compliance Center verwaltet werden.
Wenn Sie diese Ausnahmen erstellen, sollten Sie daran denken, dass durch das Hinzufügen dieser sendenden Server viele der Filterdienste von EOP umgangen werden:
- Filter in EOP und Microsoft Defender für Office 365
- Automatische Bereinigung zur Nullstunde (Zero-hour Purge - ZAP)
- Standardsystemwarnungen (Default system alerts)
- AIR und Clustering in Defender für Microsoft 365 (Automated Investigation and Response)
- Warnungen (Alerts) und AIR werden nicht ausgelöst
- Sichere Links in Defender für Microsoft 365
- Sichere Anhänge in Defender für Microsoft 365
PowerShell cmdlets
Get-PhishSimOverridePolicy
Get-PhishSimOverrideRule
New-PhishSimOverridePolicy
New-PhishSimOverrideRule
Remove-PhishSimOverridePolicy
Remove-PhishSimOverrideRule
Set-PhishSimOverridePolicy
Set-PhishSimOverrideRule
Standardeinstellung (Default Setup)
Wenn wir mit PowerShell nach Richtlinien oder Regeln suchen, sehen wir, dass die Standardkonfiguration in einem Mandanten leer ist:
Wie viele andere Konfigurationselemente in Microsoft 365 bilden diese beiden Cmdlets ein Paar, und wir müssen eine Richtlinie und eine Regel erstellen, um mit dieser Funktion fortzufahren. Im folgenden Abschnitt werden wir diesen Erstellungsprozess durchlaufen.
Hinzufügen einer benutzerdefinierten Konfiguration
Zunächst muss eine Richtlinie erstellt werden, die aufgrund der Beschränkung von Microsoft auf eine Richtlinie pro Mandant den Namen "PhishSimOverridePolicy" tragen muss:
New-PhishSimOverridePolicy -Name ' PhishSimOverridePolicy'
Mit dieser neuen Richtlinie können wir nun die Regel erstellen, die steuert, welche Server mit dem Mandanten kommunizieren dürfen. Im folgenden Einzeiler verweisen wir auf die erstellte Richtlinie, die IPs der Phishing-Simulations-Absender von Drittanbietern sowie auf zwei Domänen, für die wir eingehende Nachrichten zulassen werden.
New-PhishSimOverrideRule -Name 'PhishSimOverrideRule' -Policy 'PhishSimOverridePolicy' -SenderDomainIs PracticalPowerShell.com,PowerShellGeek.com -SenderIpRanges 147.160.167.0/26, 23.21.109.197,23.21.109.212
Beachten Sie, dass der von Ihnen angegebene Name ignoriert wird und eine neue Regel mit einem ähnlichen Namen erstellt wird:
Wenn die Richtlinie und die Regel konfiguriert sind, wird jede Phishing-Simulation unseres Anbieters, sofern sie von den vordefinierten IPs stammt und für die vordefinierten Domänen bestimmt ist, an die Mailbox eines Endbenutzers zugestellt.
VERWEIS:
Die gleichen Einstellungen werden auch im Microsoft Defender Center angezeigt:
E-Mail & Collaboration > Richtlinien > Bedrohungsrichtlinien > Erweiterte Zustellung
(Email & Collaboration > Policies > Threat Policies > Advanced Delivery)
Post-Konfiguration
Sobald die Richtlinie/Regel fertig ist, können wir PowerShell-Cmdlets ausführen, um die Konfiguration zu überprüfen, beispielsweise zu Validierungs- oder Dokumentationszwecken. Diese beiden Cmdlets erfüllen diesen Zweck und benötigen keine Parameter zur Ausführung:
Get-PhishSimOverridePolicy
Get-PhishSimOverrideRule
SecOps-Mailbox
Zunächst einmal: Was ist eine SecOps Mailbox? SecOps ist die Abkürzung für Security Operations, wird aber auch als Abkürzung für das Sicherheitsteam einer Organisation verwendet. Die Mailbox ist eine dedizierte Mailbox, die ungefilterte E-Mails (ob bösartig oder nicht) zur Überprüfung durch das Sicherheitsteam empfangen kann. Um diese Funktion zu nutzen, muss ein spezielles Postfach für diesen Zweck identifiziert oder erstellt werden. Sobald die Mailbox fertig ist, können wir mit PowerShell unsere Richtlinien- und Regelkombination für die SecOps Mailbox-Funktion erstellen.
Standardmäßig sollte der Tenant einer Organisation keine aufgeführt haben:
Schauen wir uns an, welche PowerShell-Cmdlets uns für die Konfiguration dieser Funktion zur Verfügung stehen:
PowerShell Cmdlets
Get-SecOpsOverridePolicy
Get-SecOpsOverrideRule
New-SecOpsOverridePolicy
New-SecOpsOverrideRule
Remove-SecOpsOverridePolicy
Remove-SecOpsOverrideRule
Set-SecOpsOverridePolicy
Set-SecOpsOverrideRule
Neue Richtlinie / Regel erstellen
Beim Erstellen einer Richtlinie und einer Regel benötigen wir nur die E-Mail-Adresse des Postfachs, das für diese Funktion verwendet werden soll. Der Name der Richtlinie und der Regel kann nicht angepasst werden. Sie müssen die von Microsoft vorgegebenen Namen verwenden. Die Namen von beiden finden Sie in der Dokumentation der Cmdlets: New-SecOpsOverridePolicy und New-SecOpsOverrideRule. Sobald wir diese Informationen haben, können wir die Kombination aus Richtlinie und Regel erstellen:
New-SecOpsOverridePolicy -Name SecOpsOverridePolicy -SentTo SecurityTeam@powershellgeek.com
New-SecOpsOverrideRule -Name SecOpsOverrideRule -Policy SecOpsOverridePolicy
Beachten Sie, dass nur eine Richtlinie und eine Regel für SecOps Overrides zulässig sind:
Ändern einer bestehenden Richtlinie / Regel
Wenn Richtlinie und Regel vorhanden sind, können wir natürlich auch die Einstellungen ändern, wenn dies erforderlich wird. Aber so normal das in PowerShell auch sein mag, es gibt nicht viel zu ändern, weder in der Richtlinie noch in der Regel. In der Richtlinie zeigt die Get-Help für das Cmdlet viele Optionen an, aber in Wirklichkeit können wir mit beiden Cmdlets nur die Eigenschaften Comment und SentTo ändern. Hier sind einige Beispiele für diese Parameter in Aktion:
Richtlinien (Policies):
Set-SecOpsOverridePolicy -Identity SecOpsOverridePolicy -Comment 'Sec Ops Policy – Security Team Mailbox'
Set-SecOpsOverridePolicy -Identity SecOpsOverridePolicy -Comment -AddSendTo ITManagers@powerShellgeek.com
Set-SecOpsOverridePolicy -Identity SecOpsOverridePolicy -Comment -RemoveSentTo securityTeam@powerShellgeek.com
Regeln (Rules):
Get-SecOpsOverrideRule | Set-SecOpsOverRideRule -Comment 'Sec Ops Rule for PowerShellGeek.com'
Entfernen einer SecOps-Postfachrichtlinie/-regel
Wenn diese Funktion nicht mehr benötigt wird, kann sie auch mit zwei Einzeilern aus dem Tenant entfernt werden:
Get-SecOpsOverridePolicy | Remove-SecOpsOverridePolicy
Get-SecOpsOverridePolicy | Remove-SecOpsOverridePolicy
Abschließende Überlegungen – Fazit
Defender für Microsoft 365 hat viele Komponenten, von denen wir in diesem Artikel nur einige erkunden. Da es sich hierbei um neue Funktionen für Defender für Microsoft 365 handelt, sollten Sie davon ausgehen, dass im Laufe der Zeit weitere Funktionen hinzugefügt werden. Nicht jede Organisation wird diese Funktionen nutzen, da einige Organisationen den Angriffssimulator von Microsoft verwenden und keinen Sicherheitsdienstleister vor EOP haben und daher möglicherweise nur die SecOps Mailbox-Funktion nutzen. Andere Unternehmen werden alle drei Funktionen nutzen, weil sie einen Drittanbieter für Phishing-Simulationen und E-Mail-Sicherheit haben. Daher muss jede dieser Funktionen von einer Organisation bewertet werden, um ihre Bedürfnisse und Szenarien zu bestimmen.
Webinar (englisch):
Automating Exchange / Exchange Online like a Pro
– with Damian Scoles (MVP) –
Haben Sie häufig wiederkehrende Aufgaben im täglichen Betrieb von Exchange / Exchange Online?
Dazu gehören z.B. das Anlegen neuer Postfächer, das Erstellen/Bearbeiten von Abwesenheitseinstellungen für Mitarbeiter im Krankenstand, die Überwachung von Postfachgrößen oder die Verwaltung von Verteilerlisten.
PowerShell bietet gute Möglichkeiten, diese und viele andere Aufgaben zu automatisieren. Mit ScriptRunner wird der Umgang mit der PowerShell komfortabler und noch teamfähiger. Damit befreien Sie sich von Routineaufgaben und etablieren PowerShell Schritt für Schritt als Automatisierungswerkzeug in Ihren Geschäftsprozessen.
Wir freuen uns, dass wir den langjährigen MVP Damian Scoles für dieses Webinar gewinnen konnten. Er ist zehnfacher Microsoft MVP mit den Schwerpunkten Exchange, Office 365 und PowerShell und bringt über 25 Jahre Erfahrung in der IT-Branche mit. In diesem Webinar bringt Damian Scoles Ihnen das Thema näher und gibt Ihnen wertvolle Tipps!
Dieses Webinar richtet sich an Administratoren, IT- und DevOps-Profis, PowerShell-Entwickler und IT-Manager.
Die Themen unseres (englischen) Webinars:
- Die Möglichkeiten der Exchange PowerShell-Module.
- Wie Sie die PowerShell-basierte Verwaltung von Postfächern über eine Weboberfläche sicher an Service Desk-Mitarbeiter delegieren können.
- Erlauben Sie Benutzern die Ausführung bestimmter PowerShell-Skripte, ohne ihnen administrative Active Directory-Rechte zu geben.
- Einfaches Verwalten, Wiederholen und Überwachen von PowerShell-Skripten.
- Die vorgefertigten Skripte (ActionPacks) von ScriptRunner unterstützen Sie bei der Exchange-Administration.
Hier geht es zur Aufzeichnung!
Related Links / Weiterführende Links
- ScriptRunner ActionPacks for Microsoft 365 - Exchange Online
- Message Labs documentation "Connect: Configuring Inbound Delivery Routing for Microsoft 365"
- Documentation for the cmdlets: New-SecOpsOverridePolicy and New-SecOpsOverrideRule
- ScriptRunner: Try out our Software and get our free demo here!
Zusammenhängende Posts
Über den Autor:
Damian Scoles ist ein zehnfacher Microsoft MVP mit Spezialisierung auf Exchange, Office 365 und PowerShell, der über 25 Jahre Erfahrung in der IT-Branche mitbringt. Er ist im Großraum Chicago ansässig und begann mit der Verwaltung von Exchange 5.5 und Windows NT. Im Laufe der Jahre hat er mit Office 365 seit BPOS gearbeitet und darüber hinaus Erfahrung mit Azure AD, Security and Compliance Admin Centers und Exchange Online. Zu seinem Engagement in der Community gehören Beiträge in TechNet-Foren, die Erstellung von PowerShell-Skripten, die in seinen Blogs zu finden sind, das Schreiben von ausführlichen PowerShell/Office365/Exchange-Blogartikeln, Tweets und die Erstellung von PowerShell-Videos auf YouTube. Er hat fünf PowerShell-Bücher geschrieben und arbeitet außerdem aktiv an dem Buch "Microsoft 365 Security for IT Pros".