NaturalNik Broadcast

Passend zu der x.509-Bullshit-Debatte über fallende CAs und die allgemeine Sinnhaftigkeit eines solchen zentralisierten Vertrauensmodells muss ich mir seit gestern mal ein bisschen über Facebook fazialpalmieren.

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?

(weiterlesen …)

Passend zu der x.509-Bullshit-Debatte über fallende CAs und die allgemeine Sinnhaftigkeit eines solchen zentralisierten Vertrauensmodells muss ich mir seit gestern mal ein bisschen über Facebook fazialpalmieren. 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 ...

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.

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 ...

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!

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, ...

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:

• 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!

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 ...

Wenn man sich im Internet ein wenig umsieht, stellt man fest, dass so ziemlich die halbe Netzgemeinde sich schon vor dem Problem sah, dass sie die aktuelle Joomla-Version auf einem System mit PHP 5.3 nicht mehr installieren können. Das liegt an der Inkompatibilität zwischen PHP 5.2 und PHP 5.3. Ich persönlich finde es ja mehr als erstaunlich, wie kaputt man eine Sprache mit einem Sprung in der Minor-Version machen kann. So etwas kann man seinen Benutzern eigentlich nicht antun, und deshalb werde ich in Zukunft auch erst recht die Finger von diesem Krampf lassen.

Nun wollen die anderen ja aber nicht immer ganz so, wie der Admin will, und deshalb muss ich auf dem neuen Ubuntu 10.10 maverick-Server natürlich Joomla (ebenfalls Krampf) supporten. Und in Ubuntu 10.10 ist PHP 5.3 an Bord.

Nun kursieren im Internet die kuriosesten Lösungen. Zum Beispiel könnte man PHP 5.2 selber kompilieren oder einfach aus den alten Repositories installieren, je nach gusto parallel zur neuen 5.3er-Version oder alleine. Beides möchte man so einfach eigentlich nicht. Ersteres könnte irgendwann die Selbstmordrate in der IT-Abteilung enorm steigern, letzteres rollt jedem sicherheitsbewussten BOFH die Fußnägel auf den Rücken.

Zum Glück hatte ich dank des Schneechaos bei der Bahn genügend Zeit, über die Problematik nachzudenken. Und kam auch tatsächlich zu einer Lösung,die ich persönlich für zwar nicht unbedingt resourcenschonend, aber sehr sauber halte: eine chroot-Umgebung mit Ubuntu karmic, darin ein Apache mit mod-php5 in der korrekten Uralt-Version. Und den dann nach außen geproxied.

(weiterlesen …)

Wenn man sich im Internet ein wenig umsieht, stellt man fest, dass so ziemlich die halbe Netzgemeinde sich schon vor dem Problem sah, dass sie die aktuelle Joomla-Version auf einem System mit PHP 5.3 nicht mehr installieren können. Das liegt an der Inkompatibilität zwischen PHP 5.2 und PHP 5.3. Ich persönlich finde es ja ...