Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Block web scanners with ipset and iptables

nbailey.ca

Post reply on HN
Print view View original

21–30 of 46 posts

Re: Block web scanners with ipset and iptables

#21

Post by gerdesj »

thrwawy74 wrote: post #13

Not to detract from the article, but we should be using nftables in 2022. :-) https://wiki.nftables.org/wiki-nftables/index.php/Moving_fro...

I started with ipfw, then ipchains, then iptables and now nftables. That is just on Linux.

To be fair: I just downloaded a ipfw setup and didn't give it much thought. I spend several weeks hand crafting several ipchains scripts. I spent ages with iptables and wrote a rubbish multi WAN effort and eventually ditched it for pfSense for edge. More ages for a host based effort. I also use ufw quite a bit for iptables. I use firewalld for nftables, these days.

Re: Block web scanners with ipset and iptables

#23

Post by TacticalCoder »

thrwawy74 wrote: post #13

Not to detract from the article, but we should be using nftables in 2022. :-) https://wiki.nftables.org/wiki-nftables/index.php/Moving_fro...

He probably is in a way. iptables is now just a wrapper around nftables and nftables understand the iptables syntax.

Re: Block web scanners with ipset and iptables

#24

Post by Avamander »

gw98 wrote: post #16

I've been using fail2ban to kill this for years. Seems to be quite effective: https://github.com/fail2ban/fail2ban

If possible, report the hosts you block using f2b to AbuseIPDB or similar projects. That way we'd be collectively better able to hinder this abuse.

Re: Block web scanners with ipset and iptables

#26

Post by quesera »

justin_oaks wrote: post #9

I 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.

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".

Re: Block web scanners with ipset and iptables

#29

Post by treffer »

quesera wrote: post #26
justin_oaks wrote: post #9

I 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.

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.

Post reply on HN