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.

• 

Grob gefasst ist so ein Mediastreaming eine Sache mit drei Komponenten:

1. Kamerabild vor Ort erzeugen und in das Notebook einspeisen.
2. Aus dem Kamerabild einen Masterstream erzeugen und zu einem Streamingserver übertragen.
3. Streamingserver, der den Masterstream empfängt und an Zuschauer weiter verteilt.

Punkt 1 ist eine rein lokale Geschichte, hierzu braucht es eine Kamera und einen Kameramann. Wobei, “Kameramann” ist an der Stelle schon wieder passé, wir reden hier eher von einem Multimann, wie es in der Fernsehsprache üblich ist. Das sind Leute, die neben dem Drehen auch schon die nächsten Schritte umsetzen. Der Multimann steuert also die Kamera, in diesem Fall mein HDV-Camcorder, der per Firewire an mein Notebook angeschlossen ist und ein digitales Bildsignal anliefert. Die Bild- und Tonqualität ist echte Broadcast-Qualität, das ankommende Signal kommt in Full-HD daher. Das nur rein der Form halber angemerkt, für eine echte Full-HD-Übertragung fehlt später die Bandbreite.

Bei Punkt 2 kommt ein Dienst namens Ustream.tv ins Spiel, das ist eine Streaming-Plattform, die es im einfachen Fall unter Tolerierung von Werbebannern kostenlos gibt, ohne Einblendung von Werbebannern ab 99 US-Dollar im Monat kostet. Auf den ersten Blick viel, allerdings darf man beim Mediastreaming nicht außer acht lassen, was das bei einem richtigen Streaming für Ressourcen kostet und das will sich so ein Dienst irgendwo auch bezahlen lassen dürfen.

Ustream kann man direkt per Webbrowser bedienen und per Flash auch auf Video- und Audioquellen zugreifen lassen, das funktioniert aber nur leidlich gut. Sinnvoller ist es, den kostenlosen “Ustream Producer” herunterzuladen (für Mac und Windows) und zu installieren. Dieser Client greift deutlich stabiler auf die lokalen Videoquellen zu. Es gibt auch eine Pro-Version des Clients, der mehrere Kamerabilder gleichzeitig zur Abmischung bereitstellt, also eine Art “Bildmischung light” ermöglicht, die kostenlose Variante ist aber für ein einziges Kamerabild völlig ausreichend. Also einen Login-Zugang auf der Website von Ustream einrichten, damit den Client auf dem Notebook bestücken, die Kamera an das Notebook hängen und schon sollte im Client das Kamerasignal erscheinen.

Nächste Baustelle: Internet. Der Test zu Hause am heimischen DSL ist soweit in Ordnung, der Stream kommt bei Ustream an und wird mit etwa 10 bis 20 Sekunden Verzögerung wieder ausgestrahlt. Das ist für einen Mediastream, der ja nur One-Way sein soll, soweit in Ordnung. Die Frage war nur, ob der Upload auch mit UMTS funktioniert und ob das dann auch mit dem chronisch überlasteten UMTS-Netz von O2 hier in Pforzheim tut. Glücklicherweise besitzt mein Notebook eine UMTS-Karte und darin ein SIM-Modul von O2, so dass der Test schnell bewerkstelligt war.

Und auch dieser Test tut einwandfrei. Zwar geht die Latenzzeit nochmal ein paar Sekunden weiter nach oben, aber das, was zum Test am heimischen PC von Ustream wieder zurückkommt, ist ruckelfrei und von brauchbarer Qualität. Hätte man vor Ort eine brauchbare UMTS-Versorgung, würde dem Upload nichts entgegenstehen. Testlabor erfolgreich beendet, morgen gibt es dann einen Testdurchlauf vor Ort.

Das heißt: Hätte es gegeben, wenn nicht nach drei Stunden Testlabor leider eine Absage gekommen wäre. Schade, denn das hätte funktioniert. Aber immerhin haben die drei Stunden Testlabor für eine Druckbetankung in Sachen Knowledge gesorgt und ich werde mir mal in den nächsten Tagen einen weiteren Test antun und testweise aus der Prärie funken.

• 

So weit, so gut. Was mit größeren Gerätschaften funktioniert, funktionierte jedoch nicht mit der Fritzbox. Zwar konnte ich über den VPN-Tunnel mein Netzwerk erreichen, jedoch keinen Datenverkehr ins Internet routen. Das blockte die Fritzbox ab und das ließ sich auch mit einigem Gefrickel in der Konfiguration nicht ändern.

