Schutz vor Spidern etc.

[Ralf (Berlin)]

Eine Frage in die Runde:

mir gehen mittlerweile die ganzen Spider gehörig auf die Nerven, die permanent versuchen sich irgendwo reinzuknabbern.

Überlegung: diese Spider erzeugen charakteristische Fehler, z.B. Seitenaufrufe mit /" oder mit } etc. Es sollte also kein Problem sein IP's die solche Aufrufe tätigen oder innerhalb kurzer Zeit ein Bündel von Fehlerseiten erzeugen für 24h zu sperren und sie auf eine tote Seite abzuschieben.

Die Ermittlung der Seiten erfolgt über die Fehlerseite, das Ausperren könnte ein Droplet im Template erledigen.

Mache ich da einen Denkfehler oder übersehe ich dabei etwas?

Gruß
Ralf

[DarkViper]

Mache ich da einen Denkfehler oder übersehe ich dabei etwas?

yep... denn wenn ein Spider mal bei nem Droplet angekommen ist, kannst ihn auch vollends weiter laufen lassen. Die Serverlast wurde zu diesem Zeitpunkt längst verursacht.

Wenn Spider filtern, dann als allererstes in der /wb/index.php, noch bevor großartig Speicher alloziert oder gar Datenbankabfragen ausgeführt wurden. Alles andere ist Augenwischerei und Scheinkosmetik.

[Ralf (Berlin)]

Wenn Spider filtern, dann als allererstes in der /wb/index.php, noch bevor großartig Speicher alloziert oder gar Datenbankabfragen ausgeführt wurden. Alles andere ist Augenwischerei und Scheinkosmetik.

Wo du recht hast, hast du recht 

Was hälst du für vernünftig/vertretbar? Ich stelle mir die Vorgehensweise so vor:

• ein Script auf der Fehlerseite loggt die IPs. Erzeugt die IP Fehler nach einem bestimmten Muster wird sie sofort gesperrt, ebenso, wenn sie z.B. 5 Fehler innerhalb von 60 Sekunden erzeugt.
• in der index.php wird geprüft, ob die IP gesperrt ist, falls ja, wird die IP auf eine Sperrseite geleitet oder kommentarlos geerdet.

Gruß
Ralf

[Waldschwein]

Hallo!

Ich weiß nicht, aber ich finde alles, was grundsätzlich automatisch "Benutzer" aussperrt auf Grund von IPs und Verhaltensmustern immer etwas... Nunja, nicht sonderlich sinnvoll (ja, auch der WB-Admin hat so etwas, aber da macht es am ehesten Sinn).
Es gibt ja aber z.B. in phpBB3 das Feature, dass Spider grundsätzlich einer eigenen Gruppe zugewiesen werden und auch als solche in der Online-Liste auftauchen - anscheinend klappt das sogar ganz gut. Also wäre es eine Überlegung wert, dort einmal nachzusehen, "wie die das so" handhaben, weil die meisten Spider ja generell dieselbe IP-Adresse verwenden.
Dann schreibt man sich eine Liste zusammen, evtl. mit Admintool erweiterbar, und dann müsste man nur noch in der index.php (oder ganz oben im Template mittels Droplet, am Besten noch vor dem Doctyp?) mitteilen, dass diese Liste beachtet wird. Zudem kann es hilfreich sein, wenn man grundsätzlich Spameinträge bekommen sollte (wieso auch immer), sind diese meist aus einem Land, wo eh kein Benutzer auf die Seite kommt - also kann man hier auch gleich diese aussperren.
Natürlich kann man dies nach Belieben erweitern, und gleich sogar ein Admin-Tool für jederman drauß basteln - mit einer Liste, die man selbst definieren kann, aber grundsätzlich einmal "die wichtigsten" an Board hat.
Wobei das alles ja nichts großartig anders ist als eine robots.txt, nur eben diesmal strikt.

Einfach ein paar Denkanstöße.

Gruß Michael

[maverik]

na dann schaut mal hier bevor das rad zweimal erfunden wird

http://www.bot-trap.de

denke das geht in die gleiche richtung

[Waldschwein]

na dann schaut mal hier bevor das rad zweimal erfunden wird

http://www.bot-trap.de

denke das geht in die gleiche richtung

Hhmm, die Seite ist ja sogar mit WB gemacht.  Also geht es schon einmal grundsätzlich.

Gruß Michael

[Ralf (Berlin)]

Hallo Maverik,

na dann schaut mal hier bevor das rad zweimal erfunden wird

http://www.bot-trap.de

denke das geht in die gleiche richtung

das sieht gut aus, schaue ich mir an - könnte aber schon die Lösung sein.

Gruß
Ralf

[Ralf (Berlin)]

Hallo alle miteinander,

der erste Test mit Bot-Trap sieht sehr gut aus, mal sehen wie sich das auf Strecke bewährt...

Für eine einfache Kontrolle der Logfiles habe ich ein Tool geschrieben: dbBotTrap. Das Tool installiert sich als Admin-Tool, eine Konfiguration ist nicht erforderlich.

Auf bot-trap.de wird für WebsiteBaker eine Einbindung in den jeweiligen Templates vorgeschlagen, ich halte das nicht für die beste Lösung, ich binde die page.restrictor.php über die config.php von WebsiteBaker ein:

Code:

// init Page Restrictor first...
if (file_exists($_SERVER["DOCUMENT_ROOT"].'/page.restrictor.php')) {
  //define('PRES_WHITELIST_IP', '91.18.216.141'); # entsperrt die single IP 91.18.216.141
  //define('PRES_WHITELIST_IPR', '91.18.216.140/91.18.216.142'); # entsperrt den IPRange von 91.18.216.140 bis 91.18.216.142
  //define('PRES_WHITELIST_UA', 'libwww'); # entsperrt den UA libwww

  $logfile = $_SERVER['DOCUMENT_ROOT'].'/logs/'.date('Ymd').'.log';
  define('PRES_LOG_FILE', $logfile);

  require_once($_SERVER["DOCUMENT_ROOT"].'/page.restrictor.php');
}

Die Verlagerung der LOG files nach /logs und die Aufteilung in tägliche Logfiles hält das Ganze etwas übersichtlicher...

Gruß
Ralf