Intrusion Detection Systems: Re: Tripwire or alternative

[rajohnson1 () uswest net (Richard Johnson)]

Archive: http://msgs.securepoint.com/ids
FAQ: http://www.ticm.com/kb/faq/idsfaq.html
IDS: http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
UNSUBSCRIBE: email "unsubscribe ids" to majordomo () uow edu au
At 12:37 PM 7/18/00 -0400, Fernando Trias wrote:
> Centralizing information in the freeware version of tripwire is achieved 
> by emailing the reports to a central email which somebody must check every 
> day. No central console required. But it sounds like the problem is not 
> solved by centralization.
I have thought about this subject as well.  Currently, I
just look at the tripwire reports mailed to me each
day by my cron jobs running on each of the tripwire
monitored machines.  Luckily, I have a small number of
these machines to monitor and have not felt the pain
enough to take the steps that would be needed if
tens or hundreds of machines needed to be monitored.

However, if I was faced with many machines, I could imagine a
cron initiated script that would take the difference of the
tripwire output of today (this AM, this hour) with that of yesterday
(last PM, last hour) and report that on a summary report (with the
differences of all other machines being monitored with
tripwire) to the human oracle.

A perl script could pull the front matter of the tripwire report
from the mail title line through the "###".  This would make the
comparison simple but complete.  The title line might have the
name of the machine in it that sent the tripwire report.

A directory tree of the reports with subdirectories named for
each tripwire managed machine could house the tripwire reports.

The centralized report writer cron job would look like something
like this (assume that you have an account set up on your
tripwire "manager" machine called tripster):

file each tripster mail message into the appropriate subdirectory
for the machine that has sent the tripwire report
for each directory (i.e., machine in the tripwire report archive)
         find the front matter with the perl script of the latest
                 two reports in the directory
         diff these front matters, concatenating the output
                 of the diff to the summary report (to be forwarded to the
                 human oracle)
         # add automaton oracle assessment of the diff file here
         #
end for
mail summary report to the human oracle

Very little custom programming is needed, I think, for a simple
monitoring system.  A great deal of the work can be done with
standard *nix tools.  Of course, more elaborate, pro-active
systems that, for example, delegated some of the oracle work
to the cron job sketched above could be done with more effort.
I could imagine an oracle program in the commented position
of the sketched script above that would cause a machine to flash
red and its sound card to give verbal warning that "system <tripwire
monitored machine name> has been breached" ....

As was pointed out on other posts to this thread, the configuration
of the tripwire job (i.e., which directories need to be monitored)
is somewhat problematical, but with a little tuning, the most important
stuff could be monitored eliminating some of the noise entries that
can clutter the tripwire reports via correct flags and appropriate
directory selection. Certainly any dedicated, single purpose, semi-public
machine on a perimiter network would be easy to monitor with this
setup.  Machines that are being accessed constantly by humans are
more difficult, since they wander about, trying to see what is in the
system directories.