Um es kurz zu machen: Nun geht es! Mit dem Firmware-Update vom September 2010 wurde die VPN-Funktionalität offenbar entsprechend angepasst, so dass nach einer kleinen Änderung der VPN-Konfigurationsdatei, die für den Import in die Fritzbox bestimmt ist, die Fritzbox als Secure Gateway für VPN-Verbindungen von einem iPhone (und natürlich auch einem iPad) genutzt werden kann. Hier mal alles Notwendige Schritt für Schritt.

Schon eine VPN-Konfiguration auf der Fritzbox?

Dann bitte Vorsicht walten lassen, denn wenn jetzt die neu erstellte VPN-Konfigurationsdatei hochgeladen wird, werden alle bestehenden VPN-Konfigurationen entfernt. Wenn also eine bestehende VPN-Konfiguration vorhanden ist und die auch noch benötigt wird, dann müssen beide VPN-Konfigurationen in einer Datei zusammengeführt werden. Hier sollte bitte das oben genannte Programm “FRITZ!Fernzugang einrichten” zum grundlegenden Aufbau der VPN-Konfiguration eingesetzt werden, damit die Verschachtelung der einzelnen Konfigurationen korrekt bleibt. Die notwendigen Änderungen für die VPN-Verbindung des iPhone lässt sich dann immer noch nachträglich hinzufügen.

VPN-Konfiguration auf der Fritzbox

Die Fritzbox hat nach wie vor auf ihrer Benutzeroberfläche keine eigene Einstellungsmöglichkeiten für VPN-Verbindungen, diese müssen also weiterhin als VPN-Konfigurationsdatei importiert werden. Solche VPN-Konfigurationsdateien können mit einem kostenlosen Programm namens “FRITZ!Fernzugang einrichten” (gibt es bei AVM im Download-Bereich) erstellt werden. Da wir jedoch für die VPN-Geschichte vom iPhone die so erstellte VPN-Konfigurationsdatei sowieso nochmal anpassen müssen, hier eine VPN-Konfigurationsdatei in ganzer Länge zum Herauskopieren und Anpassen. Ist zwar nicht schön formatiert, erfüllt aber seinen Zweck. Einfach den folgenden eingerückten Teil in einen Texteditor kopieren. Infos zu den rot markierten Bereichen gibt es weiter unten:

vpncfg {
connections {
enabled = yes;
conn_type = conntype_user;
name = "Accountname";
always_renew = no;
reject_not_encrypted = no;
dont_filter_netbios = yes;
localip = 0.0.0.0;
local_virtualip = 0.0.0.0;
remoteip = 0.0.0.0;
remote_virtualip = 192.168.178.202;
remoteid {
key_id = "Accountname";
}
mode = phase1_mode_aggressive;
phase1ss = "all/all/all";
keytype = connkeytype_pre_shared;
key = "sharedsecret";
cert_do_server_auth = no;
use_nat_t = yes;
use_xauth = yes;
use_cfgmode = no;
xauth {
valid = yes;
username = "Accountname";
passwd = "Kennwort";
}
phase2localid {
ipnet {
ipaddr = 0.0.0.0;
mask = 0.0.0.0;
}
}
phase2remoteid {
ipaddr = 192.168.178.202;
}
phase2ss = "esp-all-all/ah-none/comp-all/no-pfs";
accesslist =
"permit ip any 192.168.178.202 255.255.255.255";
}
}

Zu den rot markierten Bereichen:

• “name” und “key_id”
  Ein beliebiger Accountname, der in beiden Feldern gleich lauten muss. Keine komplizierten Sonderzeichen oder Leerschritte.
• “remote_virtualip” und “ipaddr”
  Das ist die virtuelle IP-Adresse, unter der das iPhone (bzw. der VPN-Client) später im lokalen Netzwerk der Fritzbox erscheinen wird. Wenn das LAN mit den Netzwerk-Standardeinstellungen betrieben wird, nutzt die Fritzbox das Netzwerk 192.168.178.x und für VPN-Clients IP-Adressen ab 201. (In diesem Fall habe ich jetzt die 192.168.178.202 ausgewählt, weil ich noch eine weitere VPN-Konfiguration nutze, die hier nicht aufgeführt ist.)
