Hi, 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 www.isc.org 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 http://www.chkrootkit.org/. 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." http://www.tuxedo.org/~esr/jargon/html/entry/Hanlon's-Razor.html