Ich benutze ja sowieso HTTPS Everywhere (das solltet ihr auch tun), und gesern habe ich mir auch endlich mal wieder Certificate Patrol installiert, ein sehr nützliches Addon, das vor ausgetauschten Zertifikaten und Ähnlichem warnt.

Und dann flog mir plötzlich das hier um die Ohren:

Was ist hier passiert?

Das ist noch relativ einfach. Beim letzten Seitenaufruf hat der Server pixel.facebook.com ein Wildcard-Zertifikat, ausgestellt von DigiCert, vorgezeigt. Das ist eine laut Mozilla vertrauenswürdige CA, und offenbar ist da auch noch nichts gegenteiliges öffentlich geworden, ich habe sie nur gestern mit jemandem verwechselt.

Und dann ist da plötzlich ein anderes Zertifikat, nämlich ausgestellt von VeriSign. Da kommen ein paar Fragen auf:

• Wieso ersetzt Facebook sein Zertifikat plötzlich durch ein VeriSign-Zertifikat? Gut, können sie ja tun, aber …
• … wieso tun sie das JETZT, wo sie das doch (siehe Screenshot) schon seit fast einem halben Jahr rum liegen haben?

So weit so gut, kann ja mal sein, verplante Admins gibt’s immer, oder vielleicht hatten sie sogar einen guten Grund. Aber dann fliegt mir heute das hier entgegen:

Huch, wie jetzt? Facebook ersetzt das Zertifikat für pixel.facebook.com von VeriSign durch DigiCert? (In diesem Screenshot blöderweise das gleiche wie oben, zwischendurch hatte ich da noch ein anderes drin aber leider vergessen zu speichern).

Was ist da los? Nach kurzem Nachdenken ganz einfach:

pixel.facebook.com ist ein Alias für einen Haufen Webserver, die dann per DNS-Round-Robin ausgewürfelt werden:

nik@keks:~$ host pixel.facebook.com
pixel.facebook.com is an alias for star.facebook.com.
star.facebook.com has address 69.171.229.39

nik@keks:~$ host pixel.facebook.com
pixel.facebook.com is an alias for star.facebook.com.
star.facebook.com has address 69.63.190.29

Gut, kann man machen. Nur: ist es sinnvoll, die Server dann auf SSL-Ebene völlig asynchron zu halten? Ich kann mir vorstellen, dass man sich da eigentlich nur selber mit ins Knie schießt. Und bei einigermaßen gut informierten Benutzern löst es auch ein bisschen Verwirrung aus.

Aber pixel.facebook.com liefert ja auch nur Werbung aus, also, äh, die personalisierte Werbung, die das Bewegungsprofil der Benutzer in Form von personalisierten Anzeigen nach außen aggregiert. Ist kein digitales Vertrauen notwendig da!

Update: Ach, auf ihren Haupt-Servern können die das auch. Ich schreib jetzt mal an den Support …

Ich habe das Teil dann mal analysiert und folgendes gefunden:

• Das Programm enthält eine ganze Menge unnützen Code zur Tarnung.
• Es lädt dann von www.ukseikatsu.com eine Datei namens /images/ok.exe nach und legt sie im Benutzerprofil unter einer zufälligen Nummer ab.
• Dieser Code entpackt dann eine weitere Datei namens winsvc.exe, die den eigentlichen Kern darstellt.
• winsvc.exe verbinedt sich zu 141.105.66.235 auf Port 5500. Das ist eigentlich der VNC-Port, deshalb interessiert das die meisten Personal Firewalls nicht. In Wirklichkeit lauscht da aber ein IRC-Server.
• Der IRC-Server ist die Kontrollzentrale eines Botnets, zu dem der Client dann gehört.

Um so einen Mist in Zukunft zu verhindern: Klickt in drei Teufels Namen nicht immer jeden Scheiß an!

Linux-User sind übrigens sicher.

Update: Abuse complaint an Rusconnect, den Provider bei dem der IRC-Server läuft, ist raus.

Update 2: Dominic hat auf meinen Auftrag hin eine ausführbare Version (in Tcl) gebaut. Wir haben den Wurm Paul getauft und paul-removal.exe sollte jetzt auch unter Windows Vista und Windows 7 funktionieren. Hier ist alles gesammelt.

