In etwas über einer Woche ist es dann so weit: Ab dem 28.4.2011, also dem Release-Termin der finalen Version von Ubuntu 11.04 (natty), wird knapp die Hälfte der Menschheit endgültig zu blöd für diese Distribution sein. Denn nur so kann man sich erklären, dass in einem kürzlichen Usability-Test der neuen Unity-Oberfläche neben einer ganzen Reihe anderer interessanter Phänomene 5 von 11 Testern das GUI zum crashen brachten.
In den letzten 2,5 Tagen haben Felix und ich uns mal eine kleine “Cyber-Crime-Beobachtungs-Zentrale” zusammengenagelt. Das entstand daraus, dass nach einer Unachtsamkeit eines Kollegen ein paar brasilianische Botnet-Kiddies den Leibniz-Webserver übernommen hatten. Aber darum geht es ja jetzt nicht 
…
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.
OK, also das Benutzernamen-Feld unserer Windows-Clients war wohl für die letzten Wochen eine root-Shell auf unseren Fileserver. Dort hatte ich logwatch installiert, um Benutzer zu fangen, die ihre Accountdaten weitergeben (d.h. z.B. auf einer geographisch völlig unmöglichen Kombination von Clients gleichzeitig eingeloggt sind).
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!
Seit ein paar Wochen zähle ich mich nun offiziell zu den Sicherheitsfanatikern. Also jetzt nicht in dem Sinne, dass ich paranoid vor blauen Lämpchen davonlaufe, weil das ja Bluetooth sein könnte und ich darüber abgehört werde, sondern im Passwort-Bereich.
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:
…)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!
Ich dachte mir gerade ich bewerbe mich mal als neuer Werbedesigner für die T-Com. Den Anfang mache ich mit einem Plakat für die Hotline.
Wenn's mal wieder länger dauert: Abwarten und Tee trinken!
