Linux.com

Installation from tarball is simple and well-documented. There a quite a few switches you can use before you make the executable. Consult the documentation for a complete list. A few of the more useful ones will be covered here.

Probably the neatest characteristic of samhain, which separates it from other host-based IDSes, is the stealth features. The designers have put a tremendous amount of paranoid code into this project, and a well-configured samhain installation can resist almost any subversion. We'll start with the simpliest technique, renaming all references to samhain to an arbitrary name. If an intruder cannot discover that samhain is running, he cannot compromise it.

./configure --enable-install-name=NAME

where NAME is an innocuous-sounding executable name. To be sure that the program isn't accidentally discovered, you can specify that samhain should never respond to the command line. Alternatively, you can make it respond to the command line only after a certain password is typed:

./configure --enable-nocl=PASS

If PASS is set to an empty string it disables command-line interaction completely. Otherwise, invoke samhain with PASS as the first argument followed by the other arguments.

Samhain can check for kernel rootkits on FreeBSD and Linux, and I suggest you do so if possible:

./configure --with-kcheck=SYSTEM_MAP

where SYSTEM_MAP is the System.map file for your system. On my SuSE Linux box it's /boot/System.map. For FreeBSD omit the SYSTEM_MAP argument (e.g., use just --with-kcheck).

There are many other interesting stealth options available, all documented along with the rest of the compilation switches in Appendix A of the documentation.

After the configure script does its magic, simply run make and make install. There is also a make install-boot option that adds a script to your computer to start samhain on bootup, though the script may not work on all systems.

Configuration

Samhain by default installs its configuration file in /etc/samhainrc. The configuration file is divided into several sections:

• Attributes -- files specified in this section are checked only for change in permission and ownership
• LogFiles -- files in this section are not checked for timestamp, size, or cryptographic checksum changes, because they change often
• GrowingLogFiles -- files in this section are not checked for timestamp and cryptographic signature changes and increases in file size (decreases are noted)
• IgnoreAll -- files in this section are never checked for modifications
• IgnoreNone -- these files have all modifications checked, including access time
• ReadOnly -- all modifications are checked except for access time
• User0 -- all modifications are checked
• User1 -- all modifications are checked

