Das Internet der Dinge – wenn IPv6 unverzichtbar wird

Das “Internet der Dinge” – was für ein merkwürdiger Begriff. Englisch (Internet of Things, kurz: IOT) klingt das auch nicht besser. Was also verbirgt sich dahinter? Tatsache ist, dass immer mehr Geräte über eine Internetanbindung verfügen und mittels einer IP-Adresse auch mit anderen Systemen aus dem Internet kommunizieren. Neulich habe ich mir einen neuen Blu-Ray-Player gekauft und musste im Rahmen der Assistent-gesteuerten Erstkonfiguration auch eine IP-Konfiguration eingeben bzw. die Netzwerk-Schnittstelle des Blu-Ray-Players für den Bezug einer IP-Konfiguration mittels DHCP-Server einrichten. Das Gerät ermöglicht nun auch die Auswahl von Youtube-Videos und ähnliches.

“Das ist doch ein alter Hut!”, werden Sie jetzt sagen. Klar, aber wenn wir diesen Gedanken jetzt konsequent weiterführen, ist es nicht mehr weit bis zu dem Punkt, an dem auch Geräte IP- und Internet-Anbindung haben, die wir heute vielleicht noch gar nicht auf dem Schirm haben. Kürzlich habe ich eine Werbung des Engergiedienstleisters EnBW gesehen, in der für eine App für iPhone & Co geworben wird, über die die Heizung, das Licht und andere “Dinge” im Haus gesteuert werden können – selbstverständlich von überall. Haben Sie Ihr Bügeleisen abgeschaltet bevor Sie in den Urlaub gefahren sind? Schauen Sie doch einfach nach – in webbasierten Management-Oberflächen oder eben in der All-in-One-App von EnBW & Co.

“Dinge” – da ist es, das ominöse Wort. Die Vernetzung von beliebigen Dingen – vom Kühlschrank über das Bügeleisen bis hin zu Sensoren, die bestimmte Umweltparameter messen und in Echtzeit an eine Auswertungsstation senden. Langfristig geht der Trend weg von dedizierten Computern, die als eierlegende Wollmilchsäue alle in diesem Rahmen anfallenden Arbeiten erledigen und entsprechende Interfaces bereitstellen hin zu einzelnen, hochspezialisierten Geräten (oder eben “Dingen”), die auf sich selbst gestellt ihren kleinen, aber wichtigen Beitrag zur Automatisierung und Remote-Steuerung des alltäglichen Lebens beisteuern. Diese Dinge kommunizieren untereinander oder mit zentralen oder auch dezentralen Managementsystemen – das Internet der Dinge.

Was erwartet uns also in Zukunft? Welche “Dinge” sind dazu prädestiniert, das Internet der Dinge zu bevölkern? Der Fantasie sind keine Grenzen gesetzt! Im Grunde könnte jeder Kugelschreiber seine eigene Internet-Anbindung erhalten. Das ist Ihnen zu weit draußen? Dann nehmen wir doch einfach mal Brillen – spätestens seit der Vorstellung von Googles “Glass” ist der Weg zur alltäglichen Verbindung von Brillen mit dem Internet keine Utopie mehr, sondern greifbar nahe. Und so finden wir Anwendungsmöglichkeiten in diversen Bereichen, z.B.:

  • Fernwartung: hier können so ziemlich alle technischen Gegenstände, die verschiedene Zustände haben können, gesteuert und deren Zustand ausgelesen werden, z.B. Autos, Gasthermen, Baumaschinen, Roboter, etc.
  • Mess- und Sensortechnik: was heute noch vor Ort an Daten abzulesen ist, kann morgen schon automatisiert an zentrale Managementstationen geliefert werden.
  • Gebäude-Automation: diverse Elemente von Gebäuden können automatisiert überwacht und gesteuert werden – Jalousien, Heizungen, Klimanalagen, etc.
  • Medizintechnik: die Überwachung diverser medizinischer Geräte – von großen radiologischen Geräten bis hin zum Herzschrittmacher.

Auch wenn diese Liste noch wesentlich länger werden könnte, dürfte jetzt bereits klar werden, wie sich die Kommunikation im Internet zukünftig entwickeln könnte. Der Mensch wird hier eine zunehmend geringere Rolle spielen – wobei das Internet der Dinge darauf ausgerichtet ist, den Menschen in seinen Tätigkeiten besser zu unterstützen. Aber eben auf weniger aufdringliche Weise oder zumindest hochgradig automatisiert.

