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]
--------------------------------------------------------------------------
