[lnx 2.4 / slack 8] Veel processen gaan in T mode

[ACM]

Een van onze servers doet sinds een tijdje erg raar, gisteren en vandaag iig.

Na een paar mins uptime (~5 tot 10) doet ineens ls het niet meer, top, ps e.a. wel.

Als je dan met top kijkt zie je dat er een ls in T-mode is (stopped or traced) en een met een pid + 1, die Z(ombie) is.

't Zelfde geldt voor rm, mv, uname, hostname, en allerlei andere commando's.
chkrootkit gaf geen rare dingen aan.

Als je dan strace (met -p $pid) aan zo'n process hangt, dan gaat het process ineens verder...
Als je het direct met strace start (strace ls ofzo) dan gaat het ook goed.

Geteste kernels: 2.4.18 en 2.4.24 (voor die .24 had deze config)
Fs is reiserfs.
Verder hebben we de laatste tijd niks er aan gewijzigd, bij mijn (en Kees') weten.

Waarom gaan al die processen in T-mode en belangrijker, hoe los ik dat op??

[odysseus]

Hier durf ik niet direct meer een antwoord op te geven...wel weet ik dat er de afgelopen paar weken al twee topics zijn geweest van mensen met hetzelfde probleem, dus er zit duidelijk ergens iets fout. Zie [rml][ Linux] Sleeping processes[/rml] (misleidende titel overigens) en proces met status T wil niet dood. Beide topics geven geen oplossing voor het probleem. Het lijkt erop dat het bij meer mensen voorkomt en dat het dus waarschijnlijk geen probleem is met hardware - niet met drie machines in een paar weken.

[Confusion]

Een van die anderen had het probleem in Debian. Daar is het package 'coreutils', waarin ls zit, voor het laatste 4/10/2003 ge-update, dus waarschijnlijk ligt het niet aan brakheid van een nieuwe versie van ls (bovendien is, aan het changelog te zien, er al een jaar niets meer veranderd aan ls).

Misschien dat er recentelijk andere mogelijk relevante packagesvervangen zijn? (Ik weet niet welke dat zouden kunnen zijn).

[ACM]

't Lijkt erop dat alleen die binaries die in /bin staan niet goed werken...
Binaries uit /usr/bin gaan in principe goed.

En als je dan strace aan zo'n hangend /bin process hangt zie je dat ie eerst alle files uit bin even afgaat... nu eerst maar even alle files uit /bin overgekopieerd van een goed systeem.

[ACM]

http://www.viruslibrary.com/virusinfo/Linux.OSF.8759.htm

dat zit er dus op... soepel

[pierre-oord]

Al een ouwe zo te zien. Wel handig is het als je verteld in welk programma dit virus zat; misschien een bekende tool?

edit:
Ik heb geen ervaringen met virussen en linux, maar sterkte met het eraf halen

[ Voor 29% gewijzigd door pierre-oord op 06-02-2004 22:41 ]

[ACM]

nou, zo'n beetje alles in /bin had het geloof ik wel: ls, touch, hostname, cut, cat, e.a.

[Verwijderd]

ACM schreef op 06 februari 2004 @ 22:50:
nou, zo'n beetje alles in /bin had het geloof ik wel: ls, touch, hostname, cut, cat, e.a.

was het overschrijven van de files genoeg om het virus de nek om te draaien, of laat je toch nog even een scanner z'n werk doen? (F-Port oid? )

[ACM]

ik heb het volgende gedaan:
een goede /bin gekopieerd naar de nfs-mount, voor de zekerheid daar chattr +i op gedaan
de executables allemaal vanaf die nfs-mount draaien (dus /mnt/.../ls ipv ls enzo) en daarmee alles in /bin overschreven op de geinfecteerde machine.

Toen een virusscanner gedownload en die is nog bezig met scannen

[Verwijderd]

ACM schreef op 06 februari 2004 @ 23:19:
ik heb het volgende gedaan:
een goede /bin gekopieerd naar de nfs-mount, voor de zekerheid daar chattr +i op gedaan
de executables allemaal vanaf die nfs-mount draaien (dus /mnt/.../ls ipv ls enzo) en daarmee alles in /bin overschreven op de geinfecteerde machine.

Toen een virusscanner gedownload en die is nog bezig met scannen

Ik ben benieuwd hoe intelligent dat virus is Ofdat tie zichzelf nogmaals heeft gered

Maar de scanner zal het wel oppikken

[ Voor 4% gewijzigd door Verwijderd op 06-02-2004 23:52 ]

[Confusion]

ACM schreef op 06 februari 2004 @ 21:37:
http://www.viruslibrary.com/virusinfo/Linux.OSF.8759.htm

dat zit er dus op... soepel

Nog enige kans dat je kan achterhalen wanneer het gebeurd is en daarmee misschien wie het gedaan heeft?

[moto-moi]

Onder debian wordt elke dag een check gedaan op de belangrijkste bestanden, en dan krijg ik dit soort stats elke dag in /var/log :

code:

  360517  2755   1 root       utmp          267544 Tue Mar 25 13:31:44 2003 ./usr/bin/screen
  360524  2755   1 root       utmp          110456 Tue May  6 16:44:20 2003 ./usr/bin/aterm-xterm
  360527  4755   1 root       root           32440 Sat Apr 26 21:50:53 2003 ./usr/bin/chage
  360534  4754   1 root       audio           5816 Mon Mar 31 09:53:34 2003 ./usr/bin/beep
  360557  4755   1 root       root           28088 Sat Apr 26 21:50:53 2003 ./usr/bin/chfn

Plus dat er elke dag de lijst met de vorige dag wordt vergeleken d.m.v. diff . bij Debian wordt dit allemaal geregeld door middel van /etc/checksecurity.conf , hetgeen (blijkbaar) wordt uitgelezen door cron.

[igmar]

ACM schreef op 06 februari 2004 @ 21:37:
http://www.viruslibrary.com/virusinfo/Linux.OSF.8759.htm

dat zit er dus op... soepel

Goed.. Dan zat ik d'r al 2 topics niet erg ver naast met m'n rootkit

Enig idee hoe dat d'r op gekomen is ? Je zal dat virus echt als root moeten uitvoeren wil je /bin kunnen intecteren. Ik zou ook nu maar een rootkit check doen, aangezien je die nu ook wel eens kado hebt kunnen krijgen.

Dan is d'r nog een ander punt : De packagemanager had dit ook moeten zien.

[ACM]

igmar schreef op 07 februari 2004 @ 12:23:
Enig idee hoe dat d'r op gekomen is ? Je zal dat virus echt als root moeten uitvoeren wil je /bin kunnen intecteren. Ik zou ook nu maar een rootkit check doen, aangezien je die nu ook wel eens kado hebt kunnen krijgen.

Ik gok dat er, al dan niet automatisch, gebruik van een ptrace+cvsd-exploit gemaakt is, maar weet dat niet zeker. De kernel was er oud genoeg voor, maar deze rule zou toch wel e.e.a tegen moeten houden kwa cvs toegang (de rules zouden op een ongelukkig moment natuurlijk weggeweest kunnen zijn:
DROP tcp -- anywhere anywhere tcp dpt:cvssshpserver
DROP tcp -- anywhere anywhere tcp dpt:cvspserver

Dan is d'r nog een ander punt : De packagemanager had dit ook moeten zien.

Sinds wanneer is een packagemanager continue files aan het afgrazen om te zien of ze niet meer goed zijn
Daar heb je tripwire voor (wij dus niet) e.d.

't Vervelende van een virus is juist dat je juist na het terugzetten van een goed werkende versie, je wederom met een virusinfectie kan zitten, omdat je een geinfecteerde file gemist had (je packagemanager ofzo was bij ons gelukkig niet het geval )

Btw, een extra controlemiddel om te zien of je door dit virus gepakt bent:
strace ls

als ie daar /proc/$pid/exe opent, dan ben je de sjaak, dat doet ls normaal niet en dat virus wel om te zien of er niet stiekem ge-traced wordt

[ Voor 4% gewijzigd door ACM op 07-02-2004 13:19 ]