I think that there is room to mention the well known tools such as AIDA and TripWire and LogCheck.

For starters, why you do NOT keep any sort of compiler on your machine.

It's rather difficult to load kernel obfuscation modules (like hiding processes and files) without header files and no compiler.

It'd be even better if you could make every program execute only (no reading) and hide /proc through something like NSASecurity setup. What they dont know, they cant do much with. Obfuscation, THEN security. Keep em guessing.

I PREFFER OSSEC HIDS to do this. look www.ossec.net i think this is the most powerfull agent ever :)

It's rather difficult to load kernel obfuscation modules (like hiding processes and files) without header files and no compiler.

I'll tell you a little secret: if you know the kernel version number and target architecture, you can build a module on another, totally different machine. Wow! 2007 technology man!

It's pretty trivial to just deduce what kernel the machine is running and build working binaries wherever you want. In fact it would be preferred, since a sysadmin is far more likely to notice a rogue gcc process sucking up CPU than a file transfer while the rootkit is being loaded.

Anyway - if the person has root on the box (which they need to install the rootkit anyway), then they can just ship up THEIR OWN COMPILER if they want to regardless.

Most modern rootkits are kernel level and Trip Wire can not readily detect them. Nevertheless it is still useful to have at hand.

You'd want to be able to flip it on the fly for OS updates. Otherwise, you're looking at pretty routine downtime -- which may or may not be an issue for you.

Impractical, because it requires you to dedicate a drive to the stuff that can be mounted RO. Just mount the PARTITION read-only, instead.

If you have more than one machine, get a dedicated syslog server and send the logs from the other machines over to it. This way logs aren't on the main machines and it is much harder to compromise the audit trail.

For businesses, get something like a Trigeo appliance [trigeo.com] and keep an eye on the behavior of everything.

Make sure all your permissions/rules are based off the concept of "default deny, explicit allow".

You could also built a monolithic kernel and not allow modules at all. Kind of hard to insert a corrupt module if the kernel isn't modular!

  Charles

chkrootkit is good, I like it anyway, you can get it in Fedora Core 6 through yum (although you don't seem to be able to get rkhunter through yum any more). you have to run it as root, maybe its something about what it needs to access... anywho, you can get issues with false possitives, I just ran it and got;

Searching for OBSD rk v1... /usr/lib/security
/usr/lib/security/classpath.security
....
Searching for suspicious files and dirs, it may take a while...
/usr/lib/perl5/5.8.8/i386-linux-thread-multi/.pack list

so I wouldn't worry too much if you see something that looks iffy before you check it out (I'd have been annoyed if I just reinstalled my OS just to find the same thing happening again). It will also show your ethnet port as being in "sniffer". Anywho, best practices can minimize the risk to pretty much 0... oh, but for God's sake PLEASE switch off remote root access on ssh over default ports, ideally switch it off altogether (If you need it please learn how to use it). Ssh coupled with an easily broken root password is the single biggest cause of rootkits... and a huge /var/log/secure!

Something like this [s-t-d.org]?

Kind of bypasses the point of detection, in a way.

One cane safely ass-u-me that if the storage is disconnected, then , if You look very very close, then You could detect a rootkit. Though IF,

1. If the kit is in-mem only and subverts no system binaries and stores its support files somewhere under /home/maryjanesmith/ or somewhere on /var/www, in other words - locations with thouesand of changing files (TripWire won't work even with SHA1 or other non md5 sums)
2. Uses an unpatched hole or security lapse to activate itself (say, attacker checks if the rootkit is there, by sending some fancy ping and expecting a fancy pong, e.g.)

Then even an offline inspection can be bypassed.

Besides, I'm sure a lot of businesses will take the risk of running potentially compromised server, than incur downtime.

Now, the Challenge is: What to do, to lock down system so that it is possible to verify the kernel and some userspace against a known good state and the system always gives veritable results? I think that SELinux already does a lot of that - limits root's access. You can setup its policy so, that it will only allow executing binaries and load modules from from read-only partition. The point, is to lock down the box to such state, where only physical access allows security sensitive part modification. I know this is inconvenient,but if some Good Practices [tm] are followed, then a machine once-setup can run with config unchanged for a Year or so. Have some sort of Patch Tuesday or rely on trusted and secured binaries that allow package updated only if their strong crypto signatures validate.

On an end note, securing and maintaining a system like this with existing tools (that I am aware of) is timeconsuming and hence - expensive. So, the cost-benefit ratio might be nearing the "Let's just re-roll the system on suspected cracks" scenraio. For SMB at least.

. The system could be almost completely restored on an orderly shutdown, leaving nothing detectable but a single hook (hide everything else in swap or unused sectors in filesystem)

The only way to leave a 'hook' on any common setup is to modify the storage medium of the OS or modify the firmware of a piece of hardware. Both can be detected, and there's no way to prevent that.

MD5 hashes can be subverted, which means the above mentioned initial hook could hide (I believe this is only really useful if the hook was in the original package and you are turning it on by changing a single bit)

There is no known computationally viable way any decent hash can be 'subverted' in the manner you are implying. Changing a single bit will completely change the hash of a binary with any decent hashing algorithm. You're not going to be able to find a hash collision that provides you with a binary that is the same size as the one you are replacing and does everything you want.