August 22, 2003
Tripwire Configured and Running
I've recently gotten my act together and brought our machines up to speed with intrusion detection. Tripwire is installed on the our servers by default (some agreement between Sun and Tripwire), and it appears that as a part of the Jumpstart procedure the initial database is generated, but the tripwire check isn't put into cron, and the machine is in such a bare bones state that the initial database is somewhat pointless.
Not having tripwire running causes unnecessary worrying, so I dedicated a few hours to getting up to speed on the Solaris install of tripwire, creating a new databases for each machine, and setting up the nightly check.
Getting the database updated was easy: tripwire -interactive
The interactive mode is a bit tedious because a lot had changed, but I wanted to make sure I was aware of everything being changed in the database since the original build.
Once that is done I reran tripwire to ensure that it would return OK, then stuck an entry in cron:
tripwire -loosedir -q
The loosedir allows a little more flexibility when checking directories and the q supresses anything but actual mismatches in the database.
The most important step came next, detecting changed in the actual database. Tripwire isn't much good if the database is on the machine in a writable format, in the instance of a compromise the attacker can simply regenerate the database. This requires some extra measures to ensure the database isn't changed. Documents I've read suggest burning the database to CD-R and using the read-only media for checks. Our servers are in another physical location so after any updates we'd have to physically go over and replace the media.
Rather than doing that we opted to copy both the database and a md5 hash onto a local machine, burn that to CD-R and run a nightly check out to each machine that compares the md5 of the database on the server to the md5 on the local CD-R. If the md5 is changed we have the read-only database to put back onto the machine to perform further analysis.
Will see if anything comes up with this arrangement, seems pretty good. Definetely better than not having it running at all.
Posted by mike at August 22, 2003 11:22 PM