Skip to the main content.

ScriptRunner Blog

PowerShell und Exchange Online-Sicherheit

Inhaltsverzeichnis

Post Featured Image

Hacker. Spammer. Phishing. Oh weh! (Okay, das war ein Klischee.)

Aber mal in Ernst: Exchange Online ist einer Vielzahl von Angriffen, Angriffsvektoren und Übeltätern ausgesetzt. Der Job eines Administrators ist mit dem Wechsel zu Cloud-Diensten in Bezug auf die Sicherheit schwieriger geworden. Unternehmen wie Microsoft bemühen sich jedoch, diese Ängste zu zerstreuen und Exchange Online-Admins Tools zur Verfügung zu stellen, mit denen sie diese Bedrohungen bewältigen können. In diesem Artikel sehen wir uns an, wie Sie PowerShell nutzen können, um Sicherheit für Exchange Online zu gewährleisten.

 

Authentifizierungstypen

Zunächst werfen wir einen Blick auf das Konzept der Authentifizierung:

Basic Authentication

Basic Authentication verwendet eine Passwort-Abfrage/Antwort für jede Interaktion mit einer Ressource in Exchange Online. Weitere Zugriffsanforderungen sind nicht implementiert. Wenn eine Verbindung zu Exchange Online nicht sicher ist, könnte das Kennwort abgefangen werden.

Modern Authentication

Modern Authentication basiert auf der Verwendung von OAUTH 2.0 und ADAL (Active Directory Authentication Library) unter Verwendung von Token-basierter Authentifizierung, die wesentlich mehr Sicherheit bietet.
Bei älteren Tenants ist Modern Auth möglicherweise deaktiviert, während es bei neueren Tenants standardmäßig aktiviert ist. Wir können unseren Tenant überprüfen, indem wir diesen Einzeiler in der Exchange Online PowerShell ausführen:

Get-OrganizationConfig | Ft OAuth2ClientProfileEnabled

Die nachfolgende Ausgabe zeigt, dass Modern Authentication aktiviert ist:

Bild1-3

Wäre dies false, wäre Modern Auth ausgeschaltet, was gegen die Best Practices für Office 365 verstößt und auch keine sehr sichere Haltung darstellt. Stellen Sie sicher, dass dies aktiviert ist. Beachten Sie, dass dies nicht verhindert, dass sich Basic Auth-Clients mit Exchange Online verbinden. Es gibt andere Möglichkeiten, dies zu tun.

Der nächste Schritt ist das Blockieren von Basic Auth!

 

Authentifizierungsrichtlinie

Das Blockieren von Basic Auth für Exchange Online kann über mindestens zwei verschiedene Methoden erfolgen. Eine davon ist der bedingte Zugriff, auf den wir nicht näher eingehen werden (aber er kann mit PowerShell durchgeführt werden!), und die andere Methode ist eine sogenannte Authentifizierungsrichtlinie. Mit einer Authentifizierungsrichtlinie können wir steuern, welche Aspekte von Exchange Online Basic Auth verwenden oder nicht verwenden können. Zunächst einmal, was ist die Standardkonfiguration für eine Authentifizierungsrichtlinie? Nun, eigentlich keine!

Get-AuthenticationPolicy | fl
Bild2-1

Okay. Nun, wenn es keine Richtlinie gibt, was können wir dann tun? Wir erstellen eine. Mit PowerShell ODER durch eine Änderung im M365 Admin Center. Wie stellen wir das an? Zuerst müssen wir die Standard-Authentifizierungsrichtlinie finden. Die Authentifizierungsrichtlinie befindet sich im M365 Admin Center unter Settings→ Org Settings → Modern Authentication, wo wir Folgendes vorfinden:

Bild3-1

Damit die Richtlinie in der PowerShell erscheint, entfernen wir einfach ein Häkchen bei einem Punkt, sagen wir IMAP, speichern die Einstellungen und warten 15-30 Sekunden. Nach dem Warten können wir Folgendes ausführen:

Get-AuthenticationPolicy | fl

Bild4-1

um die vorgenommene Änderung zu sehen:

Beachten Sie, dass AllowBasicAuthIMAP deaktiviert ist. Um Basic Auth für alle diese Protokolle zu blockieren, können wir diesen Einzeiler ausführen:

