I've setup tripwire on a debian server, and default policy had some strange settings.

# Critical devices
  rulename = "Devices & Kernel information",
  severity = $(SIG_HI),
    /dev            -> $(Device) ;
#   /proc           -> $(Device) ;

/proc is very volatile, so I've commented it out, but I guess I should put some of it content explicitly in here. I have some ideas, but I'll ask for an advice on that matter.

Other thing is /var/log :

# These files change every time the system boots
  rulename = "System boot changes",
  severity = $(SIG_HI)
    /var/lock               -> $(SEC_CONFIG) ;
    /var/run                -> $(SEC_CONFIG) ; # daemon PIDs
#   /var/log                -> $(SEC_CONFIG) ;

Again too volatile and too many false positives. Should I explicitly monitor some specified parts of it and what. Rest of /var is $(SIG_MED) and $(SEC_INVARIANT), which sounds reasonable for /var/log too.

  • What is your question? – cstamas Jun 3 '09 at 7:18
  • Should I put /prox/x instead of /proc, and what is 'x'. Same for /var/log – Slartibartfast Jun 3 '09 at 10:44
  • Slartibartfast, it looks like you never got an answer what x to fill in. You figured it out eventually? Yours – benjamin Mar 10 '11 at 4:21

I think your assumptions are okay.

There is nothing interesting in proc to watch for, and they change every time. /dev is also a good question. I used to have that line, but now with udev I am not so sure.

You still have this line, do you?

/var -> $(SEC_INVARIANT) (recurse = 0) ;

My real problem with tripwire is, that it requires regular attention to keep it up-to-date. When I had the time it worked great, but not anymore.

Maybe it is worth to take a look at Samhain. It only reports once then learns the changes. It has other great features (maybe I will extend this later).

  • Now I see sucuri's comment. This was in my edit area, but only succeeded to post a few seconds ago. – cstamas Jun 3 '09 at 15:27
  • Yes, /var is in policy – Slartibartfast Jun 5 '09 at 10:34

You know that tripwire open source is outdated and not supported anymore? Plus, its configuration is a pain and it has no centralized support.

The recommended integrity monitors that are open source, with centralized support and actively maintained are:

-OSSEC - https://ossec.github.io/

-Samhain - http://www.la-samhna.de/samhain/

-Osiris - http://osiris.shmoo.com/

I am specially a fan of OSSEC, which is the simplest,easiest to use... But try them all and see if you like.

  • 1
    No, I don't know. As a matter of fact, many security articles on the web + many answers here on SF have suggested tripwire, so this comes as a news for me. – Slartibartfast Jun 3 '09 at 13:54
  • I really don't know why... If you look at the source from 2000 and the last package on sourceforge (2007) it is all the same thing (with copyright changes). I think people keep mentioning tripwire because it was the first one out there, but not being updated, no native windows support, no centralized management should make people move to something else. – sucuri Jun 3 '09 at 14:15
  • 1
    +1 for Ossec ! Really simple and very efficient – Antoine Benkemoun Jun 3 '09 at 16:58
  • Thanks for the suggestions. OSSEC isn't part of Debian repository, so I'll probably go with one of other two, for now. – Slartibartfast Jun 5 '09 at 10:37

Checking system files against known checksums is mostly useless since rootkit started to fake file contents hence providing correct checksums. Consider focusing on intrusion detection and prevention using more modern tools like SElinux.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.