“Even the best IPS technology is only marginally effective against DDoS attacks, and it is often possible for those waging the attack to consume all available bandwidth into your network. Whether the attacker swamps your server or your Internet pipe, the effect is the same: Users are unable to access resources on your network.”
Distributed Denial of Service attacks are arising even though the world is ample of security tools. There is not any particular software service available to make a true DDoS attack to a particular host. That is where “AtckNow” comes in.
“AtckNow” is a distributed DoS system for the use of Network Security Testers who need an effective system to check out how fail proof the protected system is. This could be used as a commercial product as there is growing demands for the network security. This system will only send packets to a target host despite of the target host accept the packets or not. Thus, this system is not capable of measuring the security of the target host. The system administrator/Network Security officer should be able to measure how much of packets the target host could bear.
“…discovery of a large botnet made up of over 100,000 Android devices located in more than 100 countries. The investigation was launched in response to large DDoS attacks that have hit several content providers and content delivery networks over the past few weeks.”
This system comprises of two servers (Main and Control) and many clients (including Android devices). The clients are acting as bots where they get controlled by the Main Server to use them as packet senders for the target host. The server will remotely ask the bots to send packets to a particular host. Where the Control Server gets to know how many packets each host has sent and what is the sum (this could be used to earn the revenue).
Using Java as the language to build up the applications where the LipeRMI has been used as the Middleware. The reason to choose LipeRMI is because of the Android platform compatibility. That is why LipeRMI is more suitable for the scenario (Java RMI is not compatible with the Android).
To make the system, NetBeans IDE has been used as it is provided by Oracle Inc. (Because of the Native Java Language Compatibility). Android Studio has been used to build the Mobile Application.
Windows, Linux, MacOS and Android devices act as bots where they listen to the Main and Control Server periodically only if it needs. This has been achieved by using timer tasks where it will run on demand but steadily until it covers its target. There are two servers has been developed since when the bot count becomes very high (In Practical, it will happen.), one server may get crashed or performance problems will occur in the long run. Thus, additionally added a control server (Apart from the main server) where the control server will do the calculations parts needed (Such as calculating the Bot count and organise them to calculate the rewards etc.). Whenever a bot has been connected to the Main Server, it will trigger the functions of the Control server where it sends the IP address, Hostname and Number of Gets per second to calculate and transfer the information needed by the Main Server. Ultimately, the main server owner could display the summarised result at the end.
The Main Server Application GUI where the user will see the summarised content within the UI. First, user has to click on start connection where he/she will start the Main Server. Then in the server status text box, the updates will display (such as a new bot connected, connection initialisation details etc.). In the DDoS URL text field, the host URL should be typed. And then the user will click on the “Set DDOS URL” button. Soon after 10 seconds, the bots will reply their get counts per 10 seconds (In here, the bots will get the DDOS URL and send HTTP GET requests until the 10 second timer ends. After that, it will pass the count to the control server where the control server will make an array of bots and transfer data to the Main Server. That is where the user will get to know the GET count of available bots).
After that, the user has to type the number of DDoS attacks will be sent to the target host in the text field located left to the “Start DDOS Attack” button. Then, the user should click on the “Start DDOS Attack” button which sends the get count to the bots. The available bots will get triggered and then bots will look for the number of GET counts to be done from themselves. From the control server, the bots will get the amount of GETs calculated based on the Main Server proposed bot count with the Bots GET count per 10 seconds. Hence, it will get distributed. And then onwards, the bots will execute the GET requests to the target server at once. This is where the attack happens. As soon as they have completed the execution of GETS. They will report the GET count they have done upon a successful completion. The control server gets this data and then calculate the reward to be payed to the bot and send the summarised data to the Main Server. Then the user should pay them accordingly.
The Control Server and Desktop Bots running as a service where there is no GUI involved (In Practical, the bots will work in the background). The logs can be live streamed through the output tab in NetBeans. It will show the application status.
When it comes to the Mobile Application, it will perform as a bot where it has no difference from the desktop bot application when it comes to the functionality. It can be installed in any Android Device which has Network connectivity. It connects to the Main Server and Control server where necessary.
At first, it was hard to make use of a compatible API since there are many alternatives to choose from one over the other. “LipeRMI” has been used as the middleware as it is a ground up solution for the JavaRMI. It has addressed the issues of Java RMI where it fails to call-back if the receiver is placed inside a NAT/Local Network or a Firewall. JavaRMI gives unnecessary network configurations from the user’s aspect. This is hard to do for an end-user application as It involves changing the firewall/network rules according to the application developed.
Apart from that, LipeRMI can be run on many environments which follows the internet communication via sockets. Hence, it could be used inside Android platform where Java RMI could not. This makes the application universal. Thus, it is very flexible to use LipeRMI in the Android application as the desktop application has the same architecture. For a DDoS system like this, it is quite flexible for the developer to make a common interface and call the Main Server functions directly from the use of the interface. That is where Spring architecture falls behind LipeRMI.
At first, choosing a middleware was a difficult task as there are many alternatives and most of them were not suitable even if they are widely accepted and used in common environments. E.g. Spring Framework (We could not call the remote methods easily as it involves Json parsing and text manipulation which becomes redundant as we write the program). As it is better to have a mobile application in the distributed system, researched about the architecture of many distributed systems. It was impossible to use JavaRMI in the Android platform as it is not compatible with the Android environment. Then thought of using JavaRMI between Bots (Desktop Application) and the Main/Control Server Application while using Spring to communicate between the Mobile Application and the Main/Control Server. It is not a better solution for a system like this when comes to the system architecture. It could be defined as using unnecessary technologies to achieve a common task. LipeRMI eliminates this issue.
However, apart from its advantages, the main burden to develop the application from there is to learn to use LipeRMI as it is quite different from JavaRMI (However, its implementation logic is similar to JavaRMI; but not the code.). There are no extensive guides to practice the LipeRMI. At last, by practicing more through self-studying addressed that issue. While developing the application, many exceptions have been thrown (When the bot not responds to the server or the server went offline etc.). These errors have been fixed. However, it consumed much more time than it used to be as it involves running through many platforms to test the code (including Linux, Windows, MacOS and Android). Sometimes, the timer tasks used in the main server congested with control server tasks. Which lead to memory leaks. Thus, it was quite complex to handle that extensively. In order to resolve, the timers were assigned to run in distinct times. Nevertheless, it was quite complex to look at the code itself as the components were connected together; not limited to local application; but extended till the bots (which are running in different environments). Apart from the software developing, network address incompatibilities were also happened (such as IP address changes and conflicts). To resolve such, generating unique port number for each server has been worked.
Performing a DDoS attack to a target host is a difficult task as it involves thousands of bots connected to a server. And it is same with the DDOS testing programs. That is where “AtckNow” comes in. It Performs and Handles the complicated and complex DDoS attacks as in real world without having the constraints based on platform. Consisting of Main Server, Control Server, Desktop Bot and Mobile Bot Applications which are designed as real-world applications to perform the same action within seconds. It has a good business model where it could be used to check whether the system (Website or other endpoint) is immune to DDOS attacks.