Mailinglist Archive: opensuse-security (220 mails)

< Previous Next >
Re: [suse-security] Intrusion
  • From: Antun Balaz <antun@xxxxxxxxxxxx>
  • Date: Mon, 24 Nov 2003 17:55:23 +0100 (CET)
  • Message-id: <Pine.LNX.4.44.0311241750400.5867-100000@xxxxxxxxxxxxxxxxxxxx>

Thanks again for helpful information.

New question: According to the history file of user whose account was used
for intrusion, rootkit was downloaded from

cat /etc/issue
chmod +x k
chmod +x noparty
etc. etc.

Directory*/ 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

< Previous Next >
Follow Ups