Yahoo (vermeintlich im) Iran.

Als ich gerade im Webbrowser die Website von Yahoo Finances besuchen wollte, musste ich staunen. Zeigte doch tatsächlich das Plugin „Flagfox“, das dem Firefox die nützliche Funktion des automatischen IP-Lookups beibringt, plötzlich eine recht seltene Flagge im IP-Adressraum an. Die Vermutung bestätigte sich – der Iran. Man achte in diesem Screenshot auf die Infobox unterhalb der Suchbox, die anzeigt, dass für den Hostnamen „de.finance.yahoo.com“ die IP-Adresse 188.125.65.211 aufgelöst wurde (was definitiv stimmt und mit nslookup nachprüfbar ist) und diese IP-Adresse offenkundig mit dem Ländercode für den Iran registriert ist:

Yahoo und Iran – das passt ungefähr so gut zusammen wie Audi und der Planet Mars, nämlich gar nicht. Allein dieser Anachronismus, dass mit dieser obigen Auskunft Yahoo irgendetwas im Iran hosten könnte, weckte meine netzwerkdetektivische Leidenschaft.

Erste Auskunftei in Sachen IP-Adressen sind die RIR, die Regional Internet Registries. Diese international tätigen Vergabestellen sind dafür zuständig, in ihrer jeweiligen Region die Zuteilung von IP-Adressen an Internet Service Provider sicherzustellen. Im Falle der Adresspräfix 188 ist hier das RIPE zuständig, also die RIR, die für Europa und Vorderasien zuständig ist.

In Sachen Auskunft ist es im Internet üblich, die Registrierungsinformationen des IP-Adressraumes öffentlich zu dokumentieren und über ein so genanntes WhoIs durchsuchbar zu halten. Internet Service Provider wiederum, die vom RIPE IP-Adressräume zugeteilt bekommen haben, sind vertraglich verpflichtet, diese Registrierungsinformationen für weiterdelegierte Adressräume zeitnah in die RIPE-Datenbank einzupflegen und aktuell zu halten.

Über das WhoIs des RIPE ist also problemlos eine Recherche für die obige IP-Adresse möglich, was folgendes Ergebnis lieferte:

inetnum:        188.125.64.0 - 188.125.71.255
netname:        IR-YAHOO
descr:          Yahoo! Europe
country:        IR
admin-c:        YEU-RIPE
tech-c:         YEU-RIPE
status:         ASSIGNED PA
mnt-by:         YAHOO-MNT
source:         RIPE #Filtered

role:           Yahoo Europe Operations Department
address:        Yahoo Europe Operations
address:        125 Shaftesbury Avenue
address:        London
address:        WC2H 8AD
remarks:        trouble:      uk-abuse@cc.yahoo-inc.com
admin-c:        NA1231-RIPE
tech-c:         SCY3-RIPE
tech-c:         NA1231-RIPE
tech-c:         IG1154-RIPE
tech-c:         DR2790-RIPE
tech-c:         CJO3-RIPE
nic-hdl:        YEU-RIPE
mnt-by:         YAHOO-MNT
source:         RIPE #Filtered
abuse-mailbox:  uk-abuse@cc.yahoo-inc.com

Der obere Block der Auskunft ist das so genannte „inetnum“-Objekt, das enthält die grundlegende Information darüber, in welchen IP-Adressblock die IP-Adresse gehört. Die IP-Adresse 188.125.65.211 gehört also in einen Adressblock, der von 188.125.64.0 bis 188.125.71.255 reicht. Spannend dabei ist der Ländercode, der im Feld „country“ angegeben ist, das ist tatsächlich der Code „IR“, der in der ISO-Ländertabelle für den Iran steht. Dass dieser Adressblock tatsächlich zu Yahoo gehört (genau genommen zu Yahoo Europe), wird über das Feld „admin-c“ angezeigt. Die Abkürzung „YEU-RIPE“ ist wiederum ein Verweis auf ein „role“-Objekt, das Informationen über den Besitzer erhält. Die Auskunft über „YEU-RIPE“ ist der untere Block der obigen Auskunft. Es handelt sich also hier mit maximaler Sicherheit tatsächlich um Yahoo Europe, auf jeden Fall aber über eine offizielle Yahoo-Einrichtung.

Zuerst dachte ich an einen Fehler in der Registrierung. Vielleicht ist dem zuständigen Systemadministrator, der die obigen Informationen in die RIPE-Datenbank eingetragen hat, ein Fehler bei der Eingabe des Ländercodes unterlaufen und das „IR“ steht fälschlicherweise dort. Tatsächlich kann nämlich der Verwalter eines IP-Adressblocks diese Länderinformation selbst eintragen.

