DDoS attacks commonly occur at layers 3 (network), 4 (transport), 6 (representation), and 7 (application) of OSI layer 7.

Cloud service providers guarantee response to layer 3 and 4 attacks, which occur in the infrastructure section, but attacks that occur at layer 7 require code modifications and configuration changes.

Application layer attacks allow attackers to overload specific functions in an application, making the application unusable or preventing legitimate users from responding. Attacks are sometimes difficult to detect because only a small amount of network traffic is possible. Let's take a look at RUDY attacks, which are representative DDoS techniques of HTTP-based 7-layer attacks!

1. Definition of a RUDY attack

Ru-dead-yet due to Slow HTTP POST DoS attack? It is an abbreviation of It is an attack technique that utilizes vulnerabilities when the developer's security settings are wrong or the application, framework, etc. are not up to date. DDoS attacks are disruptive attacks that infringe on a server's availability by sending large amounts of traffic, while slow attack techniques infringe on availability with low traffic.

It is an attack that uses state information that does not maintain one of the characteristics of HTTP, and delays it in order to force it to continue. It is said that an abnormally large amount of data is sent using the POST method, and small data is slowly transmitted little by little.

Use the HTTP POST method to manipulate the Content-Length value of the header into a very large value and send the data in very small pieces. The server looks at the Content-Length value in the client's HTTP header and maintains the Connetion until the content is of that length. Substantial content is sent one character at a time interval. Eventually, the server will experience a delay of as much as Contetn-Length X Interval Seconds per session. This is a method of using KeepAlive's vulnerability to seize connections by sending abnormally sized data in small pieces.

2. RUDY attack confirmed

Slow, low attacks can be difficult to mitigate because they are carried out much more carefully than traditional denial-of-service attacks. Also, as long as the server side does not disconnect with KeepAliveTimeout, the actual request is made normally, so no error log is left.

Here's how to check for tricky RUDY attacks via Watap.

1. Select transactions with long response times from the heatmap on the application dashboard. Since the Y axis of the heatmap indicates response time, a transaction with a long response time is likely to be a request whose target has not been interrupted for a long time.

2. If the HTTP method is POST, check the HTTP header value for the transaction with the highest call time by sorting the HTTP call time in descending order.

3. Check the Content-Length length of the HTTP header. A POST call with an abnormally long Content-Length length and a long response time can be recognized as an attack.

3. Attack prevention

You can prevent this attack by setting a session threshold or setting an appropriate timeout.

1. Set the threshold value Content-Length and the actual incoming packet size as threshold values to block. When a POST packet larger than the size set by Content-Length is received, it is set to block if n or more packets below the specified size are checked during a specified period of time. Also, set a threshold for the number of connections that can be connected simultaneously from the same origin IP.

2. Timeout settings

- Set a connection timeout
The connection is terminated by setting a timeout for how long the session lasts without sending or receiving any data between the client and the web server. However, proper user connections with slow Internet connections may cause the server to deny service.

- Set a read timeout
Set to respond to an error if all of the request body information is not received for a period of time.

With Watap, it is possible to determine DDoS that may occur at layer 7 and establish a basis for action.