I run an SSH server exposed to the internet and already use Fail2Ban to detect repeated authentication failures. I would also like to report obvious SSH scanning and vulnerability-probing attempts to AbuseIPDB.
The difficulty is that many scanners connect only once, so there may be no repeated failures for Fail2Ban to count. I also want to avoid reporting legitimate malformed clients or ordinary internet background noise. Ideally, the setup would identify events such as invalid SSH protocol banners, classify them appropriately as scanning or hacking activity, and submit them under the correct AbuseIPDB category (for example, 14 for port scanning or 15 for hacking).
Some example log messages include invalid banner characters, invalid protocol identifiers, and connections that terminate during the banner exchange. Is there a reliable way to build this with Fail2Ban, or should this be handled with a separate journal-processing script?
2 Answers
For one-off events and multi-line sshd messages, a small systemd service or timer reading the journal may be easier to control than Fail2Ban. Read new entries with journalctl cursors, correlate related lines using the sshd process ID, extract the remote address, apply a narrow set of rules, and then submit only events that meet your confidence threshold. This also makes it easier to assign AbuseIPDB categories deliberately instead of treating every malformed connection as a brute-force attack.
Fail2Ban can match a single event by setting the filter's maxretry to 1, but the tricky part is reliably extracting the address. In this case, the useful line is the one containing `banner exchange: Connection from`, rather than trying to match every possible preceding error message. You could create a custom filter and action that calls a wrapper around the AbuseIPDB API, but be conservative about what you submit. Invalid banners and protocol strings are generally scanner behavior, yet they are not automatically proof of malicious activity, so an overly broad filter could create false reports.
That is my concern: there seem to be many different SSH probe formats, and I do not know which ones are safe to classify as scanning versus hacking. I would rather miss a few reports than submit normal clients or generic noise.
A custom Fail2Ban action can still work if you prefer keeping everything in one place, but it will not solve the classification problem by itself. The important part is defining a small, tested list of unmistakable probes and rate-limiting or deduplicating reports before calling the API.