Streaming auf AppleTV über Subnetzgrenzen hinweg

airplay_appletvMit dem Update auf Softwareversion 6.1 bekam das AppleTV in Verbindung mit iOS 7.1 und höher ein neues Feature: AirPlay Discovery via Bluetooth. Dies ermöglicht nun viel einfacher die Verbindung zwischen AppleTV und AirPlay-Klienten, wenn sich diese nicht im selben IP-Subnetz befinden. Einrichtungen mit vielen IT-Anwendern sind gezwungen, einzelnen Abteilungen oder Arbeitsgruppen eigene getrennte IP-Subnetze zuzuordnen. Oft wird dem WLAN-Netz auch ein eigener IP-Bereich zugewiesen. Befindet sich das AppleTV dann netztechnisch im IP-Bereich einer Arbeitsgruppe, müssen die Klienten einige Barrieren überwinden.

Haben beide Geräte Bluetooth aktiviert und die aktuelle Softwareversion installiert, wird auf dem iPad/iPod/iPhone das AppleTV angezeigt. Unter Umständen ist jedoch keine Kommunikation zwischen den Klienten möglich. AirPlay erfordert, dass vom AppleTV eine neue TCP/UDP-Session zum Endgerät aufgebaut werden kann, obwohl die ursprüngliche Session vom Endgerät initiiert wurde.

Damit schließt AirPlay Umgebungen aus, die NAT mittels Port-Addresstranslation durchführen. Diese Hürde kann man jedoch durch Aufbau einer VPN-Verbindung überwinden. Verteilt das VPN-Gateway jedem Endgerät eine eigene IP, kann so doch AirPlay eingesetzt werden.

Nun müssen gegebenenfalls noch Freigaben eingerichtet werden, wenn die Subnetze durch eigene Firewalls abgesichert sind. Leider verwendet AirPlay dynamische Ports, so dass ganze Bereiche freigegeben werden müssen. Dabei verläuft die Kommunikation von hohen Ports (49152 – 65535) zu hohen Ports.

Folgende Freigaben sollten eingerichtet werden:Firewallregeln

Je nach Firewall-Typ müssen auch die Rückantworten zu den fünf Freigaben eingetragen werden, also Quellnetz/-port und Zielnetz/-port vertauscht.

Mit diesen Freigaben sollte AirPlay funktionieren. Wir konnten mit den gewählten Einstellungen Videos, Musik und den Bildschirminhalt erfolgreich auf das AppleTV streamen.

Passwörter mit Dashlane aufbewahren, einsetzen und synchronisieren

Meine Ausgangspunkt

Mein digitales Leben ist „geschützt“ durch gefühlt Zillionen von Passwörtern – faktisch sind es einige Hundert, aber mit Erinnerungsvermögen ist da nichts mehr zu machen. Bisher nutzte ich meinen Browser sowie eine lokale Anwendung auf meinem Smartphone zur Verwahrung dieser Credentials. Das war mehr schlecht als recht, denn mein Gerätebestand umfasst OS X, Android, Windows7 und iOS — alles in allem ein mittlerer Alptraum.

Dashlane „betritt“ mein digitales Leben

Ein Artikel von David Pogue [1][2] machte mich auf Dashlane aufmerksam. Das Tool behebt mein Problem inzwischen wirklich recht gut. Der „Migrationsaufwand“ war bei mir nicht wirklich vernachlässigbar, weil die Import-Funktion bei mir nicht so genial funktioniert hat – also knapp unter „Do What I Think“-Niveau. Auch das Sortieren der einzelnen Records nach Kategorien nervt (auch wenn es vernünftig ist).

Nach dieser Einstiegshürde ist Dashlane aber wirklich nützlich. Ich nutze die Anwendung nicht lokal, sondern synchronisiere darüber mein gutes halbes Dutzend Devices. Das funktioniert kostenlos für 30 Tage, danach nur mit einer kostenpflichtigen Subscription – Eine schwierige Abwägung zwischen Geiz und Komfort!

Meine Konfiguration ist nun so, dass ich Dashlane auf meinem Notebook, Arbeitsplatzrechner, Android-Smartphone, iPad und den privaten Rechnern nutze. Das Smartphone nutze ich auch als One-Time-Password-Generator (Google Authenticator).

Erfahrungen

Dashlane ist schon sehr pfiffig darin, Formulare richtig auszufüllen, aber David Pogues Beschreibung erscheint mir etwas zu euphorisch. Mir sind schon etliche Seiten untergekommen, bei denen die Logik nicht funktioniert. Bei englischsprachigen Seiten funktioniert das Auto-Ausfüllen aber gut.

