Applies To:

Show Versions Show Versions

Manual Chapter: Building a Security Policy Automatically with the Policy Builder
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

The Policy Builder is the automated tool with which you create a security policy. You can run the Policy Builder to build a new security policy, or to update an existing security policy. If you have several security policies for a web application, you run the Policy Builder for each security policy. However, you can run only one instance of a security policy in Policy Builder (per device). Additionally, the security policy running in Policy Builder becomes the active security policy for the corresponding web application.
Note: If you are creating a security policy for a new, unconfigured web application, we recommend that you use the Deployment Wizard to set up the security policy. The Deployment Wizard guides you through the Policy Builder configuration. For more information on using the Deployment Wizard, refer to the BIG-IP® Application Security Manager: Getting Started Guide, which is available at https://support.f5.com.
The Policy Builder parses requests and responses and populates the security policy with the entities that it finds in the traffic. This action tightens the security policy. The entities may include file types, URLs, and parameter types. Once you make this security policy the active security policy, when the Application Security Manager receives a similar request, the system does not issue violations against the request, or block the request (if the enforcement mode is blocking). If a violation is not issued, the request is not blocked.
With the Policy Builder, you have two options for the source of the traffic that the Policy Builder analyzes: live traffic and system-generated traffic. When you use live traffic as the traffic source, the Policy Builder analyzes logged requests to, and responses from, the web application. When you use system-generated traffic as the traffic source, the Policy Builder emulates user behavior by browsing the web application.
When you are setting up the Policy Builder in manual mode, you decide which traffic source to use. This determines the remaining configuration options for the Policy Builder.
Live traffic is the typical client-server traffic for a web application. Live traffic can be from trusted clients or untrusted clients. Trusted clients are those from whom you know the traffic is not malicious. Typical sources of trusted traffic are internal test groups, employees, or other users in a controlled environment. For information on how the Policy Builder recognizes trusted clients, see Configuring Trusted IPs for live traffic. Untrusted clients can be anyone who can access the web application.
When you run the Policy Builder using system-generated traffic as the traffic source, the Policy Builder uses system-generated traffic to extract the web application entities from the web application. Use this mode when you do not have any recorded traffic, and you want the Policy Builder to automatically fetch requests (browse) against the web application, process the responses, and use all the outgoing links. The Policy Builder uses the collected information to update the security policy to accept all of the generated traffic.
The Policy Builder uses security templates to provide the guidelines by which the Policy Builder creates or updates the security policy. You select a security template regardless of the traffic source for the Policy Builder.
Global Level
When you use the Global Level security template, the Policy Builder creates a security policy that detects evasion techniques and checks for RFC compliance for the HTTP protocol. It also checks for file types, global parameters, request lengths, header lengths, meta characters in headers, cookie lengths, and attack signatures.
URL Level
When you use the URL Level security template, the Policy Builder creates a security policy that enforces the options of the Global Level template, and also adds URLs and URL parameters to the security policy.
The Policy Builder has built-in algorithms that analyze web application traffic according to the security template that you select. From that analysis, the Policy Builder updates the corresponding security policy with web application entities that it finds. The entities may include file types, URLs, meta characters, parameters, parameter values, and parameter types. This analysis process is called heuristics. As the Policy Builder runs, the heuristics algorithms scan all of the web application traffic, and detect additions and change to the web application entities. When the heuristics analysis reaches a point of decision in the algorithm, the Policy Builder makes corresponding changes in the security policy. Heuristics analysis reduces the workload of building and maintaining a security policy.
When you run the Policy Builder in live traffic mode, there are many configuration options, and an input filter, to customize the traffic analysis. There are both a basic and an advanced configuration for the Policy Builder. The Advanced mode provides additional configuration settings, to further refine how the Policy Builder processes the live traffic.
1.
On the Main tab of the Application Security navigation pane, click Automatic.
The Automatic Policy Building Configuration 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 Configuration area, select Basic or Advanced.
If you select Advanced, the screen refreshes to display additional configuration options.
4.
For the Traffic Source setting, select Live Traffic.
5.
For the Continuous Mode setting, select either Run continuously or Run once on gathered traffic. See Configuring the Continuous Mode for live traffic, following, for more information.
6.
For the Security Template setting, select the security template that you want the Policy Builder to use. See Understanding the security templates for the Policy Builder, for more information.
7.
In the Configuration area, configure the remaining settings as required. The settings are described in the sections following.
9.
Click the Start button (below the Input Filter area).
The screen refreshes, and displays the Automatic Policy Building Status screen, where you can monitor the progress of the Policy Builder.
The Continuous Mode for live traffic specifies whether the Policy Builder runs all the time, and processes all traffic, or whether the Policy Builder processes only requests and responses that have already been logged. The Continuous Mode options are:
Run continuously
When you select this option, the Policy Builder runs from the time you start it until you click the Stop button.
Run once on gathered traffic
When you select this option, the Policy Builder analyzes only traffic that the system has already received, and stops once that analysis process is complete.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Continuous Mode setting.
If, for the Continuous Mode setting, you select the Run continuously option, you can also specify whether the Policy Builder automatically updates and applies the security policy whenever the analyzed traffic contains entities that are different from those in the current active security policy. You do this by enabling the Track Site Changes setting. If you disable the Track Site Changes setting, the system generates a learning suggestion whenever there is a discrepancy between the security policy and the traffic, and you evaluate the associated requests to determine whether you need to update the security policy with the changed entity.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Track Site Changes setting.
Note: This setting is available only if you have selected Run continuously for the Continuous Mode setting.
The Policy Builder uses the Domain setting to differentiate between URLs that belong to the web application and URLs that do not belong to the web application (but to which the web application contains links). For example, the home page in your web application may contain a link to an external search engine. When you configure a Policy Builder domain, the Policy Builder updates the security policy with entities from your web application, and does not update the security policy with entities that belong to the external search engine.
The Policy Builder domain settings should match the client SSL and server SSL settings for the local traffic virtual server with which the application security class is associated. Otherwise, the Policy Builder cannot gain direct access to the web server that is hosting the web application.
Note: For more information about the local traffic virtual server options, and the Client SSL and Server SSL profiles, refer to the Configuration Guide for BIG-IP® Local Traffic Management.
1.
On the Main tab of the Application Security navigation pane, click Automatic.
The Automatic Policy Building Configuration screen opens.
2.
Above the Configuration area, select Advanced.
The screen refreshes to display additional configuration options.
3.
For the Domains setting, configure the following options:
a)
In the Domain box, type the fully-qualified domain name of the web server.
b)
For the Protocol setting, select the appropriate protocol option for your web application.
c)
In the IP Address box, type the address of the web server.
d)
In the Port box, type the port for the HTTP service, typically 80.
4.
Click the Add button.
The system adds the domain to the Domains list.
The Policy Builder uses the session ID source to keep track of traffic from the same client-server session. The Policy Builder extracts the session ID from one of the following sources:
ASM Session
Each request and response that the Application Security Manager processes contains an ASM cookie. When you select the ASM Session source, the Policy Builder extracts the session information associated with the ASM cookie.
Cookie
When you select the Cookie source, the Policy Builder extracts the session information associated with the cookie that you specify.
Parameter
When you select the Parameter source, the Policy Builder extracts the session information associated with the parameter that you specify.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Session ID setting.
If you select Cookie, type a cookie name in the Cookie name box.
If you select Parameter, type a parameter name in the Parameter name box.
Every time the Policy Builder runs for a security policy, it collects the heuristics data. (For more information on heuristics, see Understanding heuristics.) If you want the Policy Builder to delete all previously collected data and start a new data collection process, you can reset the heuristics data. If you run the Policy Builder for a specific security policy more than once, you can specify that the Policy Builder includes existing heuristics data in the analysis process.
Important: Resetting heuristics and including existing heuristics are mutually exclusive actions. In other words, if you reset the heuristics, the Policy Builder cannot include them in a future analysis.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Heuristics setting.
2.
Click the Reset Statistics button.
The system clears any previously collected data from the heuristics database for the security policy.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Include Previously Collected Heuristics setting.
2.
Check the box to enable the Policy Builder to use any existing heuristics, along with any new heuristics, in the current analysis.
If you are running the Policy Builder using trusted client traffic, you can configure the IP addresses of those trusted clients in the Trusted IPs setting of the Policy Builder configuration. Examples of a trusted IP configuration are:
All sources: 0.0.0.0 - 255.255.255.255
Specific subnet: <trusted.subnet>.1.0 - <trusted.subnet>.1.255
The Policy Builder processes traffic from trusted clients differently than traffic from untrusted clients. For trusted clients, the Policy Builder automatically updates the security policy with any entity changes or updates that it discovers. Additionally, if traffic from the trusted clients triggers any attack signatures, the system automatically disables those signatures within the security policy.
Tip: See Using live traffic as the traffic source, for more information on using trusted clients.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Trusted IPs setting.
If you are configuring the Policy Builder to use either the URL Level or Flow Level security template, the Policy Builder detects and analyzes parameters, and sets the parameter type. If the web application contains dynamic parameters, you can configure the Policy Builder to identify them. Dynamic parameters are parameters whose set of accepted values can change, and that usually depend on the user session. For more information on dynamic parameters, refer to Working with dynamic parameters and extractions.
The No dynamic parameter definitions option:
The Identify dynamic parameters by heuristics option:
Adds dynamic parameters to the security policy based on traffic to the web application that meets the internal heuristic criteria.
Tracks sets of values for the parameter in responses (HTML sources) to determine whether to add it to the security policy as a dynamic parameter. If the Policy Builder has insufficient statistics, it sets the parameter type to alphanumeric user-input.
The Define Hidden fields as dynamic parameters option:
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Identify Dynamic Parameters setting.
The Input Filter options determine from which requests the Policy Builder extracts the web application information that it uses to build or update the security policy. You can use any combination of filter options, or you can run the Policy Builder with the default options. Table 6.1 provides a description of the filter options.
The File Types Associations screen provides a list of file types that are frequently used in web applications, and their most common usage in the web application. In this list, you can configure how the Policy Builder processes a certain file type or URL for the corresponding security policy, thus saving tedious manual configuration in the security policy. For example, image files would not typically be a link, so you can use the file types associations settings to instruct the Policy Builder to define all image files (*.bmp, *.gif, *.jpg, and so on) as files that are not referrers.
The default settings provided in the file type associations list cover the most common file types and associations, and you can adapt them to your needs by checking or clearing boxes. Table 6.2 provides a description of the default file types and their corresponding file type associations.
This option specifies whether all URLs of this type can be entry points to the web application. The system does not specify a default entry point.
This option specifies whether URLs of this type may contain references to other files. For example, an HTML page that contains an HREF link or a CGI file that calls another file, are referrers. Picture and sound files cannot be referrers because these URLs never contain links to other URLs, and are not web pages.
If your web application contains file types that are not included in the default File Types Associations list, you can create custom file type associations, and add them to the list.
1.
On the Main tab of the Application Security navigation pane, click Automatic.
The Automatic Policy Building Configuration screen opens.
2.
On the menu bar, click File Types Associations.
The File Types Associations 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.
Above the File Types Associations area, click Create.
The New File Type screen opens.
5.
In the File Type box, type the file type extension for the new file type. Note that file type names are not case-sensitive.
6.
Click OK.
The screen refreshes, and the new file type appears in the File Types Associations list.
7.
In the File Types Associations area, check any flags for properties that you want to associate with the new file type.
8.
Click the Save button below the File Type Associations list to save any changes you have made.
9.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
You can easily remove any extra or unnecessary file types, and their corresponding associations, from the File Types Associations list. Note that you can delete both custom file types, and the default file types.
1.
On the Main tab of the Application Security navigation pane, click Automatic.
The Automatic Policy Building Configuration screen opens.
2.
On the menu bar, click File Types Associations.
The File Types Associations 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.
Check the box (in the Select column) to the left of the file type that you want to delete from the File Types Associations list.
5.
Below the File Types Associations area, click the Delete button.
The system removes the file type from the list.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
If you have modified the File Types Associations list, and you want to remove those changes from the list entirely, you can restore the default settings. Restoring the default settings returns the File Types Associations list to its original state by removing any user-added file types and resetting all of the associations for the default file types.
1.
On the Main tab of the Application Security navigation pane, click Automatic.
The Automatic Policy Building Configuration screen opens.
2.
On the menu bar, click File Types Associations.
The File Types Associations 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.
Below the File Types Associations area, click Restore Defaults.
A confirmation popup screen opens.
5.
Click OK.
The screen refreshes and the system restores the default settings for the File Types Associations list.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
When you run the Policy Builder in the system-generated traffic mode, the system emulates client traffic browsing through the web application. There are several configuration options for this mode that help the system browse the web application.
Important: Although you do not have to configure all of these options, at minimum you must configure the Domains and Start Points settings.
1.
On the Main tab of the Application Security navigation pane, click Automatic.
The Automatic Policy Building Configuration 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 Configuration area, select Advanced.
The screen refreshes to display additional configuration options.
4.
For the Traffic Source setting, select System-Generated Traffic.
The screen refreshes and displays the configuration options that are available for this traffic mode.
5.
For the Security Template setting, select the security template that you want the Policy Builder to use. See Understanding the security templates for the Policy Builder, for more information.
6.
For the Domains setting, configure the domain information for the web application. See Configuring domains for system-generated traffic, for more information.
7.
For the Start Points setting, configure the start points information for the web application. See Configuring the Start Points setting, for more information.
9.
Click the Start button.
The screen refreshes and displays the Automatic Policy Building Status screen, where you can monitor the progress of the Policy Builder.
The Policy Builder uses the Domain setting to differentiate between URLs that belong to the web application and URLs that do not belong to the web application (but to which the web application contains links). For example, the home page in your web application may contain a link to an external search engine. When you configure a Policy Builder domain, the Policy Builder updates the security policy with entities from your web application and does not update the security policy with entities that belong to the external search engine.
Important: When you run the Policy Builder in the system-generated traffic mode, you must configure a Policy Builder domain and start point.
The Policy Builder domain settings should match the client SSL and server SSL settings for the local traffic virtual server with which the application security class is associated. Otherwise, the Policy Builder cannot gain direct access to the web server that is hosting the web application. You can configure the Policy Builder domain settings to use any combination of HTTP and HTTPS. Table 6.3 shows the mapping.
HTTP or HTTPS
Note: For more information about the local traffic virtual server options, and the Client SSL and Server SSL profiles, refer to the Configuration Guide for BIG-IP® Local Traffic Management.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, for the Domains setting, configure the following settings.
a)
In the Domain box, type the fully-qualified domain name of the web server.
b)
For the Protocol setting, select the appropriate protocol option for your web application.
c)
In the IP Address box, type the address of the web server.
d)
In the Port box, type the port for the HTTP service, typically 80.
2.
Click the Add button.
The system adds the domain to the Domains list.
The Policy Builder uses the session ID source to keep track of traffic from the same client-server session. The Policy Builder extracts the session ID from one of the following sources:
ASM Session
Each request and response that the Application Security Manager processes contains an ASM cookie. When you select the ASM Session source, the Policy Builder extracts the session information associated with the ASM cookie.
Cookie
When you select the Cookie source, the Policy Builder extracts the session information associated with the cookie that you specify.
Parameter
When you select the Parameter source, the Policy Builder extracts the session information associated with the parameter that you specify.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Session ID setting.
When you run the Policy Builder using system-generated traffic, the Policy Builder starts the data collection process for a web application from a URL. This URL is known as the start point. The start point is usually the web application's home page. If the web application has several start points, you can instruct the Policy Builder to scan the application from each start point, separately. For example, an online banking site has a public area, which anyone can access, and a secure area that requires a unique login. When a customer logs in to the secure area, they may be redirected to a different web application. To successfully map the entire web application, the Policy Builder must know about all of these start points.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Start Points setting.
a)
In the Domains List box, select the Policy Builder domain for which you are creating a start point.
b)
In the Start Point box, type the address of the default start page of the application, for example, http://siterequest.example.com/index.html
Important: Every start point must reference a Policy Builder domain.
3.
Click the Add button.
The system adds the start point to the Start Points list.
Tip: If your web application has more than one start point, we recommend that you run the Policy Builder one or more times to scan the public access areas of the web application, and then run the Policy Builder with the login information configured, to scan the secure areas of the web application.
If the web application contains a page designed to log a visitor out of the web application, you need to instruct the Policy Builder not to follow the logout link. Otherwise, when you run the Policy Builder, it logs out of the web application before it has fully scanned the application. For example, many web applications have an Exit or Logout link right on the home page, which would cause the Policy Builder to exit the application as soon as it enters. You can prevent this behavior by using the Logout Pages setting to identify the logout points that the Policy Builder should avoid.
Note: If you configure the Policy Builder to recognize (and ignore) a logout page in a web application, the system adds this page to the security policy.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Logout Pages setting.
2.
In the Logout Pattern box, type the relative path of the logout page.
3.
Click the Add button.
The system adds the new logout page to the Logout Pages list.
You can use the Form Fillers general setting to define form parameters and values that the Policy Builder then uses to fill in forms. For example, if your web application has a login form, you can define the user name and password parameters, and their corresponding values.
When you run the Policy Builder using system-generated traffic, the Policy Builder populates the form fillers parameters automatically. You can then review the form filler parameters to provide the appropriate values.
Tip: Sometimes the parameter names are not self-explanatory, and you may need to consult with the web application programmer. If it is available to you, you can also search the HTML source code for this information.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Form Fillers setting.
2.
In the Parameter Name box, type the name of the parameter, for example, username.
3.
In the Parameter Type box, select the appropriate type. Note that if you select password, the system displays asterisks instead of clear text in the Form Fillers list.
4.
In the Parameter Value box, type the value that you want the Policy Builder to enter when it reaches the specified parameter. If the parameter type is password, the system requires you to confirm the value.
5.
Click the Add button.
The system adds the new form filler parameter to the Form Fillers list.
When a request to a non-existent web page comes in, web applications typically return a standard HTTP 404 response page, with a page not found error message. This response page may be exploited to stage attacks. To prevent attacks, some web applications may use customized error pages that use the HTTP 200 status code in the response, instead of the HTTP 404 status code. Web application designers do this so that their content can be controlled and verified.
By default, the Policy Builder adds pages that use the HTTP 200 Status OK message to the security policy, and ignores pages that generate the HTTP 404 message. If you do not define the Page Not Found Criteria setting, the Policy Builder attempts to identify it by itself. If your web application uses customized error pages (those that do not return the HTTP 404 status code), you need to supply a text string that the pages do contain, so that the Policy Builder can identify them as valid error message pages, and avoid adding them to the security policy. The Policy Builder can recognize an error page by its file name, or by text strings that are found in the HTML tags, <TITLE> or <BODY>.
Tip: The Policy Builder always follows the redirect link, if one is configured. The Policy Builder identifies the page behind the link, and avoids the link if the identified page is included in the Page Not Found list.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Page Not Found Criteria setting.
2.
In the Apply To box, select the URL that the Policy Builder searches to identify the error page.
3.
In the Search Item box, type the header or string that the Policy Builder searches for.
4.
Click the Add button.
The system adds the page not found criteria to the Page Not Found Criteria list.
Every time the Policy Builder runs for a security policy, it collects the heuristics data. (For more information on heuristics, see Understanding heuristics.) If you want the Policy Builder to delete all previously-collected data and start a new data collection process, you can reset the heuristics data. If you run the Policy Builder for a specific security policy more than once, you can specify that the Policy Builder includes existing heuristics data in the analysis process.
Important: Resetting heuristics and including existing heuristics are mutually exclusive actions. In other words, if you reset the heuristics, the Policy Builder cannot include them in a future analysis.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Heuristics setting.
2.
Click the Reset Statistics button.
The system clears any previously-collected data from the heuristics database for the security policy.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the Include Previously Collected Heuristics setting.
2.
Check the box to enable the Policy Builder to use any existing heuristics, along with any new heuristics, in the current analysis.
When you run the Policy Builder using system-generated traffic, there are several configuration options that determine the general behavior of the Policy Builder. Table 6.4 lists these configuration options and their purpose.
Specifies whether the Policy Builder creates back flows in the security policy for referrer URLs. You can use the back flow information to impose rules on navigating backwards, which occurs when the visitor uses the browser Back button.
Specifies whether the Policy Builder creates flows in the security policy for URLs that a web browser can cache, for example, image files.
Minimal delay between worm requests to web application (milliseconds)
Running the Policy Builder using system-generated traffic is similar to a central unit sending out multiple simultaneous probes to the different areas of the web application in order to register web application entities. Each probe exercises the web application by following links and filling in forms, similar to an actual user. This process increases the traffic to the web application.
The Policy Builder can send the probes in quick or slow succession. Quicker bursts create more traffic. A burst is measured in terms of the number of seconds to wait before sending the next probe. If your web application is active and currently serving visitors, consider increasing this value in order to slow down the Policy Builder.
Number of times the Policy Builder fetches requests with the same structure
For this property, specify the number of samples that are sufficient for the Policy Builder to scan when it discovers identical structures. Applications may contain many identical structures within URLs, where only the parameter values differ. The following examples illustrate identical structures that differ only by the parameter values:
To reduce the policy building time (and the accompanying traffic), you can instruct the Policy Builder to scan only a few (and not all) of such identical structures, assuming that all others behave in the same way.
Note: A higher value yields a more accurate security policy, however, it takes a longer amount of time for the Policy Builder to complete the process.
Maximum number of requests generated for each form by the form iterator
When the Policy Builder encounters a form, it processes it as many times as the number of pre-defined parameter values included in it. For example, a list containing ten URLs causes the Policy Builder to process the form ten times. You can reduce crawling time and traffic, however, by instructing the Policy Builder to process only a few of the URLs and not all of them.
For this property, specify the number of samples you deem it sufficient for the Policy Builder to process from the same form with different values. A higher value yields a more accurate policy with longer crawling times.
The Policy Builder uses this property to select the User-Agent header data when it scans the web application.
If the web application uses HTTP authentication, you can use the HTTP Authentication settings to configure the logon criteria. The Policy Builder accepts all RFC 2617 authentication formats, as well as the Microsoft® NTLM authentication format.
1.
On the Automatic Policy Building Configuration screen, in the Configuration area, locate the HTTP Authentication setting.
2.
In the HTTP Authentication Username box, type the user name for the web server. For Microsoft NTLM authentication, type the user name in the following format:
3.
In the HTTP Authentication Password box, type the password for the web server.
The Policy Builder Status screen provides information about the running status of the Policy Builder. The Status screen displays information about the Policy Builder session, and also displays graphs that compare the number of new and updated entities.
When you run the Policy Builder, the system generates a series of graphs on the Policy Builder Status screen. The graphs display the processed requests, URLs, file types, and parameters. You can use the graphs to help decide when to stop the Policy Builder. When the updates reach zero, the Policy Builder has added all of the entities that it can find.
1.
On the Main tab of the Application Security navigation pane, click Automatic.
The Automatic Policy Building Configuration 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.
On the menu bar, click Status.
The Automatic Policy Building Status screen opens, and displays the Policy Builder status information.
When the Policy Builder runs, it generates log entries for all events and actions taken for the security policy it is building (or updating). The Policy Builder log contains a description of the reason for a security policy change, the related entity, and any action taken; information about thresholds reached for the number of requests for an entity, traffic volume, or number of sessions; and file type events.
For more information on logging in general, refer to the TMOS Management Guide for BIG-IP® Systems, which is available in the AskF5SM Knowledge Base, https://support.f5.com.
Because the Policy Builder log-file size can grow to be quite large, the log has filters available that limit the result set returned for the specified security policy and web application. You can filter the log events using either the pre-defined filters or a custom filter.
The Policy Builder log filter has two filter groups: Basic and Advanced. The Basic filter group displays all log events from the selected web application security policy. The Advanced filter group provides you the ability to limit the result set by selecting more granular criteria than are available from the pre-defined Basic filter options. Table 6.5 lists the log filter options.
Displays a limited the result set by providing further narrowing options from the following categories:
1.
On the Main tab of the Application Security navigation pane, click Automatic.
The Automatic Policy Building Configuration screen opens.
2.
On the menu bar, click Log.
The Automatic Policy Building Log screen opens.
3.
In the editing context area, ensure that the edited web application and security policy are those for which you want to view log transactions.
5.
Click the Go button.
The screen refreshes, and displays the Policy Builder log file for the web application and security policy that you selected.
1.
On the Main tab of the Application Security navigation pane, click Automatic.
The Automatic Policy Building Configuration 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.
On the menu bar, click Status.
The Automatic Policy Building Status screen opens.
4.
Below the Policy Builder Status area, click the Stop button.
The system stops the Policy Builder, the screen refreshes, and you see a summary of the Policy Builder data collection.
Once you have stopped the Policy Builder, we recommend that you review any learning suggestions that the Policy Builder may not be able to resolve. See Processing learning suggestions that the Policy Builder cannot process, for more information.
For a few violations, the learning suggestions do not represent an update to the security policy. Instead, the violations are indicative of an issue that requires user interpretation. The Policy Builder cannot resolve these violations, and displays them on the Automatic Policy Building Report screen.
For these violations, we recommend that you review the violations and the associated requests, and determine whether they represent legitimate violations or false-positives. You can disable these violations if they are not applicable to your web application, which turns off the blocking policy so that you are no longer notified of requests that trigger the violation. Alternately, you can clear the learning suggestions, and the Learning Manager continues to issue learning suggestions for the requests.
Important: The Learning Manager does not generate learning suggestions for requests that cause non-existent URL violations if the web server sends an HTTP response with status codes in the 400-499 range or the 500-599 range.
If you do not want the system to display the violations that require user interpretation, you can disable the violation. When you disable a violation, you can select whether to disable all or some of the blocking actions (the Learn, Alarm, and Block flags) for the violation. The system then ignores future instances of the violation, and passes the requests on to the web application resources.
Warning: Disabling violations or signature sets can have severe consequences. Be sure that you understand the ramifications of the disabling action before completing it.
1.
4.
In the Traffic Learning area, check the box next to the violation name that you want to disable.
5.
Click the Disable Violation button.
A confirmation popup screen opens.
6.
Click OK.
The screen refreshes, and you no longer see the violation.
7.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
A confirmation popup screen opens.
8.
Click OK.
The system applies the updated security policy.
When you clear a violation, the system deletes the violation, but does not update the security policy. The Security Enforcer continues to generate alarms for future instances of the violation, and the Learning Manager continues to generate learning suggestions relative to the violation.
1.
3.
In the View by box, select whether to view by Violations or URL.
4.
In the list, check the box next to a violation, and then click Clear.
A Confirm Delete popup screen opens.
5.
Click OK.
The system deletes the learning suggestion.
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)