Administrator's Blog

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!