• “key”
  Hier ist der Shared Secret für die IPSec-Verschlüsselung einzutragen. Prinzipiell gehen hier auch Sonderzeichen, es genügt jedoch eine Zeichenfolge mit Groß- und Kleinbuchstaben, sowie Ziffern. Da dieses Shared Secret später auf dem VPN-Client auch nur einmal eingegeben werden muss, darf es gern länger sein, bei mir sind es 16 Stellen.
• “username” und “passwd”
  Das sind Benutzername und Passwort für die zusätzliche XAUTH-Authentifizierung. Hier empfehle ich für “username” den oben schon festgelegten Accountnamen, für “passwd” ist ein Passwort empfehlenswert, das nicht das Shared Secret ist und immerhin so aufgebaut sein sollte, dass man es sich einfach merken kann, da dieses Passwort bei jedem VPN-Verbindungsaufbau – zumindest auf dem iPhone – eingegeben werden muss.
• “accesslist”
  Die Zeile mit dem rot markierten Eintrag ist eminent wichtig dafür, wie der ausgehende Datenverkehr des VPN-Clients auf der Fritzbox behandelt werden soll. Hier ist wichtig, dass die rot markierte IP-Adresse genau die gleiche Adresse ist, wie weiter oben bei “remote_virtualip” und “ipaddr” angegeben.

Alles angepasst? Dann die Datei mit beliebigem Dateinamen und der Dateiendung “.cfg” abspeichern und diese Datei in die Fritzbox importieren. Das passiert in der Rubrik “Internet” unter “Freigaben” und dort in der Registerkarte “VPN”. Der Importvorgang dauert einige Sekunden und quittiert dann entweder mit einem erfolgreichen oder erfolglosen Import. Ist er erfolglos, stimmt mit ziemlicher Sicherheit etwas am Aufbau der VPN-Konfiguration nicht.

VPN-Konfiguration auf dem iPhone

Die VPN-Konfiguration auf dem iPhone ist weit weniger kompliziert, als es klingt. Zu finden ist sie in den Einstellungen unter “Allgemein”, dort unter “Netzwerk” und dort wiederum unter “VPN”. Hier auf “VPN hinzufügen” tippen und den Button “IPSec” wählen. Es erscheint folgendes Fenster:

Auch hier kurz die einzelnen Punkt ausführlich:

• Beschreibung
  Die Beschreibung kann frei gewählt werden und dient lediglich zur Kennzeichnung der VPN-Verbindung auf dem iPhone.
• Server
  Hier kommt die Adresse hinein, unter der die Fritzbox im Internet zu erreichen ist. Wer eine feste IP-Adresse hat, kann entweder die IP-Adresse oder den Hostnamen angeben. Wer keine feste IP-Adresse hat, kann sich mit einem DynDNS-Dienst behelfen.( Ich setze dyndns.org ein, die dazugehörigen Daten können bequem in der Fritzbox hinterlegt werden, so dass die Fritzbox selbstständig dafür sorgt, bei einem DSL-Verbindungsneuaufbau auch den DynDNS-Eintrag zu aktualisieren.)
• Account
  Hier kommt der Accountname ein, der oben in der VPN-Konfiguration festgelegt wurde.
• Kennwort
  Und hier eben das oben festgelegte Kennwort (nicht das Shared Secret!) hinein, wenn nicht bei jedem Verbindungsaufbau neu nach dem Kennwort für die Verbindung gefragt werden soll. Ich empfehle, das Kennwort hier nicht zu hinterlegen, so wie ich es immer bei mobilen Geräten handhaben würde, die VPN-Verbindungen in Netzwerke aufbauen können sollen, die nicht von einem eigenen Administrator, der im Ernstfall schnell die VPN-Konfigurationen deaktivieren kann, gehostet werden.
• Zertifikat verwenden
  Ausgeschaltet lassen, wir verwenden kein Zertifikat.
• Gruppenname
  Hier auch einfach den Accountnamen eintippen.
• Shared Secret
  Und hier kommt das Shared Secret hinein.
• Proxy
  Auf “Aus” gestellt lassen, wir verwenden keinen Proxy.

Das war es. Einstellungen sichern und gut.

VPN aufbauen

Das VPN lässt sich in den iPhone-Einstellungen mit dem nun neu eingeblendeten VPN-Schieber starten. Einfach den Schieber aktivieren und schon wird versucht, den Tunnel zu öffnen. Wird der Tunnel zur Fritzbox etabliert, erscheint nach einigen Sekunden die Passwortabfrage. Glückt diese, erscheint in der Infozeile des iPhone ein winziges VPN-Symbol, gleichzeitig ist auf der Benutzeroberfläche die nun aktive VPN-Verbindung zu sehen.

