Server

TipTIP
 

The most frequent reason for client/server connection problems is the following:

The server must be able to determine the client name. This is because only authenticated connections from registered clients are allowed, and the server must be able to check the client hostname against the list of allowed hosts, and look up the password verifier for that host.

There are two different ways to accomplish this. Unfortunately, judging from customer feedback as well from common sense, both do not work very well with a messed up local DNS (including /etc/hosts files) and/or überparanoid or misconfigured firewalls (in case of connections across one).

First method: Determine client name on client, and try to cross-check on server

This does not work for a number of people because (1) the /etc/hosts file on the client machine has mistakes (see the Section called Client or Standalone> for examples of correct and incorrect /etc/hosts files), (2) the server cannot resolve the client address because the local DNS is f***ed up, or (3) the client machine has multiple network interfaces, and the interface used is not the one the client name resolves to.

If the client uses the wrong interface on a multi-interface machine, there is a config file option SetBindAddress=IP address that allows to choose the interface the client will use for outgoing connections.

If you want to download the config file from the server, you should instead use the corresponding command line --bind-address=IP address to select the interface.

If you encounter problems, you may (1) fix your /etc/hosts file(s), (2) fix your local DNS, or (3) switch to the second method.

Errors in name resolving/cross-checking can be avoided by setting a very low severity (lower than the logging threshold), e.g.

SeverityLookup=debug

in the Misc section of the server configuration, if you prefer running unsafe at any speed instead of fixing the problem (you have been warned). Doing so will allow an attacker to pose as the client.

Second method: Use address of connecting entity as known to the communication layer

This has been dropped long ago because it may not always be the address of the client machine. It appears that some people have firewalls posing as the connection endpoint (this is a guess based on bug reports from systems we don't have access to). To enable this method, use

SetClientFromAccept=true

in the Misc section of the server configuration file. If the address cannot be resolved, or reverse lookup of the resolved name fails, no error message will be issued, but the numerical address will be used.

Cannot resolve client name host=XXX

See the tip above.

Cannot resolve socket peer IP for client host=XXX peer=YYY

See the tip above.

Reverse lookup of socket peer failed host=XXX peer=YYY obj=ZZZ

See the tip above (obj is the IP to which the peer name should resolve).

No socket peer alias matches client name host=XXX peer=YYY

See the tip above.

Invalid connection attempt: Not in client list

In the server config file, you have not listed the client. Or you have listed it, but not with the correct name. The name to use is the one the client has determined for the host it is running on, and is given in the error message. This error frequently occurs if you have listed the client with a FQDN in the server config file, while the client itself can only determine the IP address of its host (usually caused by improper entries in /etc/hosts).

Time limit exceeded

The respective client for that this message is generated has not sent anything for some interval of time (default 84600 sec = 1 day). The interval can be set in section [Misc] with SetClientTimeLimit=NNN. This feature has the purpose to detect if a client is dead. You might want to ensure that timestamps are sent to the server (in [Log]: ExportSeverity=mark). If you don't want to use this feature, set the time limit to some very large value.

Invalid connection attempt: Session key mismatch

Most likely, the client password (set in the binary via the samhain_setpwd utility) does not match the credentials in the server config file.

Invalid connection attempt: Signature mismatch

Clients sign their messages using a session key negotiated with the server. The message indicates that the server could not verify the signature. This may be caused by a running two instances of samhain on the same client machine, both of them accessing the server (and negotiating different session keys ...). The system will recover automatically from the problem by forcing the failed client to negotiate a fresh session key.

I want / don't want both the server and client timestamps in the SQL database

In the Database section of the configuration file, you can put an option SetDBServerTstamp=true/false This will enable/disable logging of the server timestamp for client messages. The server timestamp will be written to a seperate record, with log_ref set to the value of log_index of the corresponding client message. See also the Section called SQL Database in the chapter called Configuration — Basic>.

I don't want the client timestamps in the SQL database

Sending timestamps from the client allows the server to detect if a client is not running anymore (use SetClientTimeLimit=NNN in the [Misc] section of the server config file to set the number of seconds after which the server will issue an error message if no timestamp has been received).

However, you might not want to log these timestamps to the database (or other log facilities). To filter them, you can use two methods (examples are for the SQL database). The first one has the disadvantage that only messages of severity err or higher will be logged:
     [Misc]
     UseClientSeverity=yes
     [Log]
     DatabaseSeverity=err
     

The second method is more specific — log everything not belonging to the STAMP class of messages (see the Section called Classes in the chapter called Configuration — Basic>):
     [Misc]
     UseClientClass=yes
     [Log]
     DatabaseClass=PANIC RUN FIL TCP ERR ENET EINPUT
     

PANIC .. Address already in use subroutine=bind

The server cannot bind to its port because the port is already used. Maybe you have accidentially already an instance of the server running.