Hi there,

I definitelly support Tripwire. There are two good reasons for that:
1. Tripwire has encrypted policy and configuration which makes it resillient to the insider's attack (even root may not know that private key I used to encrypt the files, so I can be sure nobody was tampering with my configuration and policy);
2. opposing to what ddaas says, I speak in favor of a standpoint that simplicity of usage is not an advantage here: i.e. intrusion detection is not an easy task at all so a more elaborated system is welcome to help me with the intricacies of such a task.

Although AIDE is certainly a tool to consider, in point 2 I was not referring to the software by itself but more to the fact that with the AIDE tool there have been no general recomendations as for the most efficient or the most appropriate policies which represent the human part of the intrusion detection intelligence. On the other hand I was able to find such prepared policies shipped with the Tripwire tool for various kinds of UNIX like systems which makes me think that guys at Tripwire inc. took this challenge in a more professional way and have developed a more mature intrusion detection art.

//Mod.note: This post got pruned from the vintage 2005 thread tripwire vs. aide.


Cool. But please note:
- Tripwire's past has been marred with licensing problems,
- there exist two versions (commercial and OSS) and both their web sites are more marketing angle than anything else,
- the oldest recorded open bug report still stems from 2001,
- the last announcement on the mailing list stems from 2007,
- the last unanswered question on the dev mailing list stems from 2008,
- the last release stems from 2011 and besides that
- I question if it does qualify as OSS as there's no public SVN or GIT repository as a way to gauge development.
If the above doesn't cause at least a shred of doubt then you may not be aware how to assess things or you may have ulterior motives... OTOH AIDE does. Their oldest open bug report stems from 2006 and it's supported and actively maintained showing a last commit date for non-trivial change of October 2012. More than that since you posted in a 7 year old thread it didn't discuss one other tool: Samhain.


So does Samhain. In contrast to tripwire or AIDE Samhain is the only active file integrity checker of the three, it can watch everything tripwire or AIDE can and more (kernel addresses, extended attributes, MAC), it can obfuscate its binary in addition to encrypting its configuration file and database and it supports the client server paradigm too being able to use encrypted traffic as well.


Look at for example policy/twpol-Linux.txt and notice that it suggests odd mount points like "/cdrom" (instead of what should reside in /mnt or /media these days), it makes assumptions wrt the used partitioning scheme (like "/var/lost+found"), then there's discrepancies in rules ("/usr/local/doc" but not "/usr/share/doc"?) and it doesn't know about directories like "/sys" or "/selinux". Is that odd? No, because if you diff the policy file from 2.4.1.2 (2007) with the one from last year you will find that in the case of twpol-Linux.txt its last modification date is September 16th 2005. In short it isn't even current, it may disregard entities you would like to or must watch and it will generate false positives. As such it can not realistically be marked as either appropriate or efficient IMHO.

1 members found this post helpful.

Thanks for extending on that matter. In general, I'm keen on everything you've said, and yes, I'm aware of the fact that Tripwire is not anymore supported as it used to be when I first met it. That may be a big drawback, however I haven't had any serious problems with Tripwire since I started using it.

Agree, policy/twpol-Linux.txt suggests odd mountpoints and a lot of odd files as well, but it is not hard for an average Linux user to see which should be the correct entries instead of the odd ones. As a matter of fact, I have quite changed policy/twpol-Linux.txt for my own needs. What I value most in policy/twpol-Linux.txt are not the odd files and other filesystem entries but the ID masks they recommend for various types of the files. With AIDE I don't get this at all.

Thank you for your valuable recommendation about the Samhain. I will certainly have a look at it and as you say is a promissing evolution for an oldtimer like me :-)