How to stop hack / dos attack on web API

Question

My site experiences a denial of service / hacker attack last week. The attack hits our web API with randomly generated invalid API keys in a loop.

I'm not sure if they are trying to guess the key (mathematically impossible, like 64-bit keys) or trying to attack the DOS server. The attack is spreading, so I can’t block the entire IP address, as it comes from hundreds of clients.

I assume that this is a Android application from IP addresses, so someone has malware in the Android application and all settings are installed to attack my server.

The server is Tomcat / Java, currently the web API simply responds 400 to invalid keys and caches IP addresses that made several invalid key attempts, but still some processing is required for every bad request.

Any suggestions on how to stop the attack? Is there a way to identify an Android application making a request from an HTTP header?

Answer 1

Prevention of brute force attacks:

There are many tools and strategies that will help you with this, and which are completely dependent on your server implementation and requirements.

Without the use of a firewall, IDS, or other network management tools, you will not be able to stop DDOS and also refuse to service your application. However, you can change your application to make brute force attacks much more difficult.

The standard way to do this is to implement blocking or progressive delay . Blocking prohibits the IP address from making a login request for X minutes if they cannot log in N times. Progressive delay adds a large and large delay for processing each failed login request.

If you use Tomcat authentication system (i.e. you have the <login-constraint> element in your webapp configuration), you should use Tomcat LockoutRealm , which makes it easy to put IP addresses in a lock as soon as they make a lot of failed requests.

If you are not using the Tomcat authentication system, you will need to post additional information about what you are using to get more specific information.

Finally, you can simply increase the length of your API keys. 64 bits seem to be an insurmountable huge number of keys to search, but its insufficient weight by modern standards. A number of factors can help make it much less secure than you expect:

• A botnet (or other large network) can make tens of thousands of attempts per second if you do not have protection.
• Depending on how you generate your keys and collect entropy, your actual key space may be much smaller.
• As the number of valid keys increases, the number of keys you need to try to find a real (at least theoretically) drop sharply.

Increasing the length of the API key to 128 (or 256 or 512) will not be expensive, and you will significantly increase the search space (and therefore complexity) of any brute-force attack.

Mitigation of DDOS attacks:

However, to mitigate DDOS attacks, you need to do a little work. DDOS attacks are tough to defend against them and especially hard if you do not control the network your server is running on.

As the saying goes, there are several server-side actions you can do:

• Install and configure a web application firewall, such as mod_security , to reject incoming connections that violate the rules that you define.
• Setting up an IDS system, such as Snort , to detect when a DDOS attack occurs and take the first steps to eliminate it
• See the @Martin Muller post for another great option, fail2ban
• Create your own Tomcat Valve , as described here , to reject incoming requests from their User-Agents (or any other criteria) as the last line of defense.

In the end, however, you can do this to stop the DDOS attack for free. A server has only so much memory, so many processor cycles, and so much network bandwidth; with enough incoming connections, even the most efficient firewall will not make you refuse. You can better attack 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 products to reduce consumer demand and DDOS Enterprise ( @SDude has some excellent recommendations in his post ). None of these options are cheap, fast, or easy, but they are affordable.

Bottom line:

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

Answer 2

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

• Register CloudFlare or Incapsula . This is day by day for them.
• Consider using the AWS API Gateway as a second step for your API requests. You'll enjoy filtering, throttling, security, autoscaling, and HA for your Amazon API. You can then redirect valid requests to your computers (in or outside of Amazon).

Internet → CloudFlare / Incapsula → AWS API Gateway → Server API

0.02

PS: I think this question relates to Sec

Answer 3

The best way is to prevent access to your services completely for those IP addresses that failed, say, 3 times. This will take up most of the download from your server, since the attacker is blocked before Tomcat even starts the flow for this user.

One of the best tools to achieve this is fail2ban ( http://www.fail2ban.org ). It is provided as a package on all major Linux distributions.

What you need to do is basically log failed attempts in the file and create a custom filter for fail2ban. Darryn van Tonder has a good example of how to write your own filter on his blog: https://darrynvt.wordpress.com/tag/custom-fail2ban-filters/

Answer 4

If the D-DOS attack is serious, application level checks do not work at all. All throughput will be consumed by D-DOS clients, and your application level checks will not be triggered. Almost your web service does not start at all.

If you need to protect your application from serious D-DOS attacks, you have no choice but to rely on third-party tools to pay money. One of the clean pipe providers (which only sends good traffic) that I can learn from my past experience: Neustar

If the D-DOS attack on your site is mild, you can implement application level checks. For example, the configuration below limits the maximum number of connections from one IP, as described in Limit calls from one IP

 <Directory /home/*/public_html> -- You can change this location MaxConnPerIP 1 OnlyIPLimit audio/mpeg video </Directory> 

For more information on the D-DOS attack, see the Wiki link . It contains a list of preventative and flexible tools, which include: Firewalls, switches, routers, IP address prevention, D-DOS-based protection

and finally

Clean pipes (all traffic is transmitted through a "cleaning center" or "cleaning center" using various methods, such as proxies, tunnels or even direct schemes that separate the "bad" traffic (DDoS and other common Internet attacks) and sends only good traffic outside the server)

You can find 12 clean pipe distributors.

Answer 5

Here are a couple of ideas. In addition, there are a number of strategies, but this should help you get started. Also understand that amazon gets ddos'd on a frequent basis, and their systems tend to have several heuristics that harden (and therefore you) from these attacks, especially if you use Elastic load balancing, which you should use anyway .

• Use CDNs - they often have ways to detect and protect against ddos. Akamai, craftsmanship or Amazons own a cloud front.
• Use iptables to blacklist offensive ips. The more tools you have, the faster you can lock / unlock

• Use throttling mechanisms to prevent large numbers of requests

• Automatically reject requests that are very large (say, more than 1-2 MB if you don’t have a photo upload service or the like) before they get into your application

• Prevent cascading crashes by setting a limit on the total number of connections to other components of your system; for example, do not let the database server overload by opening a thousand connections to it.

Answer 6

For a targeted and highly distributed DOS attack, the only practical solution (in addition to ensuring that it can be absorbed) is to profile the attack, identify hints, and route this traffic to a low-level handler.

There are some messages in your question - that the request is invalid, but there are apparently too many costs to determine. That requests originate from a specific group of networks and which are supposedly occurring in packets.

In your comments, you told us at least one other story - the user agent is null.

Without adding any additional components, you can start with a tarpitting connection - if a request that matches the profile appears, check and confirm the key, but then your code will be asleep for a second or two. This will reduce the number of requests from these customers for a small fee.

Another solution would be to use log errors matching the request and use fail2ban to reconfigure your real-time firewall to remove all packets from the source address for a while.

No, it is unlikely that you will be able to identify the application without capturing the damaged device.