Ständig wiederholte Zugriffe blockierbar?

[Ingo Turski]

Hi,
beim Durchstöbern meiner Logs bin ich doch glatt erschrocken...
Da kommt doch ein Firefox/0.8 mit aktiviertem Javascript und gemeldeten 1280px Bildschirmbreite aus der Schweiz über bluewin.ch auf meine Seite, spielt ein bisschen mit dem Styleswitcher meines CSS-Layouts und geht dann über meine guided tour durch meine Tips. Soweit sogut.

Dann startet er "WebZIP/3.71 (http://www.spidersoft.com)" (offensichtlich eine sehr alte Version) und dieses Programm beginnt, meine Seiten komplett zu spidern. Ansich normal... aber als das Programm dann auf einen 401 stößt, fängt es an zu spinnen. Es fordert von nun an im Sekundentakt die Resource /web/ an und bekommt die 8kb auch jede Sekunde neu mit 200 ausgeliefert.
Der User scheint von all dem nichts mitzubekommen, denn das Spiel lief doch tatsächlich fast 48 Stunden nonstop. :-(
Zwischendurch wechselte dreimal die IP (wohl Zwangstrennung nach 24 Std.), was dann jeweils ca. 10 Sek. "Ruhe" brachte.

Nun würde mich mal interessieren, ob und welche Möglichkeiten es gibt, solchen offensichtlich unsinnigen Traffic zu blockieren.

freundliche Grüße
Ingo

[Christoph Schnauß]

hallo Ingo,

Nun würde mich mal interessieren, ob und welche Möglichkeiten es gibt, solchen offensichtlich unsinnigen Traffic zu blockieren.

Interessante Fragestellung. Meines Wissens ist eine solche "selektive Blockierung" nicht machbar. Du willst ihm ja den Besuch und auch das "Spidern" durchaus noch erlauben und wirst nur (zu recht) grantig, wenn er auf einen 401er hin zu spinnen anfängt. Mit allow/deny könntest du den user vollständig sperren  -  naja, dann kommt er eben durch ein anderes Türchen wieder rein.

Es gäbe die etwas aufwendige Möglichkeit, alle, die je einen 401er provoziert haben, auszuschließen. Das ist aber nicht besonders sinnvoll (ich habe zum Beispiel bei dir auch schonmal einen 401er bekommen, aber ich wäre ziemlich sauer, wenn du mich "bannen" würdest).

Eine Möglichkeit besteht eventuell noch darin, mal alles, was BrwserMatch kann, auszuloten. Schließlich gehts ja darum, dieses doofe WebZIP/3.71 auszuschließen  -  aber da muß ich mit Mutmaßungen aufwarten, praktische Erfahrungen dazu habe ich auch nicht.

Es wird dir kaum etwas andres übrigbleiben, als diesen user insgesamt zu sperren  -  aber: ich würde mich freuen, wenn ich mich mit diesem Hinweis irren sollte und jemand andres doch noch eine Möglichkeit für eine "selektive Sperrung" weiß.

Grüße aus Berlin

Christoph S.

[Tom]

Hello und guten Morgen Christoph,

Es gäbe die etwas aufwendige Möglichkeit, alle, die je einen 401er provoziert haben, auszuschließen. Das ist aber nicht besonders sinnvoll (ich habe zum Beispiel bei dir auch schonmal einen 401er bekommen, aber ich wäre ziemlich sauer, wenn du mich "bannen" würdest).

Könntest Du mir mal bitte ausführlich erklären, wie Du das machst? ;-)

@Ingo:
Du schreibst ja selber, dass die IP manchmal gewechselt hat.
Die könnte schließlich auch noch viel häufiger wechseln.
Wie willst Du den User also erkennen?

Hast Du vielleicht mit Session und Cookie gearbeitet und der Fehler liegt nachher in deinem eignen Programm, weil da ein "Redirect-Kurzschluss" eingebaut ist?

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Christoph Schnauß]

hallo Tom,

Es gäbe die etwas aufwendige Möglichkeit, alle, die je einen 401er provoziert haben, auszuschließen
Könntest Du mir mal bitte ausführlich erklären, wie Du das machst? ;-)

In Kurzform und nur als "Ideenskizze": log auslesen und nach 401ern suchen. Per Script die gefundenen IP-Adressen und/oder User-Agents in eine .htaccess schreiben und ausschließen. Nu sag mir nicht, daß du darauf nicht selber hättest kommen können ;-)

Grüße aus Berlin

Christoph S.

[Tom]

Hello,

Es gäbe die etwas aufwendige Möglichkeit, alle, die je einen 401er provoziert haben, auszuschließen
Könntest Du mir mal bitte ausführlich erklären, wie Du das machst? ;-)

In Kurzform und nur als "Ideenskizze": log auslesen und nach 401ern suchen. Per Script die gefundenen IP-Adressen und/oder User-Agents in eine .htaccess schreiben und ausschließen. Nu sag mir nicht, daß du darauf nicht selber hättest kommen können ;-)

Und wen hast Du da ausgeschlossen?

