9.4 Lokale Host-Firewall prüfen

Ziel dieser Seite

Diese Seite beschreibt die systematische Diagnose einer lokalen Host-Firewall unter Windows, Linux und macOS sowie ihre Abgrenzung von:

Nach der Bearbeitung muss nachvollziehbar geprüft werden können:

Eine Host-Firewall darf nicht vorsorglich vollständig deaktiviert werden. Zuerst müssen der betroffene Datenfluss und die tatsächlich wirksame Regel nachgewiesen werden.

Sicherheits- und Wirkungsklassen

Kennzeichnung Bedeutung
LESEND Erfasst ausschließlich vorhandene Zustände.
NETZAKTIV Erzeugt Netzwerkverkehr zum geprüften Ziel.
SENSITIV Kann interne Regeln, Adressen, Programme oder Kommunikationsbeziehungen sichtbar machen.
ÄNDERND Verändert Firewallkonfiguration oder Protokollierung.
AUSFALLRISIKO Kann bestehende Verbindungen, Verwaltung oder Dienste beeinträchtigen.

Firewallregeln und Protokolle können sicherheitsrelevante Informationen enthalten:

Diese Informationen müssen geschützt gespeichert und weitergegeben werden.

Aufgabe einer lokalen Host-Firewall

Eine lokale Host-Firewall filtert Netzwerkverkehr direkt auf einem Endgerät oder Server.

Abhängig vom Betriebssystem kann sie prüfen:

Eine Host-Firewall ersetzt keine Netzwerkfirewall. Beide Ebenen können gleichzeitig filtern.

Datenpfad vereinfachen

Eingehender Datenverkehr:

Client
→ Netzwerkfirewall
→ Servernetzwerkschnittstelle
→ lokale Host-Firewall
→ lokaler Socket
→ Anwendung

Ausgehender Datenverkehr:

Anwendung
→ lokaler Socket
→ lokale Host-Firewall
→ Servernetzwerkschnittstelle
→ Netzwerkfirewall
→ Ziel

Container- oder VM-Verkehr kann zusätzlich einen Weiterleitungspfad verwenden:

Client
→ Hostnetzwerkschnittstelle
→ Host-Firewall oder NAT
→ virtuelle Bridge
→ Container- oder VM-Firewall
→ Anwendung

Jede Ebene muss getrennt nachgewiesen werden.

Host-Firewall, Listener und Anwendung unterscheiden

Befund Aussage
Dienst läuft Prozessstatus ist vorhanden
Listener vorhanden Socket wurde gebunden
lokale Verbindung funktioniert lokaler Netzwerkpfad funktioniert
entfernte Verbindung funktioniert der getestete Ende-zu-Ende-Pfad funktioniert
Firewallregel vorhanden eine konfigurierte Regel existiert
Firewallregel wirksam Regel gilt für den konkreten Datenfluss
Paket wird geloggt Paket wurde an einem bestimmten Filterpunkt erfasst
Anwendung antwortet Transport und Anwendung funktionieren für den Test

Eine vorhandene Allow-Regel beweist nicht, dass:

Prüfdaten des betroffenen Flows

Vor der Regelsuche muss der Datenfluss exakt dokumentiert werden.

Richtung:
<eingehend oder ausgehend>

Transportprotokoll:
<TCP, UDP, ICMPv4, ICMPv6 oder anderes>

Quelladresse:
<IP-Adresse oder Netz>

Quellport:
<Port oder dynamischer Bereich>

Zieladresse:
<IP-Adresse>

Zielport:
<Port>

Lokales Programm:
<vollständiger Pfad>

Lokaler Dienst:
<Dienstname>

Schnittstelle:
<Ethernet, WLAN, VPN, Loopback oder virtuell>

Netzwerkprofil oder Zone:
<Domain, Private, Public oder Linux-Zone>

Zeitpunkt:
<Datum, Uhrzeit und Zeitzone>

Ohne diese Angaben kann nicht sicher entschieden werden, ob eine Firewallregel zum Fehler passt.

Eingehend, ausgehend und weitergeleitet

Richtung Bedeutung
eingehend Verkehr ist an den lokalen Host adressiert
ausgehend Verkehr wird durch einen lokalen Prozess erzeugt
weitergeleitet Verkehr durchquert den Host zu einem anderen Endpunkt

Unter Linux entsprechen diese Pfade häufig den Netfilter-Hooks beziehungsweise Basischains:

input
output
forward

Ein Paket für einen Container oder eine virtuelle Maschine kann den Hostpfad forward verwenden, obwohl der Client den Hostport anspricht.

Eine Regel im lokalen input-Pfad muss deshalb nicht für weitergeleiteten Containerverkehr gelten.

Loopback ist kein vollständiger Firewalltest

Ein Test gegen:

127.0.0.1
::1
localhost

prüft den Loopbackpfad.

Dieser Test bildet nicht zwingend ab:

Auch ein Test gegen die eigene LAN-Adresse vom selben Host kann lokal geroutet werden und muss nicht denselben Pfad wie ein entfernter Client verwenden.

Für eine vollständige Prüfung ist ein repräsentativer externer Client erforderlich.

Firewallzustände richtig interpretieren

Aktion Typisches Verhalten
Allow oder Accept passender Verkehr darf den Filterpunkt passieren
Drop Paket wird ohne aktive Fehlermeldung verworfen
Reject Paket wird verworfen und es kann eine Ablehnung zurückgesendet werden
Log Ereignis wird protokolliert; allein keine Allow- oder Blockaktion
Default Deny nicht ausdrücklich erlaubter Verkehr wird blockiert
Default Allow nicht ausdrücklich blockierter Verkehr wird erlaubt

Ein TCP-Reset kann entstehen durch:

Ein Timeout kann durch stilles Drop-Verhalten entstehen, beweist aber nicht automatisch eine Firewallblockierung.

Wirksame Richtlinie statt nur Konfigurationsdatei prüfen

Firewallregeln können stammen aus:

Entscheidend ist die tatsächlich aktive Richtlinie.

Eine Konfigurationsdatei oder GUI kann vom wirksamen Kernelzustand abweichen, wenn:

Windows-Firewallprofile

Windows verwendet drei Firewallprofile:

Profil Typische Verwendung
Domain Netzwerk mit erkannter und authentifizierter Active-Directory-Domäne
Private als vertrauenswürdig eingestuftes privates Netzwerk
Public nicht vertrauenswürdiges oder öffentliches Netzwerk

