Working with Virtual Web Applications

Transcription

1 CHAPTER 25 This chapter describes how to configure web application security. It covers these topics: Creating a Virtual Web Application Using Monitor Mode Creating Modifiers Creating a Virtual Web Application A virtual web application applies a set of rules and security operations to a particular class of traffic. In general, a single virtual web application will need to be added to the policy for each actual backend web application you want to protect. However, the exact correspondence between virtual web applications and the actual backend application will vary based on the nature of the application. In creating a virtual web application, you define the consumer interface that selects messages to which it applies. To avoid message matching ambiguity, the Manager prevents you from configuring two virtual web applications with identical traffic filtering criteria. However, through the use of prefix matching, regular expressions, or other overlapping filtering conditions, it is nevertheless possible to deploy multiple virtual web applications that can be matched by a single message. When a message is compatible with multiple virtual web applications, the one with the more specific consumer interface wins. In terms of the consumer interface, more specific means, for instance, a virtual URL that has a longer path or a greater number of selection parameters. There are two basic modes in which you can create a new virtual web application: Using the Basic Virtual URL option, in which the Manager automatically generates various settings for the consumer interface for the virtual web application based on the URL you enter. Using the Custom Virtual URL with Filters option, which provides fine grain control of the consumer interface generated for the virtual web application, including the ability to select traffic based on parameter or HTTP header values. The virtual URL and request filter settings comprise the client interface for the virtual web application. If advanced traffic selection criteria are not required for this application, such as request parameter filtering, you can use the Basic Virtual URL menu option to configure the interface. Note that the settings provided by the custom virtual URL option are available for a virtual web application created using the basic virtual URL option. Therefore, in most cases, it will make sense to create the virtual web application in basic virtual URL mode and modify its advanced filtering properties later, if needed

2 Creating a Virtual Web Application Chapter 25 Messages to virtual web applications are processed by the Reactor processing engine. When configuring a virtual web application, it is important to keep this in mind they 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 in the user interface when assigning these attributes to a virtual web application. A policy compilation error is generated if, after the virtual web application is created, its port or server definition is changed to use Flex Path. Creating the Virtual Web Application Using Basic Virtual URL To create a new virtual web application using the basic virtual URL mode: Step 1 Step 2 Step 3 Click the Virtual Web Applications link in the navigation menu. Click the New Virtual Web Application button to create a new virtual web application definition in the policy. A virtual web application encapsulates settings for a particular backend application for which you want to process and validate traffic at the ACE XML Gateway. Configure the virtual web application using the information in the following table: Table 25-1 Virtual Web Application settings Name Web App Group A descriptive name used to identify this virtual web application definition in the policy. This name must be unique for virtual web applications in the policy. This name will appear in log descriptions for events associated with this virtual web application, so it should be sensible for users of the event log. The group in which this virtual web application should be created. You can choose from an existing group listed in the menu or create a new group for the application by choosing new Web App Group and typing a name for the group. In general, a group should hold all virtual web applications that need to be managed and monitored together. Management operations that can be performed on a group include operating mode setting and virtual web application disabling. Groups are a reference point for monitoring as well, since the Web App Firewall Incidents report presents information by group

3 Chapter 25 Creating a Virtual Web Application Basic Virtual URL Matching Mode (Custom Virtual URL with Filters setting) With this option, specify a distinguishing portion of the request URL in incoming requests to be handled by this virtual web application, such as This is the address at which consumers will address requests to the Gateway. It is used to perform a prefix match against request URLs. Requests for this URL or any sub-path are matched to this virtual web application, such as to The trailing parts of the request URL, if any, are propagated to the outgoing request. The host portion of the URL can be a hostname or an IP address. Only specify an IP address if it is also configured at the network interface of the ACE XML Gateway to which the policy will be deployed. If it is not, the Reactor process at the Gateway will be unable to start after policy deployment. The Virtual URL value you enter will be used to populate several properties of the virtual web application, as follows: The host portion of the value is used to create a new port/hostname object, if one does not already exist for the host and port combination. By default, a server definition is created based on the request host, and is set as the destination server for the new virtual web application object. The non-hostname portion of the path is used as the Path value for the virtual web application object. The path along with the port hostname composes the URL at which the web application is exposed by the Cisco ACE XML Gateway to clients. While the port/hostname object generated by the virtual web application editor can be configured later to allow regular expression matching on the virtual hostname, regular expressions cannot be entered directly into the Virtual URL field when creating the virtual web application. The field accepts only letters, numbers, dots, and hyphen characters. Based on the path you entered, choose how you want the ACE XML Gateway to use the value to match requests. Also choose whether you want the value to be matched in a case-insensitive manner by selecting the checkbox for this option. For more information, see the preceding description for the Path field

