# Network Segmentation: Den ‘Blast Radius’ minimieren

TL;DR / Management Summary Ein flaches Netzwerk ist der Traum jedes Angreifers. Sobald ein Server kompromittiert ist, kann sich der Hacker ungehindert im gesamten Netz ausbreiten (Lateral Movement). Netzwerk-Segmentierung bricht diese Freiheit. Wir nutzen VLANs (Artikel 142) und Host-Firewalls (Artikel 310), um die Infrastruktur in isolierte Zonen zu unterteilen. Das Ziel: Ein gehackter Webserver darf niemals direkt auf den Backup-Server oder das Management-Interface des Hypervisors zugreifen können.

# 1. Einführung & Architektur

North-South vs. East-West.

1. North-South Traffic: Datenverkehr zwischen dem Internet und dem Rechenzentrum (Schutz durch Perimeter-Firewall).
2. East-West Traffic: Datenverkehr zwischen Servern innerhalb des RZ. Hier liegt oft das größte Risiko.

# Das Enterprise Zonen-Modell (Mermaid)

graph TD
    A[Internet] --- B[Perimeter Firewall]
    B --> C[Zone: DMZ - Public Web]
    B --> D[Zone: App - Internal Logic]
    B --> E[Zone: Database - Data Store]
    B --> F[Zone: Management - SSH/Backup]
    C -.-x|Blocked| E
    D --> E
    F --> C
    F --> D
    F --> E
    subgraph "Isolation"
        C
        D
        E
    end

# 2. Implementierung auf dem Linux-Host

VLANs als Barrieren.

Nutzen Sie für jede Vertrauensstufe ein eigenes VLAN-Interface.

# Beispiel: Trennung von Daten und Backup

In einem Backup-Server sollte das Backup-Netz physisch oder logisch (VLAN) getrennt sein.

• eth0 (VLAN 10): Öffentlicher Zugriff (HTTP).
• eth1 (VLAN 99): Backup-Traffic (Nur Zugriff von Backup-Nodes).

# 3. Micro-Segmentation: Die Host-Firewall als Schutz

Vertraue niemandem.

Selbst innerhalb eines VLANs sollten Server sich gegenseitig misstrauen (Zero Trust, Artikel 312).

# Beispiel: Datenbank-Schutz

Erlauben Sie in der nftables.conf der Datenbank nur Zugriffe von spezifischen App-Server-IPs, nicht vom gesamten Subnetz.

# In /etc/nftables.conf
chain inbound {
    ip saddr { 10.0.1.10, 10.0.1.11 } tcp dport 5432 accept
    ip saddr 10.0.1.0/24 tcp dport 5432 drop
}

# 4. Day-2 Operations: Management-Zugriff

Die ‘Jump Host’ Strategie.

Administrativer Zugriff (SSH, Proxmox GUI) darf niemals über das öffentliche Internet oder das normale Applikations-VLAN erfolgen.

• Nutzen Sie einen dedizierten Jump Host (Artikel 305).
• Der Jump Host ist der einzige Knoten, der in das Management-VLAN routen darf.

# 5. Troubleshooting & “War Stories”

Wenn die Mauer zu hoch ist.

# Story 1: “Der blinde SQL-Connect”

Symptom: Der neue App-Server kann die Datenbank nicht erreichen. telnet db 5432 schlägt fehl. Ursache: Der Admin hat vergessen, die Route zwischen dem App-VLAN und dem DB-VLAN in der zentralen Firewall (oder auf den Hosts) freizuschalten. Lösung: Nutzen Sie mtr (Artikel 271), um zu sehen, an welchem Hop das Paket verworfen wird. Prüfen Sie sowohl die Quell- als auch die Ziel-Firewall.

# Story 2: “Lateral Movement nach Web-Hack”

Symptom: Ein Angreifer übernimmt einen Webserver. Er nutzt diesen als Proxy, um das interne Netzwerk zu scannen und findet offene Redis-Instanzen ohne Passwort. Ursache: Fehlende Egress-Filterung (Artikel 312) auf dem Webserver und fehlende Segmentierung zwischen Web- und App-Layer. Lösung: Isolieren Sie Webserver in einer DMZ. Verbieten Sie ihnen jeglichen Zugriff auf das interne Netz, außer auf die spezifischen Load-Balancer oder API-Endpunkte.

# 6. Fazit & Empfehlung

• Gruppierung: Fassen Sie Server mit ähnlichem Risiko-Profil in einer Zone zusammen.
• Inkonsistenz: Nutzen Sie keine “Multihomed” Server (Server in vielen Netzen gleichzeitig), wenn diese als Router missbraucht werden könnten.
• Wahl: Nutzen Sie für die Segmentierung Hardware-Unterstützung (Switches mit ACLs) kombiniert mit Host-Software-Firewalls.

# Anhang: Cheatsheet für Architekten