Regeln können für ein oder mehrere Profile gelten.

Ein häufiger Fehler ist:

Allow-Regel gilt nur für Domain oder Private.
Die aktive Schnittstelle verwendet jedoch Public.

Windows kann unterschiedliche Profile gleichzeitig für unterschiedliche Schnittstellen verwenden.

Windows: aktive Netzwerkprofile prüfen

LESEND

Get-NetConnectionProfile |
  Select-Object `
    InterfaceAlias,
    InterfaceIndex,
    Name,
    NetworkCategory,
    IPv4Connectivity,
    IPv6Connectivity

Zu prüfen sind:

Das Domainprofil darf nicht manuell als Ersatz für eine fehlerhafte Domänenerkennung erzwungen werden. Zuerst müssen DNS, Erreichbarkeit, Authentifizierung und Netzwerkidentifikation geprüft werden.

Windows: Firewallprofile prüfen

LESEND

Get-NetFirewallProfile |
  Select-Object `
    Name,
    Enabled,
    DefaultInboundAction,
    DefaultOutboundAction,
    AllowInboundRules,
    AllowLocalFirewallRules,
    AllowLocalIPsecRules,
    NotifyOnListen,
    LogFileName,
    LogMaxSizeKilobytes,
    LogAllowed,
    LogBlocked

Wirksame Profile aus dem aktiven Richtlinienspeicher:

Get-NetFirewallProfile `
  -PolicyStore ActiveStore |
  Format-List *

Zu dokumentieren sind:

Die Standardaktionen dürfen nicht ungeprüft als Block beziehungsweise Allow angenommen werden.

Windows: aktive Regeln erfassen

LESEND

Alle wirksamen Regeln:

Get-NetFirewallRule `
  -PolicyStore ActiveStore

Aktivierte Regeln:

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Enabled True

Aktivierte eingehende Allow-Regeln:

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Enabled True `
  -Direction Inbound `
  -Action Allow

Aktivierte eingehende Blockregeln:

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Enabled True `
  -Direction Inbound `
  -Action Block

Aktivierte ausgehende Blockregeln:

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Enabled True `
  -Direction Outbound `
  -Action Block

Herkunft der Regeln:

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Enabled True |
  Select-Object `
    Name,
    DisplayName,
    Direction,
    Action,
    Profile,
    PolicyStoreSourceType,
    PolicyStoreSource

ActiveStore stellt die zusammengeführte aktive Richtlinie der auf das System wirkenden Policy Stores dar. Eine Abfrage ohne -PolicyStore ActiveStore kann eine andere Sicht liefern.

Windows: vollständige Regeldarstellung

LESEND

Show-NetFirewallRule `
  -PolicyStore ActiveStore

Für eine bekannte Regel:

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Name "<Regelname>" |
  Format-List *

Die eigentlichen Port-, Adress-, Programm- und Dienstbedingungen werden in zugeordneten Filterobjekten verwaltet.

Windows: Portfilter prüfen

LESEND

Alle Portfilter:

Get-NetFirewallPortFilter `
  -PolicyStore ActiveStore

Regeln für lokalen Port 443 suchen:

Get-NetFirewallPortFilter `
  -PolicyStore ActiveStore |
  Where-Object LocalPort -eq "443" |
  Get-NetFirewallRule |
  Select-Object `
    Name,
    DisplayName,
    Enabled,
    Direction,
    Action,
    Profile,
    PolicyStoreSourceType,
    PolicyStoreSource

Regeln für entfernten Port 443:

Get-NetFirewallPortFilter `
  -PolicyStore ActiveStore |
  Where-Object RemotePort -eq "443" |
  Get-NetFirewallRule |
  Select-Object `
    Name,
    DisplayName,
    Enabled,
    Direction,
    Action,
    Profile

Danach muss der vollständige Portfilter der gefundenen Regel geprüft werden:

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Name "<Regelname>" |
  Get-NetFirewallPortFilter |
  Format-List *

Zu prüfen sind:

Windows: Adressfilter prüfen

LESEND

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Name "<Regelname>" |
  Get-NetFirewallAddressFilter |
  Format-List *

Zu prüfen sind:

Eine Allow-Regel für:

RemoteAddress = 192.0.2.0/24

gilt nicht für einen Client aus:

198.51.100.0/24

Windows: Programmfilter prüfen

LESEND

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Name "<Regelname>" |
  Get-NetFirewallApplicationFilter |
  Format-List *

Zu prüfen sind:

Eine Regel für einen alten Anwendungspfad gilt nicht automatisch für eine neue Programmdatei.

Windows: Dienstfilter prüfen

LESEND

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Name "<Regelname>" |
  Get-NetFirewallServiceFilter |
  Format-List *

Zu prüfen sind:

Eine Regel kann für einen Dienst gelten, obwohl mehrere Dienste denselben Prozess wie svchost.exe verwenden.

Windows: Schnittstellenfilter prüfen

LESEND

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Name "<Regelname>" |
  Get-NetFirewallInterfaceFilter |
  Format-List *

Zu prüfen sind:

Eine Regel für LAN muss nicht für einen VPN- oder WLAN-Pfad gelten.

Windows: Regelbedingungen vollständig dokumentieren

Für eine gefundene Regel müssen mindestens folgende Informationen zusammengeführt werden:

Name:
<Regelname>

Status:
<aktiviert oder deaktiviert>

Richtung:
<eingehend oder ausgehend>

Aktion:
<Allow oder Block>

Profile:
<Domain, Private, Public>

Protokoll:
<TCP, UDP, ICMPv4 oder ICMPv6>

Lokaler Port:
<Port>

Entfernter Port:
<Port>

Lokale Adresse:
<Adresse oder Netz>

Entfernte Adresse:
<Adresse oder Netz>

Programm:
<Pfad>

Dienst:
<Dienstname>

Schnittstelle:
<Filter>

Richtlinienquelle:
<Local, Group Policy, MDM oder andere>

Erst der Vergleich aller Bedingungen mit dem konkreten Datenfluss zeigt, ob die Regel tatsächlich passt.

Windows-Regelvorrang

Für Windows-Firewallregeln gilt unter anderem:

Windows-Firewallregeln dürfen nicht wie eine einfache von oben nach unten abgearbeitete ACL-Liste interpretiert werden.

Windows: Gruppenrichtlinienbezug prüfen

LESEND

Zusammenfassung der angewendeten Computerrichtlinien:

gpresult /scope computer /r

Wirksame Firewallregeln enthalten zusätzlich:

PolicyStoreSourceType
PolicyStoreSource

Zu prüfen sind:

Eine zentral verwaltete Regel darf nicht durch eine lokale Parallelregel umgangen werden.

Windows: Firewallprotokoll prüfen

Der Protokollpfad kann je Profil abweichen und muss über Get-NetFirewallProfile bestimmt werden.

Typischer Standardpfad:

%SystemRoot%\System32\LogFiles\Firewall\pfirewall.log

Letzte Einträge:

LESEND · SENSITIV

Get-Content `
  "$env:SystemRoot\System32\LogFiles\Firewall\pfirewall.log" `
  -Tail 100

Nach Adresse oder Port suchen:

Get-Content `
  "$env:SystemRoot\System32\LogFiles\Firewall\pfirewall.log" `
  -Tail 1000 |
  Select-String "192.0.2.100|443"

Zu korrelieren sind:

Fehlende Einträge beweisen nicht, dass die Firewall nicht beteiligt ist. Protokollierung kann deaktiviert, begrenzt oder an einem anderen Pfad konfiguriert sein.

Windows: temporäre Protokollierung

Vor einer Änderung müssen die vorhandenen Profilwerte dokumentiert werden.

Aktuellen Zustand sichern:

Get-NetFirewallProfile |
  Select-Object `
    Name,
    LogFileName,
    LogMaxSizeKilobytes,
    LogAllowed,
    LogBlocked

