With the rapid change and development going on with Web 2 applications, security has always been a big concern. The same goes with network infrastructure, which is becoming more and more complex; and with the focus on software defined networking, more of the control plane is moving towards the software.

With this, there is also more that needs to be secured. For example, since websites are not just plain HTML anymore, they contain a large mix of dynamic content working with an active database in the back and adapting based upon who the users are and what kind of device the site is being accessed from.

So where does NetScaler fit in? Since it is usually between the users and the services, it might be, in many cases, the first line of defense against malicious hackers.

NetScaler is equipped with many security features that can fend off attacks, such as the following:

These are just some of the features that can be used; last but not least, we have the application firewall feature.

The application firewall is used to secure services running behind NetScaler. It consists of policies and profiles. Here we use the policy to identify patterns in the traffic, and profiles are used to specify what we are going to do with the traffic, like most features in NetScaler.

There are two ways that the application firewall delivers protection; the first is signature based. This means that NetScaler recognizes a pattern based upon a signature and, depending on the action, might drop the connection. So this is useful if it is a known vulnerability that a hacker is trying to exploit.

The second way it can protect is with the deep protection features, which are used for unknown attacks. Here, we can configure it with a learning feature. This learning feature can be a useful way to see, for example, which websites the users are allowed to access internally and which they are not. This allows NetScaler to adapt a standard behavior.

Here we can also define filters. For example, users are allowed to access my website but not a URL starting with /mysite or /sales and we can define an action when someone tries to access a URL with /mysite.

So deep protections are useful for URL masking, SQL injections, buffer overflows, managing forms, and so on.

Now that we have talked a little bit about how Application Firewall works, let us go in and show how it operates.

We cannot go through every feature within the application firewall, since it contains so much advanced functionality. We are only going to go through the basic features and some of the deep protection features. If you are interested in knowing more about the features not covered in this book, I suggest you head on over to the article in eDocs available at http://support.citrix.com/proddocs/topic/ns-security-10-1-map/appfw-checks-con.html; it contains information about all the different deep protection features.

Before we start using the application firewall feature, we have to enable it. This can be done by using the GUI under System | Settings | basic features | application firewall or by using the following CLI command:

Enable ns feature appfw

After that we can go to Security | Application Firewall and start configuring the features. To show how we can enable the different protection features, we can go through Application Firewall Wizard.

This will start a wizard where we first need to define the name of a web application. This is not linked to vServers but is used just for descriptive purposes. We also need to define a web application type that defines what choices we get in protection features. So as an example, let us say that we want to secure a regular IIS site running on Windows Server 2012, which is basic HTML. Then we can enter the name IIS and choose regular web application HTML under type.

Next, under Rule, we need to define a rule that allows NetScaler to identify which traffic it should look at. Here we can use many of the same expressions we use on the other features; we can also type in true. Then, this rule will apply for every connection made to NetScaler.

Next, we need to choose what signatures we want to enable; since this is an IIS server, we can enable Microsoft IIS signatures. When we click on Next here, we get some options as to what we would like NetScaler to do with the traffic that is picked up by the signatures. The default is Log and Stat.

If we click on More…, we can see all of the different signatures that are going to be used as part of the IIS signature set.

We can leave it at default for now just to see what happens, so click on Next. Now we need to configure the deep protection features.

Remember that these features are for an unknown attack, so we can use the learning feature to define a baseline or go in and change the default behavior. This feature applies for XSS, SQL injections, and more, but for now let us just enable Start URL and Deny URL under the URL Protection features.

When we click on Next, we are presented with the two features we enabled. This can be seen in the following screenshot:

The Start URL action defines which URL a client is allowed to use to start a connection against a service. This means that the first connection from our client can go directly to http://mycompany.com/index.html but not directly to http://mycompany.com/employee/me.

This function is used to prevent forceful browsing, which means preventing repeated attempts at random URLs. So URLs entered here cannot be used with, for example, bookmarks since they are direct URLs.

By default, the feature is set with the following values:

We can also enable Block; then, the feature will start blocking requests made if a rule is violated.

If we click on Open, we are presented with Checks; these define which start URLs are allowed. We also have a Learning button down below; if we have enabled the learning function for this feature, it will show all the entry URLs that have been accessed.

We can also enter our own custom entry start URLs; if we want all our users to start on index.html, we can add this by choosing Add and entering the URL.

But we can enable the blocking action and leave the rest at its default and make sure that the learn action is enabled.

If we go back to the deep actions, we also have the deny URL action. This is basically an allow/deny action. If we click open, we get a list of URLs where we can define the users that are not allowed to browse, as shown in the following screenshot:

Now, by default, none of these rules will do anything. We have to enable them and then define a general action for the rules. For example, if we want to block connections that are tied to HTR source disclosure, we would need to perform the following actions:

We can also add our own URLs by choosing the Add button and then choosing enabled. So, after we have reviewed the settings, click on Next and then on Finish.

Now, by default, this policy will be bound at a global level, meaning that it will apply to every service on NetScaler. If we want to bind it to a specific service, we should unbind it at a global level and bind it to a specific service.

Now, if we wish to change the bindings, go to Application Firewall | Policy manager | Default Global; we can see that the application we created is now bound there. Choose Unbind and then find the web service we wish to bind it to and choose Bind.

If we now start to do some random requests against the Web service, we can see that the log starts to fill up, and if we try to open some URLs that we have defined as not allowed, we can also see the violation rules.

These can be viewed by navigating to Application Firewall | Policies and then selecting the name of the policy we just created.

Open it, go to Security Checks, and choose Logs. We can see from the following screenshot that, after accessing some random URLs on our web service, the Start URL rule kicks in and starts blocking connections.

Every user who tries to access a random URL on the service that triggers a violation rule will automatically get redirected to the main page. We can define a redirect URL for those who try to access random URLs.

This can be done by navigating to Profile | Settings | Redirect URL.

We have now seen a small portion of what Application Firewall has to offer; it offers a wide range of different features that can be used to prevent Cross Side Scripting, SQL injections, and such. As mentioned earlier, if you wish to learn more about the different features within Application Firewall, head over to the following eDocs article: http://support.citrix.com/proddocs/topic/ns-security-10-map/appfw-config-con.html.