Log message validation means verifying that a log message comes from the process it claims and not from a fake one.

With the syslog logging system, every process can inject log messages with an arbitrary name. Thus, malicious local users might craft log lines with arbitrary addresses to block, and inject them with the "sshd" identificator, simulating attacking activity from that address.

Log-based DoS protecting tools implicitly assume local users to be trusted. With log message validation, you can safely use sshguard even on hosts where this assumption does not hold. This is possible because of sshguard's powerful yacc parser.

Using the Log Sucker combined with Log Validation is discouraged in SSHGuard 1.5: since with the Log Sucker tiny latencies may occur between the log appearance and fetching, in some circumstances these lead the validator to not trust the log entry. A version of Log Sucking tailored to the own event system of each supported OS is coming in next versions.

Process validation iter

Log message validation makes sense when sshguard is fed log messages from syslog or from syslog-ng. When sshguard works by polling logs directly from a raw file, you only need to adjust the log file permissions so that only root can write on it.

Log message validation works this way:

1. a pidfile (a text file containing the pid of a daemon at any time) is given to sshguard, associated to a specific service (service code) sshguard is protecting
2. every time sshguard receives a log message, it compares its generating PID with the one in the pidfile. The PID is inserted by the logging system itself, so it cannot be faked by user programs.
3. if the PID in the log entry does not match, sshguard tries to check if it is at least a child of the authoritative process. Daemons that work with the fork() paradigm (like e.g. sshd) will also work this way.
4. if the PID does not match the authoritative process, nor does it appear to be a child of it, the log message is ignored.

How to use log message validation

You must give sshguard a pidfile for each service it is protecting. By default, sshguard protects service ssh (code 100). A table with known service codes may help you.

Associating a service with its process' pidfile is pretty easy (all pidfiles are typically located in the /var/run directory in UNIX):

# check service 100 (sshd) against pidfile /var/run/sshd.pid
sshguard -f 100:/var/run/sshd.pid

The -f option can be used multiple times to configure different services for validation, e.g.:

# validate service 100 (sshd) and service 123 (mydaemon)
sshguard -f 100:/var/run/sshd.pid -f 123:/var/run/mydaemon.pid

Services that are not associated to a pidfile use a default-allow policy (all of their log messages are accepted by default).

When a daemon restarts, its pid changes. Sshguard handles this events transparently without the admin intervention.