Merkwürdiges problem mit den Tasks

[stamos]

Hallo,

ich habe einen Root-Server bei Server4you, Suse 9.2 apache2, (jaja ich weiß, bitte nicht kommentieren).

darauf habe ich ein forum laufen, was auch ganz gut besucht ist. eigentlich läuft auch alles ganz prima, nur das zeitweise die Tasks im "top" plötzlich hochschießen von z.B. 150 auf 370 mit dem ergebnis das in der apache error log steht:

server reached MaxClients setting, consider raising the MaxClients setting

die clients da kann ich allerdings so hoch setzen wie ich will, z.b. auf 500, dann würde im "top" die Taskzahl auf 500 steigen.

was kann diesen plötzlichen Task-Anstieg auslösen??

der restliche sever läuft ok (mail, ftp etc.) nur apache2 streikt dann eben....

quote aus dem top:

Code: Select all

top - 23:03:11 up 20 min,  1 user,  load average: 2.31, 1.53, 1.27
Tasks: 275 total,   3 running, 271 sleeping,   0 stopped,   1 zombie
Cpu(s): 43.4% us,  2.6% sy,  0.0% ni, 53.6% id,  0.3% wa,  0.0% hi,  0.0% si
Mem:   2041676k total,   898300k used,  1143376k free,    11300k buffers
Swap:  1052248k total,        0k used,  1052248k free,   202420k cached

oder auch

Code: Select all

top - 23:05:51 up 23 min,  1 user,  load average: 2.22, 1.81, 1.41
Tasks: 368 total,   2 running, 366 sleeping,   0 stopped,   0 zombie
Cpu(s): 91.7% us,  4.7% sy,  0.0% ni,  3.7% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:   2041676k total,  1024712k used,  1016964k free,    11584k buffers
Swap:  1052248k total,        0k used,  1052248k free,   212016k cached

[theton]

Ich kenne solche Phaenomene eigentlich nur von DOS- bzw. DDOS-Angriffen. Bist du dir sicher, dass deine Forum-Software keine Luecken hat? Wie aktuell ist dein Apache und wie aktuell dein PHP?

[stamos]

als forum software habe ich vbulletin 3.5.3, die neueste version.

PHP Version 4.3.10, MySQL 4.1.10a und Apache/2.0.53

wenn es eine DOS-Attacke wäre, müsste ich es dann nicht in den log-files sehen? (welche wären es dann konkret?)

[theton]

Jeder Zugriff wird in der access_log gespeichert, sofern der Apache richtig konfiguriert ist. Unter SuSE ist die soviel ich weiss per Default unter /var/log/apache2/access_log.

[stamos]

die logs sind mehrere 100MB groß (ich habe viel traffic auf meiner seite), mit nem Editor komme ich da nicht weit.

gibt es vielleicht einen parser der bestimmte sachen raussucht o.ä.?

[captaincrunch]

Ein solcher Parser nennt sich (z.B.) "grep"

[theton]

Siehe 'man grep', 'man tail'. Beispiel fuer grep:

grep "suchwort" <datei>

Alternativ kann man den Output, wenn er zu lang wird auch an einen Pager weiter leiten, mit dem man dann in Ruhe durch den Output scrollen kann (siehe 'man bash'):

grep "suchwort" <datei> | less

Oder du schaust dir die Datei gleich in nem Pager an

less <datei>

Kleiner Tip an dich. Richte dir mal logrotate ein. Damit hast du dann kleinere uebersichtliche Logs, deren Datum des Inhalts du am Dateinamen erkennen kannst (z.b. access_log-2006-01-24.gz). Und wie du an der Endung im Beispiel siehst, kann man die auch gleich zusammenpacken lassen um Speicherplatz zu sparen. :)

[skolem]

Hallo!

server reached MaxClients setting, consider raising the MaxClients setting

Ich hab genau das gleiche Problem. (Apache/2.0.54-worker PHP4-FCGI) Ich hab mal in den Logs geschaut und nichts ungewöhnliches feststellen können. Pro Sekunde sind etwa 20 Zugriffe zu verzeichnen. Etwa 2 Minuten vor dieser Meldung brechen die Zugriffe dann ein. Dann liefert der Server weder statische, noch dynamische Seiten aus. Erst ein Neustart des Servers hilft.

Im Error error.log ist ersichtlich, dass die PHP-Scripte nicht korrekt abgearbeitet werden. Etwa 2 Minuten später kommt die Meldung.

Code: Select all

[Thu Feb 16 10:21:04 2006] [error] [client XX.XXX.XXX.XX] FastCGI: comm with server /var/www/php-fcgi-scripts/default/php-fcgi-starter" aborted: idle timeout (30 sec)
[Thu Feb 16 10:21:04 2006] [error] [client XX.XXX.XXX.XX] FastCGI: incomplete headers (0 bytes) received from server "/var/www/php-fcgi-scripts/default/php-fcgi-starter"

