It is really required today to have a mechanism to prevent brute force login attacks to Citrix Access Gateway or NetScaler AAA for Traffic Management Login pages. Like many other web applications that have a public facing HTML form used for login, this is an assumed risk. In this article I’ll show you how you can use the NetScaler HTTP Rate Limiting feature in conjunction with the Responder module to detect and respond to a potential brute force attack. So Let’s put up a scenario there we would like to limit the number of Active Directory Login attempts to 3 during a 60 seconds intervall of time and refer to an error page when it occurs.
This is what we need to do to accomplish this task:
1. Logon to your Netscaler appliance, Extend the AppExpert node, Rate Limiting and define two “selectors” (This tells us what to track or “select”)
- Click add, give the first selector a name Username Login Limiter and the following expression and hit Create
HTTP.REQ.COOKIE.VALUE(“AG_USER”)
Tips: Of course you can use any selector expression you like here, depends on what you are intending to track or “select”. So for example if you prefer to select both IP and URL since we want to track hits to the same URL from the same IP you could configure something like this:
add ns limitSelector Username Login Limiter CLIENT.IP.SRC HTTP.REQ.URL
- Click add again and create the second rate limiting selector by giving it a name AD Login Limiter and and the following expression:
HTTP.REQ.BODY(25000).REGEX_SELECT(re/(login=[^&]+)/)
2. Now it’s time to create a “Limit Identifier” and bind the first selector we already created to it:
The identifier indicates the pattern within the time slice that will trigger a hit. We choose the selector we defined above, and a mode of “REQUEST_RATE” as we want to know how many times the specific Cookie Value will be requested in the Time Slice. Since requests may not occur at a specific interval within the time slice, a BURSTY limit type is better to use than a SMOOTH one. We are not concerned about reducing bandwidth here since we want to block so that can be left to default of 0.
- Click Add and give the Limit identifier a name Let’s say AD_Login_Limiter, Chose the Username Login Limiter as a selector, REQUEST_RATE as mode, BURSTY as limit type, Threshold of value 3 and Time Slice of 60000 (msec) and hit OK!
3. Now we are going to create a responder action & a responder policy
- Create a new responder action by hitting Add, Give it a name AD Login Limiter, use the Redirect type and enter the target value (in this case let’s suppose we have an internal webserver hosting an error page that we would like to return if we get a hit on the responder policy)Tips: Of course you can chose to return a specific audit message that can be forwarded to an off-box SIEM solution instead of a web-page if you prefer that. Within the message you can insert dynamic tokens for the IP, URL or a Cookie value you are tracking to identify the application.
To do that you can configure an audit Message action using the Alert log level and define a log message that look something like this:
add audit messageaction aaa_login_err_alert ALERT “\”Max login attempts detected from \” + CLIENT.IP.SRC + \” to \” + HTTP.REQ.URL + \” within a 5 sec period. Possible brute force login attack\”” -logtoNewnslog YES -bypassSafetyCheck YES
- Create a new responder policy with name AD_Login_Limiter, bind the AD Login Limiter action you just created, and enter the following expression:
(HTTP.REQ.URL.EQ(“/vpn/tmindex.html”) || HTTP.REQ.URL.EQ(“/vpn/index.html”)) && HTTP.REQ.COOKIE.VALUE(“NSC_VPNERR”).EQ(“4001”) && SYS.CHECK_LIMIT(“AD_Login_Limiter“)
4. As a final step you need to bind the responder policy globally.
You should be good to go by now 😉
Test and see if it is working!
Attention! Be aware of:
- Directory Account Lock-out
HTTP Rate Limiting will not totally help you with the problem of account lock-out unless you set the thresholds for the selector to be less than the account security policy. This is a common occurrence with brute force attacks as they often use the same username iteratively with different password combinations. This issue can combated by using a 2nd factor auth method or Captcha. - False Positive Blocking from Forward Proxies
Users who are coming in on the same forward proxy could be blocked from access if there are multiple users attempting a login within the time slice window. This is due to all clients presenting themselves with the same SRC IP address which the limit identifier is tracking.
If you are thinking about tweaking and tracking for other parameters to configure something like this, here is a Good Rate Limiting Exampel