4 Creating a Virtual Web Application Chapter 25 Destination Server The HTTP server that serves as the backend destination for this virtual web application. The Cisco ACE XML Gateway sends traffic that is qualified by this virtual web application to this destination host. The servers that appear in this menu are those that have been configured in the Destination HTTP Servers page. If set to same as virtual URL, the destination server will automatically be set to the host identified in the Virtual URL field. With the custom virtual URL option selected, the destination server maps to the Port/Hostname field. Note A virtual web application can be assigned to a destination server that uses Reactor processing only; it is not compatible with destination servers that use Flex Path processing. In the virtual web application configuration pages, destination servers that use Flex Path processing do not appear in the destination server selection menu. If a virtual web application is assigned to a destination server that later is modified to use Flex Path processing, the virtual web application will not work correctly and results in an error while policy compilation. Also the same is true for HTTP ports. Timeout Firewall Profile Monitor Mode The amount of time that the ACE XML Gateway should wait for a response from the destination server for each request. The traffic processing and validation profile that you want to apply for this web application. A profile is a named collection of rule and active security settings. The settings include whether a given rule is enabled and its configuration parameters. If the profile you want to use does not yet exist, you can set the profile to one of the built-in profiles and change it later. If selected, sets the initial operating mode of the virtual web application to monitor mode. In monitor mode, a message that triggers a message inspection rule in the applied profile is not blocked. Instead it is passed through with an event logged. When first deploying and testing the virtual web application configuration, it is often useful to set it to monitoring mode. This allows you to check for false positives (that is, legitimate traffic that nevertheless matches an attack signature) without effecting live production traffic. If the virtual web application generates false positives, you can quickly create a modifier that exempts the matched traffic from the rule that triggered the blocking event from the log description for the event. Note that message rewrite rules are applied to traffic handled by the virtual web application in monitor mode. Also note that, in enabled mode, messages are rejected at the first instance in which they violate a rule and are not further evaluated against other rules in the profile. The event log or incidents report will only show the rule that caused the message to be blocked, not any other rule that a message may have violated had its processing continued. On the other hand, in monitor mode, all rules violated by a message are indicated

5 Chapter 25 Creating a Virtual Web Application Step 4 When finished, click Save Changes to commit the new virtual web application to the working policy. Creating the Virtual Web Application using Custom Virtual URL With Filters To create a new virtual web application using the custom virtual URL with filters mode, follow the steps in Creating the Virtual Web Application Using Basic Virtual URL section on page However, instead of the Basic Virtual URL option, choose Custom Virtual URL With Filters, and configure the settings specific to this option: Table 25-2 Virtual URL filter settings Port/Hostname (Custom Virtual URL with Filters setting) The port object on which the virtual web application should listen for traffic for this web application. The port defines a listening port number and virtual hostname. It also provides configuration settings for a static response page that can be used for health checks on the Cisco ACE XML Gateway. If the port is not in the menu, create it on the HTTP Ports & Hostnames page. If the Destination Server option is set to same as virtual URL, the value of port/hostname will be automatically propagated as the destination service for the virtual web application. To change the port and hostname value while keeping the existing destination server setting, change the Destination Server from the same as virtual URL option to a specific server definition. Note A virtual web application can be assigned to the ports that use Reactor processing only; it is not compatible with ports that use Flex Path processing. In the virtual web application configuration pages, ports that use Flex Path processing do not appear in the port section menu. If a virtual web application is assigned to a port and later is modiffied to use Flex Path processing, the virtual web application will not work correctly and results in error while policy compilation. Also the same is true for the HTTP servers

6 Creating a Virtual Web Application Chapter 25 Path (Custom Virtual URL with Filters setting) Matching Mode (Custom Virtual URL with Filters setting) Methods (Custom Virtual URL with Filters setting) The path addressed by incoming requests that you want to be matched to this virtual web application. As specified by the Matching Mode setting for the path, the path may be: The exact request path in messages that you want to match, such as: oakinsurance/customer This will only match requests that specify as the request path the entire string, without additional characters A prefix to the request path, such as: oakinsurance/ This path will match any request address that begins with oakinsurance/, such as oakinsurance/customer/getquote or oakinsurance/partners A path made that includes regular expression components, such as: oakinsurance/.*/getquote In this case, the regular expression command sequence (.*) is used to match any characters, so that both oakinsurance/customer/getquote and oakinsurance/partners/getquote would be matched. A backslash character can be used in this field to escape regular expression command characters. The regular expression implementation in the Web Application Security features of the Cisco ACE XML Gateway is based on PCRE (Perl-Compatible Regular Expressions). Based on the path you entered, choose how you want the ACE XML Gateway to use the value to match requests. Also choose whether you want the value to be matched in a case-insensitive manner by selecting the checkbox for this option. For more information, see the preceding description for the Path field. The HTTP request method of the requests to be matched to this virtual web application. The method appears as the first token in the request line of the request, such as GET in GET /images/logo.gif HTTP/1.1. Options are: ignore The HTTP request method is not considered. basic HTTP methods (GET/POST/HEAD) matches only the methods listed, excluding requests with other methods such as DELETE or TRACE. any standard HTTP 1.x method The request must be one that is defined as a standard HTTP 1.0 or 1.1 method, including GET, POST, HEAD, PUT, DELETE, OPTIONS, or TRACE. specified HTTP 1.x methods Standard HTTP 1.0 or 1.1 methods that you select. custom Any method name that you specify. If entering more than one, specify one method name per line. The name should match exactly the method specified in the first line of the request. Note that the method names you type are automatically converted to uppercase. They are matched to messages in a case-sensitive manner

