Schwer ist es auch im ausgesperrten Zustand nach Lösungen für Probleme zu suchen, die angeblich im Inneren zu finden wären. In einem Nebensatz erwähnt der Vermieter, dass er auch eine etwas teuerere Mietswohnung im Angebot hätte, die u.U. die Lösung für dieses Problem wäre.

Die Geschichte ist nicht frei erfunden. Sie spielt aber auch nicht in der Realität, sondern in der virtuellen Welt des Internets. Bei dem Vermieter handelt es sich um die Firma Hosteurope, die u.a. so genannte Webhostingpakete vermietet. Die zu meinem Paket gehörenden 7 Domains, z.B. www.beautifulda.de und www.fuldaecho.de wurden vor Kurzem gesperrt, da eine Überlastung vorläge.

Es folgt ein Rückblick der letzten 12 Tage. Wer es genau wissen möchte, kann auch den anonymisierten Mailwechsel mit Hosteurope hier nachlesen.

1. Tag: Donnerstag, 16. November

Am Donnerstag, 16. November ca. gegen 13.00 Uhr bemerke ich, dass keine meiner Domains in meinem Webpack bei Hosteurope funktionieren. Auf telefonisches Nachfragen, ca. gegen 14.00 Uhr erhalte ich die Auskunft, dass auf dem Server wohl „nur der Apache einmal neu gestartet werden müsse“.

Um 15.23 Uhr erhalte ich eine Mail, die mich darauf hinweist, dass eine „Überlastung“ vorliegt und das Webpack deshalb gesperrt wurde. Der enthaltene Hinweis „vielleicht wechseln Sie auch auf einen VPS“ klingt wie Erpressung, wenn gerade alle sieben Domains, die ich in diesem Paket habe, ohne Vorwarnung abgeschaltet wurden.

In meiner sehr freundlichen Antwort (kurz vor 16.00 Uhr) zeige ich mich verwundert, dass keine Ankündigung erfolgte. Ich verweise auch auf das Problem, dass ich keinerlei Ansatzpunkt besitze, wie ich die Last reduzieren könnte.

Das freundliche Nachfragen meinerseits wird gegen 17.00 Uhr mit einem harschen Hinweis auf §5 der von mir akzeptierten AGBs beantwortet. Der Sachbearbeiter zitiert sogar den passenden Gummiparagraphen, nachdem der Webhoster eine Sperrung immer vornehmen darf, sofern „eine übermäßige Inanspruchnahme der Einrichtungen des Providers“ vorliegt. Mit dem Hinweis „folgende Einträge in unseren Logs haben zur Sperrung Ihres Webpack geführt“ erhalte ich einen unkommentierten Logfile-Auszug, ohne jeden zeitlichen Bezug und ohne irgendeinen Hinweis auf die Bedeutung der Spalten.

Immerhin sind IP-Adressen in der Logdatei enthalten. Das Webfrontend zum Abrufen der Logfiles funktioniert trotz der Sperrung. So kann ich sehen, dass am gleichen Tag tatsächlich ein Angriff auf eine Komponente des CMS Joomla erfolgte.

Ich ging daher davon aus, dass der Hosteurope-Support recht hätte, schrieb in meiner Antwort um 18.00 Uhr sogar, dass es in diesem Fall meine Schuld sei und bedankte mich. Ich bat um eine schnelle Freischaltung und gab an, dass ich die betreffenden Domains deaktivieren würde.

Was ich zu diesem Zeitpunkt noch nicht wusste. Es hatte zwar einige hundert Zugriffe auf das Verzeichnis der Joomla-Komponente gegeben, doch liefen fast alle Zugriffe ins Leere (404-Fehler). Die restlichen Zugriffe waren überschaubar. Zusammen mit dem Autor der Komponente überprüfte ich die vermutete Sicherheitslücke. Ergebnis nach 4-5 Stunden intensiven Suchens: es gab keine Sicherheitslücke!

Immerhin wurde das Paket gegen 18.30 Uhr freigeschaltet.

3. Tag: Samstag, 18. November

Frühmorgens wurde mir per Mail mitgeteilt, dass das Paket nun wieder freigeschaltet wäre. Außerdem wurde mir mitgeteilt, dass mir eine Textdatei bereitgestellt wurde, die potenziell „unsichere Dateien“ enthielte. Leider konnte ich die Datei aufgrund falsch gesetzter Zugriffsrechte (Eigentümer „root“) nicht lesen.

Um 9.00 Uhr teilte ich dies dem Support mit.

