1

Hi I just wanted some feedback on a DDOS preventing php script that I'm designing. It is quite simple and I wanted some feedback on whether you guys think it would be effective.

I'm currently using the ulogin framework as a base and have implemented API Keys. At the moment the user will send a request with a key. This key is checked against the database to see if it correct. So if the key is not correct the program will return.

If the key is correct then some statistics are going to be calculated. The first thing is to increment the counter. The average hit per second will be calculated from the time they started requesting to the current time. Also there is a window of X seconds in which the counter will be reset (Lets say 300). The programmer specifies the max number of requests that should be allowed in this window. If the key is over the limit of requests per stats reset (Window) or over a certain amount of requests per second, they will be blocked and not given access. However the counter still increments but another counter is started (blockcount).

When the counter is set to 0 at the end of the window, the count for the next window will be set to what ever the blockcount is and the blockcount will be set to 0. If the user doesn't use the API key for X (window) seconds then both counters will be reset to 0.

I have added a transferpenalty variable (0-1) that will take a percentage of the blockcount on to the next window instead of the entire block count but I don't think that it is neccessary to have this.

Is this already being done? Would this protect against a sniffed API key being used to (D)DOS a server? What are your thoughts :)

0

The fact you must check a database leaves your DDOS script vulnerable to that sort of attack. The key to guarding yourself against this sort of thing is building a protective layer that responds quicker than the DOS attackers can send requests your way while still allowing legitimate traffic to access internal resources. I doubt a database can be quick enough.

You might need to store these stats in a persistent memory store like memcached, which has its own security concerns because it is not authenticated.

  • 1
    The only query to the database is to update the counters – Harry Jul 26 '14 at 18:17
  • I would load test your solution to see what it can stand. Just throw traffic at it until it cries uncle. – Greg Burghardt Jul 27 '14 at 1:37
  • I've created an attack script and it seems to be dealing with it fine. The traffic that we're expecting is maybe max 100 views a day. The key thing is that if the key is detected as requesting to much it will stop being return any information so this should stop the attackers requests from causing a problem. – Harry Jul 28 '14 at 15:19

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.