{{announcement.body}}
{{announcement.title}}

Implementing DDoS With MuleSoft: Demonstration With Apache JMeter

DZone 's Guide to

Implementing DDoS With MuleSoft: Demonstration With Apache JMeter

In this article, we discuss how to stop DDoS attacks with MuleSoft by limiting the number of time a user can hit a certain API endpoint.

· Integration Zone ·
Free Resource

DDoS (Distributed Denial Of Service)

A Distributed Denial-of-Service (DDoS) is any type of attack where the attackers attempt to prevent legitimate users from accessing the service. In a DDoS attack, the attacker usually sends excessive messages asking the network or server to authenticate requests that have invalid return addresses.

How to Prevent DDoS Attacks

There are different ways we can prevent DDoS attacks; we can do IP blacklisting to avoid traffic from sources of attack, rate limit your application to prevent it from being overwhelmed, or use both of them to provide multiple layers of security.

Here, we will see Rate limiting with SLA way of doing it.

You may also like: Everything You Need to Know about DDOS: What Is a DDOS Attack?

Rate Limiting With SLA

Rate Limiting policies based on Service Level Access (SLA) are client ID-based policies that use the client ID as a reference to impose limits on the number of requests that each application can make within a period of time.

To implement Rate Limiting with SLA in Mulesoft and then test with JMeter you need the following prerequisites: 

  • Create an API and deploy it to Runtime Manager.
  • Apache JMeter to test the policy.

Let's see how to implement Rate Limiting with SLA in MuleSoft. Let’s create an API proxy from the API manager for our existing application called, “demo”.

Manage API from exchange

Manage API from exchange

Creating demo API

Creating demo API

Provide Implementation URL, which will be base URI for our application, “demo”.


Providing implementation API

Providing implementation API

Now, let’s deploy the API proxy to the Runtime Manager.

Deployment Configuration

Deployment Configuration

Deploying API proxy

Deploying API proxy

Now, once we have created the proxy and deployed to Runtime, we get an APP URL for proxy, which we need to update as consumer endpoint in API settings.

This consumer endpoint is what we are going to use for further invocation of our API instead of using applications Cloudhub URL.

Consumer endpoint

Consumer endpoint

Let’s test the application without any policies.

As you can see, we are able to hit the application via our API proxy.

Hitting endpoint with API proxy

Hitting endpoint with API proxy

For applying the Rate Limiting policy with SLA, which will help prevent DDOS attacks, we need to first create SLAs.

So, let’s create two SLA tiers, as shown below:

  • Basic:
    • Number of requests: 2.
    • Time period: 30.
    • Time unit: seconds.
  • Advance:
    • Number of requests: 100.
    • Time period: 30.
    • Time unit: seconds.

In API Manager, under SLA Tiers, click on the button, Add SLA Tiers to add SLAs.

Adding SLAs

Adding SLAs

Create “Basic SLA Tier”.

Adding SLA Tier

Adding SLA Tier

Basic SLA tier

Basic SLA tier

Create “Advance SLA Tier":

Creating Advance SLA tier

Creating Advance SLA tier

So, now we have 2 SLA tiers. Let's now create an SLA-based Rate Limiting policy.

Creating SLA-based limiting policy

Creating SLA-based limiting policy

After selecting the version, click on Configure policy.

Configuring policy

Configuring policy

Click on apply with default configuration.

Applying default configuration

Applying default configuration

Now, you can see Rate limiting - SLA based policy in API level policies.

Rate Limiting SLA-based policy

Rate Limiting SLA-based policy

Now, to test this policy, we're required to create two applications, one each for each SLA tier.

Go to Exchange, open asset “demo”, and request for access with the SLA tier selected as “Basic”. 

Requesting access

Requesting access

After requesting access, you will get a client_id and client_secret. Store them in your notepad for future use.

Creating Client Id and Client Secret

Creating Client Id and Client Secret

Let’s do the same for the Advance SLA tier. This time you will need to create a new application.

So, let's create an application “demo-advance” for the Advance SLA tier.

Creating new application

Creating new application

After requesting access, we will get another set of client_id and client_secret, which we will store in Notepad.
Creating Client Id and Client Secret

