Cisco ACE XML Gateways

Table Of Contents

Release Note for the Cisco ACE XML Gateway

Contents

New Software Features in 6.0(0)

Web Application Security

License Considerations

Web Application Firewall Security Features

Access Control Enhancements

Monitoring Configuration Changes

Software Feature Changes in 6.0(1)

HTTP Cookie Validation

Hostname Regular Expression Matching

Software Feature Changes in 6.0(2)

Base Configuration Version Update

Debugging Options Menu

Access to Unique Request Identifiers

Manager Cipher Suite Strength Increased

Software Release 6.0(2) Update Notes

Updater Database Performance Check

Hot Fixes Incorporated in this Release

Software Feature Changes in 6.0(3)

Response Exception Mapping Options Changed

Handler Names Qualified by Group Name

64 KB Default Request URI Limit Added

Important Notes

Using ACE Web Application Firewall Features in the ACE XML Gateway

Reactor Performance for Web Application Security

Reactor Message Size Limit

About HTTP Cookie Security

HTTP Cookie Validation in Software Version 6.0(0)

Web Application Security Configuration and Usage Notes

Retired Features

About the Product Documentation

Software Version 6.0(3) Open Caveats and Resolved Caveats

Software Version 6.0(3) Open Caveats

Software Version 6.0(3) Resolved Caveats

Software Version 6.0(2) Open Caveats and Resolved Caveats

Software Version 6.0(2) Open Caveats

Software Version 6.0(2) Resolved Caveats

Software Version 6.0(1) Open Caveats and Resolved Caveats

Software Version 6.0(1) Open Caveats

Software Version 6.0(1) Resolved Caveats

Software Version 6.0(0) Open Caveats and Resolved Caveats

Software Version 6.0(0) Open Caveats

Software Version 6.0(0) Resolved Caveats

Applying the Software Update

Obtaining the Updater

Running the Updater

Rolling Back an Update

Related Documentation

Release Note for the Cisco ACE XML Gateway

---

January 29, 2009

Contents

This release note applies to software version 6.0(x) for the Cisco Application Control Engine (ACE) XML Gateway and the Cisco ACE Web Application Firewall. The Cisco ACE Web Application Firewall is a new product built upon the ACE XML Gateway software platform.

For detailed information on product features, refer to the ACE XML Gateway and ACE Web Application Firewall documentation on http://www.cisco.com.

This release note contains the following sections:

•New Software Features in 6.0(0)

•Software Feature Changes in 6.0(1)

•Software Feature Changes in 6.0(2)

•Software Feature Changes in 6.0(3)

•Important Notes

•Software Version 6.0(3) Open Caveats and Resolved Caveats

•Software Version 6.0(2) Open Caveats and Resolved Caveats

•Software Version 6.0(1) Open Caveats and Resolved Caveats

•Software Version 6.0(0) Open Caveats and Resolved Caveats

•Applying the Software Update

•Related Documentation

New Software Features in 6.0(0)

This section lists important new software features and feature enhancements in this 6.0(0) release, including:

•Web Application Security

•Access Control Enhancements

•Monitoring Configuration Changes

Web Application Security

The 6.0(0) software release of the Cisco ACE XML Gateway introduces the web application security feature set. The web application security features allow you to protect web applications from common attacks, such as cross-site scripting (XSS) attacks, SQL and command injection, privilege escalation, cross-site request forgeries (CSRF), buffer overflows, cookie tampering, and denial-of-service (DoS) attacks. They are designed to help you meet a wide range of web application security requirements, including those specified by the Payment Card Industry Data Security Standard (PCI DSS) Version 1.1.

The web application security features are built on the ACE XML Gateway software platform and are fully incorporated into the Cisco ACE XML Gateway product. They are also available as a separately licensable product, the Cisco ACE Web Application Firewall.

Whereas the ACE XML Gateway allows you to apply advanced integration, WS-* features, messaging and XML processing capabilities to a specific backend service, the web application security features define security and processing measures that are applied to HTTP and HTTPS traffic broadly, across a particular class of traffic flowing through the network. In the ACE XML Gateway, the features coexist and can be used together to apply traffic security and processing measures across backend resources.

License Considerations

ACE Web Application Firewalls are administered by the ACE Web Application Firewall Manager. The Managers for each license can only manage Firewall/Gateway appliances that have the same license as it does. That is, an ACE XML Manager cannot manage a Web Application Firewall appliance, and a Web Application Firewall Manager cannot manage an ACE XML Gateway. Heterogeneous clusters are not supported.

A version 6.0 or later ACE XML Gateway Manager can import a Portable Policy File (PPF) generated by any contemporary or previous version of the Manager, including a PPF generated by a Manager that has a Web Application Firewall license. However, since its policy comprises a subset of an XML Gateway policy, a Web Application Firewall Manager cannot import PPFs generated by an ACE XML Gateway Manager.

You may upgrade from an ACE Web Application Firewall license to a full ACE XML Gateway license by purchasing the appropriate license key for each appliance. However, downgrading from the ACE XML Gateway to the ACE Web Application Firewall license is not supported. For more information, contact Cisco Support.

Web Application Firewall Security Features

ACE Web Application Firewall functionality is a subset of ACE XML Gateway functionality; the ACE XML Gateway provides all features of the ACE Web Application Firewall, but the ACE Web Application Firewall does not provide all of the functions available on the ACE XML Gateway.

The Manager with a particular type of license only allows you to configure policy features that are enabled for that license. That is, the ACE Web Application Firewall Manager web console only presents controls supported for the ACE Web Application Firewall. Features specific to the ACE XML Gateway are hidden. Manager-specific features, such as approval-based deploy, subpolicies, multi-cluster management, user authentication, and so on, are the same for both licenses.

Feature Differences between the ACE XML Gateway and the ACE Web Application Firewall

The following lists notable feature differences between the product licenses. Note that this list does not include all differences in behavior or configurability. ACE XML Gateway features that are not available in the ACE Web Application Firewall include:

•Support for protocols other than HTTP/HTTPS (that is, other protocols that are supported by the ACE XML Gateway, such as SMTP, TIB/RV, JMS, and MQ)

•Web Service/SOA or XML-specific features (for example, XSLT, XML Encryption and XML Signature, SOAP header processing, and so on)

•Policy generation by WSDL import or UDDI discovery

•Custom SDK extension modules

•Access control and authentication. While the ACE Web Application Firewall can pass through access control/authentication credentials, it cannot generate or verify credentials.

•Server farm definitions in server objects for load balancing

•Message traffic logging

•Response caching

While XML support is not a focus of the web application firewall, it does provide Reactor XML threat defense protection.

ACE Web Application Firewall Feature Summary

In addition to the features described in the "Web Application Security" section, the following web application security features are available:

•HTTP header processing

•HTTP error response mapping

•Referer HTTP header checking to deter cross-site request forgery (CSRF)

•Cookie security (encryption or signing)

•Data overflow defense

•Rule violation blocking or monitor mode

•Message rewrite rules on responses

•Message inspection rules on requests

•Extensible rules and signatures

•Incident report

•Incident-based policy adaptation

Access Control Enhancements

The security token authentication feature has been extended with an additional token type in the ACE XML Gateway product (not available in the ACE Web Application Firewall product). The security token authentication credential lets you set up access control conditions against an HTTP header value in the request or a value identified by XPath. A third token type has been added that lets you set up authentication against an HTTP argument.

This security token type is to be used for identity reporting and for throttling requests to the backend server. An HTTP argument is a value extracted from the query string of a GET request or the body of a form POST (where the content is of type application/x-www-form-urlencoded). Its value can be tested by regular expression or by a SOAP callout condition.

Monitoring Configuration Changes

The following changes have been made to monitoring configuration settings in the appliance shell menu:

•The SNMP polling community string is now configurable from the menu.

•syslog destinations are configurable from the menu. You can configure up to two additional syslog event destinations.

•A menu option has been added for disabling trap generation by the appliance.

Software Feature Changes in 6.0(1)

This section lists important features changes and enhancements in this 6.0(1) release, including:

•HTTP Cookie Validation

•Hostname Regular Expression Matching

HTTP Cookie Validation

HTTP Cookie validation behavior introduced in software release 6.0(0) has been modified. In version 6.0(0), with cookie security enabled, the firewall also validates cookies for correctness. In some cases, the level of cookie validation performed by feature is overly strict.

For software release 6.0(1), the HTTP cookie processing behavior has been modified so that the cookie is passed through as generated by the backend system.

---

Note For more information on cookie validation in 6.0(0), see "HTTP Cookie Validation in Software Version 6.0(0)" section.

---

Hostname Regular Expression Matching

An HTTP listening port in the policy can be configured to listen for traffic addressed to a particular hostname. In 6.0(0), by default, the hostname configured in the port object was matched to requests based on a substring match. That is, a request to mail.example.com would be matched to a port configured to listen on example.com.

In 6.0(1), the hostnames must be an exact match, unless you choose the Allow regular expression matching in the hostname option.

To effect the substring match previously performed by default in 6.0(1), select the regular expression matching option in the port object configuration and add the following regular expression characters to the hostname, such as ".*example.*"