Wer ein Jailbreak-iPhone besitzt und das höchst empfehlenswerte Programmpaket SBSettings installiert hat, um damit einige grundlegende Funktionen des iPhone schnell zu aktivieren, kann in Cydia noch das zusätzliche Paket “SBSettings VPN Toggle” installieren, das dann einen zusätzlichen Button für das Aktivieren/Deaktivieren der VPN-Verbindung zu SBSettings hinzufügt. Komfortabler geht es dann kaum noch.

Die üblichen Hinweise, Fragen und Antworten

• iPad?
  Gute Nachricht: Funktioniert im Prinzip genau so, wie auf dem iPhone und ist auch genau so zu konfigurieren.
• VPN-Passwörter auf mobilen Geräten
  Wie oben kurz angerissen: VPN-Passwörter gehören nicht auf mobile Geräte, auch wenn diese Sperrfunktionen haben. Mit dem Shared Secret geht es nicht anders, das Passwort für die zusätzliche XAUTH-Authentifizierung muss man jedoch wirklich nicht auf dem iPhone hinterlegen, sondern gibt das bei jedem Verbindungsaufbau ein. Grundsicherungsmaßnahme.
• Absicherung der Fritzbox
  Ein paar Dinge müssen auch einfach hier klar sein. Die Fritzbox braucht ein vernünftiges Passwort, ein eingerichtetes WLAN-Netzwerk sollte verschlüsselt mit WPA2 und einem hinreichend langen Key arbeiten und wenn man die Fritzbox-Bedienoberfläche für Fernzugriffe aus dem Internet aktiviert, dann bitteschön SSL gesichert und mit gesondertem HTTP-Zugriffspasswort. Ein sicheres VPN lebt davon, dass sowohl Client, als auch Server gesichert sind.
• Ist der Tunnel sicher?
  IPSec ist grundsätzlich state-of-the-art und eine aktuelle und weit verbreitete VPN-Tunneltechnologie. Welche Algorithmen tatsächlich eingesetzt werden, habe ich aktuell nicht parat, es dürfte sich jedoch um grundsätzlich starke Verschlüsselung handeln, die noch mit einer zusätzlichen Benutzerauthentifizierung (“XAUTH”) ergänzt wird. In Sachen Tunnel gilt: Aufgebaut wird der immer nur zwischen Client und Server, also in diesem Fall zwischen iPhone und Fritzbox. Wenn also nicht gerade jemand eine Man-in-the-middle-Attacke fährt und beispielsweise den Endpunkt so manipuliert, dass dieser nicht auf der heimischen Fritzbox endet, sondern auf einem anderen Gerät, ist man also weitgehend sicher davor, dass der Tunnel von Dritten abgehört werden kann – wenn eben die Schlüssel hinreichend komplex sind.
• Kann man dem VPN-Client auf dem iPhone trauen?
  Das ist eine gute Frage. Pardon, kann ich nicht beantworten. Zum einen, weil ich kein Verschlüsselungsspezialist bin und zum anderen, weil die iOS-Software des iPhone/iPad nicht öffentlich zur Evaluation zur Verfügung steht. Dass “Cisco” draufsteht, ist zumindest ein Zeichen dafür, dass es sich nicht um ganz namenlose Software handelt und da viele Unternehmen auf Cisco-Router und -Software schwören, kann man sich zumindest ein Stück weit darauf verlassen, dass es nicht ganz so üble Software sein dürfte. Für Paranoiker gilt jedoch auch hier, dass sowohl Apple, als auch Cisco eben US-amerikanische Unternehmen sind.
• Performance und Stromverbrauch
  Die Performance der Fritzbox ist für VPN-Verbindungen ausreichend, selbst mehrere VPN-Verbindungen bedient meine Fritzbox 7270 problemlos. Da sie eine ADSL-Fritzbox ist, ist die Limitierung des ADSL-Anschlusses vermutlich schneller erreicht, als die VPN-Verschlüsselungsperformance. Auf dem iPhone gilt das grundsätzlich auch, nur ist hier zu beachten, dass alles, was zusätzliche Performance braucht, Energie verbraucht und die muss man sich auf einem iPhone immer gut einteilen. Es macht also Sinn, das VPN immer dann einzusetzen, wenn man es auch zwingend braucht und das ist immer dann der Fall, wenn ein drahtloses Netzwerk unverschlüsselt sendet und die zu übertragene Kommunikation das ebenfalls ist. Nutzt man über das iPhone beispielsweise SSL-gesichertes Banking oder Mailkonten auf Basis von ActiveSync oder verschlüsseltem IMAP, dann sind diese Kommunikationskanäle bereits verschlüsselt. Ebenso unproblematisch ist so Kommunikation wie beispielsweise der eingebauten Wetter-App, die niemand wirklich verschlüsselt braucht. Sinnvoll ist VPN-Verschlüsselung spätestens dann, wenn Apps über API auf Dienste zugreifen und hier befürchtet werden muss, dass dies nicht über HTTPS gesichert läuft. Kaum eine Social-Networking-App tut das nämlich oder bietet hierzu Optionen an. Spätestens hier ist der VPN-Tunnel gefragt und die investierte Energie eine gute Anlage.

