Hallo,
das sind genau die bekannten Probleme - daher fand ich den Ansatz der Firewall bzw. in dem Fall eher iptables nicht mal �bel. Es sollte durchaus m�glich sein via "limit" die Anzahl der request/min auf einen Wert n zu setzen. Wird der �berschritten - wird die IP geblockt. Da es legitime Anfragen sind nutzt alles andere ohnehin nicht.
Grundlegendes Problem: Du erwischt im schlimmsten Fall einen gro�en Firmenproxy oder einen von AOL. Ist also nicht unbedingt die L�sung.
Das Problem der Erkennung sehe ich nicht. Die Logfiles werden regelm��ig alle Stunde ausgewertet (webalizer bspw.) und die Zugriffszahlen mit denen der letzten x Stunden verglichen (simples Script in $scriptsprache). Bei einem erheblichen Anstieg merkst Du das recht schnell weil der Anstieg im Normalfall linear ist und nicht wie bei dieser Art Angriff eine Glockenkurve.
* Zuerst ging das FS mit den Logs gegen 100%. Ok, ich bin in Urlaub; vmtl habe ich geschlampert: R�umen wir also mal auf.
:-)
* 12h sp�ter: Das FS mit wwwhome (eine RAMDISK) geht gegen 100%. Ok, da liegen kleinere Logs von webalizer. Kein Problem; gemirrored. * 12h sp�ter: beide FS auf 100, Server lahm, aber nimmt Requests an; Mail kommt nicht durch, webmin z�h -> HEY, hier l�uft was schief! Ich hoffe, ich konnte kenntlich machen, dass die *Erkennung* das Problem ist.
Vorstellbar aber nicht so wirklich - bei *langfristigem* Monitoring und entsprechenden Referezzahlen. Gut ich bin da ehrlich: Habe ich auch in der Form noch nicht (daher Dank an Dich weil ich das jetzt umsetzen werde). Das ist aber mit Sicherheit ein Ansatz:
Wenn die letzten 10 Stunden der Schnitt bei 1000 Requests/Stunde lag und er auf einmal bei 1500 liegt dann ist irgendwas. Das kommt nicht so derartig pl�tzlich.
Bsp: IP xyz fordert einfach zigtausendmal eine existierende Seite an.Das w�re ja kein Problem. Es ist ja andersherum: 200.000 IP fordern eine Seiter an. (Und komplexere Szenarien sind vorstellbar. - Der Code ist drau�en. Insoweit bin nicht nur ich gef�hrdet ...)
Doch auch das ist ein Problem - wenn die Seite lastintensiv genug ist, zieht es Dir die Datenbank �ber die erlaubten Requests und Du guckst in die R�hre. Sicher ist der Fall nicht so f�rchterlich - aber den sollte man ja auch automatisiert behandeln wollen.
Wenn eine Datei, und das siehst Du auch in den webalizer/analog/irgendwas Logs pl�tzlich unverh�ltnism��ig oft angefragt wird - ist die Erkennung kein Thema mehr. Aber die Abwehr.
Vielleicht auf einem vorgeschalteten Gateway mittels kernel http ? Keinen Ahnung...
Gibt es ein simples Verfahren derartiges automatisiert festzustellen und diese IP, als Notl�sung f�r N�chste und Wochenenden, in die /etc/hosts.deny zu schreiben?Wie soll das denn gehen?
Das war die Frage :-)
Da stehen dann 500.000 IP und bei jedem Request werden die durchgehechelt? Auch eine SQL-DB w�rde das nicht machen.
Nein ich bin wie gesagt vom anderen Fall ausgegangen: 1 IP fragt legale aber lastintensive Seiten ab. Mit gen�gend Bandbreite kriegst Du so jede Maschine seeeehr langsam... in unserem Fall mit x tausend IPs die eine Datei abfragen muss was intelligentes her.
grep auf access.log ist auch T�ddelkram: Das bringt nur weitere Last auf die Maschine.
Das ist klar.
Schnelle Denkans�tze - w�ren zu diskutieren. Und umzusetzen: * Gr��e access/error.log �berwachen: (Problem Schwellwert.)
Vergleichszahlen - da hilft tats�chlich nur langfristiges Erfassen der Werte. Nutzt Dir aber auch nicht viel weil das noch Erkennung ist.
* mod-status: Wenn 80% aller erlaubten Childs laufen, klemmt es. Und wenn das W�chterprogramm selbst keinen Child mehr bekommt, dann ist es eh Zeit, den Server zu terminieren.
Nutzt nur bedingt weil Du ja den Dienst zur Verf�gung stellen willst. In dem Moment wo Du ihn wieder anwirfst hast Du das Problem erneut. Abgesehen davon hat der Angreifer in dem Fall eh gewonnen: Du bist down.
* Via grep pr�fen, ob H�ufung auf eine konkrete Datei
Das kriegst Du recht leicht mit einem grep auf die webalizer/analog Logs raus. Je nachdem wie oft Du die laufen l��t auch recht zeitnah. Auf jeden Fall sind daf�r kleine Logs notwendig - also eher logrotate daily als logrotate weekly. Das ist die Erkennung eines Angriffs.
Frage bleibt die Abwehr bzw. Schw�chung des ganzen. Gehen wir mal konkret von einem beliebigen Root-Server aus wo eben kein Gateway puffern kann und iptables oder ggfls. der kernel-http l�uft. Kann mit letzterem was abfangen und dem System so Luft geben? Oder tats�chlich in iptabels via "limit" die IPs aussondern die massenhaft auf Datei xyz.php zugreifen bzw. wie verhindere ich das pl�tzlich alle AOL User draussen bleiben :-)
Ein sch�nes Wochenende erstmal. Ich f�r meinen Teil werde mir das Perl-Manual schnappen oder in PHP versuchen einen Ansatz zur Logfileanalyse die sowas erkennt zu basteln - wahrscheinlich erfinde ich das Rad neu (und bestimmt schlechter als die Vorg�nger) aber warum soll man bei strahlendem Sonnenschein nicht im Prak liegen und coden :-)
regards, Michael
--------------------------------------------------------------------------
Apache HTTP Server Mailing List "users-de" unsubscribe-Anfragen an [EMAIL PROTECTED]
sonstige Anfragen an [EMAIL PROTECTED]
--------------------------------------------------------------------------
