Was sind Windows Firewall Ausgangsregeln?
Windows Firewall Ausgangsregeln steuern Verbindungen, die einen Windows-Computer verlassen. Die Standardaktion eines Profils für ausgehenden Datenverkehr legt fest, was geschieht, wenn keine anwendbare Regel diesen Datenverkehr erlaubt oder blockiert. Ein Pilot mit Standardsperre beginnt mit einer definierten Gruppe von Computern und einer dokumentierten Liste notwendiger Verbindungen. Anschließend wird geprüft, ob diese Verbindungen unter der vorgesehenen Richtlinie weiterhin funktionieren.
Diese Härtungsentscheidung verursacht betrieblichen Aufwand. Microsoft empfiehlt für die meisten Bereitstellungen, ausgehenden Datenverkehr standardmäßig zu erlauben, und zieht eine Standardsperre für bestimmte besonders sichere Umgebungen in Betracht. Ein Befund zur erfassten Standardaktion eröffnet daher eine Prüfung; er begründet keine allgemeine Pflicht, ausgehenden Datenverkehr in der gesamten Domäne zu blockieren. Siehe Microsofts Leitfaden zu Windows Firewall-Regeln.
Die praktische Frage lautet, ob Ihre Organisation eine sinnvolle Freigabeliste für die ausgewählten Computer pflegen kann. Legen Sie vor einer Änderung der Standardaktion fest, wer Änderungen verantwortet, welche Anwendungen kommunizieren müssen und wie ausgefallene Abhängigkeiten wiederhergestellt werden. Eine Richtlinie, die Updates oder die Fernverwaltung ohne Wiederherstellungsweg unterbricht, kann dem Zweck der Maßnahme entgegenwirken.
Funktionsweise: Profilstandard und Blockierregel unterscheiden sich
Die Profile Domain, Private und Public haben eigene Einstellungen. Wählen Sie das Profil des Piloten bewusst und prüfen Sie, welches Profil im Zielnetzwerk verwendet wird. Eine Konfiguration des Domain-Profils belegt nicht, was geschieht, wenn derselbe Computer ein Private- oder Public-Netzwerk nutzt.
Zwei unterschiedliche Ansätze müssen auseinandergehalten werden. Bei der Standardaktion Block für ausgehenden Datenverkehr kann eine anwendbare explizite Freigaberegel notwendige Verbindungen erlauben. Bei einer expliziten umfassenden Blockierregel stellt eine widersprechende gewöhnliche Freigaberegel diesen Datenverkehr dagegen nicht wieder her: Explizite Blockierregeln haben Vorrang. Eine spezifischere Freigabe umgeht keine überlappende explizite Sperre. Dieses Vorrangverhalten gilt auch für ausgehende Regeln.
Auch Richtlinienspeicher sind relevant. Eine in einer Verwaltungs-GPO gespeicherte Regel beschreibt die beabsichtigte Konfiguration. Der ActiveStore des Zielsystems repräsentiert die derzeit aktive Richtlinie, die aus den anwendbaren Speichern zusammengesetzt wird. Die Zusammenführung lokaler Regeln kann beeinflussen, welche Ausnahmen einbezogen werden. Prüfen Sie die tatsächlichen Zusammenführungseinstellungen und Regelquellen, statt anzunehmen, eine lokal erstellte Ausnahme werde verwendet. Microsofts Leitfaden zur Verwaltung über die Befehlszeile dokumentiert lokale und GPO-basierte Vorgänge.
Trennen Sie Einschränkungen der Authentifizierung von Einschränkungen der Konnektivität. Unser Leitfaden zum Blockieren von ausgehendem NTLM auf Tier-0-Systemen behandelt die Einschränkung eines Authentifizierungsmechanismus, der bei Coercion und Relay eine Rolle spielt. Diese Entscheidung definiert keine Firewall-Freigabeliste für Anwendungen und Ziele. Ebenso belegt eine Standardaktion der Firewall für ausgehenden Datenverkehr nicht, dass die NTLM-Authentifizierung deaktiviert ist.
Erkennung: Erfasste GPO-Daten mit dem Zielsystem vergleichen
Dokumentieren Sie Computer, Netzwerkkontext, vorgesehenen Richtlinienumfang und Erfassungszeitpunkt. Führen Sie die folgenden lesenden Befehle einzeln in PowerShell auf einem repräsentativen Windows-Zielsystem aus. Es handelt sich um Beispiele auf Grundlage der Dokumentation, nicht um Messungen, die für diesen Artikel durchgeführt wurden.
Schritt 1: Aktive Profileinstellungen lesen
Microsoft dokumentiert Get-NetFirewallProfile mit ActiveStore:
Get-NetFirewallProfile -PolicyStore ActiveStore
Prüfen Sie Name, Enabled und DefaultOutboundAction für jedes Profil sowie die Einstellungen zur Zusammenführung lokaler Regeln und zur Protokollierung. Bewahren Sie die zurückgegebene Ausgabe auf. Bestätigen Sie, welches Netzwerkprofil der Pilot tatsächlich verwendet. Ein Block-Wert bei einem inaktiven Profil reicht nicht als Nachweis dafür aus, dass der getestete Datenfluss gefiltert wurde.
Vergleichen Sie das Domain-Ergebnis mit dem GPO-Wert WindowsFirewall/DomainProfile/DefaultOutboundAction, der aus Registry.pol erfasst wurde. In der Darstellung des Detektors bedeutet 0 Allow und 1 Block. Fehlt der GPO-Wert oder weicht er vom Zielsystem ab, untersuchen Sie die Richtlinienanwendung und konkurrierende Konfigurationsquellen. Ersetzen Sie das aktive Ergebnis des Computers nicht durch den vom Collector ausgewählten Wert.
Schritt 2: Ausgehende Regeln und ihre Quellen prüfen
Verwenden Sie die Referenz zu Get-NetFirewallRule, um ausgehende Regeln aus der aktiven Richtlinie abzurufen und ihre ursprünglichen Speicher nachzuverfolgen:
Get-NetFirewallRule -Direction Outbound -PolicyStore ActiveStore -TracePolicyStore
Prüfen Sie Aktivierungsstatus, Aktion, Profil, Quelle sowie die zugehörigen Filter für Anwendung, Dienst, Adresse und Port. Die Regelobjekte allein zeigen nicht sämtliche zugehörigen Filter vollständig an. Prüfen Sie diese Details in Windows Firewall with Advanced Security oder mit den entsprechenden NetSecurity-Filter-Cmdlets. Identifizieren Sie überlappende Blockierregeln und zu umfassende Freigaben, bevor Sie einen Konnektivitätstest interpretieren.
Unser Leitfaden mit vier Prüfungen zur GPO-Sicherheit verwendet dieselbe Verifikationsmethode: Vergleichen Sie die beabsichtigte Richtlinie, die Computer, die sie erhalten, und den tatsächlich verwendeten Schutz. Seine Prüfungen zu LLMNR, WSUS, LSA und UNC belegen keine Abdeckung durch ausgehende Firewall-Regeln. Wenden Sie die Methode hier anhand von Firewall-spezifischen Nachweisen auf dem Zielsystem an.
Schritt 3: Notwendigen und abgewiesenen Datenverkehr beobachten
Lesen Sie den konfigurierten LogFileName des Profils aus, statt auf allen Computern denselben Pfad anzunehmen. Der Befehlszeilenleitfaden nennt %SystemRoot%\System32\LogFiles\Firewall\pfirewall.log. Die Referenz zu Set-NetFirewallProfile dokumentiert die Protokollierung akzeptierter und verworfener Pakete. Setzen Sie aufbewahrte Einträge mit dem Anwendungsvorgang, dem Zeitstempel, dem Protokoll und den getesteten Endpunkten in Beziehung.
Für einen isolierten, lokal verwalteten Laborpilot aktiviert dieser Befehl beide Protokollierungsoptionen für Domain:
Set-NetFirewallProfile -Profile Domain -LogAllowed True -LogBlocked True
Konfigurieren Sie die Protokollierung bei verwalteten Computern stattdessen in der maßgeblichen Richtlinie und verifizieren Sie sie im ActiveStore. Änderungen der Protokollierung sind von der Standardaktion für ausgehenden Datenverkehr getrennt. Dokumentieren Sie die vorherigen Einstellungen und planen Sie die Aufbewahrung, damit Nachweise für die Fehleranalyse verfügbar bleiben. Ein verworfenes Paket ist ein Ausgangspunkt für Untersuchungen, kein Malware-Nachweis. Ein leeres Protokoll beweist nicht, dass jeder Anwendungspfad erlaubt ist.
Abhilfe: Einen Pilot mit begrenzter Standardsperre planen (Remediation)
Schritt 1: Eignung der Standardsperre für die ausgewählte Gruppe entscheiden
Dokumentieren Sie den geschäftlichen und sicherheitsbezogenen Grund für den Pilot, die ausgewählten Computer und die Grenze des Domain-Profils. Wählen Sie eine überschaubare Gruppe, deren Anwendungsverantwortliche für Tests verfügbar sind. Legen Sie Wartungsfenster, Zuständigkeiten für die Überwachung und einen unabhängigen Wiederherstellungsweg fest. Entscheiden Sie, welche Nachweise eine Ausweitung erlauben und welcher Fehler einen Rollback erfordert.
Ist das Abhängigkeitsinventar unvollständig oder kann es niemand pflegen, dokumentieren und beheben Sie diese Einschränkung vor der Durchsetzung. Das Ziel ist eine dauerhaft betreibbare Konnektivitätsrichtlinie. Einen Konfigurationsbefund durch eine domänenweite Änderung der Standardaktion zu schließen, ohne deren Auswirkungen zu verstehen, ist kein sinnvolles Erfolgskriterium.
Schritt 2: Anwendungen und ihre Abhängigkeiten inventarisieren
Dokumentieren Sie für jede Anwendung und jeden Dienst die ausführbare Datei oder Dienstidentität, die vorgesehenen Ziele, das Protokoll, die Zielports, die Betriebszeiten und die verantwortliche Person. Nehmen Sie DNS-Auflösung, Abruf von Updates, Verwaltungsagenten, Fernadministration und Wiederherstellungswerkzeuge ausdrücklich in die Prüfung auf. Inventarisieren Sie sowohl Routinevorgänge als auch seltene Wartungsaufgaben. Eine erfolgreiche interaktive Sitzung testet kein geplantes Update und keine geplante Sicherung.
Erstellen Sie die Liste anhand von Herstelleranforderungen und beobachteten legitimen Vorgängen. Unterscheiden Sie unmittelbar von der Anwendung benötigte Ziele von unterstützender Infrastruktur wie Proxy oder Resolver. Ändern sich Endpunkte im Laufe der Zeit, dokumentieren Sie die Pflege der Freigabeliste. Leiten Sie keine vollständige Abhängigkeitskarte aus einem kurzen Paketmitschnitt ab und genehmigen Sie nicht automatisch jede beobachtete Verbindung.
Schritt 3: Dokumentierte Freigaberegeln vorbereiten
Erstellen Sie die erforderlichen Ausnahmen, bevor Sie die Standardsperre aktivieren. Ordnen Sie jeder Regel eine verantwortliche Person, einen Zweck, ein Profil und eine Prüfentscheidung zu. Prüfen Sie, dass die Regeln den Pilot über den vorgesehenen Richtlinienspeicher erreichen, und lösen Sie Konflikte mit expliziten Sperren. Prüfen Sie die Zusammenführung lokaler Regeln, damit von Anwendungen installierte Regeln und von Administratoren erstellte Ausnahmen bewusst behandelt werden.
Die folgende illustrative Regel verwendet die von New-NetFirewallRule dokumentierten Parameter. Pfad, Adresse, Port, Domäne und GPO sind Beispiele, die durch verifizierte Inventarwerte ersetzt werden müssen. Diese Regel darf nicht unverändert bereitgestellt werden:
New-NetFirewallRule -DisplayName "Pilot application to approved service" -Direction Outbound -Action Allow -Profile Domain -Program "C:\Program Files\Example\client.exe" -Protocol TCP -RemoteAddress 192.0.2.10 -RemotePort 443 -PolicyStore "corp.contoso.com\Outbound Pilot"
Eine einzelne Beispielausnahme ist kein Inventar der Anwendungsabhängigkeiten. Ergänzen Sie nur Regeln, die durch die tatsächliche Arbeitslast einschließlich ihrer unterstützenden Dienste gerechtfertigt sind. Prüfen Sie auch vorhandene umfassende Freigaben: Eine Standardsperre hat nur begrenzten Nutzen, wenn eine allgemeine Ausnahme weiterhin die Verbindungen erlaubt, die Sie einschränken wollten.
Schritt 4: Nur den ausgewählten Bereich des Domain-Profils ändern
Für die GPO des Beispielpiloten können die dokumentierten Set-NetFirewallProfile-Parameter die gewählte Standardaktion ausdrücken:
Set-NetFirewallProfile -Profile Domain -DefaultOutboundAction Block -PolicyStore "corp.contoso.com\Outbound Pilot"
Bestätigen Sie vor der Änderung, dass diese GPO nur auf die ausgewählte Gruppe angewendet wird. Bewahren Sie die vorherige Einstellung auf und lassen Sie die Firewall aktiviert. Wiederholen Sie nach der Richtlinienanwendung die ActiveStore-Abfragen für Profile und Regeln auf den Zielcomputern. Ein erfolgreicher Verwaltungsbefehl schreibt Konfiguration; er belegt nicht, dass jedes vorgesehene Ziel sie angewendet hat.
Schritt 5: Datenflüsse messen und Rollback erproben
Testen Sie jeden dokumentierten Vorgang unter dem aktiven Domain-Profil. Prüfen Sie Anwendungsverhalten, Namensauflösung, Updateprüfungen, Verwaltungszugriff und Wiederherstellungszugriff. Vergleichen Sie Fehler mit verworfenem Datenverkehr und Regeldetails. Ist eine Verbindung notwendig, dokumentieren Sie ihren Zweck, bevor Sie die passende Ausnahme ergänzen oder korrigieren. Testen Sie anschließend den ursprünglichen Vorgang erneut.
Definieren Sie einen kontrollierten Test für Datenverkehr, den die Richtlinie abweisen soll, mit einem genehmigten Testziel und einer genehmigten Arbeitslast. Dokumentieren Sie das erwartete Ergebnis und die tatsächlichen Nachweise vom Zielsystem. Interpretieren Sie eine erfolgreiche Abweisung nicht als Beweis dafür, dass sämtlicher unerwünschter ausgehender Datenverkehr blockiert wird. Bewahren Sie die Aufzeichnungen erlaubter und abgewiesener Vorgänge gemeinsam auf, damit Prüfer Sicherheitsabsicht und Kompatibilität beurteilen können.
War die dokumentierte vorherige Standardaktion der Beispiel-GPO Allow, lautet ihr Rollback-Befehl:
Set-NetFirewallProfile -Profile Domain -DefaultOutboundAction Allow -PolicyStore "corp.contoso.com\Outbound Pilot"
Stellen Sie den tatsächlichen vorherigen Richtlinienzustand wieder her, wenn dieser abwich, gegebenenfalls einschließlich einer nicht konfigurierten Einstellung. Prüfen Sie Pilotregeln und Protokollierungsänderungen getrennt. Eine verbleibende explizite Sperre kann die Konnektivität weiterhin verhindern, nachdem die Standardaktion wieder auf Allow gesetzt wurde. Prüfen Sie den ActiveStore erneut und wiederholen Sie den fehlgeschlagenen Geschäftsvorgang, bevor Sie die Wiederherstellung als abgeschlossen erklären. Weiten Sie den Pilot erst aus, wenn Inventar, Zuständigkeiten, Tests und Rollback-Dokumentation die nächste Gruppe rechtfertigen.
Wie EtcSec dies erkennt
Die geprüfte Detect()-Implementierung von etc-collector stellt eine hier relevante Prüfung bereit: FIREWALL_OUTBOUND_NOT_BLOCKED. Sie initialisiert einen Befund mit Schweregrad Low und Count = 0 und sucht anschließend den erfassten Integer FirewallOutboundAction. Liefert die Suche nil oder einen anderen Wert als 1, setzt sie Count = 1. Ein zurückgegebener Wert von 1 belässt Count = 0.
Der Registry.pol-Parser befüllt dieses Feld nur aus einem Schlüssel, der zu WindowsFirewall und DomainProfile passt und den Wertnamen DefaultOutboundAction enthält. Werte der Profile Private und Public liegen außerhalb dieser Prüfung. Die Integer-Hilfsfunktion sucht zuerst einen von nil verschiedenen Wert in der Default Domain Controllers Policy, dann in der Default Domain Policy und schließlich in einer anderen verfügbaren GPO. Ihr Fallback iteriert über eine Go-Map; er bestimmt nicht den Vorrang von Windows-Richtlinien.
Diese Grenzen sind bei der Prüfung eines Befunds relevant. Das Fehlen eines erfassten GPO-Werts löst die Prüfung aus, ohne die effektive Standardaktion oder die tatsächliche Anwendung auf einem Computer zu messen. Count = 1 zählt keine exponierten Endpunkte und weist keinen Command-and-Control-Datenverkehr nach. Count = 0 validiert weder die Aktivierung der Firewall noch notwendige Freigaberegeln, Konflikte mit expliziten Sperren, lokale Ausnahmen oder einen erfolgreichen Pilotbetrieb.
Nutzen Sie dieses Signal als Ausgangspunkt für die oben beschriebene begrenzte Untersuchung. Ergänzen Sie die Prüfung um das aktive Profil des Zielsystems, effektive Regeln, Anwendungstests und Rollback-Nachweise. Entscheiden Sie, ob eine Standardsperre für diese Gruppe geeignet ist, und klären Sie die Konfigurationsfrage anhand der daraus gewonnenen Nachweise statt allein anhand der aggregierten GPO-Suche.
Entdecken Sie die Identity-Security-Seiten zu diesem Thema