Ich will es mal so sagen: Ein Fußballfan randaliert im Stadion. Die Ordner wollen ihm Hausverbot erteilen. Da er seinen Ausweis nicht dabei hat, aber eine Straßenbahnfahrkarte der Linie 3 schreiben die Ordner nun ans Tor: Der Besucher, der mit der Linie 3 kommt, hat Hausverbot.

_darauf_ müsstest Du doch auch noch nach zwei des guten Flaschen Holunderweines _selber_ kommen *gg*

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Ingo Turski]

Hi,

Du schreibst ja selber, dass die IP manchmal gewechselt hat.
Die könnte schließlich auch noch viel häufiger wechseln.
Wie willst Du den User also erkennen?

darum geht's mir ja gar nicht, insofern habt ihr mich leider mißverstanden. Auch nicht um den 401 - das war nur offensichtlich der Auslöser, den ich übrigens hier mit einem Beispiellink (allerdings nur über Javascript!) selbst provoziere.
Vielmehr darum, solche zigfach wiederholten gleichen - sprich absolut identischen - Zugriffe blockieren.

Hast Du vielleicht mit Session und Cookie gearbeitet und der Fehler liegt nachher in deinem eignen Programm, weil da ein "Redirect-Kurzschluss" eingebaut ist?

Nein. Es handelt sich um statische HTML-Seiten.

freundliche Grüße
Ingo

[Tom]

Hello,

Hast Du vielleicht mit Session und Cookie gearbeitet und der Fehler liegt nachher in deinem eignen Programm, weil da ein "Redirect-Kurzschluss" eingebaut ist?
Nein. Es handelt sich um statische HTML-Seiten.

Also auch ohne JavaScript und ohne Meta-Refreshs?
Denn auch damit kann man bekanntlich Weiterleitungen verursachen!

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Ingo Turski]

Hi,

Also auch ohne JavaScript und ohne Meta-Refreshs?
Denn auch damit kann man bekanntlich Weiterleitungen verursachen!

Javascript verwende ich zwar, aber daran kann es nicht gelegen haben. Und Meta Refreshs nutze ich nicht.

freundliche Grüße
Ingo

[Anonymous]

Nun würde mich mal interessieren, ob und welche Möglichkeiten es gibt, solchen offensichtlich unsinnigen Traffic zu blockieren.

  
SetEnvIf User-Agent ^WebZIP/3\.71 kill_him  
Order Allow,Deny  
Deny from env=kill_him  

Ansonsten geht das nicht ohne größeren technischen Aufwand.

[Ingo Turski]

Hi,

SetEnvIf User-Agent ^WebZIP/3.71 kill_him
Order Allow,Deny
Deny from env=kill_him

das wäre jetzt für diesen einen UA (obwohl der String ja noch nicht komplett wäre, oder?)  
Aber der hat ja inzwischen Ruhe gegeben. Nur könnte sowas ja theoretisch auch bei anderen Programmen passieren.  
  
freundliche Grüße  
Ingo

