IT-Sicherheit

Network Lockdown: Kernel-Level Netzwerkisolation mit KI-gestützter Incident Response

20. Februar 2026

it-security incident-response firewall forensik claude-code

Network Lockdown: Kernel-Level Netzwerkisolation mit KI-gestützter Incident Response

Bei einem Sicherheitsvorfall lautet die erste Regel: den Rechner sofort vom Netz nehmen. Kein Datenabfluss, keine Lateral Movement, keine Command-and-Control-Kommunikation. Aber dann stehst du vor einem isolierten Rechner und musst alleine herausfinden, was passiert ist. Logs auswerten, Backdoors finden, Schadcode identifizieren — unter Zeitdruck und ohne Hilfe. Network Lockdown löst genau dieses Problem: Es blockiert den gesamten Netzwerkverkehr auf Kernel-Ebene und lässt nur eine einzige Verbindung offen — Claude Code CLI zur Anthropic API.

Das Problem: Isolation vs. Handlungsfähigkeit

Jeder Incident-Responder kennt das Dilemma. Ein System ist kompromittiert, und die Standardprozedur verlangt sofortige Netzwerkisolation. Das ist richtig und wichtig — jede Sekunde, die ein kompromittiertes System online bleibt, riskiert weiteren Schaden: Datenexfiltration, Lateral Movement zu anderen Systemen, C2-Kommunikation mit dem Angreifer.

Aber sobald der Netzstecker gezogen ist, bist du auf dich allein gestellt. Forensische Analyse auf einem isolierten Rechner bedeutet:

Kein Zugriff auf Dokumentation — du kannst nicht nachschlagen, wie ein bestimmtes Malware-Pattern aussieht
Keine externen Tools — du arbeitest mit dem, was lokal installiert ist
Kein zweiter Rechner — wenn du keinen vorbereiteten Forensik-Laptop hast, fehlt dir die Referenz
Kein Experten-Support — du kannst weder Kollegen noch externe Berater kontaktieren

In der Praxis führt das oft dazu, dass die Isolation entweder zu spät erfolgt oder zu früh wieder aufgehoben wird. Beides ist schlecht.

Die Lösung: Selektive Kernel-Level-Isolation

Network Lockdown verfolgt einen anderen Ansatz. Statt den Rechner komplett vom Netz zu nehmen, wird der gesamte Netzwerkverkehr auf Kernel-Ebene blockiert — mit einer einzigen, kontrollierten Ausnahme: HTTPS-Verbindungen zur Anthropic API (api.anthropic.com, Port 443).

Das bedeutet: Claude Code CLI funktioniert weiterhin. Du hast einen KI-gestützten Incident-Response-Assistenten direkt auf dem betroffenen System, der Dateien lesen, analysieren, durchsuchen und bearbeiten kann. Gleichzeitig ist jede andere Netzwerkkommunikation unterbunden.

Was erlaubt ist

Claude Code CLI — HTTPS-Verbindungen zu api.anthropic.com auf Port 443
Loopback-Verkehr — 127.0.0.0/8 und ::1/128 für lokale Prozesse
DNS-Anfragen — Port 53 zu System-DNS-Servern, notwendig für die IP-Auflösung
Etablierte Verbindungen — Rückpakete bereits bestehender Verbindungen

Was blockiert wird

Alles andere. Browser, SSH, Updates, E-Mail, C2-Callbacks, Reverse Shells, Datenexfiltration — nichts kommt rein oder raus. Blockierte Pakete werden ohne ICMP-Antwort verworfen (DROP statt REJECT), sodass ein Angreifer nicht einmal feststellen kann, ob die Firewall aktiv ist.

Technische Architektur: Warum Kernel-Level?

Ein entscheidender Punkt: Die Paketfilterung erfolgt nicht im Userspace, sondern direkt im Betriebssystem-Kernel. Das ist der fundamentale Unterschied zu Application-Level-Firewalls oder Proxy-basierten Lösungen.

Der Paket-Flow

Eine Anwendung sendet ein Paket (z.B. ein Browser ruft eine URL auf)
Der System Call übergibt das Paket an den Kernel
Der Kernel Network Stack empfängt das Paket
Der Firewall-Filter (PF/Netfilter/WFP) interceptiert das Paket
Regelauswertung: Ist das Ziel die Anthropic API auf Port 443? Ist es DNS? Ist es Loopback?
Wenn ja: PASS — das Paket erreicht das Network Interface
Wenn nein: DROP — das Paket wird verworfen, die Anwendung erhält einen Timeout

