Hacker News Reader

Comment by flockonus | Hacker News Reader

Have you considered putting cloudflare or similar CDN with unlimited egress in front of your bucket?

Reading your blogpost I don't fully get how the current signing implementation can halt massive downloads, or the "attacker"(?) would just adapt their methods to get the signed URLs first and then proceed to download what they are after anyway?

View on HN

You cannot just put Cloudflare in front of your Google hosted bucket, that's against CF's terms of service. In order to do that you would have to also host the content itself on Cloudflare R2/Images etc. There used to be also html only restriction but that's no longer the case.

> Next, we got rid of the antiquated HTML vs. non-HTML construct, which was far too broad. Finally, we made it clear that customers can serve video and other large files using the CDN so long as that content is hosted by a Cloudflare service like Stream, Images, or R2.

https://blog.cloudflare.com/updated-tos/

This is absolutely nuts to me and would immediately rule out ever hosting anything on google storage for me

It’s Cloudflare’s, which prohibits usage not directly related to hosting web content.

i cant delete this but i misread original comment.

Where is this against the GCP or CloudFlare's TOS?

Lots of people do this, so you definitely can do this even if its against CF's terms of service, which is something I can't find evidence of.

> Cloudflare reserves the right to disable or limit your access to or use of the CDN, or to limit your End Users’ access to certain of your resources through the CDN, if you use or are suspected of using the CDN without such Paid Services to serve video or a disproportionate percentage of pictures, audio files, or other large files.

If you're putting the CDN in front of a bucket with nothing but images, you're automatically in breach.

https://www.cloudflare.com/service-specific-terms-applicatio...

The issue would be if you just did it for the bucket but didn't load any web pages through cloudlfare, as long as your website uses cloudlfare, this is a very normal and supported use case. You might potentially run into problems if you used it just for the bucket, the pages (or what ever else) the images in the bucket are normally called from aren't using cloudlfare so cloudlfare just sees your bucket and nothing else, I've never come across people having issues with this but I've only ever seen it for people who have at least some of their normal traffic also going through cloudlfare.

Is this your private opinion, or your professional one?

Because that sentence doesn’t cut the mustard in a professional setting. That’s a FAFO sentiment.

FAFO: F*ck Around and Find Out

It is indeed FAFO, because Cloudflare doesn't spell out what counts as "a disproportionate percentage" of multimedia assets.

If I serve an HTML page through Cloudflare that loads 100 images, each of which is 10x the size of the HTML page, then 99.9% of my bandwidth usage will be images. Is that a disproportionate percentage? It's entirely at Cloudflare's discretion, they can kick out anyone they don't like.

I spend a lot of time at work trying to make sure we have our surprises as known unknowns, not unknown unknowns. And that includes avoiding surprises that are entirely in a third party’s control. I’ve heard too many stories of cron jobs shutting people off a midnight. And too many of them shutting you off on the first. Which sometimes comes on a Saturday. If I’m awake at midnight on a Saturday I’m not in a place where I want to deal with a surprise like that.

Give me something with fast feedback, where I can warn myself and others that some serious shit might happen when I push this button. Not random shit at midnight or 00:00 GMT.

You totally can, just not a "disproportionate percentage"

That's when you're caching a whole page which contains images. The OP is talking about putting the CDN in front of a bucket which doesn't serve anything but images (= 100%).

You can easily work around that problem by putting the CDN in front of everything, including web pages and API calls, not only your bucket of images.

OP might want to do that anyway, since the attacker will now be hammering their Rails app instead of just the bucket.

Yup. The only mitigation here is that there is a limit to how many different asset URLs they will be able to generate, but if they want to be malicious they can download the same file over and over again and still make you rack up a huge bill.

This is true. I’d still need a CDN in front of the actual files to prevent that. That’s a takeaway for me from this feedback.

10k req/s would potentially crash the ruby proxy server halting the image serving.

Cloudflare is the way to go. I generally serve heavy files, e.g. videos, from a Cloudflare bucket to avoid expensive bills from primary host.

Honestly, I would just move to R2 and save on egress fees even without the CDN. Runaway egress bills are no fun.

I saved myself thousands $/mo moving to R2.

What is R2?

Cloudflare's S3-compatible offering with zero egress fees: https://www.cloudflare.com/developer-platform/r2/

Putting a CDN in front would prevent this at the bucket level, but then someone could still hit the CDN at 10k requests/second. We could rate limit it there though, which would be nice.

The downside is that people already have the URLs for existing bucket directly. So we'd need to change those either way.

The reason why the attacker couldn't just hit the API to get the signed URLs is due to rate limiting that I go over using the rack-attack ruby gem. Since that's limited to 60/second, that's more like 43k images/day max.

> someone could still hit the CDN at 10k requests/second

CDNs have mechanism to rate limit that you can easily configure, and they will be better at this than a ruby gem (no offence to that).

On Ruby you're taking on the rate limiting job down to your CPU and limited visibility per IP... idk man, cloudflare is 20/month.

Reply on news.ycombinator.com