Layer-3-Security: IP-Spoofing, Routing-Abuse und Filtering

Layer-3-Security entscheidet in vielen Netzen darüber, ob Angriffe nur „Lärm“ bleiben oder ob sie sich schnell ausweiten: Auf IP-Ebene lassen sich Quellen fälschen, Routing-Entscheidungen missbrauchen und ganze Kommunikationspfade umleiten. Während Layer-2-Kontrollen wie DHCP Snooping oder Dynamic ARP Inspection vor allem lokale Segmente schützen, betrifft Layer 3 die Netzgrenzen, Inter-VLAN-Routing, WAN-Anbindungen, Cloud-Konnektivität und die Übergänge zu Partnern oder Dienstleistern. Genau dort entstehen typische Sicherheitsrisiken: IP-Spoofing für DDoS-Reflexion oder Tarnung, Routing-Abuse durch falsche Routen oder Prefix-Hijacking und unzureichendes Filtering, das „verbotene“ Pakete unbemerkt passieren lässt. Ein gut gehärtetes Layer-3-Design ist daher weniger eine einzelne Funktion als ein Bündel aus klaren Policies: Ingress-/Egress-Filter, Anti-Spoofing, Routing-Authentisierung, sinnvolle Segmentierung und Telemetrie, die Abweichungen sichtbar macht. Dieser Artikel zeigt praxisnah, welche Angriffsformen auf Layer 3 realistisch sind, wie Sie die Angriffsfläche reduzieren und welche Filter- und Routing-Kontrollen im Betrieb tatsächlich helfen.

Warum Layer 3 eine eigene Sicherheitslogik braucht

IP ist das verbindende Element zwischen Segmenten, Standorten und Netzen. Sobald Traffic geroutet wird, sind klassische „nur lokal“-Mechanismen nicht mehr ausreichend. Gleichzeitig ist IP bewusst flexibel: Ein Router entscheidet anhand von Routing-Tabellen und Policies, wohin ein Paket geht. Genau diese Flexibilität kann missbraucht werden.

• Skalierungseffekt: Ein Fehler oder Missbrauch an einer Routing-Grenze kann viele Segmente gleichzeitig betreffen.
• Vertrauenszonen: Übergänge (Campus↔DC, DC↔Cloud, Cloud↔Internet) sind natürliche Angriffs- und Fehlkonfigurationspunkte.
• Identitätsproblem: IP-Quellen lassen sich fälschen; ohne Anti-Spoofing ist Attribution schwierig.
• Routing ist Steuerung: Wer Routen kontrolliert, kontrolliert Pfade – mit potenziell großem Impact.

IP-Spoofing: Was es ist und warum es weiterhin relevant ist

Unter IP-Spoofing versteht man das Fälschen der Quell-IP-Adresse in IP-Paketen. Der Angreifer nutzt das, um Identität zu verschleiern, Rückantworten umzuleiten oder DDoS-Reflexion zu ermöglichen. Wichtig ist die Unterscheidung zwischen Szenarien, bei denen Spoofing technisch sinnvoll ist, und solchen, bei denen es durch den notwendigen Rückkanal begrenzt wird.

• Reflexions-/Amplification-DDoS: Spoofing ist zentral, weil Antworten an das Opfer gehen sollen.
• Tarnung in Stateless-Angriffen: Bei UDP oder bestimmten ICMP-Mustern ist Spoofing leichter nutzbar.
• Begrenzung bei TCP: Für echte TCP-Sessions ist Spoofing deutlich schwieriger, weil der Rückkanal und Sequenzmechanismen fehlen – aber nicht völlig irrelevant (z. B. bei SYN-Flood).

Ein etablierter Best-Practice-Rahmen gegen Spoofing ist „Network Ingress Filtering“, bekannt als BCP 38. Eine passende Referenz ist RFC 2827 sowie die weiterentwickelte Fassung RFC 3704, die Anti-Spoofing-Praktiken und Varianten beschreibt.

Typische Spoofing-Failure-Modes in Enterprise-Netzen

