Administrator's Blog

Wie ich zu meiner Erheiterung eben auf Heise gelesen habe, leitet perl.com neuerdings auf ein dubioses Blog (grepblogs.net) weiter, wo mit Erotik-Inhalten geworden wird. Witzigerweise gehört diese Domain aber Tom Christiansen, einem bekannten Perl-Entwickler. Offenbar hat er versucht, sich ein zweites Standbein aufzubauen, wenns mit PERL mal nicht mehr so klappt Das PERL-Hauptquartier unter perl.org ist aber weiterhin problemlos erreichbar.

Dies ist auf jeden Fall mal wieder ein tolles Beispiel dafür, dass man fremde JavaScript nicht auf seiner Seite einbinden sollte. Schuld ist hier nämlich ein JavaScript-Include, das folgendermaßen aussieht:

<script src="http://grepblogs.net/adx.js" type="text/javascript" language="JavaScript">

Normalerweise liefert dieses Script wahrscheinlich nur ein Banner oder so etwas aus, in diesem Fall aber eben eine nette Weiterleitung

Besonders toll wäre dieses Szenario, wenn mal wer ein paar Server von Google-Analytics hackt. Dann könnte ein Angreifer quasi das halbe Internet manipulieren und auf eigene Server umleiten. Schließlich haben millionen von Webseiten das Google-Analytics-JavaScript bei sich eingebunden. Unter Anderem auch diverse von mir betriebene Projekte. Bei Google sollte der Sicherheitsstandard zwar entsprechend hoch sein, generell ist dies aber kein netter Gedanke. Zumal ja nichtmal Google schuld sein muss, schließlich würde DNS-Spoofing auch schon reichen, um google-analytics.com umzuleiten ...

Nachdem ich mich die Tage mit einer Nasennebenhöhlenentzündung rumgeplagt habe bzw. immernoch rumplage (daher meine geringer Aktivität hier) ist von Tchibo.de bereits die nächste kompetente Antwort auf die von mir entdeckte XSS-Lücke eingetroffen. Schockierenderweise sah die Antwort diesmal so aus:

Sehr geehrter Herr Klikics,
[ ... ]
Das Problem ist bekannt. Soweit uns bekannt ist, wird dies bei den wichtigen Seiten unterbunden.
Sie können uns gerne einen Tipp schicken, damit wir weiter Verbesserungen machen können.

Ist nicht wahr, oder? Entweder man unterbindet XSS konsequent oder man lässt es. Schließlich spielt es im Falle eines Missbrauchs doch keine Rolle, wo genau der User seine Kreditkartennummer an den Phisher übermittelt. Als "Tipp" habe ich diesmal geantwortet, dass man HTML-Tags prinzipiell aus Userangaben entfernen sollte, vor Allem wenn man die Userangaben nach dem Absenden eines Formulares noch einmal anzeigt. Mal schauen ob ich erneut eine so tolle Antwort erhalte.

Im Grunde hätte ich die Lücke (die natürlich immernoch besteht) vielleicht lieber aktiv nutzen sollen, anstatt mich mit dem Support rumzuschlagen. Für eine Senseo-Maschine z.B. für 29,99 EUR hätten doch sicher jede Menge Leute ihre Kreditkartennummer an mich übermittelt, oder?

Erstmal wünsche ich allen Lesern ein gesundes Neues und viel Spaß in 2008 (lieber spät als nie, bin die Tage erst aus dem Skiurlaub eingetroffen ). Natürlich wird das Admin-Blog auch 2008 weiterleben und euch mit mehr oder weniger tollem Tech-Talk erfreuen. Kommentare/Anregungen sind natürlich weiterhin erwünscht, gern helfe ich bei Fragen auch weiterhin per Mail weiter oder gebe Tipps zu meinen Artikeln.

Als erstes technisches Highlight dieses Jahr habe ich als neues Firmenhandy das "QBOWL" von Samsung bekommen, welches von Vodafone als Konkurrent für das iPhone ins Rennen geschickt wurde (siehe Bild). Ein iPhone kommt ja bekanntlich aus bereits erklärten Gründen für mich als Telefon nicht in Frage, und mein altes Nokia E61 hat mich dann doch auf Dauer genervt, vor Allem was die Ausmaße anging. Einige bezeichnen das gute Stück treffenderweise als Eiskratzer ;), aber der Funktionsumfang und die Bedienung als "Business-Handy" waren dennoch einwandfrei. Ich war also dementsprechend gespannt und ein wenig skeptisch, ob das QBOWL meine Ansprüche erfüllen kann.