Set-AuthenticationPolicy -Identity 'BlockBasic637530830181380023' -AllowBasicAuthActiveSync:$False -AllowBasicAuthAutodiscover:$False -AllowBasicAuthImap:$False -AllowBasicAuthMapi:$False -AllowBasicAuthOfflineAddressBook:$False -AllowBasicAuthOutlookService:$False -AllowBasicAuthPop:$False -AllowBasicAuthReportingWebServices:$False -AllowBasicAuthRest:$False -AllowBasicAuthRpc:$False -AllowBasicAuthSmtp:$False -AllowBasicAuthWebServices:$False -AllowBasicAuthPowershell:$FalsengWebServices $False -AllowBasicAuthRpc $False -AllowBasicAuthSmtp $False -AllowBasicAuthWebServices $False -AllowBasicAuthPowershell $False
und überprüfen Sie die Änderungen:
Get-AuthenticationPolicy | fl

Bild5-1

Wir haben jetzt Basic für die gesamte Liste der Verbindungstypen deaktiviert, die für die Verbindung mit Exchange Online verfügbar sind.

 

Protokoll-Einschränkungen

Für Exchange Online bietet Microsoft viele Protokolle für Endanwender an, um eine Verbindung zu ihrem Postfach herzustellen. Wir haben IMAP, POP, ActiveSync, ECP, MAPI, OWA und mehr. Typischerweise wollen wir weniger sichere Protokolle wie IMAP4 und POP3 blockieren, damit die Anwender diese nicht einsetzen, um sich mit einem Postfach zu verbinden. Wir können diese Verbindungen mit den CasMailboxPlan-Cmdlets steuern. Im Allgemeinen gibt es in Exchange Online vier Haupt-CAS-Postfachpläne, aber diese Anzahl kann je nach Lizenzierungsmodell variieren.

Für unser Beispiel haben wir einen Exchange Online-Tenant mit entweder E3- oder E5-Lizenzierung.

Wenn wir Get-CasMailboxPlan| Ft Name

ausführen, werden diese Pläne angezeigt:

Bild6-1

  1. Deskless
  2. Regular
  3. Enterprise und
  4. Essentials

Wir können anzeigen, was in einem dieser Pläne verfügbar ist, indem wir dieses Cmdlet ausführen:

Get-CASMailboxPlan ExchangeOnlineEnterprise-a198b3f1-d047-49ed-b00d-b9ae84d0390a | Fl *Enabled

Bild7-1

Wenn wir nun Protokolle deaktivieren müssen, IMAP und POP sind die besten Kandidaten, können wir dies wie folgt tun:

Set-CASMailboxPlan -Identity ExchangeOnlineEnterprise-a198b3f1-d047-49ed-b00d-b9ae84d0390a -IMAPEnabled $False -POPEnabled $False

Mit diesem Einzeiler können wir diese Änderung für alle Pläne auf einmal vornehmen:

Get-CASMailboxPlan | Set-CASMailboxPlan -IMAPEnabled $False -POPEnabled $False

Damit haben wir nun die Angriffsmöglichkeiten für den Zugriff auf Exchange Online-Postfächer reduziert.

 

OWA Offline-Modus

Eine der oft übersehenen Funktionen von Webmail, bekannt als OWA, ist die Funktion des Offline-Modus. Diese Funktion hinterlässt eine unverschlüsselte Kopie der letzten 500 E-Mails auf Ihrem Gerät, auf die Sie einfach zugreifen können, während Sie nicht verbunden sind. Die Theorie ist, dass Vielreisende in der Lage sind, mit ihren letzten E-Mails zu arbeiten, Antworten zu erstellen und mit den in den letzten E-Mails enthaltenen Informationen zu arbeiten. Allerdings ist die fehlende Verschlüsselung die Achillesferse dieses Setups.

Wir können uns das mit der PowerShell für die OWA Mailbox Policies wie folgt ansehen:

Get-OwaMailboxPolicy | Ft AllowOfflineOn
Bild10-1

Wir sehen, dass sie tatsächlich eingeschaltet ist. Wie schalten wir sie nun aus? Nun, wir haben drei Optionen für AllowOfflineOn – PrivateComputersOnly, NoComputers oder AllComputers.

Der Wert, den wir brauchen, ist „NoComputers“, daher benötigt man zum Deaktivieren den Namen der Richtlinie und die Parameter für AllowOfflineOn:

Set-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default -AllowOfflineOn NoComputers

Wenn wir mehr als eine OWA-Mailbox-Richtlinie haben, können wir sie für alle auf einmal deaktivieren:

Get-OwaMailboxPolicy | Set-OwaMailboxPolicy -AllowOfflineOn NoComputers

Die Anwender können den Offline-Modus nun nicht mehr für OWA verwenden und ihre E-Mails sind sicherer.

 