Blockprotokollierung für ein bestimmtes Profil aktivieren:

ÄNDERND · SENSITIV

Set-NetFirewallProfile `
  -Profile Domain `
  -LogBlocked True

Die Änderung muss:

Das Aktivieren der Protokollierung für erlaubte Verbindungen kann sehr große Datenmengen erzeugen.

Windows Filtering Platform prüfen

Windows Filtering Platform, kurz WFP, bildet die Filterplattform für Windows-Firewall, IPsec und weitere Filterkomponenten.

Relevante Security-Ereignisse können sein:

Ereignis-ID Bedeutung
5152 WFP hat ein Paket blockiert.
5154 Anwendung oder Dienst durfte auf eingehende Verbindungen lauschen.
5155 Anwendung oder Dienst wurde am Lauschen gehindert.
5156 WFP hat eine Verbindung erlaubt.
5157 WFP hat eine Verbindung blockiert.
5158 Bindung an einen lokalen Port wurde erlaubt.
5159 Bindung an einen lokalen Port wurde blockiert.

Blockereignisse lesen:

LESEND · SENSITIV

Get-WinEvent `
  -FilterHashtable @{
    LogName = "Security"
    Id      = 5152, 5155, 5157, 5159
  } `
  -MaxEvents 100

Diese Ereignisse stehen nur zur Verfügung, wenn die entsprechenden Überwachungsrichtlinien aktiv waren.

Zu prüfen sind:

Sehr umfangreiche WFP-Überwachung kann viele Ereignisse erzeugen und muss gezielt eingesetzt werden.

Windows: netsh als ergänzende Sicht

LESEND

Profile:

netsh advfirewall show allprofiles

Regeln:

netsh advfirewall firewall show rule name=all verbose

Überwachungszustand:

netsh advfirewall monitor show firewall

Der ältere Kontext:

netsh firewall

sollte nicht mehr für die aktuelle Verwaltung verwendet werden. Für moderne Systeme sind PowerShell-NetSecurity-Cmdlets und netsh advfirewall vorgesehen.

Windows: Drittanbieterfilter berücksichtigen

Verkehr kann blockiert werden, obwohl keine passende Windows-Firewall-Blockregel sichtbar ist.

Mögliche zusätzliche Filter:

Hinweise:

Sicherheitssoftware darf nicht ohne Freigabe beendet oder deinstalliert werden.

Windows: Hyper-V, WSL und Container

Verkehr zu einer VM, WSL-Instanz oder einem Container kann zusätzliche Filterebenen durchlaufen.

Zu unterscheiden sind:

Verfügbare Hyper-V-Firewall-Cmdlets prüfen:

Get-Command `
  -Name "*NetFirewallHyperV*" `
  -ErrorAction SilentlyContinue

Wenn entsprechende Cmdlets vorhanden sind, müssen Hyper-V-Profile und Regeln zusätzlich geprüft werden.

Eine Allow-Regel im normalen Hostprofil beweist nicht automatisch, dass Verkehr zu einer VM oder WSL-Instanz erlaubt wird.

Linux: verwendetes Firewall-Backend bestimmen

Auf Linux-Systemen können mehrere Werkzeuge vorhanden sein:

Zuerst muss bestimmt werden, welches System die aktive Richtlinie verwaltet.

Versionen prüfen:

LESEND

nft --version

iptables --version

Eine iptables-Ausgabe kann auf ein Backend hinweisen:

iptables vX.Y.Z (nf_tables)

oder:

iptables vX.Y.Z (legacy)

Aktive Manager:

systemctl is-active firewalld

systemctl is-active ufw

Die Installation oder Aktivität eines Managers beweist nicht, dass keine weiteren Regeln existieren.

Linux: nftables-Regelsatz prüfen

LESEND · SENSITIV

sudo nft list ruleset

Mit Regel-Handles:

sudo nft -a list ruleset

Zu prüfen sind:

Wichtige Tabellenfamilien:

Familie Bedeutung
inet gemeinsame Verarbeitung von IPv4 und IPv6
ip IPv4
ip6 IPv6
bridge Bridgeverkehr
arp ARP
netdev früher Paketpfad an Netzgeräten

Eine Regel in inet kann sowohl IPv4 als auch IPv6 betreffen. Separate ip- und ip6-Regeln müssen getrennt geprüft werden.

Linux: nftables-Hooks prüfen

Typische Hooks:

Hook Datenpfad
input Verkehr zum lokalen Host
output lokal erzeugter Verkehr
forward weitergeleiteter Verkehr
prerouting vor der Routingentscheidung
postrouting nach der Routingentscheidung
ingress früher Eingangspfad

Der Name einer Chain muss nicht ihrem Hook entsprechen. Entscheidend ist die tatsächliche Chain-Definition.

Beispiel:

