Learning Application Firewall (Must know)

The AppFw module checks the HTTP host and referrer headers that are present in the requests, and prevents any attacks to modify the content of forms sent to the server. It also maintains the state of each session with the help of its own session cookies. This section would help us dive into the possible features available in APPFw. Citrix NetScaler App Firewall is compliant with the PCI-DSS criteria; it also protects zero-day or custom-made attacks, which we will see in detail later in this chapter

Getting ready

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:

• Basic

• Advanced

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).

How to do it...

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

1. Configure App Firewall profile to be basic, and configure a policy with RULE (here we are going to use HTTP.REQ.IS_VALID), which means anything and everything.

2. Tick the Learning checkbox of Start URL before you enable blocking.

3. Go to the App Firewall profile, under the Settings tab. HTML Settings can be configured to redirect to another URL or load an html page:

   

4. Bind the App Firewall policy to the appropriate load balancing (LB Vserver, for the policy to take effect when the user tries to access the LB Vserver.

   For example, www.packttest.com resolves to the VIP of an LB Vserver. The following code snippet shows the config through CLI:

   >add appfw profile packtpro -startURLAction none -RefererHeaderCheck if_present -CSRFtagAction block log stats -crossSiteScriptingAction learn log stats -crossSiteScriptingCheckCompleteURLs ON -XMLSQLInjectionAction none -XMLXSSAction none -XMLWSIAction none -XMLValidationAction none -useHTMLErrorObject ON -HTMLErrorObject test
   >add appfw policy packtpol HTTP.REQ.IS_VALID packtpro
   >bind lb vserver packtlb packt_svc
   >bind lb vserver packtlb -policyName packtpol -priority 100 -gotoPriorityExpression END -type REQUEST
   

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.*)"

How it works...

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.

There's more...

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

Tips and troubleshooting

A few commands that will help us in troubleshooting the App Firewall issues are as follows:

• show appfw stats: This output shows the request and response rate per second, the violation stats, and the number of server-side response error pages (for example, starting with 4xx and 5xx).

• show appfw settings:

  DefaultProfile:  APPFW_BYPASS UndefAction:  APPFW_BLOCK
  SessionTimeout:  900     SessionLifetime:  0
  SessionCookieName:  citrix_ns_id ImportSizeLimit:  134217728
  CookiePostEncryptPrefix:  ENC
  Done
  

  As the output denotes, this displays the default profile and action. The default session timeout (in seconds), beyond which the App Firewall module will terminate the idle user session, the cookie name, and so on, are all configurable.

• /var/log/ns.log and messages.gz: These commands will show the App Firewall logs in addition to the packet captures, and so on.

Starting with NetScaler version 10, the Common Event Format logging is enabled on NetScaler. In fact, the logs contain the source port in addition with the IP address and the HTTP method used by the client/users, which is very useful for debugging purposes.

Importing and exporting the App Firewall profile configuration across NetScaler devices makes it easier for the administrator to configure on many NetScaler appliances in one go.

Sessionless URL closure has the same functionality as session URL closure, with the only difference being that instead of tracking a session based on a cookie, the App Firewall module now inserts token into the responses that are being sent to the client.

Note

Once deployed in the main production site, it is no longer required to enable Learning for each of the subfeatures in an AppFw profile, since that would only cause more and more resources to get depleted.

The Application Firewall, though deployed in a Layer 3/Layer 4 setup, works mainly on Layer 7 HTTP. It is recommended to test this feature in your labs before making it sit directly on your production environment, even though the configuration is as simple as ticking a checkbox and enabling a few options. The results should be optimal for your organization's standpoint.