Applies To:

Show Versions Show Versions

Manual Chapter: Working with Wildcard Entities
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Wildcard entities are web application entities in the security policy that contain one or more shell-style wildcard characters. In Application Security ManagerTM, wildcard entities can represent file types, URLs, parameters, and cookie headers. Wildcards provide flexibility for security policy building. By using wildcard entities, you can efficiently build a security policy without in-depth knowledge of the web application, and reduce the number of violations and false-positives.
This chapter describes how to manually create wildcard entities. If you are using automatic policy building, the Policy Builder creates wildcards, adds explicit entities, and when the security policy is stable, removes wildcards and enforces the explicit entities, depending on the configuration. In that case, you do not need to create wildcards because the security policy is built automatically.
The syntax for wildcard entities is based on shell-style wildcard characters. Table 9.1 lists the wildcard characters that you can use in a wildcard entity name.
The easiest wildcard to configure is the asterisk (*), which the system interprets as match everything. You can use the * character on its own, or in a name.
Note: If you add to the security policy a wildcard URL that does not begin with the asterisk (*) character (for example a*b), the system does not automatically add the slash (/) character before it. You must manually add the slash (/) character before this type of URL for the system to enforce it.
When you create a wildcard entity, you have the option to enable staging and tightening for that entity. You can use tightening first to learn explicit entities, review and enforce learning suggestions; the system automatically enables staging for entities you have learned. F5 Networks recommends against using both staging and tightening on the same entity.
Tightening is using wildcards to learn the entities (file types, URLs, parameters, and cookies). Staging is learning the attributes of an entity (wildcard or explicit), providing additional granularity over tightening.
You can perform tightening on wildcard entities (file types, URLs, parameters, and cookies) to learn explicit entities. When you enable tightening for a wildcard entity, and the system receives a request that contains an entity that matches the wildcard entity, the system generates a learning suggestion for the found entity. You can then review the new entities, and decide which are legitimate entities for the web application.
Tightening gives you the option of developing a more specific policy, a policy that is more accurate and in alignment with the traffic. Such a policy can provide better security, but requires more tuning to make sure all the specific entities that you add are accurately configured.
If the Policy Builder is running and the traffic source is trusted (either by definition or because of heuristic decisions), the Policy Builder automatically adds the new specific entity to the security policy.
Note: When you accept learning suggestions, you add explicit entities to the security policy. The next time the system receives a request with that entity, the Security Enforcer applies the security policy to the explicit entry, and not to its parent wildcard entity. Note also that accepting many explicit entities may complicate security-policy maintenance.
Each security policy can have wildcards for file types, URLs, parameters, and cookies. When you create a security policy using the Deployment wizard, the system enables tightening on wildcard entities (depending on the scenario you select). As traffic is sent to the web application, the system learns the explicit properties of the file types, URLs, parameters, and cookies.
Tip: Use tightening on wildcard entities to build the security policy with explicit entities, and then enforce the entities that are ready to be enforced by using the Enforce and Enforce Ready buttons. When you accept tightening suggestions for a wildcard, the system automatically places the explicit entity into staging.
You can perform staging on wildcard entities (file types, URLs, and parameters) to learn the properties of the entities, as described in Table 9.2.
When an entity is in staging, the system does not block any requests for this entity. Instead, it posts learning suggestions for staged entities on the Learning screens. After the staging period is over and you see that requests for this entity do not log additional learning suggestions, F5 Networks recommends you take the entity out of staging by clearing the Perform Staging check box on the file types, URLs, or parameters properties screen. This is necessary only if you are manually building a security policy, and not using automatic policy building.
Tip: Use staging on wildcard entities to build the security policy without explicit entities of this type, so that the wildcard entity itself is enforced with the settings found on it.
Staging is also extremely useful when a site update occurs for a web application. With staging, you can add new URLs or parameters to the security policy and stage only the new entities. You can keep existing policy entities in blocking mode, while placing the new entities in transparent mode, which can generate learning alerts.
1.
In the navigation pane, expand Application Security, point to Manual Policy Building and click Staging-Tightening Summary.
The Staging-Tightening Summary screen opens.
2.
In the Staging-Tightening Summary, check to see if a number other than 0 appears in the Ready To Be Enforced column.
4.
Click the Enforce Ready button.
A confirmation popup screen opens where you can confirm that you want to enforce all entities that are ready to be enforced for the selected entity types.
5.
Click OK.
The screen refreshes; the system performs the following on selected entities:
1.
In the navigation pane, expand Application Security, point to Manual Policy Building and click Staging-Tightening Summary.
The Staging-Tightening Summary screen opens.
2.
In the Staging-Tightening Summary, check to see if a number appears in the In Staging-Tightening column.
A number greater than zero indicates that entities of that type were discovered while in staging or with tightening enabled.
3.
Click the number to view the file types, URLs, or parameters in staging or with tightening enabled.
The allowed file types, URLs, or parameters list opens.
5.
Click the Enforce button.
A confirmation popup screen opens, where you confirm that you want to enforce all selected entities.
6.
Click OK.
The screen refreshes; the system performs the following on selected entities:
Check for explicit matches
First, the Security Enforcer checks for an explicit match, that is, the Security Enforcer scans the security policy to verify whether it contains the exact entity. If the security policy contains an explicit matching entity, the system applies the checks that are specified for that entity.
Check for wildcard matches
If the security policy does not contain an explicit matching entity, the system checks the wildcard entities to determine whether any of them match the requested entity. If the system finds a wildcard match, the Security Enforcer applies any applicable security checks. If you have enabled tightening for the wildcard entity, the Security Enforcer generates a learning suggestion for the new entity, which the system displays on the Traffic Learning screen.
If the Security Enforcer does not find an explicit match or a wildcard match, the system generates a violation for the illegal entity. If the triggered violation is in blocking mode, the system drops the request and sends the Blocking Response page to the client.
File types represent the file type extensions of the files that make up the web application, such as htm, jsp, and gif. You can specify wildcard file types in a security policy when you do not want the overhead of maintaining a list of explicit file types.
You can create a wildcard file type so that requests do not generate violations based on the requested file type. Any file type that matches the wildcard expression is considered legal. For example, the wildcard * specifies that any file type is allowed by the security policy. By default, allowed file types you create are put into staging. If you want to enable tightening (first disable staging), you can learn which file types are used in the protected web application. For more information, see Working with entities in staging or with tightening enabled.
1.
In the navigation pane, expand Application Security and click File Types.
The Allowed File Types screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the Allowed File Types list, click the Create button.
The Add Allowed File Type screen opens.
4.
For the File Type setting, select Wildcard from the list, and then type a wildcard string in the box (for example, *).
5.
If you want the system to display explicit file types that match the wildcard entity pattern that you specify, clear the Perform Staging check box, and then check the Perform Tightening setting.
Note: F5 Networks recommends against using both tightening and staging at the same time on the same wildcard entity.
7.
8.
Click the Create button to add the wildcard file type to the security policy.
The screen displays the updated Allowed File Types screen.
9.
To put the security policy changes into effect immediately, click the Apply Policy button, then click OK to confirm.
The system applies the updated security policy.
1.
In the navigation pane, expand Application Security and click File Types.
The Allowed File Types screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the Allowed File Types list, in the Type column, click the name of the file type that you want to modify.
The Allowed File Type Properties screen opens.
5.
Click the Update button to update the security policy with any changes you may have made.
The screen refreshes, and displays the Allowed File Types screen.
6.
To put the security policy changes into effect immediately, click the Apply Policy button, then click OK to confirm.
The system applies the updated security policy.
You can delete wildcard file types once the explicit file types used in the application have been added to the security policy.
1.
In the navigation pane, expand Application Security and click File Types.
The Allowed File Types screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the Select column (far left), check the box next to the wildcard file type that you want to remove, and then click the Delete button.
The system displays a confirmation popup screen.
4.
Click OK.
The system deletes the wildcard file type from the configuration.
5.
To put the security policy changes into effect immediately, click the Apply Policy button, then click OK to confirm.
The system applies the updated security policy.
When you have configured more than one wildcard file type, you can set the enforcement order, which is the sequence in which the Security Enforcer searches for a match within those wildcard file types. If it finds a match, the Security Enforcer then applies the security checks that are associated with that wildcard entity to the matching entity.
You can organize wildcard file types in the sequence that you want them to be enforced, which is from most-specific to least-specific. The system enforces wildcard file types from the top down.
1.
In the navigation pane, expand Application Security and click File Types.
The Allowed File Types screen opens.
2.
On the menu bar, click Wildcards Order.
The Wildcards Order screen opens.
3.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
4.
For the Wildcard File Types List setting, make any adjustment to the list order by using the Up and Down buttons.
5.
Click the Save button to save any changes you may have made.
6.
To put the security policy changes into effect immediately, click the Apply Policy button, then click OK to confirm.
The system applies the updated security policy.
URLs represent the pages and images that compose the web application. Wildcard URLs use wildcard characters in the URL name. When you are building a security policy, using wildcard URLs reduces the number of false-positives. You can also use wildcard URLs in a security policy when you do not want the overhead of maintaining explicit URLs. By using wildcard URLs, you can configure security checks for a set of URLs, rather than configuring the security checks for each individual URL.
You can create a wildcard URL so that requests do not generate violations based on the requested URL. Any URL that matches the wildcard expression is considered legal. For example, the wildcard expression * specifies that any URL is allowed by the security policy. By default, allowed wildcard URLs you create are put into staging. If you want to enable tightening (first disable staging), you can learn which URLs are used in the protected web application.
1.
In the navigation pane, expand Application Security and click URLs.
The Allowed URLs List screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the Allowed URLs List area, click the Create button.
The New Allowed URL screen opens.
4.
For the URL setting, select Wildcard from the list, and then type a wildcard string in the box (for example, *).
The screen refreshes and displays additional settings for meta characters.
5.
If you want the system to display explicit URLs that match the wildcard entity pattern that you specify, clear the Perform Staging check box, and then check the Perform Tightening setting.
Note: F5 Networks recommends against using both tightening and staging at the same time on the same wildcard entity.
6.
For the Protocol setting, select the web applications protocol.
7.
If you want the system to validate XML data in requests to this URL based on the settings configured in an XML profile, check the Apply XML Profile setting.
a)
If you already have an XML profile, select one from the list. If not, click the + button to create one for the security policy. For details, see Chapter 12, Protecting XML Applications.
b)
For the Check XML Content-Type Headers setting, specify how the system applies the XML profile to requests for this URL.
Select All if you want the system to inspect all requests.
Select User-defined and type a string if you want the system to inspect only those requests whose Content-Type header value contains the string you specified. The default value is *xml*.
b)
Check the Check AMF (When the content type matches "amf") box.
9.
For the URL Description setting, type an optional description.
10.
In the Meta Characters area, the Check characters on this URL setting is enabled by default so that the system verifies meta characters in the URL. (If you do not want to check for meta characters, clear the check box, and proceed to step 11.)
a)
From the Global Security Policy Settings list, select any meta characters that you want to specifically allow or disallow, and move them to the Overridden Security Policy Settings list.
Note: The Overridden Security Policy Settings take precedence over the global settings for the web applications character set.
11.
Click the Create button to add the wildcard URL to the security policy.
The screen displays the updated Allowed URLs List screen.
12.
To put the security policy changes into effect immediately, click the Apply Policy button, then click OK to confirm.
The system applies the updated security policy.
Tip: If you enabled staging or tightening and Policy Builder is enabled, the system analyzes traffic going to the web application and adds entities or their properties to the policy. If you did not, you can accept learning suggestions manually. For details, see Working with entities in staging or with tightening enabled.
1.
In the navigation pane, expand Application Security and click URLs.
The Allowed URLs List screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the Allowed URLs List area, in the URL column, click the name of the URL that you want to modify.
The Allowed URL Properties screen opens.
5.
Click the Update button to update the security policy with any changes you may have made.
The screen refreshes, and displays the Allowed URLs List screen.
6.
To put the security policy changes into effect immediately, click the Apply Policy button, then click OK to confirm.
The system applies the updated security policy.
1.
In the navigation pane, expand Application Security and click URLs.
The Allowed URLs List screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the Allowed URLs List area, check the box next to the wildcard URL that you want to remove, and then click the Delete button.
The system displays a confirmation popup screen.
4.
Click OK.
The system deletes the wildcard URL from the configuration.
5.
To put the security policy changes into effect immediately, click the Apply Policy button, then click OK to confirm.
The system applies the updated security policy.
When you have configured more than one wildcard URL, you can set the enforcement order, which is the order in which the Security Enforcer searches for a match within those wildcard URLs. If the Security Enforcer finds a match in the wildcard URLs, the Security Enforcer then applies the security checks that are associated with that wildcard entity to the matching entity.
Tip: When ordering wildcard URLs, you should arrange them in the order in which you want them to be enforced. The system enforces them from the top down.
1.
In the navigation pane, expand Application Security and click URLs.
The Allowed URLs List screen opens.
2.
On the menu bar, click Wildcards Order.
The Wildcards Order screen opens.
3.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
4.
In the Wildcards Order area, for the Wildcard URLs List setting, make any adjustment to the list order by using the Up and Down buttons.
5.
Click the Save button to save any changes you may have made.
6.
To put the security policy changes into effect immediately, click the Apply Policy button, then click OK to confirm.
The system applies the updated security policy.
You can specify wildcard parameters in a security policy when you do not want the overhead of maintaining a list of explicit parameters. Using wildcard parameters reduces the number of Illegal parameter violations you receive when creating a security policy.
If you create a wildcard parameter and enable staging or tightening, you can also learn the types or attributes of the parameter, and which parameters are used in the protected web application.
For wildcard parameters that you create, any parameter name that matches the wildcard expression is permitted by the security policy. For example, typing the wildcard * specifies that the security policy allows every parameter. By default, new parameters you create are put into staging. If you want to enable tightening (first disable staging), you can learn which parameters are used in the protected web application.
1.
In the navigation pane, expand Application Security and click Parameters.
The Parameters List screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the Parameters List area, click the Create button.
The Add Parameter screen opens.
4.
In the Create New Parameter area, for the Parameter Name setting, select Wildcard from the list, and then type a wildcard string in the box (for example, *).
5.
For the Parameter Level setting, select the appropriate option for this wildcard parameter.
URL Parameter: For more information, see Working with URL parameters.
Flow Parameter: For more information, see Working with flow parameters.
6.
If you want the system to display explicit parameters that match the wildcard entity pattern that you specify, clear the Perform Staging box, and then check the Perform Tightening box.
Note: F5 Networks recommends against using both tightening and staging at the same time on the same wildcard entity.
7.
To allow requests to contain multiple parameters with the same name, check the Allow Repeated Occurrences box. The default setting is disabled.
8.
If you want to treat the parameter you are creating as a sensitive parameter (not visible in logs or the user interface), check Sensitive Parameter.
9.
For the Parameter Value Type setting, select the appropriate type from the list.
The screen refreshes to display additional settings that are relevant to the parameter value type that you selected.
Note: For detailed information regarding the parameter value type options, see Understanding parameter value types.
10.
Configure the remaining settings as required, and then click the Create button.
The screen refreshes, and displays the new wildcard parameter.
11.
To put the security policy changes into effect immediately, click the Apply Policy button, then click OK to confirm.
The system applies the updated security policy.
Tip: If you enabled staging or tightening and Policy Builder is enabled, the system analyzes traffic going to the web application and adds entities or their properties to the policy. Otherwise, you can accept learning suggestions manually. For details, see Working with entities in staging or with tightening enabled.
You may want to modify the settings for an existing wildcard parameter. You can change the properties of a parameter, but you cannot change its name.
1.
In the navigation pane, expand Application Security and click Parameters.
The Parameters List screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the Parameters List area, in the Parameter Name column, click the name of the wildcard parameter that you want to modify.
The [Global/URL/Flow] Parameter Properties screen opens.
5.
Click the Update button to update the security policy with any changes you may have made.
The screen refreshes, and displays the Parameters List screen.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
A confirmation popup screen opens.
7.
Click OK.
The system applies the updated security policy.
1.
In the navigation pane, expand Application Security and click Parameters.
The Parameters List screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the Parameters List area, in the Select column (far left), check the box next to the wildcard parameter that you want to remove, and then click the Delete button.
The system displays a confirmation popup screen.
4.
Click OK.
The system deletes the wildcard parameter from the configuration.
5.
To put the security policy changes into effect immediately, click the Apply Policy button, then click OK to confirm.
The system applies the updated security policy.
When you configure more than one wildcard parameter, you can set the enforcement order, which is the sequence in which the Security Enforcer searches for a match within those wildcard parameters. If the Security Enforcer finds a match in the wildcard parameters, the Security Enforcer then applies the security checks that are associated with that wildcard entity to the matching entity. For wildcard parameters, the system looks for matches in this order: flow parameters, URL parameters, then global parameters.
The Security Enforcer always looks for a match on an explicit parameter first. If the explicit parameter is not found, the Security Enforcer looks for the next possible wildcard match on the current level, that is, flow, URL, or global. This process continues for each parameter level, as shown in Figure 9.1.
Tip: When adding wildcard URLs, you should arrange them in the order in which you want them to be enforced. The system enforces them from the top down.
1.
In the navigation pane, expand Application Security and click Parameters.
The Parameters List screen opens.
2.
On the menu bar, click Wildcards Order.
The Wildcards Order screen opens.
3.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
4.
In the Wildcards Order area, for the Global Parameters Wildcards List, the URL Parameters Wildcards List, and the Flow Parameters Wildcards List options, adjust the order of the wildcards in the list by using the Up and Down buttons for each option.
5.
Click the Save button to save any changes you may have made.
6.
To put the security policy changes into effect immediately, click the Apply Policy button, then click OK to confirm.
The system applies the updated security policy.
You can use wildcards for allowed modified cookie headers to reduce the number of Modified domain cookie violations you receive when creating a security policy. For more information on cookie headers, refer to Configuring allowed modified cookies.
You can enable tightening on wildcard cookies to cause the system to build the security policy by adding explicit cookies. When all of the explicit cookies have been learned, you (or the Policy Builder, if using automatic policy building) can delete the wildcard entity.
1.
In the navigation pane, expand Application Security and click Headers.
The Cookies screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the Allowed Modified Cookies area, click the Create button.
The New Allowed Cookie screen opens.
4.
From the Cookie Name Type list, select Wildcard.
5.
In the Cookie Name box, type the pattern string that matches the cookie name.
Tip: For wildcard syntax, refer to Understanding wildcard syntax.
6.
If you want the system to add explicit cookies that match the wildcard cookie, check the Tightening box.
7.
Click the Create button.
The screen refreshes, and you can see the newly created allowed cookie in the Allowed Modified Cookies area.
8.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area, then click OK to confirm.
The system applies the updated security policy.
You can check the tightening status of the cookies on the list of allowed modified cookies. If the wildcard allowed modified cookie has been tightened, the system displays a light bulb icon. The color of the light bulb provides details about the status of the allowed modified cookie:
Green
Indicates that no learning suggestions are available, but the tightening period is not over.
Yellow
Indicates that learning suggestions are available. Move the cursor over the light bulb icon to view whether the tightening period is over, or not.
Orange
Indicates that no learning suggestions are available and the tightening period is over. This entity is ready to be taken out of tightening, and be enforced.
We recommend you take an entity out of tightening when its tightening period is over, and you validate that requests for this entity did not log any suggestions.
1.
In the navigation pane, expand Application Security and click Headers.
The Cookies screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those you are interested in.
3.
If you want to search for cookies containing a specific string, after for the Cookie Name Contains setting, type the string.
4.
For Cookie Name Type, select Wildcard.
5.
For Tightening, specify the status of the cookies you want to display:
6.
Click Go to cause the system to filter the list of allowed modified cookies.
The system updates the list of allowed modified cookies.
7.
In the Tightening column of the allowed modified cookies list, point to the light bulb icon.
The system displays information on the last time you or the Policy Builder tightened this wildcard entity (the last tightening event time).
8.
If the status indicates that learning suggestions are available for any of the allowed modified cookies, in the navigation pane, point to Manual Policy Building, then click Staging-Tightening Summary.
The Staging-Tightening Summary screen opens.
9.
In the Allowed Cookies row, click the number in the Have Suggestions column.
Learning suggestions for that cookie are displayed.
10.
Review the suggestions that match the wildcard, decide which are legitimate for the web application, and accept them to the security policy.
You can delete wildcards for allowed modified cookies that you do not need in the security policy by enforcing the cookies. If a cookie in the allowed modified cookies list has an orange light bulb status, the tightening period is over and no more learning suggestions are available. In this case, you may want to enforce the allowed modified cookie.
1.
In the navigation pane, expand Application Security and click Headers.
The Cookies screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the Allowed Modified Cookies area, in the Select column (far left), check the box next to the wildcard cookie that has tightening enabled and which you want to remove, click the Enforce button, and then confirm.
The system deletes the wildcard cookie from the configuration.
4.
To put the security policy changes into effect immediately, click the Apply Policy button, then click OK to confirm.
The system applies the updated security policy.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)