A simple DOS-Protection

I use this kind of restrictions quite often in combination with pages like logon pages to keep people from doing brut force password attacks or pages that cause stress to the server to keep people from overloading the webserver.

Rate Limiting

My DOS protection is based on the rate limiting feature. This feature, together with it’s twin sister, action analytics, help bringing dynamics into our Citrix ADC / NetScaler configuration.

The feature consists of 2 parts: The Selector and the Limit Identifyer. Selectors are shared with action analytics.

  • Rate Limiting is a DOS protection feature.
  • Action Analytics helps us to satisfy customer requests like “cache the 50 most frequently used webpages”.

The selector

The selector selects the kind of request we are interested in. In our case, it is the number of URLs accessed from a certain IP. Our selector should create a table like that:

 

IP URL Hits
93.83.148.34 /owa/logon/logon.aspx 4
192.168.229.1 /owa/logon/logon.aspx 1
92.168.229.1 /owa/ 92

So it’s a simple list, containing IP addresses (CLIENT.IP.SRC) and URLs (HTTP.REQ.URL)

Navigate to AppExpertRate LimitingSelectors and click Add.

NetScaler: Add a stream selector for rate limiting / DOS protection

Add up to 5 expressions into your selector by clicking add.

The Limit Identifier

The limit identifier defines, how much is “too much”. In our case, more than 3 requests in 10 seconds.

Navigate to AppExpertRate LimitingLimit Identifier and click NetScaler: Add a Limit Identifier for rate limiting / DOS protection

  • Selector: The stream selector created before
  • Mode: Bursty (a total of 3 requests in 10 seconds allowed) or smooth (requests have to be distributed evenly within the given time-frame)
  • Threshold: The maximum number of requests allowed (in our case 3)
  • Time slice: The time frame for these requests (in our case 3 requests in 10 seconds = 10,000 milliseconds)
  • Maximum Bandwidth: A limit for bandwidth, 0 means unlimited; perfect in this case.
  • Traps: The maximum number of traps to send in a row. Silence after that. 0 means no traps at all.

The policy

Our policy will be a responder policy. The action will be the built-in drop action, so we can right start with the policy. Maybe the first guess would be a policy like this:

NetScaler: Rate limiting policy for DOS protection

This policy could get bound to our load-balancing vServer. Unfortunately, it would not permit more than 3 requests to any of these pages, not just to the blue one.

You could give it a try: It will work but block not just too many requests for the blue page, but for all other pages as well. So it is not specific enough.

NetScaler: Binding a Rate limiting policy for DOS protection

Depending on your browser you may see the fourth request taking rather long, but eventually loading.

This is because browsers usually continue sending requests. The first one of these automatic requests hitting the policy more than 10 seconds after your initial (successful) request, will be successful. The behaviour will change if you change the action from drop to reset. In this case, you will get immediate response from the Citrix ADC / NetScaler and the browser will show an error page.

The correct version:

You can see, we chained an HTTP.REQ.URL.EQ("/blue.htm") to the expression we did before. We use a boolean AND, so we restrict the blue page only.

&& is a boolean AND, || is a boolean OR, ! a NOT.

I put the policy expression selecting  the blue page in front, as this policy expression requires less CPU than looking up an URL in our potentially huge rate-limiting table. Because of this, the Citrix ADC / NetScaler will not have to search the rate-limiting table for a request to /home.htm.

We always do the less CPU intensive expressions in front and the more CPU intensive ones on last position to save CPU.





Leave a Comment

Your email address will not be published.