Dass es dann doch kein Fehler sein kann, merkte ich schnell an der zweiten Zeile, dem „netname“-Feld. Hier gibt nämlich der Verwalter des IP-Blocks einen frei wählbaren Netznamen an, der rein zur internen Dokumentation dient. Dort findet sich explizit der Eintrag „IR-YAHOO“. Es ist sehr unwahrscheinlich, dass der Autor dieses Eintrages einen falschen Ländercode einträgt und diesen Fehler dann auch nochmal im Netznamen begeht.

Also, der Ländercode „IR“ ist für diesen Netzwerkblock offensichtlich gewollt und beabsichtigt. Warum das so ist, lässt sich erklären, wenn man näher auf die Eigenheiten dieser Ländercodierung eingeht. Denn tatsächlich ist dieser Ländercode, den zwingend jeder Empfänger von IP-Adressblöcken in der Netzwerkdokumentation setzen muss, nicht einfach nur informell, sondern elementar – mit dieser Ländercodierung arbeiten quasi alle Dienste, die eine Recherche von IP-Adressen nach Ländern ermöglichen, so zum Beispiel Statistikdienste wie Google Analytics oder Piwik oder aber auch Dienste, die IP-Adressen nach Ländern sperren müssen.

Und da sind wir dann beim Iran und hier bei einem vermutlich genau umgekehrten Fall. Damit Yahoo seine Dienste in den Iran durchbekommt und seine Netze nicht einfach so gesperrt bekommt, hat Yahoo vermutlich den obigen IP-Adressblock explizit für die Nutzung im Iran vorgesehen und das obige Netz entsprechend mit dem Ländercode „IR“ versehen. Hier will sich Yahoo also offensichtlich in irgendeiner Form fügen und es den iranischen Zensoren, die da mit ziemlicher Sicherheit eine mehr oder weniger umfangreiche Sperrliste pflegen, möglicht unbürokratisch einfach machen, Yahoo nicht zu übersehen und „versehentlich“ zu sperren.

Und dabei vergessen die Jungs von Yahoo Europe eine Sache: Was sie da machen, ist genau genommen nicht erlaubt. Der Ländercode für einen Netzblock ist nicht dazu da, anzugeben, wo vermutlich die Besucher sitzen, die auf Dienste zugreifen, die in diesem Netzblock laufen könnten, sondern er ist dazu da, kennzuzeichnen, wo dieser Netzblock tatsächlich eingesetzt wird, also der Server physikalisch steht. Wenn ich ein traceroute auf die IP-Adresse 188.125.65.211 mache, löst sich das folgendermaßen auf und da ist relativ wenig „Iran“ zu sehen:

tracert 188.125.65.211

Routenverfolgung zu proxy1.stage.finance.vip.ird.yahoo.net
[188.125.65.211] über maximal 30 Abschnitte:

  1. besimox [192.168.124.1]
  2. 217.0.118.47
  3. 87.186.241.42
  4. l-eb2-i.L.DE.NET.DTAG.DE [62.154.89.46]
  5. 217.243.216.202
  6. vlan60.csw1.Frankfurt1.Level3.net [4.69.154.62]
  7. ae-62-62.ebr2.Frankfurt1.Level3.net [4.69.140.17]
  8. ae-21-21.ebr2.London1.Level3.net [4.69.148.185]
  9. vlan104.ebr1.London1.Level3.net [4.69.143.97]
 10. ae-5-5.car1.Dublin1.Level3.net [4.69.136.89]
 11. YAHOO-INC.car1.Dublin.Level3.net [212.73.251.2]
 12. ae-1.msr2.ird.yahoo.com [66.196.67.233]
 13. te-8-4.bas-b1.ird.yahoo.com [87.248.101.107]
 14. proxy1.stage.finance.vip.ird.yahoo.net [188.125.65.211]

Ablaufverfolgung beendet.

Das ist also der Weg von meinem Rechner („besimox“) bis zum Zielserver, ingesamt also 14 Knoten im Internet. Interessant hierbei sind die Knoten ab dem 8. Knoten, die der Provider „Level3“ schön nach der Örtlichkeit, in die der Knoten steht, benannt hat. Der Weg geht also von Frankfurt, nach London und dort nach Dublin, also nach Irland. Was auch so stimmt, denn Yahoo hostet seine Dienste in Europa (unter anderem) in Irland. Und nicht Iran.

Die ITU als selbsternannter Retter des Internet.

