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 AppExpert → Rate Limiting → Selectors and click Add.
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 AppExpert → Rate Limiting → Limit Identifier and click 
- 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:
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.
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.
[wpedon id=”798″ align=”center”]