7 Chapter 25 Using Monitor Mode HTTP Headers (Custom Virtual URL with Filters setting) Parameters (Custom Virtual URL with Filters setting) Configure this option to have requests matched to this virtual web application based on the presence or value of one or more HTTP headers in the request. Requests that do not have the specified HTTP headers or values are not handled by this virtual web application. HTTP header names are matched in a case-insensitive manner, while their values are matched case-sensitive. Configure this option to have requests matched to this virtual web application based on the presence or value of one or more request parameters. Requests with parameters that do not match your requirements are not handled by this virtual web application. Parameter names and values are compared to messages in a case-sensitive manner. Parameters can be URL arguments in the request or parameters in the body of POST requests. URL arguments appear as ampersand-delimited name-value pairs in the request URL, as illustrated by the zip and session parameters: oakinsurance/partners/getquote?zip=94114&session=01234 You can set requirements for parameters using Perl-style regular expressions or by identifying the parameter by name. Specify request parameter requirements using these operators: exists The message must have the named parameter. matches regex The value of the named parameter must match the regex you specify. is The value of the named parameter must match the characters you specify, case-sensitive. is not The value of the named parameter must not match the characters you specify, case-sensitive. Note that specifying a matching or a non-matching ( is not ) requirement does not require that the parameter be present in the request. That is, if a request that otherwise matches the filter does not contain a parameter for which you ve specified a matching or non-matching value, it is accepted. Using Monitor Mode The processing mode for a virtual web application can be one of: enabled The ACE XML Gateway blocks messages that violate message inspection rules and applies content rewrite rules and active security features. monitor mode If selected, the ACE XML Gateway does not block traffic that matches a message inspection rule or violates an active security setting. Instead, it logs the event. This mode is useful for testing a configuration or monitoring the prevalence of potentially malicious traffic without affecting the traffic flow. Message rewrite rules, HTTP processing, exception mapping, and cookie security are applied to traffic even if the virtual web application is in monitor mode. disabled Stops the ACE XML Gateway from receiving traffic on the consumer interface defined for the virtual web application. Note that traffic is blocked unless a less specific virtual web application consumer interface exists that matches the messages that would have been matched by the disabled virtual web application

8 Using Monitor Mode Chapter 25 The monitor mode is particularly useful for testing and developing the policy. In enabled mode, messages are rejected at the first instance at which they violate a rule; they are not further evaluated against other rules in the profile. The event log or incidents report will only show the rule that caused the message to be blocked, not any other rule that a message may have violated had its processing continued. On the other hand, in monitor mode, if a message is found to violate a rule, it continues to be processed by the other rules in the profile. This allows you to view in the log all rules that a message would violate, not just the first blocking rule triggered. You can set the operating status in the policy at several contexts: for a rule in a profile for an individual virtual web application for a group for all virtual web applications in the policy. You can also specify a default mode for newly created virtual web applications. Since it is usually advisable to observe the interaction of a virtual web application with network traffic in passive mode, before it affects the network traffic. For a given virtual web application, monitor mode works the same way whether set policy-wide, from the group, or just for the virtual web application. To set the operating mode policy-wide: Step 1 Step 2 Click the Virtual Web Applications link from the navigation menu. From the Set all virtual web apps to menu on the Virtual Web Applications, choose the desired operating mode: enabled, monitor mode, or disabled. To set the operating mode by group: Step 1 Step 2 Step 3 Click the Virtual Web Applications link from the navigation menu. Click on the name of the virtual web application group that you want to set. The group names appear in the green-shaded headings. From the Set all virtual web apps to menu in the group page, choose the desired operating mode, enabled, monitor mode, or disabled. To set the operating mode for an individual virtual web application: Step 1 Step 2 Step 3 Step 4 Click the Virtual Web Applications link from the navigation menu. Click on the name of the virtual web application that you want to set. The group names appear in the green-shaded headings. From the edit link next on the right side of the overview header. Click the Monitor Mode check box at the bottom of the page. The mode change is applied as a one-time event; that is, after setting the monitor mode with this control, the operating mode of groups or virtual web applications can be changed individually

