Was ist eine Bogon-IP-Adresse und warum sie wichtig ist
Eine Bogon-IP-Adresse ist eine Adresse aus privatem, reserviertem oder nicht zugewiesenem Adressraum, die im öffentlichen Internet niemals als Quelle von Datenverkehr auftreten sollte. Der Name leitet sich von „bogus“ (falsch, unecht) ab. Die betroffenen Bereiche werden von der IANA und mehreren RFCs festgelegt. Ob eine Adresse ein Bogon ist, lässt sich also anhand einer veröffentlichten, standardbasierten Liste nachschlagen, statt es zu erraten.
Die wichtigsten Bogon-Bereiche
Man sollte zwei Gruppen unterscheiden. Reservierte Spezialbereiche sind durch Standards definiert und werden nie öffentlich geroutet. Nicht zugewiesener Adressraum, manchmal „Full Bogons“ genannt, ist Adressraum, den noch keine Registry vergeben hat. Die unten aufgeführten reservierten Bereiche begegnen Ihnen am häufigsten.
0.0.0.0/8: „dieses Netzwerk“; tritt als Quelle auf, wenn ein Host noch keine Adresse hat.10.0.0.0/8,172.16.0.0/12,192.168.0.0/16: private Netze nach RFC 1918.100.64.0.0/10: gemeinsamer Adressraum für Carrier-Grade NAT (RFC 6598).127.0.0.0/8: Loopback.169.254.0.0/16: Link-Local, wird automatisch vergeben, wenn DHCP fehlschlägt.192.0.0.0/24: IETF-Protokollzuweisungen.192.0.2.0/24,198.51.100.0/24,203.0.113.0/24: Dokumentationsblöcke (RFC 5737), die Ihnen in Beispielen und Tutorials begegnen.198.18.0.0/15: Netzwerk-Benchmarking (RFC 2544).224.0.0.0/4: Multicast.240.0.0.0/4: für künftige Verwendung reserviert, dazu255.255.255.255, die Limited-Broadcast-Adresse.
Für IPv6 gehören dazu unter anderem ::/128 (nicht spezifiziert), ::1/128 (Loopback), fc00::/7 (Unique Local Addresses), fe80::/10 (Link-Local), ff00::/8 (Multicast) und 2001:db8::/32 (Dokumentation). Auch IPv4-gemappte Adressen wie ::ffff:0:0/96 und das NAT64-Präfix 64:ff9b::/96 verdienen Beachtung, denn sie sind Übersetzungsmechanismen, die ebenfalls nicht als Client-Adressen auftauchen sollten. Manche ältere Artikel führen außerdem 192.88.99.0/24 (6to4-Relay-Anycast) auf, das inzwischen als veraltet gilt.
Warum ein Bogon in Ihren Logs wichtig ist
Erscheint ein Bogon als scheinbarer Client einer Anfrage, die über das öffentliche Internet kam, trifft einer von wenigen Fällen zu, und böse Absicht steckt nicht immer dahinter. Oft liegt die Ursache in der Infrastruktur: Ein Reverse-Proxy oder Load Balancer reicht die echte Client-Adresse nicht weiter, sodass Ihre Anwendung die private Adresse des Proxys sieht; ein X-Forwarded-For-Eintrag wurde an der falschen Position entnommen; oder ein NAT-Setup hat eine interne Adresse in ein öffentliches Feld durchsickern lassen. Das sind Konfigurationsfehler, die man beheben sollte, weil sie Rate Limiting, Geolokalisierung und Missbrauchsmeldungen beeinträchtigen.
Die andere Ursache ist Absicht. Quelladressen lassen sich in Paketen und Headern fälschen, und Angreifer nutzen Bogon-Quellen für gespoofte Floods oder um Filter auszutesten. Da legitimer Datenverkehr nicht aus diesen Bereichen stammen kann, filtern vorgelagerte Betreiber sie am Netzwerkrand (der Gedanke hinter dem Ingress Filtering in BCP 38), und Ihre eigene Firewall sollte Bogon-Quellen auf öffentlichen Schnittstellen verwerfen. Beachten Sie die Einschränkung: Innerhalb Ihres Netzwerks sind private Adressen normal, wenden Sie die Regel also nur an der öffentlichen Grenze an.
Reservierter versus nicht zugewiesener Adressraum
Die Unterscheidung ist wichtig, wenn Sie einen eigenen Filter bauen. Reservierte Bereiche sind durch Standards festgelegt und ändern sich selten, eine statische Tabelle bleibt daher über Jahre korrekt. Nicht zugewiesener Adressraum ist anders, denn Registries vergeben Blöcke im Lauf der Zeit, und eine Adresse, die letztes Jahr ein Bogon war, kann heute zu einem realen Netzwerk gehören. Filter, die nicht zugewiesene Blöcke fest codieren, haben in der Vergangenheit neue Kunden neu vergebener Bereiche ausgesperrt. Deshalb ist die Liste der reservierten Bereiche die sicherere Wahl für den Einsatz im Anwendungscode, und Fragen zum Besitzer öffentlicher Adressen gehören in Registry-Daten statt in eine Bogon-Liste.
Eine Adresse prüfen
Sie können jede Adresse im Bogon-IP-Checker testen. Er vergleicht sie mit den veröffentlichten reservierten IPv4- und IPv6-Bereichen und zeigt den passenden Block samt Referenztabelle an. In der API enthält die Antwort der IP-Abfrage die Felder bogon und bogon_type, sodass eine Log-Pipeline diese Adressen ohne eigene Bereichstabellen markieren kann. Die API-Dokumentation listet die vollständige Antwort auf.
Eine Einschränkung sollten Sie kennen. Der Checker nutzt eine standardbasierte Liste reservierter Bereiche, keine Live-Sicht auf das, was tatsächlich geroutet wird. Eine Adresse außerhalb der reservierten Bereiche ist nicht zwangsläufig zugewiesen oder erreichbar. Um herauszufinden, ob eine öffentliche Adresse tatsächlich einen Besitzer hat, nutzen Sie die IP-WHOIS-Abfrage für den Registry-Eintrag oder die ASN-Abfrage, um das Netzwerk zu sehen, das sie ankündigt.
Praktischer Umgang
- Normalisieren und validieren Sie Adressen früh; weisen Sie Bogons in Feldern ab, die eine öffentliche Client-IP erwarten.
- Verwerfen Sie Bogon-Quellen am öffentlichen Rand mit Firewall-Regeln, wenden Sie sie aber nicht auf internen Datenverkehr an.
- Taucht unerwartet ein Bogon auf, prüfen Sie zuerst die Konfiguration von Proxy und Load Balancer, denn Fehlkonfigurationen sind häufiger als Angriffe.
- Bedenken Sie, dass Bogon-Adressen keine Geolokalisierung haben. Überspringen Sie daher Geolokalisierungs- und Reputationsabfragen für sie und sparen Sie sich die Anfrage.