Kommen wir nun zu der Frage, was das Ganze mit IPv6 zu tun hat. Die Antwort darauf liegt gar nicht mal in erster Linie darin, dass derartig viele Geräte ja auch entsprechend viele IP-Adressen benötigen, die dann nur von IPv6 in ausreichendem Maße bereitgestellt werden können – auch wenn diese Aussage sicherlich wahr ist. Entscheidender hierbei ist, dass viele Dinge, die zukünftig IP-basiert kommunizieren werden, ein längere Lebenszeit haben, als dies bei unserem PC, Smartphone oder Tablet – oder auch der Blu-Ray-Player der Fall ist. Ein Steuerungsregler oder eine Gastherme wird voraussichtlich noch in 10 oder 15 Jahren in Betrieb sein können – und in dieser Zeit wird sich aller (skeptischen) Voraussicht nach IPv6 flächendeckend durchgesetzt haben. Das Internet der Dinge wird zu einem erheblichen Teil aus kleinen, hochspezialisierten Geräten bestehen, die über keine Update-Funktion oder ähnliches verfügen. Damit muss alles, was das Gerät auch in 10 oder 15 Jahren können soll, bereits heute verbaut und berücksichtigt werden – und dazu gehört eben auch IPv6.

Fragen, die sich daraus ergeben, sind z.B., wie viel Speicher muss ein solches “Ding” haben, um IPv6 zu unterstützen? Welche Kommunikationsformen muss das Gerät beherrschen, um zukunftssicher zu sein? Welche Reaktionszeiten sind notwendig, welche Verzögerungszeiten tolerierbar, etc. Hersteller können es sich bei diesen Embedded-Systemen nicht leisten, IPv6 zu ignorieren. Der Speicherplatz, den IPv6 benötigt, ist deutlich schwieriger zu berechnen, als für IPv4. Dies liegt unter anderem daran, dass IPv6 im Gegensatz zu IPv4 mehrere Adressen auf einem Interface nutzt: neben der Link Local-Adresse z.B. auch eine Unique Local- und eine (oder mehrere) Global Unicast-Adresse(n). Hinzu kommen ggf. bestimmte Multicast-Adressen.

Unter dem Strich bringt IPv6 hier ein einen gewissen Unsicherheitsfaktor mit sich, der schwierig zu handhaben ist, da heute noch nicht sicher abschätzbar ist, wie sich die Kommunikation in 10 oder 15 Jahren darstellen wird. Das Internet der Dinge wird kommen bzw. sich deutlich ausweiten. Es bleibt nur zu hoffen, dass die Hersteller die Zeichen der Zeit erkennen und sich der Herausforderung von IPv6 stellen – ansonsten könnte es passieren, dass in 10 bis 15 Jahren das Internet der Dinge zur IPv6-Bremse wird.

 

E-Mail-Tracking: Ich weiß wo dein Haus wohnt!

Wie fänden Sie es, wenn Sie eine E-Mail in Frankfurt am Bahnhof über Ihr Smartphone öffnen würden und beim Absender geht im gleichen Moment ein Alarm los: “Manuela Meyer hat am 7.10.2013 um 15:33 Uhr die Mail in Frankfurt mit ihrem iPhone aus dem D2-Netz geöffnet”? Also mich beunruhigt dieser Gedanke durchaus. Tatsache ist, dass das so genannte E-Mail-Tracking seit langer Zeit tägliche Praxis ist! In der Tat ist es grundsätzlich problemlos möglich, die oben genannten Informationen zu ermitteln – und zwar genau zu dem Zeitpunkt, da Sie als Empfänger Ihre Mail öffnen! Wie das geht und wie Sie sich dagegen schützen können, möchte ich Ihnen in diesem Blog-Beitrag einmal erläutern.

Basis des E-Mail-Trackings ist das Einbetten externer Bilder in Mails. Oftmals sind diese Bilder nur ein Pixel groß, so dass sie nicht erkannt werden. Dabei lädt der Mailclient im Moment des Öffnens der Mail die entsprechende Grafik von einem Server nach. In diesem Zusammenhang greift der Mailclient also auf den Server zu, der nun wie bei einem Webzugriff unter anderem die folgenden Daten sammeln kann:

  • IP-Adresse des zugreifenden Systems (damit ist eine Lokalisierung möglich)
  • Mailclient und Betriebssystem (durch den so genannten User-Agent-String)
  • Provider, über den zugegriffen wird (ebenfalls über die IP-Adresse ermittelbar)

