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.

www.tripwire.com