Verwalten der Windows-Firewall über die Befehlszeile
Dieser Artikel enthält Beispiele zum Verwalten der Windows-Firewall mit PowerShell und netsh.exe, die zum Automatisieren der Verwaltung der Windows-Firewall verwendet werden können.
Festlegen globaler Standardeinstellungen für Profile
Globale Standardwerte legen das Geräteverhalten pro Profil fest. Die Windows-Firewall unterstützt Domänenprofile, private und öffentliche Profile.
Die Windows-Firewall löscht Datenverkehr, der nicht dem zulässigen unerwünschten Datenverkehr entspricht, oder Datenverkehr, der als Reaktion auf eine Anforderung vom Gerät gesendet wird. Wenn Sie feststellen, dass die von Ihnen erstellten Regeln nicht erzwungen werden, müssen Sie möglicherweise die Windows-Firewall aktivieren. So aktivieren Sie die Windows-Firewall auf einem lokalen Gerät:
PowerShell
EingabeaufforderungSet-NetFirewallProfile -Profile Domain,Public,Private -Enabled True
Steuern des Verhaltens der Windows-Firewall
Die globalen Standardeinstellungen können über die Befehlszeilenschnittstelle definiert werden. Diese Änderungen sind auch über die Windows-Firewall-Konsole verfügbar. Die folgenden Scriptlets legen die standardmäßigen ein- und ausgehenden Aktionen fest, geben geschützte Netzwerkverbindungen an und ermöglichen die Anzeige von Benachrichtigungen für den Benutzer, wenn das Empfangen eingehender Verbindungen durch ein Programm blockiert wird. Es ermöglicht Unicastantworten auf Multicast- oder Broadcast-Netzwerkdatenverkehr und gibt Protokollierungseinstellungen für die Problembehandlung an.
Set-NetFirewallProfile -DefaultInboundAction Block -DefaultOutboundAction Allow -NotifyOnListen True -AllowUnicastResponseToMulticast True -LogFileName %SystemRoot%\System32\LogFiles\Firewall\pfirewall.log
Deaktivieren der Windows-Firewall
Microsoft empfiehlt, die Windows-Firewall nicht zu deaktivieren, da Sie andere Vorteile verlieren, z. B. die Möglichkeit, IPsec-Verbindungsregeln (Internet Protocol Security) zu verwenden, netzwerkschutz vor Angriffen, die Netzwerkfingerabdrücke verwenden, Windows-Diensthärtung und Startzeitfilter. Nicht-Microsoft-Firewallsoftware kann programmgesteuert nur die Regeltypen der Windows-Firewall deaktivieren, die aus Kompatibilitätsgründen deaktiviert werden müssen. Sie sollten die Firewall zu diesem Zweck nicht selbst deaktivieren. Wenn die Deaktivierung der Windows-Firewall erforderlich ist, deaktivieren Sie sie nicht, indem Sie den Windows-Firewalldienst beenden (im Snap-In Dienste lautet der Anzeigename Windows Defender Firewall, und der Dienstname lautet MpsSvc). Das Beenden des Windows-Firewalldiensts wird von Microsoft nicht unterstützt und kann Probleme verursachen, einschließlich:
- Startmenü kann nicht mehr funktionieren
- Moderne Anwendungen können nicht installiert oder aktualisiert werden.
- Fehler bei der Aktivierung von Windows per Telefon
- Anwendungs- oder Betriebssysteminkompatibilitäten, die von der Windows-Firewall abhängen
Die richtige Methode zum Deaktivieren der Windows-Firewall besteht darin, die Windows-Firewallprofile zu deaktivieren und den Dienst laufen zu lassen. Gehen Sie wie folgt vor, um die Firewall zu deaktivieren oder die Gruppenrichtlinie Einstellung Computerkonfiguration|Administrative Vorlagen |Netzwerk|Netzwerk Connections|Windows-Firewall |Domain Prolfile |Windows-Firewall: Schützen Sie alle Netzwerkverbindungen. Weitere Informationen finden Sie im Bereitstellungshandbuch zur Windows-Firewall. Im folgenden Beispiel wird die Windows-Firewall für alle Profile deaktiviert.
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False
Bereitstellen grundlegender Firewallregeln
Dieser Abschnitt enthält Skriptletbeispiele zum Erstellen, Ändern und Löschen von Firewallregeln.
Erstellen von Firewallregeln
Das Hinzufügen einer Firewallregel in Windows PowerShell sieht ähnlich aus wie in Netsh, aber die Parameter und Werte werden unterschiedlich angegeben. Hier sehen Sie ein Beispiel dafür, wie Sie zulassen, dass die Telnet-Anwendung im Netzwerk lauscht. Diese Firewallregel ist auf das lokale Subnetz ausgerichtet, indem anstelle einer IP-Adresse ein Schlüsselwort (keyword) verwendet wird. Genau wie in Netsh wird die Regel auf dem lokalen Gerät erstellt und wird sofort wirksam.
New-NetFirewallRule -DisplayName "Allow Inbound Telnet" -Direction Inbound -Program %SystemRoot%\System32\tlntsvr.exe -RemoteAddress LocalSubnet -Action Allow
Das folgende Scriptlet zeigt, wie Sie eine grundlegende Firewallregel hinzufügen, die ausgehenden Datenverkehr von einer bestimmten Anwendung und einem lokalen Port zu einem Gruppenrichtlinie Object (GPO) in Active Directory blockiert. In Windows PowerShell wird der Richtlinienspeicher als Parameter im Cmdlet New-NetFirewall angegeben. In Netsh müssen Sie zuerst das Gruppenrichtlinienobjekt angeben, das die Befehle in einer Netsh-Sitzung ändern sollen. Die von Ihnen eingegebenen Befehle werden für den Inhalt des Gruppenrichtlinienobjekts ausgeführt, und die Ausführung bleibt wirksam, bis die Netsh-Sitzung beendet wird oder bis ein anderer set store-Befehl ausgeführt wird. Hier ist domain.contoso.com der Name Ihres Active Directory Domain Services (AD DS), und gpo_name ist der Name des Gruppenrichtlinienobjekts, das Sie ändern möchten. Anführungszeichen sind erforderlich, wenn im Gruppenrichtlinienobjektnamen Leerzeichen vorhanden sind.
New-NetFirewallRule -DisplayName "Block Outbound Telnet" -Direction Outbound -Program %SystemRoot%\System32\tlntsvr.exe -Protocol TCP -LocalPort 23 -Action Block -PolicyStore domain.contoso.com\gpo_name
GPO-Zwischenspeicherung
Um den Aufwand für ausgelastete Domänencontroller zu verringern, können Sie Windows PowerShell ein Gruppenrichtlinienobjekt in Ihre lokale Sitzung laden, alle Änderungen in dieser Sitzung vornehmen und es dann jederzeit wieder speichern. Der folgende Befehl führt die gleichen Aktionen wie im vorherigen Beispiel aus (durch Hinzufügen einer Telnet-Regel zu einem Gruppenrichtlinienobjekt), aber dazu wenden wir die Zwischenspeicherung von Gruppenrichtlinienobjekten in PowerShell an. Das Ändern des Gruppenrichtlinienobjekts durch Laden in Ihre lokale Sitzung und verwendung des Parameters -GPOSession wird in Netsh nicht unterstützt.
$gpo = Open-NetGPO -PolicyStore domain.contoso.com\gpo_name
New-NetFirewallRule -DisplayName "Block Outbound Telnet" -Direction Outbound -Program %SystemRoot%\System32\telnet.exe -Protocol TCP -LocalPort 23 -Action Block -GPOSession $gpo
Save-NetGPO -GPOSession $gpo
Dieser Befehl führt keine Batches für Ihre einzelnen Änderungen aus, er lädt und speichert das gesamte Gruppenrichtlinienobjekt auf einmal. Wenn also andere Änderungen von anderen Administratoren oder in einem anderen Windows PowerShell Fenster vorgenommen werden, überschreibt das Speichern des Gruppenrichtlinienobjekts diese Änderungen.
Ändern einer vorhandenen Firewallregel
Wenn eine Regel erstellt wird, können Sie mit Netsh und Windows PowerShell Regeleigenschaften und Einfluss ändern, aber die Regel behält ihren eindeutigen Bezeichner bei (in Windows PowerShell wird dieser Bezeichner mit dem Parameter -Name angegeben). Beispielsweise könnten Sie über eine Regel Web 80 zulassen verfügen, die TCP-Port 80 für eingehenden nicht angeforderten Datenverkehr aktiviert. Sie können die Regel so ändern, dass sie mit einer anderen Remote-IP-Adresse eines Webservers übereinstimmt, dessen Datenverkehr zugelassen wird, indem Sie den lesbaren, lokalisierten Namen der Regel angeben.
Set-NetFirewallRule -DisplayName "Allow Web 80" -RemoteAddress 192.168.0.2
Netsh erfordert, dass Sie den Namen der Regel angeben, damit sie geändert werden kann, und wir haben keine alternative Möglichkeit, die Firewallregel zu erhalten. In Windows PowerShell können Sie die Regel mithilfe ihrer bekannten Eigenschaften abfragen.
Wenn Sie ausführen Get-NetFirewallRule, stellen Sie möglicherweise fest, dass allgemeine Bedingungen wie Adressen und Ports nicht angezeigt werden. Diese Bedingungen werden in separaten Objekten dargestellt, die als Filter bezeichnet werden. Wie bereits gezeigt, können Sie alle Bedingungen in New-NetFirewallRule und Set-NetFirewallRule festlegen. Wenn Sie Firewallregeln abfragen möchten, die auf diesen Feldern (Ports, Adressen, Sicherheit, Schnittstellen, Dienste) basieren, müssen Sie die Filterobjekte selbst abrufen.
Sie können den Remoteendpunkt der Regel Web 80 zulassen (wie zuvor geschehen) mithilfe von Filterobjekten ändern. Wenn Sie Windows PowerShell verwenden, fragen Sie mithilfe des Portfilters nach Port ab. Wenn dann andere Regeln vorhanden sind, die sich auf den lokalen Port auswirken, erstellen Sie mit weiteren Abfragen, bis die gewünschte Regel abgerufen wird.
Im folgenden Beispiel wird davon ausgegangen, dass die Abfrage eine einzelne Firewallregel zurückgibt, die dann an das Set-NetFirewallRule Cmdlet weitergeleitet wird, indem Windows PowerShell die Fähigkeit von Pipelineeingaben nutzt.
Get-NetFirewallPortFilter | ?{$_.LocalPort -eq 80} | Get-NetFirewallRule | ?{ $_.Direction -eq "Inbound" -and $_.Action -eq "Allow"} | Set-NetFirewallRule -RemoteAddress 192.168.0.2
Sie können auch Regeln mithilfe des Wildcardzeichens abfragen. Im folgenden Beispiel wird ein Array von Firewallregeln zurückgegeben, das einem bestimmten Programm zugeordnet ist. Die Elemente des Arrays können in nachfolgenden Set-NetFirewallRule Cmdlets geändert werden.
Get-NetFirewallApplicationFilter -Program "*svchost*" | Get-NetFirewallRule
Mehrere Regeln in einer Gruppe können gleichzeitig geändert werden, wenn der zugeordnete Gruppenname in einem Set-Befehl angegeben wird. Sie können Firewallregeln zu angegebenen Verwaltungsgruppen hinzufügen, um mehrere Regeln mit den gleichen Einflüssen zu verwalten. Im folgenden Beispiel fügen wir der Gruppe Telnet-Verwaltung sowohl eingehende als auch ausgehende Telnet-Firewallregeln hinzu. In Windows PowerShell wird die Gruppenmitgliedschaft angegeben, wenn die Regeln zum ersten Mal erstellt werden, sodass wir die vorherigen Beispielregeln neu erstellen. Das Hinzufügen von Regeln zu einer benutzerdefinierten Regelgruppe ist in Netsh nicht möglich.
New-NetFirewallRule -DisplayName "Allow Inbound Telnet" -Direction Inbound -Program %SystemRoot%\System32\tlntsvr.exe -RemoteAddress LocalSubnet -Action Allow -Group "Telnet Management"
New-NetFirewallRule -DisplayName "Block Outbound Telnet" -Direction Outbound -Program %SystemRoot%\System32\tlntsvr.exe -RemoteAddress LocalSubnet -Action Allow -Group "Telnet Management"
Wenn die Gruppe zum Zeitpunkt der Regelerstellung nicht angegeben ist, kann die Regel der Regelgruppe mit Punktnotation in Windows PowerShell hinzugefügt werden. Sie können die Gruppe nicht mit Set-NetFirewallRule angeben, da der Befehl Abfragen nach Regelgruppe zulässt.
$rule = Get-NetFirewallRule -DisplayName "Allow Inbound Telnet"
$rule.Group = "Telnet Management"
$rule | Set-NetFirewallRule
Wenn der Set Regelgruppenname angegeben ist, wird die Gruppenmitgliedschaft mit Hilfe des Befehls nicht geändert, sondern alle Regeln der Gruppe erhalten die gleichen Änderungen, die von den angegebenen Parametern angegeben werden.
Das folgende Scriptlet aktiviert alle Regeln in einer vordefinierten Gruppe, die die Remoteverwaltung enthält, die Firewallregeln beeinflusst.
Set-NetFirewallRule -DisplayGroup "Windows Firewall Remote Management" -Enabled True
Es gibt auch ein separates Enable-NetFirewallRule Cmdlet zum Aktivieren von Regeln nach Gruppe oder nach anderen Eigenschaften der Regel.
Enable-NetFirewallRule -DisplayGroup "Windows Firewall Remote Management" -Verbose
Löschen einer Firewallregel
Regelobjekte können deaktiviert werden, sodass sie nicht mehr aktiv sind. In Windows PowerShell belässt das Cmdlet Disable-NetFirewallRule die Regel auf dem System, versetzt sie jedoch in einen deaktivierten Zustand, sodass die Regel nicht mehr angewendet wird und sich auf den Datenverkehr auswirkt. Eine deaktivierte Firewallregel kann durch Enable-NetFirewallRule erneut aktiviert werden. Dieses Cmdlet unterscheidet sich von Remove-NetFirewallRule, das die Regeldefinition dauerhaft vom Gerät entfernt. Das folgende Cmdlet löscht die angegebene vorhandene Firewallregel aus dem lokalen Richtlinienspeicher.
Remove-NetFirewallRule -DisplayName "Allow Web 80"
Wie bei anderen Cmdlets können Sie auch abfragen, dass Regeln entfernt werden sollen. Hier werden alle blockierenden Firewallregeln vom Gerät gelöscht.
Remove-NetFirewallRule -Action Block
Es kann sicherer sein, die Regeln mit dem Befehl Get abzufragen und in einer Variablen zu speichern, die regeln zu beachten, die betroffen sind, und sie dann an den Befehl Entfernen weiterzu leiten, genau wie bei den Set-Befehlen . Das folgende Beispiel zeigt, wie Sie alle blockierenden Firewallregeln anzeigen und dann die ersten vier Regeln löschen können.
$x = Get-NetFirewallRule -Action Block
$x
$x[0-3] | Remove-NetFirewallRule
Remoteverwaltung
Die Remoteverwaltung mit WinRM ist standardmäßig aktiviert. Die Cmdlets, die den CimSession-Parameter unterstützen, verwenden WinRM und können standardmäßig remote verwaltet werden. Im folgenden Beispiel werden alle Firewallregeln des persistenten Speichers auf einem Gerät mit dem Namen RemoteDevice zurückgegeben.
Get-NetFirewallRule -CimSession RemoteDevice
Wir können alle Änderungen oder Anzeigeregeln auf Remotegeräten durchführen, indem wir den Parameter -CimSession verwenden. Hier entfernen wir eine bestimmte Firewallregel von einem Remotegerät.
$RemoteSession = New-CimSession -ComputerName RemoteDevice
Remove-NetFirewallRule -DisplayName "AllowWeb80" -CimSession $RemoteSession -Confirm
Bereitstellen grundlegender IPsec-Regeleinstellungen
Eine IPsec-Richtlinie (Internet Protocol Security) besteht aus Regeln, die das IPsec-Verhalten bestimmen. IPsec unterstützt peer-Authentifizierung auf Netzwerkebene, Datenursprungsauthentifizierung, Datenintegrität, Datengeheimnis (Verschlüsselung) und Wiedergabeschutz.
Windows PowerShell können leistungsstarke, komplexe IPsec-Richtlinien wie in Netsh und der Windows-Firewallkonsole erstellen. Da Windows PowerShell jedoch objektbasiert und nicht auf Zeichenfolgentoken basiert, bietet die Konfiguration in Windows PowerShell mehr Kontrolle und Flexibilität.
In Netsh wurden die Authentifizierungs- und Kryptografiesätze als Liste von durch Trennzeichen getrennten Token in einem bestimmten Format angegeben. In Windows PowerShell erstellen Sie anstelle der Standardeinstellungen zuerst die gewünschten Authentifizierungs- oder kryptografischen Vorschlagsobjekte und bündeln sie in Listen in Ihrer bevorzugten Reihenfolge. Anschließend erstellen Sie eine oder mehrere IPsec-Regeln, die auf diese Sätze verweisen. Der Vorteil dieses Modells besteht darin, dass der programmgesteuerte Zugriff auf die Informationen in den Regeln viel einfacher ist. Weitere Beispiele finden Sie in den folgenden Abschnitten.
Erstellen von IPsec-Regeln
Das folgende Cmdlet erstellt eine einfache IPsec-Transportmodusregel in einem Gruppenrichtlinie Object. Eine IPsec-Regel ist einfach zu erstellen. Alles, was erforderlich ist, ist der Anzeigename, und die verbleibenden Eigenschaften verwenden Standardwerte. Eingehender Datenverkehr wird authentifiziert, und die Integrität wird mithilfe des Standard-Schnellmodus und Standard Moduseinstellungen überprüft. Diese Standardeinstellungen finden Sie in der Konsole unter Anpassen von IPsec-Standardwerten.
New-NetIPsecRule -DisplayName "Require Inbound Authentication" -PolicyStore domain.contoso.com\gpo_name
Hinzufügen benutzerdefinierter Authentifizierungsmethoden zu einer IPsec-Regel
Wenn Sie einen benutzerdefinierten Satz von Schnellmodusvorschlägen erstellen möchten, der sowohl AH als auch ESP in einem IPsec-Regelobjekt enthält, erstellen Sie die zugeordneten Objekte separat und verknüpfen ihre Zuordnungen. Weitere Informationen zu Authentifizierungsmethoden finden Sie unter Auswählen des IPsec-Protokolls.
Sie können dann die neu erstellten benutzerdefinierten Schnellmodusrichtlinien verwenden, wenn Sie IPsec-Regeln erstellen. Das Kryptografiesatzobjekt ist mit einem IPsec-Regelobjekt verknüpft.
In diesem Beispiel bauen wir auf der zuvor erstellten IPsec-Regel auf, indem wir einen benutzerdefinierten Schnellmodus-Kryptografiesatz angeben. Die endgültige IPsec-Regel erfordert, dass ausgehender Datenverkehr mit der angegebenen Kryptografiemethode authentifiziert wird.
$AHandESPQM = New-NetIPsecQuickModeCryptoProposal -Encapsulation AH,ESP -AHHash SHA1 -ESPHash SHA1 -Encryption DES3
$QMCryptoSet = New-NetIPsecQuickModeCryptoSet -DisplayName "ah:sha1+esp:sha1-des3" -Proposal $AHandESPQM -PolicyStore domain.contoso.com\gpo_name
New-NetIPsecRule -DisplayName "Require Inbound Authentication" -InboundSecurity Require -OutboundSecurity Request -QuickModeCryptoSet $QMCryptoSet.Name -PolicyStore domain.contoso.com\gpo_name
IKEv2 IPsec-Transportregeln
Ein Unternehmensnetzwerk muss möglicherweise die Kommunikation mit einer anderen Agentur sichern. Sie entdecken jedoch, dass die Agentur Nicht-Windows-Betriebssysteme ausführt und die Verwendung des IKEv2-Standards (Internet Key Exchange Version 2) erfordert. Sie können IKEv2-Funktionen in Windows Server 2012 anwenden, indem Sie IKEv2 als Schlüsselmodul in einer IPsec-Regel angeben. Diese Funktionsspezifikation kann nur mithilfe der Computerzertifikatauthentifizierung und nicht mit der Phase-2-Authentifizierung verwendet werden.
New-NetIPsecRule -DisplayName "Require Inbound Authentication" -InboundSecurity Require -OutboundSecurity Request -Phase1AuthSet MyCertAuthSet -KeyModule IKEv2 -RemoteAddress $nonWindowsGateway
Weitere Informationen zu IKEv2, einschließlich Szenarien, finden Sie unter Sichern von End-to-End-IPsec-Connections mithilfe von IKEv2.
Kopieren einer IPsec-Regel aus einer Richtlinie in eine andere
Firewall- und IPsec-Regeln mit denselben Regeleigenschaften können dupliziert werden, um die Neuerstellung in verschiedenen Richtlinienspeichern zu vereinfachen. Um die zuvor erstellte Regel aus einem Richtlinienspeicher in einen anderen zu kopieren, müssen die zugeordneten Objekte ebenfalls separat kopiert werden. Es ist nicht erforderlich, die zugehörigen Firewallfilter zu kopieren. Sie können Regeln abfragen, die auf die gleiche Weise kopiert werden sollen wie andere Cmdlets. Das Kopieren einzelner Regeln ist eine Aufgabe, die über die Netsh-Schnittstelle nicht möglich ist. Hier erfahren Sie, wie Sie dies mit Windows PowerShell erreichen können.
$Rule = Get-NetIPsecRule -DisplayName "Require Inbound Authentication"
$Rule | Copy-NetIPsecRule -NewPolicyStore domain.costoso.com\new_gpo_name
$Rule | Copy-NetPhase1AuthSet -NewPolicyStore domain.costoso.com\new_gpo_name
Behandeln von Windows PowerShell Fehlern
Um Fehler in Ihren Windows PowerShell Skripts zu behandeln, können Sie den Parameter -ErrorAction verwenden. Dieser Parameter ist besonders nützlich für die Cmdlets Remove . Wenn Sie eine bestimmte Regel entfernen möchten, werden Sie feststellen, dass sie fehlschlägt, wenn die Regel nicht gefunden wird. Wenn Regeln entfernt werden und die Regel noch nicht vorhanden ist, ist es akzeptabel, diesen Fehler zu ignorieren. In diesem Fall können Sie die folgenden Schritte ausführen, um fehler vom Typ "Regel nicht gefunden" während des Entfernungsvorgangs zu unterdrücken.
Remove-NetFirewallRule -DisplayName "Contoso Messenger 98" -ErrorAction SilentlyContinue
Die Verwendung von Wildcards kann auch Fehler unterdrücken, aber sie können möglicherweise Regeln entsprechen, die Sie nicht entfernen möchten. Diese Wildcards können eine nützliche Verknüpfung sein, sollten aber nur verwendet werden, wenn Sie wissen, dass es keine zusätzlichen Regeln gibt, die versehentlich gelöscht werden. Daher entfernt das folgende Cmdlet auch die Regel und unterdrückt alle "Nicht gefunden"-Fehler.
Remove-NetFirewallRule -DisplayName "Contoso Messenger 98*"
Wenn Sie bei Verwendung von Wildcards den übereinstimmenden Regelsatz überprüfen möchten, können Sie den Parameter -WhatIf verwenden.
Remove-NetFirewallRule -DisplayName "Contoso Messenger 98*" -WhatIf
Wenn Sie nur einige der übereinstimmenden Regeln löschen möchten, können Sie den Parameter -Confirm verwenden, um eine Regel-nach-Regel-Bestätigungsaufforderung abzurufen.
Remove-NetFirewallRule -DisplayName "Contoso Messenger 98*" -Confirm
Sie können auch einfach den gesamten Vorgang ausführen und dabei den Namen jeder Regel anzeigen, während der Vorgang ausgeführt wird.
Remove-NetFirewallRule -DisplayName "Contoso Messenger 98*" -Verbose
Monitor
Die folgenden Windows PowerShell-Befehle sind im Aktualisierungszyklus einer Bereitstellungsphase nützlich. Damit Sie alle IPsec-Regeln in einem bestimmten Speicher anzeigen können, können Sie die folgenden Befehle verwenden. In Netsh zeigt dieser Befehl keine Regeln an, wobei profile=domain,public or profile=domain,private. Es werden nur Regeln angezeigt, die über die einzelne Eintragsdomäne verfügen, die in der Regel enthalten ist. Die folgenden Befehlsbeispiele zeigen die IPsec-Regeln in allen Profilen.
Show-NetIPsecRule -PolicyStore ActiveStore
Sie können Standard Sicherheitszuordnungen im Modus auf Informationen überwachen, z. B. welche Peers derzeit mit dem Gerät verbunden sind und welche Schutzsuite verwendet wird, um die Sicherheitszuordnungen zu bilden. Verwenden Sie das folgende Cmdlet, um vorhandene Standard-Modusregeln und deren Sicherheitszuordnungen anzuzeigen:
Get-NetIPsecMainModeSA
Suchen des Quell-GPO einer Regel
Um die Eigenschaften einer bestimmten Regel oder Regelgruppe anzuzeigen, fragen Sie die Regel ab. Wenn eine Abfrage Felder zurückgibt, die als NotConfigured angegeben sind, können Sie bestimmen, aus welchem Richtlinienspeicher eine Regel stammt. Bei Objekten, die aus einem Gruppenrichtlinienobjekt stammen (der Parameter -PolicyStoreSourceType ist im Befehl Show als GroupPolicy angegeben), wird der Name des Gruppenrichtlinienobjekts gefunden und im Feld PolicyStoreSource zurückgegeben, wenn -TracePolicyStore übergeben wird.
Get-NetIPsecRule -DisplayName "Require Inbound Authentication" -TracePolicyStore
Es ist wichtig zu beachten, dass die offengelegten Quellen keinen Domänennamen enthalten.
Bereitstellen einer grundlegenden Domänenisolationsrichtlinie
IPsec kann verwendet werden, um Domänenmitglieder von Nicht-Domänenmitgliedern zu isolieren. Die Domänenisolation verwendet die IPsec-Authentifizierung, um zu verlangen, dass die in die Domäne eingebundenen Geräte die Identitäten der kommunizierenden Geräte positiv einrichten, um die Sicherheit eines organization zu verbessern. Ein oder mehrere Features von IPsec können verwendet werden, um Datenverkehr mit einem IPsec-Regelobjekt zu schützen. Zum Implementieren der Domänenisolation in Ihrem Netzwerk erhalten die Geräte in der Domäne IPsec-Regeln, die unerwünschten eingehenden Netzwerkdatenverkehr blockieren, der nicht durch IPsec geschützt ist. Hier erstellen wir eine IPsec-Regel, die eine Authentifizierung durch Domänenmitglieder erfordert. Durch diese Authentifizierung können Sie in die Domäne eingebundene Geräte von Geräten isolieren, die keiner Domäne angehören. In den folgenden Beispielen ist die Kerberos-Authentifizierung für eingehenden Datenverkehr erforderlich und für ausgehenden Datenverkehr angefordert.
$kerbprop = New-NetIPsecAuthProposal -Machine -Kerberos
$Phase1AuthSet = New-NetIPsecPhase1AuthSet -DisplayName "Kerberos Auth Phase1" -Proposal $kerbprop -PolicyStore domain.contoso.com\domain_isolation
New-NetIPsecRule -DisplayName "Basic Domain Isolation Policy" -Profile Domain -Phase1AuthSet $Phase1AuthSet.Name -InboundSecurity Require -OutboundSecurity Request -PolicyStore domain.contoso.com\domain_isolation
Konfigurieren des IPsec-Tunnelmodus
Der folgende Befehl erstellt einen IPsec-Tunnel, der Datenverkehr von einem privaten Netzwerk (192.168.0.0/16) über eine Schnittstelle auf dem lokalen Gerät (1.1.1.1.1) an ein öffentliches Netzwerk mit einem zweiten Gerät über seine öffentliche Schnittstelle (2.2.2.2) an ein anderes privates Netzwerk (192.157.0.0/16) angefügt. Der gesamte Datenverkehr durch den Tunnel wird mithilfe von ESP/SHA1 auf Integrität überprüft und mit ESP/DES3 verschlüsselt.
$QMProposal = New-NetIPsecQuickModeCryptoProposal -Encapsulation ESP -ESPHash SHA1 -Encryption DES3
$QMCryptoSet = New-NetIPsecQuickModeCryptoSet -DisplayName "esp:sha1-des3" -Proposal $QMProposal
New-NetIPSecRule -DisplayName "Tunnel from HQ to Dallas Branch" -Mode Tunnel -LocalAddress 192.168.0.0/16 -RemoteAddress 192.157.0.0/16 -LocalTunnelEndpoint 1.1.1.1 -RemoteTunnelEndpoint 2.2.2.2 -InboundSecurity Require -OutboundSecurity Require -QuickModeCryptoSet $QMCryptoSet.Name
Bereitstellen sicherer Firewallregeln mit IPsec
In Situationen, in denen nur sicherer Datenverkehr über die Windows-Firewall zugelassen werden kann, ist eine Kombination aus manuell konfigurierten Firewall- und IPsec-Regeln erforderlich. Die Firewallregeln bestimmen die Sicherheitsstufe für zulässige Pakete, und die zugrunde liegenden IPsec-Regeln schützen den Datenverkehr. Die Szenarien können in Windows PowerShell und netsh ausgeführt werden, wobei viele Ähnlichkeiten bei der Bereitstellung auftreten.
Erstellen einer sicheren Firewallregel (zulassen, wenn sicher)
Zum Konfigurieren einer Firewallregel zum Zulassen von Verbindungen, wenn diese sicher sind, muss der entsprechende Datenverkehr authentifiziert und integritätsschutzt und dann optional von IPsec verschlüsselt werden. Im folgenden Beispiel wird eine Firewallregel erstellt, für die die Authentifizierung des Datenverkehrs erforderlich ist. Der Befehl lässt eingehenden Telnet-Netzwerkdatenverkehr nur zu, wenn die Verbindung vom Remotegerät mithilfe einer separaten IPsec-Regel authentifiziert wird.
New-NetFirewallRule -DisplayName "Allow Authenticated Telnet" -Direction Inbound -Program %SystemRoot%\System32\tlntsvr.exe -Authentication Required -Action Allow
Der folgende Befehl erstellt eine IPsec-Regel, die eine erste (Computer-)Authentifizierung erfordert, und versucht dann eine optionale zweite Authentifizierung (Benutzer).The following command creates an IPsec rule that requires a first (computer) authentication and then attempts a optional second (user) authentication. Durch das Erstellen dieser Regel wird der Datenverkehr durch die Firewallregelanforderungen für das Messenger-Programm gesichert und ermöglicht.
$mkerbauthprop = New-NetIPsecAuthProposal -Machine -Kerberos
$mntlmauthprop = New-NetIPsecAuthProposal -Machine -NTLM
$P1Auth = New-NetIPsecPhase1AuthSet -DisplayName "Machine Auth" -Proposal $mkerbauthprop,$mntlmauthprop
$ukerbauthprop = New-NetIPsecAuthProposal -User -Kerberos
$unentlmauthprop = New-NetIPsecAuthProposal -User -NTLM
$anonyauthprop = New-NetIPsecAuthProposal -Anonymous
$P2Auth = New-NetIPsecPhase2AuthSet -DisplayName "User Auth" -Proposal $ukerbauthprop,$unentlmauthprop,$anonyauthprop
New-NetIPSecRule -DisplayName "Authenticate Both Computer and User" -InboundSecurity Require -OutboundSecurity Require -Phase1AuthSet $P1Auth.Name -Phase2AuthSet $P2Auth.Name
Isolieren eines Servers durch Verschlüsselung und Gruppenmitgliedschaft
Um die Sicherheit der Geräte in einem organization zu verbessern, können Sie Domänenisolation bereitstellen, in der Domänenmitglieder eingeschränkt sind. Sie erfordern eine Authentifizierung bei der Kommunikation untereinander und lehnen nicht authentifizierte eingehende Verbindungen ab. Um die Sicherheit von Servern mit vertraulichen Daten zu verbessern, müssen diese Daten geschützt werden, indem nur der Zugriff auf eine Teilmenge von Geräten innerhalb der Unternehmensdomäne zugelassen wird. IPsec kann diese zusätzliche Schutzebene bereitstellen, indem der Server isoliert wird. In der Serverisolation ist der Zugriff auf vertrauliche Daten auf Benutzer und Geräte mit legitimen geschäftlichen Bedarf beschränkt, und die Daten werden zusätzlich verschlüsselt, um Lauschangriffe zu verhindern.
Erstellen einer Firewallregel, die Gruppenmitgliedschaft und Verschlüsselung erfordert
Für die Bereitstellung der Serverisolation legen wir eine Firewallregel auf, die den Datenverkehr auf autorisierte Benutzer oder Geräte in der IPsec-Regel einschränkt, die die Authentifizierung erzwingt. Die folgende Firewallregel lässt Telnet-Datenverkehr von Benutzerkonten zu, die Mitglieder einer benutzerdefinierten Gruppe mit dem Namen "Authorized to Access Server" sind. Dieser Zugriff kann zusätzlich je nach Gerät, Benutzer oder beidem eingeschränkt werden, indem die Einschränkungsparameter angegeben werden. Eine SDDL-Zeichenfolge (Security Descriptor Definition Language) wird erstellt, indem die Sicherheits-ID (SID) eines Benutzers oder einer Gruppe erweitert wird. Weitere Informationen zum Suchen der SID einer Gruppe finden Sie unter Suchen der SID für ein Gruppenkonto. Durch das Einschränken des Zugriffs auf eine Gruppe können Verwaltungen die Unterstützung für die starke Authentifizierung über die Windows-Firewall und/oder IPsec-Richtlinien erweitern. Im folgenden Beispiel wird gezeigt, wie Sie eine SDDL-Zeichenfolge erstellen, die Sicherheitsgruppen darstellt.
$user = new-object System.Security.Principal.NTAccount ("corp.contoso.com\Administrators")
$SIDofSecureUserGroup = $user.Translate([System.Security.Principal.SecurityIdentifier]).Value
$secureUserGroup = "D:(A;;CC;;;$SIDofSecureUserGroup)"
Mit dem vorherigen Scriptlet können Sie auch die SDDL-Zeichenfolge für eine sichere Computergruppe abrufen, wie hier gezeigt:
$secureMachineGroup = "D:(A;;CC;;;$SIDofSecureMachineGroup)"
Weitere Informationen zum Erstellen von Sicherheitsgruppen oder zum Bestimmen der SDDL-Zeichenfolge finden Sie unter Arbeiten mit SIDs. Telnet ist eine Anwendung, die keine Verschlüsselung bereitstellt. Diese Anwendung kann Daten wie Namen und Kennwörter über das Netzwerk senden. Diese Daten können von böswilligen Benutzern abgefangen werden. Wenn ein Administrator die Verwendung von Telnet zulassen, aber den Datenverkehr schützen möchte, kann eine Firewallregel erstellt werden, die IPsec-Verschlüsselung erfordert. Diese Firewallregel ist erforderlich, damit der Administrator sicher sein kann, dass bei der Verwendung dieser Anwendung der gesamte von diesem Port gesendete oder empfangene Datenverkehr verschlüsselt wird. Wenn IPsec die Verbindung nicht autorisieren kann, ist kein Datenverkehr von dieser Anwendung zulässig. In diesem Beispiel lassen wir nur authentifizierten und verschlüsselten eingehenden Telnet-Datenverkehr aus einer angegebenen sicheren Benutzergruppe zu, indem die folgende Firewallregel erstellt wird.
New-NetFirewallRule -DisplayName "Allow Encrypted Inbound Telnet to Group Members Only" -Program %SystemRoot%\System32\tlntsvr.exe -Protocol TCP -Direction Inbound -Action Allow -LocalPort 23 -Authentication Required -Encryption Required -RemoteUser $secureUserGroup -PolicyStore domain.contoso.com\Server_Isolation
Erzwingung der Endpunktsicherheit
Im vorherigen Beispiel wurde die End-to-End-Sicherheit für eine bestimmte Anwendung gezeigt. In Situationen, in denen Endpunktsicherheit für viele Anwendungen erforderlich ist, kann eine Firewallregel pro Anwendung umständlich und schwer zu verwalten sein. Die Autorisierung kann die Regelbasis überschreiben und auf der IPsec-Ebene erfolgen. In diesem Beispiel legen wir die globale IPsec-Einstellung so fest, dass nur Transportmodusdatenverkehr aus einer autorisierten Benutzergruppe mit dem folgenden Cmdlet stammen darf. Informationen zum Arbeiten mit Sicherheitsgruppen finden Sie in den vorherigen Beispielen.
Set-NetFirewallSetting -RemoteMachineTransportAuthorizationList $secureMachineGroup
Erstellen von Firewallregeln, die IPsec-geschützten Netzwerkdatenverkehr zulassen (authentifizierte Umgehung)
Die authentifizierte Umgehung ermöglicht es dem Datenverkehr von einem angegebenen vertrauenswürdigen Gerät oder Benutzer, Firewallblockregeln außer Kraft zu setzen. Diese Außerkraftsetzung ist hilfreich, wenn ein Administrator Scanserver verwenden möchte, um Geräte zu überwachen und zu aktualisieren, ohne Ausnahmen auf Portebene verwenden zu müssen. Weitere Informationen finden Sie unter Aktivieren einer authentifizierten Firewallumgehung. In diesem Beispiel wird davon ausgegangen, dass eine blockierende Firewallregel vorhanden ist. In diesem Beispiel kann jeder Netzwerkdatenverkehr an einem Beliebigen Port von einer beliebigen IP-Adresse die Blockierungsregel außer Kraft setzen, wenn der Datenverkehr als von einem Gerät oder Benutzerkonto authentifiziert wird, das Mitglied des angegebenen Geräts oder der Benutzersicherheitsgruppe ist.
New-NetFirewallRule -DisplayName "Inbound Secure Bypass Rule" -Direction Inbound -Authentication Required -OverrideBlockRules $true -RemoteMachine $secureMachineGroup -RemoteUser $secureUserGroup -PolicyStore domain.contoso.com\domain_isolation