We had a pre-sequel to the attack prevention in the previous recipe, touching only on the first line of defense; in this recipe we will discuss the app firewall module in a little more detail.

In the Configuration Utility, there is a checkbox for learning. Hence, before you set the box to production, you need to first gather a sample of the actual traffic hitting NetScaler and then enable blocking.

The HTTP referer headers are used to denote the previous page they were sourced from, and this can be exploited to get access to websites by masquerading as though coming from a valid website—it is similar to spoofing. In the App Firewall module, there is a feature called Start URL, where we can validate the referer header, if present. As shown in the following screenshot, Block, Learn, Log, and Stat are the actions that can be configured against each of the features.

There are two types of profiles that can be configured on the APP Firewall:

The difference between the two of them is that the Learn checks will not be enabled by default in the basic profile. Since the security checks all operations on the HTTP responses, it requires resources to retain and compare the information it sent previously to the users:

Learned Violations can be seen and altered according to the organization's requirements as shown in the preceding screenshot. Starting with NetScaler version 10, using the CEF (Common Event Format) logs, one can decide whether to deploy by clicking on Logs... or not.

Also in a high-availability setup, the learned data can be propagated to the secondary device, so it would help in a seamless failover (only on NetScaler version 10).

In this section, we are going to see how Start URL and the Cross Site scripting prevention work with NetScaler App Firewall:

Under the Learning Tab of the App Firewall profile, clicking on Start URL will show us the list of scripts it has learned from the traffic hitting the NetScaler:

With this data, we can select what is needed to be deployed. Once deployed, it creates a white list of URLs, which are obtained from all the responses during the user session. This functionality is called the URL closure and can be enabled under the Start URL feature (Go to the Security Checks tab of the App Firewall profile):

A simple setup is used to demonstrate the Start URL protection as shown in the preceding screenshot.

This protection can be tested by creating a query in the URL, for example, http://www.packttest.com, which is an LB VIP created with Netscaler. This URL is listed in the white list with the Start URL feature; however, http://www.packttest.com/?<script>alert(hi)</script> is not, and should be blocked as this is injecting a script along with the URL. To test this feature, we need to enable the Block checkbox in the Security Checks tab of the profile.

We could see the protection happening from the ns.log, after accessing the preceding URL:

When there is a violation of the rules, it is logged in the NetScaler BSD shell under /var/log/ns.log:

Here, along with the timestamp, we can see the URL being accessed as well as the <blocked> action taken by the App Firewall.

After learning and deploying a certain rule, we can see the rule in the running config:

>show run | grep packtpro
bind appfw profile packtpro -startURL "^http://www\\.packttest\\.com/$"

The second part of the testing is to check whether the same profile works with a CSRF attack.

The CSRF (Cross-Site Request Forgery) attacks work on logged-in user sessions, modifying the HTTP request. NetScaler adds a unique token to the forms that are sent to the users and validate the token on subsequent requests and responses between client and server.

The same setup and configuration used in the preceding demo is used here. We are going to test the site by using any link or URL on the webpage and add a script or query to the link while accessing, for example, the same VIP as used before, http://www.packttest.com, which opens up the web page, clicking on a link or URL on the web page http://www.packttest.com/citrix_products_netscaler.html?<script>alert(hi)</script>.

As we can see in the following screenshot, the ns.log has a log message stating that the packet is blocked due to a tag validation failure:

As always, it also displays the URL that is being accessed (outlined in the preceding screenshot).

Here is a HTTP header trace to show the transactions between NetScaler and the client:

GET /Test.xml?<script>alert(hi)</script> HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3)
Accept-Encoding: gzip, deflate
Host: www.packttest.com
Connection: Keep-Alive
Cookie: citrix_ns_id=SQIoGifoC0oF+GaOVYl3cCJDKTQA000

HTTP/1.1 200 OK
Pragma: "no-cache"
Content-Length: 99
Connection: close
<html>
<head>
      <title>THIS PAGE IS BLOCKED BY CITRIX APPLICAITON FIREWALL
    </title>
  </head>
</html>

As we can see in the preceding header, the session is already established and hence we see the cookie in the GET request of the client containing citrix_ns_id=SQIoGifoC0oF+GaOVYl3cCJDKTQA000.

NetScaler gracefully terminates the connection with a 200 OK message, as can be seen from a wireshark capture taken on NetScaler (see the following screenshot). The FIN and PUSH flags are highlighted in the screenshot.

There are other functionalities, such as masking the credit card numbers and other safe objects while sending responses to the users. The safe objects are configurable on NetScaler, such that when traffic hits the NetScaler, the App Firewall module checks for any safe object pattern in the requests and responses:

Role-based access control

Role-based access control is a feature that is used to control the admin access rights to NetScaler. We can configure the command policy to add/remove commands, show commands or restrict commands, to users. A predefined command policy is shown in the following screenshot:

The CLI command to configure a test user:

CLI>add system cmdPolicy test ALLOW "(^\\S+\\s+serviceGroup.*)|(^\\S+\\s+vserver.*)"

The Citrix App Firewall module comes in at both the request- and response-side processing of traffic. After the content switching or LB vserver (whichever is configured as client facing), the App Firewall module parses through the packets to check for anomalies. Similarly at the response side after SSL decryption, rewrite (if any) content filtering and then App Firewall before sending the response to the client.

In the How to do it... section of this recipe, we saw the configuration setting for defense against Start URL and CSRF attacks. The AppFw first learns the URLs passing through it using the Learning module before we deploy the rules according to our requirement. We would be able to see the rules learnt by the AppFw in the Managed Learned Rules.

In the Role-based access control section, we saw how to control the management access of NetScaler for different users at different levels. We would be able to restrict them based on read-only commands, read/write commands, superuser commands, and so on.

App Firewall needs to be used with utmost planning as it is resource intensive. In sites where Integrated Caching and App firewall is used, CPU usage will tend to be on the higher side. All NetScaler MPX series that have 4 GB of RAM are capable of handling both caching and App Firewall implementation. Typically, the Application Firewall sits in front of the caching module and the best part about this is it does not require remodeling one's network; instead it is similar to adding on the existing network, making it more secure.

In this section, we will see the new features available in NetScaler's latest versions and also a few known issues.