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 Manager, 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 Real Traffic 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 8.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 does not recommend 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 use tightening on wildcard entities (file types, URLs, parameters, and allowed cookies) to learn explicit entities. When you enable tightening for a wildcard entity, and the system receives a request that includes data that matches the wildcard entity, the system generates a tightening 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 system 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 when no more explicit entities are seen, remove the wildcard entity 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 either explicit or wildcard entities (file types, URLs, parameters, enforced cookies, and signatures) to learn the properties of the entities, as described in Table 8.2.
Parameter settings, name meta characters, value lengths, and XML and JSON violations
Cookie changes. You can put a cookie in staging to make sure that it does not change or cause violations that will block requests. If the security policy is in blocking mode, the system does not block requests with cookies that cause violations. It provides learning suggestions for issues that could be false positives.
When an entity is in staging, the system does not block requests that cause violations relevant to this entity. Instead, it posts learning suggestions for staged entities on the Learning screens. You can take an entity out of staging by clicking the Enforce button for that entity. You can also take the entity out of staging by clearing the Perform Staging check box on the file types, URLs, parameters, cookies, or signatures 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 staging (making them transparent).
To enforce file types, URLs, parameters, cookies, and signatures that are ready to be enforced
1.
On the Main tab, expand Application Security, point to Policy Building, Manual, 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:
To enforce file types, URLs, parameters, cookies, or signatures in staging or with tightening enabled
1.
On the Main tab, expand Application Security, point to Policy Building, Manual, 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 specific file types, URLs, parameters, cookies, or signatures that are ready to be enforced.
The allowed file types, URLs, parameters, cookies, or signatures 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:
Check for explicit matches
First, the system checks for an explicit match by scanning the security policy for 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 matches the requested entity. If the system finds a wildcard match, it applies any applicable security checks. If you have enabled tightening for the wildcard entity, the system generates a learning suggestion for the new entity, which the system displays on the Traffic Learning screen.
If the system 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.
On the Main tab, expand Application Security and click File Types.
The Allowed File Types screen opens.
2.
In the editing context area, ensure that the Current edited policy is the one 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 field (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 select the Perform Tightening setting.
Note: F5 Networks does not recommend using both tightening and staging at the same time on the same wildcard entity.
7.
If you want the system to validate responses to requests containing this file type, select the Check Response check box.
Tip: Checking this potion enables attack signatures (that are designed to inspect server responses) to filter responses.
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.
On the Main tab, expand Application Security and click File Types.
The File Type Properties screen opens.
2.
In the editing context area, ensure that the Current edited policy is the one 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 File Type Properties screen opens.
5.
Click the Update button to update the file type 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.
On the Main tab, expand Application Security and click File Types.
The Allowed File Types screen opens.
2.
In the editing context area, ensure that the Current edited policy is the one that you want to update.
3.
In the Select column (far left), select 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 system searches for a match within those wildcard file types. If it finds a match, the system 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 in which you want to enforce them, which is from most-specific to least-specific. The system enforces wildcard file types from the top down.
1.
On the Main tab, 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 Current edited policy is the one 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.
On the Main tab, expand Application Security and click URLs.
The Allowed URLs screen opens.
2.
In the editing context area, ensure that the Current edited policy is the one 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
The screen refreshes and displays additional settings for meta characters.
5.
Continue with the URL setting: Select the web application protocol, and then type a wildcard expression in the field (for example, *) that resolves to the URLs that the security policy should allow.
6.
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 select the Perform Tightening setting.
Note: F5 Networks does not recommend using both tightening and staging at the same time on the same wildcard entity.
7.
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 8.)
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 application character set.
8.
Click the Create button to add the wildcard URL to the security policy.
The screen displays the updated Allowed URLs 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.
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 Policy Builder is not enabled, you can accept learning suggestions manually. For details, see Working with entities in staging or with tightening enabled.
To process requests for this wildcard URL according to the header content such as XML or JSON, use the Advanced settings to create header-based content profiles. For details, refer to Enforcing requests for URLs based on header content.
1.
On the Main tab, expand Application Security and click URLs.
The Allowed URLs screen opens.
2.
In the editing context area, ensure that the Current edited policy is the one 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 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.
On the Main tab, expand Application Security and click URLs.
The Allowed URLs screen opens.
2.
In the editing context area, ensure that the Current edited policy is the one that you want to update.
3.
In the Allowed URLs List area, select 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 system searches for a match within those wildcard URLs. If the system finds a match in the wildcard URLs, the system then applies the security checks that are associated with that wildcard entity to the matching entity.
1.
On the Main tab, expand Application Security and click URLs.
The Allowed URLs screen opens.
2.
On the menu bar, click Wildcards Order.
The Wildcards Order screen opens.
3.
In the editing context area, ensure that the Current edited policy is the one 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.
On the Main tab, expand Application Security and click Parameters.
The Parameters List screen opens.
2.
In the editing context area, ensure that the Current edited policy is the one 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 field (for example, *).
5.
For the Parameter Level setting, select the appropriate option for this wildcard parameter.
Global: For more information, see Working with global parameters.
URL: For more information, see Working with URL parameters.
Flow: 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 select the Perform Tightening check box.
Note: F5 Networks does not recommend 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, select the Allow Repeated Occurrences check 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. If Policy Builder is not enabled, 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.
On the Main tab, expand Application Security and click Parameters.
The Parameters List screen opens.
2.
In the editing context area, ensure that the Current edited policy is the one 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 Parameter Properties screen opens.
5.
Click the Update button to update the parameter 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.
On the Main tab, expand Application Security and click Parameters.
The Parameters List screen opens.
2.
In the editing context area, ensure that the Current edited policy is the one that you want to update.
3.
In the Parameters List area, in the Select column (far left), select 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 system searches for a match within those wildcard parameters. If the system finds a match in the wildcard parameters, the system 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 system always looks for a match on an explicit parameter first. If the explicit parameter is not found, the system 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 8.1.
Tip: When adding wildcard URLs, arrange them in the order in which you want to enforce them. The system enforces them from the top down.
1.
On the Main tab, 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 Current edited policy is the one 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 lists 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 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 Creating cookies.
You can enable tightening on wildcard cookies to cause the system to build the security policy depending on the Cookies Settings (Headers > Cookies > Cookies Settings). The Cookies Settings determine how the system treats cookies and how to build the security policy: either by configuring which cookies are not allowed to be changed by the client (By adding enforced cookies), or by defining which cookies are allowed to be modified by the client (By adding allowed cookies).
If using enforced cookies (which is the default and preferred value), the system adds a * wildcard allowed cookie, with tightening, to the security policy. As a result, valid session cookies from the web application that were not modified and which match the wildcard cookie are suggested as additions to the list of enforced cookies. We do not recommend deleting the wildcard cookie.
If using allowed cookies, you can create a * wildcard with tightening. The system list explicit cookies that match the wildcard on the learning suggestions. When you finish adding the allowed cookies, you can remove the wildcard cookie to enforce the other cookies.
1.
On the Main tab, expand Application Security and click Headers.
The Cookies screen opens.
2.
In the editing context area, ensure that the Current edited policy is the one that you want to update.
3.
Click the Create button.
The New Cookie screen opens.
4.
For Cookie Type, select how the system treats this cookie:
Select Enforced if you do not want clients to change this cookie.
Select Allowed to let clients modify this cookie.
5.
From the Cookie Name Type list, select Wildcard.
6.
In the Cookie Name field, type the pattern string that matches the cookie name.
Tip: For wildcard syntax, refer to Understanding wildcard syntax.
7.
For Allowed cookies, if you want the system to suggest explicit cookies that match an allowed wildcard cookie, select the Tightening check box.
8.
Click the Create button.
The screen refreshes, and you can see the new cookie in the Enforced or Allowed Cookies list.
9.
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.