Bei mir geht es akut um die Mozilla-Produkte Firefox und Thunderbird. Seit vielen Jahren ist Firefox mein Standardbrowser und Thunderbird mein Standard-Mailclient. Doch heute habe ich mich entschlossen, diese Ära zu beenden.

Um das zu verstehen, ist es zunächst wichtig, wieso ich überhaupt angefangen habe, die Mozilla-Produkte zu benutzen. Aus dem gleichen Grund wie die meisten hier: Damals war ich noch Windows-Benutzer und es musste einfach ein Ersatz für Microsofts Crapware Internet Explorer und Outlook Express her. Firefox hatte schon damals den Ruf, so ziemlich alles, was Microsoft falsch gemacht hatte, richtig zu machen. Doch wenn man die Fehler anderer nicht macht, muss man eigene Fehler machen. Und das tut auch Mozilla.

Ein wichtiger Grund für den Ausstieg ist der neue Release-Zyklus für Mozilla Firefox. Alle sechs Wochen soll nun eine neue stabile Version des Browsers veröffentlicht werden. Deshalb und wegen der immer mieser werdenden Performance des Browsers steige ich nun vollständig auf Google Chrome um. Der Release-Zyklus sieht hier zwar ähnlich aus, doch im Gegensatz zu Mozilla schafft es Google, vernünftige Pakete und ein Repository für Debian stable bereitzustellen.

Beim Mailclient fällt meine Wahl nach einigem Testen auf Claws Mail. Der Hauptgrund ist, dass ich GPG und S/MIME mit meiner Fellowship-Smartcard machen möchte und die Unterstützung in Form eines PKCS#11-Treibers nicht wirklich gut ist. Claws Mail benutzt als Backend für S/MIME gpgsm. Damit ist eien Integration meines CAcert-Zertifikats in die Smartcard problemlos möglich. Und auch ansonsten macht Claws einen sehr sauberen und vor allem nerdigen Eindruck .

Mal sehen, wie lange diese Software-Auswahl jetzt hält!

Meine Erfahhrung mit dem Club beginnt im Dezember 2009 mit dem 26. Chaos Communication Congress. Felix und ich waren nach Berlin gefahren und verbrachten dort dann vier Nächte in einem Hostel, was kurz vor Silvester auch nicht ganz preiswert ist. Einen Kartenvorverkauf gab es nicht, und als wir 30 Minuten nach Einlass zur Kasse kamen, gab es keine Full-Time-Tickets mehr. Man sagte uns, wir könnten ein Tagesticket kaufen, aber ob das an den folgenden Tagen auch noch gehen würde, wisse man nicht. Als uns dann zu Ohren kam, dass auf irgendeiner Mailingliste unter der Hand Tickets für Freunde der höhrangingen Mitglieder gehandelt wurden, schlugen wir uns zum Chef der Veranstaltung, Christian C. durch. Der behandelte uns wie die letzten Arschlöcher. Er vvermittelte uns, dass er sich mit niederem Volk wie uns gar nicht abgeben würde. Nachdem ich mich veranlasst sah, diesen Ablauf zu Zwittern, tauchten urplötzlich noch mehrere hundert Full-Time-Tickets unter dem Tresen auf. Da wollte wohl ofenbar jemand die schnelle Mark mit den teureren Tagestickets machen!

Weiter ging es dann mit der SIGINT 2010 in Köln. Da war ich zwar nicht direkt betroffen, aber es gab doch einige, die sich zurecht aufgeregt haben. Hier wurden im Vorfeld Tickets verkauft – doch bei der Veranstaltung wurden die dann im Prinzip nicht benötigt. Nur vor einem der vier Vortragsräume und vor der Kaffeemaschine stand jemand, der das Bändchen sehen wollte. Informiert wurde darüber vorher niemand, sonst hätte man ja an denen, die nur zu den Ausstellern wollten, keinen Wucher betreiben können.

