sshguard triggers on its own log messages

[Wolfgang Faust]

Extract from `journalctl -u sshguard`:

May 31 03:13:00 hostname sshguard[123]: Attack from "10.0.2.2" on service 100 with danger 2.
May 31 03:13:00 hostname sshguard[123]: Attack from "10.0.2.2" on service 110 with danger 10.
May 31 03:13:01 hostname sshguard[123]: Attack from "10.0.2.2" on service 110 with danger 10.
May 31 03:13:01 hostname sshguard[123]: Attack from "10.0.2.2" on service 110 with danger 10.
May 31 03:13:01 hostname sshguard[123]: Blocking "10.0.2.2/32" for 120 secs (4 attacks in 1 secs, after 1 abuses over 1 secs.)

What seems to have happened here is that an SSH connection (service 100) failed, causing sshguard to log an attack. Then, sshguard saw its own log message (service 110), and went into a loop of retriggering attack messages until it reached the threshold and banned the IP. This is a very disproportionate response to a single connection error.

The example LOGREADER setting in the upstream repository does not exhibit this behaviour; the difference seems to be that the log filters are specified by `-t sshd` rather than SYSLOG_FACILITY; it's not clear to me why this change might have been made by the packager.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[rustyx (rustyx2)]

Use this quick workaround:

sudo sed -i "s/SYSLOG_FACILITY=4 SYSLOG_FACILITY=10/-t sshd/" /etc/sshguard/sshguard.conf
sudo systemctl restart sshguard

Can add more services (-t <service>) as needed.

Note: SSHGuard can parse the following services (see src/common/attack.h):

enum service {
    SERVICES_ALL = 0, //< anything
    SERVICES_SSH = 100, //< ssh
    SERVICES_SSHGUARD = 110, //< SSHGuard
    SERVICES_UWIMAP = 200, //< UWimap for imap and pop daemon
    SERVICES_DOVECOT = 210, //< dovecot
    SERVICES_CYRUSIMAP = 220, //< cyrus-imap
    SERVICES_CUCIPOP = 230, //< cucipop
    SERVICES_EXIM = 240, //< exim
    SERVICES_SENDMAIL = 250, //< sendmail
    SERVICES_POSTFIX = 260, //< postfix
    SERVICES_OPENSMTPD = 270, //< OpenSMTPD
    SERVICES_COURIER = 280, //< Courier IMAP/POP
    SERVICES_FREEBSDFTPD = 300, //< ftpd shipped with FreeBSD
    SERVICES_PROFTPD = 310, //< ProFTPd
    SERVICES_PUREFTPD = 320, //< Pure-FTPd
    SERVICES_VSFTPD = 330, //< vsftpd
    SERVICES_COCKPIT = 340, //< cockpit management dashboard
    SERVICES_CLF_UNAUTH = 350, //< HTTP 401 in common log format
    SERVICES_CLF_PROBES = 360, //< probes for common web services
    SERVICES_CLF_LOGIN_URL = 370, //< CMS framework logins in common log format
    SERVICES_OPENVPN = 400, //< OpenVPN
    SERVICES_OPENVPN_PS = 410, //< OpenVPN Portshare
    SERVICES_GITEA = 500, //< Gitea
};

A quick look at the source reveals that SSHGuard has a parser for its own logs, which seems to be to support remote sshguard logging scenario.

There does not seem to be a way to configure SSHGuard actions per-service, and it is always logging using LOG_AUTH facility (4). Which means SYSLOG_FACILITY=4 can never be used as a filter currently, the only solution is to filter the logs *before* they reach SSHGuard.