And how does filtering on the IP range of a country prevent traffic from that country? Or are you also blocking every known proxy and VPN service? Are you sure that your strict firewall even provides the security you wish it did?
Either way, letsencrypt will probably have a somewhat fixed pool of these challenge validation IP addresses/ranges, so adding those to a white list should probably work with a strict firewall.
I'm pretty sure that even a 50% mitigation is still valuable, and a remarkable number of attacks are completely unsophisticated. Having gone over server logs specifically looking at this sort of thing, I can tell you that a lot of attacks absolutely do appear to originate in countries that are vanishingly unlikely to have legitimate interest in the site (this was a small local business in the US, with logs showing a lot of `/wp-admin`-type attempts from Asia/Russia). So yes, blindly banning unexpected countries is very likely to reduce the number of attacks that you get, and if nothing else reduce log spam. It's a bit like changing your SSH port: easy to bypass, but it still reduces attacks by quite a bit.
But that's a wrong metric to optimize for. Cutting down the number of "attacks" by 90% doesn't improve your security. If your server has a vulnerability that can be picked up by script kiddie scanners, changing the default port only delays the inevitable.
I don't agree with this at all - 'delaying the inevitable' is 90% of security; it's the basic assumption when practicing defense in depth.
You scan for and patch known vulnerabilities, and assume that some unknown ones still remain. You deploy WAF to block some of the unknowns or at least make them harder to exploit. You harden the host and segregate the network to make it harder for the attacker to move laterally when they manage to exploit something anyway. You use SIEM or just regular log review to hopefully catch attackers that have been delayed by your defensive measures.
Putting your service on a non-default port is a perfectly valid measure as part of a larger defensive strategy. It has its pros and cons, you've got to be aware of what threats it mitigates and what it doesn't, but it can be useful.
I find that a very good, low cost, low friction measure is to do IP based mitigation only for sensitive ports (ssh, rdp, smb, etc). Ideally you implement an IP white list that you store in a safe and reliable place (cloud storage?). And your servers refresh that IP list every 5 minutes and modify the firewall if it changed. Easy to implement.
Only you can talk to sensitive ports. And the server is available to the rest of the world for non sensitive things. And if you connect from a new IP, within 5 min you have access to the server (I have a scheduled task that updates the IP list with my current IP so I usually don’t even wait).
That kind of sounds like you are implying cutting down 50% of attacks is the same as cutting down 50% of the risks. But not all attacks are equal. Only a very small portion of the risk comes from the 50% you blocked.
It blocks unsophisticated resource waste mostly, as other commenters have said, just like changing an SSH port would.
> Either way, letsencrypt will probably have a somewhat fixed pool of these challenge validation IP addresses/ranges, so adding those to a white list should probably work with a strict firewall.
They won't publish the ranges as far as I've read.
Either way, letsencrypt will probably have a somewhat fixed pool of these challenge validation IP addresses/ranges, so adding those to a white list should probably work with a strict firewall.