Beim 27c3 war das NOC dann nicht wirklich in der Lage, den Switch an unserem Stand zu supporten. Der wurde da einfach hingeknallt und auf irgendeinem Random Port der Uplink konfiguriert. Als uns nach Stunden immer noch niemand verriet, wie wir damit denn nun Netz bekommen, habe ich den Switch entfernt und unser Stand-Notebook direkt angeschlossen. Das Blinken im Nagios war dann endlich Grund genug dafür, dass sich jemand vom NOC zu uns bewegte. Dessen Fix sah so aus, dass er den Switch und mein Patchkabel einkassierte. Nach 20 Minuten brachte er beides wieder, und wir hatten immer noch kein Netz. Und ach ja, als Antwort auf die Frage im Vorfeld, ob wir nun einen Stand hätten oder nicht, bekamen wir als Antwort: “Kommt her und guckt nach ob einer da ist.” Ja, genau, sind ja nur 500km.

Für Max, Simay und mich standen dann im kommenden September die MetaRheinMainChaosDays an. Auf der Website stand bis letzte Woche noch, dass die stattfinden. Nur das Rehistrierungssystem warf ständig einen 404. Dass die gesamte Veranstaltung ausfällt, erfährt man dann auf Nachfrage, wenn man sich über den Fehler wundert. Und dann auch nicht vom CCC, sondern von Anderen, die sich auch schon gewundert hatten. Die Website wurde dann auch erst gehorstet, nachdem ich mich im IRC ordentlich abreagiert hatte. Irgendwo begegnete mir dann noch ein Tweet dazu, aber das ist für mich keine ausreichenden Information für zahlende Besucher.

Zu guter Letzt schmeißt der Vorstand dann auf dem diesjährigen Camp Daniel Domscheit-Berg in einer Nacht- und Nebel-Aktion raus. Völlig daneben, aber es bestätigt das, s sich für mich schon lange abzeichnet: der CCC hält sich für eine Eliteorganisation. Wer an der Spitze mithalten kann, wird bevorteilt; das gemeine Volk wird behandelt wie der letzte Dreck. Natürlich erst, nachdem man ihm das Geld aus der Tasche gezogen hat.

Ich will jetzt nicht Äpfel mit Birnen vergleichen, aber wieso muss der CCC im fünfstelligen Bereich Geld einnehmen, wo andere ihre Besucher für 5€ rein lassen? Aber das ist nicht mal das Problem, sondern: Wenn ich dem Verein die Veranstaltung bezahle, er sich das also ohne mich nicht leisten kann, wieso werde ich dann nicht auch so behandelt? Natürlich, was Domscheit-Berg angeht, auch über die Veranstaltungen hinaus.

Der CCC ist ein wichtiger Verein für unsere Gesellschaft. Seine Veranstaltungen besuche ich noch immer gerne; ich habe mich sogar als Mitglied des CERT beworben. Doch sofern ich nicht der einzige bin, dem die oben geschilderten Eindrücke vermittelt werden, sollte der Club ernsthaft an diesen Problemen arbeiten!

Doch Dominic wurde das Ganze dann irgendwann zu langweilig und er äußerte die Idee, doch mal ein kleines Spiel zu programmieren. Wegen der begrenzten Zeit und der weisen Voraussicht, dass ein größeres Projekt in zwei Tagen schwer zu koordinieren sein würde, schlug ich ein Experiment vor: Wir einigten uns auf ein einfaches, bekanntes Spiel (Schiffe versenken) und entwarfen ein – ebenfalls einfaches – Netzwerkprotokoll. Danach machten wir uns jeder für sich an die Entwicklung eines Clients für dieses Spiel. Am Ende sollten beide gegeneinander spielen können.

Überraschenderweise ging die Idee schon im ersten Testlauf auf: Wir haben es tatsächlich geschafft, auf Anhieb zwei kompatible Clients aufgrund einer vorherigen Vereinbarung zu implementieren. Und hier ist das Ergebnis!

SinkIt! GUI-Version (Dominic)

Dominic ist ja extremer Verfechter von Tcl/Tk, und als solchem fiel es ihm nicht schwer, innerhalb kürzester Zeit ein schon wirklich cooles GUI zu entwickeln. Schiffe lassen sich einfach mit der Maus platzieren und man erkennt sehr übersichtlich, wo man beim Gegner getroffen hat und wo man selber getroffen wurde.

Der Client kümmert sich überhaupt nicht um Sanity Checks oder ähnliches, das war Teil unserer Einigung. Es kam tatsächlich nur um die Implementation des vereinbarten Protokolls an.

