After setting up your operating system from a trusted source (for example, using a CD-ROM provided by the vendor), your newly installed host is in what is called a known good state. It is now, before bringing it online and exposing it to live traffic, that you install and configure your favorite file integrity checker.
Install your file integrity checker on a host in a known good state.
Distributed through Samhain Labs, the source archive of this file integrity checker comes embedded with its detached GPG signature. The first thing to do is to verify the GPG signature's validity. After having imported Samhain's Lab GPG key (available through its web site) to your local keyring, run the following commands and look for the "Good signature from Rainer Wichmann" line:
[emoret@simca-1000 src]$tar zxvf samhain-current.tar.gzsamhain-2.2.1b.tar.gz samhain-2.2.1b.tar.gz.asc [emoret@simca-1000 src]$gpg --verify samhain-2.2.1b.tar.gz.asc samhain-2.2.1b.tar.gzgpg: Signature made Tue 20 Jun 2006 01:12:04 PM PDT using DSA key ID 0F571F6C gpg: Good signature from "Rainer Wichmann <rwichmann@la-samhna.de>" gpg: aka "Rainer Wichmann <rwichmann@hs.uni-hamburg.de>"
To secure Samhain, I usually like to sign my configuration and database files with GPG. As it turns out, Samhain provides native verification of those signatures. All you have to do is to include support for gpg at build configuration time. In my setup, I like my GPG public key to be imported in the root account local keyring, while keeping my GPG private key in the private keyring of my local user. With this setup, you must use sudo to execute GPG operations requiring your private key and at the same time have write access to root-owned files (configuration and database).
The next step is to make sure that your GPG key was used to sign those files. Samhain allows you to specify the key fingerprint that is used to verify signatures.
Raising the bar even higher for attackers, it is also possible to embed GPG's hash inside Samhain's binary. The problem with this approach is that Samhain needs to be recompiled every time GPG is updated and, because I like running automated updates, it is just impractical in my regular usage.
Samhain runs in userspace. In other words, it relies on a trusted kernel. As such, it is theoretically possible for an attacker to subvert the system and insert a kernel-level rootkit (see Chapter 12) that could hijack system calls and return answers especially crafted to make Samhain believe there were no changes to the filesystem. To lower this kind of risk, Samhain provides two extra features:
Tracking of kernel functions address entry points by embedding five kernel-specific characteristics from the System.map file in the GPG-signed configuration file.
Hiding its own presence on the system by loading a special kernel module. This module hides any directory, filename, or process that includes the name Samhain. It also provides a self-hiding option.
While the kernel-hiding feature may seem desirable, I find it actually quite dangerous to run on production machines due to a stability issue. On kernel 2.6, it is impossible to unload this kernel module outside of rebooting the host.
As you will see in Host Monitoring in Large Environments with Prelude-IDS, using a centralized management server can be a great benefit. That is why I like to add the Prelude build option. You need to install Prelude prior to building Samhain if you want support for that feature.
Here is what you need to do to get all this configured.
Retrieve your GPG public key fingerprints with:
[emoret@simca-1000 samhain-2.2.2]$gpg —fingerprintemoretpub 4096R/DBC967BC 2005-05-11 Key fingerprint =47ED 22F9 51D9 BA85 E235 265F 8448 D230 DBC9 67BCuid Eric Moret <emoret@juniper.net> uid [jpeg image of size 3434] sub 4096R/B69AF904 2005-05-11
Reuse the fingerprint of the last command as a parameter to the configure build script.
[emoret@simca-1000 samhain-2.2.2]$./configure \--with-gpg=/usr/bin/gpg \--with-fp=47ED22F951D9BA85E235265F8448D230DBC967BC \--with-checksum=no \--with-kcheck=/boot/System.map-2.6.17-1.2157_FC5\--with-prelude \--enable-suidcheck \--enable-login-watch[...] samhain has been configured as follows: System binaries: /usr/local/sbin Configuration file: /etc/samhainrc Manual pages: /usr/local/man Data: /var/lib/samhain PID file: /var/run/samhain.pid Log file: /var/log/samhain_log Base key: 1081515965,540024950 Selected rc file: samhainrc.linux
Save the two Base key integers.
In case you recompile Samhain, you want to keep the two integers referred to as base keys because they are used to verify authentication of email messages. In other words, a version of Samhain built with a given set of base keys is not able to verify the authenticity of messages generated with a different set of base keys.
Below is the first email sent by Samhain:
-----BEGIN MESSAGE----- [2006-07-27T15:39:35-0700] simca-1000.secteam.juniper.net ALERT : [2006-07-27T15:39:35-0700] msg=<LOGKEY>, program=<Samhain>, hash=<3B6C8BD6C364F9F74837F7D9BA8A189B67EF1ED71CAD4D8D> -----BEGIN LOGKEY----- 3B6C8BD6C364F9F74837F7D9BA8A189B67EF1ED71CAD4D8D[2006-07-27T15:39:35-0700] -----BEGIN SIGNATURE----- 16F2F26D78C8B0EB8E1A74DDF44A870182FF062873B27B0D 000001 1154039974::simca-1000.secteam.juniper.net -----END MESSAGE-----
Regarding my GPG keys setup, here is what works best for me:
Import your public key in root's GPG public keyring.
Leave your passphrase-protected private key in your own user's private keyring. Configure GPG to keep your secret keyring on a mountable USB device.
When signing files, just use sudo, which will use the private key from your local user account and at the same time provide root-equivalent read/write access to files that need to be signed.
Installation is as simple as:
[emoret@simca-1000 samhain-2.2.2]$sudo MAKEDEV /dev/kmem[emoret@simca-1000 samhain-2.2.2]$sudo ./kern_head > sh_ks.h[emoret@simca-1000 samhain-2.2.2]$make[emoret@simca-1000 samhain-2.2.2]$sudo make install; sudo make install-boot
You are asked to enter your GPG key passphrase for signing the initial configuration file.
Before closing the Samhain installation section, I recommend you take advantage of some of the various scripts contributed by users and located under the scripts subdirectory:
To automate Samhain's logs rotation:
[emoret@simca-1000 scripts]$ sudo cp samhain.logrotator /etc/logrotate.dTo GPG clear sign your configuration and database files with a single command:
[emoret@simca-1000 scripts]$ sudo cp samhainadmin.pl /usr/local/sbinTo update the function addresses embedded in the configuration file with a single command (it has to be done following a kernel update):
[emoret@simca-1000 scripts]$ sudo cp samhainrc_update.sh /usr/local/sbinThe configuration file located under /etc/samhainrc is fairly self-explanatory. I recommend reading it and making appropriate changes based on your setup. Things to look for include:
Files to be checked or ignored. Ignoring a directory is achieved by preceding its path with the number −1.
Email configuration:
SetMailAddress=emoret@juniper.netExtra checks including SUID files, kernel rootkits, login/logout activity, and more are enabled by uncommenting their respective sections:
[SuidCheck] [Kernel] [Utmp]
To include the kernel checkpoints in the samhainrc configuration file, you should issue the following:
[emoret@simca-1000 ˜]$sudo samhainrc_update.sh -u /boot/System.map-2.6.17-1.2157_FC5
The preceding should be exercised every time a kernel update is done on the system.
In order to avoid some false positives mentioning the IDT interrupt, you may want to disable the Interrupt Descriptor Table check by adding the following line to the [Kernel] section of the configuration file:
KernelCheckIDT=noAfter making all the required tweaks to samhainrc, re-sign your configuration with:
[emoret@simca-1000 ˜]$ sudo samhainadmin.pl --create-cfgfileBecause Tripwire focuses on its commercial product, installing the free version of the software on a modern distribution running GCC4 is unsupported, but not impossible. Here are the things I had to do on Fedora Core 5:
Grab the latest Tripwire sources from SourceForge. Google for the GCC4 patch called tripwire-2.4.0.1-gcc4_build_fixes-1.patch. Apply and build:
[emoret@simca-1000 src]$tar jxf tripwire-2.4.0.1-src.tar.bz2[emoret@simca-1000 src]$cd tripwire-2.4.0.1[emoret@simca-1000 tripwire-2.4.0.1]$patch -p1 <../tripwire-2.4.0.1-gcc4_build_fixes-1.patchpatching file tripwire/tripwire-2.4.0.1-gcc4_build_fixes-1.patch [emoret@simca-1000 tripwire-2.4.0.1]$patch -p1 <./tripwire/tripwire-2.4.0.1-gcc4_build_fixes-1.patchpatching file src/fco/fconame.h patching file src/fco/fcosetimpl.h patching file src/tw/fcoreport.h [emoret@simca-1000 tripwire-2.4.0.1]$./configure; make
For the installation scripts to work correctly, create an install symlink to the contrib directory:
[emoret@simca-1000 tripwire-2.4.0.1]$ln -s contrib install[emoret@simca-1000 tripwire-2.4.0.1]$sudo make install
Follow onscreen instructions and accept the license. You will come to the interactive key creation script. Tripwire uses two sets of keys to encrypt and sign the following files:
/usr/local/etc/tw.cfg
/usr/local/etc/tw.pol
/usr/local/lib/tripwire/$(HOSTNAME).twd
The site key is used to sign and encrypt files potentially shared across multiple hosts (e.g., configuration and policy), while its local counterpart is reserved for host-specific files (typically the database).
Before terminating, the installation script creates and signs sample configuration and policy files. It also leaves behind plain-text versions of both files that should be removed for production.
Remember to manually remove the twpol.txt and twcfg.txt files.
Only root should be able to read the configuration and policy files. Make sure this is the case with:
[emoret@simca-1000 etc]$ sudo chmod u=r,go=- tw.cfg tw.polBy default, Tripwire reports a directory modification when a file within that directory was changed. I usually like to remove this level of redundancy and make my reports easier to read by tweaking the configuration file. If you removed the plain text configuration as recommended earlier, extract it with:
[emoret@simca-1000 etc]$ sudo twadmin --print-cfgfile > twcfg.txtMake the change in twcfg.txt with a text editor by setting the following:
LOOSEDIRECTORYCHECKING = trueRegenerate the encrypted file and do not forget to remove the plain-text version:
[emoret@simca-1000 etc]$sudo twadmin --create-cfgfile -S site.key twcfg.txtPlease enter your site passphrase:<site passphrase>Wrote configuration file: /usr/local/etc/tw.cfg [emoret@simca-1000 etc]$sudo rm twcfg.txt