Hi -
A few questions about configuring Tripwire (BTW, I am using the "academic release" version on various Linux, FreeBSD and OpenBSD boxes, which are configured as single-function servers [i.e. www servers, firewalls, database servers, etc.]): 1. When creating the policy file that instructs Tripwire which files/directories to keep checksums on, which directories should I specify? The docs and howto's generally advise you to exclude the /tmp and /var directories, since the contents of these directories are constantly changing. Since attackers know this, wouldn't they store the files and binaries they want to keep on the system in those directories and thus avoid detection by tripwire? 2. Some tripwire docs and howto's advise adding a line to crontab that will automatically run tripwire regularly (hourly, daily, etc.) and email the results to the sysadmin. If an attacker roots your box, he/she will undoubtedly check for such a line in crontab, and take the necessary steps to avoid being detected, such as doctoring the tripwire binaries or database so that rootkits, trojans, etc. will not be reported back to the sysadmin. The docs advise storing the tripwire binaries and database on a read-only media such as a cd-r to prevent them from being tampered with, but this does not prevent the shell script run by cron from being doctored to send an "all ok" email to the sysadmin. Also, the fact that tripwire files and their associated cron job exist on the box will alert the attacker to be extra cautious. The solution I use is: 1. Install/configure OS and server apps on the box. By doing a fresh install, the box is in a "known" state, and we have some confidence that it is secure and not compromised. 2. Configure the tripwire policy file to check *every* file on the box, including those in /var, /tmp, and any other directories that may contain files that are frequently created/updated/deleted. 3. Create the initial tripwire database, create a tar file that contains the tripwire binaries and database, copy the tar file to another trusted server, and delete the tripwire files from the new box. 4. Put the new box online and into production. 5. Periodically (via cron on the "other" trusted server), run a shell script (or perl or whatever) that does the following: a. use scp to copy the tar file that contains the tripwire binaries and database to the "new" server, b. use ssh to connect to the new server and run a script (contained in the tar file) that runs tripwire and stores the output in a text file, c. use scp to copy the tripwire output file back to the trusted server, d. use ssh to connect to the new server and delete the tripwire binaries, database, output report, script, and any other tripwire-related files, and e. on the trusted server, run a program that will analyze the tripwire report that was copied from the new server and send an email to the sysadmin if any suspicious activity is detected. This approach can be used to monitor multiple boxes. The scripts could also run other programs, such as chkrootkit, and could collect the output from a log watcher program (and do other security-related stuff, as well). The main problem I see is that if the box that stores all the tripwire databases gets rooted, and the attacker messes with the tripwire databases, etc., then you're screwed. Can anyone see any problems with this approach? Thanks - JC __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com