• 

Die wichtigsten Neuerungen ergeben schon eine richtig lange Liste:

• Neue, schnellere Bedienoberfläche, die nun endlich auch gut mit Mobilbrowsern funktioniert
• IPv6-Unterstützung, die bisher nur in Labor-Firmwares geboten wurde
• Starke Verbesserungen in der NAS-Funktion, u.a. Verbesserungen bei der Zahl von zulässigen USB-Geräten und Verbesserungen an der UPnP-Unterstützung. Zudem endlich auch Fernzugriff per FTP Secure
• Unterstützung von DNSsec
• Deutliche Verbesserungen in der DECT-Unterstützung, vor allem im DECT Eco-Mode
• Möglichkeit zur Einrichtung eines temporär aktivierbaren WLAN-Gastzugangs mit eigener SSID und Key
• Die Nachtschaltung für das WLAN kann erheblich genauer eingestellt werden
• Kindersicherung kann deutlich feiner mit Zeitplänen konfiguriert werden
• Deutlich verbesserte Benutzerführung im Zusammenhang mit AVM-DECT-Mobilteilen

Alles in allem ein sehr umfangreiches Update, das die Fritzbox 7270 mit vielen neuen Funktionen ausstattet, weshalb das Update eine absolut gute Empfehlung ist. Deshalb einfach in der Fritzbox das Update starten und drauf damit.

Und tatsächlich hat AVM auch ein paar kleine Goodies versteckt, unter anderem nämlich endlich die Möglichkeit, die Fritzbox als Secure Gateway für VPN-Verbindungen zu nutzen. Damit wird es nun endlich möglich, per Mobiltelefon einen IPSec-VPN-Tunnel zur Fritzbox aufzubauen und über diesen Tunnel den vollständigen Datenverkehr des Mobiltelefones über die Fritzbox ins Internet zu führen. Damit ist nun auch die Nutzung von offenen WLAN-Netzwerken kein Sicherheitsproblem mehr. Eine ausführliche Anleitung hierzu folgt demnächst.

• 

Die Vorabversion zeigt aber nun sehr anschaulich, was in das nächste offizielle Update kommen wird:

• Erweiterungen in Sachen USB und NAS
  Unter einer einheitlichen Adresse wird die Fritzbox einen angeschlossenen USB-Speicher als Network Attached Storage bereithalten, der, und das ist der Clou, auch per geschütztem FTP-Zugang nach außen hin geöffnet werden kann. Mit einer angeschlossenen USB-Festplatte ist ein Mediaserver oder schlicht ein Netzwerkspeicher nun also überhaupt kein Problem mehr. Ein integrierter Browser sorgt auf der Fritzbox-Oberfläche auch noch für ein bequemes Hochladen.
• Funktionserweiterungen der DECT-Telefonie
  An der DECT-Basis-Funktionalität wurde ebenfalls geschraubt, die AVM-DECT-Mobilteile MT-D und MT-F bekommen ebenfalls Firmware-Updates und danken das mit einer erheblich verbesserten Klangqualität und das auch im Eco-Mode und bei Grenzreichweiten. Zwar kommen die Mobilteile bei grenzwertigen Reichweiten immer noch nicht an der überlegenen Gesprächsqualität von Gigaset-Gerätschaften heran, aber die “Knack-Rate” ist schon deutlich gesunken. So Leute wie ich, die während dem Telefonieren gern durchs Haus laufen, wissen das zu schätzen.