chain host_in {
    type filter hook input priority filter;
    policy drop;
}

Eine frei benannte Chain ohne Hook wirkt nur, wenn eine andere Regel in sie springt.

Linux: nftables-Counter auswerten

Regeln können Zähler für Pakete und Bytes enthalten.

Beispielausgabe:

counter packets 42 bytes 3360 drop

Für einen kontrollierten Test:

  1. aktuellen Zählerstand dokumentieren;
  2. genau einen Test ausführen;
  3. Regelsatz erneut lesen;
  4. Zählerdifferenz prüfen;
  5. Quelladresse, Zielport und Protokoll abgleichen.

Ein unveränderter Zähler beweist nicht automatisch, dass die Regel nicht betroffen ist:

Zähler dürfen nicht vorsorglich zurückgesetzt werden, weil dadurch Beweisdaten verloren gehen.

Linux: iptables-Regeln prüfen

LESEND · SENSITIV

IPv4:

sudo iptables \
  -L \
  -n \
  -v \
  --line-numbers

IPv6:

sudo ip6tables \
  -L \
  -n \
  -v \
  --line-numbers

Vollständiger IPv4-Regelsatz mit Countern:

sudo iptables-save \
  -c

Vollständiger IPv6-Regelsatz:

sudo ip6tables-save \
  -c

Wichtige Optionen:

Option Bedeutung
-L Chains und Regeln anzeigen
-n numerische Adressen und Ports
-v ausführliche Anzeige und Counter
--line-numbers Regelpositionen anzeigen
-c bei iptables-save Counter mit ausgeben

iptables -L allein bildet nicht immer alle Tabellen und benutzerdefinierten Zusammenhänge ausreichend ab. iptables-save liefert eine vollständigere Regelsatzdarstellung.

Linux: INPUT, OUTPUT und FORWARD unterscheiden

Typische Bedeutung:

INPUT:
Paket ist an den Linux-Host selbst adressiert.

OUTPUT:
Paket wurde auf dem Linux-Host erzeugt.

FORWARD:
Paket wird durch den Linux-Host weitergeleitet.

Containerverkehr kann beispielsweise durchlaufen:

PREROUTING
→ FORWARD
→ POSTROUTING

Eine Allow-Regel in INPUT hilft in diesem Fall nicht zwingend.

Linux: firewalld-Zustand prüfen

LESEND

Dienstzustand:

firewall-cmd --state

Aktive Zonen und Zuordnungen:

firewall-cmd --get-active-zones

Standardzone:

firewall-cmd --get-default-zone

Alle Zonen:

firewall-cmd --list-all-zones

Bestimmte aktive Zone:

firewall-cmd \
  --zone=<Zone> \
  --list-all

Rich Rules:

firewall-cmd \
  --zone=<Zone> \
  --list-rich-rules

Richtlinienobjekte:

firewall-cmd --get-policies

firewall-cmd --list-all-policies

Zu prüfen sind:

Die Standardzone ist nicht automatisch die tatsächlich für jede Schnittstelle wirksame Zone.

Linux: firewalld-Laufzeit und permanente Konfiguration

firewalld unterscheidet:

Konfiguration Wirkung
Runtime aktuell aktiv, geht ohne Übernahme bei Reload oder Neustart verloren
Permanent gespeichert, wird bei Reload oder Start zur Runtime-Konfiguration

Runtime-Konfiguration einer Zone:

firewall-cmd \
  --zone=<Zone> \
  --list-all

Permanente Konfiguration:

firewall-cmd \
  --permanent \
  --zone=<Zone> \
  --list-all

Beide Ausgaben müssen verglichen werden.

Mögliche Fehler:

Ein firewall-cmd --reload ist eine Änderung und darf nicht als erster Diagnoseschritt verwendet werden.

Linux: bestimmten firewalld-Port prüfen

Runtime:

firewall-cmd \
  --zone=<Zone> \
  --query-port=443/tcp

Service:

firewall-cmd \
  --zone=<Zone> \
  --query-service=https

Permanent:

firewall-cmd \
  --permanent \
  --zone=<Zone> \
  --query-port=443/tcp

Ein positives Ergebnis beweist nur, dass Port oder Service in dieser Zone konfiguriert ist. Es beweist nicht:

Linux: UFW prüfen

LESEND

Status und Standardrichtlinien:

sudo ufw status verbose

Nummerierte Regeln:

sudo ufw status numbered

Von UFW verwaltete hinzugefügte Regeln:

sudo ufw show added

Vollständigere Netfilter-Sicht:

sudo ufw show raw

Zu prüfen sind:

ufw status zeigt nicht zwingend alle Regeln, die außerhalb von UFW erzeugt wurden. Ein Status inactive beweist deshalb nicht, dass im Kernel keine anderen Netfilterregeln aktiv sind.

Linux: vorhandene Firewallprotokolle prüfen

Kernelmeldungen im betroffenen Zeitraum:

LESEND · SENSITIV

journalctl \
  -k \
  --since "15 minutes ago"

firewalld-Dienstmeldungen:

journalctl \
  -u firewalld \
  --since "15 minutes ago"

UFW-Dienstmeldungen:

journalctl \
  -u ufw \
  --since "15 minutes ago"

Zu beachten:

Neue Logregeln dürfen nur gezielt, rate-limitiert und zeitlich begrenzt erstellt werden.

Linux: eBPF-, XDP- und tc-Filter berücksichtigen

Pakete können vor oder außerhalb der erwarteten nftables- oder iptables-Regel verworfen werden.

Schnittstellendetails:

ip \
  -details \
  link show \
  dev <Schnittstelle>

tc-Ingressfilter:

sudo tc \
  filter show \
  dev <Schnittstelle> \
  ingress

tc-Egressfilter:

sudo tc \
  filter show \
  dev <Schnittstelle> \
  egress

Falls bpftool vorhanden ist:

sudo bpftool net

Mögliche Verursacher:

Diese Filter dürfen nicht ohne Kenntnis ihres Besitzers entfernt werden.

macOS: zwei Firewallbereiche unterscheiden

Unter macOS müssen mindestens zwei unterschiedliche Mechanismen getrennt betrachtet werden:

Mechanismus Aufgabe
Application Layer Firewall steuert eingehende Verbindungen anhand von Apps und Diensten
Packet Filter pf paket- und regelbasierte Filterung auf Netzwerkebene

Zusätzlich können vorhanden sein:

Die macOS Application Firewall wird nicht primär als frei konfigurierbare Portfirewall verwaltet. Apple beschreibt sie als anwendungsbezogene Firewall.

macOS: Application Firewall in der Oberfläche prüfen

Aktueller Pfad:

Apple-Menü
→ Systemeinstellungen
→ Netzwerk
→ Firewall

Zu prüfen sind:

Die genaue Darstellung kann je nach macOS-Version und Geräteverwaltung abweichen.

macOS: Application Firewall im Terminal prüfen

LESEND

Gesamtstatus:

sudo /usr/libexec/ApplicationFirewall/socketfilterfw \
  --getglobalstate

Block-All-Zustand:

sudo /usr/libexec/ApplicationFirewall/socketfilterfw \
  --getblockall

Tarnmodus:

sudo /usr/libexec/ApplicationFirewall/socketfilterfw \
  --getstealthmode

Anwendungsliste:

sudo /usr/libexec/ApplicationFirewall/socketfilterfw \
  --listapps

Lokale Hilfe und verfügbare Optionen:

/usr/libexec/ApplicationFirewall/socketfilterfw \
  --help

Zusammenfassung über System Profiler:

system_profiler SPFirewallDataType

Zu prüfen sind:

macOS: pf-Zustand prüfen

LESEND · SENSITIV

Status:

sudo pfctl -s info

Filterregeln:

sudo pfctl -sr

NAT-Regeln:

sudo pfctl -sn

Zustandstabelle:

sudo pfctl -ss

Gesamtübersicht:

sudo pfctl -sa

Zu prüfen sind:

Apple weist darauf hin, dass Packet Filter keine unterstützte API für die Integration eigener Softwareprodukte ist. Systembestandteile können die Regeln verwalten und verändern. Die Diagnose vorhandener Zustände ist deshalb von einer dauerhaften eigenen Produktintegration zu unterscheiden.

macOS: Network Extensions und Sicherheitsfilter

Installierte System Extensions:

LESEND

systemextensionsctl list

Mögliche Filterkomponenten:

Eine deaktivierte Application Firewall beweist nicht, dass keine Network Extension den Verkehr filtert.

Sicherheits- oder VPN-Erweiterungen dürfen nicht ohne Freigabe entfernt oder deaktiviert werden.

Docker und Host-Firewall

Docker kann auf dem Host eigene iptables- oder nftables-Regeln erzeugen, um:

Zu prüfen sind:

docker info

docker network ls

docker ps \
  --format 'table {{.Names}}\t{{.Ports}}'

docker inspect \
  <Containername> \
  --format '{{json .NetworkSettings.Ports}}'

Wichtige Punkte:

Ein freigegebener Hostport beweist nicht, dass die Anwendung im Container lauscht.

Kubernetes und lokale Host-Firewall

Auf einem Kubernetes-Knoten können zusätzlich wirken:

NetworkPolicy ist nicht dasselbe wie die allgemeine Host-Firewall.

Zu prüfen sind:

kubectl get networkpolicy \
  --all-namespaces

kubectl get service \
  --all-namespaces

kubectl get pods \
  --all-namespaces \
  -o wide

kubectl get endpointslice \
  --all-namespaces

Bei hostnahen Problemen müssen zusätzlich CNI- und Knotenkonfiguration berücksichtigt werden.

TCP-Fehlerbilder einer lokalen Firewall

Paketbefund Mögliche Einordnung
SYN erreicht Host nicht vorgelagerter Pfad oder falsche Zieladresse
SYN erreicht Host, Firewall loggt Drop lokale Host-Firewall bestätigt
SYN erreicht Host, kein Listener Betriebssystem kann RST senden
SYN erreicht Host, Listener vorhanden, keine Antwort lokale Filterung, Prozess oder Überlastung
Host sendet SYN/ACK, Client erhält es nicht ausgehender Filter oder Rückweg
Verbindung wird sofort zurückgesetzt Reject, fehlender Listener oder Anwendung
lokaler Test funktioniert, externer nicht Bindung, Profil, Host-Firewall oder Netzwerkpfad
nur ein Quellnetz fehlerhaft RemoteAddress- oder Zonenregel
nur IPv6 fehlerhaft fehlende IPv6-Regel oder ICMPv6-Problem
nur nach VPN-Verbindung fehlerhaft Profil-, Schnittstellen- oder VPN-Filter

UDP-Fehlerbilder einer lokalen Firewall

Paketbefund Mögliche Einordnung
UDP-Anfrage erreicht Host nicht vorgelagerter Pfad
Anfrage erreicht Host, Drop wird geloggt lokale Host-Firewall
Anfrage erreicht Host und Prozess nicht Hostfilter, Namespace oder Puffer
Anwendung antwortet, Antwort verlässt Host nicht ausgehende Hostfilterung
keine Antwort und kein ICMP geöffnet/still oder Drop
ICMP Port Unreachable kein passender UDP-Endpunkt oder aktive Ablehnung
nur große Datagramme scheitern Fragment-, MTU- oder ICMP-Filterung
Broadcast oder Multicast scheitert Schnittstellen-, Zonen- oder Gruppenregel

Ein allgemeiner TCP-Porttest ist kein Nachweis für UDP.

ICMP und ICMPv6 prüfen

Firewallregeln müssen ICMPv4 und ICMPv6 getrennt betrachten.

Zu prüfen sind:

Das Blockieren von Ping beweist nicht, dass TCP oder UDP blockiert wird.

Umgekehrt kann Ping funktionieren, während ein TCP- oder UDP-Port blockiert ist.

Das vollständige Blockieren von ICMP oder ICMPv6 kann Path MTU Discovery und Diagnose beeinträchtigen.

Paketaufzeichnung und Firewallprotokoll kombinieren

Eine Paketaufzeichnung allein zeigt nicht immer, ob ein Paket alle lokalen Filterstufen passiert hat. Der Aufzeichnungspunkt kann vor oder nach bestimmten Filtern liegen.

Belastbarer Nachweis:

  1. Testzeitpunkt genau dokumentieren.
  2. Paketaufzeichnung auf dem Host starten.
  3. Firewallcounter oder Protokoll erfassen.
  4. Genau einen Test ausführen.
  5. Listener und Prozesszustand erfassen.
  6. Firewallprotokoll mit dem Flow abgleichen.
  7. Paketaufzeichnung und Regelcounter vergleichen.
  8. Test vom repräsentativen Client wiederholen.