Kein Userspace-Prozess kann diese Filterung umgehen. Das ist entscheidend, denn Malware, die Root-Rechte hat, könnte Application-Level-Firewalls deaktivieren oder umgehen. Kernel-Level-Filtering ist hingegen an den Netzwerk-Stack selbst gekoppelt.

Plattform-spezifische Implementierung

Network Lockdown unterstützt alle drei großen Desktop-Plattformen. Jede Implementierung nutzt den nativen Kernel-Level-Paketfilter des jeweiligen Betriebssystems.

macOS: Packet Filter (PF)

macOS verwendet PF, das von OpenBSD portierte Packet-Filter-Framework, das direkt in den XNU-Kernel integriert ist. Network Lockdown nutzt PF-Anchors für eine saubere Isolation der Regeln.

# Lockdown aktivieren
sudo ./network-lockdown.sh on

# Status prüfen
sudo ./network-lockdown.sh status

# Aktive Rules anzeigen
sudo ./network-lockdown.sh rules

Das Skript erstellt einen dedizierten PF-Anchor unter /etc/pf.anchors/claude-lockdown, in dem alle Lockdown-Regeln gekapselt sind. Bei der Deaktivierung wird der Anchor entfernt und die ursprüngliche PF-Konfiguration aus einem automatisch erstellten Backup wiederhergestellt.

Technisch gesehen:

pfctl konfiguriert die Kernel-Rules via ioctl() System Calls
PF arbeitet im XNU Kernel Network Stack zwischen BSD Socket Layer und Link Layer
Die Regeln werden in Kernel-Memory gespeichert

Linux: Netfilter mit iptables

Unter Linux kommt Netfilter zum Einsatz, das fest im Linux-Kernel integrierte Firewall-Framework. Netfilter verwendet fünf Kernel-Hooks an strategischen Stellen im Netzwerk-Stack:

# Lockdown aktivieren
sudo ./network-lockdown-linux.sh on

# IPs aktualisieren
sudo ./network-lockdown-linux.sh refresh

# Lockdown deaktivieren
sudo ./network-lockdown-linux.sh off

Die Netfilter-Hooks arbeiten an folgenden Stellen:

NF_INET_PRE_ROUTING — vor der Routing-Entscheidung
NF_INET_LOCAL_IN — Pakete, die an lokale Anwendungen gehen
NF_INET_FORWARD — weitergeleitete Pakete
NF_INET_LOCAL_OUT — Pakete von lokalen Anwendungen
NF_INET_POST_ROUTING — nach der Routing-Entscheidung

Zusätzlich erlaubt die Linux-Variante explizit ICMPv6 für das IPv6 Neighbor Discovery Protocol und nutzt das conntrack Kernel-Modul für Stateful Filtering.

Windows: Windows Filtering Platform (WFP)

Für Windows gibt es ein PowerShell-Skript, das die Windows Filtering Platform nutzt — implementiert im Kernel-Mode-Treiber netio.sys.

# PowerShell als Administrator
.\network-lockdown-windows.ps1 on

# Status prüfen
.\network-lockdown-windows.ps1 status

# Lockdown deaktivieren
.\network-lockdown-windows.ps1 off

Alle Lockdown-Rules werden mit dem Präfix Claude-Lockdown- identifiziert, was eine saubere Verwaltung und Entfernung ermöglicht. Das Skript erstellt separate Rules für IPv4 und IPv6 und erkennt automatisch das aktive Netzwerkprofil (Domain/Private/Public).

Incident Response Workflow

Der eigentliche Mehrwert von Network Lockdown zeigt sich im praktischen Einsatz. Hier ein typischer Incident-Response-Workflow:

Schritt 1: Lockdown aktivieren

Sobald ein Sicherheitsvorfall erkannt wird, aktivierst du den Lockdown:

sudo ./network-lockdown.sh on

Ab diesem Moment kann kein Prozess mehr nach außen kommunizieren. Die Ausgabe bestätigt, welche Anthropic-API-IPs erlaubt wurden und dass der Lockdown aktiv ist.

Schritt 2: Forensische Analyse mit Claude Code

Jetzt beginnt die eigentliche Arbeit. Claude Code (empfohlen: Opus 4.6) ist ein vollwertiger KI-Agent im Terminal, der Dateien lesen, durchsuchen, analysieren und bearbeiten kann. Einige Beispiele:

Verdächtige Logins identifizieren:

