Using the NetScaler Appliance to Block HashDoS Attacks

Requirements

• Administrator access to a NetScaler appliance
• A test computer to launch the HashDoS POC, preferably a Linux computer
• Web-Server

Using the NetScaler Appliance to Block HashDoS Attacks

Most of the solutions suggested for HashDoS attack are to limit the number of fields that can be submitted. http://blogs.technet.com/b/srd/archive/2011/12/29/asp-net-security-update-is-live.aspx
This includes the Snort rule that works in detecting the attack.

Responder Policy

In this method a combination of AppExpert named expressions and a responder policy is used to prevent the HashDoS attack. To prevent the HashDoS attack, you can limit the request length on Apache or IIS and use the following expression to block all posts bigger than 10000 bytes with the responder policy having an action of DROP or RESET:
http.REQ.METHOD.EQ("POST") && http.REQ.CONTENT_LENGTH.GT(10000)

You can remove the POST request but it is more likely that a POST request is bigger than a GET request. Limiting the expression to POST request reduces the performance load on the NetScaler appliance as it automatically ignores GET requests.

Add this expression to a responder policy with a RESET or DROP action and bind the policy at a global level or to the appropriate virtual servers.

Run the following commands to add the responder policy and bind the policy:

add policy expression expr_hashdos_prevention "http.REQ.METHOD.EQ(\"POST\") && http.REQ.CONTENT_LENGTH.GT(1000)"
add responder policy pol_resp_hashdos_prevention expr_hashdos_prevention DROP NOOP
bind responder global pol_resp_hashdos_prevention 70 END -type REQ_OVERRIDE

Application Firewall

Application Firewall monitors the length of POST parameters and also limits the number of parameters sent in the HTTP request.

With the Application Firewall feature of the NetScaler appliance you can use URL closure to block the basic attacks though more advanced attacks can get through. Additionally, with field consistency protection, you can allow only field names that were sent out with the form. This prevents any crafted field names that cause collisions.

Application Firewall protects the infrastructure from a Web application perspective. In NetScaler software release 9.3, a negative model is introduced with signatures from Sourcefire (Snort) and increased the protection against known attacks.

The Application Firewall can be bound on a single virtual server or at a global level. Refer to the following links for more details:

• Application Firewall: http://blogs.citrix.com/tag/appfw/

Logging

It is useful to record the information and verify if valid network traffic is blocked.

Run the following commands to collect the syslog from the NetScaler appliance:

add audit syslogPolicy remote_syslog_log ns_true remote_syslog0 -acl ENABLED -userDefinedAuditlog YES
bind system global remote_syslog_log –priority 100

In the preceding command remote_remote_syslog0 is the configured syslog server. The -acl ENABLED -userDefinedAuditlog YES parameter is required so that the events are recorded when the rule hits.

Run the following command to enable logging by using syslog and newnslog:

add audit messageaction auditlog_hashdos_responder ALERT "\"Possible Hashdos attack - A large POST Request from \"+CLIENT.IP.SRC+\" was requested \"+HTTP.REQ.URL.HTTP_URL_SAFE+\" , and used this browser: \"+HTTP.REQ.HEADER(\"User-Agent\").HTTP_HEADER_SAFE" -logtoNewnslog YES

Run the following command to view the newnslog entry:

# nsconmsg -K /var/nslog/newnslog -d logfromnfw

Testing

To test this issue, create the file named doom. You can use this file to send POST requests to a PHP.

1. Run the following command to check the details about the file doom:
   $ file doom
   test/testdata.txt: ASCII text, with very long lines, with CRLF line terminators
   $ more doom
   EzEzEzEzEzEzEz=&EzEzEzEzEzEzFY=&EzEzEzEzEzEzG8=&EzEzEzEzEzEzH%17=&EzEzEzEzEzEzD%9B
   =&EzEzEzEzEzFYEz=&EzEzEzEzEzFYFY=&EzEzEzEzEzFYG8=&EzEzEzEzEzFYH%17=&EzEzEzEzEzFYD%9B=
   &EzEzEzEzEzG8Ez=&EzEzEzEzEzG8FY=&EzEzEzEzEzG8G8=&EzEzEzEzEzG8H%17=&EzE
   zEzEzEzG8D%9B=&EzEzEzEz
   ………………..
   ………………..
   ………………..
   
   Note: This file is a URL-encoded file.

2. Run the following commands when the NetScaler appliance is configured to block the HashDoS attack:

   time curl --data @doom http://x.x.x.x/test.php
   curl: (56) Failure when receiving data from the peer       => indicating that the responder policy is working!
   
   real    0m0.018s
   user    0m0.016s
   sys     0m0.000s

3. Run the following commands when the NetScaler appliance is not configured to block the HashDoS attack:

   time curl --data @doom http://x.x.x.x/test.php
   real    1m9.571s
   user    0m0.008s
   sys     0m0.012s
   The following screen shot shows the variation in the performance of the CPU and Apache:

   

   
   
   
   

You can bind the responder policies at a global level to protect the backend servers. However, most of the network traffic can pass through the NetScaler appliance resulting in many undefined hits.

> show responder policy pol_resp_hashdos_prevention
        Name: pol_resp_hashdos_prevention
        Rule: expr_hashdos_prevention
        Responder Action: NOOP
        UndefAction: NOOP
        Hits: 2
        Undef Hits: 163
 

If you bind the responder policy at the global level, then the number of undefined hits increases. This is because it logs everything on port 80 destined for the NetScaler appliance or a virtual server on the appliance. The undefined hits could be a POST with a missing content length header or a TCP connection on port 80. You can have an undefined action of NOOP to protect valid network traffic.

Caveat

This article is only intended as a helpful prevention technique when the customer patches the development framework on the Web application. The customer must ensure that they set the correct Content Length size so that valid network traffic is not affected and bind the policy to the required virtual servers.