9 Chapter 25 Creating Modifiers Creating Modifiers A virtual web application can contain one or more modifiers. Like a virtual web application, a modifier applies rules and security actions to selected traffic. However, a modifier selects traffic only from the traffic handled by the virtual web application. A modifier applies traffic processing settings to a subset of the traffic handled by the containing virtual web application. While the settings in a modifier are originally derived from the virtual web application, they are otherwise independent of that virtual web application. That is, messages selected by a modifier are subject only to its processing settings (not to the modifier s as well as the virtual web application settings). You can create modifiers directly or from the event log. For events associated with virtual web applications rules, the event log descriptions contain a Create Exemption link, which allow you to quickly modify a policy to avoid false positives. It creates a new modifier page for the virtual application with a preset configuration based on the event. Note A modifier should be used only when you have a distinct subclass of traffic at a virtual web application that you want to process or validate differently. In many cases, the quality of a request that generated a false positive could be present in requests to other parts of the web application as well, not just to the subclass of traffic selected by the modifier. In this case, it is likely more appropriate to address a false positive through a profile-level change rather than by the addition of a modifier. When you create a modifier, its traffic filter is prepopulated with any required filter criteria from the virtual web application. If you attempt to change required settings, an error message appears in the interface. If you change the virtual web application filter criteria to be incompatible with modifiers that already exists, a compile time error is generated. Creating Modifiers Directly To create a modifier directly (that is, not through an event log incident): Step 1 Step 2 Step 3 Step 4 Click the Virtual Web Applications link in the navigation menu. Click on the name of the virtual web application for which you would like to create a modifier. Click the add modifier link. In the Request Filter for Firewall Modifier page, specify traffic-selection criteria to which this modifier applies. The settings are prepopulated with the traffic selection criteria of the virtual web application. Keep in mind that a modifier selects traffic from the traffic flow handled by the virtual web application based on its request filter criteria. Therefore, the modifiers selection criteria must be more specific, but also compatible with that of the virtual web application. For a modifier that selects by URL path, for instance, this means that the modifier path must extend the path of the virtual web application. Configure the filter settings described in the following table

10 Creating Modifiers Chapter 25 Table 25-3 FIlter settings Path Methods HTTP Headers Parameters The request path that selects the messages to which you want this modifier to apply. The modifier selects messages from the traffic stream handled by the virtual web application; therefore, the path must extend the path of the virtual web application. For example, with a virtual web application path of /oakinsurance, the modifier path could be /oakinsurance/customer or /oakinsurance/partners/quotes/. From the HTTP methods accepted by the virtual web application, choose the subset of this modifier should accept. Notice that the methods accepted by the virtual web application are prepopulated in the request filter. Specifies traffic selection criteria based on HTTP header values in incoming requests. Specifies traffic selection criteria based on parameters in incoming requests. Step 5 Step 6 Step 7 Click Save Changes. The Edit Firewall Modifier page displays the profile as applied by the parent virtual web application. Modify its configuration as desired for processing traffic by this modifier by clicking the override link for a rule. You can configure specialized security actions, message inspection rules, and message rewrite rules to be applied by the modifier. When finished click the Exit to Virtual Web App Group link. Creating Incident-Based Modifiers The ACE XML Manager enables you to quickly adjust the policy based on incidents generated by actual traffic at the Gateway. This feature allows you to quickly configure the policy to accept the traffic that generated an incident, typically as a result of a false positive (that is, for legitimate messages that are incorrectly categorized as security threats). Note An incident-based modifier generates very specific traffic selection criteria, by default. It should be created only to have a distinct subclass of traffic at a virtual web application processed or validated differently. In many cases, the quality of a request that generated a false positive could be present in requests to other parts of the web application as well, not just to the subclass of traffic selected by the modifier. In this case, it is likely more appropriate to address a false positive through a profile-level change rather than by the addition of a modifier. To create an incident-based modifier: Step 1 Step 2 Step 3 Click the Event Log link from the navigation menu. Locate a log description for an event from which you want to create a modifier. You may need to adjust the log view filtering criteria at the top of the page. Event descriptions associated with web application security events include a Create Exemption link. Clicking the Create Exemption link for the item. A page opens in which you can create a modifier based on the event

11 Chapter 25 Creating Modifiers Step 4 Adjust the default settings as needed and save the configuration. For details on modifier configuration, see Creating Modifiers Directly section on page

12 Creating Modifiers Chapter