Experiment #3 (Service Denied)

One of the most fascinating things about the realm of Cyber Security is how despite attackers deploying increasingly sophisticated kinds of attacks, the solution(s) will always be anchored to the fundamentals. Reading the statistics and news would easily get any Internet user on their toes but did you know that the answer to these terrors is simpler than we make it seem? This experiment is based on the recent DDoS Attack on various systems in Kenya and it seeks to test the effect(s) and remedies to a DDoS Attack on an Android application.

BACKGROUND

If you have been around the block recently, you might have come across the incident that turned almost every Techie (even Non-Techies) into a Cyber Security Expert/Consultant/Guru. Heck, this tweet summarises it all:

Shout-out to Dr. Bright :)

If you haven’t then it’s simple: An entity named Anonymous Sudan deployed a DDoS Attack on various platforms in Kenya, such as the eCitizen platform which is responsible for most if not all government-related services. While this experiment is not focused on the incident itself, it will simulate a similar scenario to capture the effects and solutions to preventing such an occurrence. In the grand scheme of things, DDoS Attacks are probably one of the easiest Cyber Attacks to prevent but are also the easiest to ruin a system’s existence as they can be very tricky to handle once they happen. You know the saying: Prevention is better than cure, so this experiment will simulate a DDoS attack on an Android application that consumes a REST API to act as the remedy.

CONCEPTUAL DIAGRAM (With Reverse Proxy)

With Reverse Proxy…

CONCEPTUAL DIAGRAM (Without Reverse Proxy)

Without Reverse Proxy…

OBJECTIVES

1. To set up an Android application that consumes a REST API…
2. To set up and simulate a Reverse Proxy Server and Load Tester…
3. To simulate a DDoS Attack, gather findings through Monitoring and Analytics, and draw conclusions based on them…

TOOLS, TECHNOLOGIES & LIBRARIES

1. Android Application -> To consume a REST API and act as the client…
2. Physical Android Device -> To run the Android application…
3. Laptop -> To generate Network Traffic and simulate a DDoS Attack (Apache JMeter), as well as act as the Reverse Proxy Server (Nginx)…
4. PCAPDroid -> To perform Network Traffic Monitoring and gather Analytics…
5. Coffee, Music, etc -> No reason, just do it :)

PROCEDURE

STEP 1: LET’S GET TO WORK…

In case you have not yet noticed, most of my experiments will require you to build the required applications based on your personal preferences. That is because how you build them does not really matter. What matters is that you build an Android application that consumes a REST API. This experiment uses the JSON Placeholder Free Fake REST API as it has several end-points that you could use for free: https://jsonplaceholder.typicode.com/

Also, remember Experiment #1? Remember how you were warned against using HTTP instead of HTTPS? Don’t use HTTP kind of REST APIs. Please. For the love of Technological Literacy :)

STEP 2: PROXY, BUT IN REVERSE…

Now, we set up a Reverse Proxy. Why a Reverse Proxy, Emmanuel? That’s a very good question! For a DDoS Attack to be successful, one of the requirements should be an excessive flow of Network Traffic to the target device (servers, usually) without some kind of Load Balancing mechanism. By using an effective Load Balancing system such as a Reverse Proxy, the chances of a DDoS Attack affecting your platform are very minimal, in my opinion. There are highly sophisticated and optimized providers that offer such solutions at a large scale such as Cloudflare (as we will come to see later) but for the sake of simplicity, this experiment will use Nginx to set up a local Reverse Proxy. Here is the documentation that should guide you on how to set it up depending on your OS: https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/

You can also use Chat-GPT to give you a detailed walk-through of how you would set up Nginx on your local machine.

After setting up a Reverse Proxy as per your preference(s), download and install Apache JMeter. This application is crucial for the next step.

Once you have correctly set up Nginx, you can proceed to the next step:

STEP 3: MAINTAINING THE BALANCE

Similar to Step 1 (all steps actually), this one will require you to set up Apache JMeter based on your desired configurations. However, you should generally set up a new Test Plan, create a new Thread group and specify the number of virtual threads to simulate concurrent users making network requests to your REST API, create a new HTTP(S) Sampler, and customise it based on your Reverse Proxy settings.

Once everything is done, run PCAPDRoid and only capture your Android application’s traffic by selecting it on the list of apps available on your device. Run the Apache JMeter application to simulate an influx of Network Traffic as well as your Android application. Record your analytics on PCAPDroid, including the latency of the application.

Now set up a new Test Plan on Apache JMeter but this time instead of using the IP Address of your Reverse Proxy, use your actual Android device to simulate it as the REST API server since using the actual server’s IP is unethical and illegal. Run the Apache JMeter application after starting a new capture on PCAPDroid and launch the application once Apache JMeter has kicked off. Record your findings.

RESULTS & FINDINGS

Here is the capture when a Reverse Proxy is involved:

Here is the output when no Reverse Proxy or Load Balancing mechanism is involved:

OBSERVATIONS

1. When no Load Balancing mechanism is engaged, the Android application records degraded performance when performing the HTTPS Requests.
2. The delay caused by a lack of Load Balancing is up to 3 times more than that observed when Load Balancing is set up.
3. When no Load Balancing mechanism is set up, the Android application intermittently throws an I/O Exception (switches to the Error Screen if this has been set up using the Sealed Interface of Loading, Success, and Error states) indicating difficulty in connecting to the REST API Server, as would have been observed ina real-life DDoS Attack.

VERDICT

This experiment has set up two scenarios to demonstrate the impact of implementing Load Balancing on the performance and User Experience of an Android application. When engaged, Load Balancing ensures optimum app performance with respect to the servers involved while the opposite results in an undesirable and reduced performance of up to 3 times delay in latency.

RECOMMENDATIONS

1. Use of reliable and trusted Cloud Security providers such as Cloudflare and Nginx to implement fault tolerance at a larger scale to ensure continuous availability of your application (If it is a commercial application with a substantial user count)…
2. Ensuring that your application follows the principles of Clean Architecture to allow seamless scalability and optimize the app’s efficiency regardless of any surge in Network Traffic (Assuming the server side has followed the same principle of Fault Tolerance)…
3. Making use of CDNs, Offline-First, and/or Serverless architectures that prioritize data availability, for example through periodic synchronization to enable the availability of fresh data despite faulty network bandwidth or congestion…

REFERENCES

Building a scalable, modularized, testable app from scratch. (n.d.). Www.youtube.com. Retrieved July 29, 2023, from https://www.youtube.com/watch?v=qX6zmKY4KP0

Apache JMeter — User’s Manual: Getting Started. (2017). Apache.org. https://jmeter.apache.org/usermanual/get-started.html

‌NGINX Docs | NGINX Reverse Proxy. (2019). NGINX Documentation. https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/