NS AppFirewall Guide

Citrix
NetScaler
9.2
Citrix Application Firewall Guide

Copyright and Trademark Notice
CITRIX SYSTEMS, INC., 2010. ALL RIGHTS RESERVED. NO PART OF THIS DOCUMENT MAY BE REPRODUCED OR
TRANSMITTED IN ANY FORM OR BY ANY MEANS OR USED TO MAKE DERIVATIVE WORK (SUCH AS TRANSLATION,
TRANSFORMATION, OR ADAPTATION) WITHOUT THE EXPRESS WRITTEN PERMISSION OF CITRIX SYSTEMS, INC.
ALTHOUGH THE MATERIAL PRESENTED IN THIS DOCUMENT IS BELIEVED TO BE ACCURATE, IT IS PRESENTED
WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE ALL RESPONSIBILITY FOR THE USE
OR APPLICATION OF THE PRODUCT(S) DESCRIBED IN THIS MANUAL.
CITRIX SYSTEMS, INC. OR ITS SUPPLIERS DO NOT ASSUME ANY LIABILITY THAT MAY OCCUR DUE TO THE USE OR
APPLICATION OF THE PRODUCT(S) DESCRIBED IN THIS DOCUMENT. INFORMATION IN THIS DOCUMENT IS SUBJ ECT
TO CHANGE WITHOUT NOTICE. COMPANIES, NAMES, AND DATA USED IN EXAMPLES ARE FICTITIOUS UNLESS
OTHERWISE NOTED.
The following information is for FCC compliance of Class A devices: This equipment has been tested and found to comply with the limits
for a Class A digital device, pursuant to part 15 of the FCC rules. These limits are designed to provide reasonable protection against
harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses, and can radiate radio-
frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio
communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case users will be
required to correct the interference at their own expense.
Modifying the equipment without Citrix' written authorization may result in the equipment no longer complying with FCC requirements
for Class A digital devices. In that event, your right to use the equipment may be limited by FCC regulations, and you may be required to
correct any interference to radio or television communications at your own expense.
You can determine whether your equipment is causing interference by turning it off. If the interference stops, it was probably caused by
the NetScaler Request Switch 9000 Series equipment. If the NetScaler equipment causes interference, try to correct the interference by
using one or more of the following measures:
Move the NetScaler equipment to one side or the other of your equipment.
Move the NetScaler equipment farther away from your equipment.
Plug the NetScaler equipment into an outlet on a different circuit from your equipment. (Make sure the NetScaler equipment and your
equipment are on circuits controlled by different circuit breakers or fuses.)
Modifications to this product not authorized by Citrix Systems, Inc., could void the FCC approval and negate your authority to operate the
product.
BroadCom is a registered trademark of BroadCom Corporation. Fast Ramp, NetScaler, WANScaler, Citrix XenApp, and NetScaler
Request Switch are trademarks of Citrix Systems, Inc. Linux is a registered trademark of Linus Torvalds. Internet Explorer, Microsoft,
PowerPoint, Windows and Windows product names such as Windows NT are trademarks or registered trademarks of the Microsoft
Corporation. NetScape is a registered trademark of Netscape Communications Corporation. Red Hat is a trademark of Red Hat, Inc. Sun
and Sun Microsystems are registered trademarks of Sun Microsystems, Inc. Other brand and product names may be registered trademarks
or trademarks of their respective holders.
Software covered by the following third party copyrights may be included with this product and will also be subject to the software license
agreement: Copyright 1998 Carnegie Mellon University. All rights reserved. Copyright David L. Mills 1993, 1994. Copyright
1992, 1993, 1994, 1997 Henry Spencer. Copyright J ean-loup Gailly and Mark Adler. Copyright 1999, 2000 by J ef Poskanzer. All
rights reserved. Copyright Markus Friedl, Theo de Raadt, Niels Provos, Dug Song, Aaron Campbell, Damien Miller, Kevin Steves. All
rights reserved. Copyright 1982, 1985, 1986, 1988-1991, 1993 Regents of the University of California. All rights reserved. Copyright
1995 Tatu Ylonen, Espoo, Finland. All rights reserved. Copyright UNIX System Laboratories, Inc. Copyright 2001 Mark R V
Murray. Copyright 1995-1998 Eric Young. Copyright 1995,1996,1997,1998. Lars Fenneberg. Copyright 1992. Livingston
Enterprises, Inc. Copyright 1992, 1993, 1994, 1995. The Regents of the University of Michigan and Merit Network, Inc. Copyright
1991-2, RSA Data Security, Inc. Created 1991. Copyright 1998 J uniper Networks, Inc. All rights reserved. Copyright 2001, 2002
Networks Associates Technology, Inc. All rights reserved. Copyright (c) 2002 Networks Associates Technology, Inc. Copyright 1999-
2001The Open LDAP Foundation. All Rights Reserved. Copyright 1999 Andrzej Bialecki. All rights reserved. Copyright 2000
The Apache Software Foundation. All rights reserved. Copyright (C) 2001-2003 Robert A. van Engelen, Genivia inc. All Rights
Reserved. Copyright (c) 1997-2004 University of Cambridge. All rights reserved. Copyright (c) 1995. David Greenman. Copyright (c)
2001 J onathan Lemon. All rights reserved. Copyright (c) 1997, 1998, 1999. Bill Paul. All rights reserved. Copyright (c) 1994-1997 Matt
Thomas. All rights reserved. Copyright 2000 J ason L. Wright. Copyright 2000 Theo de Raadt. Copyright 2001 Patrik Lindergren.
All rights reserved.
Last Updated: J uly 2010
CONTENTS
Preface
About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
New in This Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv
Formatting Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv
Related Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .v
Getting Service and Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .v
Documentation Feedback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
Chapter 1 Introduction
What is the Application Firewall? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
What the Application Firewall Does . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
How the Application Firewall Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
The Application Firewall Platform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
The Application Firewall on a Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
The User Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
The Citrix NetScaler Command Line Interface . . . . . . . . . . . . . . . . . . . . . . . . .10
The Citrix NetScaler Configuration Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
Chapter 2 Installation
Planning the Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
Installing the Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
The Citrix NetScaler 7000. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
The Citrix NetScaler 9010. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
The Citrix NetScaler 10010. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
The Citrix NetScaler 12000. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
The Citrix NetScaler MPX 15000. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
The Citrix NetScaler MPX 17000. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
Performing Initial Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Using the Configuration Utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
Using the Citrix NetScaler Command Line Interface . . . . . . . . . . . . . . . . . . . .58
Chapter 3 Simple Configuration
Enabling the Application Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
Creating and Configuring a Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
Creating and Configuring Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71
Binding Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
iv Citrix Application Firewall Guide
Chapter 4 Profiles
About Application Firewall Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84
The Built-In Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84
User-Created Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84
Creating, Configuring, and Deleting Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
Configuring the Security Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101
Common Security Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101
HTML Security Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102
XML Security Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103
Configuring the Security Checks with the Configuration Utility. . . . . . . . . . .104
Configuring the Security Checks at the NetScaler Command Line. . . . . . . . .114
Configuring the Profile Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122
Configuring the Profile Settings by Using the Configuration Utility . . . . . . .122
Configuring the Profile Settings at the NetScaler Command Line . . . . . . . . .126
Configuring the Learning Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129
Chapter 5 Policies
An Overview of Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135
Configuring Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136
Globally Binding a Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .149
Chapter 6 Imports
Creating a Custom Settings File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154
Exporting the Default Custom Settings File. . . . . . . . . . . . . . . . . . . . . . . . . . .154
Editing the Custom Settings File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155
Importing Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157
Chapter 7 Global Configuration
The Engine Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161
Cookie Name. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162
Session Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162
Maximum Session Lifetime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163
Logging Header Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163
Undefined Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164
Default Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164
Import Size Limit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165
Confidential Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .166
Field Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171
Contents v
Chapter 8 The Common Security Checks
The Start URL Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175
Configuring the Start URL List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179
The Deny URL Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182
Configuring the Deny URL List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .183
The Cookie Consistency Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .186
Configuring the Cookie Consistency List. . . . . . . . . . . . . . . . . . . . . . . . . . . . .188
The Buffer Overflow Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .190
Configuring the Buffer Overflow Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . .192
The Credit Card Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193
Configuring the Credit Card List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .195
The Safe Object Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .196
Chapter 9 The HTML Security Checks
The Form Field Consistency Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201
Configuring the Form Field Consistency List . . . . . . . . . . . . . . . . . . . . . . . . .205
The Field Formats Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .208
Configuring the Field Formats List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .212
The CSRF Form Tagging Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .215
Configuring the CSRF Form Tagging List. . . . . . . . . . . . . . . . . . . . . . . . . . . .218
The HTML Cross-Site Scripting Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .219
Configuring the HTML Cross-Site Scripting List . . . . . . . . . . . . . . . . . . . . . .223
The HTML SQL Injection Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .226
Configuring the HTML SQL Injection List . . . . . . . . . . . . . . . . . . . . . . . . . . .231
Chapter 10 The XML Security Checks
The XML Format Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .235
The XML Denial of Service Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .237
Configuring the XML Denial of Service List. . . . . . . . . . . . . . . . . . . . . . . . . .239
The XML Cross-Site Scripting Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241
The XML SQL Injection Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243
The XML Attachment Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .246
Configuring the XML Attachment Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . .248
The Web Services Interoperability Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .249
Configuring the Web Services Interoperability List. . . . . . . . . . . . . . . . . . . . .251
The XML Message Validation Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .252
Configuring the XML Message Validation Checks. . . . . . . . . . . . . . . . . . . . .253
The XML SOAP Fault Filtering Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .255
vi Citrix Application Firewall Guide
Chapter 11 The Application Firewall Reports
The PCI DSS Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .257
The Application Firewall Configuration Report . . . . . . . . . . . . . . . . . . . . . . . . . .260
The PCI DSS Standard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .263
Chapter 12 Use Cases
Protecting a Shopping Cart Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .267
Creating and Configuring the Shopping Cart Profile. . . . . . . . . . . . . . . . . . . .268
Creating and Configuring a Shopping Cart Policy. . . . . . . . . . . . . . . . . . . . . .284
Protecting a Product Information Query Page. . . . . . . . . . . . . . . . . . . . . . . . . . . .289
Creating and Configuring a Product Query Profile . . . . . . . . . . . . . . . . . . . . .290
Creating and Configuring a Product Query Policy. . . . . . . . . . . . . . . . . . . . . .299
Managing Learning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .303
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Appendix A PCRE Character Encoding Format
Representing UTF-8 Characters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347
Appendix B PCI DSS Standard
Appendix C Configuring for Large Files and Web Pages
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .369
Three Workarounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .369
Appendix D SQL Injection Check Keywords
Appendix E Cross-Site Scripting: Allowed Tags and Attributes
Allowed Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .381
Allowed Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .383
PREFACE
Preface
Before you begin to configure the Citrix Application Firewall, take a few minutes
to review this chapter and learn about related documentation, other support
options, and ways to send us feedback.
In This Preface
About This Guide
New in This Release
Audience
Formatting Conventions
Related Documentation
Getting Service and Support
Documentation Feedback
About This Guide
The Citrix Application Firewall Guide provides an overview of two products: the
standalone Citrix Application Firewall, and the Citrix NetScaler Application
Firewall feature, an integrated part of the Citrix NetScaler Application Delivery
System. Except for certain installation and basic configuration steps, these
products are nearly identical. The guide explains what the Application Firewall is
and does, and provides detailed instructions on installing, configuring, and
managing it.
This guide provides the following information:
Chapter 1, Introduction. Provides an overview of the Application
Firewall, including what it does and how it works.
Chapter 2, Installation. Provides installation and configuration
information for the standalone Citrix Application Firewall.
Chapter 3, Simple Configuration. Provides instructions on how to create
your first Application Firewall profile, your first Application Firewall
ii Citrix Application Firewall Guide
policy, and globally bind the policy. This process enables the Application
Firewall to start protecting Web servers.
Chapter 4, Profiles. Describes Application Firewall profiles and how to
configure the security checks and other settings associated with profiles.
Chapter 5, Policies. Describes Application Firewall policies, how to
create a policy, and the structure of the expressions language used in
creating policies.
Chapter 6, Imports. Provides instructions on how to import HTML error
pages, XML error pages, XML schemas, and WSDL pages into the
Application Firewall configuration.
Chapter 7, Global Configuration. Provides instructions on how to
configure the global Engine settings, Confidential Field settings, and Field
types.
Chapter 8, The Common Security Checks. Describes each Application
Firewall security check that is common to all types of profile.
Chapter 9, The HTML Security Checks. Describes each Application
Firewall security check that applies to HTML-based Web applications and
HTML content.
Chapter 10, The XML Security Checks. Describes each Application
Firewall security check that applies to XML-based Web services and XML
content.
Chapter 11, The Application Firewall Reports. Describes the PCI DSS
report and the The Application Firewall Configuration report, and provides
an overview of the PCI DSS standard.
Chapter 12, Use Cases. Provides two use cases that describe how to
configure the Application Firewall to protect a back-end SQL database, and
scripted content that accesses and/or modifies information on other Web
servers.
AppendixA, PCRE Character Encoding. Provides a primer on using
PCRE character encoding to represent non-ASCII characters in Application
Firewall regular expressions.
AppendixB, PCI DSS Standard. Provides a copy of the official Payment
Card Industry (PCI) Data Security (DSS) Standard.
AppendixC, Configuring for Large Files and Web Pages. Provides
instructions on how to configure the Application Firewall to handle large
uploaded files and large, complex Web pages with minimal impact on
performance.
AppendixD, SQL Injection Check Keywords. Lists the SQL keywords
that the Application Firewall SQL Injection security check uses when
examine requests.
iii
AppendixE, Cross-Site Scripting: Allowed Tags and Attributes. Lists the
HTML tags and attributes that the Application Firewall Cross-Site
Scripting security check will allow in requests without blocking the request.
New in This Release
NetScaler nCore Technology uses multiple CPU cores for packet handling and
greatly improves the performance of many NetScaler features. Release 9.2 adds
nCore support for many additional features, including load balancing, virtual
private networks (VPNs), and the Application Firewall.
In Release 9.2, the following new features are also supported in the Application
Firewall:
Built-in profiles. The Application Firewall now installs with four built-in
profiles. These profiles provide tools to allow or block connections that do
not require further filtering.
Default and undefined profiles. You can now designate a default profile
and an undefined profile on a per-profile basis. The default profile is used
for connections that do not match any Application Firewall policy. The
undefined profile is used when a connection evaluates as undefined.
Learning feature GUI changes. The Manage Learned Rules dialog box
has been simplified and streamlined, and the Learning Data Visualizer has
been integrated more completely with the Learning feature.
NetScaler advanced policies. You can now use advanced policies and
expressions to configure the Application Firewall. Advanced expressions
provide a rich set of expression elements along with options to control the
flow of evaluation within a policy bank. These elements and options enable
you to maximize the capabilities of the Application Firewall. Advanced
policies, which comprise a set of rules and actions that use the advanced
expression format, further enhance your ability to analyze data at various
network layers and at different points along the flow of traffic. For more
information about the benefits of using advanced policies and expressions,
see the Introduction to Policies and Expressions chapter in the Citrix
NetScaler Policy Configuration and Reference Guide.
User-configurable SQL and XSS lists. Users can now modify the lists of
SQL special characters, SQL keywords, cross-site scripting allowed tags,
and cross-site scripting allowed attributes used by the HTML and XML
SQL injection security check and the HTML and XML cross-site scripting
check. Users can create and upload multiple different lists, and designate
the list to be used on a per-profile basis.
For a summary of the new features and remaining unsupported features, see the
Citrix NetScaler 9.2 Release Notes.
iv Citrix Application Firewall Guide
Audience
This guide is intended for the following audience:
IT Managers. IT managers or other individuals responsible for managing
your network.
System Administrators. Any system administrators responsible for
managing your standalone Citrix Application Firewall, or your Citrix
NetScaler Application Accelerator or NetScaler appliance.
The concepts and tasks described in this guide require you to have a basic
understanding of networking and firewall concepts and terminology, the HTTP
protocol, HTML and XML Soap, and Web security.
This documentation uses the following formatting conventions.
Convention Meaning
Boldface Information that you type exactly as shown (user input);
elements in the user interface.
<Angl e Br acket s> Placeholders for information or parameters that you
provide. For example, <Fi l eName>in a command
means you type the actual name of a file. Also, new terms,
and words referred to as words (which would otherwise be
enclosed in quotation marks).
%SystemRoot% The Windows system directory, which can be WTSRV,
WINNT, WINDOWS, or any other name you specify when
you install Windows.
Monospace System output or characters in a command line. User input
and placeholders also are formatted using monspace text.
{ braces } A series of items, one of which is required in command
statements. For example, { yes | no } means you must type
yes or no. Do not type the braces themselves.
[ brackets ] Optional items in command statements. For example, in
the following command, [ - r ange
posi t i veI nt eger ] means that you have the option of
entering a range, but it is not required:
add lb vserver name serviceType IPAddress
port [-range positiveInteger]
Do not type the brackets themselves.
v
Related Documentation
A complete set of documentation is available on the Documentation tab of your
NetScaler and from http://support.citrix.com/. (Most of the documents require
Adobe Reader, available at http://adobe.com/.)
To view the documentation
1. From a Web browser, log on to the NetScaler.
2. Click the Documentation tab.
3. To view a short description of each document, hover your cursor over the
title. To open a document, click the title.
Getting Service and Support
Citrix offers a variety of resources for support with your Citrix environment,
including the following:
The Knowledge Center is a self-service, Web-based technical support
database that contains thousands of technical solutions, including access to
the latest hotfixes, service packs, and security bulletins.
Technical Support Programs for both software support and appliance
maintenance are available at a variety of support levels.
The Subscription Advantage program is a one-year membership that gives
you an easy way to stay current with the latest product version upgrades
and enhancements.
Citrix Education provides official training and certification programs on
virtually all Citrix products and technologies.
| (vertical bar) A separator between options in braces or brackets in
command statements. For example, the following indicates
that you choose one of the following load balancing
methods:
lbMethod = ( ROUNDROBIN | LEASTCONNECTION |
LEASTRESPONSETIME | URLHASH | DOMAINHASH |
DESTINATIONIPHASH | SOURCEIPHASH |
SRCIPDESTIPHASH | LEASTBANDWIDTH |
LEASTPACKETS | TOKEN | SRCIPSRCPORTHASH |
LRTM | CALLIDHASH | CUSTOMLOAD )
Convention Meaning
vi Citrix Application Firewall Guide
For detailed information about Citrix services and support, see the Citrix Systems
Support Web site at
http://www.citrix.com/lang/English/support.asp.
You can also participate in and follow technical discussions offered by the experts
on various Citrix products at the following sites:
http://community.citrix.com
http://twitter.com/citrixsupport
Documentation Feedback
You are encouraged to provide feedback and suggestions so that we can enhance
the documentation. You can send email to the following alias or aliases, as
appropriate. In the subject line, specify Documentation Feedback. Be sure to
include the document name, page number, and product release version.
For NetScaler documentation, send email to nsdoc_feedback@citrix.com.
For Command Center documentation, send email to
ccdocs_feedback@citrix.com.
For Access Gateway documentation, send email to
agdocs_feedback@citrix.com.
You can also provide feedback from the Knowledge Center at http://
support.citrix.com/.
To provide feedback from the Knowledge Center home page
1. Go to the Knowledge Center home page at http://support.citrix.com/.
2. On the Knowledge Center home page, under Products, expand NetScaler,
and then click the NetScaler release for which you want to provide
feedback.
3. On the Documentation tab, click the guide name, and then click Article
Feedback.
4. On the Documentation Feedback page, complete the form, and then click
Submit.
CHAPTER 1
Introduction
The Citrix Application Firewall prevents security breaches, data loss, and
possible unauthorized modifications to Web sites that access sensitive business or
customer information. It accomplishes this by filtering both requests and
responses, examining them for evidence of malicious activity and blocking those
that exhibit it.
To use the Application Firewall, you must configure at least one profile to tell it
what to do with the connections it filters, one policy to tell it which connections to
filter, and then associate the profile with the policy. You can configure an
arbitrary number of different profiles and policies to protect more complex Web
sites. You can adjust how the Application Firewall operates on all connections in
the Engine Settings. You can enable, disable, and adjust the setting of each
security check separately. Finally, you can configure and use the included PCI-
DSS report to assess your security configuration for compliance with PCI-DSS
standard.
You can configure the Application Firewall using either the Citrix NetScaler
Configuration Utility (configuration utility) or the Citrix NetScaler Command
Line Interface (NetScaler command line).
What is the Application Firewall?
The Application Firewall is a filter that sits between Web applications and users,
examining requests and responses and blocking dangerous or inappropriate
traffic. The Application Firewall protects Web servers and Web sites from
unauthorized access and misuse by hackers and malicious programs, such as
viruses and trojans (or malware). It provides protection against security
vulnerabilities in legacy CGI code or scripts, Web server software, and the
underlying operating system.
2 Citrix Application Firewall Guide
The Application Firewall is available on two platforms. First, the Citrix
Application Firewall is a standalone appliance based on the Citrix NetScaler
Application Accelerator platform and Citrix NetScaler Application Delivery
System operating system. Second, the Citrix NetScaler Application Firewall
feature is part of the Citrix NetScaler Application Delivery System, which runs
on all models of the Citrix NetScaler Application Accelerator or Citrix NetScaler
appliance. Therefore, users who want a dedicated Application Firewall can
purchase a standalone Citrix Application Firewall. Users who want the
Application Firewall functionality in addition to other NetScaler operating
system features can purchase a new Citrix NetScaler appliance, or upgrade to
version9.1 of the NetScaler operating system and install it on their existing
appliance appliance.
Note: Citrix also supports the Citrix Application Firewall EX, which is built on
a different hardware and operating system platform than the Application Firewall
discussed in this manual. The Citrix Application Firewall EX has its own separate
documentation set. This manual does not apply to the Citrix Application Firewall
EX. If you need to obtain the Citrix Application Firewall EX documentation,
contact Citrix Customer Support for further assistance.
What the Application Firewall Does
The Citrix Application Firewall protects Web servers and Web sites from misuse
by hackers and malware, such as viruses and trojans, by filtering traffic between
each protected Web server and users that connect to any Web site on that Web
server. The Application Firewall examines all traffic for evidence of attacks on
Web server security or misuse of Web server resources, and takes the appropriate
action to prevent these attacks from succeeding.
Most types of attacks against Web servers and Web sites are launched to
accomplish two overall goals. These are:
Obtaining private information. The Application Firewall watches for
attacks intended to obtain sensitive private information from your Web sites
and the databases that your Web sites can access. This information can
include customer names, addresses, phone numbers, social security num-
bers, credit card numbers, medical records, and other private information.
The hacker or malware author can then use this information directly, sell it
to others, or both.
Much of the information obtained by such attacks is protected by law, and
all of it by custom and expectation. A breach of this type can have
extremely serious consequences for customers whose private information
was compromised. At best, these customers will have to exercise vigilance
Chapter 1 Introduction 3
to prevent others from abusing their credit cards, opening unauthorized
credit accounts in their name, or appropriate the customers identity
outright to commit criminal activities in their name (or identity theft). At
worst, the customers may face ruined credit ratings or even be blamed for
criminal activities in which they had no part.
If a hacker or malware author manages to obtain such information through
your Web site and then misuses it, that can create an embarrassing situation
at best, and may expose your company to legal consequences.
Obtaining unauthorized access and control. The Application Firewall
watches for attacks intended to give the attacker access to and control of
your Web server without your knowledge or permission. This prevents
hackers from using your Web server to host unauthorized content, act as a
proxy for content hosted on another server, provide SMTP services to send
unsolicited bulk email, or provide DNS services to support these activities
on other compromised Web servers. Such activities constitute theft of your
server capacity and bandwidth for purposes you did not authorize.
By preventing unauthorized access to and control of your Web servers, the
Application Firewall also helps prevent the common practice of unautho-
rized modifications of your home page or other pages on your Web site (or
Web site defacement).
Most Web sites that are hosted on hacked Web servers (or compromised
Web servers) promote questionable or outright fraudulent businesses. For
example, the majority of pharming Web sites, phishing Web sites, and child
pornography Web sites (or CP Web sites) are hosted on compromised Web
servers. So are many sites that sell prescription medications without a
prescription, illegal OEM copies of copyrighted software, and untested and
often worthless quack medical remedies.
If a hacker or malware author manages to host such a Web site on your
companys Web server, or use your companys Web server to provide spam
support services, that can create an embarrassing incident at the very least.
Many types of attacks can be used to obtain private information from or make
unauthorized use of your Web servers. These attacks include:
Buffer overflow attacks. Sending an extremely long URL, cookie, or other
bit of information to a Web server in hopes of causing it or the underlying
operating system to hang, crash, or behave in some manner useful to the
attacker. A buffer overflow attack can be used to gain access to unautho-
rized information, to compromise a Web server, or both.
Cookie security attacks. Sending a modified cookie to a Web server, usu-
ally in hopes of obtaining access to unauthorized content using falsified
credentials.
Forceful browsing. Accessing URLs on a Web site directly, without navi-
gating to the URLs via hyperlinks on the home page or other common start
URLs on the Web site. Individual instances of forceful browsing may sim-
ply indicate a user who bookmarked a page on your Web site, but repeated
attempts to access non-existent content or content that users should never
access directly often represents an attack on Web site security. Forceful
browsing is normally used to gain access to unauthorized information, but
can also include a buffer overflow attack and be used to compromise your
server.
Web form security attacks. Sending inappropriate content to your Web
site using a Web form. Inappropriate content can include modified hidden
fields, HTML or code in a field intended for alphanumeric data only, a
overly long string in a field that accepts only a short string, an alphanumeric
string in a field that accepts only an integer, and a wide variety of other data
that your Web site does not expect to receive in that Web form. A Web form
security attack can be used either to obtain unauthorized information from
your Web site or to compromise the Web site outright, usually when com-
bined with a buffer overflow attack.
In addition to standard Web form security attacks, there are two specialized
types of attacks on Web form security that deserve special mention:
- SQL injection attacks. Sending an active SQL command or
commands using SQL special characters and keywords using a Web
form, with the goal of causing a back-end SQL database to execute
that command or commands. SQL injection attacks are normally used
to obtain unauthorized information.
- Cross-site scripting attacks. Using a script on a web page to violate
the same origin policy, which forbids any script from obtaining
properties from or modifying any content on a different Web site.
Since scripts can obtain information and modify files on your Web
site, allowing a script access to content on a different Web site can
provide an attacker the means to obtain unauthorized information, to
compromise a Web server, or both.
XML security attacks. Sending inappropriate content to an XML-based
application, or attempting to breach security on your XML-based applica-
tion. There are a number of special attacks that can be made against XML-
based applications using XML requests that contain malicious code or
objects. These include attacks based on badly-formed XML requests, or
XML requests that do not conform to the W3C XML specification, XML
requests used to stage a denial of service (DoS) attack, and on XML
requests that contain attached files that can breach site security.
In addition to standard XML-based attacks, there are two specialized types
of XML attacks that deserve special mention:
- SQL injection attacks. Sending an active SQL command or
commands using SQL special characters and keywords in a XML-
based request, with the goal of causing a back-end SQL database to
execute that command or commands. SQL injection attacks are
normally used to obtain unauthorized information.
- Cross-site scripting attacks. Using a script included in an XML-
based application to violate the same origin policy, which forbids any
script from obtaining properties from or modifying any content on a
different application. Since scripts can obtain information and modify
files using your XML application, allowing a script access to content
belonging to a different application can provide an attacker the means
to obtain unauthorized information, to compromise the application, or
both.
The Application Firewall has special filters, or checks, that look for each of these
types of attack and prevent them from succeeding. The checks use a range of
filters and techniques to detect each attack, and respond to different types of
attacks or potential attacks differently. A potential attack that does not pose a
significant threat may simply be logged. If the same pattern of activity does not
reoccur, it probably was not a deliberate attack and no further action was needed.
A series of potential attacks may require a different response, which may include
blocking further requests from that source.
The greatest threat against Web sites and applications does not come from known
attacks, however. It comes from new and unknown attacks, attacks for which the
Application Firewall may not yet have a specific check. For this reason, the core
Application Firewall methodology does not rely upon specific checks. It relies
upon comparing requests and responses to a profile of normal use of a protected
Web site or application. The user helps create the profile during initial
configuration and at intervals thereafter by providing certain information to the
Application Firewall. The Application Firewall then generates the rest of this
profile using its learning feature.
Thereafter, if a request or response falls outside of the profile for that Web site or
application, either the threat in the request or response is neutralized, or the
request or response is blocked. This is called a positive security model, and allows
the Application Firewall to protect a Web site or application against attacks for
which it may not yet have specific checks.
In summary, the Application Firewall prevents outsiders from misusing your Web
sites and applications for their own purposes. It ensures that your Web sites and
applications are used as you intended them to be used, for your benefit and that of
your customers.
The following section explains in more detail how the Application Firewall
performs these tasks.
How the Application Firewall Works
The Application Firewall protects your Web sites and applications by filtering
traffic to and from them, and blocking or rendering harmless any attacks or
threats that it detects. This subsection provides an outline of the filtering process
it uses to accomplish this.
The platform on which the Application Firewall is built is the Citrix NetScaler
Application Delivery product line, which can be installed as either a layer 3
network device or a layer 2 network bridge between your servers and your users,
usually behind your companys router or firewall. Depending on which
Application Firewall model you have and which other tasks it performs, you may
install it in different locations and configure it differently. To function, however,
an Application Firewall must be installed in a location where it can intercept
traffic between the Web servers you want to protect and the hub or switch through
which users access those Web servers. You then configure the network to send
requests to the Application Firewall instead of directly to your Web servers, and
responses to the Application Firewall instead of directly to your users.
The Application Firewall then filters that traffic before forwarding it to its final
destination. It examines each request or response using both its internal rule set
and your additions and modifications. In addition to profiling the Web servers it
protects using its learning feature, the Application Firewall also profiles each
specific users session in real time to determine if incoming traffic from that user
to your Web server, and outgoing traffic from your Web server to that user, is
appropriate in light of previous requests from the user during the current session.
It then blocks or renders harmless any that trigger a specific check or that fail to
match the Web site profile. The figure below provides an overview of the filtering
process.
A Flowchart of Application Firewall Filtering
As the figure shows, when a user requests a URL on a protected Web server, the
Application Firewall first examines the request to ensure that it violates no
network security rules. These rules check for DoS attacks and other types of
network attacks that are not specific to Web servers. Many of those attacks do not
require the same level of analysis to detect as many Web site or application
attacks do. Detecting and stopping these attacks before analyzing requests further
reduces overall load on the Application Firewall.
If the request passes network security inspection, the Application Firewall checks
to see if the request needs further filtering. Requests for certain types of content,
such as image files, do not require further analysis. Requests for HTML-based
web pages, XML-based applications, or active content do require further analysis,
and are passed to the Application Firewall filtering engine.
The Application Firewall then examines the request, applying all relevant checks
and comparing it to the profile it has of the protected Web site or XML
application. If the request passes the Application Firewall security checks, it is
passed to the Rewrite feature, which applies any Rewrite rules. Finally, the
Application Firewall passes the request on to the server.
The Web site or application sends its response back to the Application Firewall,
which examines the response. If the response does not violate any security
checks, it is passed to the Rewrite feature, which applies any Rewrite rules.
Finally, the Application Firewall forwards the response to the user. This process is
repeated for each request and response.
In summary, the Application Firewall filters HTTP traffic for security-related
issues at two points in the HTTP request/response cycle: it filters requests before
they are sent to the server, and responses before they are sent to the user. When it
detects a problem, it either neutralizes the problem or, if it cannot, blocks the
request or response.
The Application Firewall Platform
The Citrix Application Firewall is built on the NetScaler operating system
(NetScaler operating system) platform. It is fully integrated into the appliance
platform and interoperates cleanly with all other appliance features.
The appliance software runs on several types of hardware and a range of different
servers optimized for different levels and types of network traffic. All are
collectively referred to as the Citrix NetScaler Application Delivery product line.
As of the NetScaler operating system 8.0 release, the Application Firewall has
been available as a licensed feature. You can also purchase a standalone Citrix
Application Firewall based on the same platform.
For more information about the hardware platforms in the Citrix NetScaler
Application Delivery product line, see Installing the Server on page19. For
complete information about the Citrix NetScaler Application Delivery product
line, see the Citrix NetScaler Installation and Configuration Guide.
The Application Firewall on a Network
To do its work properly, any Application Firewall model must be installed in the
right place on your network. The location must allow traffic to and from your
protected Web servers to be routed through the Application Firewall. You can
ensure this by installing the Application Firewall in a location where traffic to and
from your Web servers must pass through it, or you can use virtual LANs
(VLANS) to ensure that your network can distinguish between packets that need
to be routed to the Application Firewall, and packets that the Application Firewall
has already filtered and that can be sent to the Web server or user, as appropriate.
Although the appliances in the Citrix NetScaler Application Delivery product line
are normally installed as a layer 3 devices, none of them acts like a traditional
layer 3 or layer 4 firewall when filtering traffic to and from your protected Web
servers. The Application Firewall itself analyzes only HTTP requests and
responses, and analyzes HTTP traffic at a different level than a traditional firewall
does. Therefore, only requests to your Web sites or applications that might
contain attacks are sent to the Application Firewall.
A NetScaler appliance must see and route other types of traffic than simply HTTP
connections because it will have multiple appliance features licensed and
enabled. Some of the other appliance features block DoS and DDoS attacks,
accelerate throughput to and from your applications, and provide secure access to
servers and applications. When installing a NetScaler appliance, you will
therefore need to determine the best location in light of all the features you plan to
use. The appliance OS then determines which packets need to be processed by the
Application Firewall and routes only those packets to it.
If you are installing or already use a NetScaler appliance and have licensed the
Application Firewall feature, you must first determine which other appliance
features you will use in addition to the Application Firewall. You should then
determine where on your network to install your NetScaler appliance so that it
can intercept all incoming traffic that it must process, and as little additional
traffic as possible.
The best solution will depend heavily on the configuration of your individual
network. Because a NetScaler appliance is a multipurpose appliance, you
probably will need to install it in a central location in your network, where it can
intercept much (if not all) traffic entering your network from the outside. You
may also not have the option of installing it within the same subnet as the servers
that host your protected Web sites or applications.
These factors will require some additional configuration of your NetScaler
appliance so that they can identify and properly route traffic to the Application
Firewall.
The User Interfaces
All models in the Citrix NetScaler Application Delivery product line can be
configured and managed from either of two different user interfaces: the
command line-based Citrix NetScaler Command Line Interface (the NetScaler
command line) and the web-based Citrix NetScaler Configuration Utility (the
configuration utility).
The Citrix NetScaler Command Line Interface
The Citrix NetScaler Command Line Interface (NetScaler command line) is a
modified UNIX shell based on the FreeBSD bash shell. To configure the
Application Firewall using the NetScaler command line, you type commands at
the prompt and press the Ent er key, just as you do with any other Unix shell.
Note: The actual appearance of the NetScaler command line window varies
somewhat depending on which SSH program you use to connect to the NetScaler
command line.
The format of NetScaler command line commands is:
> action groupname entity <ent i t yname> [ - par amet er ]
For act i on, you substitute the action you want to perform. For gr oupname, you
substitute the groupname associated with the feature or task. For ent i t y, you
substitute the specific type of object you are viewing or changing. For
<ent i t yname>, you substitute the IP, hostname, or other specific name for the
entity. Finally, for [ - par amet er ] , you substitute one or more parameters (if
any) that your command requires.
For example, you use the add appf i r ewal l pr of i l e command to create a
profile named HTML with basic defaults, as shown below.
> add appf i r ewal l pr of i l e HTML - def aul t s basi c
Done
>
In this command, add is the action; appf i r ewal l is the groupname; pr of i l e is
the entity; HTML is the <ent i t yname>; and - def aul t s basi c is the parameter.
Since the command produces no output, the NetScaler command line simply
informs you that it has performed the command by printing Done, and then
returns to the prompt.
You use the show appf i r ewal l pr of i l e command to review all profiles that
currently exist on your Application Firewall, as shown below:
> show appf w pr of i l e
3) Name: HTML1 Er r or URL: /
St r i pComment s: ON Def aul t Char Set : i so- 8859- 1
St ar t URLAct i on: bl ock l og st at s St ar t URLCl osur e: OFF
DenyURLAct i on: bl ock l og st at s XSSAct i on: bl ock l og st at s
XSSTr ansf or mUnsaf eHTML: OFF XSSCheckCompl et eURLs: OFF
SQLAct i on: bl ock l og st at s SQLTr ansf or mSpeci al Char s: OFF
SQLOnl yCheckFi el dsWi t hSQLChar s: ON Fi el dConsi st encyAct i on:
none
Cooki eConsi st encyAct i on: none Buf f er Over f l owAct i on: bl ock
l og st at s
Buf f er Over f l owMaxURLLengt h: 1024
Buf f er Over f l owMaxHeader Lengt h: 4096
Buf f er Over f l owMaxCooki eLengt h: 4096
Fi el dFor mat Act i on: bl ock l og st at s Def aul t Fi el dFor mat Type:
" "
Def aul t Fi el dFor mat Mi nLengt h: 0 Def aul t Fi el dFor mat MaxLengt h:
65535
Commer ceAct i on: bl ock l og st at s Commer ceCar d:
Commer ceMaxAl l owed: 0 Commer ceXOut : OFF
Done
>
Unlike the add appf i r ewal l pr of i l e command, this command has output,
and that output is displayed beneath the line where you typed the command. The
output terminates with Done, and beneath that, a new prompt is displayed.
Another useful command, the show conf i g command, lacks everything after
the groupname. It has no entity or parameters, as shown below.
> show conf i g
Net Scal er I P: 192. 168. 100. 42 ( mask: 255. 255. 255. 0)
Number of MappedI P( s) : 1
Node: St andal one
Gl obal conf i gur at i on set t i ngs:
HTTP por t ( s) : ( none)
Max connect i ons: 0
Max r equest s per connect i on: 0
Cl i ent I P i nser t i on: DI SABLED
Cooki e ver si on: 0
Mi n Pat h MTU: 576
Pat h MTU ent r y t i meout : 10
FTP Por t Range: 0
Done
>
You use the show conf i g command to determine the appliance IP and global
configuration settings. To determine the settings for any specific configuration
area, you use the show action with the appropriate groupname and entity, as you
did above to view the Application Firewall profile settings.
There are an enormous number of commands and variations available at the
NetScaler command line. A small number of these commands that you can use to
configure various parts of the Application Firewall are described in this manual.
For a complete description of the commands available at the NetScaler command
line, see the Citrix NetScaler Command Reference Guide.
The Citrix NetScaler Configuration Utility
The configuration utility is a web-based interface used to configure the
Application Firewall. You can perform almost any configuration task using the
configuration utility. Less experienced users usually find the configuration utility
the easiest interface to use.
The figure below shows the configuration utilitys System Overview screen.
The Citrix NetScaler Configuration Utility, System Overview
Note: The items displayed in the navigation tree on the left of the configuration
utility window differ depending on which features are licensed on your NetScaler
appliance.
The configuration utility screen has three areas that organize the work of
configuring all the features you licensed on your Citrix NetScaler Application
Accelerator or NetScaler appliance.
Logo bar. The logo bar extends along the top of the configuration utility
window. On the left the Citrix logo and Access Gateway Enterprise Edi-
tion title appear. On the right is a horizontal row of global hyperlinks that
allow you to control the look and feel of the configuration utility screen,
save your settings, do a complete refresh of the entire configuration utility
display, log out, and access the online help.
Navigation tree. The navigation tree extends down the left side of the
screen, and provides a collapsible menu that contains links to all screens in
the configuration utility. To navigate to a screen within a category, you
click the plus (+) sign to expand that category. When a submenu is open, the
plus sign changes to a minus (-) sign and all screens and subcategories
within that category are displayed.
- To display a category or subcategory, you click the plus sign beside
the category or subcategory title.
- To collapse a category or subcategory that has been displayed, you
click the minus sign beside the title of that category.
Page Title bar. The page title bar extends horizontally across the screen,
directly beneath the logo bar and to the right of the navigation menu. It con-
tains the title of the current page, and on the right a button that allows you
to refresh just that page.
Page Data area. The page data area contains the information for the page
you have displayed at the time. If the data area contains more information
that can easily be fit on one page, it may have multiple pages that you
access by clicking tabs at the top of the data area. For example, the System
Overview screen shown in the screen shot titled The Citrix NetScaler Con-
figuration Utility, System Overview on page12 has two tabs: the System
Information and System Sessions tabs.
Note: The data area on most pages in the configuration utility is read-
only. To add a configuration entry or modify an existing configuration
entry, you normally click the appropriate button at the bottom of the data
area and use the dialog box that appears to make your changes.
In addition to the main screens, the configuration utility makes considerable use
of wizards and other types of dialog boxes. A dialog box is a standalone window
that asks you a question or prompts you to fill in a form that asks for a set of
related data points. You click a button at the bottom or the right of the dialog box
to respond to the question (usually a Yes or No button) or to indicate that youve
finished filling in the form (usually an OK or Cancel button).
Wizards organize a related set of tasks in a logical workflow, displaying each task
on a separate page and prompting you to perform that task before you proceed to
the next task. The pages within a wizard also contain short explanations of what
each task is for and what it does.
To use the a wizard, you simply follow the instructions on each page, and when
you have finished, click the Next > button to proceed to the next page and next
task. If at any point, you need to change a setting you made on a previous page,
you can click the < Back button to return to that page and modify your work.
Then, you click the Next > button to return to the task you were completing
previously.
You are likely to encounter two wizards quickly: the Setup Wizard and Upgrade
Wizard. The figure below shows the first screen of the Setup Wizard.
The Setup Wizard, First Screen
The Setup Wizard takes you through the process of initial configuration of your
NetScaler appliance, prompting you for the necessary information at each step.
The Setup Wizard and other wizards in the configuration utility can make the
sometimes-daunting job of configuring a new NetScaler appliance much easier.
The figure below shows the first screen of the Upgrade Wizard.
The Upgrade Wizard, First Screen
The Upgrade Wizard, like the Setup Wizard, takes you through a set of screens.
Instead of performing an initial configuration, however, it takes you through the
process of upgrading your NetScaler appliance, prompting you for the necessary
information at each step.
This concludes the current chapter.
If you are installing a new Citrix NetScaler appliance, proceed to Chapter 2,
Installation, on page17.
If you are upgrading the NetScaler operating system on a Citrix NetScaler
appliance that you already own, and want to enable and configure the Citrix
NetScaler Application Firewall feature, proceed directly to Chapter 3,
Simple Configuration, on page65.
CHAPTER 2
Installation
This chapter contains basic installation instructions for two types of system:
The standalone Citrix Application Firewall, built on the Citrix NetScaler
platform.
Any appliance in the Citrix NetScaler Application Delivery product line
that runs the Citrix NetScaler Application Firewall feature.
Note: If you already have a NetScaler appliance installed on your network,
have just upgraded to the NetScaler 9.1 release, and have licensed the Citrix
NetScaler Application Firewall feature, you do not need to read this chapter. Your
appliance is already installed and has already had initial configuration performed
on it. Skip to Chapter 3, Simple Configuration, on page65.
The first section provides a detailed look at all of the hardware platforms (or
appliances) on which the standalone or embedded Application Firewall runs,
shows where ports and other important features are located on each unit, and
explains what you must do to get the appliance properly installed on your
network. The second section describes what you must do to perform initial
configuration of the NetScaler operating system.
When you have finished installing the appliance and performing initial
configuration, your appliance will be ready for you to configure the Application
Firewall itself.
Planning the Installation
The Citrix NetScaler Application Delivery product line supports a wide range of
installation modes, depending on which NetScaler features you will use and how
your network is set up. This section provides instructions for installing a
standalone Citrix Application Firewall, or for performing a simple installation of
a single Citrix NetScaler appliance. For more detailed information about a wider
range of available configurations, including high availability (HA) pairs and SSL
VPN, see the Installation and Configuration Guide, Volume 1, Chapter 2,
Installing the Application Switch.
The NetScaler appliance can be installed with a single connection via one hub or
switch to your network (called one-arm mode), or with two connections to
different hubs or switches to two different subnets (called two-arm mode). The
following figure provides a conceptual illustration of both modes.
Citrix NetScaler appliance Installation Modes
Each installation mode has its advantages. With a one-arm mode installation, you
do not have to worry about complex webs of connections. You simply connect the
appliance and the Web servers it protects to a single layer 2 switch, and set up
VLANs to handle routing. With a two-arm mode installation, however, the
appliance is physically located between the Web servers it protects and your
users. Connections must pass through it, minimizing chances that a route can be
found around it. This may enhance security.
You must also consider whether to install the appliance on the same subnet as the
Web servers it protects, or on a different subnet from some or all of them. In a
single subnet networking environment, the appliances IP address, mapped IP
address (MIP) and the IP address of all servers the Application Firewall manages
are on the same subnet. Installation on a single subnet is easier to configure, but
may require more work overall if the Web servers you want to protect are
currently on different subnets or are installed on a subnet which cannot
accommodate the appliance.
Router
Application Firewall
Protected
Web Servers Protected
Web Servers
Layer 2
Switch
Layer 2
Switch
Layer 2
Switch
One-Arm Mode Two-Arm Mode
Router
Chapter 2 Installation 19
In a multiple subnet networking environment, the appliances IP address, mapped
IP address (MIP), and the IP addresses of the servers it connects to are on two or
more subnets. Installation on multiple subnets may require that you add static
routes and make other configuration adjustments to ensure that the appliance and
the servers it manages are able to connect to each other correctly, and that
incoming traffic to a managed server goes through the NetScaler appliance before
being sent to the managed server.
There is no single right configuration for installations. You should review your
network and decide where to install your appliance based on which features you
will enable and which servers it will manage. Once you have decided where to
install your appliance and how to connect it to your net, you can proceed with the
installation.
Installing the Server
This section describes how to install your NetScaler appliance in your server
room. It describes the hardware platforms on which these servers are built, and
tells you how to operate each unit properly.
As of the current release, the hardware platforms on which all models in the
Citrix NetScaler Application Delivery product line are available are the Citrix
NetScaler 7000, the Citrix NetScaler 9000, the Citrix NetScaler 9010, the Citrix
NetScaler 10000, the Citrix NetScaler 10010, the Citrix NetScaler 12000, the
Citrix NetScaler MPX 15000, and the Citrix NetScaler MPX 17000. The
Application Firewall can be licensed on any of these hardware platforms as part
of any model of the NetScaler appliance. The standalone Citrix Application
Firewall is available on the Citrix NetScaler 7000 and the Citrix NetScaler 12000
platforms.
Before installing your appliance, you must first determine which hardware
platform your Application Firewall uses.
Citrix NetScaler 7000. If you are installing unit built on the 7000 platform,
proceed to The Citrix NetScaler 7000 on page20.
Citrix NetScaler 9010. If you are installing a unit built on the 9010 plat-
form, proceed to The Citrix NetScaler 9010 on page22.
Citrix NetScaler MPX 15000. If you are installing a unit built on the
15000 platform, proceed to The Citrix NetScaler MPX 15000 on page33.
Citrix NetScaler MPX 17000. If you are installing a unit built on the
17000 platform, proceed to The Citrix NetScaler MPX 15000 on page33.
The Citrix NetScaler 7000
The Citrix NetScaler 7000 model is a single processor, 1U unit that supports both
Fast Ethernet and copper Gigabit Ethernet. The unit ships with 1 GB of memory
by default. The 7000 handles up to 50,000 HTTP requests per second and up to
4,400 SSL transactions per second. It has a system throughput of 600 Mbps, and
SSL and compression throughputs of 150 Mbps.
The figure below contains a drawing of the 7000 as seen from the front, with
ports and important features labeled.
The Citrix NetScaler 7000, From the Front
You use the handles to carry the unit. You mount the unit onto your server room
rack and screw the rack mounts to the rack using standard rack-mount screws.
The LCD display consists of two lines of 16 characters each, a neon backlight,
and a screen refresh rate of 3 seconds. It provides real-time information about the
units state and activity in sequential screens with real-time statistics, diagnostic
information and active alerts. For more information about the LCD and how to
configure it, see the Citrix NetScaler Hardware Installation and Setup Guide.
The Citrix NetScaler 7000 has the following ports on the front of the unit:
Four 10/100Base-T network interfaces (labeled 1/1, 1/2, 1/3, and 1/4)
Two 10/100/1000Base-T network interfaces (labeled 1/5 and 1/6)
Serial port (9600 baud, 8 bits, 1 stop bit, No parity)
You can use the serial port to connect a notebook computer directly to the unit
using the supplied serial cable, as described in Using the Configuration Utility,
on page40.
The figure below shows a drawing of the 7000 from the back, with important
features labeled.
The Citrix NetScaler 7000, From the Back
To plug in the 7000, simply insert the supplied power cord into the power supply,
and plug the other end into an appropriately grounded outlet. To power down the
7000, you should first execute a controlled shutdown via the CLI or GUI. Then,
press the main power supply switch on the rear right-hand side of the unit to
switch the unit off.
Before you install the 7000, ensure that you have the following items available:
The power cord and serial cable, which are supplied with the 7000.
One to four ethernet cables, which are not supplied with the unit.
Four rack screws and a screwdriver.
You are now ready to install the 7000.
To install the Citrix NetScaler 7000 in your server room
1. Open the packing box the appliance arrive d in, and lift the appliance
carefully out of the box.
Caution: Handle the appliance with care. Like all servers, it is sensitive
to sudden jolts and shaking. Do not stack appliances on top of one another.
2. Place the appliance on an open rack in your server room, or in a temporary
location with easy access for initial configuration.
If you are installing the appliance on your server room rack, you should
install it in an open rack. If you must install the unit in an enclosed rack,
ensure that the rack has adequate temperature control, and that nothing
blocks the vents on the front or rear of the appliance.
Use four rack screws to secure the unit to the rack.
Power Supply Fan
Hard Disk Power Switch
Second Power Switch
Compact Flash
Drive and Release Button
3. Plug the power cord into the back of the appliance, and then plug the other
end into a standard 110V/220V power outlet.
Caution: The unit must be connected to a properly grounded and
regulated power source. Like all servers, it is sensitive to power
fluctuations.
4. Turn on the appliance by tapping the power switch quickly, and then letting
up.
The appliance will perform a series of power-on tests that take
approximately a minute as it comes up.
You have now successfully installed your Citrix NetScaler 7000. Proceed to
Performing Initial Configuration, on page39 to configure it.
The Citrix NetScaler 9010 is a single processor, 2U unit that ships with 2 GB of
memory. The user can specify either four fiber Gigabit 1000Base-X optical
ethernet ports (fiber version) or four 10/100/1000Base-T copper ethernet ports
(copper version) when ordering the unit. The 9010 can process up to 125,000
HTTP requests per second and 4,400 SSL requests per second. It has 2,000 Mbps
system throughput, 500 Mbps SSL throughput, and 400 Mbps compression
throughput.
The figure below shows a drawing of the 9010 (fiber version) as seen from the
front, with ports and important features labeled clearly.
The Citrix NetScaler 9010 (fiber version), From the Front
The 9010 (fiber version) has the following ports on the front:
Four Optical
1000base-X
Ethernet Ports
RS232
Serial Port
LCD Display
Rack mounts
Handle
to carry
the unit.
Handle
to carry
the unit.
Four fiber Gigabit 1000-Base-X optical network interfaces, labeled 1/1, 1/
2, 1/3, and 1/4.
When facing the bezel, the upper LEDs to the left of each port inset represent
connectivity. They are lit and amber in color when active. The lower LEDs
represent throughput. They are lit and green when active.
The figure below shows a drawing of the 9010 (copper version) as seen from the
front, with ports and important features labeled clearly.
The Citrix NetScaler 9010 (copper version), From the Front
The 9010 (copper version) has the following ports on the front:
Four 10/100/1000-Base-T copper ethernet network interfaces, labeled 1/1,
1/2, 1/3, and 1/4.
For both 9010 versions, you use the handles to carry the unit. You mount the unit
onto your server room rack and screw the rack mounts to the rack using standard
rack-mount screws.
The LCD display on both versions consists of two lines of 16 characters each, a
neon backlight, and a screen refresh rate of 3 seconds. It provides real-time
information about the units state and activity in sequential screens with real-time
statistics, diagnostic information and active alerts. For more information about
the LCD and how to configure it, see the Citrix NetScaler Hardware Installation
and Setup Guide.
using the supplied serial cable. The figure below shows the 9010 from the back,
with ports and important features clearly labeled.
Four
10/100/1000base-T
Copper Ethernet Ports
RS232
Serial Port
LCD Display
Rack mounts
Handle
to carry
the unit.
Handle
to carry
the unit.
To power the unit off, you press the left side of the power switch until it clicks
down. To power it on, you press the right side until it clicks down.
You can use the 10/100/1000Base-T copper ethernet port to connect the unit to a
secure control network that you then use to configure and manage the unit. The
compact flash drive contains the NetScaler operating system (OS) software. The
hard disk can be used to store logs and backups.
The appliance has two power supplies. Normally you will want to plug two power
cords, one into each power supply and then into separate wall sockets. The unit
functions properly with only one working power supply, however; the extra
power supply serves as a fail-safe precaution.
In the event that one power supply fails, or if you choose to connect only one
power cord to the unit, an alarm sounds. You push the Disable Alarm button to
silence the alarm.
Caution: If you choose to continue operating the 9010 with only one
functioning or one connected power supply, you forfeit the built-in fail-safe
protection.
If you are installing a 9010 (fiber version), four Finisar Active Copper SFP
transceivers, which are also supplied with the appliance.
Two removable
power supplies
Hard disk
Power
switch
Non-maskeable interrupt
(NMI) button
Compact flash
drive and release button
10/100Base-T
copper Ethernet port
Disable alarm button
1. Open the packing box the appliance arrived in, and lift the appliance
Plug the power cord into the back of the appliance, and then plug the other
fluctuations.
up.
4. Take an ethernet cable, connect one end to interface number 1/4 and
connect the other end to the switch or hub that leads to your WAN or the
internet.
If you want, you can use a different interface number. The appliance detects
which interfaces are in use and which networks they are connected to
automatically.
5. If you are installing your appliance in two-arm mode, take another ethernet
cable, connect one end to interface number 1/3, and connect the other end
to the switch or hub that leads to your LAN.
Again, if you want, you can use a different interface number.
The Citrix NetScaler 10010 is a single processor, 2U unit that ships with 2 GB of
memory, four fiber Gigabit 1000Base-X optical ethernet ports, and four 10/100/
1000Base-T copper ethernet ports by default. The unit can process up to 255,000
HTTP requests per second and 8,800 SSL requests per second. It has 4,800 Mbps
system throughput, 760 Mbps SSL throughput, and 555 Mbps compression
throughput.
The following figure shows a drawing of the 10010 as seen from the front, with
ports and other important features clearly labeled.
The 10010 has the following ports on the front:
Four fiber Gigabit 1000-Base-X optical network interfaces, labeled 1/1, 1/
2, 1/3, and 1/4.
Four 10/100/1000-Base-T copper ethernet network interfaces, labeled 1/5,
1/6, 1/7, and 1/8.
Serial port (9600 baud, 8 bits, 1 stop bit, No parity).
When facing the bezel, the upper LEDs to the left of each fiber port represent
connectivity. They are lit and amber in color when active. The lower LEDs
represent throughput. They are lit and green when active.
Four gigabit
SFP ports
Four
10/100/1000Base-T
copper Ethernet ports
RS232
serial console
port
LCD display
Rack mounts
Handle
to carry
the unit
Handle
to carry
the unit
If you choose, you can convert the 1000Base-X ports on the unit to 10/100/
1000Base-T ports using the Finisar Active Copper SFP transceiver. The
following figure shows examples of the transceivers, and how they plug into the
1000base-X ports to convert them to copper ethernet ports.
The Citrix NetScaler 10010, From the Front, Details
To insert a transceiver into a 1000Base-X port, you must first lower the
transceiver lock bar into its unlocked position. You next insert the transceiver into
the port, and press firmly until it clicks into place. Finally, you raise the lock bar
to its up/locked position, and plug an ethernet cable into the port.
Note: If you do not insert and lock the transceiver correctly, you will be unable
to plug an ethernet cable into the port.
using the supplied serial cable. For more information on how to do this, see To
log on to the NetScaler command line via the serial port on page58.
The following figure shows the 10010 from the back, with ports and important
features clearly labeled.
Finisar Active Copper SFP Transceivers
Plugged in and locked in place.
Transceiver unlocked position
from side
Transceiver locked position
from side
The unit has two power supplies. Normally you will want to plug two power
silence the alarm.
protection.
Four Finisar Active Copper SFP transceivers, which are also supplied with
the appliance.
Two removable
power supplies
Hard disk
Power
switch
(NMI) button
Compact flash
10/100Base-T
fluctuations.
up.
5. Take an ethernet cable, connect one end to interface number 1/8 and
connect the other end to the switch or hub that leads to your WAN or the
internet.
automatically.
6. If you are installing your appliance in two-arm mode, take another ethernet
cable, connect one end to interface number 1/7, and connect the other end
to the switch or hub that leads to your LAN.
The Citrix NetScaler 12000 is a high-capacity, fault-tolerant hardware platform
intended for heavy use in enterprise environments. The unit is a double form
factor (2U) rack-mountable unit, 24 in/61 cm deep, that weighs 52 lbs/24 kg. It is
designed to be installed on a rack in an air-conditioned server room.
The unit can process up to 275,000 HTTP requests per second and 28,000 SSL
requests per second. It has 6,000 Mbps system throughput, 3,000 Mbps SSL
throughput, and 1,300 Mbps compression throughput.
The following figure shows the 12000 unit from the front, with ports and other
important features clearly labeled.
configure it, see the Installation and Configuration Guide, Volume 1, Chapter 3,
Configuring the Application Switch, Understanding the LCD Monitor, on
page 3-13.
using the supplied serial cable, as described in To log on to the NetScaler
command line via the serial port on page58.
The following figure shows examples of the Finisar Active Copper SFP
transceivers, and how they plug into the 1000base-X ports.
Eight Gigabit SFP Ports
RS232
serial console
port
LCD display
Rack mounts
Handle
to carry
the unit
Handle
to carry
the unit
1/1 1/2 1/3 1/4 1/5 1/6 1/7 1/8
The Citrix NetScaler 12000, From the Front, Details
To insert a transceiver into a 1000Base-X port, you must first lower the
transceiver lock bar into its unlocked position. You next insert the transceiver into
the port, and press firmly until it clicks into place. Finally, you raise the lock bar
to its up/locked position, and plug an ethernet cable into the port.
Note: If you do not insert and lock the transceiver correctly, you will be unable
to plug an ethernet cable into the port.
The following figure shows the back of the 12000, with ports and other important
Finisar Active Copper SFP Transceivers
Plugged in and locked in place.
Transceiver unlocked position
from side
Transceiver locked position
from side
Two removable
power supplies
Hard disk
Power
switch
(NMI) button
Compact flash
10/100Base-T
silence the alarm.
protection.
Eight Finisar Active Copper SFP transceivers, which are also supplied with
the appliance.
One to eight ethernet cables, which are not supplied with the unit.
fluctuations.
up.
5. Take a Finisar transceiver and an ethernet cable, insert the transceiver into
interface number 1/8, and connect the cable to that interface.
automatically.
6. Connect the other end to a hub or switch that connects to your network.
7. If you are installing your appliance in two-arm mode, repeat the previous
two steps, connecting a cable from interface 1/7 to another hub or switch
that connects to a different part of your network.
The Citrix NetScaler MPX 15000
The Citrix NetScaler MPX 15000 is a high-capacity, fault-tolerant hardware
platform intended for heavy use in enterprise environments. The unit is a double
form factor (2U) rack-mountable unit, 18.5 in/47 cm deep, that weighs 52 lbs/24
kg. It is designed to be installed on a rack in an air-conditioned server room.
The Citrix NetScaler MPX 15000, From the Front
You can use the RS232 serial console port to connect a notebook computer
directly to the unit using the supplied serial cable, as described in To log on to
the NetScaler command line via the serial port on page58.
You use the 10/100/1000Base-T copper ethernet MGMT port to connect the unit
to a secure control network that you then use to configure and manage the unit.
The 15000 has 8 Gigabit SFP ports, and two 10 Gigabit XFP ports. You convert
the SFP ports to either 10/100/1000Base-T copper Ethernet ports or 1 GB Fiber
ports using the appropriate transceivers, included with the unit. You convert the
XFP ports to 10 GB fiber ports using the XFP transceivers included with the unit.
Eight
1000Base-X
SFP ports
Two 10G
XFP ports
RS232
Serial
console port
LCD display 1000Base-T
MGMT port
Rack mounts
Handle
to carry
the unit
Handle
to carry
the unit
The Citrix NetScaler MPX 15000, From the Back
The compact flash drive contains the NetScaler operating system (OS) software.
The hard disk can be used to store logs and backups.
protection.
Eight Finisar Active Copper SFP transceivers or eight Finisar SFP Fiber
transceivers, which are supplied with the 15000.
Two Finisar XFP Fiber transceivers, which are supplied with the 15000.
One to eight network cables of the appropriate type, which are not supplied
with the unit.
To install the Citrix NetScaler MPX 15000 in your server room
1. Open the packing box the 15000 arrived in, and lift the appliance carefully
out of the box.
Power supplies
with fan
Removable compact flash
2. Place the 15000 on an open rack in your server room, or in a temporary
fluctuations.
4. Take a transceiver and a network cable, insert the transceiver into interface
number 1/8, and connect the cable to that interface.
If you want, you can use a different interface number. The 15000 detects
automatically.
6. If you are installing your 15000 in two-arm mode, repeat the previous two
steps, connecting a cable from interface 1/7 to another hub or switch that
connects to a different part of your network.
You have now successfully installed your Citrix NetScaler MPX 15000. Proceed
to Performing Initial Configuration, on page39 to configure it.
The Citrix NetScaler MPX 17000
The Citrix NetScaler MPX 17000 is a high-capacity, fault-tolerant hardware
platform intended for heavy use in enterprise environments. The unit is a double
form factor (2U) rack-mountable unit, 18.5 in/47 cm deep, that weighs 52 lbs/24
kg. It is designed to be installed on a rack in an air-conditioned server room.
The Citrix NetScaler MPX 17000, Four Port Model, From the Front
You use the handles to carry the 17000. You mount the appliance onto your server
room rack and screw the rack mounts to the rack using standard rack-mount
screws.
You can use the RS232 serial console port to connect a notebook computer
directly to the unit using the supplied serial cable, as described in To log on to
the NetScaler command line via the serial port on page58.
You use the 10/100/1000Base-T copper ethernet MGMT port to connect the
17000 to a secure control network that you then use to configure and manage the
appliance.
Depending upon which model of the 17000 you have, the appliance has the
following network ports:
The 17000, four port model, has four 10 Gigabit XFP ports. You convert
these XFP ports to 10 GB fiber ports using the XFP transceivers included
with the unit.
The 17000, ten port model, has two 10 Gigabit XFP ports and eight 1 Giga-
bit SFP ports. You convert the SFP ports to either 10/100/1000Base-T cop-
per Ethernet ports or 1 GB Fiber ports using the appropriate transceivers,
included with the unit. You convert the XFP ports to 10 GB fiber ports
using the XFP transceivers included with the unit.
Four 10G
XFP ports
RS232
Serial
console port
LCD display
Rack mounts
Handle
to carry
the unit
Handle
to carry
the unit
1000Base-T
MGMT port
The Citrix NetScaler MPX 17000, From the Back
The compact flash drive contains the NetScaler operating system (OS) software.
The hard disk can be used to store logs and backups.
protection.
If you are installing the 17000, ten port model, eight Finisar Active Copper
SFP transceivers or eight Finisar SFP Fiber transceivers and two Finisar
XFP Fiber transceivers, which are all supplied with the 17000.
If you are installing the 17000, ten port model, four Finisar XFP Fiber
transceivers, which are supplied with the 17000.
One to ten network cables of the appropriate type, which are not supplied
with the unit.
To install the Citrix NetScaler MPX 17000 in your server room
1. Open the packing box the 17000 arrived in, and lift the appliance carefully
out of the box.
Power supplies
with fan
Removable compact flash
2. Place the 17000 on an open rack in your server room, or in a temporary
fluctuations.
4. Take a transceiver and a network cable, insert the transceiver into interface
number 1/8, and connect the cable to that interface.
If you want, you can use a different interface number. The 17000 detects
automatically.
6. If you are installing your 17000 in two-arm mode, repeat the previous two
steps, connecting a cable from interface 1/7 to another hub or switch that
connects to a different part of your network.
You have now successfully installed your Citrix NetScaler MPX 17000. Proceed
to Performing Initial Configuration, on page39 to configure it.
Performing Initial Configuration
After you have installed your Citrix Application Firewall or Citrix NetScaler
appliance in your server room, you must log on and perform initial configuration,
so that the appliance can properly connect to other network devices and they can
connect to the appliance.
If you want to configure your appliance using the Citrix NetScaler Configu-
ration Utility, proceed to Using the Configuration Utility.
If you want to configure your appliance using the NetScaler command line,
proceed to Using the Citrix NetScaler Command Line Interface, on
page58.
Using the Configuration Utility
This section describes how to log on to the Citrix NetScaler Configuration Utility
and use it to perform initial configuration of a new Citrix NetScaler appliance.
Most system administrators prefer to configure the NetScaler appliance using the
Citrix NetScaler Configuration Utility (configuration utility), a J ava-based GUI
client.
Logging On to the Configuration Utility
This section describes how to log on to the configuration utility for the first time.
For those who prefer to install the configuration utility applet on their desktop, it
also describes how to do so.
To log on to the configuration utility
1. Run the web browser of your choice, and open the following URL:
ht t p: / / 192. 168. 100. 1/
Note: The NetScaler operating system is preconfigured with a default IP
address and associated netmask to allow you to access it to configure it. The
default IP is 192.168.100.1 and the default netmask is 255.255.0.0.
The Citrix NetScaler Web Logon screen is displayed, as shown below.
The Citrix NetScaler Web Logon Screen
2. In the User Name text box, type the initial user name assigned to your
NetScaler appliance, and in the Password text box, type the initial
password.
You can obtain the initial user name and password from your sales
representative or from Citrix Customer Support.
Note: You do not need to change the setting in the System window.
3. Click the Login button to log on.
The logon screen disappears, and the default Citrix NetScaler home page
appears, as shown below.
The Citrix NetScaler Home Page, Monitoring Screen
4. In the menu bar on the upper right part of the home page, click the
Configuration link to display the System Configuration page, shown below.
The Citrix NetScaler Configuration Page
The Configuration page provides links to the two different versions of the
Citrix NetScaler Configuration Utility: the Applet Client, and the Web Start
Client. Both utilities require that you have the Sun Microsystems J ava
Client, version 1.5 or above, installed on your workstation.
5. Install the Citrix NetScaler Configuration Utility on your workstation.
You can install the Applet client.
A. Click the Applet Client link to the right of the Configuration
Utility label.
The Sun Microsystems J ava logo is displayed as the applet
downloads from the NetScaler appliance and loads into
memory. After it has loaded, the applet configuration utility
opening screen appears, shown below.
The Applet Configuration Utility Opening Screen
You can install the Web Start client.
A. Click the Web Start Client link to the right of the Applet Client
link.
Windows prompts you to open the web start client script, as
shown below.
The Windows Web Start Client Prompt
B. If the Open With radio button is not already selected, click it to tell
Windows to open the web start client script using the J ava engine.
C. Click the OK button.
J ava starts up, and displays a splash screen. The configuration utility
logon screen is then opened in a separate window. as shown below.
The Citrix NetScaler Configuration Utility Logon Screen
D. Type the logon in the User Name text box, type the password in the
Password text box, and click the OK button to log on.
You are logged on, and the configuration utility Setup wizard is
displayed, shown below.
The Configuration Utility Setup Wizard
An icon for the configuration utility is also installed on your
Windows desktop. In the future, you click the icon to load the
configuration utility and display the logon screen.
You have successfully logged onto the configuration utility. You must now
perform initial configuration of your NetScaler appliance.
Initial Configuration using the Configuration Utility
This section describes how to perform initial configuration of your NetScaler
appliance using the configuration utility Setup Wizard. The underlying operating
system of these servers is the same, and the process of initial configuration is also
the same.
Note: In all procedures that explain how to perform tasks using the
configuration utility, the Web Start client is shown in screenshots that illustrate
different steps. It differs from the Applet client only in that the Applet client
appears inside a web browser window. In all other respects, they are identical.
To configure the NetScaler operating system using the Setup Wizard
1. If you have not already done so, log onto the configuration utility.
For instructions, see To log on to the configuration utility on page40.
The opening screen of the Setup Wizard should be displayed after you
install the utility.
2. Click the Next > button to display the Network Config page, shown below,
and begin configuration.
The Setup Wizard, Network Config Page
3. Complete the Network Config page.
A. In the NetScaler IP Address Configuration area, IP Address field,
enter the IP address you will use as the NSIP.
The NSIP is the management IP you will use to connect to and
configure your appliance. It replaces the default IP
(192. 168. 100. 1) that you used to connect to the appliance and
install the configuration utility. You should choose a non-routable IP
on your company LAN for this IP, to prevent an attacker that
breaches your other defenses from being able to send packets to the
appliance.
B. In the Netmask field, enter the netmask for the NSIP.
C. In the Gateway field, enter the default gateway for the NSIP.
D. Enter an appropriate hostname in the Hostname field.
If a hostname is assigned to your Application Firewall in your
company DNS, enter that hostname.
If no hostname is assigned to your Application Firewall in
DNS, enter an appropriate hostname that is not assigned to
another host.
E. In the MIP/SNP Configuration area, IP Address field, select MIP
(mapped IP) or SNP (subnet IP), and then fill in the IP.
If you selected MIP, enter an IP address to be used as an MIP.
An MIP is the logical IP address used to communicate with
back-end services, such as your protected Web servers.
If you selected SNP, enter an IP address within the same subnet
as the NSIP.
F. In the Netmask field, enter the netmask for the MIP or SNIP.
4. Click the Next > button to display the Choose Application page, shown
below.
The Setup Wizard, Choose Application Page
5. Click the Next > button to choose, Skip this step, and proceed to the
summary page, shown below.
The Setup Wizard, Summary Page
6. Review your configuration choices.
If any choices are mistaken, use the < Back button to navigate back to the
appropriate page and make the necessary changes.
7. When you are satisfied with the configuration, click the Finish button to
save your changes in the NetScaler configuration file.
The Setup Wizard Summary page notifies you that your changes were
successfully written to nonvolatile memory.
8. Click the Exit button to close the Setup Wizard and return to the main
configuration utility screen.
If your NetScaler appliance does not already have the necessary licenses installed
on it, you must next install those licenses.
Note: Before you perform the following procedure, you must make sure that
the licenses that you received from Citrix Customer Support or your reseller have
been placed on a local or networked drive that is accessible from your NetScaler
appliance.
To install licenses by using the using the configuration utility
1. In the Menu tree, click the System entry to display the System Settings
Overview page, as shown below.
The System Licenses Page
2. Click the Manage Licenses button to display the Manage Licenses dialog
box, shown below.
The Manage Licenses Dialog Box
3. Click the Add button to display the Select Licenses browse dialog, and
navigate to and select the licenses you want to install.
4. Click the Select button to install the selected licenses.
You may also need to enable the Application Firewall feature.
To enable the Application Firewall by using the configuration utility
1. In the Menu tree, click the System entry to display the System Settings
Overview page, as shown below.
The Configuration Utility, System Settings Overview Page
The page contains a series of sections that contain hyperlinks to various
configuration details.
2. In the Modes & Features section, click the Change Basic Features
hyperlink to display the Configure Basic Features dialog box, shown below.
The Configure Basic Features Dialog Box
3. If it is not already selected, select the Application Firewall check box at the
bottom of the list.
4. Click the OK button in the lower lefthand corner of the data area.
The screen refreshes, and the Application Firewall entry is now checked.
Finally, you need to finish initial configuration of your Application Firewall by
configuring a server, a service, and a virtual server to handle traffic to your
protected web servers.
To complete initial configuration of the Application Firewall by using the
configuration utility
1. In the Menu tree, click the Load Balancing entry, then the Servers page,
shown below, and create a server.
The Load Balancing Servers Page
A. In the lower left-hand corner of the data area, click the Add button.
The Create Server dialog box appears, shown below.
The Create Server Dialog Box
B. Type a name for your server in the Server Name text box.
The name can begin with a letter, number, or the underscore symbol,
and can consist of from one to 127 letters, numbers, and the hyphen
(- ), period (. ) pound (#), space ( ), at sign (@), equals (=), colon (:),
and underscore (_) symbols.
C. Type the IP address or FQDN of your first protected Web server in
the IP Address/Domain Name text box.
D. Click the Create button to create the server.
Your new server appears in the servers list.
E. Repeat stepsa through d to create a new server configuration for each
of your Web servers.
F. Click the Close button to close the Create Server dialog box and
return to the Servers page.
2. Click the Services entry to display the Services page, shown below, and
create a service.
The Load Balancing Services Page
A. In the lower left-hand corner of the data area, click the Add button.
The Create Service dialog box appears, shown below.
The Create Service Dialog Box
B. Type a name for your service in the Service Name text box.
(- ), period (. ) pound (#), space ( ), at sign (@), equals (=), colon (: ),
C. If your service will receive HTTPS traffic, click the down arrow to
the right of the Protocol list box and choose SSL.
If your service will receive unencrypted HTTP traffic, leave the
Protocol set to HTTP.
D. Click the down arrow to the right of the Server text box, and choose
the appropriate server from the list of servers you created in step7.
E. Type the port number on which this service should listen in the Port
text box.
For Web servers, this will usually be port 80. For secure Web servers,
this will usually be port 443.
For now, you can ignore the other options. See the Citrix NetScaler
Installation and Configuration Guide for more information about
these options if you wish.
F. Click the Create button to create the service.
Your new service appears in the services list.
G. Repeat stepsa through f to create a new service for each server you
added in step7.
H. Click the Close button to close the Create Service dialog box and
return to the Services page.
3. Click the Virtual Servers entry to display the Virtual Servers page, shown
below, and create a virtual server (vserver).
The Configuration Utility Virtual Servers Page
A. In the lower left-hand corner of the data area, click the Add button to
display The Create Virtual Server dialog box, shown below.
The Create Virtual Server Dialog Box
B. In the Name text box, type a name for the virtual server.
(- ), period (. ) pound (#), space ( ), at sign (@), equals (=), colon (: ),
C. If your virtual server will receive HTTPS traffic, click the down
arrow to the right of the Protocol list box and choose SSL.
If your virtual server will receive unencrypted HTTP traffic, leave the
Protocol set to HTTP.
D. In the IP address text box, type an unused IP within the same subnet
as the protected Web server.
For example, if your protected Web server is at 192.168.12.45 and
subnets on your network are created within CIDR /24s, you can use
any unused IP in the 192.168.12.0/24 range.
E. In the Port text box, type the same port number you did in step8(d).
F. In the Services list beneath the text boxes, check the check box beside
the service you want to associate with this virtual server.
Note: Do not check more than one check box in this list. If you do,
only one checked service chosen at random will be associated with
this virtual server.
G. Click the Create button to create the vserver.
Your new virtual server appears in the Virtual Servers list.
H. Repeat stepsa through g to create a new vserver for each server/
service pair you configured.
I. Click the Close button to close the Create Virtual Server dialog box
and return to the Virtual Servers page.
You have successfully completed initial configuration of your Citrix Application
Firewall or Citrix NetScaler appliance. Proceed to Chapter 3, Simple
Configuration, on page65, to begin configuring the Application Firewall itself.
Using the Citrix NetScaler Command Line
Interface
This section describes how to log on to the NetScaler command line and use it to
perform initial configuration of a new Citrix Application Firewall or Citrix
NetScaler appliance.
Logging On to the NetScaler Command Line
Some system administrators prefer a Unix command line to a GUI interface.
Those users can configure the Application Firewall from the NetScaler command
line instead of using the configuration utility. In addition, a few advanced tasks
must be performed at the NetScaler command line.
When logging on to the NetScaler command line on a new Citrix Application
Firewall or Citrix NetScaler appliance, you must use the following procedure.
To log on to the NetScaler command line via the serial port
1. Plug the supplied serial cable into the serial port on your Citrix Application
Firewall or Citrix NetScaler appliance.
For a picture that shows the location of the serial port on your unit, see the
appropriate section for your hardware platform under Installing the
Server beginning on page19.
2. Plug the other end of the serial cable into your workstation or laptop serial
port.
3. Run the vt100 terminal emulation program of your choice.
For Microsoft Windows, you can use Hyperterminal, which is
installed with all modern versions of Windows.
For Apple Macintosh OSX, you can use the GUI-based Terminal
program or the shell-based t el net client.
Note: OSX is a based on the FreeBSD Unix platform. Most
standard Unix shell programs are available from the OSX command
line.
For Unix-based workstations, you can use the shell-based t el net
client or any terminal emulation program that comes with your GUI.
4. Set the terminal parameters as shown below.
5. Press the Enter key, or (if you are using a Macintosh) the Return key.
The terminal screen displays the Logon prompt.
Note: You might have to press the Enter key twice or three times,
depending on which terminal program you are using.
6. Type the system account logon, nsr oot , and press the Enter key.
The terminal screen displays the Password prompt.
7. Type the default password, and press the Enter key again.
You obtain the default password from your sales representative or from
Citrix Customer Support.
You are logged onto the NetScaler command line, and the initial prompt
Parameter Setting
Por t The port to which you connected the serial cable,
usually COM1.
Bi t s Per Second
( BPS)
9600
Dat a Bi t s 8
Par i t y N (none)
St op Bi t s 1
Fl ow Cont r ol None
Last l ogi n: Sun Nov 12 16: 20: 08 2006 f r om10. 129. 201. 8
Done
>
After initial configuration, you can log onto the Application Firewall NetScaler
command line via SSH to the NSIP, the IP assigned to the appliance during initial
configuration. Most system administrators find this more convenient than
connecting a computer directly to the appliance.
To log onto the NetScaler command line via SSH
1. Run the SSH client of your choice.
For Microsoft Windows, you can use a commercial SSH program, or
install and use the open source PuTTY program.
For Apple Macintosh OSX, you can use a commercial GUI-based
SSH program, or the shell-based ssh client included with OSX.
For Unix-based workstations, you can use the shell-based ssh client
or any SSH client that operates with your GUI.
2. Connect to the NSIP of your Citrix Application Firewall or Citrix NetScaler
appliance.
If you are using a shell-based SSH client, it displays a username or
login prompt on the screen.
If you are using a GUI-based SSH client, it displays a dialog box that
may prompt you for a username, or may prompt you for a login.
These are the same thing; different SSH clients simply call them by
different names.
Note: If you have not yet assigned an NSIP to your appliance, your SSH
client will not connect. You cannot log on via SSH until you have done the
initial configuration on your appliance. Discontinue this procedure, and
instead log on as described in To log on to the NetScaler command line via
the serial port on page58.
3. At the login prompt, type the logon for the default system account, which is
nsr oot .
If the dialog box does not show a field for the password, or if you are
using a shell-based SSH client, press the Enter key or click the OK
button, as appropriate, to display the password prompt.
If the dialog box shows a field for the password, skip to the next step.
4. At the password prompt, type the password, and press the Enter key or click
the OK button, as appropriate.
You are logged onto the NetScaler command line, and the initial prompt
Last l ogi n: Sun Nov 12 16: 20: 08 2006 f r om10. 129. 201. 8
Done
>
You have successfully logged onto the NetScaler command line. Proceed to
Initial Configuration by Using the NetScaler Command Line to begin
configuring the NetScaler operating system.
Initial Configuration by Using the NetScaler Command
Line
This section describes how to perform initial configuration of your Citrix
Application Firewall or Citrix NetScaler appliance manually, by using the
NetScaler command line.
To enable the Application Firewall by using the NetScaler command line
1. Save your Citrix NetScaler licenses to an easily-accessible location on your
local hard disk.
You obtain these licenses from your Citrix sales representative, Citrix
reseller, or Citrix Customer Support. Each feature has a separate license
file. License files are in a proprietary binary format.
2. Run the SFTP client of your choice.
There are many different SFTP clients. Which you will use depends on
which type of computer and operating system you use and personal
preference. Any SFTP client capable of opening an SFTP Level 2
connection should work correctly.
3. Open a connection to the NSIP assigned to your Application Firewall.
4. Navigate to the / nsconf i g directory.
5. If the / nsconf i g/ l i cense directory does not already exist, create it.
If you are upgrading from a previous version of the Citrix NetScaler
Application Delivery System to version 8.1, the directory may not exist.
6. Do a binary-mode transfer of your new licenses from your local hard drive
to your Application Accelerator or NetScaler appliance, and put them into
the / nsconf i g/ l i cense directory.
Some SFTP clients automatically detect the file type of files and perform
the correct type of transfer. Other clients will prompt you to tell them
whether to perform a binary or an ASCII transfer. Yet others will assume
that they should perform a binary transfer unless instructed otherwise. You
must ensure that your SFTP client performs the correct type of transfer.
Caution: You must not change the filenames of your license files, or your
Application Accelerator or NetScaler appliance will be unable to detect
your licenses.
7. If you have not already done so, log onto the NetScaler command line on
your appliance.
For instructions on how to do this, see To log on to the NetScaler
command line via the serial port on page58.
8. Enter the following command to change the Root Password.
> set syst emuser nsr oot <newpass>
For <newpass>, substitute the new password you have chosen.
Caution: Your new password is echoed on the command line as you type
it. For that reason, you should be careful to change it only when no
unauthorized persons might see the new password. In addition to this, the
NetScaler command line does not confirm your new password by requiring
that you retype it before putting the new password into effect. For this
reason, you must review the password you typed before you press the Enter
key to ensure that you actually typed what you intended to type.
9. Enter the following command to add a mapped IP (MIP) to your
configuration.
> add ns i p <MI P> <net mask> - t ype mi p
For <MI P>, substitute the IP you will use as the MIP. For <net mask>,
substitute the MIP netmask.
The NetScaler operating system uses MIPs as aliases for the servers it
manages when communicating with them. You must create one MIP for
your appliance to function, and may need to create several if your Web sites
are hosted on multiple Web servers or if those servers answer requests to
multiple IP/port combinations.
10. Enter the following command to set the default gateway.
> add r out e <MI P> <LOCALI P> <gat eway>
For <MI P>, substitute the MIP you assigned in the previous step. For
<LOCALI P>, substitute the internal, non-routable IP assigned to your Web
server. For <gat eway>, substitute the default gateway for the LANIP.
This command tells the NetScaler operating system to route packets to sent
to the Web server at <LOCALI P>, which is not routable from outside your
LAN, to the default gateway at <gat eway>.
11. Enter the following command to configure the NetScaler IP (NSIP).
> set ns conf i g - i paddr ess <NSI P> - net mask <net mask>
For <NSI P>, substitute the IP you will use for the NSIP. For <net mask>,
substitute the netmask for that IP.
The NSIP is the management IP address for the appliance, and is used for
all management related access to the appliance.
12. Enter the following command to enable the Application Firewall.
> enabl e ns f eat ur e appf w
13. Save your configuration, as shown below.
> save ns conf i g
14. Enter the following command to display your current configuration, with
the changes you made.
> show ns conf i g
If any of your changes are not as you want them to be, repeat the command
that configures that item, then repeat the previous step to save your configu-
ration again.
15. When every part of your configuration is exactly as you want it, enter the
following command to reboot your appliance.
> r eboot
16. Log back on to the appliance as nsr oot , using the new administrative
password you set.
17. Enter the following command to confirm connectivity to the appliance.
> pi ng <NSI P>
For <NSI P>, substitute the NSIP you assigned to the appliance.
You have successfully completed initial configuration of your Application
Firewall or NetScaler appliance. Proceed to Chapter 3, Simple Configuration,
on page65, to begin configuring the Application Firewall itself.
CHAPTER 3
Simple Configuration
The simplest Application Firewall configuration consists of one profile and one
associated policy. Such a configuration, which requires little customization or
detailed knowledge about the Application Firewalls operation, is sufficient for
many users. Users with more complex Web sites can perform a simple
configuration to provide immediate protection, and then do additional
configuration later.
To perform a simple configuration, you enable the Application Firewall, create
profile, create a policy, and bind the profile to the policy.
Enabling the Application Firewall
If you are upgrading an existing Citrix NetScaler appliance from a version of the
NetScaler operating system prior to 8.0 to the current version, you must first
update the licenses on your appliance and then enable the Application Firewall
before you configure it. If you are installing a new Citrix Application Firewall or
Citrix NetScaler appliance, you do not need to perform this procedure.
To enable the Application Firewall using the NetScaler command line
Type the following command at the prompt:
enabl e ns f eat ur e Appl i cat i onFi r ewal l
To enable the Application Firewall using the configuration utility
1. In the navigation pane, expand System and click Settings.
2. In the Settings pane, under Modes & Features, click basic features.
3. In the Configure Basic Features dialog box, select the Application
Firewall check box.
4. Click OK.
Creating and Configuring a Profile
A profile is a collection of security settings that are used to protect specific types
of web content or specific parts of your Web site or application. The Application
Firewall has two categories of profile: built-in profiles and user-created profiles.
Built-in profiles provide out-of-the-box tools for handling simple content that can
either be passed on without further filtering, or blocked without further filtering.
For more information about the built-in profiles, see The Built-In Profiles on
page84.
User-created profiles provide tools for handling more complex content that
cannot simply be passed on or blocked without filtering. They contain many user-
configurable options, most of which are described in detail in subsequent parts of
the Citrix Application Firewall Guide. For more information about user-created
profiles, see User-Created Profiles on page84.
Below are instructions on how to create and configure a user-created profile to
provide good initial protection for your Web sites.
Note: Creating and configuring an Application Firewall profile is a complex
task. Inexperienced users usually find that this task is much simpler to perform
using the Citrix NetScaler Configuration Utility (configuration utility) than the
NetScaler command line (NetScaler command line).
To create and configure an HTML profile using the NetScaler command line
At the NetScaler command prompt, type the following commands:
add appf w pr of i l e <name> - def aul t s basi c
set appf w pr of i l e <name> - t ype ( HTML | XML | HTML XML )
save ns conf i g
Parameters for Creating and Configuring a New Profile
Parameter Description
Name (<name>) A name for the profile. The name can begin
with a letter, number, or the underscore
symbol, and can consist of from one to 31
letters, numbers, and the hyphen (- ), period
(. ) pound (#), space ( ), at sign (@), equals
(=), colon (:), and underscore (_) symbols.
You should choose a name that will make it easy
for others to tell what type of content this profile
was created to protect.
Chapter 3 Simple Configuration 67
To create and configure a profile using the configuration utility
1. Log on to the configuration utility, using either the J ava client or the Web
Start client.
For instructions on doing this, see To log on to the configuration utility
on page40.
2. In the Menu tree, expand the Application Firewall entry to display the
choices in that category.
3. Click Profiles to display the Profiles pane, shown below.
Defaults (- def aul t s ( basi c
| advanced) )
You can choose one of two default configurations
when you create a profile: Basic or Advanced. A
profile created with basic defaults should protect
most Web sites while requiring little additional
configuration.A profile created with advanced
defaults is intended to protect more complex Web
sites requiring additional configuration.
Type (- t ype ( HTML | XML |
HTML XML) )
You can create three types of profile: HTML,
XML, or Web 2.0. To designate a Web 2.0 profile,
you type HTML XML after the - t ype
parameter.
Parameters for Creating and Configuring a New Profile
The Application Firewall Profiles Pane
If you have not yet created your first profile, the list will contain only the
four built-in profiles. If you have created one or more profiles, those
profiles will be listed below the built-in profiles.
4. Click the Add button to display the Create Application Firewall Profile
dialog box, shown below.
The Create Application Firewall Profile Dialog Box
5. In the Profile Name text box, type a name for your profile.
The name can begin with a letter, number, or the underscore symbol, and
can consist of from one to 31 letters, numbers, and the hyphen (- ), period
(. ) pound (#), space ( ), at sign (@), equals (=), colon (: ), and underscore
(_) symbols. You should choose a name that will make it easy for others to
tell what type of content this profile was created to protect.
6. Choose the type of profile you want to create.
If your profile will protect an XML application, in the Profile Type
drop-down list select XML.
If your profile will protect Web 2.0 content consisting of mixed XML
and HTML content (such as an ATOM feed, a blog, or an RSS feed),
in the Profile Type drop-down list select Web 2.0.
If your profile will protect standard HTML-based web content, you
can skip this step. The default setting, HTML, is correct.
If you are unsure what types of content your profile will protect, you can
choose Web 2.0 to make the full range of Application Firewall security
checks available to protect your Web site.
7. If your profile will protect Web sites containing complex J avascripts or
forms that access back-end SQL databases, in the Defaults radio button
array select the Advanced radio button.
If your Web sites do not contain complex content, you do not need to
change the default settings for your new profile; the Basic radio button is
already selected.
For more information about the default settings and what those settings are
for each Application Firewall check, see Chapter 4, Profiles, on page83.
8. Click Create to create your profile.
Your new profile appears in the data area of the Application Firewall
Profiles page.
9. Repeat steps5 through 8 to create any additional profiles you might need to
protect other types of content.
10. Click Close to close the Create Application Firewall Profile dialog box, and
return to the Application Firewall Profiles pane.
11. In the Profiles pane, select the first profile you created.
12. Click Open to display the Configure Application Firewall Profile dialog
box for that profile.
This dialog box contains four tabs. When you are configuring your initial
profiles, you can safely ignore the General, Settings and Learning tabs.
13. Click the Security Checks tab to display it, and configure the Deny URL
check.
A. In the list, select Deny URL.
B. Click Modify to display the Modify Deny URL check dialog box.
All of the Deny URLs on the list are disabled by default. The first
Deny URL is highlighted.
C. Click the scroll button to the right of the Deny URLs list and scroll
down to the bottom of the list.
D. Hold down the Shift key, and click the last entry in the Deny URLs
list to select all Deny URLs on the list.
E. Click the Enable button to enable all of the default Deny URLs.
F. Click the OK button to save your changes.
All of the default Deny URLs are now enabled, protecting your Web
sites from a number of known attacks.
G. Click the Close button to close the Modify Deny URL check dialog
box, and return to the Configure Application Firewall Profiles dialog
box.
H. Click the Close button to close the Configure Application Firewall
Profiles dialog box and return to the Application Firewall Profiles
screen.
14. Repeat steps12 and 13 for each profile you created.
Creating and Configuring Policies
When configuring a new Application Firewall, after you create your profiles, you
must create a policy for each profile. Policies are used to determine whether a
request or a response meets specific criteria. When a request or response meets a
policys criteria, or matches a policy, the Application Firewall then filters the
request or response using the associated profile.
A policy is a set of parameters that defines a particular type of web content or
particular part of a Web site. The Application Firewall uses policies to determine
which profile to use when filtering specific requests or responses.
During initial configuration, you create a policy that protects all vulnerable
content on your Web sites. Later, if necessary, you can create additional policies
that better protect specific parts of your Web site. If you create more than one
policy, you also must set the order in which the Application Firewall tests
requests and responses against each policy. This lets you easily create specific
policies for special content without requiring changes to the more general policy.
You simply set a higher priority for a specific policy than a more general policy.
The following procedures explain how to create a policy that filters based on any
of several simple criteria. You can create significantly more complex policies in
the Application Firewall, policies that designate specific web pages, specific
types of connections, or a complex combination of factors. You can use either
classic or advanced policies and expressions to configure the Application
Firewall.
Classic expressions are simpler, and provide a basic set of tools that allow you to
filter requests based on the HTTP header. Advanced expressions are more
complex, and provide a considerably richer set of expression elements, along
with options to control the flow of evaluation within a policy bank. These
elements and options enable you to maximize the capabilities of Application
Firewall. Advanced policies, which comprise a set of rules and actions that use
the advanced expression format, further enhance your ability to analyze data at
various network layers and at different points along the flow of traffic.
For a more complete description of how to create Application Firewall policies,
see Chapter 5, Policies, on page135. For more information about the benefits
of using advanced policies and expressions, see the Advanced and Classic
Policies chapter in the Citrix NetScaler Policy Configuration and Reference
Guide.
You can create a policy either in the configuration utility or at the NetScaler
command line.
To create a policy using the configuration utility
Start client.
on page40.
choices in that category, and click Policies to display the Policies page,
shown below.
The Application Firewall Policies Page
If you have not yet created any policies, this page will be blank. If you have
created one or more policies, they will be displayed on the page.
3. In the lower left-hand corner of the data area, click the Add button to
display the Create Application Firewall Policy dialog box, shown below.
The Create Application Firewall Policy Dialog Box
4. In the Policy Name* text box, type a name for your new policy.
(. ) pound (#), space ( ), at sign (@), equals (=), colon (:), and underscore
tell what type of content this policy was created to detect.
5. In the Action drop-down list, select the name of the profile you just created
to associate with this policy.
Note: You can create Application Firewall policies with either NetScaler
classic expressions or advanced expressions. Advanced expressions
provide a considerably richer and more flexible set of options, but are also
more difficult to learn and use. The instructions below describe how to
create a policy using classic expressions. For more information about using
advanced expressions to create Application Firewall policies, see
Configuring Policies on page136.
6. Click the Add button to display the Add Expression dialog box, shown
below, and construct an expression that describes the type of web
connections you want this policy to match.
The Add Expression Dialog Box
Note: You should leave the expression type set to General Expression for
Application Firewall policies.
The Flow Type is set to REQ by default. This tells the Application Firewall
to look at incoming connections, or requests, and the associated outgoing
connection, or response. Since the Application Firewall treats a request and
its associated response as a single entity, all Application Firewall policies
begin with REQ.
A. If the Protocol is not already set to HTTP, in the Protocol drop-down
list, select HTTP.
This tells the Application Firewall to look at HTTP requests, requests
sent to a Web server. You have several other choices available in this
list box, but the majority of Application Firewall policies use the
HTTP protocol.
Note: In the NetScaler operating system expressions language,
HTTP includes HTTPS requests, as well.
B. In the Qualifier drop-down list, select a qualifier for your policy.
The qualifier tells the Application Firewall what part of the protocol
it should look at.
To filter HTTP Requests to a particular host, choose HOST as
your qualifier.
To filter HTTP Requests to a specific web page, choose URL as
your qualifier.
To filter HTTP Requests that contain a particular query string,
choose URLQUERY as your qualifier.
For a description of all the available choices, see To configure a
policy by using the configuration utility, stepC on page140.
After you make this choice, the Add Expression dialog box display
refreshes, and displays the Header Name* text box beneath the Flow
Type list box, as shown below.
The Add Expression Dialog Box, URL Qualifier
C. In the Operator list box and choose the operator for your expression.
The operator tells the Application Firewall what type of comparison
or criterion to use.
To filter HTTP Requests to a particular host, choose == as your
qualifier.
To filter HTTP Requests to a specific web page, choose == as
your qualifier.
choose CONTAINS as your qualifier.
For a description of all the available choices, see To configure a
policy by using the configuration utility, stepD on page141.
D. If you see a text box labeled Value*, type the string or number you
want the policy to check for.
To filter HTTP Requests to a specific host, type that host name.
For example, if the host of your companys Web site is
www. exampl e. com, type that in the Value* text box.
To filter HTTP Requests to a specific web page, type the
complete URL of the web page. For example, if you want to
filter all requests to ht t p: / / www. exampl e. com/
l ogi n. php, type that in the Value* text box.
type that string. For example, if you want to search queries for
strings that contain the string pr od_l i t , type that in the
Value* text box.
E. If you chose HEADER as your Qualifier, type the header name you
want in the Header Name* text box.
This tells the Application Firewall to check all requests to see if the
URL header exists. Since all requests by definition have a URL
header, this expression matches all requests.
If you did not choose HEADER as your Qualifier, this text box will
not appear.
F. If you chose HEADER or URLQUERY as your Qualifier, type the
appropriate values in the Len and Offset text boxes if you wish
This tells the Application Firewall to check a specific portion of the
header or URL query. These fields are optional; you can leave them
blank.
If you did not choose HEADER or URLQUERY as your Qualifier,
these text boxes do not appear.
G. Click the OK button to add your expression to the list in the middle
of the Create Application Firewall Policy dialog box.
H. Click the Close button to close the Add Expression dialog box, and
return to the Create Application Firewall Policy dialog box.
7. Click the Create button to create your policy.
8. Click the Close button to close the Create Application Firewall Policy
dialog box and return to the Policies page.
Your new policy appears in the data area of the Policies page list.
To create a policy by using the NetScaler command line
1. Run the SSH client of your choice, connect to the NSIP of your appliance,
and log on to the NetScaler command line.
For instructions on doing this, see To log onto the NetScaler command line
via SSH on page60.
2. Enter the following command to create the policy.
> add appf w pol i cy <name> <r ul e> <pr of i l e>
Make the following substitutions:
For <name>, substitute a name for the policy. The name can begin
with a letter, number, or the underscore symbol, and can consist of
from one to 127 letters, numbers, and the hyphen (- ), period (. )
pound (#), space ( ), at sign (@), equals (=), colon (:), and underscore
(_) symbols. You should choose a name that will make it easy for
others to tell what type of content this policy was created to detect.
For <r ul e>, substitute the following NetScaler expression:
" REQ. HTTP. HEADER HOST CONTAI NS ( " www. exampl e. com" ) "
For www. exampl e. com, substitute the hostname of your companys
Web site.
Note: All rules must be enclosed in double quotes.
This expression tells the Application Firewall to check the Host
header of all requests to see whether it contains your companys Web
site host. This will match all requests to that Web site.
For <pr of i l e>, substitute the name of the profile you just created.
This policy tells the Application Firewall to apply the default profile you
created to all requests that it matches. Since this policy matches all HTTP
requests, it will match all connections to your protected Web servers.
You can later create profiles and policies to protect specific types of content
that require additional protection, and set their priorities appropriately so
that they are evaluated first. Then, you can use this policy and profile to
protect any part of your Web sites that is not covered by a more specific
policy.
3. Enter the following command to save your configuration.
> save ns conf i g
4. Enter the following command to confirm that your policy was correctly
created.
> show appf w pol i cy <name>
For <name>, substitute the name of the policy you created.
If your policy was correctly created, you do not need to do anything
further.
If you want to change your policys name, expression, or profile, you
must delete it as shown below, and then recreate it.
> r mappf w pol i cy <name>
You have successfully created your first policy. You must next bind that policy
globally or to a bind point to put it and its associated profile into effect.
Binding Policies
To put a policy and its associated profile into effect, you bind the policy, either
globally or to a bind point, and assign it a priority. You bind each policy to
activate that policy, so that the NetScaler operating system knows to implement it.
The priority you assign determines the order in which your policies are evaluated,
allowing you to evaluate the most specific policy first, and more general policies
in descending order, finishing with your most general policy.
When you are binding your first policy, which is generic and should apply to all
HTTP traffic that is not covered by a more specific policy, you should assign that
policy a low priority, so that you can create and bind other, higher-priority
policies later without having to reconfigure your first policy.
You can bind a policy either by using the configuration utility or by using the
To globally bind a policy by using the configuration utility
Start client.
on page40.
2. In the Menu tree, expand the Application Firewall entry and click Policies
to display the Policies page.
3. In the list of policies in the data area, click your new policy once to
highlight it.
4. Click the Global Bindings button to display the Bind/Unbind Firewall
Policy(s) to Global dialog box, shown below.
The Bind/Unbind Policy(s) to Global Dialog Box
5. Click the Insert Policy button to insert a row in the data area of this dialog
box and display available policies, as shown below.
The Bind/Unbind Policy(s) to Global Dialog Box, after Insert Policy Button is Clicked
In addition to listing any policies you have created that are not already in
the Bind/Unbind Policy(s) to Global Dialog box data area, the drop-down
list includes the New Policy entry. If you choose this entry, the Create
Application Firewall Policy dialog box is displayed, allowing you to create
a new policy.
6. Click the policy you created to insert it in the list.
The policy you chose is inserted, and the check box in the State column is
selected, which indicates that it is bound and activated.
7. If you want to globally bind your policy, but temporarily keep it inactive, in
the State column clear the check box.
When you globally bind a policy, by default it is enabled and goes
immediately into effect. In some cases, you might want to have a policy
reviewed before you put it into effect, but want to be able to enable it
quickly. You can do this by clearing the State check box or setting the
policy to DISABLED.
8. In the Priority column, click the default integer and edit the number to
assign the appropriate priority to this policy.
You can set the priority to any positive integer. In the NetScaler operating
system, policy priorities work in reverse orderthe higher the number, the
lower the priority. For example, if you have three policies with priorities of
10, 100, and 1000, the policy assigned a priority of 10 is performed first,
then the policy assigned a priority of 100, and finally the policy assigned an
order of 1000. Since the Application Firewall implements only the first
policy that a request matches, not any additional policies that it might also
match, policy priority is important to get the results you intended.
If you give your first policy a low priority (such as 1000), you tell the
Application Firewall to perform it only if other policies with a higher
priority do not match a request. If you give your first policy a high priority
(such as 1), you tell the Application Firewall to perform it first, and skip
any other policies that might also match.
You can leave yourself plenty of room to add other policies in any order,
and still set them to evaluate in the order you want, by setting priorities with
intervals of 50 or 100 between each policy when you globally bind it. If
you do this, you can add additional policies at any time without having to
reassign the priority of an existing policy. You simply look at the priorities
assigned to the preceding and following policies, and assign a new policy a
priority between that of those two numbers.
9. Click the OK button to save your changes.
The Bind/Unbind Firewall Policy(s) to Global dialog box closes, and you
return to the Policies page.
The figure below shows two globally-bound policies in the data area of the
Policies page.
The Policies Page, with two Globally-Bound Policies
To globally bind a policy using the NetScaler command line
via SSH on page60.
2. Enter the following command to globally bind the policy.
> bi nd appf w gl obal <pol i cy> <pr i or i t y>
For <pol i cy>, substitute the name of the policy you just created. For
<pr i or i t y>, substitute a positive integer that represents the priority you
want to assign to that policy.
In the NetScaler operating system, policy priorities work in reverse order
the higher the number, the lower the priority. For example, if you have three
policies with priorities of 10, 100, and 1000, the policy assigned a priority
of 10 is performed first, then the policy assigned a priority of 100, and
finally the policy assigned an order of 1000. Since the Application Firewall
implements only the first policy that a request matches, not any additional
policies that it might also match, policy priority is important to get the
results you intended.
If you give your first policy a low priority (such as 1000), you tell the
Application Firewall to perform it only if other policies with a higher
priority do not match a request. If you give your first policy a high priority
(such as 1), you tell the Application Firewall to perform it first, and skip
any other policies that might also match.
You can leave yourself plenty of room to add other policies in any order,
and still set them to evaluate in the order you want, by setting priorities with
intervals of 50 (or, better, 100) between each policy when you globally
bind it. If you do this, you can add additional policies at any time without
having to reassign the priority of an existing policy. You simply look at the
priorities assigned to the preceding and following policies, and assign a
new policy a priority between that of those two numbers.
> save ns conf i g
You have successfully globally bound your policy and associated profile. The
Application Firewall is now filtering HTTP traffic to your company Web server
using the basic profile you created.
If your Web server or Web site does not support SQL or have access to sen-
sitive private information, you can safely stop here. The default profile and
default policy will protect it sufficiently.
If your Web server hosts Web forms that connect to SQL databases, or uses
active scripts that access other Web sites, you should create additional pro-
files to protect that content, and additional policies to detect this special
content. You can proceed to Chapter 12, Use Cases, on page267 for
examples that show how to best protect SQL databases and scripted con-
tent.
If you want to know more about the advanced features of the Application
Firewall, proceed to Chapter 4, Profiles, on page83 for a detailed
description of how to create an advanced profile; Chapter 8, The Common
Security Checks, on page175 for detailed descriptions of each Applica-
tion Firewall security check; or Chapter 5, Policies, on page135 for a
detailed description of how to create complex policies to detect certain
types of content you might want to protect using an advanced profile.
CHAPTER 4
Profiles
This chapter describes in detail what Application Firewall profiles are and do, and
explains how to configure each check available in a user-created profile. The
Application Firewall has a number of security checks available in its user-created
profiles, all of which can be enabled or disabled, and configured in a number of
ways in each profile. You can also enable the learning feature and use it to
customize the Application Firewalls settings for the web content it protects using
that profile.
Note: You do not need to read this chapter if the default configuration you
performed in Chapter 3, Simple Configuration, on page65 meets your needs.
You can find the following types of information in the designated sections of this
chapter:
For an overview of Application Firewall profiles that describes what they
are and do, see About Application Firewall Profiles.
For procedures that describe how to add, configure, and delete profiles,
using either the configuration utility or the NetScaler command line, see
Creating, Configuring, and Deleting Profiles, on page85.
For specific information about profile settings, see Configuring the Profile
Settings, on page122.
For specific information about learning and the configuration options for
each type of security check that includes the learning feature, see Config-
uring the Learning Feature, on page129.
For specific information about the configuration options for each security check
and how each option affects the functioning of that security check, see Chapter 8,
The Common Security Checks, on page175 and the following two chapters.
About Application Firewall Profiles
An Application Firewall profile is a collection of settings that tell the Application
Firewall which security checks to use when filtering a particular request or
response, and how to handle a request or response that fails a security check.
The Built-In Profiles
The built-in profiles provide an easy way to process types of content that do not
require complex filtering. The four built-in profiles are:
APPFW_BYPASS. Allows requests to proceed without any filtering. You
should use this profile only for requests and responses that do not require
any Application Firewall protection.
APPFW_RESET. Resets the connection, requiring the user to re-establish
his or her session by visiting a designated start URL. You can use this
profile for requests that might constitute an attack on your protected Web
sites, but that could be due to a legitimate typo or error by the user. A
legitimate user is free to restart the session, but an attacker who is trying to
access forbidden content will find that each attempt costs valuable time.
APPFW_DROP. Drops the connection without response. You should use
this profile only for requests that are unquestionably due to an attack on
your Web site.
APPFW_BLOCK. Redirects the connection to the designated error page.
You should use this profile for requests that are likely from a legitimate user
who may have bookmarked a URL on your protected Web site that is not
designated as a start URL. This is the friendliest type of blocking, intended
to redirect the user to the appropriate start page.
User-Created Profiles
For more complex types of content, you can create the following types of profile:
HTML profile. Protects standard HTML-based web content. You use this
type of profile for Web sites that consist of standard HTML-based content.
This includes Web sites that contain Web forms, J avascript, and dynamic
content.
XML profile. Protects XML-based applications. You use this type of pro-
file to protect XML-based content, such as applications based on the XML
SOAP protocol or other XML protocols that are delivered via the Web.
Web 2.0 profile. Protects Web 2.0 content containing both XML and
HTML content.You use this type of profile to protect ATOM newsfeeds,
blogs, RSS feeds, and other types of Web 2.0 content that contains mixed
XML and HTML-based elements.
Chapter 4 Profiles 85
You created at least one user-created profile when initially configuring the
Application Firewall. Depending upon the type of content you wanted to protect
using that profile, you might have created an HTML profile, an XML profile, or a
Web 2.0 profile. If that profile was intended to protect HTML or XML content
that does not contain legacy code or access back-end SQL databases, you
probably created the profile with Basic defaults. That type of profile is configured
to prevent forceful browsing, cookie tampering, tampering with Web form
structure and content, and buffer overflow attackssufficient protection for web
pages that do not contain active scripts, do not access sensitive data, and do not
access a back-end SQL database. That type of profile also requires little if any
additional configuration.
If the profile was intended to protect a Web site that contains legacy CGI scripts,
complex J avascript, or access back-end SQL servers, you probably created the
profile with Advanced defaults. For example, a Web site that contains embedded
javascripts should be checked for cross-site scripting. A shopping cart application
that contains Web forms that connect to a back-end SQL database and handles
sensitive customer information should be checked for signs of tampering with the
Web form, inappropriate content in form fields, and SQL injection attacks.
Responses from such a shopping cart application should be checked for attempts
to obtain sensitive customer information, such as credit card numbers and the
associated customer records. These types of profiles require additional
configuration, either to allow the learning feature to generate the necessary
exceptions to various security rules or to tweak the settings manually.
The rest of this chapter describes in detail how to create and configure
Application Firewall profiles to provide exactly the type and level of protection
you need.
Creating, Configuring, and Deleting Profiles
This section describes how to create, configure, and delete profiles, using either
the configuration utility or the NetScaler command line.
To configure the built-in profiles by using the configuration utility
1. In the navigation pane, expand Application Firewall, and then click
Profiles.
2. In the Application Firewall Profiles pane, select a built-in profile, and
then click Open.
The Configure Application Firewall Built-In Profile dialog box appears,
with the information for the selected built-in profile. It contains two tabs:
General and Settings. The General tab contains read-only information
about the profile.
3. Click Settings, and configure the user-configurable options for the selected
built-in profile.
All four built-in profiles contain the Log Every Policy Hit check box. This
check box is unselected by default for APPFW_BYPASS, and selected by
default for the other three built-in profiles. You configure this setting by
selecting and/or clearing the check box.
The APPFW_BLOCK built-in profile also contains the HTML Error
settings. When Application Firewall blocks a users request, the
Application Firewall can either redirect the users request to a designated
Redirect URL or display an HTML Error Object. You configure the
HTML error settings by selecting the appropriate radio button, and then
configuring the option as described below.
Redirect URL. To redirect the users request to a designated Redirect
URL, type the URL you want in the text box to the right. The default
setting is /, which redirects the user to the protected Web sites home
page.
HTML Error Object. To display an HTML Error Object from the
Application Firewalls cache, click the down arrow to the right of the
HTML Error Object list box and choose the HTML error object you
want to display. If you have not already imported the appropriate
HTML error object, click Import to do so.
Note: If the error object you want to import is not on a server that
your NetScaler appliance can connect to through the LAN, first verify
that the appliance has Internet connectivity. Otherwise you will be
unable to import the error object.
4. Click OK when finished.
The instructions below apply to any type of user-created profile and, in the
configuration instructions, to any type of security check within the profile.
You create a new user-created profile either in the configuration utility
Application Firewall Profiles screen or at the NetScaler command line, as
described below.
To create a profile by using the configuration utility
1. Log on to the configuration utility.
For more information about logging on, see To log on to the configuration
utility on page40.
Profiles.
3. In the details pane, click Add to display the Create Application Firewall
Profile dialog box.
4. In the Profile Name text box, type a name for your new profile.
can consist of from one to 31 letters, numbers, and the hyphen (-), period
(.) pound (#), space ( ), at sign (@), equals (=), colon (:), and underscore
tell what type of content this profile was created to protect.
5. If you are creating an XML or Web 2.0 profile, click the down arrow to the
right of the Profile Type list box and choose the appropriate type.
If you are creating an HTML profile, you can skip this step.
6. In the Defaults radio button array beneath the Profile Name text box, select
the radio button beside Basic or Advanced to choose the default settings
you want for your profile.
Choose Basic to enable several of the most important Application
Firewall checks and preconfigure them to require very little or no
additional configuration and maintenance.
Choose Advanced to enable additional features and turn on the
Learning feature, so that the Application Firewall can observe traffic
on your Web sites and help generate the appropriate configuration.
The defaults control which Application Firewall checks are enabled and
how they are configured when the profile is created. They do not affect how
the profile is configured after you create it. You can enable and modify the
configuration of any Application Firewall checks at any time.
For more information about the default settings for each Application
Firewall check, see Chapter 8, The Common Security Checks, on
page175.
7. Click Create.
The new profile appears in the list in the Profiles pane.
8. Repeat steps6 through 8 as many times as you like to create multiple new
profiles.
9. Click Close to close the Create Application Firewall Profile dialog box
and return to the Profiles pane.
You configure a profile either in the configuration utility Application Firewall
Profiles screen, or at the NetScaler command line, as described below.
To configure a user-defined profile by using the configuration utility
1. In the list on the Profiles page, click the entry for the profile you want to
modify once, to highlight it.
2. Click the Open button to display the Configure Application Firewall
Profile dialog box, shown below.
The Configure Application Firewall Profile Dialog Box, General Tab
This dialog box contains four tabs. They are:
General. Displays the profile's name and a general description. This
tab is read-only; you cannot modify any of this information.
Checks. Lists the Application Firewall security checks, and allows
you to modify the settings for each.
Settings. Allows you to configure certain aspects of the Application
Firewall's behavior in this profile.
Learning. Allows you to configure and manage the learning feature
for this profile.
3. Click the Security Checks tab to display it, shown below, and make any
modifications you like to the settings for any security check on the list.
The Configure Application Firewall Profile Dialog Box, Checks Tab,
for Web 2.0 Profiles
You can enable or disable the check actions for any security check in this
tab, by selecting or clearing the appropriate check box. You can also
configure any additional check actions or parameters by click >>in the
More column, and making your changes in the pop-up window.
To make additional changes to any security check, you open the Modify
Check dialog box as described below, and make your changes in it.
A. In the security checks list, select the security check whose settings
you want to modify.
B. Click the Modify button to display the Modify Check dialog box for
that rule.
The Modify Start URL Check dialog box General tab is shown below.
The other Modify Check dialog boxes General tabs are similar.
The Modify Start URL Check Dialog Box, General Tab
The Modify Check dialog box has two tabs of its own, the General
tab and the Settings tab. The General tab is displayed by default. It
contains a description of the rule and the Check Actions area, which
contains a list of actions that are performed when a request or
response matches this particular security check.
C. Enable or disable each action in the Check Actions area by checking
or unchecking the check box to the left of it.
Block. The Block action tells the Application Firewall to block
requests or responses that match this check.
Log. The Log action tells the Application Firewall to add a log
entry for any request or response that matches this check.
Learn. The Learn action enables learning for this check. When
learning is not available for a check, this entry and check box
are greyed out.
Statistics. The Statistics action tells the Application Firewall to
maintain statistics about the numbers and types of requests or
responses that match this check, and what it did with those
requests or responses.
Other actions are available with certain security checks. See
Chapter 8, The Common Security Checks, on page175, and the
two following chapters, for more information.
D. Click the Checks tab to display it.
The Modify Start URL Check dialog box, Checks tab, is shown
below. The other Modify Check dialog box Checks tabs are similar.
The Modify Start URL Check Dialog Box, Checks Tab
The Checks tab contains a list of exceptions (or relaxations) to this
security check. For newly-created profiles that you are configuring
for the first time, depending on which check you are configuring and
whether you originally created the profile with basic or with
advanced defaults, the list of relaxations may be empty, or may have
default entries.
Beneath the list of relaxations are buttons that allow you to add a new
relaxation, modify an existing relaxation, and delete a relaxation.
Clicking the Add button displays the Add Check Relaxation
dialog box, shown below, where you can add a new relaxation.
The Add Start URL Check Relaxation Dialog Box
Selecting an existing relaxation and then clicking Modify
displays the Modify Check Relaxation dialog box, shown
below, where you can modify the relaxation you chose.
The Modify Start URL Check Relaxation Dialog Box
Selecting an existing relaxation and then clicking Remove
removes the relaxation from the list.
Selecting a disabled relaxation and then clicking Enable
enables that relaxation.
Selecting an active relaxation and then clicking Disable
disables that relaxation.
Note: For more information on how to how to enter a Start URL,
see The Start URL Check on page175. For more information about
using the Regex Editor and Regex Tokens, see Configuring the
Security Checks with the Configuration Utility on page104 and
following.
E. Click Close to close the Modify Check dialog box and return to the
Configure Application Firewall Profile dialog box.
4. Back in the Configure Application Firewall Profile dialog box, click the
Settings tab to display it, as shown below.
The Configure Application Firewall Profile Dialog Box, Settings Tab
Note: The Settings tab contains a great many options, so when it is first
displayed, only the top portion is visible, and a scroll bar appears to the
right to allow you to reach the options that are below and not shown. You
can adjust the size to display all options at once, as is shown above.
Depending on the profile type you are configuring, the Settings tab contains
some or all of the following configuration options:
HTML Settings.
HTML Error. When it blocks a users request, the Application
Firewall can either redirect the users request to a designated
Redirect URL, or it can display an HTML Error Object.
Redirect URL. To redirect the users request to a
designated Redirect URL, you click the radio button
beside Redirect URL, then type the URL you want in the
text box to the right. The default setting is /, which
redirects the user to the protected Web sites home page.
HTML Error Object. To display an HTML Error
Object from the Application Firewalls cache, you click
the radio button beside HTML Error Object, then click
the down arrow to the right of the HTML Error Object
list box and choose the HTML error object you want to
display. If you have not already imported the HTML
error object you want into the Application Firewall
configuration, you click the Import button to do so.
Note: If the error object you want to import is on a server that
your NetScaler appliance can connect to only via the Internet,
rather than the LAN, first verify that the appliance has Internet
connectivity. Otherwise you will be unable to import the error
object.
Charset. The default charset (character set) used by the Citrix
NetScaler Configuration Utility. By default, the Application
Firewall charset is set to ISO-8859-1, the western European
encoding suitable for English and other western European
languages. A list box containing valid ISO character encoding
types supported by the Application Firewall appears to the right
of the Charset label. You can change the charset for your
Application Firewall to any other supported charset by clicking
the down arrow to the right of the list box, and picking another
encoding from the list.
Strip HTML Comments. Tells the Application Firewall to
remove any HTML comments from the web pages on your
Web site before sending them to users. This feature is disabled
by default. You enable this feature by checking the Strip HTML
Comments check box.
Exclude Uploaded Files From Security Checks. Tells the
Application Firewall not to scan uploaded files for violations of
its security checks. This feature is disabled by default. You can
enable it by selecting the check box. If users will upload large
files to your protected Web sites, enabling this feature will
improve performance without significantly degrading security.
Exempt Closure URLs From Security Checks. Tells the
Application Firewall not to run URL-based security checks on
URLs accessed by clicking a link on a web page that the user
legitimately accessed on your protected Web site. This feature
is enabled by default. You can disable it by clearing the check
box.
Enable Form Tagging. Tells the Application Firewall to tag
the form fields in Web forms in the HTML pages on your
protected Web sites. This feature is enabled by default. You can
disable this feature by unchecking the check box.
Canonicalize HTML Response. Tells the Application Firewall
to modify responses sent by your protected Web servers to
ensure that they contain only valid HTML. This feature is
enabled by default. You can disable this feature by unchecking
the check box.
Invalid Percent Handling. Specifies whether the Application
Firewall should use Apache, ASP, or secure mode for invalid
percent handling. Secure mode is the default.
Default Content Type. Specifies the content-type that the
Application Firewall should assume when an HTML request or
response does not specify a content-type. Can be set separately
for Request and Response. Request Default: None (blank).
Response Default: application/octet-stream.
XML Settings.
XML Error Object. You choose the XML Error Object you
want the Application Firewall to display when it blocks a users
request for XML content here, by clicking the down arrow to
the right of the XML Error Object list box and choose the XML
error object you want to display. If you have not already
imported the XML error object you want into the Application
Firewall configuration, you click the Import button to do so.
object.
Common Settings.
Post Body Limit. To tell the Application Firewall the
maximum size of POST body that it should allow, type the
maximum in the text box as an integer representing a number of
bytes. Default: 20,000,000.
Custom Settings. Here you choose a custom settings file from
the files uploaded to the Application Firewall in the Imports
pane. The custom settings file contains customized lists of SQL
special characters, SQL keywords, cross-site scripting allowed
tags, and cross-site scripting allowed attributes. The SQL
injection and cross-site scripting security checks then use the
customized lists instead of the built-in default lists.
Check Request Headers. Tells the Application Firewall to
check request headers as well as POST bodies for SQL
Injection and Cross-Site Scripting check violations. Unselected
by default.
Log Every Policy Hit. Tells the Application Firewall to log
every connection that matches an Application Firewall policy
to the NetScaler log. Unselected by default.
5. Click the Learning tab to display it, as shown below.
The Configure Application Firewall Profile Dialog Box, Learning Tab
The Learning tab consists of the following sections:
Security checks list. At the top of the dialog box is a window
containing a list of security checks that use the learning feature. This
list contains those security checks that are appropriate for the type of
profile that you are configuring, so the list will be different depending
on the profile type. You must first select a check in this list before you
can configure its learning settings.
Manage Rules. You click the Manage Rules button to access the
Manage Learned Rules dialog box.
Learning Thresholds. You configure two settings for the selected
check by typing a positive integer into the appropriate text box. The
text box labeled, Minimum number of sessions for learning, tells
the Application Firewall how many user sessions it must observe
before it can start learning relaxations for this check. The text box
labeled, Percentage of sessions seen, tells the Application Firewall
what percentage of total sessions it has observed must contain a
violation of this check before it should learn a relaxation for this
check.
Both of these settings are set to ten (10) by default.
Profile Learned Rules. In this section you click the Remove all
Learned Data button to delete all learned information on the
Application Firewall for the current profile.
Clicking this button will not remove any rules that have been
deployed, skipped or ignored. It merely removes learned data that
you have not yet reviewed and acted on.
Caution: Do not click this button unless you want to remove all
learned data for this profile, not just the selected check, and start the
learning process over again.
6. Click the OK button to permanently add your changes to the Application
Firewall configuration.
7. Click the Close button to close the Configure Application Firewall Profile
dialog box and return to the Profiles page.
8. To configure a different profile, select that profile, and then click Open and
repeat this procedure.
9. To remove a profile using the configuration utility, in the Profile page list,
select it, and then click Remove.
When the configuration utility asks you to confirm your choice, you click
the Yes button.
To create and configure a profile using the NetScaler command line
1. Run the secure shell (SSH) client of your choice, connect to the NSIP of
your appliance, and log on to the NetScaler command line.
via SSH on page60.
2. Enter the following command to create the profile.
> add appf w pr of i l e <name> [ - def aul t s ( basi c | advanced ) ]
For <name>, substitute a name for the profile. The name can begin with a
letter, number, or the underscore symbol, and can consist of from one to 31
letters, numbers, and the hyphen (-), period (.) pound (#), space ( ), at sign
(@), equals (=), colon (:), and underscore (_) symbols. You should choose a
name that will make it easy for others to tell what type of content this
profile was created to protect.
For [-defaults ( basic | advanced )], substitute the appropriate string to
set the defaults for this profile. If you want to create your profile with basic
defaults, type -defaults basic. If you want to create your profile with
advanced defaults, type -defaults advanced.
3. Enter the following command to set the profile type.
> set appf w pr of i l e <name> [ - t ype ( HTML | XML ) ]
For [-type ( HTML | XML ) ], substitute the appropriate string to create the
type of profile you want. If your profile will protect standard HTML
content, type -type HTML. If your profile will protect an XML application,
type -type XML. If your profile will protect a Web 2.0 application, type -
type HTML XML.
4. Enter the following command to configure the security checks and settings
for your profile.
> set appf w pr of i l e <name> - <ar g1> [ - <ar g2> ]
For <arg1> and any subsequent arguments, substitute the appropriate
parameter for the security check parameter you want to set.
For a list of valid parameters and a description of each, see the table titled,
Application Firewall Profile Security Check Parameters, on page116 and
following.
For more information about the parameters of each Application Firewall
security check and how they function, see the appropriate chapter:
Common security checks. For security checks that apply to all kinds
of profile, see Chapter 8, The Common Security Checks, on
page175.
HTML security checks. For security checks that apply only to
HTML and Web 2.0 profiles, see Chapter 9, The HTML Security
Checks, on page201.
XML security checks. For security checks that apply only to XML
and Web 2.0 profiles, see Chapter 10, The XML Security Checks,
on page235.
> save ns conf i g
6. Enter the following command to confirm that your profile was correctly
created.
> show appf w pr of i l e <name>
To remove a profile using the NetScaler command line, you log onto the
NetScaler command line and enter the following command:
> r mappf w pr of i l e <name>
For <name>, you substitute the name of the profile you want to remove.
If the profile is not associated with an active policy, the profile is removed.
If the profile is associated with an active policy, an error message is dis-
played notifying you that the profile is in use, and the profile is not
removed. You must first remove the policy associated with the profile, and
then you can remove the profile.
This concludes the generic procedures for configuring profiles. The remainder of
this chapter contains specific information about configuring a profiles security
checks and settings, and configuring and managing learning. This information is
organized in the same order in which it appears in the Citrix NetScaler
Configuration Utility, but all Application Firewall features and their associated
options can be configured at the NetScaler command line as well.
Configuring the Security Checks
This section describes how to configure the Application Firewall security checks,
and navigate the Configure Application Firewall Profile dialog box, Security
Checks tab.
The Application Firewall supports three types of security checks, which are:
Common Security Checks. Applicable to all types of Web content, and
available for all types of user-created profile.
HTML Security Checks. Applicable to HTML content, and available for
HTML and Web 2.0 profiles.
XML Security Checks. Applicable to XML content, and available for
XML and Web 2.0 profiles.
Common Security Checks
The common security checks supported by the Application Firewall are as
follows:
Start URL security check. Examines the URLs to which incoming
requests are directed, and blocks connections to URLs that are not listed in
the Start URLs list, or that a user has not reached by navigating to them
from listed start URLs.
Deny URL security check. Examines the URLs to which requests are
directed, and blocks connections to all URLs specified in this list.
Cookie Consistency security check. Examines cookies returned with user
requests to see that they match the cookies your Web server set for that user.
If a modified cookie is found, the cookie is stripped from the request before
the request is forwarded to the Web server.
Buffer Overflow security check. Examines requests to detect attempts to
cause a buffer overflow on the Web server.
Credit Card security check. Examines Web server responses, including
headers, for credit card numbers. If this check finds a credit card number in
a response, it either removes the credit card number from the response
before sending it or blocks the response.
Safe Object security check. Allows you to create classes of protected con-
tent, such as social security numbers, and protects them in much the same
manner as it does credit cards.
For a detailed description of the common security checks, see Chapter 8, The
Common Security Checks, on page175.
HTML Security Checks
Form Field Consistency security check. Examines the structure of the
Web forms returned by users to your Web server and verifies that the struc-
ture of the Web form and any default data are unchanged.
Field Formats security check. Examines the data a user returns using a
Web form on your Web site and verifies that the data being returned for
each field is valid for that field.
CSRF Form Tagging. Tags each Web form sent by a protected Web site to
users with a unique and unpredictable FormID, and then examines the Web
forms returned by users to ensure that the supplied FormID is correct. This
check protects against Cross Site Request Forgery (CSRF) attacks.
HTML Cross-Site Scripting security check. Examines requests and
responses for scripts that attempt to access or modify content on a different
Web site than the one on which the script is located. When this check finds
such a script, it either renders the script harmless before forwarding the
request or response to its destination, or it blocks the connection.
HTML SQL Injection security check. Examines requests that contain
form field data for attempts to inject SQL commands into a back-end SQL
database. When this check detects injected SQL code, it either blocks the
request or renders the injected SQL code harmless before forwarding the
request to the Web server.
Caution: If you enable the HTML Cross-Site Scripting check or the
HTML SQL Injection check (or both), your NetScaler appliance is a single
CPU unit, and your protected Web sites accept file uploads or contain Web
forms that produce extremely large POST bodies when a user fills them out,
you should make sure that your Application Firewall is configured
appropriately. For detailed information, see AppendixC, Configuring for
Large Files and Web Pages, on page369.
For a detailed description of the HTML security checks, see Chapter 9, The
HTML Security Checks, on page201.
XML Security Checks
XML Format security check. Examines requests to determine whether
they meet the criteria set by the W3 consortium for well-formed XML.
When this check detects a request that does not meet these criteria, it blocks
that request.
XML Denial-of-Service (DoS) security check. Examines requests to
determine whether they are part of an XML denial-of-service attack. When
this check detects a request that meets the XML DoS criteria, it blocks that
request.
XML Cross-Site Scripting security check. Examines requests and
responses for scripts that attempt to access or modify content on a different
server than the server that hosts the application that hosts the script. When
this check finds such a script, it blocks the connection.
XML SQL Injection security check. Examines requests for attempts to
inject SQL commands into a back-end SQL database. When this check
detects injected SQL code, it blocks the request.
XML Attachment security check. Examines XML requests for attach-
ments that might constitute an attack. When this check detects such an
attachment, it blocks that request.
WS-I security check. Examines requests to determine if they meet the
applications Interoperability (WS-I) standard. When this check detects a
request that does not meet this standard, it blocks that request.
XML Message Validation security check. Examines XML messages and
ensures that they are valid.
XML SOAP Fault Filtering security check. Examines responses from
protected Web sites and filters out XML SOAP faults. This prevents leak-
ing of sensitive information.
For a detailed description of XML security checks, see Chapter 10, The XML
Security Checks, on page235.
Configuring the Security Checks with the
Configuration Utility
You configure the security checks for your profiles in the Configure Application
Firewall Profile dialog box, Checks tab. This dialog box contains a list of all
security checks and the tools you need to configure every option and feature
associated with each check. The figure below shows the Checks tab for a Web 2.0
profile. HTML and XML profiles have shorter lists of security checks, but are
otherwise the same.
The Configure Application Firewall Profile Dialog Box, Checks Tab, Web 2.0 Profile
The Security Checks list consists of six columns. The first contains the name of
the Application Firewall security check. The second, third, fourth, and fifth show
whether blocking, logging, statistics, and learning are enabled or disabled for that
check. The sixth shows the type of check: common, HTML, or XML. In the
lower left-hand corner of the dialog box, beneath the Security Checks list, is the
Modify button.
To modify a particular security check, you first click its name in the Security
Checks list. Next, you click the Modify button to display the Modify Check
dialog box for that rule. The following figure shows the Modify Cookie
Consistency Check dialog box with the General tab displayed.
The Modify Cookie Consistency Check Dialog Box, General Tab
For all checks except the Safe Object check, the General tab is displayed by
default when you first open the check. The Safe Object check lacks the General
tab, and the Settings tab is therefore displayed by default.
In the General tab you configure the Check Actions for each security check. The
check actions are the actions that the Application Firewall performs when a
request or response violates this particular check. The check actions are:
Block. Tells the Application Firewall to block connections that violate this
check. You enable blocking for the rule by checking the Block check box,
and disable blocking by clearing the Block check box.
You might disable blocking for any of a number of reasons, depending on
which check you are configuring, the type of profile you are configuring,
and the web content that profile protects. If you are installing a new Appli-
cation Firewall, you might need to disable blocking for some checks to
prevent false positives while you allow the learning feature to generate an
appropriate list of exceptions (or relaxations) to the security check, to allow
it to protect your Web sites without blocking legitimate content. If you are
configuring a check that offers an alternative to blocking, such as rendering
dangerous content harmless or removing protected information from a
response, you might prefer to use the alternative means of protection. In
some cases, you might want to disable the check entirely.
You enable blocking to tell the Application Firewall to prevent a connection
that violates a security check from being forwarded to your Web server or
the user.
Learn. Tells the Application Firewall to use its learning feature to observe
traffic to and from your protected Web sites, and generate a list of recom-
mended relaxations to this particular security check. You enable learning by
checking the Learn check box, and disable it by unchecking the Learn
check box.
Note: Not all security checks support learning. The Learn check box
appears in this tab for all security checks, but is greyed out if it is not
available for the security check you are configuring.
If you are configuring a security check that supports learning and created a
profile with basic defaults, learning is disabled by default, and you
probably will not want to enable it. The basic defaults are intended to
provide good out-of-the-box protection for Web sites and web content
without requiring the system administrator to do much configuration or
interact with the Application Firewall extensively on an ongoing basis.
Using the learning feature requires both of these things.
If you are configuring a security check that supports learning and created a
profile with advanced defaults, learning is enabled by default. Most users
will prefer to leave learning enabled while theyre configuring a new Appli-
cation Firewall, or when theyve made any significant changes to the
content on a protected Web site, unless they are entirely disabling the
security check they are configuring. It is usually much easier to let learning
do the work of determining the correct relaxations for your Web site, rather
than having to determine which rules are needed and create them manually.
If you are using learning, you normally turn off blocking until learning has
seen enough traffic to generate the necessary list of relaxations. You then
review the learned relaxations and accept those that you want to use. When
learning has seen enough traffic to generate a good list, you re-enable
blocking, turn off learning, and are done.
Log. Tells the Application Firewall to log any connections that violate the
security check you are configuring. You enable logging by checking the
Log check box, and disable it by clearing the Log check box.
You normally will not want to disable logging for any security check unless
you are completely disabling that security check. If anything unexpected
happens, the logs are an important resource for troubleshooting.
Statistics. Tells the Application Firewall to generate statistics for connec-
tions that violate the security check you are configuring. You enable statis-
tics by checking the Statistics check box, and disable it by clearing the
Statistics check box.
You normally will not want to disable statistics for any security check
unless you are completely disabling that security check. Statistics can help
you monitor the types of attacks that a particular check is seeing, and
determine how effective that check is on your protected Web sites.
The following additional check action appears in the HTML Cross-Site Scripting
and HTML SQL Injection checks:
Transformation. Tells the Application Firewall to modify any cross-site
scripts or SQL injection code it finds in a users request to render them
harmless and then pass the modified request on to the Web server, rather
than blocking the request outright. For the Cross-Site Scripting check, this
check action is labeled Transform cross-site scripts. For the SQL Injec-
tion check, it is labeled Transform SQL special characters.
You can use Transformation to allow legitimate user requests to be passed
to your protected Web servers safely when those requests might inadvert-
ently contain injected SQL special characters or keywords, or cross-site
scripting commands. You normally will enable either Transformation or
Blocking, but not both. If you have blocking enabled, enabling transfor-
mation is redundant because the Application Firewall is already blocking
access to those web pages that contain cross-site scripts or injected SQL
code.
Caution: If you enable this feature, your NetScaler appliance is a single
CPU unit, and your protected Web sites accept file uploads or contain Web
forms that produce extremely large POST bodies when a user fills them out,
you should ensure that your Application Firewall is configured
appropriately. For detailed information, see AppendixC, Configuring for
Large Files and Web Pages, on page369.
The following additional check action appears in the XML SOAP Fault Filtering
check:
Remove. Tells the Application Firewall to remove XML SOAP Fault errors
from responses before forwarding those responses to the user.
In addition, for certain security checks there is a Parameters section that contains
configuration item specific to that security check. The Start URL rule contains the
following parameters.
URL closure. Tells the Application Firewall to allow users to access any
web page on your Web site by clicking a hyperlink on any other web page
on your Web site. This ensures that users who access your home page can
easily navigate to any content that is reachable by clicking hyperlinks from
that point.
Validate Referer Header. Tells the Application Firewall to verify that the
Referer header in a Request that contains Web form data comes from your
protected Web server rather than from another Web site. This verifies that
your Web site, rather than an outside attacker, is the source of that Web
form. This protects against cross-site request forgeries (CSRF) without
requiring form tagging, which is more CPU-intensive than header checks.
For more information about CSRF, see The CSRF Form Tagging Check
on page215.
The Application Firewall can handle the HTTP Referer header in one of the
following three ways, depending on which option you select in the drop-
down list:
- Off. Do not validate the Referer header. This is the default setting for
profiles created with basic defaults.
- If-Present. Validate the Referer header if a Referer header exists. If
an invalid Referer header is found, the request violates the Start URL
security check. If no Referer header exists, the request does not
violate the Start URL security check. This is the default setting for
profiles created with advanced defaults.
This option allows the Application Firewall to perform Referer
header validation on requests that contain a Referer header, but not
block requests from users whose browsers do not set the Referer
header or who use web proxies or filters that remove that header.
- Always. Always validate the Referer header. If there is no Referer
header, or if the Referer header is invalid, the request violates the
Start URL security check.
The Field Formats check contains the following parameters:
Field Type. Sets the field type assigned to form fields in web forms that do
not have a field type.
Caution: If you set a restrictive default field type, and do not disable
blocking until you are certain that the field types assigned to your form
fields are correct, users may be unable to use your web forms.
Minimum Length. Sets the default minimum data length assigned to form
fields in web forms that do not have an explicit setting.
Maximum Length. Sets the default maximum data length assigned to form
fields in web forms that do not have an explicit setting.
Both the HTML and the XML SQL Injection checks contain the following
parameters:
Restrict checks to fields containing SQL special characters. Tells the
Application Firewall to check only form data that contains SQL special
characters for violations of the HTML SQL Injection check rules. Since
most SQL databases ignore any SQL commands that are not accompanied
by the appropriate SQL special characters, this usually reduces server load
without compromising security.
SQL Comments Handling. Tells the Application Firewall how to handle
SQL comments in the web pages it checks. By default, the Application
Firewall treats all SQL comments as it does any other content, and checks
the entire request for SQL special characters and keywords. Since SQL
servers ignore any text they recognize as part of a comment, you can help
prevent false positives by configuring the Application Firewall to recognize
SQL comments and skip them when checking a request for violations of the
SQL injection check. You can also thwart attackers who may send requests
containing comments and observe your Web servers response to profile
your SQL servers behavior and identify which SQL software it uses.
The HTML Cross-Site Scripting check contains the following parameter.
Check complete URLs for cross-site scripting. Tells the Application Fire-
wall to check the entire URL, instead of just the query portion of the URL,
for violations of the HTML Cross-Site Scripting check.
To configure most options specific to a particular security check, and manually
add or modify relaxations, you click the Checks tab. The figure below shows the
Cookie Consistency Check dialog box with the Checks tab displayed.
The Modify Cookie Consistency Check Dialog Box, Checks Tab
This tab looks much the same for the majority of the security checks, although it
is significantly different in the Modify Check dialog box for the Buffer Overflow,
Credit Card, XML DOS, WS-I and Safe Object checks. In the other checks, this
dialog box consists of a list of relaxations that covers about three-fourths of the
tab, and a details area at the bottom that displays detailed information about the
specific relaxation that is selected.
You can manually add a new relaxation to the relaxations list by clicking the Add
button to display the Add Check Relaxation dialog box for the security check you
are configuring. The Add Cookie Consistency Check Relaxation dialog box is
shown below.
The Add Cookie Consistency Check Relaxation Dialog Box
In the Cookie Name section, you have several choices.
Literal. You can type a literal string representing the name of the cookie.
Regular Expression. You can enter a PCRE-compatible regular expression
that represents a cookie name, or a pattern that will match many cookie
names. If you choose to type a regular expression, you can enter it in one of
three ways:
Directly. You can type the regular expression directly into the text
field.
Using the Regex Tokens. If you prefer to type the regular expression
manually into the text field, but would like assistance with certain
regular expressions elements, you can click the Regex Tokens button
to display the Regex Tokens menu, shown below, and choose regular
expressions elements from the drop-down menu.
The Add Cookie Consistency Check Relaxation Dialog Box,
with Regex Tokens Menu Displayed
When you choose an element from the Regex Tokens menu, it is
placed at the cursor location in the Cookie Name text area. You can
then copy and paste these symbols just as if you had typed them.
Using the Regex Editor. You can click the Regex Editor button to
display the Regular Expressions Editor, shown below.
The Application Firewall Regular Expression Editor
You use the Regular Expression Editor by editing the default regular
expression in the Regular Expression text area. You can modify or
remove the default expression, type new text, and use the Regex
Tokens menu just below and to the left of the text area to help you
add new regular expression elements to your expression. If you want
to clear the window and start over, you can click the Clear button just
below and to the right of the text area. As you type, the Analyzer
window updates its detailed description of your regular expression.
To test your expression, you can type or paste a cookie name into the
Test Regular Expression text area. If the cookie matches your regular
expression, it appears in green. If it does not, it appears in red.
When you have finished creating your regular expression and are
satisfied that it will do what you want, you click the OK button to
close the Regular Expression Editor and return to the Add Cookie
Consistency Check Relaxation dialog box.
The other Add Check Relaxation dialog boxes differ from this one to a lesser or
greater extent. Users who want to manually add a relaxation for a particular
security check should see the section about that check beginning in Chapter 8,
The Common Security Checks, on page175, or beginning in Chapter 9, The
HTML Security Checks, on page201, or beginning in Chapter 10, The XML
Security Checks, on page235, and read the specific information about that
security check.
You can manually edit an existing relaxation by selecting the relaxation, and then
clicking the Modify button to display the Modify Check Relaxation dialog box
for the security check you are configuring. The Modify Cookie Consistency
Check Relaxation dialog box is shown below.
The Modify Cookie Consistency Check Relaxation Dialog Box
As you can see, except for the title and the presence in the dialog box of the
relaxation data, this dialog box is identical to the corresponding Add Check
Relaxation dialog box. Like the Add Check Relaxation dialog boxes, the other
Modify Check Relaxation dialog boxes differ from this one to a lesser or greater
extent. For specific information about a particular security check, you should see
the section about that security check in Chapter 8, The Common Security
Checks, on page175, or one of the following two chapters.
You remove a relaxation by clicking the entry for that relaxation once, to
highlight it, then clicking the Remove button. The dialog box tab refreshes, and
the relaxation you chose is removed.
Configuring the Security Checks at the NetScaler
Command Line
You configure the security checks at the NetScaler command line by typing the
following command with the appropriate parameters:
set appf w pr of i l e <name> [ - t ype ( HTML | XML | HTML XML) ]
- <ar g1> [ - <ar g2> ]
For <name>, you substitute the name of the profile you are configuring. For
<type>, you substitute either HTML (for an HTML profile), XML (for an XML
profile), or HTML XML (for a Web 2.0 profile). For <arg1>, you substitute the
first parameter setting. For <arg2>, you substitute the second parameter setting,
if any. You can add an unlimited number of additional parameter settings after
these.
For example, to configure the Start URL actions for the profile named Example
to block, log and generate statistics for requests that violate the Start URL
security check, you would type the following command:
set appf w pr of i l e Exampl e - st ar t URLAct i on bl ock l og st at s
This command tells the Application Firewall to block requests that violate the
Start URL security check, log all such requests, and generate statistics for the
Start URL security check. If you want to configure the XML DoS security check
to act similarly, you would type the following:
set appf w pr of i l e Exampl e - xml DoSAct i on bl ock l og st at s
You can configure the Application Firewall to perform this set of actions for any
security check by substituting the appropriate parameter for that security check
for -xmlDoSAction.
Caution: When you set a parameter at the NetScaler command line, all options
for that parameter are overwritten by the settings you specify. You must therefore
explicitly include all options you want when you configure a parameter at the
NetScaler command line. If you do not, your command will reset any option you
did not explicitly mention to the default setting, which can cause unexpected
results.
A list of all parameters for the Application Firewall security checks is provided in
the following table. To the right of each parameter the description tells you which
security check that parameter applies to and which type of profile is affected by
that security check.
Security checks that affect all profiles are labeled common
Security checks that affect HTML profiles and HTML content in Web 2.0
profiles are labeled HTML
Security checks that affect XML profiles and XML content in Web 2.0 pro-
files are labeled XML
Beneath this information is a list of the options for that parameter, and a
description of the effect of each option.
Application Firewall Profile Security Check Parameters
- st ar t URLAct i on <ar g> Applies to: Start URL security check. (common)
-startURLAction none: Disables the Start URL security
check.
-startURLAction block: Enables blocking for the Start
URL check.
-startURLAction learn: Enables learning for the Start
URL check.
-startURLAction log: Enables logging for the Start URL
check.
-startURLAction stats: Enables statistics for the Start
URL check.
- st ar t URLCl osur e ( ON | OFF ) Applies to: Start URL security check. (common)
ON enables Start URL closure; OFF disables Start URL
closure.
- exempt Cl osur eURLsFr omSecur i t yChecks
Applies to: Start URL security check. (common
ON exempts requests that pass the Start URL Closure test
from additional security checks; OFF does not exempt these
requests from further checking.
- denyURLAct i on <ar g>
Applies to: Deny URL security check. (common)
-denyURLAction none: Disables the Deny URL security
check.
-denyURLAction block: Enables blocking for the Deny
URL check.
-denyURLAction log: Enables logging for the Deny URL
check.
-denyURLAction stats: Enables statistics for the Deny
URL check.
- cooki eConsi st encyAct i on <ar g>
Applies to: Cookie Consistency security check. (common)
-cookieConsistencyAction none: Disables the Cookie
Consistency security check.
-cookieConsistencyAction block: Enables blocking for
the Cookie Consistency check.
-cookieConsistencyAction learn: Enables learning for
-cookieConsistencyAction log: Enables logging for the
Cookie Consistency check.
-cookieConsistencyAction stats: Enables statistics for
- f i el dConsi st encyAct i on <ar g>
Applies to: Form Field Consistency security check.
(HTML)
-fieldConsistencyAction none: Disables the Form
Field Consistency security check.
-fieldConsistencyAction block: Enables blocking for
the Form Field Consistency check.
-fieldConsistencyAction learn: Enables learning for
-fieldConsistencyAction log: Enables logging for the
Form Field Consistency check.
-fieldConsistencyAction stats: Enables statistics for
- cr ossSi t eScr i pt i ngAct i on <ar g>
Applies to: HTML Cross Site Scripting security check.
(HTML)
-crossSiteScriptingAction none: Disables the Cross-
Site Scripting security check.
-crossSiteScriptingAction block: Enables blocking
for the Cross-Site Scripting check.
-crossSiteScriptingAction learn: Enables learning
-crossSiteScriptingAction log: Enables logging for
the Cross-Site Scripting check.
-crossSiteScriptingAction stats: Enables statistics
-
cr ossSi t eScr i pt i ngTr ansf or mUnsaf eHTML
Applies to: HTML Cross Site Scripting security check.
(HTML)
ON enables the Application Firewall to modify any HTML
that violates the Cross-Site Scripting check so that it does
not violate this check; OFF disables this feature.
- cr ossSi t eScr i pt i ngCheckCompl et eURLs Applies to: HTML Cross Site Scripting security check.
(HTML)
ON tells the Application Firewall to check complete URLs
for any HTML that violates the Cross-Site Scripting check;
OFF tells the Application Firewall to check only the query
portion of URLs.
- SQLI nj ect i onAct i on <ar g>
Applies to: HTML SQL Injection security check. (HTML)
-SQLInjectionAction none: Disables the SQL Injection
security check.
-SQLInjectionAction block: Enables blocking for the
SQL Injection check.
-SQLInjectionAction learn: Enables learning for the
-SQLInjectionAction log: Enables logging for the SQL
Injection check.
-SQLInjectionAction stats: Enables statistics for the
- SQLI nj ect i onTr ansf or mSpeci al Char s (
ON | OFF )
ON enables the Application Firewall to modify any SQL
special characters that violates the SQL Injection check so
that they do not violate this check; OFF disables this feature.
-
SQLI nj ect i onOnl yCheckFi el dsWi t hSQLCha
r s ( ON | OFF )
ON tells the Application Firewall to check only Web form
fields that contain SQL special characters for violations of
the SQL Injection check; OFF tells the Application Firewall
to check all Web form fields.
- SQLI nj ect i onPar seComment s <ar g>
Applies to: HTML SQL Injection security check (HTML)
-SQLInjectionParseComments checkall: Tells the
Application Firewall to check all comments for SQL.
-SQLInjectionParseComments ansi: Tells the
Application Firewall to skip ANSI comments when
checking for SQL.
-SQLInjectionParseComments nested: Tells the
Application Firewall to skip nested comments when
checking for SQL.
-SQLInjectionParseComments ansinested: Tells the
Application Firewall to skip ANSI and nested comments
when checking for SQL.
- f i el dFor mat Act i on <ar g>
Applies to: Field Format security check. (HTML)
-fieldFormatAction none: Disables the Field Formats
security check.
-fieldFormatAction block: Enables blocking for the
Field Formats check.
-fieldFormatAction learn: Enables learning for the
-fieldFormatAction log: Enables logging for the Field
Formats check.
-fieldFormatAction stats: Enables statistics for the
- def aul t Fi el dFor mat Type <st r i ng> Applies to: Field Format security check. (HTML)
Sets the default Field Format for all form fields in all Web
forms protected by the current profile to <string>, where
<string> equals either a default or user-defined field
type.
- def aul t Fi el dFor mat Mi nLengt h <i nt > Applies to: Field Format security check. (HTML)
Sets the default minimum length for all form fields in all
Web forms protected by the current profile to <int>, where
<int> equals a positive integer.
- def aul t Fi el dFor mat MaxLengt h <i nt >
Applies to: Field Format security check. (HTML)
Sets the default maximum length for all form fields in all
Web forms protected by the current profile to <int>, where
<int> equals a positive integer.
- buf f er Over f l owAct i on <ar g>
Applies to: Buffer Overflow security check. (common)
-bufferOverflowAction none: Disables the Buffer
Overflow security check.
-bufferOverflowAction block: Enables blocking for the
Buffer Overflow check.
-bufferOverflowAction log: Enables logging for the
-bufferOverflowAction stats: Enables statistics for the
- buf f er Over f l owMaxURLLengt h <i nt >
Sets the default maximum length for URLs in requests
directed to Web sites protected by the current profile to
<int>, where <int> equals a positive integer.
- buf f er Over f l owMaxHeader Lengt h <i nt >
Sets the default maximum length for HTTP headers in
requests directed to Web sites protected by the current
profile to <int>, where <int> equals a positive integer.
- buf f er Over f l owMaxCooki eLengt h <i nt > Applies to: Buffer Overflow security check. (common)
Sets the default maximum length for cookies in requests
directed to Web sites protected by the current profile to
<int>, where <int> equals a positive integer.
- cr edi t Car dAct i on <ar g>
Applies to: Credit Card security check. (common)
-creditCardAction none: Disables the Credit Card
security check.
-creditCardAction block: Enables blocking for the
Credit Card check.
-creditCardAction log: Enables logging for the Credit
Card check.
-creditCardAction stats: Enables statistics for the
Credit Card check.
- cr edi t Car d ( vi sa | mast er car d |
di scover | amex | j cb | di ner scl ub )
Enables protection for the designated credit card.
- cr edi t Car dMaxAl l owed <i nt >
Sets the maximum number of credit card numbers that the
Application Firewall should allow before blocking a
response to <int>, where <int> equals a positive integer.
- cr edi t Car dXOut ( ON | OFF ) Applies to: Credit Card security check. (common)
ON tells the Application Firewall to mask any credit card
numbers it detects in a response using the letter x; OFF
disables this feature. For example, a credit card number of
1111-2222-3333-4567 would be displayed as xxxx-xxxx-
xxxx-4567.
- xml DoSAct i on <ar g>
Applies to: XML Denial-of-Service security check. (XML)
-xmlDoSAction none: Disables the XML Denial-of-
Service security check.
-xmlDoSAction block: Enables blocking for the XML
Denial-of-Service check.
-xmlDoSAction learn: Enables learning for the XML
-xmlDoSAction log: Enables logging for the XML
-xmlDoSAction stats: Enables statistics for the XML
- xml For mat Act i on <ar g>
Applies to: XML Format security check. (XML)
-xmlFormatAction none: Disables the XML Format
security check.
-xmlFormatAction block: Enables blocking for the XML
Format check.
-xmlFormatAction log: Enables logging for the XML
Format check.
-xmlFormatAction stats: Enables statistics for the XML
Format check.
- xml SQLI nj ect i onAct i on <ar g>
Applies to: XML SQL Injection security check. (XML)
-xmlSQLInjectionAction none: Disables the XML SQL
Injection security check.
-xmlSQLInjectionAction block: Enables blocking for
the XML SQL Injection check.
-xmlSQLInjectionAction log: Enables logging for the
XML SQL Injection check.
-xmlSQLInjectionAction stats: Enables statistics for
the XML SQL Injection check.
-
xml SQLI nj ect i onOnl yCheckFi el dsWi t hSQL
Char s ( ON | OFF )
ON tells the Application Firewall to check only XML
elements that contain SQL special characters for violations
of the SQL Injection check; OFF tells the Application
Firewall to check all XML elements.
- xml SQLI nj ect i onPar seComment s <ar g>
-xmlSQLInjectionParseComments checkall: Tells the
Application Firewall to check all comments for SQL.
-xmlSQLInjectionParseComments ansi: Tells the
Application Firewall to skip ANSI comments when
checking for SQL.
-xmlSQLInjectionParseComments nested: Tells the
Application Firewall to skip nested comments when
checking for SQL.
-xmlSQLInjectionParseComments ansinested: Tells
the Application Firewall to skip ANSI and nested comments
when checking for SQL.
- xml XSSAct i on <ar g>
Applies to: XML Cross-Site Scripting security check.
(XML)
-xmlXSSAction none: Disables the XML Cross-Site
Scripting security check.
-xmlXSSAction block: Enables blocking for the XML
Cross-Site Scripting check.
-xmlXSSAction log: Enables logging for the XML Cross-
Site Scripting check.
-xmlXSSAction stats: Enables statistics for the XML
Cross-Site Scripting check.
- xml WSI Act i on <ar g> Applies to: WS-I security check. (XML)
-xmlWSIAction none: Disables the WS-I security check.
-xmlWSIAction block: Enables blocking for the WS-I
check.
-xmlWSIAction learn: Enables learning for the WS-I
check.
-xmlWSIAction log: Enables logging for the WS-I check.
-xmlWSIAction stats: Enables statistics for the WS-I
check.
- xml At t achment Act i on <ar g>
Applies to: XML Attachment security check. (XML)
-xmlAttachmentAction none: Disables the XML
Attachment check.
-xmlAttachmentAction block: Enables blocking for the
XML Attachment check.
-xmlAttachmentAction learn: Enables learning for the
-xmlAttachmentAction log: Enables logging for the
-xmlAttachmentAction stats: Enables statistics for the
- xml Val i dat i onAct i on <ar g>
Applies to: XML Validation security check. (XML)
-xmlValidationAction none: Disables the XML
Validation check.
-xmlValidationAction block: Enables blocking for the
XML Validation check.
-xmlValidationAction log: Enables logging for the
-xmlValidationAction stats: Enables statistics for the
- XMLSOAPFaul t Act i on Applies to: XML SOAP Fault Filtering security check.
(XML)
-xmlSOAPFaultAction none: Disables the XML SOAP
Fault Filtering check.
-xmlSOAPFaultAction block: Enables blocking for the
XML SOAP Fault Filtering check.
-xmlSOAPFaultAction log: Enables logging for the XML
SOAP Fault Filtering check.
-xmlSOAPFaultAction stats: Enables statistics for the
XML SOAP Fault Filtering check.
-xmlSOAPFaultAction remove: Enables removal of
SOAP Faults from responses for the XML SOAP Fault
Filtering check.
- CSRFt agAct i on Applies to: CSRF Form Tagging security check.
-CSRFtagAction none: Disables the XML SOAP Fault
Filtering check.
-CSRFtagAction block: Enables blocking for the XML
-CSRFtagAction log: Enables logging for the XML
-CSRFtagAction stats: Enables statistics for the XML
Configuring the Profile Settings
This section describes how to configure the Application Firewall settings. The
Application Firewall settings control which error URLs the Application Firewall
redirects users to when a request or response is blocked, whether the Application
Firewall strips comments from responses before forwarding them to users, and
the default charset and default field type.
Configuring the Profile Settings by Using the
Configuration Utility
This section describes how to configure the Application Firewall settings using
the configuration utility.
When using the configuration utility, you configure the Application Firewall
settings in the Configure Application Firewall Profile dialog box, Settings tab,
shown below.
- Ref er er Header Check
Applies to: Start URL security check.
-RefererHeaderCheck none: Disables the Referer Header
check parameter.
-RefererHeaderCheck if-present: Runs the Referer
Header check if a Referer header is present, and blocks
requests that fail the check. Otherwise, does not block the
request.
-RefererHeaderCheck always: Always runs the Referer
Header check, and blocks any request that does not have an
appropriate Referer header.
- r esponseCont ent Type
Note: The Settings tab contains many options, which means that when it is first
displayed, only the upper options appear. A scroll bar to the right of the options
allows you to scroll down to the remaining options. You can also adjust the size
of dialog boxes to display all options at once, as shown above.
Depending upon the profile type, this tab may contain any of the following
configuration options:
HTML Settings.
HTML Error. When it blocks a users request, the Application
Firewall can either redirect the users request to a designated
Redirect URL, or it can display an HTML Error Object.
Redirect URL. To redirect the users request to a
designated Redirect URL, you click the radio button
beside Redirect URL, then type the URL you want in the
text box to the right. The default setting is /, which
redirects the user to the protected Web sites home page.
HTML Error Object. To display an HTML Error
Object from the Application Firewalls cache, you click
the radio button beside HTML Error Object, then click
the down arrow to the right of the HTML Error Object
list box and choose the HTML error object you want to
display. If you have not already imported the HTML
error object you want into the Application Firewall
configuration, you click the Import button to do so.
object.
Charset. The default charset (character set) used by the Citrix
NetScaler Configuration Utility. By default, the Application
Firewall charset is set to ISO-8859-1, the western European
encoding suitable for English and other western European
languages. A list box containing valid ISO character encoding
types supported by the Application Firewall appears to the right
of the Charset label. You can change the charset for your
Application Firewall to any other supported charset by clicking
the down arrow to the right of the list box, and picking another
encoding from the list.
Strip HTML Comments. Tells the Application Firewall to
remove any HTML comments from the web pages on your
Web site before sending them to users. This feature is disabled
by default. You enable this feature by checking the Strip HTML
Comments check box.
Exclude Uploaded Files From Security Checks. Tells the
Application Firewall not to scan uploaded files for violations of
its security checks. This feature is disabled by default. You can
enable it by selecting the check box. If users will upload large
files to your protected Web sites, enabling this feature will
improve performance without significantly degrading security.
Exempt Closure URLs From Security Checks. Tells the
Application Firewall not to run URL-based security checks on
URLs accessed by clicking a link on a web page that the user
legitimately accessed on your protected Web site. This feature
is enabled by default. You can disable it by clearing the check
box.
Enable Form Tagging. Tells the Application Firewall to tag
the form fields in Web forms in the HTML pages on your
protected Web sites. This feature is enabled by default. You can
disable this feature by unchecking the check box.
Canonicalize HTML Response. Tells the Application Firewall
to modify responses sent by your protected Web servers to
ensure that they contain only valid HTML. This feature is
enabled by default. You can disable this feature by unchecking
the check box.
Invalid Percent Handling. Specifies whether the Application
Firewall should use Apache, ASP, or secure mode for invalid
percent handling. Secure mode is the default.
Default Content Type. Specifies the content-type that the
Application Firewall should assume when an HTML request or
response does not specify a content-type. Can be set separately
for Request and Response. Request Default: None (blank).
Response Default: application/octet-stream.
XML Settings.
XML Error Object. You choose the XML Error Object you
want the Application Firewall to display when it blocks a users
request for XML content here, by clicking the down arrow to
the right of the XML Error Object list box and choose the XML
error object you want to display. If you have not already
imported the XML error object you want into the Application
Firewall configuration, you click the Import button to do so.
object.
Common Settings.
Post Body Limit. To tell the Application Firewall the
maximum size of POST body that it should allow, type the
maximum in the text box as an integer representing a number of
bytes. Default: 20,000,000.
Custom Settings. Here you choose a custom settings file from
the files uploaded to the Application Firewall in the Imports
pane. The custom settings file contains customized lists of SQL
special characters, SQL keywords, cross-site scripting allowed
tags, and cross-site scripting allowed attributes. The SQL
injection and cross-site scripting security checks then use the
customized lists instead of the built-in default lists.
Check Request Headers. Tells the Application Firewall to
check request headers and cookies for HTML and XML SQL
Injection and Cross-Site Scripting check violations. Not
selected by default.
Log Every Policy Hit. Tells the Application Firewall to log
every connection that matches an Application Firewall policy
to the NetScaler log. Unselected by default.
Configuring the Profile Settings at the NetScaler
Command Line
You configure the settings at the NetScaler command line by typing the following
command with the appropriate parameters:
set appf w pr of i l e <name> - <ar g1> [ - <ar g2> ]
For <name>, you substitute the name of the profile you are configuring. For
<arg1>, you substitute the first setting. For <arg2>, you substitute the second
setting, if any. You can add an unlimited number of additional settings after these.
For example, to configure the HTML Error URL for the profile named
Example to http://www.example.com/404.html, you would type the
following command:
set appf w pr of i l e Exampl e - er r or URL " ht t p: / / www. exampl e. com/
404. ht ml "
This command tells the Application Firewall to redirect blocked requests and
responses to that URL. If you want to enable stripping of HTML comments from
responses, you would type the following:
set appf w pr of i l e Exampl e - st r i pComment s ON
You can configure any of the Application Firewall settings similarly, by
substituting the appropriate parameter and options.
Caution: When you set a parameter at the NetScaler command line, all options
for that parameter are overwritten by the settings you specify. You must therefore
explicitly include all options you want when you configure a parameter at the
NetScaler command line. If you do not, your command will reset any option you
did not explicitly mention to the default setting, which can cause unexpected
results.
A list of all parameters for the Application Firewall settings is provided in the
following table. To the right of each parameter is the description, which tells you
which setting the parameter controls. It then provides a list of the options for that
parameter, and a description of the effect of each option.
Application Firewall Profile Settings Parameters
- ht ml Er r or Obj ect <st r i ng> Applies to: HTML Error Object, which is sent to the users
browser when a request for an HTML web page is blocked.
Sets the HTML Error Object to <string>, where <string>
equals the name of an HTML error object uploaded to the
Application Firewall in the Engine Settings Imports page.
- xml Er r or Obj ect <st r i ng> Applies to: XML Error Object, which is sent to the users
browser whenever a request for an XML URL is blocked.
Sets the XML Error Page to <string>, where <string>
equals the name of an XML error object uploaded to the
Application Firewall in the Engine Settings Imports page.
- er r or URL <expr essi on> Applies to: HTML Redirect URL setting.
Sets the HTML Redirect URL to <string>, where <string>
equals either a literal URL or a PCRE-compatible regular
expression that evaluates to a URL.
- useHTMLEr r or Obj ect ( ON | OFF )
Applies to: HTML Error Object.
ON tells the Application Firewall to use the HTML error object
when blocking a user request for HTML content; OFF tells the
Application Firewall to use the redirect URL when blocking a
user request for HTML content.
- st r i pComment s ( ON | OFF )
Applies to: HTML Comment Stripping.
ON tells the Application Firewall to strip HTML comments from
responses before sending them to users; OFF tells the
Application Firewall to send responses to users unmodified.
- def aul t Char Set <st r i ng> Applies to: Default Character Setting.
Sets the default charset to <string>, where <string> equals
one of the charsets supported by the Application Firewall. For a
list of charsets and an explanation of each, see AppendixA,
PCRE Character Encoding Format, on page347.
- post BodyLi mi t <i nt eger > Applies to: Maximum size of HTML POST body.
Sets the maximum size of any HTML POST body a user is
allowed to send to your protected Web servers to the number of
bytes specified in <i nt eger >. The Application Firewall blocks
any user request that contains an HTML POST body larger than
the maximum limit you set. By default, this parameter is unset,
which means that the Application Firewall will not enforce a
maximum limit on POST BODY size.
- canoni cal i zeHTMLResponse ( ON |
OFF )
Applies to: HTML responses.
ON tells the Application Firewall to modify (or canonicalize)
HTML responses sent by your protected Web servers to users to
ensure that they meet the HTML 4.0 standard. OFF tells the
Application Firewall to send HTML responses without
modifying them.
- enabl eFor mTaggi ng ( ON | OFF )
Applies to: HTML Web forms.
ON tells the Application Firewall to tag the form fields in Web
forms sent by your protected Web servers. This allows certain
security checks to operate more smoothly. OFF tells the
Application Firewall not to tag form fields in your Web forms.
- excl udeFi l eUpl oadFr omChecks
Applies to: All Requests (common)
ON tells the Application Firewall to skip uploaded files when
running security checks on Web form requests containing data;
OFF tells the Application Firewall to run its security checks on
all parts of the request.
- i nval i dPer cent Handl i ng
Applies to: HTML Requests
-invalidPercentHandling apache: Uses Apache mode.
-invalidPercentHandling ASP: Uses ASP mode.
-invalidPercentHandling secure: Uses secure mode
- checkRequest Header s ( ON | OFF )
Applies to: All Requests (common)
ON tells the Application Firewall to check request headers for
HTML and XML SQL Injection and HTML Cross-Site
Scripting check violations; OFF disables this check.
Application Firewall Profile Settings Parameters
Configuring the Learning Feature
The Application Firewall learning feature is a repetitive pattern filter that
observes activity on a Web site or application protected by the Application
Firewall, to determine what constitutes normal activity on that Web site or
application. It then generates a list of configuration options for supported security
checks.
The default Application Firewall security checks are restrictive; they recognize
only legitimate activity on protected Web sites and applications. If a security
check detects a request or response that falls outside its default security rules, the
Application Firewall blocks that request or response. This type of security model
is called a positive security model. The positive security model enables the
Application Firewall to protect Web applications from unknown types of attacks
as well as known or common attacks, but it can also block legitimate traffic if the
protected Web site configuration is complex, because this type of firewall
requires a great deal of information about the Web sites it protects and how users
normally interact with those sites.
Profiles created with basic defaults have a set of relaxations already in place that
are appropriate for most Web site content that does not contain complex scripts or
unorthodox methods of access to SQL databases, or that does not handle sensitive
private information. Learning is not enabled by default for profiles created with
basic defaults, and is probably not needed unless you need to modify part of this
configuration.
Profiles created with advanced defaults are more restrictive, and require that you
spend time configuring them appropriately. Learning makes this task
considerably easier. If you attempted purely manual configuration for any but the
simplest Web site, you would have to do the following:
Enter all URLS that users will access directly to begin a session on your
protected Web sites, such as the application home pages, into the list of
Start URLs.
Add any cookies that are created or modified legitimately by the client
browser to the list of cookies that are allowed to violate the Cookie Consis-
tency check.
Add any Web forms that contain form fields that the users browser may
add or delete, or whose types the browser may change, in the list of Web
forms allowed to violate the Form Field Consistency check.
Add any Web forms that violate the HTML SQL Injection check or HTML
Cross-Site Scripting check to the relaxation lists for these checks.
In addition, to optimize security, you would need to consider the following:
You should review and enable the default Deny URL expressions in the
Deny URL check.
You probably should manually create an appropriate Field Format assign-
ment for each form field in each Web form on your Web site in the Field
Format check.
If any of your Web sites handles customer credit card numbers, you should
enable protection for the credit card types it accepts in the Credit Card
check.
If your company has its own credit cards or other sensitive customer infor-
mation that can be used to place orders, you should create an appropriate
rule to protect that information using the Safe Object check.
Instead, you can enable learning, let it observe traffic to and from your Web sites,
and then decide which learned relaxations to accept and which to reject. Or you
can create some relaxations manually and use the learning feature to generate
others.
The Learning feature is supported for the following Application Firewall security
checks:
Start URL security check
Cookie Consistency security check
Form Field Consistency security check
Field Formats security check
HTML Cross-Site Scripting security check
HTML SQL Injection security check
XML Denial-of-Service (DoS) security check
XML Attachment security check
WS-I security check
The security checks available in any given profile depend on the type of profile.
In the Configure Web Application Firewall Profile, Configure XML
Application Profile, or Configure Web 2.0 Application Firewall dialog box,
click the Learning tab to display a list of the available security checks that
support the learning feature.
Beneath the list are two text boxes in which you can set learning thresholds for a
particular security check after you click the list entry for that security check. You
might need to configure the thresholds so that you base learned relaxations on an
appropriate number of user sessions and observed violations of the security check
that you are configuring. If the thresholds are set too high, learning will proceed
slowly and you might not generate all of the configuration options you need for
your sites legitimate users. If the thresholds are set too low, the learning feature
may generate configuration options that allow attacks or misuse of your Web site
or application.
There are two thresholds:
Minimum number threshold. Depending on which security checks learn-
ing settings you are configuring, the minimum number threshold might
refer to the minimum number of total user sessions that the Application
Firewall must observe, the minimum number of requests only, or the mini-
mum number of times it has seen a specific form field. By default, this is set
to 1.
Percentage of times threshold. Depending on which security checks
learning settings you are configuring, the percentage of times threshold
might refer to the percentage of total observed user sessions that violated
the security check, the percentage of requests only, or the percentage of
times a form field matched a particular field type. By default, this is set to 0.
Note: Thresholds are not supported for the XML Denial of Service attack, so
the learning thresholds do not appear in the learning tab when it is selected.
Beneath the thresholds, under Profile Learned Rules, you can click Remove All
Learned Data to clear all unreviewed learned data for this security check from
the learning features database. Forcing the learning feature to start over can
significantly improve the quality of learned configuration options and prevent
errors if you have made significant changes to your Web site or application while
learning was enabled.
Note: Clicking the Remove All Learned Data button does not remove any
learned rules that you have already reviewed and implemented. It just removes all
learned data that you have not yet reviewed for the selected security check.
When enabled, the learning feature analyzes all traffic to and from your Web sites
and determines how your users normally access and interact with your Web sites.
It uses this information to create recommended configuration options (often
called learned relaxations) that allow users to continue accessing your Web site
as they normally do without providing an opening for an attacker.
After the Application Firewall generates its list of recommended configuration
options for a particular security check, you must review those configuration
options and either accept (deploy) them or reject (skip) them.
Note: A learned configuration option is not in effect until you review and
deploy it.
To review the learned relaxations for a security check
Start client. (For instructions, see To log on to the configuration utility on
page40.)
2. In the Menu tree, expand Application Firewall, and then click Profiles to
display the Profiles page.
3. Select the profile that you want to configure, and, in the lower left-hand
corner of the details pane, click Open.
4. Click the Learning tab.
5. In the list of supported security checks at the top of the dialog box, select
the security check for which you want to review learning, and then click
Manage Rules.
A new dialog box opens and displays a list of all observed patterns that
violate the security check you selected, but that also appear to represent
normal behavior for your protected Web site or application. The patterns
are in PCRE regular expressions format.
6. Review the learned patterns for your protected Web site or application.
You can do this in one of two ways:
Directly. You can review the actual learned patterns as displayed in
the window.
A. Click the first learned relaxation once, to highlight it, and
choose how you want to handle it.
If you want to modify it and then accept it, click Edit &
Deploy, edit the regular expression, and click OK to save
your changes and deploy the learned relaxation.
If you want to accept it without modifications, click
Deploy.
If you want to remove it from the list without deploying
it, click Skip.
B. Click each learned relaxation in turn, and repeat the previous
step to review it.
C. When you have finished reviewing learned relaxations, click
Close to close the Manage Learned Rules dialog box and
return to the Configure Application Firewall Profile dialog
box.
Learning Visualizer. You can review the learned data in the
Learning Visualizer, a graphic window that displays the data
hierarchically, allowing you to choose general patterns that match
many of the learned patterns.
A. Click Visualizer to open the Learning Visualizer dialog box,
which displays a branching tree that contains each learned
pattern.
To make the structure easier to view, you can move any leaf or
branch by selecting it and then dragging it to a new location.
B. Select a node that contains a learned pattern that you want to
review.
The screen area beneath the tree structure, under Regex of
Selected Node, displays a generalized expression that matches
all of the patterns on that node.
C. If you want to display an expression that matches just one of
the branches or just one of the leaves, select that branch or leaf.
D. Choose how you want to handle this regular expression.
If you want to modify it and then accept it, click Edit &
Deploy, edit the regular expression, and click OK to save
your changes and deploy the learned relaxation.
If you want to accept it without modifications, click
Deploy.
If you want to remove it from the list without deploying
it, click Skip.
After you choose one of these options, that node, branch, or
leaf disappears from the Learning Visualizer display.
E. Continue selecting and processing nodes, branches, or leaves
until you have reviewed the entire structure.
F. Click Close to close the Learning Visualizer dialog box.
G. Click Close to close the Manage Learned Rules dialog box
and return to the Configure Application Firewall Profile
dialog box.
After you have configured your Application Firewall and reviewed the
recommendations generated by learning over a period of time, the Application
Firewall is properly configured to protect your Web sites.
CHAPTER 5
Policies
This chapter describes in detail what Application Firewall policies are and do,
and explains how to create policies for different types of web content. Policies in
the Application Firewall resemble those in the rest of the NetScaler operating
system, but they have some unusual features and require that you consider certain
issues that other NetScaler policies do not.
Note: You do not need to read this chapter if the default configuration you
performed in Chapter 3, Simple Configuration, on page65, or any additional
configuration you performed in Chapter 12, Use Cases, on page267 meets your
needs.
An Overview of Policies
This section describes what an Application Firewall policy consists of, and how
the Application Firewall uses policies when it protects your Web sites. The
Application Firewall relies on policies to tell it how to distinguish between
different types of content, and how to filter each type.
A policy consists of two main parts:
Rule. An expression or group of expressions that defines the types of
requests and associated responses that the Application Firewall is to filter.
The NetScaler operating system supports two different proprietary expres-
sions languages: the NetScaler classic and NetScaler advanced policy
expressions languages. NetScaler classic is based on PCRE-format regular
expressions, with special terms added to allow you to designate any
attribute of any connection that it can process. NetScaler advanced is an
object-oriented programming language with special features to support
specific NetScaler functions.
The Application Firewall processes only HTTP connections, and therefore
uses a subset of the overall NetScaler expressions languages. For more
information about both expressions languages, see the Citrix NetScaler
Policy Configuration and Reference Guide.
Profile. For Application Firewall policies, the profile is the set of actions
that the Application Firewall is to use when filtering requests and
responses.
Policies allow you to assign different filtering rules to different types of web
content. Not all web content is alike. A simple Web site that uses no complex
scripting and accesses and handles no private data might require only the level of
protection provided by a profile created with basic defaults.
Web content that contains J avascript-enhanced Web forms or accesses a back-end
SQL database will probably require more tailored protection. You can create a
different profile to filter this content, and create a separate policy that can
determine which requests are being sent to that content. You then associate the
policy expression with a profile you created and globally bind the policy to put it
into effect.
Application Firewall policy expressions can be created in either NetScaler classic
syntax or NetScaler advanced syntax. The classic syntax is the same expression
syntax used by the Application Firewall in previous releases. The advanced
syntax has been available in a number of other NetScaler features for the past two
major releases. It is considerably more flexible and more powerful than classic
syntax, allowing creation of expressions that operate on more of the request or
response and analyze it in a greater number of ways. For more information on
NetScaler policies and both types of syntax, see the Citrix NetScaler Policy
Configuration and Reference Guide.
Note: All Application Firewall policies that are bound to global or to a bind
point must use the same type of syntax. You can create both classic and advanced
policies, but you can bind only one type of policy at a time.
The remainder of this chapter describes how you create, configure, and manage
Application Firewall policies.
Configuring Policies
You create and configure Application Firewall policies on the Application
Firewall Policies page of the configuration utility, or by using the NetScaler
command line. The main task in configuring a policy is the creation of the rule,
which consists of one or more classic or advanced expressions.
To configure a policy by using the configuration utility
Policies.
2. In the Application Firewall Policies pane, do one of the following.
Chapter 5 Policies 137
To create a new policy, click Add.
To modify an existing policy, select the policy, and then click Open.
3. In the Policy Name text box, type a name for your new policy.
(. ) pound (#), space ( ), at sign (@), equals (=), and underscore (_)
symbols. You should choose a name that will make it easy for others to tell
what type of content this policy was created to detect.
4. From the Profile drop-down list, select the profile you want to associate
with this policy .
You can create a new profile to associate with your policy from this dialog
by clicking New, and you can modify an existing profile by clicking
Modify.
Note: In some parts of the Policy pane, a profile is referred to as an
action. In the Application Firewall context, they are the same thing.
5. Choose the syntax you want to use for your Policy expression.
If you want to use classic syntax, accept the default and proceed to
the next step.
If you want to use advanced syntax, select Advanced Syntax.
The Expression portion of the dialog box changes to match your
choice. The advanced syntax Expression window has fewer elements
than does the classic syntax Expression window. Instead of a
preview window, a button provides access to the Advanced
Expression Evaluator, which evaluates the expression you entered,
to verify that it is valid, and displays an analysis of the expressions
effect.
6. Enter your policy expressions.
If you are using classic syntax and need further instructions, see To
create a NetScaler classic expression by using the configuration
utility on page138.
If you are using advanced syntax and need further instructions, see
To create a NetScaler advanced expression by using the
configuration utility on page142.
7. Click Create.
8. Repeat steps3 through 7 to create additional policies.
9. Click Close to close the Create Application Firewall Policy dialog box
and return to the Policies pane.
Your new policies appear in the Policies page list. They are not yet active,
because you have not yet bound them.
To create a NetScaler classic expression by using the configuration utility
1. In the Match Any Expression list box, choose how you want the
Application Firewall to evaluate multiple expressions.
If you plan to use only one expression, you can skip this step.
Your choices are:
Match Any Expression. If a request matches any expression in the
Expressions list, the request matches this policy.
Match All Expressions. If a request matches all expressions in the
Expressions list, the request matches this policy. If it does not match
them all, it does not.
Tabular Expression. Switches the Expressions list to a tabular
format with two columns. In the first column, you place one of the
following operators:
The AND [&&] operator, which tells the Application Firewall to
require that a request match both the current expression and the
following expression to match the policy.
The OR [| | ] operator, which tells the Application Firewall to
require that a request match either the current expression or the
following expression, or both, to match the policy. Only if the
request does not match either expression does it not match the
policy.
The END [) ] operator, which tells the Application Firewall that
this is the last expression in this policy.
In the second column, you place the regular expression. The Tabular
format allows you to create a complex policy that contains both
Match Any Expression and Match All Expressions on a per-
expression basis. You are not limited to just one or the other.
Advanced Free-Form. Switches off the Expressions Editor entirely
and turns the Expressions list into a text area in which you can type
one or more expressions. This is both the most powerful and the most
difficult method of creating a policy, and is recommended only for
those thoroughly familiar with PCRE-format regular expressions and
their Citrix NetScaler Application Accelerator or NetScaler
appliance.
Caution: If you switch to Advanced Free Form expression editing
mode, you cannot switch back to any of the other modes. Do not
choose this expression editing mode unless you are sure that is what
you want.
2. Choose or create an expression to define your policy rule.
You can choose a predefined expression (or named expression) from
the Named Expressions list.
A. From the first drop-down list, choose the category that includes
the named expression you want to use.
B. From the second drop-down list, which was populated after you
selected the category, select the exact named expression you
want.
When you select a named expressions, the regular expression
definition of that named expression appears in the Preview
Expression pane beneath the Named Expression drop-down
lists.
C. Click Add Expression to add the named expression to the
Expression list.
You can create a new expression by using the Add Expression dialog
box.
A. Click Add to display the Add Expression dialog box, shown
below.
You should leave the expression type set to General Expression
for Application Firewall policies.
The Flow Type is set to REQ by default. This configures the
Application Firewall to look at incoming connections, or
requests, and the associated outgoing connection, or response.
Since the Application Firewall treats a request and its
associated response as a single entity, all Application Firewall
policies begin with REQ.
B. If the Protocol is not already set to HTTP, choose HTTP in the
Protocol drop-down list.
This tells the Application Firewall to look at HTTP requests,
requests sent to a Web server.
Note: In classic syntax, HTTP includes both HTTP and
HTTPS requests.
C. Choose the second term (or qualifier) for your expression from
the Qualifier drop-down list.
Your choices are:
METHOD. The HTTP method used in the request.
URL. The contents of the URL header.
URLTOKENS. The URL tokens in the HTTP header.
VERSI ON. The HTTP version of the connection.
HEADER. The header portion of the HTTP request.
URLLEN. The length of the contents of the URL header.
URLQUERY. The query portion of the contents of the URL
header.
URLQUERYLEN. The length of the query portion of the
URL header.
The contents of the remaining drop-down lists change to the
choices appropriate to the qualifier you choose. If you choose
header, a text field labeled Header Name appears below the
Flow Type drop-down list, as shown below.
The Add Expression Dialog Box, Partially Filled In
D. Choose the third term (or operator) for your expression from
the Operator drop-down list.
Your choices depend on the qualifier you chose in the previous
step. The complete list of operators that you might see are:
==. Matches the following text string exactly.
! =. Does not match the following text string.
>. Is greater than the following integer.
CONTAI NS. Contains the following text string.
CONTENTS. The contents of the designated header, URL,
or URL query.
EXI STS. The specified header or query exists.
NOTCONTAI NS. Does not contain the following text
string.
NOTEXI STS. The specified header or query does not
exist.
If you want this policy to operate on requests sent to a specific
Host, you can leave the default, the equals (==) sign.
E. If the Value text box is visible, type the appropriate string or
number.
If you are testing a string, type the string into the Value
text box.
If you are testing an integer, type the integer into the
Value text box.
For example, if you want this policy to operate on requests sent
to the host shoppi ng. exampl e. com, you would type that
string in the Value text box, as shown below.
The Add Expression Dialog Box, Completely Filled In
F. If you chose HEADER as the Protocol, type the header you want
in the Header Name text box.
G. Click OK to add your expression to the Expression list.
H. Repeat stepsB through G to create any additional expressions
you want for your profiles rule.
I. Click Close to close the Add Expression dialog box and return
to the Create Application Firewall Policy dialog box.
To create a NetScaler advanced expression by using the configuration
utility
1. Click Advanced Syntax.
The layout of the Create Application Firewall Policy dialog box changes,
and appears as shown below.
The Create Application Firewall Policy Dialog Box, Advanced Syntax
2. Click Prefix, and choose the prefix for your expression from the drop-down
list.
Your choices are:
HTTP. The HTTP protocol. Choose this if you want to examine some
aspect of the request that pertains to the HTTP protocol.
SYS. The protected Web site(s). Choose this if you want to examine
some aspect of the request that pertains to the recipient of the request.
CLIENT. The computer that sent the request. Choose this if you want
to examine some aspect of the sender of the request.
SERVER. The computer to which the request was sent. Choose this if
you want to examine some aspect of the recipient of the request.
After you choose a prefix, the Application Firewall displays a two-part
prompt window that displays the possible next choices at the top, and a
brief explanation of what the selected choice means at the bottom, as shown
below. The choices in the prompt window list depend on which prefix you
chose.
The Create Application Firewall Policy Dialog Box, Advanced Syntax, With Prompts
3. Choose your next term.
If you chose HTTP as your prefix, your only choice is REQ, which
specifies the Request/Response pair. (The Application Firewall operates on
them as a unit rather than separately.) If you chose another prefix, your
choices are more varied. For help on a specific choice, click that choice
once to display information about it in the lower prompt window.
When you have decided which term you want, double-click it to insert it
into the Expression window.
4. Type a period after the term you just chose to display the next prompt, and
choose your next term as described in the previous step.
When a term requires that you type a value, fill in the appropriate value. For
example, if you choose HTTP.REQ.HEADER(""), you need to type the
header name between the quotation marks.
5. Continue choosing terms from the prompts, and filling in any values that
are needed, until your expression is finished.
For more information about creating expressions for Application Firewall
policies, see the Citrix NetScaler Policy Configuration and Reference
Guide.
To create a policy by using the NetScaler command line
1. At the NetScaler command prompt, type the following command:
add appf w pol i cy <name> " <r ul e>" <pr of i l e>
For <name>, substitute a name for the policy. The name can begin
with a letter, number, or the underscore symbol, and can consist of
from one to 127 letters, numbers, and the hyphen (- ), period (. )
pound (#), space ( ), at sign (@), equals (=), and underscore (_)
symbols. You should choose a name that will make it easy for others
to tell what type of content this policy was created to detect.
For <r ul e>, substitute a NetScaler expression that defines the web
content you want to filter using this policy.
Note: You can create a rule using either classic or advanced
expressions using this command. You simply type the appropriate
expressions and enclose them all in double straight quotation marks.
To create a classic expression, follow this syntax:
" <f l ow t ype>. <pr ot ocol >. <qual i f i er >. <oper at or >
[ . <val ue>] [ . <header name>] "
For each of the designated elements, substitute the appropriate
value. The following list describes each element and provides
the correct values or explains how to determine what the
correct values are:
Flow type. Whether the policy filters requests or
responses. The flow type is always REQ for Application
Firewall policies because the Application Firewall filters
each request and its associated response as a unit.
Protocol. The protocol of the connections that this policy
will filter. For Application Firewall policies, this should
be HTTP.
Qualifier. The aspect of the protocol that the policy
should consider. The following values are valid:
METHOD. The HTTP method used in the request.
URL. The contents of the URL header.
URLTOKENS. The URL tokens in the HTTP header.
VERSI ON. The HTTP version of the connection.
HEADER. The header portion of the HTTP request.
URLLEN. The length of the contents of the URL
header.
URLQUERY. The query portion of the contents of the
URL header.
URLQUERYLEN. The length of the query portion of
the URL header.
Operator. The symbol that describes the condition you
want the Application Firewall to test. Depending on
which qualifier you chose, two or more operators may be
valid. The complete list of valid operators is:
==. Matches the following text string exactly.
! =. Does not match the following text string.
>. Is greater than the following integer.
CONTAI NS. Contains the following text string.
CONTENTS. The contents of the designated header,
URL, or URL query.
EXI STS. The specified header or query exists.
NOTCONTAI NS. Does not contain the following text
string.
NOTEXI STS. The specified header or query does
not exist.
Value. If you chose the equals (==), does not equal (! =),
is greater than (>), CONTAI NS, or NOTCONTAI NS
operators, you must include the string or value that the
Application Firewall should test the qualifier against.
If you are testing a string, type the string into the Value
text box.
If you are testing an integer, type the integer into the
Value text box.
For example, if you are testing the URL header to see if it
contains the subdomain shoppi ng. exampl e. com, you
type the string shoppi ng. exampl e. com.
Header Name. If you chose HEADER as your Protocol,
you must also include the name of the header that
contains the attribute or string you want the Application
Firewall to use for the test.
For example, the following expression tells the
Application Firewall to check all requests to see that the
URL header exists.
" REQ. HTTP. HEADER URL EXI STS"
Since all requests by definition have a URL header, this
expression matches all requests.
For <pr of i l e>, substitute the name of the profile you
want to associate with this policy.
To create an advanced expression, follow this syntax:
" <pr ef i x>. <t er m>[ . <t er m2>[ . <t er m3>[ . . . ] ] ] "
For more information about advanced expression syntax, see
the Citrix NetScaler Policy Configuration and Reference
Guide.
Note: Only those users who are thoroughly familiar with
NetScaler advanced expressions should attempt to create them
using the NetScaler command line. Less experienced users will
find the configuration utility much easier to use and more
helpful.
save ns conf i g
created.
show appf w pol i cy <name>
For <name>, substitute the name of the policy you created.
If your policy was correctly created, you do not need to do anything
further.
If your policy was created with the wrong name or associated with
the wrong profile, you modify it by deleting it as shown below, and
then recreating it as described in this procedure.
r mappf w pol i cy <name>
If your policy was created with a flawed regular expression, you
modify it by issuing the following command.
set appf w pol i cy <name> " <r ul e>" <pr of i l e>
You substitute values for <name>, <r ul e>, and <pr of i l e> as
described in the first step of this procedure.
You modify an existing policy in the configuration utility in the Policies pane, by
clicking it once to highlight it, then clicking Open to open the Modify
Application Firewall Policy dialog box. Except for the title, this dialog box is
identical to the Create Application Firewall Policy dialog box. You modify your
policy following the process described in To configure a policy by using the
You modify an existing policy at the NetScaler command line by re-issuing the
create policy command described in To create a policy by using the NetScaler
command line on page144, but substituting the set appf w pol i cy command
for the add appf w pol i cy command. When you issue the set appf w
pol i cy command, it overwrites the existing configuration for that policy.
You delete a policy in the configuration utility by clicking it once to highlight it,
then clicking the Remove button. You delete a policy at the NetScaler command
line by issuing the r mappf w pol i cy command, as described in To create a
policy by using the NetScaler command line, step3 on page148.
Globally Binding a Policy
To put a policy and its associated profile into effect, you globally bind the policy
and assign it a priority. The priority you assign determines the order in which
your policies are evaluated. Set the priorities to evaluate the most specific policy
first, and then more general policies in descending order, finishing with the most
general policy.
Note: All Application Firewall policies that are bound to global or to a bind
point must use the same type of syntax: either classic or advanced syntax, but not
a mixture of both. You can bind only one type of policy at a time.
You can globally bind a policy either in the configuration utility or at the
To globally bind a policy by using the configuration utility
1. In the navigation pane, expand Application Firewall, and click Policies.
2. In the details pane, click Global Bindings.
3. In the Bind/Unbind Firewall Policy(s) to Global dialog box, choose the
type of policy you will bind.
If your policies are based on classic syntax, select Classic Expression.
If your policies are based on advanced syntax, select Advanced
Expression.
4. Click Insert Policy to insert a row in the data area of the dialog box and
display the available unbound policies.
In addition to listing any policies you have created that are not already in
the data area, the drop-down list includes a New Policy entry. If you choose
this entry, the Create Application Firewall Policy dialog box appears,
enabling you to create a new policy.
5. Click the policy you created to insert it in the list.
The check box in the State column is automatically selected, indicating that
the policy you selected is bound and activated.
6. If you want to globally bind your policy, but temporarily keep it inactive, in
the State column, clear the check box.
When you globally bind a policy, by default it is enabled and goes
immediately into effect. In some cases, you might want to have a policy
reviewed before you put it into effect, but want to be able to enable it
quickly. You can do this by clearing the State check box to disable the
policy.
7. In the Priority column, click the default integer and edit the number to
assign the appropriate priority to this policy.
policies that it might also match, policy priority is important to getting the
results you intended.
8. Click OK to save your changes and return to the Policies pane.
To globally bind a policy by using the NetScaler command line
1. At the NetScaler command prompt, type the following command to
globally bind the policy.
> bi nd appf w gl obal <pol i cy> <pr i or i t y>
For <pol i cy>, substitute the name of the policy you want to globally bind.
For <pr i or i t y>, substitute a positive integer that represents the priority of
this policy.
policies that it might also match, policy priority is important to getting the
results you intend.
> save ns con f i g
CHAPTER 6
Imports
Several Application Firewall features make use of external files that you upload
to the Application Firewall when configuring it. Using the configuration utility,
you manage those files in the Imports pane, which has five tabs, corresponding to
the five types of files you can import:
HTML Error Page. The page that the Application Firewall displays when
a user connection to an HTML Web page is blocked or a user asks for a
non-existent HTML Web page. The blocked requests are for HTML-based
content protected by an HTML or Web 2.0 profile. This error page must be
a standard HTML file.
XML Error Page. The page that the Application Firewall displays when a
user connection to an XML application is blocked or a user asks for a non-
existent XML application. The blocked requests are for XML-based con-
tent protected by an XML or Web 2.0 profile. This error page must be an
XML file.
XML Schema. A standard XML configuration file that describes the struc-
ture of a specific type of XML document. To validate XML messages, you
can use the imported schema in an XML or Web 2.0 profile. This file must
be a valid XML schema.
WSDL. A standard XML SOAP configuration file that defines the ele-
ments of a specific XML application.To validate XML messages, you can
use the imported WSDL in an XML or Web 2.0 profile. This file must be a
valid XML SOAP WSDL.
Custom Settings. The Application Firewall's internal lists of SQL special
characters, SQL keywords, cross-site scripting tags, cross-site scripting
attributes, and XPATH special strings and keywords.You can replace the
default lists with lists containing your own special characters, keywords,
tags, attributes, XPATH special strings, or XPATH keywords. You can also
upload multiple lists, and then assign different lists to different profiles.
If you import a new custom settings file, you must be careful to use the correct
format. The recommended procedure is to download (or export) the default
custom settings file or XPATH injection file to your computer, modify it, and then
upload (or import) the modified file to the NetScaler appliance. For the other file
types, you can simply create the files and import them.
Creating a Custom Settings File
The custom settings file is an XML file in a specific format. If you upload a new
custom settings file, it must match the format of the default custom settings XML
file. The recommended procedure is to export the default custom settings file and
and edit it.
Caution: If you are unfamiliar with XML or HTML, or are unfamiliar with text
editors, you should not attempt to modify the custom settings file. If you import
an improperly formatted custom settings file, you could render the SQL Injection
or Cross-Site Scripting checks unusable or cause the Application Firewall to
behave unpredictably.
Exporting the Default Custom Settings File
You can export the def aul t _cust om_set t i ngs. xml file and use it as a
template for creating a new custom settings file.
To export the default custom settings file by using the configuration utility
Imports.
2. Click the Custom Settings tab.
3. Click Export Built-In Settings to display the Export Built-In Custom
Settings dialog box.
4. Click Browse, navigate to a local file system and directory in which to save
the custom settings file, and click Select.
5. Select the Custom Settings file that you want to download.
Currently you have two choices: def aul t _cust om_set t i ngs. xml and
xpat h_i nj ect i on_pat t er ns. xml .
6. Click Download to download the custom settings file.
The custom settings file is downloaded to your local computer and saved in
the directory you specified under the same name you selected above.
Chapter 6 Imports 155
Editing the Custom Settings File
You can edit the custom settings file in a text editor of your choice. After editing
the default file (def aul t _cust om_set t i ngs. xml ), you can, if you want, save
it as a new file with a different name. When you import the new file, it defines the
custom settings used by the HTML and XML SQL Injection checks and HTML
and XML cross-site scripting checks. The custom settings file has the following
content.
Caution: You should not modify any of the header sections; they must appear
exactly as shown.
File header. The file header appears as follows:
<! - - Def aul t SQL/ XSS par amet er s- - >
<! - - / nsconf i g/ appf w_cust omset t i ngs. conf - - >
<AppFwCust omSet t i ngs>
SQL Injection section header. The SQL injection header and opening tag
follow the File header:
<! - - SQL i nj ect i on par amet er s- - >
<i nj ect i on t ype=" SQL" >
SQL Keywords subsection. The header for the SQL keywords subsection
follows immediately after the SQL injection section header. The SQL
keywords follow this header. The list varies in length and composition, but
each term is enclosed in <keywor d></ keywor d> tags. You add SQL
keywords to the list by entering each keyword on a separate line and
enclosed in the specified tags. The SQL keywords section is terminated
with a blank line.
Following are some of the default SQL keywords, in context:
<! - - SQL keywor ds- - >
<keywor d>sel ect </ keywor d>
<keywor d>i nser t </ keywor d>
. . .
<keywor d>SYS. USER_SYS. PRI VS</ keywor d>
<keywor d>SYS. USER_TAB_PRI VS</ keywor d>
SQL Special Strings subsection. The header for the SQL special
characters subsection follows the SQL keywords subsection, and the SQL
special characters follow this header. Each special string is on a single line,
and is enclosed in <speci al st r i ng></ speci al st r i ng> tags. You add
special strings to the list by entering each string on a separate line, and
enclosing it in the specified tags. The section is terminated by a blank line,
and it is followed by the closing tag for the SQL Injection section.
The default SQL special strings section appears as follows:
<! - - SQL speci al st r i ngs- - >
<speci al st r i ng>' </ speci al st r i ng>
<speci al st r i ng>\ \ </ speci al st r i ng>
<speci al st r i ng>; </ speci al st r i ng>
</ i nj ect i on>
Cross-Site Scripting (XSS) section header. The XSS section header and
opening tags follow the SQL Injection section ending tag:
<! - - XSS par amet er s- - >
<xss>
<al l owed>
XSS Allowed Tags subsection. The XSS allowed tags subsection follows
the section header, with the section header at the top and a list of allowed
tags beneath it. Each allowed tag is on a separate line and is enclosed in
<t ag></ t ag> tags. You add XSS allowed tags to the list by entering each
tag on a separate line, and enclosing it in the specified XML tags. The
subsection is terminated by a blank line.
Following are some of the default XSS allowed tags, in context:
! - - XSS al l owed t ags- - >
<t ag>a</ t ag>
<t ag>addr ess</ t ag>
<t ag>b</ t ag>
<t ag>basef ont </ t ag>
. . .
<t ag>t r </ t ag>
<t ag>t t </ t ag>
<t ag>u</ t ag>
<t ag>ul </ t ag>
XSS Allowed Attributes subsection. The XSS allowed attributes
subsection follows the XSS Allowed Tags subsection, with the section
header at the top and a list of allowed attributes beneath it. Each allowed tag
is on a separate line, and is enclosed in <at t r i but e></ at t r i but e> tags.
You add XSS allowed attributes to the list by entering each attribute on a
separate line, and enclosing it in the specified tags. The subsection is
terminated by a blank line, followed by the closing tags for the XSS
section, another blank line, and the closing tag for the custom settings file.
Following are some of the default XSS allowed attributes, in context:
<! - - XSS al l owed at t r i but es- - >
<at t r i but e>abbr </ at t r i but e>
<at t r i but e>accesskey</ at t r i but e>
. . .
<at t r i but e>vspace</ at t r i but e>
<at t r i but e>wi dt h</ at t r i but e>
</ al l owed>
</ xss>
</ AppFwCust omSet t i ngs>
Importing Configuration Files
You can import the supported configuration files to the Application Firewall by
using the configuration utility or using the NetScaler command line.
Note: Verify that the NetScaler appliance has Internet connectivity before
importing an XML schema or WSDL file, or an HTML or XML error object, that
is on a server that your NetScaler appliance cannot connect to through the LAN.
Otherwise, you will be unable to import the XML Schema, WSDL file, or error
object.
To import a file to your Application Firewall by using the configuration utility
1. In the navigation pane, expand Application Firewall.
2. In the Application Firewall Profiles pane, select the tab for the type of file
you want to import.
Note: The upload process is identical on all five tabs from the user point
of view.
3. Click the Add button to display the Import New dialog box for the type of
file you want to import.
4. In the Name text box, type a name for the object you are importing.
5. Choose the type of upload.
If the object is on a Web site or other location on the Intranet or
Internet, select Import from URL.
If the object is on your local computer or a file server mounted on
your local computer, select Import from Local File.
6. In the URL or Local File text box, type the path to the resource.
If you are uploading the object from a Web site or Intranet location,
you should type a URL in standard browser format, as follows:
<pr ot ocol >: / / <host >/ [ <pat h>/ ] <f i l ename>
For <pr ot ocol >, substitute the appropriate protocol, which is
normally ht t p, but it could be ht t ps or f t p if the file is located on a
secure Web server or on an FTP server. For <host >, substitute the
host name or IP address of the server. For <pat h>, substitute the path
to the object. If the object is in the web root or FTP root directory, the
path is zero-length and you do not need to type anything. For
<f i l ename>, substitute the name of the file that contains the object.
If you are importing the object from your local computer, you should
type the path and file name of the object in the appropriate format for
your local computer.
7. Click the Import button to import the object and create the resource.
Note: If the NetScaler appliance is unable to locate the resource, and you
are uploading from an Internet or Intranet site, and you have verified that
the URL and file you requested exists, you should look at the ns. l og file
to verify that the URL you used is accessible from your NetScaler
appliance. After correcting the problem, you repeat steps6 through 8 to
import the object.
8. Click the Close button to close the Import Console message box.
9. To modify the path of an existing object, you select that object, and then
click Modify to display the object in the Modify Import dialog box.
You then modify the path as you wish, and when you are finished click
Save.
10. To delete an object, you select the object, and then click Remove.
The Proceed dialog box appears, asking you to confirm your choice. You
click OK to confirm your choice.
11. If you want to import a different type of resource, click the tab for that
resource and repeat steps4 through 11.
To import a file onto your Application Firewall by using the NetScaler
command line:
via SSH, on page60.
2. Upload the file of your choice.
To upload an HTML error page, enter the following command.
i mpor t appf w ht ml er r or page <sr c> <name>
To upload an XML error page, enter the following command.
i mpor t appf w xml er r or page <sr c> <name>
To upload an XML schema, enter the following command.
i mpor t appf w xml schema <sr c> <name>
To upload a WSDL, enter the following command.
i mpor t appf w wsdl <sr c> <name>
To upload a custom settings file, enter the following command.
i mpor t appf w cust omset t i ngs <sr c> <name>
For <sr c>, substitute the URL or path to and name of the source file. For
<name>, substitute a name for the file. The name can begin with a letter,
number, or the underscore symbol, and can consist of from one to 127
letters, numbers, and the hyphen (- ), period (. ) pound (#), space ( ), at sign
(@), equals (=), colon (: ), and underscore (_) symbols. You should choose a
name that will make it easy for others to tell what type of content this
profile was created to protect.
> save ns conf i g
4. Confirm that your object was imported correctly, by typing one of the
commands shown below.
If you assigned the wrong name to an imported object or used the wrong
URL, delete the object and reimport it
If you uploaded an HTML error page, type the following command to
display the entries for all HTML error pages on the server:
show appf w ht ml er r or page
To delete an HTML error page, type the following command:
r mappf w ht ml er r or page <name>
If you uploaded an XML error page, type the following command to
display the entries for all XML error pages on the server:
show appf w xml er r or page
To delete an XML error page, type the following command:
r mappf w xml er r or page <name>
If you uploaded an XML schema, type the following command to
display the entries for all XML schemas on the server:
show appf w xml schema
To delete an XML schema, type the following command:
r mappf w xml schema <name>
If you uploaded a WSDL, type the following command to display the
entries for all WSDLs on the server:
show appf w wsdl
To delete a WSDL, type the following command:
r mappf w wsdl <name>
If you uploaded a custom settings file, type the following command
to display the entries for all custom settings files on the server:
show appf w cust omset t i ngs
To delete a custom settings file, type the following command:
r mappf w cust omset t i ngs <name>
CHAPTER 7
Global Configuration
The Application Firewall global configuration affects all profiles and policies.
The Global Configuration items are:
Engine Settings. A collection of global settingssession cookie name,
session time-out, maximum session lifetime, logging header name,
undefined profile, default profile, and import size limitthat pertain to all
connections that the Application Firewall processes, rather than to a
specific subset of connections.
Confidential Fields. A set of form fields in Web forms that contain
sensitive information that should not be logged to the Application Firewall
logs. Form fields such as password fields on a logon page or credit card
information on a shopping cart checkout form are normally designated as
confidential fields.
Field Types. The list of Web form field types used by the Field Formats
security check. Each of these field types is defined by a PCRE-compliant
regular expression that defines the type of data and the minimum/maximum
length of data that should be allowed in that type of form field.
You can configure each of these items in the appropriate dialog box, which is
accessed by clicking a link in the main Application Firewall pane, or at the
The Engine Settings
The engine settings pertain to all connections that the Application Firewall
processes, rather than to specific connections defined by a profile. You normally
do not need to modify these settings from the default values. If the default settings
cause a conflict with other servers, however, or if the default time-out causes
premature disconnection of your users, you may need to modify these settings.
You can modify the name of the cookie that stores the session ID, the session
time-out and maximum lifetime values, the use of a client IP address logging
header, the profile to apply when the corresponding policy action is undefined,
the default profile (applied to connections that do not match a policy), and the
size limit for imported files.
Cookie Name
The Application Firewall uses the session cookie to track user sessions. By
default, this cookie is named ci t r i x_ns_i d. You do not normally need to
modify this name, but if it conflicts in any way with a cookie set by your
protected Web servers, you can change the name.
To change the name of the session cookie by using the configuration utility
1. In the navigation pane, click Application Firewall.
2. In the details pane, click Change Engine Settings.
3. In the Application Firewall Engine Settings dialog box, under Cookie
Name, type a new cookie name.
4. Click OK to save your changes.
To change the name of the session cookie by using the NetScaler command
line
At the NetScaler command prompt, type:
set appf w set t i ngs - sessi onCooki eName <st r i ng>
For <st r i ng>, substitute your preferred session cookie name.
Session Timeout
The session timeout is the length of time, in seconds, that the Application
Firewall waits before timing out user Web site sessions. By default, this is set to
900 seconds (15 minutes). After the Application Firewall times out the session,
the user must re-establish a session by visiting the home page or a designated start
URL.
You can change the default timeout in the Engine Settings.
To modify the session timeout period by using the configuration utility
3. In the Application Firewall Engine Settings dialog box, under Session
Time-out (seconds), type the number of seconds the Application Firewall
waits before timing out a user's session.
To modify the session timeout period by using the NetScaler command line
set appf w set t i ngs - sessi onTi meout <number >
Chapter 7 Global Configuration 163
For <number >, substitute the timeout value in seconds.
Maximum Session Lifetime
The maximum session lifetime defines the maximum amount of time, in seconds,
that the Application Firewall will allow a user session to remain active, regardless
of user activity. By default, this is set to 900 seconds (15 minutes). When the limit
is reached, the Application Firewall terminates the session. To regain access, the
user must establish a new session by visiting a designated start page.
To configure the maximum session lifetime by using the configuration utility
3. In the Application Firewall Engine Settings dialog box, under Maximum
Session Lifetime, select the Enabled check box.
4. In the text box that appears to the right of the Enabled check box, type the
maximum session lifetime as a number of seconds.
To configure the maximum session lifetime by using the NetScaler
command line
set appf w set t i ngs - sessi onl i f et i me <number >
For <number >, substitute the number of seconds.
Logging Header Name
The logging header is the name of an HTTP header containing the IP that the
client used to connect to your protected Web server. By default, this setting is
blank, which tells the Application Firewall not to add a logging header.
To add a logging header by using the configuration utility
3. In the Application Firewall Engine Settings dialog box, under Logging
Header Name, type the name of the HTTP request header that will contain
the client IP.
To add a logging header by using the NetScaler command line
set appf w set t i ngs - cl i ent I PLoggi ngHeader <st r i ng>
For <st r i ng>, substitute a name for the HTTP request header that will contain
the client IP.
Undefined Profile
The undefined profile is the profile that is used when an Application Firewall
policy evaluates as undefined. An undefined evaluation indicates an internal error
condition. If no Undefined Profile is set, the Application Firewall aborts
processing of these connections and passes them back to the NetScaler appliance
without attempting to filter them. This behavior can constitute a security hazard
in some circumstances, so the default setting for the Undefined Profile is set as
the APPFW_BLOCK built-in profile.
You can specify a different profile here.
To configure the undefined profile by using the configuration utility
3. In the Application Firewall Engine Settings dialog box, under Undefined
profile, choose a default or user-created profile from the drop-down list.
To configure the undefined profile by using the NetScaler command line
set appf w set t i ngs - undef act i on <st r i ng>
For <st r i ng>, substitute the name of the profile you want to use when a
connection evaluates as undefined.
Default Profile
The default profile is the profile that is used when a connection does not match
any of the Application Firewall policies. Normally the default profile is set to
APPFW_BYPASS, which means that the Application Firewall passes
connections that fail to match any policy back to the NetScaler appliance without
attempting to filter them further.
If you do not want the Application Firewall to skip filtering of these connections,
you can specify a different default profile here.
To configure the default profile by using the configuration utility
3. In the Application Firewall Engine Settings dialog box, under Default
profile, choose a default or user-created profile from the drop-down list.
To configure the default profile by using the NetScaler command line
set appf w set t i ngs - def aul t pr of i l e <st r i ng>
For <st r i ng>, substitute the name of the profile you want to use when a
connection does not match any profile.
Import Size Limit
The import size limit is the cumulative total maximum number of bytes allowed
for importing files to the Application Firewall.
To configure the import size limit by using the configuration utility
3. In the Application Firewall Engine Settings dialog box, under Import
Size Limit, type the maximum number of bytes allowed for imported files.
To configure the import size limit by using the NetScaler command line
set appf w set t i ngs - i mpor t Si zeLi mi t <i nt eger >
For <i nt eger >, substitute a positive integer that represents the maximum
number of bytes allowed for importing files onto the Application Firewall.
Confidential Fields
You can use the confidential field feature to designate Web form fields as
confidential to protect the information users type into them. Normally, any
information a user types into a Web form on one of your protected Web servers is
logged in the NetScaler logs. The information typed into a Web form field
designated as confidential, however, is not logged. That information is saved only
where the Web site is configured to save this data, normally in a secure database.
Common types of information that you may want to protect with a confidential
field designation include:
Passwords
Credit card numbers, validation codes, and expiration dates
Social security numbers
Private home addresses and telephone numbers
In addition to being good server security, proper use of confidential field
designations may be necessary for PCI-DSS compliance on ecommerce servers,
HIPAA compliance on servers that manage medical information in the United
States, and compliance with other data protection standards.
Note: In the following two cases, the Confidential Field designation will not
function as described above:
If a Web form has either a confidential field or an action URL longer than
256 characters, the field or action URL is truncated in the NetScaler logs.
With certain SSL transactions, the logs are truncated if either the
confidential field or the action URL is longer than 127 characters.
In either of these cases, the Application Firewall will x-out a fifteen-character
string instead of the normal eight character string. To ensure that any confidential
information is removed, the user must use form field name and action URL
expressions that match the first 256, or (in cases where SSL is used) the first 127
characters.
To configure your Application Firewall to treat a Web form field on a protected
Web site as confidential, you add that field to the Confidential Fields list. You can
also modify the confidential field designation, and remove it.
To configure a confidential field by using the configuration utility
2. In the Application Firewall pane, click Manage Confidential Fields.
3. In the Manage Confidential Fields dialog box, do one of the following.
To add a new form field to the list, click Add.
To change an existing confidential field designation, select the field,
and then click Open.
The Create Confidential Form Field dialog box or the Configure
Confidential Form Field dialog box appears.
If you select an existing confidential field designation and then click Add,
the Create Confidential Form Field dialog box displays the information
for that confidential field. You can modify that information to create your
new confidential field.
4. If you want to create a new confidential field listing, but not enable it
immediately, or if you want to disable an existing confidential field but
leave it on the list, clear the Enabled check box.
By default, confidential fields are created as enabled.
5. If you will use a regular expression as the field name, in the Field Name
section, select the Is form field name a regular expression check box.
6. Type or modify the name of the form field or form fields that should be
treated as confidential fields.
You can do this in the following ways:
Type a literal string that represents a specific field name.
Type a PCRE-compatible regular expression that either represents a
specific field name or that matches multiple fields with names that
follow a pattern.
Following are some regular expressions that define form field names
that you might find useful:
^passwd_ (Applies confidential-field status to all field names
that begin with the string passwd_.)
^( ( [ 0- 9a- zA- Z. _- ] *| | \ \ x[ 0- 9A- Fa- f ] [ 0- 9A- Fa- f ] ) +-
) ?passwd_ (Applies confidential-field status to all field names
that begin with the string passwd_, or that contain the string
- passwd_ after another string that might contain non-ASCII
special characters.)
7. In the Action URL text box, type the action URL of the Web form in which
the form field or form fields that should be treated as confidential fields
appear.
You can do this in the following ways:
Type a literal string that represents a specific URL.
Type a PCRE-compatible regular expression that represents a specific
URL or that matches multiple URLs with a common pattern.
Following are some regular expressions that define specific URL
types that you might find useful. You should substitute your own web
host(s) and domain(s) for those in the examples.
If the Web form appears on multiple web pages on the web host
www. exampl e. com, but all of those web pages are named
l ogon. pl ?, you could use the following regular expression:
ht t ps?: / / www[ . ] exampl e[ . ] com/ ( [ 0- 9A- Za- z] [ 0- 9A- Za-
z_. - ] */ ) *l ogon[ . ] pl \ ?
www. exampl e- espaol . com, which contains the n-tilde ()
special character, you could use the following regular
expression, which represents the n-tilde special character as an
encoded UTF-8 string containing C3 B1, the hexadecimal code
assigned to that character in the UTF-8 charset:
ht t ps?: / / www[ . ] exampl e- espa\ xC3\ xB1ol [ . ] com/ ( [ 0- 9A-
Za- z] [ 0- 9A- Za- z_. - ] */ ) * l ogon[ . ] pl
Note: When a regular expression appears on two or more
lines, you should type it on a single line in the NetScaler
command line, and press the Enter key only once at the end.
If the Web form on quer y. pl appears on multiple web pages
on different hosts within the exampl e. comdomain, you could
use the following regular expression:
" ht t ps?: / / ( [ 0- 9A- Za- z] [ 0- 9A- Za- z_-
. ] *[ . ] ) *exampl e[ . ] com/ ( [ 0- 9A- Za- z] [ 0- 9A- Za- z_- . ] */
) *l ogon[ . ] pl \ ?"
If the Web form on quer y. pl appears on multiple web pages
on different hosts in different domains, you could use the
following regular expression:
" ht t ps?: / / ( [ 0- 9A- Za- z] [ 0- 9A- Za- z_- . ] *[ . ] ) *[ 0- 9A- Za-
z] [ 0- 9A- Za- z_- . ] +[ . ] [ a- z] {2, 6}/ ( [ 0- 9A- Za- z] [ 0- 9A- Za-
z_- . ] */ ) *l ogon[ . ] pl \ ?"
" ht t ps?: / / www[ . ] exampl e[ . ] com/ ( [ 0- 9A- Za- z] [ 0- 9A- Za-
z_- . ] */ ) *l ogon[ . ] pl \ ?"
8. In the Comments section, type an explanation of why you designated this
form field or these form fields as confidential.
This field is optional; you can leave it blank.
9. Click Create or OK to save your changes.
A message box appears, notifying you that your new confidential field
designation was successfully created. To close the message box, click OK.
10. To remove a confidential field designation from the confidential fields list,
select the confidential field listing you want to remove, then click Remove
to remove it, and OK to confirm your choice.
11. Click Close to close the current dialog box, and return to the Manage
Confidential Fields dialog box.
12. Click Close to close the Manage Confidential Fields dialog box and
return to the Application Firewall pane.
To configure a confidential field by using the NetScaler command line
To add a new confidential field, type the following command at the NetScaler
command prompt:
add appf w conf i dFi el d <name> " <ur l >"
[ - i sRegex ( REGEX | NOTREGEX ) ] [ - comment " <st r i ng>" ]
[ - st at e ( ENABLED | DI SABLED ) ]
To modify an existing confidential field, type the following command at the
NetScaler command prompt:
set appf w conf i dFi el d <name> " <ur l >"
[ - i sRegex ( REGEX | NOTREGEX )
To verify that your confidential field designation is correct, type the following
command at the NetScaler command prompt:
show appf w conf i dFi el d <name>
For <name>, substitute the name of the confidential field as either a literal
string or as a PCRE-compatible regular expression.
Below are some regular expressions that define field names that you might
find useful.
^passwd_ (Applies confidential-field status to all field names that
begin with the string passwd_.)
^( ( [ 0- 9a- zA- Z. _- ] *| | \ \ x[ 0- 9A- Fa- f ] [ 0- 9A- Fa- f ] ) +- ) ?passwd_
(Applies confidential-field status to all field names that begin with
the string passwd_, or that contain the string -passwd_ after another
string that might contain non-ASCII special characters.)
For <ur l >, substitute either a literal URL or a PCRE-compatible regular
expression, enclosed in double straight quotation marks, that defines the
URL or URLs that contain the Web forms.
Below are some regular expressions that define specific URL types you
might find useful. You should substitute your own web host(s) and
domain(s) for those in the examples.
" ht t ps?: / / www[ . ] exampl e[ . ] com/ ( [ 0- 9A- Za- z] [ 0- 9A- Za- z_-
. ] */ ) *l ogon[ . ] pl \ ?"
www. exampl e- espaol . com, which contains the n-tilde () special
character, you could use the following regular expression, which
represents the n-tilde special character as an encoded UTF-8 string
containing C3 B1, the hexadecimal code assigned to that character in
the UTF-8 charset:
" ht t ps?: / / www[ . ] exampl e- espa\ xC3\ xB1ol [ . ] com/
( [ 0- 9A- Za- z] [ 0- 9A- Za- z_- . ] */ ) *l ogon[ . ] pl "
Note: When a regular expression appears on two or more lines, you
should type it on a single line in the NetScaler command line, and
press the Enter key only once at the end.
If the Web form on quer y. pl appears on multiple web pages on
different hosts within the exampl e. comdomain, you could use the
following regular expression:
" ht t ps?: / / ( [ 0- 9A- Za- z] [ 0- 9A- Za- z_- . ] *[ . ] ) *exampl e[ . ] com/
( [ 0- 9A- Za- z] [ 0- 9A- Za- z_- . ] */ ) *l ogon[ . ] pl \ ?"
If the Web form on quer y. pl appears on multiple web pages on
different hosts in different domains, you could use the following
regular expression:
" ht t ps?: / / ( [ 0- 9A- Za- z] [ 0- 9A- Za- z_- . ] *[ . ] ) *[ 0- 9A- Za- z] [ 0-
9A- Za- z_- . ] +[ . ] [ a- z] {2, 6}/ ( [ 0- 9A- Za- z] [ 0- 9A- Za- z_- . ] */
) *l ogon[ . ] pl \ ?"
" ht t ps?: / / www[ . ] exampl e[ . ] com/ ( [ 0- 9A- Za- z] [ 0- 9A- Za- z_-
. ] */ ) *l ogon[ . ] pl \ ?"
Set the - i sRegex argument to tell the Application Firewall whether the
URL you set was a literal string or a regular expression.
If you used a literal string for the URL, type -isRegex NOTREGEX.
If you used a regular expression for the URL, type -isRegex REGEX.
If you want to add a comment to your field type, for <comment >, substitute
a string enclosed in double straight quotation marks.
Set the - st at e argument to specify whether you want to enable or disable
this confidential field designation.
Field Types
A field type is a regular expression that defines a particular data format and
minimum/maximum data lengths for a form field in a Web form. When you are
configuring the Field Formats check and making field format assignments, you
choose a format for each form field from the Field Types list. Each field type is
defined by a PCRE-format regular expression that describes what data type and
length a form field can contain when a user returns data in a Web form on your
Web site.
The Application Firewall comes with several default field types. These are:
i nt eger . A string of any length consisting of numbers only, without a dec-
imal point, and with an optional preceding minus sign (- ).
al pha. A string of any length consisting of letters only.
al phanum. A string of any length consisting of letters and/or numbers.
noht ml . A string of any length consisting of characters, including punctua-
tion and spaces, that does not contain HTML symbols or queries.
any. Anything at all.
Caution: Assigning the any field type as the default field type, or to a
field, allows active scripts, SQL commands, and other possibly dangerous
content to be returned in that form field. You should use the any type
sparingly, if you use it at all.
You can add your own field types to the Field Types list. For example, you might
want to add a field type for a social security number, postal code, or phone
number in your country. You might also want to add a field type for a customer
identification number or store credit card number.
You can add a new field type, modify an existing user-created field type, remove
a field type, and enable or disable a field type.
To configure a field type by using the configuration utility
1. In the navigation pane, expand Application Firewall.
2. In the Application Firewall pane, click Manage Field Types.
3. Do one of the following:
To add a new field type, click Add.
To modify an existing field type, select it, and then click Open
Note: You cannot modify or delete the default field types. If you highlight
a default field type, the Remove button remains greyed out. The Open
button opens the default field type in a read-only message box.
4. If you are adding a new field type, in the Field Name text box, type a name
for the field type you want to add.
can consist of from one to 31 letters, numbers, and the hyphen
(- ), period (. ) pound (#), space ( ), at sign (@), equals (=), colon (:), and
underscore (_) symbols.
If you are modifying an existing field type, this text box is disabled.
5. In the Regular Expression text area, type a PCRE-compatible regular
expression that defines the field type you want.
Below are two regular expressions that define specific field types you
might find useful:
To define a field type for international phone numbers that begin with
the country code and can contain up to 40 additional numerals,
spaces, and the hyphen [- ], open [( ] parenthesis, and close [) ]
parenthesis characters, you can use the following regular expression:
^+[ 0- 9] {1, 3} [ 0- 9( ) - ] {1, 40}$
To define a field type for a company credit card with numbers
formatted as ##- #####- ######, that begins with the two-letter
abbreviation for a U.S. state, followed by a five-digit integer,
followed by six-digit hexadecimal string, you can use the following
regular expression:
^[ A- Z] [ A- Z] - [ 0- 9] {5, 5}- [ 0- 9A- F] {6, 6}$
6. In the Priority text box, type a positive integer that sets the priority of this
field type.
Field types are evaluated in order of priority, with the lowest numbers
having the highest priority. The Application Firewall accepts the first field
type match and does not continue evaluating field types after it has found a
match. Therefore, you should assign the lowest number to the most specific
field type, assign the next lowest number to the next most specific field
type, and so on.
7. In the Comments text area, type a description of the field type and the
purpose for which you created it.
This field is optional; you can leave it blank.
8. Click Create.
9. Repeat steps4-8 to create or modify additional field types.
10. Click Close to close the current dialog box and return to the Manage Field
Types dialog box.
Any new field types you added are displayed in the list.
To configure a field type by using the NetScaler command line
To add a new field type, type the following command at the NetScaler command
prompt:
add appf w f i el dType <name> " <r egex>" <pr i or i t y> [ - comment
" <st r i ng>" ] >
To modify an existing field type, type the following command at the NetScaler
command prompt:
set appf w f i el dType <name> " <r egex>" <pr i or i t y> [ - comment
" <st r i ng>" ] >
To verify that you created your field type correctly, type the following command
at the NetScaler command prompt:
show appf w f i el dType <name> " <r egex>" <pr i or i t y> [ - comment
" <st r i ng>" ] >
For <name>, substitute a name for the field type. The name can begin with
a letter, number, or the underscore symbol, and can consist of from one to
127 letters, numbers, and the hyphen (- ), period (. ) pound (#), space ( ), at
sign (@), equals (=), and underscore (_) symbols. You should choose a name
that will make it easy for others to tell what type of content this field type
defines.
For <r egex>, substitute a PCRE-compatible regular expression, enclosed
in double straight quotation marks, that defines the field type.
Below are two regular expressions that define specific field types you
might find useful:
To define a field type for international phone numbers that begin with
the country code and can contain up to 40 additional numerals,
spaces, and the hyphen [- ], open [( ] parenthesis, and close [) ]
parenthesis characters, you can use the following regular expression:
" ^+[ 0- 9] {1, 3} [ 0- 9( ) - ] {1, 40}$"
To define a field type for a company credit card with numbers
formatted as ##- #####- ######, that begins with the two-letter
abbreviation for a U.S. state, followed by a five-digit integer,
followed by six-digit hexadecimal string, you can use the following
regular expression:
" ^[ A- Z] [ A- Z] - [ 0- 9] {5, 5}- [ 0- 9A- F] {6, 6}$"
For <pr i or i t y>, substitute an integer that defines the priority of this field
type.
Field types are evaluated in order of priority, with the lowest numbers
having the highest priority. The Application Firewall accepts the first field
type match and does not continue evaluating field types after it has found a
match. Therefore, you should assign the lowest number to the most specific
field type, the next lowest number to the next most specific field type, and
so on.
If you want to add a comment to your field type, for <comment >, substitute
a string enclosed in double straight quotation marks.
CHAPTER 8
The Common Security Checks
If you are a system administrator who needs to configure a specific security check
for your Web site, see the topic about that security check for a description of how
the security check operates, what types of attacks it helps prevent, and how the
configuration details affect the filtering of requests or responses.
The Start URL Check
The Start URL check examines the URLs in incoming requests and blocks the
connection attempt if the URL does not meet the specified criteria. To meet the
criteria, the URL must match an entry in the Start URL list, unless the Enforce
URL Closure parameter is enabled. If you enable this parameter, a user who
clicks a link on your Web site is connected to the target of that link.
The primary purpose of the Start URL check is to prevent repeated attempts to
access random URLs on a Web site, or forceful browsing. Forceful browsing can
be used to trigger a buffer overflow, find content that users were not intended to
access directly, or find a back door into secure areas of your Web server.
In any of your Application Firewall profiles, you can configure general settings
for the Start URL check, and you can configure entries in the Start URL list. In a
profile that you created with the basic defaults, the Start URL list has two default
expressions that allow access to the common types of HTML files, graphics files,
stylesheets, and scripts used on Web sites. Many sites have no user-accessible
content that does not fall into one of these categories, and allowing access to these
types of content is not normally risky from a security perspective. The default
Start URL expressions typically require little, if any, further configuration, and
you can also probably use the default general settings with them. You might,
however, want to create additional entries, called relaxations, to allow access to
additional types of content. A profile that you created with the advanced defaults
does not have any default entries in the Start URL list. Depending on how you
configure the general Start URL settings, you can create your own list entries or
have Application Firewall learn them.
You can configure some of the general settings in the pane that opens when you
open a profile. To configure all of the general settings, open the Modify Start
URL dialog box.
To configure the general settings by using the configuration utility
Profiles.
2. In the Application Firewall Profiles pane, select a profile, and then click
Open.
3. In the Configure Application Firewall Profile dialog box, click the
Security Checks tab.
A list of all the security checks that apply to this profile type appears.
Beside the Start URL entry, you can select or clear check boxes to enable
or disable actions that can be taken when a connection does not meet the
specified criteria. To access all of the general settings, continue with the
following steps.
4. Click Start URL, and then click Modify.
5. In the Modify Start URL Check dialog box, click the General tab.
6. Under Actions, enable or disable each of the actions described in Modify
Start URL Check Actions.
7. Under Parameters, specify values for the parameters described in Modify
Start URL Check Parameters.
8. Click OK when finished, and click Close to close the dialog box.
Modify Start URL Check Actions
The Check Actions control how the Start URL check functions. They are:
Block. Block connections that violate the Start URL security check.
Enabled by default in profiles created with both basic and advanced
defaults. Clear/select the check box to disable/enable blocking.
For a profile with basic defaults, you probably do not want to disable
blocking for the Start URL check. By default, profiles created with basic
defaults allow connections to HTML pages and any common types of Web
content. In the unlikely event that your Web site hosts an unsupported
content type, or content with an unsupported extension, you can simply add
the appropriate extension to the list of Start URLs manually.
For a profile with advanced defaults, there are many reasons why you might
want to disable blocking. The most common is to prevent false positives
when you first install the Application Firewall. Profiles created with
advanced defaults do not have any Start URLs listed. You must either
manually add your Web site home pages to the Start URL list when you
first configure the profile, or allow the Learning feature to generate a list for
you. If you prefer to let learning do the work, you need to turn off blocking
Chapter 8 The Common Security Checks 177
until learning has seen enough traffic to generate the necessary list of start
URLs.
Learn. Use the learning feature to observe traffic to and from your pro-
tected Web sites, and generate a list of recommended URLs to add to the
Start URL list. Disabled by default in profiles created with basic defaults,
and enabled by default in profiles created with advanced defaults. Clear/
select the check box to disable/enable learning.
For a profile with basic defaults, you probably do not want to enable
learning for the Start URL rule. By default, profiles created with basic
defaults allow connections to HTML pages and any common types of web
content. This will probably allow connections to any legitimate web page
on your protected Web sites. Since using learning requires you to spend
additional time configuring the Start URL check, you probably do not want
to use it if you do not need it.
For a profile with advanced defaults, you can leave learning enabled and
turn off blocking until learning has seen enough traffic to generate the
necessary list of start URLs. You then review the learned recommendations
for start URLs and accept those that you want to allow. When learning has
seen enough traffic to generate a good list, you re-enable blocking, and you
are finished.
If you disable learning and create the Start URL list manually, you must be
careful to avoid false positives. You can add your Web site home pages to
the Start URL list when you first configure the profile, and leave URL
closure enabled. An Application Firewall configured in this manner allows
users to access your home page, and from there to access any URL on your
Web site by clicking a link on another web page on your Web site. The
Application Firewall is therefore unlikely to block any legitimate queries,
except when a user has bookmarked a web page other than a home page.
Caution: If you choose to disable learning and rely on a list of your Web
site home pages and URL closure to allow access to your Web sites, you
must manually add to the Start URL list all the URLs that your users are
likely to bookmark.
Log. Log connections that violate the Start URL security check. Enabled by
default in profiles created with either basic or advanced defaults. Clear/
select the check box to disable/enable logging. You normally do not want to
disable logging for this or any security check. If anything unexpected hap-
pens, the logs are an important resource for troubleshooting.
Statistics. Generate statistics for connections that violate the Start URL
security check. Enabled by default in profiles created with either basic or
advanced defaults. Clear/select the check box to disable/enable statis-
tics.You normally do not want to disable statistics. They can help you mon-
itor the types of attacks that a particular security check is detecting so that
you can determine how effective that check is on your protected Web sites.
Modify Start URL Check Parameters
The Start URL Parameters control other general settings for this security check.
They are:
Enforce URL Closure. Allow users to access any Web page on your Web
site by clicking a hyperlink on any other page on your Web site. Disabled
by default in profiles created with basic defaults, and enabled by default in
profiles created with advanced defaults. Clear/select the check box to dis-
able/enable URL Closure.
For a profile with basic defaults, you probably do not want to enable URL
closure. By default, these profiles allow connections to HTML pages and
other common types of web content. This should allow connections to any
legitimate web page on your protected Web sites. URL closure is unlikely
to offer any advantage, and requires extra CPU time.
If you created a profile with advanced defaults, you might want to enable
Enforce URL Closure to ensure that users who access your Web site
through an approved Start URL are allowed to access any content that they
can reach by navigating through your Web site.
Note: URL Closure allows any query string to be appended to and sent
with the action URL of a Web form submitted using the HTTP GET
method.
Validate Referer Header. Tells the Application Firewall to verify that the
Referer header in a Request that contains Web form data comes from your
protected Web server rather than from another Web site. This verifies that
your Web site, rather than an outside attacker, is the source of that Web
form. This protects against cross-site request forgeries (CSRF) without
requiring form tagging, which is more CPU-intensive than header checks.
For more information about CSRF, see The CSRF Form Tagging Check
on page215.
The Application Firewall can handle the HTTP Referer header in one of the
following three ways, depending on which option you select in the drop-
down list:
- Off. Do not validate the Referer header. This is the default setting for
profiles created with basic defaults.
- If-Present. Validate the Referer header if a Referer header exists. If
an invalid Referer header is found, the request violates the Start URL
security check. If no Referer header exists, the request does not
violate the Start URL security check. This is the default setting for
profiles created with advanced defaults.
This option allows the Application Firewall to perform Referer
header validation on requests that contain a Referer header, but not
block requests from users whose browsers do not set the Referer
header or who use web proxies or filters that remove that header.
- Always. Always validate the Referer header. If there is no Referer
header, or if the Referer header is invalid, the request violates the
Start URL security check.
Configuring the Start URL List
To configure the Start URL list, you can add relaxations by using the
configuration utility's Add Start URL Relaxation dialog box or modify existing
relaxations by using the Modify Start URL Relaxation dialog box. The contents
of the two dialog boxes are the same.
To configure the Start URL List by using the configuration utility
Profiles.
Open.
3. In the Configure Application Firewall Profiles dialog box, click the
5. In the Modify Start URL Check dialog box, do one of the following:
To create a new relaxation, click Add to open the Add Start URL
Check Relaxation dialog box. (If you select an existing relaxation
and then click Add, you can use the selected relaxation as the basis of
a new relaxation.)
To modify an existing relaxation, select it from the Start URL list
and click Open to open the Modify Start URL Check Relaxation
dialog box.
6. In the dialog box, configure the following elements:
Enabled check box. A relaxation can be in active use (enabled) or can be
inactive (disabled). When you create a relaxation, it is enabled by default.
You disable it by clearing the Enabled check box.
Start URL. In the Start URL text area, you enter a PCRE-format regular
expression that defines the URL that you are adding to the relaxations list.
You can type the regular expression, use the Regex Tokens menu to enter
regular expression elements and symbols directly into the text box, or use
the Regular Expressions Editor to construct the expression.
For information and instructions on using the Regex Tokens menu and the
Regular Expressions Editor, see Configuring the Profile Settings by Using
the Configuration Utility on page122.
The regular expression you type must consist of ASCII characters only. Do
not cut and paste a URL that contains any characters outside of the basic
128-character ASCII set. If you want to include a URL that contains non-
ASCII characters, you must enter those characters manually using the
PCRE hexadecimal character encoding format.
Note: See AppendixA, PCRE Character Encoding Format, on
page347, for a complete description of supported characters and how to
encode them properly when configuring the Application Firewall.
6. Click Create or OK. If finished creating new relaxations, or if you have
modified an existing relaxation, click Close.
Examples
Below are several examples of Start URL relaxations.
Allow users to access the home page at www. exampl e. com:
^ht t p: / / www[ . ] exampl e[ . ] com$
Allow users to access all static HTML (. ht mand . ht ml ), server-parsed
HTML (. ht p and . sht ml ), PHP (. php), and Microsoft ASP (. asp) for-
mat web pages at www. exampl e. com:
^ht t p: / / www[ . ] exampl e[ . ] com/ ( [ 0- 9A- Za- z] [ 0- 9A- Za- z_- ] */ ) *
[ 0- 9A- Za- z] [ 0- 9A- Za- z_. - ] *[ . ] ( asp| ht p| php| s?ht ml ?) $
Allow users to access the same files at www. exampl e- espaol . com,
which contains the n-tilde () special character. This special character must
be represented as an encoded UTF-8 string containing C3 B1, the hexadec-
imal code assigned to that character in the UTF-8 charset:
^ht t p: / / www[ . ] exampl e- espa\ xC3\ xB1ol [ . ] com/ ( [ 0- 9A- Za- z] [ 0- 9A-
Za- z_- ] */ ) *
[ 0- 9A- Za- z] [ 0- 9A- Za- z_. - ] *[ . ] ( asp| ht p| php| s?ht ml ?) $
Allow users to access web pages with pathnames or filenames that contain
non-ASCII characters:
^ht t p: / / www[ . ] exampl e- espa\ xC3\ xB1ol [ . ] com/ ( ( [ 0- 9A- Za-
z] | \ \ x[ 0- 9A- Fa- f ] [ 0- 9A- Fa- f ] ) ( [ 0- 9A- Za- z_- ] | \ \ x[ 0- 9A- Fa- f ] [ 0-
9A- Fa- f ] ) */ ) *
( [ 0- 9A- Za- z] | \ \ x[ 0- 9A- Fa- f ] [ 0- 9A- Fa- f ] ) ( [ 0- 9A- Za- z_- ] | \ \ x[ 0-
9A- Fa- f ] [ 0- 9A- Fa- f ] ) *[ . ] ( asp| ht p| php| s?ht ml ?) $
In the expression above, each character class has been grouped with the
string \ \ x[ 0- 9A-Fa-f] [ 0- 9A-Fa-f] , which will match all properly-
constructed character encoding strings, but not allow stray backslash
characters that are not associated with a UTF-8 character encoding string.
(The double backslash (\ \ ) is an escaped backslash, which tells the Appli-
cation Firewall to interpret it as a literal backslash.)
If you included only one backslash, the Application Firewall would instead
interpret the following left square bracket ([ ) as a literal character rather
than the opening of a character class, which would break the expression.
Allow users to access all GIF (. gi f ), J PEG (. j pg and . j peg), and PNG
(. png) format graphics at www. exampl e. com:
[ 0- 9A- Za- z] [ 0- 9A- Za- z_. - ] *[ . ] ( gi f | j pe?g| png) $
Allow users to access CGI (. cgi ) and PERL (. pl ) scripts in the CGI - BI N
directory only at www. exampl e. com:
^ht t p: / / www[ . ] exampl e[ . ] com/ CGI - BI N/ [ 0- 9A- Za- z] [ 0- 9A- Za- z_. -
] *[ . ] ( cgi | pl ) $
Allow users to access downloadable Microsoft Office and other document
files in the docsar chi ve directory only at www. exampl e. com:
^ht t p: / / www[ . ] exampl e[ . ] com/ docsar chi ve/ [ 0- 9A- Za- z] [ 0- 9A- Za-
z_- . ] *[ . ] ( doc| xl s| pdf | ppt ) $
Caution: Regular expressions are powerful. Especially if you are not
thoroughly familiar with PCRE-format regular expressions, double-check any
regular expressions you write to make sure that they define exactly the URL you
want to add as a relaxation, and nothing else. Careless use of wildcards, and
especially of the dot-asterisk (. *) metacharacter/wildcard combination, can have
results you did not want or expect, such as allowing access to web content that
you did not intend for users to access.
The Deny URL Check
The Deny URL check examines and blocks connections to URLs that are
commonly accessed by hackers and malicious code, or any other URLs you
specify. The Deny URL check prevents attacks against various security
weaknesses known to exist in Web server software or on many Web sites. The
Deny URL check takes priority over the Start URL check, and thus denies
malicious connection attempts even when a Start URL relaxation would normally
allow a request to proceed.
The check contains a list of URLs that are common targets of hackers or
malicious code, and that rarely if ever appear in legitimate requests. You can also
add URLs or URL patterns to the list.
open a profile. To configure all of the general settings, open the Modify Deny
URL dialog box.
Profiles.
Open.
Beside the Deny URL entry, you can select or clear check boxes to enable
following steps.
4. Click Deny URL, and then click Modify.
5. In the Modify Deny URL Check dialog box, click the General tab.
Deny URL Check Actions.
Modify Deny URL Check Actions
The Check Actions control how the Deny URL check functions. They are:
Block. Block connections that violate the Deny URL security check.
defaults. Clear/select the Deny URL check to disable/enable blocking.
You normally will want to leave the Deny URL check enabled. It provides
an effective second line of defense that is narrowly tailored to prevent
known attacks, and does not require much processing.
Note: To enable the Deny URL check, in the Checks tab of this dialog
box you must also enable each specific Deny URL rule you want the
Application Firewall to enforce.
Learn. The learning feature is not available with the Deny URL check, so
the Learn check box is greyed out.
Log. Log connections that violate the Deny URL security check. Enabled
by default in profiles created with either basic or advanced defaults. You
normally do not want to disable logging for this or any security check. If
anything unexpected happens, the logs are an important resource for trou-
bleshooting.
Statistics. Generate statistics for connections that violate the Deny URL
security check. Enabled by default in profiles created with either basic or
advanced defaults. You normally do not want to disable statistics. They can
help you monitor the types of attacks that a particular security check is
detecting so that you can determine how effective that check is on your pro-
tected Web sites.
Configuring the Deny URL List
To configure the Deny URL list, you first enable the default Deny URLs that you
want to use. You can also add additional URLs to the Deny URL list.
To configure this list, you use the configuration utility's Add Deny URL
Relaxation dialog box or modify existing relaxations by using the Modify Deny
URL Relaxation dialog box. The contents of the two dialog boxes are the same.
To configure the Deny URL List by using the configuration utility
Profiles.
Open.
4. Click Deny URL, and then click Modify.
5. In the Deny URL Check dialog box, do one of the following:
To create a new deny URL, click Add to open the Add Deny URL
Check Relaxation dialog box. (If you select an existing relaxation
a new relaxation.)
To modify an existing deny URL, select it from the Deny URL list
and click Open to open the Modify Deny URL Check Relaxation
dialog box.
To enable/disable an existing deny URL, select it from the Deny
URL list and click Enable/Disable.
Important: To fully enable the Deny URL security check, you
should enable the default deny URLs on the Deny URL list. To do
this, select all default deny URLs, then click Enable.
To remove an existing deny URL, select it from the Deny URL list
and click Remove.
6. In the Add/Modify Deny URL dialog box, configure the following elements:
Enabled check box. A deny URL can be in active use (enabled) or can be
inactive (disabled). When you create a deny URL, it is disabled by default.
You enable it by selecting the Enabled check box.
Deny URL. In the Deny URL text area, you enter a PCRE-format regular
expression that defines the URL that you are adding to the list. You can
type the regular expression, use the Regex Tokens menu to enter regular
expression elements and symbols directly into the text box, or use the Reg-
ular Expressions Editor to construct the expression.
For information and instructions on using the Regex Tokens menu and the
Regular Expressions Editor, see Configuring the Profile Settings by Using
the Configuration Utility on page122.
The regular expression you type must consist of ASCII characters only. Do
not cut and paste a URL that contains any characters outside of the basic
128-character ASCII set. If you want to include a URL that contains non-
ASCII characters, you must enter those characters manually using the
PCRE hexadecimal character encoding format.
6. Click Create or OK. If finished creating new deny URLs, or if you have
modified an existing deny URL, click Close.
Examples
Below are several examples of Deny URLs.
Do not allow users to access the image server at i mages. exampl e. com
directly:
^ht t p: / / i mages[ . ] exampl e[ . ] com$
Do not allow users to access CGI (. cgi ) or PERL (. pl ) scripts directly:
[ 0- 9A- Za- z] [ 0- 9A- Za- z_. - ] *[ . ] ( cgi | pl ) $
Deny users direct access to CGI (. cgi ) or PERL (. pl ) scripts at the host
ht t p: / / www. exampl e- espaol . com, which contains the n-tilde ()
non-ASCII special character. This special character must be represented as
an encoded UTF-8 string containing C3 B1, the hexadecimal code assigned
to that character in the UTF-8 charset:
Za- z_- ] */ ) *
[ 0- 9A- Za- z] [ 0- 9A- Za- z_. - ] *[ . ] ( cgi | pl ) $
page347 for a complete description of supported characters and how to
Deny users direct access to scripts at the host ht t p: / / www. exampl e-
espaol . com, when the server contains pathnames or filenames that con-
tain non-ASCII characters:
9A- Fa- f ] ) */ ) *
9A- Fa- f ] [ 0- 9A- Fa- f ] ) *[ . ] ( cgi | pl ) $
The double backslash (\ \ ) is an escaped backslash, which tells the Appli-
cation Firewall to interpret it as a literal backslash. If you included only one
backslash, the Application Firewall would instead interpret the following
left square bracket ([ ) as a literal character rather than the opening of a
character class, which would break the expression.
thoroughly familiar with PCRE-format regular expressions, double-check
any regular expressions you write to make sure that they define exactly the
URL you want to add as a relaxation, and nothing else. Careless use of
wildcards, and especially of the dot-asterisk (. *) metacharacter/wildcard
combination, can have results you did not want or expect, such as allowing
access to web content that you did not intend for users to access.
The Cookie Consistency Check
The Cookie Consistency check examines cookies returned by users to see that
they match cookies your Web site set for that user. If a modified cookie is found,
the cookie is stripped from the request before the request is forwarded to the Web
server. This check applies to requests only.
The Cookie Consistency check prevents attackers from modifying cookies set by
a protected Web site and returning those modified cookies to the Web site. An
attacker would normally modify a cookie to log on to the Web site under another
users credentials, and thereby gain access to sensitive private information, or to
cause a buffer overflow. The Buffer Overflow check, discussed on page190,
protects against attempts to cause a buffer overflow by using a ridiculously
overlong cookie. The Cookie Consistency check focuses on the first scenario.
In any of your Application Firewall profiles, you configure general settings for
the Cookie Consistency security check in the pane that opens when you open a
profile. The default settings are the same in all profiles. To configure all of the
general settings, open the Modify Cookie Consistency Check dialog box.
Profiles.
Open.
Beside the Cookie Consistency entry, you can select or clear check boxes
to enable or disable actions that can be taken when a connection does not
meet the specified criteria. To access all of the general settings, continue
with the following steps.
4. Click Cookie Consistency, and then click Modify.
5. In the Modify Cookie Consistency Check dialog box, click the General
tab.
Cookie Consistency Check Actions.
7. Click OK when finished, and then click Close to close the dialog box.
Modify Cookie Consistency Check Actions
The Check Actions control how the Cookie Consistency check functions. They
are:
Block. Block connections that violate the Cookie Consistency security
check. Enabled by default in profiles created with both basic and advanced
defaults. Clear/select the check box to disable/enable blocking.
For a profile with basic defaults, you probably do not want to enable the
Cookie Consistency security check. In these profiles the Cookie Consis-
tency check is turned off and all of its Check Action settings are disabled.
Unless your protected Web sites require users to log on and set cookies to
maintain logon information, you probably do not need the protection that
this rule provides. The Buffer Overflow check provides sufficient
protection against the only other meaningful attack an attacker can launch
by tampering with a cookie.
For a profile with advanced defaults, there are many reasons why you might
want to disable blocking. The most common is to prevent problems when
you first install the Application Firewall. No profile has any default cookie
relaxations defined. If your Web server sets user-modifiable cookies (such
as those created by client-side J avascripts in Web forms), unless you
disable blocking the Application Firewall will strip those cookies from
requests sent to your Web server. You must either manually add these
cookies to the Cookie Consistency list when you first configure the profile,
or allow the learning feature to generate a list of learned cookie relaxations
for you. If you prefer to let learning do the work, you need to turn off
blocking until learning has seen enough traffic to generate the necessary list
of relaxations.
tected Web sites, and generate a list of recommended cookie expressions to
add to the Cookie Consistency list. Disabled by default in profiles created
with basic defaults, and enabled by default in profiles created with
advanced defaults. Clear/select the check box to disable/enable learning.
For a profile with basic defaults, you should not enable learning for the
Cookie Consistency security check unless you plan to enable and use it. If
you want to use the Cookie Consistency check in this profile, you should
enable learning, logging, and statistics, and then follow the Cookie Consis-
tency check instructions for profiles created with Advanced Defaults.
For a profile with advanced defaults, you can either leave learning enabled,
or disable it. If you prefer to let learning do the work, you need to turn off
blocking until learning has seen enough traffic to generate the necessary list
of cookie relaxations. You then review the learned relaxations and accept
those that you want to allow. When learning has seen enough traffic to
generate a good list, you re-enable blocking, and are done.
To disable learning and still avoid false positives, you must manually add
any user-modifiable cookies to the Cookie Consistency check relaxations
list when you first configure the profile. Unless you are very familiar with
your Web sites, you will probably find it easier to let learning generate the
list for you.
Log. Log connections that violate the Cookie Consistency check. Enabled
by default in profiles created with either basic or advanced defaults. Clear/
select the check box to disable/enable logging. You normally do not want to
disable logging for this or any security check. If anything unexpected hap-
pens, the logs are an important resource for troubleshooting.
Statistics. Generate statistics for connections that violate the Cookie Con-
sistency check. Enabled by default in profiles created with either basic or
advanced defaults. Clear/select the check box to disable/enable statistics.
You normally do not want to disable statistics. They can help you monitor
the types of attacks that a particular security check is detecting so that you
can determine how effective that check is on your protected Web sites.
Configuring the Cookie Consistency List
To configure the Cookie Consistency list, you can add cookie expressions by
using the configuration utility's Add Cookie Consistency Check Relaxation
dialog box or modify existing relaxations by using the Modify Cookie
Consistency Check Relaxation dialog box. The contents of the two dialog boxes
are the same.
To configure the Cookie Consistency List by using the configuration utility
Profiles.
Open.
4. Click Cookie Consistency, and then click Modify.
5. In the Modify Cookie Consistency Check dialog box, do one of the
following:
To create a new relaxation, click Add to open the Add Cookie
Consistency Check Relaxation dialog box. (If you select an existing
relaxation and then click Add, you can use the selected relaxation as
the basis of a new relaxation.)
To modify an existing relaxation, select it from the Cookie
Consistency list and click Open to open the Modify Cookie
Enabled check box. A relaxation can be in active use (enabled) or
can be inactive (disabled). When you create a relaxation, it is enabled
by default. You disable it by clearing the Enabled check box.
Cookie. In the Cookie text area, you enter a PCRE-format regular
expression that defines the cookie that you are adding to the list. You
can type the regular expression, use the Regex Tokens menu to enter
regular expression elements and symbols directly into the text box, or
use the Regular Expressions Editor to construct the expression.
For information and instructions on using the Regex Tokens menu
and the Regular Expressions Editor, see Configuring the Profile
Settings by Using the Configuration Utility on page122.
The regular expression you type must consist of ASCII characters
only. Do not cut and paste a URL that contains any characters outside
of the basic 128-character ASCII set. If you want to include a cookie
expression that contains non-ASCII characters, you must enter those
characters manually using the PCRE hexadecimal character encoding
format.
7. Click Create or OK. If finished creating new cookie expressions, or if you
have modified an existing cookie expression, click Close.
Examples
Below are several examples of cookie expressions.
Allow cookies that begin with the string l ogon_ and are followed with the
users logon name to be user-modifiable:
^l ogon_[ 0- 9A- Za- z] +$
If your Web site preserves user logon information using a cookie similar to
this, you can modify this regular expression to match the cookies your Web
site uses. For example, if your Web site has a special logon for Turkish-
speaking customers, you might have a cookie that begins with the string
t r ke- l ogon_. The special characters in that string must be represented
as encoded UTF-8 strings.
^t \ xC3\ xBCr k\ xC3\ xA7e- l ogon_[ 0- 9A- Za- z] +$
If you want to allow encoded characters in the remainder logon name as
well as the first portion, you must group the character class at the end with
the string \ \ x[ 0- 9A- Fa- f ] [ 0- 9A- Fa- f ] , as shown below:
^t \ xC3\ xBCr k\ xC3\ xA7e- l ogon_( [ 0- 9A- Za- z] | \ \ x[ 0- 9A- Fa- f ] [ 0- 9A-
Fa- f ] ) +$
page347 for a complete description of supported special characters and
how to encode them properly when configuring the Application Firewall.
Allow cookies that contain the string sc- i t em_, followed by the ID of an
item that the user has added to his shopping cart ([ 0- 9A- Za- z] +), a sec-
ond underscore (_), and finally the number of these items he wants ([ 1-
9] [ 0- 9] ?), to be user-modifiable:
^sc- i t em_[ 0- 9A- Za- z] +_[ 1- 9] [ 0- 9] ?$
The preceding regular expression does not restrict the length of the item ID,
but carefully restricts the number of each item a user is allowed to order to
ninety-nine or fewer.
regular expressions you write to make sure that they define exactly the URL you
results you did not want or expect, such as allowing access to web content that
you did not intend for users to access.
The Buffer Overflow Check
The Buffer Overflow check detects attempts to cause a buffer overflow on the
Web server. If the Application Firewall detects a URL, cookie or header longer
than the specified maximum length in a request, it blocks that request because it
might be an attempt to cause a buffer overflow.
The Buffer Overflow check prevents attacks against insecure operating system or
Web server software that can crash or behave unpredictably when it receives a
data string that is larger than it can handle. Proper programming techniques
prevent buffer overflows by checking incoming data and either rejecting or
truncating overlong strings. Many programs, however, do not check all incoming
data, and are therefore vulnerable to buffer overflows. This issue especially
affects older versions of Web server software and operating systems, many of
which are still in use.
open a profile. To configure all of the general settings, open the Modify Buffer
Overflow dialog box.
Profiles.
Open.
Beside the Buffer Overflow entry, you can select or clear check boxes to
enable or disable actions that can be taken when a connection does not
4. Click Buffer Overflow, and then click Modify.
5. In the Modify Buffer Overflow Check dialog box, click the General tab.
Buffer Overflow Check Actions.
Modify Buffer Overflow Check Actions
The Check Actions control how the Buffer Overflow check functions. They are:
Block. Block connections that violate the Buffer Overflow security check.
defaults. Clear/select the Buffer Overflow check to disable/enable blocking.
You normally will want to leave the Buffer Overflow check enabled. It
provides effective protection against many common attacks, and requires
little processing time.
Learn. The learning feature is not available with the Buffer Overflow
check, so the Learn check box is greyed out.
Log. Log connections that violate the Buffer Overflow security check.
Enabled by default in profiles created with either basic or advanced
defaults. You normally do not want to disable logging for this or any secu-
rity check. If anything unexpected happens, the logs are an important
resource for troubleshooting.
Statistics. Generate statistics for connections that violate the Buffer Over-
flow security check. Enabled by default in profiles created with either basic
or advanced defaults. You normally do not want to disable statistics. They
can help you monitor the types of attacks that a particular security check is
detecting so that you can determine how effective that check is on your pro-
tected Web sites.
Configuring the Buffer Overflow Checks
To configure the Buffer Overflow checks, you modify the three parameters on the
Modify Buffer Overflow Check dialog box, Checks tab. These parameters set the
total length of HTTP headers, length of each individual URL, and length of each
individual cookie allowed before the Application Firewall treats the request as a
buffer overflow attack and blocks it.
To configure the Buffer Overflow checks by using the configuration utility
Profiles.
Open.
4. Click Buffer Overflow, and then click Modify.
5. In the Modify Buffer Overflow Check dialog box, configure the following
elements:
- Maximum URL Length. The maximum length the Application
Firewall will allow for a requested URL. Set to 1024 by default. You
can set this to any positive integer between 0 and 65536.
- Maximum Cookie Length. The maximum length the Application
Firewall will allow for an individual cookie in a request. Set to 4096
by default. You can set this to any positive integer between 0 and
65536.
- Maximum Header Length. The maximum length the Application
Firewall will allow for HTTP headers. Set to 4096 by default. You
can set this to any positive integer between 0 and 65536.
The Credit Card Check
The Credit Card check provides special handling for credit card numbers. A Web
application does not usually send a credit card number in a response to a user
request, even when the user supplies a credit card number in the request. The
Application Firewall examines Web server responses, including headers, for
credit card numbers. If it finds a credit card number in the response, and the
administrator has not configured it to allow credit card numbers to be sent, it
responds in one of two ways:
It blocks the response.
It replaces all but the final group of digits in the credit card with xs. For
example, a credit card number of 9876- 5432- 1234- 5678 would be ren-
dered xxxx- xxxx- xxxx- 5678.
The Credit Card check prevents attackers from exploiting a security flaw in your
Web server software or on your Web site to obtain credit card numbers of your
customers. If your Web sites do not have access to credit card information, you do
not need to configure this check. If your Web sites do have access to credit card
information, such as via a shopping cart application, or your Web sites have
access to back-end database servers that contain customer credit card numbers,
you should configure protection for each type of credit card that you accept.
Note: A Web site that does not access a back-end SQL database usually does
not have access to sensitive private information, such as credit card numbers.
open a profile. To configure all of the general settings, open the Modify Credit
Card Check dialog box.
Profiles.
Open.
Beside the Credit Card entry, you can select or clear check boxes to enable
following steps.
4. Click Credit Card, and then click Modify.
5. In the Modify Credit Card Check dialog box, click the General tab.
Credit Card Check Actions.
Modify Credit Card Check Actions
The General tab contains the Action settings, which control how the Credit Card
check functions. These settings are:
Block. Block connections that violate the Credit Card check. Disabled by
default in profiles created with both basic and advanced defaults. Clear/
select the Credit Card check to disable/enable blocking.
Note: To enable the Credit Card check, after you enable blocking you
must also enable protection in the Settings tab of this dialog box for each
specific type of credit card you want the Application Firewall to protect.
Learn. Learning is disabled for the Credit Card check, so the Learn check
box is greyed out.
Log. Log any connections that violate the Credit Card check. Disabled by
default in all profiles. You normally will want to enable logging if you
enable this security check. If anything unexpected happens, the logs are an
important resource to troubleshoot.
Statistics. Generate statistics for connections that violate the Credit Card
check. Disabled by default in all profiles. You normally will want to enable
statistics if you enable this security check. They can help you monitor the
types of attacks that a particular check is seeing, and determine how effec-
tive that check is on your protected Web sites.
X-Out. Mask any credit card numbers it detects in a response with the letter
X, as described earlier in this section. Disabled by default in all profiles.
You enable/disable x-out by checking/clearing the X-out check box.
Modify Credit Card Check Parameters
Beneath the Check Actions section of the General tab is the Parameters section. It
contains only one entry.
Maximum credit cards allowed per page. Allow up to the specified
number of credit card numbers per page in responses without masking the
credit card numbers or blocking the response. The Maximum is set to zero
(0) by default. Usually no web pages will contain unmasked credit card
numbers, but occasionally a web page might legitimately contain a credit
card number or even a list of credit card numbers. You configure the
maximum number of credit card numbers allowed by modifying the value
in the Maximum credit cards allowed per page text box.
Configuring the Credit Card List
To configure the Credit Card list, you enable or disable protection for each credit
card in the Modify Credit Card Check dialog box, Checks tab.
To configure the Credit Card List by using the configuration utility
Profiles.
Open.
4. Click Credit Card, and then click Modify.
5. In the dialog box, select each credit card type that you want to protect, and
then click Protect.
Note: You can hold down your Shi f t or Ct r l key while choosing credit
card types, and then enable or disable several credit card types at once by
clicking the Protect or Unprotect button while multiple credit card types
are selected.
If you want to cancel protection for a credit card type, select that credit card
type and then click Unprotect.
The Safe Object Check
The Safe Object check provides user-configurable protection for sensitive
business information, such as customer numbers, order numbers, and country- or
region-specific telephone numbers or postal codes. A user-defined regular
expression or custom plug-in tells the Application Firewall the format of this
information, and defines the rules to be used to protect it.
If the Application Firewall detects a string in a user request that matches a safe
object definition, depending on how you configured that particular Safe Object
rule, it either blocks the response, masks the protected information, or removes
the protected information from the response before sending it to the user.
You configure the Safe Object check the Modify Safe Object Check dialog box.
Unlike all other checks, the Modify Safe Object Check dialog box does not have
separate General and Checks tabs.
To configure the Safe Object Check by using the configuration utility
Profiles.
Open.
5. In the Modify Safe Object Check dialog box, do one of the following:
To create a new safe object, click Add to open the Add Safe Object
dialog box, and do the steps. (If you select an existing safe object and
then click Add, you can use the selected safe object as the basis of a
new safe object.)
To modify an existing safe object, select it from the Safe Objects list
and click Open to open the Modify Safe Object dialog box.
Enabled check box. A safe object can be in active use (enabled) or
can be inactive (disabled). When you create a safe object, it is
enabled by default. You disable it by clearing the Enabled check box.
Safe Object Name. A name for your new safe object. The name can
begin with a letter, number, or the underscore symbol, and can consist
of from one to 127 letters, numbers, and the hyphen (-), period (.)
pound (#), space ( ), at sign (@), equals (=), colon (:), and underscore
(_) symbols.
Actions. Enable/disable each of the actions described below by
selecting/clearing the check box.
Block. Block responses that contain a string that matches a
Safe Object definition. Disabled by default in all profiles.
X-Out. Mask any strings it detects in a response that match a
Safe Object definition with the letter X. Disabled by default
in all profiles.
Log. Tells the Application Firewall to log any connections that
contain a string that matches a Safe Object definition. Disabled
by default in all profiles. You normally will want to enable
logging if you enable this security check. If anything
unexpected happens, the logs are an important resource to
troubleshoot.
Statistics. Generate statistics for responses that contain a string
that matches a Safe Object definition. Disabled by default in all
profiles. You normally will want to enable statistics if you
enable this security check. Statistics provide a useful means of
measuring how often a particular security check is used when
protecting your Web sites, and how effective it is.
Remove. Remove from a response any strings that match a safe
object definition it detects. Disabled by default in all profiles.
Regular Expression. Enter a PCRE-format regular expression that
defines the safe object. You can type the regular expression, use the
Regex Tokens menu to enter regular expression elements and
symbols directly into the text box, or use the Regular Expressions
Editor to construct the expression.
only. Do not cut and paste characters outside of the basic 128-
character ASCII set. If you want to include non-ASCII characters,
you must enter those characters manually using the PCRE
hexadecimal character encoding format.
page347, for a complete description of supported characters and how
to encode them properly when configuring the Application Firewall.
Maximum Match Length. Enter a positive integer that represents
the maximum length of the string you want to match. For example, if
you want to match U.S. social security numbers, you should enter
eleven (11) in this field. That allows your regular expression to match
a string with nine numerals and two hyphens. If you want to match
California drivers license numbers, you should enter eight (8). If you
want to match an Example Manufacturing, Inc. customer ID such as
that shown above, you should enter twenty (20).
Caution: If you do not enter a maximum match length in this field,
the Application Firewall will use a default value of one (1) when
filtering for strings using your Safe Object expressions. This will
cause most Safe Object expressions to fail to match their target
strings.
6. Click Create or OK. If finished creating new safe objects, or if you have
modified an existing safe object, click Close.
Examples
Below are several PCRE expression examples for safe objects that protect types
of information that you might want to prevent your Web site(s) from displaying to
users.
Look for strings that appear to be U.S. social security numbers, which con-
sist of three numerals (the first of which must not be a zero), followed by a
hyphen, followed by two more numerals, followed by a second hyphen, and
ending with a string of four more numerals:
[ 1- 9] [ 0- 9] {2, 2}- [ 0- 9] {2, 2}- [ 0- 9] {4, 4}
Note: Do not use start anchors (^) at the beginning of Safe Object
expressions, or end anchors ($) at the end of Safe Object expressions.
These PCRE entities are not supported in Safe Object expressions, and if
used, will cause your expression not to match what it was intended to
match.
Look for strings that appear to be California drivers license IDs, which
start with a letter, and are followed by a string of exactly seven numerals:
[ A- Za- z] [ 0- 9] {7, 7}
Look for strings that appear to be Example Manufacturing customer IDs
which consist of a string of five hexadecimal characters (all the numerals
and the letters A through F), followed by a hyphen, followed by a three-let-
ter code, followed by a second hyphen, and ending with a string of ten
numerals:
[ 0- 9A- Fa- f ] {5, 5}- [ A- Za- z] {3, 3}- [ 0- 9] {10, 10}
any regular expressions you write to ensure that they define exactly the type
of string you want to add as a Safe Object definition, and nothing else.
Careless use of wildcards, and especially of the dot-asterisk (. *)
metacharacter/wildcard combination, can have results you did not want or
expect, such as blocking access to web content that you did not intend to
block.
CHAPTER 9
The HTML Security Checks
This chapter describes in detail the Application Firewall security checks that
apply specifically to HTML profiles. It explains how each security check
operates, what types of attacks it helps prevent, and how the configuration details
affect how that security check filters a request or response. This information is
intended for system administrators who need to understand a particular HTML
security check in detail to configure it properly for their Web sites.
Note: You do not need to read this chapter unless you need to understand in
detail how specific HTML security checks work, what all the options are for
each, and how each option affects its operation.
The Form Field Consistency Check
The Form Field Consistency check examines the Web forms returned by users of
your Web site, and verifies that the Web form was not modified inappropriately
by the client. This check applies only to HTML requests that contain a Web form,
with or without data. It does not apply to XML requests.
The Form Field Consistency check prevents clients from making unauthorized
changes to the structure of the Web forms on your Web site when they are filling
out a Web form and submitting data using that form. It also ensures that the data a
user submits meets the HTML restrictions for length and type, and that data in
hidden fields is not modified. This prevents an attacker from tampering with a
Web form and using the modified form to gain unauthorized access to Web site,
redirect the output of a contact form that uses an insecure script and thereby send
unsolicited bulk email, or exploit a vulnerability in your Web server software to
gain control of the Web server or the underlying operating system. Web forms are
a weak link on many Web sites and attract a wide range of attacks.
The Form Field Consistency check verifies all of the following:
If a field is sent to the user, the check ensures that it is returned by the user.
The check enforces HTML field lengths and types.
If your Web server does not send a field to the user, the check does not
allow the user to add that field and return data in it.
If a field is a read-only or hidden field, the check verifies that the data has
not changed.
If a field is a list box or radio button field, the check verifies that the data in
the response corresponds to one or more of the values in that field.
If a Web form returned by a user violates one or more of the form field
consistency checks, and you have not configured the Application Firewall to
allow that Web form to violate the Form Field Consistency checks in that manner,
the request is blocked.
Note: The Form Field Consistency check enforces HTML restrictions on data
type and length, but does not otherwise validate the data in Web forms. You can
use the Field Formats check to set up rules that validate data returned in specific
form fields on your Web forms.
open a profile. To configure all of the general settings, open the Modify Deny
URL dialog box.
Profiles.
Open.
Beside the Form Field Consistency entry, you can select or clear check
boxes to enable or disable actions that can be taken when a connection
does not meet the specified criteria. To access all of the general settings,
continue with the following steps.
4. Click Form Field Consistency, and then click Modify.
5. In the Modify Form Field Consistency Check dialog box, click the
General tab.
Form Field Consistency Check Actions.
Chapter 9 The HTML Security Checks 203
Modify Form Field Consistency Check Actions
The Check Actions control how the Form Field Consistency check functions.
They are:
Block. Tells the Application Firewall to block connections that violate the
Form Field Consistency check. Disabled by default in profiles created with
basic defaults, and enabled by default in profiles created with advanced
defaults. Clear/select the check box to disable/enable blocking
If you created a profile with basic defaults, you probably do not want to
enable the Form Field Consistency rule. Configuring the Form Field
Consistency check correctly requires that you use learning mode to
generate the relaxations list for this check. If you want to use this check on
your Web site, you should enable learning, logging, and statistics, but leave
blocking disabled. Then, follow the recommendations for profiles created
with advanced defaults.
If you created a profile with advanced defaults, there are many reasons why
you might want to disable blocking for the Form Field Consistency check.
The most common is to prevent false positives when you first install the
Application Firewall. No profile has any default Form Field Consistency
relaxations defined. If your Web server uses Web forms that are modified
by the users browser, unless you disable blocking the Application Firewall
will block the user from using those Web forms to send data to your Web
server. You must either manually add those Web forms to the Form Field
Consistency relaxations list when you first configure the profile, or allow
the learning feature to generate a list of learned Form Field Consistency
relaxations for you.
If you prefer to let learning do the work, you turn off blocking until learning
has seen enough traffic to generate the necessary list of relaxations.
mended form field relaxations to add to the Form Field Consistency relax-
ations list. Disabled by default in profiles created with basic defaults, and
enabled by default in profiles created with advanced defaults. Clear/select
the check box to disable/enable learning.
If you created a profile with basic defaults, you should not enable learning
for the Form Field Consistency rule unless you plan to enable and use this
check. If you want to use the Form Field Consistency check in this profile,
you should enable learning, logging, and statistics, and then follow the
Form Field Consistency check instructions for profiles created with
advanced defaults.
If you created a profile with advanced defaults, you have a choice. You can
leave learning enabled, or disable it. If you prefer to let learning do the
work, you turn off blocking until learning has seen enough traffic to
generate the necessary list of Form Field Consistency relaxations. You then
review the learned relaxations and accept those that you want to allow.
When learning has seen enough traffic to generate a good list, you re-enable
blocking, and are done.
any Web forms modified on the users browser to the Form Field Consis-
tency check relaxations list when you first configure the profile. Unless you
are very familiar with your Web sites, you will probably find it easier to let
learning generate the list for you.
Form Field Consistency check. Disabled by default in profiles created with
basic defaults, and enabled by default in profiles created with advanced
defaults. Clear/select the check box to disable/enable logging.
If you created a profile with basic defaults, you should not enable logging
Advanced Defaults.
If you created a profile with advanced defaults, you normally will not want
to disable logging for this or any check you are using to filter traffic. If
anything unexpected happens, the logs are an important resource to trouble-
shoot.
tions that violate the Form Field Consistency check. Disabled by default in
profiles created with basic defaults, and enabled by default in profiles cre-
ated with advanced defaults. Clear/select the check box to disable/enable
statistics.
If you created a profile with basic defaults, you should not enable statistics
advanced defaults.
If you created a profile with advanced defaults, you normally will not want
to disable statistics for this or any check you are using to filter traffic.
Statistics provide a useful means of measuring how often a particular
security check is used when protecting your Web sites, and how effective it
is.
Configuring the Form Field Consistency List
To configure the Form Field Consistency list, you can add relaxations by using
the configuration utility's Add Form Field Consistency Check Relaxation dialog
box, or modify existing relaxations by using the Modify Form Field Consistency
Check Relaxation dialog box. The contents of the two dialog boxes are the same.
To configure the Form Field Consistency List by using the configuration
utility
Profiles.
Open.
4. Click Form Field Consistency, and then click Modify.
5. In the Modify Form Field Consistency Check dialog box, do one of the
following:
To create a new relaxation, click Add to open the Add Form Field
Consistency Check Relaxation dialog box. (If you select an existing
To modify an existing relaxation, select it from the Form Field
Consistency list and click Open to open the Modify Form Field
Field Name. In the text area in the Field Name section, you enter
either a literal string or a PCRE-format regular expression that
defines the name of the form field that you are adding to the
relaxations list. If you use a regular expression, you also check the
check box labeled, Is Field Name Regular Expression.
You can type the regular expression, use the Regex Tokens menu to
enter regular expression elements and symbols directly into the text
box, or use the Expressions Editor to construct the expression. For
information and instructions on using the Regex Tokens menu and
the Regular Expressions Editor, see Configuring the Profile Settings
by Using the Configuration Utility on page122 and following.
only. Do not cut and paste a form field name that contains any
characters outside of the basic ASCII character set. If you want to
include a field name that contains non-ASCII characters, you must
enter those characters manually using the PCRE UTF-8 hexadecimal
character encoding format. For more information, see AppendixA,
Caution: If any Web form on your protected Web sites has a field
named as_f i d, you must disable form tagging. If you do not, the
Application Firewall will generate a field consistency check error and
block the web page that contains this Web form. See Enable Form
Tagging on page126 for instructions.
Action URL. In the text area in the Action URL section, you enter a
PCRE-format regular expression that defines the URL of the Web
forms you want to exempt from this rule.
Note: The regular expression you type must consist of ASCII
characters only. Do not cut and paste an action URL that contains any
include an action URL that contains non-ASCII characters, you must
enter those characters manually using the PCRE hexadecimal
Examples
Below are several examples of Form Field Consistency relaxations.
Choose form fields with the name User Type:
^User Type$
Choose form fields with names beginning with User Type_ and followed
by a string beginning with a letter or number and consisting of from one to
twenty-one letters, numbers, or the apostrophe or hyphen symbol:
^User Type_[ 0- 9A- Za- z] [ 0- 9A- Za- z' - ] {0, 20}$
You can modify this regular expression to match the form fields your Web
site uses. For example, if your Web site has Turkish-speaking customers
whose first names may contain special characters, you might have a form
field that begins with the string Tr ke- User Type_ on their logon page.
The special characters in that string must be represented as encoded UTF-8
strings.
^T\ xC3\ xBCr k\ xC3\ xA7e- User Type_[ 0- 9A- Za- z] ++$
If you want to allow encoded characters in the remainder of the field name
as well as the first portion, you must group the character class at the end
with the string \ \ x[ 0- 9A- Fa- f ] [ 0- 9A- Fa- f ] , as shown below:
^T\ xC3\ xBCr k\ xC3\ xA7e- User Type_( [ 0- 9A- Za- z] | \ \ x[ 0- 9A- Fa- f ] [ 0-
9A- Fa- f ] ) +$
page347, for a complete description of supported special characters and
Choose form field names that begin with a letter or number, consist of a
combination of letters and/or numbers only, and that contain the string Num
anywhere in the string:
^[ 0- 9A- Za- z] *Num[ 0- 9A- Za- z] *$
Below are several example Form Field Action URL expressions.
Choose URLs beginning with ht t p: / / www. exampl e. com/
sear ch. pl ?, and containing any string after the query except for a new
query:
^ht t p: / / www[ . ] exampl e[ . ] com/ sear ch[ . ] pl \ ?[ ^?] *$
Choose URLs beginning with ht t p: / / www. exampl e- espaol . com,
which contains the n-tilde () non-ASCII special character. This special
character must be represented as an encoded UTF-8 string containing C3
B1, the hexadecimal code assigned to that character in the UTF-8 charset:
Za- z_- ] */ ) *
[ 0- 9A- Za- z] [ 0- 9A- Za- z_- . ] *[ . ] ( asp| ht p| php| s?ht ml ?) $
Allow users to access web pages beginning with ht t p: / / www. exampl e-
espaol . com, when the server contains pathnames or filenames that
contain non-ASCII characters:
9A- Fa- f ] ) */ ) *
The double backslash (\ \ ) is an escaped backslash, which tells the
Application Firewall to interpret it as a literal backslash. If you included
only one backslash, the Application Firewall would instead interpret the
following left square bracket ([ ) as a literal character rather than the
opening of a character class, which would break the expression.
Choose all URLs that contain the string / sear ch. cgi ?:
^[ ^?<>] */ sear ch[ . ] cgi \ ?[ ^?<>] *$
regular expressions you write to ensure that they match exactly what you want
them to match, and nothing else. Careless use of wildcards, and especially of the
dot-asterisk (. *) metacharacter/wildcard combination, can have results you did
not want or expect.
The Field Formats Check
The Field Formats check requires that you tell the Application Firewall about the
type and length of data expected in each form field on each Web form you want to
protect. It then examines the data users return using Web forms on your Web site
and verifies that the data meets the formatting restrictions you set for that form
field. If any Web form data does not meet your formatting restrictions, the
Application Firewall blocks the users request. This check applies to HTML
requests only; it does not apply to XML requests.
The Field Formats check prevents an attacker from returning inappropriate Web
form data to your Web site, which in turn prevents certain types of attacks on your
Web site and back-end database servers. For example, if a particular field expects
the user to enter a phone number, the Field Formats check examines the users
response to ensure that the data matches the format for a phone number. If a
particular field expects a first name, the Field Formats check ensures that the data
in that field is of a type and length appropriate for a first name. It does the same
thing for each form field you configure it to protect.
You can configure the Field Formats check manually, or by enabling learning and
then approving the configuration rules that learning generates.
Note: The Field Formats check provides a different type of protection than the
Form Field Consistency check. The Form Field Consistency check verifies that
the structure of the Web forms returned by users is intact, that data format
restrictions configured in the HTML are respected, and that data in hidden fields
has not been modified. It can do this without any specific knowledge about your
Web forms other than what it derives from the Web form itself.
The Field Formats check verifies that the data in each form field matches the
specific formatting restrictions you configured manually, or generated using the
learning feature and approved. In other words, the Form Field Consistency check
enforces general Web form security, while the Field Formats check enforces the
specific rules you set for your Web forms.
the Field Formats security check in the pane that opens when you open a profile.
The default settings are the same in all profiles. To configure all of the general
settings, open the Modify Field Formats Check dialog box.
Profiles.
Open.
Beside the Field Formats entry, you can select or clear check boxes to
4. Click Field Formats, and then click Modify.
5. In the Modify Field Formats Check dialog box, click the General tab.
Field Formats Check Actions.
Modify Field Format Check Actions
The Check Actions control how the Field Format check functions. They are:
Field Formats check. Enabled by default in all profiles. Clear/select the
check box to disable/enable blocking.
If you created a profile with basic defaults, you probably do not want to
configure the Field Formats rule. It requires significant effort to configure,
and is useful primarily for Web forms that do not already enforce the
correct types and lengths of data in each field. If you want to use the Field
Formats check, you should enable learning, and then follow the instructions
for Field Format profiles created with advanced defaults.
If you created a profile with advanced defaults, there are many reasons why
you might want to disable blocking for the Field Formats check. The most
common is to prevent false positives when you first configure this check, or
when you manually assign field formats to the fields in new Web forms on
your Web site.
If you prefer to let learning generate a list of recommended field formats,
you should also turn off blocking until learning has seen enough traffic to
generate a list of recommended field formats and you have approved some
or all of those field formats. You should then leave blocking turned off for a
few days and observe the logs to ensure that the recommended field formats
are working correctly with your forms before you re-enable blocking.
mended field formats for your Web forms. Disabled by default in profiles
created with basic defaults, and enabled by default in profiles created with
advanced defaults. Clear/select the check box to disable/enable learning.
for the Field Formats check unless you plan to use this check. If you want to
use the Field Formats check in this profile, you should enable learning,
logging, and statistics, and then follow the Field Formats check instructions
for profiles created with advanced defaults.
If you created a profile with advanced defaults, you have a choice. If you
want to configure and use the Field Formats check in this profile, you
should leave learning enabled. If you do not want to use this check, you
should disable learning.
If you want to use the Field Formats check, you should let learning generate
a list of recommended field formats. To do this, you turn off blocking until
learning has seen enough traffic to generate a list of field formats. You then
review the learned field formats and accept those that you want to use. You
then observe the logs for a few days to ensure that your configurations do
not cause legitimate form field data to be blocked. When you are certain
that your configuration is working correctly, you re-enable blocking, and
are done.
Field Formats check. Enabled by default in all profiles. Clear/select the
check box to disable/enable logging.
You should not enable logging for the Form Field Consistency rule unless
you plan to enable and use this check. You normally will not want to
disable logging for this or any check you are using to filter traffic. If
shoot.
tions that violate the Field Formats check. Enabled by default in all profiles.
Clear/select the check box to disable/enable statistics.
You should not enable statistics for the Field Formats check unless you plan
to enable and use this check. You normally will not want to disable
statistics for this or any check you are using to filter traffic. Statistics
provide a useful means of measuring how often a particular security check
is used when protecting your Web sites, and how effective it is.
The Default Field Format parameters for the Field Format check are:
Field Type. Sets the field type assigned to form fields in web forms that do
not have a field type. This parameter is not set by default. You can assign
any field type that is defined on your Application Firewall as the default
field type.
Caution: If you set a restrictive default field type, and do not disable
blocking until you are certain that the field types assigned to your form
fields are correct, users may be unable to use your web forms.
Minimum Length. Sets the default minimum data length assigned to form
fields in web forms that do not have an explicit setting. This parameter is
set to 0 by default.
Maximum Length. Sets the default maximum data length assigned to form
fields in web forms that do not have an explicit setting. This parameter is
set to 65535 by default.
Configuring the Field Formats List
To configure the Field Formats list, you can add expressions by using the
configuration utility's Add Field Formats Check Relaxation dialog box or modify
existing relaxations by using the Modify Field Formats Check Relaxation dialog
box. The contents of the two dialog boxes are the same.
To configure the Field Formats List by using the configuration utility
Profiles.
Open.
4. Click Field Formats, and then click Modify.
5. In the Modify Field Formats Check dialog box, do one of the following:
To create a new relaxation, click Add to open the Add Field Format
dialog box. (If you select an existing relaxation and then click Add,
you can use the selected relaxation as the basis of a new relaxation.)
To modify an existing relaxation, select it from the Field Formats list
and click Open to open the Modify Field Format dialog box.
Enabled check box. A field format assignment can be in active use
(enabled) or can be inactive (disabled). When you create a field
format assignment, it is enabled by default. You disable it by
unchecking the Enabled check box.
either a literal string or a PCRE-format regular expression that
defines the name of the form field that you are adding to the
relaxations list. If you use a regular expression, you also check the
check box labeled, Is Field Name Regular Expression.
characters only. Do not cut and paste a field name that contains any
include a field name that contains non-ASCII characters, you must
enter those characters manually using the PCRE UTF-8 hexadecimal
Action URL. In the text area in the Action URL section, you enter a
PCRE-format regular expression that defines the URL of the Web
forms that contain the form field to which you want to assign a
particular field format.
Format. In the Format section, you fill in the list box and two text
boxes.
Type. Click the down arrow to the right of the Type list box,
and choose a field type from the field types list. If you want to
add a new field type definition to the list, click the Manage
button to open the Manage Field Types dialog box. For more
information on adding field types, see Chapter 7, Field
Types, on page167.
Minimum Length. If you want to require users to fill in this
particular form field, type a positive integer that represents the
minimum length in characters that data in this particular form
field. The default value is zero (0), meaning that the field can be
left blank.
Maximum length. If you want to limit the length of data
returned in this field, type a positive integer that represents the
maximum length in characters of data in this particular form
field. The default value is 65535.
Comments. In the text area in the Comments section, you type a
comment that explains what this field format does, and why you
added it. This section is optional; you can leave it blank if you wish.
7. Click Create or OK. If finished creating new expressions, or if you have
modified an existing expression, click Close.
Examples
Below are several examples of Field Name relaxations.
Choose form fields with the name Fi r st Name:
^Fi r st Name$
Choose form fields with names beginning with Name_ and followed by a
string beginning with a letter or number and consisting of from one to
twenty letters, numbers, or the apostrophe or hyphen symbol:
^Name_[ 0- 9A- Za- z] [ 0- 9A- Za- z' - ] {0, 20}$
field that begins with the string Tr ke- Fi r st Name_ on their logon page.
The special characters in that string must be represented as encoded UTF-8
strings.
^T\ xC3\ xBCr k\ xC3\ xA7e- Fi r st Name_[ 0- 9A- Za- z] ++$
^T\ xC3\ xBCr k\ xC3\ xA7e- Fi r st Name_( [ 0- 9A- Za- z] | \ \ x[ 0- 9A- Fa- f ] [ 0-
9A- Fa- f ] ) +$
Choose form field names that begin with a letter or number, consist of a
combination of letters and/or numbers only, and that contain the string Num
anywhere in the string:
^[ 0- 9A- Za- z] *Num[ 0- 9A- Za- z] *$
any regular expressions you write to ensure that they match exactly what
you want them to match, and nothing else. Careless use of wildcards, and
especially of the dot-asterisk (. *) metacharacter/wildcard combination, can
have results you did not want or expect.
Below are several example Field Format Action URL expressions.
Choose URLs beginning with ht t p: / / www. exampl e. com/
sear ch. pl ?, and containing any string after the query except for a new
query:
^ht t p: / / www[ . ] exampl e[ . ] com/ sear ch[ . ] pl \ ?[ ^?] *$
Choose URLs beginning with ht t p: / / www. exampl e- espaol . com,
which contains the n-tilde () non-ASCII special character. This special
character must be represented as an encoded UTF-8 string containing C3
B1, the hexadecimal code assigned to that character in the UTF-8 charset:
Za- z_- ] */ ) *
[ 0- 9A- Za- z] [ 0- 9A- Za- z_- . ] *[ . ] ( asp| ht p| php| s?ht ml ?) $
Allow users to access web pages beginning with ht t p: / / www. exampl e-
espaol . com, when the server contains pathnames or filenames that
contain non-ASCII characters:
9A- Fa- f ] ) */ ) *
Choose URLs that contain the string / sear ch. cgi ?:
^[ ^?<>] */ sear ch[ . ] cgi \ ?[ ^?<>] *$
The CSRF Form Tagging Check
The CSRF Form Tagging check tags each Web form sent by a protected Web site
to users with a unique and unpredictable FormID, and then examines the Web
forms returned by users to ensure that the supplied FormID is correct. This check
protects against Cross Site Request Forgery (CSRF) attacks.
The CSRF Form Tagging check prevents attackers from launching an attack
against your protected Web sites by using their own Web form to send high
volume form responses with data to that Web site. This check requires relatively
little CPU processing capacity compared to certain other security checks that
analyze Web forms in depth. It is therefore able to handle high volume attacks
while having little impact on the performance of the protected Web site or the
Application Firewall itself.
Note: The CSRF check assumes that the form origin and form action URLs
have the same domain. The relaxation rule may not work with cross domains
unless the form origin URL is specified as . *.
If you enable CSRF Form Tagging in a profile, you must also do the following:
Enable Form Tagging. The CSRF check depends upon form tagging and
does not work without it.
Disable Integrated Caching. You should disable Integrated Caching for all
web pages containing forms that are protected by that profile. The
Integrated Caching feature and CSRF form tagging are not compatible.
You should also consider enabling Referer checking. You enable Referer
checking in the Modify Start URL Check dialog box, under Parameters, but it
prevents cross-site request forgeries, not Start URL violations. Referer checking
also puts less load on the CPU than the CSRF Form Tagging check. If a request
violates Referer checking, it is immediately blocked, so the CSRF Form Tagging
check is not invoked. For more information, see The Start URL Check on
page175.
the CSRF Form Tagging security check in the pane that opens when you open a
general settings, open the Modify Cross Site Request Forgery Tagging Check
dialog box.
Profiles.
Open.
Beside the CSRF Form Tagging entry, you can select or clear check boxes
4. Click CSRF Form Tagging, and then click Modify.
5. In the Modify Cross Site Request Forgery Tagging Check dialog box,
click the General tab.
CSRF Form Tagging Check Actions.
Modify CSRF Form Tagging Check Actions
The Check Actions control how the CSRF Form Tagging check functions. They
are:
Block. Block connections that violate the CSRF Form Tagging security
check. Disabled by default in profiles created with basic defaults, and
enabled by default in profiles created with advanced defaults. Clear/select
the CSRF Form Tagging check to disable/enable blocking.
For a profile with basic defaults, you probably do not want to enable the
CSRF Form Tagging security check. In these profiles the CSRF Form
Tagging check is turned off and all of its Check Action settings are
disabled. Unless your protected Web sites use Web forms and attract DoS
attacks against your Web forms, you probably do not need the protection
that this check provides.
For a profile with advanced defaults, you might want to disable blocking to
prevent problems when you first install the Application Firewall. No profile
has any default CSRF Form Tagging relaxations defined. If any Web forms
on another Web site has an action URL that points to your protected Web
site, the Application Firewall will block responses containing those forms.
You must either manually add those forms to the CSRF Form Tagging list
when you first configure the profile, or allow the learning feature to
generate a list of learned CSRF Form Tagging relaxations for you. If you
prefer to let learning do the work, you need to turn off blocking until
learning has seen enough traffic to generate the necessary list of relax-
ations.
Learn. The learning feature is not available with the Deny URL check, so
the Learn check box is greyed out.
Log. Log any connections that violate the CSRF Form Tagging check. Dis-
abled by default in profiles created with basic defaults, and enabled by
default in profiles created with advanced defaults. You normally will want
to enable logging if you enable this security check. If anything unexpected
happens, the logs are an important resource to troubleshoot.
Statistics. Generate statistics for connections that violate the CSRF Form
Tagging check. Disabled by default in profiles created with basic defaults,
and enabled by default in profiles created with advanced defaults. You nor-
mally will want to enable statistics if you enable this security check. They
can help you monitor the types of attacks that a particular check is seeing,
and determine how effective that check is on your protected Web sites.
Configuring the CSRF Form Tagging List
To configure the CSRF Form Tagging list, you can add action URL expressions
by using the configuration utility's Add CSRF Form Tagging Check Relaxation
dialog box or modify existing relaxations by using the Modify CSRF Form
Tagging Check Relaxation dialog box. The contents of the two dialog boxes are
the same.
To configure the CSRF Form Tagging list by using the configuration utility
Profiles.
Open.
4. Click CSRF Form Tagging, and then click Modify.
5. In the Modify CSRF Form Tagging Check dialog box, do one of the
following:
To create a new relaxation, click Add to open the Add CSRF Form
Tagging Relaxation dialog box. (If you select an existing relaxation
a new relaxation.)
To modify an existing relaxation, select it from the CSRF Form
Tagging list and click Open to open the Modify CSRF Form
Tagging Check Relaxation dialog box.
Form Origin URL. In the Form Origin URL text area, you enter a
PCRE-format regular expression that defines the URL that hosts the
Web form that you are adding to the list. You can type the regular
expression, use the Regex Tokens menu to enter regular expression
elements and symbols directly into the text box, or use the Regular
Expressions Editor to construct the expression.
of the basic 128-character ASCII set. If you want to include an
format.
Form Action URL. In the Form Action URL text area, you enter a
PCRE-format regular expression that defines the URL that accepts
data input into the Web form that you are adding to the list. You can
type the regular expression, use the Regex Tokens menu to enter
regular expression elements and symbols directly into the text box, or
use the Regular Expressions Editor to construct the expression.
of the basic 128-character ASCII set. If you want to include an
format.
7. Click Create or OK. If finished creating new expressions, or if you have
modified an existing expression, click Close.
The HTML Cross-Site Scripting Check
The HTML Cross-Site Scripting check provides special defenses against cross-
site scripting attacks. The Application Firewall examines both the headers and the
POST bodies of user requests for possible cross-site scripting attacks. If it finds a
possible cross-site scripting attack, it either transforms the request to render the
attack harmless, or blocks the request.
The purpose of the HTML Cross-Site Scripting check is to prevent misuse of the
scripts on your protected Web sites to breach security on your Web sites. It does
this by blocking scripts that violate the same origin rule, which states that scripts
should not access or modify content on any server but the server where they are
located. Any script that violates the same origin rule is called a cross-site script,
and the practice of using scripts to access or modify content on another server is
called cross-site scripting. The reason cross-site scripting is a security issue is that
a Web server that allows cross-site scripting can be attacked using a script that is
not on that Web server, but on a different Web server, such as one owned and
controlled by the attacker.
Note: If the Cookie Consistency Check is enabled, this check ignores cookies
that were set by the server even when they contain elements that it would
otherwise block, to prevent blocking of legitimate requests.
Unfortunately many companies have a large installed base of J avascript-enhanced
web content that violates the same origin rule. To enable the HTML Cross-Site
Scripting check on these Web sites, the system administrators will have to
generate the appropriate relaxations so that this check does not block legitimate
activity on the Web site.
Caution: If you enable this feature, your NetScaler appliance is a single CPU
unit, and your protected Web sites accept file uploads or contain Web forms that
produce extremely large POST bodies when a user fills them out, you should
ensure that your Application Firewall is configured appropriately. For detailed
information, see AppendixC, Configuring for Large Files and Web Pages, on
page369.
the HTML Cross-Site Scripting security check in the pane that opens when you
open a profile. The default settings are the same in all profiles. To configure all of
the general settings, open the Modify HTML Cross-Site Scripting Check
dialog box.
Profiles.
Open.
Beside the HTML Cross-Site Scripting entry, you can select or clear
check boxes to enable or disable actions that can be taken when a
connection does not meet the specified criteria. To access all of the general
settings, continue with the following steps.
4. Click HTML Cross-Site Scripting, and then click Modify.
5. In the Modify HTML Cross-Site Scripting Check dialog box, click the
General tab.
HTML Cross-Site Scripting Check Actions.
Modify HTML Cross-Site Scripting Check Actions
The Check Actions control how the HTML Cross-Site Scripting check functions.
They are:
HTML Cross-Site Scripting check. Enabled by default in profiles created
with both basic and advanced defaults. Clear/select the check box to dis-
able/enable blocking.
mended cross-site scripting relaxations for your Web forms. Disabled by
default in profiles created with basic defaults, and enabled by default in
profiles created with advanced defaults. Clear/select the check box to dis-
able/enable learning.
for the HTML Cross-Site Scripting check unless legitimate scripts on your
protected Web sites are blocked by this check. If that is the case, you should
disable blocking, enable learning, and then follow the HTML Cross-Site
Scripting check instructions for profiles created with advanced defaults.
If you created a profile with advanced defaults, you have a choice. If your
protected Web sites do not use scripts, or if you are certain that none of your
scripts violates the cross-site scripting rules, you can disable learning. The
HTML Cross-Site Scripting check will block no legitimate traffic on Web
sites that do not use scripts, or that use scripts that do not violate cross-site
scripting rules.
If your protected Web sites use active scripts and you are not certain that
these scripts adhere to the cross-site scripting rules, you should leave
learning enabled and let it generate a list of recommended cross-site
scripting relaxations. To do this, you turn off blocking until learning has
seen enough traffic to generate a list of relaxations. You then review the
learned cross-site scripting relaxations, and accept those that you want to
use.
You then observe the logs for a few days to ensure that your configuration
does not cause legitimate cross-site scripts to be blocked. When you are
certain that your configuration is working correctly, you re-enable blocking,
and are done.
HTML Cross-Site Scripting check. Enabled by default in profiles created
with both basic and advanced defaults. Clear/select the check box to dis-
able/enable logging.
You normally will not want to disable logging for this or any check. If
shoot.
Statistics. Tells the Application Firewall to generate statistics for violations
of the HTML Cross-Site Scripting check. Enabled by default in profiles
created with both basic and advanced defaults. Clear/select the check box to
disable/enable statistics.
You normally will not want to disable statistics. They can help you monitor
the types of attacks that a particular check is seeing, and determine how
effective that check is on your protected Web sites.
Transform cross-site scripts. Tells the Application Firewall to modify any
cross-site scripts it detects to render them harmless. Disabled by default in
profiles created with both basic and advanced defaults. Clear/select the
check box to disable/enable transformation of cross-site scripts.
If you enable this feature, the Application Firewall performs the following
transformations:
- Left angle bracket (<) to HTML character entity equivalent (&l t ; )
- Right angle bracket (>) to HTML character entity equivalent (&gt ; ).
This ensures that browsers do not interpret unsafe html tags, such as
<scr i pt >, and thereby execute malicious code.
If you enable both Request header checking and transformation, any special
characters found in Request headers will also be transformed
When scripts on your protected Web site contain cross-site scripting
features, but the Web site does not rely upon those scripts to operate
correctly, you can disable blocking and enable this feature to prevent
blocking of legitimate web pages without reducing the protection that the
Application Firewall provides to your protected Web sites.
Note: You normally enable either Transform Cross-Site Scripts or
blocking, but not both. If you have blocking enabled, enabling
transformation is redundant because the Application Firewall is already
blocking access to those web pages that contain cross-site scripts.
Check complete URLs for cross-site scripting. Tells the Application Fire-
wall to check the entire URL, instead of just the query portion of the URL,
for violations of the HTML Cross-Site Scripting check. Disabled by default
in profiles created with both basic and advanced defaults. Clear/select the
check box to disable/enable complete URL checking.
Configuring the HTML Cross-Site Scripting List
To configure the HTML Cross-Site Scripting list, you can add form field and
action URL expressions by using the configuration utility's Add HTML Cross-
Site Scripting Check Relaxation dialog box or modify existing relaxations by
using the Modify HTML Cross-Site Scripting Check Relaxation dialog box. The
contents of the two dialog boxes are the same.
To configure the HTML Cross-Site Scripting List by using the configuration
utility
Profiles.
Open.
4. Click HTML Cross-Site Scripting, and then click Modify.
5. In the Modify HTML Cross-Site Scripting Check dialog box, do one of
the following:
To create a new relaxation, click Add to open the Add HTML
Cross-Site Scripting Check Relaxation dialog box. (If you select an
existing relaxation and then click Add, you can use the selected
relaxation as the basis of a new relaxation.)
To modify an existing relaxation, select it from the HTML Cross-
Site Scripting list and click Open to open the Modify HTML
Cross-Site Scripting Check Relaxation dialog box.
either a literal field name or a PCRE-format regular expression that
defines the field names to which your relaxation applies. If you type a
PCRE-format regular expression, you must also check the check box
labeled, Is Field Name Regular Expression.
Action URL. In the text area in the Action URL section, you enter
either a literal URL or a PCRE-format regular expression that defines
the URLs to which your relaxation applies.
characters only. Do not cut and paste a URL that contains any
include a URL that contains non-ASCII characters, you must enter
those characters manually using the PCRE hexadecimal character
encoding format. For more information, see AppendixA, PCRE
Character Encoding Format, on page347.
Location. Choose the element that your relaxation will apply to from the
drop-down list. Your choices are:
- FORMFIELD. Form fields in Web forms. This is the default choice.
- HEADER. HTTP request headers.
- COOKIE. HTTP Set-Cookie headers.
Comments. In the text area in the Comments section, you type a comment
that explains why you added this relaxation to the configuration. This sec-
tion is optional; you can leave it blank if you wish.
Examples
Below are several examples of expressions that can be used in this check.
Check all fields beginning with the string l ogon_ and followed by a string
of upper- and lower-case letters or numbers that is at least two characters
long and no more than fifteen characters long:
^l ogon_[ 0- 9A- Za- z] {2, 15}$
Choose form fields with names beginning with Name_ and followed by a
^Name_[ 0- 9A- Za- z] [ 0- 9A- Za- z' - ] {0, 20}$
field that begins with the string Tr ke- Name_ on their logon page. The
special characters in that string must be represented as encoded UTF-8
strings.
^T\ xC3\ xBCr k\ xC3\ xA7e- Name_[ 0- 9A- Za- z] +$
^T\ xC3\ xBCr k\ xC3\ xA7e- Name_( [ 0- 9A- Za- z] | \ \ x[ 0- 9A- Fa- f ] [ 0- 9A-
Fa- f ] ) +$
Check all fields beginning with the string sessi oni d- and followed by a
ten-digit number:
^sessi oni d- [ 0- 9] {10, 10}$
Below are several example URL expressions.
Check all URLs beginning with the string quer y_ and followed by a string
long and no more than forty characters long, and ending with the string
. j s:
^quer y_[ 0- 9A- Za- z] {2, 40}[ . ] j s$
Check all URLs containing the string pr odi nf o in the path:
^ht t ps?: / / [ 0- 9A- Za- z. _- ] */ [ ^<>?] *\ ?pr odi nf o[ ^<>?] *$
Check all URLs containing the string pr odi nf o in the path, on servers
with hostnames, pathnames or filenames that contain non-ASCII
characters:
^ht t ps?: / / ( ( [ 0- 9A- Za- z] | \ \ x[ 0- 9A- Fa- f ] [ 0- 9A- Fa- f ] ) ( ( [ 0- 9A- Za-
z_- ] | \ \ x[ 0- 9A- Fa- f ] [ 0- 9A- Fa- f ] +[ . ] ) +[ a- z] {2, 6}/
[ ^<>?] *\ ?pr odi nf o[ ^<>?] *$
regular expressions you write to ensure that they define exactly the URL you
results you did not want or expect, such as blocking access to web content that
you did not intend to block.
Note: See AppendixA, PCRE Character Encoding Format, on page347 for
a complete description of supported characters and how to encode them properly
when configuring the Application Firewall.
The HTML SQL Injection Check
The HTML SQL Injection check provides special defenses against injection of
unauthorized SQL code that might break security. It examines both the headers
and the POST bodies of requests for injected SQL code. If the Application
Firewall detects unauthorized SQL code in a user request, it either transforms the
request to render the SQL code inactive, or blocks the request. This check applies
to HTML profiles only; it is not used with XML profiles.
Many Web applications have Web forms that communicate with relational
database servers using SQL. Often the scripts that pass Web form information to
the database do not validate the information provided by the user before passing it
on to the database, allowing malicious code or a hacker to send SQL commands
to the Web server via the insecure Web form.
Caution: If you enable this feature, your NetScaler appliance is a single CPU
unit, and your protected Web sites accept file uploads or contain Web forms that
produce extremely large POST bodies when a user fills them out, you should
ensure that your Application Firewall is configured appropriately. For detailed
information, see AppendixC, Configuring for Large Files and Web Pages, on
page369.
the HTML SQL Injection security check in the pane that opens when you open a
general settings, open the Modify HTML SQL Injection Check dialog box.
Profiles.
Open.
Beside the HTML SQL Injection entry, you can select or clear check
4. Click HTML SQL Injection, and then click Modify.
5. In the Modify HTML SQL Injection Check dialog box, click the General
tab.
HTML SQL Injection Check Actions.
Modify HTML SQL Injection Check Actions
The Check Actions control how the HTML SQL Injection check functions. They
are:
Block. Tells the Application Firewall to block connections that contain
injected SQL code. Enabled by default in profiles created with both basic
and advanced defaults. You disable blocking for the HTML SQL Injection
check by clearing the Block check box, and re-enable blocking after dis-
abling it by checking the Block check box.
Learn. Tells the Application Firewall to use its learning engine to observe
mended SQL injection relaxations. Disabled by default in profiles created
with basic defaults, and enabled by default in profiles created with
advanced defaults. You enable learning by checking the Learn check box,
and disable it by unchecking the Learn check box.
for the HTML SQL Injection check unless legitimate Web form traffic on
your protected Web sites is blocked by this check. If that is the case, you
should disable blocking, enable learning, and then follow the HTML SQL
Injection check instructions for profiles created with advanced defaults.
If you created a profile with advanced defaults, you have three choices. If
your protected Web sites do not contain Web forms, or if you are certain
that none of your Web forms violates the HTML SQL Injection check rules,
you can disable learning. The SQL Injection check will block no legitimate
traffic on Web sites that do not use Web forms, or that use Web forms that
do not violate the HTML SQL Injection check rules.
If your protected Web sites use Web forms and you are not certain that these
Web forms do not violate the HTML SQL injection rules, you should leave
learning enabled and let it generate a list of recommended SQL injection
relaxations. To do this, you turn off blocking until learning has seen enough
traffic to generate a list of relaxations. You then review the learned SQL
injection relaxations, and accept those that you want to use.
You then observe the logs for a few days to ensure that your configuration
does not cause legitimate Web form traffic to be blocked. When you are
certain that your configuration is working correctly, you re-enable blocking,
and are done.
HTML SQL Injection check. Enabled by default in profiles created with
both basic and advanced defaults. You disable logging for the HTML SQL
Injection check by clearing the Log check box, and re-enable logging after
disabling it by checking the Log check box.
shoot.
Statistics. Tells the Application Firewall to generate statistics for violations
of the HTML SQL Injection check. Enabled by default in profiles created
with both basic and advanced defaults. You disable statistics for the HTML
SQL Injection check by clearing the Statistics check box, and re-enable sta-
tistics after disabling it by checking the Statistics check box.
Transform SQL special characters. Tells the Application Firewall to
change any SQL special characters it detects into harmless equivalents.
SQL special characters tell an SQL server that the following text is an SQL
command, or SQL keyword. Normally, unless the appropriate SQL special
characters are present, an SQL database ignores any SQL keywords. Dis-
abled by default in profiles created with both basic and advanced defaults.
You enable this feature by checking the Transform check box, and disable it
after enabling it by unchecking the Transform check box.
If you enable the Transform feature, the Application Firewall performs the
following transformations:
- Single straight quote (' ) to double straight quote (" )
- Backslash (\ ) to double backslash (\ \ ).
- Semicolon (; ) is dropped completely.
If you enable both Request header checking and transformation, any SQL
special characters found in headers will also be transformed. The following
headers normally contain semicolons (; ), so enabling both Request header
checking and transformation may cause errors:
- User-Agent
- Accept
- Accept-Encoding
- Accept-Language
- Accept-Charset
- Expect
When Web forms on your protected Web site may legitimately contain SQL
special characters or SQL keywords, but the Web form does not rely upon
them to operate correctly, you can disable blocking and enable this feature
to prevent blocking of legitimate Web form data without reducing the
protection that the Application Firewall provides to your protected Web
sites.
Note: You normally enable either this feature or blocking, but not both. If
you have blocking enabled, enabling transformation is redundant because
the Application Firewall is already blocking access to those web pages that
contain injected SQL code.
Beneath the Actions area is the Parameters area, which contains additional
configuration items.
Application Firewall to check only form data that contains SQL special
characters for violations of the HTML SQL Injection check rules. Since
most SQL databases ignore any SQL commands that are not accompanied
by the appropriate SQL special characters, this usually reduces server load
without compromising security. Disabled by default in profiles created with
basic defaults, and enabled in profiles created with advanced defaults.
You enable this feature by checking the Check Complete URLs check box,
and disable it after enabling it by unchecking the Check Complete URLs
check box.
SQL injection check. You can also thwart attackers who may send requests
containing comments and observe your Web servers response to profile
your SQL servers behavior and identify which SQL software it uses.
Unlike the other options on the General tab, the SQL Comments Handling
option consists, not of a check box, but of a radio button array. To modify
the SQL Comments Handling settings, you click the radio button beside the
option you want.
- ANSI. Tells the Application Firewall to recognize SQL ANSI
comments, which are normally used by Unix-based SQL databases,
and skip those comments when filtering requests for violations of the
SQL injection check.
- Nested. Tells the Application Firewall to recognize nested SQL
comments, which are normally used by Microsoft SQL Server, and
skip those comments when filtering requests for violations of the
SQL injection check.
- ANSI/Nested. Tells the Application Firewall to recognize comments
that adhere to both the ANSI and nested SQL comment standards,
SQL injection check. Comments that match only the ANSI standard,
or only the nested standard, will not be skipped.
Note: You should normally choose either the Nested or the ANSI/
Nested option only if your back-end database runs on Microsoft SQL
Server. Most other types of SQL server software do not recognize
nested comments. For that reason, no requests containing nested
comments should be directed at other types of SQL servers. If nested
comments do appear in a request directed at another type of SQL
server, they may indicate an attempt to breach security on that server.
- Check all Comments. Tells the Application Firewall to check the
entire request for violations of the SQL injection check, without
skipping anything.
Configuring the HTML SQL Injection List
To configure the HTML SQL Injection list, you can add form field and action
URL expressions by using the configuration utility's Add HTML SQL Injection
Check Relaxation dialog box or modify existing relaxations by using the Modify
HTML SQL Injection Check Relaxation dialog box. The contents of the two
dialog boxes are the same.
To configure the HTML SQL Injection List by using the configuration utility
Profiles.
Open.
4. Click HTML SQL Injection, and then click Modify.
5. In the Modify HTML SQL Injection Check dialog box, do one of the
following:
To create a new relaxation, click Add to open the Add HTML SQL
Injection Check Relaxation dialog box. (If you select an existing
To modify an existing relaxation, select it from the HTML SQL
Injection list and click Open to open the Modify HTML SQL
Injection Check Relaxation dialog box.
either a literal field name or a PCRE-format regular expression that
defines the field names to which your relaxation applies. If you type a
PCRE-format regular expression, you must also check the check box
labeled, Is Field Name Regular Expression.
Action URL. In the text area in the Action URL section, you type
either a literal URL or a PCRE-format regular expression that defines
the URLs to which your relaxation applies.
characters only. Do not cut and paste a URL that contains any
include a URL that contains non-ASCII characters, you must enter
those characters manually using the PCRE hexadecimal character
encoding format. For more information, see AppendixA, PCRE
Character Encoding Format, on page347.
Location. Choose the element that your relaxation will apply to from
the drop-down list. Your choices are:
FORMFIELD. Form fields in Web forms. This is the default
choice.
HEADER. HTTP request headers.
COOKIE. HTTP Set-Cookie headers.
Comments. In the text area in the Comments section, you type a
comment that explains why you added this relaxation to the
configuration. This section is optional; you can leave it blank if you
wish.
7. Click Create or OK. If finished creating new form field or action URL
expressions, or if you have modified an existing expression, click Close.
Examples
Below are several examples of expressions that can be used in this check.
Check all fields beginning with the string l ogon_ and followed by a string
long and no more than fifteen characters long:
^l ogon_[ 0- 9A- Za- z] {2, 15}$
Choose form fields with names beginning with l ogon_ and followed by a
^l ogon_[ 0- 9A- Za- z] [ 0- 9A- Za- z' - ] {0, 20}$
field that begins with the string t r ke- l ogon_ on their logon page. The
special characters in that string must be represented as encoded UTF-8
strings.
^t \ xC3\ xBCr k\ xC3\ xA7e- l ogon_[ 0- 9A- Za- z] +$
^t \ xC3\ xBCr k\ xC3\ xA7e- l ogon_( [ 0- 9A- Za- z] | \ \ x[ 0- 9A- Fa- f ] [ 0- 9A-
Fa- f ] ) +$
Check all fields beginning with the string sessi oni d- and followed by a
ten-digit number:
^sessi oni d- [ 0- 9] {10, 10}$
any regular expressions you write to ensure that they define exactly the
URL you want to add as a relaxation, and nothing else. Careless use of
wildcards, and especially of the dot-asterisk (. *) metacharacter/wildcard
combination, can have results you did not want or expect, such as blocking
access to web content that you did not intend to block.
Below are several example URL expressions.
Check all URLs beginning with the string quer y_ and followed by a string
long and no more than forty characters long, and ending with the string. j s:
^quer y_[ 0- 9A- Za- z] {2, 40}[ . ] j s$
Check all URLs beginning with the same string as above, on servers with
hostnames, pathnames or filenames that contain non-ASCII characters:
^quer y_( [ 0- 9A- Za- z] | \ \ x[ 0- 9A- Fa- f ] [ 0- 9A- Fa- f ] ) {2, 40}[ . ] j s$
string \ \ x[ 0- 9A- Fa- f ] [ 0- 9A- Fa- f ] , which will match all properly-
CHAPTER 10
The XML Security Checks
This chapter describes in detail the Application Firewall security checks specific
to XML profiles. It explains how each security check operates, what types of
attacks it helps prevent, and how the configuration details affect how that security
check filters a request or response. This information is intended for system
administrators who need to understand a particular security check in detail to
configure it properly for their Web sites.
Note: You do not need to read this chapter unless you need to understand in
detail how specific XML security checks work, what all the options are for each,
and how each option affects its operation.
The XML Format Check
The XML Format check examines the XML format of incoming requests, and
blocks those requests that are not well formed, or that do not meet the criteria in
the XML specification for properly-formed XML documents. Some of those
criteria are:
An XML document must contain only properly-encoded Unicode
characters that match the Unicode specification.
No special XML syntax characterssuch as <, >, and "&"can be
included in the document except when used in XML markup.
All begin, end, and empty-element tags must be correctly nested, with none
missing or overlapping
XML element tags are case-sensitive; all beginning and end tags must
match exactly.
A single root element must contain all the other elements in the XML
document.
A document that does not meet the XML well-formedness criteria does not meet
the definition of an XML document. Strictly speaking, it is not XML. However,
not all XML applications and web services enforce the well-formedness standard,
and not all handle poorly-formed or invalid XML correctly. Inappropriate
handling of a poorly-formed XML document can cause security breaches. The
purpose of the XML Format check is to prevent a malicious user from using a
poorly-formed XML request to breach security on your XML application or web
service.
the XML Format security check in the pane that opens when you open a profile.
The default settings are the same in all profiles. To configure all of the general
settings, open the Modify XML Format Check dialog box.
Profiles.
Open.
Beside the XML Format entry, you can select or clear check boxes to
4. Click XML Format, and then click Modify.
XML Format Check Actions.
Modify XML Format Check Actions
The Check Actions control how the XML Format check functions. They are:
XML Format check. Enabled by default. You disable blocking for the XML
Format check by clearing the Block check box, and re-enable blocking after
disabling it by selecting the Block check box.
You should not disable blocking for the XML Format check except when
troubleshooting this specific check. Unlike every other security check in the
Application Firewall, this security check has dependencies: if the XML
Format check fails, then no other XML security checks are performed.
Chapter 10 The XML Security Checks 237
Legitimate user requests are unlikely to be blocked by this check, and it is
likely to catch and block attacks before the more intensive checks must be
run.
If you want to be absolutely certain that you are not blocking any legitimate
user requests whatsoever, you can disable this check at first, and then
review the logs for this profile closely for a short period of time. The logs
will indicate when the Application Firewall would have blocked a request
for violating the XML Format check. You can then verify whether the
request was valid or appears not to have been valid.
Learn. The learning feature is not available with the XML Format check,
so the Learn check box is greyed out.
XML Format check. Enabled by default. You disable logging for the XML
Format check by clearing the Log check box, and re-enable logging after
disabling it by checking the Log check box.
shoot.
tions that violate the XML Format check. Enabled by default. You disable
statistics for the XML Format check by clearing the Statistics check box,
and re-enable statistics after disabling it by checking the Statistics check
box.
The XML Format check has no Checks tab. The Check Actions are the only
options you can configure for this check.
The XML Denial of Service Check
The XML Denial of Service (XML DoS or XDoS) check examines incoming
XML requests to determine whether they match the characteristics of a denial-of-
service (DoS) attack, and blocks those requests that do. The purpose of the XML
DoS check is to prevent an attacker from using XML requests to launch a denial-
of-service attack on your server or application.
the XML Denial of Service security check in the pane that opens when you open
a profile. The default settings are the same in all profiles. To configure all of the
general settings, open the Modify XML Denial of Service Check dialog box.
Profiles.
Open.
Beside the XML Denial of Service entry, you can select or clear check
4. Click XML Denial of Service, and then click Modify.
5. In the Modify XML Denial of Service Check dialog box, click the
General tab.
XML Denial of Service Check Actions.
Modify XML Denial of Service Check Actions
The Check Actions control how the XML Denial of Service check functions.
They are:
XML DoS check. Enabled by default. You disable blocking for the XML
DoS check by clearing the Block check box, and re-enable blocking after
disabling it by selecting the Block check box.
You probably will not want to disable blocking for the XML DoS check. At
the default settings, which enable only a few of the XML DoS rules, it is
unlikely to block any legitimate requests. If a particular rule causes
blocking of legitimate requests, you should disable that rule instead. See the
remainder of this section for more information on enabling and disabling
specific XML DoS check rules.
tected applications, and generate a list of patterns to add to the XML DoS
list. Disabled by default in profiles created with basic defaults, and enabled
by default in profiles created with advanced defaults.
XML DoS security check unless your application needs additional
protection beyond that provided by the default XML DoS rule set. If you
want to use the XML DoS check in this profile, you should enable learning,
logging, and statistics, and then follow the XML DoS check instructions for
profiles created with Advanced Defaults.
or disable it. If you prefer to let learning generate additional XML DoS
patterns to improve protection for your protected applications, you need to
turn off blocking until learning has seen enough traffic to generate the
necessary list of expressions. You then review the learned list and accept
those that you want to allow. When learning has seen enough traffic to
generate a good list, you re-enable blocking, and are done.
Otherwise, you can disable learning and rely upon the default list of XML
DoS patterns, which should provide adequate protection for most protected
applications.
XML DoS check. Enabled by default. You disable logging for the XML
DoS check by clearing the Log check box, and re-enable logging after dis-
abling it by checking the Log check box.
shoot.
tions that violate the XML DoS check. Enabled by default. You disable sta-
tistics for the XML DoS check by clearing the Statistics check box, and re-
enable statistics after disabling it by checking the Statistics check box.
Configuring the XML Denial of Service List
To configure the XML DoS list, you modify the XML DoS rules by using the
Modify XDoS Check dialog box for each of the rules. The contents of the Modify
XDoS Check dialog boxes differ to a greater or lesser extent, but none consist of
more than two text boxes containing parameters that you can adjust.
To configure the XML DoS List by using the configuration utility
Profiles.
Open.
4. Click XML Denial of Service, and then click Modify.
5. In the Modify XML Denial of Service Check dialog box, select the XDoS
check that you want to modify from the XDoS list and click Open to open
the Modify XDoS Check dialog box.
6. In the dialog box, modify the values you want to change.
For information about the specific XDoS rules and the parameters that you
can modify, see The XML DoS Rules on page240.
7. Click OK, and then click Close.
The following table provides a list of the XML DoS rules and a description of
each.
The XML DoS Rules
Rule Description
Maximum Element Depth Restricts the maximum number of nested levels in each individual element
to 256. If this rule is enabled, and the Application Firewall detects an XML
request with an element that has more than the maximum number of
allowed levels, it blocks the request. The user can modify the maximum
number of levels to any value between one (1) and 65,535.
Maximum Element Name Length Restricts the maximum length of each element name to 128 characters.
This includes the name within the expanded namespace, which includes
the XML path and element name in the following format:
{http://prefix.example.com/path/}target_page.xml
The user can modify the maximum name length to any value between one
(1) character and 65,535.
Maximum #Elements Restricts the maximum number of any one type of element per XML
document to 65,535. The user can modify the maximum number of
elements to any value between one (1) and 65,535.
Maximum #Element Children Restricts the maximum number of children (including other elements,
character information, and comments) each individual element is allowed
to have to 65,535. The user can modify the maximum number of element
children to any value between one (1) and 65,535.
Maximum #Attributes Restricts the maximum number of attributes each individual element is
allowed to have to 256. The user can modify the maximum number of
attributes to any value between one (1) and 256.
Maximum Attribute Name Length Restricts the maximum length of each attribute name to 128 characters.
The user can modify the maximum attribute name length to any value
between one (1) and 2,048.
Maximum Attribute Value Length Restricts the maximum length of each attribute value to 2048 characters.
The user can modify the maximum attribute name length to any value
Maximum CDATA Section Length Restricts the length of the CDATA section for each element to 65,535. The
user can modify the maximum CDATA section length to any value
The XML Cross-Site Scripting Check
The XML Cross-Site Scripting check examines both the headers and bodies of
incoming XML requests for possible cross-site scripts errors, and blocks requests
that contain these errors. This check applies only to XML requests.
The purpose of the XML Cross-Site Scripting check is to prevent misuse of the
scripts in your protected XML applications to breach security. It does this by
blocking scripts that violate the same origin rule, which states that scripts should
not access or modify content on any server but the server where they are located.
Any script that violates the same origin rule is called a cross-site script, and the
practice of using scripts to access or modify content on another server is called
cross-site scripting.
The reason cross-site scripting is a security issue is that a application that allows
cross-site scripting can be attacked using a script that is not on the same server as
that application, but on a different server, such as one owned and controlled by
the attacker.
Maximum File Size Restricts the size of each file to 20 MB. The user can modify the maximum
file size to any value.
Minimum File Size Requires that each file be at least 9 bytes in length. The user can modify
the minimum file size to any positive integer representing a number of
bytes.
Maximum #Entity Expansions Limits the number of entity expansions allowed to the specified number.
Default: 1024.
Maximum Entity Expansion Depth Restricts the maximum number of nested entity expansions to no more
than the specified number. Default: 32.
Maximum #Namespaces Limits the number of namespace declarations in an XML document to no
more than the specified number. Default: 16
Maximum Namespace URI Length Limits the URL length of each namespace declaration to no more than the
specified number of characters. Default: 256
Block Processing Instructions Blocks any special processing instructions included in the request. This
rule has no user-modifiable values.
Block DTD Blocks any DTD included with the request. This rule has no user-
modifiable values.
Block External Entities Blocks all external entities references by the request. This rule has no user-
modifiable values.
The XML DoS Rules
Rule Description
the XML Cross-Site Scripting security check in the pane that opens when you
the general settings, open the Modify XML Cross-Site Scripting Check dialog
box.
Profiles.
Open.
Beside the XML Cross-Site Scripting entry, you can select or clear check
4. Click XML Cross-Site Scripting, and then click Modify.
XML Cross-Site Scripting Check Actions.
Modify XML Cross-Site Scripting Check Actions
The Check Actions control how the XML Cross-Site Scripting check functions.
They are:
XML Cross-Site Scripting check. Enabled by default. You disable blocking
for the XML Cross-Site Scripting check by clearing the Block check box,
and re-enable blocking after disabling it by selecting the Block check box.
You will not want to disable blocking for the XML Cross-Site Scripting
check on your production servers. Cross-site scripts are risky within an
XML context. While you are testing a new Application Firewall configu-
ration, however, you can disable this check and then monitor your logs to
determine whether any XML requests containing cross-site scripts are legit-
imately sent to your protected application. If you do spot any such requests,
you may want to consider modifying the application to remove this vulner-
ability rather than disabling this important security check for your appli-
cation.
Learn. The learning feature is not available with the XML Cross-Site
Scripting check, so the Learn check box is greyed out.
XML Cross-Site Scripting check. Enabled by default. You disable logging
for the XML Cross-Site Scripting check by clearing the Log check box, and
re-enable logging after disabling it by checking the Log check box.
shoot.
tions that violate the XML Cross-Site Scripting check. Enabled by default.
You disable statistics for the XML Cross-Site Scripting check by clearing
the Statistics check box, and re-enable statistics after disabling it by check-
ing the Statistics check box.
The XML Cross-Site Scripting check has no Checks tab. The Check Actions are
the only options you can configure for this check.
The XML SQL Injection Check
The XML SQL Injection check examines the headers and bodies of incoming
requests for inappropriate SQL special characters and keywords that might
indicate an attempt to inject SQL code, and blocks those requests.
The purpose of the XML SQL Injection check is to prevent an attacker from
using your XML application to send SQL commands to your back-end SQL-
based database servers and either obtaining information that they were not
entitled to obtain, or gaining control of the server. Many applications
communicate with relational database servers using SQL. Often the scripts that
pass Web form information to the database do not validate the information
provided by users before passing it on to the database, allowing malicious code or
a hacker to send SQL commands to the database server. If the Application
Firewall detects unauthorized SQL code in a user request, it blocks the request.
the XML SQL Injection security check in the pane that opens when you open a
general settings, open the Modify XML SQL Injection Check dialog box.
Profiles.
Open.
Beside the XML SQL Injection entry, you can select or clear check boxes
4. Click XML SQL Injection, and then click Modify.
XML SQL Injection Check Actions.
Modify XML SQL Injection Check Actions
The Check Actions control how the XML SQL Injection check functions. They
are:
XML SQL Injection check. Enabled by default. You disable blocking for
the XML SQL Injection check by clearing the Block check box, and re-
enable blocking after disabling it by selecting the Block check box.
You will not want to disable blocking for the XML SQL Injection check in
your production environment unless your application has no access to any
back-end SQL-based database server. While you are testing a new Appli-
cation Firewall configuration, however, you can disable this check and then
monitor your logs to determine whether any XML requests containing SQL
special characters or keywords are legitimately sent to your protected appli-
cation. If you do spot any such requests, and your protected application can
access a back-end SQL-based database server, you may want to consider
either removing access to the database server or modifying the application
to remove this vulnerability.
Learn. The learning feature is not available with the XML SQL Injection
XML SQL Injection check. Enabled by default. You disable logging for the
XML SQL Injection check by clearing the Log check box, and re-enable
logging after disabling it by checking the Log check box.
shoot.
tions that violate the XML SQL Injection check. Enabled by default. You
disable statistics for the XML SQL Injection check by clearing the Statistics
check box, and re-enable statistics after disabling it by checking the Statis-
tics check box.
Beneath the Actions area is the Parameters area, which contains additional
configuration items.
Application Firewall to check only XML that contains SQL special charac-
ters for violations of the XML SQL Injection check rules. Since most SQL
databases ignore any SQL commands that are not accompanied by the
appropriate SQL special characters, this usually reduces server load without
compromising security.
You enable this feature by checking this check box, and disable it after
enabling it by unchecking this check box.
XML SQL Injection check. You can also thwart attackers who may send
requests containing comments and observe your Web servers response to
profile your SQL servers behavior and identify which SQL software it
uses.
Unlike the other options on the General tab, the SQL Comments Handling
option consists, not of a check box, but of a radio button array. To modify
the SQL Comments Handling settings, you click the radio button beside the
option you want.
- ANSI. Tells the Application Firewall to recognize SQL ANSI
comments, which are normally used by Unix-based SQL databases,
- Nested. Tells the Application Firewall to recognize nested SQL
comments, which are normally used by Microsoft SQL Server, and
skip those comments when filtering requests for violations of the
- ANSI/Nested. Tells the Application Firewall to recognize comments
that adhere to both the ANSI and nested SQL comment standards,
XML SQL Injection check. Comments that match only the ANSI
standard, or only the nested standard, will not be skipped.
Note: You should normally choose either the Nested or the ANSI/
Nested option only if your back-end database runs on Microsoft SQL
Server. Most other types of SQL server software do not recognize
nested comments. For that reason, no requests containing nested
comments should be directed at other types of SQL servers. If nested
comments do appear in a request directed at another type of SQL
server, they may indicate an attempt to breach security on that server.
- Check all Comments. Tells the Application Firewall to check the
entire request for violations of the XML SQL injection check,
without skipping anything.
The XML SQL Injection check has no Checks tab. The Check Actions and
Parameters are the only options you can configure for this check.
The XML Attachment Check
The XML Attachment check examines incoming requests for malicious
attachments, and block those requests that contain attachments that might breach
applications security. The purpose of the XML Attachment check is to prevent an
attacker from using an XML attachment to breach security on your server.
the XML Attachment security check in the pane that opens when you open a
general settings, open the Modify XML Attachment Check dialog box.
Profiles.
Open.
Beside the XML Attachment entry, you can select or clear check boxes to
4. Click XML Attachment, and then click Modify.
5. In the Modify XML Attachment Check dialog box, click the General tab.
XML Attachment Check Actions.
Modify XML Attachment Check Actions
The Check Actions control how the XML Attachment check functions. They are:
XML Attachment check. Enabled by default. You disable blocking for the
XML Attachment check by clearing the Block check box, and re-enable
blocking after disabling it by selecting the Block check box.
You probably will not want to disable blocking for the XML Attachment
check in your production environment. An attack can be launched on your
protected application using an XML attachment. To determine whether
attachments that violate this check are legitimately sent to your protected
application, you can disable this check in a test environment and direct
characteristic requests to the application. You then observe the logs to
determine whether the Application Firewall would have blocked any
requests because of this rule.
tected applications, and generate a list of patterns to add to the XML
Attachment list. Disabled by default in profiles created with basic defaults,
and enabled by default in profiles created with advanced defaults.
For a profile with basic defaults, you normally do not want to enable
learning for the XML Attachment security check unless your application
receives traffic that violates the normal XML Attachment check rules. If
you expect for that to be the case, you should enable learning, logging, and
statistics, and then follow the XML Attachment check instructions for
profiles created with Advanced Defaults.
or disable it. If you prefer to let learning generate a list of exceptions to the
standard XML Attachment patterns, you need to turn off blocking until
learning has seen enough traffic to generate the necessary list of expres-
sions. You then review the learned list and accept those that you want to
allow. When learning has seen enough traffic to generate a good list, you re-
enable blocking, and are done.
any XML attachments that you expect your protected application to receive
from users, but that violate this check, to the XML Attachment check relax-
ations list when you first configure the profile. Unless you are very familiar
with your applications, you will probably find it easier to let learning
generate the list for you.
XML Attachment check. Enabled by default. You disable logging for the
XML Attachment check by clearing the Log check box, and re-enable log-
ging after disabling it by checking the Log check box.
shoot.
tions that violate the XML Attachment check. Enabled by default. You dis-
able statistics for the XML Attachment check by clearing the Statistics
check box, and re-enable statistics after disabling it by checking the Statis-
tics check box.
Configuring the XML Attachment Checks
You configure the XML Attachment checks in the Checks tab, as described
below.
To configure the XML Attachment checks by using the configuration utility
Profiles.
Open.
4. Click XML Attachment, and then click Modify.
5. In the Modify XML Attachment Check dialog box, configure the
following options:
Maximum Attachment Size. Tells the Application Firewall to allow
attachments that are no larger than the maximum attachment size you
specify. To enable this option, you first select the Enabled check box,
and then type the maximum attachment size in bytes in the Size text
box.
Attachment Content Type. Tells the Application Firewall to allow
attachments of the specified content type. To enable this option, you
first select the Enabled check box, and then enter a regular expression
that matches the Content-Type attribute of the attachments that you
want to allow by:
Typing the URL expression directly in the text window. If you
do this, you can use the Regex Tokens menu to enter a number
of useful regular expressions at the cursor instead of typing
them manually.
Clicking Regex Editor to open the Regular Expression Editor,
and use it to construct the URL expression you want.
The Web Services Interoperability Check
The Web Services Interoperability (WS-I) check examines both requests and
responses for adherence to the WS-I standard, and blocks those requests and
responses that do not adhere to this standard. The purpose of the WS-I check is to
block requests that might not interact with other XML appropriately. An attacker
can use inconsistencies in interoperability to launch an attack on your XML
application.
the Web Services Interoperability security check in the pane that opens when you
the general settings, open the Modify Web Services Interoperability Check
dialog box.
Profiles.
Open.
Beside the Web Services Interoperability entry, you can select or clear
check boxes to enable or disable actions that can be taken when a
connection does not meet the specified criteria. To access all of the general
settings, continue with the following steps.
4. Click Web Services Interoperability, and then click Modify.
5. In the Modify Web Services Interoperability Check dialog box, click the
General tab.
Web Services Interoperability Check Actions.
Modify Web Services Interoperability Check Actions
The Check Actions control how the Web Services Interoperability check
functions. They are:
WS-I check. Disabled by default for profiles created with basic defaults,
and enabled by default for profiles created with advanced defaults. You dis-
able blocking for the WS-I check by clearing the Block check box, and re-
enable blocking after disabling it by selecting the Block check box.
You probably will not want to disable blocking for the WS-I check.
tected applications, and generate a list of patterns to add to the WS-I list.
Disabled by default in profiles created with basic defaults, and enabled by
default in profiles created with advanced defaults.
WS-I security check unless you plan to use it. If you want to use the WS-I
check in this profile, you should enable learning, logging, and statistics, and
then follow the WS-I check instructions for profiles created with Advanced
Defaults.
or disable it. If you prefer to let learning generate a list of exceptions to the
standard WS-I patterns, you need to turn off blocking until learning has
seen enough traffic to generate the necessary list of expressions. You then
review the learned list and accept those that you want to allow. When
learning has seen enough traffic to generate a good list, you re-enable
blocking, and are done.
expressions for exceptions to the standard WS-I checks that you expect will
be needed with your protected applications when you first configure the
profile. Unless you are very familiar with your applications, you will
probably find it easier to let learning generate the list for you.
WS-I check. Enabled by default. You disable logging for the WS-I check by
clearing the Log check box, and re-enable logging after disabling it by
checking the Log check box.
shoot.
tions that violate the WS-I check. Enabled by default. You disable statistics
for the WS-I check by clearing the Statistics check box, and re-enable sta-
tistics after disabling it by checking the Statistics check box.
Configuring the Web Services Interoperability List
To configure the WS-I list, you enable or disable the individual WS-I rules in the
Modify Web Services Interoperability Check dialog box. You can also view
detailed information about each WS-I rule in this dialog box. You cannot make
any other changes to the WS-I list.
To configure the Web Services Interoperability List by using the
Profiles.
Open.
4. Click Web Services Interoperability, and then click Modify.
5. In the Modify Web Services Interoperability Check dialog box, select the
WS-I check that you want to enable or disable from the WS-I list, and then
click Enable or Disable.
6. To view detailed information about a WS-I rule, in the Modify Web
Services Interoperability Check dialog box select the rule, and then click
Details to display the details window for that rule.
The details window contains information about each rules purpose and
effect that can help you decide whether to enable it or disable it.
This completes the section on the WS-I check.
The XML Message Validation Check
The XML Message Validation check examines requests that contain XML
messages to ensure that they are valid. If a request contains an invalid XML
message, the Application Firewall blocks the request. The purpose of the XML
Validation check is to prevent an attacker from using specially-constructed
invalid XML messages to breach security on your application.
the XML Message Validation security check in the pane that opens when you
the general settings, open the Modify XML Message Validation Check dialog
box.
Profiles.
Open.
Beside the XML Message Validation entry, you can select or clear check
4. Click XML Message Validation, and then click Modify.
5. In the Modify XML Message Validation Check dialog box, click the
General tab.
XML Message Validation Check Actions.
Modify XML Message Validation Check Actions
The Check Actions control how the XML Message Validation check functions.
They are:
XML Validation check. Enabled by default. You disable blocking for the
XML Validation check by clearing the Block check box, and re-enable
blocking after disabling it by selecting the Block check box.
You probably will not want to disable blocking for the XML Validation
check.
Learn. The learning feature is not available with the XML Validation
XML Validation check. Enabled by default. You disable logging for the
XML Validation check by clearing the Log check box, and re-enable log-
ging after disabling it by checking the Log check box.
shoot.
tions that violate the XML Validation check. Enabled by default. You dis-
able statistics for the XML Validation check by clearing the Statistics check
box, and re-enable statistics after disabling it by checking the Statistics
check box.
Configuring the XML Message Validation Checks
You configure the XML Message Validation checks in the Checks tab, as
described below.
To configure the XML Message Validation checks by using the configuration
utility
Profiles.
Open.
4. Click XML Message Validation, and then click Modify.
5. In the Modify XML Message Validation Check dialog box, configure the
following options:
SOAP Envelope. Tells the Application Firewall to validate only the
SOAP envelope of XML messages. This is the default setting.
If you choose SOAP Envelope validation, you do not need to do any
further configuration to implement Request validation. By default,
the Application Firewall does not attempt to validate responses. If
you want to validate responses from your protected application or
Web 2.0 site, you check the Validate Response check box.
WSDL. Tells the Application Firewall to validate XML messages
using an XML SOAP WSDL. If you choose this type of validation,
you must upload the WSDL you will use for validation. See
Chapter 6, Imports, on page153 for information on uploading
WSDL files.
If you choose WSDL validation, in the WSDL Object drop-down list
you must choose a WSDL. If you want to validate against a WSDL
that has not already been imported to the Application Firewall, you
can click the Import button to open the Manage WSDL Imports
dialog box and import your WSDL. See Importing Configuration
Files on page157 for more information on this dialog box and
importing.
If you want the Application Firewall to enforce the WSDL strictly,
and not allow any additional XML headers not defined in the WSDL,
you must clear the check box labeled, Allow additional headers not
defined in the WSDL.
Caution: If you uncheck the Allow Additional Headers check box,
and your WSDL does not define all XML headers that your protected
XML application or Web 2.0 application expects or that a client
sends, you may block legitimate access to your protected service.
By default, the Application Firewall does not attempt to validate
responses. If you want to validate responses from your protected
application or Web 2.0 site, you check the Validate Response check
box.
XML Schema. Tells the Application Firewall to validate XML
messages using an XML schema. If you choose this type of
validation, you must upload the XML schema you will use for
validation. See Chapter 6, Imports, on page153 for information on
uploading XML schema files.
If you choose XML Schema validation, in the XML Schema Object
drop-down list you must choose an XML schema. If you want to
validate against an XML schema that has not already been imported
to the Application Firewall, you can click the Import button to open
the Manage XML Schema Imports dialog box and import your XML
schema. See Importing Configuration Files on page157 for more
information on this dialog box and importing.
Response Validation. By default, the Application Firewall does not
attempt to validate responses. If you want to validate responses from
your protected application or Web 2.0 site, you must select the
Validate Response check box. When you do, the check box below it
labeled, Reuse the XML Schema specified in request validation,
and the XML Schema Object drop-down list beneath that, are
activated.
You can check the Reuse XML Schema check box to use the
schema you specified for request validation to do response
validation as well. If you check this check box, the XML
Schema Object drop-down list is greyed out.
You can use the XML Schema Object drop-down list to upload
a different XML schema for response validation.
The XML SOAP Fault Filtering Check
The XML SOAP Fault Filtering check examines responses from protected Web
sites and filters out XML SOAP faults. This prevents leaking of sensitive
information to attackers.
open a profile. To configure all of the general settings, open the Modify XML
SOAP Fault Filtering Check dialog box.
Profiles.
Open.
Beside the XML SOAP Fault Filtering entry, you can select or clear check
4. Click XML SOAP Fault Filtering, and then click Modify.
5. Under Actions, enable or disable each of the actions described below.
The Check Actions control how the XML SOAP Fault Filtering check
functions. They are:
Block. Block connections that violate the XML SOAP Fault Filtering
security check. Enabled by default in profiles created with both basic
and advanced defaults. Clear/select the XML SOAP Fault Filtering
check to disable/enable blocking.
You normally will want to leave the XML SOAP Fault Filtering
check enabled. It prevents leakage of sensitive information that is can
lead to attacks on your protected applications with little or no chance
of blocking legitimate use of your protected applications.
Learn. The learning feature is not available with the XML SOAP
Fault Filtering check, so the Learn check box is greyed out.
Log. Log connections that violate the XML SOAP Fault Filtering
security check. Enabled by default in profiles created with either
basic or advanced defaults. You normally do not want to disable
logging for this or any security check. If anything unexpected
happens, the logs are an important resource for troubleshooting.
Statistics. Generate statistics for connections that violate the XML
SOAP Fault Filtering security check. Enabled by default in profiles
created with either basic or advanced defaults. You normally do not
want to disable statistics. They can help you monitor the types of
attacks that a particular security check is detecting so that you can
determine how effective that check is on your protected Web sites.
Remove. Remove XML SOAP Fault errors from responses before
forwarding those responses to the user. Unselected by default. If your
XML application generates SOAP faults and you want to be certain
that users do not see these faults, you can select this check action.
7. Click Create or OK, and then click Close
CHAPTER 11
The Application Firewall Reports
This chapter describes the two Application Firewall reports that you can view: the
PCI DSS report and the Application Firewall Configuration report. It tells you
where to display and print these reports, and how to use the information that they
provide to better configure and secure your NetScaler appliance.
The PCI DSS Report
The Payment Card Industry (PCI) Data Security Standard (DSS), version 1.2,
consists of twelve security criteria that most credit card companies require
businesses who accept online payments via credit and debit cards to meet. These
criteria are designed to prevent identity theft, hacking, and other types of fraud. If
an internet service provider or online merchant does not meet the PCI DSS
criteria, that ISP or merchant risks loosing authorization to accept credit card
payments via their Web site.
ISPs and online merchants prove that they are in compliance with PCI DSS via an
audit conducted by a PCI DSS Qualified Security Assessor (QSA) Company. The
PCI DSS report is designed to assist them both before and during the audit.
Before the audit, it shows which Application Firewall settings are relevant to PCI
DSS, how they should be configured, and (most important) whether your current
Application Firewall configuration meets the standard. During the audit, the
report can be used to demonstrate compliance with relevant PCI DSS criteria.
The PCI DSS report consists of a list of those PCI DSS criteria that are relevant to
your Application Firewall configuration. Under each criterion, it lists your
current configuration options, indicates whether your current configuration
complies with the PCI DSS criterion, and explains how to configure the
Application Firewall so that your protected Web site(s) will be in compliance
with that criterion.
The PCI DSS report is located under the SystemReports menu tree. You click
Generate PCI DSS Report to generate the report as an Adobe PDF file.
Depending upon your browser settings, the report is then either displayed in the
pop-up window or you are prompted to save it to your hard disk.
Note: To view this and other reports, you must have the Adobe Reader program
installed on your computer. If you do not, you can download it from the Adobe
Web site by clicking the link supplied on the page.
When displayed in the Adobe Reader, the opening screen of the PCI DSS report
appears as shown below.
The PCI DSS Report: Opening Screen
If you scroll down a page, the Executive Summary section of the report appears,
as shown below.
Chapter 11 The Application Firewall Reports 259
The PCI DSS Report: Executive Summary
To see the rest of the report, you use the scroll bar to the right to scroll up and
down the page, and the Adobe Reader paging tools at the bottom to navigate
between pages. The Application Firewall Configuration hyperlink at the top of
the first page to download the configuration information, or the entire report as
one file.
The main report consists of the following sections:
Description. Provides a description of the PCI DSS Compliance Summary
report.
Firewall License and Feature Status. Tells you whether the Application
Firewall is licensed and enabled on your NetScaler appliance.
Executive Summary. A table that lists the PCI DSS criteria, and tells you
which of those criteria are relevant to the Application Firewall.
Detailed PCI DSS Criteria Information. For each of the PCI DSS criteria
that is relevant to your Application Firewall configuration, the PCI DSS
report provides a section that contains information on whether your config-
uration is currently in compliance, and if it is not, how to bring it into com-
pliance.
Data for individual profiles is included in the Configuration section of the report,
which you access either by clicking Application Firewall Configuration at the top
of the report, or directly from the Reports pane. The Application Firewall
Configuration report is the same as the PCI DSS report, with the PCI DSS-
specific summary omitted, and is described below.
The Application Firewall Configuration Report
The Application Firewall Configuration report is located under the
SystemReports menu tree. You click Generate Application Firewall
Configuration Report to generate the report as an Adobe PDF file. Depending
upon your browser settings, the report is then either displayed in the pop-up
window or you are prompted to save it to your hard disk.
The figure below shows the first page of the Application Firewall Configuration
Report displayed in the Adobe Reader.
The PCI DSS Report: Application Firewall Profiles Summary
The Profiles Summary page consists of the following:
Application Firewall Policies. A table that lists your current Application
Firewall policies, showing the policy name, the content of the policy, the
action (or profile) it is associated with, and global binding information.
Application Firewall Profiles. A table that lists your current Application
Firewall profiles, and indicates which policy each profile is associated with.
If a profile is not associated with a policy, the table displays INACTIVE in
that location.
You download all report pages for all policies by clicking the Download All
Profiles hyperlink at the top of the Profiles Summary page. You display the report
page for each individual profile by clicking the hyperlink for that profile in the
Application Firewall Profiles table at the bottom of this screen.
The Profile page for individual profiles consists of the following:
Credit Card Protection Status. Shows each type of credit card the Appli-
cation Firewall can protect, and explains whether protection is enabled and
how credit card protection is configured. For more information about the
different Credit Card check settings and what the effect of each is, see The
Cookie Consistency Check, on page186.
Start URL Check Actions. Shows each action enabled for the Start URL
check. Start URL actions include Block, Learn, Log, Statistics, and URL
Closure, any of which can be enabled independently of the others. For more
information about these actions and what the effect of each is, see the The
Start URL Check, on page175.
Start URL Check. Shows information about each Start URL you have con-
figured.
Cookie Consistency Check Actions. Shows each action enabled for the
Cookie Consistency check. Cookie Consistency actions include Block,
Learn, Log, and Statistics, any of which can be enabled independently of
the others. For more information about these actions and what the effect of
each is, see the The Cookie Consistency Check, on page186.
Cookie Consistency Check. Shows information about each Cookie Con-
sistency Check relaxation you have configured.
Field Consistency Check Actions. Shows each action enabled for the
Form Field Consistency check. Form Field Consistency check actions
include Block, Learn, Log, and Statistics, any of which can be enabled
independently of the others. For more information about these actions and
what the effect of each is, see the The Form Field Consistency Check, on
page201.
Field Consistency Check. Shows information about each Form Field Con-
sistency Check relaxation you have configured.
Buffer Overflow Check Actions. Shows each action enabled for the
Buffer Overflow check. Buffer Overflow check actions include Block, Log,
and Statistics, any of which can be enabled independently of the others. For
more information about these actions and what the effect of each is, see the
The Buffer Overflow Check, on page190.
Buffer Overflow Check. Shows the current setting for Maximum Cookie
Length, Maximum URL Length, and Maximum Header Length.
Field Formats Check Actions. Shows each action enabled for the Field
Formats check. Field Formats check actions include Block, Learn, Log, and
Statistics, any of which can be enabled independently of the others. For
The Field Formats Check, on page208.
Field Formats Check. Shows information about each Field Formats Check
relaxation you have configured.
HTML Cross-Site Scripting Check Actions. Shows each action enabled
for the HTML Cross-Site Scripting check. HTML Cross-Site Scripting
check actions include Block, Learn, Log, Statistics, and Transform Cross-
Site Scripts, any of which can be enabled independently of the others. For
The HTML Cross-Site Scripting Check, on page219.
HTML Cross-Site Scripting Check. Shows information about each
HTML Cross-Site Scripting Check relaxation you have configured.
HTML SQL Injection Check Actions. Shows each action enabled for the
HTML SQL Injection check. HTML SQL Injection check actions include
Block, Learn, Log, Statistics, and Transform SQL Special Characters, any
of which can be enabled independently of the others. In addition, this sec-
tion contains information about your settings for the HTML SQL Injection
Check parameters, Restrict Checks to Fields Containing SQL Special
Characters and SQL Comments Handling. For more information about
these actions and what the effect of each is, see the The HTML SQL Injec-
tion Check, on page226.
HTML SQL Injection Check. Shows information about each HTML SQL
Injection Check relaxation you have configured.
Safe Objects Check. Shows each Safe Object expression you have defined
on your Application Firewall. For more information on the Safe Object
check, see The Safe Object Check, on page196.
Deny URL Check Actions. Shows each action enabled for the Deny URL
check. Deny URL check actions include Block, Log, and Statistics, any of
which can be enabled independently of the others. For more information
about these actions and what the effect of each is, see The Deny URL
Check, on page182.
Deny URL Check. Lists each default Deny URL you have enabled on your
Application Firewall, and each user Deny URL you have configured.
You can download a PDF file containing the PCI DSS report page for the current
profile by clicking the Download Current Profile hyperlink at the top of the page.
You can return to the Profiles Summary page by clicking the Application Firewall
Profiles hyperlink. Finally, you can go directly to the main page by clicking the
Home hyperlink.
You can refresh the PCI DSS report at any time by clicking the Refresh button in
the upper right-hand corner of the browser. You should refresh it if you make
changes to your NetScaler appliance configuration, and in particular changes to
the Application Firewall settings.
The PCI DSS Standard
The twelve PCI DSS criteria are listed below, along with the information that the
PCI DSS report provides for each. You can also view this standard on the Reports
pane, by clicking PCI DSS Standards Document.
Build and Maintain a Secure Network
Requirement 1: Install and maintain a firewall configuration to protect cardholder data.
This requirement is not applicable to Web sites protected by the Citrix
Application Firewall. Since the NetScaler appliance contains an Application
Firewall, you do not need to install a separate firewall configuration to protect
your cardholder data.
Requirement 2: Do not use vendor-supplied defaults for systempasswords and other
security parameters.
This requirement affects two configuration items on the Application Firewall:
have you changed the default password for the nsroot account, and do you use
encryption to protect all administrative access to the NetScaler appliance? If you
have not changed the nsroot password, you must do so to meet this requirement.
If you require users to access the configuration utility using an HTTPS rather than
HTTP connection, and access the NetScaler command line via SSH, you do not
need to do anything to meet that part of the requirement. Normally the
Application Firewall is configured to require this type of access.
Protect Cardholder Data
Requirement 3: Protect stored cardholder data.
The following configuration items are relevant to this requirement:
To ensure that the NetScaler appliance does not store magnetic stripe data,
credit card validation codes, or PINs after a credit card is authorized, you
must configure the Confidential Fields Logging feature for each form field
in each Web form that accepts this data. You will need to do this in each
profile that protects a Web site with a Web form that accepts magnetic
stripe data, credit card validation codes, or PINs.
For more information on configuring this feature, see Chapter 6, Confi-
dential Fields, on page155.
If any credit card you accept for payment is not protected, you must enable
protection for it. The Application Firewall masks the display of any credit
card numbers you protect using the Credit Card check. The PCI DSS report
contains a Credit Card status table that lists each profile you have created,
and tells you which credit card types are protected on which profile.
Note: PCI DSS allows you to display only the first six and final four
digits of a PAN on screen.
For information about the Credit Card check and instructions on config-
uring it, see The Cookie Consistency Check, on page186 and following.
Are Primary Account Numbers (PANs) stored in unreadable format?
To ensure that the NetScaler appliance does not store unencrypted Primary
Account Numbers (PANs) in its logs, you must configure the Confidential
Fields Logging feature for each form field in each Web form that accepts
this data. You will need to do this in each profile that protects a Web site
with a Web form that accepts PANs.
For more information on configuring this feature, see Chapter 6, Confi-
dential Fields, on page155.
Requirement 4: Encrypt transmission of cardholder data across open, public networks.
This requirement is not applicable to the Citrix Application Firewall, but to the
Web servers that handle this data. You must ensure that any Web server that
transmits cardholder data across an open network uses an appropriate type of
encryption to protect that data.
Maintain a Vulnerability Management Program
Requirement 5: Use and regularly update anti-virus software.
This requirement is not applicable to the Citrix Application Firewall, which uses
a proprietary operating system and is not susceptible to infection by any known
type of virus. You must ensure that any other server on your network that accepts,
transmits, or stores cardholder data and is susceptible to virus infection uses
appropriate anti-virus software and updates it frequently.
Requirement 6: Develop and maintain secure systems and applications.
The Application Firewall blocks both known and unknown attacks against the
Web applications it protects. The PCI DSS report contains a list of each policy
and each profile you have configured, with relevant information about each one.
For each profile, it explains which security checks are enabled and how they are
configured. You must review this configuration and determine whether it
appropriately protects all servers on your network that accept, transmit, and store
customer data.
Implement Strong Access Control Measures
Requirement 7: Restrict access to cardholder data by business need-to-know.
Web servers and back-end database servers that handle this data. You must ensure
that any database server that stores cardholder data has appropriate access control
restrictions and measures in place, and that you enforce compliance with those
measures.
Requirement 8: Assign a unique ID to each person with computer access.
To ensure compliance with this standard, you must create separate user names
and passwords for each individual that accesses the NetScaler appliance. The
NetScaler appliance cannot determine whether you have done this or not because
it cannot tell whether more than one person is using the same user name and
password to log on.
Requirement 9: Restrict physical access to cardholder data.
access controls on your server room and to any non-electronic copies of this data.
The department responsible for maintaining your offices and physical plant must
ensure that only authorized people can enter the server room or gain access to
files that contain non-electronic copies of this information.
Regularly Monitor and Test Networks
Requirement 10: Track and monitor all access to network resources and cardholder
data.
The NetScaler appliance takes care of most of this. It logs all activity by root or
administrative accounts automatically. It automatically maintains audit trails for
all sensitive types of activity. It logs all logon attempts (valid and invalid) and all
activity by any user identification or authentication mechanism automatically. it
logs all activity involving creation or deletion of system-level objects
automatically. To ensure that all system clocks and times are synchronized
properly, you must configure an NTP server and then configure the NetScaler
appliance to set the time on its system clock from this NTP server. This
guarantees that the logs generated by the NetScaler appliance have proper
timestamps.
Requirement 11: Regularly test security systems and processes.
This requirement is not applicable to the Citrix Application Firewall, but to your
network. Your IT department must regularly run security audits on your network
and servers to ensure that they are working correctly, and fix any security
vulnerabilities as they are found.
Maintain an Information Security Policy
Requirement 12: Maintain a policy that addresses information security.
This requirement is not applicable to the Citrix Application Firewall, but to your
company. The appropriate office must write and maintain a policy that describes
how your company ensures that sensitive customer information, including
cardholder data, will be protected.
For more information on the PCI DSS standard, see AppendixB, PCI DSS
Standard, on page351.
CHAPTER 12
Use Cases
This chapter contains two use cases that explain how to configure your Citrix
Application Firewall to protect specific types of Web servers and specific kinds of
web content.
Shopping Cart application. If part of your Web site communicates with a
back-end SQL-based database, such as a shopping cart application usually
does, see Protecting a Shopping Cart Application on page267 for infor-
mation on how to configure the Application Firewall to protect the applica-
tion and the SQL database.
Product Information query. If your Web sites contain J avascripts or other
scripts that obtain information from or save information to any Web server
but their own, such as a product information library accessed through a jav-
ascript-enhanced Web form, see Protecting a Product Information Query
Page on page289 for information on how to configure the Application
Firewall to protect your Web sites while allowing your scripts to continue
functioning as they were designed to function.
This chapter introduces Example Manufacturing, Inc., a company with a number
of Web sites that it uses to provide information about the company, sell its many
products, manage customer support for its products, and provide internal services
to its employees. It has Web sites with all sorts of content, some of them with
access to sensitive private information.
It uses the Citrix NetScaler appliance to protect its Web sites.
Protecting a Shopping Cart Application
Example Manufacturing hosts a shopping cart application at
shoppi ng. exampl e. com. This application has Web forms that collect orders
and customer information, and that store that information in an SQL database.
The shopping cart application is old code, and has security issues. Rather than
transition to a new system, Example has installed a Citrix NetScaler Application
Switch, Enterprise Edition with the Citrix NetScaler Application Firewall feature
to protect their Web site.
The system administrator at Example has already performed the installation and
initial configuration of the NetScaler appliance. He has also enabled the
Application Firewall, created the first profile and first policy, and globally bound
the policy. He now wants to create a more specific profile to protect the shopping
cart application, with appropriate relaxations and settings for the SQL Injection
check, and an associated policy that can detect connections to the shopping cart
and apply the correct security checks when filtering those connections.
The subsections below describe how he can do this using either the configuration
utility or the NetScaler command line.
Creating and Configuring the Shopping Cart
Profile
To protect the shopping cart application, the system administrator must first
create a profile that tells the Application Firewall how to protect it. The shopping
cart application has been in use for many years. It was built using Web forms and
PERL CGI scripts, and uses cookies to maintain user state. It does not use any
J avascript in its Web forms.
The system administrator wants to protect the shopping cart against two types of
attacks to which it is particularly vulnerable:
Cookie tampering. The system administrator knows that the shopping cart
application performs no checks on the cookies that users return to the appli-
cation. An attacker could modify a cookie and gain access to the shopping
cart application under another users credentials. Once logged on as that
user, the attacker could obtain sensitive private information about the legit-
imate user or place orders using the legitimate users account.
SQL injection. The system administrator knows that the shopping cart
application performs no checks on the data returned in the form fields of its
Web forms, but passes that information on directly to the SQL database.
This leaves the SQL database vulnerable to injected SQL codean attacker
can place SQL commands in the form fields of the shopping cart form and
send them directly to the database. The attacker could use this type of attack
to obtain sensitive private information from the database or modify infor-
mation in the database.
The system administrator will create the new profile using Advanced defaults
instead of Basic defaults. He will therefore need to perform configuration on a
number of other checks to prevent the Application Firewall from blocking
legitimate traffic (false positives).
This section contains two procedures to protect this shopping cart application
one to create this profile using the configuration utility, and one to create it using
the NetScaler command line.
Chapter 12 Use Cases 269
To create a profile to protect the shopping cart using the configuration
utility
1. Log on to the configuration utility using either the J ava client or the Web
Start client.
on page40.
choices in that category, and click Profiles to display the Profiles page,
shown below.
The Application Firewall Profiles Page
3. Add a profile as described in Chapter 3, Simple Configuration, To create
and configure a profile using the configuration utility on page67, but this
time click the Advanced radio button to choose Advanced defaults.
The system administrator names the new profile Shopping Cart so that he
and others will know which type of web content it is intended to protect, as
shown below.
The Create Application Firewall Profile Dialog Box with Advanced Defaults
After he adds the profile, the profiles name appears in the profiles list in
data area of the Profiles page.
4. In the profiles list, click the name of the new profile once, to highlight it.
The figure below shows the Shopping Cart profile selected. After you select
a profile, the Open and Remove buttons at the bottom of the data area are
activated.
The Application Firewall Profiles Page, with Profile Selected
5. Click the Open button to display the Configure Application Firewall Profile
dialog box for that profile, shown below
The Configure Application Firewall Profile Dialog Box, General Tab
6. Click the Checks tab to display it, as shown below.
The Configure Application Firewall Profile Dialog Box, Checks Tab
In the Checks tab you configure the checks that the Application Firewall
uses to protect your Web sites. In this case, the system administrator wants
to configure the Start URL check; the SQL Injection check, which protects
back-end SQL-based databases; and the Cookie Consistency check, which
prevents cookie tampering. He also will configure the Credit Card check, to
prevent the shopping cart from sending credit card numbers to users, and
several other checks to prevent false positives.
7. Configure the Start URL check.
A. In the Security Checks list, if it is not already highlighted, click Start
URL once to highlight it.
B. Click the Modify button to display the Modify Start URL Check
The Modify Start URL Check Dialog Box, General Tab
C. In the Check Actions area, clear the Block check box, as shown
below.
The Modify Start URL Check Dialog Box, General Tab, with Blocking Disabled
Since the Learning check box is selected, learning mode is enabled
for this rule. The system administrator does not want to risk blocking
legitimate requests sent to the shopping cart application until learning
has generated an appropriate list of Start URLs for the Start URL
rule. After the learning feature has generated a list of Start URLs and
he has reviewed and applied them, he can re-enable blocking for this
check.
D. Click the OK button to save your changes.
The Start URL Check dialog box closes, and a message box appears,
notifying you that your changes have been successfully saved.
E. Click the OK button to close the message box and return to the
As shown below, the Block column for the Start URL entry now
reads No, showing that blocking is disabled for the Start URL rule.
The Configure Application Firewall Profile Dialog Box, Checks Tab,
with Start URL Blocking Disabled
8. Configure the Cookie Consistency check by following the same procedure
described in step7.
The figure below shows the Modify Cookie Consistency Check dialog box,
which is nearly identical to the Modify Start URL Check dialog box, except
that there is no Enforce URL closure check box.
The Modify Cookie Consistency Check Dialog Box, General Tab, with Blocking Disabled
With the Cookie Consistency rule, the system administrator wants to
disable blocking at first, to prevent legitimate cookies from being blocked.
After the learning feature has generated a list of cookie relaxations and he
has reviewed and applied them, he can re-enable blocking for this check.
9. Configure the Form Field Consistency check by following the same
procedure described in step8.
The Modify Form Field Consistency Check dialog box is identical to the
Modify Start URL Check dialog box except for the title and description
text. With the Form Field Consistency rule, the system administrator wants
to disable blocking at first to prevent legitimate form field data from being
blocked. After the learning feature has generated a list of form field
relaxations and he has reviewed and applied them, he can re-enable
blocking for this check.
10. Configure the HTML SQL Injection check.
A. In the Security Checks list, click HTML SQL Injection once to
highlight it.
B. Click the Modify button to display the Modify HTML SQL Injection
Check dialog box, shown below.
The Modify HTML SQL Injection Check Dialog Box, General Tab
C. In the Check Actions area, uncheck the Block check box.
Since the Learning check box is checked, learning mode is enabled
legitimate requests to the shopping cart application until learning has
generated an appropriate list of relaxations to the HTML SQL
Injection check.
D. Check the check box labeled, Transform SQL special characters.
This tells the Application Firewall to modify any SQL special
characters it detects into harmless character strings that will have no
effect on the SQL database. Because the system administrator just
disabled blocking for the HTML SQL Injection check, he wants to be
sure that any attempts to inject SQL code into the shopping cart
application are rendered harmless.
Note: You should ignore the choices in the Parameters area for
now.
E. Click the OK button to save your changes, and when prompted, click
the OK button to confirm your choices.
The HTML SQL Injection Check dialog box closes, and you return to
the Configure Application Firewall Profile dialog box.
11. Configure the Credit Card check.
A. In the Security Checks list, click Credit Card once to highlight it.
B. Click the Modify button to display the Modify Credit Card Check
The Modify Credit Card Check Dialog Box, General Tab
C. In the Check Actions area, check the Log, Statistics, and X-Out check
boxes, as shown below.
The Modify Credit Card Check Dialog Box, General Tab With Logging, Statistics, and X-
Out Enabled
By checking the X-Out check box, the system administrator ensures
that any credit card numbers that the shopping cart application
displays on any of its pages are masked out and cannot be read by the
user. This recreates the standard behavior of modern secure ordering
site web pages.
Note: You should ignore the choices in the Parameters area for
now.
D. Click the Settings tab to display it, as shown below.
The Modify Credit Card Check Dialog Box, Settings Tab
This tab lists six types of credit cards whose numbers the Application
Firewall can detect and either mask or block.
E. Hold down the Ctrl key, and click the name of each credit card you
want to protect once, to highlight it.
Since Example, Inc. accepts only Visa, MasterCard, American
Express, and Discover, and therefore stores only those card numbers
in its database, the system administrator highlights just those credit
cards.
F. Click the Protect button to enable protection for the selected types of
credit card numbers.
The display refreshes, and the Status column to the right of each
credit card you chose changes from Unprotected to Protected, as
shown below.
Modify Credit Card Check Dialog Box, Settings Tab, with Protected Credit Cards
G. Click the OK button to save your changes, and when prompted, click
The Credit Card Check dialog box closes, and you return to the
12. Click the OK button to close the Configure Application Firewall Profile
To create a profile to protect the shopping cart using the NetScaler
command line
via SSH on page60.
> add appf w pr of i l e " Shoppi ng Car t " - def aul t s advanced
The system administrator creates a profile named Shopping Cart, to make
clear to himself and anyone else who might configure the Application
Firewall what type of web content this profile is designed to protect. He
uses the - def aul t s advanced parameter to tell the Application Firewall
to create this profile with advanced defaults. Advanced defaults provide
protection that is more closely tailored to the Web site or web content that
they protect, but they also require more input from the system administrator
responsible for the appliance.
For more information about defaults, see Chapter 4, Profiles, on page83.
3. Enter the following command to configure the Start URL check properly
for the Shopping Cart profile.
> set appf w pr of i l e " Shoppi ng Car t " - st ar t URLAct i on LEARN
LOG STATS - st ar t URLCl osur e ON
Note: For readability, this command and others are formatted with each
parameter on a separate line, and aligned under one another. When you
enter the command at the NetScaler command line, you should type it all on
a single line, with parameters separated by a single space.
The system administrator wants to disable blocking for the Start URL
check. That allows the learning feature to generate a list of start URLs
while not blocking legitimate connections to the shopping cart application
that might violate this check. The - st ar t URLAct i on LEARN LOG STATS
parameter turns off blocking while leaving learning, logging, and statistics
enabled.
By enabling URL closure, the system administrator tells the Application
Firewall that users should be allowed to access any web content on the
shopping cart application by clicking a hyperlink on a web page within that
application. This prevents blocking of legitimate requests, and significantly
reduces the number of Start URLs that learning must generate for the
shopping cart application. The - st ar t URLCl osur e ON parameter enables
URL closure.
4. Enter the following command to configure the Cookie Consistency and
Form Field Consistency checks properly for the Shopping Cart profile.
> set appf w pr of i l e " Shoppi ng Car t "
- cooki eConsi st encyAct i on LEARN LOG STATS
- f i el dConsi st encyAct i on LEARN LOG STATS
The system administrator wants to disable blocking for the Cookie
Consistency and Form Field Consistency checks. That allows the learning
feature to generate a list of exceptions to these checks while not blocking
legitimate connections to the shopping cart application that might violate
the checks. The - cooki eConsi st encyAct i on LEARN LOG STATS
parameter turns off blocking for the Cookie Consistency check, and the -
f i el dConsi st encyAct i on LEARN LOG STATS parameter turns off
blocking for the Form Field Consistency check, while leaving learning,
logging and statistics enabled.
5. Enter the following command to configure the SQL Injection check
properly for the Shopping Cart profile.
> set appf w pr of i l e " Shoppi ng Car t "
- SQLI nj ect i onAct i on LEARN LOG STATS
- SQLI nj ect i onTr ansf or mSpeci al Char s ON
The system administrator wants to disable blocking for the SQL injection
check. That allows the learning feature to generate a list of exceptions to
this check while not blocking legitimate connections to the shopping cart
application that might violate the check. The - SQLI nj ect i onAct i on
LEARN LOG STATS parameter turns off blocking for the SQL Injection
check, but leaves learning, logging, and statistics enabled.
To protect the SQL database while learning is working, he also wants the
Application Firewall to transform any SQL special characters it detects into
a string that will have no effect on the SQL database. The
- SQLI nj ect i onTr ansf or mSpeci al Char s ON parameter enables
transformation of SQL special characters.
6. Enter the following command to configure the Credit Card check properly
for the Shopping Cart profile.
> set appf w pr of i l e SQL - cr edi t Car dAct i on LOG STATS
- cr edi t Car dXOut ON
- cr edi t Car d VI SA Mast er Car d Amex
The system administrator wants to disable blocking for the Credit Card
check because order confirmation pages from the shopping cart application
show the users credit card number. He wants to prevent that from
happening without blocking the order confirmation pages. The
- cr edi t Car dAct i on LOG STATS parameter turns off blocking for the
Credit Card check, but leaves logging and statistics enabled.
The system administrator prevents the credit card numbers from appearing
on the order confirmation pages by enabling the X-Out feature instead of
blocking. When X-Out is enabled, the Application Firewall masks the
digits of any credit card numbers it detects with the letter x. The
- cr edi t Car dXOut ON parameter turns on the X-Out feature.
Finally the system administrator adds protection for the specific types of
credit card that the shopping cart application handles. The - cr edi t Car d
Vi sa Mast er Car d Amex parameter enables protection for those credit
cards.
> save ns conf i g
created.
> show appf w pr of i l e " Shoppi ng Car t "
Before he continues, the system administrator views and checks the profile
settings to ensure that they are correct.
If the name is not correct, he removes the profile, as shown below,
and recreates it.
> r mappf w pr of i l e SQL
If any of the settings is not correct, he repeats the set appf w
pr of i l e command with the appropriate settings to fix the problem.
The system administrator has successfully created a profile to protect the
shopping cart application and its SQL database. He must now create a policy to
determine when to apply that profile.
Creating and Configuring a Shopping Cart Policy
To protect the shopping cart application, the system administrator must now
create a policy that tells the Application Firewall how to determine which
requests are to, and which responses come from, the shopping card application.
Fortunately, the shopping cart application is hosted at a subdomain,
shoppi ng. exampl e. com, so creating the policy will be easy.
This section contains two proceduresone to create the Shopping Cart policy
using the configuration utility, and one to create it using the NetScaler command
line.
To create a policy to protect the shopping cart using the configuration utility
choices in that category, and click Policies to display the Policies page.
display the Create Application Firewall Policy dialog box, shown below.
The Create Application Firewall Policy Dialog Box
If you have not yet created a policy, or if you did not first select a policy in
the data area of the Policies page, the Create Application Firewall Policy
dialog box is blank. If you selected an existing policy, the Create
Application Firewall Policy dialog box displays the information from that
policy, including all expressions, so that you can modify it to create a new
policy. You can use this to your advantage to minimize typing when you are
creating a series of similar policies.
3. In the Policy Name* text box, type a name for your new policy.
Since the system administrator is creating a policy to protect a shopping
cart, he names it, Shopping Cart.
4. Click the down arrow to the right of the Action list box, and click name of
the profile you want to associate with this policy.
The system administrator picks the Shopping Cart profile.
5. Click the Add button to display the Add Expression dialog box, shown
below, and construct an expression that describes the type of web
connections you want this policy to match.
The system administrator wants to create an expression that detects all
requests to the shopping cart application. Fortunately, that application is
hosted at its own subdomain, so he only needs to create an expression that
detects requests sent to that subdomain.
Note: Like the Create Application Firewall Policy dialog box, the
Expression Editor displays the information from the last expression you
created, so that you can modify it to create a new expression.
A. If the Flow Type is not already set to REQ, click the down arrow
beside the list box and set it to REQ.
B. If the Protocol is not already set to HTTP, click the down arrow
beside the list box and set it to HTTP.
C. If the Qualifier is not already set to Header, click the down arrow
beside the list box and set it to Header.
D. Click the down arrow beside the list box and set the Operator to
CONTAINS, as shown below.
The Add Expression Dialog Box, HEADER CONTAINS Operator
E. In the Value* text box, type the hostname of the host where this
application is located.
The system administrator types shoppi ng. exampl e. com.
F. Type Host in the Header* text box, as shown below.
The Add Expression Dialog Box, HEADER CONTAINS Operator with Text and Header
Name
G. Click the OK button to add the expression to the Expression list.
H. Click the Close button to close the Expression Editor and return to the
Create Application Firewall Policy dialog box.
6. Click the Create button to create the policy.
The system administrator creates the Shopping Cart policy, and it appears
in the Profiles page list in the data area.
The system administrators new policy, Shopping Cart, now appears in the
Profiles page, as shown below.
The Application Firewall Policies Page, with Policies Defined
8. Globally bind the Shopping Cart policy following the procedure in
Chapter 3, Simple Configuration, To globally bind a policy by using the
The system administrator globally binds the Shopping Cart policy,
assigning it a priority of 1 to ensure that any connections to the shopping
cart application are processed using the Shopping Cart policy and profile.
When he is finished, the Policies page column labeled, Globally bound?,
shows a check mark and yes, indicating that the Shopping Cart policy is
globally bound, as shown below.
The Application Firewall Policies Page, with Policies Globally Bound
To create a policy to protect the shopping cart using the NetScaler
command line
1. At the NetScaler command line, enter the following command to create the
new policy.
The system administrator makes the following substitutions:
For <name>, the system administrator substitutes Shopping Cart, to
indicate that this policy detects SQL content.
Note: Names that contain embedded spaces must be enclosed in
double quotes.
For <r ul e>, the system administrator substitutes the following
PCRE-compatible regular expression:
" REQ. HTTP. HEADER URL CONTAI NS shoppi ng. exampl e. com"
This regular expression tells the Application Firewall to check all HTTP
requests to see whether they include the host shoppi ng. exampl e. com.
These requests, and only these requests, are sent to the shopping cart and
should be checked using the SQL profile.
For <pr of i l e>, the system administrator substitutes Shopping
Cart, to indicate that this policy is associated with the Shopping Cart
profile.
The actual command that the system administrator types is as follows:
> add appf w pol i cy " Shoppi ng Car t " " REQ. HTTP. HEADER URL
CONTAI NS shoppi ng. exampl e. com" " Shoppi ng Car t "
Note: Although the preceding rule wraps onto two lines, you should type
it on a single line in the NetScaler command line.
> save ns conf i g
created.
> show appf w pol i cy <name>
For <name>, the system administrator substitutes Shopping Cart. The
policy is correct, so the system administrator proceeds to bind it globally.
4. Follow the procedure in Chapter 3, Simple Configuration, in the
procedure To globally bind a policy using the NetScaler command line
on page81 to globally bind the new policy.
The system administrator globally binds the new policy, assigning it a
priority of 1 to ensure that any connections to the shopping cart application
are processed using the Shopping Cart policy and profile rather than
another, less specific policy.
The system administrator has successfully created a policy to protect the
shopping cart applications SQL database, and globally bound that policy with the
appropriate priority. The Application Firewall is now filtering connections to the
shopping cart application using the new policy and profile.
Protecting a Product Information Query Page
Example Manufacturing hosts a large amount of information about its products
and solutions on its corporate Web site, www. exampl e. com. The Web site uses
J avascript in Web forms that allow users to access brochures, technical
specifications, and white papers about a variety of products and on a variety of
subjects. These white papers are provided only to customers or prospective
customers who request them and provide their names and email addresses.
The Web forms do not have access to the main customer database, but write the
names and email addresses of customers that request white papers to an auxiliary
file on the shoppi ng. exampl e. comserver for later processing. The J avascripts
on these Web forms violate the same origin rule, which normally does not allow
scripts to access or modify content on any server but their own. (This security
vulnerability is called cross-site scripting.) An attacker could therefore
potentially use a J avascript on the Example Manufacturing Web site to obtain a
copy of the white paper requests file or other content on the Web server that
should not be available to users. Example Manufacturing wants to protect its Web
site without rewriting all of its Web forms and scripts.
The system administrator therefore needs to create a more specific profile to
protect these J avascript-enhanced forms, with appropriate relaxations and settings
for the Cross-Site Scripting check, and an associated policy that can detect
connections to the Web forms and apply the correct profile when filtering those
connections.
Creating and Configuring a Product Query Profile
To protect the J avascript-enhanced forms on the exampl e. comWeb site, the
system administrator must first create a profile that tells the Application Firewall
how to protect this type of content. He specifically wants to protect these Web
forms from cross-site scripting attacks while allowing them to function as they
were designed to function.
The system administrator will create this profile using Advanced defaults instead
of Basic defaults. He will therefore need to perform configuration on a number of
other checks to prevent the Application Firewall from blocking legitimate traffic.
The procedures below describe how he can do this using either the configuration
utility or the NetScaler command line.
To create a profile to protect product query pages using the configuration
utility
1. Log on to the configuration utility using either the J ava client or the Web
Start client.
on page40.
choices in that category, and click Profiles to display the Profiles page.
3. Add a profile as described in Chapter 3, Simple Configuration, To create
and configure a profile using the configuration utility on page67, but click
the Advanced radio button to choose Advanced defaults.
The system administrator names the new profile Product Query so that he
and others will know which type of web content it is intended to protect, as
shown below.
The Create Application Firewall Profile Dialog Box
After he adds the profile, the profiles name appears in the profiles list in
data area of the Profiles page.
4. In the profiles list, click the name of your new profile once, to highlight it.
dialog box.
6. Click the Checks tab to display it.
In the Checks tab you configure the checks that the Application Firewall
uses to protect your Web sites. The system administrator needs to configure
several checks for this profile.
7. Configure the Start URL check.
A. In the Security Checks list, click Start URL once to highlight it.
B. Click the Modify button to display the Modify Start URL Check
dialog box.
C. Uncheck the Block, Learn, Log, Statistics and Enforce URL Closure
check boxes, as shown below.
Modify Start URL Dialog Box, General Tab, Disabled
The system administrator wants to disable the Start URL check
entirely because this profile will be applied only to specific, known
URLs that the system administrator will list explicitly in the Scripts
policy. Requests to any other URLs will be processed using another
profile.
The Modify Start URL Check dialog box closes, and a message box
appears, notifying you that your changes have been successfully
saved.
8. Configure the Cookie Consistency check.
A. In the Security Checks list, click Cookie Consistency once to
highlight it.
B. Click the Modify button to display the Modify Cookie Consistency
Check dialog box.
C. Uncheck the Block check box, as shown below.
Modify Cookie Consistency Check Dialog Box, with Blocking Disabled
With the Cookie Consistency rule, the system administrator wants to
disable blocking at first, to prevent legitimate cookies from being
blocked. After the learning feature has generated a list of cookie
The Cookie Consistency Check dialog box closes, and a message box
appears, notifying you that your changes have been successfully
saved.
9. Configure the Form Field Consistency check by following the same
procedure described in step8.
With the Form Field Consistency rule, the system administrator wants to
disable blocking at first to prevent legitimate form field data from being
blocked. After the learning feature has generated a list of form field
10. Configure the Cross-Site Scripting check.
A. In the Security Checks list, click Cross-Site Scripting once to
highlight it.
B. Click the Modify button to display the Modify Cross-Site Scripting
Check dialog box, shown below.
The Modify Cross-Site Scripting Check Dialog Box, General Tab
C. In the Check Actions area, uncheck the Block check box.
Since the Learning check box is checked, learning mode is enabled
legitimate requests until learning has generated an appropriate list of
relaxations to the Cross-Site Scripting rule.
Since no URLs except those explicitly listed in the J avascript Profile
will be checked using this profile, no J avascripts except those that the
system administrator has checked and approved will be checked
using this profile.
Note: The Cross-Site Scripting check has an additional setting that
can be used to protect against cross-site scripting errors. If the system
administrator had checked the check box labeled, Transform cross-
site scripts,, that would have told the Application Firewall to render
any unsafe scripts harmless, and then allow the connection to
proceed. This would break the specific URLs that the system
administrator wants to protect, however, because it would modify the
J avascripts that the web pages at these URLs contain, rendering them
non-functional.
D. Click the OK button to save your changes, and when prompted, click
The Cross-Site Scripting Check dialog box closes, and you return to
the Configure Application Firewall Profile dialog box.
11. Click the Settings tab to display it, as shown below.
12. In the text box, modify the Error Page to the appropriate URL.
The default value of forward slash (/ ) tells the Application Firewall to
redirect blocked requests to the Web site home page. For other pages on the
exampl e. comWeb site, this is the correct behavior, but the Web site uses a
special error page,
ht t p: / / www. exampl e. com/ r equest er r or . ht ml , for blocked
requests to this particular URL.
After ensuring that the special error page exists and is displayed in the web
browser when opened directly, the system administrator modifies the Error
Page as follows to redirect these requests to the appropriate URL:
/ r equest er r or . ht ml
This setting will redirect all blocked requests to the web pages in question
to ht t p: / / www. exampl e. com/ r equest er r or . ht ml .
The Configure Application Firewall Profile dialog box closes, and you
return to the Profiles page.
To create a profile to protect product query pages using the NetScaler
command line
via SSH on page60.
> add appf w pr of i l e " Pr oduct Quer y" - def aul t s advanced
The system administrator creates a profile named Product Query, to make
clear to himself and anyone else who might configure the Application
Firewall what type of web content this profile is designed to protect. He
uses the - def aul t s advanced parameter to tell the Application Firewall
to create this profile with advanced defaults. Advanced defaults provide
protection that is more closely tailored to the Web site or web content that
they protect, but they also require more input from the system administrator
responsible for the appliance.
For more information about defaults, see Chapter 4, Profiles, on page83.
3. Enter the following command to configure the Start URL check properly
for the Scripts profile.
> set appf w pr of i l e " Pr oduct Quer y" - st ar t URLAct i on NONE
- st ar t URLCl osur e OFF
Note: For readability, this command and others are formatted with each
parameter on a separate line, and aligned under one another. When you
enter the command at the NetScaler command line, you should type it all on
a single line, with parameters separated by a single space.
The system administrator wants to disable the Start URL check because the
Scripts profile will be applied only to specific, known URLs. Requests to
any other URLs will be processed using a different profile. It is therefore
easiest not to use the Start URL rule with this request. The -
st ar t URLAct i on NONE parameter disables the Start URL rule. The -
st ar t URLCl osur e OFF parameter turns off URL closure.
4. Enter the following command to configure the Cookie Consistency and
Form Field Consistency checks properly for the Scripts profile.
> set appfw profile "Product Query"
-cookieConsistencyAction LEARN LOG STATS
-fieldConsistencyAction LEARN LOG STATS
The system administrator wants to disable blocking for the Cookie
Consistency and Form Field Consistency checks. That allows the learning
feature to generate a list of exceptions to these checks while not blocking
legitimate connections that might violate the checks. The
- cooki eConsi st encyAct i on LEARN LOG STATS parameter turns off
blocking for the Cookie Consistency check, and the
- f i el dConsi st encyAct i on LEARN LOG STATS parameter turns off
blocking for the Form Field Consistency check, without disabling learning,
logging, or statistics.
5. Enter the following command to configure the Cross-Site Scripting check
properly for the Scripts profile.
> set appfw profile "Product Query"
-crossSiteScriptingAction LEARN LOG STATS
The system administrator wants to disable blocking for the Cross-Site
Scripting check. That allows the learning feature to generate a list of
exceptions to this check while not blocking legitimate connections that
might violate the check. The - cr ossSi t eScr i pt i ngAct i on LEARN
LOG STATS parameter turns off blocking for the Cross-Site Scripting
check without disabling learning, logging, or statistics.
Only specific and explicitly listed URLs will be checked using this profile.
Since blocking is on for the Start URL check in the generic profile that is
used to filter any other URLs containing J avascript, no scripted Web form
content except for the URLs that the system administrator specifically
includes in the Scripts policy will be exempted from the Cross-Site
Scripting check. This allows the system administrator to check and approve
any J avascripts that violate the same origin rule before users can access the
web pages on which those scripts appear.
Note: The Cross-Site Scripting check has an additional parameter that
can be used to protect against cross-site scripting errorsthe
- cr ossSi t eScr i pt i ngTr ansf or mUnsaf eHTML ON parameter. This
parameter tells the Application Firewall to render any unsafe scripts
harmless, and then allow the connection to proceed. This parameter,
however, would break the specific URLs that the system administrator
wants to protect because it would modify the scripts that the URLs contain,
rendering them non-functional.
6. Enter the following command to set the Error Page.
> set appf w pr of i l e " Pr oduct Quer y"
- er r or URL " / r equest er r or \ . ht ml "
The default Error Page value of forward slash (/ ) tells the Application
Firewall to redirect blocked requests to the Web site home page. For other
pages on the exampl e. comWeb site, this is the correct behavior, but the
Web site uses a special error page for blocked requests to this particular
URL, so the system administrator sets it explicitly here.
> save ns conf i g
created.
> show appf w pr of i l e " Pr oduct Quer y"
Before he continues, the system administrator views and checks the profile
settings to ensure that they are correct.
If the name is not correct, he removes the profile, as shown below,
and recreates it.
> r mappf w pr of i l e " Pr oduct Quer y"
If any of the settings is not correct, he repeats the set appf w
pr of i l e command with the appropriate settings to fix the problem.
The system administrator has successfully created a profile to protect the
J avascript-enhanced forms on the Example Web site. He must now create a policy
to determine when to apply that profile.
Creating and Configuring a Product Query Policy
To protect the product query Web forms on the exampl e. comWeb site, the
system administrator must now create a policy that tells the Application Firewall
how to determine which requests are sent to these Web forms. Unlike the
shopping cart application, these Web forms are not all located in a specific
subdomain or named using a specific naming convention, so the system
administrator decides to list the relevant URLs explicitly in the policy to
guarantee that this policy and profile will be applied only to those URLs.
This section contains two proceduresone to create the J avascript policy using
the configuration utility, and one to create it using the NetScaler command line.
To create a policy to protect product query pages using the configuration
utility
choices in that category, an.
display the Create Application Firewall Policy dialog box.
If you have not yet created a policy, or if you did not first select a policy in
the data area of the Policies page, the Create Application Firewall Policy
dialog box is blank. If you selected an existing policy, the Create
Application Firewall Policy dialog box displays the information from that
policy, including all expressions, so that you can modify it to create a new
policy. You can use this to your advantage to minimize typing when you are
creating a series of similar policies.
3. In the Policy Name text box, type a name for your new policy.
Since the system administrator is creating a policy to protect product query
search URLs, he names it, Product Query.
4. Click the down arrow to the right of the Action list box, and click name of
the profile you want to associate with this policy.
The system administrator picks the Product Query profile.
5. Click the Add button to display the Add Expression dialog box, and
construct an expression that describes the type of web connections you
want this policy to match.
The system administrator wants to create an expression that detects
requests to the product query web pages. Unfortunately those web pages are
not hosted on a separate subdomain, nor do they follow a predictable
naming convention.
The system administrator wants to be sure that any cross-site scripts except
those on the specified, approved web pages are blocked. So he decides to
list each URL containing a product query Web form separately in the
policy. This means that the Product Query policy will detect only the
approved URLs, and will therefore apply the Product Query profile with its
associated relaxations only to approved URLs.
Note: Like the Create Application Firewall Policy dialog box, the Add
Expression dialog box displays the information from the last expression
you created, so that you can modify it to create a new expression.
A. If the Flow Type is not already set to REQ, click the down arrow
beside the list box and set it to REQ.
B. If the Protocol is not already set to HTTP, click the down arrow
beside the list box and set it to HTTP.
C. If the Qualifier is not already set to Header, click the down arrow
beside the list box and set it to Header.
D. Click the down arrow beside the list box and set the Operator to ==.
The == symbol requires an exact bitwise match.
E. Type URL in the Header* text box.
F. In the Value* text box, type the URL you want to protect.
The system administrator types the following URL.
ht t p: / / www. exampl e. com/ pr oduct s/ wpr equest . j ht ml
G. Repeat stepF to add additional URLs to the list.
The system administrator adds the following URLs, one after the
other:
ht t p: / / www. exampl e. com/ pr oduct s/ quot er equest . j ht ml
ht t p: / / www. exampl e. com/ sol ut i ons/ whi t epaper . j ht ml
ht t p: / / www. exampl e. com/ cust supt / docr eq. j ht ml
All of these URLs write user information to a file on the
shoppi ng. exampl e. comserver, although all are hosted on the
www. exampl e. comserver. All therefore violate the Cross-Site
Scripting check, and need an explicit relaxation of that check to
prevent their being blocked.
H. Click the OK button to add the expression to the Expression list.
I. Click the Close button to close the Add Expression dialog box and
return to the Create Application Firewall Policy dialog box.
The Create Application Firewall dialog box now contains four
expressions.
6. Click the Create button to create the policy.
The system administrator creates the Product Query policy.
dialog box and return to the Policies page.
8. Globally bind the Product Query policy following the procedure in
Chapter 3, Simple Configuration, To globally bind a policy by using the
The system administrator globally binds the Product Query policy,
assigning it a priority of 2 to ensure that any connections to the specified
URLs are processed using the Product Query policy and profile.
To create a policy to protect product query pages using the NetScaler
command line
1. At the NetScaler command line, enter the following command to create the
new policy.
The system administrator makes the following substitutions:
For <name>, the system administrator substitutes " Pr oduct
Quer y" , to show which URLs this policy should be applied to.
For <r ul e>, the system administrator substitutes the following four
PCRE-compatible regular expressions, separated by the OR (| | )
operator:
" ^ht t p: / / www\ . exampl e\ . com/ pr oduct s/ wpr equest \ . j ht ml $"
" ^ht t p: / / www\ . exampl e\ . com/ pr oduct s/ quot er equest \ . j ht ml $"
" ^ht t p: / / www\ . exampl e\ . com/ sol ut i ons/ whi t epaper \ . j ht ml $"
" ^ht t p: / / www\ . exampl e\ . com/ cust supt / docr eq\ . j ht ml $"
These regular expressions tell the Application Firewall to check all
HTTP requests to see whether the URL contents are exactly the same
as any of the strings in the regular expression.
For <pr of i l e>, the system administrator substitutes Product
Query, to indicate that this policy is associated with the Product
Query profile.
The system administrator wants to create an expression that detects
requests to the product query web pages. Unfortunately those web pages are
not hosted on a separate subdomain, nor do they follow a predictable
naming convention.
The system administrator wants to be sure that any cross-site scripts except
those on the specified, approved web pages are blocked. So he decides to
list each URL containing an approved product query Web form separately
in the policy. This means that the Scripts policy will detect only the
approved URLs, and will therefore apply the Scripts profile with its
associated relaxations only to the approved URLs.
The actual command that the system administrator types is as follows:
> add appf w pol i cy " Pr oduct Quer y" " REQ. HTTP. HEADER URL ==
^ht t p: / / www\ . exampl e\ . com/ pr oduct s/ wpr equest \ . j ht ml $ | |
REQ. HTTP. HEADER URL == ^ht t p: / / www\ . exampl e\ . com/ pr oduct s/
quot er equest \ . j ht ml $ | | REQ. HTTP. HEADER URL == ^ht t p: / /
www\ . exampl e\ . com/ sol ut i ons/ whi t epaper \ . j ht ml $ | |
REQ. HTTP. HEADER URL == ^ht t p: / / www\ . exampl e\ . com/ cust supt /
docr eq\ . j ht ml " " Pr oduct Quer y"
Note: Although the preceding command wraps onto multiple lines, you
should type it on a single line in the NetScaler command line.
> save ns conf i g
created.
> show appf w pol i cy " Pr oduct Quer y"
The policy is correct, so the system administrator proceeds to bind it
globally.
4. Follow the procedure in Chapter 3, Simple Configuration, in the
procedure To globally bind a policy using the NetScaler command line
on page81 to globally bind the new policy.
The system administrator globally binds the new policy, assigning it a
priority of 2 to ensure that any connections to web pages containing the
specified product query Web forms are processed using the Product Query
policy and profile.
The system administrator has successfully created a policy to protect the product
query Web forms on the company Web site, and globally bound that policy with
the appropriate priority. The Application Firewall is now filtering connections to
these URLs using the new policy and profile.
Managing Learning
The exampl e. comsystem administrator responsible for managing their Citrix
NetScaler appliance just created two specific Application Firewall profiles with
advanced defaults to protect special content on the Example Web sites. Unlike
profiles created with basic defaults, profiles created with advanced defaults use
the learning feature. This feature creates an appropriate set of security check
relaxations for protected Web sites (or learned relaxations), but someone must
review those relaxations and approve them before the Application Firewall can
use them.
This subsection describes how the system administrator can review and
implement learned relaxations.
To review learned relaxations using the configuration utility
1. Log on to the configuration utility using either the Applet client or the Web
Start client.
on page40.
choices in that category, and click Profiles to display the Profiles page.
3. In the profiles list, click the name of the profile you want to review for new
learned rules once, to highlight it.
The system administrator clicks the SQL profile.
dialog box.
5. Click the Learning tab to display it, as shown below.
The Configure Application Firewall Profile Dialog Box, Learning Tab
In the Security Checks list at the top of the tab, the Start URL check is
highlighted by default.
6. Click the Manage Rules button to open the Manage Start URL Learned
Rules dialog box, shown below.
The Manage Start URL Learned Rules Dialog Box, Simple Tab
The Simple tab is displayed by default. It shows a list of literal URLs that
the learning feature has observed users accessing directly.
7. Click the Generalized tab to display it, as shown below.
The Manage Start URL Learned Rules Dialog Box, Generalized Tab
The Generalized tab shows a list of PCRE-format regular expressions for
the same URLs. Normally you need fewer regular expressions than literal
URLs to provide appropriate list of relaxations for the Start URL rule. The
system administrator wants to create as non-restrictive a set of Start URL
relaxations as is consistent with proper Web site security, and prefers a few
regular expressions to many literal start URLs, so he uses the Generalized
tab to review start URL learned rules.
He is happy with the default settings for the #expressions (number of
regular expressions), and leaves that field unchanged. If he were to modify
it, he would click the Generalize button afterward to regenerate the list of
Start URL relaxations.
8. Click the first regular expression on the list once, to highlight it.
9. Review the regular expression, and choose how to dispose of it.
You can accept it with edits by clicking the Edit & Deploy button. If
you do, the Edit Regular Expression dialog box appears with that
regular expression loaded in it. You edit the regular expression, then
click the OK button to save your changes and deploy the modified
learned rule.
You should choose this option when a rule is almost correct, but you
want to modify it to allow for a few additional URLs or to cover a
slightly smaller number of URLs.
You can accept it as is by clicking the Deploy button. If you do, the
learned rule is deployed exactly as it was created by the learning
feature.
You should choose this option when a rule is exactly as you want it.
The system administrator approves of the regular expression as it was
generated by learning, so he clicks the Deploy button.
10. Repeat step9 for each learned rule on the list.
11. Click the Close button to close the Manage Start URL Learned Rules dialog
box, and return to the Configure Application Firewall Profile dialog box.
12. Click the entry for each remaining security check that you are using in this
profile, and repeat step7 through step9 to review learned relaxations for
that check.
The system administrator reviews learned relaxations for the Cookie, Form
Field, and SQL Injection relaxations.
13. Click the Close button to close the Configure Application Firewall Profile
14. Click the entry for each remaining profile that has learning enabled, and
repeat step4 through step13 to review the learned relaxations for this
profile.
The system administrator clicks the J avascript profile, and reviews
recommendations for the Start URL, Cookie, Form Field, and Cross-Site
Scripting checks.
The system administrator reviews learned relaxations once a day for the next two
weeks. At the end of that period, or at whichever point he is confident that the
Application Firewall is properly configured not to block legitimate activity for a
particular security check, he re-enables blocking for that security check.
After he has re-enabled blocking for all security checks, the exampl e. com
system administrator has successfully configured the Application Firewall to
protect the exampl e. comWeb sites.
GLOSSARY
Glossary
This chapter contains a glossary of terms used in the Citrix Application Firewall documentation. These
terms apply to the Application Firewall itself, to the Citrix NetScaler Application Delivery product line,
and to other related subjects.
A
Access Gateway. An appliance built on the Citrix NetScaler Application Accelerator platform that provides secure
access to private networks, such as company LANs, using SSL VPN and IPSEC.
Alarm. An SNMP notification sent to a designated person or server in response to certain system and firewall
events.
Note: In previous versions of the Application Firewall, the term alert notification was used for an
alarm. They mean almost the same thing.
Alert. A system or firewall event that the Application Firewall or underlying NetScaler OS is configured to take
notice of and log. You can configure the Application Firewall to generate an alert when a request or
response violates a security check.
Application Accelerator. An appliance that provides secure remote access and application protection for a small to
medium-sized business. The entry-level appliance in the Citrix NetScaler Application Delivery product
line.
NetScaler appliance. An appliance that provides secure remote access and application protection for larger
businesses. The mid-level and enterprise level appliances in the Citrix NetScaler Application Delivery
product line.
B
Binding. An assigned relationship between a policy and a profile. A policy must be bound to a profile to put that
policy into effect. A profile must be bound to at least one policy to put that profile in to effect.
Bot. A program installed illicitly on a server after security on the server is breached by a hacker or malware.
Most bots grant an outside user substantial or complete control over the server. Servers that are running a
bot are usually used by spammers to provide support for direct sending of spam email, hosting of
spammed Web site content, proxy support to mask the actual origin of spam email or actual location of a
spammed Web site, and DNS support for other compromised servers.
Frequently the only way to secure a server after bot infestation is to reformat its hard disk and reinstall the
operating system from original media. Even then, if the hacker or malware that installed the bot gained
access through a security vulnerability in the operating system or Web server software, the server is
vulnerable to reinfection unless the security problem is fixed.
Botmaster. The individual that controls a server that has had its security breached and is running a bot. This
individual may or may not be the hacker or malware author responsible for breaching the servers security
and installing the bot in the first place.
Breach. An event that occurs when the Application Firewall detects a Stop Word, fails to find a Go Word, or
detects a violation of the SAFE Access, SAFE Commerce, SAFE Content, SAFE Identity, or SAFE Object
rules.
Breach attempt. An event that occurs when the Application Firewall detects and stops a Start URL violation,
Cookie Consistency Check violation, Form Field violation, Operation Access violation, violation of the
Buffer Overflow Detection rules, Input Validation violation, or violation of the SAFE SQL or SAFE XSS
rules.
Buffer overflow. A software security vulnerability in which a memory location used to store data fills up, and
causes the Web server to behave unpredictably. Buffer overflows are behind a number of known security
issues with Web server software.
Buffer Overflow check. A filter that checks for and blocks requests that contain inappropriately long URLs,
cookies, or other data that might be an attempt to cause a buffer overflow. The Application Firewall blocks
these requests.
C
CGI. Common Gateway Interface. A protocol for interfacing scripts and programs with a Web server. CGI
scripts are a common source of security problems with Web sites.
Check. A filter that examines Web server requests or responses for particular types of behavior that might signal
an attack on Web site security, and takes appropriate action.
Child pornography. Pornography that uses or depicts children in unambiguous sexual situations. Local laws define
exactly what constitutes child pornography in a particular jurisdiction. It is illegal in all jurisdictions.
Because child pornographers are aggressively pursued by international law enforcement agencies, Web
sites and other Internet-based distribution of child pornography makes heavy use of compromised Web
servers.
CLI. Command line interface. The character-based interface to the Application Accelerator or NetScaler
appliance. The NetScaler operating system is built on the FreeBSD platform, and the CLI is built upon the
FreeBSD Unix bash shell.
Compromised Web server. A Web server whose security has been breached, usually by a hacker or malware. Most
compromised Web servers run a bot and are controlled by a botmaster. Compromised Web servers may
leak confidential private data to unauthorized persons, contain unauthorized content, provide unauthorized
Internet services, or any combination of these things.
Configuration utility. The web-based graphical user interface (GUI) used to configure the Application Accelerator
and NetScaler appliance.
Glossary
Control interface. The ethernet port used to access the Configuration Utility and configure the Application
Firewall.
Control IP. The IP address of the Application Firewall control interface, used by system administrators to access
the Application Firewall via SSH to perform configuration or management tasks.
Cookie. A piece of data a Web server sends to a web browser, to be stored in RAM memory or on the local
computers hard disk, and sent back to the Web server with every request to that Web application. Web
servers use cookies to track user sessions, identify users who have previously visited the site, store user
information for registered users, and for many other purposes. A hacker can sometimes modify a cookie
and breach security on the Web server.
Cookie Consistency check. The Application Firewall filter that checks incoming cookies to ensure that users have
not modified them.
CP Web site. A Web site that hosts child pornography. Most CP Web sites are hosted on compromised Web
servers.
Credit Card check. A filter that checks Web server responses to ensure that credit card numbers are not sent to
users unless they should be. You define which types of credit card information the Application Firewall
should check for, and tell the Application Firewall whether to x-out any credit card numbers it finds, delete
them from the response, or block the response outright.
Cross-site scripting. A script that bypasses the same origin policy, a security measure that prohibits a script on one
Web site from obtaining properties from or setting properties for any content on a different Web site. Since
the scripts on your Web site can access data and modify content on your Web site, it is unsafe to allow a
non-local script to receive information from or modify the content on your Web site.
Cross-Site Scripting check. A filter that checks scripts for cross-site scripting vulnerabilities, and either renders
them harmless or blocks the response.
CSRF. Cross-site request forgery. A type of Web site attack in which an attacker masquerades as an authenticated
user of the Web site, and exploits that users access to run unauthorized content, often content hosted on
untrusted third-party Web sites.
CSRF form tagging. A security check that tags each Web form served by your protected Web sites with a random
and unpredictable FormID, and verifies that requests containing a Web form match a FormID generated by
the Application Firewall. This prevents an attacker from using a modified Web form to attack your
protected Web server.
D
DDoS. Distributed Denial of Service. Using many different computers, usually compromised servers, to send a
coordinated flood of connection requests to a server in order to overwhelm its capacity and deny other
users access to it. One type of DOS attack.
Deep linking. Accessing a Web site by going directly to a URL that is normally accessible only through a few
layers of navigation. By default, the Application Firewall prevents users from deep linking, requiring that
user connections be to designated start URLs or via normal navigation of the Web site.
Deny URL. A URL on your Web site that no user should ever access directly. For example, most CGI scripts
should never be accessed directly, but only by a web page on your Web site. Attempts to access CGI
scripts and certain other content directly may represent an attempt to breach security on your Web site.
Deny URL check. A filter that checks to see if a URL is on the list of URLs that users should never access directly.
You list these URLs when configuring your Application Firewall. The Application Firewall then checks
incoming requests, and blocks any request that attempts to access a resource on its list of deny URLs.
Dialog box. A small, standalone window in the configuration utility that asks the user a question or prompts the
user to fill in certain information. Most configuration tasks in the configuration utility are performed via
dialog boxes of various types.
DoS. Denial of Service. Opening a large number of connections to any server on a network to try to overwhelm
the servers capacity, causing it to stop accepting connections and denying other users access to it.
E
Error page. The web page to which the Application Firewall redirects a user when the Application Firewall blocks
illegal or suspicious activity. By default, this is the domain home page.
F
False positive. Blocking of a legitimate request or response. False positives are rare with profiles created with
Basic defaults. If you create more specialized profiles using Advanced defaults, you must configure those
profiles carefully. It is highly advisable to disable blocking for those profiles until you have configured
them manually and allowed learning mode to generate an appropriate set of relaxations for the profile.
Field Formats check. A filter that allows you to assign a data type and minimum and maximum lengths to the
fields in the Web forms on your Web site. The Application Firewall then ensures that all data returned in
any of these Web forms matches the data type and length you assigned to that field in that Web form.
Field types. A list of descriptions of the types of data permitted in a field in a Web form, used by the Field Formats
check. The Application Firewall ships with a standard list of field types which are sufficient for most
Application Firewall configurations. You can also add other data types to the list, and you can set a default
data type.
Filter. A set of rules that the Application Firewall uses to check user requests and Web server responses to ensure
that everything is as it should be.
FIPS. Federal Information Processing Standards. A federally-mandated standard for hardware protection of
SSL certificates and keys. The Citrix Access Gateway, Citrix NetScaler Application Accelerator and
Citrix NetScaler appliance all support FIPS management of SSL certificates and keys.
Flow type. The direction of a connection. Incoming connections, or requests, have an REQ flow type; outgoing
connections, or responses, have an RES flow type.
Note: All regular expressions used in Application Firewall policies must have an REQ flow type.
Regular expressions used in other NetScaler operating system policies can have either flow type.
Forceful browsing. Attempting to access URLs directly, without first accessing a normal start URL on the Web site
and navigating to web pages by clicking a hyperlink on another page on the Web site. Forceful browsing
can be innocent; some users prefer to bookmark and access favorite web pages directly. Repeated attempts
to access nonexistent content or content that should not be accessed directly, however, is usually a sign of
an attack on a Web sites security. The Application Firewall blocks forceful browsing attempts using its
Start URL and Deny URL checks.
Glossary
Form Field Consistency check. A filter that checks to ensure that the data a user returns when completing a Web
form in an HTML-based Web site is valid for each field of that Web form. A hacker or malicious program
can sometimes breach Web server security by submitting inappropriate data in a Web form. The
Application Firewall checks for such attempts, and when it detects a request containing a Web form that
has inappropriate data, it blocks the request.
H
HA. High availability. Two Citrix NetScaler Application Accelerators or NetScaler appliancees configured to
operate as a unit, with one appliance actively accepting and processing traffic while the other monitors it.
if the first appliance quits accepting and processing traffic, the second appliance takes over for it and
begins accepting and processing traffic, preventing an outage.
The NetScaler HA feature uses VRRP to provide high availability and fault tolerance.
Hacker. In the Citrix NetScaler documentation, an individual who makes direct, personal attempts to gain access
to a server or network resource illicitly, without the permission of the owner of that server or network
resource. This is as opposed to the author of a virus or trojan program (a malware author), who does not
normally target a specific server or resource.
In the past, a hacker often attempted to break into a server or resource for the sheer joy of meeting the
challenge and succeeding. Todays hackers are more often motivated by a desire to take control of the
resource and use it to make money for themselves.
Hidden field. A field in an HTML form that is hidden from the user. Normally hidden fields are used to retain data
across multiple requests on a Web site, and thus emulate state when using HTTP, a stateless protocol. A
hacker or malicious program can modify the data in a hidden field to breach security on your Web server.
HTML profile. An Application Firewall profile that applies to HTML-based web content. The majority of web
content is HTML-based, and is protected by this type of profile.
HTTP. HyperText Transfer Protocol. The protocol used to send packets between a users browser and a Web
server.
HTTP data. The part of an HTTP request that contains the information that the user typed into a Web form, or the
part of an HTTP response that contains the web content the user requested.
HTTP headers. The part of an HTTP connection that contains information about the Web server or users browser
that is intended to assist the Web server or browser in handling the connection. In other words, the HTTP
headers are the metadata portion of the HTTP request or response.
In a response, the HTTP headers contain information that is not normally displayed in the users web
browser.
HTTP request. An HTTP connection from a user to your Web server, requesting content from your Web server.
HTTP response. An HTTP connection from your Web server to a user, sending information to the user.
HTTP traffic. Any HTTP connection, either from a user to your Web server or from your Web server to a user.
HTTPS. HyperText Transfer Protocol Secure. A protocol for sending HTTP packets securely between a users
browser and a Web server, so that intercepted packets are encrypted and cannot be read. (Also called the
SSL protocol.)
I
Identity theft. The process of obtaining enough private information about a user to allow a criminal to pretend to
be that user. Normally a criminal engages in identity theft so that he can purchase goods or services using
that users credit cards and in that users name. An identity thief often sells this information to other
criminals, as well.
See phishing on page317 for more information on a common method many criminals use to engage in
identity theft.
Integrity checking. The process of verifying through a checksum or other cryptographic algorithm that a packet on
a network has not been modified while being transmitted between the source and the destination.
IPSEC. IP security. A protocol for negotiating encryption and authentication at the IP level. IPSEC allows you to
ensure that all packets between two hosts, regardless of packet type or protocol used to transmit, are
encrypted.
L
LAN. Local area network. The network inside your companys firewall or router, where your companys Web
servers, mail servers, and other protected resources are located.
LAN interface. The ethernet port on the Application Firewall, Application Accelerator or NetScaler appliance that
connects to your protected Web servers.
LAN IP. The IP on the Application Firewall that connects to your protected Web servers.
Layer 1, Layer 2, Layer 3, Layer 4, Layer 5, Layer 6, and Layer 7. See Network layers.
Learning feature. The Application Firewall repetitive activity filter, used to spot typical user behavior when
accessing protected Web sites, and recommend appropriate settings for the request inspection and input
validation filters.
Learning mode. See learning.
License. The contractual agreement between your company and Citrix that specifies which features you will use
on your Citrix Application Firewall, Application Accelerator, or NetScaler appliance.
License key file. A file provided by Citrix that you must upload to your Citrix Application Firewall, Application
Accelerator, or NetScaler appliance to enable it and all licensed features.
Log. One of a collection of text files maintained by your Citrix Application Firewall, Application Accelerator,
or NetScaler appliance that consists of information about various activities and events that occur on it. Log
files usually contain a single line of text per logged event or activity. All appliances in the Citrix NetScaler
Application Delivery product line keep several kinds of logs.
M
Malware. A virus, trojan, or other malicious software intended to breach security on a server or network appliance.
Once security is breached, the malware may steal sensitive private information from the computer, grant
control of the computer to a botmaster, or both.
Glossary
Malware author. The author of a malware program, who may or may not also be the recipient of private
information obtained by the program or controller of computers whose security was breached by the
program.
MIP. Mapped IP. An IP assigned to your Citrix NetScaler Application Accelerator or NetScaler appliance that it
can use to refer to the servers it protects. MIPs are used for many functions in the NetScaler operating
system. You must create one MIP when configuring the NetScaler operating system for the first time, and
normally will create a number of them in the course of configuring various features of the NetScaler
operating system.
N
Negative security model. A security model that relies on detecting known attacks and specific types of suspicious
behavior likely to breach security on a protected server or network.
NetScaler operating system. NetScaler operating system. The FreeBSD-based operating system that runs on all
appliances in the Citrix NetScaler Application Delivery product line.
Network layers. Categories that define the protocols and types of traffic that a network device handles. For
example, a layer 3 device handles IP traffic sent using either the TCP/IP or the UDP protocol. A layer 2
device handles MAC address traffic. The standalone Citrix Application Firewall, the Citrix Access
Gateway, and the Citrix NetScaler Application Accelerator and NetScaler appliance are all layer 3
devices.
Node. A single server, appliance or device within a network.
Node property. An attribute of a node, such as its IP address, hostname or domain.
NSIP. NetScaler IP. The management IP assigned to your Citrix NetScaler Application Accelerator or NetScaler
appliance. You use this IP to connect to the appliance when configuring or managing it.
NTP. Network time protocol. The protocol used to update server clocks across a network.
O
Operation. In web services, a single exchange of information in which a user passes one set of information to a
web service, and in return receives another set of information from the web service. Operations are defined
in the WSDL file for the web service, and the Application Firewall can be configured to allow or deny
access to each operation in a web services WSDL.
Operation part. a single structured bit of information that forms part of a web services operation. The Application
Firewall enforces proper length and format of data a user sends to the protected web service.
Operator. The portion of a NetScaler operating system policy regular expression that specifies exactly what part of
the qualifier a regular expression should examine, and what type of information it should look for. Some
qualifiers are freestanding (such as EXISTS and NOTEXISTS). Some (such as ==, !=, CONTAINS,
NOTCONTAINS, and CONTENTS) require a string (called the value) for comparison.
P
Packet. A packet is the basic unit of data routed between an origin and a destination on a TCP/IP or other packet-
switching network. A packet contains part of a larger message and the destination address. On TCP/IP
networks, packets are often called datagrams.
Packet switching. A process for transmitting a message from one server to another on a network by dividing the
message into smaller units, or packets, before sending them. Each packet is then transmitted individually,
and can follow any available route to its destination rather than the same route any previous or following
packets may have followed. If the destination receives a corrupt packet, it detects the corruption using
integrity checking protocols and signals the origin to retransmit just that packet rather than the entire
message. The destination also signals the origin to retransmit any packets it was expecting and did not
receive.
Once all packets forming a message arrive at the destination and pass integrity checking, they are
recompiled into the original message.
Pharming. Using DNS forgeries or spoofing to redirect requests from a legitimate bank, financial institution, or
ecommerce Web site to a pharming Web site, a Web site controlled by the criminal that did the forgery.
Pharming Web sites normally look identical to the legitimate companys Web site.
Under the mistaken impression that they are accessing the real bank or ecommerce Web site, users then log
on normally and provide any private information that the pharming Web site requests, sending that
information to the pharmer. The information obtained by a pharming Web site normally includes logons
and passwords, and may also include credit card numbers and expiration dates, social security numbers,
and other sensitive private information.
In many cases, a pharming attack will attempt to obtain enough information to steal the users identity. See
identity theft on page314 for more information.
Because the criminal (or pharmer) modified the Internets DNS system to redirect users to the pharming
Web site, the users browser will display the correct URL in the navigation window. DNS is the Internets
address system; it is what tells a web browser that a request to a particular host (such as
www. exampl e. com) should go to one server instead of another. It is therefore extremely difficult for
users to detect pharming attacks.
Pharming is closely related to phishing, a similar type of attack that uses email or instant messages instead
of DNS forgeries to redirect customers to a Web site that collects the same sorts of sensitive private
information. See phishing on page317 for more information.
Glossary
Phishing. Using email or instant messages to deceive users into providing sensitive private informationsuch as
logons and passwords to an online banking or ecommerce Web site, or credit card numbers and expiration
datesunder the belief that the information is being given to their bank or another institution that has the
right to the information.
A phishing attempt normally involves two elements: the phish itself and the phishing Web site. The phish
is a message, usually an email or instant message (IM), that pretends to be from a legitimate bank,
financial institution, or business, and that directs users to provide their private information either via a Web
site link or (much less commonly) by replying to the message itself.
The phishing Web site mimics the Web site of a legitimate bank, financial institution or ecommerce
company, but is owned by the criminal (or phisher) that sent the phish. The web page often looks exactly
like the logon page for the legitimate site, and like the legitimate site requests the users logon and
password. After the user logs on, the phish Web site may prompt him or her to provide credit card numbers
and expiration dates, a social security number, and any other private information the phisher wants to have.
The phish Web site then sends this information to the phisher, who can use it to log on to and empty the
users bank account or charge goods and services to the users credit card.
In many cases, a phishing attack will attempt to obtain enough information to steal the users identity. See
identity theft on page314 for more information.
Phishing is closely related to pharming, a similar type of attack that uses DNS forgeries instead of email or
instant messages to redirect customers to a Web site that collects the same sorts of sensitive private
information. See pharming on page316 for more information.
Policy. A set of parameters created by the system administrator when configuring the Application Firewall that
defines a specific type of web content or particular part of a Web site. The Application Firewall uses
policies to determine which profile to use when filtering a particular request or response.
Port. 1. When referring to hardware, an interface on a server that connects to another server or network
device. There are a number of port types, the most common including:
- The RJ 45 port, normally used to connect one of the servers ethernet interfaces to the network.
These ports are normally included on all computers, workstations and servers alike. The servers
in the Citrix NetScaler Application Delivery product line have between four and nine RJ 45
ports that connect to ethernet interfaces of various capacities and transmission speeds.
- The RS-232C (serial) port, normally used to connect a laptop computer or other workstation to
the server when configuring the server. All of the servers in the Citrix NetScaler Application
Delivery product line have one RS-232C port.
- The USB (universal serial bus) port, normally used to connect auxiliary devices such as
scanners, printers, external hard disk drives or other storage devices, cameras, and similar
equipment to the server. These ports are included on almost all workstation or laptop
computers, but less commonly on servers. None of the servers in the Citrix NetScaler Appli-
cation Delivery product line has a USB port.
- The Centronics parallel port and its enhanced cousins, normally used to connect the computer
to a printer or scanner. These ports are frequently included on workstations, but less commonly
on laptop computers and rarely on servers because this type of port has largely been replaced by
the USB port. None of the servers in the Citrix NetScaler Application Delivery product line has
a parallel port.
- The RJ 11 port, normally used to connect the computer to an external modem, or to connect an
internal modem directly to a telephone jack. These ports are normally included on workstation
or laptop computers, not on servers. None of the servers in the Citrix NetScaler Application
Delivery product line has an RJ 11 port.
2. When referring to software, a number representing a virtual input location where a server program
listens for connections. For example, a Web server usually listens for HTTP connections on port 80,
and for HTTPS connections on port 443. An SMTP server usually listens for connections on port 25.
Other server programs listen on other port numbers.
Positive security model. A security model that relies, not upon detecting attempts to violate security, but upon
recognizing valid or legitimate behavior and blocking everything else. The Application Firewall uses a
positive security model to protect web content.
Profile. 1. A collection of security settings that a system administrator creates when configuring the
Application Firewall, and that the Application Firewall uses thereafter to protect a specific type of web
content. A profile tells the Application Firewall which checks to perform and how to respond when a
request or response violates a particular check.
2. The list that your Application Firewall maintains of typical requests to your Web site and responses
from that Web site. A Web sites profile consists of the list of exceptions to (or relaxations of) the normal
filtering rules that you enter manually, and the recommendations generated by learning mode that you
accept and implement.
Protocol. 1. A specific type of communication between a server and client or two servers on the Internet.
HTTP is the protocol used by Web sites for non-encrypted communications, and HTTPS is the protocol
used for encrypted communications.
2. The portion of a NetScaler operating system policy regular expression that determines the protocol
to which the regular expression applies.
Q
Qualifier. The portion of a NetScaler operating system policy regular expression that determines the feature of the
protocol to which the regular expression applies.
R
Regular expression. A protocol, or language, for matching patterns of characters, numbers, and symbols. The
Application Firewall supports PCRE (PERL compatible regular expressions) to specify URLs, cookies,
and form fields when manually entering relaxations, or when learning generates recommendations for
these filters.
Request. A connection from a user to a Web server. Requests are inbound connections to your Web servers.
Response. A connection from a Web server to a user in response to a request sent by that user. Responses are
outbound connections from your Web servers.
Rule. A single pattern or standard used by the Application Firewall to determine whether to block traffic or not.
See also check and filter.
S
Safe Object check. A filter that allows users to define a particular type of information in Web server responses that
the Application Firewall is to protect, such as social security numbers, drivers license numbers, or
customer IDs. You can define the information to be protected precisely using a PCRE regular expression,
and can tell the Application Firewall what to do when it detects a violation of a safe object rule: block the
response, remove the blocked information from the response, or x-out the blocked information in the
response.
Glossary
Same origin policy. A web scripting security policy that prohibits a script on one Web site from obtaining
properties from or setting properties for any content from a different Web site. In other words, it requires
that the script and any content it interacts with have the same origin. The Web server determines the origin
of a script and another piece of web content by checking the domain name, protocol and port for each. The
script and the other piece of web content have the same origin if and only if the protocol, host, and port are
all identical.
Security model. The underlying reasoning used to protect the security of a server or any other computer or
network appliance.
Session. A single set of connections between a Web site and a specific user, including both requests from the user
to the Web site and responses by the Web site to the user.
Session profile. The list an Application Firewall maintains of an individual users requests to a protected Web site
and responses from that Web site to that user during a single session. It uses the session profile in a number
of tests to determine whether a request or response is valid.
Session timeout. Period of inactivity after which the Application Firewall stops tracking a users session. The user
must then establish a new session with your Web site by accessing a start URL before continuing his or her
activity.
SMTP. Simple Mail Transport Protocol. The protocol commonly used to send email to other users on TCP/IP
networks.
SMTP server. A server that supports the SMTP protocol, and that the Application Firewall can use to send email
alert notifications.
SNMP. Simple Network Management Protocol. A protocol to allow system administrators to view and change
certain network properties from a remote location.
SOAP. Simple Object Access Protocol. An XML-based syntax for exchanging messages. Using SOAP, web
services on different platforms and using normally-incompatible technologies can exchange information.
SOAP fault filtering. A security check that filters responses to detect and remove XML SOAP faults. SOAP faults
can contain sensitive information about your protected Web sites that could help an attacker.
Spoofing. Any of several techniques that cause a packet to appear to have originated at one IP when in fact it
originated at another IP. Spoofing is most commonly used in DDOS attacks and pharming attacks.
SQL. Structured Query Language. A standard language for requesting information from a database. Many
databases in wide use on Web sites support SQL.
SQL injection. Submission of unauthorized SQL commands to a back-end SQL server using a Web form on your
Web site. SQL injection is usually an attempt to break your Web sites security and obtain sensitive private
information.
SQL Injection check. A filter that checks Web form data for injected SQL special characters and keywords. If the
Application Firewall detects SQL code in a Web form submitted to your Web site, it either renders the
SQL code harmless by transforming any special characters, or blocks the response.
SSH. Secure shell. A program that allows a user to establish an encrypted, secure connection to a server through
port 22. An SSH session can be used to establish an interactive shell on the Application Firewall, allowing
an administrator to perform administrative tasks.
SSL. Secure sockets layer. A protocol for sending HTTP packets securely between a users browser and a Web
server. (Also called the HTTPS protocol.)
SSL VPN. Secure sockets layer virtual private network. A virtual private network that operates through an SSL
web link on port 443.
Start URL. A URL that users normally access directly, without navigating to it by clicking a hyperlink on another
web page on your Web site. For example, your Web sites home page is a start URL. You should also
consider any subsidiary home page, such as a customer support web page or my account web page, a
start URL and configure your Application Firewall accordingly.
Start URL check. A filter that lists your Web sites start URLs, the URLs that users can access to start a session on
your Web site. If you enable the URL closure option for your Web site, then you must list only those web
pages that users will access directly as start URLs. If you do not enable the URL closure option, you must
add the URLs of all web pages on your Web site that users will access to the Start URL list.
State. Whether a globally bound policy is enabled and in use, or disabled and not in use.
T
Threshold. The absolute number of times a behavior occurs on your Web site, and the percentage of total Web site
connections that exhibit this behavior, before the learning feature learns a particular pattern or rule. You set
the thresholds for each rule that applies to each profile you create, so you can configure different
thresholds for different rules.
U
UDDI. Universal Description, Discovery, and Integration. An XML-based address book, or registry, that allows
businesses throughout the world to create a listing for themselves so that customers and partners can locate
them, and XML-based ecommerce web services can exchange structured information with them. In other
words, an XML-based global address book for the Internet.
URL. Uniform Resource Locator. A standard address for an HTML page or other resource on the Web. URLs
are formatted like this:
pr ot ocol : / / host name[ : por t ] / pat h[ / r esour ce. f i l ename]
A web URL normally uses the HTTP or HTTPS protocol, as shown here:
ht t p: / / host name[ : por t ] / pat h[ / r esour ce. f i l ename]
ht t ps: / / host name[ : por t ] / pat h[ / r esour ce. f i l ename]
URL closure. A setting in the Start URL filter that tells the Application Firewall to allow users to access any
resource on your Web site by clicking a hyperlink on any web page on the Web site. If you enable URL
closure, then you only have to list your Web sites home page and any other pages users will access
directly in the Start URL list. If you do not enable URL closure, you must list all URLs on your Web site
that users will access in the Start URL list.
User. 1. An account on the Application Accelerator or NetScaler appliance server that allows a system
administrator to log on and configure the appliance.
2. Anyone who connects to your Web site.
V
Value. The portion of a NetScaler operating system policy regular expression that the operator uses to test a
request to determine whether it matches the policy or not.
VRRP. Virtual Router Redundancy Protocol. A protocol for managing a backup server that causes the backup
server to automatically take over for any designated master server that fails.
Glossary
W
WAN. Wide area network. The network outside your companys firewall or router, from which users access
your companys resources.
WAN interface. The ethernet port that connects your Application Firewall to the network from which users access
your Web sites.
WAN IP. The IP address at which the Application Firewall receives incoming HTTP and HTTPS requests from
users.
Web server. 1. The hardware platform that runs Web server software and hosts web content.
Note: A single such Web server frequently hosts a number of Web sites, and may also run multiple
copies (or instances) of the Web server software.
2. The software package that runs on a server and answers HTTP requests and responses. The most
common Web server software packages are the open source Apache HTTP Server package and
commercial Microsoft Internet Information Server (IIS), but there are many others in use as well.
3. A single instance of the Web server software that runs in server memory answers HTTP or HTTPS
requests for a specific IP/port combination.
Web service. Web-based content that employs one or more of three technologiesSOAP, WSDL and UDDIto
offer structured content to users via the web.
Web Services Definition Language. See WSDL.
Web services profile. An Application Firewall profile that protects a web service.
Web site. A collection of content hosted on a single Web server and accessed via a single hostname. For example,
all content accessed through www. exampl e. comis part of the Web site at www. exampl e. com.
Web site defacement. Vandalism of a Web site through illicit modification of the Web sites content and
appearance, that is, online graffiti.
Wizard. A set of tasks presented in a dialog box that shows each task to the user on a separate screen and prompts
the user to perform that task before proceeding to the next screen and next task. Wizards are used
throughout the configuration utility.
WSDL. Web Services Definition Language. An XML-based language for defining web services and explaining
how to access them.
WSDL file. A file containing a description of a particular web service and explaining how it is accessed.
X
XML. Extensible markup language. A text markup language that supports interchange of structured data, a
subset of SGML. The Application Firewall protects a subset of XML-based web content called web
services.
INDEX
Index
A
Access Gateway
definition 309
FIPS support 312
IPSEC 309
LAN 309
SSL VPN 309
Action URL setting
Cross-Site Scripting check 224
Field Formats check 213
action. See also profile.
action. See profile.
adaptive learning
Cookie Consistency check 276, 282, 293, 297
Cross-Site Scripting check 294, 297
Form Field Consistency check 276, 282, 294, 297
learned relaxations 303
preventing false positives 312
profile 318
regular expression 318
reviewing learned relaxations 303
reviewing Start URL learned relaxations 304
SQL Injection check 277
Start URL check 274
use case 303307
adaptive learning. See also learned relaxations.
Add... button
policies 7273
advanced defaults
about 281, 290, 296
avoiding false positives 312
Cookie Consistency check Block setting 187
Cookie Consistency check Learn setting 188
creating a profile 290
CSRF FormTagging check Block setting 217
FormField Consistency check Block setting 203
FormField Consistency check Learn settings 203
HTML Cross-Site Scripting check 221
HTML SQL Injection check Block setting 228
HTML SQL Injection check Learn setting 228
protecting SQL database 268
WS-I check Learn setting 250
XML Attachment check Learn setting 248
XML DoS check Learn setting 239
alarm
definition 309
alarm. See also alert.
alert
definition 309
alert notification. See alarm.
alert. See also alarm.
Application Accelerator
definition 309
FIPS support 312
application delivery
Application Accelerator 309
about 12
blocking hackers 2
configuration utility 11
configuring security checks 272
filtering 6, 8
filtering flowchart 7
hacker 1
hardware platforms 1938
installation 8, 17
installing 1938
layer 2 network bridge 6
layer 3 network device 6
network 9
network layers 9
network location 8
overview 3, 67
platform 8
policies 7177, 135136
policy flow type 312
positive security model 5
use cases 267307
user 320
application firewall
enabling 65
updating licenses 65
Application Switch
definition 309
FIPS support 312
as_fid
formtagging caution 206
attack
against SQL database 268
buffer overflow 3
check 5
compromised web server 3
cookie security 3
cookie tampering 268
cross-site scripting 45, 290
filtering 6
filtering flowchart 7
forceful browsing 175
hacker 2
identity theft 2
known web attacks 5
malware author 2
SQL injection 45, 268
types 2
types of 3
unknown web attacks 5
web formsecurity 4
B
basic defaults
Cookie Consistency check Block setting 187
Cookie Consistency check Learn setting 187
CSRF FormTagging check Block setting 217
FormField Consistency check Block setting 203
FormField Consistency check Learn setting 203
HTML Cross-Site Scripting check Learning setting
221
HTML SQL Injection check Block setting 228
HTML SQL Injection check Learn setting 228
rarity of false positives 312
WS-I check Learn setting 250
XML Attachment check Learn setting 247
XML DoS check Learn setting 238
binding
CLI 81, 150
configuration utility 78, 149
definition 309
globally binding policies 78, 149
binding. See also global binding.
Block setting
Buffer Overflow check 191
Cookie Consistency check 187
Credit Card check 194
CSRF Form Tagging check 217
Deny URL check 182
Form Field Consistency check 203
HTML SQL Injection check 228
Start URL check 176
WS-I check 250
XML Attachment check 247
XML Cross-Site Scripting check 242
XML DoSt check 238
XML Format check 236
XML SOAP Fault Filtering check 256
XML SQL Injection check 244
XML Validation check 253
blocking
Form Field Consistency check 276, 282, 294, 297
SQL Injection check 277, 283
Start URL check 273274, 282
blog. See Web 2.0 profile.
Index 325
bot
definition 310
botmaster
definition 310
botmaster. See also bot, hacker, malware.
bot. See also hacker, malware, botmaster.
breach
definition 310
breach attempt
definition 310
buffer overflow
about 3
definition 310
forceful browsing 4
Buffer Overflow Check
Block setting 191
Log setting 192
Statistics setting 192
Buffer Overflow check
about 190193
definition 310
Learn setting unavailable 192
maximumcookie length 192
maximumheader length 193
maximumURL length 192
buffer overflow check
about 101
CLI parameter and values 118
buffer overflow max cookie length
buffer overflow max header length
buffer overflow max URL length
built-in profiles
about 84
C
canonicalize HTML response
Centronics. See port.
CGI
definition 310
deny URL 311
protecting SQL databases 268
check
about 5
definition 310
known web attacks 5
profile 318
unknown web attacks 5
Check complete URLs for cross-site scripting
about 109, 223
check relaxations
names as literal strings 111
names as regular expressions 111
regex editor 112
checks
about profiles 83133
configuring 272
checksum. See integrity checking.
check. See also filter, rule.
child pornography
compromised web server 3, 310
CP web site 311
definition 310
child pornography. See also CP web site.
Citrix NetScaler 10010. See hardware, 10010.
Citrix NetScaler MPX 15000. See hardware, 15000.
CLI
about 1011
adding a confidential field 169
adding field types 173
associating policy and profile 289
bash 10
client IP header 164
configuring Cookie Consistency check 282, 297
configuring Credit Card check 283
configuring Cross-Site Scripting check 297
configuring FormField Consistency check 282,
297
configuring security checks 114121, 126
configuring SQL Injection check 282
configuring Start URL check 282
creating a policy 7677, 144289
creating a profile 66, 281
default profile 165
definition 310
deleting a policy 149
disabling Start URL check 296
error page 298
example of add appfw policy command 302
import size limit 165
maximumsession lifetime 163
modifying a policy 149
NSIP 76
save ns config 100
saving policy configuration 289
saving profile 298
scripted content policy 301302
scripted content profile 296298
security check parameters and values 116
set appfw settings -clientIPLoggingHeader 164
set appfw settings -defaultprofile 165
set appfw settings -importsizelimit 165
set appfw settings -sessionlifetime 163
set appfw settings -undefaction 164
show appfw profile 100
SQL database profile 281284
SSH 76, 99, 158, 372373, 375
transformunsafe HTML 298
undefined profile 164
verifying policy configuration 289
verifying profile 298
CLI command
add appfw confidField 169
add appfw field type 173
add appfw policy 76, 145, 149, 288289, 301
add appfw profile 66, 99, 281, 296
bind appfw global 81, 150
enable ns feature 63
import appfw htmlerrorpage 158159
rmappfw htmlerrorpage 159
rmappfw policy 77, 148149
rmappfw profile 284
rm appfw wsdl 160
rmappfw xmlerrorpage 159
rm appfw xmlschema 159
save ns config 66, 77, 82, 148, 151, 159, 283, 289,
298, 302
set appfw confidField 169
set appfw field type 173
set appfw policy 149
set appfw profile 66, 100, 282283, 296298, 372
show appfw field type 173
show appfw htmlerrorpage 159
show appfw policy 77, 148, 289, 302
show appfw profile 283, 298
show appfw wsdl 159160
show appfw xmlerrorpage 159
show appfw xmlschema 159
CLI. See also SSH.
Close button
confidential fields 169
policies 76
command line interface. See CLI.
Comments setting
common security checks
buffer overflow security check 101
cookie consistency security check 101
credit card security check 102
deny URL security check 101
safe object security check 102
start URL security check 101
compromised web server
about 3
bot 310
botmaster 310
child pornography 310
CP web site 311
definition 310
hacker 310
malware 310
compromised web site. See compromised web server.
confidential fields
about 166
adding 166
adding at the CLI 169
Close button 169
comments 169
Create button 169
identity theft 166
logging 166
Remove button 169
removing 169
types 166
UTF-8 character encoding in URL 168, 170
Index 327
configuration
about 267
about simple configuration 65
advanced defaults 290
advanced features 82
CLI 10
creating a policy 136148
Credit Card check 278, 283
Credit Card check X-Out option 283
default profile 164
defaults 70
Deny URL check 182, 255
disabling Start URL check 292, 297
disabling URL closure 292, 297
error page 296, 298
filtering specific URLs 299, 301
FormField Consistency check 202, 276, 282, 293,
297
globally binding policies 78151
GUI 104
html error page 159
list of security checks 101103
logging header name 163
named expression 139
policies 135136
policy 317
policy name 76, 137, 145, 169, 173, 285
policy names 73
profile 5
profile names 69, 99, 372
profiles 83
protected credit card types 283
saving policy 289
security checks 101, 272
session cookie name 162
session timeout 162
settings 122
simple 82
SQL comment handling 245
SQL comments handling 109, 230
SQL Injection check 276, 282
SQL protection 82
Start URL check 272, 282, 291
transformcross-site scripts 295
transformSQL special characters 277, 283
transform unsafe HTML 298
updating licenses 65
URL closure 282
user 320
user interface 9
verifying policy 289
about 1115
Add Expression dialog box 139
adding a profile 290
Application Firewall Policies page 72
Application Firewall Profiles page 68
associating policy and profile 285
Bind/Unbind Firewall Policy(s) to Global dialog
box 79
create profile dialog box 69
definition 310
deleting a policy 149
dialog box 312
Expression Editor 139
logo bar 12
navigation tree 12
page data area 13
page title bar 13
policy ??287
screen areas 12
scripted content profile 290296
Setup Wizard 1314
SQL database profile 269281
Systemmenu 51
system overview 12
Upgrade Wizard 1314
upgrade wizard 15
wizards 13, 321
configuration. See also configuration utility.
control interface
definition 311
control IP
definition 311
cookie
about cookie tampering 268
about security of 3
definition 311
cookie check
about 101
Cookie check. See Cookie Consistency check.
Cookie Consistency Check
Block setting 187
Learn setting 187
Log setting 188
Cookie Consistency check
about 186190, 272
about cookie tampering 268
blocking 276, 282, 293, 297
configuration 292
configuring 275, 282, 297
definition 311
Enabled check box 189
entering a cookie expression 189, 218219
logon relaxation 189
modifying ??190
PCRE expressions 189
profile 268284
shopping cart itemrelaxation 190
UTF-8 character encoding 190
cookie consistency check
cookie security. See Cookie Consistency check.
CP web site
about 3
definition 311
CP web site. See also bot, hacker, malware.
CP. See child pornography.
Create button
policies 76
Credit Card check
about 193195, 272
Block setting 194
blocking 283
Close button 195
configuring 278, 283
definition 311
Learning setting not available 194
list of protected credit cards 280
Log setting 194
maximumcredit cards allowed setting 195
parameters 195
protected credit cards 283
X-Out 278, 283
X-Out setting 194
credit card check
about 102
credit card max allowed
credit card protected types
Index 329
credit card x-out
Cross Site Request Forgery attack. See CSRF.
cross site scripting. See cross-site scripting, Cross-Site
Scripting check.
cross-site scripting
about 45, 220, 241
attacks 290
definition 311
description of 290
same origin policy 45, 311
same origin rule 220, 241
transforming 295
what is it? 220, 241
Cross-Site Scripting check
about 290
blocking 294, 297
definition 311
same origin rule 298
URL setting 224
Cross-Site Scripting check. For HTML requests, see
HTML Cross-Site Scripting check. For XML
requests, see XML Cross-Site Scripting check.
Cross-Site Scripting rule
transformunsafe HTML 298
cross-site scripting. See also Cross-Site Scripting check,
same origin policy.
cryptographic algorithm
integrity checking 314
CSRF
CSRF formtagging 102
definition 311
CSRF formtagging
about 102
definition 311
CSRF FormTagging Check
Block setting 217
CSRF Form Tagging check
about 215
Log setting 217
customer ID. See safe object.
D
datagram. See packet.
DDoS
definition 311
deep linking
definition 311
defacement. See web site defacement.
default charset
settings 122
default field format max length
default field format min length
default field format type
default field type
settings 122
default profile
about 164
defaults
about 70
definition
Access Gateway 309
alarm 309
alert 309
Application Accelerator 309
Application Switch 309
binding 309
bot 310
botmaster 310
breach 310
breach attempt 310
buffer overflow 310
CGI 310
check 310
CLI 310
control interface 311
control IP 311
cookie 311
CP web site 311
cross-site scripting 311
CSRF 311
CSRF formtagging 311
DDoS 311
deep linking 311
deny URL 311
Deny URL check 311
dialog box 312
DoS 312
error page 312
false positive 312
field types 312
filter 312
FIPS 312
flow type 312
HA 313
hacker 313
hidden field 313
HTML profile 313
HTTP 313
HTTP data 313
HTTP headers 313
HTTP request 313
HTTP response 313
HTTP traffic 313
identity theft 314
integrity checking 314
IPSEC 314
LAN interface 314
LAN IP 314
learning feature 314
license 314
license key file 314
log 314
malware 314
malware author 315
MIP 315
negative security model 315
NetScaler OS 315
network layers 315
node 315
node property 315
NSIP 315
NTP 315
operation 315
operation part 315
operator 315
packet 316
packet switching 316
pharming 316
phishing 317
policy 317
port 317
profile 318
protocol 318
qualifier 318
request 318
response 318
rule 318
Safe Object check 318
same origin policy 319
security model 319
session 319
session timeout 319
SMTP 319
SMTP server 319
SNMP 319
SOAP 319
SOAP fault filtering 319
spoofing 319
SQL 319
SQL injection 319
Index 331
SQL Injection check 319
SSH 319
SSL 319
SSL VPN 319
start URL 319
Start URL check 320
state 320
threshold 320
UDDI 320
URL 320
URL closure 320
user 320
value 320
VRRP 320
WAN 314, 321
WAN interface 321
WAN IP 321
web server 321
web service 321
web services profile 321
web site 321
web site defacement 321
wizard 321
WSDL 321
WSDL file 321
XML 321
denial of service. See DOS.
deny URL
adding 184
CGI scripts 311
definition 311
Deny URL Check
Block setting 182
Log setting 183
Deny URL check
about 182186
configuring 182
definition 311
entering a Deny URL 184
Modify Rule... button 182
modifying a Deny URL ??186
UTF-8 character encoding in URL 185
deny URL check
about 101
deny URLs
examples of 185
deny URL/modifying 184
dialog box
definition 312
distributed denial of service. See DDOS.
DoS
definition 312
drivers license number. See safe object.
E
Enable check box
Safe Object check 196
Start URL check 179
enable form tagging
Enabled check box
Deny URL check 184
Enforce URL closure
about 178
engine settings
about 161
default profile 164
logging header name 163
removing a confidential field 169
session timeout 162
tracking users Application Firewall session 162
error page
definition 312
error URL
settings 122
exclude file uploads from checks
expression
creating 139142
example 147
flow type 74, 139, 145
header name 142, 147
matching all requests 76
matching policy expressions 138
operator 75, 141, 146
policy 77
protocol 74, 140, 146
qualifier 74, 140, 146
value 141, 147
extensible markup language. See XML.
F
false positive
about 268
Cookie Consistency check, preventing 276, 282,
293
Credit Card check, preventing 283
Cross-Site Scripting check, preventing 294
definition 312
Form Field Consistency check, preventing 276,
282, 294
preventing via adaptive learning 312
SQL Injection check, preventing 277
Start URL check, preventing 274, 282
transformSQL special characters, preventing 277
field format check
Field Formats check
about 208215
Action URL setting 213
advanced defaults 210
basic defaults 210
Block setting 210
Comments setting 213
comparison with FormField Consistency check
209
configuring 209
definition 312
Field Name setting 212
field types 171, 312
Format setting 213
HTML profiles only 208
Learn setting 210211
Log setting 211
Maximum length setting 213
Minimum Length setting 213
Type setting 213
"Is Field Name Regular Expression" check box 212
field formats check
about 102
Field Name setting
field type
field types
adding 172173
alphanum 171
any 171
default 171
definition 312
integer 171
nohtml 171
priority 172, 174
warning about the any field type 171
filter
definition 312
filtering
about 6, 8
blocking 6
flowchart 7
session profile 6
the filtering process 8
filter. See also check, rule.
FIPS
definition 312
Index 333
flow type
about 74, 139, 145
Application Firewall requirements 312
definition 312
REQ 312
requests 312
RES 312
responses 312
forceful browsing
about 4, 175
buffer overflow 4
definition 312
Deny URL check 4, 312
start URL 4
formfield
formfield check
about 102
Form Field Consistency check
about 201208
as_fid caution 206
Block setting 203
blocking 276, 282, 294, 297
comparison with Field Formats check 209
configuring 202, 276, 282, 293, 297
definition 313
entering a field name 205
Learn setting 203
Log setting 204
Modify FormField Consistency Check dialog box,
General tab 203
Modify Rule... button 202
when to use Field Formats check instead 202
formfield consistency check
formsecurity. See Form Field Consistency check.
formstructural security. See FormField Consistency
check.
formtagging
as_fid 206
Format setting, Field Formats check 213
FormID
G
global binding
about 78151
CLI 8182, 150151
configuration utility 7880, 149
priorities 78, 149
state 80, 150
global configuration
engine settings 161
field types 171
GUI
Add Expression dialog box, HEADER qualifier 75
adding field types 172
GUI. See configuration utility.
H
HA
definition 313
hacked web server. See compromised web server.
hacker
Application Firewall 1
bot 310
definition 313
filtering 2
identity theft 2
legal consequences 3
hacker. See also malware.
hardware
10010 2628
12000 3038
7000 2021
9010 2224
platforms 1938
header
header name
about 76, 142, 147
URL 76
hidden field
definition 313
hidden field. See also formfield consistency checks.
high availability. See HA.
HTML Cross-Site Scripting check
about 219226
advanced defaults and learning 221
basic defaults and learning 221
Block setting 221
Check complete URLs for cross-site scripting 109,
223
Comments setting 224
Is Field Name Regular Expression check box 224
Learn setting 221
Log setting 222
Transformcross-site scripts check box 222
UTF-8 URL examples 226
HTML cross-site scripting check. See HTML XSS
check.
HTML error object
html error page
name 159
source 159
HTML profile
about 84
definition 313
HTML profiles
HTML profile. See also profile.
HTML security checks
CSRF formtagging 102, 215
field formats security check 102
formfield consistency security check 102
HTML cross-site scripting security check 102
HTML SQL injection security check 102
HTML SQL injection
about 226
HTML SQL Injection check
about 226
Block setting 228
Is Field Name Regular Expression check box 232
Learn setting 228
Log setting 228
Parameters area 230
Restrict checks to fields containing SQL special
characters 109, 230
SQL Comments Handling setting 109, 230
TransformSQL special characters 229
HTML SQL injection check
about 102
HTML SQL injection only check SQL
HTML SQL injection parse comments
HTML SQL injection transform special characters
HTML XSS check
about 102
HTML XSS check complete URL
HTML XSS transform unsafe HTML
HTTP
definition 313
HTTP data
definition 313
HTTP headers
definition 313
HTTP request
definition 313
HTTP request. See also request.
HTTP request/response cycle. See HTTP request, HTTP
response.
HTTP response
definition 313
HTTP response. See also response.
HTTP traffic
definition 313
fltering 8
routing 8
HTTP traffic. See also HTTP request, HTTP response.
Index 335
I
identity theft
about 3
and web site attacks 2
defintion 314
hacker 2
malware author 2
identity theft. See also phish.
import size limit
about 165
imports
installation
about 1719
Application Firewall 8, 17
installation mode
about 18
one-armmode 18
two-arm mode 18
integrity checking
definition 314
packet 314
IPSEC
Access Gateway 309
definition 314
Is Field Name Regular Expression check box
about 224, 232
J
javascript
same origin rule 220, 241, 290
use case 299302
K
known web attack
about 5
L
LAN
Access Gateway 309
definition 314
LAN interface
definition 314
LAN IP
definition 314
layer 1. See network layers.
layer 2 network bridge
layer 3 network device
layer. See network layers.
Learn setting
Start URL check 177
unavailable with XML Cross-Site Scripting check
243
unavailable with XML Format check 237
unavailable with XML SQL Injection check 245
unavailable with XML Validation check 253
WS-I check 250
XML DoS check 238
learned relaxations
about 303
deploy 307
edit & deploy 306
generalized 305
simple 305
where to review 303
learning
definition 314
generalized learned relaxations 305
learning visualizer 133
not available for Buffer Overflow check 192
not available for CSRF FormTagging check 217
not available for Deny URL check 183
not available for XML SOAP Fault Filtering check
256
profile 5
simple learned relaxations 305
learning engine
learning mode. See learning feature.
learning visualizer
about 132
license
definition 314
license key file
definition 314
license key file. See also license.
licenses
updating 65
license. See also license key file.
log
definition 314
Log setting
Buffer Overflowcheck 192
Deny URL check 183
Start URL check 177
WS-I check 251
XML DoS check 239
logging header name
about 163
logo bar
about 12
logs
M
malware
about 1
bot 310
definition 314
legal consequences 3
malware author
definition 315
identity theft 2
malware author. See also malware, botmaster.
malware. See also hacker.
mapped IP. See MIP.
maximumcredit cards allowed setting
about 195
maximumsession lifetime
about 163
MIP
definition 315
Modify button
Modify Rule... button
Deny URL check 182
N
named expression. See expression, NetScaler expression.
navigation tree
about 12
negative security model
definition 315
negative security model. See also security model.
NetScaler IP. See NSIP.
NetScaler operating system. See NetScaler OS.
NetScaler OS
about 17
definition 315
operator and policy 315
priorities 8081, 150
protocol and policy 318
qualifier and policy 318
value and policy 320
NetScaler platform
network features 9
network
Application Firewall location 8
layers 315
node 315
node attribute 315
network layers
definition 315
network time protocol. See NTP.
node
definition 315
node property
definition 315
NSIP
CLI 76
definition 315
Index 337
NTP
definition 315
O
one-armmode, about 18
online graffiti. See web site defacement.
operation
definition 315
operation part
definition 315
operation part. See also web service.
operation. See also web service.
operator
about 75, 141, 146
CONTAINS 315
CONTENTS 315
definition 315
EXISTS 315
NOTCONTAINS 315
NOTEXISTS 315
policy 315
value 315, 320
!= 315
== 315
P
packet
definition 316
packet switching
definition 316
page data area
about 13
page title bar
about 13
parallel. See port.
parameters
Payment Card Industry Data Security Standard. See PCI
DSS.
PCI DSS
about the PCI DSS report 257263
about the PCI DSS standard 263266
description section 259
Detailed PCI DSS Criteria Information 259
Executive Summary section 259
Firewall License and Feature Status section 259
QSA 257
report sections 259
security audit 257
PCRE
about field types 171
CGI relaxation 181
CGI-BIN relaxation 181
Cookie Consistency check ??190
cookie expression examples 189
cookie expression with UTF-8 encoding 190
cookie name expression 189
Cross-Site Scripting check examples ??225
Deny URL check ??186
Deny URL examples 185
entering UTF-8 characters 213
Field Formats check Action URL setting 213
Field Formats check expression with UTF-8
encoding 214
Field Formats check Field Name setting 212
Form Field Consistency check expression with
UTF-8 encoding 207
Form Field Consistency examples 206
GIF relaxation 181
home page 180
HTML Cross-Site Scripting check examples 224
225
HTML Cross-Site Scripting check expression with
UTF-8 encoding 225
HTML Cross-Site Scripting examples 225
HTML page relaxation 180
HTML SQL Injection check Field Name setting
232
HTML SQL Injection examples 233
image content relaxation 181
JPG relaxation 181
Microsoft Office documents relaxation 181
PDF relaxation 181
PERL relaxation 181
PNG relaxation 181
policy expressions 73
SQL Injection check expression with UTF-8
encoding 233
SQL Injection check UTF-8 URL examples 234
Start URL check ??181
Start URL examples 180181
URL expression with UTF-8 encoding 168, 170,
180, 185, 207, 215
warning against careless use 181, 186, 190
warning not to use carelessly 214
PCRE expression
Cookie Consistency check 189, 218219
safe object 197
PCRE. See regular expression.
PERL-compatible regular expressions. See PCRE.
PERL. See CGI, SQL, scripting.
pharming
compromised web site 3
definition 316
pharming. See also phishing.
phisher. See phishing.
phishing
compromised web site 3
definition 317
phishing web site. See phishing.
phishing. See also pharming.
phish. See phishing.
policies
about 71
Action 73
Add... button 7273
associating with profile 73
Close button 76
Create Application Firewall Policy dialog box 73
Create button 76
creating and configuring 7177
flow type 74
global binding 7882
header name 76
operator 75
Policy Name 73
protocol 74
qualifier 74
requests 74
responses 74
Value 75
policy
about 135136
about generic 77
about specific 77
about state 80, 150
action 299
associating with profile 77, 137, 148, 285, 289, 299
binding 309
comparison between Application Firewall and other
135
creating 136148
creating an expression 139142
definition 317
deleting 149
evaluation order 78, 149
example of add appfw policy CLI command 302
example of regular expression 289
expression 77, 285
expression example 147
filtering specific URLs 299, 301
flow type 139, 145, 285, 300
global binding ??151
header 286
header name 142, 147
matching expressions 138
matching requests to a specific host 288
modify 149
name 76, 137, 145, 169, 173, 285, 299
operator 141, 146, 286, 315
profile 71, 136, 317
protecting an SQL database 284289
protecting scripted content 299302
protocol 140, 146, 285, 300, 318
qualifier 140, 146, 286, 318
regular expression 288, 299
requests 139
responses 139
rule 135
saving configuration 289
value 141, 147, 286, 320
verifying configuration 289
port
Centronics 317
definition 317
hardware 317
parallel 317
RJ11 317
RJ45 317
RS232C 317
software 317
USB 317
positive security model
about 5
definition 318
profile 5
positive security model. See also security model.
post body limit
Index 339
priority
about 78, 8081, 149150
profile
about 83
advanced defaults 268, 281, 290, 296
associating with policy 73, 77, 137, 148, 285, 289,
299
avoiding false positives 312
binding 309
check 318
Checks tab 8893
common security checks 100
configuring Cookie Consistency check 275, 282,
292, 297
configuring Credit Card check 278, 283
configuring Cross-Site Scripting check 294, 297
configuring FormField Consistency check 276,
282, 293, 297
configuring SQL Injection check 276
configuring Start URL check 272, 282, 291
configuring with advanced defaults 271281
confirming settings 100
creating 85
creating at CLI 281
Credit Card check X-Out option 283
Credit Card check, X-Out option 278
defaults 70
definition 318
disabling Start URL check 292, 297
disabling URL closure 292, 297
error page 296, 298
header 300
HTML 84
HTML security checks 100
learned relaxations 303
learning feature 5
name 69, 99, 372
operator 300
policy 71, 136, 317
protected credit card types 283
protected web site 5
protecting scripted content 290298
protecting SQL database 268
qualifier 300
relaxation 318
request 318
response 318
saving at CLI 298
set of actions 136
Settings tab 93
SQL Injection check, configuring 282
transform unsafe HTML 298
types 84
URL closure 282
value 300
verifying 283
verifying at CLI 298
Web 2.0 84
XML 84
XML security checks 100
profiles
built-in profiles 84
default profile 164
user-created profiles 84
profile. See also session profile.
protocol
about 74, 140, 146
definition 318
HTTP 74, 140
policy 318
qualifier 318
Q
QSA
about 257
PCI DSS 257
qualifier
about 74, 140, 146
definition 318
header 74
policy 318
protocol 318
R
regex editor
about 112113
regex tokens
about 111
regular expression
about NetScaler policy expressions 135
definition 318
definition of PCRE format 318
example 289
flow type 285, 300
header 300
names in check relaxations 111
operator 286, 300, 315
policy 145, 285, 288, 299
protocol 285, 300, 318
qualifier 286, 300, 318
safe object 318
value 286, 300
regular expression editor. See regex editor.
regular expressions
regex editor 112113
regex tokens 111
warning against careless use 181, 186, 190
regular expressions. See also regex.
relaxation
profile 318
Start URL check 180
Remove button
Remove setting
XML SOAP Fault Filtering check 107, 256
reports
PCI DSS 257
request
about 74, 139
definition 318
filtering 312
flow type 312
handling 7
header name 76
policy 317
profile 318
requests
matching all 148
matching requests to a specific host 288
response
about 74, 139
definition 318
filtering 312
flow type 312
handling 8
policy 317
profile 318
characters
about 109, 230, 245
reverse proxy
layer 3 network device 6
RJ11. See port.
RJ45. See port.
RS232C. See port.
RSS feed. See Web 2.0 profile.
rule
definition 318
expression 135
rule. See also check, filter.
Index 341
S
safe object
Safe Object check
about 196199
actions 197
definition 318
entering a safe object expression 197
Safe Object name 196
what is it? 196
safe object check
about 102
Safe Object name. See Safe Object check.
same origin policy
about 45
definition 319
same origin policy. See also cross-site scripting.
same origin rule
about 220, 241, 290
scripting
secure shell. See SSH.
security
PCI DSS 257
security audit
PCI DSS 257
security breach attempt. See breach attempt.
security breach. See breach.
security checks
list of common security checks 101102
list of HTML security checks 102
list of XML security checks 103, 130
parameter table 116
security model
definition 319
security model. See also negative security model and
positive security model.
session
definition 319
session cookie
about 162
session cookie name
setting at CLI 162
setting at the GUI 162
session profile
filtering 6
session timeout
about 162
definition 319
session timeout. See also session.
session. See also session profile.
settings
error page 296
Setup Wizard
about 1314
SGML. See XML.
shopping cart. See SQL database, use case.
simple mail transfer protocol. See SMTP.
SMTP
definition 319
SMTP server
definition 319
SNMP
definition 319
SOAP
definition 319
web service 321
XML 319
SOAP fault filtering
definition 319
social security number. See safe object.
spoofing
definition 319
spoofing. See also pharming.
SQL
definition 319
SQL injection 45
transformSQL special characters 283
use case 267289
SQL comments
settings 109, 230, 245
SQL Comments Handling setting
about 109, 230
ANSI 230, 246
ANSI/Nested 231, 246
Check all Comments 231, 246
Nested 231, 246
SQL injection
about 45, 268
definition 319
policy 268289
profile 269284
SQL Injection check
about ??234, 272
blocking 277, 283
definition 319
SQL Injection check. For HTML profiles, see HTML
SQL Injection check. For XML profiles, see XML
SQL keyword. See SQL, SQL injection.
SQL special characters. See SQL, SQL injection.
SSH
CLI 76, 99, 158, 372373, 375
definition 319
SSH. See also CLI.
SSL
definition 319
SSL VPN
Access Gateway 309
definition 319
start URL
definition 319
forceful browsing 4
Start URL Check
Block setting 176
Learn setting 177
Log setting 177
Start URL check
about 175181
blocking 273, 282
CGI relaxation 181
configuration 291
definition 320
disabling 292, 297
entering a Start URL 180
forceful browsing 175, 312
home page relaxation 180
HTML page relaxation 180
image content relaxation 181
Microsoft Office documents relaxation 181
modifying a Start URL ??181
PDF relaxation 181
PERL relaxation 181
URL closure 282
URL closure setting 178
Validate Referer Header 178
start URL check
about 101
Start URL check. See also URL closure.
Start URL expression
CGI-BIN relaxation 181
state
about 80, 150
definition 320
Statistics setting
Deny URL check 183
Start URL check 177
WS-I check 251
XML DoS check 239
Index 343
strip comments
settings 122
T
threshold
definition 320
threshold. See also adaptive learning.
Transform cross-site scripts
about 222
Transform SQL special characters
about 229
transformation
HTML and XML SQL injection check 107
HTML and XML XSS checks 107
trojan. See malware.
two-arm mode, about 18
U
UDDI
definition 320
web service 321
XML 320
undefaction
undefined profile
about 164
universal serial bus. See port.
unknown web attack
about 5
Upgrade Wizard
about 1314
upgrade wizard
about 15
URL
definition 320
HTTP header 76
URL closure
about 107108
definition 320
disabling 292, 297
URL closure. See also start URL.
URL setting. See Action URL setting.
USB. See port.
use case
adaptive learning 303
Javascript 290302
SQL database 267289
SQL database profile ??284
SQL injection 268
Start URL check 272
use HTML error object
user
configuration 320
definition 320
web site 320
user interface
about 9
CLI 9
user-created profiles
about 84
user. See also system administrator.
UTF-8
Field Formats check expression 214
Form Field Consistency check expression 207
HTML Cross-Site Scripting check examples 226
HTML Cross-Site Scripting check expression 225
PCRE expression example 168, 170, 180, 185,
190, 207, 215
SQL Injection check examples 234
SQL Injection check expression 233
V
Validate Referer Header
about 178
Value
about 75
value
about 141, 147
definition 320
operator 315, 320
policy 320
vandalism. See defacement.
virtual router redundancy protocol. See VRRP, HA.
virus. See malware.
VRRP
definition 320
VRRP. See also HA.
W
WAN
definition 321
WAN interface
definition 321
WAN IP
definition 321
Web 2.0 profile
about 84
web form
about security of 4
cross-site scripting 290
javascript 289
web form integrity. See Form Field Consistency check.
web formsecurity. See Form Field Consistency check,
web forms
field types 171
web server
Apache 321
blocking hackers 2
definition 321
hardware 321
hosting multiple web sites 321
instance 321
malware 2
Microsoft IIS 321
multiple instances of 321
protection of 2
request 318
response 318
software 321
web service
definition 321
XML profile 84
web services definition language. See WSDL.
web services profile
definition 321
web services profile. See also profile.
web site
blocking hackers 2
definition 321
filtering 6
hostname 321
malware 2
policy 317
profile 5
protection of 2
simple configuration 82
SQL 319
SQL configuration 82
user 320
web server 321
web site defacement
about 3
definition 321
wizard
about 13
definition 321
WSDL
definition 321
web service 321
XML 321
WSDL file
definition 321
WS-I Check
Block setting 250
WS-I check
about 249252
Learn setting 250
Log setting 251
X
XDoS security check. See also XML denial-of-service
security check.
XML
definition 321
SOAP 319
UDDI 320
WSDL 321
XML profile 84
XML application
filtering 6
XML Attachment Check
Block setting 247
Index 345
XML Attachment check
about 246249
Learn setting 247
Log setting 248
XML attachment check
about 103
XML Cross-Site Scripting Check
Block setting 242
XML Cross-Site Scripting check
Learn setting not available 243
Log setting 243
XML cross-site scripting check. See XML XSS check.
XML denial-of-service security check
about 103
XML DoS Check
Block setting 238
XML DoS check
Learn setting 238
Log setting 239
XML error object
XML Format Check
Block setting 236
XML Format check
about 103
Log setting 237
XML format check
XML profile
about 84
XML security checks
WS-I security check 103
XML attachment security check 103
XML cross-site scripting security check 103
XML denial-of-service security check 103
XML format security check 103
XML message validation security check 103
XML SOAP fault filtering security check 103
XML SQL injection security check 103
XML SOAP Fault Filtering Check
Block setting 256
Log setting 256
Remove setting 107, 256
XML SOAP Fault Filtering check
about 255256
configuring 255
Modify button 255
XML SQL Comments Handling setting
about 245
XML SQL Injection Check
Block setting 244
XML SQL Injection check
Log setting 245
Parameters area 245
characters 245
SQL Comments Handling setting 245
XML SQL injection check
about 103
XML SQL injection only check fields with SQL
XML SQL injection parse comments
XML Validation Check
Block setting 253
XML Validation check
about 252255
Log setting 253
XML validation check
XML WS-I check
XML XSS check
about 103
X-Out setting
about 194
XSS. See cross-site scripting.
APPENDIX A
PCRE Character Encoding Format
This appendix describes how to enter non-ASCII charactersincluding those
found in the English, Chinese, J apanese, Korean, and Turkish languagesinto
your Application Firewall configuration.
Representing UTF-8 Characters
The NetScaler operating system supports direct entry of characters in the
printable ASCII character set onlycharacters with hexadecimal codes between
HEX 20 (ASCII 32) and HEX 7E (ASCII 127). To include a character with a code
outside that range in your Application Firewall configuration using either the
Configuration Utility or the NetScaler command line, you must enter its UTF-8
hexadecimal code as a PCRE regular expression.
A number of character types require encoding using a PCRE regular expression if
you include them in your Application Firewall configuration as a URL, form field
name, or Safe Object expression. These include:
Upper-ASCII characters. Characters with encodings from HEX 7F
(ASCII 128) to HEX FF (ASCII 255). Depending on the character map
used, these encodings can refer to control codes, ASCII characters with
accents or other modifications, non-Latin alphabet characters, and symbols
not included in the basic ASCII set. These characters can appear in URLs,
form field names, and Safe Object expressions.
Double-Byte characters. Characters with encodings that use two 8-byte
words. Double-byte characters are used primarily for representing Chinese,
J apanese, and Korean text in electronic format. These characters can appear
in URLs, form field names, and Safe Object expressions.
ASCII control characters. Non-printable characters used to send com-
mands to a printer. All ASCII characters with hexadecimal codes less than
HEX 20 (ASCII 32) fall into this category. These characters should never
appear in a URL or form field name, however, and would rarely if ever
appear in a Safe Object expression.
The NetScaler appliance does not support the entire UTF-8 character set, but only
the characters found in the following eight encodings:
English US (ISO-8859-1). Although the label reads, English US, the
Application Firewall supports all characters in the ISO-8859-1 character
set, also called the Latin-1 character set. This character set fully represents
most modern western European languages, and represents all but a few
uncommon characters in the rest.
Chinese Traditional (Big5). The Application Firewall supports all charac-
ters in the BIG5 character set, which includes all of the Traditional Chinese
characters (ideographs) commonly used in modern Chinese as spoken and
written in Hong Kong, Macau, Taiwan, and by many people of Chinese eth-
nic heritage who live outside of mainland China.
Chinese Simplified (GB2312). The Application Firewall supports all char-
acters in the GB2312 character set, which includes all of the Simplified
Chinese characters (ideographs) commonly used in modern Chinese as spo-
ken and written in mainland China.
Japanese (SJIS). The Application Firewall supports all characters in the
Shift-J IS (SJ IS) character set, which includes most characters (ideographs)
commonly used in modern J apanese.
Japanese (EUC-JP). The Application Firewall supports all characters in
the EUC-J P character set, which includes all characters (ideographs) com-
monly used in modern J apanese.
Korean (EUC-KR). The Application Firewall supports all characters in the
EUC-KR character set, which includes all characters (ideographs) com-
monly used in modern Korean.
Turkish (ISO-8859-9). The Application Firewall supports all characters in
the ISO-8859-9 character set, which includes all letters used in modern
Turkish.
Unicode (UTF-8). The Application Firewall supports certain additional
characters in the UTF-8 character set, including those used in modern Rus-
sian.
When configuring the Application Firewall, you enter all non-ASCII characters
as PCRE-format regular expressions using the hexadecimal code assigned to that
character in the UTF-8 specification. Symbols and characters within the normal
ASCII character set have a single two-digit hexadecimal code assigned to them in
the UTF-8 character set, the same single two-digit code assigned to them in the
ASCII character set. For example, the exclamation point (!) is assigned UTF-8
code 21. Symbols and characters from another supported character set have a
paired set of hexadecimal codes assigned to them. For example, the letter a with
an acute accent () is assigned UTF-8 code C3 A1.
Appendix A 349
The syntax you use to represent these UTF-8 codes in the Application Firewall
configuration is \xNN for ASCII characters; \xNN\xNN for non-ASCII
characters used in English, Russian, and Turkish; and \xNN\xNN\xNN for
characters used in Chinese, J apanese, and Korean. For example, if you want to
represent a ! in an Application Firewall regular expression as a UTF-8 character,
you would type \x21. If you want to include an , you would type \xC3\xA1.
Note: Normally you will not need to represent ASCII characters in UTF-8
format, but when those characters might confuse a web browser or an underlying
operating system, you can use the characters UTF-8 representation to avoid this
confusion. For example, if a URL contains a space, you might want to encode the
space as \x20 to avoid confusing certain browsers and Web server software.
Below are examples of URLs, form field names, and Safe Object expressions that
contain non-ASCII characters that must be entered as PCRE-format regular
expressions to be included in the Application Firewall configuration. Each
example shows the actual URL, field name, or expression string first, followed by
a PCRE-format regular expression for it.
A URL containing extended ASCII characters.
Actual URL: http://www.josnuez.com
Encoded URL: ^http://www[.]jos\xC3\xA9nu\xC3\xB1ez[.]com$
Another URL containing extended ASCII characters.
Actual URL: http://www.example.de/trmso.html
Encoded URL:
^http://www[.]example[.]com/tr\xC3\xB6mso[.]html$
A form field name containing extended ASCII characters.
Actual field name: nome_do_usurio
Encoded field name: ^nome_do_usu\xC3\xA1rio$
A Safe Object expression containing extended ASCII characters.
Unencoded expression: [A-Z]{3,6}[1-9][0-9]{6,6}
Encoded expression: [A-Z]{3,6}\xC2\xA5[1-9][0-9]{6,6}
UTF-8 Character Encodings Reference
You can find a number of tables that include the entire Unicode character set and
matching UTF-8 encodings on the Internet. A useful Web site that contains this
information is located at the following URL:
ht t p: / / www. ut f 8- char t abl e. de/ uni code- ut f 8- t abl e. pl
For the characters in this table to display correctly, you must have an appropriate
Unicode font installed on your computer. If you do not, the visual display of the
character may be in error. Even if you do not have an appropriate font installed to
display a character, however, the description and the UTF-8 and UTF-16 codes on
this set of web pages will be correct.
Note: Citrix does not host or specifically recommend this web page. This
URLis provided here to assist users.
APPENDIX B
PCI DSS Standard
This appendix contains the text of the PCI DSS 1.2 specification, in English.
Payment Card Industry (PCI)
Data Security Standard
Requirements and Security Assessment Procedures
Version 1.2
October 2008
Appendix B 353
PCI DSS Requirements and Security Assessment Procedures, v1.2 October 2008
Copyright 2008 PCI Security Standards Council LLC Page 1
Table of Contents
Introduction and PCI Data Security Standard Overview ....................................................................................................................3
PCI DSS Applicability Information .......................................................................................................................................................4
Scope of Assessment for Compliance with PCI DSS Requirements ................................................................................................5
Network Segmentation.............................................................................................................................................................................................. 5
Wireless .................................................................................................................................................................................................................... 6
Third Parties/Outsourcing......................................................................................................................................................................................... 6
Sampling of Business Facilities and System Components....................................................................................................................................... 6
Compensating Controls ............................................................................................................................................................................................ 7
Instructions and Content for Report on Compliance .........................................................................................................................8
Report Content and Format ...................................................................................................................................................................................... 8
Revalidation of Open Items..................................................................................................................................................................................... 11
PCI DSS Compliance Completion Steps............................................................................................................................................................. 11
Detailed PCI DSS Requirements and Security Assessment Procedures .......................................................................................12
Build and Maintain a Secure Network....................................................................................................................................................................... 13
Requirement 1: Install and maintain a firewall configuration to protect cardholder data........................................................................................ 13
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters ....................................................... 17
Protect Cardholder Data............................................................................................................................................................................................ 20
Requirement 3: Protect stored cardholder data...................................................................................................................................................... 20
Requirement 4: Encrypt transmission of cardholder data across open, public networks....................................................................................... 26
Maintain a Vulnerability Management Program........................................................................................................................................................ 28
Requirement 5: Use and regularly update anti-virus software or programs........................................................................................................... 28
Requirement 6: Develop and maintain secure systems and applications.............................................................................................................. 29
Implement Strong Access Control Measures............................................................................................................................................................ 35
Requirement 7: Restrict access to cardholder data by business need to know..................................................................................................... 35
Requirement 8: Assign a unique ID to each person with computer access. .......................................................................................................... 37
Requirement 9: Restrict physical access to cardholder data.................................................................................................................................. 42
Regularly Monitor and Test Networks ....................................................................................................................................................................... 46
Requirement 10: Track and monitor all access to network resources and cardholder data. ................................................................................. 46
Requirement 11: Regularly test security systems and processes. ......................................................................................................................... 49
Maintain an Information Security Policy.................................................................................................................................................................... 52
Requirement 12: Maintain a policy that addresses information security for employees and contractors............................................................... 52
Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers .........................................................................59
Appendix B: Compensating Controls .............................................................................................................................................61
Appendix C: Compensating Controls Worksheet ..........................................................................................................................62
Appendix D: Attestation of Compliance Merchants ...................................................................................................................64
Appendix E: Attestation of Compliance Service Providers .......................................................................................................68
Appendix F: PCI DSS Reviews Scoping and Selecting Samples.............................................................................................72
Appendix B 355
Introduction and PCI Data Security Standard Overview
The Payment Card Industry (PCI) Data Security Standard (DSS) was developed to encourage and enhance cardholder data security and facilitate
the broad adoption of consistent data security measures globally. This document, PCI Data Security Standard Requirements and Security
Assessment Procedures, uses as its foundation the 12 PCI DSS requirements, and combines themwith corresponding testing procedures into a
security assessment tool. It is designed for use by assessors conducting onsite reviews for merchants and service providers who must validate
compliance with the PCI DSS. Below is a high-level overview of the 12 PCI DSS requirements. The next several pages provide background about
preparing for, conducting, and reporting a PCI DSS assessment, whereas the detailed PCI DSS requirements begin on page 13.
PCI DSS Applicability Information
The following table illustrates commonly used elements of cardholder and sensitive authentication data; whether storage of each data element is
permitted or prohibited; and whether each data element must be protected. This table is not exhaustive, but is presented to illustrate the different
types of requirements that apply to each data element.
Data Element
Storage
Permitted
Protection
Required PCI DSS Req. 3.4
Primary Account Number
(PAN)
Yes Yes Yes
Cardholder Name
1
Yes Yes
1
No
Service Code
1
Yes Yes
1
No
Cardholder Data
Expiration Date
1
Yes Yes
1
No
Full Magnetic Stripe Data
3
No N/A N/A
CAV2/CVC2/CVV2/CID No N/A N/A
Sensitive
Authentication
Data
2
PIN/PIN Block No N/A N/A

1
These data elements must be protected if stored in conjunction with the PAN. This protection should be per PCI DSS requirements for general protection of
the cardholder data environment. Additionally, other legislation (for example, related to consumer personal data protection, privacy, identity theft, or data
security) may require specific protection of this data, or proper disclosure of a company's practices if consumer-related personal data is being collected during
the course of business. PCI DSS, however, does not apply if PANs are not stored, processed, or transmitted.
2
Sensitive authentication data must not be stored after authorization (even if encrypted).
3
Full track data from the magnetic stripe, magnetic stripe image on the chip, or elsewhere.
Appendix B 357
Scope of Assessment for Compliance with PCI DSS Requirements
The PCI DSS security requirements apply to all systemcomponents. Systemcomponentsare defined as any network component, server, or
application that is included in or connected to the cardholder data environment. The cardholder data environment is that part of the network that
possesses cardholder data or sensitive authentication data. Network components include but are not limited to firewalls, switches, routers,
wireless access points, network appliances, and other security appliances. Server types include, but are not limited to the following: web,
application, database, authentication, mail, proxy, network time protocol (NTP), and domain name server (DNS). Applications include all
purchased and customapplications, including internal and external (Internet) applications.
Network Segmentation
Network segmentation of, or isolating (segmenting), the cardholder data environment fromthe remainder of the corporate network is not a PCI
DSS requirement. However, it is recommended as a method that may reduce:
The scope of the PCI DSS assessment
The cost of the PCI DSS assessment
The cost and difficulty of implementing and maintaining PCI DSS controls
The risk to an organization (reduced by consolidating cardholder data into fewer, more controlled locations)
Without adequate network segmentation (sometimes called a "flat network") the entire network is in scope of the PCI DSS assessment. Network
segmentation can be achieved through internal network firewalls, routers with strong access control lists or other technology that restricts access
to a particular segment of a network.
An important prerequisite to reduce the scope of the cardholder data environment is a clear understanding of business needs and processes
related to the storage, processing or transmission of cardholder data. Restricting cardholder data to as few locations as possible by elimination of
unnecessary data, and consolidation of necessary data, may require reengineering of long-standing business practices.
Documenting cardholder data flows via a dataflow diagramhelps fully understand all cardholder data flows and ensures that any network
segmentation is effective at isolating the cardholder data environment.
If network segmentation is in place and will be used to reduce the scope of the PCI DSS assessment, the assessor must verify that the
segmentation is adequate to reduce the scope of the assessment. At a high level, adequate network segmentation isolates systems that store,
process, or transmit cardholder data fromthose that do not. However, the adequacy of a specific implementation of network segmentation is highly
variable and dependent upon such things as a given network's configuration, the technologies deployed, and other controls that may be
implemented.
Appendix F: PCI DSS Reviews Scoping and Selecting Samples provides more information on the effect of scoping during a PCI DSS
assessment.
Wireless
If wireless technology is used to store, process, or transmit cardholder data (for example, point-of-sale transactions, line-busting), or if a wireless
local area network (LAN) is connected to or part of the cardholder data environment (for example, not clearly separated by a firewall), the PCI DSS
requirements and testing procedures for wireless environments apply and must be performed as well (for example, Requirements 1.2.3, 2.1.1, and
4.1.1). Before wireless technology is implemented, a company should carefully evaluate the need for the technology against the risk. Consider
deploying wireless technology only for non-sensitive data transmission.
Third Parties/Outsourcing
For service providers required to undergo an annual onsite assessment, compliance validation must be performed on all systemcomponents
where cardholder data is stored, processed, or transmitted.
A service provider or merchant may use a third-party provider to store, process, or transmit cardholder data on their behalf, or to manage
components such as routers, firewalls, databases, physical security, and/or servers. If so, there may be an impact on the security of the cardholder
data environment.
For those entities that outsource storage, processing, or transmission of cardholder data to third-party service providers, the Report on
Compliance (ROC) must document the role of each service provider, clearly identifying which requirements apply to the reviewed entity and which
apply to the service provider. There are two options for third-party service providers to validate compliance: 1) They can undergo a PCI DSS
assessment on their own and provide evidence to their customers to demonstrate their compliance, or 2) If they do not undergo their own PCI
DSS assessment, they will need to have their services reviewed during the course of each of their customer's PCI DSS assessments. See the
bullet beginning For managed service provider (MSP) reviewsunder Part 3 in the Instructions and Content for Report on Compliancesection
below for more information.
Additionally, merchants and service providers must manage and monitor the PCI DSS compliance of all associated third parties with access to
cardholder data. Refer to Requirement 12.8 in this document for details.
Sampling of Business Facilities and System Components
The assessor may select representative samples of business facilities and systemcomponents in order to assess PCI DSS requirements. These
samples must include both business facilities and systemcomponents, must be a representative selection of all of the types and locations of
business facilities as well as types of systemcomponents, and must be sufficiently large to provide the assessor with assurance that controls are
implemented as expected.
Examples of business facilities include corporate offices, stores, franchise merchants, and business facilities in different locations. Sampling
should include systemcomponents for each business facility. For example, for each business facility, include a variety of operating systems,
functions, and applications that are applicable to the area under review. Within each business facility, the reviewer could choose Sun servers
running Apache WWW, Windows servers running Oracle, mainframe systems running legacy card processing applications, data transfer servers
running HP-UX, and Linux Servers running MYSQL. If all applications run froma single OS (for example, Windows or Sun), then the sample
Appendix B 359
should still include a variety of applications (for example, database servers, web servers, data transfer servers). (See Appendix F: PCI DSS
Reviews Scoping and Sampling.)
When selecting samples of business facilities and systemcomponents, assessors should consider the following:
If there are standard, required PCI DSS processes in place that each facility must follow, the sample can be smaller than is necessary if
there are no standard processes, to provide reasonable assurance that each facility is configured per the standard process.
If there is more than one type of standard process in place (for example, for different types of systemcomponents or facilities), then the
sample must be large enough to include systemcomponents or facilities secured with each type of process.
If there are no standard PCI DSS processes in place and each facility is responsible for their processes, then sample size must be larger
to be assured that each facility understands and implements PCI DSS requirements appropriately.
Please also refer to Appendix F: PCI DSS Reviews Scoping and Selecting Samples.
Compensating Controls
On an annual basis, any compensating controls must be documented, reviewed and validated by the assessor and included with the Report on
Compliance submission, per Appendix B: Compensating Controls and Appendix C: Compensating Controls Worksheet.
For each and every compensating control, the Compensating Controls Worksheet (Appendix C) must be completed. Additionally, compensating
control results should be documented in the ROC in the corresponding PCI DSS requirement section.
See the above-mentioned Appendices B and C for more details on compensating controls.
Instructions and Content for Report on Compliance
This document must be used as the template for creating the Report on Compliance. The assessed entity should follow each payment brands
respective reporting requirements to ensure each payment brand acknowledges the entitys compliance status. Contact each payment brand to
determine reporting requirements and instructions.
Report Content and Format
Follow these instructions for report content and format when completing a Report on Compliance:
1. Executive Summary
Include the following:
Describe the entitys payment card business, including:
- Their business role with payment cards, which is how and why they store, process, and/or transmit cardholder data
Note: This is not intended to be a cut-and-paste from the entitys web site, but should be a tailored description that shows the
assessor understands payment and the entitys role.
- How they process payment (directly, indirectly, etc.)
- What types of payment channels they serve, such as card-not-present, (for example, mail-order-telephone-order (MOTO), e-
Commerce), or card-present
- Any entities that they connect to for payment transmission or processing, including processor relationships
A high-level network diagram(either obtained fromthe entity or created by assessor) of the entitys networking topography that
includes:
- Connections into and out of the network
- Critical components within the cardholder data environment, including POS devices, systems, databases, and web servers, as
applicable
- Other necessary payment components, as applicable
Appendix B 361
2. Description of Scope of Work and Approach Taken
Describe the scope, per the Scope of Assessment section of this document, including the following:
Environment on which assessment focused (for example, clients Internet access points, internal corporate network, processing
connections)
If network segmentation is in place and was used to reduce scope of the PCI DSS review, briefly explain that segmentation and
how assessor validated the effectiveness of the segmentation
Document and justify sampling used for both entities (stores, facilities, etc.) and systemcomponents selected, including:
- Total population
- Number sampled
- Rationale for sample selected
- Why sample size is sufficient to allow assessor to place reasonable reliance that controls reviewed represent controls in place
throughout entity
- Describe any locations or environments that store, process, or transmit cardholder data that were EXCLUDED fromthe scope
of the review, and why these locations/environments were excluded
List any wholly-owned entities that require compliance with the PCI DSS, and whether they are reviewed separately or as part of
this assessment
List any International entities that require compliance with the PCI DSS, and whether they are reviewed separately or as part of this
assessment
List any wireless LANs and/or wireless payment applications (for example, POS terminals) that are connected to, or could impact
the security of the cardholder data environment, and describe security in place for these wireless environments
The version of the PCI DSS Requirements and Security Assessment Procedures document used to conduct the assessment
Timeframe of assessment
3. Details about Reviewed Environment
Include the following details in this section:
A diagramof each piece of the communication link, including LAN, WAN or Internet
Description of cardholder data environment, for example:
- Document transmission and processing of cardholder data, including authorization, capture, settlement, chargeback and other
flows as applicable
- List of files and tables that store cardholder data, supported by an inventory created (or obtained fromthe client) and retained
by the assessor in the work papers. This inventory should include, for each cardholder data store (file, table, etc.):
List all of the elements of stored cardholder data
How data is secured
How access to data stores are logged
List of hardware and critical software in use in the cardholder data environment, along with description of function/use for each
List of service providers and other entities with which the company shares cardholder data (Note: these entities are subject to PCI
DSS Requirement 12.8)
List of third-party payment application products and versions numbers in use, including whether each payment application has
been validated according to PA-DSS. Even if a payment application has been PA-DSS validated, the assessor still needs to verify
that the application has been implemented in a PCI DSS compliant manner and environment, and according to the payment
application vendors PA-DSS Implementation Guide. Note: It is not a PCI DSS requirement to use PA-DSS validated applications.
Please consult with each payment brand individually to understand their PA-DSS compliance requirements.
List of individuals interviewed and their titles
List of documentation reviewed
For managed service provider (MSP) reviews, the assessor must clearly identify which requirements in this document apply to the
MSP (and are included in the review), and which are not included in the review and are the responsibility of the MSPs customers
to include in their reviews. Include information about which of the MSPs IP addresses are scanned as part of the MSPs quarterly
vulnerability scans, and which IP addresses are the responsibility of the MSPs customers to include in their own quarterly scans.
4. Contact Information and Report Date
Include:
Contact information for merchant or service provider and assessor
Date of report
5. Quarterly Scan Results
Summarize the four most recent quarterly scan results in the Executive Summary as well as in comments at Requirement 11.2
Note: It is not required that four passing quarterly scans must be completed for initial PCI DSS compliance if the assessor verifies
1) the most recent scan result was a passing scan, 2) the entity has documented policies and procedures requiring quarterly
scanning going forward, and 3) any vulnerabilities noted in the initial scan have been corrected as shown in a re-scan. For
subsequent years after the initial PCI DSS review, four passing quarterly scans must have occurred.
Appendix B 363
Scan must cover all externally accessible (Internet-facing) IP addresses in existence at the entity, in accordance with the PCI DSS
Security Scanning Procedures
6. Findings and Observations
Summarize in the Executive Summary any findings that may not fit into the standard Report on Compliance template format.
All assessors must use the Detailed PCI DSS Requirements and Security Assessment Procedures template to provide detailed
report descriptions and findings on each requirement and sub-requirement.
The assessor must review and document any compensating controls considered to conclude that a control is in place.
See Compensating Controls section above and Appendices B and C for more details on compensating controls.
Revalidation of Open Items
A controls in placereport is required to verify compliance. The report is considered non-compliant if it contains open items,or items that will be
finished at a future date. The merchant/service provider must address these items before validation is completed. After these items are addressed
by the merchant/service provider, the assessor will then reassess to validate that the remediation occurred and that all requirements are satisfied.
After revalidation, the assessor will issue a new Report on Compliance, verifying that the cardholder data environment is fully compliant, and
submit it consistent with instructions (see below).
PCI DSS Compliance Completion Steps
1. Complete the Report on Compliance (ROC) according to the section above entitled Instructions and Content for Report on Compliance.
2. Ensure passing vulnerability scan(s) have been completed by a PCI SSC Approved Scanning Vendor (ASV), and obtain evidence of
passing scan(s) fromthe ASV.
3. Complete the Attestation of Compliance, for either Service Providers or Merchants as applicable, in its entirety. See Appendices D and E
for Attestations of Compliance.
4. Submit the ROC, evidence of a passing scan, and the Attestation of Compliance, along with any other requested documentation, to the
acquirer (for merchants) or to the payment brand or other requester (for service providers).
Detailed PCI DSS Requirements and Security Assessment Procedures
For the PCI DSS Requirements and Security Assessment Procedures, the following defines the table column headings:
PCI DSS Requirements This column defines the Data Security Standard and lists requirements to achieve PCI DSS compliance;
compliance will be validated against these requirements.
Testing Procedures This column shows processes to be followed by the assessor to validate that PCI DSS requirements are in place
In Place This column must be used by the assessor to provide a brief description of controls found in place, including those controls
found to be in place as a result of compensating controls. (Note: that this column must not be used for items that are not yet in place or for
open items to be completed at a future date.)
Not in Place This column must be used by the assessor to provide a brief description controls that are not in place. Note that a non-
compliant report should not be submitted to a payment brand or acquirer unless specifically requested. See Appendix D and Appendix E:
Attestations of Compliance for further instructions on non-compliant reports.
Target Date/Comments For those controls Not In Placethe assessor may include a target date that the merchant or service provider
expects to have controls In Place. Any additional notes or comments may be included here as well.
Appendix B 365
Build and Maintain a Secure Network
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Firewalls are computer devices that control computer traffic allowed between a companys network (internal) and untrusted networks (external), as
well as traffic into and out of more sensitive areas within a companys internal trusted network. The cardholder data environment is an example of
a more sensitive area within the trusted network of a company.
A firewall examines all network traffic and blocks those transmissions that do not meet the specified security criteria.
All systems must be protected fromunauthorized access fromuntrusted networks, whether entering the systemvia the Internet as e-commerce,
employees Internet access through desktop browsers, employees e-mail access, dedicated connection such as business to business
connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and fromuntrusted networks can provide
unprotected pathways into key systems. Firewalls are a key protection mechanismfor any computer network.
PCI DSS Requirements Testing Procedures In Place
Not in
Place
Target Date/
Comments
1.1 Establish firewall and router
configuration standards that include the
following:
1.1 Obtain and inspect the firewall and router configuration
standards and other documentation specified belowto verify
that standards are complete. Complete the following:
1.1.1 A formal process for approving
and testing all network connections and
changes to the firewall and router
configurations
1.1.1 Verifythat there is a formal process for testing and
approval of all network connections and changes to
firewall and router configurations.

1.1.2.a Verifythat a current network diagram(for
example, one that shows cardholder data flows over the
network) exists and that it documents all connections to
cardholder data, including any wireless networks.
1.1.2 Current network diagramwith all
connections to cardholder data, including
any wireless networks
1.1.2.b Verifythat the diagramis kept current.
1.1.3 Requirements for a firewall at
each Internet connection and between any
demilitarized zone (DMZ) and the internal
network zone
1.1.3 Verifythat firewall configuration standards include
requirements for a firewall at each Internet connection and
between any DMZ and the internal network zone. Verify
that the current network diagramis consistent with the
firewall configuration standards.

1.1.4 Description of groups, roles, and
responsibilities for logical management of
network components
1.1.4 Verifythat firewall and router configuration
standards include a description of groups, roles, and
responsibilities for logical management of network
components.

Not in
Place
Target Date/
Comments
1.1.5.a Verifythat firewall and router configuration
standards include a documented list of services, protocols
and ports necessaryfor businessfor example, hypertext
transfer protocol (HTTP) and Secure Sockets Layer (SSL),
Secure Shell (SSH), and Virtual Private Network (VPN)
protocols.
1.1.5 Documentation and business
justification for use of all services,
protocols, and ports allowed, including
documentation of securityfeatures
implemented for those protocols
considered to be insecure
1.1.5.b Identify insecure services, protocols, and ports
allowed; and verifythey are necessary and that security
features are documented and implemented by examining
firewall and router configuration standards and settings for
each service. An example of an insecure service, protocol,
or port is FTP, which passes user credentials in clear-text.

1.1.6.a Verifythat firewall and router configuration
standards require reviewof firewall and router rule sets at
least every six months.
1.1.6 Requirement to reviewfirewall
and router rule sets at least everysix
months
1.1.6.b Obtain and examine documentation to verifythat
the rule sets are reviewed at least every six months.

1.2 Build a firewall configuration that
restricts connections between untrusted
networks and anysystemcomponents in
the cardholder data environment.
1.2 Examine firewall and router configurations to verify
that connections are restricted between untrusted networks
and systemcomponents in the cardholder data
environment, as follows:
Note: An untrusted network is any network that is external to the networks belonging to the entity under
review, and/or which is out of the entity's ability to control or manage.
1.2.1.a Verifythat inbound and outbound traffic is limited
to that which is necessary for the cardholder data
environment, and that the restrictions are documented.
1.2.1 Restrict inbound and outbound
traffic to that which is necessaryfor the
cardholder data environment.
1.2.1.b Verifythat all other inbound and outbound traffic is
specifically denied, for example by using an explicit deny
allor an implicit deny after allowstatement.

1.2.2 Secure and synchronize router
configuration files.
1.2.2 Verifythat router configuration files are secure
and synchronizedfor example, running configuration
files (used for normal running of the routers) and start-up
configuration files (used when machines are re-booted),
have the same, secure configurations.

Appendix B 367
Not in
Place
Target Date/
Comments
1.2.3 Install perimeter firewalls between
any wireless networks and the cardholder
data environment, and configure these
firewalls to deny or control (if such traffic is
necessaryfor business purposes) any
traffic fromthe wireless environment into
1.2.3 Verifythat there are perimeter firewalls installed
between any wireless networks and systems that store
cardholder data, and that these firewalls deny or control (if
such traffic is necessary for business purposes) any traffic
fromthe wireless environment into the cardholder data
environment.

1.3 Prohibit direct public access between
the Internet and any systemcomponent in
1.3 Examine firewall and router configurations, as detailed
below, to determine that there is no direct access between
the Internet and systemcomponents, including the choke
router at the Internet, the DMZ router and firewall, the DMZ
cardholder segment, the perimeter router, and the internal
cardholder network segment.
1.3.1 Implement a DMZ to limit inbound
and outbound traffic to only protocols that
are necessary for the cardholder data
environment.
1.3.1 Verifythat a DMZ is implemented to limit inbound
and outbound traffic to only protocols that are necessary
for the cardholder data environment.

1.3.2 Limit inbound Internet traffic to IP
addresses within the DMZ.
1.3.2 Verifythat inbound Internet traffic is limited to IP
addresses within the DMZ.

1.3.3 Do not allowany direct routes
inbound or outbound for traffic between
the Internet and the cardholder data
environment.
1.3.3 Verifythere is no direct route inbound or outbound
for traffic between the Internet and the cardholder data
environment.

1.3.4 Do not allowinternal addresses to
pass fromthe Internet into the DMZ.
1.3.4 Verifythat internal addresses cannot pass fromthe
Internet into the DMZ.

1.3.5 Restrict outbound traffic fromthe
cardholder data environment to the
Internet such that outbound traffic can
only access IP addresses within the DMZ.
1.3.5 Verifythat outbound traffic fromthe cardholder data
environment to the Internet can only access IP addresses
within the DMZ.

Not in
Place
Target Date/
Comments
1.3.6 Implement stateful inspection,
also known as dynamic packet filtering.
(That is, onlyestablishedconnections
are allowed into the network.)
1.3.6 Verifythat the firewall performs stateful inspection
(dynamic packet filtering). [Only established connections
should be allowed in, and only if they are associated with
a previously established session (run a port scanner on all
TCP ports with syn resetor syn ackbits seta
response means packets are allowed through even if they
are not part of a previously established session).]

1.3.7 Place the database in an internal
network zone, segregated fromthe DMZ.
1.3.7 Verifythat the database is on an internal network
zone, segregated fromthe DMZ.

1.3.8 Implement IP masquerading to
prevent internal addresses frombeing
translated and revealed on the Internet,
using RFC 1918 address space. Use
network address translation (NAT)
technologiesfor example, port address
translation (PAT).
1.3.8 For the sample of firewall and router components,
verifythat NAT or other technology using RFC 1918
address space is used to restrict broadcast of IP
addresses fromthe internal network to the Internet (IP
masquerading).

1.4.a Verifythat mobile and/or employee-owned
computers with direct connectivityto the Internet (for
example, laptops used by employees), and which are used
to access the organizations network, have personal firewall
software installed and active.
1.4 Install personal firewall software on
any mobile and/or employee-owned
computers with direct connectivityto the
Internet (for example, laptops used by
employees), which are used to access the
organizations network.
1.4.b Verifythat the personal firewall software is configured
bythe organization to specific standards and is not alterable
bymobile computer users.

APPENDIX C
Configuring for Large Files and Web Pages
This appendix describes how to configure a Web site that handles very large
HTTP POST requests to minimize processing delays and hangs on the Citrix
Application Firewall.
Overview
The Application Firewall is processor intensive. On multi-processor hardware
platforms, it makes heavy use of coprocessors, which limits loading on the main
processor. On single processor platforms, however, certain types of requests can
overload the Application Firewall and cause slow processing on the Citrix
NetScaler appliance.
In extreme cases, the NetScaler appliance will appear to hang while it processes
the request, causing a failover in an HA pair installation. In a single unit
installation, users will be unable to access protected servers and applications until
the unit finishes processing the large request or is rebooted.
In particular, when a user uploads a large file or returns any type of large POST
request to a protected Web server, this condition may be triggered. If the
Transform Cross-Site Scripts check action, the Transform SQL Special
Characters check action, or both are enabled, this condition may be triggered
more easily. The actual size of POST body required to trigger this condition
varies depending on CPU speed and the amount of RAM available on the
NetScaler appliance. Normally the total size of a POST request must be over 2
MB to trigger this condition.
Three Workarounds
Depending on whether your protected Web servers process large POST requests,
and if they do, how many large POST requests they process, there are three
workarounds for this issue.
Legitimate large uploaded files. If users may legitimately upload
extremely large files to your Web server, you can simply disable security
checks on uploaded files. Web servers do not normally execute code in
uploaded files, even those that contain active code. It is extremely unlikely
that a successful cross-site scripting attack or SQL injection attack could be
launched using an uploaded file, so it is normally safe to disable security
checks for this type of content.
Legitimate large Web form POST bodies. If your protected Web site has
Web forms that can legitimately create extremely large POST bodies, you
need to configure your NetScaler appliance to minimize processing of large
POST bodies. To prevent SQL injection or cross-site scripting attacks, you
should do this only when the form contents are not used as parameters for
SQL queries or displayed on a web page.
No legitimate large POST bodies. If users should never upload extremely
large files to your Web server, and if none of your Web forms, when filled
wiith legitimate data, can create extremely large POST bodies, you can sim-
ply configure the Application Firewall to reject any POST bodies above a
certain size. This is the safest option, and is recommended whenever you
know that it will not block legitimate traffic.
The following procedures describe how to configure your system appropriately.
The first procedure describe how to disable checking of uploaded files using the
configuration utility.
To disable checking of uploaded files from the configuration utility
1. If you have not already done so, log onto the configuration utility.
For instructions, see To log on to the configuration utility on page40.
2. In the Menu tree, click the plus to the left of the Application Firewall entry
to expand it and display its submenu, then click the Profiles entry to display
the Profiles page.
3. Create a profile to protect Web forms that receive large file uploads.
You can create this profile with basic or with advanced defaults. Normally
it is wise to use advanced defaults when creating a profile to protect Web
forms because the Application Firewall can require specific relaxations to
protect specific Web form content appropriately, relaxations most easily
generated using the Learning feature. Advanced defaults provide
appropriate starter settings when you will use the Learning feature.
For instructions on creating a profile using the configuration utility, see To
create a profile by using the configuration utility on page86.
4. In the Profile page data area, click the entry for the profile you just created
once, to highlight it.
Appendix C 371
5. Click the Open button to open the Configure Application Firewall Profile
dialog box for the profile you selected.
6. Configure the profile security checks as appropriate, disabling blocking for
security checks that might block legitimate requests until they are properly
configured.
For instructions on configuring a profile using the configuration utility, see
To configure a user-defined profile by using the configuration utility on
page87.
7. Click the Settings tab to display the Settings page, shown in The
Configure Application Firewall Profile Dialog Box, Settings Page on
page371.
The Configure Application Firewall Profile Dialog Box, Settings Page
8. Check the check box labeled, Exclude uploaded files from security
checks.
The Configure Application Firewall Profile dialog box closes, and you
return to the Profiles page.
10. Create and configure an appropriate policy to detect connections to those
web pages that contain Web forms used to accept uploaded files.
For detailed instructions on configuring a policy, see To configure a policy
by using the configuration utility on page136.
11. Globally bind your new policy to put it into effect.
For detailed instructions on globally binding a policy, see To globally bind
a policy by using the configuration utility on page149.
The second procedure, below, describe how to disable checking of uploaded files
using the NetScaler command line.
To disable checking of uploaded files from the NetScaler command line
via SSH on page60.
2. Create a profile to protect Web forms that receive large file uploads.
You can create this profile with basic or with advanced defaults. Normally
it is wise to use advanced defaults when creating a profile to protect Web
forms because the Application Firewall can require specific relaxations to
protect specific Web form content appropriately, relaxations most easily
generated using the Learning feature. Advanced defaults provide
appropriate starter settings when you will use the Learning feature.
Using the NetScaler command line, you enter the following command to
create a new profile with advanced defaults:
> add appf w pr of i l e <name> - def aul t s advanced
For <name>, substitute a name for your profile.
3. Configure the profile to disable blocking and enable learning for the
security checks you will use.
For detailed instructions on configuring a new profile with advanced
defaults, see To create and configure a profile using the NetScaler
command line on page99.
4. Enter the following command to disable checking of uploaded files for that
particular profile.
> set appf w pr of i l e <name> - excl udeFi l eUpl oadFr omChecks ON
For <name>, substitute the name of the profile that will be used when
filtering the URLs that contain Web forms used to upload files.
Appendix C 373
5. Create and configure an appropriate policy to detect connections to those
web pages that contain Web forms used to accept uploaded files.
For detailed instructions on configuring a policy, see To create a policy by
using the NetScaler command line on page144.
6. Globally bind your new policy to put it into effect.
For detailed instructions on globally binding a policy, see To globally bind
a policy by using the NetScaler command line on page150.
The next procedure, below, describes how to configure your NetScaler appliance
to minimize processing of large POST bodies. Some parts of this procedure can
be performed using the configuration utility, but some must be performed using
the NetScaler command line. For that reason, the procedure describes how to
perform the configuration at the NetScaler command line.
To configure the NetScaler appliance for minimal processing of large POST
requests
via SSH on page60.
2. Type the following command to enter the BSD shell from the NetScaler
command line.
> shel l
The prompt changes from > to #, and you are in the BSD shell.
3. Type the following command to disable scanning of POST bodies above a
certain size when applying security checks.
# nsapi mgr - s appf w_post _body_scan_l i mi t =<l i mi t >
For <limit>, substitute the maximum number of bytes the Application
Firewall should scan for security check violations. For example, if you
want to set a POST body scan limit of 1 MB, for <limit> you would
substitute 1000000.
This command applies globally to all Application Firewall profiles on the
NetScaler appliance or HA pair.
4. Type the following command to disable extraction of the Web form ID from
POST bodies.
# nsapi mgr - s appf w_post _body_ext r act _f or mi d=<l i mi t >
For <limit>, substitute the number 0. By default, this parameter is set to a
value of 1, which enables extraction of Web form IDs. Turning off Web
form ID extraction speeds processing of extremely large POST bodies
considerably.
This command applies globally to all Application Firewall profiles on the
NetScaler appliance or HA pair.
5. Type the following command to leave the BSD shell.
# exi t
The prompt changes from # back to >, and you exit the BSD shell and
return to the NetScaler command line.
6. If you are certain that users will never legitimately return a POST above a
certain size in response to any content protected by a particular profile, type
the following command to block outright any POST requests above this
limit.
> set appf w pr of i l e <name> - post BodyLi mi t <l i mi t >
For <name>, substitute the name of the profile. For <limit>, substitute the
number of bytes above which POST requests should be blocked. For
example, if you want to block all POST bodies above 2 MB in size, for
<limit> you would substitute 2000000.
Setting a post body limit can significantly reduce the impact of any
extremely large POST requests that might be sent to your server in error or
as part of an attack.
Note: If you set the POST body limit to a higher value than you set the
global POST body scan limit, the Application Firewall will allow POST
requests larger than the POST body scan limit, but smaller than the POST
body limit, to proceed without security scanning. This may introduce a
vulnerability into your configuration.
7. Repeat the previous step for each profile used to filter large POST body
content.
Unlike the nsapimgr command in the previous step, the set appfw
profile command always applies only to the specific profile you chose.
You must therefore issue the command in the previous step once for each
profile you want to configure.
The final procedure, below, describes how to configure the Application Firewall
to reject requests with POST bodies over a certain size outright.
Note: This procedure can be used on any NetScaler appliance to prevent
possible problems caused by requests with overly large POST bodies when you
do not expect your protected Web servers to receive any such requests.
Appendix C 375
To configure the Application Firewall to reject large POST requests
via SSH on page60.
2. Enter the following command to block outright any POST requests above
this limit for the specified profile.
> set appf w pr of i l e <name> - post BodyLi mi t <l i mi t >
For <name>, substitute the name of the profile. For <limit>, substitute the
number of bytes above which POST requests should be blocked. For
example, if you want to block all POST bodies above 2 MB in size, for
<limit> you would substitute 2000000.
3. Repeat the previous step for each profile used to filter large POST body
content.
APPENDIX D
SQL Injection Check Keywords
This appendix provides a list of the SQL keywords recognized by the Application
Firewall SQL Injection check. These SQL keywords are used by the HTML SQL
Injection check and the XML SQL Injection check to determine whether a
request contains unauthorized injected SQL code.
Note: Since SQL servers treat SQL keywords as case-sensitive, the list of
keywords below is also case-sensitive, with capitalized letters sorting before
lower-case letters.
MSysACEs
MSysObj ect s
MSysQuer i es
MSysRel at i onshi ps
SYS. ALL_CATALOG
SYS. ALL_CONSTRAI NTS
SYS. ALL_OBJ ECTS
SYS. ALL_TABLES
SYS. ALL_TAB_COLUMNS
SYS. ALL_TAB_PRI VS
SYS. ALL_TRI GGERS
SYS. ALL_USERS
SYS. ALL_VI EWS
SYS. TAB
SYS. USER_CATALOG
SYS. USER_CONSTRAI NTS
SYS. USER_OBJ ECTS
SYS. USER_ROLE_PRI VS
SYS. USER_SYS_PRI VS
SYS. USER_TABLES
SYS. USER_TAB_COLUMNS
SYS. USER_TAB_PRI VS
SYS. USER_TRI GGERS
SYS. USER_VI EWS
add
al t er
and
begi n
case
char
commi t
const r ai nt
cr eat e
decode
del et e
di st i nct
dr op
execut e
exec
exi st s
gr ant
gr oup
i nser t
i nt er sect
j oi n
l i ke
mi nus
modi f y
nul l
or
r evoke
r ol l back
sel ect
shut down
Appendix D 379
sp_sdi debug
syscol umns
sysobj ect s
uni on
updat e
wher e
xp_avai l abl emedi a
xp_cmdshel l
xp_del et emai l
xp_di r t r ee
xp_dr opwebt ask
xp_dsni nf o
xp_enumdsn
xp_enumer r or l ogs
xp_enumgr oups
xp_enumqueuedt asks
xp_event l og
xp_f i ndnext msg
xp_f i xeddr i ves
xp_get f i l edet ai l s
xp_get net name
xp_gr ant l ogi n
xp_l ogevent
xp_l ogi nconf i g
xp_l ogi ni nf o
xp_makewebt ask
xp_msver
xp_per f end
xp_per f moni t or
xp_per f sampl e
xp_per f st ar t
xp_r eader r or l og
xp_r eadmai l
xp_r egr ead
xp_r evokel ogi n
xp_r unwebt ask
xp_schedul er si gnal
xp_sendmai l
xp_ser vi cecont r ol
xp_snmp_get st at e
xp_snmp_r ai set r ap
xp_spr i nt f
xp_sql i nvent or y
xp_sql r egi st er
xp_sql t r ace
xp_sscanf
xp_st ar t mai l
xp_st opmai l
xp_subdi r s
xp_unc_t o_dr i ve
APPENDIX E
Cross-Site Scripting: Allowed Tags and
Attributes
This appendix provides a list of the HTML tags and attributes allowed as safe by
the Application Firewall Cross-Site Scripting check.
Note: HTML tags are not case-sensitive, so the HTML tags shown below are in
all-capital letters. Any combination of capitals and lower-case letters can be used
for an HTML tag name, however, and the tag will still be valid and still have the
same effect.
Allowed Tags
<A>
<ADDRESS>
<B>
<BASEFONT>
<BGSOUND>
<BIG>
<BLOCKQUOTE>
<BQ>
<BR>
<CAPTION>
<CENTER>
<CITE>
<DD>
<DEL>
<DFN>
<DIV>
<DL>
<DT>
<EM>
<FONT>
<H1>
<H2>
<H3>
<H4>
<H5>
<H6>
<HR>
<I>
<IMG>
<KBD>
<LI>
<MAP>
<MARQUEE>
<OL>
<P>
<SMALL>
<STRIKE>
<STRONG>
<SUB>
<SUP>
<TABLE>
<TD>
<TH>
<TR>
<TT>
Appendix E 383
<U>
<UL>
Allowed Attributes
abbr
accesskey
align
alt
axis
bgcolor
border
cellpadding
cellspacing
char
charset
charoff
cite
class
clear
color
colspan
compact
coords
dir
face
headers
height
hreflang
href
hspace
id
ismap
lang
longdesc
name
noshade
nowrap
rel
rev
rowspan
rules
scope
shape
size
src
start
summary
tabindex
target
title
type
usemap
valign
value
vspace
width

NS AppFirewall Guide

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

NS AppFirewall Guide

Transféré par

Droits d'auteur :

Formats disponibles

Citrix

Vous aimerez peut-être aussi