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
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) :
Based on the profile type you choose, you define your security violation checks:
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:
We only gather learned data from the trusted IPs.
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.
Deploy or Edit and Deploy the rule.
Some Regular Expressions that could be useful when customizing the relaxation rules:
|
1 2 3 4 5 6 7 8 9 10 |
^ - start wildcard string $ - end .*$ - everything after path and end ^https://[.]hostname[.]dk/test/.*$ ^https://[.]hostname[.]dk/test/.*[][.]filename$ |
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.
|
1 2 3 4 5 6 7 8 |
add policy expression CIP "CLIENT.IP.SRC +\"\"" add policy patset AllowedIPs bind policy patset AllowedIPs 192.168.0.200 -index 1 bind policy patset AllowedIPs 192.168.0.201 -index 2 bind policy patset AllowedIPs 192.168.0.202 -index 3 set lb vserver "LB-VIP"-Listenpolicy "CIP.EQUALS_ANY(\"AllowedIPs\") && Client.TCP.DSTPORT.EQ(443)" |
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.
|
1 2 3 |
add appfw policy appfw-pol-webappname true appfw-prof-webappname bind cs vserver cs-vs-443-webapp -policyName appfw-pol-webappname -priority 100 -gotoPriorityExpression END -type REQUEST |
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.
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.
Enable Auto Update Settings of signature, Select Action on Signature.
Enable Signature rules and attach to AppFW Profile under Profile Settings.
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:
From local NetScaler Shell:
|
1 2 3 |
tail -f /var/log/ns.log I grep "APPFW" |
Gather network trace while reproducing issue:
|
1 2 3 4 |
set appfw profile -trace ON start nstrace -tcpdump enabled -size 0 -mode appFW stop nstrace |
The nstrace is stored in a time-stamped folder which is created in the /var/nstrace folder on the appliance.