One of the more common requests I see is how to prevent brute force login attacks to the 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.

Part 1 of this article looks at 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. Part 2 we will look at how you can leverage CAPTCHA on the NetScaler to augment this method to provide an additional layer of protection.

Some background on the problem to solve

It is fairly simple now-a-days in the age of YouTube how-to videos and a myriad of other black art do-it-yourself tools (Brutus, THC Hydra, John the Ripper, Cain & Abel, etc…) to learn how to build and orchestrate a brute force style dictionary attack which attempts to find a set of username and password credential pairings that successfully authenticate a malicious attacker. For sites that use HTTP authentication methods such as an HTML Forms this involves, at a very basic level, a specifically crafted HTTP Post which has user/pass form field names with variables that change with each request in a loop that iterates to N! until the dictionary library of usernames and passwords has been exhausted. In statistics, this is simply referred to as Combination theory where you have a combination of n things taken k at a time without or with repetitions. This is a very simple computation for a single computer to perform and even easier when you are dealing with something distributed. All might need to do is buy or compile a decent list of URLs, usernames and passwords to reference. Implementing protection against brute force attacks is important for any organization exposing an application to the Internet and is also one of the Open Web Application Security Projects (OWASP) recommended testing procedures.

How can the NetScaler HTTP Rate Limiting feature help?

Since both AGEE and NetScaler utilize HTTP Forms authentication, they are also vulnerable to this problem. The NetScaler HTTP Rate Limiting feature can be used in conjunction with the Responder feature as a valid deterrent to help address this vulnerability.

Below is a graphical display of the flow of a logon session with the Rate limiting method configured.

1
End user or malicious application/user are presented with a login form to “POST” credentials to.
q

2
Invalid credentials result in an error message displayed to the end user and a specific HTTP response
q

3
What we want to accomplish after a set number of login attempts are exceeded within a certain time slice, the user is presented with an alternate response that prevents further posts and potentially also prevents an account lock-out if we make the threshold lower than the account security policy

Implementation on Citrix NetScaler

Follow these 6 steps to limit the number of requests to the AGEE or AAATM login page. Steps for both GUI and CLI are provided.

1

 Define a Limit Selector
This tells us what to track or “select”. You want to select both IP and URL since we want to track hits to the same URL from the same IP
GUI:
Define a limit selector
CLI:
add ns limitSelector aaa_err_login_selector CLIENT.IP.SRC HTTP.REQ.URL

2

 Define a Limit Identifier
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 URL 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.
GUI:
Define a Limit Identifier
CLI:
add ns limitIdentifier aaa_err_login_identifier -threshold 3 -timeSlice 300000 -selectorName aaa_err_login_selector -trapsInTimeSlice 3

3

 Define a Log Message Action
This step is optional but does provides a mechanism to notify you with a specific audit message that can be forwarded to an off-box SIEM solution. Within the message you can insert dynamic tokens for the IP and URL you are tracking to identify the application.
GUI:
Define a Custom Log Message
CLI:
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

4

 Define a Responder Action