• Endlich eine offizielle IPv6-Unterstützung
  Die nun offizielle IPv6-Unterstützung, das Internet-Protokoll der Zukunft, ist nun endlich da und auch schon einige Jahre überfällig, denn eine Beta-Firmware gab es schon einige Jahre, es gab aber von Seiten von AVM bisher leider nie ein Commitment dafür, wann denn eine offizielle IPv6-Unterstützung zu erwarten ist. Das passiert nun wohl endlich. Die IPv6-Optionen sind, je nach vorhandenem Zugang, entweder nativ oder mit einem IPv6-Tunnelprovider. Erschöpfende Dokumentation dazu wird es, so wie ich AVM kenne, demnächst im Supportbereich der Fritzbox 7270 geben.

• 

Das funktioniert zuverlässig auch dann, wenn der PC im Ruhezustand (Hibernation) ist, nicht aber, wenn er im Energiesparmodus schlummert. Und das hat auch einen einfachen Grund: Im Energiesparmodus ist der PC nicht wirklich ausgeschaltet und damit ist auch das BIOS nicht mehr im Spiel. “Wake on LAN” funktioniert also nicht, weil nicht das BIOS auf der Netzwerkschnittstelle hört, sondern das Betriebssystem. Schickt man also einen Rechner ferngesteuert nach dem Einsatz nicht in den finalen Schlaf oder in den Ruhezustand, sondern in den Energiesparmodus, dann bringt man ihn unter Umständen in eine Sackgasse, aus dem er nur direkt an der Konsole wieder erweckt werden kann.

Um den PC auch im Energiesparmodus ferngesteuert wieder hochfahren zu können, ist also eine Einstellung im Betriebssystem gefragt. Und die bringt, wie alle anderen Betriebssysteme auch, die Energieeinstellungen der Netzwerkkarte mit – wenn die Netzwerkkarte das unterstützt, was aber alle moderneren Karten und direkt auf Mainboards verbauten Module tun. Unter Windows also ab in den Gerätemanager (Rechte Maustaste auf “Computer”, dort auf “Eigenschaften”, dann links auf “Geräte-Manager”).

Im Geräte-Manager gibt es dann unter “Netzwerkadapter” alle im System verfügbaren Netzwerkkarten, bei den meisten Rechnern wird das eine einzige sein. Ein Doppelklick darauf und schon erscheinen die Eigenschaften ebendieser. Auf der Registerkarte “Energieverwaltung” gibt es dann die gewünschten Optionen:

Die erste Option ist für uns uninteressant und kann angehakt bleiben, denn wenn jemand ferngesteuert auf dem PC ist, ist tatsächlich auch die Netzwerkkarte in Betrieb und der PC wird diese nicht ausschalten. Die zweite Option ist standardmäßig nicht aktiviert, die wollen wir aber nun aktivieren, denn das ist genau die gesuchte Funktion. Mit dieser Einstellung wird PC dann tatsächlich aus dem Energiesparmodus wieder starten, wenn auf der Netzwerkschnittstelle Pakete empfangen werden.

Damit das nicht bei jedem empfangenen Paket passiert, sollte unbedingt auch noch die dritte Funktion aktiviert werden, damit nur “Verwaltungsstationen” den PC starten können. Die Fritzbox beherrscht das.

Alles im OK bestätigen und fertig.

• 

Was der Surfstick dann aber dort macht? Er gaukelt dem Gerät vor, dass er ein USB-Speicherstick sei und leitet die Zugriffe dann über die Fritzbox an einen konfigurierbaren Ort auf einem Rechner weiter, dort dann beispielsweise in ein Verzeichnis mit Bildern. Die Idee dahinter ist, auf diese Weise Gerätschaften netzwerkfähig zu machen, die gar keinen Netzwerkanschluss mitbringen.

Beispielhafter Anwendungszweck: Man hat einen digitalen Bilderrahmen, der einen USB-Anschluss besitzt. An den wird der Surfstick angeschlossen, der so konfiguriert ist, dass er die Dateizugriffe des Bilderrahmens an die Fritzbox weiterleitet und die dann wiederum an einen Rechner, auf dem ein Verzeichnis entsprechend freigegeben ist und die anzuzeigenden Bilder enthält.

Aus dem White Paper wird leider nicht klar, ob alle AVM Surfsticks funktionieren. Denn wenn das so wäre, wäre man (wenn man schon eine Fritzbox 7270 besitzt) mit rund 40 Euro für den günstigsten Surfstick dabei.

• 

Desweiteren gibt es in den Labor-Firmwares auch die Möglichkeit zur Anlage von mehreren Telefonbüchern, die dann auch auf den Mobilteilen gesondert ausgewählt werden können.