Nachdem das gute Stück für 399,90 EUR in einem Vodafone-Laden ohne Vertrag, Simlock oder Netlock erworben wurde - ich will ja schließlich meine O2-Karte samt UMTS-Datentarif behalten - machte ich mich gleich ans Testen. Der Lieferumfang kann sich eigentlich sehen lassen, so fanden sich in der Packung eine 4 GByte Micro-SD-Karte samt Adapter auf SD und ein SD-USB-Kartenleser sowie Kopfhörer und offenbar eine Kabel-Freisprecheinheit, die ich allerdings noch nicht getestet habe. Das Telefon selbst wirkt technisch hochwertig, wenn auch das iPhone ein wenig "geiler" ist, ums mal so zu sagen. Das QBOWL hat auch leider nur eine Displayabdeckung aus Plastik und wird ohne Tasche bzw. Tuch ausgeliefert. Besonders das Tuch vermisst man ein wenig, da das Touch-Display sehr schnell fettig wird. Aber dank eBay sollte ich in Kürze stolzer Besitzer von Tasche+Tuch sein

Nachdem ich meine o2-Karte sowie die Speicherkarte und Akku eingesetzt hatte, konnte es losgehen. Das Vodafone-Branding im Gerät hält sich in Grenzen, man wird nur beim Start sowie im Menü durch den "Vodafone-Live" - Eintrag daran erinnert. Unschöner ist hingegen der Vodafone-Schriftzug oben auf der Vorderseite des Telefons, aber auch daran gewöhnt man sich (sieht man auf dem Bild hier nicht). Die Bedienung ist weitestgehend intuitiv, wenngleich man sich manchmal ein wenig mehr CPU-Power wünschen würde, was die Geschwindigkeit der Eingaben mit dem Finger angeht. Teilweise muss man kurz warten, bis etwas losgeht. Im Großen und Ganzen kann man das Gerät aber flüssig bedienen und nach einer Weile macht es sogar richtigen Spaß. Das Display erscheint mir sehr gut ablesbar und farbenfroh, die Kamera ist wohl eher durchschnittlich trotz ihrer 3 MP. Darauf lege ich aber sowieso keinen Wert. Wichtiger sind für mich ein guter Browser sowie Mailclient.

Nachdem ich die Vodafone-Profile durch den UMTS-Zugang von o2 ersetzt hatte, kam ich problemlos ins Netz. Die Geschwindigkeit via UMTS ist sehr angenehm, HSDPA ist via o2 hier in Dresden leider noch nicht verfügbar. Nicht gerade ein Grund, den Vertrag zu verlängern oder o2 weiterzuempfehlen, aber vielleicht tut sich da ja was dieses Jahr. Zu meiner Freude funktioniert das "eingebaute" Google-Maps ebenfalls problemlos mit o2, nur der modifizierte Opera-Mini verabschiedet sich permanent mit Timeouts. Ich benutze allerdings lieber den eingebauten Browser (NetFront 3.4 von ACCESS), der problemlos funktioniert. Die Seiten werden zügig geladen und ordentlich dargestellt. Der Mailclient ist ein wenig unausgereift, so gibt es z.B. nur einen globalen Posteingang für alle Konten. Auch TLS-Auth für SMTP wird offenbar nicht unterstützt, so dass ich auf meinem Postfix-Mailserver smtpd_tls_auth_only=yes auskommentieren musste. Etwas unschön und nicht sehr zeitgemäß - das Nokia hatte damit keinerlei Probleme. SSL wird hingegen unterstützt. Sinnlos finde ich die Begrenzung von Mails auf 2048 Byte - das reicht zwar i.d.R. aus, aber wozu eine solch unsinnige Einschränkung? Nervig ist auch, dass der Mailclient keine RFC-konformen Mails verschicken kann. Man kann also immer damit rechnen, dass die versendeten Mails im Spamassassin auf der Empfängerseite hängen bleiben. Hier mal ein Spamreport für eine normale Mail vom QBOWL aus:

X-Spam-Status: No, score=2.4 tagged_above=-1000 required=6.31
tests=[BAYES_05=-1.11, FORGED_RCVD_HELO=0.135,
FROM_EXCESS_BASE64=1.309, MIME_BASE64_NO_NAME=0.224,
MSGID_FROM_MTA_ID=1.393, SUBJECT_EXCESS_BASE64=0.449]

Der MP3-Player ist einwandfrei und auch die mitgelieferten Kopfhörer klingen nicht direkt schlecht, soweit ich das nach einem Test mit den mitgelieferten Files sagen kann. Auf der SD-Karte befanden sich nämlich 100 Songs und einige Musikvideos. Am Linux-PC wurde das Telefon als Massenspeicher via USB erkannt, so dass man problemlos weitere Songs auf die Speicherkarte laden kann. Bluetooth funktionierte ebenfalls problemlos (sowohl Filetransfer als auch Freisprechen im Auto). Die Tastatur funktioniert nach einer Weile auch richtig gut, so dass man schnell ein paar Mails tippen kann und problemlos im Web agiert. Auch der automatische Mailabruf im vorgegebenen Intervall funktioniert ebenfalls zuverlässig, leider vermisse aber die Abrufzeit-Option vom E61 (da hatte ich Mo-Fr von 8-22 Uhr), denn zwischen 22 und 8 Uhr will ich beispielsweise nicht bei jeder neuen Mail einen Alarm hören sondern schlafen. Ein 24/7 - Abruf von Mails macht für mich keinen Sinn, so dass ich diese Option wohl deaktivieren werde.

Ich finde dennoch, dass das QBOWL trotz einiger Mägel durchaus empfehlenswert ist, sowohl optisch als auch technisch. Wunder darf man natürlich nicht erwarten, aber bis auf WLAN ist eigentlich alles dran, was man von einem modernen Handy erwartet. Und das kann man vom iPhone nicht wirklich behaupten, oder? Das für mich perfekte Handy, sei es nun als Smartphone oder Sonstwas, gibt es aber leider immernoch nicht. Mein damaliger Palm Treo 650/680 war zwar schon recht nah dran, ist aber heute einfach nicht mehr zeitgemäß. So hoffe ich, dass das QBOWL mir gute Dienste leistet, bis sich mal jemand ein Herz fasst und mir das perfekte Handy entwickelt. Denn so weltfremd sind meine Ansprüche an ein solches Gerät sicher nicht ...

Nachdem ich vor einigen Tagen eine XSS-Lücke auf tchibo.de entdeckt hatte, antwortete mir der sofort informierte Support heute leider sehr unzureichend auf die Info zur Schwachstelle in der eigenen Webseite. Offenbar vermutet der Mensch im Support, dass ich das sinnlose "Stallowned"-Bild mit in meine Empfehlungs-eMail packen will. Sehr interessant, diese Vermutung

Meine Erwähnungen von "XSS-Lücke" und "Sicherheitsproblemen" wurden großzügig übersehen und ignoriert, so dass ich leider Opfer dieser Standardantwort wurde:

Sehr geehrter Herr Klikics,
[ ... ]
Die Angaben der fett markierten Felder benötigen wir, um Ihre Empfehlung bearbeiten zu können.
Diese sind bei Ihnen nicht gefüllt.

Das "eingefügte" Bild kann nicht mitgesendet werden.
[...]

Aber natürlich lasse ich nicht locker und habe erneut mit der Bitte um Weiterleitung meiner Info's an die IT geantwortet. Mal schauen, was nun zurückkommt ...

Vorgestern las ich mit Interesse den Heise-Artikel zu einer XSS-Lücke auf bundesregierung.de, wo Marcell Dietl in Blog Links zu bundesregierung.de gepostet hatte, auf dem Ex-Rambo Sylvester Stallone mit einem coolen Hemd und dem Spruch "You got STALLOWN3D" zu sehen war (Link zum Bild). Das war nach dem Fake-Rücktritt von Angela Merkel bereits die 2. Lücke auf der Website der Bundesregierung. Nunja, dass unsere Regierung nicht nur offenkundige Fehler auf ihrer Website sondern in diversen Bereichen hat, ist ohnehin schon lange klar

