My logs and firewall greatly disagree. Please avoid comments on HN like this where it boxes solutions into a "my way or the highway" result, when it has been demonstrated to you here it's not "Absolutely pointless". Security is the layering of multiple solutions and defenses to protect your assets, there is no magic bullet or single solution.
"My logs and firewall are less cluttered" is not at all the correct metric to measure the security of your box.
IP address spoofing is a thing. Blocking CIDR ranges might protect you from low-effort, drive-by botnets that constantly scan the entire internet (which all should be completely mitigated by using certificate based auth anyway), but blocking based on IP address is absolutely not an effective control against a determined hacker.
You must consider your threat model. For your personal instance that you host hobby things on, you probably won't be targeted via IP spoofing. For any type of company, you should not be relying on CIDR blocking as part of your security layers. CIDR blocking is only effective at reducing the clutter of your logs, which is a convenience, not a security control. The real security control is using proper auth methods, which are so easy to do at this point that it's ridiculous for even a hobbyist to not do them.
my understanding is that spoofing only works for sessionless protocols or situations -- eg a single udp packet or a series of packets that do not rely on any kind of response, since the response (like a tcp ack, or a dh handshake) is routed to the spoofed address. this would not apply to ssh. what contexts are you thinking of?
Why are you assuming that a determined attacker doesn't control your L4 stack? MITMs are a threat, your network could be compromised, routers (especially consumer routers) are rife with vulnerabilities. This is the entire reason "zero trust" is pushed.
In any serious security design, "the attacker probably won't do that" would and should be shot down immediately. If your security strategy is hoping that an attacker will be kind enough to not exploit your open vulnerability, you've already failed at threat modeling and at security.
If an attacker can do it, you must assume they will do it. Because they will. That should be the starting point for any threat model.
that's cool man, i'm still going to block the 99.9999% of attackers that don't own my isp. you are conflating "bad idea in extremely exotic scenario" with "counterproductive"; ever heard of defense in depth?
So I know this is all probabilistic and there's probably some benefit, but are there really a meaningful number of attackers who could attack a server which only allows public key authentication and who will be slowed by country-granularity IP blocking? If you're counting blocked attempts in logs, you're counting attempts that were never going to succeed.
(Note: This works only if 1. Your IP blocks are very coarse, and 2. You disallow password authentication)
This isn't about deflecting a targeted attack, it's about reducing the amount of noise in your logs so that it becomes easier to detect a targeted attack.
For the same reason, assuming you must expose SSHD to the world, it makes sense not to expose it on port 22.
If you set up a machine on AWS EC2 and give it a public IP address, you can watch in near-realtime as the "admin/admin" login attempts come in (last time I tried this on a whim it took less than a minute).
> If you're counting blocked attempts in logs, you're counting attempts that were never going to succeed.
By your own logic, if the problematic traffic shares the same geographic origin and you only happen to spot failed attempts, blocking all traffic from the same geographic origin would also block potentially successful attempts.
And I agree with the OP: there's an awful lot of malicious traffic sharing a common geographical origin. If you ever felt curious, just launch a cheap VM and setup a web server to listen to traffic and log any connection attempt. You don't even need to host a site. In no time you'll start to see your VM being hit by all sorts of web scrapers and security vulnerability scanners.
My logs and firewall greatly disagree. Please avoid comments on HN like this where it boxes solutions into a "my way or the highway" result, when it has been demonstrated to you here it's not "Absolutely pointless". Security is the layering of multiple solutions and defenses to protect your assets, there is no magic bullet or single solution.