December 6, 2008

Day 6 - Automating Tripwire

We need more automation-minded people writing tools. While playing with tripwire today, I saw something that made me think, how am I supposed to automate this? I don't like feeling like a useful tool can't be automated, so let's figure out how.

I'd done the basics using tripwire, so far. Creating site and host keys, creating the encrypted config and policy files, and running 'tripwire --init' to get things started. After making some changes, I ran 'tripwire --check' to see what tripwire would tell me. Things were going good until I decided to update tripwire's idea of what the current system should be, with 'tripwire --update'

The tripwire guide I was following told me what would happen, but I hadn't read that far. Tripwire launched vi and let me edit a document that started like this:

Tripwire(R) 2.3.0 Integrity Check Report

Report generated by:          root
Report created on:            Fri Dec  5 19:11:39 2008
Database last updated on:     Never
The document was full of information about what had changed on the system. I hadn't a clue what I was supposed to do, since I was only skimming documentation when I got stuck or confused, so I went back to the guide and saw:
"If any changes are found you will be presented with a "ballot-box" styled form that must be completed by placing an 'x' opposite the violations that are safe to be updated in the database."
(link to the guide this quote came from under further reading)
I have to what? Carefully hand-edit some generated output, so tripwire will know what to store back in it's truth database? How the heck do you automate this? Was this a design decision meaning automation and security were mutually exclusive? I don't think they're mutually exclusive.

The tripwire config you used when you ran 'tripwire --init' had a variable in it, "EDITOR." This was set to /usr/bin/vi. I changed it to '/bin/cat' and regenerated (tripwire --create-cfgfile) the encrypted config file and reran the update command, and instead of launching vi, the data was simply output to stdout, meaning we might be able to automate it, replacing cat with some smart script.

The data format in the file report is very clearly meant for human reading, not for computer parsing. Tripwire can parse it for its own purposes, but are you up to writing a parser? Googling for tripwire report parser doesn't show promise.

I replaced /usr/bin/nano with a shell script to see what output I should expect. Rerunning 'tripwire --check' and then 'tripwire --update', my nano change shows up like this:

[x] "/usr/bin/nano"
Leaving that box checked would mean "I know nano changed, it's ok." Writing a handler that automatically decided whether file was knowingly modified might be simple. For example, if you upgraded a package recently, most/all of the files for that package will be reported as modified/added/removed. You might be able to ask your packaging system if a file is valid. For instance, if a file is listed as modified, and you use RPMs, you could see if the file has changed since installing the RPM:
% rpm -Vf /usr/bin/nano
S.5....T    /usr/bin/nano
According to rpm's manpage, the first column means that the size, md5, and modifciation time are different on the current nano than the one that was installed by the rpm.

I'd hate to have to answer these questions every time I did an upgrade on one of my servers. Doing it once would be annoying, but doing it across all of my servers after an upgrade (how many servers would that be for you?) would be an impossible nightmare.

Since tripwire is a useful tool, you could use the verification information from rpm to automatically answer tripwire's inquiry with a script set as your EDITOR config variable. If you're especially on-top of your sysadmin practices, your systems have automated software rollouts, and if you want to use tripwire, you'll need to automate the management process.

Further reading:

Open source version of Tripwire
Intrusion Detection with Tripwire
The tripwire guide I was learning from.


Joe Topjian said...

This is brilliant.

Using Tripwire on a system has caused me to change my procedures for doing system upgrades. When an upgrade needs done, I immediately run Tripwire and auto-accept any changes so I'm not stuck in "ballot-box hell".

This sucks because it can prevent you from doing any type of automation with with system updates, too (even though IMO they shouldn't be totally automated).

I also did something similar using rpm and md5 at a previous job: we found that on some days our Tripwire reports would be massive because of Fedora doing regular prefetches on binaries. So I modified the daily Tripwire job to pass its output to a script which would verify the md5 of the binary against the rpm database. It makes your Tripwire report shrink tremendously.

Maybe I will try to get a hold of the script I wrote...

xtat said...

I'd recommend something like integrit or aide-- more free, simple, and better designed.