←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. kortilla ◴[] No.27416120[source]
This isn’t “one person bought a bad camera”, it was certain ASNs accounting for a huge portion of the traffic. If the operators are unresponsive to the abuse request (making them incompetent network operators), then you absolutely block them. At that point the fallout is the fault of the network operators for operating an abuse friendly network.

This is how cloudflare handles it for normal web services. If you’re coming from trash IPs there is no chance a curl request is going to make it through to a backend without an onerous captcha.

replies(1): >>27416486 #
2. jeroenhd ◴[] No.27416486[source]
I wouldn't expect one person with one camera to cause such a load, but popular, cheap internet cameras pull this crap all the time. I remember reading a story here about one company that hardcoded a particular IP address for their NTP bootstrapping in their firmware, with thousands of devices all across the world and no way to easily update them. Such a thing can easily happen with consumer routers and other networking equipment, generating a publicly accessible link for their user's convenience.

If I saw the Time Warner ASN send too many requests, my first thought wouldn't be to just block a huge ISP. Who knows what mihjt be causing these issues and what you could be breaking by interrupting service.

The Time Warner NOC wouldn't be able to completely fix the problem if the source of the issue is the firmware of a certain shitty IoT device. If someone emailed their NOC about some weird IP cams installed by their customers causing load on their servers, they could feel like that's a problem between icanhazip and the camera manufacturer, not something they can fix.

The author is quite tolerant of the obviously malicious behaviour others are attacking his servers with. I'd have taken more aggressive measures instead of scaling up capacities myself. Because the problem is volume and not necessarily anything complex, I'd wager that even a simple block could be quite expensive because that traffic and the associated retries will be going somewhere. Directing the traffic towards the last router in their ASN through DNS would be something I'd consider, making it the problem of the network operators.