> "Durchsuche /var/log auf verdächtige SSH-Logins der letzten 48 Stunden"

Kürzlich geänderte Dateien finden:

> "Finde alle kürzlich geänderten Dateien in /etc und /usr/local/bin"

Offene Ports und Prozesse prüfen:

> "Zeige alle offenen Ports und die zugehörigen Prozesse — gibt es unbekannte Einträge?"

Cronjobs und Timer analysieren:

> "Zeige alle aktiven Cronjobs und systemd Timer — gibt es verdächtige Einträge?"

Schritt 3: Schadcode identifizieren und beseitigen

Wenn verdächtige Dateien gefunden werden, kann Claude Code diese direkt analysieren:

> "Diese Datei sieht nach einer Reverse Shell aus — analysiere den Code"
> "Finde alle Dateien die von diesem User in den letzten 24h erstellt wurden"
> "Prüfe ob authorized_keys manipuliert wurde"

Schritt 4: System härten und Lockdown aufheben

Nach der Bereinigung dokumentierst du die Findings und hebst den Lockdown auf:

> "Erstelle ein Skript das alle gefundenen IOCs dokumentiert"
> "Setze die SSH-Konfiguration auf sichere Defaults zurück"

sudo ./network-lockdown.sh off

Sicherheitsaspekte und Grenzen

Kein Sicherheitstool ist perfekt. Es ist wichtig, die Stärken und Grenzen von Network Lockdown zu verstehen.

IP-Auflösung zur Aktivierungszeit

Die Anthropic-API-IPs werden beim Aktivieren des Lockdowns via DNS aufgelöst:

dig +short api.anthropic.com A
dig +short api.anthropic.com AAAA

Wenn Anthropic seine CDN-IPs ändert, muss der refresh-Befehl ausgeführt werden, um die Firewall-Regeln zu aktualisieren. In der Praxis ist das selten nötig, aber es ist wichtig, diese Abhängigkeit zu kennen.

DNS als minimale Angriffsfläche

DNS-Verkehr ist erlaubt, weil er für die IP-Auflösung notwendig ist. Theoretisch könnte ein Angreifer DNS-Tunneling versuchen. In der Praxis ist das Risiko gering:

Claude Code CLI verwendet TLS-Zertifikatsprüfung — DNS-Spoofing führt zu einem TLS-Fehler
DNS-Anfragen sind auf System-DNS-Server beschränkt
Der DNS-Traffic könnte bei Bedarf zusätzlich über DNS-over-HTTPS (DoH) abgesichert werden

Schutz vor Doppel-Aktivierung

Ein Lockfile-Mechanismus (/tmp/claude-lockdown.lock auf macOS/Linux) verhindert versehentliche Doppel-Aktivierung. Das Lockfile wird bei der Deaktivierung automatisch entfernt.

Backup und Wiederherstellung

Alle drei Skripte erstellen automatisch ein Backup der aktuellen Firewall-Konfiguration vor der Aktivierung. Im Notfall kann die ursprüngliche Konfiguration manuell wiederhergestellt werden:

# macOS
pfctl -f /etc/pf.conf.bak

# Linux
iptables-restore < /etc/iptables.backup
ip6tables-restore < /etc/ip6tables.backup

# Windows
netsh advfirewall import "C:\Windows\Temp\firewall-backup.wfw"

Performance und Overhead

Ein berechtigter Einwand bei Kernel-Level-Filtering ist der Performance-Impact. Die gute Nachricht: Er ist vernachlässigbar.

CPU-Overhead: Weniger als 1% — die Regelauswertung findet inline im Netzwerk-Stack statt und besteht aus simplen IP/Port-Vergleichen
Latenz: Keine messbare Latenz für erlaubte Verbindungen
Memory: Die Firewall-Rules belegen etwa 4-8 KB Kernel-Memory
Skalierung: Bis zu 50 IP-Adressen problemlos handhabbar

Für den Incident-Response-Einsatz ist Performance ohnehin sekundär. Wichtig ist, dass die Isolation zuverlässig funktioniert und Claude Code CLI reibungslos arbeitet.

Warum Claude Code als einzige Ausnahme?

Die Wahl von Claude Code als einzige erlaubte Verbindung ist bewusst getroffen und hat mehrere Gründe:

Minimale Angriffsfläche: Claude Code CLI benötigt nur eine einzige HTTPS-Verbindung zu api.anthropic.com. Es gibt keinen lokalen Server, keine offenen Ports, keinen Webinterface-Traffic. Die Kommunikation ist TLS-verschlüsselt und auf eine Domain beschränkt.