Alternativ zu dieser Heise-Meldung hatte ich in einem weiteren Tab meines Firefox noch den Onlineshop eines großen Kaffee- und Schnäppchen/Allesanbieters, nämlich tchibo.de, offen. Eine Skijacke hatte es mir besonders angetan, so dass ich diese gleich einem Familienmitglied per Empfehlung senden wollte. Natürlich gibts diese Funktion beim eingesetzten Shopsystem Intershop auf tchibo.de zu jedem Produkt als Option. Und natürlich werden dort (leider) die Eingaben nicht ordentlich geprüft, so dass man mit diversen Tags die tollsten Sachen auf der Tchibo-Seite machen kann. Unter Anderem kann man das coole Stallowned-Bild dort einbinden (siehe Screenshot) und Texte hinterlegen (hier: XSS ist plöt!). Das sind wahrscheinlich noch die harmlosesten Varianten, mit I-Frames und externen Javascripts kann man noch viel mehr machen, vielleicht sogar unerfahrene User zur Eingabe ihrer Kreditkartennummern usw. bewegen, wenn man massenhaft Spams mit diesen manipulierten Links raushaut. Wie einfach das geht, und dass es dort in dem Formular keinerlei Sicherheitsabfragen gibt, zeigt dieser Direktlink (keine Ahnung, wie lange der funktionieren wird), der den Nutzer direkt zu der manipulierten Seite bringt - in diesem Fall nur wieder mit dem harmlosen Bild von "Sly"

Natürlich habe ich es nicht bis auf die Spitze getrieben, sondern lieber die Betreiber über den Missstand informiert ... die Kollegen dort sollten also dringend mal die Datei /home/cvs/cvsroot/tchibo_cvs/dev/share/private/eCS/Store/templates/de/tch_de_recommendation.isml bearbeiten - witzigerweise lässt sich der absolute Pfad zum File im CVS-Repository direkt als Kommentar aus dem Quelltext auslesen (was ja eigentlich nix macht hier an der Stelle). Da kann man auch sehen, dass die Datei zuletzt am 30.11.07 bearbeitet wurde.

Leider gibt es wahrscheinlich noch tausende von Webseiten, die derartige Lücken aufweisen und sich der Konsequenzen nicht bewusst sind. Spätestens aber wenn die eigene Seite einmal für Phishing oder Ähnliches missbraucht wurde und evtl. sogar deswegen in der Presse auftaucht, werden die kleinen Lücken zu richtigen Problemen. Dabei ist es doch eigentlich recht einfach, dies zu umgehen. Eine einfache Umwandlung oder Entfernung von HTML-Tags in Eingabefeldern behebt dieses Problem beispielsweise sehr effektiv.

Update:
Im Heiseforum war ein weiteres, sehr nettes Beispiel verlinkt: XSS auf cdu.de - nur mal als Beweis dafür, dass tausende Sites betroffen sind

Seit einigen Tagen erfreut sich das admin-blog.com (also dieses Blog hier *g*) besonders großer Beliebtheit, wenn man den Stats glauben darf. Und das kann man getrost, denn die Apache-Logs werden seit Ewigkeiten von Webdruid ausgewertet und grafisch dargestellt. Probleme gab es damit noch nie und ich setze Webdruid zudem auch bei diversen anderen Projekten ein. Auf jeden Fall ging die Anzahl der "echten" Besucher am Tag von vorher ~1000, was ich für ein Non-Mainstream-Blog schon gut fand, auf beachtliche ~6000 hoch. Entweder sind das alles Spambots, die das Blog hier "überfahren", oder tatsächliche User. In den Logs sieht man nichts Üngewöhnliches, was auf massive Zugriffe von nur wenigen Quellen hindeutet.

Auf dem Graph rechts kann man das sehr gut sehen. Am 1.12. waren es noch die "normalen" rund 1000 User, dann plötzlich nahezu jeden Tag über 6000 (gelber Graph). Auch die Pageviews haben sich mehr als verdoppelt. Der PageRank des Blogs ist aber auf 4 geblieben, was ein recht guter Wert ist, wenn man "legal" arbeitet. Einige neue Rewrite-Einstellungen in letzter Zeit könnten evtl. auch der Grund sein, ich rewrite zumindest seit 3-4 Wochen alle Zugriffe immer auf www.admin-blog.com, auch die der anderen Domains linux-log.de und tuxblog.de. Wer weiss ...

