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 that it discovered. When you use the Policy Builder, you do not need to create wildcards manually because the security policy is built automatically.
You can also use the selective learning mode with wildcards. The selective learning mode uses wildcards to discover the entities in the web application that need enforcing, and adds those explicit entities to the security policy. This applies to all * wildcard entities.
This chapter describes creating wildcards for file types, URLs and parameters. For details about creating wildcards for cookies, refer to BIG-IP® Application Security Manager: Implementations.
The syntax for wildcard entities is based on shell-style wildcard characters. Table 4.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 either staging or explicit learning for that entity. With explicit learning, the policy discovers entities and creates learning suggestions from which you can update the security policy. The system then automatically enables staging for entities you have learned.
The learn explicit entities feature uses wildcards to discover the entities in a web application (file types, URLs, parameters, and cookies). Staging is learning the attributes of an entity (wildcard or explicit), which provides additional granularity.
You use explicit learning on wildcard entities (file types, URLs, parameters, and allowed cookies) to identify explicit entities. When you enable explicit learning for a wildcard entity, and the system receives a request that includes data that matches the wildcard entity, the system generates an explicit entity suggestion for the found entity. You can then review the new entities, and decide which are legitimate entities for the web application.
The learn explicit entities feature 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 the learn explicit entities feature 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.
Use the learn explicit entities feature 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 explicit entity suggestions for a wildcard, the system automatically places the explicit entity into staging if the Perform Staging flag is available and enabled on the learning suggestion screen. Also, if the wildcard entity has the Perform Staging flag enabled, the explicit entity inherits the wildcard attributes (including whether the Perform Staging flag is on).
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 4.2.
Parameter settings, name meta characters, value lengths, and XML, JSON, and base64 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 disabling the Perform Staging setting 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 Security, point to Application Security, Policy Building, and click Enforcement Readiness.
The Enforcement Readiness screen opens.
2.
In the Enforcement Readiness Summary area, check to see if a number other than 0 appears in the Ready To Be Enforced column.
3.
If yes, then select that entity type and 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.
4.
Click OK.
The screen refreshes; the system performs the following on selected entities:
1.
On the Main tab, expand Security, point to Application Security, Policy Building, and click Enforcement Readiness.
The Enforcement Readiness screen opens.
2.
In the Enforcement Readiness Summary, check to see if a number appears in the Not Enforced column.
A number greater than zero indicates that entities of that type were discovered while in staging.
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 and removes selected entities (explicit and wildcard) from staging.
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 learn explicit entities 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.
If you don't want to populate the policy with new entities, you can disable violations (such as Illegal file type, Illegal parameter, Illegal URL, and Modified domain cookies) on the Blocking screen.
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. For more information, see Using the Enforcement Readiness summary.
1.
On the Main tab, expand Security, point to 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.
Click the Create button.
The Add Allowed File Type screen opens.
4.
From the File Type list, select Wildcard from the list, and then type a wildcard string in the field (for example, *).
5.
Leave the Perform Staging setting enabled.
6.
From the Learn Explicit Entities list, specify whether the system adds explicit entities that match a wildcard to the security policy.
Never (wildcard only)
The system does not add or suggest that you add entities that match the wildcard to the policy. When false positives occur, the system suggests relaxing the settings of the wildcard entity. This option results in a security policy that is easy to manage but may not be as strict.
Selective
The system adds or suggests that you add entities that match the wildcard to the policy. When false positives occur, the system adds or suggests that you add an explicit entity with relaxed settings that avoid the false positive. This option provides a good balance between security, policy size, and ease of maintenance.
Tip: For the * pure wildcard entity, you can click the link to select Learn Explicit Entities on the Policy Building: Settings screen.
8.
If you want the system to validate responses to requests containing this file type, select Enabled for the Apply Response Signatures setting.
Tip: Checking this option enables attack signatures (that are designed to inspect server responses) to filter responses.
9.
Click the Create button to add the wildcard file type to the security policy.
The screen displays the updated Allowed File Types screen.
10.
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 Security, point to 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 Security, point to 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 Security, point to 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 learn explicit entities, you can learn which URLs are used in the protected web application.
1.
On the Main tab, expand Security, point to 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.
Click Create.
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.
Leave the Perform Staging setting enabled.
7.
From the Learn Explicit Entities list, specify whether the system adds explicit entities that match a wildcard to the security policy.
Never (wildcard only)
The system does not add or suggest that you add entities that match the wildcard to the policy. When false positives occur, the system suggests relaxing the settings of the wildcard entity. This option results in a security policy that is easy to manage but may not be as strict.
Selective
The system adds or suggests that you add entities that match the wildcard to the policy. When false positives occur, the system adds or suggests that you add an explicit entity with relaxed settings that avoid the false positive. This option provides a good balance between security, policy size, and ease of maintenance.
Tip: For the * pure wildcard entity, you can click the link to select Learn Explicit Entities on the Policy Building: Settings screen.
8.
In the Meta Characters tab, 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 9.)
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.
9.
Click the Create button to add the wildcard URL to the security policy.
The screen displays the updated Allowed URLs screen.
10.
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 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 Using the Enforcement Readiness summary.
To process requests for this wildcard URL according to the header content such as XML, JSON, or GWT, 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 Security, point to 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 Security, point to 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 Security, point to 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, 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.
1.
On the Main tab, expand Security, point to 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.
Click Create.
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.
Leave the Perform Staging setting enabled.
7.
From the Learn Explicit Entities list, specify whether the system adds explicit entities that match a wildcard to the security policy.
Never (wildcard only)
The system does not add or suggest that you add entities that match the wildcard to the policy. When false positives occur, the system suggests relaxing the settings of the wildcard entity. This option results in a security policy that is easy to manage but may not be as strict.
Selective
The system adds or suggests that you add entities that match the wildcard to the policy. When false positives occur, the system adds or suggests that you add an explicit entity with relaxed settings that avoid the false positive. This option provides a good balance between security, policy size, and ease of maintenance.
Tip: For the * pure wildcard entity, you can click the link to select Learn Explicit Entities on the Policy Building: Settings screen.
8.
If the parameter can have an empty value, leave the Allow Empty Value setting enabled. Otherwise, uncheck the box.
9.
To allow requests to contain multiple parameters with the same name, enable the Allow Repeated Occurrences setting. The default setting is disabled.
10.
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.
11.
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.
12.
Configure the remaining settings for data types, meta characters, and attack signatures as required, and then click the Create button.
The screen refreshes, and displays the new wildcard parameter.
13.
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 learn explicit entities 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 Using the Enforcement Readiness summary.
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 Security, point to 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 Security, point to 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 4.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 Security, point to 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.
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)