Software Feature Changes in 6.0(2)

This section lists important features changes and enhancements in this 6.0(2) release, including:

•Base Configuration Version Update

•Debugging Options Menu

•Access to Unique Request Identifiers

•Manager Cipher Suite Strength Increased

•Software Release 6.0(2) Update Notes

Base Configuration Version Update

A base configuration update is available for software release 6.0(2). The base configuration defines the built-in signatures, rules, and profiles available for configuring web application security. Base configuration updates can be applied to the system independently of software updates.

New appliances that have software version 6.0(2) pre-installed will include the latest base configuration by default. However, if updating to 6.0(2) from a previous version, you will need to apply the base configuration update directly.

A base configuration update file is in the form of a PPF (Portable Policy Format) file. To apply the base configuration update, upload the PPF file using the Update Base Configuration button in the Rules & Signatures page of the Manager web console.

---

Note The portable policy format is used for the files generated by exporting a policy from the Manager as well. However, a base configuration update PPF file cannot be uploaded through the Policy Import tool; it can only be used to update the base configuration in the Rules & Signatures page.

---

The version identifier for the base configuration update is 1.0(1)_2008081201. The base configuration identifier (2008081201) appears on the Rules & Signatures page of the Manager web console. This version of the base configuration should not be applied to software versions prior to 6.0(2); it is not compatible with 6.0 or 6.0(1).

You can acquire the base configuration update file from cisco.com. Instructions for installing the base configuration as well as details on changes contained in this update are included in the README file associated with the base configuration update.

Debugging Options Menu

A new menu option in the appliance configuration interface makes it easier to enable core file capture on the system. Core files can be generated by the system when processes terminate abnormally. They are useful for troubleshooting system errors.

You should enable core file retention only as directed by Cisco support. After enabling core file retention, you will most likely need to induce or otherwise allow the error to occur for which you are seeking support. Generated core files are automatically included in a diagnostic snapshot you generate from the Manager web console.

Be sure to disable core file retention after generating the diagnostic snapshot. Also, when finished, you will need to remove the generated core files from your system. You should do so with the guidance of Cisco support. Core files can consume a significant amount of disk space, eventually leading to disk space exhaustion.

To turn on core file retention, go to the Debugging Options menu located in the Advanced Options menu of the appliance configuration screens. Choose the Keep Core Files item. In the menu, choose:

•enable to generate core files

•disable to stop generating core files

Turning on or off core file retention requires a process restart. When prompted, restart the Gateway processes.

Access to Unique Request Identifiers

Each request/response message processing transaction at the Gateway is associated with a unique identifier at the Gateway. This identifier appears with all log event entries associated with the message processing transaction (in the event log viewer, the identifier is labeled GUID).

The value of this identifier is now available through a Reactor expression syntax variable, REQUEST_GUID. As with other Reactor variables, it can be used in various contexts, including custom error response pages, header values, and static response pages served from echo servers.

When used in error response messages, the GUID value is particularly helpful for troubleshooting service errors. It allows a request error as seen by a client to be correlated to the event log items associated with the request. You can add the request ID information to error response pages or other response pages configured in the policy using the syntax: $(REQUEST_GUID)

For more information on variables, see the rule variable list in the "Developing Rules and Signatures" chapter in the Cisco ACE XML Gateway User Guide and Cisco ACE Web Application Firewall User Guide.

Manager Cipher Suite Strength Increased

The list of cipher suites used to establish secure connections between the Manager and browsers has been modified by eliminating several low-strength cipher suites. In 6.0(2), the accepted cipher suites are:

•SSL_RSA_WITH_RC4_128_MD5

•SSL_RSA_WITH_RC4_128_SHA

•TLS_RSA_WITH_AES_128_CBC_SHA

•TLS_DHE_RSA_WITH_AES_128_CBC_SHA

•TLS_DHE_DSS_WITH_AES_128_CBC_SHA

•SSL_RSA_WITH_3DES_EDE_CBC_SHA

•SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA

•SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA

•TLS_RSA_WITH_AES_256_CBC_SHA

•TLS_DHE_RSA_WITH_AES_256_CBC_SHA

•TLS_DHE_DSS_WITH_AES_256_CBC_SHA

Note that, despite the increased cryptographic strength of the connection, the Manager should be deployed and accessible only within a secure network environment.

Software Release 6.0(2) Update Notes

To upgrade a system from the previous software version 6.0(1), you use the 6.0(2) updater. The updater is intended to update systems running software version 6.0(1). To update from an earlier version, you can use the chained updater. The chained updater applies multiple updates sequentially, and can be used to update your system from version 5.0(2) or later.

Step-by-step procedures for applying the update are documented in the INSTALL text file included in the updater distribution. To access the INSTALL file, download the 6.0(2) software distribution archive from www.cisco.com and transfer it to a location on the target appliance file system. Extract the distribution archive using the following command:

tar -xvzf <distribution_file_name>.tar.gz

This unpacks the distribution to the current directory. The INSTALL file appears at the root of the distribution directory.

Note the following points regarding the 6.0(2) updater:

•The updater does not change the base configuration (the set of signature, rules and profile applicable to web application security). To update the base configuration, you will need to load the base configuration update directly in the Manager web console after updating its software version.

•On Manager appliances, the updater now checks the validity of the performance statistics database before applying the update. If the performance database is unavailable for any reason, you can have the updater attempt to regenerate the database. (Previously, an invalid performance statistics database could render parts of the system inoperable following an update.)

Performance data, which appears in the Dashboard and Performance Monitor pages of the Manager web console, provides performance information around the request and response processing activities of the system. In general, the updater script attempts to retain existing performance data across software version updates. However, before doing so, the updater checks the performance database for validity first. If invalid, the updater can attempt to regenerate the database, which may result in the loss of preexisting performance data. If it is important for you to retain historical performance data in your system, you should export the performance data from the Manager web console before attempting to apply the update.

The data validity check results in a shutdown of Manager system for about a minute. In general, you should apply software updates when a brief system downtime will have minimal impact on system users.

Updater Database Performance Check

The INSTALL instructions included in the 6.0(2) distribution do not reflect the additional step required for the performance data check. When applying the update on a Manager appliance, after the initial system validity check, the updater presents the following prompt:

The statistics databases need to be checked for consistency 
before the update can begin. 
That requires shutting down the ACE XML Gateway Manager 
for about one minute. 
Do you want to continue at this time? 

Enter "no" (or "n") if you want to cancel the update or enter "y" to continue. If you enter "y", the script shuts down the system to perform the performance data consistency. If the database is found to be valid, the update proceeds as normal.

If the database is found to be invalid, text such as the following appears:

Error: stats database cluster62064/stats is corrupted (code 1). 
At least one cluster has a corrupted database. They must  
be repaired in order for the update to proceed.  
NOTE: if the database can not be repaired, it will 
	be deleted 
Do you want to repair the databases during update?  

Enter "y" to have the database repaired if possible. As noted, performance data may be lost if the database cannot be repaired. If you enter "n", the update is cancelled.

For more information on the installation steps, see the INSTALL file included in the update distribution.

Hot Fixes Incorporated in this Release

This release incorporates HotFix 35. You can use the single-step updater to update software from version 6.0(1) to 6.0(2) without removing the hotfix. However, to use the chained updater to update from a prior version, you need to first remove the hotfix.

Software Feature Changes in 6.0(3)

This section lists important features changes and enhancements in this 6.0(3) release, including:

•Response Exception Mapping Options Changed

•Handler Names Qualified by Group Name

•64 KB Default Request URI Limit Added

Response Exception Mapping Options Changed

The web application profile interface in the Manager web console has been changed to remove unnecessary options. A web application profile lets you define how HTTP exceptions (that is, error responses) are handled for a given virtual web application. Previously, if the status code for an error response was set for pass through, settings that were only applicable to the alternative, fixed-response option still appeared in the user interface. Values configured in these fields (Content-Type, Other Headers, and Response Body) were ignored, since the pass through option supersedes the fixed value configuration and the values of those fields were populated from the original response.

In this release, the user interface has been changed so that those fields do not appear in the interface when pass through is selected in the Status Code drop-down menu. (CSCso89879)

Handler Names Qualified by Group Name

Previously, a policy that had multiple handlers with the same name caused policy development conflicts (as described by the CSCsu90291). In release 6.0(3), the conflict has been resolved by distinguishing handlers by the handler group to which it belongs. Accordingly, handler names in the user interface now appear with the name of the handler group to which the handler belongs. This change affects the Manager web console interface wherever handler names appear, including the Virtual Service page, Access Control overview page, and Service Properties page.

64 KB Default Request URI Limit Added

Previously an issue existed in which a lengthy request URI could consume all available memory on the appliance, even with data overflow limits enabled (CSCsu18471). In correcting this issue, a default request URI limit has been added of 64KB. Previously, no limit was enforced. This issue was observed when the URI was several gigabytes in size. Requests that exceed the 64KB limit will receive the error response "HTTP 400 - Bad Request".

