[an error occurred while processing this directive]

Chapter 12. Security Design

Table of Contents

1. Usage
1.1. Client security in a client/server system
2. Integrity of the samhain executable
3. Client executable integrity
4. The server
5. General

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 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. This will help somewhat against intruders that try to run it under a debugger ...

  • use signed database/configuration files.

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

[an error occurred while processing this directive]