Being a bit paranoid after losing two systems to virii back in November (which came in from a script kiddie trying to set up trojans), I've installed tripwire in addition to full iptables firewalling. However I simply started with the default policy file, which seems tailored to Red Hat while I'm running Mandy 8.1, and which seems to pick up lots of routine activity as being suspicious. I've removed references to things I don't have installed, such as Apache and telnet, but it's still awfully noisy with what appear to be false alerts. For instance, any change of the *.pid files in /var/* shows up as a security violation.

It's also giving alerts about /lib/dev-state/* which seem to change any time I have to re-boot.

Even more annoying, every time logrotate archives the logs, I get an alert. I'm getting so many alerts now that I fear I'll miss a real problem, hidden in this noise.

I'm looking for ideas from people who use tripwire, as to which files and actions should be monitored, and what should be checked in addition to the checksum and MD5 values.

Strangely enough, one of the alerts I'm getting deals with /proc/scsi being missing -- but I've never used scsi on this system to my knowledge, and hadn't done any hardware configuration for weeks prior to the last update of my policy database. Would this indicate that someone might have modified my database without my knowledge? Nothing else suspicious seems to be showing up, but of course a rootkit could easily mislead all my reporting actions (rpm -V, logcheck, and Mandy's own msec package)...

Portsentry shows that I'm getting probed around 3 times per day on average (I'm on line 24*7 with an open FTP server for use by my customers, which makes my system almost a honeypot), but it seems quite effective at blocking the offending addresses, and both the grc.com checkout and the dslreports.com scanner show no visible ports except for TCP:21. FTP logs don't show any successful suspicious activity; I keep tight control of write permissions. Anybody have any ideas?

/* I'm not using Tripwire anymore, but Aide. */

Anyway, to exclude /proc for example you could add something like:
!/proc
to your policy and rebuild the database.
If you want to exclude subdires try:
/opt
!/opt/rootkits
This basically could apply to all stuff that's not under your control. /Proc isn't static, PIDfiles change and do not indicate malicious activity per se, etc, etc.

Btw, you do save an off-site copy of the databases on read-only media, right?..

Quote:

This basically could apply to all stuff that's not under your control. /Proc isn't static, PIDfiles change and do not indicate malicious activity per se, etc, etc.

One of the things I'm looking for in this thread is a list of such things; I'm pretty new to Linux (just since this past November) although I used MULTICS back in the pre-Unix days (1967-75) so the basic ideas are familiar but the details are not.

It may or may not be related directly, but I've created Samba shares to my /etc and /var/log directories so that I can examine them from any of my 5 LAN workstations -- and when I view (NOT change) things in the /etc directory from a Win98 box, tripwire then reports a change in the "change date" although the "modification date" remains constant. How do these two dates differ, and how can I prevent having to rebuild my database after each look at /etc from another station?

My plan is to get the databases stored off-line but first I have to get them stable enough to be usable. Meanwhile, I'm getting approximately the same set of alerts each day, which I interpret to mean that nothing changed from one day to the next since I'm not updating the database daily...

How does Aide differ, and where can I find it? If it's better, I'll switch!

Well, system-wide necessary stuff under /etc, /boot, system binary and support dirs should have stable content, like local additions under /usr/local, and stuff under /tmp, tmp /var should contain temporary content or content subject to (freq) changes, like /var/log, /var/ftp, /var/named etc, etc.
From what you reported, I believe Trippy reports changed *modification or access* time to you, not *change* time, so if Tripwire permits, you should try to change your config to detect only changes in *change* time (for those files if possible), at least Aide supports that...
Running a lot chrooted, having patched down a lot in the kernel using GRSecurity patches and using Linux Capabilites to remove -CAP_SYS_MOD and -CAP_SYS_RAWIO (last one bites reboots, watch it) I'm willing to live with having different configs, like for system binaries, local binaries, etc, etc, this has the benefit of cutting down checktime on regular runs, focussing on the necessary stuff only, and provide enuff coverage to scan the hell outta this Russian Roulette :-]

Diff Aide Tripwire? Hmm. I choose Aide cuz it allowed me more finegrained configs. This could also mean I never learnt to config Tripwire decently... :-]

Well, I did a lot of research today, grabbed a copy of Aide 0.8 from the horse's mouth, and then re-did my policy and configuration files for Tripwire to see if I can control it first...

It's detecting both the mtime and the ctime for some files, and it's the ctime that changes when I access files via Samba from Win98 but the mtime stays the same as do both the checksums. That makes me think it's some sort of Samba or vfat anomaly (I have Samba configured so my Windows login gets root privileges on the Linux files and that might have something to do with it; I've also found other strangeness in the vfat file system in that I cannot "mv OLDFILE oldfile" to make filenames lower-case. The shell replies that I cannot mv a file to itself! I have to add a couple of characters to the name, then repeat the mv to take the added characters off).

My immediate solution was to simply remove those files from being tracked, since they weren't critical to system security. Eventually I'll have to do a full re-install and lock everything down before getting back on line with it, but before I take that step I want to optimize my setup for maximum paranoia <g>...