Wie immer gilt bei Hinweisen auf Beta-Versionen von Soft- und Firmware: Nicht auf Produktivsystemen einsetzen, wenn man nicht das Basteln gewohnt ist und nicht riskieren möchte, evt. auch wieder eine frühere Firmware-Version einzuspielen. Und vor dem Einspielen einer Labor-Firmware auf jeden Fall erst einmal die Fritzbox auf die aktuelle, freigegebene Firmware-Version aktualisieren, die Konfiguration abspeichern und dann erst die Labor-Firmware einspielen. Wenn nämlich alles schiefgeht, kann man wieder die letzte, freigegebene Firmware-Version einspielen und hat dann auch gleich die Konfiguration parat. Ja, ich sage das hier aus eigener Erfahrung.

Wer sicher gehen möchte, wartet auf die finale Version 54.04.74, die dürfte in den nächsten Tagen veröffentlicht werden.

• 

“Die ganzen extremistischen Terroristen-Nazi-Bombenleger betreiben ja im Moment aus Protest gegen die Internetzensur öffentliche Nameserver, mit denen man DNS-Zensur umgehen kann. Wisst ihr, wer noch?

$ host -t ns bundestag.de
bundestag.de name server s615.babiel.com
[...]
$ host s615.babiel.com
s615.babiel.com has address 217.79.215.156
$ host blog.fefe.de 217.79.215.156
blog.fefe.de has address 80.244.246.150

Der Bundestag! (Danke, Lutz)“

Was will uns Fefe sagen? Nämlich das, dass der Deutsche Bundestag DNS-Nameserver verwendet und diese offenbar auch für externe Benutzer Adressen auflösen kann. Was er allerdings nicht schreibt, ist der Umstand, dass es sein könnte, aber nicht wirklich getestet werden kann. Fangen wir mal an mit den Tatsachen:

Was hat er da überhaupt oben analysiert? Also, der Befehl “host” ist etwas ähnliches wie “nslookup”, nämlich ein Werkzeug zum Auflösen von DNS-Namen. In der ersten Zeile wird abgefragt, welcher Nameserver für die Domain “bundestag.de” autoritativ zuständig ist. Die zweite Zeile beantwortet dies mit dem Nameserver “s615.babiel.com”. In der vierten Zeile fragt er mit “host s615.babiel.com” die IP-Adresse des Nameservers ab und bekommt dies in der fünften Zeile geliefert (“217.79.215.156″). In der sechsten Zeile fragt er mit “host blog.fefe.de 217.79.215.156″ den so ermittelten Nameserver, ob er blog.fefe.de kennt.

1. Nameserver, die Domains hosten, müssen nicht unbedingt auch die gleichen Nameserver sein, die für die Nutzung von DNS-Auflösungen bei Kundenzugängen genutzt werden. Bei Hosting-Providern ist dies sogar eher unüblich. Spielt aber bei unserer Betrachtung nur eine sekundäre Rolle.
2. Die wenigsten Nameserver sind für bestimmte Adresskreise beschränkt und können aus dem ganzen Internet heraus für DNS-Auflösungen genutzt werden. Das hat weitgehend historische und technische Gründe, denn das Domain Name System ist durch seinen streng hierarchischen Aufbau vergleichsweise starr und wenig reglementierbar, weshalb es auch relativ wenig Mißbrauchspotential für Nameserver gibt – zumal eben letztendlich auch jeder Nutzer einen eigenen DNS-Nameserver einrichten und nutzen könnte, wenn er wollte und der Trend zukünftig auch in diese Richtung gehen dürfte. Dass der obige Nameserver deshalb auch aus dem Internet heraus für andere Domainnamen zur DNS-Auflösung genutzt werden kann, ist eher nichts besonderes, sondern (derzeit) weitgehend Normalität im Internet.
3. Gehört das Blog von Fefe mit ziemlicher Sicherheit zu keiner Website, die derzeit in irgendeiner Datenbank mit zu sperrenden Websites etwas zu suchen hätte. “Derzeit” deshalb, weil man ja inzwischen kaum noch davor gefeit ist, dass man morgen in einem Dorf aufwacht, durch das der nächste Minister auf der Suche nach seinem Profil die nächste Sau treibt.

• 

Internet
Fahrlässiger Umgang mit Passwörtern