Dies setzt allerdings voraus, dass das Bild auch tatsächlich nachgeladen werden kann. Da sich HTML-Mails inzwischen als Standard etabliert haben, ist dieser “Nachlade-Vorgang” jedoch ganz natürlich geworden, auch wernn er glücklicherweise bei den meisten E-Mail-Clients per Default deaktiviert ist. Hier werden dem Leser nur Buttons mit dem Hinweis “Bilder downloaden” o.ä. angezeigt, so dass Sie hier noch eine gute Kontrolle darüber haben, ob und was nachgeladen wird.

Interessanterweise sieht dies bei einigen Systemen – allen voran Webmailer – allerdings anders aus: hier wird fröhlich nachgeladen, was das Zeug hält.So ist diese Funktion z.B. beim Webmailer von 1und1 automatisch aktiviert. Die nachfolgende Abbildung zeigt, an welcher Stelle der Einstellungen des Webmailers das Nachladen externer Bilder unterbunden werden kann:

Unter E-Mail|Einstellungen|Anzeigen können Sie die Option Laden extern verlinkter Bilder sperren aktivieren. Dies ist in der Regel eine sehr gute Idee! Bei manchen Mailclients bzw. Webmailern ist diese Option allerdings gar nicht vorhanden. Hier können Sie sich maximal durch Nutzung von Proxies davor schützen, Ihren Standort preiszugeben. Da der User-Agent-String trotzdem versendet wird, erfährt der Absender zumindest Ihre Client- und Betriebssystem-Informationen.

Und wer glaubt, mit seinem Smartphone auf der sicheren Seite zu sein, irrt ebenfalls gewaltig: viele Smartphone-Mailclients laden HTML-Inhalte sofort und ungefragt herunter. Auch hier müssen Sie diese freizügigen Voreinstellungen explizit anpassen, um sich zu schützen. Dasselbe gilt natürlich auch für Tablets.

Falls Sie sich jetzt fragen, wer an solchen Informationen Interesse haben könnte – abgesehen von der NSA, die jedoch direkt an der Quelle sitzt und daher nicht auf derartige Tricks zurückgreifen muss: es handelt sich z.B. um

  • Werbeagenturen, die ihren Kunden nachweisen müssen, wann, von wem und wie oft entsprechende Info-Mails geöffnet wurden
  • Unternehmen, die Informationen über ihre Kunden sammeln wollen (wie z.B. T-Online, welche Rechnungen mit entsprechenden Tracking-Bildern verschickt)
  • Daten-Diebe, die vor dem Verkauf der gestohlenen E-Mail-Listen die Echtheit von E-Mail-Adressen überprüfen wollen
  • usw.

Tja, Interessenten an diesen Informationen gibt es genug – daher hat sich eine ganze Branche um das E-Mail-Tracking entwickelt, um auch das letzte Quentchen an Informationen zu ermitteln, die wir ungeahnt preisgeben beim Öffnen unserer Mails …

Mit DS-Lite und IPv6 in die falsche Richtung

Eigentlich sollten wir uns freuen: Der Internet-Provider Unitymedia bietet seinen Kunden Kunden in Baden-Württemberg jetzt Download-Raten von bis zu 100 MBit/s und damit eine Steigerung um 100% gegenüber den bisherigen Angeboten. Doch damit nicht genug: da Unitymedia die öffentlichen IPv4-Adressen ausgehen, wurde nun im Zugangsnetz zusätzlich auf IPv6 umgestellt – spitze! Ich als IPv6-Botschafter kann eine solche Entwicklung nur begrüßen! Wenn, ja, wenn da nicht ein Haken bei der Sache wäre: Unitymedia nutzt für das Zugangsnetz und für die Anbindung neuer Kabel-Kunden DS-Lite. Dies steht für Dual Stack-Lite und bezeichnet eine tunnelbasierende Migrationsstrategie für den Übergang auf IPv6. “Ja und, Eric, was ist daran nun schlecht?” werden Sie jetzt vielleicht fragen.

