I am new to the IT Security field and am essentially a developer as opposed to a networking person hence the question may be a dumb one

I am writing a REST service exposed to the internet which accepts files to be uploaded to the server, and the size could be up to 5 MB. We have restrictions on the server side to not accept content greater than 5 MB, but this happens after the fact - meaning after the content has been uploaded and we are already reading it. Which raises a few security related questions on DDOSing of our service:

  1. What happens if a bot net starts uploading 100MB files from 100 machines at the same time. This would mean that our network pipes are clogged handling 10GB of data while slowing down our real customers? How do we even detect such an attack where the number of servers are so less. Can we configure our IT infrastructure to block requests by payload size based on the service being accessed (we have multiple services hosted in our IT infrastructures)?
  2. Can you turn back requests from your IT infrastructure whose content length goes beyond a certain limit?
  3. In general, for a server which accepts POST/PUT requests, how do you protect from an attack which just uploads files on the POST request, even though the server is not meant to accept file uploads?
  • I think the question if off-topic here. It's a very simple math formula how many clients can upload data to you at the same time, so the question is how to write code (or configure your servers) such that the system throttles clients when there is too much data. I think this question is more fit for StackOverflow (if you want to solve it with code) or Serverfault (if you want to solve it with configuration).
    – Luc
    Jul 28, 2013 at 16:12
  • 1
    The question was not how much data we can accept at the same time. The question was how do you detect such an attack, and how do you protect from such malintentioned uploads. The problem with solving it with code is that then the data has already consumed your bandwidth, which is what I wanted to avoid.
    – coderSam
    Jul 28, 2013 at 17:16
  • 1
    You're right. This is a threat to your web service. What to do about it? Wish there was an easy answer. There are strategies. This question is general enough that you should look at google for 'how to prevent a ddos attack' and read up. No specific answer available.
    – Jonathan
    Jul 28, 2013 at 18:18
  • 2
    @coderSam Couldn't you just read up to 5MB and if you receive another packet then it returns an error? Then again they could just send a bunch of small files.. so you still lose. Jul 28, 2013 at 20:30
  • @coderSam Ah okay, then I misunderstood! That sounds like it's at least on-topic here.
    – Luc
    Jul 28, 2013 at 21:54

3 Answers 3


but this happens after the fact

Really? What webserver are you using (you forgot to tell us). Apache, nginx, lighttpd all have options to limit the size of a request (the request is dropped if the client supplies a size greater than the limit in the header or the limit of data is received by the server).

If you want to validate the size before uploading it then you'd have to implement a non-sandboxed java applet.

This would mean that our network pipes are clogged handling 10GB of data

No - not if you implement QOS based traffic management. This can be tricky to do on the operating system (again you forgot to tell us what this is) - if you are using Apache then have a look at mod_qos or mod_bw

How do we even detect such an attack

Active monitoring + automated responses - If you're using some flavour of Unix, then ensure your webserver is confiugred to cap the post size and LOG MESSAGES on violation, then set up fail2ban to process those messages.

Can you turn back requests

Yes - see above. The only caveat is that someone trying to kill your servers may tell fibs in the content-length header (which is optional anyway).

  • Sorry for the delayed response. We are using apache http server, mule running on RHEL. Problem with content length is that, as you said, it can be forged. Validating the content length before upload is not possible as its a REST service exposed for anybody to call from the internet. Hence we would need something which can check incoming packets, link them together and as soon as its above 5MB, reject it. Is that possible? With deep packet inspection?
    – coderSam
    Aug 6, 2013 at 5:34
  • About QOS based traffic management, are you talking about mod-qos? Any specific guidance, reference you could give?
    – coderSam
    Aug 6, 2013 at 5:40
  • mod_qos is one solution (IIRC it supports minimum bandwidth guarantee). If you've got enough traffic, simply disabling the window scaling may be a viable solution. I've avoided using tc / tcng - I don't find it very intuitive - but it's available without installing any additional software.
    – symcbean
    Aug 6, 2013 at 8:07

What would happen if the attacker sends the data at the same bandwitch, but keeping up to your size limit? What's the difference between sending 100 100MB files, and sending 10000 1MB files?

If you want to be immune to DDOS attack, than you can forget - you can't. Event the biggest giants are affected by such attacks from time to time. Even the biggest server farms have traffic limitations.

What if you're under attack? The best you can do is to identify the sources of the attack and drop them on routers. That may be the single IPs, but it may be necessary to drop the whole IP ranges, or even the whole traffic from particular countries. It can (and probably will) affect many of your clients, but, hopefully, it will allow the others to operate.

Some of such blocks can be made by scripts, but mostly it may need to be taken manually. How to distinguish between a user uploading his whole summer picture collection from fake requests? What request rate should trigger a response? It's a very hard question, if someone innocent gets blocked, it's often a lost client.

Then you must strike back. A DDOS attack is as legal as pushing old plastic bottles into your letterbox - you must identify and disable the offenders. The IP providers should shut down their clients that are conciously doing mischief. The software producers should fix their products, if the cause of the chaos is a virus or a worm. Finally, there are legal institutions that should find the authors of such attack.

Honestly, DDOS is such a big offence (taking control over a large amount of servers or home computers) that you'd have to make some really big enemies to be the aim of such an attack. So if you're neither rich nor famous nor influential nor extremistic, the chances for such an attack are very low.

  • 2
    In addition to this great answer: You could impose a strong rate limit on anonymous users and a less strict one for registered users. GitHub does this with their API and there are many others out there using the same technique.
    – Max
    May 9, 2016 at 18:11

Read posts as a stream byte by byte, when you hit the 5MB limit simply return an exception and close the connection.

It's not hard to handle requests this way and most up to date web frameworks can do this.

As an additional protection log IP addresses and look for flooding / subnets of IP's in rejection logs and then have an instant drop policy in place that will have the server instantly close the file stream from a known dos IP.

A typical user will do it once or twice then stop trying and contact an administrator or something, a hacker / botnet will just keep trying no matter what generally so it's not hard to spot the problem IP's.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.