With NetScaler 14.1, Citrix started to allow binding Web Application Firewall (WAF) policies to the gateway and to a AAA vServer or a Gateway.

Why does it make sense to bind a WAF to the gateway?

The more popular Citrix NetScaler became, the greater the interest of hackers in NetScaler grew. And NetScaler is now a very widely used tool for remote access. Due to the increased interest of hackers in NetScaler, we are unfortunately seeing more and more vulnerabilities in the AAA (Authentication, Authorization, Auditing) process being exposed.

How can we protect ourselves? Since version 14.1, we can use NetScaler WAF to secure the AAA process without any tricks. This makes it more difficult for hackers: they have to find two errors that complement each other. One in the gateway, one in the WAF. This is relatively unlikely. So the gateway becomes much more secure if we use WAF to secure the AAA process.

Where to start?

First of all, read Julian Jakob’s great blog about this feature! It will tell you how to use it, and how to bind policies and profiles (hint: secretly, by changing AAA settings: Go to Gateway or AAA, “Change AAA settings” and select a policy.).

With 14.1 Build 21.57 and 13.1 Build 53.17 there’s the long-awaited support for using NetScaler’s Web Application Firewall (WAF) for all kinds of Gateway vServer and AAA vServer. It’s easy, there are pre-defined profiles for AAA and Gateway:

• ns-aaa-default-appfw-profile (intended for AAA)
• ns-aaatm-default-appfw-profile (AAA for trafic management)
• ns-vpn-default-appfw-profile (NetScaler gateway)

Great! Let’s use it!

Stop: First, let’s take a look at the profile. Mine here is based on AAA-TM. It’s is of type HTML, XML and JSON. Great! Everything there!

Unfortunately, we see, that there are hardly any security checks enabled! But it uses patterns: ns-aaatm-spec. Let’s have a look at these patterns! Oh. It’s not possible! They don’t exist! So these are secret patterns made by Citrix.

OK. A great new feature, but still room for improvement!

How to improve these existing profiles?

Signatures

Citrix has defined these hidden signatures. We don’t know what they do. On one hand, that’s good, because hackers don’t know either. On the other, it’s bad because we have to do what Citrix thinks is the best to do. Of course, I can’t judge how good these built-in signatures really are!

Like everywhere else in NetScaler, you can create your own signatures. But of course, you have to maintain them yourself, as is the case with any other signature. On the one hand, this is risky, but on the other hand, it is also an opportunity to do it better. Do you want to give it a try? If you fail, you can simply unbind your signature and the Citrix signature is automatically bound again.

Security scans

I found it astonishing that Citrix, apart from “Rest API Schema Validation”, does not use security scans at all. Why is that? I suspect the problem is the customization of the schemas.

Start URLs

It would actually be easy to check, say the start URLs. But of course that would block all self-made images, interfere with the login dialogs, etc. But if all that already exists? Nothing is easier than that! Let’s start the learning feature!

Learning works very well. I can see all unknown URLs in the learning log.
All?
No! Just a handful! That’s clearly not enough. This WAF profile seems to have a few things built in or not protected. I can’t judge that.
I deploy the few rules I have learned once and switch to block. The next login process works. But logging out doesn’t! But now I have /cgi/logout$ as a learned rule in learning. Also the deployed, now the logout also works.

Please, keep in mind: I didn’t do any customizations, this is just an example, you may need to do the learning yourself!

Field Formats

I wanted to do the same for field formats. However, learning had not been triggered with field formats. So I have to give it a try.
To do so, I define the field for the token (name: passwd1) as an integer [0-9], but limit the length to 4 digits. My tokens, however, are 6 always digits in size, so this should trigger the WAF.

This rule does not get triggered! So Field-Formats, different from Start URLs, won’t get triggered. This is also true, if I add very different types of data like ~@€*+^~.

So currently, Field-Formats are useless with AAA/Gateway.