Re: Compromised system - still ok?
Some interesting points raised by Alvin.
On the other hand, run rkhunter after updating its lists & chkrootrit.
See what they have to say about your system, but also watch out for false
positives due to back-ported security patches (mostly for openssl, ssh,
..) in Debian.
If the machine is not critical, given the fact that you seem to have
noticed the compromise rather early on and that your firewall blocked
traffic to the telnetserver, you could invest some extra time in checking
md5sums of important files (again rkhunter & chkrootkit can help a bit
here ), close the security hole and reboot to your new kernel.
But before doing so, check your logfiles. Are you missing information for
some days from a while ago? Or missing complete logfiles/days?
Probably the attacker(s) had access to the box before - and long before
you noticed - so they concealed their traces, and then you should go to
step 2 without hesitation.
Watch for suspicious traffic going to and from the box for a while, then
forget about it.
If the machine is really important or serving important data, check the
integrity of the data, back it up and take no chances but reinstall the
box from scratch.
Under capitalism, man exploits man.
Under communism, it's just the opposite.
> On Mon, 7 Feb 2005, Geoff Crompton wrote:
>> >>You were rooted, you should reinstall. It's not worth risking that he
>> >>left something that you didn't find.
> <my opinion>
> "reinstalling" is the equivalent of a "script kiddie" and probably lower
> in skill level of the script kiddie
> see below for reasons if one cares
>> > I see no evidence at all of being rooted, or even hints thereto. Yes,
>> > the backup account was compromized. It looks like there were quite
>> > security measures in place, try to look hard for any attempt to kernel
>> > exploit or otherwise local exploit, and think about what files this
>> > backup account had access to. Of course, importance of the system
>> > matters too, if you were the NSA or something, I'd definitely
>> > however, if you're not THAT paranoid, I think you can do with locking
>> > down backup account, checking all files writeable by backup (all files
>> > with recent ctime?), and places like /var/tmp, /tmp, etc.
> nsa and other 3-letter agencies will probably find out:
> - where the cracker came from
> - what else the cracker did on the suspect box
> - what other machines the cracker tried to access inside the
> network and what other files were changed on other servers
> - how they got in and repoduce how they got in
> - come to your door step and serve a warrant if
> one broke into a "secret" machine
> - are there automated jobs that run at fixed times or
> whenver you do something
> - how long have they been in the system before you noticed
> and sometimes they are in there for weeks or months before
> you start to notice because they started to use the cracked box
> - is the backup clean or is it suspect too
> - what files the cracker changed
> - what files the cracker added
> - .. on and on ..
> you can reinstall AFTER you can answer all the above questions
> or give up and give the point ot the script kiddie cracker
> resinstalling is bad because ..
> - you donno how they got in and they can get back in
> the same way again, and the 2nd time, they'd probably be
> less friendly
> - most crackers are not malicious and just wanna prove something
> to themself or their buddies
> - reinstalling and cleanup after a cracked box is very painful
> and can take days weeks of cleanup whether you reinstall or not
> - reinstallng does NOT clean up the other machines the
> cracker could have used .. ( esp passwordless login systems
> where they have free access to everything )
> - reinstalling is bad because you didn't check your backups
> before restoring, and for all you know, you can be restoring
> their trojan that will wake up one day again in the future
> - if you didn't change your normal computer usage after the
> breakin, they will be back again
> - thousands of "best practices" security rules and policies
> to follow or not depending on ones paranoia or risk of something
> might happen vs the obvious required time/steps needed to protect
> against those possible crack attempts
>> Unless the evidence of being rooted was hidden. This can be done with
>> * replacing system binaries, so that, for instance, /bin/ls does not
>> list the root kit files, and that /bin/ps does not display the rootkit
> those are trivial to check and verify .. few minutes
> one keeps a copy of all files and directories on another media ( cdrom )
> - anything that shows up different is new file since the
> "md5sum was done" or its the cracker files
> - if you upgrade daily .. you're sorta assuming a few
> things, like you don't know or care that certain files changed
> on certain days or hopefulling logging it but how do you
> know it was changed due to update vs cracker got in and also
> got its files in your "these are my changes for today" checksums
>> * replacing kernel (or modules) so that process information relating to
>> the root kit is hidden, and files are hidden
> most rootkits leaves traces .. though it's getting better at hiding
>> * hiding the root kit files in 'empty' spaces on the filesystem, (ie,
>> where no inodes are pointing to)
>> * hiding the root kit files in the filesystem (amongs other files, a
>> little bit in each inode maybe?)
> ideal places for those is using the extra buytes of
> ( small files, where lots of unused bytes is available )
> if they have hidden their stuff inside a secret filesystem of unused
> disk space... you need professional 3-letter help ...
> - reinstalling will not help you, as they probably outclass
> your/our security policies
> and a more likely scarier problem, is they installed a keyboard sniffer
> ( quietly sniffing all your passwds )
> - do you login each time or do you login only once ??
>> Yes, if the system is not important, you might not bother re-installing
>> it. However in my (fairly recent experience), it was _easier_ to
>> reinstall than it was to check all those things.
> one should watch and study the network to that cracked box and learn
> as much as you can
> c ya
> To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact