From Server Architecture to analyze the impact of Slow-Rate DDoS

On my recent article, I’ve shown you some of the tools being used by Hactivist group to attack Hong Kong sites. I’m sure most of you was surprised how effortless it is to run and generate DDoS attack.

Today, I will show you one more main weapon that has been introduced by the attacker called “Torshammer”.

Torshammer is one of the slow-rate DDoS attack tools. As claimed by Hacktivist group, this tool usually efficient and has great impact on most Apache server of any kind. Why apache?

Let’s start to analyze the impact of slow-rate DDoS attack on Apache Server by reviewing its server architecture.

By default, Apache is using thread-based server architectures that handle each incoming connection with a separate thread and dedicated activity.

Two common thread-based server architectures used by Apache Web server are as follows:

• Multi-process architecture with Multi Processing Module (MPM) Prefork
• Multi-threaded architecture with Multi Processing Module (MPM) Worker

1) MPM Prefork (Multi-Process Architecture):

This is a process-per-connection model. It dedicates a process for handing each connection. When using MPM prefork, the main server process forks several handler (child process) processes on start-up. Those handlers will listen for connection and every connection isolated from each other do not share memory.

The large memory footprint as a result of the connection-process mapping that leads to a concurrency/memory trade-off. Thus, it makes it harder to scale the maximum simultaneous connection.

2) MPM Worker (Multi-Threaded Architecture):

This model of apache can serve a large number of requests with less system resources than the prefork model because on this working model a limited number of processes will serve many numbers of requests. In other word, it is thread-per-connection model.

In this model, multiple threads share the same address space. E.g. shared cache for cacheable responses. Compared to multi-process architectures, a thread only consumes limited memory to handle a connection.

I/O Access inside multi-thread server architecture:

Multi-thread server architecture uses a simple I/O access - A synchronous and blocking I/O operation. Operation system overlaps multiple threads to handle concurrent connections where a reasonable amount of CPU-bound operations must be executed.

In most cases, the blocking I/O operation will trigger scheduling and causes the context switch to allow the next thread to continue.However, during heavy loading, every single thread stack for each connection consumes large amounts of memory and constant context switching will cause huge losses of CPU time. As a result, it will increase chance of CPU cache misses.

In most cases, people will reduce the number of threads to improve the performance of every thread that makes it harder to scale the maximum simultaneous connection.

So, what is slow-rate DDoS?


Slow-Rate DDoS Attack:

There are many different type of slow-rate DDoS attack but their main purpose is similar. It causes the web server application threads to await the end of boundless posts in order to process them. This causes the exhaustion of the web server resources and causes it to enter a denial-of-service state for any legitimate traffic.

The key of slow-rate DDoS is it generates large number of current connections and maintains it as long as possible.

Let us use Torshammer as example:

Torshammer executes a DoS attack by using a classic slow POST attack, where POST content is transmitted in slow rates under the same session (actual rates are randomly chosen within the limit of 0.1-3 seconds).

It will generate number of HTTP POST request and establish the connection to the server (source from Tor network or attacker’s computer). Every connection will hold around 1000 to 30000 second.

If apache can’t close the connection correctly, it will get a lot of current connection at same time and lot of child processes/thread will be spawned.

Inside of each of connection, it is just only sending some randomize characters to maintain the established connection. As the limit of thread-base server architectures, it can’t maintain too many current connections. When the attack hit the maximum of child process/thread that apache can open, it will no longer serve the legitimate traffic.

This tool does not need to generate huge attack bandwidth and high HTTP request per second. Just need to hold the maxim current connection that apache can handle between 1000 to 30000 second. It uses limited resources to terminate the apache server.

Attacker just need to use a Tor network from single computer and can automatically generate an effective DDoS attack.


Conclusion:

In conclusion, not only apache, but also most of thread-base server architectures are suffering from slow-rate DDoS attack. Today, DoS attack is against to the vulnerabilities that related to design of network infrastructure, devices, operation system, platform, services, protocol, etc.

Attacker will study your DDoS related vulnerabilities and select the effective one before attack.

E.g. Hactivist group classified targets by web servers on 14 Oct and attack on 18 Oct 2pm:

So, how to harden our system? Before we discuss the protection, we need to understand the nature of each DDoS attack. Let us go through one by one.

For more reading on server architectures: http://berb.github.io/diploma-thesis/original/042_serverarch.html

To be continuous…