Auf jeden Fall vielen Dank an die lieben Besucher, vielleicht schreibt ja mal Einer ein Kommentar - ich freue mich immer wie ein kleines Kind über jeden Kommentar/Trackback zu meinen geistigen Ergüssen;)

Wenn das mit den Zugriffen so weitergeht wirds dann langsam Zeit, dass ich hier Erotikwerbung und Casinobanner schalte.
Oder doch lieber eBay im Zusammenspiel mit AdWords?

Ich weiss, dass viele Admins "Lighty" wegen seiner teilweise höheren Geschwindigkeit dem Apache vorziehen. Leider konnten das meine Tests in der Vergangenheit nicht bestätigen. Aber man muss natürlich mehrere Szenarien probieren. Also gab ich "Lighty" erneut die Chance, sich gegen den Apache zu beweisen. Und zwar auf einem Server, der nur Suchvorschläge für die User ausgibt, ähnlich dem Prinzip auf Google Suggest. Dabei sind in unserem Umfeld ~200 Requests/sec. auf ein PHP-Script zu beantworten, welches einige SQLite Datenbanken abfragt und die Ergebnisse ausgibt. Im Grunde ein sehr einfaches Script, aber die Masse der Anfragen macht hier die Last aus. Peaks von 300-400 Requests/sec. sind durchaus möglich.

Als Umgebung kam ein Debian GNU/Linux 4.0 AMD64 (Kernel 2.6.18-4-amd64) Server mit 2 Stück Dual-Core AMD Opteron(tm) Processor 2216 HE (sagt cat /proc/cpuinfo | grep Opteron | head -n1) @ 2.4 GHz, 4 GByte RAM und 2x WD-Rapor SATA-Platten an einem 3Ware-8000 Controller zum Einsatz. Ich würde das als duchaus leistungsfähiges System bezeichnen.

Zuerst wurde Lighty via apt-get in Version 1.4.13-4etch1 samt xCache (aus Sourcen) und PHP 5.2.0-8+etch5~pu1 (eingebunden via FastCGI) installiert, was aber nicht wirklich gut funktionierte. Denn nach einigen Minuten ging die CPU-Last auf 100% und der Server reagierte nicht mehr wie gewünscht auf Anfragen. Nach einigen Recherchen im Wiki auf der HP von Lighty stieß ich dann auf den wahrscheinlichsten Grund, eine Lösung war leider nicht zu finden. Seltsamerweise trat das Problem in der anschließend von Hand kompilierten Version 1.4.18 nicht mehr auf, so dass der Server ca. 24 Stunden unter Last durchlaufen konnte. Die Load bewegte sich bei 3.x im Schnitt und alle Anfragen wurden schnell beantwortet. Allein die Prozessanzahl war mit mehreren hundert PHP-Prozessen etwas hoch (8 Lighty-Prozesse mit je 64 PHP-Prozessen waren konfiguriert), was aber kein Problem war. Änderungen an der Anzahl der PHP-Prozesse brachten keinerlei Veränderungen an der Last.

Nun konnte der Apache in Version 1.3.34-4.1 (Debian-Paket) samt PHP-Modul libapache-mod-php5 in Version 5.2.0-8+etch5~pu1 zum Einsatz kommen. Statt xCache habe ich hier den eAccelerator v0.9.5.2 aus Sourcen zum Einsatz gebracht. Die Konfiguration gefiel mir sowieso deutlich besser also bei Lighty, schließlich kenne und benutze ich Apache seit vielen Jahren. Auch scheint mir das Finetuning hier etwas genauer möglich zu sein, zumindest was KeepAlive etc. angeht. Das KeepAliveTimeout wurde also auf 5 sec. gesetzt, MinSpareServers auf 15, MaxSpareServers auf 25 - die anderen Werte habe ich nicht verändert. Der Apache läuft nun seit rund 48h im Dauertest und hat eine mittlere Load von 2.x. Alle Anfragen werden ebenfalls problemlos beantwortet. Außerdem ist die Prozessanzahl deutlich geringer, da für PHP als Modul keine FastCGI-Prozesse "gespawnt" werden müssen wir bei Lighty.

