Microsoft Defender and PowerShell – Lösungen für die Migration zu Exchange Online

Inhaltsverzeichnis

 

 

Post Featured Image

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 

01_Hygiene Service and Exchange Mailbox before

Nachher

02_Hygiene Service and Exchange Mailbox after

 

 

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:

03_screenshot from greenfield environment

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:

04_

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:

05_

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:

06_

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

07_

Get-PhishSimOverrideRule

08_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:

09_

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:

10_


Ä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

11_

Get-SecOpsOverridePolicy | Remove-SecOpsOverridePolicy

12_

 

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.

 

Good2know

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.

 

 

exchange-webinar-microsoft-mvp-damian-scoles-landscape

 

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

Zusammenhängende Posts

Über den Autor: