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

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.

• Spoofing und DDoS: gefälschte Quellen nutzen häufig private oder ungültige Adressräume.
• Fehlkonfiguration: Kunden oder Partner leaken RFC1918/ULA/Link-Local in Richtung Internet.
• Botnet-Noise: kompromittierte Hosts erzeugen unsinnige Pakete, die nur Ressourcen binden.
• Forensik-Qualität: wenn Bogons durchkommen, werden Logs und Analysen unzuverlässig.

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.

• Reduktion von Spoofing: weniger gefälschte Quellen am Edge, bessere DDoS-Abwehrgrundlage.
• Schutz der Infrastruktur: weniger unsinniger Traffic zur Control Plane und zu Infrastruktur-IPs.
• Höhere Datenqualität: saubere Netflow/IPFIX- und Firewall-Logs, bessere Attribution.
• Partnerreputation: weniger Abuse-Reports, weniger „Bad Neighbor“-Eindruck bei Peers.
• Operational Hygiene: klare Standardregel statt ad hoc „wieso sehen wir RFC1918 am IXP?“

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.

• Peering/IXP Edge: Bogon-Filter als Input-ACL/BPF auf Interconnect-Interfaces.
• Transit Edge: identischer Ansatz wie Peering, zusätzlich oft strengere Policies für Infrastruktur-IPs.
• Customer/Access Edge: abhängig vom Produkt: hier primär uRPF/BCP38 und Kundenprefix-Filter, Bogons ergänzend.
• Core: Bogon Filtering ist dort meist zweitrangig; besser am Rand stoppen, Core nicht „zum Filterpunkt“ machen.
• Management/Service VRFs: keine Internet-Bogon-Liste blind anwenden; dort sind RFC1918/ULA oft legitim.

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.

• Private Adressen: RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
• Loopback: 127.0.0.0/8.
• Link-Local: 169.254.0.0/16.
• Multicast und Broadcast-Sonderfälle: je nach Policy, typischerweise nicht als unicast Source zulassen.
• Dokumentationsnetze: Bereiche, die für Beispiele reserviert sind, gehören nicht als echte Internetquellen auf den Edge.
• Reserved/Special Use: Adressräume, die im Internet nicht geroutet werden sollten (z. B. bestimmte Test-/Benchmark-/Reserved-Blöcke).

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.

• Link-Local: fe80::/10 gehört nicht als Internetquelle auf einen Transit-/Peering-Port.
• Unique Local Addresses (ULA): fc00::/7 gehören nicht in öffentliche Internetquellen.
• Loopback/Unspecified: ::1/128 und ::/128 sind als Source im Internet unsinnig.
• Dokumentationsprefixe: z. B. 2001:db8::/32 ist nicht produktiv zu routen.
• Multicast: ff00::/8 ist nicht als Unicast Source legitim.

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.

• Source-Bogon-Filtering: Baseline-Pflicht an Internetkanten.
• Destination-Bogon-Filtering: sinnvoll als Schutz von Infrastruktur-IPs und internen Netzen, aber abhängig von Design (VRFs, NAT, DDoS-Scrubbing).
• Infrastructure Protection: Router-Loopbacks und Management-IPs durch separate Infrastructure-ACLs schützen.

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.

• Bogon am Peering/Transit: stoppt „gar nicht plausible“ Quellen sofort.
• uRPF/Ingress am Access: stoppt Kundenspoofing selbst mit scheinbar gültigen Internetprefixes.
• CoPP/CPPr: schützt CPU vor Control-Plane-Noise, auch wenn Filter mal etwas durchlassen.
• DDoS-Integration: Flowspec/RTBH/Scrubbing als Reaktion auf große Angriffe ergänzen Hygiene.

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.

• Pflege über Feed: dynamische Bogon-Prefixes nicht manuell pflegen, sondern automatisiert und versioniert.
• Canary Rollout: zuerst ausgewählte Edge-Ports/PoPs, dann ausrollen.
• Monitoring der Drops: Drop-Counter, Top Sources, Spike-Detection – damit Sie Fehlfilter schnell sehen.
• Standard-Runbook: „Kunde meldet Erreichbarkeitsproblem“ → check Bogon drops → validate prefix status → adjust.
• Rezertifizierung: regelmäßige Reviews, ob die Liste aktuell ist und ob Ausnahmen noch nötig sind.

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.

• Pflichtmetriken: Drops pro Interface/PoP, Drops nach Prefixklasse (RFC1918, Link-Local, ULA), PPS/Spikes.
• Top Offenders: Top Quellprefixe und Top ASNs (wo ableitbar) für Incident Triage.
• Anomaliealarme: plötzliche Drop-Spikes, neue Muster, Peaks im Zusammenhang mit DDoS.
• Selective Logging: nur bei Investigations oder kurzzeitigen Deep-Dives detailliert loggen.

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

• Statische Listen ohne Updates: veralten und können legitime Prefixes blockieren, wenn IANA-Zuweisungen ändern.
• Einheitliche Regeln ohne Zonenmodell: Bogon-Filter im Management-VRF kann legitime private Netze brechen.
• Nur Destination-Filterung: lässt Spoofing-Quellen durch und verfehlt den Hauptnutzen.
• Keine CoPP/Rate Limits: selbst mit Bogons kann Control Plane durch andere Noise-Vektoren leiden.
• Keine Observability: Drops passieren, aber niemand sieht Muster oder Fehlfilter rechtzeitig.

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

• Source-Bogon-Filtering Pflicht: RFC1918, Loopback, Link-Local, ULA, Dokumentationsprefixe und weitere Special-Use-Bereiche am Internet-Edge droppen.
• IPv4 und IPv6 getrennt: eigene Listen und Policies, inklusive IPv6-spezifischer Special-Use-Prefixes.
• Zonenmodell beachten: Internet/Peering/Transit streng, Management/Service-VRFs differenziert.
• Feed-basierte Pflege: dynamische Bogons automatisiert aktualisieren, versionieren und rezertifizieren.
• Operational Safety: Canary Rollout, Drop-Monitoring, Runbooks für Fehlfilter und Ausnahmen.
• Integration mit uRPF/BCP38: Bogons am Edge, Ingress-Filter am Access, CoPP als Schutz der Control Plane.
• Observability: Drops/Spikes/Top Offenders messen, gezielte Alarme statt Log-Flut.

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

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

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.