NaturalNik Broadcast

Lange Zeit habe ich mich nun mit der Auswahl der richtigen Linux-Distribution beschäftigt. Nachdem ich 2002 meine ersten Kontakte mit Linux machte, als unser damaliger Informatiklehrer an usnerer Schule SuSE Linux einführte, habe ich mich durch diverse Distributionen durchprobiert.

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.

Lange Zeit habe ich mich nun mit der Auswahl der richtigen Linux-Distribution beschäftigt. Nachdem ich 2002 meine ersten Kontakte mit Linux machte, als unser damaliger Informatiklehrer an usnerer Schule SuSE Linux einführte, habe ich mich durch diverse Distributionen durchprobiert. Natürlich habe ich mich mit SuSE lange Zeit wohlgefühlt, hauptsächlich wohl weil ich noch nichts anderes ...

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.

(weiterlesen …)

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

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

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