NS AppFirewall Guide

Citrix Application Firewall Guide

Citrix® NetScaler® 9.2

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 SUBJECT 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 radiofrequency 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 © Jean-loup Gailly and Mark Adler. Copyright © 1999, 2000 by Jef 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 Juniper Networks, Inc. All rights reserved. Copyright © 2001, 2002 Networks Associates Technology, Inc. All rights reserved. Copyright (c) 2002 Networks Associates Technology, Inc. Copyright 19992001© The 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 Jonathan 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 Jason L. Wright. Copyright © 2000 Theo de Raadt. Copyright © 2001 Patrik Lindergren. All rights reserved. Last Updated: July 2010

C ONTENTS 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

Chapter 8

v

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

P REFACE

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.

•

Appendix A, “PCRE Character Encoding.” Provides a primer on using PCRE character encoding to represent non-ASCII characters in Application Firewall regular expressions.

•

Appendix B, “PCI DSS Standard.” Provides a copy of the official Payment Card Industry (PCI) Data Security (DSS) Standard.

•

Appendix C, “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.

•

Appendix D, “SQL Injection Check Keywords.” Lists the SQL keywords that the Application Firewall SQL Injection security check uses when examine requests.

iii

•

Appendix E, “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.

Formatting Conventions This documentation uses the following formatting conventions. Formatting Conventions Convention

Meaning

Boldface

Information that you type exactly as shown (user input); elements in the user interface.



Placeholders for information or parameters that you provide. For example, 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, [-range positiveInteger] 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

Formatting Conventions Convention

Meaning

| (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 )

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.

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 [email protected].

•

For Command Center documentation, send email to [email protected].

•

For Access Gateway documentation, send email to [email protected].

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.

C HAPTER 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 PCIDSS 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 version 9.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 numbers, 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 customer’s 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 unauthorized 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 company’s Web server, or use your company’s 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 unauthorized information, to compromise a Web server, or both.

•

Cookie security attacks. Sending a modified cookie to a Web server, usually in hopes of obtaining access to unauthorized content using falsified credentials.

4

Citrix Application Firewall Guide

•

Forceful browsing. Accessing URLs on a Web site directly, without navigating to the URLs via hyperlinks on the home page or other common start URLs on the Web site. Individual instances of forceful browsing may simply 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 combined 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 application. There are a number of special attacks that can be made against XMLbased 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:

Chapter 1

Introduction

5

-

SQL injection attacks. Sending an active SQL command or commands using SQL special characters and keywords in a XMLbased 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 XMLbased 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.

6

Citrix Application Firewall Guide

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 company’s 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 user’s 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.

Chapter 1

Introduction

7

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.

8

Citrix Application Firewall Guide

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 page 19. 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.

Chapter 1

Introduction

9

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).

10

Citrix Application Firewall Guide

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 Enter 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 [-parameter]

For action, you substitute the action you want to perform. For groupname, you substitute the groupname associated with the feature or task. For entity, you substitute the specific type of object you are viewing or changing. For , you substitute the IP, hostname, or other specific name for the entity. Finally, for [-parameter], you substitute one or more parameters (if any) that your command requires. For example, you use the add appfirewall profile command to create a profile named HTML with basic defaults, as shown below. > add appfirewall profile HTML -defaults basic Done >

In this command, add is the action; appfirewall is the groupname; profile is the entity; HTML is the ; and -defaults basic 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 appfirewall profile command to review all profiles that currently exist on your Application Firewall, as shown below: > show appfw profile 3) Name: HTML1 ErrorURL: / StripComments: ON DefaultCharSet: iso-8859-1 StartURLAction: block log stats StartURLClosure: OFF DenyURLAction: block log stats XSSAction: block log stats XSSTransformUnsafeHTML: OFF XSSCheckCompleteURLs: OFF SQLAction: block log stats SQLTransformSpecialChars: OFF SQLOnlyCheckFieldsWithSQLChars: ON FieldConsistencyAction: none CookieConsistencyAction: none BufferOverflowAction: block log stats BufferOverflowMaxURLLength: 1024 BufferOverflowMaxHeaderLength: 4096

Chapter 1

Introduction

11

BufferOverflowMaxCookieLength: 4096 FieldFormatAction: block log stats DefaultFieldFormatType: "" DefaultFieldFormatMinLength: 0 DefaultFieldFormatMaxLength: 65535 CommerceAction: block log stats CommerceCard: CommerceMaxAllowed: 0 CommerceXOut: OFF Done >

Unlike the add appfirewall profile 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 config command, lacks everything after the groupname. It has no entity or parameters, as shown below. > show config NetScaler IP: 192.168.100.42 Number of MappedIP(s): 1 Node: Standalone Global configuration settings: HTTP port(s): Max connections: Max requests per connection: Client IP insertion: Cookie version: Min Path MTU: Path MTU entry timeout: FTP Port Range:

(mask: 255.255.255.0)

(none) 0 0 DISABLED 0 576 10 0

Done >

You use the show config 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.

12

Citrix Application Firewall Guide

The figure below shows the configuration utility’s 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 Edition” 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

Chapter 1

Introduction

13

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 contains 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 Configuration Utility, System Overview” on page 12 has two tabs: the System Information and System Sessions tabs. Note: The data area on most pages in the configuration utility is readonly. 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 you’ve 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.

14

Citrix Application Firewall Guide

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

Chapter 1

Introduction

15

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 page 17.

•

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 page 65.

16

Citrix Application Firewall Guide

C HAPTER 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 page 65. 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.”

18

Citrix Application Firewall Guide

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. One-Arm Mode Router

Two-Arm Mode Router

Layer 2 Switch

Layer 2 Switch

Application Firewall Layer 2 Switch Protected Web Servers

Application Firewall Protected Web Servers

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 appliance’s 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.

Chapter 2

Installation

19

In a multiple subnet networking environment, the appliance’s 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 page 20.

•

Citrix NetScaler 9010. If you are installing a unit built on the 9010 platform, proceed to “The Citrix NetScaler 9010” on page 22.

•

Citrix NetScaler 10010. If you are installing a unit built on the 10010 platform, proceed to “The Citrix NetScaler 10010” on page 26.

•

Citrix NetScaler 12000. If you are installing a unit built on the 12000 platform, proceed to “The Citrix NetScaler 12000” on page 30.

•

Citrix NetScaler MPX 15000. If you are installing a unit built on the 15000 platform, proceed to “The Citrix NetScaler MPX 15000” on page 33.

20

Citrix Application Firewall Guide

•

Citrix NetScaler MPX 17000. If you are installing a unit built on the 17000 platform, proceed to “The Citrix NetScaler MPX 15000” on page 33.

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 unit’s 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 page 40.

Chapter 2

Installation

21

The figure below shows a drawing of the 7000 from the back, with important features labeled. Second Power Switch

Fan

Hard Disk

Power Supply

Power Switch Compact Flash Drive and Release Button

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.

22

Citrix Application Firewall Guide

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 page 39 to configure it.

The Citrix NetScaler 9010 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. Rack mounts

LCD Display Handle to carry the unit.

RS232 Serial Port

Four Optical 1000base-X Ethernet Ports

Handle to carry the unit.

The Citrix NetScaler 9010 (fiber version), From the Front The 9010 (fiber version) has the following ports on the front:

Chapter 2

Installation

23

•

Four fiber Gigabit 1000-Base-X optical network interfaces, labeled 1/1, 1/ 2, 1/3, and 1/4.

•

Serial port (9600 baud, 8 bits, 1 stop bit, No parity)

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. Rack mounts

LCD Display Handle to carry the unit.

RS232 Serial Port

Four 10/100/1000base-T Copper Ethernet Ports

Handle to carry the unit.

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.

•

Serial port (9600 baud, 8 bits, 1 stop bit, No parity)

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 unit’s 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. You can use the serial port to connect a notebook computer directly to the unit using the supplied serial cable. The figure below shows the 9010 from the back, with ports and important features clearly labeled.

24

Citrix Application Firewall Guide

Power switch

Non-maskeable interrupt (NMI) button

Disable alarm button

Two removable power supplies

Hard disk Compact flash 10/100Base-T drive and release button copper Ethernet port

The Citrix NetScaler 9010, From the Back 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. Before you install the 9010, ensure that you have the following items available: •

The power cord and serial cable, which are supplied with the 9010.

•

One to four ethernet cables, which are not supplied with the unit.

•

If you are installing a 9010 (fiber version), four Finisar Active Copper SFP transceivers, which are also supplied with the appliance.

•

Four rack screws and a screwdriver.

You are now ready to install the 9010.

Chapter 2

Installation

25

To install the Citrix NetScaler 9010 in your server room

1.

Open the packing box the appliance arrived 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. 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.

3.

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.

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.

You have now successfully installed your Citrix NetScaler 9010. Proceed to “Performing Initial Configuration,” on page 39 to configure it.

26

Citrix Application Firewall Guide

The Citrix NetScaler 10010 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. Rack mounts

LCD display Handle to carry the unit

RS232 Four gigabit Four serial console 10/100/1000Base-T SFP ports port copper Ethernet ports

Handle to carry the unit

The Citrix NetScaler 10010, From the Front 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. 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 unit’s 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.

Chapter 2

Installation

27

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.

Finisar Active Copper SFP Transceivers Plugged in and locked in place. Transceiver unlocked position from side

Transceiver locked position from side

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. You can use the serial port to connect a notebook computer directly to the unit 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 page 58. The following figure shows the 10010 from the back, with ports and important features clearly labeled.

28

Citrix Application Firewall Guide

Power switch

Non-maskeable interrupt (NMI) button

Disable alarm button

Two removable power supplies

Hard disk Compact flash 10/100Base-T drive and release button copper Ethernet port

The Citrix NetScaler 10010, From the Back 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 unit 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 10010 with only one functioning or one connected power supply, you forfeit the built-in fail-safe protection. Before you install the 10010, ensure that you have the following items available: •

The power cord and serial cable, which are supplied with the 10010.

•

Four Finisar Active Copper SFP transceivers, which are also supplied with the appliance.

•

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 10010.

Chapter 2

Installation

29

To install the Citrix NetScaler 10010 in your server room

1.

Open the packing box the appliance arrived 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.

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.

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. 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.

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. Again, if you want, you can use a different interface number.

You have now successfully installed your Citrix NetScaler 10010. Proceed to “Performing Initial Configuration,” on page 39 to configure it.

30

Citrix Application Firewall Guide

The Citrix NetScaler 12000 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. Rack mounts

1/1

Handle to carry the unit

LCD display

RS232 serial console port

1/2

1/3

1/4

1/5

1/6

1/7

1/8

Eight Gigabit SFP Ports

Handle to carry the unit

The Citrix NetScaler 12000, 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 unit’s 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 Installation and Configuration Guide, Volume 1, Chapter 3, “Configuring the Application Switch,” “Understanding the LCD Monitor,” on page 3-13. You can use the serial 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 page 58. The following figure shows examples of the Finisar Active Copper SFP transceivers, and how they plug into the 1000base-X ports.

Chapter 2

Installation

31

Finisar Active Copper SFP Transceivers Plugged in and locked in place. Transceiver unlocked position from side

Transceiver locked position from side

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 features clearly labeled. Power switch

Non-maskeable interrupt (NMI) button

Disable alarm button

Two removable power supplies

Hard disk Compact flash 10/100Base-T drive and release button copper Ethernet port

The Citrix NetScaler 12000, From the Back 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.

32

Citrix Application Firewall Guide

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 unit 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 12000 with only one functioning or one connected power supply, you forfeit the built-in fail-safe protection. Before you install the 12000, ensure that you have the following items available: •

The power cord and serial cable, which are supplied with the 12000.

•

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.

•

Four rack screws and a screwdriver.

You are now ready to install the 12000. To install the Citrix NetScaler 12000 in your server room

1.

Open the packing box the appliance arrived 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.

Chapter 2

3.

Installation

33

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.

5.

Take a Finisar transceiver and an ethernet 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 appliance detects which interfaces are in use and which networks they are connected to 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. Again, if you want, you can use a different interface number.

You have now successfully installed your Citrix NetScaler 12000. Proceed to “Performing Initial Configuration,” on page 39 to configure it.

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 following figure shows the 15000 unit from the front, with ports and other important features clearly labeled.

34

Citrix Application Firewall Guide

Rack mounts

LCD display Handle to carry the unit

RS232 Serial console port

1000Base-T MGMT port Eight 1000Base-X SFP ports

Two 10G XFP ports

Handle to carry the unit

The Citrix NetScaler MPX 15000, 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 unit’s 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. 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 page 58. 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. The following figure shows the back of the 15000, with ports and other important features clearly labeled.

Chapter 2

Removable compact flash drive and release button

Installation

35

Power supplies with fan

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. The unit 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. Caution: If you choose to continue operating the 15000 with only one functioning or one connected power supply, you forfeit the built-in fail-safe protection. Before you install the 15000, ensure that you have the following items available: •

The power cord and serial cable, which are supplied with the 15000.

•

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.

•

Four rack screws and a screwdriver.

You are now ready to install the 15000. 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. 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.

36

Citrix Application Firewall Guide

2.

Place the 15000 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.

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. The appliance will perform a series of power-on tests that take approximately a minute as it comes up.

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 which interfaces are in use and which networks they are connected to automatically.

5.

Connect the other end to a hub or switch that connects to your network.

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. Again, if you want, you can use a different interface number.

You have now successfully installed your Citrix NetScaler MPX 15000. Proceed to “Performing Initial Configuration,” on page 39 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 following figure shows the 17000 unit from the front, with ports and other important features clearly labeled.

Chapter 2

Installation

37

Rack mounts

LCD display Handle to carry the unit

1000Base-T MGMT port RS232 Serial console port

Four 10G XFP ports

Handle to carry the unit

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. 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 unit’s 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. 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 page 58. 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 Gigabit SFP 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.

The following figure shows the back of the 17000, with ports and other important features clearly labeled.

38

Citrix Application Firewall Guide

Removable compact flash drive and release button

Power supplies with fan

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. The unit 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. Caution: If you choose to continue operating the 17000 with only one functioning or one connected power supply, you forfeit the built-in fail-safe protection. Before you install the 17000, ensure that you have the following items available: •

The power cord and serial cable, which are supplied with the 17000.

•

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.

•

Four rack screws and a screwdriver.

You are now ready to install the 17000. 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.

Chapter 2

Installation

39

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 17000 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.

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. The appliance will perform a series of power-on tests that take approximately a minute as it comes up.

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 which interfaces are in use and which networks they are connected to automatically.

5.

Connect the other end to a hub or switch that connects to your network.

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. Again, if you want, you can use a different interface number.

You have now successfully installed your Citrix NetScaler MPX 17000. Proceed to “Performing Initial Configuration,” on page 39 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.

40

Citrix Application Firewall Guide

•

If you want to configure your appliance using the Citrix NetScaler Configuration 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 page 58.

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 Java-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: http://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.

Chapter 2

Installation

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.

41

42

Citrix Application Firewall Guide

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.

Chapter 2

Installation

43

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 Java 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 Java 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.

44

Citrix Application Firewall Guide

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

Chapter 2

Installation

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 Java engine.

C.

Click the OK button.

45

Java 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.

46

Citrix Application Firewall Guide

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 page 40. The opening screen of the Setup Wizard should be displayed after you install the utility.

Chapter 2

2.

Installation

47

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.

48

Citrix Application Firewall Guide

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.

• F. 4.

If you selected SNP, enter an IP address within the same subnet as the NSIP.

In the Netmask field, enter the netmask for the MIP or SNIP.

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.

Chapter 2

Installation

49

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.

50

Citrix Application Firewall Guide

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.

Chapter 2

Installation

51

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.

52

Citrix Application Firewall Guide

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.

Chapter 2

Installation

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

53

54

Citrix Application Firewall Guide

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.

2.

E.

Repeat steps a 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.

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.

Chapter 2

Installation

55

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. 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.

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 step 7.

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.

56

Citrix Application Firewall Guide

Your new service appears in the services list.

3.

G.

Repeat steps a through f to create a new service for each server you added in step 7.

H.

Click the Close button to close the Create Service dialog box and return to the Services page.

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.

Chapter 2

Installation

57

The Create Virtual Server Dialog Box B.

In the Name text box, type a name for the virtual server. 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.

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 step 8(d).

58

Citrix Application Firewall Guide

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 steps a 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 page 65, 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 page 19.

Chapter 2

Installation

59

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 telnet client. Note: OSX is a based on the FreeBSD Unix platform. Most standard Unix shell programs are available from the OSX command line.

• 4.

For Unix-based workstations, you can use the shell-based telnet client or any terminal emulation program that comes with your GUI.

Set the terminal parameters as shown below.

Parameter Port Bits Per Second (BPS) Data Bits Parity Stop Bits Flow Control

5.

Setting The port to which you connected the serial cable, usually COM1. 9600 8 N (none) 1 None

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, nsroot, 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 appears, as shown below.

60

Citrix Application Firewall Guide

Last login: Sun Nov 12 16:20:08 2006 from 10.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.

2.

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.

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 page 58. 3.

At the login prompt, type the logon for the default system account, which is nsroot.

4.

•

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.

At the password prompt, type the password, and press the Enter key or click the OK button, as appropriate.

Chapter 2

Installation

61

You are logged onto the NetScaler command line, and the initial prompt appears, as shown below. Last login: Sun Nov 12 16:20:08 2006 from 10.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 /nsconfig directory.

5.

If the /nsconfig/license 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 /nsconfig/license 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.

62

Citrix Application Firewall Guide

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 page 58.

8.

Enter the following command to change the Root Password. > set system user nsroot

For , 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 ip -type mip

For , substitute the IP you will use as the MIP. For , 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 route

For , substitute the MIP you assigned in the previous step. For , substitute the internal, non-routable IP assigned to your Web server. For , substitute the default gateway for the LANIP. This command tells the NetScaler operating system to route packets to sent to the Web server at , which is not routable from outside your LAN, to the default gateway at .

Chapter 2

11.

Installation

63

Enter the following command to configure the NetScaler IP (NSIP). > set ns config -ipaddress -netmask

For , substitute the IP you will use for the NSIP. For , 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. > enable ns feature appfw

13.

Save your configuration, as shown below. > save ns config

14.

Enter the following command to display your current configuration, with the changes you made. > show ns config

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 configuration again. 15.

When every part of your configuration is exactly as you want it, enter the following command to reboot your appliance. > reboot