Schon seit Anbeginn des Internet und auch seines Vorläufers ARPANet ist die Vergabe von IP-Adressen (bzw. im ARPANet die Netzwerkadressen) eine Geschichte, die die Netzcommunity selbst verwaltet. Anfänglich war dies die IANA, die Internet Assigned Numbers Authority. Wer als Institution entsprechende Adressressourcen benötigte, bekam diese von der IANA, nachdem einige wenige Formalitäten geklärt wurden.

In der Zwischenzeit ist die IP-Adressvergabe verteilt auf fünf so genannte Regional Internet Registries (RIR), die jeweils zuständig sind für einen bestimmten Bereich auf der Erde (siehe hierzu auch den Artikel zur IP-Adressierung in netplanet). Auch hier gilt, dass Provider nach Erfüllung einiger Voraussetzungen von der jeweils zuständigen Regional Internet Registry notwendige IP-Adressblöcke erhalten können und das nach fairen, nachvollziehbaren und kollegialen Maßstäben passiert.

In der Netzcommunity, den so genannten Netheads, wird man vermutlich niemanden finden, der dieses System nicht gut findet. Dafür aber bei den Telefonleuten, den Bellheads, denn da läutet schon der oberste Verein, die International Telecommunication Union (ITU), die Alarmglocke. Tatsächlich hat die ITU vor einigen Tagen bekräftigt, dass sie sich ebenfalls als Vergabestelle für IP-Adressen im zukünftigen IPv6-Protokoll etablieren möchte. “Bekräftigt” deshalb, weil die ITU an dem Thema schon seit über fünf Jahren arbeitet, zumindest gedanklich.

Konsequenz ist dabei eher nichts, was die ITU an den Tag legt, denn sie will nicht einfach die gesamte IP-Adressvergabe übernehmen, sondern sich als weitere RIR positionieren, zu den schon bestehenden fünf. Nanu, fragt sich da der geografisch Gebildete, welche Region will den ITU versorgen, wenn die schon bestehenden RIR schon alle Bereiche des Planeten versorgen?

Die ITU greift dummerweise da ein Argument auf, dass vielleicht 2005 noch funktionierte, nämlich die Sorge, dass unterentwickelte Regionen der Erde in der Zuteilung von IP-Adressen benachteiligt sein könnten. Vor fünf Jahren waren die Lieblingsbeispiele der ITU da Afrika und Südamerika. Nur – Afrika hat inzwischen das AfriNIC als eigene RIR und Südamerika das LACNIC.

Diese Argumentation der ITU ist so abstrus, dass es schon der eigenen Mitgliedschaft mulmig wird und das sind vor allem westliche Regierungsvertreter, die mit Forderungen nach einer reellen Prüfung der angeblichen Notwendigkeit eines ITU-Engagements als RIR eine deutliche Position gegen die RIR-Ambitionen der ITU beziehen.

Technische Grundlagen zu Online-Sperren, Teil 3: IP-Filtering.

Die „Königsklasse“ beim Filtern ist das Filtern auf IP-Ebene.

Wie funktioniert das Filtern auf IP-Ebene?

Das Internet-Protokoll ist im Schichtenmodell die Schicht, die direkt auf dem Übertragungsmedium aufliegt. Da das Internet-Protokoll die unterste Schicht in der Übertragung des Internets ist, sind alle darüberliegenden Protokolle darin eingekapselt. Wird also eine Website übertragen, dann geschieht dies über das HTTP-Protokoll, das wiederum im TCP-Protokoll eingekapselt ist und dies wiederum im Internet-Protokoll.

Die Adressierung im Internet-Protokoll erfolgt über IP-Adressen; jeder Rechner im Internet muss über eine solche IP-Adresse erfolgen und ist über diese Adresse eindeutig identifizierbar. Denkbar ist aber auch, die gesamte IP-Kommunikation an dieser Stelle inhaltlich zu analysieren und aufzuzeichnen, was bei nicht verschlüsselter Kommunikation das Nachvollziehen der übertragenen Inhalte ermöglicht. So erfolgt für gewöhnlich auch das Abhören von Internet-Anschlüssen.

Wie wäre der Filteransatz beim Filtern?

Der Filteransatz läuft beim IP-Filtering über das Analysieren bzw. Ausfiltern von IP-Kommunikation nach bestimmten Kriterien. Sinnvollerweise ist das die Absender- oder Empfängeradresse. Da dieses Filtering auf der untersten Ebene der Internet-Kommunikation erfolgt, ist das Filtern an dieser Stelle auch sehr fundamental „hart“, weil hier die Kommunikation an der Wurzel infiltiert wird und im Filterfall die gesamte Kommunikation gemäß den Filterregeln unterbunden werden kann.

Wo hapert es im Filteransatz des IP-Filterings?