In vielen Unternehmen entsteht Spoofing-Risiko weniger durch „böse“ interne Akteure als durch fehlende Baseline-Filter und unklare Transit-Pfade. Häufige Muster:

• Offene Campus-Uplinks: Access-/Distribution-Routing ohne konsequentes Ingress-Filtering pro Segment.
• Zu große Trust-Zonen: „Intern ist vertrauenswürdig“ führt zu wenigen Kontrollen zwischen VLANs.
• Fehlende Egress-Kontrollen: Ausgehender Traffic wird nicht auf plausible Quellen geprüft, was Reflexionsmissbrauch ermöglicht.
• Asymmetrische Pfade: Rückwege laufen anders als Hinwege; schlecht konfiguriertes Reverse Path Filtering wird dann entweder zu permissiv oder verursacht Drops.

Routing-Abuse: Von Fehlkonfiguration bis Hijacking

Routing-Abuse umfasst absichtliche oder unbeabsichtigte Manipulationen von Routing-Informationen. In Enterprise-Kontexten sind es oft zunächst Fehlkonfigurationen (falsche Summaries, falsche Redistribution, zu breite Default-Routen), im Internet-Kontext kommt Prefix Hijacking oder Route Leak hinzu. Das gemeinsame Risiko: Traffic fließt nicht dort entlang, wo er soll.

• Route Leak: Routen, die nur intern gedacht sind, werden nach außen propagiert oder zwischen Domänen „geleakt“.
• Prefix Hijack: Ein Netz kündigt ein Prefix an, das ihm nicht gehört, und zieht Traffic an.
• Policy-Bypass: Wenn Routing so verändert wird, dass Firewalls, Proxies oder Inspection-Punkte umgangen werden.
• Blackholing: Entweder absichtlich (Mitigation) oder versehentlich (Fehler) wird Verkehr ins Leere geroutet.

Für betriebliche Internet-Routing-Hygiene sind die Prinzipien von MANRS eine hilfreiche Orientierung, insbesondere zu Filterung, Anti-Spoofing, Koordination und Validierung von Routing-Informationen.

Filtering auf Layer 3: Die wichtigste Baseline, die oft fehlt

Layer-3-Filtering bedeutet nicht automatisch „Firewall“. Häufig sind es Router-ACLs, Prefix-Listen, Policy-Based Routing (PBR) und Edge-Policies, die verhindern, dass unerwartete Quellen, Ziele oder Protokolle überhaupt passieren. Der Schlüssel ist ein klares Modell: Was ist auf welchem Interface „zulässig“?

• Ingress Filtering: Prüfung eingehender Pakete auf plausible Quellen (Anti-Spoofing) und zulässige Zielbereiche.
• Egress Filtering: Kontrolle ausgehender Pakete, um Missbrauch und Datenabfluss zu begrenzen (auch für Compliance relevant).
• Transit Filtering: Zwischen Zonen definieren, welche Protokolle und Netze überhaupt geroutet werden.

Anti-Spoofing in der Praxis: uRPF und klassische ACLs

Zwei verbreitete Werkzeuge gegen Spoofing sind klassische Access Control Lists (ACLs) und Unicast Reverse Path Forwarding (uRPF). Beide haben ihren Platz – und beide scheitern, wenn man ihre Grenzen ignoriert.

ACL-basierte Anti-Spoofing-Regeln

ACLs sind transparent und kontrollierbar: Sie definieren, welche Quellpräfixe auf einem Interface überhaupt akzeptiert werden. Besonders effektiv ist das an klaren Segmentgrenzen, etwa an VLAN-SVI-Interfaces oder an WAN-/Provider-Edges.

• Stärken: deterministisch, auditierbar, gut für stabile Segmente.
• Schwächen: Pflegeaufwand bei vielen Präfixen, Fehleranfälligkeit bei dynamischen Umgebungen.

uRPF: Plausibilitätsprüfung über Routing-Tabellen

uRPF prüft, ob der Router für die Quelladresse eines Pakets einen plausiblen Rückweg kennt. Ist der Rückweg unplausibel, wird das Paket verworfen. Je nach Modus kann uRPF strenger oder toleranter sein.

