Hardening-Checkliste L3/L4: Minimum Controls für Public Infrastructure

Eine Hardening-Checkliste L3/L4 beschreibt die minimalen, aber wirkungsvollen Schutzmaßnahmen auf Netzwerk- und Transportebene, die jede Public Infrastructure zuverlässig umsetzen sollte. Gemeint sind dabei Systeme und Übergabepunkte, die direkt oder indirekt vom Internet erreichbar sind: Edge-Router, Transit-Links, Internet-Gateways, DDoS-Mitigation, Load-Balancer, Firewalls, NAT, VPN-Edges und öffentliche Services, die auf L4 (TCP/UDP) exponiert werden. Gerade weil L3/L4-Controls oft „unsichtbar“ wirken, werden sie in vielen Umgebungen zu spät standardisiert – mit der Folge, dass Spoofing, Reflection, Scans, volumetrische DDoS-Attacken oder Routing-Fehlkonfigurationen unnötig großen Schaden anrichten. Diese Hardening-Checkliste L3/L4 liefert eine praxistaugliche Mindestbasis: Sie hilft, Angriffsflächen zu reduzieren, Kapazität für legitimen Traffic zu schützen, Fehlkonfigurationen schneller zu erkennen und Incident Response zu vereinfachen. Gleichzeitig ist das Ziel nicht maximale Restriktion um jeden Preis, sondern operierbare Sicherheit: jede Maßnahme muss messbar, wartbar und im Change-Prozess testbar sein.

Scope und Begriffe: Was zählt zu L3/L4-Hardening?

L3-Hardening betrifft IP-Routing und Paketbehandlung (IPv4/IPv6, ICMP/ICMPv6, Routing-Protokolle, Anti-Spoofing, MTU/Fragmentierung, Control-Plane-Schutz). L4-Hardening betrifft Transport-Mechanismen wie TCP/UDP (State-Tabellen, SYN-Handling, Connection-Limits, Timeouts, UDP-Amplification-Risiken, Service-Exposure). „Public Infrastructure“ meint dabei nicht nur klassische Rechenzentren, sondern auch Cloud-Edges, Anycast/PoPs, CDN-Anbindungen, Hybrid-Uplinks und externe Transit-Partner.

Hardening-Checkliste L3: Minimum Controls

Ingress Filtering gegen Spoofing (BCP38/BCP84)

Ein zentraler Minimum Control ist Ingress Filtering: Pakete mit gefälschter Quelladresse sollen möglichst nahe am Eintrittspunkt verworfen werden. Dadurch reduzieren Sie Reflection-/Amplification-Risiken und verhindern, dass Ihr Netz selbst als Plattform für Angriffe missbraucht wird. Die Grundlage dafür ist BCP 38, das das Filtern von Spoofing-Quellen beschreibt. Eine gut wartbare Referenz ist RFC 2827 (BCP 38).

• Ingress-Filter an Kunden-/Partner-Edges: nur Quellpräfixe zulassen, die zum jeweiligen Anschluss gehören.
• Anti-Spoofing an Internet-Edges: offensichtlich ungültige Quellen (Bogons, Special-Use) droppen.
• Regeln auch für IPv6 umsetzen (häufige Lücke in der Praxis).

uRPF sinnvoll einsetzen (strict vs. loose)

Unicast Reverse Path Forwarding (uRPF) ist ein wirksamer Baustein, wenn Routing-Pfade gut kontrolliert sind. In asymmetrischen Umgebungen kann „strict“ uRPF legitimen Traffic fälschlich verwerfen; „loose“ uRPF ist toleranter, aber weniger strikt. Entscheidend ist, die uRPF-Variante pro Edge-Kontext zu wählen (z. B. strict an klaren Customer-Edges, loose an komplexen Internet-Edges).

• uRPF strict nur dort, wo Rückwege eindeutig sind.
• uRPF loose bevorzugen, wenn Asymmetrie normal ist.
• Vor Aktivierung: Testfenster, Counter- und Drop-Analyse, Rollback definieren.

Bogon- und Special-Use-Adressen filtern (IPv4/IPv6)

Das Blocken nicht-routbarer oder reservierter Quelladressen („Bogons“) ist ein klassisches L3-Minimum-Control. Wichtig ist, sich an authoritative Quellen zu orientieren und die Regeln regelmäßig zu aktualisieren. Hilfreich sind die IANA-Register für Special-Purpose-Netze: IANA IPv4 Special-Purpose Address Registry und IANA IPv6 Special-Purpose Address Registry.

