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:
- 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
- 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.
- 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.
- 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
-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
When a daemon restarts, its pid changes. Sshguard handles this events transparently without the admin intervention.
Latest Releases View all»
F.A.Q. View all»
- What is sshguard?Sshguard is a small program that monitors services running on your machine from the log files. When it ...
- I use IPFW and IPs are not successfully blockedFor minimizing the intrusiveness, sshguard puts blocking rules very low in the IPFW chain (with IDs from 55000 ...
- Sshguard does not workYou have one of these problems: sshguard is not given logs correctly sshguard cannot run the commands for ...