sshguard triggers on its own log messages
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
sshguard (Debian) |
Fix Released
|
Unknown
|
|||
sshguard (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
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.
Changed in sshguard (Debian): | |
status: | Unknown → New |
Changed in sshguard (Debian): | |
status: | New → Confirmed |
Changed in sshguard (Debian): | |
status: | Confirmed → Fix Released |
Status changed to 'Confirmed' because the bug affects multiple users.