• Inbound aus dem Internet: RFC1918, Loopback, Link-Local, Dokumentationsnetze als Source droppen.
• IPv6: ULA (fc00::/7), Link-Local (fe80::/10), Dokumentationspräfix (2001:db8::/32) als Source droppen.
• Ausnahmen nur, wenn es einen dokumentierten technischen Grund gibt.

ICMP/ICMPv6: gezielt erlauben statt pauschal blocken

ICMP ist für Diagnose und Stabilität wichtig (z. B. PMTUD). Pauschales Blocken führt häufig zu schwer erklärbaren Problemen (Blackholing bei MTU, fehlerhafte Traceroutes, schlechte Fehlersignale). Für IPv6 ist ICMPv6 noch kritischer, weil Neighbor Discovery und bestimmte Control-Nachrichten essenziell sind. Eine gute technische Referenz ist RFC 4890 (ICMPv6 Filtering Recommendations).

• ICMP Rate Limits setzen (Control-Plane-Schutz), aber nicht „alles droppen“.
• IPv6: ICMPv6-Funktionen für ND/PMTUD gezielt erlauben.
• Monitoring: ICMP-Drops separat zählen und auf Path-MTU-Probleme prüfen.

Control-Plane-Protection (CoPP/CPPr) und Management-Plane-Hardening

Ein häufiges Ausfallmuster: Die Control Plane von Routern/Edges wird durch Flooding oder Scans überlastet (CPU hoch, Routing instabil, BGP-Sessions flappen). Minimum Controls sind daher Control-Plane-Policer und strikte Management-Zugriffe.

• CoPP/CPPr aktivieren: Schutzprofile für BGP, ICMP, Routing-Protokolle, SNMP, SSH, NTP.
• Management ausschließlich über dedizierte Management-Netze oder VPN/Zero-Trust-Zugänge.
• „No management from Internet“ als Standardregel.

Routing Security: Prefix Filtering, Max-Prefix, Policy Hygiene

Fehlkonfigurationen und Route Leaks sind in Public Infrastructure besonders kritisch, weil sie schnell großflächige Auswirkungen haben. Minimum Controls auf BGP-Sessions sind Prefix-Filter, Max-Prefix-Limits und klare Policies. Zusätzlich wird RPKI zunehmend als Standard betrachtet, um ungültige Routen zu erkennen. Für Grundlagen zu RPKI eignet sich die Dokumentation der RPKI-Community, z. B. RPKI-Dokumentation.

• Inbound Prefix Filter: nur erwartete Präfixe vom Peer akzeptieren.
• Outbound Prefix Filter: nur eigene/autorisiert angekündigte Präfixe announcen.
• Max-Prefix: Sessions schützen (Fehlkonfig, Route Leak, Table Explosion).
• RPKI Validation: Invalids droppen oder mindestens depriorisieren (Policy klar dokumentieren).

Fragmentierung, MTU und Path-MTU-Discovery bewusst behandeln

Fragmentierung und MTU-Probleme verursachen besonders bei Public Services schwer reproduzierbare Fehler. Ein Minimum Control ist, PMTUD nicht „kaputtzufiltern“ und Fragmente nicht blind zu verwerfen, ohne die Nebenwirkungen zu prüfen. Gleichzeitig sind Fragmente ein Missbrauchsvektor (Evasion, Ressourcenverbrauch). Das Ziel ist eine balancierte Policy: Fragmente reduzieren, aber Kompatibilität sicherstellen.

• PMTUD ermöglichen: relevante ICMP-Typen nicht pauschal blocken.
• Fragment-Handling dokumentieren: welche Zonen dürfen Fragmente, welche nicht.
• Monitoring für „fragment drops“ und MTU-bezogene Errors etablieren.

Hardening-Checkliste L4: Minimum Controls

Service Exposure: nur notwendige Ports, klare Ownership

Auf L4 ist das Grundprinzip: Was nicht benötigt wird, darf nicht erreichbar sein. Das umfasst sowohl klassische Port-Listen als auch Cloud Security Groups und Load-Balancer Listener. Jede offene Port-Freigabe braucht einen Owner, einen Zweck und eine Review-Frequenz.

