- Trusted users
If some element in the path to the log file is writeable by someone else than root or the effective user of the process, you have to include that user in the list of trusted users(unless their UIDs are already compiled in).
- Separate log files for clients
Only relevant on the server. Use a separate log file for (reports from) each client. The root name of these log files will be the same as the main log file, with the client name appended.
The log file is named
samhain_log by default,
and placed into
/var/log by default (name and location can be
configured at compile time). If
samhain has been
compiled with the
--enable-xml-log option, it will be written in XML
If you have compiled for stealth (
Chapter 10 ), you won't see
much, because if obfuscated, then both a 'normal' and an
XML logfile look, well ... obfuscated. Use
The log file is created if it does not exist, and locked by creating a lock file, which has the same path as the logfile, with a ".lock" appended. The lock file holds the PID of the process, which allows samhain to recognize and remove a stale lock if there is no process with that PID.
On the log server, it is possible to use separate log
files for individual clients. This can be enabled with
yes/no in the Misc
section of the server configuration file. No locking will
be performed for client files (only one instance of the
server can listen on the TCP port, thus there will be no
The directory where the logfile and its lock file are located must be writeable only by trusted users (see Section 10.1 ). This requirement refers to the complete path, i.e. all directories therein. By default, only root and the effective user of the process are trusted.
Audit trails (sequences of messages from individual runs of samhain ) in the log file start with a [SOF] marker. Each message is followed by a signature, that is formed by hashing the message with a key.
The first key is generated at random, and sent by e-mail, encrypted with a one-time pad as described in the previous section on e-mail. Further keys are generated by a hash chain (i.e. the key is hashed to generate the next key). Thus, only by knowing the initial key the integrity of the log file can be assured.
The mail with the key looks like:
-----BEGIN MESSAGE----- message -----BEGIN LOGKEY----- Key(48 chars)[timestamp] -----BEGIN SIGNATURE----- signature ID TRAIL_ID:hostname -----END MESSAGE-----
To verify the log file's integrity, a convenience function is provided:
When encountering the start of an audit trail, you will then be asked for the key (as sent to you by e-mail). You can then: (i) hit return to skip signature verification, (ii) enter the key (without the appended timestamp), or (iii) enter the path to a file that contains the key (e.g. the mail box).
If you use option (iii), the path must be an absolute path (starting with a '/', not longer than 48 chars. For each audit trail, the file must contain a two-line block with the -----BEGIN LOGKEY----- line followed by the line ( Key(48 chars)[timestamp]) from the mail. Additional lines before/after any such two-line block are ignored (in particular, if you collect all e-mails from samhain in a mailbox file, you can simply specify the path to that mailbox file).