About this list Date view Thread view Subject view Author view Attachment view

From: Roderick A. Anderson (raanders_at_acm.org)
Date: Thu 28 Apr 2005 - 22:31:23 BST

I have a vserver that has all the indicators that is is a victim of a root
kit ( SucKIT ). In my readings so far I see that SucKIT is is loaded
through /dev/kmem ( ie. it doesn't need a kernel sith support for loadable
kernel modules -- <http://la-samhna.de/library/rootkits/list.html> ).
This is a very old Vserver kernel ( embarrassing but true -- 2.4.21ctx-17
   Several other vservers , like this one , were built unified to a
reference cserver so whenever I find a replaced/changed file in the
'compromised' vserver ; fcheck ( run in the main server ) reports all the
unified vservers' files as changed.

For awhile I didn't have fcheck checking all the places it should have so
I've played hell trying to erradicate the rootkit. So my question is is
possible for an exploit using /dev/kmem in a vserver to stick something
in the kernel like a this?

Each time after I find and remove or replace the files and/or directories
I reboot the vserver ( not the main ). I'm still seeing the return of the
'!@#$%^&*' buggers. So either I haven't got all the compromised accounts
plugged or there is someway the hole is remaining open.

I'm trying to remove this rather than just build a new vserver and move to
it. A "Good" exercise I feel.

Any thoughts or ideas on this?


    "Open Source Software - You usually get more than you pay for..."
     "Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL"
               "Will code for ale, porter, or single-malt"

_______________________________________________ Vserver mailing list Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Thu 28 Apr 2005 - 22:31:47 BST by hypermail 2.1.3