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

Let us serve you, but don't bring us down

blog.archive.org

Post reply on HN
Print view View original

31–40 of 255 posts

Re: Let us serve you, but don't bring us down

#31

Post by pfooti »

jb_gericke wrote: post #21
pfooti wrote: post #5

I run a system at my employer that occasionally gets scraped by malicious users. It can be used to infer the purchasability of a specific domain, which is a moderately-interesting API endpoint, since that requires talking to domain registries. For a while, nobody cared enough about it to abuse the endpoint. But then we started getting about 40 QPS of traffic. We normally get less than 1. I was keeping an eye on it, b…

Why not put auth on the endpoint and enforce quotas and rate limiting (an api gateway like kong could handle this for you).

Endpoint was invoked in our signup funnel, so there was a bootstrapping problem for quota enforcement, the attackers weren't making a whole signup, just getting to the point where the domain search ran.

Re: Let us serve you, but don't bring us down

#32

Post by jszymborski »

reaperman wrote: post #27
akiselev wrote: post #17

Earlier quoted context omitted.

How are they getting millions of ipv4 addresses? IIUC that’s at least the equivalent of a /12 block. Do those shady residential proxies really operate at that scale? If they’re ipv6 address wouldn’t they be safe to block across large ranges?

It is trivially easy to get millions of IPv6’s, even spread out across a thousand ranges. It is also trivially “easy” to get past reCAPTCHA, but it costs more. My guess is that a domain name checker tool isn’t worth the cost per request to bypass reCAPTCHA (approximate 0.02 cents per session)

Right, but this is why the GGP's post suggested throttling IPV6. Or at least that was my understanding.

Re: Let us serve you, but don't bring us down

#33

Post by tastysandwich »

I have a side project that scrapes thousands and thousands of pages of a single website.

So as not to piss them off (and so they don't try to block me), my script will take about 6 hours. Between each page fetch it sleeps for a small, random amount of time. It's been working like that for years.

Re: Let us serve you, but don't bring us down

#34

Post by rapnie »

pfooti wrote: post #5

I run a system at my employer that occasionally gets scraped by malicious users. It can be used to infer the purchasability of a specific domain, which is a moderately-interesting API endpoint, since that requires talking to domain registries. For a while, nobody cared enough about it to abuse the endpoint. But then we started getting about 40 QPS of traffic. We normally get less than 1. I was keeping an eye on it, b…

Maybe mCaptcha [0] is worth a look. It applies a Proof-of-Work like algorithm (not blockchain-related) which makes it very expensive for scrapers to get data in bulk, but poses least amount of friction to individual users. The project is implemented in Rust and received NGI.eu/NLnet funding. I don't know its state of production-readiness, but Codeberg.org is considering using it (this choice is informed by higher respect for privacy and improved a11y compared to hCaptcha).

[0] https://mcaptcha.org/

Re: Let us serve you, but don't bring us down

#35

Post by pfooti »

boulos wrote: post #29
pfooti wrote: post #5

I run a system at my employer that occasionally gets scraped by malicious users. It can be used to infer the purchasability of a specific domain, which is a moderately-interesting API endpoint, since that requires talking to domain registries. For a while, nobody cared enough about it to abuse the endpoint. But then we started getting about 40 QPS of traffic. We normally get less than 1. I was keeping an eye on it, b…

Rate limit and return a 429?

See sibling, but the endpoint was part of a signup funnel, so short of rearchitecting it completely to put that check after customer creation, there's no real persistent key to rate limit on. Any one IP ended up getting rate limited to 5 requests per hour on that API, but the attack was incoming from what looked like a botnet, so it was tricky.

Re: Let us serve you, but don't bring us down

#37

Post by Defletter »

akiselev wrote: post #25
p-e-w wrote: post #8

Earlier quoted context omitted.

Indeed. Tens of thousands of requests per second from just 64 hosts? So they allow individual hosts to make hundreds of requests per second, sustained? That sounds crazy. Even for a burst limit hundreds per second would be extremely high.

Archive.org is a core utility for the web to the point where Wikipedia and many other sites would collapse without it in the sense that many if not most of their outbound links would be dead forever. I’m pretty sure it would even impact the US justice system [1]. Obviously judges aren’t going to have to worry about reasonable rate limits but if these DDoSes are rare, I’d much rather they dealt with them on a case by…

Probably not just the US justice system. I also guess that academia would take a hit too. Not every citation is of a published paper.

Re: Let us serve you, but don't bring us down

#39

Post by reaperman »

jszymborski wrote: post #32
reaperman wrote: post #27

Earlier quoted context omitted.

It is trivially easy to get millions of IPv6’s, even spread out across a thousand ranges. It is also trivially “easy” to get past reCAPTCHA, but it costs more. My guess is that a domain name checker tool isn’t worth the cost per request to bypass reCAPTCHA (approximate 0.02 cents per session)

Right, but this is why the GGP's post suggested throttling IPV6. Or at least that was my understanding.

The 500ms latency will help a lot if tons of requests are coming in serial. But most likely they are coming in parallel.

It’s hard to “throttle” a single isolated request from a lone IP.

Re: Let us serve you, but don't bring us down

#40

Post by crote »

copperx wrote: post #16

I'm not an expert in networking, but isn't this scenario Cloudflare's bread and butter? Is there any reason to not outsource this problem?

It depends. A CDN-like approach wouldn't really work because all requests are different and legit, so plain old caching isn't going to cut it.

On the other hand, Cloudflare has quite some experience with DDoS protection, so they definitely have the right infrastructure in place to stop this kind of abuse. What is the bill going to be, though?

Post reply on HN