How to stop hack/DOS attack on web API

Preventing Brute-Force Attacks:

There is a vast array of tools and strategies available to help you do this, and which to use depends entirely on your server implementation and requirements.

Without using a firewall, IDS, or other network-control tools, you can't really stop a DDOS from, well, denying service to your application. You can, however, modify your application to make a brute-force attack significantly more difficult.

The standard way to do this is by implementing a lockout or a progressive delay. A lockout prevents an IP from making a login request for X minutes if they fail to log in N times. A progressive delay adds a longer and longer delay to processing each bad login request.

If you're using Tomcat's authentication system (i.e. you have a <login-constraint> element in your webapp configuration), you should use the Tomcat LockoutRealm, which lets you easily put IP addresses on a lockout once they make a number of bad requests.

If you are not using Tomcat's authentication system, then you would have to post more information about what you are using to get more specific information.

Finally, you could simply increase the length of your API keys. 64 bits seems like an insurmountably huge keyspace to search, but its underweight by modern standards. A number of factors could contribute to making it far less secure than you expect:

• A botnet (or other large network) could make tens of thousands of attempts per second, if you have no protections in place.
• Depending on how you're generating your keys and gathering entropy, your de facto keyspace might be much smaller.
• As your number of valid keys increases, the number of keys that need to be attempted to find a valid one (at least in theory) drops sharply.

Upping the API key length to 128 (or 256, or 512) won't cost much, and you'll tremendously increase the search space (and thus, the difficulty) of any brute force attack.

Mitigating DDOS attacks:

To mitigate DDOS attacks, however, you need to do a bit more legwork. DDOS attacks are hard to defend against, and its especially hard if you don't control the network your server is on.

That being said, there are a few server-side things you can do:

• Installing and configuring a web-application firewall, like mod_security, to reject incoming connections that violate rules that you define.
• Setting up an IDS system, like Snort, to detect when a DDOS attack is occurring and take the first steps to mitigate it
• See @Martin Muller's post for another excellent option, fail2ban
• Creating your own Tomcat Valve, as described here, to reject incoming requests by their User-Agents (or any other criterion) as a last line of defense.

In the end, however, there is only so much you can do to stop a DDOS attack for free. A server has only so much memory, so many CPU cycles, and so much network bandwidth; with enough incoming connections, even the most efficient firewall won't keep you from going down. You'll be better able to weather DDOS attacks if you invest in a higher-bandwidth internet connection and more servers, or if you deploy your application on Amazon Web Services, or if you bought one of many consumer and enterprise DDOS mitigation products (@SDude has some excellent recommendations in his post). None of those options are cheap, quick, or easy, but they're what's available.

Bottom Line:

If you rely on your application code to mitigate a DDOS, you've already lost

If it's big enough you just can't stop it alone. You can do all the optimisation you want at the app level, but you'll still go down. In addition to app-level security for prevention (as in FSQ's answer) you should use proven solutions leaving the heavy lifting to professionals (if you are serious about your business). My advise is:

1. Sign-up for CloudFlare or Incapsula. This is day to day for them.
2. Consider using AWS API gateway as the second stage for your API requests. You'll enjoy filtering, throttling, security,auto-scaling and HA for your API at Amazon scale. Then you can forward the valid requests to your machines (in or outside amazon)

Internet --> CloudFlare/Incapsula --> AWS API Gateway --> Your API Server

0,02

PS: I think this question belongs to Sec