SSHGuard is an intrusion prevention utility that parses logs and automatically blocks misbehaving IP addresses (or their subnets) with the system firewall. SSHGuard version 2.1 was just released with new blocking services, the ability to block a configurable-sized subnet, and better log reading capabilities.
SSHGuard 2.1 was just released, only 236 days after the last major release with SSHGuard 2.0. In addition to updated attack signatures, here’s a quick overview of the new features that have been included with the latest release:
New feature: Block attacker’s subnet
Administrators can now configure the size of an IPv4 and IPv6 subnet that should be blocked in response to an attack originating from that subnet. By default, SSHGuard will block a /128 subnet for IPv6 addresses and /32 for IPv4 (meaning, just a single address.)
SSHGuard doesn’t yet support detecting attacks originating from within the same subnet.
New service: Remote SSHGuard
SSHGuard can now parse and act on its own logged attack- and block responses. Meaning you can feed it a remote SSHGuard log with a remote log feed service (like systemd remote journal), and share attack data and blocklists between multiple systems. Please try to avoid feeding it the local log to avoid recursive blocking.
New service: Cockpit administration dashboard
SSHGuard can now detect and thwart brute-force login attacks against the Cockpit web administration dashboard for Linux systems.
New service: HTTP server probing
SSHGuard can now process the NCSA Common Log Format (CLF) and can detect and thwart probing for popular web services like WordPress, Horde, RoundCube, and phpMyAdmin. Supports all web servers with CLF logging capabilities (extended formats also supported.)
New service: WordPress
A new WordPress service lets SSHGuard detect and thwart brute-force login attacks against WordPress.
Note that only login attempts against wp-login.php is supported, as attacks against xmlrpc.php (XML RPC) doesn’t leave behind a discernible attack signature in the server log signature. XML RPC should be disabled in any case as it allows over a hundred password guess per server request. (Yikes!) Web server logs must be in NCSA CLF. Check out the accompanying tutorial for instructions on how to set this up.
New firewall backend: nftable
The new sshg-fw-nft-sets backend works with nftables. It creates a priority -10 table called sshguard, adds attackers, and will by default set up rules to drop future connections from recognized attackers. Like all firewall backends, the new backend is a easily-customized script that you can replace with your custom firewall backend script.
Changed: Simultaneously read logs from files and a logreader
All these new features depend on having the relevant service logs fed into SSHGuard. It’s now easier than ever to pipe logs to SSHGuard. SSHGuard can now be configured to read logs from a LOGREADER command (like tail -f or journalctl) and from a list of FILES at the same time. Earlier versions would not read logs from FILES when a LOGREADER was configured. This provides greater flexibility for systems and services not yet on-board with unified logging systems like the systemd journal on Linux or os_log on MacOS.
You can get the latest release of SSHGuard from Sourceforge, learn more on the SSHGuard website, or grab the source from BitBucket. You can find generic installation instructions and I’ve provided more specific install and setup instructions for Fedora Linux users.