I do, however, think that if there was a more widespread scorched earth approach then the issues like those mentioned in the article would be much less common.
Fortunately, real network admins are smarter than that.
Yes, there are less scorched-earth ways of looking at this, but this works for me.
As always, any of this stuff is heavily context specific. Like you said: network admins need to be smart, need to adapt, need to know their own contexts.
IP based bans have long been obsolete.
And corporate IT wonders why employees are always circumventing "security policies"...
There would be a lot of refinement and contingencies to implement something like this for corporate / business.
Having said that, I still exist on the ruthless side of blocking equation. I'd generally prefer some kind of small allow list than a gigantic block list, but this is how it's (d)evolved.
Single queries should never be harmful to something openly accessible. DOS is the only real risk, and blocking after a certain level of traffic solves that problem much better with less possibility of a false positive, and no risk to your infrastructure, either.
Manual reviewing like this also helped me find a bunch of organisations that just probe the entire IPv4 range on a regular basis, trying to map it for 'security' purposes. Fuck them, blocked!
P.S. I wholeheartedly support your choice of blocking for your reasons.
Yep, #1 source of junk traffic, in my experience. I set those prefixes go right into nullroute on every server I set up:
https://raw.githubusercontent.com/UninvitedActivity/Uninvite...
#2 are IP ranges of Azure, DO, OVH, vultr, etc... A bit harder to block those outright.
Nowadays, wireguard would probably be a better choice.
(both of above of course assume one is to do a sensible thing and add "perma-bans" a bit lower in firewall rules, below "established" and "port-knock")