To change the default limit, contact your support representative.

Important Notes

This section describes behavior changes, supplemental documentation, and other information for this release. It includes the following sections:

•Using ACE Web Application Firewall Features in the ACE XML Gateway

•Reactor Performance for Web Application Security

•Reactor Message Size Limit

•About HTTP Cookie Security

•Web Application Security Configuration and Usage Notes

•Retired Features

•About the Product Documentation

Using ACE Web Application Firewall Features in the ACE XML Gateway

The 6.0 release introduces a new policy object for enabling traffic handling at the ACE XML Gateway, the virtual web application. Like a virtual service, a virtual web application enables traffic handling at the Gateway. However, it is intended to be applied more broadly than a virtual web service—to a class of traffic rather than for an individual Web Service operation. Also, its features are particularly focused on web application security, rather than integration and XML processing.

While the traffic processing settings for a virtual service are embedded in the virtual service policy object, settings for web application security are encapsulated by a profile. A profile allows you to separately define traffic processing behavior for a class of traffic, which can then be applied to multiple virtual web applications. (Modifiers let you create application-specific exemptions to a profile.)

It's possible to configure the ACE XML Gateway policy so that a request satisfies the selection criteria of more than one handler object. When choosing which object to use for a given request, the Gateway uses the more specific consumer interface first (such as the more specific path). If a virtual service and a virtual web application can both be matched to a request, the ACE XML Gateway employs a policy of choosing the virtual service first. That is, if a message matches a consumer interface for a virtual service as well as a virtual web application, it will be handled by the virtual service. While consumer interface criteria between virtual services and virtual web application may overlap, using identical request matching criteria (that is, the same host, port, path, and so on) for the consumer interfaces for a virtual services and a virtual web application results in a compile-time error.

Messages to virtual web applications are processed by the Reactor processing engine in the ACE XML Gateway. When configuring a virtual web application in the ACE XML Gateway Manager, it is important to keep in mind that virtual web applications are compatible only with Reactor-enabled port and server definitions in the policy. Port or server definitions that are configured to use Flex Path only are not available to be assigned to a virtual web application in the user interface. Changing a port or server definition to Flex Path after it is already assigned to a virtual web application results in a compile-time error.

Reactor Performance for Web Application Security

The Reactor is the high-performance HTTP processing engine within the ACE XML Gateway and ACE Web Application Firewall. It is important to note that the Reactor's capacity for concurrent connections is affected by the logging level set for the system. Logging at the higher levels of detail—Warning, Notice, Info, and Debug—reduces the number of concurrent connections that can be maintained by the Reactor (resulting in degraded performance and possibly a high incidence of dropped connections). For best performance in heavy-traffic environments, you should set the event logging level to the Alert or Error levels only.

Note that certain use cases for the ACE Web Application Firewall require Warning-level logging, for example, when using web application security in monitor mode; signature matches are logged at the Warning-level, so Warning-level logging must be enabled in this case. Before implementing this configuration, you should consider the performance implications of the log level it requires. For more information, contact your Cisco support representative.

Reactor Message Size Limit

The size limits of messages handled by the Reactor processor (the HTTP traffic processing engine within the ACE XML Gateway and ACE Web Application Firewall) are:

•Request limit: 1.5GB

•Response limit: 2GB

If it receives a message that exceeds the limit, the ACE Web Application Firewall drops the message and logs the event. Currently, the product documentation lists only the response message size limit.

Note that for responses, the log description for this event differs between a chunked response and non-chunked response. For a non-chunked response, the Web Application Firewall drops the response and logs an event indicating that the HTTP header Content-Length of the response contains an illegal value. For a chunked response, the message is dropped with an event description of "Terminating HTTP session: 500 Unable to connect".

For requests that exceed the limit, the Firewall responds with a "503 Service unavailable" HTTP error.

The limitation applies to the ACE Web Application Firewall as well as to service traffic handled by the Reactor processor with the ACE XML Gateway licensed product. For more information on large message handling in the ACE XML Gateway, see the Cisco ACE XML Gateway User Guide.

About HTTP Cookie Security

The cookie security feature, a component of web application security introduced in software release 6.0(0), helps to ensure the validity and privacy of HTTP cookies. You can use the feature to sign or encrypt cookies in responses from backend applications. When a secured cookie is received in subsequent requests from the client, it is decrypted or validated against its signature, ensuring that it has not been seen or modified outside the protected network.

Cookie security should not be used with applications that use Javascript to set or modify cookies at the client. For example, client-side Javascript may set a cookie to indicate the browser type to the backend application. Since client-modified cookies will fail validation or decryption, cookie security should be disabled in such cases. Note that with cookie signature enabled, new cookies added at the client will be dropped at the firewall; however, with encryption enabled, new cookies will be accepted. In either case, cookies modified at the client are dropped.

In 6.0(0), when cookie security is enabled, the firewall validates response cookies against certain requirements specified in RFC 2109 and its replacement RFC 2965. If a cookie is found to be invalid according to the requirement, it is either dropped or normalized. This behavior is overly strict for many deployments. This behavior does not apply to software release 6.0(1). In 6.0(1) the default behavior was changed so that cookies are not screened for compliance to the cookie specification.

HTTP Cookie Validation in Software Version 6.0(0)

In 6.0(0), the following conditions are considered errors and cause cookies to be removed or modified:

•Invalid cookie and attribute names. The ACE Web Application Firewall allows special characters in cookie names except commas (","), semi-colons (";"), double-quotes "(")", equals ("="), and whitespaces.

•Invalid cookie value. The ACE Web Application Firewall allows special characters in unquoted cookie values except commas (","), semi-colons (";"), double-quote "(")". A quoted cookie value cannot contain quotes. Characters after the second quote of the quoted value up to the end of the name-value pair (semicolon) are removed.

•Any unclosed quote is considered an error.

•Invalid attribute value. For string values (Comment, CommentURL, Domain, Path, Port, Expires), the same rules applicable to cookie values apply. Integer values (Max-Age, Version of individual cookie in a Set-Cookie header) are verified as specified by the HTTP cookie specification. If the value of an "integer" attribute is not numeric or is negative, the whole attribute is removed. For attributes that cannot have values (Secure, Discard, HTTPOnly) the value is removed, if supplied.

•While the version attribute is required by the cookie RFC specification, the ACE Web Application Firewall does not require it.

•All attributes except the following are removed: Comment, CommentURL, Domain, Path, Port, Max-Age, Expires, Secure, Discard, HTTPOnly, Version.

•Duplicate attributes are considered an error.

