SafeLine WAF Waiting Room: The Terminator of HTTP Flood DDoS Attack

This article is written by a loyal user of SafeLine WAF, Nishuo666.

First of all, this is definitely not a paid article. Although their staff offered me a half-month pro license, this review was proposed by myself, and I will still evaluate SafeLine fairly and objectively.

As a loyal user of SafeLine for over a year, I am honored to be invited by the SafeLine team to experience the new version 7.2.3.

SafeLine Website: https://waf.chaitin.com/
Release Notes: https://docs.waf.chaitin.com/en/reference/release-note

From the release notes, the "CC Protection" and "Bot Protection" features have updates. One interesting feature is the "Waiting Room". Here is the official description:
Enabling the waiting room can effectively smooth out peak loads when the number of simultaneous visits to the website is too high.

It seems to be a rate-limiting and anti-HTTP Flood DDoS attack / CC attack feature, and here is an official demo picture:

HTTP Flood DDoS Attack and Traditional Protection Methods

First, a HTTP flood DDoS attack or CC attack (Challenge Collapsar) is a common type of DDoS attack. Traditional DDoS attacks usually aim to consume server bandwidth by sending a large number of network packets to clog the server's network outlet, preventing normal users from accessing the server.

HTTP flood DDoS attacks differ from traditional DDoS attacks as they mainly operate at the HTTP layer. Attackers simulate multiple legitimate users continuously requesting the website, causing the server's CPU, memory, and other resources to be heavily consumed, preventing normal users from accessing the server.

Website administrators must be familiar with HTTP flood DDoS attacks, which are very common and difficult to defend against on the internet.

The most common way to defend against HTTP flood DDoS attacks is to limit the frequency of visits from the source IP. If an IP sends a large number of HTTP requests in a short time, all subsequent visits from that IP are blocked. This method is effective against HTTP flood attacks but has many drawbacks, such as:

• A single IP could be a large gateway, commonly used by an entire company or school, making high access frequency normal for that IP.
• Attackers might use a large amount of proxy IPs to reduce the access frequency of each individual IP.
• Some events might cause sudden business peaks. During these peaks, high traffic might come from legitimate users, not attackers.

Therefore, simple frequency limitations are insufficient against HTTP flood attacks. Skilled attackers will find ways to bypass detection, and normal users might be mistakenly blocked.

In fact, every application has a relatively clear upper limit on the amount of business it can handle, such as:

• University Course Selection System: It can handle 1,000 students selecting courses simultaneously, but 2,000 students trying to register at the same time will crash the server.
• Ticket Booking System: It can handle 1,000 users booking tickets simultaneously, but 2,000 users at once will crash the server.
• Forum: It can handle 200 users discussing simultaneously, but 1,000 users commenting on hot news will crash the server.

In such cases, the best solution is to limit user traffic, similar to waiting for a table at a crowded restaurant.

image source: Unlikely_Turnip836

SafeLine WAF Waiting Room

The SafeLine Waiting Room is designed to handle high traffic peaks that might overwhelm a website server.

The SafeLine WAF does not enable the waiting room by default. To enable it, simply click the "HTTP Flood" button on the interface and configure the waiting room parameters.

As shown in the above picture, SafeLine WAF waiting room has two configurable parameters:

• Maximum of Concurrent Users Allowed: This indicates the maximum number of users the website can accommodate simultaneously. Beyond this number, users will start to wait.
• Active Session Timeout: If a user in the waiting room is inactive for a certain period, they will be kicked out and need to queue in line again.

Fill in the configuration according to your business needs. The demonstration site configuration is "1". Let's test it:

1. Open the website with a browser, successfully enter the site, and refresh multiple times with no changes, indicating I am the only user currently, which is great.
2. Open the site with another browser, and SafeLine prompts me to queue.
3. Open the site with a mobile browser, and SafeLine indicates two users are in the queue.
4. Close the first two browsers and wait a few seconds, then the mobile browser successfully enters the site after reaching the front of the queue.

The process is very smooth, and the rate-limiting effect is excellent. A quick look at the front-end code reveals that SafeLine uses WebSocket to implement the queuing logic. The server notifies the browser of changes in queue numbers automatically, ensuring both performance and security.

The feature is very user-friendly.

Finally, for those interested in WAF technology, feel free to join SafeLine Discord community (https://discord.gg/dy3JT7dkmY) and discuss with us.