Hi all, I am trying to lock down my linode and already done a buch of adjustements. Among others, I have tiger running periodically integrit as file integrity checker: I am wondering what would be a good strategy to store known hashes and integrit binaries to prevent their modification?

I was wondering if creating and mouting a read-only device (e.g. as /readonly) in my linode configuration wizard would be sufficient? Is there anyway that intruders that gained shell access will remount the device with rw?

Cheers,

~pimu

I suggest storing the checksums off of your linode, and have them protected on the other machine. Somone rooting your box would be able to remount the device rw.

You probably know this, but modern versions of tripwire can lock the database with a key, so it's relatively safe locally. I think tripwire's licence is slightly evil these days, but aide is a drop-in replacement that may have the same functionality - and samhain is a much larger package that covers the same and more ground.

I'm going to retract my earlier statement. It is quite possible that setting a device readonly in LPM would prohibit it from being remounted rw. On a normal unix machine, HD's can be mounted ro and then remounted r/w (every time you boot this is done to /), however if done via LPM then the device may very well be treated as a hardware readonly device.

I suppose the easiest answer is to try it :>

Using a key to encrypt the tripwire database is a good idea, however if your box is rooted and the tripwire database is deleted then it still doesn't help much. The tripwire binary could be trojaned as well to capture the key and not report the rootkit.

Very true jhm - if they delete it, it's gone. However at least that night's tripwire will alert you that you've been compromised, and we all reinstall if compromised, right! But yes, it wouldn't help you recover the audit trail of how you were compromised.

Surely if you create a readonly drive on a Linode, it needs a reboot to make it writable? Not that I've tried, but I presume. This would mean you'd need to reboot whenever you updated... anything unless you had a tolerance for long reports of false positives.

I sometimes use old tripwire by writing checksums to a remote NFS mount that was readonly: and having another restricted area that was writable on the same remote server (by root) for changed databases. That way, root on the remote server was required to "activate" (i.e. mv) the checksum databases into place for the next night's tripwire run. But as ever, caveat NFS - wouldn't want to do this with a linode unless I had a VPN I really trusted between my Linode and me...

Ideally, I would run file integrity check from a remote host storing both binaries and database (over ssh). However, this is not possible for me.

I created a read-only device in LPM and, as pointed out by jhm, it is apparently treated as hardware read-only. To update integrit and its DB, I need to change disk settings in LPM, reboot the linode, apply changes to /readonly (after remounting r/w), set the device back to r/o in LPM, and finally reboot.

One word: painfull, but works for me since I have a rather small system (mail and svn server) that does'nt get updated very often. I am just keeping track of what have been updated recently (through the cron-apt reports) and analyse integrit report consequently.

~pimu