Volles Dateisystem-Zugriff: Claude Code kann direkt auf dem betroffenen System Dateien lesen, analysieren und bearbeiten. Das bedeutet: Logs auswerten, Binaries untersuchen, Konfigurationen prüfen, verdächtige Dateien identifizieren — alles ohne das System verlassen zu müssen.

Kein zweiter Rechner nötig: Die KI läuft remote bei Anthropic. Du brauchst nur ein Terminal auf dem betroffenen System. Das ist ein enormer Vorteil in Situationen, wo kein Forensik-Laptop verfügbar ist.

Kontext-Verständnis: Anders als statische Forensik-Tools kann Claude Code den Kontext verstehen. Du kannst in natürlicher Sprache beschreiben, was du suchst, und die KI durchsucht das System intelligent — nicht nur per Pattern Matching.

Vergleich mit klassischen Ansätzen

Physische Isolation (Netzwerkkabel ziehen)

Der klassische Ansatz: Stecker ziehen, USB-Stick mit Forensik-Tools einstecken.

Vorteil: 100% sichere Isolation
Nachteil: Kein Zugriff auf externe Expertise, keine KI-Unterstützung, alle Tools müssen vorher auf USB vorbereitet sein

VLAN-Isolation

Enterprise-Lösung: Das kompromittierte System in ein isoliertes VLAN verschieben.

Vorteil: Netzwerkzugriff auf dedizierte Forensik-Server möglich
Nachteil: Erfordert Netzwerk-Infrastruktur, Switch-Konfiguration, nicht für Einzelsysteme geeignet

Host-basierte Firewall (manuell)

Manuelles Konfigurieren von iptables/PF/WFP-Regeln.

Vorteil: Vollständige Kontrolle
Nachteil: Zeitaufwändig, fehleranfällig unter Stress, keine Automatisierung

Network Lockdown

Automatisierte Kernel-Level-Isolation mit KI-Zugang.

Vorteil: Schnell aktivierbar, KI-gestützte Analyse, plattformübergreifend, automatisches Backup
Nachteil: DNS-Verkehr als minimale Angriffsfläche, Abhängigkeit von Anthropic-Infrastruktur

Befehls-Referenz

Alle drei Plattform-Skripte unterstützen dieselben Befehle:

Befehl	Beschreibung
`on`	Aktiviert den Lockdown, erstellt Backup der aktuellen Firewall-Rules
`off`	Deaktiviert den Lockdown, stellt vorherige Rules wieder her
`status`	Zeigt aktuellen Status (aktiv/inaktiv) und letzte Aktivierung
`refresh`	Aktualisiert Anthropic IP-Adressen, reaktiviert Lockdown automatisch
`rules`	Zeigt alle aktiven Lockdown-Rules im Detail
`help`	Zeigt Verwendungshinweise

Voraussetzungen

macOS: Keine zusätzliche Installation nötig — pfctl ist in macOS integriert.

Linux:

# Debian/Ubuntu
sudo apt-get install iptables dnsutils curl

# RHEL/CentOS/Fedora
sudo dnf install iptables bind-utils curl

Windows: PowerShell 5.1 oder höher, Windows 10/11 oder Windows Server 2016+.

Alle Skripte benötigen erhöhte Rechte (sudo auf macOS/Linux, Administrator-PowerShell auf Windows), da die Modifikation der Kernel-Firewall eine privilegierte Operation ist.

Fazit

Network Lockdown löst ein reales Problem in der Incident Response: das Dilemma zwischen notwendiger Netzwerkisolation und dem Bedarf an externer Unterstützung. Durch Kernel-Level-Paketfilterung wird der gesamte Netzwerkverkehr blockiert, während eine einzige, kontrollierte Verbindung zu Claude Code CLI bestehen bleibt.

Das Ergebnis ist ein forensisch isolierter Rechner mit einem KI-Experten an deiner Seite. Keine C2-Kommunikation, keine Datenexfiltration, keine Lateral Movement — aber voller Zugriff auf KI-gestützte Analyse, die dir hilft, den Vorfall schneller und gründlicher aufzuarbeiten.

Das Projekt ist Open Source unter MIT-Lizenz und auf GitHub verfügbar. Teste die Skripte in einer sicheren Umgebung, bevor du sie produktiv einsetzt — und denke daran: Ein aktiver Lockdown blockiert wirklich alles außer Claude Code CLI, einschließlich SSH-Verbindungen und Browser.