Windows-Paketaufzeichnung mit pktmon

pktmon kann Paketerfassung und Drop-Erkennung innerhalb des Windows-Netzwerkstacks unterstützen.

Filter zurücksetzen:

SENSITIV · ÄNDERND

pktmon stop

pktmon filter remove

Filter für TCP-Port 443:

pktmon filter add TCP443 -t TCP -p 443

Aufzeichnung starten:

pktmon start --capture --pkt-size 0 --file-name C:\Temp\firewall443.etl

Nach reproduziertem Fehler stoppen:

pktmon stop

Konvertieren:

pktmon etl2pcap C:\Temp\firewall443.etl --out C:\Temp\firewall443.pcapng

Filter entfernen:

pktmon filter remove

Das Zielverzeichnis muss vorhanden sein. Aufzeichnung und Filter müssen anschließend zurückgenommen werden.

Linux-Paketaufzeichnung

LESEND · SENSITIV

TCP-Port 443:

sudo tcpdump \
  -ni any \
  'tcp port 443' \
  -c 200

UDP-Port 53 und ICMP:

sudo tcpdump \
  -ni any \
  '(udp port 53) or icmp or icmp6' \
  -c 200

Bestimmte Schnittstelle und Gegenstelle:

sudo tcpdump \
  -ni <Schnittstelle> \
  'host 192.0.2.100 and tcp port 443' \
  -c 200

Eine sichtbare eingehende Anfrage beweist, dass sie den Capturepunkt erreicht hat. Ob sie die Anwendung erreicht, muss zusätzlich mit Firewallcounter, Socket- und Anwendungsbefund geprüft werden.

macOS-Paketaufzeichnung

Verfügbare Schnittstellen:

tcpdump -D

Bestimmte Schnittstelle:

sudo tcpdump \
  -ni en0 \
  'host 192.0.2.100 and tcp port 443' \
  -c 200

Loopback:

sudo tcpdump \
  -ni lo0 \
  'tcp port 8080' \
  -c 200

Application Firewall, pf, Network Extension und Anwendung müssen getrennt ausgewertet werden.

Lokalen und entfernten Test vergleichen

Windows:

NETZAKTIV

Test-NetConnection `
  -ComputerName "127.0.0.1" `
  -Port 443

Test-NetConnection `
  -ComputerName "192.0.2.25" `
  -Port 443

Von einem entfernten Client:

