Live data from Hacker News

Block web scanners with ipset and iptables

nbailey.ca

11–20 of 46 posts

Re: Block web scanners with ipset and iptables

#12

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.

That was mostly just for the blog post. In reality my default vhost 301's back to the IP that sent the request. I doubt it ever does anything, but I like to think it makes hackers attack themselves in the confusion :p

I also have a fake /admin path that just contains a bunch of offensive/illegal phrases in 10 ish languages, but it was out of character for the post.

444 is a good idea though, I didn't know about that response code!

Re: Block web scanners with ipset and iptables

#14

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.

You will like this more elaborate attacks you can do to those bots https://www.hackerfactor.com/blog/index.php?/archives/762-At...

Re: Block web scanners with ipset and iptables

#15

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.

I use "402 Payment Required“ right now, which is sent to the client. Didn't know about 444, which isn't listed on the Wikipedia page about HTTP return codes ...

Re: Block web scanners with ipset and iptables

#17
What are some best practices to deal with in on a PC? I mean, by default pretty much everything is closed and it's not like there is any "legitimate traffic" at all, but over time it still accumulates some open ports by running stuff in docker and elsewhere: a jupyter console here, an MPD UI there — most of the time I don't even think about the fact that I'm constantly scanned by someone, and remember only after I see some logs and get disturbed by the number of rude guests.

Re: Block web scanners with ipset and iptables

#18
post #15

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.

I use "402 Payment Required“ right now, which is sent to the client. Didn't know about 444, which isn't listed on the Wikipedia page about HTTP return codes ...

It is listed on wikipedia, but under "Unofficial Codes -> nginx" as it is nginx specific and not standardized.

Re: Block web scanners with ipset and iptables

#19
post #17

What are some best practices to deal with in on a PC? I mean, by default pretty much everything is closed and it's not like there is any "legitimate traffic" at all, but over time it still accumulates some open ports by running stuff in docker and elsewhere: a jupyter console here, an MPD UI there — most of the time I don't even think about the fact that I'm constantly scanned by someone, and remember only after I se…

I have used wail2ban and just started using ipban
Post reply on HN