Chapter 12. Security Design
Prev |  | Next

# Chapter 12. Security Design

## 1. Usage

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. On some operating systems (e.g. Solaris) static compiling may not be possible at all.

- 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 ...

  | Note
  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.

### 1.1. Client security in a client/server system

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.

Prev |  | Next
2. Method B: The native package manager | Home | 2. Integrity of the samhain executable