Wirklich cool ist, dass man das Ausfüllen auf „Subdomains“ ausdehnen bzw. einschränken kann und die Möglichkeit mit mehreren Accounts für eine Website umgehen zu können. Nett ist auch die Möglichkeit, sichere Passwörter erzeugen zu lassen; nützlich sind die Hinweise auf vermutliche kompomitierte Web-Site, bei denen man Accounts hat. Das Wallet habe ich bisher wenig (aber erfolgreich) genutzt. Die anderen Features wie Nachrichten-Austausch und so nutze ich nicht.

Risiken und Nebenwirkungen

Ach ja, das Synchronisieren geht natürlich über die Server von Dashlane. Das Sicherheitsmodell scheint mir wasserdicht zu sein, solange man auf keinem seiner Endgeräte einen Keylogger eingefangen hat oder sonst irgendwie das Masterpasswort verliert. Im Normalfall geht also „unbrauchbarer“ AES256-Datenschrott über den Austauschpunkt. Für die Sicherheit von AES256 gibt es sogar eine Zusicherung der NSA – super!

Um etwas Schutz gegen die Keylogger-Problematik zu haben, nutze ich die Zwei-Faktor-Authentifizierung. Dann kann niemand ein Endgerät mit meinem Dashlane-Datenaustausch-Account verknüpfen. Wenn ich mein Android-Smartphone UND mein Masterpasswort verliere, wäre das natürlich ganz schlecht.

Nun gut, die Prism-Tempora-Sonstwas-Maschinen wissen nun wirklich ganz genau, welche Endgeräte ich nutze. Vermutlich ist dies ja auch für jene Leute die wirklich interessante Information – Passwörter von Individuen brauchen die eh nicht so dringend. Also: „Ja, man gibt Futter für diese Maschinen“, damit das Korrelieren im Big-Data-Wust dann besser geht.

Zusammenfassung

Angesichts des Nutzens finde ich das Werkzeug sehr interessant und werde es weiterhin einsetzen. Unberührt von der technischen Coolness ist der Umstand, dass beispielsweise eine Unternehmspolicy das Hinterlegen bestimmter Credentials in Password-Manager-Anwendungen untersagen kann.

Zwei-Faktor-Verifikation für Google-Accounts

Ob das RRZK-Blog ein guter Platz ist, um über ein Feature von Google-Accounts zu schreiben? Ich bin nicht sicher, aber viele an der Uni nutzen ja die Google-Angebote und daher ist es vielleicht für ein paar Leute von Interesse.

Ich selbst nutze einen Google-Account seit 2006 für mein „persönliches digitales Leben“. Die Datenschutz-Problematik ist mir durchaus bewusst, aber die Funktionen sind einfach zu verführerisch, um widerstehen zu können. Schon lange hat mich gestört, dass meine Daten nur durch ein kleines Passwort von der Welt getrennt sind. In einer globalen Cloud können merk- und tippbare Passwörter praktisch nie ein geeigneter Schutzmechanismus sein.

Seit einigen Monaten bietet Google nun eine Authentifizierungsmethode an, die „Two Step Verification“ genannt wird. Das klingt verdächtig nach der klassischen Zwei- bzw. Mehr-Faktor-Authentifizierung. Dies legt auch die Intro-Page nahe, die sagt „Sign in will require something you know and something you have“. Klingt sehr gut.

Der Start ist auch recht simpel; eine kleine Änderung in den Account-Einstellungen und man erhält Einmal-Zugriff-PINs über SMS, Voice Call oder eine recht nette Authenticator-App (für Android, iOS usw.), die zusammen mit dem traditionellen Passwort den Zugriff auf das Konto ermöglichen. Außerdem kann man Geräte nach eigenem Ermessen als „vertrauenswürdig“ einstufen; dann entfällt dort die Eingabe der zusätzlichen PIN. Auch der Desaster-Fall ist bedacht: dafür gibt es Backup-PINs zum Ausdrucken (Natürlich nicht ausdrucken, falls der Drucker ein Gerät mit Festplatte oder Netzwerk-Anschluss ist 😉 ).

Wie immer gibt es in der schönen neuen Welt auch ein paar Relikte aus der hässlichen alten Welt; in diesem Fall sind das die „anwendungsspezifischen Passwörter„. Diese sind zwar nicht „anwendungsspezifisch“, aber Passwörter mit fast allen schlechten Eigenschaften, die Passwörter haben können. Sie sind nicht anwendungsspezifisch, weil sie den Zugriff auf das komplette Google-Konto ermöglichen. Die Terminologie bedeutet, dass sie nur für eine bestimmte Anwendung eingesetzt werden sollen.