In beiden Webservern wurde übrigens alle überflüssigen (also quasi alle ausser fcgi bzw. PHP) Module für den Test deaktiviert. Abschließend kann ich nur sagen, dass ich hier erneut keinen Vorteil für Lighty verbuchen kann und daher Apache auf diesem Server im Einsatz bleibt. Aber vielleicht finde ich ja noch das ideale Szenario für Lighty

In der heutigen Nacht wurde ich von SMS geweckt, die ganz grauenvolle Inhalte hatten. Es war fast so, als wollten meine Server mir etwas sagen ....
Erst kamen diverse NAGIOS-Meldungen, dann habe ich auf den Servern in /var/log und via dmesg eigenartige Logeinträge gefunden.
Zu allem Überfluss fuhr sich einer der Loadbalancer selbst herunter, nachdem er komisches Zeug ins Log geschrieben hat - sowas habe ich noch nie erlebt

Aber seht selbst, hier die "Beweise" in Textform:

NAGIOS sagte:
Notification Type: PROBLEM
Service: Age
Host: robert.klikics.de
Address: 07.12.1980
State: CRITICAL
Date/Time: 2007-12-07 00:00:41
Additional Info: Age of 26 expired, Rob is getting older and older

"dmesg | grep -i rob"auf diversen Servern ergab dann:
Calibrating delay using age timer specific routine.. 27.000008 AgeMIPS (lpj=6383969)
CPU: After generic identify, caps: Rob is too old now, Error-Code: bfebfbff 20100000 00000000 00000000 0004e33d 00000000 00000001 in libAge.so

"tail /var/log/messages" auf einem Loadbalancer schaffte dann Klarheit:
Dec 7 00:22:58 LB1 -- Rob, you're too old for administrating me any longer. I want a sexy, young admin and not a 27 years old grandpa ... --
Dec 7 00:22:58 LB1 -- I'll shutdown me now until you get a young admin for me - bye grandpa! --

Broadcast message from AgeWatch@LB1 (pts/0) (Fri Dec 7 00:22:59 2007):
The system is going down for halt NOW!

Tja was soll ich sagen - man wird auch als Admin nicht jünger!

Ich dachte ja immer, unsere Firmenseite hat mit Peaks von 500 Reqs/sec. schon sehr viele Besucher, aber Wikipedia toppt alles von mir bisher Gesehene mit Peaks von ~50.000 Requests/sec. Das ist einfach nur Wahnsinn. Aus der Jahresgrafik (siehe unten) kann man auch sehr schön sehen, wie der Traffic immer weiter ansteigt - ein Ende scheint nicht in Sicht. Da werden die DB-Server und Squid's wohl ordentlich schwitzen. Aber es wird bald Nachschub geben, von den geplanten 4,6 Mio. Ausgaben im nächsten Jahr sollten laut Heise 2,5 Mio. für Server und deren Administration ausgegeben werden.

Aktuell rennen laut http://de.wikipedia.org/wiki/Wikipedia:Server insgesamt 341 Maschinen für die Wikipedia. Im Verhältnis zu den Usern/Requests eigentlich eine winzige Zahl. Mit gutem Caching kann man offenbar sehr viel erreichen. Google hat da schnell mal das Tausendfache an Servern, was wahrscheinlich nicht einmal reicht. Laut einem Voting liegt deren Serverbestand um die 1,2 Mio - Genaues weiß man allerdings nicht. Ich tippe auf ~500.000, da ich diese Zahl schon öfter gelesen habe

Hier noch die RRD-Graphs der Wikipedia-Requests:

Hier mal ein lustiger Beitrag, der meiner Meinung nach ganz nett die diversen Betriebssysteme/Gesinnungen darstellt (sorry, das Thumbnail ist ein wenig klein, da das Bild so breit ist):


        ^^^^^^^^^^ ----> da auf das Pic klicken (hey, das ist das erste Mal, dass ich "^" produktiv einsetze, außer in RegExp oder Chat-Sessions *g*)

Besonders gut gefällt mir ja der Vista-Typ, aber natürlich sind auch GNU und Linux irgendwie treffend dargestellt