Test-NetConnection `
  -ComputerName "app.example.test" `
  -Port 443 `
  -InformationLevel Detailed

Linux und macOS:

nc -vz 127.0.0.1 443

nc -vz 192.0.2.25 443

Von einem entfernten Client:

nc -vz app.example.test 443

Auswertung:

lokaler Test entfernter Test Mögliche Einordnung
erfolgreich erfolgreich getesteter TCP-Pfad funktioniert
erfolgreich fehlerhaft Bindung, Host-Firewall oder Netzwerkpfad
fehlerhaft fehlerhaft Listener, Dienst, Port oder lokale Filterung
Loopback erfolgreich, LAN-IP fehlerhaft Bindung oder schnittstellenbezogene Regel
IPv4 erfolgreich, IPv6 fehlerhaft IPv6-Bindung oder IPv6-Firewall
ohne VPN erfolgreich, mit VPN fehlerhaft Profil-, Schnittstellen- oder VPN-Regel

Host-Firewall von Netzwerkfirewall abgrenzen

Nachweis Einordnung
Paket erreicht Serverschnittstelle nicht Problem vor dem Server
Paket erreicht Host und Host-Firewall loggt Drop lokale Host-Firewall bestätigt
Paket erreicht Host, kein Drop, kein Listener Dienst- oder Bindungsproblem
Paket erreicht Host, Listener vorhanden, Anwendung loggt nichts lokaler Filter, Endpoint Security oder Anwendung
Antwort verlässt Serverschnittstelle lokaler ausgehender Pfad wahrscheinlich passiert
Antwort verlässt Host nicht und Outbound-Drop wird geloggt lokale ausgehende Firewall
Client- und Serveraufzeichnung unterscheiden sich Verlust oder Filterung im Zwischenpfad
anderer Server im selben Netz funktioniert hostspezifische Konfiguration wahrscheinlich

Eine Paketaufzeichnung an nur einem Punkt reicht häufig nicht zur eindeutigen Abgrenzung.

Hypothese und Gegenbeweis

Beispiel:

Hypothese:
Die aktive Windows-Firewall blockiert eingehende TCP-Verbindungen auf
Port 443, weil die Allow-Regel nur für das Domainprofil gilt, die
aktive Schnittstelle aber dem Public-Profil zugeordnet ist.

Erwarteter Befund:
Get-NetConnectionProfile zeigt Public.
Die Regel gilt nur für Domain.
Der lokale Listener auf Port 443 ist vorhanden.
Der lokale Test funktioniert.
Der entfernte Test schlägt fehl.
Das Firewallprotokoll zeigt einen Drop für den Testflow.

Gegenbeweis:
Die Schnittstelle verwendet Domain und eine wirksame Allow-Regel
passt vollständig zu Protokoll, Port, Quelladresse und Programm.

Testmethode:
Profil-, Regel-, Listener-, Protokoll- und Paketprüfung.

Risiko:
Die lesenden Prüfungen verändern den Firewallzustand nicht.

Linux-Beispiel:

Hypothese:
Die Netzwerkschnittstelle befindet sich in der firewalld-Zone public,
aber die Freigabe wurde in der Zone internal angelegt.

Erwarteter Befund:
firewall-cmd --get-active-zones ordnet die Schnittstelle public zu.
Port 443 ist in public nicht erlaubt, in internal jedoch vorhanden.
Der Listener existiert und ein externer Test schlägt fehl.

Gegenbeweis:
Die Schnittstelle ist internal zugeordnet oder eine andere wirksame
Regel erlaubt den konkreten Flow.

Kontrollierte Maßnahmen

Maßnahme Voraussetzung Risiko
vorhandene passende Regel aktivieren Regel ist geprüft und nur deaktiviert Dienst wird erreichbar
Profilzuordnung korrigieren falsche Netzwerkkategorie nachgewiesen Vertrauensniveau des Netzwerks ändert sich
gezielte Allow-Regel erstellen konkreter legitimer Flow bestätigt zusätzliche Angriffsfläche
zu breite Regel einschränken unnötiger Geltungsbereich bestätigt legitime Clients können ausfallen
falsche Blockregel korrigieren Blockregel als Ursache nachgewiesen Schutzwirkung kann reduziert werden
Programmpfad aktualisieren Anwendungspfad hat sich nachweislich geändert falsches Programm könnte freigegeben werden
RemoteAddress-Bereich korrigieren Quellnetz stimmt nachweislich nicht weitere Quellen können Zugriff erhalten
TCP-/UDP-Protokoll korrigieren Protokollverwechslung bestätigt zusätzlicher Transportweg wird geöffnet
IPv6-Regel ergänzen Dienst soll IPv6 nutzen und Block ist bestätigt zusätzliche IPv6-Erreichbarkeit
firewalld-Runtime und Permanent angleichen Abweichung bestätigt Wirkung über Neustart hinaus
Container-Weiterleitungsregel korrigieren Forward-Pfad bestätigt mehrere Container können betroffen sein
Endpoint-Security-Ausnahme beantragen Produktfilter als Ursache bestätigt zentrale Sicherheitswirkung
Logging zeitlich begrenzt aktivieren vorhandene Daten reichen nicht Speicher- und Datenschutzrisiko

Vor jeder Änderung müssen dokumentiert werden:

Systematischer Diagnoseablauf

  1. Exakte Fehlermeldung aufnehmen.
  2. Zeitpunkt und Zeitzone dokumentieren.
  3. Client, Server und Anwendung bestimmen.
  4. TCP, UDP, ICMPv4 oder ICMPv6 bestimmen.
  5. Quell- und Zieladressen dokumentieren.
  6. Quell- und Zielports dokumentieren.
  7. Listener und Bindungsadresse prüfen.
  8. Besitzenden Prozess bestimmen.
  9. lokalen Loopbacktest durchführen.
  10. konkrete lokale Schnittstellenadresse testen.
  11. Test von einem repräsentativen entfernten Client durchführen.
  12. Paketfluss eingehend, ausgehend oder weitergeleitet bestimmen.
  13. aktive Firewalltechnik bestimmen.
  14. aktives Profil, aktive Zone oder Schnittstelle bestimmen.
  15. Standardaktionen prüfen.
  16. wirksame Regeln erfassen.
  17. Allow- und Blockregeln prüfen.
  18. Protokoll- und Portfilter vergleichen.
  19. Adressbereiche vergleichen.
  20. Programm- und Dienstfilter vergleichen.
  21. Schnittstellenfilter vergleichen.
  22. Richtlinienquelle bestimmen.
  23. zentrale Richtlinien und lokale Zusammenführung prüfen.
  24. Firewallcounter und vorhandene Protokolle auswerten.
  25. bei Bedarf zeitlich begrenzte Protokollierung aktivieren.
  26. Paketaufzeichnung am Host durchführen.
  27. Paketaufzeichnung mit einem zweiten Punkt vergleichen.
  28. Container-, VM- und Namespacepfade berücksichtigen.
  29. Endpoint Security, VPN und zusätzliche Filter berücksichtigen.
  30. Hypothese und Gegenbeweis formulieren.
  31. Genau eine kontrollierte Änderung durchführen.
  32. identischen Test wiederholen.
  33. Anwendung statt nur Porttest verifizieren.
  34. weitere repräsentative Clients prüfen.
  35. temporäre Protokollierung und Filter zurücknehmen.
  36. Ursache, Maßnahme und Prävention dokumentieren.

Befundmatrix

Befund Mögliche Einordnung Nächster Nachweis
kein Listener kein Firewallproblem nachgewiesen Dienst und Bindung prüfen
lokaler Test funktioniert, remote nicht Firewall, Bindung oder Netzwerkpfad Serveraufzeichnung
Paket erreicht Server nicht vorgelagerter Pfad Netzwerkfirewall und Routing
Paket erreicht Server, Drop wird geloggt lokale Host-Firewall passende Regel bestimmen
Paket erreicht Server, kein Drop, kein App-Log Endpoint Filter oder Anwendung Prozess- und WFP/eBPF-Befund
Allow-Regel vorhanden, falsches Profil Regel nicht wirksam aktive Profilzuordnung
Allow-Regel vorhanden, falsche Zone Regel nicht wirksam firewalld-Zuordnung
Allow-Regel vorhanden, falsches Protokoll TCP-/UDP-Verwechslung Portfilter
Allow-Regel vorhanden, falsche Quelladresse Scope passt nicht Adressfilter
Allow-Regel vorhanden, alter Programmpfad App-Filter passt nicht Prozesspfad
Blockregel und Allow-Regel treffen zu Blockregel kann Vorrang besitzen vollständige Regelbedingungen
lokale Regel verschwindet zentrale Verwaltung PolicyStoreSource oder MDM
UFW inaktiv, Verkehr blockiert andere Netfilterregeln nft list ruleset
firewalld-Port permanent, nicht runtime noch nicht wirksam Runtime vergleichen
firewalld-Port runtime, nicht permanent verschwindet bei Reload Permanent vergleichen
nft-Counter steigt an Drop-Regel Regel trifft den Flow Zeit und 5-Tupel prüfen
iptables-Counter bleibt unverändert anderer Pfad oder Backend nftables und Namespace prüfen
Application Firewall erlaubt App, trotzdem blockiert pf, Network Extension oder VPN weitere Filter prüfen
Docker-Port veröffentlicht, Hostzugriff scheitert Forward-/Docker-Regel oder Container Docker-Regeln und Listener
Hostdienst funktioniert, Container nicht Namespace oder Forward-Pfad Container-Socket und NAT
nur IPv6 blockiert fehlende IPv6-Regel ip6, inet oder ICMPv6
nur VPN betroffen Schnittstellen-, Profil- oder VPN-Filter Zustand mit und ohne VPN
Antwort verlässt Host, Client sieht sie nicht Problem nach dem Host Rückweg und Netzwerkfirewall

Typische Diagnosefehler

Verifikation

Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden:

Eine vollständig deaktivierte Firewall ist keine gültige Verifikation einer sicheren Lösung.

Dokumentationsvorlage

Störung:
<exakte Beschreibung>

Zeitpunkt:
<Datum, Uhrzeit und Zeitzone>

Client:
<Hostname und IP-Adresse>

Server:
<Hostname und IP-Adresse>

Anwendung:
<Dienst und Prozess>

Richtung:
<eingehend, ausgehend oder weitergeleitet>

Transportprotokoll:
<TCP, UDP, ICMPv4 oder ICMPv6>

Quelladresse und Port:
<Adresse und Port>

Zieladresse und Port:
<Adresse und Port>

Listener:
<Adresse, Port, Prozess und PID>

Schnittstelle:
<Name und Typ>

Firewalltechnik:
<Windows Firewall, nftables, firewalld, UFW, pf oder andere>

Aktives Profil oder Zone:
<Wert>

Standardaktion:
<eingehend und ausgehend>

Wirksame Regel:
<Name, Aktion und Bedingungen>

Richtlinienquelle:
<lokal, GPO, MDM oder anderes>

Portfilter:
<Befund>

Adressfilter:
<Befund>

Programm- oder Dienstfilter:
<Befund>

Firewallprotokoll:
<Zeitpunkt und Aktion>

Paketaufzeichnung:
<eingehender und ausgehender Befund>

Zusätzliche Filter:
<Endpoint Security, VPN, Container oder Hypervisor>

Nachgewiesene Ursache:
<technischer Befund>

Gegenbeweis ausgeschlossen durch:
<Test und Ergebnis>

Durchgeführte Maßnahme:
<genau eine kontrollierte Änderung>

Sicherheitsauswirkung:
<Beschreibung>

Risiko und Rückweg:
<Beschreibung>

Verifikation:
<identischer Test, Anwendung und weitere Systeme>

Prävention:
<Monitoring oder Konfigurationsverbesserung>

Checkliste

Schnellreferenz

Aufgabe Befehl
Windows-Netzwerkprofil Get-NetConnectionProfile
Windows-Firewallprofile Get-NetFirewallProfile
wirksame Windows-Regeln Get-NetFirewallRule -PolicyStore ActiveStore
aktivierte Windows-Regeln Get-NetFirewallRule -PolicyStore ActiveStore -Enabled True
Windows-Blockregeln Get-NetFirewallRule -PolicyStore ActiveStore -Enabled True -Action Block
Windows-Portfilter Get-NetFirewallPortFilter -PolicyStore ActiveStore
Windows-Adressfilter Get-NetFirewallAddressFilter -PolicyStore ActiveStore
Windows-Programmfilter Get-NetFirewallApplicationFilter -PolicyStore ActiveStore
Windows-Dienstfilter Get-NetFirewallServiceFilter -PolicyStore ActiveStore
vollständige Windows-Regeln Show-NetFirewallRule -PolicyStore ActiveStore
Windows-Firewallprotokoll Get-Content "$env:SystemRoot\System32\LogFiles\Firewall\pfirewall.log" -Tail 100
Windows-WFP-Blockereignisse Get-WinEvent -FilterHashtable @{LogName="Security"; Id=5152,5155,5157,5159}
Windows-netsh-Profile netsh advfirewall show allprofiles
Windows-netsh-Regeln netsh advfirewall firewall show rule name=all verbose
nftables-Regelsatz sudo nft list ruleset
nftables mit Handles sudo nft -a list ruleset
iptables-Regeln sudo iptables -L -n -v --line-numbers
IPv6-iptables sudo ip6tables -L -n -v --line-numbers
iptables-Gesamtsicht sudo iptables-save -c
firewalld-Zustand firewall-cmd --state
aktive firewalld-Zonen firewall-cmd --get-active-zones
firewalld-Zone firewall-cmd --zone=<Zone> --list-all
permanente firewalld-Zone firewall-cmd --permanent --zone=<Zone> --list-all
firewalld-Port prüfen firewall-cmd --zone=<Zone> --query-port=<Port>/<Protokoll>
UFW-Status sudo ufw status verbose
nummerierte UFW-Regeln sudo ufw status numbered
vollständige UFW-Sicht sudo ufw show raw
Kernelprotokoll journalctl -k --since "15 minutes ago"
macOS-Firewallstatus sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
macOS-App-Liste sudo /usr/libexec/ApplicationFirewall/socketfilterfw --listapps
macOS-Firewallübersicht system_profiler SPFirewallDataType
macOS-pf-Status sudo pfctl -s info
macOS-pf-Regeln sudo pfctl -sr
macOS-pf-States sudo pfctl -ss
macOS-System-Extensions systemextensionsctl list
Windows-TCP-Test Test-NetConnection -ComputerName <Ziel> -Port <Port>
Linux/macOS-TCP-Test nc -vz <Ziel> <Port>
Linux-Aufzeichnung sudo tcpdump -ni any 'tcp port <Port>' -c 200

Befehle und Maßnahmen, die nicht unkontrolliert als erste Diagnose verwendet werden dürfen

Set-NetFirewallProfile -Enabled False
netsh advfirewall set allprofiles state off
Disable-NetFirewallRule ohne exakte Regelbegrenzung
Enable-NetFirewallRule ohne exakte Regelbegrenzung
Remove-NetFirewallRule
New-NetFirewallRule ohne dokumentierten Scope
netsh int ip reset
netsh winsock reset
nft flush ruleset
iptables -F
iptables -X
ip6tables -F
ufw disable
ufw reset
firewall-cmd --reload
firewall-cmd --complete-reload
systemctl stop firewalld
systemctl restart firewalld
pfctl -d
pfctl -F all
Änderung oder Entfernen von Docker-Regeln
Deaktivieren der Docker-Firewallverwaltung
Entfernen von Kubernetes- oder CNI-Regeln
Deaktivieren eines VPN-Filters
Beenden oder Deinstallieren von Endpoint Security
dauerhafte ungefilterte Paketprotokollierung

Ein vollständiges Deaktivieren der Firewall verändert den Sicherheitszustand, kann Richtlinien verletzen und liefert keinen präzisen Nachweis darüber, welche Regel den ursprünglichen Fehler verursacht hat.

Quellen

Offizielle Microsoft-Dokumentation

Offizielle Netfilter- und Linux-Dokumentation

Offizielle firewalld- und Ubuntu-Dokumentation

Offizielle Apple-Dokumentation

Offizielle Containerdokumentation

Für diese Seite wurden keine Community-Berichte oder Social-Media-Aussagen als technische Nachweise verwendet.

Revision #1
Created 2 August 2026 16:45:56 by Admin
Updated 2 August 2026 16:46:08 by Admin