sh - erzeugt hohe CPU Last

[raid]

Hallo,

bräuchte bitte mal Eure Hilfe!

Ich hab hier noch einen SuSE 9.3 Server (keine Angst Apache & Co sind aktuell) mit 3Ware RAID-1 im Einsatz und die Kiste macht irgendwie seit heute nach einem Mainboardwechsel Probleme. DMESG meldet keine Probleme, aber nach einer gewissen Zeit schmiert die Kiste immer ab, da geht kein einziger Dienst mehr, Ping funktioniert aber noch.

Also hab ich mal eine Weile TOP am laufen gehabt, da startet sich dann ein Script welches bei TOP in der Spalte Command mit "sh" benannt wird und dieses zieht 99,9% CPU Last. Nur "sh" ist ja IMHO innerhalb /bin eine Verlinkung für BASH. Nun frage ich mich, ob mir jemand einen Tipp geben kann wie sowas zustande kommt?

Ich hab dann mittel strace versucht da mal zu schnüffeln, aber tote Hose, passierte nichts. Ich konnte den Prozess mittels kill Befehl in allen Varianten nicht stoppen und ps aux hat mir auch nichts angezeigt.

Rootkit Hunter lief auch durch ohne Ergebnis und die Logfiles zeigen bis auf massig SSH Bruteforce Attacken nix auffälliges. Das ich das nicht stoppen konnte und bei ps aux nichts angezeigt wurde, sieht für mich aus, als ob sich da was verrannt hat, aber wie kommt man da auf die Spur? Das ist ja demnach ein toter Prozess der Leistung zieht wie verrückt ... *kopfkratz* Kann man sowas verhindern?

[Roger Wilco]

Code: Select all

man 1p ulimit
man 5 limits.conf
man 5 limits

[raid]

Okay Danke für den Wegweiser ... andere Sache, wie siehst Du die Chance, dass es meine unschöne Lösung gegen SSH Attacken ist die das Problem verursacht?

Code: Select all

#!/bin/sh

ipt="/usr/sbin/iptables"

$ipt -F
$ipt -X

$ipt -N SSH_WHITELIST
$ipt -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
$ipt -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
$ipt -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
$ipt -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

Die erste Zeile im Code legt einem die Lösung so nahe und ist wo die einzigste Sache, die sich auf /bin/sh bezieht ... :-k

[Roger Wilco]

wie siehst Du die Chance, dass es meine unschöne Lösung gegen SSH Attacken ist die das Problem verursacht?

Gering. Es sind keine Schleifen in dem Skript und auch ansonsten nichts, was das System übermäßig stressen könnte.

[oxygen]

Welchen User hat der Prozess den? Klingt für mich so als hätte jemand eine Shell z.B. über eine PHP Lücke gestartet und macht jetzt sonst was damit...

[raid]

Das wurde vom Root ausgeführt ... und weil ich genau das dachte, was Du schreibst, habe ich den Rootkit Hunter laufen lassen und selber alles durchforstet und nichts gefunden. Ich vermute einfach, dass es wirklich das Script war bzw. ich hab jetzt den SSH Port verlegt und das obige Script dadurch nicht mehr starten brauchen ... allerdings macht mit dem neuen Mainboard der Server jetzt seinen Spaß mit mir:

Code: Select all

Bad page state at free_hot_cold_page (in process 'kswapd0', page c156d800)
flags:0x20000008 mapping:d1b4bc6c mapcount:0 count:0
Backtrace:
 [<c01470ec>] bad_page+0x7c/0xb0
 [<c014790c>] free_hot_cold_page+0x7c/0x110
 [<c01482fc>] __pagevec_free+0x1c/0x30
 [<c014d3e3>] release_pages+0x163/0x180
 [<c014d415>] __pagevec_release+0x15/0x20
 [<c014eab8>] shrink_cache+0x358/0x360
 [<c014f058>] shrink_zone+0x98/0xd0
 [<c014f4c3>] balance_pgdat+0x233/0x3a0
 [<c014f70c>] kswapd+0xdc/0x140
 [<c01360a0>] autoremove_wake_function+0x0/0x50
 [<c01360a0>] autoremove_wake_function+0x0/0x50
 [<c014f630>] kswapd+0x0/0x140
 [<c0102345>] kernel_thread_helper+0x5/0x10

Ich vermute mal, dass es irgendwie mit dem ollen 2.6.11er Kernel zusammenhängt und irgendwelchen Eigenschaften des neuen Boards, wenn man ihm beim Bootvorgang /noapic mit auf den Weg gibt, dann schmiert er nach einer Stunde einfach so ab ohne irgend welche Fehler zu loggen. Naja wie dem auch sei, extrem zeitnah mal ne aktuelle SuSE draufbügeln, beobachten und dann mal sehen ...