Several UNIX daemons come with support for libwrap, a library that allows programs to decide when to accept or reject connections based on some rules configured system-wide.

In its simplicity, this solution is peculiar: by operating entirely in user space, it does not snoop in any kernel/networking-specific feature and thus it is highly portable. This costs some negligible performance and the need for all daemons to be programmed to be libwrap-enabled or to work under (x)inetd. This means that, notwithstanding SSHGuard successfully blocking some attackers, if a daemon meets neither requirement, blocked attackers may still access the service.

TCP Wrappers decide when to accept/reject connections based on a user-provided file, typically /etc/hosts.allow. Through its hosts firewall backend, SSHGuard can manipulate this file by dynamically adding and releasing rules for addresses that are found abusing any service monitored.

How it works

Provided you have chosen the hosts backend while compiling SSHGuard, this backend requires no configuration. Just make sure to create the /etc/hosts.allow file (or whatever else you chose at compile time) if it does not exist.

When SSHGuard starts with the hosts backend, it creates a special block in the hosts.allow file, enclosed in a ##sshguard## pair. When an address is blocked, SSHGuard puts inside this block a DENY rule, so that all libwrap-enabled programs will reject connections from that address.

It goes without saying that you're not supposed to touch the ##sshguard## block in this file. Everything else in there you are free to change, even with SSHGuard running; if you want to be on the safe side, edit with a smart editor that informs you when the file updates under your fingers (SSHGuard surprise!).

While running, SSHGuard's block in /etc/hosts.allow will contain rules saying Deny connections from this list of hosts, to ALL services; these will look some like this:

##sshguard##
ALL : 1.2.3.4 10.9.8.7 [2001:0db8:85a3:0000:0000:8a2e:0370:7334] : DENY
##sshguard##

Some implementations of the TCP wrappers do not support long configuration lines. SSHGuard takes care of breaking them down in multiple safety-length directives.

Services implementing TCP Wrappers support

The rule of thumb is: if a service runs under inetd, then it is TCP Wrappers enabled (inetd performs the checks). If it doesn't, then it is TCP Wrappers enabled if it links against libwrap — which you can test with e.g.: ldd /usr/sbin/mydaemon | grep wrap on Linux and BSD, or otool -l /usr/sbin/mydaemon | grep wrap on Mac OS X.

This is a partial list for popular daemons:

• OpenSSH (native)
• Sendmail (inetd)
• Exim (inetd)
• Dovecot (inetd)
• cucipop (inetd)
• UWimap (inetd)
• vsftpd (inetd)
• proFTPd (inetd)
• pure-ftpd (inetd)
• FreeBSD ftpd (inetd)

Troubleshooting

If you have any problem with this backend, check if the /etc/hosts.allow file exists before SSHGuard starts.

After SSHGuard starts, check that SSHGuard was able to open it and place its ##sshguard## block in there (stop sshguard, edit the block out of the file, then restart sshguard): if not, it's likely a permissions problem (or at compile time you specified a different file).

For any other question, write in.