•The following attributes are always surrounded by quotation marks (") when re-constructing the cookie, regardless of what was in the original header: Comment, CommentURL, Domain, Max-Age, Path, Port, Version (of individual cookie in a Set-Cookie header).

•When normalizing a Set-Cookie header attribute of cookies, they are re-ordered as follows: Comment, CommentURL, Discard, Domain, Max-Age, Expires, Path, Port, Secure, HTTPOnly, Version.

•When normalizing the cookie, a Cookie header attributes of cookies are re-ordered as follows, regardless their position in the original header: Path, Domain, Port.

•The Gateway breaks single Set-Cookie header that contains multiple cookie values into separate Set-Cookie headers.

Web Application Security Configuration and Usage Notes

The following considerations apply to web application security policy development. This information is supplemental to information included in the product documentation.

•Deleting a signature that is in use by a rule raises a compilation error in the Manager web console. However, by design, deleting a rule that is in use by a profile does not raise a warning. In general, before deleting a rule, you should be aware of how it is used by profiles and delete the rule only if you are comfortable with removing its functionality from the profiles that use it.

•In cookie security, changing the cookie processing configuration at the Firewall for a live web application can produce unexpected effects for clients who have used the application with the prior configuration. For instance, changing cookie handling for an application so that cookies are encrypted rather than signed may result in clients sending multiple cookies in subsequent requests— cookies generated for cookie encryption as well as those previously generated for cookie signature. A similar possibility exists if you change the passphrase for an encrypted cookie. Subsequent requests from clients who have used the application with the previous passphrase may contain multiple encrypted cookies.

How this condition will appear to users will vary depending on how the web application handles cookies, especially multiple cookies with the same name. One possible effect is that users will not appear to be able to log in to the affected web application until they have cleared their cached cookies.

This condition will most often be observed during initial policy configuration and testing. However, if you need to change the cookie processing configuration in a production environment, consider the effects of the change on clients.

•TLS Connection upgrade is not supported. The HTTP Upgrade mechanism is intended to permit an existing unsecured TCP connection to be upgraded to TLS. Either a server or client can initiate the upgrade attempt. A server, for instance, indicates that a connection is to be upgraded by responding to a client request with an "Upgrade Required" response with status code 426, as follows:

HTTP/1.1 426 Upgrade Required
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade

By default, the Gateway and Firewall pass through this response from the server to the client, causing the client to continue the protocol switching procedure. However, since the Gateway or Firewall do not support connection upgrade, subsequent TLS requests from the client fail.

Retired Features

The following features are no longer available in the ACE XML Gateway product:

•The Details link from the service directory has been removed.

•Handler suggestions in log. The handler suggestion feature, in which log descriptions for unmatched request events suggested handlers that may have been intended to be addressed by the request, has been removed.

•WS-Timestamp configuration settings removed from Advanced SOAP Header Processing page. The Advanced SOAP Header processing page no longer contains settings for configuring WSU:Timestamp handling. The settings are duplicated by the options on the SOAP header processing page.

About the Product Documentation

Other than this release note and the ACE XML Gateway Quick Start Guide included in the box, each product has its own documentation set. While every effort was made to target the Cisco ACE Web Application Firewall documentation exclusively to Cisco ACE Web Application Firewall features, the documents may contain references to features that are available only with the Cisco ACE XML Gateway product.

The Cisco ACE Web Application Firewall documentation set includes the Cisco ACE Web Application Firewall Getting Started Guide, a tutorial-style guide that takes you step-by-step through the process for setting up web application security with the Cisco ACE Web Application Firewall features. The guide applies to using the web application security features with an Cisco ACE XML Gateway license as well.

The Cisco ACE Web Application Firewall Getting Started Guide includes instructions for setting up a web application security policy to protect a specific sample backend application, the Poison Oak Insurance web application. Note that the sample application is not currently publicly available.

Software Version 6.0(3) Open Caveats and Resolved Caveats

The following sections contain the open and resolved caveats in software version 6.0(3):

•Software Version 6.0(3) Open Caveats

•Software Version 6.0(3) Resolved Caveats

Software Version 6.0(3) Open Caveats

The following table lists open caveats.

Issue ID	Description
CSCsv85586	HTTP header processing works incorrectly when configured for regular expression-based processing. When the action for the HTTP header processing configuration is set to "use regular expression match", instead of being processed as configured, the header is passed through. Workaround: N/A
CSCsv97848	The ACE XML Gateway reports validation errors for a SOAP message containing an element with a type restriction. The event is indicated in the event log with validation errors: "XML was not valid: Datatype error" and "XML was not valid: Type 'restricted type' that is used in xsi:type is not derived from the type of element". This error occurs only when schema-based validation is applied to elements defined in the policy by external schema import. Also, it affects services that use the Flex Path processor only. Workaround: This issue can be avoided by making the service subject to Reactor processing instead of Flex Path processing, if possible. For instance, if the service is subject to Flex Path processing due to message logging, this issue can be avoided by turning off message logging for the service.
CSCsw42790	The ACE XML Gateway accepts invalid SOAP messages that do not conform to an XML schema applied to the service. Schema-based validation is enabled for requests passed through a virtual service or handler. Message processing for the service uses Flex Path processing due to any of these factors: •Message traffic logging is set to log headers or bodies of messages. •The "Always Use Flex Path" option is set for the virtual service or handler or for the associated HTTP port or HTTP server. This issue occurs if the XML schema used to validate the SOAP messages was generated by import of a WSDL that contains two schemas, one of which defines elements to be validated and other that defines their types. Workaround: Two workarounds for this issue are possible: •If possible, configure the virtual service or handler for Reactor processing rather than Flex Path processing. •Move all schema definitions from the WSDL file to separate XML schema files.
CSCsw45428	Under certain circumstances, it's possible for audit log data to become corrupted, resulting in these symptoms: 1. The ACE XML Manager reports that all gateways are unreachable. 2. It's impossible to create a diagnostic snapshot from the manager ("An error occurred while generating the diagnostic snapshot which prevented it from finishing. Please contact Cisco Support for additional assistance."). 3. The Policy Changes page cannot be opened, and instead results in an internal error ("ACE XML Gateway Manager Internal Error"). 4. The policy cannot be deployed, with an "ACE XML Gateway Manager Internal Error" reported. This issue has been observed to occur as a side-effect of disk memory exhaustion on the appliance. Workaround: Contact your support representative.
CSCsw72558	The ACE XML Gateway doesn't reject SOAP messages that are invalid according to the XML schema applied in the policy. This issue affects SOAP messages that contain elements that use type inheritance. That is, the element is defined by a type inherited from the base type defined in the schema (by xsi:type attribute). Also, it affects services in which the "Always Use Flex Path" option is enabled or in which message traffic logging is enabled. Workaround: This issue occurs due to optimizations used during message validation. These optimizations can be switched off as follows: 1. Access the shell menu on each Gateway appliance in the cluster. 2. Choose "Manage ACE XML Gateway Processes" and then "Stop ACE XML Gateway". 3. Return to the main menu and choose "Advanced Options" and then "Bash". 4. Edit the file "/usr/local/reactivity/config/runtime.properties". 5. Add the following line into the file: xmlschema.validation.simple.maxdocsize=0 6. Save changes and exit from bash. 7. Restart Gateway processes using "Manage ACE XML Gateway Processes" > "Start ACE XML Gateway".
CSCsw78835	Appliance disk space on the ACE XML Gateway or Manager can be exhausted by policy history data. This issue may occur if a large policy is deployed many hundreds of times. Currently there is no rotating mechanism for the policy history data. Workaround: Contact your support representative.
CSCsw72824	With schema validation enabled, the ACE XML Gateway may not reject a SOAP message that is invalid according to the schema. The issue affects services processed by the Flex Path processor and where the XML schema has local namespace declarations, e.g.: <xs:element name="RootElem" type="myns:myType" xmlns:myns="MyNamespace"/> Workaround: Move namespace declarations from subelements to the root xs:schema element. That is, using the example, rewrite the schema by moving the namespace declaration xmlns:myns="MyNamespace" to the root xs:schema element.
CSCsw72869	The ACE XML Gateway doesn't reject an invalid SOAP messages that do not conform to an XML schema. The policy includes an imported WSDL file that contains two schemas. Elements from the first schema refer to types defined in the second. Restrictions applied to types in the nested schema have no effect on message validation. Workaround: Two workarounds for this issue are possible: •If possible, configure the virtual service or handler for Reactor processing rather than Flex Path processing. •Move all schema definitions from the WSDL file to separate XML schema files.

Software Version 6.0(3) Resolved Caveats

The following table lists resolved caveats.

Issue ID	Description
CSCsq50927	HTTP GET requests that contain a Content-Length header set to 0 are rejected by the ACE WAF with an error response of HTTP Error 400, "Bad Request", and error detail, "HTTP GET requests must not have a Content-length". The Event Log contains the following warning "Content-Length header is forbidden on HTTP GET requests". Workaround: There is no workaround. An HTTP GET request with a "Content-length: 0" header is always rejected.
CSCsr05070	The WSDL update process creates a new HTTP server object in the policy instead of reusing or updating an existing one. This error occurs when you attempt to update a WSDL that resides in a user-created subpolicy if the original HTTP server resides in the Shared subpolicy. Note This error only affects WSDL updates (WSDL import works properly). Workaround: If this error occurs, the services generated from the WSDL will need to be remapped to use the HTTP server in the shared policy instead of the newly created duplicate HTTP server object. Once done, the new HTTP server object can be deleted.
CSCsu00258	The event log contains a signature match warning event followed by several occurrences of the error message "Error parsing line from stats file, ignore the line". The signature match event does not appear in the "Web App Firewall Incidents" report. This issue occurs when a request URL has a parameter with a LF (line feed) or CR (carriage return) symbol in its name and the request is blocked by a message inspection rule. Workaround: N/A
CSCsu00447	The "charset" part of the "Content-Type" header is stripped when a SOAP response message goes through the ACE XML Gateway. For example, "text/xml; charset=utf8" becomes just "text/xml". It occurs when a SOAP response message is processed by a SOAP 1.1 Document-type handler at the ACE XML Gateway. Workaround: Configure header processing for the handler to insert the correct header, such as "text/xml;charset =utf8"
CSCsu02287	A SAML authenticator rejects a request that contains a SAML token that is correctly signed by a certificate of a trusted CA in the ACE XML Gateway policy. The Event Log describes the event with a message similar to: "Certificate embedded in SAML Subject testuser was trusted by a CA, but the CA is not in the list for this credential. Skipping this statement." This error may occur if the policy contains several CA certificates that can be used by an authenticator to successfully validate a given SAML token, most likely as a result of a single CA certificate having been uploaded as a separate resource in multiple subpolicies. Workaround: Ensure that there is only one copy of a particular CA certificate in the policy; that is, a CA certificate should not be uploaded multiple times in different subpolicies. If several subpolicies need to use the same certificate, the certificate should be added to the Shared subpolicy. (If the certificate cannot be added to Shared, there is no workaround for this issue.)
CSCsu18471	An HTTP request with a very long URI (several gigabytes) can consume an appliance's memory despite limits specified by data overflow settings for a virtual web application. In this event, the event log contains warnings regarding memory allocation. Workaround: N/A
CSCsu26487	Some traffic processing conditions can cause excessive CPU consumption by the Reactor processes, resulting in decelerated performance for the ACE Web Application Firewall. The issue appears if several clients with limited download speed have requested large files through the ACE Web Application Firewall. While the Reactor processes are loading the files from the backend servers, excessive CPU usage occurs. Workaround: N/A
CSCsu29385	Certain traffic processing conditions can induce excessive memory consumption by the Reactor process, resulting in "503, service unavailable" errors to the client and the following warning message in the event log: "Worker memory limit reached: cannot allocate more memory (worker.memory.limit)". This issue may occur if several slow clients have requested large files through the ACE Web Application Firewall where the overall size of the requested files is more than the worker pool memory limit configured for the ACE WAF. Workaround: N/A
CSCsu40874	Incoming SSL/TLS connections to the ACE XML Gateway fail because the policy for the ACE XML Gateway is configured to require a client certificate but the client fails to send a certificate despite being configured to do so. This issue occurs when: 1. The SSL/TLS authenticator is based on an "exact match" requirement against a consumer certificate, as opposed to being signed by the specific Certificate Authority (CA). 2. There are no Trusted CA resources in the policy, including in any subpolicies. Workaround: Upload the CA issuer of the "exact match" certificate as a Trusted CA Resource.
CSCsu66833	Deleting handler-related policy objects that have dependencies across subpolicies can result in an exception error in the Manager interface with non-informative error messages upon policy compilation. This error occurs upon policy deployment if an object has been deleted from a subpolicy that is still in use by an object in another subpolicy. Workaround: N/A
CSCsu67670	After a WSDL file is updated, its associated schema bundle is duplicated. This can occur when updating a WSDL in a policy that was created on the ACE XML Gateway version 5.0 or earlier. As a result of WSDL import, an XML schema resource is generated based on the WSDL file. Instead of updating the previously created XML schema resource, the WSDL update process results in a separate, duplicate XML schema resource. Workaround: After updating the WSDL file, all services and handlers will refer to the new XML schema resource. Therefore, the previous version of the XML schema resource can be safely removed from the policy. Further updates of the WSDL file will not create new duplicate XML schema resources.
CSCsu79407	A duplicated Content-Length header can appear for 500 Error responses when Exception Mapping is turned on. This issue affects SOAP Document handlers on the Flex Path. It can appear if the Exception Mapping for SOAP messages has been configured to pass through all 500 error responses from a backed server to a client. Workaround: Several workarounds for this issue are possible: •Reset the configuration for all exception mapping rules to their default value, so that errors are not passed through from the backend service. By default the ACE XML Gateway sends its own message for 500 errors. •Reset the configuration to the default value only for the SOAP 500 exception mapping affected by the incorrect behavior. •Replace the SOAP 500 error message with a custom message in the exception mapping configuration. Note that as a result of the workarounds, the initial error response from the backed server will not be visible for a client.
CSCsu90291	An attempt to edit the general settings for a virtual service or handler fails with the error "The name is already in use. Please enter a different name." This issue occurs if a policy contains services or handlers imported from two WSDL files that define operations with the same names. As a result, the policy has multiple handlers or virtual services with the same names. Workaround: Do not import WSDL files with operations that have equal names into a single subpolicy; such WSDLs can be imported into separate subpolicies.
CSCsv21338	The response to a HEAD request from a virtual web application that has a mapped exception has a Content-Length header value of zero. A virtual web application uses the ACE WAF profile with exception mapping configured to provide a custom message with body. Workaround: N/A
CSCsv54570	The ACE WAF blocks HTTP messages that contain headers with non-ASCII characters in their value field. If this occurs, the ACE WAF Manager event log reports the following warning-level event: "HTTP parse error: unable to parse HTTP headers". An attempt to send such requests results in an HTTP Error 400, "Bad Request", response to the client. If this type of header occurs in the server response, the event log includes the following warning: "Error while reading response from server: I/O error on read". Workaround: N/A
CSCsv76384	The ACE XML Gateway returns HTTP Error 503, "Error in firewall," responses for requests to a particular basic virtual service. This error may occur if a basic virtual service has header processing enabled for response processing, it is configured to pass through all headers, and the "Save Changes" button was pressed more than once in the Manager web console during the response processing header configuration. Workaround: Disable header processing in the "Response Processing" section of the basic virtual service by clicking the "x" button to completely remove header processing, and then again turn on header processing and enable pass through for headers.
CSCsv73828	An ACE WAF inspection rule is not triggered if an attack pattern contains an HTML entity without a trailing semicolon. This occurs if a message contains HTML entities without terminating semicolons, as in the following example of the encoded word "javascript": &#x6A&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70&#x74 Workaround: N/A
CSCsv95085	The "charset" part of the "Content-Type" header is stripped when a SOAP request message goes through the ACE XML Gateway. For example, "text/xml; charset=utf8" becomes just "text/xml". This issue affects SOAP request messages processed by a SOAP 1.1 Document-type handler on the Flex Path. Workaround: Configure the Flex Path handler on which this issue occurs to use header processing and set desired value of the Content-Type explicitly. Note that this change may affect request processing performance for this handler.
CSCsw17831	The ACE WAF sends 500 (Unable to connect) errors to clients when a backend server unexpectedly closes a keep-alive connection to the ACE WAF rather than completing the request-response exchange and closing the connection as expected. Workaround: Disable connection reuse by adding the line "connection.reuse=false" (without quotes) to the "/usr/local/reactivity/io/conf/reactor.conf" file and re-deploying the policy. Turning off connection reuse in this manner may have an impact on performance.
CSCsw27972	When a client tries to download a large file (several megabytes in size) through the ACE WAF, it may eventually receive an HTTP 500, "Unable to connect" error. This issue affects transactions in which the requested file size is more than 1 MB in size, and the backend server response is chunked. The bigger the file size, the greater the likelihood of this error occurring. Workaround: N/A
CSCsw45667	In some cases, requests containing escaped characters in the URL path may cause an error in the regular expression engine of the ACE WAF that permits the request through, even if it contains an attack. The event log will contain a warning message reporting "WARNING: regular expression execution returned an error (-10)". Workaround: N/A
CSCsx29100	After a system upgrade to versions 6.0(1) or 6.0(2), traffic processing performance may be degraded due to excessive memory consumption. The software updater scripts for releases 6.0(1) and 6.0(2) incorrectly modify the configuration setting that controls the number of Reactor worker processes. In each case, the number of workers is doubled when the updater and rollback scripts are run. Note that the maximum value for the Reactor worker processes is 40, so this number cannot be exceeded. However, the recommended value for Reactor worker processes is 8, and setting this value to a higher number may result in memory errors and performance problems with the system. This may occur if one or more of the following have been applied to the system: the software updater scripts for releases 6.0(1) or 6.0(2) or the rollback scripts to the 6.0, 6.0(1) or 6.0(2) releases. Note This issue has been corrected in the version 6.0(3) updater by its setting the configuration value of the Reactor worker thread to 8, the recommended value.

Software Version 6.0(2) Open Caveats and Resolved Caveats

The following sections contain the open and resolved caveats in software version 6.0(2):

•Software Version 6.0(2) Open Caveats

•Software Version 6.0(2) Resolved Caveats

Software Version 6.0(2) Open Caveats

The following table lists open caveats.

Issue ID	Description
CSCso23323	The ACE XML Gateway policy provides built-in definitions of XML namespaces for well-known SOAP header types, including for WS-Security, WS-Addressing, and WS-Utility. Furthermore, you can define additional namespaces in the policy. Configuring a custom namespace that duplicates a predefined namespace will result in unexpected message processing failures. That is, valid messages that have named headers in the custom namespace are rejected with a soap-fault error. Workaround: Use the Known Header configuration options in the Advanced SOAP Header processing page to specify requirements for the service traffic.
CSCso89884	With an ACE Web Application Firewall license, enabling the HTTP header processing setting "Insert Client SSL Certificate DN in header name" results in an empty header value for the client SSL Certificate DN. Workaround: To have this header populated with the client SSL certificate DN, enable the SSL verify option. In the web console, go to System Management > IO Process Settings > HTTP Server. Change the SSLVerifyClient option from none to optional_no_ca.
CSCsq18236	Cluster management page does not come up after a product software update. The Public/Private Keypairs page may also stop displaying properly after applying a software version update. This only occurs if the appliance at one time ran product version 4.3.x or prior. Workaround: On software version 5.0 and above, work around this issue by editing the file /var/lib/reactivity/console_documents/cluster/config/webapp.properties In the file, remove the following line: keytool.path=/usr/java/j2sdk1.4.2_04/bin/keytool
CSCsq26977	The ACE XML Gateway incorrectly requires a WS-Addressing Action header (<wsa:Action>) in messages processed by handlers that are configured to "pass through incoming SOAPAction values."
CSCsq39429	If the ACE XML Gateway connects to a large number of backend servers in the course of processing requests for virtual services, under sustained heavy load, it's possible for the Gateway to stop functioning with an event logged indicating: "Too many open files." This condition has been observed only when the Gateway routes traffic to a large number of different backend destination hosts, that is, in excess of 800.
CSCsq50927	Requests that include a Content-Length header result in status code 400 errors.
CSCsq56488	Importing a large PPF into the Manager web console may fail with an "Internal error" message in the Manager. This results from memory exhaustion of the JavaVM process, and is possible with PPF files larger than 50MB.
CSCsq93549	The Credit Card Number Masking rule available in a web application security profile operates on the header and body of HTTP response messages. Currently, the rule matches content on a sub-string match basis rather than on a whole-word basis. As a result, the following sample header content: 123E1234-1234-123456C9 Would be matched by the CreditCard14 signature and rewritten as follows: 123Exxxxxxxxxxxxxx56C9 This has the potential to produce false positives, particularly in HTTP header content.
CSCsr07708	Connections that trigger the denial-of-service protection response in the ACE XML Gateway not properly closed. This issue affects only the denial-of-service protection feature applicable to virtual web services in the ACE XML Gateway policy.
CSCsr18786	An HTTP response with the status code "302, Object moved" followed by a RST flag at the TCP level causes the appliance to close the connection to the back-end service, with an "500 Unable to connect" error description in the Event Log and error response to the client.
CSCsu00447	The ACE XML Gateway incorrectly removes the charset identifier in the "Content-Type" header of SOAP response messages. For example, "text/xml";charset=utf8" becomes "text/xml". This issue affects SOAP 1.1 Document handlers.
CSCsu02287	In SAML-based authentication, requests that are signed by a trusted Certificate Authority (CA) certificate may be incorrectly rejected by the authenticator. This issue may occur if there are multiple trusted CAs in the policy configuration across subpolicies (other than shared). The log error description associated with this event is: "Certificate embedded in SAML subject user was trusted by a CA, but the CA is not in the list for this credential"
CSCsu24594	"Expect" HTTP header processing as described in RFC 2616 not fully implemented.
CSCsu25320	In operating error scenarios, it's possible for dropped core files to consume available disk space on the appliance.
CSCsu40874	When there are no trusted Certificate Authorities configured in the policy, requests authenticated at the Gateway by an exact client certificate match requirement may fail at the connection handshake.
CSCsx29100	After a system upgrade to versions 6.0(1) or 6.0(2), traffic processing performance may be degraded due to excessive memory consumption. The software updater scripts for releases 6.0(1) and 6.0(2) incorrectly modify the configuration setting that controls the number of Reactor worker processes. In each case, the number of workers is doubled when the updater and rollback scripts are run. Note that the maximum value for the Reactor worker processes is 40, so this number cannot be exceeded. However, the recommended value for Reactor worker processes is 8, and setting this value to a higher number may result in memory errors and performance problems with the system. This may occur if one or more of the following have been applied to the system: the software updater scripts for releases 6.0(1) or 6.0(2) or the rollback scripts to the 6.0, 6.0(1) or 6.0(2) releases. Workaround: To correct this issue: 1. Connect to the appliance using a SSH client. 2. From the shell menu, access the bash prompt. 3. Edit the /usr/local/reactivity/io/conf/reactor.conf file to set the worker.processes configuration value to 8.

Software Version 6.0(2) Resolved Caveats

This table lists caveats resolved in release 6.0(2).

Issue ID	Description
CSCso76083	In software versions 6.0 and 6.0(1), time period search fields in the Manager web console log view pages do not work properly. As a result, start and end times entered in the search form are not applied in the search.
CSCsq22380	With a Web Application Firewall licensed Manager, settings in the web console page Systems Management > Firewall Setting are not savable.
CSCsq92528	Set-Cookie response header folding performed by the Flex Path processor incompatible with most browsers. The Flex Path processor "folds" HTTP headers—that is, it combines multiple, identically named headers into a single header with comma-separated values. This behavior is incompatible with many browsers for the Set-Cookie header.
CSCsq94557	The Manager web console unnecessarily accepts HTTP TRACE requests.
CSCsr09320	Connections at the Reactor processor may be dropped with event log message, "worker process terminated abnormally," when several clients simultaneously download content by HTTPS and abort their sessions randomly.
CSCsr10287	Reactor processes may go into an infinite loop, rendering the Gateway unresponsive to incoming traffic, after many aborted client connections during large downloads.
CSCsr14379	Reactor processes may hang after a large number of TCP probes to an HTTPS port if handler routes to an HTTPS-enabled back-end application.
CSCsr23100	Incorporate updated bind packages that help mitigate DNS spoofing attacks (RHSA-2008:0533-01).
CSCsr31914	If the request URL associated with a security incident included multiple quote characters, the incident reports in the Web App Firewall Incidents page may be mis-identified. The incident may be identified using characters from the request URL of the request that induced the incident.
CSCsr41363	The Web App Firewall Incidents report can contain items that do not match any rule or rule group names. The title of such records may start with hexadecimal number.
CSCsr43206	Multiple NTP server hostnames entered in the Time Settings screen of the appliance Advanced Options menu are not preserved in the appliance configuration; only the first NTP server specified in the field is saved.
CSCsr44369	Event logging for certain activities around web application security in the ACE XML Gateway or Web Application Firewall missing from the Event Log.
CSCsr45618	When policy object are imported into the Manager web console from a PPF file selectively, it's possible for virtual web application objects to be imported without their groups, resulting in broken dependencies in the policy. (Importing other objects with missing dependencies causes a broken reference report upon import.) If this occurs, navigating to the Virtual Web Application page results in internal Manager error.
CSCsr48691	Authenticators configured to check for the TLSClient SAML token do not function correctly. It checks for the "urn:oasis:names:tc:SAML:2.0:ac:classes:TLSCLient" token instead of "urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient" (note capitalization).
CSCsr62997	Messages with HTTP status code 100 (continue) are not handled correctly. Typically, such messages result in status code 500, Unable to connect, errors.
CSCsr71043	If multiple connections are improperly terminated during Gateway response processing, it's possible for memory exhaustion to occur on the appliance. A memory worker limit warning message will appear in event log and the operating system may generate a core file. This issue may occur when there are multiple improperly terminated connections (more than 10) for responses that are relatively large (around 20MB or larger). An improperly terminated connection is one in the FIN_WAIT state for which the client does not send TCP RST packet closing the connection.
CSCsr76644	Excessive memory usage occurs at the Gateway when serving requests for low bandwidth clients with backend servers that return chunked responses that indicate unlimited length or that send more data than specified by Content-Length. In this case, warning messages similar to the following appear in the event log: "Worker memory limit reached: cannot allocate n more bytes".
CSCsr81147	Requests that use HEAD method not handled correctly by the Reactor. Sending a HEAD request intermittently results in a "500 Unable to connect" error response to the client, and generates event log items similar to the following: HTTP error: message reached EOF before all content... Terminating HTTP session: 500 Unable to connect
CSCsr81197	When a non-administrative user accesses a subpolicy in the Manager web console, security incidents may not appear in the Web App Firewall Incidents page.

Software Version 6.0(1) Open Caveats and Resolved Caveats

The following sections contain the open and resolved caveats in software version 6.0(1):

•Software Version 6.0(1) Open Caveats

•Software Version 6.0(1) Resolved Caveats

Software Version 6.0(1) Open Caveats

The following table lists open caveats.

Issue ID	Description
CSCso23323	The ACE XML Gateway policy provides built-in definitions of XML namespaces for well-known SOAP header types, including for WS-Security, WS-Addressing, and WS-Utility. Furthermore, you can define additional namespaces in the policy. Configuring a custom namespace that duplicates a predefined namespace will result in unexpected message processing failures. That is, valid messages that have named headers in the custom namespace are rejected with a soap-fault error. Workaround: Use the Known Header configuration options in the Advanced SOAP Header processing page to specify requirements for the service traffic.
CSCso89884	With an ACE Web Application Firewall license, enabling the HTTP header processing setting "Insert Client SSL Certificate DN in header name" results in an empty header value for the client SSL Certificate DN. Workaround: To have this header populated with the client SSL certificate DN, enable the SSL verify option. In the web console, go to System Management > IO Process Settings > HTTP Server. Change the SSLVerifyClient option from none to optional_no_ca.
CSCsq18236	Cluster management page does not come up after a product software update. The Public/Private Keypairs page may also stop displaying properly after applying a software version update. This only occurs if the appliance at one time ran product version 4.3.x or prior. Workaround: N/A
CSCsq39429	If the ACE XML Gateway connects to a large number of backend servers while processing requests for virtual services, under sustained heavy load, it's possible for the Gateway to stop functioning with an event logged indicating: "Too many open files." This condition has been observed only when the Gateway routes traffic to a large number of different backend destination hosts, that is, in excess of 800. Workaround: N/A
CSCsq93549	The Credit Card Number Masking rule available in a web application security profile operates on the header and body of HTTP response messages. Currently, the rule matches content on a sub-string match basis rather than on a whole-word basis. As a result, the following sample header content: 123E1234-1234-123456C9 Would be matched by the CreditCard14 signature and rewritten as follows: 123Exxxxxxxxxxxxxx56C9 This has the potential to produce false positives, particularly in HTTP header content.
CSCsr79239	Attempting to import an unsupported base configuration version to the Manager results in Manager internal error. Software versions 6.0 and 6.0(1) only work with the initial version of the base configuration. Base configuration versions 1.0(1) and later are not intended to work with these versions. However, the Manager does not gracefully report version mismatches. Attempting to upload later base configuration versions to software version 6.0 and 6.0(1) results in an internal error in the Manager web console.
CSCsx29100	After a system upgrade to versions 6.0(1) or 6.0(2), traffic processing performance may be degraded due to excessive memory consumption. The software updater scripts for releases 6.0(1) and 6.0(2) incorrectly modify the configuration setting that controls the number of Reactor worker processes. In each case, the number of workers is doubled when the updater and rollback scripts are run. Note that the maximum value for the Reactor worker processes is 40, so this number cannot be exceeded. However, the recommended value for Reactor worker processes is 8, and setting this value to a higher number may result in memory errors and performance problems with the system. This may occur if one or more of the following have been applied to the system: the software updater scripts for releases 6.0(1) or 6.0(2) or the rollback scripts to the 6.0, 6.0(1) or 6.0(2) releases. Workaround: To correct this issue: 1. Connect to the appliance using a SSH client. 2. From the shell menu, access the bash prompt. 3. Edit the /usr/local/reactivity/io/conf/reactor.conf file to set the worker.processes configuration value to 8.

Software Version 6.0(1) Resolved Caveats

This table lists caveats resolved in release 6.0(1).

Issue ID	Description
CSCso76973	When a message inspection rule runs on the result of a function call, the event log description does not correctly show the value that the rule acted upon. The value is referenced in the description but empty. For example, a message inspection rule such as "REQUEST_PARAM['pName'].count() gt 10", results in an event log description "Match was in REQUEST_PARAM['pName'].count(), which had value". (Notice that no value is indicated.) Workaround: N/A
CSCso96972	Reactor does not generate log reports for invalid cookies. Enabling the Cookie Security feature in the profile (cookie signing or cookie encryption) causes the system to validate cookies and remove invalid cookies. An event is not logged when a cookie is determined to be invalid and removed. Workaround: N/A
CSCso96968	When Cookie Security is enabled in a profile and a request/response contains a Cookie/Set-Cookie header with all cookies being invalid, the header is left unchanged. Neither cookie encryption nor cookie signing is applied to the header and the header is passed through the Gateway unchanged. Workaround: N/A
CSCso99420	During SSL handshake with clients requesting SSL-enabled services, if there are no trusted certificate authorities configured in its policy, the Gateway emits a CertificateRequest message with no certificate names specified, in violation of the SSL specification (RFC2246). Instead, no CertificateRequest message should be emitted. Workaround: N/A
CSCsq05329	The URL Resource Refresh button causes resources in the policy that were originally imported from a URL location to be updated with changes reflected in the resource at the URL location. The refresh process does not work for XML Schema Definitions URL-based resources. (Hotfix 32)
CSCsq27898, CSCsq29250, CSCso95114	HTTP cookie validation is overly strict for some applications. When you enable cookie security in a firewall profile (that is, cookie encryption or cookie signature), the system also validates cookies for correctness. It validates HTTP cookies strictly, according to the requirements defined in RFC 2109 and its replacement RFC 2965. Cookies found not to conform with the specification are either removed from the response or normalized to meet the specification. In many practical implementations, the cookie validation and normalization performed by the Firewall may be too strict. You should enable cookie security in a production environment only after thoroughly testing its behavior for compatibility with the format and structure of the cookies generated by the backend infrastructure in your environment.
CSCsq32751	With multiple users logged in to the Manager web console in different subpolicy contexts and actively using the interface, attempts to deploy the policy may fail and result in a corrupted policy deployment. Other symptoms include failure of the http-server process to start and broken reference reports in the web console, typically in the virtual service browser but possibly other pages as well. Workaround: While there is only one user session active in the console, redeploy the policy. (Hotfix 33)
CSCsq42490	Under heavy traffic load, the Firewall may become unresponsive. Traffic processing errors occur with the following warning message in the event log: "Policy manager:worker process terminated abnormally." Workaround: N/A
CSCsq62662	Multiple Cisco products contain either of two authentication vulnerabilities in the Simple Network Management Protocol version 3 (SNMPv3) feature. These vulnerabilities can be exploited when processing a malformed SNMPv3 message. These vulnerabilities could allow the disclosure of network information or may enable an attacker to perform configuration changes to vulnerable devices. The SNMP server is an optional service that is disabled by default in Cisco products. Only SNMPv3 is impacted by these vulnerabilities. Workarounds are available for mitigating the impact of the vulnerabilities described in this document. Note SNMP versions 1, 2 and 2c are not impacted by these vulnerabilities. The United States Computer Emergency Response Team (US-CERT) has assigned Vulnerability Note VU#878044 to these vulnerabilities. Common Vulnerabilities and Exposures (CVE) identifier CVE-2008-0960 has also been assigned to these vulnerabilities. This advisory is posted at: http://www.cisco.com/warp/public/707/cisco-sa-20080610-snmpv3.shtml
CSCsq76527	With keepalive turned off in the backend application and with high traffic volume, it's possible for the Reactor processor to enter an infinite loop state. That is, the appliance becomes unresponsive with 100% CPU utilization for the Reactor process. Workaround: To avoid encountering this condition, periodically restart the Reactor process.
CSCsq78651	Numeric zeros (0) removed from IP addresses in the log and in x-forwarded-for header values. Workaround: N/A
CSCsq86661	Hostname match in port object configuration is case-sensitive. Workaround: N/A

Software Version 6.0(0) Open Caveats and Resolved Caveats

The following sections contain the open and resolved caveats in software version 6.0(0):

•Software Version 6.0(0) Open Caveats

•Software Version 6.0(0) Resolved Caveats

Software Version 6.0(0) Open Caveats

The following table lists open caveats.

Issue ID	Description
CSCsm93017	SDK Output Extensions misreport service latency time for performance monitoring purposes. Workaround: N/A
CSCso96972	Reactor does not generate log reports for invalid cookies. Enabling the Cookie Security feature in the profile (cookie signing or cookie encryption) causes the system to validate cookies and remove invalid cookies. An event is not logged when a cookie is determined to be invalid and removed. Workaround: N/A
CSCso76973	When a message inspection rule runs on the result of a function call, the event log message does not show the "value" that the rule acted on. For example, if a message inspection rule is specified which runs on "REQUEST_PARAM['paramName'].count() gt 10", the event log will contain a message like "Match was in REQUEST_PARAM['paramName'].count(), which had value ". (Notice that no value is indicated.) Workaround: N/A
CSCso96968	When Cookie Security is enabled in a profile and a request/response contains a Cookie/Set-Cookie header with all cookies being invalid, the header is left unchanged. Neither cookie encryption nor cookie signing is applied to the header and the header is passed through the Gateway unchanged. Workaround: N/A
CSCso89884	With an ACE Web Application Firewall license, enabling the HTTP header processing setting "Insert Client SSL Certificate DN in header name" results in an empty header value for the client SSL Certificate DN. Workaround: To have this header populated with the client SSL certificate DN, enable the SSL verify option. In the web console, go to System Management > IO Process Settings > HTTP Server. Change the SSLVerifyClient option from none to optional_no_ca.
CSCsq27898, CSCsq29250, CSCso95114	HTTP cookie validation is overly strict for some applications. When you enable cookie security in a firewall profile (that is, cookie encryption or cookie signature), the system also validates cookies for correctness. It validates HTTP cookies strictly, according to the requirements defined in RFC 2109 and its replacement RFC 2965. Cookies found not to conform with the specification are either removed from the response or normalized to meet the specification. In many practical implementations, the cookie validation and normalization performed by the Firewall may be too strict. You should enable cookie security in a production environment only after thoroughly testing its behavior for compatibility with the format and structure of the cookies generated by the backend infrastructure in your environment. Workaround: Disable cookie encryption or signing.
CSCsr79239	Attempting to import an unsupported base configuration version to the Manager results in Manager internal error. Software versions 6.0 and 6.0(1) only work with the initial version of the base configuration. Base configuration versions 1.0(1) and later are not intended to work with these versions. However, the Manager does not gracefully report version mismatches. Attempting to upload later base configuration versions to software version 6.0 and 6.0(1) results in an internal error in the Manager web console.

Software Version 6.0(0) Resolved Caveats

This table lists caveats resolved in release 6.0.

Issue ID	Description
CSCsl48144	The Reactor process in the ACE XML Gateway does not accept chunked HTTP requests. The ACE XML Gateway drops the requests and returns an error response with HTTP status code 411, Length Required.
CSCsm20928	With message logging enabled and the ACE XML Gateway under heavy traffic load, the Dashboard page of the ACE XML Manager web console takes a long time to load, possibly up to several minutes.
CSCsm49686	The WSDL delete operation in the ACE XML Manager results in the removal of policy objects not created by the original import of the WSDL. Only objects created by the WSDL import should be removed, and only if no manually created objects rely on the object. However, an issue exists that causes manually created backend server objects to be removed in some cases. For backend servers that are overridden by an echo server at WSDL import time, a WSDL update followed by a WSDL delete causes the echo server to be removed from the policy, if no other virtual services rely on the server object.
CSCsm68305	Setting cached SSL session reuse to 0 does not prevent SSL session caching by the Cisco ACE XML Gateway. Settings in the I/O processing page allow you to manage SSL session caching for connections from the Cisco ACE XML Gateway to destination servers. You can control the time-to-live and the maximum number of reuses for a cached SSL session. Setting the "Cached Sessions at Most" field to 0 does not prevent session caching.
CSCsm81746	The EncryptedKey and EncryptedData elements in outgoing encrypted messages do not have any namespace information included. Recipients of such messages will not be able to decrypt them and will likely indicate an unexpected element or similar error.
CSCsm85390	Denial of service detection may disable connections from localhost, in particular, from extension modules attempting to connect via localhost.
CSCsm93609	Product software updater that upgrades from 5.1.0 to 5.2.0 permits update to proceed on disk with insufficient disk space.
CSCso07822	The growth of the Manager audit log is not automatically checked; the log can eventually exhaust disk space on the Manager.
CSCso46206	SNMP Traps incorrectly sent for diskStatus and temperatureStatus objects when reporting not available status.
CSCso78856	With external LDAP authentication used for Manager web console access, a user account whose type have been changed from administrator retains certain administrative privileges.
CSCzi11658	If the Cisco ACE XML Manager is off for an extended period of time (generally at least several weeks), during which the ACE XML Gateways in its control handle a significant workload, once the Manager starts up the transfer of log information from the Gateways to the Manager may fail. The failure appears as an internal error message when visiting the Dashboard page in the ACE XML Manager web console. Workaround: For administrative purposes, the ACE XML Manager should generally not be off for an extended period of time. Nevertheless, if this issue occurs, follow these steps to recover operability of the ACE XML Manager. Note that by following these steps you will lose the historical performance statistics, but you will get new statistics going forward. 1. Access the appliance bash prompt, and change directories as follows: cd /usr/local/reactivity/log/approuter 2. Delete statistics information as follows: rm *.stats

Applying the Software Update

This section describes how to update your ACE XML Gateway or ACE Web Application Firewall appliance to the latest software version. You can apply updates to the appliance using either the chained updater or the non-chained updater. A chained updater upgrades the appliance by more than one version; a non-chained updater applies a single incremental version update. The steps for using each are similar, however, as described here.

Before performing the update, carefully read the Release Note document for the software source and target versions you are applying. If using a chained updater, be sure to read the individual release notes for each version applied by the updater, not just the release note applicable to the final version.

An ACE XML Gateway or ACE Web Application Firewall deployment consists of one or more gateway or firewall appliances and at least one Manager, the administrative server for the system. If updating a live deployment with multiple appliances, the order in which you update the appliances is important. You should update the Manager first, then any gateways or firewalls in the Manager's control. If there is more than one gateway or firewall in the Manager's control, use a rolling upgrade procedure to avoid service downtime. The following steps provide an example upgrade procedure. This example assumes that a load balancer exists upstream from a cluster of gateways or firewalls.

1. Apply the update to the Manager. When finished, make sure you can access the Manager web console.

2. Once you have confirmed the update on the Manager, disable or take out the first gateway or firewall from the server farm group configuration of the upstream load balancer.

3. Apply the update to the first gateway or firewall.

4. When finished, deploy the policy selectively from the Manager to the updated gateway or firewall.

5. Re-enable the updated gateway or firewall in the server farm of the upstream load balancer.

6. Remove the second gateway or firewall from the server farm.

7. Apply the update to the second gateway or firewall.

8. Deploy the policy to the second gateway or firewall, and put it back in the server farm.

9. Repeat steps 6 through 8 for each gateway or firewall in the server farm.

The updater script is intended to be run on a appliance that has received at least one policy deployment from the Manager. That is, you should not attempt to run the updater script on an appliance that is in its initial, factory-default state. If necessary, deploy from the Manager to all appliances at least once before running the updater. (The policy that is deployed does not need to include any special configuration—a default policy will work.)

If an update fails for any reason, please contact your Cisco support representative.

Obtaining the Updater

To acquire the version 6.0(3) software updater, perform these steps:

---

Step 1 At www.cisco.com, from the Support menu, click Download Software.

Step 2 Choose Application Networking Software in the software product category list.

Step 3 Log in, if prompted.

Step 4 From the product list, click on Cisco ACE XML Gateway.

Step 5 Click on the link for the major release version you are attempting to update.

Step 6 From the file list, download the version 6.0(3) distribution archive for either the chained or non-chained updater.

Step 7 After downloading the archive, transfer it to a directory location on the target appliance, such as to the /tmp directory.

---

Note In general, the /tmp directory on the appliance should be used for storing temporary files, such as the updater archive. The contents of this directory are purged automatically after they have been on the appliance for 10 days.

---

Step 8 Verify the distribution as follows:

a. Change to the directory in which you have put the distribution archive:

cd /tmp

b. Check the validity of the archive by issuing the md5sum command against it, as follows:

md5sum axg-update-<target_build>-from-<source_build>.tar.gz

---

Once the distribution has been validated, you can run the updater script, as described next.

Running the Updater

Once you've acquired the update archive, follow these steps to update the software on the appliance:

---

Step 1 Unpack the distribution archive, as follows:

tar xzf axg-update-<target_build>-from-<source_build>.tar.gz

Step 2 Change the current directory to the newly created directory:

cd axg-update-<target_build>-from-<source_build>

Step 3 Run the update script from the extracted update distribution directory, as follows:

./doUpdate.sh

The updater first looks for conditions that may prevent it from successfully applying the update. If it finds such conditions, the update is cancelled. If this occurs, contact your support representative.

The updater also warns you if it detects other types of unusual conditions, such as changes to non-configuration files. The script offers you the opportunity to interrupt the update to save the files or make any other changes before proceeding.

Step 4 After the initial system validity check, the updater presents the following prompt:

The statistics databases need to be checked for consistency before the update can begin. 
That required shutting down the ACE XML Manager for about one minute. 
Do you want to continue at this time? 

Enter "no" (or "n") if you want to cancel the update or enter "y" to continue.

If you enter "y", the script shuts down the system to perform the performance data consistency. If the database is found to be valid, the update proceeds as normal. If the database is found to be invalid, text such as the following appears:

Error: status database cluster62064/status is corrupted (code 1). 
At least one cluster has a corrupted database. They must be repaired in order for the 
update to proceed.  
NOTE: if the database can not be repaired, it will be deleted. 
Do you want to repair the databases during update? 

Enter "y" to have the database repaired if possible. As noted, performance data may be lost if the database cannot be repaired. If you enter "n", the update is cancelled.

---

Note The updater can be cancelled while in progress at certain times. Those times are indicated by onscreen instructions (which read in part "C to abort"). Only cancel the updater (by pressing Ctrl-C) if the onscreen instructions indicate it is possible to do so.

---

When a version update is complete, the appliance is rebooted. This occurs once for the non-chained updater and multiple times for the chained updater, once for each version update in the chain.

If you are performing the update from an SSH client, keep in mind that you will be disconnected at the first reboot, and informational messages will no longer appear. When the update is finished, you can view the information message in the updater log file located in the following directory: /var/log/reactivity/

You can verify that the chained updater has completed by logging into the Manager Console and examining the event log. If the update is still in progress, the connection from the browser to the web console will be refused. When it is finished, a Notice-level item will appear in the event log indicating the identifier of the new version running on the appliance, such as: "Running release 6.0.1-2008-06-27T21". After the chained update, each version will appear in the event log.

---

Note Do not proceed to the next step until a message indicating that the target version is running appears in the Event Log.

---

Step 5 The policy and general state of the console policy should not appear substantially different from the pre-updated version. Inspect it to be sure. Contact your support representative if you find anything in the policy that looks unusual or unexpected.

After all other appliances have been updated, recompile and deploy the policy from Manager.

---

When finished, your system is updated to the latest software version and ready for use.

Rolling Back an Update

It's possible to roll back a successful update. The rollback script included in the update distribution (doRollback.sh) restores an appliance to its state before the update was applied.

A rollback should NOT be attempted unless you are certain that the original update has completed successfully. After a chained update, you must use the same, extracted updater that was used to perform the original update. You cannot use an updater that has not been run, including an updater newly extracted from the original distribution archive.

---

Caution In general, it is strongly recommended that you contact Cisco support BEFORE attempting a rollback.

---

Related Documentation

The following documents provide information on the ACE XML Gateway product:

•ACE XML Gateway User Guide

•ACE XML Gateway Quick Start Guide

•ACE XML Gateway Administration Guide

The ACE Web Application Firewall product documents are:

•ACE Web Application Firewall User Guide

•ACE Web Application Administration Guide

•ACE Web Application Getting Started Guide

•ACE XML Gateway Quick Start Guide (included in the appliance packaging)

This document is to be used in conjunction with the documents listed in the "Related Documentation" section.

CCDE, CCENT, Cisco Eos, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, the Cisco logo, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn is a service mark; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.

All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0805R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

© 2009 Cisco Systems, Inc. All rights reserved.