Site icon bintorosoft.com

Bogon Filtering: Baseline-Regeln für Provider Edge und Internet

Red Snapper

IT technician patching network cables in a data center, high detail, 8k --ar 3:2 Job ID: e9684b02-5319-4bac-85cc-7547fc73db90

Bogon Filtering gehört zu den wichtigsten „Hygiene“-Maßnahmen an der Provider Edge und am Internet-Perimeter, weil es eine große Klasse offensichtlich ungültiger oder unerwünschter IP-Quellen und -Ziele konsequent entfernt. „Bogons“ sind dabei vereinfacht gesagt Adressbereiche, die im öffentlichen Internet nicht geroutet werden sollten – zum Beispiel private RFC1918-Netze, Link-Local-Adressen, Loopbacks, Dokumentationsnetze oder nicht zugewiesene/reservierte Prefixes. Wenn solche Adressen trotzdem auf Ihrem Edge auftauchen, ist das fast immer ein Hinweis auf Spoofing, Fehlkonfiguration oder Missbrauch. Für Telcos und ISPs ist Bogon Filtering besonders relevant: Es reduziert Spoofing-Risiko, senkt die Wahrscheinlichkeit, als Quelle von Reflection/Amplification missbraucht zu werden, entlastet DDoS- und Abuse-Prozesse und verbessert die Qualität von Telemetrie und Forensik. Gleichzeitig muss eine Baseline realistisch sein: Bogon-Listen ändern sich (z. B. wenn Prefixes neu vergeben werden), IPv6 bringt eigene Spezialfälle, und unbedachtes Filtern kann in Sonderarchitekturen (Tunneling, Carrier NAT, CGNAT, Management-VRFs) Kollateralschäden verursachen. Dieser Artikel zeigt eine praxistaugliche Baseline: Welche Bogon-Regeln an Provider Edge und Internet gehören, wo sie greifen sollten, wie man sie pflegt, und welche typischen Fehler man vermeiden muss.

Was sind Bogons – und warum tauchen sie überhaupt am Internet-Edge auf?

Im Normalfall sollten an einer Internetkante nur öffentlich routbare Quell- und Zieladressen sichtbar sein. Bogon-Traffic entsteht meist aus drei Ursachen: Erstens Spoofing, bei dem Angreifer Quelladressen fälschen, um Rückverfolgung zu erschweren oder Reflection zu ermöglichen. Zweitens Fehlkonfigurationen, etwa wenn ein Kunde private Adressen ins Internet „leakt“, falsch genattete Pakete erzeugt oder Router falsche Routen exportieren. Drittens „Noise“ aus kompromittierten Systemen und Botnets, die über scanningartige Muster Pakete mit unsinnigen Quellen senden. Für Provider ist der Befund simpel: Bogon-Pakete haben im öffentlichen Internet fast nie eine legitime Funktion – und sind daher ein idealer Kandidat für Baseline-Filter am Rand.

Baseline-Ziele: Warum Bogon Filtering in Telco-Netzen „Pflicht“ ist

Eine Baseline ist dann sinnvoll, wenn sie mit wenig Risiko viel Wirkung erzielt. Genau das trifft auf Bogon Filtering zu: Es blockt Traffic, der im öffentlichen Internet praktisch nie legitim ist, und reduziert damit mehrere Risiken gleichzeitig. Wichtig ist allerdings, dass Sie Bogon Filtering nicht als Ersatz für uRPF/BCP38, CoPP oder Routing-Policy verstehen. Es ist ein Baustein – aber ein sehr effektiver.

Wo Bogon Filtering in der Architektur greifen sollte

Der wichtigste Grundsatz lautet: Bogon Filtering wirkt am besten so nah wie möglich am Eintrittspunkt in Ihre öffentliche Domäne. In Provider-Netzen sind das typischerweise Peering/IXP-Edges, Transit-Uplinks, Internet-Edges von BRAS/BNG-/CGNAT-Umgebungen (je nach Design) sowie externe Interconnects. Gleichzeitig sollten Sie Bogon Filtering nicht blind in internen VRFs oder in Managementdomänen einsetzen, weil dort private Adressräume legitim sein können. Eine Baseline muss daher Zonen unterscheiden: Internet Edge vs. interne Service-/Management-Zonen.

Baseline-Regeln für IPv4: Welche Netze an der Internetkante geblockt werden sollten

Für IPv4 ist die Baseline in vielen Netzen relativ stabil: Es gibt Adressbereiche, die im öffentlichen Internet nie als Quelladresse auftauchen sollten. Eine praxisnahe Baseline unterscheidet dabei „klar ungültig“ (immer blocken) und „dynamisch“ (IANA-Status kann sich ändern). Provider sollten deshalb eine gepflegte Bogon-Liste nutzen, statt starre, unaktualisierte Prefixlisten über Jahre zu konservieren.

Baseline-Regel: „Always block“ vs. „Maintain with feed“

Einige Prefixes sind dauerhaft „always block“ (z. B. RFC1918, 127/8, 169.254/16). Andere hängen von aktueller IANA-Zuweisung ab (historisch „unallocated“). Eine Baseline sollte deshalb festlegen, dass dynamische Bogons über einen verlässlichen Feed gepflegt werden, statt in manuelle Listen zu wandern, die veralten.

Baseline-Regeln für IPv6: Mehr Spezialfälle, aber gleiche Logik

IPv6 bringt mehr Spezialadressen, die im öffentlichen Internet nicht als Source auftauchen sollten. Gleichzeitig ist IPv6 in vielen Provider-Netzen heute produktiv, und Fehlfilter können reale Kundenprobleme verursachen. Eine Baseline sollte IPv6 daher bewusst und sauber handhaben: „klar ungültige“ Sources konsequent blocken und gleichzeitig die notwendigen ICMPv6-Mechaniken nicht versehentlich kaputt filtern.

Quell- vs. Ziel-Filtering: Was an der Edge sinnvoll ist

Bogon Filtering wird häufig als „Source-Filter“ verstanden – und das ist auch der wichtigste Teil. Ziel-Filtering kann ebenfalls sinnvoll sein, ist aber vorsichtiger zu bewerten: Manche Ziele sind intern legitim (z. B. Managementnetze), andere sollten nie aus dem Internet erreichbar sein. Eine Baseline sollte daher Source-Bogon-Filtering als Pflicht setzen und Destination-Bogon-Filtering risikobasiert gestalten, insbesondere um zu vermeiden, dass interne Services unbeabsichtigt blockiert werden.

Zusammenspiel mit uRPF und BCP38: So wird die Baseline stark

Bogon Filtering reduziert offensichtlich falsche Quellen. uRPF und BCP38-ähnliche Ingress-Filterung gehen einen Schritt weiter: Sie prüfen, ob eine Quelladresse für diesen Kunden/Port plausibel ist. Die stärkste Baseline kombiniert daher: Bogon Filtering am Internet-Edge, uRPF/Ingress-Filter am Customer Edge, und CoPP als Schutz der Router-Control-Plane. So bekommen Sie sowohl breite Hygiene als auch präzise Anti-Spoofing-Kontrolle.

Operationalisierung: Wie Sie Bogon Filtering sicher einführen

Auch wenn Bogon Filtering „low risk“ ist, kann eine falsche Umsetzung schaden: veraltete Listen, falsche Reihenfolge in ACLs, unterschiedliche Implementierungen in Multi-Vendor-Edges oder fehlende Ausnahmen für spezielle Interconnect-Designs. Eine Baseline sollte deshalb einen klaren Rollout- und Pflegeprozess enthalten: Feed-Update, Canary-Rollout, Monitoring und Rezertifizierung.

Logging und Observability: Was Sie messen sollten (und was nicht)

Bogon Filtering ist ein ideales Signal für Security Operations: Drops sind meist „echter“ Missbrauch oder Fehlkonfiguration. Dennoch sollten Sie nicht jeden einzelnen Drop als Log-Event in ein SIEM kippen, sonst wird das Datenvolumen unbeherrschbar. Eine Baseline sollte daher auf aggregierte Telemetrie setzen und nur bei Anomalien in Detailtiefe gehen.

Typische Anti-Patterns: Was eine Bogon-Baseline verhindern sollte

Baseline-Checkliste: Bogon Filtering für Provider Edge und Internet

Mit dieser Baseline wird Bogon Filtering zu einem sauberen, wartbaren Standard an Provider-Edges: Sie entfernen offensichtlich ungültige Quellen frühzeitig, reduzieren Spoofing und DDoS-Missbrauch, verbessern die Qualität Ihrer Telemetrie und schaffen eine stabile Grundlage für weiterführende Controls wie uRPF, CoPP und DDoS-Mitigation – ohne sich durch veraltete Listen oder fehlende Zonierung neue Betriebsrisiken einzuhandeln.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

Sie erhalten

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.

Exit mobile version