Hier gibt es Dominics GUI-Version zum Download (lauffähig unter Linux mit 64-bit-Architektur wegen der Abhängigkeit zu einer elbstkompilierten UDP-Bibliothek – was soll ich sagen, Tcl eben : sinkit-gui-x64.tar.gz

SinkIt! CLI-Version (Dominik)

Ich hingegen habe mich natürlich an meine favorisierte Sprache Python gehalten und einen wirklich abartigen Konsolen-Client hingeschmiert. Immerhin funktioniert das Teil asynchron (nein, wir achten nicht auf Spielrunden, es sollte ja nur das Protokoll implementiert werden ) und ist vollkommen plattformunabhängig. Mit GUIs kann ich halt einfach nicht umgehen .

(Kleine Anmerkung am Rande: nach dem ersten Test haben wir dann mit Dominics Version weitergespielt …)

Mein Python-Skript gibt es hier: sinkit-cli-all.py.gz

Ach ja, übrigens: Doch, normalerweise sind wir geistig gesund .

Natürlich habe ich mich mit SuSE lange Zeit wohlgefühlt, hauptsächlich wohl weil ich noch nichts anderes kannte und SuSE ja allgemein ein beliebter Anfängerfehler ist (oder war). Danach sprang ich, von einem Kollegen infiziert, in die kalten Fluten und beschäftigte mich eingehend mit Gentoo. Bis heute muss ich sagen, dass mir der Gentoo-Ansatz am besten gefällt. Das Portage-System ist natürlich durchaus mit den BSD-Ports vergleichbar und ein rundum angepasstes System ist damit perfekt möglich.

Für den Desktop-Einsatz jedoch eigenete sich Gentoo leider auf lange Sicht nicht. Gerade wenn man öfters mal spontan neue Programme benötigt, gibt es hier Stress. Möchte mann in einer Präsentation ein Programm zeigen, mit dessen Notwendigkeit man vorher nicht gerechnet hat, macht ein dreistündiger Kompiliervorgang nicht den allerbesten Eindruck. Mit dem GRP-Ansatz könnte man dieses Problem zwar lösen, jedoch gibt es da – meines Wissens – keine aktiven Entwicklungen.

Zuletzt war ich dann im Desktopeinsatz langjähriger Ubuntu-Benutzer. Im Serverbetrieb setzte ich stattdessen (größtenteils) auf Debian GNU/Linux. Im Prinzip war der Hintergedanke, grundsätzlich Debian-artige Systeme einzusetzen, da Paketverwaltung und Ähnliches hier einfach am schönsten ist. Ubuntu war die Alternative zu Debian testing, um ein halbwegs aktuelles System zu haben.

Spätestens mit Ubuntu 11.04 “Natty Narwhal” hat Canonical jedoch gezeigt, dass sie ihr Betriebssystem nun gezielt zerstören möchten. Unity und die restlichen damit verbundenen Patches kann man einem gesunden Menschen einfach nicht antun, und vor allem hinterlässt die Art und Weise der Entwicklung einen äußerst faden Nachgeschmack. Es sieht nämlich so aus, als sei Unity nur der Anfang einer langen Ära von Ubuntu-spezifischen Änderungen und Alternativlösungen. Vielleicht gibt es den einen oder anderen, der das möchte, aber ich persönlich möchte von der Community entwickelte, vernünftige Software.

Nachdem ich im letzten Jahr knallhart an Fedora gescheitert war (ieses System wollte bei mir einfach keine Grafik machen oder hängte sich alle 10 Minuten weg; die Fedora-Jungs bei den CLT hatten auch keine Ahnung wie sie das lösen sollten) habe ich dieser Distribution dann in den letzten Wochen noch einmal einen ausführlichen Besuch abgestattet. Zunächst war ich begeistert, da das System wirklich stabil und schnell lief und größtenteils recht unberührt aussah. Nach reiflichen Überlegungen war dann jedoch klar, dass man RPM und vor allem so etwas behäbiges und kaputtes wie yum dann doch nicht haben will. Die Antwort auf die Fragen der Paketverwaltung heißt apt.

Und nicht zuletzt ist da dann noch eine zugegebenermaßen eher religiöse Frage, nämlich die nach dem Maintainer einer Distribution. Aus meiner Sicht ist Debian schlicht die reinste Distribution. Rein bedeutet in diesem Fall, dass es weder einen historisch gewachsenen Bezug zu einem kommerziellen Anbieter (SuSE), einen kommerziellen Träger (Ubuntu) noch einen kommerziellen Supporter, der sich Sitze in einer Foundation kauft (Fedora) gibt. Natürlich wird auch Debian von großen Unternehmen wie HP oder 1&1 gefördert, jedoch gibt es hier keine Anzeichen von überdurchschnittlicher Beeinflussung durch die kommerziellen Interessen eines einzelnen Sponsors.

Bleibt ein ärgerlicher Punkt, nämlich der der in Debian stable deutlich veralteten Software. Jedoch kann man ja, wenn man es vernünftig tut, durchaus mit Debian testing arbeiten oder aktuellere Software händisch nachinstallieren. Für unerfahrene Anwender ist das sicherlich nicht die beste Option, für mich und meinen Benutzerkreis, der in der Handhabung und Wartung des Systems von mir betreut wird, ist es jedoch die beste Alternative.

Es steht hiermit, nach 9 Jahren, also fest: Debian soll und wird meine Heimat werden. Sowohl als Benutzer als auch als aktiver Kontributor.

Ich selber hatte vor einiger Zeit schon mal das Vergnügen, als ich in der aktuellen Ubuntu-Version 10.10 mal vorsichtig Unity testete. Nun kann man ja eigentlich erwarten, dass das Ding zumindest seinen Dienst tut, wenn es auch nicht die Standardoberfläche ist. Die QA einer Distribution sollte ja eigentlich sicherstellen, dass die vorhandenen Pakete keine wirklich abartigen Bugs enthalten. Und im Netbook Remix war Unity ja soweit ich weiß da ja schon Standard. Aber das ging gehörig schief. Nicht nur konnte ich das Teil absolut nicht bedienen, es ging auch alle paar Minuten in einem Segmentation Fault unter. Prost.

Und der schon genannte Usability-Test spricht dann auch irgendwie Bände. Hier mal ein kurzer Überblick über die detailierten Ergebnisse:

• 7 von 10 Testern brauchen Geschicklichkeitsübungen, um das Fenstermenü zu finden
• Das Menü Systemeinstellungen wird noch immer von allen Testern vermisst.
• Nur 5 von 11 Testern haben es geschafft das Launcher-Panel zu bearbeiten. Die meisten versuchten sich mit dem übriggebliebenen GNOME-Menüeditor, der keinem mehr was bringt.
• 8 Tester haben es nicht geschafft ein Icon zum Launcher hinzuzufügen. Warum weiß keiner so genau, das Ding hat sich halt gewehrt.
• 9 von 11 Testern haben es geschafft ein Fenster zu schließen. Das klingt jetzt toll, aber die anderen 9 haben sich nur von plötzlich auftauchenden Bugs oder verschwindenden Buttons nicht so sehr ablenken lassen wie die restlichen zwei.
• 5 von 11 Testern haben Unity beim Testen mal eben komplett gecrashed oder wurden von plötzlich auftauchenden, dauerfokussierten udn nie mehr verschwindenden Fenstern überrascht.

Besonders gefreut habe ich mich ja über diese Formulierung:

9/9 easily saved their LibreOffice Writer document. (P1 recovered
    amazingly well after trying to save "Letter to Mr Smith 08/04/11",
    and getting the vile response "Error stating file '/home/ubuntu
    /Documents/Letter to Mr Smith 08/04': No such file or directory").

Sehr hübsch. Aber lest das am besten alles nochmal selber, es lohnt sich .

Ich bin ja mal gespannt, ob die das noch rechtzeitig gefixt bekommen. Die letzten Releases waren ja drei Tage vor dem Termin auch noch vollständig im A****. Aber so heftig wie das ist, das kann eigentlich gar nicht mehr gut gehen. Bei Felix hat es Unity übrigens gar nicht auf die Reihe bekommen, irgendwas auf den Bildschirm zu malen (X.org und GNOME an sich funktionieren perfekt, wie man da als Unity scheitern kann ist mir ein Rätsel …).

Ubuntu wäre dann damit (außer vielleicht auf Tablets oder Netbooks) wohl vorbei, weil arbeiten kann man mit Unity sowieso nicht vernünftig (mit GNOME Shell dann in Zukunft übrigens auch nicht, aber das vielleicht noch eher). Momentan bin ich mit Debian eigentlich ganz zufrieden, auch wenn die ja “rock solid” immer noch mit “steinalt” übersetzen (da war neulich noch einer ganz stolz dass die jetzt die Security-Patches für Chromium 9 auf ihren Chromium 6 gebackported haben). Aber vielleicht kann man das ja aushalten …

Update: Hier übrigens auch ein netter Artikel dazu von Michael Kofler.

Da wir generell auf allen usneren Servern Fail2Ban betreiben, einen Log-Monitoring-Daemon, der auf Auffälligkeiten wie wiederholte fehlgeschlagene Logins und Ähnliches prüft und entsprechend reagiert. Eine Reaktion ist das bannen der angreifenden Adresse mittels iptables, eine weitere Aktion ist das Versenden eines detaillierten Reports per E-Mail.

Unsere erste Idee war nun, diese Reports zu aggregieren udn an ein zentrales Postfach zuzustellen. Erst einmal nur, um da zwischendurch mal einen kleinen Überblick zu bekommen, wie sich die Angriffe so verteilen. Portscans, SSH-Brute-Force-Angriffe und Ähnliches gehören ja zum “normalen” Grundrauschen im Internet, und da kommt täglich schon so einiges zusammen.

Als wir die Reports dann aggregiert hatten, kam die Idee auf, daraus doch gleich automatisch Abuse Complaints zu generieren und an die Provider der Angreifer zu senden. Da Fail2Ban zwar standardisiert, aber nciht wirklich maschinenlesbar mailt, ist dafür einiges an ekliger Parserei notwendig. Aber es funktioniert.

Und was soll ich sagen? Ich zitiere einfach mal Felix …

aber eins muss ich dir lassen das ist extrem geil was du da gebaut hast

Jo, danke . Was daraus geworden ist, findet ihr jetzt unter dem Namen Bashinators Abuse Central.

Ach ja, übrigens … die Skripts sind eklig. Die Website ist … also, hat ihren eigenen Charm. Und das ist ein Spaßprojekt . Ach ja, und SSI rockt.

Seit ein paar Tagen bekam ich dann von logwatch keine Mails mehr, was ich dann heute mal gedebuggt habe. Nun hat sich wohl irgendwann mal ein User mit irgendwelchem Random-Kram versucht einzuloggen (“3836jai)xoh)”). Unser Samba-Server ist so eingerichtet, dass er eine Logdatei pro User anlegt. Äh, das hat so mal Sinn gemacht … wirklich. Und deshalb gab es jetzt also eine Datei namens “log.3836jai)xoh)”. Und das fand logwatch gar nicht so lustig, denn logwatch wirft eine Liste der Logdateien die es so findet einfach so ohne sanity checks oder Quoting oder sonst was in die sh. Das resultierte dann in ein bisschen Fehlerausgabe und einem unsauberen Ende:

sh: -c: line 0: syntax error near unexpected token `)'
sh: -c: line 0: `cat /var/log/samba/log. 4023 /var/log/sa .........

Ist natürlich alles in allem ärgerlich, und irgendwie sollte man dieses komische Log-Setup auch mal wieder abschaffen. Aber dennoch, ich finde ein logwatch sollte das nicht einfach so tun. Nehmen wir mal an, ein User hätte sich aus Versehen als “; rm -rf /” oder “; poweroff” angemeldet. Dann hätte der Fileserver am nächsten Morgen um 6:25 sauber die Platte gewiped oder sich zur Ruhe gebettet. Echt unschön sowas …

Habe das jetzt mal an die Entwickler gefaxt, aber die lesen ihren Bugtracker offenabr nie. Mal schauen ob sie auf Mails reagieren … und der logwatch darf vorerst in seiner Hütte bleiben .

Update 1.3.2011: Bereits nach wenigen Stunden hatte einer der logwatch-Entwickler auf meine Mail auf der Mailingliste reagiert und einen Patch veröffnetlicht. Heute kriegte ich dann dank Google Alerts mit, dass Ubuntu was dazu in den Security Notices hat.

Und hier ist sie – meine erste offiziell entdeckte Vulnerability – CVE-2011-1018 (CVE | NVD | USN | …). Irgendwie bin ich ja dann doch so’n bisschen stolz. Darf ich jetzt eigentlich noch in die USA einreisen ?

