[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Apache 2.2: allow/deny aus Datenbank/memcache/cookie
[Thread Prev] | [Thread Next]
- Subject: Apache 2.2: allow/deny aus Datenbank/memcache/cookie
- From: Raphael Eiselstein <rabe@xxxxxxxxx>
- Date: Fri, 7 Dec 2012 01:06:16 +0100
- To: uugrn@xxxxxxxxxxxxxxx
Hallo zusammen, ich pflege aktuell manuell eine .htaccess-Datei, um Zugriffe von bestimmten IPs oder IP-Ranges auf GET-Requests zu beschraenken. <LimitExcept GET> â?¦ deny from 78.27.128.0/18 deny from 85.127.0.0/16 â?¦ </LimitExcept> Ich will den Vorgang allerdings automatisieren, um Spammer und Botnetze effektiv auszusperren, zu mindest von der *akiven* Teilnahme am Rhein-Neckar-Wiki zu hindern. Ich habe taeglich einige zig bis hundert Zugriffe in dieser Form im Logfile stehen: GET /index.php?title=Special:UserLogin&type=signup HTTP/1.1 Die Seite [[Special:UserLogin]] existiert jedoch nicht. Ein normaler Benutzer wuerde sich immer ueber den Link anmelden, der ihm angeboten wird, das waere dann zB http://rhein-neckar-wiki.de/index.php?title=Spezial:Anmelden&returnto=Hauptseite Es sind also nur und ausschliesslich Bots, die sich die MediaWiki-Eigenschaft zunutze machen, dass Zugriffe auf englischsprachige Spezialseiten immer umgeleitet werden auf die lokalsprachlichen, hier deutsch. Meine Idee ist es also, Zugriffe auf /index.php mit title=Special:UserLogin und type=signup abzufangen und direkt zu blocken, sodass der (meist nur wenige Sekunden spaeter) folgende POST-Request direkt abgewiesen mird mit "403 Forbidden". Dazu wuerde ich eine Extension bauen, die eine Blockliste in MySQL pflegt. Allerdings will ich, dass Apache diese Blockliste dann selbst direkt verwendet um POST-Requests zu blocken. Alternativ: Die IP-Sperren sind ja immer nur kurzzeitig sinnvoll, d.h. nach zB einem Tag ist diese Sperre nicht mehr sinnvoll, weil der infizierte PC dann laengst eine neue IP-Adresse hat. Anstelle von MySQL koennte ich auch den ohnehin vorhandenen Memcache verwenden. Dennoch auch hier: Kann Apache das selbst zugreifen oder muss ich auch hier jedesmal erst PHP bemuehen? Da die Bots generell Cookies annehmen, von denen sie vieher nicht wissen, wie sie heissen, koennte ich auch ein Cookie setzen, mit dem ich den Zugriff fuer Post-Requests "freischalte" und dem Apache auf *irgendeine* Weise beibringen, dass er alles, was kein GET-Request ist abweist, wenn dieses Cookie *nicht* gesetzt ist. Sicher, das wuerde kein Scriptkiddie abhalten, das es spziell auf mich abgesehen hat, aber es wuerde die Bot-Scripte effektiv aussperren. Und ja, das Cookie wird bei jedem "verdaechtigen" Zugriff entsprechend geaendert, sodass es fuer !GET gesperrt bleibt. Prinzipiell ist ein PHP-Code, der auf ein Cookie prueft und nur bei Bedarf komplexere Dinge tut sehr schlank, zumal das Projekt insgesamt ja schon sehr schwerlastig in PHP daherkommt (MediaWiki). Prinzipiell bin ich an einer Loesung interessiert, mit der Apache pro Request den Zugriff verhindert und eben nicht erst PHP loslaufen muss. Alternative Ideen oder vielleicht sogar Loesungen? Gruss Raphael -- Raphael Eiselstein <rabe@xxxxxxxxx> http://rabe.uugrn.org/ xmpp:freibyter@xxxxxx | https://www.xing.com/profile/Raphael_Eiselstein GnuPG: E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D .........|.........|.........|.........|.........|.........|.........|.. -- UUGRN e.V. http://www.uugrn.org/ http://mailman.uugrn.org/mailman/listinfo/uugrn Wiki: https://wiki.uugrn.org/UUGRN:Mailingliste Archiv: http://lists.uugrn.org/