Ein zusätzlicher Schutz (im Vergleich zum klassischen Passwort) besteht neben der Länge darin, dass es weniger Risiken gibt, das Passwort zu verlieren oder unabsichtlich offenzulegen (revealing). Faktisch wird es einmal angezeigt und dann nie wieder; schreibt man es nicht auf, sondern kopiert es sofort in die Anwendung der Wahl und vergisst es, so kann man es selbst nicht mehr verlieren. Trotzdem kann in der rauen Wirklichkeit das eigene Google-Konto über diesen Mechanismus „geknackt“ werden. Also: Der Provider kann es noch „für einen verlieren“ – quasi „RaaS, Revealing as a Service“.

Klar, die „anwendungssprezifischen Passwörter“ sind eben Passwörter und daher ist der Authentifizierungsmechanismus auch keine echte Zwei-Faktor-Authentifizierung. Ich vermute, dass Google daher auch von einer „Two Factor Verification“ spricht. Zu dem Mechanismus und seinen potenziellen Schwachstellen gibt es diverse mehr oder weniger technische Erläuterungen.

Alles sinnlos also? Falls das eigene digitale Leben spartanisch ist und sich auf die Browser-Schnittstelle bzw. moderne Android-Systeme (wohl >2.3) beschränkt, sind anwendungsspezifische Passwörter verzichtbar. Dann ist das Niveau des Zugriffschutzes mit Zwei-Faktor-Verifikation deutlich besser als ohne.

Andernfalls muss man halt mit dem kleinen Schönheitsfehler leben. Ein Sicherheitszuwachs bleibt: Falls man doch einmal das gute alte Passwort verlieren sollte oder falls es ein Service-Provider „für einen selbst“ verliert, kann nicht ohne weiteres von jedem Rechner im Internet auf das Konto zugegriffen werden.

Was man auch noch im Auge behalten sollte:

  1. Gut auf die Backup-Codes aufpassen.
  2. Einen kritischen Blick auf die Liste der Sites, Apps und Dienste, denen Zugriff auf die eine oder andere Information des Google-Kontos eingeräumt wird. Sicherheitsvorfälle in diesen Bereichen können auf das Google-Konto übergreifen.

SoFS-Nutzung von Android Tablets

Bislang gab es nur Hinweise, wie SoFS von Windows und MacOS aus nutzbar ist. Aber auch von Android aus kann man dank Webdav gut auf SoFS zugreifen. Man installiert sich dazu aus dem Google Playstore zunächst den „Total Commander“ und darin dann das Webdav plugin. Dieses dann mit https(!) checken, sofsdav.uni-koeln.de/private/<username> als pfad, username und password konfigurieren und fertig! Dem Hin- und Her-Kopieren von Dateien zwischen Android-Device und SoFS steht nur noch die verfügbare Bandbreite im Wege…

AirPrint-Erfahrungen

Seit einiger Zeit (ab Version 4.2.1) können iOS-Geräte wie z.B. iPads und iPhones drucken. Der offizielle Weg funktioniert aber nur in Heimnetzwerken und mit wenigen Druckermodellen. Im Netz kursieren viele Anleitungen, wie man diese Beschränkung umgehen kann. Was ich hier darstelle, ist nicht neu, sondern nur ein Erfahrungsbericht über die Fallstricke, die einem begegnen können. Der beste Ausgangspunkt für eigene Versuche, den ich gefunden habe, ist dieser Blogeintrag. Insbesondere die dort aufgelisteten Links sind sehr hilfreich.

Auf die grundsätzlichen Dinge, wie die Konfiguration von CUPS und das Erstellen der Servicerecords im DNS, gehe ich hier nicht ein. Das ist an anderer Stelle (s.o.) schon zur Genüge getan. Folgende Probleme hatte ich zunächst:

  • Farbausdruck ging nicht
  • Druck aus Safari ging nicht

Das letztere Problem wurde, wie man im CUPS-Log (mit debug-Logging) sehen konnte, dadurch ausgelöst, dass das zu druckende Dokument als URF-Image geschickt wurde. URF ist ein „raster image format“, für das Apple den MIME-Typ image/urf verwendet, das aber leider nirgends dokumentiert ist. Eigentlich sollte URF in meinem Fall nicht verwendet werden, weil ich (gemäß den Anleitungen) urf=none deklariert hatte. Ich hielt das für ein möglicherweise neues Problem und habe deshalb nach Lösungen zum Drucken von URF gesucht. Es sei hier schon verraten: das war eine falsche Fährte. Dennoch folgt ein kurzer Exkurs zum Drucken von URF.