An hourglass indicates that no learning suggestions are available, but the staging or tightening period is not over.

A scholars cap indicates that learning suggestions are available. Move the cursor over the icon to view whether the staging or tightening period is over.

A shield indicates that no learning suggestions are available and the staging or tightening period is over. This entity is ready to be taken out of staging or tightening, and be enforced.
1.
On the Main tab, expand Application Security and click Headers.
The Cookies screen opens.
2.
In the editing context area, ensure that the Current edited policy is the one you are interested in.
3.
4.
For Cookie Name Type, select Wildcard.
5.
For Staging-Tightening, specify the status of the cookies you want to display:
6.
Click Go to cause the system to filter the list of cookies.
The system updates the lists of cookies.
7.
In the Staging or Tightening column of the cookies lists, point to the status icon.
The system displays information about staging or tightening for this wildcard entity.
8.
If the status indicates that learning suggestions are available for any of the cookies, on the Main tab, click Policy Building > Manual > Staging-Tightening Summary.
The Staging-Tightening Summary screen opens.
9.
In the Cookies row, click a number (greater than 0) 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.
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.
You can delete wildcards for cookies that you do not need in the security policy by enforcing the cookies. You can enforce a cookie when no more learning suggestions are available.
1.
On the Main tab, expand Application Security and click Headers.
The Cookies screen opens.
2.
In the editing context area, ensure that the Current edited policy is the one that you want to update.
3.
In the Enforced Cookies list, in the Select column (far left), select the box next to the wildcard cookie which you want to enforce, 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)