Tripwire musings

You'll all have to wait another day for another review; I have three things read but not reviewed yet waiting for me to find the time, but as I was up until 4:30am last night helping with a rollout, I ran out of time too early today.

I spent some time this evening cleaning up tripwire reports for all the systems we upgraded Kerberos software on recently, and thinking once again about how much of a pain it is and how much we need samhain or something like it deployed. We've automated our tripwire process a lot, using Kerberos and some properties of AFS and a wrapper script I wrote a while back and then improved over time. It's already a lot better than what you get with tripwire out of the box, but it still works on the level of an individual machine (with possibly shared configuration).

The big advantage of samhain is that it's a centralized server that everything reports to, so I don't have to have each system mail the tripwire reports to a central location and then use scripts to check for clean and dirty ones and maintain an archive. That also makes it considerably more secure; it's still possible to fool a central system like samhain, of course, with a sufficiently dedicated attacker, but it's a lot harder.

I've only looked at it briefly, enough to think it will work, but here's the way my ideal system would work (some security considerations ignored since it's too late to go into those details as well). There's a central coordination server that collects all of the reports. It sorts them out into clean and dirty, and also classifies systems into groups according to who runs them. Each day, it sends out a report of dirty systems to the relevant contact addresses. Administrators can go to the central web site, authenticate in some fashion, and then mark off the reports of changes that they say are fine, and samhain updates the database appropriately on the central system. They should also have some way of changing configuration files, but I'd rather that be CVS-controlled and don't really want easy buttons on the web site to say to ignore particular files, since then people don't really think about what patterns we should be looking for.

(I actually like the annoyance factor of having to edit configuration files to exclude files that are changing outside of the areas of the disk devoted to such files. It pushes people towards using FHS properly.)

Added on to that, I also want something equivalent to tripwire -update, although I can live without it. This is a way of saying "I know I just touched the following four files; please recheck them, redigest them, and just update the database with their current status without asking about it later and without rechecking the whole system." The reason why I can live without it is because I must have the simple approval of changes method for updating the database; once I have that, approving changes is fast and doesn't require rechecking the system like doing it properly does now, so it's not as much of a problem to just let the system be dirty the next night and then approve the changes.

The tricky part of deploying samhain will be getting the binary distribution down solid and getting the machine groupings and nightly reports working the way that I want. I think the web pieces and the approval is already there -- at least, I hope it is -- but I've not really looked yet.

I really want to find some time to do this, since I think the whole tripwire process can be made about an order of magnitude faster, which will then mean that more people in my group will really take the time to do it regularly. Right now, it's such a hassle that it's very tempting to skip it, since 99.99% of what tripwire picks up is legitimate changes we don't care about.

Posted: 2005-07-25 21:01 — Why no comments?

Last spun 2013-07-01 from thread modified 2013-01-04