5 comments·January 15, 2022
I recall back in the days of torrenting before VPN's were all the rage people would use "IP block lists". They didn't work. This is because that idea was based on a false understanding of the problem. If one IP is blocked, another is used. Commonly now we can just spin one up from a cloud provider. A new ipv4 address, to a "hacker" is a keystroke.
This failed idea of IP ban lists in the context of security is dangerous. Time and money spent on this will draw away from proper solutions. Bad security is worse than none. Bad security creates a false sense of security and shoos away people who know better. The quality of a companies existing work will reflect whom is attracted to working on it.
Along with this various domestic IP's will be caught in the dragnet and banned for no good reason.
Instead of figuring out IP's for log4j, build systems where a vulnerability like log4j would be heavily mitigated. The same as how we don't try to make lists of failed ssh logins. We instead design ssh to not be vulnerable, and limit access to it.
Whilst I agree with the general premise of your post, (to me) the point of temporary IP bans is not so much security but rather taking load off a service under attack.
Systems like CrowdSec or the old and trusty fail2ban help a lot in reducing the noise coming from cracked/hacked systems trying to break into your servers.
It is not "either or." Defense in depth suggests applying several imperfect measures that together provide better defense than any individual approach along.
Defense in depth still requires good systems. Bad systems included in "defense in depth", again, provides false security and often times reduces the security of the others. If this is reasonable to do then so is digging a moat for the office building. It's not at all effective and in no way will tangibly help.
This sounds like a federated fail2ban which is actually a fantastic idea.
I have mentioned this before, but my experience with "hackers" has been that attacks are coordinated from thousands of compromised machines.
My solution thus far has been to leave the ssh port and ban any IP that tries to authenticate (leaving the option of
Likewise, a few rules to catch automated sql-injection scanners and the like, has really cut down on the noise.