Samhain | ||
---|---|---|
<<< Previous | Next >>> |
It is recommended to:
compile a static binary (not linked to shared libraries), using the configure option --enable-static if possible (not possible on Solaris — this is a Solaris problem, not a problem of samhain)
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
If you use a precompiled samhain executable (e.g. from a binary distribution), in principle a prospective intruder could easily obtain a copy of the executable and analyze it in advance. This will enable her/him to generate fake audit trails and/or generate a trojan for this particular binary distribution.
For this reason, it is possible for the user to add more key material into the binary executable. This is done with the command:
samhain --add-key=key@/path/to/executable
This will read the file /path/to/executable, add the key key, which should not contain a '@' (because it has a special meaning, separating key from path), overwrite any key previously set by this command, and write the new binary to the location /path/to/executable.out (i.e. with .out appended). You should then copy the new binary to the location of the old one (i.e. overwrite the old one).
<<< Previous | Home | Next >>> |
Method B: The native package manager | Integrity of the executable |