Zunächst sind Tunnelmechanismen immer eine Krücke und mit bestimmten Einschränkungen versehen. Entweder erfordern sie eine aufwändige Infrastruktur oder sie sind langsam, unperformant oder vielleicht nicht umsetzbar. Und normalerweise geht es um das Tunneln von IPv6 in IPv4-Paketen. Bei DS-Lite jedoch geht es darum, IPv4-Traffic in IPv6 zu tunneln. Lassen Sie uns also mal einen Blick auf die technischen Aspekte bei DS-Lite werfen, um gemeinsam nachzuvollziehen, wo das Problem liegt:

Bei DS-Lite (spezifiziert nach RFC 6333) existiert im Zugangsnetz des Providers kein offizieller IPv4-Netzbereich. Stattdessen erhält der Kunde (bzw. dessen externe Router-Schnittstelle) eine Global Unicast-IPv6-Adresse, mit der er über IPv6 direkt ins Internet kommunizieren kann. Die internen Systeme erhalten bei Bedarf ganz normal private IPv4-Adressen (gemäß RFC 1918) vom Router oder Kabelmodem per DHCP oder manuell zugewiesen. Diese sind vom Kunden frei wählbar. Und jetzt kommt das Neue:

Wenn jetzt ein internes System über IPv4 ins Internet kommunizieren möchte, wird das Paket am Router nicht etwa wie bisher auf eine öffentliche IPv4-Adresse genattet sondern mit Original-IPv4-Adresse in einen IPv6-Tunnel geleitet und zum Provider-NAT-Gerät (Carrier Grade NAT, CGN genannt) weitergeleitet. Das CGN-Gerät entpackt das IPv6-Paket und führt mit der IPv4-Adresse des Kunden eine Network Address Translation auf eine öffentliche Adresse des Providers durch. Das Paket wird nun ganz gewöhnlich durch das IPv4-Internet zum IPv4-Ziel geroutet und das Antwortpaket gelangt zurück zum CGN-Gerät.

Damit das CGN-Gerät eine Zuordnung des Antwortpakets vornehmen kann, hat es sich zum Zeitpunkt der Weiterleitung des ersten IPv4-Paketes des Kunden die folgenden Informationen gemerkt:

  • Source-IPv6-Adresse des Kunden
  • Source-IPv4-Adresse des Kunden
  • TCP/UDP-Ports

Da die eindeutige IPv6-Adresse des Kunden in der NAT-Tabelle enthalten ist, kann der Kunde auch jede beliebige IPv4-Adresse verwenden – auch wenn hunderte von anderen Kunden die gleichen IPv4-Adressen verwenden. Notfalls greifen die bekannten Port Address Translation-Regeln (PAT) und passen die Source-Port-Nummern an.

Abb. 1: DS-Lite mit CGN (Quelle: Wikipedia, Autor: Mro)

Mit DS-Lite wird also ein reines IPv6-Zugangsnetz verwendet, um sowohl über IPv6 nativ als auch via IPv4 kommunizieren zu können. Der Unterschied zum Dualstack liegt insbesondere darin, dass die NAT auf den Provider übergeht. Soweit ist das in Ordnung. Warum also spreche ich von einem Weg in die falsche Richtung? Nun, auch hier hängt es natürlich von der Perspektive ab: während normale Anwender, die ausschließlich Traffic in Richtung Internet initiieren (WWW, Mail, FTP, DNS, etc.) vermutlich keine Probleme bemerken werden, sieht das für Poweruser, die von außen auf ihren Anschluss zugreifen wollen, ganz anders aus! Da der Provider hier die NAT durchführt, werden IPv4-Pakete von außen sofort verworfen. Ein direkter Zugang – auch über DynDNS-Mechanismen, ist nicht mehr möglich. Ihre privaten Server zu Hause können Sie also nicht mehr ansteuern …

Wohl gemerkt gibt es natürlich Auswege aus dem Dilemma: zum einen gibt es eine Reihe von Anwendungen, die eine Verbindung zu einem zentralen Server im Internet aufbauen und erst anschließend miteinander verbunden werden (z.B. das beliebte TeamViewer). Zum anderen ist nach wie vor möglich, Cloud basierte Anwendungen, die im Internet gehostet werden, zu nutzen. Außerdem kann man den Spieß auch umdrehen und Tunnelverbindungen durch Reverse-Tunnel nutzen.

