max_clients überschritten -> apache schmiert ab

[Globestern]

hi

bei mir tritt seit kurzer Zeit desöftern folgendes Problem auf:

zur "Rushhour" schmiert mein Apache komplett ab, dann hilft nur noch ein apache stop

[Sun Nov 22 19:55:30 2009] [error] server reached MaxClients setting, consider raising the MaxClients setting
[Sun Nov 22 22:29:50 2009] [warn] child process 17870 still did not exit, sending a SIGTERM

sobald ich die Error Meldung erhalte, wird die Webseite nicht mehr ausgeliefert.. der Load auf dem Server ist aber iO.

Ich finde dieses Problem gefährlich, da ein potentieller Angreifer dies problemlos ausnützen könnte.. DDoS Attacken welche Load verursachen können wesentlich einfacher gedropt werden, als 1000 Ips welche die Seite 1x normal besuchen und so die max_clients überschreiten lassen..

<IfModule worker.c>
ServerLimit         35
StartServers         5
MaxClients         1225
MinSpareThreads     25
MaxSpareThreads     75
ThreadsPerChild     35
</IfModule>

Timeout 20
KeepAliveTimeout 13
MaxKeepAliveRequests 150

soll ich evtl. die Timeouts etwas tiefer ansetzen?
die MaxKeepAliveRequests sind aus meiner Sicht iO.

Mfg

 

[Huschi]

Bist Du Dir überhaupt sicher, dass Du den MPM-Worker nutzt?
Denn die Fehlermeldung "child process..." deutet eher auf den MPM-Prefork hin.

Den KeepAliveTimeout kannst Du auf jedenfall runter ziehen. 1 oder 2 Sekunden reichen meist aus.

Außerdem wären ein paar Fakten zu Deiner Server-Ausstattung recht hilfreich.

huschi.

 

[Globestern]

ja, bin ich:

./httpd -V
Server version: Apache/2.2.14 (Unix)
Server built:   Oct 11 2009 23:29:24
Server's Module Magic Number: 20051115:23
Server loaded:  APR 1.3.9, APR-Util 1.3.9
Compiled using: APR 1.3.9, APR-Util 1.3.9
Architecture:   64-bit
Server MPM:     Worker
  threaded:     yes (fixed thread count)
    forked:     yes (variable process count)
Server compiled with....
 -D APACHE_MPM_DIR="server/mpm/worker"
usw

server hardware:

Intel(R) Xeon(R) CPU X3220 @ 2.40GHz
8GB RAM

free -m
             total       used       free     shared    buffers     cached
Mem:          8007       5475       2531          0        745       1919
-/+ buffers/cache:       2810       5196
Swap:         1906          0       1905

load average: 0.20, 0.34, 0.43

das sind die momentanen Werte.. zur Rushhour wird dann natürlich etwas knapper, aber sollte noch genügend Perf. da sein

gerne kann ich noch tuning_primer Werte posten, falls das hilft.

gibt es eine Möglichkeit, die aktuellen Connections vom Apachen anzuzeigen - per speziellem netstat Befehl?

 

[Huschi]

Auch wenn Du noch Speicher frei hast, so bringt ein höher MaxClients nicht wirklich mehr Performance.
Um DDos-Angriffe abzuwehren kann man z.B. auf mod_evasive zurück greifen.

Zur Anzeige der aktuellen Requests nimmst Du am Besten mod_status mit "ExtendedStatus On".

huschi.

 

[Globestern]

ddos ist momentan kein Problem - evasive ist bereits im Einsatz im Zusammespiel mit einem drop der IPs per iptables

die Performance und Ladegschwindigkeit der Seite ist 1a.. das Problem ist eher wie oben beschrieben, dass die Seite nicht mehr erreichbar ist, sobald die max_clients erreicht wurden..

mfg

ps. danke für den Tipp mit mod_status

 

[kostaki]

hast du den MaxKeepAliveRequests jetzt schon mal runter gesetzt und dann getestet? Das sollte schon weiter helfen.

 

[Deleted member 4401]

Also dass man mit mod evasive DDoS Attacken abfangen kann halte ich für Augenwischerei, das mag bei einzelnen DoS Angriffen oder sehr kleinen Botnets (bis wenige Hundert) gut funktionieren aber sobald es sich um halbwegs grössere Nets handelt erreicht man gerade bei Verwendung von Firewall Regeln genau das Gegenteil: Jeder neue Request muss erst einmal die ganze Chain durchlaufen was das komplette System durch die resultierenden i/o-waits ins Nirvana schickt sobald die Chain bzw. die darauf einprasselnden Requests eine gewisse Grösse erreicht haben.

Sich auf mod evasive zu verlassen ist in diesem Falle meiner Meinung nach grob fahrlässig, und ohne abgeklärt zu haben ob es sich überhaupt um "gutartige" Requests handelt an der config rumzustellen ist auch nicht gerade logisch.
Keine hohe Load aber maxClients reached könnte z.B. für Slowloris sprechen (da hier ja keine Seiten mit evtl. dazugehörigen Datenbankqueries geladen werden sondern nur Verbindungen blockiert werden die noch nicht einmal richtig aufgebaut waren), und da würde man auch in den Logs nichts finden (im Bezug auf Requests) sondern nur über netstat, ebensowenig würde da mod evasive helfen.

 

[Globestern]

hast du den MaxKeepAliveRequests jetzt schon mal runter gesetzt und dann getestet? Das sollte schon weiter helfen.

bisher siehts ganz gut aus.. warte jetzt mal den sonntag abend ab

Also dass man mit mod evasive DDoS Attacken abfangen kann halte ich für Augenwischerei, das mag bei einzelnen DoS Angriffen oder sehr kleinen Botnets (bis wenige Hundert) gut funktionieren aber sobald es sich um halbwegs grössere Nets handelt erreicht man gerade bei Verwendung von Firewall Regeln genau das Gegenteil: Jeder neue Request muss erst einmal die ganze Chain durchlaufen was das komplette System durch die resultierenden i/o-waits ins Nirvana schickt sobald die Chain bzw. die darauf einprasselnden Requests eine gewisse Grösse erreicht haben.

bei richtigen attacken braucht es grössere "systeme" wie firewall basierende filterung, dns basierend usw.. zum glück musste ich mich aber noch nie mit einer richtig grossen rumschlagen..

Sich auf mod evasive zu verlassen ist in diesem Falle meiner Meinung nach grob fahrlässig, und ohne abgeklärt zu haben ob es sich überhaupt um "gutartige" Requests handelt an der config rumzustellen ist auch nicht gerade logisch.
Keine hohe Load aber maxClients reached könnte z.B. für Slowloris sprechen (da hier ja keine Seiten mit evtl. dazugehörigen Datenbankqueries geladen werden sondern nur Verbindungen blockiert werden die noch nicht einmal richtig aufgebaut waren), und da würde man auch in den Logs nichts finden (im Bezug auf Requests) sondern nur über netstat, ebensowenig würde da mod evasive helfen.

slowloris ist ein sehr guter input.. werde ich mir gleich mal anschauen
unabhängig davon haben wir mit keepalive ja bereits eine gute "gegenmassnahme" getroffen