• Strikter Modus: Rückweg muss über dasselbe Interface gehen; stark gegen Spoofing, aber empfindlich bei asymmetrischem Routing.
• Lockerer Modus: Rückweg muss nur existieren; toleranter, aber weniger strikt gegen bestimmte Missbrauchsszenarien.

Die praktische Einordnung und typische Einsatzmuster finden sich in RFC 3704 im Kontext von Ingress Filtering und Reverse-Path-Prüfungen.

Was „gutes Filtering“ auf Layer 3 konkret beinhaltet

Viele Filtersets scheitern, weil sie zu allgemein sind („deny bad stuff“) statt klar zu definieren, was gut ist. Eine robuste Layer-3-Security-Baseline enthält typischerweise diese Bausteine:

• Ingress: nur erwartete Quellen: Auf Access-/WAN-Edges akzeptieren Sie nur die Präfixe, die dort wirklich entstehen dürfen.
• Default-Drop für illegitime Bereiche: Pakete mit Quellen aus RFC1918/RFC6598/RFC5735-Sonderbereichen sollten an Internet-Edges nicht auftauchen.
• Kontrolle von ICMP: ICMP ist wichtig für Path MTU Discovery und Fehlerdiagnose, sollte aber bewusst freigeschaltet und beobachtet werden.
• Fragmentierung berücksichtigen: Filtering muss Fragmente korrekt behandeln; sonst entstehen Umgehungs- oder False-Positive-Risiken.
• Logging mit Augenmaß: Nicht jedes Drop-Event ist ein Incident; aber Trends und Peaks sind wertvoll.

Routing-Härtung im Enterprise: OSPF, BGP und Redistribution sicher gestalten

Viele Unternehmen nutzen intern OSPF/IS-IS und an Kanten BGP (z. B. zu Providern, Cloud-Interconnects oder großen Standorten). Die größte Angriffsfläche entsteht dort, wo Routing-Domänen zusammengeführt werden: Redistribution, Default-Routes, Summarization und Policy.

• Redistribution minimieren: Nur die Präfixe importieren, die wirklich gebraucht werden; alles andere explizit blocken.
• Prefix-Listen statt „any“: Jede Route, die Sie annehmen oder announcen, sollte gegen erwartete Prefix-Listen geprüft werden.
• Max-Prefix Limits: Schutz gegen Routing-„Explosion“ (Fehlkonfiguration oder Leak), um Tabellen stabil zu halten.
• Auth für IGP: OSPF/IS-IS-Authentisierung reduziert das Risiko, dass ein fremder Router Routing-Updates einspeist.

Internet-Routing: Route Hijacking und RPKI-Validierung

Wenn Sie eigene öffentliche Präfixe announcen oder stark von Internet-Routen abhängen, ist die Validierung von BGP-Ankündigungen ein zentraler Bestandteil moderner Layer-3-Security. RPKI (Resource Public Key Infrastructure) ermöglicht, Route Origin Authorization (ROA) zu veröffentlichen, damit Empfänger prüfen können, ob ein AS ein Präfix legitim originieren darf.

• Effekt: Reduziert das Risiko von einfachen Origin-Hijacks, wenn Netzbetreiber Validierung aktiv nutzen.
• Praxis: ROAs pflegen und BGP-Policies so ausrichten, dass „invalid“ Routen sauber behandelt werden.
• Grenze: RPKI löst nicht alle BGP-Probleme (z. B. Path-Manipulation), ist aber eine starke Baseline.

Für einen fundierten Einstieg in RPKI und ROAs ist die Informationsseite der RIPE NCC zu RPKI hilfreich.

Segmentierung auf Layer 3: Warum Subnetze, VRFs und Zonen entscheidend sind

Filtering wirkt besser, wenn die Architektur die richtigen Durchsetzungspunkte bietet. In flachen Netzen mit riesigen Subnetzen ist es schwer, „normales“ von „anomalem“ Verkehr zu trennen. Saubere Layer-3-Segmentierung schafft klare Grenzen.

