Hacker, Spammer? http://....../POST_ip_port.php

[swolfram [templatix]]

Dass man versucht einen  Angreifer möglichst früh auszusperren ist mir klar. Aber warum muss das zwingend über htaccess erfolgen?

Tabellen erweitern, Datenbankabfragen bauen... Und weil es eben zusätzliche Datenbankabfragen sind, die JEDES Mal erneut abgerufen und geprüft werden müssen. Ich glaube der Server reagiert schneller mit der .htaccess

Mal davon abgesehen, das man auch noch relativ unnötigen Datenmüll in seiner DB ansammelt und diese damit weiter unnötig aufblähen würde. Ich halte serverseitige Lösungen für sinnvoller.

[webald]

Wieso Datenmüll ansammeln?

In der Tabelle stehen nur die gesperrten IP. Ob die in der DB stehen oder in der htaccess macht vom Datenvolumen keinen nennenswerten Unterschied. Die Abfrage ob der Zugriff zulässig ist könnte man auch überspringen, wenn man nach der Erstprüfung ein Flag in der Session setzt. Tabellen müssen doch auch keine erweitert werden, sind nur 2 oder 3 neue.

Dass es Connectoren gibt, die unbedingt im Admin-Verzeichnis liegen wollen sollte dringend geändert werden.

[swolfram [templatix]]

Ich bin nicht so der IT-Profi was Server betrifft, aber ist die Serverlast nicht einfach geringer wenn der Apache von Beginn an, den Bösewicht sperrt, anstatt das man erst auf der Seite Scripte laden lässt, die dann DB-Abfragen macht und Dinge prüft? Und wie gesagt, man muss nix an der DB rumpfuschen.

Aber jeder wie er es lieber mag. Hauptsache die Lösung führt zum Erfolg.

[Bonsai]

Was ich mal vorhatte, aber nicht Zeit dafür:

Sämtliche Zugriffe auf Unsinn wie
/administrator
/myphpadmin
/wp_admin
Per .htaccess redirecten auf /block_script_kiddies.php

Diese block_script_kiddies.php liest dann die IP des Angreifers und fügt in der .htaccess hinter dem letzten Vorkommen von "Deny from"
eine neue Zeile ein:
Deny from IP_DES_ANGREIFERS

Jetzt noch in der robots.txt ein Disallow für
/administrator
/myphpadmin
/wp_admin
/block_script_kiddies.php

damit Google sich nicht selbst aussperrt.
Nachteil: Man sperrt auch Kunden mit verseuchten Rechnern, die versuchen einzubrechen.

@swolfram: Völlig richtig! Wenn Apache sperrt, hat er weniger Arbeit als wenn das mit PHP + MySQL läuft.

[webald]

Ja, deshalb Flag in session und nur einmal prüfen => keine Last auf dem mysql, last auf Apache genau eine if-Abfrage.

ein Script in der htaccess rumpfuschen lassen finde ich nicht gut, außerdem müßte die dann auch beschreibbar sein (=> Sicherheitsrisiko).

Interesant wäre es doch, wenn man ein Scriptkiddie automatisiert erkennt, es zu ärgern, indem man die Serverantwort verzögert. Wenn der Server bei solchen Zugriffsversuchen seine Antwort erst nach 5 Sekunden zurücksendet, dann haben die bald keine Lust mehr. Nur wie geht das ohne große Serverlast?

[swolfram [templatix]]

@webald
Ich verstehe Deinen Ansatz, aber auch wenn ich nur eine einzige IF-Abfrage an die DB richte, dann bricht Server und DB-Server bei einer DDOS schneller zusammen, als wenn nur der Apache zuvor aussperrt. Der hat zwar auch Last, aber bei weitem nicht so viel.

@bonsai
Manche animiert das erst recht, da was zu versuchen
Stillschweigend blocken ist gut genug. Und wie webald sagte, müsstest Du die .htaccess davor beschreibbar machen. Ganz zu schweigen wenn da mal was schiefgeht und auch nur 1 Zeichen schief kommt, dann geht gleich nichts mehr.

[Bonsai]

Was will der versuchen? Der greift EINMAL auf die falsche Datei zu, und dann ist die IP tot.

Selbst mit Botnetzwerk absolut keine Chance ...

Man sollte eventuell noch mit einbauen, dass man bei 10 Sperrungen innerhalb einer Stunde eine Mail bekommt .... das könnte dann ein Denial of Service Angriff über ein Botnetzwerk sein.