Mailinglist Archive: opensuse-edu (86 mails)

< Previous Next >
Re: [suse-linux-uk-schools] ps not working -> cracked system

On 2 Mar 2001, at 19:31, Gary Stainburn wrote:
> I'm posting this purely as a cautionery note, and it may or may not
> relate your problem.
> An friend of mine has had a similar problem on his firewall system.
> Also, some services stop working - probably library based, and people
> have had trouble logging into the system.

These kind of problems have been reported on various Security (
especially Cobalt RaQ ) mailing lists about problems with telnet and
logging in to Linux boxes.

> Today, it was finally tied down to the fact that someone had broken
> into his system - probably through bind, although he was running a
> recent version, 8.2.2-P3.

In BIND terms that's ancient, when the box is rebuilt it should be
running 8.2.3, if not 9.<whatever is safe now>. Though please don't
take my word for it, check for the latest details.

> The problems were apparent, because a number of the commands, such as
> 'ps' and 'ls' had been replaced by versions compiled on another box.

This is commonly known as a "rootkit", because it allows a hacker to
hide the alterations they've made to the host. There are various
different ones available, which means:

> For those who wish to check, try to cd into #/usr/src/.puta. Don't
> try to 'ls' it because it won't show it. Apparently, the 'cd'
> command hasn't been altered, presumably because the cracker needed it
> to get back all the user ID/passwords it was harvesting every time
> popd, telnetd etc. was used.

this won't necessarily show whether the host has been hacked or not.
Try comparing the output of netstat and ps with the output of lsof
and sockstat if you have them; and a scan of the box externally, to
see if netstat and ps have been compromised. Also look in /dev and
/proc for unusual files and directories, especially those starting
with a dot. Also, while I haven't used it myself, I've heard
generally good things about chkrootkit at
And compare MD5 checksums with known good binaries on a known good
box, or even those off an install CD.

Oh, and check the contents of inetd.conf ( especially the end ), and
check inetd is using /etc/inetd.conf for it's config and not
"/usr/games/buried away in some obscure
directory/.hidden/.hackers.special.full.of.holes.inetd.conf" instead.

And after all that, you still can't be sure, but it's a start :(

"Never attribute to malice that which can be adequately explained by stupidity."'s-Razor.html

< Previous Next >
This Thread