[shrip] Actually the same thing keeps baffling me. Something like this is so obvious (espl to attackers who will be looking for things like this). But maybe the idea here is to detect atleast 80% of the attacks, since most of the "automated" ones, usually fool around with the system directories. So a file integrity checker would be able to detect these. But here again is the problem of real time detection... whats the point if you discover that a possible worm has been installed on you computer 4-5 hrs after it has been??? This is a severe flaw with "offline" file integrity checkers like tripwire. I have yet to see an "online" file integrity checker (actually that would be equivalent to a file MONITOR). Maybe another purpose of the integrity checker would be to see if someone has tampered with your files, say if your server is a web server, a file integrity checker would detect if your website has been defaced (provided you have added that directory to the profile). Again offline is a problem. I also don't quite understand what tripwire has to do with those billions of parameters it stores. Also, tripwire goes heavy on the system resources when it does perform an integrity check.
Shripal Meghani Senior Software Engineer nSecure Software (P) Ltd. |-----Original Message----- |From: John Christopher [mailto:[EMAIL PROTECTED]] |Sent: Friday, December 28, 2001 8:34 PM |To: [EMAIL PROTECTED] |Subject: tripwire config | | | |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 |
