File checking is basically I/O-limited, i.e. typically most of the time the application waits for data from the disk. Most of the application runtime is spent in the checksum algorithm, but as the application is I/O-limited, using a faster algorithm does not neccessarily result in any noticable speed improvement.
Logging can be very expensive, so you should avoid enabling many different logging facilities. You should also avoid low logging thresholds (info/debug) on production systems — it tends to drown real problems in the noise of purely informational messages, and reduces performance quite noticably.
Other things you can do are:
Build a static binary (use the --enable-static switch for configure). Static binaries are faster, and also more secure, because they cannot be subverted via libraries they depend on.
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.
Change the compiler switches to optimize more aggressively.
If on a commercial UNIX, check whether the native compiler produces faster code (you need an ANSI C compiler). The ./configure script honours CC (compiler) and CFLAGS environment variables.
On the other side, if you want to reduce the load caused by file checking, you can change the scheduling priority (see man nice ), and/or limit the I/O:
[Misc] # low priority (positive argument means lower priority) SetNiceLevel=19 # kilobytes per second SetIOLimit=1000
If you want to avoid thrashing the file cache, you can tell samhain to drop checksummed files from the cache (unless they were already cached). For performance reasons, this defaults to 'false'.
[Misc] # drop checksummed files from cache SetDropCache = True
Similarly, for the SUID check, you can limit the files per seconds:
[SuidCheck] # limit on files per seconds SuidCheckFps=250