What an malicious end-user or “bot” would see if they met the threshold defined in the limit identifier.Note – this Responder Action could be more simplified, but this one is crafted to integrate with the NetScaler Symphony Theme.  If you are using a different type of HTTP Auth, or you do not desire to indulge the attackers with any response at all, you may also configure a responder policy to simply DROP or RESET the connection.
GUI:
Define a Responder Action
CLI:
add responder action aaa_err_login_blockip_5min_act respondwith “\”<html><head><title>Citrix NetScaler</title><link rel=\’SHORTCUT ICON\’ href=\’/vpn/images/AccessGateway.ico\’ type=\’image/vnd.microsoft.icon\’><meta http-equiv=\’Content-Type\’ content=\’text/html; charset=UTF-8\’>\” + \”<meta content=noindex,nofollow,noarchive name=robots><link href=\’/vpn/images/caxtonstyle.css\’ type=text/css rel=STYLESHEET></head><body>\” + \”<table style=\’height:100%; width:100%;background:#e4e7e9 url(/vpn/images/Background.png) repeat-x center left;\’ cellpadding=\’0\’ cellspacing=\’0\’><tr><td valign=\’middle\’ align=\’center\’><table cellspacing=\’0\’ cellpadding=\’0\’ border=\’0\’><tr>\” + \”<td align=\’center\’><table cellspacing=\’0\’ cellpadding=\’0\’ class=\’logonBoxWidth\’><tr><td colspan=\’3\’ class=\’headertop\’><span class=\’headerLabel\’>NetScaler Access Gateway</span><span class=\’headertm\’><sup>TM</sup></span></td></tr><tr>\” + \”<td class=\’logonBoxTopLeft\’></td><td class=\’logonBoxTopMid\’></td><td class=\’logonBoxTopRight\’></td></tr><tr><td class=\’logonBoxMidLeft\’></td><td class=\’logonBoxMid\’ align=\’justified\’ valign=\’middle\’\’>\” + \”You have reached the maximum allowed login attempts from your device at: <strong> \” + CLIENT.IP.SRC + \”</strong>. <p>You will not be permitted to logon again for 5 minutes. Please contact your system administrator\” + \”.</td><td class=\’logonBoxMidRight\’></td></tr><tr>\” + \”<td class=\’logonBoxFooterLeft\’></td><td class=\’logonBoxFooterMid\’></td><td class=\’logonBoxFooterRight\’></td></tr></table></td></tr></table></td></tr></table><div class=\’BottomLogo\’><img src=\’/vpn/images/logo.png\’ height=\’25\’ width=\’60\’ /></div>\” + \”</body></html>\””

5

 Define a Responder Policy for AAATM or AGEE
The responder policy references the rate limit selector and matches the AAATM or VPN URLs and also detects the presence of the invalid login session cookie and fires the responder and log actions defined above.Note – If you only desire to trap AAATM or AGEE VPN you can remove the relevant condition in the defined expression. This method will also work for other web applications byt specifying a different URL.
GUI:
Define a Responder Policy
CLI:
add responder policy aaa_err_login_blockip_5min_policy “(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(\”aaa_err_login_identifier\”)” aaa_err_login_blockip_5min_act -logAction aaa_login_err_alert

6

 Globally bind the Responder Policy
We have to bind globally to deal with both VPN and AAATM but it would be just as easy to bind the responder policy to a specific AAATM or VPN VServer.
GUI:
Globally Bind the Responder Policy
CLI:
bind responder global aaa_err_login_blockip_5min_policy 110 END -type REQ_DEFAULT

What else can be done?

  1. Utilize 2-factor authentication such as RSA SecurID, Phonefactor, CryptoCard, etc…
    When a second factor auth is provided, this immensely improves the over-all authentication security posture. The most common is a One-Time-Password (OTP) solution that requires the user to use something they know and a form of challenge which may range from a randomized code from a token to a phone call, email, or SMS message. NetScaler supports many of these 2-factor solutions as they are based on standard RADIUS. Many vendors have also gotten Citrix Ready certification which means they have verified their solution works properly with Citrix NetScaler and Access Gateway.
  2. Use a 2-factor authentication method as the Primary Authentication
    The NetScaler or Access Gateway permit the configuration of Primary and Secondary authentication methods, In addition, this second factor method can be specified as the primary authentication method. The significance of this is that the 2nd factor auth would be attempted first by the NetScaler AAA daemon and will fail if the attempt if the before the directory auth is attempted.
  3. Implement Captcha image verification – (See Part 2)
    Captcha stands for Completely Automated Public Turing test to tell Computers and Humans Apart. This method involves presenting a problem challenge that humans can solve but would be very difficult for a computer. Captcha was specifically developed to prevent automated software from filling out an HTML form such as those used for logon. A common type of CAPTCHA requires the user to type letters or digits from a distorted image that appears on the screen.

What does HTTP Rate Limiting not address?

  • 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 as described above.
  • 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.

Download the batch configuration script

More Information