Creating Client Id and Client Secret

Testing With JMeter

Now, we are ready to test whether our policy is working or not. We will be testing using JMeter, which you can download from https://jmeter.apache.org/download_jmeter.cgi.

After downloading, unzip into the preferred location on drive and go to the \bin folder.

Double click on jmeter.bat for windows

Adding JMeter

Adding JMeter

You will see an empty Test plan. Test Plan is where actual tests are kept.

Test plan

Test plan

Testing Basic SLA tier

Let's create a ThreadGroup under TestPlan, which is where we define all threads and related properties for our execution.

Testing basic SLA

Testing basic SLA

The previously defined Basic SLA tier has the following config:

      No of requests: 2.

      Time period: 30.

      Time unit: seconds.

So, let’s configure the ThreadGroup for the Basic tier.

Under Thread properties:

Number of Threads (Users): This property defines how many threads/users can be used to execute this test, so for our current scenario I have kept it as 1.

Ramp-up period(seconds): This is the time taken by JMeter to start all the threads. Keep it as 0.

Loop-count: This count specifies the number of times you want to execute the test; for our scenario, since we have a limit of two requests per 30 seconds, let's keep this value at three.

Configuring User Thread properties

Configuring User Thread properties

Now that our Thread configuration is complete, let's define the HTTP endpoint that we want to hit.

To define the HTTP endpoint, we have to create an HTTP request under our ThreadGroup that we created in the previous step.

Defining HTTP endpoint

Defining HTTP endpoint

Once our HTTP request is created, we configure it as shown below: 

        Protocol: HTTP. 

        ServerName or IP: demo-proxy.us-e2.cloudhub.io (which is our proxy applications URL).

        Method: Get.

        Path: /rate-limiting (our API’s endpoint).

HTTP request

HTTP request

To use an SLA-based policy, we need to provide a client_id and client_secret, which goes into the header of an HTTP call. We can do this in the HTTP header manager.

Adding SLA-based policy

Adding SLA-based policy

Lets now add a client_id and client_secret in the header, as shown below:

adding client id and secret><figcaption style=Adding client Id and secret

All the configuration has been done for us to run the tests now, but we want to see the result of executions for which we want to create listeners.

There are various different types of listeners provided by JMeter, which make the analysis of your test executions simple.

For our case, let's create a Results Tree, as shown below.

Creating a Results Tree

Creating a Results Tree

This will create an empty template, as shown below:

Creating empty template

Creating an empty template

Now, we are ready for execution. We need to click on the green-colored arrow button for execution.

Executing task

Executing task

Let's execute it now:

Executing request

Executing request

After executing, we can see that the test has run three times (left box), out of which the first and second were successful (in green). The third one failed (in red) due to this error: “HTTP/1.1 429 Too Many Requests”.

The third test failed, since in the Basic SLA tier, we have configured that a total of two requests are allowed over a period of 30 seconds. After this, all the requests will be rejected.

Testing Advance SLA tier

Let’s do the same testing for the Advance SLA tier.

The previously defined Advanced SLA tier now has the following config :

      No of requests: 100.

      Time period: 30.

      Time unit: seconds.

So, let’s configure the ThreadGroup for the Basic tier.

Under Thread properties:

     Number of Threads (Users): 3.

     Ramp-up period(seconds):  0.

     Loop-count: 101.

Basic tier configuration
Basic tier configuration

The only other thing we need to run this test plan is to change client_id  and client_secret in the HTTP header Manager, which we created from the Advance SLA tier.

Creating Client Id and secret

Creating Client Id and secret

Let's run now run it.

Executing from Basic tier

Executing from Basic tier

As you can see, after 100 requests, our calls failed due to the following error: “HTTP/1.1 429 Too Many Requests

Conclusion

SLA-based Rate Limiting restricts the number of requests by users to your API, based on the configuration of an SLA tier, which in turn helps us in preventing attacks, such as DDoS.


Further Reading

Topics:
mule ,mulesoft 4 ,mule api ,rate limiting ,ddos attack ,jmeter ,mule runtime ,performance testing

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}