• Inbound Allowlist: nur veröffentlichte Services erlauben (z. B. TCP/443, ggf. UDP/443 für QUIC).
• Management-Ports (SSH/RDP/WinRM/SNMP) niemals „public“; Zugriff nur via VPN/Bastion/Zero-Trust.
• Regelmäßige „Open Port“-Inventur (monatlich/vierteljährlich).

TCP-Schutz: SYN-Flood-Resilienz und Connection-Management

TCP-basierte Angriffe und Lastspitzen zielen häufig auf die Erzeugung von State: SYN-Floods, viele kurze Verbindungen, gezielte Erschöpfung von Conntrack/State Tables. Minimum Controls sind hier robuste SYN-Mechanismen, Limits und sinnvolle Timeouts.

• SYN Cookies oder SYN Proxy (je nach Plattform) aktivieren, wo sinnvoll.
• Connection Limits pro Source/IP/Prefix statt global, um Self-DDoS zu vermeiden.
• Time-outs prüfen: zu lange „half-open“-States erhöhen Risiko, zu kurze Timeouts brechen legitime Flows.
• Separates Monitoring: new connections/s, SYN rate, retransmissions (als Indikator für Overload).

State-Table-/Conntrack-Schutz: Kapazität, Telemetrie, Fallback

State-Exhaustion ist in Public Infrastructure ein häufiges Outage-Szenario. Minimum Controls sind: harte Kapazitätsgrenzen kennen, Frühwarn-Metriken messen und im Incident eine klare Recovery-Strategie haben (ohne „blind rebooten“).

• Telemetrie: State-Table-Auslastung, Drops wegen table full, NAT-Port-Auslastung.
• Thresholds: Warnungen früh (z. B. bei 70–80%), Critical später (z. B. 90–95%), abhängig vom System.
• Notfallplan: gezieltes Rate Limiting, temporäre Blocklisten, Scrubbing-Pfade aktivieren.

UDP-Hardening: Amplification vermeiden und Noise dämpfen

UDP ist für viele legitime Services relevant (DNS, VoIP, QUIC), aber auch Hauptträger volumetrischer DDoS-Angriffe. L4-Minimum Controls sind: keine unnötigen UDP-Services öffentlich, klare Rate Limits und Schutz gegen Reflection.

• Kein offener DNS-Resolver; DNS inbound nur für autoritative DNS oder definierte Use Cases.
• NTP restriktiv: Zugriff auf definierte Quellen beschränken, unnötige öffentliche Exposition vermeiden.
• UDP Rate Limits: pps- oder bandwidth-basiert, möglichst granular nach Source/Prefix.
• Visibility: Top UDP Ports, Top Sources, Spike-Erkennung (pps/bps).

Rate Limiting und Policing: Baseline-basiert statt Bauchgefühl

Damit Rate Limiting nicht legitime Peaks beschädigt, sollte es auf Messwerten basieren. Ein praktikables Vorgehen ist, Limits aus der P95-Baseline abzuleiten und einen Sicherheitsfaktor zu nutzen.

$L=P\times F$

P steht für die P95-Baseline (z. B. pps oder new connections/s) und F für einen Faktor (typisch 2–5, abhängig vom Service). Dieses Modell ersetzt keine Tests, liefert aber eine nachvollziehbare Startgröße.

• Erst „observe“ (Counter), dann „enforce“ (limitieren).
• Prefer per-source Limits (IP/Prefix/Token) statt globaler Limits.
• Ausnahmen nur mit Owner, Ablaufdatum und Review.

Anycast, CDN, Scrubbing: L4-Hardening über Architektur

Nicht jedes Problem ist durch einzelne Filterregeln lösbar. In Public Infrastructure ist die Architektur oft das wirksamste L4-Hardening: Anycast verteilt Last, CDNs absorbieren volumetrische Peaks, Scrubbing-Center filtern großflächige DDoS-Muster. Wichtig ist, diese Mechanismen in Ihre Checkliste als Minimum-Option aufzunehmen, wenn Ihr Risikoprofil es erfordert.

• Scrubbing-Integration testen: BGP-Announce/Withdraw, Failback, Timings, Ownership.
• CDN-Regeln auf L4 abstimmen (z. B. UDP/443 für QUIC nur, wenn benötigt).
• Anycast-Failover und Monitoring: Latenz, Packet Loss, Region-Verteilung.

Beobachtbarkeit als Minimum Control: Metriken, Logs, Korrelation