Übrigens war mir bis gerade eben gar nicht klar wieso man da so einen Aufstand drum macht (gut, den macht man um jede Sicherheitslücke, aber es wirkt irgendwie erschlagend). Ich dachte ja das wäre nur in meiner komischen Samba-Konfig. mit den Benutzernamen im Log-Dateinamen so dramatisch, aber dann fiel mir auf, dass das sogar auf den meisten Linux-Distributionen mit Standard-Konfig. exploitbar ist. Viele Default-Konfigs setzen nämlich den NetBIOS-Namen des Clients in den Logdateinamen ein (log file = log.%m). Den kann man sich als Client im Prinzip ja auch selber ausdenken. Samba wird dann zwar unter Umständen sagen “Ne du, das Ding sieht komisch aus” oder “Häh, wer bist denn du?” – aber das wird es nicht nur dem Client mitteilen sondern das auch loggen. Und zwar wohin? Genau …

Update 4.3.2011: Die Debianer haben es dann heute mit DSA-2182-1 auch schon zu einem Advisory gebracht. Boah, sind die flott!

Sehr zu Felix Belustigung (und anfänglich meinem Leidwesen) bin ich dazu übergegangen, wirklich für jeden Dienst ein eigenes Passwort zu verwenden. Dabei gibt es zwei Klassen:

• Selfmade-Passwörter für Dienste, die ich oft brauche oder wo ein Passwortmanager irgendwie doof wäre (Systemanmeldung …)
• Random-Passwörter für Dienste und Websites, die ich nur so am Rande benutze

So habe ich nun also für mein (etwas advancederes) Heimnetz mein altes, sicheres Standardpasswort und für das Leibniz-Netz ein neues, selber zusammengesetztes Passwort (26 Zeichen, alpha-numerisch + Sonderzeichen …. ne, damit hab ich so gar keien Probleme …). Für Facebook & Co. gibt es Zufallspasswörter von einer Qualität, die ich dem entsprechenden Backend zutraue (es gibt noch immer so viele Entwickler die es für eine ganz hervorragende Idee halten, Passwörter zu normalisieren und dann nach 8 Zeichen abzuschneiden …).

Als wichtigste Komponente kommt dann der Passwort-Manager ins Spiel. Meine Wahl fiel dabei, anfangs vor allem deswegen, weil mir keine Alternativen bekannt waren, auf KeePass bzw. seine Variationen. Und diese Software hat sich mittlerweile bei mir mehr als bewährt: Ich benutze die Datenbank des Programms an allen möglichen Orten. Unter Ubuntu (KeePassX), Windows (KeePass, nach Belieben auch in einer portablen Version) und sogar auf meinem Android-Handy (KeePassDroid). Und das hat bisher trotz unterschiedlicher Versionen noch nicht ein einziges Mal geknallt. Daran sollten sich so ziemlich die meisten anderen Entwickler mal eine dicke Scheibe abschneiden.

Jetzt kommt natürlich völlig zurecht die Frage: Wie bekommt man diese Datenbank den nun sinnvoll auf so viele Systeme? Ganz einfach: Mit meinem Lieblings-Webdienst Dropbox.

Dropbox synchronisiert ganze Ordner zwischen mehreren Computern und wenn man das denn möchte sogar mehreren Benutzern. Udn in meiner Dropbox liegt nun also meien KeePass-Datenbank. Das klingt jetzt erstmal total witzlos, dass ich meine ach so hochsicheren Passwörter einem Drittanbieter vor die Füße werfe. Aber in dieser Dropbox liegen sogar meine SSL- und GnuPG Private-Keys. Man muss sich halt sicher sein, dass niemand, der die Daten bekommt, dann auch tatsächlich etwas damit anfangen kann. Dank sicherer Krypto-Container sollte das nicht so das große Problem sein.

Was aber klasse ist: Genau so wie KeePass gibt es den Dropbox-Client wieder für alle wichtigen Plattformen, das heißt Windows, Linux und Android. So habe ich meine Passwortdatenbank immer und überall parat.

Ob das irgendwann mal noch ganz kräftig in die Hose geht (mein lieber Felix prophezeit mir das ja schon von Anfang an, aber da setze ich mal darauf dass er eh dann irgendwo ein Backup findet …) wird sich zeigen, aber bis dahin kann ich erstmal nur sagen: Wow, genial!