Frühere Versionen von Mac OS X hatten einen CUPS-Filter namens urf2pdf, mit dem das Drucken von URF möglich war. Mit dem Update auf 10.6.5 hat Apple diesen Filter gelöscht, man findet ihn aber noch im Netz. Wenn man den (mit den richtigen Permissions, also root:wheel als owner/group) installiert, und in den CUPS-Einstellungen den MIME-Type image/urf aktiviert, klappt das tatsächlich – aber nur unter Mac OS X. Ich habe keine Möglichkeit gefunden, CUPS unter Linux beizubringen, mit URF umzugehen.

Das zweite Problem war, dass alle Ausdrucke schwarzweiß waren, obwohl im Servicerecord für den Drucker Farbfähigkeit annonciert war. Wie ich jetzt weiß, war beider Rätsel Lösung offenbar identisch: Tippfehler im Servicerecord. Beim Studium der „Bonjour Printing Specification“ von Apple fiel mir auf, dass ich ein (ganz anderes) Attribut falsch geschrieben hatte. Nachdem ich alles entsprechend angepasst hatte, gingen auf einmal Farb- und Duplexdruck. Es sieht so aus, als ignoriere der Parser alle Attribute nach einem falsch geschriebenen. Deshalb wurde auch mein urf=none nicht ausgewertet. Mit der korrigierten Fassung geht jetzt auch ein CUPS-Server unter Linux, weil die iOS-Geräte jetzt alle Druckjpbs als PDF schicken.

Fazit: wie so oft in der IT können kleine Ursachen große Auswirkungen haben.

Intranettes Symbian – Nokia Handys mit Cisco VPN verbinden

Dienstag abend, in einem verspäteten Regionalexpress in der Pampa zwischen Pulheim und Stommeln: Ein netter kleiner RRZK-Mitarbeiter nutzt sein hypermodernes Präzisionsinstrument aus Finnland (a.k.a. Nokia E72), um die E-Mails zu lesen, die ihn nach der Bürozeit erreicht haben. Aha, der Herr Professor Hänneschen hat Probleme mit dem Zugriff auf seinen Webspace und hat daraufhin ein Ticket bei uns eröffnet. Der nette kleine RRZK-Mitarbeiter erkennt das Problem und möchte dem armen Professor den Abend retten, also schnell auf das OTRS zugegriffen und – BÄM… „Zugriff verweigert“. Ach ja, das Ticketsystem ist nur aus dem Uninetz erreichbar. Toll, dass die Uni dafür VPN anbietet. Blöd, dass Nokia Handys sich damit nicht verbinden können.

Nun stehen zur Lösung dieses Problems im Netz diverse kostenpflichtige VPN-Clients zur Verfügung. Aber das Schöne: Es geht sogar kostenlos! Eine ganz allgemeine Anleitung dazu findet man auf den Seiten von Mobilfunk-FAQ. Hier beschränke ich mich daher auf eine etwas kürzere Anleitung für diejenigen, die sich speziell mit dem VPN der Uni Köln verbinden möchten. Vorab: Die Nutzung erfolgt auf eigene Gefahr und ohne Support oder Gewährleistung, falls etwas schief geht!

Zunächst benötigt man diese SIS-Datei, also ein Symbian-Installationspaket. Eigentlich wäre das sogar schon alles, aber leider muss die Datei für jedes Handy einzeln signiert werden. Es besteht über die Seite Symbiansigned die Möglichkeit, ein Programm zu signieren. Wichtig ist dabei die IMEI (die Seriennummer des Handys), die über die Eingabe von *#06# auf dem Handy angezeigt werden kann. Nach dem Upload der Datei erhält man per Mail das signierte Programm als Download.

Sobald Sie über die nun signierte SIS-Datei verfügen, laden Sie diese einfach auf Ihr Handy (per OVI, Bluetooth, Speicherkarte etc.) und installieren Sie das Paket. Je nach Handymodell müssen Sie nun einen neuen VPN- oder Intranetzugangspunkt einrichten und dabei die VPN-Richtlinie bzw. -Policy „VPN-Policy“ auswählen. Der Name des Zugangspunktes selbst ist beliebig. Bei der Einrichtung des Zugangspunktes müssen Sie zudem noch auswählen, über welche Netzverbindung Sie sich mit dem VPN verbinden möchten (neuere Modelle bieten praktischerweise den generischen „Internet“-ZP hierfür an). Künftig können Sie sich dann direkt über den erstellten Zugangspunkt im Uninetz anmelden. Anmerkung: Dies funktioniert *nicht* im WLAN der Uni, ist dort ja auch völlig unnötig.