Web-Server schützen

[vgwort line=“2″ server=“vg05″ openid=“6d7276dd823443d4b33801faa9239154″]

Seit einiger Zeit beobachte ich verstärkte Zugriffe auf den Artikel Freundliche und unfreundliche Crawler. In den Monaten Februar und März hat er sich an die Spitze der abgerufenen Seiten gesetzt. Seit Anfang Mai geht jeder 4 Aufruf auf diese Seite; Zeit, der Ursache auf den Grund zu gehen.

Die Auswertung des Log zeigt, dass ca. 2899 IP-Adressen 21442 Zugriffe auf die Seite versucht haben. Grundsätzlich muss ein Host um eine WordPress-Seite anzuzeigen auf mehrere Seiten zugreifen, doch die meisten Hosts greifen nur auf diese Seite zu. Die nachfolgende Grafik zeigt, wie viel IP-Adressen wie oft zugegriffen haben. (Die Skalierung ist etwas ungewöhnlich, erfüllt aber meinen Zweck.)

Grafik IP-Adressen / Zugriffe
Auswertung der Anzahl der Hosts nach getätigten Zugriffen auf einen Artikel.

Ein fast die Hälfte der Rechner greift nur einmal auf die Seite zu. Das geht in erster Näherung in Ordnung. Warum sollten sie es mehrfach tun? Das von IP-Adressen mehrfach eine Seite angefordert wird, ist auch nicht unbedingt ungewöhnlich, denn hinter einer Adresse könnte der Proxy eines Providers stehen. Aber es gibt auch Host die mehr als 200 mal auf die Seite zugegriffen haben.

IP-Adresse Zugriffe
113.212.68.a 431
113.212.70.b 255
176.31.182.a 239
176.31.182.b 221
176.31.182.c 246
176.31.182.d 210
192.95.59.a 265
199.59.56.a 559
216.151.130.a 1048
37.59.179.a 220
5.135.189.a 634
80.93.217.a 782
94.23.230.a 243

Gleichzeitig gibt es aus einigen Sub-Netzen (5.135.0.0/16) gehäufte Zugriffe im unteren Bereich. Bei riskyinternet.com sind einige dieser Adressen als unerwünschte Zeitgenossen bekannt. Die Frage ist: Was wollen die Kameraden genau mit dieser Seite / diesem Artikel?

Sperren des Zugriffes

Zuerst würde ich den Kameraden den Spaß gerne verderben. Das Sperren einzelner Adressen ist bei der Menge nicht praktikabel. Wenn ich Adressen sperren möchte, dann müsste ich ganze Netzbereiche sperren. Das lohnt aber nur, wenn aus diesen Bereichen auch genug Zugriffe erfolgen. Die Medaille hat auch eine zweite Seite. Erwünschte Zugriffe würden ebenfalls gesperrt. Es wäre schön, wenn sich noch ein anderes Kriterium finden lassen könnte.

User Agent String

Unter den User Agent (UA) Strings findet sich das folgende Muster:

Mozilla/5.0 <a href=\http://example.com/somepage/\">Some thing</a> (Windows NT 5.1; U; en) Presto/2.10.229 Version/11.60"

Damit kann ich etwas anfangen. Hier versucht sich jemand mit Referrer Spam. Nun, meine Webalizer Statistiken lagern auf einem geschützten virtuellen Host. Damit laufen die Bemühungen der Kameraden hier Referrer ins Leere. Aber diese UA sind sinnlos und ein Sperren oder Umlenken der Zugriffe richtet keinen Schaden an. Dies ist ein Fall für Apache2 mod_rewrite. Und so ergänze ich die .htaccess Datei um die Zeilen:


RewriteCond %{HTTP_USER_AGENT} .*\<a\ href=.*
RewriteRule ^(.*)$ http://localhost/ [R,L]

Das Kriterium ist nicht schlecht, denn es trifft auch Zugriffe auf andere Seiten. Ein Test ergibt: Dieses Kriterium traf 1943 Zugriffe; also nur ca. 9%. Damit ist es leider nicht sehr effizient.

Eine weitere Analyse der UA ist also erforderlich. Die „verwendeten“ Browser sind relativ alt. Von Firefox werden nur die fünf Versionen verwendet: 3.5, 4.0b7pre, 5.0, , 5.0.1 , 5.02. Damit kann ich immerhin über 5.000 Zugriffe oder 25% abdecken. Also ergänze ich den Eintrag in der .htaccess um eine weitere Zeile.


RewriteCond %{HTTP_USER_AGENT} .*Firefox/[123456789]\..* [OR]
RewriteCond %{HTTP_USER_AGENT} .*\<a\ href=.*
RewriteRule ^(.*)$ http://localhost/ [R,L]

Nun könnte ich den Microsoft Internet Explorer (MSIE) 6.0 einschließen, damit hätte ich weitere 5.000 Zugriffe gesperrt. Eigentlich keine schlechte Idee. Wer jetzt noch mit dem MSIE 6.0 unterwegs ist, der gehört geschlagen. Mit dem MSIE 7.0 wird es schwieriger. Ich kenne große Organisationen, die verwenden noch den MSIE 7.0 oder 8.0.

Sehr viel geht auch über den Opera/9.80. Aktuell ist 12.15 für Linux. Da könnte ich noch weitere Treffer einschließen. Dies ist jedoch ein Irrtum. Die Version steht am Ende und wenn ich die Version 11.60 abgelehnt hätte, dann hätten sich die Ablehnungen nur um 1 erhöht, denn dies korrespondiert mit der Regel .*\<a\ href=.*.

So, genug für heute. Morgen gibt es eine Ergänzung zu den Angriffen auf die wp-login.php.