Netzwerksegmentierung und Mikrosegmentierung für Zero Trust

Netzwerksegmentierung verhindert Lateral Movement - die größte Gefahr nach dem Initial Access. Wer einmal im Netz ist, kann sich unbegrenzt bewegen wenn keine Segmentierung existiert. Dieser Guide zeigt den Weg von der VLAN-Basis bis zur Zero-Trust-Mikrosegmentierung.

Warum Segmentierung entscheidend ist

Das Problem ohne Segmentierung (Flat Network)

• Angreifer gelangt auf einen Rechner (Phishing)
• Lateral Movement: sofort Zugriff auf alle 500 anderen Rechner
• Keine Firewall zwischen Workstations und Servern
• Ransomware breitet sich in Minuten aus

Reale Schäden:

• Notpetya 2017: startete auf einem System → verschlüsselte in 90 Minuten 40.000 Maersk-Rechner weltweit
• Colonial Pipeline 2021: Ransomware auf Bürounetz → Sicherheitsbedenken für OT → Pipeline abgeschaltet

Mit Segmentierung

• Phishing-Opfer: Workstation im User-VLAN
• Angreifer sieht: nur andere Workstations (im gleichen VLAN)
• Firewall blockiert: Workstation → Server-VLAN (kein Lateral Movement!)
• Domain Controller: nur aus IT-VLAN erreichbar
• Schaden: begrenzt auf ein Segment

VLAN-Konzept: Layer-2-Segmentierung

Typische VLAN-Struktur für Mittelstand

VLAN	Funktion	Subnetz
VLAN 10	Server (Production)	192.168.10.0/24
VLAN 20	Server (Development)	192.168.20.0/24
VLAN 30	Users (Standard)	192.168.30.0/24
VLAN 40	Users (Management/IT)	192.168.40.0/24
VLAN 50	IoT/Drucker/Geräte	192.168.50.0/24
VLAN 60	WLAN-Gäste	192.168.60.0/24
VLAN 70	VoIP	192.168.70.0/24
VLAN 80	Backup-Systeme	192.168.80.0/24
VLAN 90	Management (Netz-Geräte)	192.168.90.0/24
VLAN 100	OT/ICS (falls vorhanden)	10.10.0.0/24

Firewall-Regeln zwischen VLANs

Von → Nach	Regel
Users → Server	Spezifische Ports! (443/HTTPS, 445/SMB wenn nötig)
Users → Users	DENY ALL (Workstation zu Workstation blockiert!)
IoT → Server	DENY ALL (Drucker braucht keine AD-Verbindung!)
Gäste → intern	DENY ALL + nur Internet-Zugang
Backup → Server	Nur Backup-Ports (VSS, VEEAM-Agent)
Management → alle	Restricted (nur IT-Admins!)

Cisco-Konfigurationsbeispiel

interface GigabitEthernet0/1
  description "User Workstation Port"
  switchport mode access
  switchport access vlan 30
  spanning-tree portfast
  storm-control broadcast level 20
  ip dhcp snooping limit rate 15

interface GigabitEthernet0/24
  description "Trunk zu Firewall"
  switchport mode trunk
  switchport trunk allowed vlan 10,20,30,40,50,60,70,80,90,100

DMZ-Architektur

DMZ-Konzept

Internet → [Außen-Firewall] → DMZ → [Innen-Firewall] → Internes Netz

In der DMZ (öffentlich erreichbar, aber isoliert):

• Web-Server (HTTPS 443)
• Mail-Gateway (SMTP 25, IMAPS 993)
• VPN-Concentrator
• Reverse Proxy / WAF
• Jump Server (Bastion Host für externe Admins)

Regel-Grundsatz:

• Internet → DMZ: nur spezifische Ports
• DMZ → Intern: nur das nötigste (DB-Verbindung, LDAP)
• Intern → DMZ: Admin-Zugriff (aus IT-VLAN!)
• Internet → Intern: NIEMALS direkt!

Bastion Host / Jump Server

• Einziger Einstiegspunkt für externe Admin-Zugänge
• Sehr stark gehärtet (nur SSH/RDP, keine anderen Dienste)
• MFA: immer!
• Logging: alle Sessions aufgezeichnet (PAM-Integration)
• Session-Timeouts: 15 Minuten Inaktivität

# Cloud-Bastion (AWS) - Temporärer SSH-Key (60 Sekunden gültig → kein permanenter Key!):
aws ec2-instance-connect send-ssh-public-key \
  --instance-id i-1234567890abcdef0 \
  --availability-zone eu-central-1a \
  --instance-os-user ec2-user \
  --ssh-public-key file://my-pub-key.pub

Mikrosegmentierung

Traditionell vs. Mikrosegmentierung

Traditionell: Segmentierung auf VLAN/Subnet-Ebene

• Alle Server im VLAN 10 können miteinander reden
• Web-Server kann Datenbank-Server ansprechen → OK
• Web-Server kann auch Backup-Server ansprechen → Kein Problem?