Hoffentlich bekomme ich für das Bild nicht wieder eine Abmahnung bzgl. Urheberrechtsverstoß samt Forderungen in astronomischen Höhen wie damals vor einem Jahr für diesen bekloppten 16-Bit Rechner, der aus einem Bierkasten gebastelt wurde! Solltest Du, lieber unbekannter geistiger Erzeuger dieses coolen Bildes, ein Problem mit der Darstellung hier haben, lass es mich bitte wissen. Vorzugsweise per Mail und nicht, wie der andere Experte damals, per Brief von einem bekannten Anwalt. Vielen Dank

Seit ca. einem Monat läuft die aktuelle Spendenaktion für die Wikipedia. Ich habe selbst schon bemerkt, dass das People-Meter sich nur schleppend weiterentwickelt und ging davon aus, dass deutlich zu wenige Spenden eingegangen sind. Und tatsächlich sind bisher laut heise.de erst 900.000 Dollar zusammengekommen. Bei zig mio. Besuchern am Tag sollte da doch etwas mehr drin sein, oder? Ich habe auf jeden Fall schon meinen Teil gespendet, da ich quasi täglich die Wikipedia nutze und sie einfach super ist.

Den Kritikern gebe ich allerdings auch Recht, dass die geplanten Kosten von 4.6 Millionen Dollar für nächstes Jahr etwas hoch erscheinen. Wenn ich da Posten wie "Unternehmensberatung" etc. lese frage ich mich allerdings auch, ob das Ganze nicht ein wenig zu "fett" wird. Ich bin durchaus der Meinung, man sollte sich auf auf die Website samt Hostingkosten etc. beschränken, dann würden die 900.000 wahrscheinlich schon ausreichen und die Seite selbst könnte wie gewohnt werbefrei bleiben. Wofür das Geld konkret gebraucht wird etc. lässt sich im Fundraising Blog nachlesen, welches extra wegen der Spendenflaute eingerichtet wurde.

Trotzdem sollte jeder, der die Wikipedia oft oder gar täglich nutzt, ruhig mal 10 EUR locker machen (armen Studenten etc. sei mal verziehen, wenn sie es nicht tun ). Dafür lieber die GEZ sparen oder so, die Wikipedia hat für meinen Geschmack zumindest mehr Wert als ard.de und zdf.de zusammen

Mit einem Schmunzeln las ich kürzlich den Blogeintrag "Google as a password cracker" bzw. den Artikel dazu auf heise.de. Da hat also Jemand zufällig einen MD5-Hash "reverse lookup'en" können, indem er ihn bei Google eingegeben hat. Er kam dann darauf, dass der Hash "20f1aeb7819d7858684c898d1e98c1bb" aus dem Wort "Anthony" entstand. Inzwischen oder evtl auch schon viel länger kann man das übrigens auch mit dem "reverse engineer" auf md5.rednoize.com herausbekommen - ebenso derzeit 48.424.776 weitere Hashes. Eine wirklich interessante Website

Einmal mehr sieht man daran, dass normales MD5-Hashing nicht (mehr) ausreicht, um Passwörter sicher zu speichern. Da sollte man wenigstens mit einem Salt oder besser gleich mit SHA1 arbeiten, um die Passwörter sicher in irgendwelchen Datenbanken etc. zu speichern. Für den Endanwender bleibt es natürlich dabei, ein möglichst komplexes Passwort zu verwenden. "Anthony" gehört übrigens definitiv nicht dazu.

Linux selbst eignet sich übrigens im Zusammenspiel mit PERL auch perfekt zum "Cracken" von MD5's, dabei kann man sich direkt das Dictionary mit seinen derzeit 98.569 gängien Worten (auf meinem Ubuntu-Laptop eben nachgezählt) unter /usr/share/dict/words zu nutze machen:

perl '-MDigest::MD5(md5_hex)' -ne 'chomp; print "$_\n" if md5_hex($_)
eq "20f1aeb7819d7858684c898d1e98c1bb"' /usr/share/dict/words

Obiges Kommando gibt, wie sollte es anders sein, "Anthony" zurück
Achja, und die Bash selbst kann das natürlich auch, wenn auch deutlich langsamer:

for i in `cat /usr/share/dict/words`; do echo -n $i | md5sum | grep 20f1aeb7819d7858684c898d1e98c1bb && echo -n $i; done

PS: Wer e7c76cef847afb15ad91d9fa29321509 "knackt", kann sich einen Keks nehmen