Freigegebene IPv4-Adressbereiche sind "verschmutzt"
Einige kürzlich freigegebenen IPv4-Adressbereiche sind offenbar für die Nutzung in Produktionsumgebungen ungeeignet. Während BGPmon zahlreiche nicht genehmigte Routing-Ankündigungen registriert, überlastete ein Test beim RIPE Lab ein für die Übertragung von Routing-Informationen zuständiges Verwaltungsnetz.
Mitte Januar 2010 hatte die für die Verteilung der IP-Adressbereiche zuständige IANA zahlreiche, teils seit Anfang der 1980er Jahre reservierte IPv4-Adressblöcke den regionalen Verteilern (Registries) zugeteilt. Seither darf beispielsweise das APNIC die Adressen aus dem Block 1.0.0.0/8 (1/8) als offizielle und im IPv4-Internet weiterleitbare Adressen an Kunden vergeben.
Allerdings nutzen einige Netzwerker diese Adressen unberechtigt für Beispiele, als Vorgabe oder sogar als pseudo-private Adressen. So kommunizieren Teilnehmer am dezentralen Peer-to-Peer-Netz anoNet über Adressen aus dem Bereich 1/8. Die Software umgeht damit zwar Konflikte mit den in LANs üblichen und erlaubten Adressen (10/8 , 172.16/12 sowie 192.168/16), kollidiert nun aber mit den IANA-Vorgaben.
Wie beliebt die Adressen aus dem Bereich 1/8 sind, zeigen die Daten der Monitoring-Website BGPmon, die über das Border Gateway Protocol (BGP) die Verfügbarkeit von Verbindungswegen zwischen den Netzen autonomer Systeme (AS) protokolliert und analysiert. In der Zeit seit Mai 2009 ermittelte BGPmon 364 Bekanntmachungen eines Subnetzes aus 1/8, die sich zu 23 einzelnen gruppieren lassen (orgin AS und Präfix). Wie sich in den Auswertungen zeigt, gehört das Netz 1.1.1/24 zu den beliebtesten Präfixen. Daher hoffen die BGPmon-Autoren, dass die APNIC diesen Präfix nicht vergibt – "außer vielleicht für ein nettes Honeynet -Projekt".
Ähnliche Erfahrungen machten auch die Autoren eines Blog-Beitrags bei RIPE Lab: Sie beschreiben wie sich nach der Ankündigung der Subnetze 1.255.0.0/16, 1.50.0.0/22, 1.2.3.0/24 und 1.1.1.0/24 über einen Remote Route Collector (RRC) der Datenverkehr auf einer Leitung mehr als vervierfachte. Eine 10-MBit-Leitung zum Internetknoten in Amsterdam AMS-IX wurde dabei recht schnell mit Anfragen zur Adresse 1.1.1.1 verstopft. Eine weitere sFlow-Analyse zeigte, dass es insgesamt sogar 50 MBit/s waren, die über das eigentlich nur für den Austausch von Routing-Informationen gedachte Netz laufen wollten.
Gut 75 Prozent dieses Netzwerkverkehrs waren UDP-Anfragen auf Port 15206, die als Ziel zu 90 Prozent die Adresse 1.1.1.1 hatten. Die meisten dieser Netzwerkpakete besaßen einen Signatur, die auf einen Trojaner namens KiLo hinweist. Weitere UDP-Pakete gingen an die Ports 2427 und 2727, die zum Media Gateway Protocol gehören, und offenbar von falsch eingerichteten VoIP-Geräten eines Telekommunikationsanbieter kamen. Unter TCP ging die Hälfte aller Pakete an Port 80 (HTTP). Ein kleiner Teil der HTTP-Anfragen gehört zu bestehenden Verbindungen, die laut Beitrag denen eines asiatischen Online-Spiels gleichen. Da dieses Datenaufkommen stabil blieb, zog das RIPE die Bekanntmachung für die Adressbereiche 1.1.1.0/24 und 1.2.3.0/24 am 2. Februar wieder zurück - das Datenaufkommen am AMS-IX fiel daraufhin wieder auf die üblichen 2 MBit/s.
Nach Ansicht der RIPE-Mitarbeiter sind die ermittelten Zahlen nur begrenzt aussagekräftig, da der beschriebenen Aufbau nur eine geringe Übertragungsrate zuließ. Verlässliche Zahlen könne nur ein Test in einem Hochgeschwindkeitsnetz liefern. Allerdings zeige der Versuch, wo die größten Problem liegen. Unter den beschriebenen Umständen seien diese Adressbereiche für die Nutzung in Produktionsumgebungen ungeeignet, schließen sie ihren Bericht.
Gänzlich neu sind solche Phänomene nach einer Änderung der reservierten und freigegebenen Adressbereiche hingegen nicht: So konnten die Kunden eines italienischen Providers einige Server im Internet nicht mehr erreichen, nachdem der IP-Block 41/8 freigegeben wurde. Der Anbieter nutzte den Adressbereich als private Adressen für seine Kunden und setzte sie per Network Address Translation (NAT) gegenüber dem restlichen Internet um. Nach der Freigabe des Blockes hielt der NAT-Router die Anfragen jedoch weiterhin für interne und schickte sie folglich auch nicht weiter. (rek)
