Requirements
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.
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 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:
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
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.phpRun 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> 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: 163If 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.
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.