Why not using the way easier to configure i(f)tables? It's so much more straightforward and flexible.
What are i(f)tables? Google does not suggest anything.
Block web scanners with ipset and iptables
41–46 of 46 posts
Re: Block web scanners with ipset and iptables
#42On my internet facing hosts, I use the firehol level 2 and level 3 block sets along with blocking all CN IP space that I can accurately identify. My logs are eerily quiet.
I tried firehol for some time and quite liked it (much more than iptables). This was after shorewall started to fade out (and is now abandoned or so). I had some problems to get community support and it seems that activity around firehol is fading away and I am not sure whether this is because this is a complete, finished product, or because it is abandoned.
I don't actually use the firehol scripts - I use the source lists with my own custom iptable/pf scripts.
Re: Block web scanners with ipset and iptables
#43fail2ban is excellent. No need for anything else. Configure it for all your server logs. It'll handle the iptables or nftables config for you.
I'll challenge you on that :-) https://www.crowdsec.net/blog/crowdsec-not-your-typical-fail...
Re: Block web scanners with ipset and iptables
#44I wonder why the author uses a 404 error response. I usually configure NGINX with "return 444;" which closes the connection without response. Scanners don't deserve a response. I may have wasted bytes receiving the request, but I won't waste any more once I know the request is garbage.
You will like this more elaborate attacks you can do to those bots https://www.hackerfactor.com/blog/index.php?/archives/762-At...
Good read, thanks.
For others who aren't interested in reading the whole thing:
The author of the post used zip-bombs, which are compressed HTTP responses that expand to 1000 times the size of the compressed data. He could send relatively small responses that would fill the requester's memory and crash the process. Beautiful.
Re: Block web scanners with ipset and iptables
#45Earlier quoted context omitted.
Beware though -- nginx 444 doesn't actually close the connection. At the packet level, it just does not respond. This distinction is important if you have a load balancer in front of nginx. The LB will wait until timeout for a response, occupying a bit of stateful memory and probably causing an error which is indistinguishable from "backend application server is offline".
That is actually cool, it is a tarpit for these bots! On a well configured site the LB timeouts should be short enough anyway. But it is a risk, especially on classic DOS attacks.
Yep it's great for tarpitting if you are not behind an LB.
The other problem, if you are behind an LB, is that the client (DoS attacker) will get a 503 from the LB after timeout. So, no gain even if your timeouts are reasonable.
It'd be great if you could return a custom response from nginx that would tell the LB to drop the request -- or you could move the exploit-detection logic to the LB instead of nginx, and the LB could do its own 444 equivalent.