←back to thread

980 points nkcmr | 2 comments | | HN request time: 0s | source
Show context
sneak ◴[] No.27415684[source]
This story is kind of sad. I wonder why the operator didn't blacklist certain netblocks/ASNs who were abusing the service.
replies(2): >>27415700 #>>27415833 #
thegeekbin ◴[] No.27415700[source]
Why punish a group for one bad actor?
replies(3): >>27415744 #>>27415950 #>>27420384 #
zootboy ◴[] No.27415744[source]
> There were many times where I saw a big traffic jump and I realized the traffic was coming from the same ASN, and likely from the same company. I tried reaching out to these companies when I saw it but they rarely ever replied. Some even became extremely hostile to my emails.

A hostile reply from a netblock operator seems like a perfectly valid reason to block their traffic.

replies(2): >>27415830 #>>27416276 #
jeroenhd ◴[] No.27415830[source]
The problem is that you don't know what the source of the traffic is. It could be an incompetent network operator/sysadmin, but it could just as well be something like an IP camera that people bought in good faith. If you block the CGNAT system of an operator that has a hundred million subscribers because it all seems to come from a single IP range you know nothing about, you could be hurting innocent users with the block.

That being said, a service like this doesn't come with any guarantees and if it'd disappear from the net tomorrow, I wouldn't blame the author. Blocking is a perfectly valid solution to this problem, but assuming malice isn't always the right answer.

Were I in this situation, I'd rate limit networks per /24 (maybe even /16?) as much as I could, and work together with antivirus companies to help identify infections of malware known to use the service to discourage criminals from abusing the system. I wouldn't even bother hosting the site on IPv6 since those addresses are supposed to be public anyway. The author clearly has more patience than I do.

replies(5): >>27415962 #>>27415994 #>>27416120 #>>27418637 #>>27419013 #
1. terom ◴[] No.27415962{3}[source]
Looking at the icanhazip.com site, I wonder how much any kind of rate-limiting per address/block would even help.

At the HTTP level it's probably cheaper to just return the HTTP 200 response. I suppose if you're doing TLS handshakes then a packet-level rate-limit would help significantly, but at the same time I'd be wary of triggering any kind of retry-behavior.

Worst-case scenario for a service like this would be having an error response/timeout trigger some kind of unlimited retry flood.

replies(1): >>27416337 #
2. jeroenhd ◴[] No.27416337[source]
The block route I'd go with is blackholing the entire range into nothing through BGP or similar so the servers wouldn't have to deal with the traffic, similar to how anti DDOS tools often work. Might even redirect the DNS for that subnet to the IP of the people running the network, let them deal with the abuse. That'd be a very offensive approach, though.

I probably wouldn't bother with TLS either, just a plain HTTP 0.1 response with minimum information should be enough.