Wie ist DS-Lite nun zu bewerten? Zum einen bietet der Provider nun endlich einen nativen IPv6-Zugang. Das ist natürlich positiv! Zum anderen ermöglicht der Kundenanschluss nun aber keine direkte IPv4-Kommunikation mehr, stattdessen führt der Provider an seinem Übergangspunkt zum Internet die Network Address Translation durch. Diverse Anwendungen, unter anderem übrigens auch VPN-Technologien, haben so ihre liebe Mühe oder versagen gänzlich den Dienst unter diesen Bedingungen.

Unter dem Strich ist DS-Lite eine Technologie, die die meisten Provider daher zu vermeiden versuchen. Unitymedia blieb aber nur wenig anderes übrig, da der Ansatz des Dual-Stacks, bei dem gleichermaßen eine IPv6-Adresse und eine IPv4-Adresse bereitgestellt werden, aufgrund des zuneige gehenden IPv4-Adresspools einerseits und des Kundenansturms andererseits nicht durchführbar ist. Bleibt zu hoffen, dass sich IPv6 bald flächendeckend durchsetzt, damit der native IPv6-Anschluss sinnvoll genutzt werden kann …

Debian Wheezy – In der Ruhe liegt die Kraft …

Seit dem 4. Mai 2013 ist es endlich soweit: Debian veröffentlicht seine neue Version 7.0 mit dem Codenamen “Wheezy”. Damit sind wiederum über 2 Jahre ins Land gezogen seit dem letzten Release von Debian 6.0 “Squeeze”.

Und wieder liefert Debian veraltete Software aus, wie z.B. den Kernel 3.2 (aktuell ist 3.9), Firefox 10 (aktuell: 20) und Gnome 3.4 (aktuell: 3.8). Diesen Umstand empfinden viele als großen Nachteil und greifen zu Alternativ-Distributionen wie Ubuntu, openSUSE oder Fedora. Diese Distris sind allein schon aufgrund ihrer meistens halbjährlichen Releases deutlich aktueller und für Anwender mit Bedarf an neuen Features interessanter.

Aber tatsächlich ist diese veraltete Software Debians größte Stärke! Warum? Weil das Debian-Projekt bereits Mitte 2012 den Freeze für die neue Version ausgerufen hat – soll heißen, seit dem hat sich der Software-Stand nicht mehr verändert und wurde nur noch intensiv getestet und ggf. optimiert. Mit Debian erhält der Anwender also eine auf Stabilität ausgerichtete Distribution, was sie insbesondere im Serverbereich sehr beliebt macht.

Ich bin ehrlich: auf einem Desktop- oder Laptop-System würde ich selbst kein Debian laufen lassen, da experimentiere ich lieber mit aktueller Software und aktuellen Features. Andererseits muss ich in diesem Bereich – ebenso wie bei anderen Distributionen – damit rechnen, dass mir ebendiese neuen Features das eine oder andere Mal um die Ohren fliegen, sprich: abstürzen oder eben nicht korrekt funktionieren.

Nun bin ich allerdings ohnehin an Linux in erster Linie als Serversystem interessiert, daher ist das Thema “Desktop” für mich nicht so relevant. Aber sollte jemand die Notwendigkeit haben, mit Debian als Desktop-System arbeiten zu müssen, kann er zum einen auf den Testing- oder gar Unstable-Zweig zugreifen (anstatt die “Stable”-Version zu nutzen) oder aber auf so genannte ”Backports” zurückgreifen, also neue Software, die für die ältere Plattform angepasst wurde. In den Backport-Repositories sind allerdings nicht alle Pakete enthalten. In Punkto “Software” ist Debian übrigens ohnehin umfangtechnisch ganz vorn, da mit dem Release derzeit über 37.500 Programmpakete bereitgestellt werden! Was es als Software unter Debian nicht gibt, steht in der Regel auch nicht in anderen Distributionen zur Verfügung.

Wie auch immer: mit dem neuen Release “Wheezy” sind unter dem Strich nur relativ geringe Änderungen gegenüber der Vorgänger-Version zu verzeichnen, unter anderem der Wechsel auf den 3er Kernel und Gnome 3 mit der Gnome Shell. Es handelt sich also nicht um eine “Revolution” der Plattform, sondern eher um eine behutsame “Evolution”.

