hi list, just curious, if this would ring a bell with someone. Recently I noticed several strange things on one of my boxes (SuSE 8.2 with stock kernel for athlon). Among evidence, that something fishy is going on, I found a rather strange process in psauwx: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 500 72 ? S 2003 0:03 init [3] root 2 0.0 0.0 0 0 ? SW 2003 0:00 [keventd] root 3 0.0 0.0 0 0 ? SWN 2003 0:00 [ksoftirqd_CPU0] root 4 0.0 0.0 0 0 ? SW 2003 0:23 [kswapd] root 5 0.0 0.0 0 0 ? SW 2003 0:00 [bdflush] root 6 0.0 0.0 0 0 ? SW 2003 0:00 [kupdated] root 7 0.0 0.0 0 0 ? SW 2003 0:06 [kinoded] root 9 0.0 0.0 0 0 ? SW 2003 0:00 [mdrecoveryd] root 12 0.0 0.0 0 0 ? SW 2003 0:00 [scsi_eh_0] root 15 0.0 0.0 0 0 ? SW 2003 0:57 [kjournald] at 219 0.0 0.0 1492 104 ? S 2003 0:00 [atd] root 425 0.0 0.0 0 0 ? SW 2003 0:00 [eth0] I have never seen something like [eth0] anywhere else (btw: what's the actual meaning of square brackets? Demons show them to, but these are kernel tasks). Looking at /proc/425 doesn't give any clues, except that it has one file descripter open pointing to /dev/initctl and a PPID of 1. I also found port 6667 to be open, or better "filtered" (nmap). The firewall (self made) doesn't touch it, and I can't associate a process with it (it doesn't accept connections either if simply telnetted to). So the question: Has anyone seen such a thing? I checked with the "checkrootkit" suit, but nothing was found. -- Patrick Ahlbrecht Systemadministration billiton internetservices direct phone: 0271 30386 19
On Thursday 01 January 2004 20:51, Patrick Ahlbrecht wrote:
Not likely a rootkit. You will find that you can stop it with 'rcnetwork stop eth0' and start it again with 'rcnetwork start eth0'. It's the service which handles you network card. Most rootkits will hide themselves by changing the output of the 'ps' command, so you're not likely to find a rootkit that way.
From where did you check this? If you used an online scanning service, it could be that your ISP is filtering port 6667. It is commonly (ab)used for IRC and therefor a fairly well known vulnerability. Some ISP's don't want their customers to run servers, the only reason why you might need it. As an 'ordinary' user, you wouldn't be harmed by filtering. Check with your acceptable use policy of your provider. Best regards, Arjen
Am Donnerstag, 1. Januar 2004 20:47 schrieb Arjen de Korte:
Well, that's the thing, that was puzzeling me. I've already had some experiences with rootkits, so finding something with ps I could not sort in was quite surprissing. Nevertheless, my homebox (SuSE 9.0) would not show such a process, even though I got a local LAN here. Stopping the network with rcnetwork stop to see what happens is not really a choice for my, as I do not have physicall access to the machine ;-).
From where did you check this? If you used an online scanning service, it
I checked it from home, using nmap (which isn't installed of the maschine in question). I thought it might be safer to check from outside.
Hm, haven't thought of this yet. I'll have to check this with our ISP, thanx for the advice. -- Patrick Ahlbrecht Systemadministration billiton internetservices direct phone: 0271 30386 19
On Friday 02 January 2004 6:51 am, Sascha Cunz wrote:
Any tool on the suspect box has to be treated with caution, IME. It's always handy to keep a few staticly-compiled binaries of things like ps and find and chkrootkit and sash - say - on a CD-R; if you suspect a compromise, put them on the suspect box and see if they give you anything more than the usual results. (I find the various arguments of 'find' to be useful 'find -atime' or 'find -mtime' - any half-clued kiddie will modify the timestamps, but there's often something that doesn't get changed and can give you clues.) - it should go without saying that the binaries need to be compiled for a system appropriate to your suspect box! Additionally, lsof (http://www-rcd.cc.purdue.edu/~abe/) is invaluable for this sort of thing. best wishes, Gideon Hallett.
On Thu, Jan 01, 2004 at 11:34:49PM +0100, Patrick Ahlbrecht wrote:
That depends on the network card. Some card drivers will spawn a kernel thread to handle incoming packets, some don't. The [foobar] notation usually indicates a kernel thread (more specifically, a process where the memory in which the command line resides is currently not available in RAM). Olaf -- Olaf Kirch | Stop wasting entropy - start using predictable okir@suse.de | tempfile names today! ---------------+
On Thursday 01 January 2004 20:51, Patrick Ahlbrecht wrote:
Not likely a rootkit. You will find that you can stop it with 'rcnetwork stop eth0' and start it again with 'rcnetwork start eth0'. It's the service which handles you network card. Most rootkits will hide themselves by changing the output of the 'ps' command, so you're not likely to find a rootkit that way.
From where did you check this? If you used an online scanning service, it could be that your ISP is filtering port 6667. It is commonly (ab)used for IRC and therefor a fairly well known vulnerability. Some ISP's don't want their customers to run servers, the only reason why you might need it. As an 'ordinary' user, you wouldn't be harmed by filtering. Check with your acceptable use policy of your provider. Best regards, Arjen
Am Donnerstag, 1. Januar 2004 20:47 schrieb Arjen de Korte:
Well, that's the thing, that was puzzeling me. I've already had some experiences with rootkits, so finding something with ps I could not sort in was quite surprissing. Nevertheless, my homebox (SuSE 9.0) would not show such a process, even though I got a local LAN here. Stopping the network with rcnetwork stop to see what happens is not really a choice for my, as I do not have physicall access to the machine ;-).
From where did you check this? If you used an online scanning service, it
I checked it from home, using nmap (which isn't installed of the maschine in question). I thought it might be safer to check from outside.
Hm, haven't thought of this yet. I'll have to check this with our ISP, thanx for the advice. -- Patrick Ahlbrecht Systemadministration billiton internetservices direct phone: 0271 30386 19
On Friday 02 January 2004 6:51 am, Sascha Cunz wrote:
Any tool on the suspect box has to be treated with caution, IME. It's always handy to keep a few staticly-compiled binaries of things like ps and find and chkrootkit and sash - say - on a CD-R; if you suspect a compromise, put them on the suspect box and see if they give you anything more than the usual results. (I find the various arguments of 'find' to be useful 'find -atime' or 'find -mtime' - any half-clued kiddie will modify the timestamps, but there's often something that doesn't get changed and can give you clues.) - it should go without saying that the binaries need to be compiled for a system appropriate to your suspect box! Additionally, lsof (http://www-rcd.cc.purdue.edu/~abe/) is invaluable for this sort of thing. best wishes, Gideon Hallett.
On Thu, Jan 01, 2004 at 11:34:49PM +0100, Patrick Ahlbrecht wrote:
That depends on the network card. Some card drivers will spawn a kernel thread to handle incoming packets, some don't. The [foobar] notation usually indicates a kernel thread (more specifically, a process where the memory in which the command line resides is currently not available in RAM). Olaf -- Olaf Kirch | Stop wasting entropy - start using predictable okir@suse.de | tempfile names today! ---------------+
participants (5)
-
Arjen de Korte
-
Gideon Hallett
-
Olaf Kirch
-
Patrick Ahlbrecht
-
Sascha Cunz