PerSourcePenalties-like abuse mitigations are not very subtle, but often very effective.
My own experience with this is not as much with SSH as with SMTP. If your particular IP emits a single non-deliverable message every 30 minutes or so, that's fine.
But: more than a handful of SPF failures for the same sender/recipient combo within 10 minutes or so? Yeah, you're now on the general-deny-list. And persisting even then? Automagically tar-pitted on the firewall, and have fun...
> But: more than a handful of SPF failures for the same sender/recipient combo within 10 minutes or so? Yeah, you're now on the general-deny-list. And persisting even then? Automagically tar-pitted on the firewall, and have fun...
What is the advantage of bothering to do this?
To me, it seems like you're risking blocking legitimate traffic (as two obvious examples, in cases where a sending mailserver is temporarily misconfigured, or if a malicious mailserver is using a cloud IP that is later recycled to a completely unrelated user), for basically zero upside.
Like: yeah, I don't care that you're self-DDOSing if you're an actual spammer. But, just in case you're a legitimate sender lacking SPF records, and you just need some help, I still want some kind of signal.
For SSH, I guess you might want something similar, just to catch authorized-yet-misconfigured remotes...
My own experience with this is not as much with SSH as with SMTP. If your particular IP emits a single non-deliverable message every 30 minutes or so, that's fine.
But: more than a handful of SPF failures for the same sender/recipient combo within 10 minutes or so? Yeah, you're now on the general-deny-list. And persisting even then? Automagically tar-pitted on the firewall, and have fun...