Nachrichtenfluss – EOP und Microsoft Defender für Office 365 (ehemals ATP)

Abhängig von der Lizenzierung und den in Exchange Online aktivierten Funktionen können EOP und Defender für Office 365 eine vielschichtige Verteidigung gegen bösartige E-Mails bieten. Diese Schichten umfassen Anti-Spam, Anti-Phishing und mehr.

Um zunächst zu beurteilen, wo wir uns befinden, können wir ein PowerShell-Modul namens ORCA verwenden, um nach Lücken zu suchen. ORCA ist eine Abkürzung für „Office 365 ATP Recommended Configuration Analyzer Report“, der so genannt wurde, bevor Microsoft das gesamte Namensschema für seine Produkte geändert hat.

Genauer gesagt prüft dieses Script nun Ihren Defender auf Office 365-Konfiguration. Wir können dieses Modul installieren, indem wir ein Windows PowerShell-Fenster öffnen und diesen Code eingeben:

Install-Module ORCA

Wir können einen schnellen Bericht starten, indem wir Folgendes ausführen:
Get-ORCAReport

Wir werden nach Anmeldeinformationen für ein globales Administratorkonto in Office 365 gefragt, und dann führt das Script seine Analyse durch:

Bild11-1

Eine ähnliche Funktion können wir auch im Security and Compliance Center unter dem Namen „Configuration Analyzer“ sehen. Bemerkenswert ist, dass die Problembehebung hier vollständig in der GUI liegt. Bei der großen Anzahl von Validierungsprüfungen (über 60) wäre eine Scriptlösung zur Behebung dieser Probleme für die meisten Admins unerreichbar.

Dieses PowerShell-Modul sollte für einmalige oder automatisierte Berichte über den aktuellen Stand des Schutzes verwendet werden. Die Problem-Behebung über PowerShell liegt aufgrund der Komplexität der Konfiguration und des Umfangs der Funktionen / PowerShell-Cmdlets, die für diese Aufgabe erforderlich sind, außerhalb des Rahmens dieses Artikels.

Wenn ein Tenant aus irgendeinem Grund nicht über eine Lizenz für Defender für Office 365 verfügt, sollten die Funktionen getestet werden, um den Wert des Produkts zu beurteilen.

Wir können den Testmodus im Security and Compliance Center aktivieren → Threat Management → Policy → Evaluate Defender for Office 365.

Bild12-1

Die Demo bleibt bis zu 90 Tage lang aktiv und das Reporting ist in der Evaluierung enthalten.

 

Role Based Access Control (RBAC)

Exchange war eines der ersten Produkte, das das Konzept der rollenbasierten Zugriffskontrolle erhielt, bei dem Operationen und Funktionen in Exchange über Rollengruppen und Verwaltungsrollen gewährt werden.

Management-Rollen sind die detaillierteren Berechtigungen für den Zugriff auf Exchange-Funktionen wie Journaling, Legal Hold und mehr. Rollengruppen hingegen sind Gruppierungen dieser Managementrollen, um logisch eine Jobfunktion oder eine Rolle zu erstellen, die jemand erfüllen kann, um legitime Aufgaben in Exchange zu erledigen.

Jetzt sind diese Konzepte von Exchange zu Exchange Online übergegangen.

Write-Host " Role Group Members "

Write-Host "----------------------"

$RoleGroup = Get-RoleGroup

Foreach ($Group in $RoleGroup) {

    $Name = $Group.Name


    $Members = Get-RoleGroupMember -Identity $Name

    If ($Null -ne $Members) {

        Write-Host "$Name "+": "

        Foreach ($Member in $Members) {

                $MemberName = $Member.Name

                write-Host " - $MemberName"

        }

        Write-Host ''

    } Else {

        Write-Host "** $Name hat keine Mitglieder."

        Write-Host ''
    }
}

Dieser Code hilft uns herauszufinden, ob es zu viele Anwender gibt, die hoch privilegierten Rollen zugewiesen sind:

Bild14-1

Im gegebenen Fall hat keine Gruppe mehr als drei Benutzer in einer Rollengruppe. Für die meisten Szenarien ist dies eine gute Zahl, mit der man arbeiten kann.

Nachdem der Bericht ausgeführt wurde, sollte jede Gruppe auf gültige Konten geprüft werden und ob der betreffende Benutzer noch in dieser Rollengruppe sein muss. Wenn nicht, sollten die Konten entfernt werden. Zusätzlich sollte eine Überprüfung dieser Zuweisungen regelmäßig in Verbindung mit anderen Sicherheitsüberprüfungen stattfinden.

 

 