...

[Thu Feb 16 10:22:53 2006] [error] server reached MaxClients setting, consider raising the MaxClients setting

...Neustart...

[Thu Feb 16 10:29:16 2006] [warn] child process 18894 still did not exit, sending a SIGTERM
[Thu Feb 16 10:29:16 2006] [warn] child process 19300 still did not exit, sending a SIGTERM
[Thu Feb 16 10:29:16 2006] [warn] child process 19381 still did not exit, sending a SIGTERM
...
[Thu Feb 16 10:29:23 2006] [notice] caught SIGTERM, shutting down

So wie ich das sehe, werden die Apache-Threads nach dem Idle Timeout der FCGI-Prozesse nicht wieder freigegeben. Die Speicherauslastung und die Prozessorlast ist OK. Auch die Datenbank, auf die die PHP-Scripte zugreifen liefert keine Fehlermeldungen.

Wo ist der Fehler?

[theton]

Dann wuerde ich mal eine aktuellere Version von Apache probieren. 2.0.54 ist ja nun reichlich alt und enthaelt zudem auch noch diverse Sicherheitsluecken. Wahrscheinlich ist das Problem in Apache 2.2.0 schon laengst behoben.

[skolem]

Dann wuerde ich mal eine aktuellere Version von Apache probieren. 2.0.54 ist ja nun reichlich alt und enthaelt zudem auch noch diverse Sicherheitsluecken. Wahrscheinlich ist das Problem in Apache 2.2.0 schon laengst behoben.

Genauer gesagt ist es die Apache stable Version 2.0.54-5 von Debian.

[theton]

Und selbst wenn Debian da hundertmal stable ranschreibt, ist das keine Garantie dafuer, dass das Programm auch bug-frei ist. Kannst natuerlich auch auf das stable pochen und sagen, dass es ja damit irgendwie gehen muss, kannst aber auch einfach mal die aktuelle Apache-Version probieren um zu sehen, ob das Problem dort immernoch auftaucht. (Ueberleg einfach mal, wieviele Patches du in dein Stable-Debian schon einspielen musstest beim Update und erzaehl mir dann nochmal, dass das, was du da installiert hast, stable sei. Und mit ziemlicher Sicherheit, wirst du auch in Zukunft noch viele Patches in dein Stable-System spielen muessen. Nicht ueberall wo stable dran steht ist auch stable drin. Heisst ja nur, dass zum Zeitpunkt des Release keine Fehler bekannt waren. Aber meist finden die eh erst die User. :D).
Daher mein Tip: Apache 2.2.0 versuchen. 2 Major-Versionen Unterschied haben schon ihren Grund.

[skolem]

Und selbst wenn Debian da hundertmal stable ranschreibt, ist das keine Garantie dafuer, dass das Programm auch bug-frei ist. Kannst natuerlich auch auf das stable pochen und sagen, dass es ja damit irgendwie gehen muss, kannst aber auch einfach mal die aktuelle Apache-Version probieren um zu sehen, ob das Problem dort immernoch auftaucht. (Ueberleg einfach mal, wieviele Patches du in dein Stable-Debian schon einspielen musstest beim Update und erzaehl mir dann nochmal, dass das, was du da installiert hast, stable sei. Und mit ziemlicher Sicherheit, wirst du auch in Zukunft noch viele Patches in dein Stable-System spielen muessen. Nicht ueberall wo stable dran steht ist auch stable drin. Heisst ja nur, dass zum Zeitpunkt des Release keine Fehler bekannt waren. Aber meist finden die eh erst die User. :D).
Daher mein Tip: Apache 2.2.0 versuchen. 2 Major-Versionen Unterschied haben schon ihren Grund.

Das kann schon sein, dass es mit der Apache-Version zusammen hängt. Aber ich werd auf dem System keine Experimente machen. Das Einspielen von Sicherheitsupdates geht bei Debian im übrigen vollautomatisch. Diesen Service hab ich bei Software die ich selbst installiere nicht. Und bei bestimmten Systemen vertrau ich einfach auf die stable-Releases, weil die schon länger getestet worden sind. Die Warscheinlichkeit das bei weniger getesteter Software Bugs und Sicherheitsprobleme auftauchen, ist IMHO wesentlich höher.

Trotzdem danke für den Tipp.

[Joe User]

2 Major-Versionen Unterschied haben schon ihren Grund.

FYI: Es ist nur eine Major, die ungeraden Majors representieren lediglich den Alpha/Beta-Tree, und einer der Gründe für den Major-Sprung stellen die inkompatiblen ABI/API-Changes dar...

[theton]

