GPL host-based intrusion detection system. Rather than just comparing files with
a known-good database, samhain can perform centralized monitoring with encrypted
TCP/IP communications, log to SQL databases, compute cryptographic checksums of
configuration files, use stealth mode to disguise itself from intruders, and
detect kernel rootkits. It offers a Web interface should you decide to use it in
client-server mode.
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.
Category:
- Security