Kostenloses Webinar

Exchange-/O365-Administration mit PowerShell automatisieren und delegieren

download-2Gibt es bei Ihnen häufig wiederkehrende Aufgaben im täglichen Betrieb von Exchange / Exchange Online? Hier erfahren Sie, wie Sie:

  • PowerShell-basierte Aufgaben zur Postfachverwaltung sicher delegieren können
  • Anwendern die Ausführung bestimmter PowerShell-Scripte erlauben, ohne ihnen administrative Rechte zu geben
  • PowerShell-Scripte einfach verwalten, abrufen und überwachen können
  • die kostenlosen PowerShell-Scripts aus dem ScriptRunner ActionPack für Exchange Online verwenden

Sehen Sie sich das Webinar kostenlos an >

 

 

Multi-Faktor-Authentifizierung

In Office 365 gibt es auch einige Möglichkeiten, wie wir MFA für Anwender in einem Tenant aktivieren können. Wir können Conditional Access, Security Defaults verwenden oder sie individuell zuweisen. In diesem Artikel werden wir als Beispiel dafür, wie wir Anwender in einem Tenant absichern können, ausführen, wie dies über die individuelle Zuweisung geschieht.

Bevor wir uns damit befassen, lassen Sie uns zunächst erläutern, warum die Multi-Faktor-Authentifizierung verwendet werden sollte:

  • erhöht die Sicherheit – erschwert es Angreifern, Benutzerkonten zu kompromittieren
  • reduziert Bedrohungen um über 99 %

Microsoft bietet zahlreiche Ressourcen zu diesem Thema. Hier finden Sie eine gute Anlaufstelle dazu.

Um MFA auf Benutzerebene zu aktivieren, müssen wir uns zunächst über ein PowerShell-Modul mit dem MSOL-Dienst verbinden.

Wenn Sie dieses nicht installiert haben, holen Sie das nach, indem Sie Folgendes ausführen:

Install-Module MSOnline

Nach der Installation können wir die Verbindung zum MSOL-Dienst wie folgt starten:
Connect-MsolService

Dann führen wir diese Zeilen aus, um die MFA-Zuweisung für die Benutzer zu erstellen:
$st = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement

$st.RelyingParty = "*"

$st.State = "Enabled"

$sta = @($st)

Wir können dies dann für einen Benutzer wie folgt einstellen:
Set-MsolUser -UserPrincipalName damian@practicalpowershell.com -StrongAuthenticationRequirements $sta

Nach Fertigstellung können wir die Einstellungen überprüfen:
(Get-MsolUser -UserPrincipalName Damian@practicalpowershell.com).StrongAuthenticationRequirements | Fl

 

Jetzt müssen wir die ganze Prozedur nur noch für alle Benutzer, die MFA benötigen wiederholen. Sobald wir damit fertig sind, können wir mit diesem Code überprüfen, welche Benutzer die Einstellung jetzt besitzen:

Get-MsolUser -All | Where {$_.StrongAuthenticationRequirements -ne $Null} |ft DisplayName, UserPrincipalName,StrongAuthenticationRequirements

Und wir sehen unsere aktivierten Benutzer:

Damit können wir überprüfen, ob unsere Benutzer MFA auf Benutzerbasis aktiviert haben.

Bild16-1

 

Fazit

Wenn wir uns die oben durchgeführten Konfigurationseinstellungen ansehen, können wir einige Schlussfolgerungen über Sicherheit, PowerShell und Exchange Online ziehen:

  • Es kann kompliziert sein
  • Microsoft bietet eine mehrschichtige Verteidigung gegen mehrere Angriffsvektoren
  • Wir können all dies in PowerShell umsetzen

Um ein umfassenderes Verständnis der obigen PowerShell-Funktionen und der durchgeführten Sicherheitsmaßnahmen zu erhalten, sollten Sie die Docs-Seiten von Microsoft zu den einzelnen Themen lesen. Mit diesem Artikel und den Docs-Seiten werden Sie in der Lage sein, die oben genannten Aufgaben zu bewältigen und sie sicher für Ihren Mandanten zu konfigurieren. Sicherheit ist der Schlüssel in Exchange Online, also vergewissern Sie sich, dass Sie die oben genannten Funktionen auf Ihren Tenant anwenden.

 

Zusammenhängende Posts

2 min read

VMUG Webcast: VMware Management meistern mit PowerCLI

5 min read

PowerShell mit Get-Help meistern

Über den Autor: