Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Setting Rate Limiting in CloudHub to Prevent DoS Attacks

DZone's Guide to

Setting Rate Limiting in CloudHub to Prevent DoS Attacks

Denial of Service, or DoS, attacks, are one of the more common cyberattacks on there. Learn how to secure your Mulesoft CloudHub app against them.

· Security Zone ·
Free Resource

Discover how to provide active runtime protection for your web applications from known and unknown vulnerabilities including Remote Code Execution Attacks.

1. Overview

The MuleSoft CloudHub environment, at an abstract level, consists of 3 main components. If your Mule Application is being exposed as a Rest API endpoint, then you would most likely be using the API manager.

Figure 1

API Manager allows the user to create RAML definition files as well as policies. As there are many reference documents about RAML definitions, I will not talk about that here, but instead, we will look at policies. The API Gateway components are given the least love by users and that's because it's not exposed for usage compared to its more famous counterpart (the API manager and the Runtime Manager).

The API Gateway is a component that implements the policies that are configured in the API Manager. Figure 1.0 shows a typical user request to access a Mule application that is running on the Runtime Manager. At (2) the API gateway would validate and authorize the user's request, if the request is authorized, the gateway would then allow the user request to proceed to step (3), the Mule Application. But, if the user request does not meet the policy specified by the API gateway then it would be rejected by the API Gateway and a 4XX HTTP response code (and its associated message) would be sent back to the user.

2. Setting Up SLA Tier Based Rate Limiting

With the understanding that we have gained from section 1, we can now talk about the rate limiting policy and SLA Tiers. As their name suggests, rate limiting policies are implemented so that the API gateway could reject a request if it is deemed too frequent during a given a duration of time. Figure 2 shows a rate limiting SLA-based policy being configured:

Figure 2

The details of this configuration are as depicted in Figure 2a, below: 

Figure 2a

For rate limiting to happen, the API gateway needs a form of identification for requesters who are making the request, in which it intuitively enforces users to submit a client ID and client secret to the API for all the requests that they will be issuing. If the API gateway sees too many requests submitted by a particular client ID, it would then reject the request until the specified duration has been reset.

The policy that we put in place in Figure 2 lays the foundation for setting up SLA tiers. Figure 2b shows two SLA tiers that are configured.

Figure 2b

The settings for the GOLD SLA tier allow a user to send 5 thousand requests per hour. If the users of the GOLD SLA tier sent 5001 requests within one hour, then request number 5001 would be rejected (Figure 2c depicts GOLD tier settings).

Figure 2c

API users that have subscribed to the Silver tier would only be allowed to send 1000 requests per hour (settings for the silver tier is as per Figure 2d).

Figure 2d

3. Conclusion

At the time of writing this post, there are two types of rate limiting policies.

  • Rate Limiting Policy - The simplest form of rate limiting policies applies as a blanket policy across all API users, this policy cannot be used in conjunction with SLA tiers. Rate limits of SLA Tiers will always be ignored if this policy is implemented (as it has a higher precedence when compared to SLA Tiers).

  • SLA Based Rate Limiting Policy - Rate limiting is based on SLA tier subscriptions that are allocated to the API user, which is what was demonstrated in this document.

I would obviously recommend the usage of SLA Based rate limiting as we could apportion the usage of the API according to user/usage groups on a case by case basis. The other benefit of having rate limiting in place is to prevent a denial of service (DoS) attack.

Find out how Waratek’s award-winning application security platform can improve the security of your new and legacy applications and platforms with no false positives, code changes or slowing your application.

Topics:
mulesoft ,api manager ,api gateway ,security ,denial of service

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}