Mikrosegmentierung: Segmentierung auf Workload-Ebene

• Jeder Server: nur erlaubte Verbindungen (Whitelist!)
• Web-Server darf NUR: Port 3306 auf DB-Server X
• Sonst: alles geblockt (Default-Deny)

Implementierungsansätze

Host-based Firewall (Basis):

• Windows Firewall / iptables/nftables
• Jeder Server: eigene Firewall-Regeln
• Problem: 1.000 Server = 1.000 Regelsätze zu verwalten

VMware NSX (Software-Defined Networking):

• Mikrosegmentierung im Hypervisor
• Jede VM: Distributed Firewall
• Policy: zentral verwaltet, überall durchgesetzt
• Ohne Netzwerk-Änderungen (nur Software!)

Illumio Core:

• Agent-basiert (Linux/Windows)
• Automatisches Mapping: welcher Workload redet mit wem?
• Policy als Code: Terraform/API-gesteuert
• Zero-Trust-Labeling: Apps, Envs, Rollen

# Illumio Workload-Labels:
# Role: web / db / app / backup
# App:  ecommerce / erp / crm
# Env:  prod / staging / dev
# Loc:  dc1 / aws / azure

# Policy: web (prod) darf mit db (prod) auf Port 5432
# Alles andere: geblockt (Default-Deny!)

Kubernetes NetworkPolicy (Container)

# Standard: alle Pods können miteinander reden (unsicher!)
# NetworkPolicy: Default-Deny + Whitelist
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}       # Alle Pods
  policyTypes:
    - Ingress
    - Egress
# Dann: spezifische Policies für erlaubte Verbindungen

Cloud-Netzwerksegmentierung

AWS VPC Design

# 3-Tier-Architektur in AWS:
VPC: 10.0.0.0/16

Public Subnets (Load Balancer, NAT Gateway):
  10.0.1.0/24 (AZ a)
  10.0.2.0/24 (AZ b)

Private Subnets (App-Tier):
  10.0.11.0/24 (AZ a)
  10.0.12.0/24 (AZ b)

Database Subnets (DB-Tier):
  10.0.21.0/24 (AZ a)
  10.0.22.0/24 (AZ b)

Security Groups (Firewall):

• ALB-SG: nur 443 vom Internet
• App-SG: nur 8080 vom ALB (keine direkte Internet-Verbindung!)
• DB-SG: nur 5432 von App-SG (keine Internet-Verbindung!)

# AWS VPC Flow Logs - Netzwerkverkehr protokollieren:
aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-id \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-group-name /aws/vpc/flowlogs

# Suspicious Flows erkennen:
# Verbindung von App-Tier direkt nach Internet? → Alert!
# Verbindung von DB-Subnet nach Public? → Alert!

Azure Virtual Network (VNet)

# Network Security Groups (NSG) an Subnets:
az network nsg create --name "app-nsg" --resource-group myrg

az network nsg rule create \
  --nsg-name "app-nsg" \
  --name "allow-from-lb" \
  --priority 100 \
  --source-address-prefixes "10.0.1.0/24" \   # LB-Subnet
  --destination-port-ranges "8080" \
  --access Allow

az network nsg rule create \
  --nsg-name "app-nsg" \
  --name "deny-all-inbound" \
  --priority 4096 \
  --access Deny --direction Inbound

Häufige Segmentierungsfehler

Das AWARE7-Penetrationstester-Team findet diese Fehler regelmäßig:

Fehler 1: Drucker im gleichen VLAN wie Server

• Drucker haben oft schwache Credentials
• Angreifer kompromittiert Drucker → Zugriff auf Server-VLAN!
• Fix: IoT-VLAN mit Default-Deny nach Server

Fehler 2: Flat WLAN-Netz ohne Gäste-Trennung

• Gäste-WLAN und Firmen-WLAN im gleichen Segment
• Gast kann auf Dateiserver zugreifen
• Fix: komplett getrenntes VLAN + kein Internetzugang auf Corp-Resources

Fehler 3: Domain Controller für alle erreichbar

• DC sollte nur aus IT-VLAN + Server-VLANs erreichbar sein
• Häufig: alle VLANs haben Zugriff auf DC (Port 88, 389, 636, 445)
• Kerberoasting von jedem Workstation-VLAN möglich!

Fehler 4: Backup-System im gleichen Segment wie Produktion

• Ransomware verschlüsselt Produktion → springt auf Backup
• Fix: Backup-VLAN isoliert, kein direkter Zugriff von Prod auf Backup

Fehler 5: Management-Netz ohne Segmentierung

• IPMI/iDRAC/iLO auf gleichem VLAN wie Users
• Management-Interfaces direkt erreichbar → volle Server-Kontrolle!
• Fix: dediziertes Management-VLAN, nur aus IT-VLAN erreichbar

Fehler 6: Alte Regeln nie entfernt

• Firewall-Regeln akkumulieren über Jahre
• “Only for testing” von 2018 steht noch drin
• Regelwerk-Audit: mindestens jährlich!