-- 
[[barrierefreie Webseitenerstellung](http://www.1ngo.de/web/) » [Suchmaschinenoptimierung](http://www.1ngo.de/web/seo.html) | [em?](http://www.1ngo.de/web/em.html)] ([Tanzschritte gesucht?](http://www.1ngo.de/tanz/);-)

[Anonymous]

das wäre jetzt für diesen einen UA (obwohl der String ja noch nicht komplett wäre, oder?)

Ja. Und der String ist nicht komplett, aber komplett genug.

Aber der hat ja inzwischen Ruhe gegeben. Nur könnte sowas ja theoretisch auch bei anderen Programmen passieren.

Wie gesagt. Ohne größeren technischen Aufwand ist da nichts zu machen. Da gibt es nur beobachten und dann entsprechend handeln.

[Tom]

Hello,

SetEnvIf User-Agent ^WebZIP/3.71 kill_him

Wo findet man denn etwas darüber?
Ich habe eben die Apache 2.0 - Doku so gut es Ging durchforstet, aber nur SetHandler gefunden.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Anonymous]

SetEnvIf User-Agent ^WebZIP/3.71 kill_him

Wo findet man denn etwas darüber?

http://httpd.apache.org/docs-2.0/mod/mod_setenvif.html.en#setenvif

[der Sperre]

Dann startet er "WebZIP/3.71 (http://www.spidersoft.com)"

Nun würde mich mal interessieren, ob und welche Möglichkeiten es gibt, solchen offensichtlich unsinnigen Traffic zu blockieren.

Falls der Webserver nichts zur Verfügung stellt (mod_throttle?), nur indem unerwünschte Software von vornherein erkannt und die dazugehörige IP gesperrt wird. Die Sperre der IP ist nötig, da ganz besonders Schlaue nach dem ersten Fehlschlagen ihre Downloadsoftware inkognito nochmals starten.

Die Lösung erfordert noch regelmäßiges manuelles Aufräumen der .htaccess.

/.htaccess
----------

ErrorDocument 403 /fehler/403.shtml

Order Deny,Allow
Deny from env=blockagent
Deny from env=blockaddress

SetEnvIfNoCase User-Agent "Plucker" blockagent
SetEnvIfNoCase User-Agent "^Java" blockagent
SetEnvIfNoCase User-Agent "^Wget" blockagent
SetEnvIfNoCase User-Agent "HTTrack" blockagent
SetEnvIfNoCase User-Agent "^WebZIP" blockagent

/fehler/403.shtml
-----------------

Zugriff verweigert blabla

<!--#if expr="$blockagent$blockaddress" -->
<!--#exec cmd="/bin/bash blockem.sh" -->
<!--#endif -->

/fehler/blockem.sh
------------------

#! /bin/bash

if [ -n "$REMOTE_ADDR" ]
then
    if [ -z "$blockaddress" ]
    then
        echo >> ../.htaccess -e "\n# date --rfc-822\n# URL: $REDIRECT_URL\n# Domain: dig +short -x $REMOTE\_ADDR\n# Agent: $HTTP_USER_AGENT\nSetEnvIf Remote_Addr $REMOTE_ADDR blockaddress"
        set | grep "^HTTP_" | sed "s/^/# /" >> ../.htaccess
    fi

i=20;
    while ((i--))
    do
        sleep 20
        read < /dev/random -n 1 byte
        echo -n $byte
    done
fi

Bei erstem Zugriff wird $blockagent gesetzt, was in blockem.sh dazu führt, das die IP und einige Parameter in die .htaccess als Sperre (SetEnvIf Remote_Addr $REMOTE_ADDR blockaddress) eingefügt wird. Alle folgenden Zugriffe setzen daraufhin (auch) $blockaddress, so dass blockem.sh zwar noch angefahren und die Warteschleife ausgelöst, aber nicht mehr (if [ -z "$blockaddress" ]) die .htaccess gefüllt wird.

Statt den Bösewicht in eine fast siebenminütige Warteschleife zu schicken, in der er nur 400 Bytes Müll erhält, und ihn damit zur Weißglut zu treiben, lässt sich das Spiel auch rigoros mit "iptables -A INPUT --source $REMOTE_ADDR -j DROP" spielen (sofern die Rechte es zulassen).

[XaraX]

Hallo Ingo,

bei meinen Versuchen mit den apachen 2.x mit worker.c bin ich derzeit auf so manche Dinge gestoßen, die mir wie ein Bug erscheinen, aber sich für Deine Zwecke ausnutzen lassen. U. a. neu in der Serverkonfiguration sind die Direktiven RLimitCPU, RLimitMEM und RLimitNPROC.

Ganz speziell dürfte es am einfachsten sein RLimitMEM zu nutzen. Die Direktive ist mit den .htaccess-Dateien verzeichnisweise konfigurierbar. Dabei würde ich, ähnlich wie "der Sperre" es vorschlug, in Deinem Fall auf ein entsprechendes 403-ErrorDocument zurückgreifen z. B. ein PHP-Script. Definiere in diesem Script eine Variable deren Größe über dem angegebenen (der selbstreden natürlich sehr niedrig angegeben wurde) Wert von RLimitMEM liegt.

Nicht getestet aber wert einmal auszuprobieren wäre auch, die SetInputFilter-Direktive in Verbindung mit einem Script zu verwenden, daß auf abstrakte Probleme dieser Art reagieren kann und notfalls den Wert von RLimitMEM "überläd".

Diese Direktiven stehen auch dem apachen > 1.2.x zur Verfügung. Leider habe ich dort noch keinerlei Erfahrungen sammeln können.

Ergebnis:

Der Server (mit worker.c) reagiert derzeit bei einem Überschreiten des Memorylimits durch response-loses Schließen der TCP-Verbindung zum Client. Probiere einfach aus, ob dies auch der Fall bei prefork.c ist. Wenn ja, dann sollte dies die traffic-schonenste Möglichkeit sein.

Gruß aus Berlin!
eddi

[Anonymous]

U. a. neu in der Serverkonfiguration sind die Direktiven RLimitCPU, RLimitMEM und RLimitNPROC.

Nein. Die gibt es seit Apache 1.2:

http://httpd.apache.org/docs/mod/core.html.en#rlimitcpu
http://httpd.apache.org/docs/mod/core.html.en#rlimitmem
http://httpd.apache.org/docs/mod/core.html.en#rlimitnproc

[XaraX]

Hallo nicht nur Anonymes, sondern auch Grußloses,

U. a. neu in der Serverkonfiguration sind die Direktiven

Diese Direktiven stehen auch dem apachen > 1.2.x zur Verfügung. Leider habe ich dort noch keinerlei Erfahrungen sammeln können.

Nein. Die gibt es seit Apache 1.2: [...]

Ich präzisiere mich, daß die Konfiguration mittels .htaccess und innerhalb von <Directory> neu ist. In diesem Zusammenhang die Handhabung in Verbindung mit einem ErrorDocument erst möglich ist...

Gruß aus Berlin!
eddi