Genau, die Alpha- und Beta-Versionen. Waere nur schoen, wenn sich die Leute von Apache dran halten wuerden. Tun sie aber offensichtlich nicht, denn die aktuelle Version von Apache1 ist 1.3.34 und die ist als stable freigegeben. Und sofern mich meine Mathematik-Kenntnisse nicht total verlassen haben, ist 3 nicht unbedingt eine gerade Zahl. :D Aber stimmt schon... von 2.1 ist nie eine Stable rausgekommen. Aber trotzdem sehen wir, dass man sich auf das Prinzip ungerade Major gleich Alpha/Beta-Version nicht unbedingt verlassen kann.

[captaincrunch]

[ ] Du weißt, dass die Versionierung beim Apache-Projekt nicht immer so war.

[theton]

Ja, das weiss ich, aber es gibt diverse Projekte, bei denen man sich nicht unbedingt darauf verlassen darf, dass eine gerade Major auch ein stable Release bedeutet und umgekehrt. Das wollte ich halt mal zu bedenken geben. Hat aber ja auch nicht unbedingt was mit dem Problem hier zu tun. Sicher ist, dass Apache 2.2.0 nicht nur Aenderungen in der ABI/API hat, sondern eben auch diverse Bugfixes und Security-Patches beinhaltet und vielleicht ist da auch was fuer diesen Fehler dabei (ich werde jetzt deswegen bestimmt nicht die Changelog durchschauen, fehlt mir leider die Zeit zu).

@skolem: Sich nen kleines Skript zu machen, das die aktuellen Apache-Source laedt, entpackt, konfiguriert, kompiliert und installiert ist ja nur wirklich kein grosses Ding. Meine Erfahrung hat gezeigt, dass auch neuere Versionen von Apache problemlos "durchkompilieren", wenn man einmal mit den gleichen configure-Optionen schon ein aelteres Release installiert hat. Dieses Skript noch mit einem 'apachectl restart' am Ende ausgestattet in die crontab gepackt sorgt dafuer, dass zukuenftig auch deine Apache immer auf dem aktuellsten Stand ist. Sollte es beim Kompilieren Fehler geben, wird dir das ja eh vom crond mitgeteilt (darauf achten, dass alle Befehle mit && voneinander getrennt sind, so dass bei einem Fehler abgebrochen wird).
Gerade bei Server-Software verlasse ich mich nie auf die Versionen des Distributors, denn bis die mal ein Sicherheitsupdate veroeffentlichen, ist meist auf der Projekt-Homepage der betroffenen Software bereits ein neues Release mit entsprechenden Patches erschienen. Bei Apache dauert sowas z.B. im Durchschnitt 24 Stunden. Und mit ein paar kleinen Skripten im Cron kann man auch Software, die aus dem Source installiert wurde, problemlos automatisch aktualisieren lassen.

[stamos]

also bei mir war es letzendlich eine DOS Attacke.

per netstat konnte ich die IP des angreifers herausbekommen und dann in der firewall blocken. das problem trat dann nicht mehr auf :)

[michaelroelle]

Wie hast du die Attacken genau erkannt. Könntest du vielleicht einen Auszug posten?

Gruß Michael

[oxygen]

Also ich denke, die Version 2.2.0 des Apache's zu installieren würde keinerlei Sinn machen, Das ganze sieht mir ganz und gar nicht nach Bug aus. Sondern eher nach einem absichtlichen ("normaler DoS", oder aber auch Ausnutzen einer Sicherheitslücke z.B. in nem Formailer) oder unabsichtlichen DoS (z.b. böse Suchmaschine/Spider, begehrte Downloads) aus.
Ã?berprüfen lässt sich ganze leicht per apachetop, einfach mal nachinstallieren.

[alexander newald]

@theton

Auf einem Produktivsystem (Und auch wenn es nur eine Seite ist, aber er sagt ja selber, viele Besuche) ein Script, welches automatisch eine Source downloaded und durchkompiliert und ohne Kompatibilitätscheck installiert und dann auch noch per Cron ???

NEIN, das will, soll und darf man nich t :roll:

Man sollte schon irgendwie auf einem Testsystem das Ganze einmal ausprobieren. Und wenn es nur ein alter Rechner im Keller ist oder wo auch immer....

[stamos]

zu zeit des angriffs kannst du per Shell den befehl
netstat -n -t
eingeben. dann kommt eine liste aller IPs die deinen server konnektieren. naja, wenn du da eine IP mehr als 20 mal siehst dann kannst du von einer Attacke ausgehen. Bei mir waren es ca. 400-600 mal die gleiche IP.

diese kannst du dann per
iptables -I INPUT -s xx.xxx.xxx.xx -j DROP
an der firewall blocken (xx.xxx.xxx.xx=angreifer IP)