sshguard

Langue: en

Autres versions - même langue

Version: 303430 (debian - 07/07/09)

Section: 8 (Commandes administrateur)

Sommaire


BSD mandoc

NAME

sshguard - monitors daemon activity

SYNOPSIS

[-a abuse_tresh ] [-p pardon_min_interval ] [-s stale_tresh ] [-w addr/host/block/file ] [-d ] [-f srv:pidfile ]

DESCRIPTION

monitors logging activity and reacts to attacks by blocking their source addresses.

has born for protecting SSH servers from the today's widespread brute force attacks, and evolved to an extensible log supervisor for blocking attacks to applications in real-time.

is given log messages in its standard input. By mean of a parser, it decides whether an entry is normal activity or attack; in the latter case, it remarks the author's address. When the number of attacks from one address exceeds a threshold, the address is blocked with the firewall.

supports the following firewalls:

AIX native firewall
for IBM AIX operating systems
netfilter/iptables
for Linux-based operating systems
Packet Filter (PF)
for BSD operating systems (Open, Free, Net, DragonFly -BSD)
IPFirewall (IPFW)
for FreeBSD and Mac OS X
IP Filter (IPFILTER)
for FreeBSD, NetBSD and Solaris
tcpd's hosts_access (/etc/hosts.allow)
portable across UNIX
null
portable do-nothing backend for applying detection but not prevention

USAGE

is given log entries to scan in its standard input. It can interpret logs with the following formats:

can interface with the following blocking systems to block attackers:

Depending on the way chosen for giving logs to sshguard, and depending on the chosen blocking system, some setup may be needed. Instructions are documented at http://sshguard.sourceforge.net/doc/setup/setup.html .

does not make use of any configuration file. Instead, a combination of optional arguments can be passed to its process on the command line, for modifying its default behaviour:

-d
run in debug mode: all logging is done to standard error, not syslog.
-a num
block an address after num attack attempts have been detected. (Default: 4)
-p secs
release a blocked address not sooner than secs seconds after being blocked. will release the address between X and 3/2 * X seconds. (Default: 7*60)
-s secs
forget about an address after secs seconds. If host A issues one attack every this many seconds, it will never be blocked. (Default: 20*60)
-w addr/host/block/file
see the WHITELISTING section.
-f servicecode:pidfile
see the LOG MESSAGE AUTHENTICATION section.

When is signalled with SIGTSTP, it suspends activity. When is signalled with SIGCONT, it resumes monitoring. During suspension, log entries are discarded without being analyzed.

WHITELISTING

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:

addresses
specify the address directly, like:
-w 192.168.1.10
or in multiple occurrences:
-w 192.168.1.10 -w 192.168.1.11 -w 192.168.1.12
host names
specify the host name directly, like:
-w friendhost.enterprise.com
or in multiple occurrences:
-w friendhost.enterprise.com -w friend2.enterprise.com
When hosts resolve to multiple addresses, all of them are whitelisted. Hosts are resolved to addresses once, when sshguard starts up.
address blocks
specify the address block in the usual CIDR notation:
-w 192.168.0.0/24
or in multiple occurrences:
-w 192.168.0.0/24 -w 1.2.3.128/26
file
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.

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 ip address
 1.2.3.4
 #   address blocks in CIDR notation
 127.0.0.0/8
 10.11.128.0/17
 192.168.0.0/24
 #   hostnames
 rome-fw.enterprise.com
 hosts.friends.com

And this is how is told to make a whitelist up from the /etc/friends file:

sshguard -w /etc/friends

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.

LOG MESSAGE AUTHENTICATION

Syslog and syslog-ng typically insert a PID of the generating process in every log line. 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 lines. This way can be safely used even on hosts where this assumption does not hold.

Log message authentication is only needed when 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 message authentication on a given service the -f option is used as follows:

-f 10:/var/run/sshd.pid
which associates the given pidfile to the ssh service (code 10). A list of well-known service codes is available at http://sshguard.sourceforge.net/doc/servicecodes.html

The -f option can be used multiple times for associating different services with their pidfile:

sshguard -f 10:/var/run/sshd.pid -f 123:/var/run/mydaemon.pid

Services that are not configured for log message authentication follow a default-allow policy (all of their log messages are accepted by default).

PIDs are checked with the following policy:

  1. the logging service is searched in the list of services configured for authentication. If not found, the entry is accepted.
  2. the logged PID is compared with the pidfile. If it matches, the entry is accepted
  3. the PID is checked for being a direct child of the authoritative process. If it is, the entry is accepted.
  4. 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.

EXTENSIONS

can be easily extended to support both more backends (systems blocking addresses, like firewalls) and to recognize more attack patterns.

Adding backends is extremely easy when the blocking and releasing operations can be controlled with system commands. provides a shell script for generating such extensions in few steps: sshguard_backendgen.sh

Adding more attack patterns needs some expertise with bison, as uses a grammar-based context-free parser for powerfulness. Thus, there is one tracker for user-proposed patterns at http://sshguard.sourceforge.net/newattackpatt.php

SEE ALSO

syslog(1), syslog.conf5

website at: http://sshguard.sourceforge.net/