5. Tag: Montag, 20. November

Nun war ich mir sicher, dass keine Joomla-Sicherheitslücke bestand. Dies teilte ich dem Support gegen 20.00 Uhr per Mail mit und fragte nach dem Grund des gesperrten Webpacks (z.B. zuviel Hauptspeicher und/oder CPU-Verbrauch).

7. Tag: Mittwoch, 22. November

Der Support teilte mir nun mit, dass die Zugriffsrechte der Datei angepasst wurden, so dass ich nun endlich einen Blick darauf werfen konnte. Der Inhalt war eine Liste der Dateien, die nicht per FTP hochgeladen wurden, sondern direkt auf der Webpräsenz, z.B. via PHP oder CGI Skripte erzeugt wurden. Da ich via PHP-Shell auf dem Webpräsenz arbeite, besitzen fast alle Dateien (22000 an der Zahl) den Eigentümer nobody.

Wie Hohn klang der folgende Satz in der gleichen Mail in meinen Ohren:

„Zum Zeitpunkt der Überlasstung war Speicher und CPU überlasstet genaueres lässt sich aber nicht sagen denn dies wird nicht geloggt.“

Mehr als eine pauschale Aussage war also nicht drin. Vor allem der Zeitpunkt wurde immer noch nicht genannt.

Dies monierte ich in meiner Mail um 13.30 Uhr am gleichen Tag: Der Support antwortete:

„die Angabe der CPU-Auslastung ist für Sie wahrscheinlich wenig hilfreich, da Ihnen die Gesamtauslastung der Server-CPU nicht bekannt ist.

Zum Zeitpunkt der Überlastung haben unsere Techniker die Logs erstellt, welche wir Ihnen zur Verfügung gestellt haben.

Eine exakte Zeitangabe ist demnach nicht mehr notwendig, da die betreffenden Aufrufe Ihres Webpack Ihnen bereits mitgeteilt wurden.“

Die genaue zeitliche Zuordnung, nämlich in Form einer Uhrzeit, wird mir erneut verweigert. Eine Handlungsaufforderung oder ein Hinweis auf eine neuerliche starke Beanspruchung des Webpacks gab es nicht.

9. Tag: Freitag, 24. November

Ich erhalte eine Erinnerung der Mail vom Mittwoch.

12. Tag: Montag, 27. November

Ich werde erneut auf die nichtssagende Mail vom Mittwoch hingewiesen. Gleichzeitig werde ich darauf aufmerksam gemacht, dass mein Paket erneut gesperrt werden würde, wenn ich bis zum 04.12.2006 nicht auf diese Mail reagieren würde.

Als Antwort schicke ich diese Zusammenfassung (1.-12. Tag) und frage „Worauf erwarten Sie eine Antwort von mir?“ Wenige Stunden später die Antwort des Hosteurope-Support:

„Teilen Sie uns bitte mit, wie Sie solche Überlastungen in Zukunft verhindern werden. Unsere Empfehlung wäre ein regelmäßiges Update Ihres CMS.“

Wie bitte? Der Nachweis, dass eine Überlastung erfolgte konnte durch Hosteurope nicht erbracht werden. Offenbar war das einzige Ziel der Aktion also, den Kunden zum Update des CMS oder zum Wechsel auf das teuerere VPS zu bewegen.

Schulnotenprinzip:

Anhand einer Signatur in der Datei „version.php“ des Joomla-CMS kann Hosteurope scheinbar(!) feststellen, welche Joomla-Installation angreifbar ist. Doch Joomla-Sicherheit kann auch oft auf anderem Wege - in diesem Falle z.B. durch einen zusätzlichen (htaccess-)Passwortschutz - erreicht werden. Dies hatte ich schon vor Wochen erledigt, doch der Support hatte offensichtlich einen Tunnelblick und konnte nur die Versionsnummer 1.0.9 (aktuell 1.0.11) sehen. Über die tatsächliche Sicherheit verrät die Updaterei nämlich sehr wenig, diese hängt vielmehr von jeder einzelnen Komponente und deren Konfiguration ab.

Der Autor dieser Zeilen ist freiberuflich tätig im Bereich Linuxschulungen und Webconsulting und ist Autor des Buches „SuSE-Linux Systemadministration“ (2. Auflage 2004, MITP-Verlag, ISBN 3-8266-1357-0).

Nur registrierte Benutzer können Kommentare schreiben.
Bitte melden Sie sich an oder registrieren Sie sich.

Powered by AkoComment 2.0!