Jan 26, 2013 4 min read Debian

Installing tripwire on Debian Sid.

One security tool I use on my Linux servers is tripwire. Essentially, it hashes both a file/directory and its metadata (modify/access/creation timestamps, file size, inode, etc.) into the tripwire database. Daily (or more often) tripwire re-scans the designated filesystems and alerts the administrator of any changes. This is glossing over many of the finer points, but if a system is compromised and key files are changed the administrator is notified at the next re-scan. Tripwire shouldn’t be the only line of defense, but it can be useful as a catch-all to notify the system manager so corrective action can be taken.

this

Actually installing tripwire is very simple:
```
# aptitude install tripwire
```
The curses-based menu prompts will instruct you to create a pair of keys to cryptographically sign many files, in order to ensure their contents or metadata haven’t changed. The first tripwire installation prompt warns that these passphrases exist unencrypted for a period of time. Because of this I have elected not to enter these passphrases at this time, and will follow the instructions in twadmin(8) for creating these keys.
To generate the keys, I ran the following command:
```
# twadmin --generate-keys \
--verbose \
--local-keyfile /etc/tripwire/local.key \
--site-keyfile /etc/tripwire/site.key
```
This generated the following output:
```
Open Source Tripwire(R) 2.4.2.2.2 built for x86_64-unknown-linux-gnu

Open Source Tripwire 2.4 Portions copyright 2000 Tripwire, Inc. Tripwire is a registered
trademark of Tripwire, Inc. This software comes with ABSOLUTELY NO WARRANTY;
for details use --version. This is free software which may be redistributed
or modified only under certain conditions; see COPYING for details.
All rights reserved.

(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)

Enter the site keyfile passphrase:
Verify the site keyfile passphrase:
Generating site key: /etc/tripwire/site.key
Generating key (this may take several minutes)...Key generation complete.
Enter the local keyfile passphrase:
Verify the local keyfile passphrase:
Generating local key: /etc/tripwire/local.key
Generating key (this may take several minutes)...Key generation complete.
```
It may have said it may take several minutes to generate these keys, but it processed through very quickly on my li’l VPS. It took mere seconds to generate the keys. It actually took more time for me to select my passphrases then it did to generate the keys. The keys are nice and encrypted (the “file” command just says they’re data!). Some notes on my passphrases:
- I use keepassx to maintain my password database. It has an added feature of generating random passwords! I back up my password database religiously, and I use sshfs on all of the workstations I control to always keep the same file updated, no matter what machine I’m using. It’s great!
- I used keepassx to generate a 128 character password for the site key, and a 64 character password for the local key. I was sure to use characters from every character class (upper, lower, underscore, hyphen, space, symbols). The site key ended up being a whole 1,024 bits of entropy, and the local key was 512 bits of entropy.
- I probably should have collected fresh entropy before generating those keys, but then I’m getting really pedantic. I have unchecked that option, so it should collect fresh entropy more often, if not every time I generate a new password.
Next step is to actually configure tripwire. This is done by modifying /etc/tripwire/twpol.txt, and removing or commenting out the stuff we don’t have or need. The first step is to run this command:
```
# tripwire --check
```
This will compare the system with the current /etc/tripwire/twpol.txt, and report on the differences. On first run, I got:
```
# tripwire --check
### Error: File could not be opened.
### Filename: /etc/tripwire/tw.cfg
### No such file or directory
### Configuration file could not be read.
### Exiting...
```
I changed the following line in /etc/tripwire/twpol.txt:
```
  $(TWETC)/tw.cfg    -> $(SEC_BIN) -i ;
```
To this:
```
  $(TWETC)/twcfg.txt    -> $(SEC_BIN) -i ; 
```
Turns out that’s not right, so I reverted the change above. What I had to do was initialize the tripwire configuration file like so:
```
# twadmin --create-cfgfile --site-keyfile site.key twcfg.txt
```
That brought me to the following:
```
# tripwire --check
### Error: File could not be opened.
### Filename: /etc/tripwire/eldon-local.key
### No such file or directory
### Exiting...
```
I had to edit twcfg.txt and regenerate tw.cfg (since my local key is /etc/tripwire/local.key, not /etc/tripwire/eldon-local.key). My next problem was that the tripwire database did not exist. I entered the following command:
```
# tripwire --init
```
After entering the local key passphrase, I got the following output:
```
### Error: File could not be found.
### /etc/tripwire/tw.pol
### Exiting...
```
I generated that policy file using the following command:
```
# twadmin --create-polfile twpol.txt
Please enter your site passphrase: 
Wrote policy file: /etc/tripwire/tw.pol
```
Next I could run the initialization:
```
# tripwire --init
...lots of messages about missing /proc files, then
Wrote database file: /var/lib/tripwire/eldon.twd
The database was successfully generated.
```
I removed /proc, and a bunch of other stuff from twpol.txt, then regenerated the policy file. I then could finally run the check:
```
# tripwire --check
```
This listed a bunch of files that couldn’t be found. I removed those from the policy file (twpol.txt), regenerated the policy, reinitialized the database, and got the standard report on standard output (I won’t reprint it here because it’s rather long). Now I can modify my upgrade alias in .bashrc:
```
alias upgrade='aptitude update && aptitude full-upgrade && \
                aptitude clean && rkhunter --propupd && tripwire --check'
```
I do not run tripwire on any of my workstations or laptops, simply because I am constantly futzing with them, and getting the near-constant email warnings that there are violations, created, deleted, or modified files outside the .twd file. Here, usability trumps security, in the ever-constant stuggle.

Trey Blancher

Comments ( )

You might also like...

Comments ()