Table of Contents
It is recommended to:
compile a static binary(not linked to shared libraries), using the configure option --enable-static if possible. Some functionality may not be available with static binaries, in particular some name services (NIS, LDAP), the portmap service (used for the port check), and the support for the Linux audit daemon and SQL databases. On some operating systems (e.g. Solaris) static compiling may not be possible at all.
The advantage is that a static binary is self-contained, i.e. if you are sure of its integrity (e.g. because it is on a write-protected medium) then you don't need to worry about the integrity of system libraries that dynamically linked binaries depend upon. The disadvantage is, if there is a bug in one of the compiled-in libraries, then you need to re-compile the static binary after a library upgrade.
strip the binary(on i386 Linux/FreeBSD, also use the provided sstrip utility: strip samhain && sstrip samhain ). This will help somewhat against intruders that try to run it under a debugger ...
make install will always strip the excutables. Trying to strip again by hand may corrupt the executable.
use signed database/configuration files using the configure option --with-gpg=PATH_TO_GPG , and compile in the fingerprint of the signing key ( --with-fp=... )
take a look at the stealth options- while 'security by obscurity' only is a very bad idea, it certainly helps if an intruder does not know what defenses you have in place
read the next chapter to understand how the integrity of the samhain executable can be verified.
In a client/server Samhain system, if an intruder has obtained root privileges on the server he may modify configuration files that are stored on the server and downloaded by the clients. Thus, if the client executes shell commands given in the configuration file (via the shell expansion option, or by logging events to external commands specified in the configuration file), this may allow the intruder to take over the clients as well.
As of version 2.8.5, there are two ways to protect against this scenario:
first, you can use the option --with-gpg=PATH to use signed configuration (and baseline database) files. The signature is checked on the client, after downloading the configuration file from the server. It is thus not possible to make the client perform any actions if the configuration file is not signed correctly (note that in versions before 2.8.5, the signature would be checked too late to prevent the attack).
second, you can just forego any execution of external programs by compiling with the options --disable-shellexpand --disable-external-scripts . No shell expansion will be performed on configuration file directives, and no logging to external programs will be supported.