Protect and Secure your Web Application with NetScaler Application Firewall (WAF) – Part 1

The first part of this post I am providing some information and guidelines on how to implement Citrix NetScaler Application Firewall in front of your web application.

In the second part coming up, we will look into the Security Insight of NMAS (NetScaler Management and Analytics Services) how this provide value and insight to an application firewall implementation.

Intro

NetScaler Web Application Firewall is basically an application level IDS/IPS. The Application Firewall can be run in Log mode only (IDS), in Block mode (IPS) or both.

The Application Firewall prevents security breaches, data loss, and possible unauthorized modifications to web sites that access sensitive business or customer information. It does so by filtering both requests and responses, examining them for evidence of malicious activity, and blocking those that exhibit such activity. Your site is protected not only from common types of attacks, but also from new, as yet unknown attacks.
In addition to protecting web servers and web sites from unauthorized access and misuse by hackers and malicious tools, the application firewall provides protection against security vulnerabilities in legacy code or scripts, other web frameworks, web server software, and the underlying operating systems

Fig. 1. – AppFW Flow

img-alternative-text

When a block occurs you can choose to redirect users a specific URL or deliver a HTML error object (Configed in the profile settings of the AppFW profile) :

img-alternative-text

Based on the profile type you choose, you define your security violation checks:

img-alternative-text

Guideline for implementing App Firewall

I recommend following approach for production deployment:

  • Plan
    • Know your environment; OS, WebServer, Application, Database, SSL, Traffic volume etc.
  • Identify your security needs and requirements
    • Evaluate which traffic and data that needs maximum protection and which that might need to be bypassed eg. static media files etc.
    • Use multiple policies and profiles to protect different content from within the same application
  • Test your deployment
    • Provide real user test when in learning mode, covering use cases
    • Evaluate after test is done, provide and adjust the needed relaxations
    • Run same user test in block mode
    • Evaluate functionality, performance and capacity requirements

It is important that the web developers viewpoint is taken into advise, when defining which Security Checks that should be applied and when implementing AppfW. What kind of policy set depends on the application platform. The same applies to the Signatures.

Trusted Learning Clients – Learning and Relaxation Rules

To ensure only legitimate traffic hits you AppFirewall make sure to cofigure “Trusted learning Clients” or only expose the vServer to pilot users internally.

We configure trusted learning clients under Learned Rules in the AppFW Profile.

We can here define clients that we trust and gather learned data from, either in IP or CIDR format:

img-alternative-text

We only gather learned data from the trusted IPs.

img-alternative-text

The learned rules should then only contain false/positive if any learned data is registered.

Based on the learned rules, you can then provide and deploy Relaxation rules. You need to find the right balance.
This is where you need to be cautious when applying these rules, as we want the relaxation rule to be very specific, but still not create a huge amount of management overhead or security exposure.

To evaluate and deploy a learned rule into a relaxation rule, go to the relevant security check under learned rules and select Edit.

img-alternative-text

Deploy or Edit and Deploy the rule.

img-alternative-text

Some Regular Expressions that could be useful when customizing the relaxation rules:

Listen Policy to limit access

We could also ensure that the vServer (Web App) in scope, only listens for traffic from specific IPs.

In this method below we use a Pattern Set to define a list of Client IPs, and we reference this in our Listen Policy on the vServer.

Firewall ACL to limit access

Another option is to control traffic to the AppFW enabled web application vServer by configuring an ACL on the Firewall between the pilot users and the vServer in scope.

AppFW Policy and Profile

Add the AppFW Policy as True and all traffic is inspected, then bind the AppFW policy to the Content Switch vServer or LB vServer in scope for the Web App.

You could split up multiple AppFW Policies and apply respectively based on content in the application.
It is possible to use a BYPASS policy but use carefully, and only apply when no better option is available.

When gathering data from AppFW Profile, use statistics on AppFW profile to get an overview of violations etc.

img-alternative-text

Signatures

Signatures can be created manually, or a copy of the default signature can be done. When signature rules are enabled and bound to the AppFW Profile, it looks for specific patterns in the traffic flow and blocks malicious traffic based on SNORT rules.

img-alternative-text

Enable Auto Update Settings of signature, Select Action on Signature.

img-alternative-text

Enable Signature rules and attach to AppFW Profile under Profile Settings.

img-alternative-text

Troubleshooting App Firewall

I would recommend to forward Syslog data to a central syslog management server, in order to provide better retention, indexing, archiving of log data. I have great experience with this open source syslog server:

GrayLog

From local NetScaler Shell:

Gather network trace while reproducing issue:

The nstrace is stored in a time-stamped folder which is created in the /var/nstrace folder on the appliance.

Leave a Reply