DoS attacks have been around for over a decade now and most of the networking gears have inherent protection against such attacks. Then what happened with Slow-header attack? Aren’t this same kind of DoS attacks? Why the sites did come down and inherent protection failed to stop these?? Unfortunately the answer is NO, these new attacks were not the same kind of attacks we saw many years ago. These new attacks are much more sophisticated and oriented from positivity of the server or application behavior. Let us understand these in details.
For a web application waiting to accept all the request headers before processing the request is the right thing to do, isn’t it? Headers contain important information which is used while processing thus application waits to capture complete request before processing. Attackers took advantage of this behavior and created stream of requests which keeps sending incomplete headers and request is never complete. Thus server connections and memory resources are tied up with those incomplete requests.
The Slow Header attack works by exploiting the Client idle timeout value on the server side. This timeout is configured on server side to drop a client connection if a client was found idle during the time interval. The Slow header attack finds the approximate timeout value set in Server side and then chooses a value which is lower than the configured value. The attack then initiates a Http Request with Partial header to the server. It keeps sending one header based on the chosen value and this way Client idle timeout will not be triggered on the server side and Request will not be complete.
The below packet trace explains how the attack works?
Here packet number 40 points out an Http request going from an attacker machine to NetScaler VIP. We can see that the Http Request is not complete and it is partial. In packet 526, http header (X-a:b..) is sent in same connection. After 20 seconds, the same header is sent in same connection to keep the connection alive.
In NetScaler, the “Show connectiontable” command lists out all connections and “stat lb vserver <vservername>” gives the currently established client connections. The below screenshot was taken during 10 such attack connections in order to give full output here.
The protection against this attack is to have ability to track these zombie connections and drop them so that it won’t disrupt the normal flow of traffic.
NetScaler has inbuilt protection against these attacks. Slow header protection is enabled by default. The Zombie connections which send partial headers after the client idle timeout will be flushed silently. Netscaler has intelligence built in to it to study the flow of traffic, identify the Slow header connections and drop them at expiry of timer. All these can be tracked with the support of counters provided by Netscaler like http_err_IncompleteRequests, http_err_IncompleteHeader and http_tot_zombie_incompq_timeout.
Once the connections are cleaned up, we can check through “Show connectiontable” command that the connections are cleaned up. We can also check the current client connections through “stat lb vserver <vservername>” as shown below,
NetScaler acts as good defence to protect the back end servers against this attack and only Customers need to set their timeout values to appropriate one which suits their application traffic.The client idle timeout value can be set using the following command,
> set lb vserver <vservername> -cltTimeout <timeout in seconds>
The other thing to be noted here is all these protections works without disrupting the normal Application traffic.