Preventing Denial of Service

Back in the day when I first began setting up labs on the internet, in the DMZ, outside of the firewall, I was warned. I threw caution to the wind and continued forward with my work. About a year later my methods had changed due to all of my experiences and all that I had witnessed. Some of the threats have changed, but many are the same. We live safely behind our firewalls, until an accident happens. I got to witness many dangerous attempts to bring down my company’s infrastructure, among other things. I think the most interesting event happened when we were able to trace an attack against a University in the USA originating from somewhere deep in China. We live in a dangerous world.

I remember reading about Denial of Service attacks, and later the Ditributed Denial of Service attacks, early in my career and thought they were the toys of script kiddies (kids who write scripts for fun and jokes). If you believe this, put some hosts out in your DMZ or outside the firewall with some open ports and time how long it takes to get slammed. I kid you not, there are people/organizations out there, port scanning 24/7/365 looking for vulnerable sites to destroy, using the simplest of methods. Protection against DOS and DDOS is fundamental and can be implemented with the Citrix NetScaler.

The technology for DOS and DDOS prevention has existed for some time now, but the attacks have become more sophisticated, which is why you really need the Next Generation Firewall offered by the NetScaler. The Citrix Next Gen Firewall not only protect you at Layer 3/4, but also at Layer 7 – the Application Layer.

How Layer 7 Denial of Service Protection Works

Internet hackers can bring down a site by sending a surge of GET requests or other HTTP-level requests. Layer 7 Denial of Service Protection provides an effective way to prevent such attacks from being relayed to the server. This feature also ensures that a Citrix NetScaler System located between the internet and the servers is not brought down by the attack while protecting the servers.

Most attackers on the Internet use applications that discard responses to reduce computation costs, and minimize their size to avoid detection. The attackers focus on speed, devising ways to send attack packets, establish connections or send HTTP requests as rapidly as possible.

A typical approach to prevent these attacks is effective in most cases. However, for more complicated attack methodologies including the use of real HTTP clients as attacking tool, the simpler prevention approaches can fail to protect the servers.

Real HTTP clients such as Internet Explorer, Firefox, or NetScape browsers can understand HTML Refresh meta tags, Java scripts, and cookies. In standard HTTP the clients have most of these features enabled. However, the dummy clients used in DoS attacks cannot parse the response from the server. If the malicious clients attempt to parse and send requests intelligently, it becomes difficult for them to launch the attack aggressively.

When the Citrix NetScaler System detects an attack, it responds to 0% to 100% of incoming requests based on the value of the Client Detect Rate parameter with a Java or HTML script containing a simple refresh and cookie. Real clients can parse the request and return the request with the cookie. Spurious clients drop the response, and are therefore dropped by the system. When a POST request is received, it is first checked for a valid cookie. If the request has a valid cookie, the request goes through, but, if the request does not have a valid cookie, the system sends a Javascript to the client asking it to resend the information with a new cookie. If the client sends a new cookie, this cookie becomes invalid after four minutes, and every response to the client is sent with the new cookie. The cookie in a POST request can become invalid in the following conditions:

  • If the POST request is made when the system is under attack, and the preceding GET request is made when the system is not under attack.
  • When the think time of the client exceeds four minutes.

Priority Queuing/Surge Protection

Under an attack, requests without proper cookies are queued by the system, this protects the servers from false clients.

Memory/Performance Implications

There is minimal effect on throughput, since the JavaScript is sent to the client at a very slow rate (default: 1% of the server’s HTTP response rate). This rate can be changed by tuning the -Client Detect Rate parameter of the HTTP DoS protection policy. The latency of the requests is increased, because the client must re-issue the request after the JavaScript is returned. This takes time, since the requests are also queued.




Get the most powerful DOS protection here.




It’s powerful!