Auf jeden Fall werde ich in der jetzt anstehenden Überarbeitung meines Buches “Linux-Server mit Debian GNU/Linux” neben der reinen Aktualisierung der vorhandenen Inhalte auch ein paar neue Themen, wie z.B. VPNs und Virtualisierung, einbringen.

Cyber Wars: Die Rückkehr der Spam-Ritter

Kennen Sie Spamhaus? Nun, seit einigen Tagen ist die Wahrscheinlichkeit stark gestiegen, dass Sie Spamhaus kennen, da die News-Webseiten voll mit Meldungen über diese Organisation zur Spam-Bekämpfung sind. Spamhaus wurde zum Opfer der wohl größten DDoS-Attacke (DDoS=Distributed Denial of Service), die bisher registriert wurde. Dieser Angriff zog auch einige Internet-Knoten in Mitleidenschaft, so dass das gesamte Internet teilweise deutlich langsamer wurde. Doch zum Hintergrund:

Das Spamhaus-Projekt ist eine in der Schweiz ansässige Organisation zur Bekämpfung von Spam, den unerwünschten Werbemails. Hierzu werden so genannte Realtime Blacklists (RBLs) erstellt, die von jedermann als Referenz zur Prüfung von Spam-Absendern verwendet werden kann. Dazu werden diese RBLs mit Adressen gefüllt, die in diesem Sinne auffällig geworden sind.

Manchmal erwischt es jedoch auch die Falschen – falls Ihr Mailserver zufällig auf einer Blacklist gelandet ist, wird es aufwändig, diesen Eintrag wieder entfernen zu lassen: Sie müssen den RBL-Betreiber direkt kontaktieren und ausführlich erläutern, wie Sie die Spam-Gefahr, die von Ihrer IP-Adresse ausging, beseitigt haben. Dann wird entschieden, ob Ihre Adresse aus der RBL entfernt wird.

Ob es nun den falschen erwischt hat oder nicht, sei einmal dahingestellt – jedenfalls sieht es so aus, als ob ein Kunde des niederländischen Providers Cyberbunker auf den RBLs von Spamhaus gelandet ist und dies nicht hinnehmen wollte. Der Cyberbunker-Betreiber Sven Olaf Kamphuis berichtet in einem über einstündigen Chat mit SPIEGEL ONLINE über den Hergang der Organisation dieses Angriffs. Angeblich habe der betroffene Kunde nach Bekanntwerden des Blacklistings seiner Adressen einen Skype-Chat eröffnet und alle Personen eingeladen, die sich in der Spamhaus-Datenbank befanden und auftreiben ließen. Er nennt es eine “Instant-Armee per Mausklick”. Auch Kamphuis selbst hat laut eigenen Angaben kräftig mitgeholfen und weitere Kunden hinzugeholt, die von Spamhaus erpresst worden seien. Dieser “spontane” Zusammenschluss nennt sich “Stophaus”.

Schließlich fasste man den Entschluss, eine umfassende DDoS-Attacke zu starten, die am 18. März begann. Das Ziel war die Überlastung der Server von Spamhaus. Tatsächlich registrierte die US-Firma Cloudflare, die Spamhaus bei der Netzanbindung unterstützt, eine Paketflut von 300 Gigabit pro Sekunde über verschiedene Knotenpunkte. Allerdings gelang es durch Verteilung der Last, Spamhaus am Netz zu halten. Dafür spürte aber teilweise das gesamte Internet die Auswirkungen dieser DDoS-Attacke. Inzwischen wurde dieser Angriff zwar offiziell wieder beendet, doch da auch in einer solchen konzertierten Aktion jeder Angreifer seine eigenen Ziele verfolgt, wird es wohl noch eine Weile dauern, bis auch die letzten Teilnehmer ihre Angriffe abbrechen.

In dem Chat stellt Kamphuis sich und die Spammer als Opfer dar, während Spamhaus eine Zensur des freien Internets vornehmen würde, um die niemand gebeten habe. Die Spammer stellten eine Art Gegengewicht zu dieser Zensur dar und kämpfen eigentlich für das Gute – nämlich ein freies Internet für freie Menschen …