Selbst große Konzerne schützen ihre Websites mit allzu simplen Passwörtern, die sich sogar von Amateuren in Minuten knacken lassen. Dem SPIEGEL liegt eine vertrauliche Liste mit Hunderten von Firmen-Passwörtern vor, die Sebastian Schreiber von der Sicherheitsfirma Syss mit ‘sehr wenig Aufwand’ aus einer Internet-Datenbank des Adressverzeichnisses namens Ripe gefischt hat. Unter den Firmen befinden sich ein Nahrungsmittelriese, eine Bank eine Wirtschaftsberatungsagentur, ein großer Webdienst-Anbieter. Sie alle hätten eine Menge zu verlieren durch einen Hackerangriff. ‘Es wäre ein Leichtes, den Webtraffic dieser firmen illegal abzuwürgen, umzuleiten oder E-Mails heimlich mitzulesen’, sagt Schreiber. Sichere Passwörter sollten aus über einem Dutzend Buchstaben, Zahlen und Sonderzeichen bestehen. Stattdessen wimmelt es in der Ripe-Datenbank von Passwörtern wie ‘adventure’, ‘TestTest’, ‘4664’. Eine große Versicherung vertraut auf ‘beruhigt’, ein Institut für Ernährungssicherheit auf ‘Karotte’, ein Flughafen auf ‘purgatory’ – englisch für Fegefeuer. Doch viele Ertappte reagierten nicht einmal, als sie auf die Nachlässigkeit hingewiesen wurden; und auch die Verwaltung der Ripe-Datenbank hat es trotz mehrerer Nachfragen monatelang versäumt, von den Nutzern bessere Passwörter einzufordern.

Was ist hier los? Sicherheitsloch? Zumindest teilweise, aber fangen wir von vorn an:

Das RIPE ist eine so genannte Regional Internet Registry, die für die Zuteilung und Verwaltung von IP-Netzparametern für die europäische Region zuständig ist. Dazu gehören IP-Adressen, aber auch Routing-Parametern. Traditionell ist es so, dass diese Informationen frei zugänglich sind, das Editieren der dort verzeichneten Einträge jedoch gesichert sind. Dazu gibt es zwei Möglichkeiten: Eine Sicherung mit einem Passwort und einem PGP-Key. Letzteres ist ein absolut sicheres Verfahren, während ersteres deutlich praktischer ist.

Damit der Spaß mit dem Herauslesen von Passwörtern nicht ganz so einfach ist, müssen zu hinterlegende Passwörter einmalverschlüsselt werden. Das bedeutet, dass der Originator des Eintrages sein Passwort nicht in Klartext hinterlegt, sondern zunächst mit einem Einwegverschlüsselungsverfahren bearbeitet – im Falle der RIPE-Datenbank wird das Verfahren MD5 eingesetzt – und dieses Ergebnis dann hinterlegt. Die Einwegverschlüsselung stellt sicher, dass die verschlüsselte Nachricht nicht mehr dechiffriert werden kann.

Der Ansatz ist nun, dass man das Passwort zwar nicht mehr dechiffrieren kann, es aber weiterhin durch einen anderen Ansatz zum Passwortknacken verwundbar ist, nämlich durch Wörterbuchattacken. Wörterbuchattacken basieren darauf, dass man eine ganze Liste von vordefinierten Wörtern schlicht einfach mal durchprobiert, in der Hoffnung, dass jemand ein einfaches Passwort verwendet, das just in dieser Wörterbuchliste vorkommt. Im Falle von einem einwegverschlüsselten Passwort muss lediglich sichergestellt werden, dass auch die Wörterbuchliste die Wörter entsprechend mit dem Einwegverschlüsselungsverfahren chiffriert sind.

Und das dürfte dann auch der Ansatz gewesen sein. Da die RIPE-Datenbank frei zugänglich ist, hat ein findiger Mensch einfach eine Wörterbuchliste genommen, die dort vorkommenden Wörter nach dem gleichen Verfahren einwegverschlüsselt, wie es das RIPE tut und dann einfach nach den Chiffraten in der RIPE-Datenbank gesucht. Äußerst einfach und leider offensichtlich auch hin und wieder wirksam.

Immerhin hat das RIPE reagiert und die Suche nach einwegverschlüsselten Passwörtern insofern erschwert, dass eine Suche nach Sonderzeichen nicht möglich ist, Sonderzeichen aber in den Chiffraten zwingend vorkommen. Sinnvollerweise kann man aber nach wie vor immer nur empfehlen, gänzlich auf die Passwortautorisierung zu verzichten und die PGP-Autorisierung einzusetzen oder zumindest ein hinreichend komplexes und langes Kennwort zu nutzen.

•