sshguard - block brute-force attacks by aggregating system logs
] [ -a thresh
] [ -b
] [ -f service
] [ -l source
] [ -p
] [ -s interval
] [ -w address
protects hosts from brute-force attacks against SSH and other
services. It aggregates system logs and blocks repeat offenders using one of
several firewall backends, including iptables
can read log messages from standard input (suitable for piping
) or monitor one or more log files. Log messages are parsed,
line-by-line, for recognized patterns. If an attack, such as several login
failures within a few seconds, is detected, the offending IP is blocked.
Offenders are unblocked after a set interval, but can be semi-permanently
banned using the blacklist option.
for setup instructions.
Other features, attack signatures, and additional documentation can be found at
- -a thresh (default 30)
- Block an attacker when its dangerousness exceeds
thresh. Each attack pattern that is matched contributes a fixed
dangerousness of 10.
- -b thresh:file
- Blacklist an attacker when its dangerousness exceeds
thresh. Blacklisted addresses are added to file so they can
be read at the next startup. Blacklisted addresses are never automatically
unblocked, but it is good practice to periodically clean out stale
- -f service:pidfile
- Deprecated. See LOG VALIDATION below.
- -i pidfile
- Write the PID of sshguard to pidfile.
- -l source
- Monitor source for log messages. By default,
sshguard reads log messages from standard input. Give this option
once for every source to monitor instead. sshguard transparently
handles log rotations. When using this option, standard input is ignored,
but can be re-added by giving ' -l -'.
- -p interval (default 120 secs, or 2
- Wait at least interval seconds before releasing a
blocked address. Repeat attackers are blocked for 1.5 times longer after
each attack. Because sshguard unblocks attackers only at infrequent
intervals, this parameter is inexact (actual blocks will be longer).
- -s interval (default 1800 secs, or 30
- Forget about an attacker interval seconds after its
last attempt. Its dangerousness will be reset to zero.
- -w address | file
- Whitelist the given address, hostname, or address block.
Alternatively, read whitelist entires from file. This option can be
given multiple times. See WHITELISTING below for details.
- Print version information and exit.
- Enable additional debugging information.
supports address whitelisting. Whitelisted addresses are not
blocked even if they appear to generate attacks. This is useful for protecting
lame LAN users (or external friendly users) from being incidentally blocked.
Whitelist addresses are controlled through the -w command-line option. This
option can add explicit addresses, host names and address blocks:
- specify the numeric IPv4 or IPv6 address directly,
or in multiple occurrences:
-w 192.168.1.10 -w 2001:0db8:85a3:0000:0000:8a2e:0370:7334
- host names
- specify the host name directly, like:
or in multiple occurrences:
-w friendhost.enterprise.com -w friend2.enterprise.com
All IPv4 and IPv6 addresses that the host resolves to are whitelisted. Hosts are
resolved to addresses once, when sshguard
- address blocks
- specify the IPv4 or IPv6 address block in the usual CIDR
or in multiple occurrences:
-w 192.168.0.0/24 -w 184.108.40.206/26
- When longer lists are needed for whitelisting, they can be
wrapped into a plain text file, one address/hostname/block per line, with
the same syntax given above.
sshguard can take whitelists from files when the -w option argument
begins with a '.' (dot) or '/' (slash).
This is a sample whitelist file (say /etc/friends):
# comment line (a '#' as very first character)
# a single IPv4 and IPv6 address
# address blocks in CIDR notation
And this is how sshguard
is told to make a whitelist up from the
The -w option can be used only once for files. For addresses, host names and
address blocks it can be used with any multiplicity, even with mixes of them.
Syslog and syslog-ng typically insert a PID of the generating process in every
log message. This can be checked for authenticating the source of the message
and avoid false attacks to be detected because malicious local users inject
crafted log messages. This way sshguard
can be safely used even on
hosts where this assumption does not hold.
Log validation is only needed when sshguard
is fed log messages from
syslog or from syslog-ng. When a process logs directly to a raw file and
sshguard is configured for polling logs directly from it, you only need to
adjust the log file permissions so that only root can write on it.
For enabling log validation on a given service the -f option is used as follows:
which associates the given pidfile to the ssh service (code 100). A list of
well-known service codes is available at
The -f option can be used multiple times for associating different services with
sshguard -f 100:/var/run/sshd.pid -f 123:/var/run/mydaemon.pid
Services that are not configured for log validation follow a default-allow
policy (all of their log messages are accepted by default).
PIDs are checked with the following policy:
- the logging service is searched in the list of services
configured for validation. If not found, the entry is accepted.
- the logged PID is compared with the pidfile. If it matches,
the entry is accepted
- the PID is checked for being a direct child of the
authoritative process. If it is, the entry is accepted.
- the entry is ignored.
Low I/O load is committed to the operating system because of an internal caching
mechanism. Changes in the pidfile value are handled transparently.
syslog(1), syslog.conf(5), hosts_access(5)
Michele Mazzucchi < email@example.com
>, Kevin Zheng