Home / server / Questions / 18302
Accepted
Slartibartfast
Asked: 2009-06-03 15:20:50 +0800 CST

Tripwire policy suggestions

  • 772

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.

linux security tripwire

3 Answers

  1. 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.

    • 5
  2. Best Answer

    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).

    • 5

  3. 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.

    • 0