Thursday, August 23, 2007
Wednesday, August 22, 2007
Class Note
Labs 18-23
Tripwire
Tripwire is a form of intrusion detection; like the secret agent trick of putting a hair on the doorknob, it lets you know if somebody's been doing things inside your system, however only *after* the break-in. It creates a 'secure' (normally kept on a read-only disk/diskette along w/ the tripwire executable) database of file and directory attributes (including, if you want, complex MD5 and snefru signatures) which then can be used to compare against to see if a file or directory has changed somehow. If a cracker has broken in and replaced your /bin/date file w/ a trojan horse version, tripwire will let you know. Normally, tripwire is run from cron and the output is sent to an admin user. The configuration file allows you to tell tripwire what files and directories to keep track of and to what level of detail do you want to watch. The level of detail is controlled by 'ignore flags.' For instance, a log file should continue to exist, though it may change in size (s), access time (a), modification time (m), inode creation time (c) and content (the signatures, 1 & 2). The permissions and file mode (p), inode (i), number of links (n), owning user (u) and group (g) shouldn't change so the config file entry would be:
/etc/dumpdates +pinug-samc12
Because this is a common set of requirements, there is a shorthand version or "template" for this:
/etc/dumpdates L # L for log file
The templates:
R : [R]ead-only (+pinugsmc12-a)
L : [L]og file (+pinug-samc12)
N : ignore [N]othing (+pinugsamc12)
E : [E]verything (-pinugsamc12)
(these can be further modified, e.g.:
/etc/dumpdates L-ug # L for log file
which'd remove the uid/gid watch on dumpdates, i.e.:
/etc/dumpdates +pin-ugsamc12 # L-ug for log file
)
There are 2 other config file directives, prune inclusive (!) and directory only add (=). Thus:
! /etc/ntp.drift
means skip the /etc/ntp.drift file altogether (otherwise, from an /etc entry, it would be checked). The directory only option:
=/tmp L
means just /tmp, not any of the files or subdirs of /tmp
There are also a number of conditional stmts, which allow you to use 1 config file for multiple machines. I'm not going into that.
To start up tripwire, make up a config file and run:
./tripwire -c config.all -init
This will create the database from scratch. This is how you start using tripwire, but ... if you've *already* got a bad file (say .pacer302.pl) on your system, tripwire won't be much help. That's why this is something that's supposed to be applied as soon as you build the system.
You should see:
Tripwire(tm) ASR (Academic Source Release) 1.3.1
File Integrity Assessment Software
(c) 1992, Purdue Research Foundation, (c) 1997, 1999 Tripwire
Security Systems, Inc. All Rights Reserved. Use Restricted to
Authorized Licensees.
### Warning: creating ./databases directory!
### Phase 1: Reading configuration file
the ./databases dir will be built in the current dir, this is the file you'll need to be moving someplace secure at some point. The file name will probably be:
tw.db_
that is:
tw.db_pmwiwb
There's a -d option for tripwire for the full path and file name to the database file. That is how you should specify it in your crontab entry:
/var/tripwire/tripwire -c /var/tripwire/config.all -d /var/tripwire/databases/tw.db_pmwiwb
where you've secured /var/tripwire (a ln to the floppy drive w/ a RO floppy?).
Then you'll probably see (esp. if you start w/ somebody else's config):
### Phase 2: Generating file list
./tripwire: /.rhosts: No such file or directory
./tripwire: /etc/utmp: No such file or directory
etc. etc. You'll need to find out why the files don't exist; either they're someplace else or you don't have them. I just comment out the ones I don't really have, and then re-run the -init. This rebuilds the db.
Then you can run tripwire for real:
./tripwire -c config.all
If something has changed, you'll see output like:
changed: -rw-rw-rw- root 40752 Oct 30 22:18:41 2000 /etc/powerchute/powerchute.dat
/etc/powerchute/powerchute.dat
### Phase 5: Generating observed/expected pairs for changed files
###
### Attr Observed (what it is) Expected (what it should be)
### =========== ========================== ========================
st_size: 40752 36360
st_mtime: Mon Oct 30 22:18:41 2000 Fri Oct 27 15:28:39 2000
st_ctime: Mon Oct 30 22:18:41 2000 Fri Oct 27 15:28:39 2000
md5 (sig1): 0 03NWdKEh1tZPFQmraud9qz
snefru (sig2): 0 3CR52h.4JIqVgGd5hqhRwV
by setting the config entry to:
/etc/powerchute/powerchute.dat +pinug-samc12
or:
/etc/powerchute/powerchute.dat L # L for log file
tripwire would ignore the size, atime, mtime, ctime, md5 and snefru changes on the file. If the ownership, permissions etc. changed, you'd still be notified.
Its up to the admin reading the email (or, for the really worried, the printout. A really good cracker could get rid of an email msg, but if the tripwire output goes straight to paper, they'd have to have physical access to destroy that) to decide if this was a person altering the file or, as in this case, just a log file being updated normally. In the latter case, it'd be a sign that you need to go back and fix the config file for this entry and then update the database.
You can update the db for a single file or dir by:
./tripwire -c config.all -update /etc/powerchute/powerchute.dat
This would update the db both for a change in the config file or if you'd added/changed powerchute.dat. This brings up the next point: once you start w/ tripwire, you need to update it each time you add, delete or change any file or dir that it is keeping an eye on. There are a couple ways to do this; as above, or:
./tripwire -c config.all -interactive
which will ask you what to do w/ each file it finds altered, created or deleted.
Once you get an "all okay" msg, you can stick the command in cron and run it for a while. Things will probably turn up, so once it seems stable, move the mess to the secure drive. We'll go over that once we do it
Bottom line: if you'd gotten tripwire installed and configured before the rptfile=pipe crack, this'd be one way to have detected it. After the fact, this wouldn't help. It will however, keep any new attacks like these from succeeding.
11/00 afb andy@wiwb.uscourts.gov