Strategy for file integrity checker on linodes?
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
5 Replies
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.
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…
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