So finden Hacker heraus, welches CMS Sie nutzen

Sie betreiben eine eigene Website, die mit einem Content Management System gepflegt wird? Dann gehören Sie zu einer Zielgruppe, die für Hacker grundsätzlich interessant ist. In machen Content Management System werden immer mal wieder Sicherheitslücken entdeckt oder man versucht einen Einbruch mit einer Brute Force Attacke, also dem einfach Ausprobieren gängiger Benutzername-Passwort-Kombinationen.

Falls Ihr Server oder das CMS mitprotokolliert, welche Anfragen eingehen, werden Sie vielleicht schon entdeckt haben, dass ab und an, zirka einmal wöchentlich HTTP-Anfragen an folgende URLs gerichtet werden. Diese URLs haben wir aus einer Testinstallation mit einer PageRank-2-Domain gewonnen, die wir ein wenig bekannt gemacht und verlinkt haben:
blogs/load/recent
member/join.php
join.php
signup.php
forum/member/register
index.php/forums/member/register
member/register
signup
register.php
registration_rules.asp?FID=0
index.php?option=com_registration&task=register
index.php?option=com_registration&task=register
forums/index.php?action=registernew
index.php?action=registernew
index.php?do=/user/register/
signup
dynamic/?q=node/
dynamic/?q=node/10

Ein Aufruf ohne 404 Fehler gibt Aufschluss über das CMS

Mit diesen URLs, die probehalber einfach an Ihre Domain angehängt werden, lässt sich herausfinden, welches CMS hier am Werk ist und welche Adresse der Login ins Administrationssystem hat.
Liefert zum Beispiel http://www.irgendeine-domain.de/dynamic/?q=node/10 keinen 404 Fehler, weiß man, dass mit großer Wahrscheinlichkeit hier Drupal eingesetzt wird. Nun kann der Angreifer überlegen, ob er eine Brute Force Attacke startet, um in das System einzudringen.

Gefahrenquelle Probeinstallationen

Fatalerweise gibt es recht viele Probeinstallationen von Joomla, Drupal oder anderen Systemen, mit denen der Administrator die Software einfach mal ausprobieren wollte und sich auch kaum Mühe gemacht hat, ein besonders schweres Passwort zu definieren. Auch der Zugangsname ist dann oft „admin“ oder „administrator“. Die Hacker versuchen so, Serverkapazität zu bündeln, um wiederum vom übernommenen Server weitere Attacken zu starten.

Wie schützt man sich vor solchen „Scans“?

Es ist kaum möglich, jemanden davon abzuhalten, probeweise eine typische URL, die ins Backend eines CMS führt, aufzurufen. Manchmal liegen die Zugangsmodule tatsächlich in einem eigenen Verzeichnis, so dass man einen extra Schutz mit .htaccess realisieren könnte. Bei vielen CMS ist dies aber gar nicht möglich. Hier kann man tatsächlich nur raten, hinreichend komplexe Nutzernamen-Passwort-Kombinationen zu wählen und das CMS immer auf dem aktuellen Stand zu halten.
Wollte man per htaccess einen IP Bereich sperren, den die Angreifer für gewöhnlich benutzen, müsste man den IP-Bereich kennen. Unter Umständen erkennt man in den Logfiles einige IP-Auffälligkeiten. goneo Kunden finden den Zugriff auf die Logfiles im Kundencenter.
Die Suche nach Angreifer-IPs ist sehr mühsam. Praktikabel ist das nicht wirklich, da die Angriffe aus allen möglichen geographischen Regionen kommen, meist von bereits übernommenen Servern.
Einen schönen Service liefert das CMS ImpressPages: Bei jedem Aufruf einer URL, die nicht existiert, schickt das System eine Warnmeldung per E-Mail an den Administrator. So bekommen Sie wenigstens den Zeitpunkt des Scans mit. Im Logfile finden Sie dann eventuell eine sperrwürdige IP-Adresse.

IP-Sperre per .htaccess – Direktive

Nur wenn sich die Anfragen auf einige wenige IP-Adressabschnitte einengen lassen (zum Beispiel, weil diese andauernd versuchen zuzugreifen, ist eine Sperre per .htaccess sinnvoll. Sie können dann in die .htaccess-Datei die Direktive „deny from [IP]“ eintragen, wobei [IP] hier für eine konkrete IP-Adresse steht.
Sie können auch mehrere deny-from Direktiven nacheinander anführen, wobei Sie dem Server noch mitteilen sollten, in welcher Reihenfolge er die Anweisungen abarbeiten soll. Also beispielsweise mit „order allow, deny“ die Reihenfolge festlegen, in der nächsten Zeile dann mit „deny from [IP]“ den Ausschluss definieren und schließlich mit “ allow from all“ festlegen, dass grundsätzlich alle IP-Adressen erlaubt sind.