Files may be specified in two ways, either as file=/path/to/some/file or dir=[number]/path/to/directory, where [number] is an option defining how many subdirectories to include; up to 99 can be checked. It is not necessary to define the recursion depth. It is also possible to use wildcards, as in file=/etc/*.conf. Normal shell wildcards are allowed: "*", "?", and "..".

The documentation suggests putting a fake file (such as "tripwire") on your filesystem and checking for it in the IgnoreNone section. This will alert you if anyone pokes around and accesses that file. You will probably want to put most of your critical files (such as /etc/passwd and programs in /usr/sbin) in the ReadOnly section since they are read often. I prefer to put my log files in GrowingLogFiles in case an intruder attempts to scrub the logs. If you rotate your logs frequently you might want to put them under LogFiles to avoid unnecesary reports. I would also put samhain, the configuration file, and the database file in IgnoreNone. After samhain is started as a daemon it will not need to re-read the configuration file or the database.

The next sections in the configuration file are configuration options. The first is [EventSeverity], which tells samhain what do when it encounters a modification. Each file policy section has a corresponding line in this section, preceeded by "Severity." The line that describes the severity of the LogFiles section is SeverityLogFiles=LEVEL, the line for Attributes is SeverityAttributes=LEVEL, and so on, where LEVEL is one of these options:

• none -- Not logged
• debug -- Debugging messages
• info -- Informational
• notice -- Normal
• warn -- Warning
• mark -- Timestamp change
• err -- Error
• crit -- Critical
• alert -- Program startup/exit or abnormal termination
• inet -- Incoming messages from clients (only in server mode)

To consider any changes to the files in ReadOnly to be of the critical level, the line would look like this:

SeverityReadOnly=crit

There is also an additional severity called "SeverityNames=LEVEL," which records unusual file names or an incorrect UID/GID.

My (simple) configuration is:

SeverityGrowingLogFiles=warn
SeverityIgnoreNone=crit
SeverityReadOnly=crit

The threshold for each action performed is recorded in the next section, [Log]. There are seven logging facilities to which Samhain can address policy violations: email (via an internal SMTP engine and cryptographically signed), syslog, /dev/console, a signed logfile, a log server, an external program, or a SQL database (currently only MySQL and PostgreSQL). Each line in the [Log] section lists a logging facility and its threshold. For every violation with a severity equal to or above the threshold, a message is sent to that facility. For example, to send all messages with a critical level or higher to email and everything from info level or higher to the syslog, the section would look like:

[Log]
MailSeverity=crit
SyslogSeverity=info

Some logging facilities require configurations in the [Misc] section, described below. It is possible to only log certain classes of events. Most users will not need this level of granularity but a listing is provided in the documentation for those who do.

If you've compiled samhain to do so, you can configure it to check for SUID/SGID files in the [SuidCheck] section. The SUID/SGID check goes through the entire filesystem looking for binaries with those flags set. At initialization all SUID/SGID binaries are put in the database and any addition to these is recorded. This is useful for finding hidden root shells or unauthorized software installations. The check is very CPU- and disk I/O-intensive, so users not concerned with this aspect may not want to run the checks. There are some options for mitigating the system strain in the configuration file:

• SuidCheckActive=1 -- set to 0 to disable
• SuidCheckInterval=86400 -- interval between checks in seconds; set this high, as it is very IO-intensive
• SuidCheckExclude=/path/to/dir -- excluded directory, used to get around some Solaris bugs
• SuidCheckFps=200 -- number of files per second to check, lower this if the check is too I/O-intensive for your purposes

Next is the section for checking loadable kernel module rootkits (Linux only). The installation documentation says there is support for FreeBSD but the configuration documentation does not and I do not have a FreeBSD box on which to experiment. If you are running Linux, you probably want to set this item to 1. Otherwise, set it to 0 (or comment it out) and the checks will not be performed.

The KernelCheckInterval is measured in seconds. The ability to check for kernel rootkits depends on the System.map file specified at compile time. Installing a new kernel will likely break this portion of samhain.

[Kernel]
KernelCheckActive=1
KernelCheckInterval=20

Next is the [Utmp] section, where samhain can be configured to check for login/logout events. Set LoginCheckActive to 1 if you want to record this information, 0 if not. Unless you have a very quiet server, this option will probably create too much noise to be uesful. You also must set the severity information, which follows the same syntax as the [Log] section. The severities configurable are:

SeverityLogin=LEVEL (info, err, crit, etc.) -- user login
SeverityLoginMulti=LEVEL -- user multiple login
SeverityLogout=LEVEL -- user logout

Lastly, set LoginCheckInterval to the seconds between checks.

The last section is the [Misc] section, which contains configurations for logging facilities and options to samhain. Most users will want to add Daemon=yes to let samhain run as a daemon in the background. This is A Good Thing for two reasons. First, as a constantly running daemon samhain will "remember" filesystem changes so you will not be bothered with constant messages about the same change. Second, running as a daemon improves security over the alternative method of running via cron, since running only at intervals could give an attacker a window for malicious changes.

By default, samhain will only log a policy violation once. The violation is remembered and you are not bogged down with thousands of reports about the same changed file. The feature is very useful and samhain has a nice audit-trail function for dealing with the file changes. But if you do not want this feature enabled specify:

ReportOnlyOnce=FALSE

The default is TRUE if it is not defined.

Next in this section is the configuration for the logging facilities. The most important is the email facility, which requires the following to be defined:

• SetMailAddress=username@hostname -- separate multiple addresses with commas
• SetMailRelay=mail.domain.com -- set this if the server for the address above doesn't allow connections from arbitrary hosts
• MaximumInterval=86400 -- maximum number of second between reports, useful as a keep-alive for samhain (86,400 seconds = 1 day).
• MailSubject="%T %H %M" -- a string to be included in the subject, and may include %T (timestamp), %H (hostname), and %M (message)

If you have configured Samhain to use a log server in the [Log] section, define SetLogServer=server.address. It is possible to store the configuration file on this server as well, but this must be configured at compile time with the --with-logserver=HOSTNAME option.

Console logging can be done to any named pipe, the default being /dev/console. Up to two console devices can be logged to, using the following syntax:

SetConsole=device1
SetConsole=device2

If you are using syslog logging, you can change samhain's syslog facility:

SyslogFacility=LOG_X -- default is LOG_AUTHPRIV

If you have a network time server (NTP), specify:

SetTimeServer=address

This aids in keeping consistency for modification logins, and is helpful in case of an intrusion.

It is also possible to change the hash function used by samhain to increase its speed. Samhain uses the TIGER hash function and computes 192-bit signatures, but can be set to use SHA-1 and MD5 hashes instead. The MD5 hash will be fastest but because it has some security issues it is not used as the default. The configuration line is:

DigestAlgo=SHA1|MD5

If samhain causes too much system activity, you can lower its strain with the following configuration lines:

SetNiceLevel=15 -- sets the nice level, a higher number is a lower priority
SetIOLimit=1000 -- limits the IO to X number of kilobytes per second

Logging integrity

Samhain takes precautions to ensure the integrity of its logs. Email messages are sent with a signature computed from the message and a key, and delivered via an internal SMTP engine to avoid sendmail corruption. The key is initialized with a random number and for each email iterated by a hash chain. The random number used is shown by the configure script at compile time. The initial key is sent in the first email is encrypted with a one-time pad (shown in the output of the configure command at compile time). A message sent from one samhain installation cannot be verified using another samhain installation unless the keys match. It is possible to specify at compile time what numbers to use for the one-time pad, use the following syntax:

./configure --enable-base=N1,N2

where N1 and N2 are two numbers within the range 0...2,147,483,647. To verify the integrity of an email sent by samhain, use the command:

samhain -M /path/to/mailbox/file

When samhain is specified (in the configuration file) to use a log file, it is set to /var/log/samhain_log by default (path and filename are changeable at compile time). It will be written in XML format (necessary for use in databases) if the --enable-xml-log option is given at compile time. If you have compiled for stealth mode, the log file will be obfuscated, and can be viewed with the command:

samhain -jL /path/to/logfile

To simply verify the logfile, enter:

samhain -L /path/to/logfile

You will be prompted for the secret key, sent with samhain's first email. The key is 48 characters and a timestamp, and appears below the line "-----BEGIN LOGKEY-----". It is also possible to save that email to a typical mailbox file and give samhain the full path. It will then find the key itself. The same caveat applies to the log file verification as to the email verification -- only copies of samhain with the same key can be used to sucessfully verify.

Running samhain

Finally we come to the day-to-day use of samhain. First, initialize or update the database. If you have already initialized a database and want to update the status of files, use the update function:

samhain -t init|update

To begin checking the status of files use:

samhain -D -t check

The -D switch starts samhain as a daemon that runs in the background and watches out for policy violations. Its use is preferable to running the command from cron without that switch. The file signature database is kept in /usr/local/var/lib/samhain (though this can be charged at compile time) and should be backed up in case of accidental or malicious deletion.

When inconsistencies are found during the running of the daemon they are logged to the appropriate facilities (set in the configuration file). They are not reported a second time unless configured to do so, so each log is a snapshot of the system after every change. In case of an intrusion this allows you to see snapshots of every change the intruder makes.

After successfully configuring and running the samhain binary as a daemon all that is left for you to do is respond effectively to the log provided.

There are many more features of Samhain I have not covered in depth, including full client-server mode with encrypted communications. There is also a Web interface for controlling the client-server operation and ability to pipe data to arbitrary programs and SQL databases. All the program's features are well-documented.

Matt Lesko has worked professionally with Unix and Linux for four years. His interests include computer/network security and free software.

- Write for us - and get paid! -

Share    Print    Comments