Der „Kollateralschaden“ ist beim IP-Filtering dann sehr hoch, wenn es um Dienste geht, die auf einer IP-Adresse mehrere Dienste gleichzeitig betreiben. Genau das wird mit Webservern gemacht, denn das HTTP-Protokoll ermöglicht es, dass auf einer IP-Adresse zwar ein Webserver als Dienst laufen kann, der jedoch eine Vielzahl von virtuellen Webserver-Instanzen haben kann – je nach Provider durchaus tausende von Instanzen gleichzeitig. Würde man so eine IP-Adresse sperren, um eine bestimmte Webserver-Instanz zu bekämpfen, würde man auf einen Schlag auch alle anderen Instanzen blockieren.

Ähnlich sieht es bei vielen anderen Diensten aus und inzwischen auch mit vielen Unternehmensnetzwerken, die intern keine öffentlichen IP-Adressen verwenden, sondern private Bereiche, die dann per NAT über eine IP-Adresse an das Internet angebunden sind.

Fazit

Das Filtern auf IP-Ebene ist „hart“ und umfassend. Nicht ohne Grund ist diese Art von Filtern in den Diskussionen um die Online-Sperre verpönt, da dieses Filtern nach gängiger Rechtsauffassung auf jeden Fall das Fernmeldegeheimnis bricht, da Kommunikation unterbunden wird.

Da moderne Internet-Dienste den Betrieb mehrerer Instanzen auf einer IP-Adresse ermöglichen, ist das IP-Filtern für das Sperren einzelner Websites auch denkbar schlecht geeignet, da der Kollateralschaden durch Filtern von eventuell benachbarten Angeboten, die sich die IP-Adresse teilen, beträchtlich sein kann und die Rechte vieler Anbieter und Nutzer verletzen könnte.

Internet kaputt.

Gerade von einer meiner Gernekunden (nämlich genau bei dem im Artikel gemeinten Gernekunden) habe ich in den letzten Tagen vermehrte Anrufe bekommen, dass der Internet-Zugang bei ihnen Spacken machen würde. Jeden Morgen würde der Zugang erst einmal nicht funktionieren und man müsse erst einmal den DSL-Router neu starten, denn erst danach würde es funktionieren – bis zum nächsten Morgen.

Nun sagt der Admin-Bauch, dass das entweder ein kneifender T-DSL-Anschluss ist oder der DSL-Router kränkelt. Den T-DSL-Anschluss habe ich dann durch die Telekom prüfen und zurücksetzen lassen, was die Symptome nicht verschwinden ließ. Blieb also nur der DSL-Router, den ich dann heute eigentlich austauschen wollte. Mich störte nämlich grundsätzlich auch der Umstand, dass die Administrationsseite des DSL-Routers über die feste IP-Adresse, die der Internet-Zugang hat, nicht erreichbar ist.

Bis ich mal heute spaßeshalber auf die Idee bekommen bin, nicht HTTP auf Port 80 zu nutzen, sondern HTTPS auf Port 443. Und siehe da, es kam etwas zurück. Nur nicht die Administrationsseite des DSL-Routers, sondern die Administrationsseite eines NAS, eines Network Attached Storage. Das wäre schon kurios genug, wenn es nicht den Umstand gäbe, dass der Kunde gar keine NAS bei sich zu Hause stehen hat.

In der Tat ist es nämlich so, dass die vergebene IP-Adresse, die ich bei der Anmeldung des ADSL-Zuganges erhalten habe, gar nicht mit dem ADSL-Zugang verknüpft ist und der Zugang bei jeder neuen Einwahl – nämlich alle 24 Stunden – mangels zugeteilter IP-Adresse vom Einwahlrouter gar keine nach außen rout-fähige IP-Adresse erhält. Damit funktioniert nach erfolgter Neueinwahl zwar der Internet-Zugriff in Richtung Internet, von außen ist der Router und das Kundennetz jedoch nicht zu erreichen. Und die ursprünglich vergebene IP-Adresse gehört einem ganz anderen Kunden. Auf solch spannenden Probleme muss man erst einmal kommen.

Die Lösung wiederum ist dann unspektakulär einfach – man suche eine wirklich freie IP-Adresse aus dem für die DSL-Zugänge reservierten Adresspool heraus, editiere den Datensatz, der per RADIUS bei der PPPoE-Anfrage herausgegeben wird und schon gibt es bei der nächsten Einwahl, die durch einen simplen Neustart des DSL-Routers provoziert wird, eine gültige und auch rout-fähige IP-Adresse.

Bei so einem Problem hat der ursprüngliche Hilferuf, dass das Internet kaputt sei, ausnahmsweise eine richtige Berechtigung gehabt. Es war hier wirklich kaputt.