Hardening ohne Telemetrie ist operativ riskant. Minimum Controls definieren daher nicht nur „Filter setzen“, sondern auch „Filter messen“. Für L3/L4 sind besonders wichtig: Drops nach Regel, pps/bps pro Interface, new connections/s, State-Table-Auslastung, ICMP/ICMPv6 Drops, sowie Routing-Health (BGP Session State, Prefix Counts).

• Counter-first: dauerhaft Zähler statt Voll-Logging (Skalierung).
• Sampling für Drops/Flows, wenn Detailanalyse nötig ist.
• Dashboards: Top Drops, Top Sources (Prefix/ASN), Zeitverlauf, Korrelation mit Service-SLI (Latency/Errors).
• Alerting gegen Alert Fatigue: nur alarmieren, wenn Network-Signal + Service-Impact zusammen auftreten.

Change- und Test-Disziplin: So bleibt Hardening stabil

Viele Outages entstehen nicht, weil Hardening „falsch“ ist, sondern weil es ohne saubere Tests ausgerollt wurde. Minimum Controls für Public Infrastructure sollten daher auch den Prozess abdecken: Reviews, Staging, Rollback, Canary-Deployment und dokumentierte Validierung.

• Policy-as-Code: Regeln versionieren, Pull-Request-Review, automatisierte Checks.
• Shadow Mode: neue Regeln zuerst zählen/markieren, dann aktiv droppen.
• Canary-Rollout: zunächst ein PoP/Region/Edge, dann breit ausrollen.
• Rollback-Plan: „One-click disable“ oder klare Kommandos, getestet im Drill.
• Post-Change Checks: Connectivity, MTU/PMTUD, BGP-Stabilität, Service-Health.

Hardening-Checkliste L3/L4: Kompakte Mindestliste (audit- und ops-tauglich)

• Anti-Spoofing: Ingress Filtering nach BCP38 an geeigneten Edges; uRPF passend zum Routing-Kontext (strict/loose).
• Bogon Filtering: Special-Use/Bogon-Quellen inbound droppen (IPv4 und IPv6), Quellen regelmäßig aktualisieren (IANA).
• ICMP/ICMPv6: gezielt erlauben (PMTUD/ND), Rate Limits und Control-Plane-Schutz statt pauschalem Blocken.
• Control-Plane Protection: CoPP/Policer aktivieren; Management-Plane strikt isolieren, kein Public Management.
• Routing Hygiene: Prefix Filter, Max-Prefix, klare BGP-Policies; RPKI-Validierung nach Policy.
• Port Exposure: Inbound nur notwendige L4-Ports; regelmäßige Port-Inventur; Ownership pro Freigabe.
• TCP Resilienz: SYN-Schutz (Cookies/Proxy), per-source Connection Limits, sinnvolle Timeouts, Retransmission-Monitoring.
• State/Conntrack: Auslastung messen, Schwellenwerte definieren, Incident-Recovery-Runbook (Rate Limit, Scrubbing, Blocklisten).
• UDP Hardening: keine unnötigen UDP-Services öffentlich; Amplification-Risiken minimieren; pps/bps-Spike-Erkennung.
• Observability: Counter pro Regel/Interface, Top Drops/Sources, Korrelation mit Service-SLI, Logging sparsam (Sampling).
• Change Safety: Shadow Mode, Canary, Rollback getestet, Post-Change Checks verpflichtend.

Typische Failure Modes: Wo Minimum Controls oft scheitern

• IPv6 vergessen: IPv4 ist gehärtet, IPv6 permissiv – Angreifer nutzen die Lücke.
• ICMP „totgefiltert“: PMTUD bricht, Verbindungen wirken „random kaputt“.
• Strict uRPF an falscher Stelle: Asymmetrischer Traffic wird gedroppt, ohne dass es sofort auffällt.
• Globales Rate Limiting: Legitimer Traffic wird mitbestraft, Self-DDoS durch eigene Policies.
• Keine Counter: Drops passieren, aber niemand weiß warum; Troubleshooting dauert unnötig lange.

Outbound-Referenzen für vertiefende Standards und Empfehlungen

• RFC 2827 (BCP 38): Network Ingress Filtering
• IANA IPv4 Special-Purpose Address Registry
• IANA IPv6 Special-Purpose Address Registry
• RFC 4890: ICMPv6 Filtering Recommendations
• RPKI-Dokumentation: Grundlagen und Betrieb

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.