1. Log analysis/monitoring: Logdog/Logsurfer+/Logwatch
2. Rootkit/bot monitoring: rkhunter + chkrootkit
3. Preemptive Firewalling: Denyhosts
4. HIDS:
   1. Tripwire & AIDE
   2. Tripwire w/ tripwire monitoring & centralized control (OSSIM server)

• Baseline configs stored in subversion for quick installation to provide basic protection.
• Configuration finetuning over an extended period (ca. 2 hrs./month per server).
• Centralized Syslog server w/ Logdog monitoring (incl. Syslog ping from remote servers).
• Protection of Tripwire/AIDE DB & policies (see below).
• Special Security mail address for all Security targeted mails.

Protection of Tripwire, such that any attempt to change its configuration by a cracker would be detected, remains a problem, even when a Tripwire itself is protected by a read-only disk. Every protection one can imagine for Tripwire can, of course, be defeated. However, the fact remains that from the time that a cracker gets root on a system, until he shuts down cron or otherwise defeats Tripwire, there is a race in time. This means that a small, specialized system monitoring tool dedicated purely to Tripwire protection which is non-cron-dependent, runs frequently, and is camouflaged to the greatest extent possible, is probably the best bet for winning that race-in-time with a cracker.

The minimum requirements that a comprehensive Tripwire monitor would need, are:

1. It should be written in a compiled language to make details of what it does difficult for a cracker to ascertain.
2. It should run at a frequent interval as a daemon that is not dependent on cron.
3. At startup, it should register with a daemon on a secure host, via an encrypted channel, and check in with that host everytime it runs, so that an alarm can be raised if it disappears.
4. It must verify the signatures of important system files on which Tripwire depends (e.g. cron and sendmail binaries, and config files which they require), as well as signatures of files in the Tripwire binary directory.
5. It must verify that important system daemons (e.g. cron and sendmail) are running.

• Optional

1. It must verify that a switchable rw/ro disk, if present, was not accidentally left in rw mode by a careless administrator.
2. It must detect network outages or route loss that would prevent it from reporting via the default network method.
3. In cases where normal network communication appears to have been lost, it must have a device that is close to write-only from the standpoint of the system CPU (e.g. split-screen system console, raw communication device which cannot be unconfigured, local printer, logging of the console serial line to a remote console manager) in which to log an alarm.

• INotify is, as of Kernel version 2.6.13, available and enabled in most delivered kernels.
• IWatch is a perl script that is available as a package in most distros and installable from source on all perl enabled systems.
• Compiling IWatch to a binary executable is a negligible act.
• Point #2 of the requirements above is currently available in IWatch.
• Points #1,3,4 and 5 are trivial to implement in IWatch.
• IWatch, once running, can monitor it's own binary and config files as well.