[Q/discussion] DDOS possibility about pictshare

[geek-at]

Good topic! On the old pictshare before the rewrite I had two more configuration settings. One was for max resizes per image and one was a resize code that hat do be present in the URL for the resize to be successful.

I didn't implement them in the new version because it was hardly ever used and even the public instance on pictshare.net never had any real problems with ddos but I do share your concern.

I'm not sure if the "max resize" setting is enough because that could potentially limit yourself too because it would be a server wide rule and not just for cpu intensive things.

What do you think would be a good solution for the problem?

[geek-at]

Yes a setting for disabling resizes of videos will be coming, that makes sense for server admins.

I was also thinking about making a queue (probably with redis) that only resizes one video at a time so even though the queue can become big, it will never crash or ddos the server

[Aivean]

The first thing that comes to mind is a rate limiter of some kind.

A very basic rate limiter (max N requests per period) that doesn't require a DB or shared memory can be implemented via the append-only log of timestamps: for each stored videofile have a log of the timestamps of the resize attempts. When a new resize attempt is made, check the timestamp of the Nth last record in the log, if it's earlier than period, allow the resize, otherwise deny it.

An IP-based rate limiter for all heavy operations would be ideal, but it would be tricky to implement in a performant way without the shared memory.

As a simplest band-aid solution, a config that entirely disallows video (or any) resizes could also work for some security-sensitive applications.

[Aivean]

Queue is a good idea, however one concern is that malicious agent would be able to saturate the queue and delay/prevent legitimate resizes.

[geek-at]

good point! maybe per video a queue limit of 3 or so per hour per IP? but a distrubuted attack would render that useless

[Aivean]

Well, there are two somewhat separate issues:

1. service DOS (load from resizing interfering with the serving or other server functions).
   Can be addressed by putting constraints on the resize work.
2. resizing DOS (i.e. malicious party denying resizing to other users).

Ideally, these would be addressed separately, e.g.:

• resizing load could be limited by the isolated, resource-bounded workers with the constraints on parallelism
• DOS can be mitigated by having IP-based and global rate-limiters, and/or using cloud-based DDoS protection in front of pictshare instance

With the current API (resizing happens anonymously on demand) I'm not sure if ideal solution is feasible. For example, if both uploading and resizing were tied to some sort of account (e.g. by an auth token), it would be possible to just add the restrictions per account.

But for the current design, the safest solution (which only really addresses the first problem) would be a global resize rate limit, together with the queue to flatten the peak load.