Samhain | ||
---|---|---|
<<< Previous | Configuration — samhain, the file monitor | Next >>> |
This section explains how to specify in the configuration file, which files or directories should be monitored, and which monitoring policy should be used.
samhain offers several pre-defined monitoring policies. Each of these policies has its own section in the configuration file. Placing a file in one of these sections will select the respective policy for that file.
The available policies (section headings) are:
All modifications except access times will be reported for these files.
Modifications of timestamps, file size, and signature will be ignored.
Modifications of timestamps, and signature will be ignored. Modification of the file size will only be ignored if the file size has increased.
Only modifications of ownership and access permissions will be checked.
No modifications will be reported. However, the existence of the specified file or directory will still be checked.
All modifications, including access time, but excluding ctime, will be reported (checking atime and ctime would require to play with the system clock ...).
Initialized to: report all modifications.
Initialized to: report all modifications.
Modifications of timestamps, size, and inode will be ignored. Checksums will be verified by calling /usr/sbin/prelink --verify. This policy is intended for verification of prelinked executables/libraries and/or directories containing such files. For details and further configuration options see the Section called Support for prelink>.
![]() | NOTE |
---|---|
Each policy can be modified in the config file section Misc with entries like RedefReadOnly=+XXX or RedefReadOnly=-XXX to add (+XXX) or remove (-XXX) a test XXX, where XXX can be any of CHK (checksum), LNK (link), HLN (hardlink), INO (inode), USR (user), GRP (group), MTM (mtime), ATM (atime), CTM (ctime), SIZ (size), RDEV (device numbers) and/or MOD (file mode). This must come before any file policies are used in the config file. |
Entries for files have the following syntax:
file=/full/path/to/the/file
Entries for directories have the following syntax:
dir=[recursion depth]/full/path/to/the/dir
The specification of a (numerical) recursion depth is optional (see the Section called Recursion depth(s)>). (Do not put the recursion depth in brackets -- they just indicate that this is an optional argument ...).
Wildcard patterns ('*', '?', '[...]') as in shell globbing are supported for paths. The leading '/' is mandatory.
If you want to suppress messages about the creation of certain files (e.g. rotated log files), you can use the options IgnoreAdded=/fullpath/with_some_regex_inside and/or IgnoreMissing=/fullpath/with_some_regex_inside (to be placed in the [Misc] section of the configuration files. If you want to add more regular expressions, you can use these options multiple times.
![]() | Note | ||
---|---|---|---|
The argument to IgnoreAdded and IgnoreMissing must be a regular expression that matches the full path.To test your regex before putting in samhain, you do something like this:
Once it's work this way, you can add it to your samhainrc file, but don't forget to add the full path. e.g:
This tip has been provided by jim at aegis hyphen corp dot org. |
samhain reads the file signature database at startup and creates an in-memory copy. This in-memory copy is then dynamically updated to reflect changes in the file system.
I.e. for each modified/disappeared/new file you will receive an alarm, then the in-memory copy of the file signature database is updated, and you will only receive another alarm for that file if it is modified again (or disappears/appears again).
Note that the on-disk file signature database is not updated (if you have signed it, the daemon could not do that anyway). However, as long as the machine is not rebooted, there should be no need to update the on-disk file signature database.
If files disappear after initialization, you will get an error message with the severity specified for file access errors (except if the file is placed under the IgnoreAll policy, in which case a message of SeverityIgnoreAll — see the Section called Severity levels in the chapter called Configuration of logging facilities> — is generated).
If new files appear in a monitored directory after initialization, you will get an error message with the severity specified for that directory's file policy (except if the file is placed under the IgnoreAll policy, in which case a message of SeverityIgnoreAll — see the Section called Severity levels in the chapter called Configuration of logging facilities> — is generated).
The special treatment of files under the IgnoreAll policy allows to handle cases where a file might be deleted and/or recreated by the system more or less frequently.
Directories can be monitored up to a maximum recursion depth of 99 (i.e. 99 levels of subdirectories. The recursion depth actually used is defined in the following order of priority:
The recursion depth specified for that individual directory (the Section called Defining which files/directories to monitor>). As a special case, for directories with the policy IgnoreAll, the recursion depth should be set to 0, if you want to monitor (the existence of) the files within that directory, but to -1, if you do not want samhain to look into that directory.
The global default recursion depth specified in the configuration file. This is done in the configuration file section Misc with the entry SetRecursionLevel=number
The default recursion depth, which is zero.
As of version 1.8.4, samhain will by default compare the number of hardlinks of a directory to the number of its subdirectories (including "." and ".."). Normally, these numbers should be equal. The idea here is that a (kernel) rootkit may hide a directory, but fail to "fix" the parent directory hardlink count (actually, I am not aware of any kernel rootkit that would care to fix the hardlink count of the parent directory). This is an experimental feature; if there are any problems, it can be disabled with the option UseHardlinkCheck=no in the [Misc] section of the configuration file.
Errors will be reported at the same severity as directory access errors option SeverityDirs=severity in section [EventSeverity]).
![]() | MacOS X |
---|---|
This feature is not supported on MacOS X (because the resource fork is implemented as an invisible directory, it modifies the parent directory hardlink count.) |
Some filesystems do not always follow the rule mentioned above (directory hardlink equals number of subdirectories). E.g. the root directory of reiserfs partitions generally seems to have two additional hardlinks. To account for such exceptions, you can specify exceptions with the option HardlinkOffset=N:/path in the [Misc] section of the configuration file. Here, N is the numerical offset (actual - expected hardlinks) for /path. For multiple exceptions, use this options multiple times (note that '/path N:/path2' would itself be a valid path, so using the option only once with multiple exceptions on the same line would be ambiguous).
![]() | NOTE |
---|---|
Please note that samhain will not check for an exception if the standard rule (offset = 0) is true for a directory. Thus it will not warn if a directory that once was exceptional is not anymore. |
Samhain checks for weird filenames (containing control/nonprintable characters, newlines or tabs) and warns about them at a severity level that is set with SeverityNames=severity in section [EventSeverity]. The rationale is: most of the time, such names are either the result of user errors, buggy scripts, or questionable activity. If you want to add characters to the set of 'good' ones, you can do so with the option: AddOKChars=N1, N2, ... in the [Misc] section of the configuration file. Nn should be the unsigned byte value of the character(s) in hex (leading '0x': 0xNN), octal (leading zero: 0NNN), or decimal.
![]() | TIP |
---|---|
This check will not be performed for files under the IgnoreAll policy. To completely disable this check, use AddOKChars=all. |
prelink is a tool available on modern Linux systems that can significantly reduce the startup time of applications. It does this by performing some of the work of the dynamic linker in advance. As this changes both executables and shared libraries, file integrity verification will fail unless prelink is supported, in particular as prelinking has to be redone if libraries are updated (so initializing the checksum database after prelinking may not be good enough).
The disadvantage is that prelinking modifies libraries and executables, and may need to be redone (potentially modifying all or many executables again) if a library is updated. This is a major problem for file integrity checkers.
Version 2.0 of samhain and later support prelink. To use this support, you need to place prelinked executables and libraries (or directories holding them) under the [Prelink] policy rather than under the (e.g.) [ReadOnly] policy. For all files under the [Prelink] policy, inode, size, and timestamps will be ignored (prelinking changes them). In addition, for ELF binaries under the [Prelink] policy, /usr/sbin/prelink --verify will be used to compute checksums (i.e. the checksum will be computed on the output of this command). For other files, checksums are computed as usual.
![]() | Speed |
---|---|
Obviously, invoking prelink results in a significant overhead, and slows down file integrity checking (tests indicate a factor of three - your mileage may vary). |
![]() | Verification failures (zero checksum) |
---|---|
It seems that prelink --verify fails if the dependencies of a prelinked binary have changed. This results in a zero checksum, and can be fixed by re-prelinking the affected binary. |
There are two configuration options in the [Misc] section that can are relevant for prelink support:
SetPrelinkPath=fullpath sets the path to the prelink executable. The default is /usr/sbin/prelink.
SetPrelinkChecksum=checksum sets the TIGER192 checksum for the prelink executable. You can compute this with samhain -H /usr/sbin/prelink (remove whitespace from the computed checksum). If the checksum is set, samhain will verify the prelink executable immediately before using it, otherwise prelink will be used without this special precaution.
As of version 1.8.2, reports about modified files include a short code in the message field to describe which properties have been modified. The codes are: 'C' for 'checksum', 'L' for (soft) 'link', 'D' for 'device number', 'I' for 'inode', 'H' for (number of) 'hardlinks', 'M' for 'mode', 'U' for 'user' (owner), 'G' for 'group' (owner), 'T' for 'time' (any), and finally 'S' for 'size'.
As an example, 'C--I----TS' would indicate that a file has been replaced by one with different checksum, inode, timestamp, and size, but (e.g.) same mode (type and access permissions) and same ownership.
<<< Previous | Home | Next >>> |
File signatures | Up | Excluding files and/or subdirectories (All except …) |