Dazu muss man wissen, dass der von ihm betriebene Internet-Provider Cyberbunker seinen Kunden so ziemlich alles durchgehen lässt, bis auf Straftaten der Kategorie “Kinderpornografie” und “Terrorismus”. Kamphuis war bereits 2010 in Deutschland vor Gericht wegen seiner Verbindungen zum Bittorrent-Verzeichnis The Pirate Bay. Dieser Prozess hat zwar keine ernsten Folgen für Kamphuis gehabt, zeigt aber seine Streitbarkeit: Kamphuis hat damals schon seine Position klar gestellt: “Jeder hat ein Recht darauf, dass seine Daten transportiert werden”.

Tatsächlich wähnt sich Kamphuis also im Recht und rechtfertigt in seiner kruden Logik das Vorgehen der Angreifer. Das Besorgniserregende ist hierbei das fehlende Unrechtsbewusstsein, welches vermutlich auch in den Köpfen vieler anderer Spammer fehlt …

Im Übrigen hat Kamphuis keine Angst vor einer Verhaftung: er hätte viele Botschaften, in die er im Notfall flüchten könne. Willkommen im Internet, der letzten Bastion “frei” denkender Menschen …

Cisco und die Passwörter

Dass Cisco auf seinen Routern und Switches nicht die Passwort-Sicherheit erfunden hat, ist wohl bekannt. Mit dem Typ-5-Passwort (basierend auf einem MD5-Hash) war es zumindest nicht mehr über den erstbesten Google-Link z.B. bei der Suche nach  ”cisco password encryption” möglich, ebendieses zu entschlüsseln. Der in der Running-Config bzw. Startup-Config gespeicherte Hash-Wert ist (bei entsprechender Wahl des Passwortes) deutlich schwieriger und nur unter bestimmten Umständen zu knacken. Laut Wikipedia ist zumindest bisher noch kein so genannter Preimage-Angriff bekannt, der gegen MD5-gesicherte Passwörter erfolgreich war. Auch die viel beachteten Rainbow-Tables sind nur für kurze Passwörter effektiv einsetzbar und verlieren ihre Effektivität bei Verwendung eines “Salts”, also einer zufälligen Zeichenkette, die an den Klartext angefügt wird - was der Grund dafür ist, dass dasselbe Passwort für einen anderen Benutzereintrag einen komplett anderen Hashwert erzeugt.

Da MD5 schon seit langem als potentiell gefährdet betrachtet wird und daher nicht mehr für die Passwort-Sicherung empfohlen wird, hat auch Cisco in seinem Betriebssystem IOS (Internet Operation System) in der Version 15 eine Umstellung auf den Typ 4 vorgenommen, der der Theorie nach einen 80 Byte großen Salt-Wert und 1000 SHA256-Iterationen verwendet. Allerdings gab Cisco nun bekannt, dass das Verfahren bei Cisco falsch umgesetzt wurde, so dass in der Realität überhaupt kein Salt eingesetzt wird und nur eine Iteration zum Einsatz kommt.

Damit ist der neue, eigentlich zum Zweck der besseren Resistenz gegen Brute-Force-Angriffe eingeführte, Typ-4-Algorithmus deutlich anfälliger gegen diese Angriffe als der ältere Typ-5-Algorithmus. Cisco empfiehlt, auf den betroffenen Geräten wieder zurück auf den Typ-5-Algorithmus zu wechseln, was allerdings nicht auf dem System selbst geschehen kann – ebenfalls sehr ärgerlich! Stattdessen muss der Admin den Passwort-Hash auf einem anderen Cisco-Modell erstellen und die entsprechende Zeile in die Konfiguration des betreffenden Gerätes hineinkopieren oder z.B. das Open-Source-Tool openssl verwenden. Die Vorgehensweise ist im Security-Resonse von Cisco beschrieben.

Diese Schwachstelle betrifft im Übrigen nur die Kommandos enable secret <Passwort> sowie username <User> secret <Passwort>. Andere Bereiche, in denen Passwörter verwendet werden, wie z.B. bei Routingprotokollen wie OSPF oder BGP sowie bei IPsec, sind hiervon nicht betroffen, da diese ihre Passwortsicherheit nicht mit dem Typ-4-Algorithmus erstellen.

Cisco wird übrigens den Fehler in der Implementation nicht ausbessern, sondern den Typ 4 als “deprecated” auslaufen lassen, anstatt des Typs 5 wie bisher geplant. In neuen IOS-Releases wird er dementsprechend nicht mehr verwendet. Stattdessen wird zukünftig ein neuer Algorithmus entwickelt, dessen Typ-Nummer noch nicht genannt wurde.