16.

Log back on to the appliance as nsroot, using the new administrative password you set.

17.

Enter the following command to confirm connectivity to the appliance. > ping

For , 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 page 65, to begin configuring the Application Firewall itself.

64

Citrix Application Firewall Guide

C HAPTER 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 Firewall’s 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: enable ns feature ApplicationFirewall

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.

66

Citrix Application Firewall Guide

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 page 84. User-created profiles provide tools for handling more complex content that cannot simply be passed on or blocked without filtering. They contain many userconfigurable 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 page 84. 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 appfw profile -defaults basic set appfw profile -type ( HTML | XML | HTML XML ) save ns config

Parameters for Creating and Configuring a New Profile Parameter

Description

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

Parameters for Creating and Configuring a New Profile Parameter

Description

Defaults (-defaults (basic | 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 (-type ( 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 -type parameter.

To create and configure a profile using the configuration utility

1.

Log on to the configuration utility, using either the Java client or the Web Start client. For instructions on doing this, see “To log on to the configuration utility” on page 40.

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.

68

Citrix Application Firewall Guide

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.

Chapter 3

Simple Configuration

69

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 Javascripts or forms that access back-end SQL databases, in the Defaults radio button array select the Advanced radio button.

70

Citrix Application Firewall Guide

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 page 83. 8.

Click Create to create your profile. Your new profile appears in the data area of the Application Firewall Profiles page.

9.

Repeat steps 5 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.

Chapter 3

H.

14.

Simple Configuration

71

Click the Close button to close the Configure Application Firewall Profiles dialog box and return to the Application Firewall Profiles screen.

Repeat steps 12 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 policy’s 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 page 135. 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.

72

Citrix Application Firewall 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

1.

Log on to the configuration utility, using either the Java client or the Web Start client. For instructions on doing this, see “To log on to the configuration utility” on page 40.

2.

In the Menu tree, expand the Application Firewall entry to display the 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.

Chapter 3

Simple Configuration

73

The Create Application Firewall Policy Dialog Box 4.

In the Policy Name* text box, type a name for your new policy. 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 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 page 136.

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.

74

Citrix Application Firewall Guide

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.

Chapter 3

Simple Configuration

75

For a description of all the available choices, see ”To configure a policy by using the configuration utility,” step C on page 140. 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.

•

To filter HTTP Requests that contain a particular query string, choose CONTAINS as your qualifier.

For a description of all the available choices, see ”To configure a policy by using the configuration utility,” step D on page 141. 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 company’s Web site is www.example.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 http://www.example.com/ login.php, type that in the Value* text box.

•

To filter HTTP Requests that contain a particular query string, type that string. For example, if you want to search queries for

76

Citrix Application Firewall Guide

strings that contain the string prod_lit, 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 page 60.

2.

Enter the following command to create the policy. > add appfw policy

Make the following substitutions: •

For , 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

Chapter 3

Simple Configuration

77

(_) 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 , substitute the following NetScaler expression: "REQ.HTTP.HEADER HOST CONTAINS ("www.example.com")"

•

For www.example.com, substitute the hostname of your company’s 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 company’s Web site host. This will match all requests to that Web site.

•

For , 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 config

4.

Enter the following command to confirm that your policy was correctly created. > show appfw policy

For , 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 policy’s name, expression, or profile, you must delete it as shown below, and then recreate it. > rm appfw policy

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.

78

Citrix Application Firewall Guide

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 NetScaler command line. To globally bind a policy by using the configuration utility

1.

Log on to the configuration utility, using either the Java client or the Web Start client. For instructions on doing this, see “To log on to the configuration utility” on page 40.

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.

Chapter 3

Simple Configuration

79

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.

80

Citrix Application Firewall Guide

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 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 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.

Chapter 3

Simple Configuration

81

The Policies Page, with two Globally-Bound Policies To globally bind a policy 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 page 60.

2.

Enter the following command to globally bind the policy. > bind appfw global

For , substitute the name of the policy you just created. For , 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

82

Citrix Application Firewall Guide

(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. 3.

Enter the following command to save your configuration. > save ns config

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 sensitive 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 profiles to protect that content, and additional policies to detect this special content. You can proceed to Chapter 12, “Use Cases,” on page 267 for examples that show how to best protect SQL databases and scripted content.

•

If you want to know more about the advanced features of the Application Firewall, proceed to Chapter 4, “Profiles,” on page 83 for a detailed description of how to create an advanced profile; Chapter 8, “The Common Security Checks,” on page 175 for detailed descriptions of each Application Firewall security check; or Chapter 5, “Policies,” on page 135 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.

C HAPTER 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 Firewall’s 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 page 65 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 page 85.

•

For specific information about profile settings, see “Configuring the Profile Settings,” on page 122.

•

For specific information about learning and the configuration options for each type of security check that includes the learning feature, see “Configuring the Learning Feature,” on page 129.

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 page 175 and the following two chapters.

84

Citrix Application Firewall Guide

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, Javascript, and dynamic content.

•

XML profile. Protects XML-based applications. You use this type of profile 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 attacks—sufficient 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 Javascript, 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.

86

Citrix Application Firewall Guide

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 user’s request, the Application Firewall can either redirect the user’s 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 user’s 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 site’s home page.

•

HTML Error Object. To display an HTML Error Object from the Application Firewall’s 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 page 40.

2.

In the navigation pane, expand Application Firewall, and then click Profiles.

Chapter 4

Profiles

87

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. 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.

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 page 175. 7.

Click Create. The new profile appears in the list in the Profiles pane.

8.

Repeat steps 6 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.

88

Citrix Application Firewall Guide

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:

3.

•

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.

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.

Chapter 4

Profiles

89

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.

90

Citrix Application Firewall Guide

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

Chapter 4

Profiles

91

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 page 175, 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.

92

Citrix Application Firewall Guide

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.

Chapter 4

Profiles

93

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 page 175. For more information about using the Regex Editor and Regex Tokens, see “Configuring the Security Checks with the Configuration Utility” on page 104 and following. E. 4.

Click Close to close the Modify Check dialog box and return to the Configure Application Firewall Profile dialog box.

Back in the Configure Application Firewall Profile dialog box, click the Settings tab to display it, as shown below.

94

Citrix Application Firewall Guide

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:

Chapter 4

•

Profiles

95

HTML Settings. •

HTML Error. When it blocks a user’s request, the Application Firewall can either redirect the user’s request to a designated Redirect URL, or it can display an HTML Error Object. •

Redirect URL. To redirect the user’s 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 site’s home page.

•

HTML Error Object. To display an HTML Error Object from the Application Firewall’s 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

96

Citrix Application Firewall Guide

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 user’s 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.

Chapter 4

Profiles

97

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. •

5.

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.

Click the Learning tab to display it, as shown below.

98

Citrix Application Firewall Guide

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.

Chapter 4

Profiles

99

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. For instructions on doing this, see “To log onto the NetScaler command line via SSH” on page 60.

2.

Enter the following command to create the profile. > add appfw profile [-defaults ( basic | advanced )]

For , 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

100

Citrix Application Firewall Guide

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 appfw profile [-type ( 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 appfw profile - [- ]

For 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 page 116 and following. For more information about the parameters of each Application Firewall security check and how they function, see the appropriate chapter:

5.

•

Common security checks. For security checks that apply to all kinds of profile, see Chapter 8, “The Common Security Checks,” on page 175.

•

HTML security checks. For security checks that apply only to HTML and Web 2.0 profiles, see Chapter 9, “The HTML Security Checks,” on page 201.

•

XML security checks. For security checks that apply only to XML and Web 2.0 profiles, see Chapter 10, “The XML Security Checks,” on page 235.

Enter the following command to save your configuration. > save ns config

6.

Enter the following command to confirm that your profile was correctly created. > show appfw profile

To remove a profile using the NetScaler command line, you log onto the NetScaler command line and enter the following command: > rm appfw profile

For , 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.

Chapter 4

•

Profiles

101

If the profile is associated with an active policy, an error message is displayed 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 profile’s 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.

102

Citrix Application Firewall Guide

•

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 content, 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 page 175.

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 structure 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 Appendix C, ”Configuring for Large Files and Web Pages,” on page 369.

Chapter 4

Profiles

103

For a detailed description of the HTML security checks, see Chapter 9, “The HTML Security Checks,” on page 201.

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 attachments 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 application’s 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 leaking of sensitive information.

For a detailed description of XML security checks, see Chapter 10, “The XML Security Checks,” on page 235.

104

Citrix Application Firewall Guide

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.

Chapter 4

Profiles

105

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 Application 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.

106

Citrix Application Firewall Guide

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 recommended 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 they’re configuring a new Application Firewall, or when they’ve 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 connections that violate the security check you are configuring. You enable statis-

Chapter 4

Profiles

107

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 user’s 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 Injection 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 inadvertently 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 transformation 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 Appendix C, ”Configuring for Large Files and Web Pages,” on page 369.

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

108

Citrix Application Firewall Guide

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 page 215. The Application Firewall can handle the HTTP Referer header in one of the following three ways, depending on which option you select in the dropdown 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.

Chapter 4

Profiles

109

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 server’s response to profile your SQL server’s 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 Firewall 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.

110

Citrix Application Firewall Guide

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.

Chapter 4

Profiles

111

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.

112

Citrix Application Firewall Guide

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.

Chapter 4

Profiles

113

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 page 175, or beginning in Chapter 9, “The HTML Security Checks,” on page 201, or beginning in Chapter 10, “The XML Security Checks,” on page 235, and read the specific information about that security check.

114

Citrix Application Firewall Guide

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 page 175, 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 appfw profile [-type ( HTML | XML | HTML XML)] - [- ]

Chapter 4

Profiles

115

For , you substitute the name of the profile you are configuring. For , you substitute either HTML (for an HTML profile), XML (for an XML profile), or HTML XML (for a Web 2.0 profile). For , you substitute the first parameter setting. For , 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 appfw profile Example -startURLAction block log stats

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 appfw profile Example -xmlDoSAction block log stats

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 profiles are labeled “XML”

Beneath this information is a list of the options for that parameter, and a description of the effect of each option.

116

Citrix Application Firewall Guide

Application Firewall Profile Security Check Parameters Parameter -startURLAction

Description 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. -startURLClosure ( ON | OFF )

-startURLAction stats: Enables statistics for the Start URL check. Applies to: Start URL security check. (common) ON enables Start URL closure; OFF disables Start URL

-exemptClosureURLsFromSecurityChecks

closure. Applies to: Start URL security check. (common

-denyURLAction

ON exempts requests that pass the Start URL Closure test from additional security checks; OFF does not exempt these requests from further checking. 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. -cookieConsistencyAction

-denyURLAction stats: Enables statistics for the Deny URL check. 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

the Cookie Consistency check. -cookieConsistencyAction log: Enables logging for the

Cookie Consistency check. -cookieConsistencyAction stats: Enables statistics for -fieldConsistencyAction

the Cookie Consistency check. 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 the Form Field Consistency check. -fieldConsistencyAction log: Enables logging for the Form Field Consistency check. -fieldConsistencyAction stats: Enables statistics for the Form Field Consistency check.

Chapter 4

Profiles

117

Application Firewall Profile Security Check Parameters Parameter -crossSiteScriptingAction

Description 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

for the Cross-Site Scripting check. -crossSiteScriptingAction log: Enables logging for

the Cross-Site Scripting check. -crossSiteScriptingAction stats: Enables statistics crossSiteScriptingTransformUnsafeHTML

-crossSiteScriptingCheckCompleteURLs

-SQLInjectionAction

for the Cross-Site Scripting check. 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. 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. 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

SQL Injection check. -SQLInjectionAction log: Enables logging for the SQL

Injection check. -SQLInjectionAction stats: Enables statistics for the -SQLInjectionTransformSpecialChars ( ON | OFF )

SQLInjectionOnlyCheckFieldsWithSQLCha rs ( ON | OFF )

SQL Injection check. Applies to: HTML SQL Injection security check. (HTML) 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. Applies to: HTML SQL Injection security check. (HTML) 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.

118

Citrix Application Firewall Guide

Application Firewall Profile Security Check Parameters Parameter -SQLInjectionParseComments

Description Applies to: HTML SQL Injection security check (HTML) -SQLInjectionParseComments checkall: Tells the

Application Firewall to check all comments for SQL. -SQLInjectionParseComments ansi: Tells the

-fieldFormatAction

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. 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

Field Formats check. -fieldFormatAction log: Enables logging for the Field

Formats check. -fieldFormatAction stats: Enables statistics for the -defaultFieldFormatType

Field Formats check. Applies to: Field Format security check. (HTML)

-defaultFieldFormatMinLength

Sets the default Field Format for all form fields in all Web forms protected by the current profile to , where equals either a default or user-defined field type. Applies to: Field Format security check. (HTML)

-defaultFieldFormatMaxLength

Sets the default minimum length for all form fields in all Web forms protected by the current profile to , where equals a positive integer. Applies to: Field Format security check. (HTML)

-bufferOverflowAction

Sets the default maximum length for all form fields in all Web forms protected by the current profile to , where equals a positive integer. 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

Buffer Overflow check. -bufferOverflowAction stats: Enables statistics for the -bufferOverflowMaxURLLength

Buffer Overflow check. Applies to: Buffer Overflow security check. (common) Sets the default maximum length for URLs in requests directed to Web sites protected by the current profile to , where equals a positive integer.

Chapter 4

Profiles

119

Application Firewall Profile Security Check Parameters Parameter -bufferOverflowMaxHeaderLength

Description Applies to: Buffer Overflow security check. (common)

-bufferOverflowMaxCookieLength

Sets the default maximum length for HTTP headers in requests directed to Web sites protected by the current profile to , where equals a positive integer. Applies to: Buffer Overflow security check. (common)

-creditCardAction

Sets the default maximum length for cookies in requests directed to Web sites protected by the current profile to , where equals a positive integer. 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 -creditCard ( visa | mastercard | discover | amex | jcb | dinersclub )

Credit Card check. Applies to: Credit Card security check. (common)

-creditCardMaxAllowed

Enables protection for the designated credit card. Applies to: Credit Card security check. (common)

-creditCardXOut ( ON | OFF )

Sets the maximum number of credit card numbers that the Application Firewall should allow before blocking a response to , where equals a positive integer. Applies to: Credit Card security check. (common)

-xmlDoSAction

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-xxxxxxxx-4567. Applies to: XML Denial-of-Service security check. (XML)

-xmlFormatAction

-xmlDoSAction none: Disables the XML Denial-ofService security check. -xmlDoSAction block: Enables blocking for the XML Denial-of-Service check. -xmlDoSAction learn: Enables learning for the XML Denial-of-Service check. -xmlDoSAction log: Enables logging for the XML Denial-of-Service check. -xmlDoSAction stats: Enables statistics for the XML Denial-of-Service check. 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.

120

Citrix Application Firewall Guide

Application Firewall Profile Security Check Parameters Parameter -xmlSQLInjectionAction

Description 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 xmlSQLInjectionOnlyCheckFieldsWithSQL Chars ( ON | OFF )

-xmlSQLInjectionParseComments

-xmlXSSAction

-xmlWSIAction

the XML SQL Injection check. Applies to: XML SQL Injection security check. (XML) 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. Applies to: XML SQL Injection security check. (XML) -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. 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 CrossSite Scripting check. -xmlXSSAction stats: Enables statistics for the XML Cross-Site Scripting check. 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.

Chapter 4

Profiles

Application Firewall Profile Security Check Parameters Parameter -xmlAttachmentAction

Description 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

XML Attachment check. -xmlAttachmentAction log: Enables logging for the

XML Attachment check. -xmlAttachmentAction stats: Enables statistics for the -xmlValidationAction

XML Attachment check. 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

XML Validation check. -xmlValidationAction stats: Enables statistics for the

-XMLSOAPFaultAction

XML Validation check. 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

-CSRFtagAction

SOAP Faults from responses for the XML SOAP Fault Filtering check. Applies to: CSRF Form Tagging security check. -CSRFtagAction none: Disables the XML SOAP Fault

Filtering check. -CSRFtagAction block: Enables blocking for the XML SOAP Fault Filtering check. -CSRFtagAction log: Enables logging for the XML SOAP Fault Filtering check. -CSRFtagAction stats: Enables statistics for the XML SOAP Fault Filtering check.

121

122

Citrix Application Firewall Guide

Application Firewall Profile Security Check Parameters Parameter -RefererHeaderCheck

Description 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. -responseContentType

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.

Chapter 4

Profiles

123

The Configure Application Firewall Profile Dialog Box, Settings Tab

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:

124

Citrix Application Firewall Guide

•

HTML Settings. •

HTML Error. When it blocks a user’s request, the Application Firewall can either redirect the user’s request to a designated Redirect URL, or it can display an HTML Error Object. •

Redirect URL. To redirect the user’s 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 site’s home page.

•

HTML Error Object. To display an HTML Error Object from the Application Firewall’s 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

Chapter 4

Profiles

125

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 user’s 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.

126

Citrix Application Firewall Guide

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. •

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 appfw profile - [- ]

For , you substitute the name of the profile you are configuring. For , you substitute the first setting. For , 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:

Chapter 4

Profiles

127

set appfw profile Example -errorURL "http://www.example.com/ 404.html"

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 appfw profile Example -stripComments 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 Parameter -htmlErrorObject

-xmlErrorObject

Description Applies to: HTML Error Object, which is sent to the user’s browser when a request for an HTML web page is blocked. Sets the HTML Error Object to , where equals the name of an HTML error object uploaded to the Application Firewall in the Engine Settings Imports page. Applies to: XML Error Object, which is sent to the user’s browser whenever a request for an XML URL is blocked.

-errorURL

Sets the XML Error Page to , where equals the name of an XML error object uploaded to the Application Firewall in the Engine Settings Imports page. Applies to: HTML Redirect URL setting.

-useHTMLErrorObject ( ON | OFF )

Sets the HTML Redirect URL to , where equals either a literal URL or a PCRE-compatible regular expression that evaluates to a URL. 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.

128

Citrix Application Firewall Guide

Application Firewall Profile Settings Parameters Parameter -stripComments ( ON | OFF )

Description Applies to: HTML Comment Stripping.

-defaultCharSet

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. Applies to: Default Character Setting.

-postBodyLimit

Sets the default charset to , where equals one of the charsets supported by the Application Firewall. For a list of charsets and an explanation of each, see Appendix A, ”PCRE Character Encoding Format,” on page 347. Applies to: Maximum size of HTML POST body.

-canonicalizeHTMLResponse ( ON | OFF )

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 . 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. Applies to: HTML responses.

-enableFormTagging ( ON | OFF )

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. Applies to: HTML Web forms.

-excludeFileUploadFromChecks

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. Applies to: All Requests (common)

-invalidPercentHandling

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. Applies to: HTML Requests -invalidPercentHandling apache: Uses Apache mode. -invalidPercentHandling ASP: Uses ASP mode. -invalidPercentHandling secure: Uses secure mode

-checkRequestHeaders ( 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.

Chapter 4

Profiles

129

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 Consistency check.

•

Add any Web forms that contain form fields that the user’s 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.

130

Citrix Application Firewall Guide

•

You probably should manually create an appropriate Field Format assignment 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 information 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 site’s 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.

Chapter 4

Profiles

131

There are two thresholds: •

Minimum number threshold. Depending on which security check’s learning 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 minimum 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 check’s 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 feature’s 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.

132

Citrix Application Firewall Guide To review the learned relaxations for a security check

1.

Log on to the configuration utility, using either the Java client or the Web Start client. (For instructions, see “To log on to the configuration utility” on page 40.)

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

Chapter 4

Profiles

133

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.

134

Citrix Application Firewall Guide

C HAPTER 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 page 65, or any additional configuration you performed in Chapter 12, “Use Cases,” on page 267 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 expressions 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.

136

Citrix Application Firewall 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 Javascript-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

1.

In the navigation pane, expand Application Firewall, and then click Policies.

2.

In the Application Firewall Policies pane, do one of the following.

Chapter 5

3.

Policies

137

•

To create a new policy, click Add.

•

To modify an existing policy, select the policy, and then click Open.

In the Policy Name text box, type a name for your new 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.

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 expression’s 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 page 138.

•

If you are using advanced syntax and need further instructions, see “To create a NetScaler advanced expression by using the configuration utility” on page 142.

7.

Click Create.

8.

Repeat steps 3 through 7 to create additional policies.

138

Citrix Application Firewall Guide

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 perexpression 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.

Chapter 5

Policies

139

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.

The Add Expression Dialog Box 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.

140

Citrix Application Firewall Guide

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.

•

VERSION. 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.

Chapter 5

Policies

141

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.

•

CONTAINS. Contains the following text string.

•

CONTENTS. The contents of the designated header, URL,

or URL query. •

EXISTS. The specified header or query exists.

•

NOTCONTAINS. Does not contain the following text

string. •

NOTEXISTS. 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.

142

Citrix Application Firewall Guide

For example, if you want this policy to operate on requests sent to the host shopping.example.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 steps B through G to create any additional expressions you want for your profile’s 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.

Chapter 5

Policies

143

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.

144

Citrix Application Firewall Guide

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:

Chapter 5

Policies

145

add appfw policy ""

Make the following substitutions: •

For , 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 , 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: "... [.][.]"

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

146

Citrix Application Firewall Guide

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.

•

VERSION. 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

Chapter 5

Policies

147

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.

•

CONTAINS. Contains the following text string.

•

CONTENTS. The contents of the designated header,

URL, or URL query. •

EXISTS. The specified header or query exists.

•

NOTCONTAINS. Does not contain the following text

string. •

NOTEXISTS. The specified header or query does

not exist. •

Value. If you chose the equals (==), does not equal (!=), is greater than (>), CONTAINS, or NOTCONTAINS 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 shopping.example.com, you type the string shopping.example.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.

148

Citrix Application Firewall Guide

"REQ.HTTP.HEADER URL EXISTS"

Since all requests by definition have a URL header, this expression matches all requests. • •

For , substitute the name of the profile you want to associate with this policy.

To create an advanced expression, follow this syntax: ".[.[.[...]]]"

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. 2.

Enter the following command to save your configuration. save ns config

3.

Enter the following command to confirm that your policy was correctly created. show appfw policy

For , 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. rm appfw policy

If your policy was created with a flawed regular expression, you modify it by issuing the following command. set appfw policy ""

You substitute values for , , and as described in the first step of this procedure.

Chapter 5

Policies

149

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 configuration utility” on page 136. 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 page 144, but substituting the set appfw policy command for the add appfw policy command. When you issue the set appfw policy 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 rm appfw policy command, as described in ”To create a policy by using the NetScaler command line,” step 3 on page 148.

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 NetScaler command line. 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.

150

Citrix Application Firewall Guide

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. 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 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. > bind appfw global

For , substitute the name of the policy you want to globally bind. For , substitute a positive integer that represents the priority of this 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

Chapter 5

Policies

151

implements only the first policy that a request matches, not any additional policies that it might also match, policy priority is important to getting the results you intend. 2.

Enter the following command to save your configuration. > save ns con fig

152

Citrix Application Firewall Guide

C HAPTER 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 nonexistent XML application. The blocked requests are for XML-based content 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 structure 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 elements 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.

154

Citrix Application Firewall Guide

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 default_custom_settings.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

1.

In the navigation pane, expand Application Firewall, and then click 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: default_custom_settings.xml and xpath_injection_patterns.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 (default_custom_settings.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:

•

SQL Injection section header. The SQL injection header and opening tag follow the File header:

•

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 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: select insert ... SYS.USER_SYS.PRIVS SYS.USER_TAB_PRIVS

•

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 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:

156

Citrix Application Firewall Guide

' \\ ;

•

Cross-Site Scripting (XSS) section header. The XSS section header and opening tags follow the SQL Injection section ending tag:

•

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 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 allowed tags--> a address b basefont ... tr tt u ul

•

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 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: abbr accesskey ... vspace width

Chapter 6

Imports

157



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.

6.

•

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.”

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: :///[/]

For , substitute the appropriate protocol, which is normally http, but it could be https or ftp if the file is located on a secure Web server or on an FTP server. For , substitute the host name or IP address of the server. For , substitute the path to the object. If the object is in the web root or FTP root directory, the

158

Citrix Application Firewall Guide

path is zero-length and you do not need to type anything. For , substitute the name of the file that contains the object. •

7.

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.

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.log file to verify that the URL you used is accessible from your NetScaler appliance. After correcting the problem, you repeat steps 6 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 steps 4 through 11.

To import a file onto your Application Firewall by 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. For instructions on doing this, see “To log onto the NetScaler command line via SSH,” on page 60.

2.

Upload the file of your choice. •

To upload an HTML error page, enter the following command. import appfw htmlerrorpage

•

To upload an XML error page, enter the following command. import appfw xmlerrorpage

•

To upload an XML schema, enter the following command. import appfw xmlschema

Chapter 6

•

Imports

159

To upload a WSDL, enter the following command. import appfw wsdl

•

To upload a custom settings file, enter the following command. import appfw customsettings

For , substitute the URL or path to and name of the source file. For , 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. 3.

Enter the following command to save your configuration. > save ns config

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 appfw htmlerrorpage

To delete an HTML error page, type the following command: rm appfw htmlerrorpage

•

If you uploaded an XML error page, type the following command to display the entries for all XML error pages on the server: show appfw xmlerrorpage

To delete an XML error page, type the following command: rm appfw xmlerrorpage

•

If you uploaded an XML schema, type the following command to display the entries for all XML schemas on the server: show appfw xmlschema

To delete an XML schema, type the following command: rm appfw xmlschema

•

If you uploaded a WSDL, type the following command to display the entries for all WSDLs on the server: show appfw wsdl

To delete a WSDL, type the following command:

160

Citrix Application Firewall Guide

rm appfw wsdl

•

If you uploaded a custom settings file, type the following command to display the entries for all custom settings files on the server: show appfw customsettings

To delete a custom settings file, type the following command: rm appfw customsettings

C HAPTER 7

Global Configuration

The Application Firewall global configuration affects all profiles and policies. The Global Configuration items are: •

Engine Settings. A collection of global settings—session cookie name, session time-out, maximum session lifetime, logging header name, undefined profile, default profile, and import size limit—that 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 NetScaler command line.

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.

162

Citrix Application Firewall Guide

Cookie Name The Application Firewall uses the session cookie to track user sessions. By default, this cookie is named citrix_ns_id. 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 appfw settings -sessionCookieName

For , 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

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 Session Time-out (seconds), type the number of seconds the Application Firewall waits before timing out a user's session.

4.

Click OK to save your changes.

To modify the session timeout period by using the NetScaler command line

At the NetScaler command prompt, type: set appfw settings -sessionTimeout

Chapter 7

Global Configuration

163

For , 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

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 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.

5.

Click OK to save your changes.

To configure the maximum session lifetime by using the NetScaler command line

At the NetScaler command prompt, type: set appfw settings -sessionlifetime

For , 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

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 Logging Header Name, type the name of the HTTP request header that will contain the client IP.

4.

Click the OK button to save your changes.

164

Citrix Application Firewall Guide To add a logging header by using the NetScaler command line

At the NetScaler command prompt, type: set appfw settings -clientIPLoggingHeader

For , 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

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 Undefined profile, choose a default or user-created profile from the drop-down list.

4.

Click the OK button to save your changes.

To configure the undefined profile by using the NetScaler command line

At the NetScaler command prompt, type: set appfw settings -undefaction

For , 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.

Chapter 7

Global Configuration

165

To configure the default profile 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 Default profile, choose a default or user-created profile from the drop-down list.

4.

Click the OK button to save your changes.

To configure the default profile by using the NetScaler command line

At the NetScaler command prompt, type: set appfw settings -defaultprofile

For , 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

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 Import Size Limit, type the maximum number of bytes allowed for imported files.

4.

Click OK to save your changes.

To configure the import size limit by using the NetScaler command line

At the NetScaler command prompt, type: set appfw settings -importSizeLimit

For , substitute a positive integer that represents the maximum number of bytes allowed for importing files onto the Application Firewall.

166

Citrix Application Firewall Guide

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

1.

In the navigation pane, click Application Firewall.

2.

In the Application Firewall pane, click Manage Confidential Fields.

3.

In the Manage Confidential Fields dialog box, do one of the following.

Chapter 7

Global Configuration

167

•

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: (Applies confidential-field status to all field names that begin with the string “passwd_”.)

•

^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.

168

Citrix Application Firewall Guide

•

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.example.com, but all of those web pages are named logon.pl?, you could use the following regular expression: https?://www[.]example[.]com/([0-9A-Za-z][0-9A-Zaz_.-]*/)*logon[.]pl\?

•

If the Web form appears on multiple web pages on the web host www.example-español.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: https?://www[.]example-espa\xC3\xB1ol[.]com/([0-9AZa-z][0-9A-Za-z_.-]*/)* logon[.]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 query.pl appears on multiple web pages on different hosts within the example.com domain, you could use the following regular expression: "https?://([0-9A-Za-z][0-9A-Za-z_.]*[.])*example[.]com/([0-9A-Za-z][0-9A-Za-z_-.]*/ )*logon[.]pl\?"

•

If the Web form on query.pl appears on multiple web pages on different hosts in different domains, you could use the following regular expression: "https?://([0-9A-Za-z][0-9A-Za-z_-.]*[.])*[0-9A-Zaz][0-9A-Za-z_-.]+[.][a-z]{2,6}/([0-9A-Za-z][0-9A-Zaz_-.]*/)*logon[.]pl\?"

•

If the Web form appears on multiple web pages on the web host www.example.com, but all of those web pages are named logon.pl?, you could use the following regular expression: "https?://www[.]example[.]com/([0-9A-Za-z][0-9A-Zaz_-.]*/)*logon[.]pl\?"

Chapter 7

8.

Global Configuration

169

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 appfw confidField "" [-isRegex ( REGEX | NOTREGEX )] [-comment ""] [-state ( ENABLED | DISABLED )]

To modify an existing confidential field, type the following command at the NetScaler command prompt: set appfw confidField "" [-isRegex ( REGEX | NOTREGEX )

To verify that your confidential field designation is correct, type the following command at the NetScaler command prompt: show appfw confidField

Make the following substitutions: •

For , 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. (Applies confidential-field status to all field names that begin with the string “passwd_”.)

•

^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.)

170

Citrix Application Firewall Guide

•

For , 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. •

If the Web form appears on multiple web pages on the web host www.example.com, but all of those web pages are named logon.pl?, you could use the following regular expression: "https?://www[.]example[.]com/([0-9A-Za-z][0-9A-Za-z_.]*/)*logon[.]pl\?"

•

If the Web form appears on multiple web pages on the web host www.example-español.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: "https?://www[.]example-espa\xC3\xB1ol[.]com/ ([0-9A-Za-z][0-9A-Za-z_-.]*/)*logon[.]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 query.pl appears on multiple web pages on different hosts within the example.com domain, you could use the following regular expression: "https?://([0-9A-Za-z][0-9A-Za-z_-.]*[.])*example[.]com/ ([0-9A-Za-z][0-9A-Za-z_-.]*/)*logon[.]pl\?"

•

If the Web form on query.pl appears on multiple web pages on different hosts in different domains, you could use the following regular expression: "https?://([0-9A-Za-z][0-9A-Za-z_-.]*[.])*[0-9A-Za-z][09A-Za-z_-.]+[.][a-z]{2,6}/([0-9A-Za-z][0-9A-Za-z_-.]*/ )*logon[.]pl\?"

•

If the Web form appears on multiple web pages on the web host www.example.com, but all of those web pages are named logon.pl?, you could use the following regular expression: "https?://www[.]example[.]com/([0-9A-Za-z][0-9A-Za-z_.]*/)*logon[.]pl\?"

Chapter 7

•

Global Configuration

171

Set the -isRegex argument to tell the Application Firewall whether the URL you set was a literal string or a regular expression. NOTREGEX.

•

If you used a literal string for the URL, type -isRegex

•

If you used a regular expression for the URL, type -isRegex

REGEX.

•

If you want to add a comment to your field type, for , substitute a string enclosed in double straight quotation marks.

•

Set the -state 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: •

integer. A string of any length consisting of numbers only, without a decimal point, and with an optional preceding minus sign (-).

•

alpha. A string of any length consisting of letters only.

•

alphanum. A string of any length consisting of letters and/or numbers.

•

nohtml. 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.

172

Citrix Application Firewall Guide 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. 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. 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

Chapter 7

Global Configuration

173

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 steps 4-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 appfw fieldType "" [-comment ""]>

To modify an existing field type, type the following command at the NetScaler command prompt: set appfw fieldType "" [-comment ""]>

To verify that you created your field type correctly, type the following command at the NetScaler command prompt: show appfw fieldType "" [-comment ""]>

Make the following substitutions: •

For , 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 , 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,

174

Citrix Application Firewall Guide

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 , 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 , substitute a string enclosed in double straight quotation marks.

C HAPTER 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.

176

Citrix Application Firewall Guide To configure the general settings 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 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 protected 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 happens, 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-

178

Citrix Application Firewall Guide

tics.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.

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 disable/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 page 215. The Application Firewall can handle the HTTP Referer header in one of the following three ways, depending on which option you select in the dropdown list: -

Off. Do not validate the Referer header. This is the default setting for profiles created with basic defaults.

Chapter 8

-

The Common Security Checks

179

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

1.

In the navigation pane, expand Application Firewall, and then click Profiles.

2.

In the Application Firewall Profiles pane, select a profile, and then click Open.

3.

In the Configure Application Firewall Profiles dialog box, click the Security Checks tab.

4.

Click Start URL, and then click Modify.

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.

180

Citrix Application Firewall Guide

•

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 page 122. 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 nonASCII characters, you must enter those characters manually using the PCRE hexadecimal character encoding format. Note: See Appendix A, ”PCRE Character Encoding Format,” on page 347, 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.example.com: ^http://www[.]example[.]com$

•

Allow users to access all static HTML (.htm and .html), server-parsed HTML (.htp and .shtml), PHP (.php), and Microsoft ASP (.asp) format web pages at www.example.com: ^http://www[.]example[.]com/([0-9A-Za-z][0-9A-Za-z_-]*/)* [0-9A-Za-z][0-9A-Za-z_.-]*[.](asp|htp|php|s?html?)$

•

Allow users to access the same files at www.example-español.com, which contains the n-tilde (ñ) 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: ^http://www[.]example-espa\xC3\xB1ol[.]com/([0-9A-Za-z][0-9AZa-z_-]*/)* [0-9A-Za-z][0-9A-Za-z_.-]*[.](asp|htp|php|s?html?)$

•

Allow users to access web pages with pathnames or filenames that contain non-ASCII characters:

Chapter 8

The Common Security Checks

181

^http://www[.]example-espa\xC3\xB1ol[.]com/(([0-9A-Zaz]|\\x[0-9A-Fa-f][0-9A-Fa-f])([0-9A-Za-z_-]|\\x[0-9A-Fa-f][09A-Fa-f])*/)* ([0-9A-Za-z]|\\x[0-9A-Fa-f][0-9A-Fa-f])([0-9A-Za-z_-]|\\x[09A-Fa-f][0-9A-Fa-f])*[.](asp|htp|php|s?html?)$

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 properlyconstructed 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 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. •

Allow users to access all GIF (.gif), JPEG (.jpg and .jpeg), and PNG (.png) format graphics at www.example.com: ^http://www[.]example[.]com/([0-9A-Za-z][0-9A-Za-z_-]*/)* [0-9A-Za-z][0-9A-Za-z_.-]*[.](gif|jpe?g|png)$

•

Allow users to access CGI (.cgi) and PERL (.pl) scripts in the CGI-BIN directory only at www.example.com: ^http://www[.]example[.]com/CGI-BIN/[0-9A-Za-z][0-9A-Za-z_.]*[.](cgi|pl)$

•

Allow users to access downloadable Microsoft Office and other document files in the docsarchive directory only at www.example.com: ^http://www[.]example[.]com/docsarchive/[0-9A-Za-z][0-9A-Zaz_-.]*[.](doc|xls|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.

182

Citrix Application Firewall Guide

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. 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 Deny URL dialog box. To configure the general settings 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 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 Deny 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 Deny URL, and then click Modify.

5.

In the Modify Deny URL Check dialog box, click the General tab.

6.

Under Actions, enable or disable each of the actions described in “Modify Deny URL Check Actions”.

7.

Click OK when finished, and click Close to close the dialog box.

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. Enabled by default in profiles created with both basic and advanced defaults. Clear/select the Deny URL check to disable/enable blocking.

Chapter 8

The Common Security Checks

183

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 troubleshooting.

•

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 protected 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

1.

In the navigation pane, expand Application Firewall, and then click Profiles.

2.

In the Application Firewall Profiles pane, select a profile, and then click Open.

3.

In the Configure Application Firewall Profiles dialog box, click the Security Checks tab.

4.

Click Deny URL, and then click Modify.

5.

In the Deny URL Check dialog box, do one of the following:

184

Citrix Application Firewall Guide

•

To create a new deny URL, click Add to open the Add Deny 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 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 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 page 122. 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 nonASCII characters, you must enter those characters manually using the PCRE hexadecimal character encoding format. Note: See Appendix A, ”PCRE Character Encoding Format,” on page 347, 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 deny URLs, or if you have modified an existing deny URL, click Close.

Chapter 8

The Common Security Checks

185

Examples

Below are several examples of Deny URLs. •

Do not allow users to access the image server at images.example.com directly: ^http://images[.]example[.]com$

•

Do not allow users to access CGI (.cgi) or PERL (.pl) scripts directly: ^http://www[.]example[.]com/([0-9A-Za-z][0-9A-Za-z_-]*/)* [0-9A-Za-z][0-9A-Za-z_.-]*[.](cgi|pl)$

•

Deny users direct access to CGI (.cgi) or PERL (.pl) scripts at the host http://www.example-español.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: ^http://www[.]example-espa\xC3\xB1ol[.]com/([0-9A-Za-z][0-9AZa-z_-]*/)* [0-9A-Za-z][0-9A-Za-z_.-]*[.](cgi|pl)$

Note: See Appendix A, ”PCRE Character Encoding Format,” on page 347 for a complete description of supported characters and how to encode them properly when configuring the Application Firewall. •

Deny users direct access to scripts at the host http://www.exampleespañol.com, when the server contains pathnames or filenames that contain non-ASCII characters: ^http://www[.]example-espa\xC3\xB1ol[.]com/(([0-9A-Zaz]|\\x[0-9A-Fa-f][0-9A-Fa-f])([0-9A-Za-z_-]|\\x[0-9A-Fa-f][09A-Fa-f])*/)* ([0-9A-Za-z]|\\x[0-9A-Fa-f][0-9A-Fa-f])([0-9A-Za-z_-]|\\x[09A-Fa-f][0-9A-Fa-f])*[.](cgi|pl)$

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 properlyconstructed 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 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.

186

Citrix Application Firewall Guide

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 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 user’s credentials, and thereby gain access to sensitive private information, or to cause a buffer overflow. The Buffer Overflow check, discussed on page 190, 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. To configure the general settings 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 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 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.

Chapter 8

The Common Security Checks

187

5.

In the Modify Cookie Consistency Check dialog box, click the General tab.

6.

Under Actions, enable or disable each of the actions described in “Modify 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 Consistency 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 Javascripts 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.

•

Learn. Use the learning feature to observe traffic to and from your protected 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

188

Citrix Application Firewall Guide

enable learning, logging, and statistics, and then follow the Cookie Consistency 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 happens, the logs are an important resource for troubleshooting.

•

Statistics. Generate statistics for 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 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

1.

In the navigation pane, expand Application Firewall, and then click Profiles.

2.

In the Application Firewall Profiles pane, select a profile, and then click Open.

3.

In the Configure Application Firewall Profiles dialog box, click the Security Checks tab.

4.

Click Cookie Consistency, and then click Modify.

Chapter 8

5.

6.

The Common Security Checks

189

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 Consistency Check Relaxation dialog box.

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.

•

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 page 122. 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.

Note: See Appendix A, ”PCRE Character Encoding Format,” on page 347, for a complete description of supported characters and how to encode them properly when configuring the Application Firewall. 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 logon_ and are followed with the user’s logon name to be user-modifiable: ^logon_[0-9A-Za-z]+$

190

Citrix Application Firewall Guide

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 Turkishspeaking customers, you might have a cookie that begins with the string türkçe-logon_. The special characters in that string must be represented as encoded UTF-8 strings. ^t\xC3\xBCrk\xC3\xA7e-logon_[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\xBCrk\xC3\xA7e-logon_([0-9A-Za-z]|\\x[0-9A-Fa-f][0-9AFa-f])+$

Note: See Appendix A, ”PCRE Character Encoding Format,” on page 347 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-item_, followed by the ID of an item that the user has added to his shopping cart ([0-9A-Za-z]+), a second underscore (_), and finally the number of these items he wants ([19][0-9]?), to be user-modifiable: ^sc-item_[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. 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 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.

Chapter 8

The Common Security Checks

191

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. 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 Buffer Overflow dialog box. To configure the general settings 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 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 Buffer Overflow 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 Buffer Overflow, and then click Modify.

5.

In the Modify Buffer Overflow Check dialog box, click the General tab.

6.

Under Actions, enable or disable each of the actions described in “Modify Buffer Overflow Check Actions”.

7.

Click OK when finished, and click Close to close the dialog box.

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. Enabled by default in profiles created with both basic and advanced 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.

192

Citrix Application Firewall Guide

•

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 security check. If anything unexpected happens, the logs are an important resource for troubleshooting.

•

Statistics. Generate statistics for 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 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 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

1.

In the navigation pane, expand Application Firewall, and then click Profiles.

2.

In the Application Firewall Profiles pane, select a profile, and then click Open.

3.

In the Configure Application Firewall Profiles dialog box, click the Security Checks tab.

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.

Chapter 8

-

6.

The Common Security Checks

193

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.

Click Create or OK. If finished creating new relaxations, or if you have modified an existing relaxation, click Close.

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 x’s. For example, a credit card number of 9876-5432-1234-5678 would be rendered 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. 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 Credit Card Check dialog box. To configure the general settings 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 profile, and then click Open.

194

Citrix Application Firewall Guide

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 Credit Card 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 Credit Card, and then click Modify.

5.

In the Modify Credit Card Check dialog box, click the General tab.

6.

Under Actions, enable or disable each of the actions described in “Modify Credit Card Check Actions”.

7.

Click OK when finished, and click Close to close the dialog box.

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 effective 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.

Chapter 8

The Common Security Checks

195

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

1.

In the navigation pane, expand Application Firewall, and then click Profiles.

2.

In the Application Firewall Profiles pane, select a profile, and then click Open.

3.

In the Configure Application Firewall Profiles dialog box, click the Security Checks tab.

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 Shift or Ctrl 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.

6.

Click Create or OK. If finished creating new relaxations, or if you have modified an existing relaxation, click Close.

196

Citrix Application Firewall Guide

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

1.

In the navigation pane, expand Application Firewall, and then click Profiles.

2.

In the Application Firewall Profiles pane, select a profile, and then click Open.

3.

In the Configure Application Firewall Profiles dialog box, click the Security Checks tab.

4.

Click Start URL, and then click Modify.

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.

6. In the dialog box, configure the following elements: •

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.

Chapter 8

•

•

The Common Security Checks

197

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. 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 page 122. The regular expression you type must consist of ASCII characters only. Do not cut and paste characters outside of the basic 128character ASCII set. If you want to include non-ASCII characters, you must enter those characters manually using the PCRE hexadecimal character encoding format. Note: See Appendix A, ”PCRE Character Encoding Format,” on page 347, for a complete description of supported characters and how to encode them properly when configuring the Application Firewall.

198

Citrix Application Firewall Guide

•

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 driver’s 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 consist 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 driver’s 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-

Chapter 8

The Common Security Checks

199

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}

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 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.

200

Citrix Application Firewall Guide

C HAPTER 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.

202

Citrix Application Firewall Guide

•

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. 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 Deny URL dialog box. To configure the general settings 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 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 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.

6.

Under Actions, enable or disable each of the actions described in “Modify Form Field Consistency Check Actions”.

7.

Click OK when finished, and then click Close to close the dialog box.

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 user’s 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.

•

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 recommended form field relaxations to add to the Form Field Consistency relaxations 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

204

Citrix Application Firewall Guide

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. To disable learning and still avoid false positives, you must manually add any Web forms modified on the user’s browser to the Form Field 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. Tells the Application Firewall to log any 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 logging. If you created a profile with basic defaults, you should not enable logging 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 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 troubleshoot.

•

Statistics. Tells the Application Firewall to generate statistics for 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 statistics. If you created a profile with basic defaults, you should not enable statistics 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 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.

Chapter 9

The HTML Security Checks

205

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

1.

In the navigation pane, expand Application Firewall, and then click Profiles.

2.

In the Application Firewall Profiles pane, select a profile, and then click Open.

3.

In the Configure Application Firewall Profiles dialog box, click the Security Checks tab.

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 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 Form Field Consistency list and click Open to open the Modify Form Field Consistency 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.

•

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 page 122 and following.

206

Citrix Application Firewall Guide

The regular expression you type must consist of ASCII characters 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 Appendix A, ”PCRE Character Encoding Format,” on page 347. Caution: If any Web form on your protected Web sites has a field named as_fid, 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 page 126 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. 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 page 122 and following. Note: The regular expression you type must consist of ASCII characters only. Do not cut and paste an action URL that contains any characters outside of the basic ASCII character set. If you want to include an action URL that contains non-ASCII characters, you must enter those characters manually using the PCRE hexadecimal character encoding format. For more information, see Appendix A, ”PCRE Character Encoding Format,” on page 347.

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 Form Field Consistency relaxations. •

Choose form fields with the name UserType: ^UserType$

Chapter 9

•

The HTML Security Checks

207

Choose form fields with names beginning with UserType_ 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: ^UserType_[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 Türkçe-UserType_ on their logon page. The special characters in that string must be represented as encoded UTF-8 strings. ^T\xC3\xBCrk\xC3\xA7e-UserType_[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\xBCrk\xC3\xA7e-UserType_([0-9A-Za-z]|\\x[0-9A-Fa-f][09A-Fa-f])+$

Note: See Appendix A, ”PCRE Character Encoding Format,” on page 347, for a complete description of supported special characters and how to encode them properly when configuring the Application Firewall. •

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 http://www.example.com/ search.pl?, and containing any string after the query except for a new query: ^http://www[.]example[.]com/search[.]pl\?[^?]*$

•

Choose URLs beginning with http://www.example-español.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: ^http://www[.]example-espa\xC3\xB1ol[.]com/([0-9A-Za-z][0-9AZa-z_-]*/)* [0-9A-Za-z][0-9A-Za-z_-.]*[.](asp|htp|php|s?html?)$

•

Allow users to access web pages beginning with http://www.exampleespañol.com, when the server contains pathnames or filenames that contain non-ASCII characters:

208

Citrix Application Firewall Guide

^http://www[.]example-espa\xC3\xB1ol[.]com/(([0-9A-Zaz]|\\x[0-9A-Fa-f][0-9A-Fa-f])([0-9A-Za-z_-]|\\x[0-9A-Fa-f][09A-Fa-f])*/)* ([0-9A-Za-z]|\\x[0-9A-Fa-f][0-9A-Fa-f])([0-9A-Za-z_-]|\\x[09A-Fa-f][0-9A-Fa-f])*[.](asp|htp|php|s?html?)$

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 properlyconstructed 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 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. Note: See Appendix A, ”PCRE Character Encoding Format,” on page 347 for a complete description of supported characters and how to encode them properly when configuring the Application Firewall. •

Choose all URLs that contain the string /search.cgi?: ^[^?]*/search[.]cgi\?[^?]*$

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 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 user’s request. This check applies to HTML requests only; it does not apply to XML requests.

Chapter 9

The HTML Security Checks

209

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 user’s 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. In any of your Application Firewall profiles, you configure general settings for 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. To configure the general settings 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 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 Field Formats 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 Field Formats, and then click Modify.

210

Citrix Application Firewall Guide

5.

In the Modify Field Formats Check dialog box, click the General tab.

6.

Under Actions, enable or disable each of the actions described in “Modify Field Formats Check Actions”.

7.

Click OK when finished, and then click Close to close the dialog box.

Modify Field Format Check Actions The Check Actions control how the Field Format check functions. They are: •

Block. Tells the Application Firewall to block connections that violate the 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.

•

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 recommended 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. If you created a profile with basic defaults, you should not 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.

Chapter 9

The HTML Security Checks

211

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. •

Log. Tells the Application Firewall to log any connections that violate the 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 anything unexpected happens, the logs are an important resource to troubleshoot.

•

Statistics. Tells the Application Firewall to generate statistics for connections 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.

212

Citrix Application Firewall Guide

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

1.

In the navigation pane, expand Application Firewall, and then click Profiles.

2.

In the Application Firewall Profiles pane, select a profile, and then click Open.

3.

In the Configure Application Firewall Profiles dialog box, click the Security Checks tab.

4.

Click Field Formats, and then click Modify.

5.

In the Modify Field Formats Check dialog box, do one of the following:

6.

•

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.

In the dialog box, configure the following elements: •

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.

•

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 page 122 and following.

Chapter 9

The HTML Security Checks

213

Note: The regular expression you type must consist of ASCII characters only. Do not cut and paste a 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 Appendix A, ”PCRE Character Encoding Format,” on page 347. •

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. 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 page 122 and following.

•

•

7.

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 page 167.

•

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.

Click Create or OK. If finished creating new expressions, or if you have modified an existing expression, click Close.

214

Citrix Application Firewall Guide Examples

Below are several examples of Field Name relaxations. •

Choose form fields with the name FirstName: ^FirstName$

•

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}$

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 Türkçe-FirstName_ on their logon page. The special characters in that string must be represented as encoded UTF-8 strings. ^T\xC3\xBCrk\xC3\xA7e-FirstName_[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\xBCrk\xC3\xA7e-FirstName_([0-9A-Za-z]|\\x[0-9A-Fa-f][09A-Fa-f])+$

Note: See Appendix A, ”PCRE Character Encoding Format,” on page 347 for a complete description of supported special characters and how to encode them properly when configuring the Application Firewall. •

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]*$

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 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.

Chapter 9

•

The HTML Security Checks

215

Choose URLs beginning with http://www.example.com/ search.pl?, and containing any string after the query except for a new query: ^http://www[.]example[.]com/search[.]pl\?[^?]*$

•

Choose URLs beginning with http://www.example-español.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: ^http://www[.]example-espa\xC3\xB1ol[.]com/([0-9A-Za-z][0-9AZa-z_-]*/)* [0-9A-Za-z][0-9A-Za-z_-.]*[.](asp|htp|php|s?html?)$

•

Allow users to access web pages beginning with http://www.exampleespañol.com, when the server contains pathnames or filenames that contain non-ASCII characters: ^http://www[.]example-espa\xC3\xB1ol[.]com/(([0-9A-Zaz]|\\x[0-9A-Fa-f][0-9A-Fa-f])([0-9A-Za-z_-]|\\x[0-9A-Fa-f][09A-Fa-f])*/)* ([0-9A-Za-z]|\\x[0-9A-Fa-f][0-9A-Fa-f])([0-9A-Za-z_-]|\\x[09A-Fa-f][0-9A-Fa-f])*[.](asp|htp|php|s?html?)$

•

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 properlyconstructed 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 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. Note: See Appendix A, ”PCRE Character Encoding Format,” on page 347 for a complete description of supported characters and how to encode them properly when configuring the Application Firewall.

•

Choose URLs that contain the string /search.cgi?: ^[^?]*/search[.]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.

216

Citrix Application Firewall Guide

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 page 175. In any of your Application Firewall profiles, you configure general settings for the CSRF Form Tagging 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 Cross Site Request Forgery Tagging Check dialog box. To configure the general settings 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 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 CSRF Form Tagging entry, you can select or clear check boxes to enable or disable actions that can be taken when a connection does not

Chapter 9

The HTML Security Checks

217

meet the specified criteria. To access all of the general settings, continue with the following steps. 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.

6.

Under Actions, enable or disable each of the actions described in “Modify CSRF Form Tagging Check Actions”.

7.

Click OK when finished, and then click Close to close the dialog box.

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 relaxations.

•

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. Disabled 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.

218

Citrix Application Firewall Guide

•

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 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 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

1.

In the navigation pane, expand Application Firewall, and then click Profiles.

2.

In the Application Firewall Profiles pane, select a profile, and then click Open.

3.

In the Configure Application Firewall Profiles dialog box, click the Security Checks tab.

4.

Click CSRF Form Tagging, and then click Modify.

5.

In the Modify CSRF Form Tagging Check dialog box, do one of the following:

6.

•

To create a new relaxation, click Add to open the Add CSRF Form Tagging 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 CSRF Form Tagging list and click Open to open the Modify CSRF Form Tagging Check Relaxation dialog box.

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.

•

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

Chapter 9

The HTML Security Checks

219

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 page 122. 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 an expression that contains non-ASCII characters, you must enter those characters manually using the PCRE hexadecimal character encoding format. Note: See Appendix A, ”PCRE Character Encoding Format,” on page 347, for a complete description of supported characters and how to encode them properly when configuring the Application Firewall. •

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. 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 page 122. 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 an 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 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 crosssite 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.

220

Citrix Application Firewall Guide

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 Javascript-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 Appendix C, ”Configuring for Large Files and Web Pages,” on page 369. In any of your Application Firewall profiles, you configure general settings for 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. To configure the general settings 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 profile, and then click Open.

3.

In the Configure Application Firewall Profile dialog box, click the Security Checks tab.

Chapter 9

The HTML Security Checks

221

A list of all the security checks that apply to this profile type appears. 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.

6.

Under Actions, enable or disable each of the actions described in “Modify HTML Cross-Site Scripting Check Actions”.

7.

Click OK when finished, and then click Close to close the dialog box.

Modify HTML Cross-Site Scripting Check Actions The Check Actions control how the HTML Cross-Site Scripting check functions. They are: •

Block. Tells the Application Firewall to block connections that violate 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 blocking.

•

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 recommended 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 disable/enable learning. If you created a profile with basic defaults, you should not 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

222

Citrix Application Firewall Guide

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. •

Log. Tells the Application Firewall to log any connections that violate 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 logging. You normally will not want to disable logging for this or any check. If anything unexpected happens, the logs are an important resource to troubleshoot.

•

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 (>).

This ensures that browsers do not interpret unsafe html tags, such as , 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.

Chapter 9

The HTML Security Checks

223

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 Firewall 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 CrossSite 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

1.

In the navigation pane, expand Application Firewall, and then click Profiles.

2.

In the Application Firewall Profiles pane, select a profile, and then click Open.

3.

In the Configure Application Firewall Profiles dialog box, click the Security Checks tab.

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:

6.

•

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 CrossSite Scripting list and click Open to open the Modify HTML Cross-Site Scripting Check Relaxation dialog box.

In the dialog box, configure the following elements:

224

Citrix Application Firewall Guide

•

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.

•

Field Name. In the text area in the Field Name section, you enter 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. 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 page 122 and following.

•

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. 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 page 122 and following. Note: 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 ASCII character 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. For more information, see Appendix A, ”PCRE Character Encoding Format,” on page 347.

•

•

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.

Chapter 9

The HTML Security Checks

225

Examples

Below are several examples of expressions that can be used in this check. •

Check all fields beginning with the string logon_ 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: ^logon_[0-9A-Za-z]{2,15}$

•

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}$

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 Türkçe-Name_ on their logon page. The special characters in that string must be represented as encoded UTF-8 strings. ^T\xC3\xBCrk\xC3\xA7e-Name_[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\xBCrk\xC3\xA7e-Name_([0-9A-Za-z]|\\x[0-9A-Fa-f][0-9AFa-f])+$

Note: See Appendix A, ”PCRE Character Encoding Format,” on page 347 for a complete description of supported special characters and how to encode them properly when configuring the Application Firewall. •

Check all fields beginning with the string sessionid- and followed by a ten-digit number: ^sessionid-[0-9]{10,10}$

Below are several example URL expressions. •

Check all URLs beginning with the string query_ and followed by a string of upper- and lower-case letters or numbers that is at least two characters long and no more than forty characters long, and ending with the string .js: ^query_[0-9A-Za-z]{2,40}[.]js$

•

Check all URLs containing the string prodinfo in the path: ^https?://[0-9A-Za-z._-]*/[^?]*\?prodinfo[^?]*$

226

Citrix Application Firewall Guide

•

Check all URLs containing the string prodinfo in the path, on servers with hostnames, pathnames or filenames that contain non-ASCII characters: ^https?://(([0-9A-Za-z]|\\x[0-9A-Fa-f][0-9A-Fa-f])(([0-9A-Zaz_-]|\\x[0-9A-Fa-f][0-9A-Fa-f]+[.])+[a-z]{2,6}/ [^?]*\?prodinfo[^?]*$

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 properlyconstructed 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 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. 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 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.

Note: See Appendix A, ”PCRE Character Encoding Format,” on page 347 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.

Chapter 9

The HTML Security Checks

227

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. 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.

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 Appendix C, ”Configuring for Large Files and Web Pages,” on page 369. In any of your Application Firewall profiles, you configure general settings for the HTML SQL Injection 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 SQL Injection Check dialog box. To configure the general settings 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 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 HTML SQL Injection 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 SQL Injection, and then click Modify.

5.

In the Modify HTML SQL Injection Check dialog box, click the General tab.

6.

Under Actions, enable or disable each of the actions described in “Modify HTML SQL Injection Check Actions”.

228

Citrix Application Firewall Guide

7.

Click OK when finished, and then click Close to close the dialog box.

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 disabling it by checking the Block check box.

•

Learn. Tells the Application Firewall to use its learning engine to observe traffic to and from your protected Web sites, and generate a list of recommended 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. If you created a profile with basic defaults, you should not enable learning 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.

•

Log. Tells the Application Firewall to log any connections that violate the HTML SQL Injection check. Enabled by default in profiles created with both basic and advanced defaults. You disable logging for the HTML SQL

Chapter 9

The HTML Security Checks

229

Injection check by clearing the Log check box, and re-enable logging after disabling it by checking the Log check box. You normally will not want to disable logging for this or any check. If anything unexpected happens, the logs are an important resource to troubleshoot. •

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 statistics after disabling it by checking the Statistics check box. 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 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. Disabled 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

230

Citrix Application Firewall Guide

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. •

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. 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 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 server’s response to profile your SQL server’s 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.

Chapter 9

The HTML Security Checks

231

-

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, and skip those comments when filtering requests for violations of the 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

1.

In the navigation pane, expand Application Firewall, and then click Profiles.

2.

In the Application Firewall Profiles pane, select a profile, and then click Open.

3.

In the Configure Application Firewall Profiles dialog box, click the Security Checks tab.

4.

Click HTML SQL Injection, and then click Modify.

5.

In the Modify HTML SQL Injection Check dialog box, do one of the following:

232

Citrix Application Firewall Guide

6.

•

To create a new relaxation, click Add to open the Add HTML SQL Injection 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 SQL Injection list and click Open to open the Modify HTML SQL Injection Check Relaxation dialog box.

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.

•

Field Name. In the text area in the Field Name section, you enter 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. 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 page 122 and following.

•

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. 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 page 122 and following. Note: 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 ASCII character 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. For more information, see Appendix A, ”PCRE Character Encoding Format,” on page 347.

Chapter 9

•

•

7.

The HTML Security Checks

233

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.

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 logon_ 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: ^logon_[0-9A-Za-z]{2,15}$

•

Choose form fields with names beginning with logon_ 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: ^logon_[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 türkçe-logon_ on their logon page. The special characters in that string must be represented as encoded UTF-8 strings. ^t\xC3\xBCrk\xC3\xA7e-logon_[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\xBCrk\xC3\xA7e-logon_([0-9A-Za-z]|\\x[0-9A-Fa-f][0-9AFa-f])+$

234

Citrix Application Firewall Guide

Note: See Appendix A, ”PCRE Character Encoding Format,” on page 347 for a complete description of supported special characters and how to encode them properly when configuring the Application Firewall. •

Check all fields beginning with the string sessionid- and followed by a ten-digit number: ^sessionid-[0-9]{10,10}$

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 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 query_ and followed by a string of upper- and lower-case letters or numbers that is at least two characters long and no more than forty characters long, and ending with the string.js: ^query_[0-9A-Za-z]{2,40}[.]js$

•

Check all URLs beginning with the same string as above, on servers with hostnames, pathnames or filenames that contain non-ASCII characters: ^query_([0-9A-Za-z]|\\x[0-9A-Fa-f][0-9A-Fa-f]){2,40}[.]js$

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 properlyconstructed 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 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. Note: See Appendix A, ”PCRE Character Encoding Format,” on page 347 for a complete description of supported characters and how to encode them properly when configuring the Application Firewall.

C HAPTER 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 characters—such 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.

236

Citrix Application Firewall Guide

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. In any of your Application Firewall profiles, you configure general settings for 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. To configure the general settings 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 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 XML Format 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 XML Format, and then click Modify.

5.

Under Actions, enable or disable each of the actions described in “Modify XML Format Check Actions”.

6.

Click OK when finished, and then click Close to close the dialog box.

Modify XML Format Check Actions The Check Actions control how the XML Format check functions. They are: •

Block. Tells the Application Firewall to block connections that violate the 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.

•

Log. Tells the Application Firewall to log any connections that violate the 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. You normally will not want to disable logging for this or any check. If anything unexpected happens, the logs are an important resource to troubleshoot.

•

Statistics. Tells the Application Firewall to generate statistics for connections 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. 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.

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-ofservice (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 denialof-service attack on your server or application. In any of your Application Firewall profiles, you configure general settings for 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.

238

Citrix Application Firewall Guide To configure the general settings 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 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 XML Denial of Service 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 XML Denial of Service, and then click Modify.

5.

In the Modify XML Denial of Service Check dialog box, click the General tab.

6.

Under Actions, enable or disable each of the actions described in “Modify XML Denial of Service Check Actions”.

7.

Click OK when finished, and then click Close to close the dialog box.

Modify XML Denial of Service Check Actions The Check Actions control how the XML Denial of Service check functions. They are: •

Block. Tells the Application Firewall to block connections that violate the 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.

•

Learn. Use the learning feature to observe traffic to and from your protected 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. For a profile with basic defaults, you should not enable learning for the XML DoS security check unless your application needs additional protection beyond that provided by the default XML DoS rule set. If you

Chapter 10

The XML Security Checks

239

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. For a profile with advanced defaults, you can either leave learning enabled, 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. •

Log. Tells the Application Firewall to log any connections that violate the 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 disabling it by checking the Log check box. You normally will not want to disable logging for this or any check. If anything unexpected happens, the logs are an important resource to troubleshoot.

•

Statistics. Tells the Application Firewall to generate statistics for connections that violate the XML DoS check. Enabled by default. You disable statistics for the XML DoS check by clearing the Statistics check box, and reenable statistics after disabling it by checking the Statistics check box. 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.

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

1.

In the navigation pane, expand Application Firewall, and then click Profiles.

2.

In the Application Firewall Profiles pane, select a profile, and then click Open.

240

Citrix Application Firewall Guide

3.

In the Configure Application Firewall Profiles dialog box, click the Security Checks tab.

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 page 240.

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 Maximum Element Depth

Maximum Element Name Length

Description 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. 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

Maximum # Elements

Maximum # Element Children

Maximum # Attributes

Maximum Attribute Name Length

Maximum Attribute Value Length

Maximum CDATA Section Length

The user can modify the maximum name length to any value between one (1) character and 65,535. 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. 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. 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. 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. Restricts the maximum length of each attribute value to 2048 characters. The user can modify the maximum attribute name length to any value between one (1) and 2,048. 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 between one (1) and 65,535.

Chapter 10

The XML Security Checks

241

The XML DoS Rules Rule Maximum File Size Minimum File Size

Maximum # Entity Expansions Maximum Entity Expansion Depth Maximum # Namespaces Maximum Namespace URI Length Block Processing Instructions Block DTD Block External Entities

Description Restricts the size of each file to 20 MB. The user can modify the maximum file size to any value. 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. Limits the number of entity expansions allowed to the specified number. Default: 1024. Restricts the maximum number of nested entity expansions to no more than the specified number. Default: 32. Limits the number of namespace declarations in an XML document to no more than the specified number. Default: 16 Limits the URL length of each namespace declaration to no more than the specified number of characters. Default: 256 Blocks any special processing instructions included in the request. This rule has no user-modifiable values. Blocks any DTD included with the request. This rule has no usermodifiable values. Blocks all external entities references by the request. This rule has no usermodifiable values.

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. 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.

242

Citrix Application Firewall Guide

In any of your Application Firewall profiles, you configure general settings for the XML 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 XML Cross-Site Scripting Check dialog box. To configure the general settings 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 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 XML 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 XML Cross-Site Scripting, and then click Modify.

5.

Under Actions, enable or disable each of the actions described in “Modify XML Cross-Site Scripting Check Actions”.

6.

Click OK when finished, and then click Close to close the dialog box.

Modify XML Cross-Site Scripting Check Actions The Check Actions control how the XML Cross-Site Scripting check functions. They are: •

Block. Tells the Application Firewall to block connections that violate the 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 configuration, however, you can disable this check and then monitor your logs to determine whether any XML requests containing cross-site scripts are legitimately sent to your protected application. If you do spot any such requests, you may want to consider modifying the application to remove this vulnerability rather than disabling this important security check for your application.

Chapter 10

The XML Security Checks

243

•

Learn. The learning feature is not available with the XML Cross-Site Scripting check, so the Learn check box is greyed out.

•

Log. Tells the Application Firewall to log any connections that violate the 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. You normally will not want to disable logging for this or any check. If anything unexpected happens, the logs are an important resource to troubleshoot.

•

Statistics. Tells the Application Firewall to generate statistics for connections 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 checking the Statistics check box. 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.

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 SQLbased 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. 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.

244

Citrix Application Firewall Guide

In any of your Application Firewall profiles, you configure general settings for the XML SQL Injection 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 SQL Injection Check dialog box. To configure the general settings 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 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 XML SQL Injection 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 XML SQL Injection, and then click Modify.

5.

Under Actions, enable or disable each of the actions described in “Modify XML SQL Injection Check Actions”.

6.

Click OK when finished, and then click Close to close the dialog box.

Modify XML SQL Injection Check Actions The Check Actions control how the XML SQL Injection check functions. They are: •

Block. Tells the Application Firewall to block connections that violate the XML SQL Injection check. Enabled by default. You disable blocking for the XML SQL Injection check by clearing the Block check box, and reenable 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 Application 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 application. 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.

Chapter 10

The XML Security Checks

245

•

Learn. The learning feature is not available with the XML SQL Injection check, so the Learn check box is greyed out.

•

Log. Tells the Application Firewall to log any connections that violate the 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. You normally will not want to disable logging for this or any check. If anything unexpected happens, the logs are an important resource to troubleshoot.

•

Statistics. Tells the Application Firewall to generate statistics for connections 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 Statistics check box. 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.

Beneath the Actions area is the Parameters area, which contains additional configuration items. •

Restrict checks to fields containing SQL special characters. Tells the Application Firewall to check only XML that contains SQL special characters 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.

•

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 XML SQL Injection check. You can also thwart attackers who may send requests containing comments and observe your Web server’s response to profile your SQL server’s 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

246

Citrix Application Firewall Guide

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 XML 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 XML SQL Injection check.

-

ANSI/Nested. Tells the Application Firewall to recognize comments that adhere to both the ANSI and nested SQL comment standards, and skip those comments when filtering requests for violations of the 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. In any of your Application Firewall profiles, you configure general settings for the XML Attachment 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 Attachment Check dialog box.

Chapter 10

The XML Security Checks

247

To configure the general settings 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 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 XML Attachment 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 XML Attachment, and then click Modify.

5.

In the Modify XML Attachment Check dialog box, click the General tab.

6.

Under Actions, enable or disable each of the actions described in “Modify XML Attachment Check Actions”.

7.

Click OK when finished, and then click Close to close the dialog box.

Modify XML Attachment Check Actions The Check Actions control how the XML Attachment check functions. They are: •

Block. Tells the Application Firewall to block connections that violate the 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.

•

Learn. Use the learning feature to observe traffic to and from your protected 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

248

Citrix Application Firewall Guide

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. For a profile with advanced defaults, you can either leave learning enabled, 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 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 reenable blocking, and are done. To disable learning and still avoid false positives, you must manually add any XML attachments that you expect your protected application to receive from users, but that violate this check, to the XML Attachment check relaxations 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. •

Log. Tells the Application Firewall to log any connections that violate the XML Attachment check. Enabled by default. You disable logging for the XML Attachment check by clearing the Log check box, and re-enable logging after disabling it by checking the Log check box. You normally will not want to disable logging for this or any check. If anything unexpected happens, the logs are an important resource to troubleshoot.

•

Statistics. Tells the Application Firewall to generate statistics for connections that violate the XML Attachment check. Enabled by default. You disable statistics for the XML Attachment check by clearing the Statistics check box, and re-enable statistics after disabling it by checking the Statistics check box. 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.

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

1.

In the navigation pane, expand Application Firewall, and then click Profiles.

2.

In the Application Firewall Profiles pane, select a profile, and then click Open.

Chapter 10

The XML Security Checks

3.

In the Configure Application Firewall Profiles dialog box, click the Security Checks tab.

4.

Click XML Attachment, and then click Modify.

5.

In the Modify XML Attachment Check dialog box, configure the following options:

249

•

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. In any of your Application Firewall profiles, you configure general settings for the Web Services Interoperability 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 Web Services Interoperability Check dialog box. To configure the general settings by using the configuration utility

1.

In the navigation pane, expand Application Firewall, and then click Profiles.

250

Citrix Application Firewall Guide

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 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.

6.

Under Actions, enable or disable each of the actions described in “Modify Web Services Interoperability Check Actions”.

7.

Click OK when finished, and then click Close to close the dialog box.

Modify Web Services Interoperability Check Actions The Check Actions control how the Web Services Interoperability check functions. They are: •

Block. Tells the Application Firewall to block connections that violate the WS-I check. Disabled by default for profiles created with basic defaults, and enabled by default for profiles created with advanced defaults. You disable blocking for the WS-I check by clearing the Block check box, and reenable blocking after disabling it by selecting the Block check box. You probably will not want to disable blocking for the WS-I check.

•

Learn. Use the learning feature to observe traffic to and from your protected 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. For a profile with basic defaults, you should not enable learning for the 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. For a profile with advanced defaults, you can either leave learning enabled, 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

Chapter 10

The XML Security Checks

251

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 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. •

Log. Tells the Application Firewall to log any connections that violate the 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. You normally will not want to disable logging for this or any check. If anything unexpected happens, the logs are an important resource to troubleshoot.

•

Statistics. Tells the Application Firewall to generate statistics for connections 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 statistics after disabling it by checking the Statistics check box. 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.

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 configuration utility

1.

In the navigation pane, expand Application Firewall, and then click Profiles.

2.

In the Application Firewall Profiles pane, select a profile, and then click Open.

3.

In the Configure Application Firewall Profiles dialog box, click the Security Checks tab.

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.

252

Citrix Application Firewall Guide

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 rule’s purpose and effect that can help you decide whether to enable it or disable it.

7.

Click OK, and then click Close.

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. In any of your Application Firewall profiles, you configure general settings for the XML Message Validation 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 Message Validation Check dialog box. To configure the general settings 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 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 XML Message Validation 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 XML Message Validation, and then click Modify.

5.

In the Modify XML Message Validation Check dialog box, click the General tab.

6.

Under Actions, enable or disable each of the actions described in “Modify XML Message Validation Check Actions”.

7.

Click OK when finished, and then click Close to close the dialog box.

Chapter 10

The XML Security Checks

253

Modify XML Message Validation Check Actions The Check Actions control how the XML Message Validation check functions. They are: •

Block. Tells the Application Firewall to block connections that violate the 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 check, so the Learn check box is greyed out.

•

Log. Tells the Application Firewall to log any connections that violate the XML Validation check. Enabled by default. You disable logging for the XML Validation check by clearing the Log check box, and re-enable logging after disabling it by checking the Log check box. You normally will not want to disable logging for this or any check. If anything unexpected happens, the logs are an important resource to troubleshoot.

•

Statistics. Tells the Application Firewall to generate statistics for connections that violate the XML Validation check. Enabled by default. You disable 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. 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.

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

1.

In the navigation pane, expand Application Firewall, and then click Profiles.

2.

In the Application Firewall Profiles pane, select a profile, and then click Open.

3.

In the Configure Application Firewall Profiles dialog box, click the Security Checks tab.

254

Citrix Application Firewall Guide

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 page 153 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 page 157 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 page 153 for information on uploading XML schema files.

Chapter 10

The XML Security Checks

255

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 page 157 for more information on this dialog box and importing. •

6.

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.

Click OK, and then click Close.

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. 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 XML SOAP Fault Filtering Check dialog box. To configure the general settings 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 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 XML SOAP Fault Filtering entry, you can select or clear check

256

Citrix Application Firewall Guide

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 XML SOAP Fault Filtering, and then click Modify.

5.

Under Actions, enable or disable each of the actions described below.

6.

Click OK when finished, and click Close to close the dialog box. 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.

7.

•

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.

Click Create or OK, and then click Close

C HAPTER 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 SystemÎReports 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.

258

Citrix Application Firewall Guide

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 configuration is currently in compliance, and if it is not, how to bring it into compliance.

260

Citrix Application Firewall Guide

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 DSSspecific summary omitted, and is described below.

The Application Firewall Configuration Report The Application Firewall Configuration report is located under the SystemÎReports 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.

Chapter 11

•

The Application Firewall Reports

261

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 Application 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 page 186.

•

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 page 175.

•

Start URL Check. Shows information about each Start URL you have configured.

•

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 page 186.

•

Cookie Consistency Check. Shows information about each Cookie Consistency 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 page 201.

•

Field Consistency Check. Shows information about each Form Field Consistency 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 page 190.

262

Citrix Application Firewall Guide

•

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 more information about these actions and what the effect of each is, see the “The Field Formats Check,” on page 208.

•

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 CrossSite Scripts, 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 HTML Cross-Site Scripting Check,” on page 219.

•

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 section 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 Injection Check,” on page 226.

•

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 page 196.

•

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 page 182.

•

Deny URL Check. Lists each default Deny URL you have enabled on your Application Firewall, and each user Deny URL you have configured.

Chapter 11

The Application Firewall Reports

263

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 system passwords 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

264

Citrix Application Firewall Guide

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, “Confidential Fields,” on page 155. •

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 configuring it, see “The Cookie Consistency Check,” on page 186 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, “Confidential Fields,” on page 155.

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.

Chapter 11

The Application Firewall Reports

265

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.

This requirement is not applicable to the Citrix Application Firewall, but to the 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.

This requirement is not applicable to the Citrix Application Firewall, but to the 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.

266

Citrix Application Firewall Guide

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 Appendix B, ”PCI DSS Standard,” on page 351.

C HAPTER 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 page 267 for information on how to configure the Application Firewall to protect the application and the SQL database.

•

Product Information query. If your Web sites contain Javascripts 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 javascript-enhanced Web form, see “Protecting a Product Information Query Page” on page 289 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 shopping.example.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.

268

Citrix Application Firewall Guide

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 Javascript 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 application. An attacker could modify a cookie and gain access to the shopping cart application under another user’s credentials. Once logged on as that user, the attacker could obtain sensitive private information about the legitimate user or place orders using the legitimate user’s 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 code—an 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 information 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 Java client or the Web Start client. For instructions on doing this, see “To log on to the configuration utility” on page 40.

2.

In the Menu tree, expand the Application Firewall entry to display the 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 page 67, 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.

270

Citrix Application Firewall Guide

The Create Application Firewall Profile Dialog Box with Advanced Defaults After he adds the profile, the profile’s 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.

Chapter 12

Use Cases

271

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

272

Citrix Application Firewall Guide

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 dialog box, shown below.

Chapter 12

Use Cases

The Modify Start URL Check Dialog Box, General Tab C.

In the Check Actions area, clear the Block check box, as shown below.

273

274

Citrix Application Firewall Guide

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 Configure Application Firewall Profile dialog box. As shown below, the Block column for the Start URL entry now reads “No,” showing that blocking is disabled for the Start URL rule.

Chapter 12

Use Cases

275

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 step 7. 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.

276

Citrix Application Firewall Guide

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 step 8. 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.

Chapter 12

B.

Use Cases

277

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 for this rule. The system administrator does not want to risk blocking 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.

278

Citrix Application Firewall Guide

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 dialog box, shown below.

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.

Chapter 12

Use Cases

279

The Modify Credit Card Check Dialog Box, General Tab With Logging, Statistics, and XOut 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.

280

Citrix Application Firewall Guide

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.

Chapter 12

Use Cases

281

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 OK button to confirm your choices. The Credit Card Check dialog box closes, and you return to the Configure Application Firewall Profile dialog box.

12.

Click the OK button to close the Configure Application Firewall Profile dialog box and return to the Profiles page.

To create a profile to protect the shopping cart 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 page 60.

2.

Enter the following command to create the profile. > add appfw profile "Shopping Cart" -defaults 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 -defaults 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 page 83.

282

Citrix Application Firewall Guide

3.

Enter the following command to configure the Start URL check properly for the Shopping Cart profile. > set appfw profile "Shopping Cart" -startURLAction LEARN LOG STATS -startURLClosure 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 -startURLAction 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 -startURLClosure 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 appfw profile "Shopping Cart" -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 to the shopping cart application that might violate the checks. The -cookieConsistencyAction LEARN LOG STATS parameter turns off blocking for the Cookie Consistency check, and the fieldConsistencyAction 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 appfw profile "Shopping Cart" -SQLInjectionAction LEARN LOG STATS -SQLInjectionTransformSpecialChars ON

Chapter 12

Use Cases

283

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 -SQLInjectionAction 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 -SQLInjectionTransformSpecialChars 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 appfw profile SQL -creditCardAction LOG STATS -creditCardXOut ON -creditCard VISA MasterCard Amex

The system administrator wants to disable blocking for the Credit Card check because order confirmation pages from the shopping cart application show the user’s credit card number. He wants to prevent that from happening without blocking the order confirmation pages. The -creditCardAction 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 -creditCardXOut 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 -creditCard Visa MasterCard Amex parameter enables protection for those credit cards. 7.

Enter the following command to save your configuration. > save ns config

8.

Enter the following command to confirm that your profile was correctly created. > show appfw profile "Shopping Cart"

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.

284

Citrix Application Firewall Guide

> rm appfw profile SQL

•

If any of the settings is not correct, he repeats the set appfw profile 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, shopping.example.com, so creating the policy will be easy. This section contains two procedures—one 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

1.

In the Menu tree, expand the Application Firewall entry to display the choices in that category, and click Policies to display the Policies page.

2.

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

Chapter 12

Use Cases

285

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 Add Expression Dialog Box 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.

286

Citrix Application Firewall Guide

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 shopping.example.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

6.

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.

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.

7.

Click the Close button to close the Create Application Firewall Policy dialog box and return to the Profiles page.

Chapter 12

Use Cases

287

The system administrator’s 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 configuration utility” on page 78. 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.

288

Citrix Application Firewall Guide

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. > add appfw policy

The system administrator makes the following substitutions: •

For , 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 , the system administrator substitutes the following PCRE-compatible regular expression: "REQ.HTTP.HEADER URL CONTAINS shopping.example.com"

Note: All rules must be enclosed in double quotes. This regular expression tells the Application Firewall to check all HTTP requests to see whether they include the host shopping.example.com.

Chapter 12

Use Cases

289

These requests, and only these requests, are sent to the shopping cart and should be checked using the SQL profile. •

For , 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 appfw policy "Shopping Cart" "REQ.HTTP.HEADER URL CONTAINS shopping.example.com" "Shopping Cart"

Note: Although the preceding rule wraps onto two lines, you should type it on a single line in the NetScaler command line. 2.

Enter the following command to save your configuration. > save ns config

3.

Enter the following command to confirm that your policy was correctly created. > show appfw policy

For , 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 page 81 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 application’s 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.example.com. The Web site uses Javascript 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.

290

Citrix Application Firewall Guide

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 shopping.example.com server for later processing. The Javascripts 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 Javascript 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 Javascript-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 Javascript-enhanced forms on the example.com Web 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 Java client or the Web Start client. For instructions on doing this, see “To log on to the configuration utility” on page 40.

2.

In the Menu tree, expand the Application Firewall entry to display the 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 page 67, but click the Advanced radio button to choose Advanced defaults.

Chapter 12

Use Cases

291

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 profile’s 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.

5.

Click the Open button to display the Configure Application Firewall Profile 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.

292

Citrix Application Firewall Guide

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. D.

Click the OK button to save your changes. The Modify Start URL Check dialog box closes, and a message box appears, notifying you that your changes have been successfully saved.

E. 8.

Click the OK button to close the message box and return to the Configure Application Firewall Profile dialog box.

Configure the Cookie Consistency check. A.

In the Security Checks list, click Cookie Consistency once to highlight it.

Chapter 12

Use Cases

B.

Click the Modify button to display the Modify Cookie Consistency Check dialog box.

C.

Uncheck the Block check box, as shown below.

293

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 relaxations 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 Cookie Consistency Check dialog box closes, and a message box appears, notifying you that your changes have been successfully saved.

E. 9.

Click the OK button to close the message box and return to the Configure Application Firewall Profile dialog box.

Configure the Form Field Consistency check by following the same procedure described in step 8.

294

Citrix Application Firewall Guide

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 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 for this rule. The system administrator does not want to risk blocking legitimate requests until learning has generated an appropriate list of relaxations to the Cross-Site Scripting rule.

Chapter 12

Use Cases

295

Since no URLs except those explicitly listed in the Javascript Profile will be checked using this profile, no Javascripts 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 crosssite 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 Javascripts 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 OK button to confirm your choices. 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.

The Configure Application Firewall Profile Dialog Box, Settings Tab

296

Citrix Application Firewall Guide

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 example.com Web site, this is the correct behavior, but the Web site uses a special error page, http://www.example.com/requesterror.html, 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: /requesterror.html

This setting will redirect all blocked requests to the web pages in question to http://www.example.com/requesterror.html. 13.

Click the OK button to save your changes. 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

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 page 60.

2.

Enter the following command to create the profile. > add appfw profile "Product Query" -defaults 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 -defaults 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 page 83. 3.

Enter the following command to configure the Start URL check properly for the Scripts profile. > set appfw profile "Product Query" -startURLAction NONE -startURLClosure OFF

Chapter 12

Use Cases

297

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 startURLAction NONE parameter disables the Start URL rule. The startURLClosure 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 -cookieConsistencyAction LEARN LOG STATS parameter turns off blocking for the Cookie Consistency check, and the -fieldConsistencyAction 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 -crossSiteScriptingAction 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 Javascript, 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

298

Citrix Application Firewall Guide

any Javascripts 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 errors—the -crossSiteScriptingTransformUnsafeHTML 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 appfw profile "Product Query" -errorURL "/requesterror\.html"

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 example.com Web 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. 7.

Enter the following command to save your configuration. > save ns config

8.

Enter the following command to confirm that your profile was correctly created. > show appfw profile "Product Query"

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.

> rm appfw profile "Product Query"

•

If any of the settings is not correct, he repeats the set appfw profile command with the appropriate settings to fix the problem.

The system administrator has successfully created a profile to protect the Javascript-enhanced forms on the Example Web site. He must now create a policy to determine when to apply that profile.

Chapter 12

Use Cases

299

Creating and Configuring a Product Query Policy To protect the product query Web forms on the example.com Web 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 procedures—one to create the Javascript 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

1.

In the Menu tree, expand the Application Firewall entry to display the choices in that category, an.

2.

In the lower left-hand corner of the data area, click the Add button to 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

300

Citrix Application Firewall Guide

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. http://www.example.com/products/wprequest.jhtml

G.

Repeat step F to add additional URLs to the list. The system administrator adds the following URLs, one after the other: http://www.example.com/products/quoterequest.jhtml http://www.example.com/solutions/whitepaper.jhtml http://www.example.com/custsupt/docreq.jhtml

All of these URLs write user information to a file on the shopping.example.com server, although all are hosted on the www.example.com server. 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.

Chapter 12

Use Cases

301

The system administrator creates the Product Query policy. 7.

Click the Close button to close the Create Application Firewall 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 configuration utility” on page 78. 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. > add appfw policy

The system administrator makes the following substitutions: •

For , the system administrator substitutes "Product Query", to show which URLs this policy should be applied to.

•

For , the system administrator substitutes the following four PCRE-compatible regular expressions, separated by the OR (||) operator: "^http://www\.example\.com/products/wprequest\.jhtml$" "^http://www\.example\.com/products/quoterequest\.jhtml$" "^http://www\.example\.com/solutions/whitepaper\.jhtml$" "^http://www\.example\.com/custsupt/docreq\.jhtml$"

Note: All rules must be enclosed in double quotes. 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 , 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

302

Citrix Application Firewall Guide

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 appfw policy "Product Query" "REQ.HTTP.HEADER URL == ^http://www\.example\.com/products/wprequest\.jhtml$ || REQ.HTTP.HEADER URL == ^http://www\.example\.com/products/ quoterequest\.jhtml$ || REQ.HTTP.HEADER URL == ^http:// www\.example\.com/solutions/whitepaper\.jhtml$ || REQ.HTTP.HEADER URL == ^http://www\.example\.com/custsupt/ docreq\.jhtml" "Product Query"

Note: Although the preceding command wraps onto multiple lines, you should type it on a single line in the NetScaler command line. 2.

Enter the following command to save your configuration. > save ns config

3.

Enter the following command to confirm that your policy was correctly created. > show appfw policy "Product Query"

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 page 81 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.

Chapter 12

Use Cases

303

Managing Learning The example.com system 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. For instructions on doing this, see “To log on to the configuration utility” on page 40.

2.

In the Menu tree, expand the Application Firewall entry to display the 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.

4.

Click the Open button to display the Configure Application Firewall Profile dialog box.

5.

Click the Learning tab to display it, as shown below.

304

Citrix Application Firewall Guide

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.

Chapter 12

Use Cases

305

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.

306

Citrix Application Firewall Guide

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.

Chapter 12

Use Cases

307

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 step 9 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 step 7 through step 9 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 dialog box and return to the Profiles page.

14.

Click the entry for each remaining profile that has learning enabled, and repeat step 4 through step 13 to review the learned relaxations for this profile. The system administrator clicks the Javascript 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 example.com system administrator has successfully configured the Application Firewall to protect the example.com Web sites.

308

Citrix Application Firewall Guide

G LOSSARY

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.

310

Citrix Application Firewall Guide

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 server’s 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 computer’s 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 user’s 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.

312

Citrix Application Firewall Guide

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 server’s 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 site’s 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. Today’s 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 user’s 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 user’s 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 user’s 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 user’s browser and a Web server, so that intercepted packets are encrypted and cannot be read. (Also called the SSL protocol.)

314

Citrix Application Firewall Guide

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 user’s credit cards and in that user’s name. An identity thief often sells this information to other criminals, as well. See phishing on page 317 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 company’s firewall or router, where your company’s 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 service’s 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.

316

Citrix Application Firewall Guide

P Packet. A packet is the basic unit of data routed between an origin and a destination on a TCP/IP or other packetswitching 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 company’s 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 user’s identity. See identity theft on page 314 for more information. Because the criminal (or pharmer) modified the Internet’s DNS system to redirect users to the pharming Web site, the user’s browser will display the correct URL in the navigation window. DNS is the Internet’s address system; it is what tells a web browser that a request to a particular host (such as www.example.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 page 317 for more information.

Glossary

Phishing. Using email or instant messages to deceive users into providing sensitive private information—such as logons and passwords to an online banking or ecommerce Web site, or credit card numbers and expiration dates—under 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 user’s 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 user’s bank account or charge goods and services to the user’s credit card. In many cases, a phishing attack will attempt to obtain enough information to steal the user’s identity. See identity theft on page 314 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 page 316 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 RJ45 port, normally used to connect one of the server’s 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 RJ45 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 Application 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 RJ11 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 RJ11 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,

318

Citrix Application Firewall Guide

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 site’s 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, driver’s 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 user’s 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 user’s 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 site’s 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 user’s 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 site’s 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.

320

Citrix Application Firewall Guide

Start URL check. A filter that lists your Web site’s 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: protocol://hostname[:port]/path[/resource.filename]

A web URL normally uses the HTTP or HTTPS protocol, as shown here: http://hostname[:port]/path[/resource.filename] https://hostname[:port]/path[/resource.filename]

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 site’s 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 company’s firewall or router, from which users access your company’s 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 technologies—SOAP, WSDL and UDDI—to 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.example.com is part of the Web site at www.example.com. Web site defacement. Vandalism of a Web site through illicit modification of the Web site’s 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.

322

Citrix Application Firewall Guide

I NDEX

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 303–307 adaptive learning. See also learned relaxations. Add... button policies 72–73

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 Form Tagging check Block setting 217 Field Formats check 210 Form Field Consistency check Block setting 203 Form Field 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

324

Citrix Application Firewall Guide

Application Firewall about 1–2 blocking hackers 2 configuration utility 11 configuring security checks 272 filtering 6, 8 filtering flowchart 7 hacker 1 hardware platforms 19–38 installation 8, 17 installing 19–38 layer 2 network bridge 6 layer 3 network device 6 network 9 network layers 9 network location 8 overview 3, 6–7 platform 8 policies 71–77, 135–136 policy flow type 312 positive security model 5 use cases 267–307 user 320 application firewall enabling 65 updating licenses 65 Application Switch definition 309 FIPS support 312 as_fid form tagging 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 4–5, 290 filtering 6 filtering flowchart 7 forceful browsing 175 hacker 2 identity theft 2 known web attacks 5 malware author 2 SQL injection 4–5, 268 types 2 types of 3 unknown web attacks 5 web form security 4

B basic defaults Cookie Consistency check Block setting 187 Cookie Consistency check Learn setting 187 CSRF Form Tagging check Block setting 217 Field Formats check 210 Form Field Consistency check Block setting 203 Form Field 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 Field Formats check 210 Form Field Consistency check 203 HTML Cross-Site Scripting check 221 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 Cookie Consistency check 276, 282, 293, 297 Credit Card check 283 Cross-Site Scripting check 294, 297 Form Field Consistency check 276, 282, 294, 297 preventing false positives 312 SQL Injection check 277, 283 Start URL check 273–274, 282 blog. See Web 2.0 profile.

Index bot compromised web server 310 definition 310 botmaster compromised web server 310 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 Buffer Overflow check 3 definition 310 forceful browsing 4 Buffer Overflow Check Block setting 191 Log setting 192 Statistics setting 192 Buffer Overflow check about 190–193 definition 310 Learn setting unavailable 192 maximum cookie length 192 maximum header length 193 maximum URL length 192 buffer overflow check about 101 CLI parameter and values 118 buffer overflow max cookie length CLI parameter and values 119 buffer overflow max header length CLI parameter and values 119 buffer overflow max URL length CLI parameter and values 118 built-in profiles about 84

C canonicalize HTML response CLI parameter and values 128 Centronics. See port. CGI definition 310 deny URL 311 protecting SQL databases 268

325

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 83–133 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 12000. See hardware, 12000. Citrix NetScaler 7000. See hardware, 7000. Citrix NetScaler 9010. See hardware, 9010. Citrix NetScaler MPX 15000. See hardware, 15000. CLI about 10–11 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 Form Field Consistency check 282,

326

Citrix Application Firewall Guide

297 configuring security checks 114–121, 126 configuring SQL Injection check 282 configuring Start URL check 282 creating a policy 76–77, 144–289 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 maximum session lifetime 163 modifying a policy 149 NSIP 76 regular expression 288 save ns config 100 saving policy configuration 289 saving profile 298 scripted content policy 301–302 scripted content profile 296–298 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 281–284 SSH 76, 99, 158, 372–373, 375 transform unsafe 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, 288–289, 301 add appfw profile 66, 99, 281, 296 bind appfw global 81, 150 enable ns feature 63 import appfw htmlerrorpage 158–159 rm appfw htmlerrorpage 159 rm appfw policy 77, 148–149 rm appfw profile 284 rm appfw wsdl 160 rm appfw 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, 282–283, 296–298, 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 159–160 show appfw xmlerrorpage 159 show appfw xmlschema 159 CLI. See also SSH. Close button confidential fields 169 Credit Card check 195 policies 76 command line interface. See CLI. Comments setting Field Formats check 213 HTML Cross-Site Scripting check 224 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 configuration about 267 about simple configuration 65 advanced defaults 290 advanced features 82 CLI 10 Cookie Consistency check 275, 282, 292, 297 creating a policy 136–148 creating a profile 66 Credit Card check 278, 283 Credit Card check X-Out option 283 Cross-Site Scripting check 294, 297 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 Field Formats check 209 filtering specific URLs 299, 301 Form Field Consistency check 202, 276, 282, 293,

327

297 globally binding policies 78–151 GUI 104 html error page 159 import size limit 165 list of security checks 101–103 logging header name 163 maximum session lifetime 163 modifying a policy 149 named expression 139 policies 135–136 policy 317 policy name 76, 137, 145, 169, 173, 285 policy names 73 preventing false positives 268 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 transform cross-site scripts 295 transform SQL special characters 277, 283 transform unsafe HTML 298 undefined profile 164 updating licenses 65 URL closure 282 user 320 user interface 9 verifying policy 289 configuration utility about 11–15 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

328

Citrix Application Firewall Guide

box 79 configuring security checks 272 create profile dialog box 69 creating a policy 136–138 creating a profile 86–87 definition 310 deleting a policy 149 dialog box 312 Expression Editor 139 logo bar 12 modifying a policy 149 navigation tree 12 page data area 13 page title bar 13 policy ??–287 reviewing learned relaxations 303–307 screen areas 12 scripted content profile 290–296 Setup Wizard 13–14 SQL database profile 269–281 System menu 51 system overview 12 Upgrade Wizard 13–14 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 Cookie Consistency check 3 definition 311 regular expression 318 cookie check about 101 Cookie check. See Cookie Consistency check. Cookie Consistency Check Block setting 187 Learn setting 187 Log setting 188 Statistics setting 188

Cookie Consistency check about 186–190, 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, 218–219 logon relaxation 189 modifying ??–190 PCRE expressions 189 profile 268–284 shopping cart item relaxation 190 UTF-8 character encoding 190 cookie consistency check CLI parameter and values 116 cookie security. See Cookie Consistency check. CP web site about 3 child pornography 311 compromised web server 311 definition 311 CP web site. See also bot, hacker, malware. CP. See child pornography. Create button policies 76 Credit Card check about 193–195, 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 maximum credit cards allowed setting 195 parameters 195 protected credit cards 283 Statistics setting 194 X-Out 278, 283 X-Out setting 194 credit card check about 102 CLI parameter and values 119 credit card max allowed CLI parameter and values 119 credit card protected types CLI parameter and values 119

Index credit card x-out CLI parameter and values 119 Cross Site Request Forgery attack. See CSRF. cross site scripting. See cross-site scripting, Cross-Site Scripting check. cross-site scripting about 4–5, 220, 241 attacks 290 definition 311 description of 290 HTML Cross-Site Scripting check 4 same origin policy 4–5, 311 same origin rule 220, 241 transforming 295 what is it? 220, 241 XML Cross-Site Scripting check 5 Cross-Site Scripting check about 290 blocking 294, 297 configuring 294, 297 definition 311 same origin rule 298 transform cross-site scripts 295 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 transform unsafe HTML 298 cross-site scripting. See also Cross-Site Scripting check, same origin policy. cryptographic algorithm integrity checking 314 CSRF CSRF form tagging 102 definition 311 CSRF form tagging about 102 definition 311 CSRF Form Tagging Check Block setting 217 CSRF Form Tagging check about 215 Enabled check box 218 Learn setting unavailable 217 Log setting 217 Statistics setting 218 customer ID. See safe object.

D datagram. See packet.

DDoS definition 311 deep linking definition 311 defacement. See web site defacement. default charset CLI parameter and values 128 settings 122 default field format max length CLI parameter and values 118 default field format min length CLI parameter and values 118 default field format type CLI parameter and values 118 default field type settings 122 default profile about 164 defaults about 70

329

330

Citrix Application Firewall Guide

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 child pornography 310 CLI 310 compromised web server 310 configuration utility 310 control interface 311 control IP 311 cookie 311 Cookie Consistency check 311 CP web site 311 Credit Card check 311 cross-site scripting 311 Cross-Site Scripting check 311 CSRF 311 CSRF form tagging 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 Formats check 312 field types 312 filter 312 FIPS 312 flow type 312 forceful browsing 312 Form Field Consistency check 313 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 positive security model 318 profile 318 protocol 318 qualifier 318 regular expression 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 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 CLI parameter and values 116 definition 311 Deny URL Check Block setting 182 Log setting 183 Statistics setting 183 Deny URL check about 182–186 configuring 182 definition 311 Enabled check box 184 entering a Deny URL 184 forceful browsing 312 Learn setting unavailable 183 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

331

deny URL/modifying 184 dialog box configuration utility 312 definition 312 distributed denial of service. See DDOS. DoS definition 312 driver’s license number. See safe object.

E Enable check box Form Field Consistency check 205 Safe Object check 196 Start URL check 179 enable form tagging CLI parameter and values 128 Enabled check box Cookie Consistency check 189 CSRF Form Tagging check 218 Deny URL check 184 Field Formats check 212 HTML Cross-Site Scripting check 224 HTML SQL Injection check 232 Enforce URL closure about 178 engine settings about 161 adding a confidential field 166 confidential fields 166 default profile 164 import size limit 165 logging header name 163 maximum session lifetime 163 removing a confidential field 169 session cookie name 162 session timeout 162 tracking user’s Application Firewall session 162 undefined profile 164 error page configuring 296, 298 definition 312 error URL CLI parameter and values 127 settings 122 exclude file uploads from checks CLI parameter and values 128

332

Citrix Application Firewall Guide

expression creating 139–142 example 147 flow type 74, 139, 145 header name 142, 147 matching all requests 76 matching policy expressions 138 named expression 139 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 transform SQL special characters, preventing 277 field format check CLI parameter and values 118 Field Formats check about 208–215 Action URL setting 213 advanced defaults 210 basic defaults 210 Block setting 210 Comments setting 213 comparison with Form Field Consistency check

209 configuring 209 definition 312 Enabled check box 212 Field Name setting 212 field types 171, 312 Format setting 213 HTML profiles only 208 Learn setting 210–211 Log setting 211 Maximum length setting 213 Minimum Length setting 213 Statistics setting 211 Type setting 213 UTF-8 character encoding 214 UTF-8 character encoding in URL 215 "Is Field Name Regular Expression" check box 212 field formats check about 102 Field Name setting HTML Cross-Site Scripting check 224 HTML SQL Injection check 232 field type Field Formats check 171 field types adding 172–173 alphanum 171 any 171 default 171 definition 312 Field Formats check 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 flow type about 74, 139, 145 Application Firewall requirements 312 configuring 285, 300 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 Start URL check 4, 312 form field regular expression 318 form field check about 102 Form Field Consistency check about 201–208 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 Enabled check box 205 entering a field name 205 Field Formats check 202 HTML profiles only 201 Learn setting 203 Log setting 204 Modify Form Field Consistency Check dialog box, General tab 203 Modify Rule... button 202 Statistics setting 204 UTF-8 character encoding 207 UTF-8 character encoding in URL 207 when to use Field Formats check instead 202 form field consistency check CLI parameter and values 116 form security. See Form Field Consistency check. form structural security. See Form Field Consistency check. form tagging as_fid 206 Format setting, Field Formats check 213 FormID CSRF Form Tagging check 215

333

G global binding about 78–151 CLI 81–82, 150–151 configuration utility 78–80, 149 priorities 78, 149 state 80, 150 global configuration confidential fields 166 engine settings 161 field types 171 GUI Add Expression dialog box 74 Add Expression dialog box, HEADER qualifier 75 adding a confidential field 166–169 adding field types 172 configuring security checks 104–114 creating a policy 72–76 creating a profile 67–71 session cookie name 162 GUI. See configuration utility.

H HA definition 313 hacked web server. See compromised web server. hacker Application Firewall 1 bot 310 compromised web server 310 definition 313 filtering 2 identity theft 2 legal consequences 3 hacker. See also malware. hardware 10010 26–28 12000 30–38 7000 20–21 9010 22–24 platforms 19–38 header configuring 286, 300 header name about 76, 142, 147 URL 76 hidden field definition 313 hidden field. See also form field consistency checks. high availability. See HA.

334

Citrix Application Firewall Guide

HTML Cross-Site Scripting check about 219–226 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 Enabled check box 224 Field Name setting 224 Is Field Name Regular Expression check box 224 Learn setting 221 Log setting 222 PCRE expressions 225 same origin rule 220 Statistics setting 222 Transform cross-site scripts check box 222 UTF-8 character encoding 225 UTF-8 URL examples 226 HTML cross-site scripting check. See HTML XSS check. HTML error object CLI parameter and values 127 html error page name 159 source 159 HTML profile about 84 definition 313 Field Formats check 208 Form Field Consistency check 201 HTML profiles HTML SQL Injection check 226 HTML profile. See also profile. HTML security checks CSRF form tagging 102, 215 field formats security check 102 form field 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 Enabled check box 232 Field Name setting 232 HTML profiles only 226 Is Field Name Regular Expression check box 232 Learn setting 228 Log setting 228 Parameters area 230 PCRE expressions 233 Restrict checks to fields containing SQL special characters 109, 230 SQL Comments Handling setting 109, 230 Statistics setting 229 Transform SQL special characters 229 HTML SQL injection check about 102 CLI parameter and values 117 HTML SQL injection only check SQL CLI parameter and values 117 HTML SQL injection parse comments CLI parameter and values 118 HTML SQL injection transform special characters CLI parameter and values 117 HTML XSS check about 102 CLI parameter and values 117 HTML XSS check complete URL CLI parameter and values 117 HTML XSS transform unsafe HTML CLI parameter and values 117 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

I identity theft about 3 and web site attacks 2 confidential fields 166 cookie tampering 268 defintion 314 hacker 2 malware author 2 identity theft. See also phish. import size limit about 165 imports import size limit 165 installation about 17–19 Application Firewall 8, 17 installation mode about 18 one-arm mode 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 cross-site scripting 220, 241 Cross-Site Scripting check 295, 298 same origin rule 220, 241, 290 use case 299–302

K known web attack about 5

L LAN Access Gateway 309 definition 314 LAN interface definition 314

335

LAN IP definition 314 layer 1. See network layers. layer 2 network bridge Application Firewall 6 layer 2. See network layers. layer 3 network device Application Firewall 6 layer 3. See network layers. layer 4. See network layers. layer 5. See network layers. layer 6. See network layers. layer 7. See network layers. layer. See network layers. Learn setting Cookie Consistency check 187 Field Formats check 210–211 Form Field Consistency check 203 HTML Cross-Site Scripting check 221 HTML SQL Injection check 228 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 Attachment check 247 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 Form Tagging 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 visualizer 132 learning mode. See learning feature.

336

Citrix Application Firewall Guide

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 Cookie Consistency check 188 Credit Card check 194 CSRF Form Tagging check 217 Deny URL check 183 Field Formats check 211 Form Field Consistency check 204 HTML Cross-Site Scripting check 222 HTML SQL Injection check 228 Start URL check 177 WS-I check 251 XML Attachment check 248 XML Cross-Site Scripting check 243 XML DoS check 239 XML Format check 237 XML SOAP Fault Filtering check 256 XML SQL Injection check 245 XML Validation check 253 logging header name about 163 logo bar about 12 logs confidential fields 166

M malware about 1 Application Firewall 1 bot 310 compromised web server 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. maximum credit cards allowed setting about 195 maximum session lifetime about 163 MIP definition 315 Modify button XML SOAP Fault Filtering check 255 Modify Rule... button Deny URL check 182 Form Field Consistency check 202

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 80–81, 150 protocol and policy 318 qualifier and policy 318 value and policy 320 NetScaler platform network features 9 network Application Firewall 6 Application Firewall location 8 layers 315 node 315 node attribute 315 network layers Application Firewall 9 definition 315 network time protocol. See NTP. node definition 315 node property definition 315 NSIP CLI 76 definition 315

Index NTP definition 315

O one-arm mode, 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 configuring 286, 300 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 Credit Card check 195 Payment Card Industry Data Security Standard. See PCI DSS. PCI DSS about the PCI DSS report 257–263 about the PCI DSS standard 263–266 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

337

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 214–215 Field Formats check Action URL setting 213 Field Formats check expression with UTF-8 encoding 214 Field Formats check Field Name setting 212 field types 170, 173 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 180–181 URL expression with UTF-8 encoding 168, 170, 180, 185, 207, 215 UTF-8 URL examples 226 warning against careless use 181, 186, 190 warning not to use carelessly 214

338

Citrix Application Firewall Guide

PCRE expression Cookie Consistency check 189, 218–219 safe object 197 Start URL check 180, 184 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 Expression dialog box 74 Add... button 72–73 associating with profile 73 Close button 76 Create Application Firewall Policy dialog box 73 Create button 76 creating and configuring 71–77 flow type 74 global binding 78–82 header name 76 matching all requests 76 operator 75 Policy Name 73 protocol 74 qualifier 74 regular expression 73 requests 74 responses 74 Value 75 policy about 135–136 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 136–148 creating an expression 139–142 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 all requests 148 matching expressions 138 matching requests to a specific host 288 modify 149 name 76, 137, 145, 169, 173, 285, 299 named expression 139 operator 141, 146, 286, 315 profile 71, 136, 317 protecting an SQL database 284–289 protecting scripted content 299–302 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 CLI parameter and values 128

Index priority about 78, 80–81, 149–150 field types 172, 174 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 88–93 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 Form Field Consistency check 276,

282, 293, 297 configuring security checks 272 configuring SQL Injection check 276 configuring Start URL check 272, 282, 291 configuring with advanced defaults 271–281 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 list of security checks 101 name 69, 99, 372 operator 300 policy 71, 136, 317 positive security model 5 protected credit card types 283 protected web site 5 protecting scripted content 290–298 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 cross-site scripts 295 transform SQL special characters 277, 283 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

339

340

Citrix Application Firewall Guide

profiles built-in profiles 84 creating a profile 66 default profile 164 undefined profile 164 user-created profiles 84 profile. See also session profile. protocol about 74, 140, 146 configuring 285, 300 definition 318 HTTP 74, 140 policy 318 qualifier 318

Q QSA about 257 PCI DSS 257 qualifier about 74, 140, 146 configuring 286, 300 definition 318 header 74 policy 318 protocol 318

R regex editor about 112–113 regex tokens about 111 regular expression about NetScaler policy expressions 135 definition 318 definition of PCRE format 318 example 289 field types 170, 173 flow type 285, 300 header 300 matching all requests 148 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 112–113 regex tokens 111 warning against careless use 181, 186, 190 regular expressions. See also regex. relaxation Form Field Consistency check 206 profile 318 regular expression 318 Start URL check 180 Remove button confidential fields 169 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 matching all requests 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 Restrict checks to fields containing SQL special 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

S safe object regular expression 318 Safe Object check about 196–199 actions 197 definition 318 Enabled check box 196 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 4–5 cross-site scripting 4–5, 311 definition 319 same origin policy. See also cross-site scripting. same origin rule about 220, 241, 290 cross-site scripting 220, 241 Cross-Site Scripting check 298 scripting protecting SQL databases 268 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 learning visualizer 132 list of common security checks 101–102 list of HTML security checks 102 list of security checks 101–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 13–14 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 HTML SQL Injection check 4 SQL injection 4–5 transform SQL special characters 283 use case 267–289 XML SQL Injection check 5 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 4–5, 268 definition 319 policy 268–289 profile 269–284

341

342

Citrix Application Firewall Guide

SQL Injection check about ??–234, 272 blocking 277, 283 configuring 276, 282 definition 319 transform SQL special characters 277, 283 UTF-8 character encoding 233 UTF-8 URL examples 234 SQL Injection check. For HTML profiles, see HTML SQL Injection check. For XML profiles, see XML SQL Injection check. SQL keyword. See SQL, SQL injection. SQL special characters. See SQL, SQL injection. SSH CLI 76, 99, 158, 372–373, 375 definition 319 SSH. See also CLI. SSL definition 319 SSL VPN Access Gateway 309 definition 319 start URL definition 319 forceful browsing 4 regular expression 318 Start URL Check Block setting 176 Learn setting 177 Log setting 177 Statistics setting 177

Start URL check about 175–181 blocking 273, 282 CGI relaxation 181 configuration 291 configuring 272, 282 definition 320 disabling 292, 297 Enabled check box 179 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 reviewing learned relaxations 304 URL closure 282 URL closure setting 178 UTF-8 character encoding in URL 180 Validate Referer Header 178 start URL check about 101 CLI parameter and values 116 Start URL check. See also URL closure. Start URL expression CGI-BIN relaxation 181 state about 80, 150 definition 320 Statistics setting Buffer Overflow check 192 Cookie Consistency check 188 Credit Card check 194 CSRF Form Tagging check 218 Deny URL check 183 Field Formats check 211 Form Field Consistency check 204 HTML Cross-Site Scripting check 222 HTML SQL Injection check 229 Start URL check 177 WS-I check 251 XML Attachment check 248 XML Cross-Site Scripting check 243 XML DoS check 239 XML Format check 237 XML SOAP Fault Filtering check 256 XML SQL Injection check 245 XML Validation check 253

Index 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 164 undefined profile about 164 universal serial bus. See port. unknown web attack about 5 positive security model 5 Upgrade Wizard about 13–14 upgrade wizard about 15 URL definition 320 HTTP header 76 URL closure about 107–108 CLI parameter and values 116 definition 320 disabling 292, 297 URL closure. See also start URL. URL setting. See Action URL setting. USB. See port.

343

use case adaptive learning 303 cookie tampering 268 Javascript 290–302 SQL database 267–289 SQL database profile ??–284 SQL injection 268 Start URL check 272 use HTML error object CLI parameter and values 127 user configuration 320 definition 320 web site 320 user interface about 9 CLI 9 configuration utility 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 configuring 286, 300 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.

344

Citrix Application Firewall Guide

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 Field Formats check 4 Form Field Consistency check 4 HTML SQL Injection check 4 javascript 289 protecting SQL databases 268 web form integrity. See Form Field Consistency check. web form security. See Form Field Consistency check, Field Formats check. web forms field types 171 web server Apache 321 Application Firewall 1 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 XML SQL Injection check 5 web services definition language. See WSDL. web services profile definition 321 web services profile. See also profile.

web site Application Firewall 1 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 configuration utility 321 definition 321 WSDL definition 321 web service 321 XML 321 WSDL file definition 321 WS-I Check Block setting 250 Statistics setting 251 WS-I check about 249–252 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 Statistics setting 248

Index XML Attachment check about 246–249 Learn setting 247 Log setting 248 XML attachment check about 103 CLI parameter and values 121 XML Cross-Site Scripting Check Block setting 242 Statistics setting 243 XML Cross-Site Scripting check Learn setting not available 243 Log setting 243 same origin rule 241 XML cross-site scripting check. See XML XSS check. XML denial-of-service security check about 103 XML DoS Check Block setting 238 Statistics setting 239 XML DoS check CLI parameter and values 119 Learn setting 238 Log setting 239 XML error object CLI parameter and values 127 XML Format Check Block setting 236 Statistics setting 237 XML Format check about 103 Learn setting not available 237 Log setting 237 XML format check CLI parameter and values 119 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 Statistics setting 256

345

XML SOAP Fault Filtering check about 255–256 configuring 255 Learn setting unavailable 256 Modify button 255 XML SQL Comments Handling setting about 245 XML SQL Injection Check Block setting 244 Statistics setting 245 XML SQL Injection check Learn setting not available 245 Log setting 245 Parameters area 245 Restrict checks to fields containing SQL special characters 245 SQL Comments Handling setting 245 XML SQL injection check about 103 CLI parameter and values 120 XML SQL injection only check fields with SQL CLI parameter and values 120 XML SQL injection parse comments CLI parameter and values 120 XML Validation Check Block setting 253 Statistics setting 253 XML Validation check about 252–255 Learn setting not available 253 Log setting 253 XML validation check CLI parameter and values 121 XML WS-I check CLI parameter and values 120 XML XSS check about 103 CLI parameter and values 120 X-Out setting about 194 XSS. See cross-site scripting.

346

Citrix Application Firewall Guide

A PPENDIX A

PCRE Character Encoding Format

This appendix describes how to enter non-ASCII characters—including those found in the English, Chinese, Japanese, Korean, and Turkish languages—into your Application Firewall configuration.

Representing UTF-8 Characters The NetScaler operating system supports direct entry of characters in the printable ASCII character set only—characters 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, Japanese, 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 commands 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.

348

Citrix Application Firewall Guide

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 characters 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 ethnic heritage who live outside of mainland China.

•

Chinese Simplified (GB2312). The Application Firewall supports all characters in the GB2312 character set, which includes all of the Simplified Chinese characters (ideographs) commonly used in modern Chinese as spoken and written in mainland China.

•

Japanese (SJIS). The Application Firewall supports all characters in the Shift-JIS (SJIS) character set, which includes most characters (ideographs) commonly used in modern Japanese.

•

Japanese (EUC-JP). The Application Firewall supports all characters in the EUC-JP character set, which includes all characters (ideographs) commonly used in modern Japanese.

•

Korean (EUC-KR). The Application Firewall supports all characters in the EUC-KR character set, which includes all characters (ideographs) commonly 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 Russian.

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, Japanese, 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 character’s 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.josénuñez.com Encoded URL: ^http://www[.]jos\xC3\xA9nu\xC3\xB1ez[.]com$

•

Another URL containing extended ASCII characters. Actual URL: http://www.example.de/trömso.html Encoded URL: ^http://www[.]example[.]com/tr\xC3\xB6mso[.]html$

•

A form field name containing extended ASCII characters. Actual field name: nome_do_usuário 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: http://www.utf8-chartable.de/unicode-utf8-table.pl

350

Citrix Application Firewall Guide

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.

A PPENDIX B

PCI DSS Standard

This appendix contains the text of the PCI DSS 1.2 specification, in English.

352

Citrix Application Firewall Guide

Payment Card Industry (PCI)

Data Security Standard Requirements and Security Assessment Procedures Version 1.2 October 2008

Appendix B

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 PCI DSS Requirements and Security Assessment Procedures, v1.2 Copyright 2008 PCI Security Standards Council LLC

October 2008 Page 1

353

354

Citrix Application Firewall Guide

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

PCI DSS Requirements and Security Assessment Procedures, v1.2 Copyright 2008 PCI Security Standards Council LLC

October 2008 Page 2

Appendix B

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 them with 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 Requirements and Security Assessment Procedures, v1.2 Copyright 2008 PCI Security Standards Council LLC

October 2008 Page 3

355

356

Citrix Application Firewall Guide

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.

Storage Permitted

Protection Required

PCI DSS Req. 3.4

Primary Account Number (PAN)

Yes

Yes

Yes

Cardholder Name 1

Yes

Yes 1

No

Yes

Yes

1

No

Yes

Yes

1

No

No

N/A

N/A

CAV2/CVC2/CVV2/CID

No

N/A

N/A

PIN/PIN Block

No

N/A

N/A

Data Element

Cardholder Data

Service Code

1

Expiration Date Sensitive Authentication Data 2

1

2 3

1

Full Magnetic Stripe Data

3

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. Sensitive authentication data must not be stored after authorization (even if encrypted). Full track data from the magnetic stripe, magnetic stripe image on the chip, or elsewhere.

PCI DSS Requirements and Security Assessment Procedures, v1.2 Copyright 2008 PCI Security Standards Council LLC

October 2008 Page 4

Appendix B

Scope of Assessment for Compliance with PCI DSS Requirements The PCI DSS security requirements apply to all system components. “System components” are 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 custom applications, including internal and external (Internet) applications.

Network Segmentation Network segmentation of, or isolating (segmenting), the cardholder data environment from the 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 diagram helps 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 from those 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.

PCI DSS Requirements and Security Assessment Procedures, v1.2 Copyright 2008 PCI Security Standards Council LLC

October 2008 Page 5

357

358

Citrix Application Firewall Guide

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 system components 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) reviews” under Part 3 in the “Instructions and Content for Report on Compliance” section 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 system components in order to assess PCI DSS requirements. These samples must include both business facilities and system components, must be a representative selection of all of the types and locations of business facilities as well as types of system components, 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 system components 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 from a single OS (for example, Windows or Sun), then the sample PCI DSS Requirements and Security Assessment Procedures, v1.2 Copyright 2008 PCI Security Standards Council LLC

October 2008 Page 6

Appendix B

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 system components, 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 system components or facilities), then the sample must be large enough to include system components 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.”

PCI DSS Requirements and Security Assessment Procedures, v1.2 Copyright 2008 PCI Security Standards Council LLC

October 2008 Page 7

359

360

Citrix Application Firewall Guide

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 brand’s respective reporting requirements to ensure each payment brand acknowledges the entity’s 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 entity’s 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 entity’s web site, but should be a tailored description that shows the assessor understands payment and the entity’s 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), eCommerce), or card-present - Any entities that they connect to for payment transmission or processing, including processor relationships ƒ A high-level network diagram (either obtained from the entity or created by assessor) of the entity’s 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

PCI DSS Requirements and Security Assessment Procedures, v1.2 Copyright 2008 PCI Security Standards Council LLC

October 2008 Page 8

Appendix B

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, client’s 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 system components 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 from the 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 diagram of 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

PCI DSS Requirements and Security Assessment Procedures, v1.2 Copyright 2008 PCI Security Standards Council LLC

October 2008 Page 9

361

362

Citrix Application Firewall Guide

ƒ ƒ ƒ

ƒ ƒ ƒ

- List of files and tables that store cardholder data, supported by an inventory created (or obtained from the client) and retained by the assessor in the work papers. This inventory should include, for each cardholder data store (file, table, etc.): x List all of the elements of stored cardholder data x How data is secured x 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 vendor’s 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 MSP’s customers to include in their reviews. Include information about which of the MSP’s IP addresses are scanned as part of the MSP’s quarterly vulnerability scans, and which IP addresses are the responsibility of the MSP’s 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.

PCI DSS Requirements and Security Assessment Procedures, v1.2 Copyright 2008 PCI Security Standards Council LLC

October 2008 Page 10

Appendix B

ƒ 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 place” report 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) from the 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).

PCI DSS Requirements and Security Assessment Procedures, v1.2 Copyright 2008 PCI Security Standards Council LLC

October 2008 Page 11

363

364

Citrix Application Firewall Guide

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 noncompliant 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 Place” the 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.

PCI DSS Requirements and Security Assessment Procedures, v1.2 Copyright 2008 PCI Security Standards Council LLC

October 2008 Page 12

Appendix B

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 company’s network (internal) and untrusted networks (external), as well as traffic into and out of more sensitive areas within a company’s 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 from unauthorized access from untrusted networks, whether entering the system via 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 from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.

PCI DSS Requirements 1.1 Establish firewall and router configuration standards that include the following:

Testing Procedures

In Place

Not in Place

Target Date/ Comments

1.1 Obtain and inspect the firewall and router configuration standards and other documentation specified below to 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 Verify that there is a formal process for testing and approval of all network connections and changes to firewall and router configurations.

1.1.2 Current network diagram with all connections to cardholder data, including any wireless networks

1.1.2.a Verify that 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.b Verify that the diagram is 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 Verify that 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 diagram is consistent with the firewall configuration standards.

1.1.4 Description of groups, roles, and responsibilities for logical management of network components

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

PCI DSS Requirements and Security Assessment Procedures, v1.2 Copyright 2008 PCI Security Standards Council LLC

October 2008 Page 13

365

366

Citrix Application Firewall Guide

PCI DSS Requirements 1.1.5 Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure

Testing Procedures

In Place

Not in Place

Target Date/ Comments

1.1.5.a Verify that firewall and router configuration standards include a documented list of services, protocols and ports necessary for business—for example, hypertext transfer protocol (HTTP) and Secure Sockets Layer (SSL), Secure Shell (SSH), and Virtual Private Network (VPN) protocols. 1.1.5.b Identify insecure services, protocols, and ports allowed; and verify they 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 Requirement to review firewall and router rule sets at least every six months

1.1.6.a Verify that firewall and router configuration standards require review of firewall and router rule sets at least every six months. 1.1.6.b Obtain and examine documentation to verify that the rule sets are reviewed at least every six months.

1.2 Build a firewall configuration that restricts connections between untrusted networks and any system components in the cardholder data environment.

1.2 Examine firewall and router configurations to verify that connections are restricted between untrusted networks and system components 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 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment.

1.2.1.a Verify that 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.b Verify that all other inbound and outbound traffic is specifically denied, for example by using an explicit “deny all” or an implicit deny after allow statement.

1.2.2 Secure and synchronize router configuration files.

1.2.2 Verify that router configuration files are secure and synchronized—for 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.

PCI DSS Requirements and Security Assessment Procedures, v1.2 Copyright 2008 PCI Security Standards Council LLC

October 2008 Page 14

Appendix B

PCI DSS Requirements

Testing Procedures

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 necessary for business purposes) any traffic from the wireless environment into the cardholder data environment.

1.2.3 Verify that 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 from the wireless environment into the cardholder data environment.

1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment.

In Place

Not in Place

Target Date/ Comments

1.3 Examine firewall and router configurations, as detailed below, to determine that there is no direct access between the Internet and system components, 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 Verify that 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 Verify that inbound Internet traffic is limited to IP addresses within the DMZ.

1.3.3 Do not allow any direct routes inbound or outbound for traffic between the Internet and the cardholder data environment.

1.3.3 Verify there is no direct route inbound or outbound for traffic between the Internet and the cardholder data environment.

1.3.4 Do not allow internal addresses to pass from the Internet into the DMZ.

1.3.4 Verify that internal addresses cannot pass from the Internet into the DMZ.

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

1.3.5 Verify that outbound traffic from the cardholder data environment to the Internet can only access IP addresses within the DMZ.

PCI DSS Requirements and Security Assessment Procedures, v1.2 Copyright 2008 PCI Security Standards Council LLC

October 2008 Page 15

367

368

Citrix Application Firewall Guide

PCI DSS Requirements

Testing Procedures

1.3.6 Implement stateful inspection, also known as dynamic packet filtering. (That is, only ”established” connections are allowed into the network.)

1.3.6 Verify that 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 reset” or ”syn ack” bits set—a 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 from the DMZ.

1.3.7 Verify that the database is on an internal network zone, segregated from the DMZ.

1.3.8 Implement IP masquerading to prevent internal addresses from being translated and revealed on the Internet, using RFC 1918 address space. Use network address translation (NAT) technologies—for example, port address translation (PAT).

1.3.8 For the sample of firewall and router components, verify that NAT or other technology using RFC 1918 address space is used to restrict broadcast of IP addresses from the internal network to the Internet (IP masquerading).

1.4 Install personal firewall software on any mobile and/or employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), which are used to access the organization’s network.

1.4.a Verify that mobile and/or employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), and which are used to access the organization’s network, have personal firewall software installed and active.

In Place

Not in Place

Target Date/ Comments

1.4.b Verify that the personal firewall software is configured by the organization to specific standards and is not alterable by mobile computer users.

PCI DSS Requirements and Security Assessment Procedures, v1.2 Copyright 2008 PCI Security Standards Council LLC

October 2008 Page 16

A PPENDIX 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.

370

Citrix Application Firewall Guide

•

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 simply 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 page 40.

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 page 86.

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 page 87.

7.

Click the Settings tab to display the Settings page, shown in “The Configure Application Firewall Profile Dialog Box, Settings Page” on page 371.

The Configure Application Firewall Profile Dialog Box, Settings Page

8.

Check the check box labeled, “Exclude uploaded files from security checks.”

9.

Click the OK button to save your changes.

372

Citrix Application Firewall Guide

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 page 136.

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 page 149.

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

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. For instructions on doing this, see “To log onto the NetScaler command line via SSH” on page 60.

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 appfw profile -defaults advanced

For , 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 page 99.

4.

Enter the following command to disable checking of uploaded files for that particular profile. > set appfw profile -excludeFileUploadFromChecks ON

For , substitute the name of the profile that will be used when filtering the URLs that contain Web forms used to upload files.

Appendix C

5.

373

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 page 144.

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 page 150.

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

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. For instructions on doing this, see “To log onto the NetScaler command line via SSH” on page 60.

2.

Type the following command to enter the BSD shell from the NetScaler command line. > shell

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. # nsapimgr -s appfw_post_body_scan_limit=

For , 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 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. # nsapimgr -s appfw_post_body_extract_formid=

For , 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.

374

Citrix Application Firewall Guide

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. # exit

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 appfw profile -postBodyLimit

For , substitute the name of the profile. For , 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 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

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. For instructions on doing this, see “To log onto the NetScaler command line via SSH” on page 60.

2.

Enter the following command to block outright any POST requests above this limit for the specified profile. > set appfw profile -postBodyLimit

For , substitute the name of the profile. For , 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 you would substitute 2000000. 3.

Repeat the previous step for each profile used to filter large POST body content.

376

Citrix Application Firewall Guide

A PPENDIX 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 MSysObjects MSysQueries MSysRelationships SYS.ALL_CATALOG SYS.ALL_CONSTRAINTS SYS.ALL_OBJECTS SYS.ALL_TABLES SYS.ALL_TAB_COLUMNS SYS.ALL_TAB_PRIVS SYS.ALL_TRIGGERS SYS.ALL_USERS SYS.ALL_VIEWS SYS.TAB SYS.USER_CATALOG SYS.USER_CONSTRAINTS SYS.USER_OBJECTS SYS.USER_ROLE_PRIVS

378

Citrix Application Firewall Guide

SYS.USER_SYS_PRIVS SYS.USER_TABLES SYS.USER_TAB_COLUMNS SYS.USER_TAB_PRIVS SYS.USER_TRIGGERS SYS.USER_VIEWS add alter and begin case char commit constraint create decode delete distinct drop execute exec exists grant group insert intersect join like minus modify null or revoke rollback select shutdown

Appendix D

sp_sdidebug syscolumns sysobjects union update where xp_availablemedia xp_cmdshell xp_deletemail xp_dirtree xp_dropwebtask xp_dsninfo xp_enumdsn xp_enumerrorlogs xp_enumgroups xp_enumqueuedtasks xp_eventlog xp_findnextmsg xp_fixeddrives xp_getfiledetails xp_getnetname xp_grantlogin xp_logevent xp_loginconfig xp_logininfo xp_makewebtask xp_msver xp_perfend xp_perfmonitor xp_perfsample xp_perfstart xp_readerrorlog xp_readmail xp_regread xp_revokelogin xp_runwebtask

379

380

Citrix Application Firewall Guide

xp_schedulersignal xp_sendmail xp_servicecontrol xp_snmp_getstate xp_snmp_raisetrap xp_sprintf xp_sqlinventory xp_sqlregister xp_sqltrace xp_sscanf xp_startmail xp_stopmail xp_subdirs xp_unc_to_drive

A PPENDIX 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

382

Citrix Application Firewall Guide



Appendix E



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

383

384

Citrix Application Firewall Guide

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