Public bug reported:
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.
** Affects: sshguard (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1881459
Title:
sshguard triggers on its own log messages
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sshguard/+bug/1881459/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