• Kleinere Subnetze: reduzieren Broadcast- und Fehlerdomänen und machen Ingress-Filter präziser.
• Zonenmodelle: Office, Server, Management, OT/IoT, DMZ, Guest – mit definierten Übergängen.
• VRFs: trennen Routing-Tabellen logisch; besonders wertvoll für Mandantentrennung, Management-Isolation oder Partnernetze.

Quick Checks: Plausibilität von Präfixen und Hostanzahl

Auch im Security-Kontext ist es manchmal nützlich, CIDR-Präfixe schnell zu plausibilisieren, etwa wenn Segmentgrößen „zu groß“ sind oder wenn Filterlisten unübersichtlich werden. Die Anzahl nutzbarer IPv4-Hosts in einem Subnetz lässt sich grob berechnen als:

$\mathrm{Hosts}\approx 2^{32-\mathrm{Prefix}}-2$

Die Subtraktion um 2 berücksichtigt typischerweise Netzwerk- und Broadcast-Adresse (je nach Sonderfällen). Der Sicherheitsnutzen: Je kleiner ein Segment, desto geringer der potenzielle „Blast Radius“ bei Spoofing- oder Routingproblemen.

Telemetrie und Detection: Was Sie auf Layer 3 messen sollten

Layer-3-Security lebt von Sichtbarkeit. Ohne Telemetrie werden Spoofing- und Routingprobleme erst bemerkt, wenn Anwendungen ausfallen oder externe Meldungen kommen. Sinnvolle Signale:

• Drop Counters und ACL Hits: Trends sind wichtiger als Einzelevents; Peaks können DDoS oder Fehlkonfiguration signalisieren.
• Routing-Änderungen: plötzliche Prefix-Änderungen, Default-Route-Wechsel, ungewöhnliche Redistribution-Events.
• NetFlow/IPFIX: wer spricht mit wem, mit welchen Volumina – hilfreich für Spoofing-Indikatoren und Datenabfluss.
• Control-Plane-Protection: Messung von CPU/Queue-Last und Steuerverkehr (BGP/OSPF) gegen DoS und Instabilität.

Häufige Fehlannahmen: Warum Layer-3-Security in Audits oft „gut aussieht“, aber nicht wirkt

• „Firewall existiert, also passt es“: Wenn Routing Firewalls umgeht oder interne Zonen zu offen sind, hilft die Existenz allein nicht.
• „Intern ist vertrauenswürdig“: Spoofing und laterale Bewegung beginnen häufig innerhalb des Netzes.
• „uRPF überall aktivieren“: ohne Verständnis für asymmetrische Pfade erzeugt das schwer erklärbare Drops.
• „BGP ist nur Provider-Thema“: Cloud-Edges, SD-WAN und Partneranbindungen machen Routing-Policy zu einem Enterprise-Thema.
• „Logging = Sicherheit“: Logging ohne Triage und Schwellenwerte erzeugt Rauschen statt Schutz.

Pragmatische Baseline: Ein Layer-3-Security-Set, das in den meisten Netzen funktioniert

• Anti-Spoofing an allen Kanten: Ingress-Filter (ACL/uRPF) pro Segment, Egress-Filter an Internet-/WAN-Edges.
• Routing-Policy restriktiv: Prefix-Listen, Max-Prefix, keine unkontrollierte Redistribution.
• Segmentierung erzwingen: Zonen/VRFs, definierte Übergänge, keine flachen „Super-VLANs“ ohne Not.
• Control-Plane schützen: Rate-Limits, CoPP/CPPr, Schutz der Routing-Protokolle.
• RPKI/Validierung nutzen: wenn öffentliche Präfixe/Internet-BGP relevant sind.
• Telemetrie operationalisieren: Drop-Trends, Routing-Changes, Flow-Daten und klare Incident-Runbooks.

Als übergreifende Orientierung für robuste Netzbetriebssicherheit sind die Empfehlungen von MANRS (für Routing-Hygiene) sowie die Anti-Spoofing-Grundlagen in RFC 2827 und RFC 3704 besonders hilfreich.

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.