Fiddling with AIDE
Due to issues with compiling Tripwire for x86_64 (or even at all with more recent gcc versions), I’ve been playing with AIDE for two days now. Like Tripwire, AIDE is a filesystem integrity checker. Unlike Tripwire (or, at least, the GPL version of Tripwire), AIDE is in more or less active development, although the last full release was a few years ago. They’re doing development on it still, even though it’s slow.
For the most part, AIDE works well. Documentation is inconsistent, which is a problem. It doesn’t use any encryption to protect the database or configuration like Tripwire, which is a drawback, but can be somewhat worked around. All in all, after spending some time tweaking the config and also writing some helper scripts and patches to the AIDE code itself (0.11-rc2 is what I’m using), I think I could actually use this.
I solved the problem of a verifiable database by using gnupg in my helper scripts. Works fairly well; need to tweak it a bit more. The problem with AIDE is that the database is a flat-text file and someone obtaining root privs could overwrite/manipulate it their desire all they want. There is a contributed script to encrypt it with gpg, but the way the script is written you need to have gpg setup without a passphrase which is the worst kind of stupid. I mean, really, if someone can get root privs and manipulate your db anyways, encrypting it with a passphrase-less key gets you nothing. I can’t even call it a false sense of security.. if this was thought out, you’d realize it was no security at all. And with a passphrase-protected gpg key, you can’t run an “aide –check” from a cronjob or anything because you’ll need to decrypt the file before you can compare the current state of the filesystem to it.Instead of encrypting the file, I opted to have a detached gpg signature associated with it. This isn’t perfect, an intruder can still read the file. But that won’t give them much. With the helper scripts, the signature is checked before a check or before an update of the db to make sure it hasn’t been tampered with. Of course, this pretty much means you need to use the wrappers to do anything. And you don’t need to have a passphrase-less key to use it. You can verify the sig without providing a passphrase; you just need to provide one when you update the database. Which is good… it means no one can update the database without knowing the passphrase.
The big problem with this is that you can circumvent all of this by not using the wrapper scripts. This, of course, is a good reason to have the aide binary stored on a floppy or CD-ROM (along with the database). But that causes it’s own usability issues. The real saving grace here would be to have some MAC definitions involved, via RSBAC, SELinux, or whatever. Not quite ready for that yet, tho. So will have to make do with what I can… at least it will keep everyone who isn’t root out of it. It’s not perfect, and not nearly as good as Tripwire in that respect, but until AIDE gets the cryptopgraphic checks/support built-in, this is probably as close as you’re going to get (once RSBAC is involved, it would be a lot easier to protect).
That just goes to show that an integrity checker like Tripwire, or AIDE, is a good tool to have, but isn’t the be-all and end-all of a host IDS. Just another piece of the puzzle.
Anyways, hopefully they consider my scripts and patches worthwhile to add to CVS (the patches don’t do much other than pretty stuff up.. the default reporting for AIDE is kinda ugly and cramped and don’t get me started on the –help output).
