Chapter 5. Configuring samhain, the host integrity monitor
Prev   Next

Chapter 5. Configuring samhain, the host integrity monitor

Table of Contents

1. Usage overview
2. Available checksum functions
3. File signatures
4. Defining file check policies: what, and how, to monitor
4.1. Monitoring policies
4.2. File/directory specification
4.3. Suppress messages about new/deleted/modified files
4.4. Dynamic database update (modified/disappeared/new files)
4.5. Recursion depth(s)
4.6. Hardlink check
4.7. Check for weird filenames
4.8. Support for prelink
4.9. SELinux attributes and Posix ACLs
4.10. Codes in messages about reported files
4.11. Loose directory checking
4.12. Storing the full content of a file
4.13. Who made changes to a file?
4.14. Skip checksumming for particular files
4.15. Graceful handling of log rotation
4.16. No such user/group
5. Excluding files and/or subdirectories (All except...)
6. Timing file checks
6.1. Using a second schedule
7. Initializing, updating, or checking
8. The file signature database
9. Checking the file system for SUID/SGID binaries
9.1. Quarantine SUID/SGID files
9.2. Configuration
10. Detecting Kernel rootkits
11. Monitoring login/logout events
12. Checking mounted filesystem policies
13. Checking sensitive files owned by users
14. Checking for hidden/fake/missing processes
14.1. Example configuration
15. Checking for open ports
15.1. Options
15.2. Example configuration
16. Logfile monitoring/analysis
16.1. Event Correlation
16.2. Reporting non-occurence of an event
16.3. Reporting bursts of similar, repeated events
16.4. Options
16.5. Example configuration
17. Checking the Windows registry
17.1. Options
17.2. Example configuration
18. Modules
19. Performance tuning
20. Storing the full content of a file (aka: WHAT has changed?)
20.1. Example configuration
20.2. Implementation details
21. Inotify support on Linux (instantaneous reports, no I/O load)
21.1. Example configuration

The samhain file monitor checks the integrity of files by comparing them against a database of file signatures, and notify the user of inconsistencies. The level of logging is configurable, and several logging facilities are provided.

samhain can be used as a client that forwards messages to the server part ( yule ) of the samhain system, or as a standalone program (for single hosts).

samhain can be run as a background process (i.e. a daemon), or it can be started at regular intervals by cron.

[Tip]Tip

It is recommended to run samhain as daemon, because

  • samhain can remember file changes, thus while running as a a daemon, it will not bother you with repetitive messages about the same problem, and

  • using cron opens up a security hole, because between consecutive invocations the executable could get modified or replaced by a rogue program.

1. Usage overview

To use samhain, the following steps must be followed:

  1. The configuration file must be prepared ( Section 4 , Section 1 , and Section 11 for details).

    • All files and directories that you want to monitor must be listed. Wildcard patterns are supported.

    • The policies for monitoring them (i.e. which modifications are allowed and which not) must be chosen.

    • Optionally, the severity of a policy violation can be selected.

    • The logging facilities must be chosen, and the threshold level of logging should be defined To activate a logging facility, its threshold level must be different from none.

    • Eventually, the address of the e-mail recepient and/or the IP address of the log server must be given.

  2. The database must be initialized. If it already exists, it should be deleted ( samhain will not overwrite, but append), or update instead of init should be used:

    samhain -t init|update

  3. Start samhain in check mode. Either select this mode in the configuration file, or use the command line option:

    samhain -t check

    To run samhain as a background process, use the command line option

    samhain -D -t check

Prev   Next
12. SQL Database Home 2. Available checksum functions