Table Of Contents
Release Note for the Cisco ACE XML Gateway
January 29, 2009
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)
This section lists important new software features and feature enhancements in this 6.0(0) release, including:
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.
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
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-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
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
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:
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
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.
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
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.
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)
•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
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.
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
The following table lists open caveats.
Software Version 6.0(3) Resolved Caveats
The following table lists resolved caveats.
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
The following table lists open caveats.
Software Version 6.0(2) Resolved Caveats
This table lists caveats resolved in release 6.0(2).
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
The following table lists open caveats.
Software Version 6.0(1) Resolved Caveats
This table lists caveats resolved in release 6.0(1).
Issue ID Description
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
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
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
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
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.
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)
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
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:
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.
Numeric zeros (0) removed from IP addresses in the log and in x-forwarded-for header values. Workaround: N/A
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
The following table lists open caveats.
Software Version 6.0(0) Resolved Caveats
This table lists caveats resolved in release 6.0.
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:
b. Check the validity of the archive by issuing the md5sum command against it, as follows:
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:
Step 3 Run the update script from the extracted update distribution directory, as follows:
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.
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.