# Zero Trust Firewalling: Alles verbieten, was nicht explizit erlaubt ist

TL;DR / Management Summary In der modernen Bedrohungslandschaft ist das Vertrauen in das “interne Netz” gefährlich. Wir wenden das Zero Trust Prinzip auf den Linux-Host an: Deny by Default. Nicht nur für eingehende Verbindungen (Ingress), sondern – noch wichtiger – auch für ausgehende Verbindungen (Egress). Wenn ein Webserver gehackt wird, darf er keine Verbindung zu einem Command-and-Control Server aufbauen können. Wir lernen, wie wir dieses strikte Regelwerk ohne Systembruch implementieren.

# 1. Einführung & Architektur

Ingress vs. Egress Filtering.

Die meisten Firewalls blockieren nur von außen nach innen.

• Ingress: Wer darf zu mir? (Standard-Hardening).
• Egress (Kritisch!): Wo darf ich hin? (Verhindert Exfiltration von Daten und Malware-Nachladen).

# Die Zero-Trust Kette (Mermaid)

graph TD
    subgraph "The Fortress Host"
        A[Application] --> B{Outbound Check}
        C[Internet] --> D{Inbound Check}
        B -->|Only DNS/Updates| C
        B --x|Blocked| E[Hacker C&C]
        D -->|Only HTTP/SSH| A
        D --x|Blocked| F[The Rest of World]
    end
    style B fill:#f96,stroke:#333
    style D fill:#f96,stroke:#333

# 2. Implementierung: Die strikte Policy

Den Hammer fallen lassen.

In nftables setzen wir die Default-Policy für alle Ketten auf drop.

# Beispiel: /etc/nftables.conf (Hardened)

table inet filter {
    # 1. Eingehend: Nur Web & SSH
    chain input {
        type filter hook input priority 0; policy drop;
        ct state established,related accept
        iif lo accept
        tcp dport { 80, 443, 22 } accept
    }

    # 2. Ausgehend: Nur DNS, HTTP (Updates) und NTP
    chain output {
        type filter hook output priority 0; policy drop;
        ct state established,related accept
        oif lo accept
        
        # DNS erlauben (UDP/TCP 53)
        udp dport 53 accept
        tcp dport 53 accept
        
        # Updates erlauben (CDN IPs wären besser, aber Hostnames gehen nicht in nft)
        tcp dport { 80, 443 } accept
        
        # Time Sync
        udp dport 123 accept
    }
}

# 3. Egress-Filtering für Profis

Whitelisting nach IPs.

Da nftables (Kernel) keine Hostnames (z.B. google.com) versteht, müssen wir für Egress-Whitelists oft mit IP-Bereichen arbeiten.

# Beispiel: Nur Zugriff auf die interne Datenbank

# Innerhalb der output chain
ip daddr 10.0.0.50 tcp dport 5432 accept

# 4. Day-2 Operations: Applikations-Profile

Regeln dynamisch erweitern.

In einer Zero-Trust Umgebung muss jede neue Applikation ihre Netzwerk-Anforderungen deklarieren.

• Ansible: Pflegen Sie eine Liste von allowed_egress_ports pro Server-Rolle.
• Audit: Nutzen Sie das Logging von abgelehnten Outbound-Paketen, um fehlende Regeln im Staging zu finden.

# 5. Troubleshooting & “War Stories”

Wenn der Server sich selbst einsperrt.

# Story 1: “Der hängende apt-update”

Symptom: apt update oder dnf update funktioniert nicht mehr, obwohl Port 80/443 ausgehend offen sind. Ursache: Die Mirror-Server nutzen Redirects auf andere IPs oder Ports, oder der DNS-Resolver (systemd-resolved) braucht zusätzlich Port 5353 (mDNS) oder 853 (DoT). Lösung: Loggen Sie die Drops in der Output-Chain: chain output { ... log prefix "OUT_DROP: " }.

# Story 2: “Ransomware-Stop”

Symptom: Ein Server wurde über eine PHP-Lücke infiziert. Die Malware versucht, den Key zum Verschlüsseln von einem Server in Russland zu laden. Ursache: Die Malware scheitert, weil der Server keine unbekannten IPs im Ausland erreichen darf. Ergebnis: Der Angriff wird gestoppt, bevor der Schaden entsteht. Der Admin wird durch die Firewall-Logs alarmiert.

# 6. Fazit & Empfehlung

• Philosophie: Betrachten Sie jeden Server als potenziell infiziert.
• Egress: Ausgehendes Filtern ist aufwendig, aber der effektivste Schutz gegen Botnetze.
• Reihenfolge: Führen Sie Egress-Filtering erst im log Modus ein, bevor Sie auf drop umstellen.

# Anhang: Cheatsheet