Applies To:

Show Versions Show Versions

Manual Chapter: Working with Attack Signatures
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

10 
Attack signatures are rules or patterns that identify attacks or classes of attacks on a web application and its components. You can apply attack signatures to both requests and responses. Additionally, within the requests signatures pool, some signatures can apply to alpha-numeric user-input parameters.
The global attack signatures pool contains all of the attack signatures that are part of the Application Security Manager configuration. This includes both system-supplied attack signatures, including XML signatures, and user-defined attack signatures.
The Application Security Manager ships with an extensive database of attack signatures. These are known as system-supplied attack signatures. You can disable system-supplied attack signatures, but you cannot delete them. You can also update system-supplied attack signatures to ensure that the system always has the most current protection against known attacks. For information on updating the attack signatures pool, refer to Updating the system-supplied attack signatures.
User-defined attack signatures are those written by customers. User-defined attack signatures must follow the same syntax rules as the system-supplied attack signatures. For details on creating and managing user-defined attack signatures, see Managing user-defined attack signatures.
An attack signature set is a group of attack signatures. Rather than applying individual attack signatures to a security policy, you can apply one or more attack signature sets. The Application Security Manager ships with several system-supplied signature sets. By default, a generic attack signature set is assigned to new security policies. Additionally, you can create your own attack signature sets. For information on creating and managing attack signature sets, refer to Working with attack signature sets.
Attack signatures apply to requests, responses, and alpha-numeric user-input parameters. Request signatures apply to the entire request, or the elements of the request. Response signatures are similar to request signatures, and provide an additional level of security for attacks that may have avoided detection in the request. Parameter signatures, which are a subset of the request signatures, apply to the name and value pairs for the alpha-numeric user-input parameters that are defined in a security policy. These signatures attempt to identify classes of attacks, for example, SQL injection, command injection, cross-site scripting, and directory traversal. Refer to Types of attacks that attack signatures detect, for specific information on the various attack types.
When the Application Security Manager receives a request, the system applies the attack signatures associated with the security policy to the request. If, in the request (or response), a pattern matches one or more of the attack signatures, the system generates the Attack signature detected violation. If the enforcement mode is blocking, the system also blocks the request and issues the Blocking Response Page to the client making the request.
Table 10.1 describes common web application attacks that attack signatures can detect.
Uses a web site's own features and functionality to consume, defraud, or circumvent the applications access control mechanisms.
Targets a web site's method of validating the identity of a user, service or application. Authorization attacks target a web site's method of determining if a user, service, or application has the necessary permissions to perform a requested action.
Occurs during an outside attempt by hackers to access post-logon pages of a web site by guessing user names and passwords; in a brute force attack, a malicious user attempts to log in to a URL numerous times, running many combinations of user names and passwords until they successfully log in.
Alters the flow on an application by overwriting parts of memory. An attacker could trigger a buffer overflow by sending a large amount of unexpected data to a vulnerable component of the web server.
Occurs when an attacker manipulates the data in a user-input field, by submitting commands that could alter the web page content or web application by running a shell command on a remote server to reveal sensitive data-for example, a list of users on a server.
Pertains to the transmission of unauthorized commands through authenticated (trusted) users of the web application. CSRF attacks can include money transfers, stock trades, privilege escalation, application modification, or other unauthorized access.
Attempts to list and access resources that the application does not directly reference, but are still accessible. An attacker can search for unlinked contents, such as temporary directories and files, and old backup and configuration files. These resources may contain sensitive information.
Occurs when an attacker attempts to pass Google Web Toolkit (GWT) data that the parser cannot parse, and may contain malicious code that can result in various attacks such as Denial of Service, buffer overflow, or cross-site scripting.
Attempts to cause an HTTP parser to crash, consume excessive resources, run slowly, run an attackers code, or cause the web application to do anything beyond its intended design.
Sends a specially formatted HTTP request that might be parsed differently by the proxy system and by the final system, so the attacker can smuggle a request to one system without the other one being aware of it. This attack makes it possible to exploit other attacks such as session hijacking, cross-site scripting (XSS), and the ability to bypass web application firewall protection.
Occurs when a web site reveals sensitive data, such as developer comments or error messages, which may aid an attacker in exploiting the system.
Attempts to include in a request information that is not permitted by the security policy, such as including a null value in a request or including an illegal attachment.
Occurs when an attacker attempts to pass JSON data that the parser cannot parse, and may contain malicious code that can result in various attacks such as Denial of Service or cross-site scripting.
Refers to an attempt to upload a file that could cause damage to the system, for example, through the use of remote code execution or hostile data uploads.
Relates to an attempt by automated client access to obtain sensitive information. HTML comments, error messages, source code, or accessible files may contain sensitive information.
Represents attacks that do not fit into the more explicit attack classifications, including email injection, HTTP header injection, attempts to access local files, potential worm attacks, CDATA injection, and session fixation.
Involves the manipulation of parameters exchanged between client and server to modify application data, such as user credentials and permissions, or the price and quantity of products.
Compromises a session token by stealing or predicting a valid session token to gain unauthorized access to the web server. Web servers often send session tokens to the client browser upon successful client authentication. A session token is usually a string of variable width, and it could be placed in the URL, in the header of an HTTP request, for example, as a cookie, or in the body of the HTTP request.
Tries to circumvent a web servers or web applications built-in security by masking the attack within a legitimate communication. For example, an attacker may include an attack in an email or Microsoft® Word document, and when a user opens the email or document, the attack starts.
Attempts to cause an XML parser to crash, consume excessive resources, run slowly, run an attackers code, or cause the web application to do anything beyond its intended design.
The attack signatures pool contains all of the attack signatures that are part of the configuration. The pool includes the system-supplied attack signatures, which are the attack signatures that are shipped with the Application Security Manager, and any user-defined attack signatures. You can perform the following tasks to manage and maintain the attack signatures pool:
The attack signatures pool is quite large, so there is a filter that you can use to display only those signatures that you are interested in viewing. The filter has several built-in filter options. You can also create a custom filter.
The built-in filter options reduce the viewable attack signatures to a subset that matches a specific characteristic of the attack signatures. Table 10.2 describes the built-in filters.
Displays only signatures whose accuracy is rated greater than or equal to the accuracy that you select. The attack signature accuracy indicates the ability of the attack signature to identify the attack, including susceptibility to false-positive alarms.
Displays only signatures whose risk is rated greater than or equal to the accuracy that you select. The attack signature risk indicates the level of potential damage this attack may cause, if it were successful.
1.
On the Main tab, expand Security, point to Options, Application Security, and then click Attack Signatures.
The Attack Signatures Update screen opens.
2.
From the Attack Signatures menu, select Attack Signatures List.
3.
From the filter list, select a built-in filter.
The screen refreshes, and displays either a text box or a select list for the selected filter.
4.
Provide the appropriate information, and click the Go button.
The screen refreshes, and displays only those attack signatures that match the criteria you selected.
If the built-in filter options are too broad in scope, you can configure a custom filter option to view signatures in the attack signatures pool. For example, you can create a custom filter that displays attack signatures that apply only to parameters, or you can create a custom filter that displays only attack signatures for a specific attack type. When you create a custom filter, you can use one or more of the filter options, as required. Table 10.3 describes the custom filter options.
Attack signature
custom filter option
Displays only attack signatures that match a specific signature ID number. Signature ID numbers are system-supplied, and cannot be modified.
Displays only attack signatures that match the selected attack type. See Table 10.1, for a description of the attack types having signatures associated with them.
Table 10.4 Signature properties 
Low: Indicates a high likelihood of false positives.
Medium: Indicates some likelihood of false positives.
High: Indicates a low likelihood of false positives.
Low: Indicates the attack does not cause direct damage or reveal highly sensitive data.
Medium: Indicates the attack may reveal sensitive data or cause moderate damage.
High: Indicates the attack may cause a full system compromise.
Indicates whether the system provides documentation explaining this attack signature (View) or not (N/A). Click the View link to display the available documentation.
1.
On the Main tab, expand Security, point to Options, and click Application Security.
The Attack Signatures Update screen opens.
2.
From the Attack Signatures menu, select Attack Signatures List.
3.
In the Signature Name column, click the signature for which you want to view information.
The Attack Signature Properties screen opens.
4.
For the Documentation setting, click View to see additional information that applies to the selected attack signature. If no additional documentation is available, you see N/A.
The Documentation for Attack Signature screen opens in a new browser window, and displays the additional documentation.
5.
For the Additional References setting, click the link to an external web site that describes the attack signature. If no additional documentation is available, you see N/A.
6.
When you finish reviewing the details, click the Close button.
The Attack Signature Properties screen reopens.
7.
On the Attack Signatures Properties screen, click Cancel to return to the Attack Signature List.
You can update the system-supplied attack signatures on a regular basis to ensure that your applications are protected against new attacks and threats.
When you update the system-supplied attack signatures, the update includes any new signatures that are available, and also updates any existing attack signatures that have been revised, including the signature documentation. You can configure automatic updates, or you can update them manually. If the update includes new signatures, the system places them in staging.
Two conditions may cause an attack signature update to fail: insufficient network access and duplicate attack signature names.
In addition, it is a good idea to update the attack signatures on all Application Security Manager systems in your network environment, keeping them in sync.
The Application Security Manager must have external network access for the update process to work. To obtain the updated signature files, you must also have both a valid service agreement with F5 Networks, and a service check date within 18 months of the signature-file update request.
If your license has lapsed, you must re-license the Application Security Manager. If you need details about allowing signature file updates through a firewall or an HTTPS proxy, refer to Solution 8217, Updating the BIG-IP ASM attack signatures, on the F5 Networks Technical Support web site. Contact F5 Networks Technical Support, http://support.f5.com, for additional assistance.
Do not use system-supplied attack signature names when you create a user-defined attack signature. Although the system does not prohibit duplicate attack signature names, future attack-signature updates may fail because of name conflicts.
If you inadvertently duplicate a system-supplied attack signature name, rename the user-defined attack signature (see Modifying a user-defined attack signature, for more information). You can then retry the update process.
F5 Networks recommends that you have the same set of attack signatures on all Application Security Manager systems, especially if you plan to copy security policies from one system to another. If you are updating the attack signatures on one system, it is a good idea to update them on all of the systems, to maintain synchronization and consistency with system security.
If you are using device groups for centralized management of BIG-IP® systems, you need to configure each system for automatic attack signature update separately. (An automatic update is one whose update mode is set to Scheduled.) Each device in the group updates its signatures automatically according to its schedule. The attack signatures update configuration is not relayed to other devices in the device group.
If you are using manual attack signature update procedures for systems in device groups, the configuration is relayed to other devices, regardless of the delivery mode. (In this case, the update mode is set to Manual.)
1.
On the Main tab, expand Security, point to Options, Application Security, then click Attack Signatures.
The Attack Signatures Update screen opens.
2.
For the Update Mode setting, click Scheduled.
3.
For the Update Interval, select how often you want the system to check for updates (daily, weekly, or monthly).
4.
To put signatures that are changed by the update into staging, enable the Place updated signatures in staging setting.
After the update, the system puts changed signatures into staging for the Enforcement Readiness Period (specified in Policy properties).
Note: The system places any new signatures added by the update into staging regardless of this setting.
5.
If you want the system to automatically apply the updated signatures to the security policy after installing attack signature updates, make sure the Auto Apply New Signatures Configuration After Update setting is enabled.
6.
Click the Save Settings button to preserve any changes you may have made to the configuration.
If you want to update the system-supplied attack signatures manually, you can use the manual update option. You can obtain the latest attack signatures update file from http://downloads.f5.com.
1.
On the Main tab, expand Security, point to Options, Application Security, then click Attack Signatures.
The Attack Signatures Update screen opens.
2.
In the Attack Signatures Update area, for the Update Mode setting, click Manual.
The screen refreshes, and displays the Delivery Mode setting.
3.
For the Delivery Mode setting, select one of the following options:
Select Automatic if you want to go directly to the F5 web server for the latest update file.
Select Manual if you want the system to save the updates in a file that you can apply at a later time. The screen displays the Upload File setting, where you can specify the path to the file that contains the updates.
4.
To put signatures that are changed by the update into staging, enable the Place updated signatures in staging setting.
After the update, the system puts changed signatures into staging for the Enforcement Readiness Period (specified in Policy properties).
Note: The system places any new signatures added by the update into staging regardless of this setting.
5.
If you want the system to automatically apply the updated signatures to the security policy after installing attack signature updates, make sure the Auto Apply New Signatures Configuration After Update setting is enabled.
6.
Click the Save Settings to save your changes.
7.
Click the Update Signatures button to start the update process.
The Application Security Manager records the logistical information about the most recent update activity, and displays this information on the Attack Signatures Update screen. You can review the last update time, as well as the readme file that pertains to the update.
1.
On the Main tab, click On the Main tab, expand Security, point to Options, Application Security, and click Attack Signatures.
The Attack Signatures Update screen opens.
2.
In the Latest Update Details area, you can review the creation date and time for the database, as well as the date and time at which the database was most recently updated.
3.
Click View Readme to see the details regarding the update.
If you want to receive notification from F5 Networks about attack signature updates available for download, you can sign up on the AskF5 web site for the Security email distribution list. Once you are on the distribution list, F5 Networks sends an email message whenever attack signature updates are available.
Note: You must have a valid service contract, and an AskF5 account, to receive the attack signature update notifications.
1.
Open a browser, and log in to the AskF5 web site at http://support.f5.com.
The AskF5 Knowledge Base screen opens.
2.
On the left, click the Mailing Lists button.
The TECHNEWS screen opens.
3.
In the Security area, click the security-subscribe@lists.f5.com link.
4.
Send the blank email message, as is.
The list manager adds your email address to the Security email distribution list.
Rather than assigning individual attack signatures to a security policy, you assign attack signature sets. By default, when you create a new security policy, the system automatically assigns the Generic Detection Signatures set to the security policy. In addition to the generic signatures set, you can assign one of the other system-supplied signatures sets to the security policy, and you can create a signature set and assign that to the security policy. You can also remove all signature set assignments from a security policy, although F5 Networks recommends against doing this.
When you create an attack signature set, you can tailor the attack signatures to your specific systems and applications. For more information on assigning an attack signature set to a security policy, see Assigning attack signature sets to a security policy.
The Application Security Manager ships with several system-supplied signature sets. By default, the Generic Detection Signatures system-supplied set is associated with all new security policies. Table 10.5 describes the system-supplied signature sets.
Targets attacks against the Microsoft® Outlook Web Access (OWA) application.
Targets attacks on a variety of different computing platforms integrated using WebSphere including general database, Microsoft Windows, IIS, Microsoft SQL Server, Apache, Oracle, Unix/Linux, IBM DB2, PostgreSQL, and XML.
Targets attacks that attempt to gain access to data structures or bypass permissions or access when a web site uses user-supplied information to construct XPath queries for XML data.
You can create signature sets in two ways: by using a filter or by manually selecting the signatures to include. Filter-based signature sets are based solely on criteria you define in the signatures filter. The advantage to filter-based signature sets is that you can focus on the criteria that define the attack signatures you are interested in, rather than trying to manage a specific list of attack signatures. Another advantage to filter-based sets is that when you update the attack signatures database, the system also updates any signature sets included in the update.
1.
On the Main tab, expand Security, point to Options, Application Security, then click Attack Signatures.
The Attack Signatures Update screen opens.
2.
From the Attack Signatures menu, select Attack Signature Sets.
3.
Above the Attack Signature Sets list, click Create.
The Create New Signature Set screen opens.
4.
In the Name field, type a unique name for the signature set.
5.
For the Type setting, select Filter-based.
6.
For the Default Blocking Actions setting, decide which blocking actions you want the system to enforce for the signature set when you associate it with a new security policy.
Note: The Learn, Alarm, and Block actions take effect only when you assign this signature set to a new security policy. If this signature set is already assigned to an existing security policy, these settings have no effect.
7.
If you want the system to automatically include this signature set in any new security policies you create, enable the Assign To Policy By Default setting.
8.
In the Signatures Filter area, select the filter options you want to use to create the new signature set. For descriptions of the individual filter options, see the online help.
9.
In the Signatures area, for the Signatures setting, you can review the signatures list that the filter settings generate.
The list content changes dynamically with the filter selection.
10.
Click the Create button.
The screen refreshes, and you see the new signature set in the Signatures Set list.
User-defined signature sets are composed of attack signatures that you individually select from the attack signatures pool. You can use the signatures filter to help narrow the scope of the available signatures in the pool, however, once the manual signature set is created, the system does not retain the filter criteria.
1.
On the Main tab, expand Security, point to Options, Application Security, then click Attack Signatures.
The Attack Signatures Update screen opens.
2.
From the Attack Signatures menu, select Attack Signature Sets.
3.
Above the Attack Signature Sets list, click Create.
The Create Signature Set screen opens.
4.
In the Create Signature Set area, in the Name field, type a unique name for the signature set.
5.
For the Type setting, select Manual.
6.
For the Default Blocking Actions setting, decide which blocking actions you want the system to enforce for the signature set when you associate it with a new security policy and enable them.
Note: The Learn, Alarm, and Block actions take effect only when you assign this signature set to a new security policy. If this signature set is already assigned to an existing security policy, these settings have no effect.
7.
If you want the system to automatically include this signature set in any new security policies you create, enable the Assign To Policy By Default setting.
8.
In the Signatures Filter area, use the filter options to reduce the scope of the Available signatures list (in the Signatures area). For descriptions of the individual filter options, see the online help.
The list content changes dynamically with the filter selection.
9.
For the Signatures setting, move the signatures you want to include in the set into the assigned signatures list.
10.
Click the Create button.
The screen refreshes, and you see the new signature set in the Signatures Set list.
You can edit user-defined attack signature sets to add or remove signatures, or change the properties of the signature set. When you edit attack signature sets, the changes apply to all of the security policies to which the set is assigned. Additionally, filter-based signature sets automatically receive any applicable updates when you use the attack signature update feature. (For more information, see Updating the system-supplied attack signatures.)
1.
On the Main tab, expand Security, point to Options, Application Security, then click Attack Signatures.
The Attack Signatures Update screen opens.
2.
From the Attack Signatures menu, select Attack Signature Sets.
The Attack Signature Sets screen opens.
3.
In the Name column, click the name of the user-defined signature set that you want to edit.
The Signature Set Properties screen opens.
5.
Click the Update button.
The system updates the signature set in all security policies that include this set.
You can remove a user-defined signature set from the configuration. When you delete a signature set, you are not deleting the attack signatures that make up the set. You are, however, removing the signature set from the security policy, which may have significant ramifications on the security policys effectiveness.
1.
On the Main tab, expand Security, point to Options, Application Security, then click Attack Signatures.
The Attack Signatures Update screen opens.
2.
From the Attack Signatures menu, select Attack Signature Sets.
The Attack Signature Sets screen opens.
3.
Select the check box preceding the user-defined signature set that you want to remove, and click the Delete button.
A confirmation popup screen displays.
4.
Click OK.
The system removes the selected signature set from the configuration.
Each security policy has its own attack signature sets. By default, the system assigns the Generic Attack Signatures to all security policies. In additions, you can assign any additional attack signature sets to a security policy, including any system-supplied set, or those that you may have created.
1.
On the Main tab, expand Security, point to Application Security, Attack Signatures, then click Attack Signatures Configuration.
The Attack Signatures Configuration screen opens.
3.
For the Attack Signature Sets Assignment setting, in the Available Signature Sets list, select the attack signature sets that you want to assign to the security policy.
Tip: To select more than one set, hold the Ctrl key and click the names.
4.
5.
Click the Save button to retain any changes you may have made.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
You can review the attack signature sets that are associated with a security policy from the Signature Sets screen. By default, the system assigns the signature set, Generic Detection Signatures, to all new security policies. Additionally, the system includes in the security policy any attack signature sets you selected with the Deployment wizard.
1.
On the Main tab, expand Security, point to Application Security, Attack Signatures, then click Attack Signatures Configuration.
The Attack Signatures Configuration screen opens.
2.
In the editing context area, ensure that the edited security policy is the one whose attack signature sets you want to view.
3.
In the Attack Signature Sets Assignment setting, you can review the signature sets that are associated with the security policy, as well as the blocking policy actions for signatures in the set.
When you assign an attack signature set to a security policy, the Attack Signatures List screen displays a list of all of the attack signatures. On this screen, you can review the signatures, their current blocking policy, and their state.
1.
On the Main tab, expand Security, point to Application Security, Attack Signatures, then click Attack Signatures List.
The Attack Signatures List screen opens.
2.
In the editing context area, ensure that the edited security policy is the one whose attack signatures you want to view.
3.
For the filter option, select All signatures to display all signatures associated with the security policy.
1.
On the Main tab, expand Security, point to Application Security, Attack Signatures, then click Attack Signatures List.
The Attack Signatures List screen opens.
2.
In the editing context area, ensure that the edited security policy is the one with attack signatures you want to disable.
3.
For the filter option, select All signatures to display all signatures associated with the security policy.
4.
Click the signature name of the attack signature you want to disable.
The Policy Attack Signature Properties screen opens.
5.
For the Enable setting, clear the Enabled check box.
6.
Click Update.
7.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
When you create a security policy, you can specify which attack signature sets to include in the policy. If you later want to change the attack signature configuration, you can change how attack signatures are applied to the security policy.
1.
On the Main tab, expand Security, point to Application Security, and click Attack Signatures.
The Attack Signatures Configuration screen opens.
3.
For Signature Staging, enable or disable signature staging. For details, see Understanding attack signature staging.
4.
In the Attack Signature Sets Assignment setting, perform the following tasks as needed:
a)
From the Available Signature Sets list, move additional signature sets that you want the security policy to include.
b)
For each signature set in the Assigned Signature Sets list, select or clear the check boxes in the Learn, Alarm, and Block columns as required.
Note: You can enable or disable the Block action only when the enforcement mode of the security policy is set to blocking.
a)
For the Check Response Settings, select the Apply Response Signatures check box.
The screen refreshes and displays additional configuration options.
c)
Alternately, click the Create button to define additional file types. The system automatically adds newly defined file types to the Apply Response Signatures for these File Types list.
6.
To configure headers that you do not want attack signatures to examine, in the Excluded Headers setting, add the custom, cookie, or referrer headers to exclude.
By specifying excluded headers, you can keep header-based attack signatures enabled in the security policy but prevent false positives produced if those signatures match legitimate header names and values found in requests to the protected web application.
7.
Click Save.
8.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
The blocking policy defines how the security policy processes requests that trigger violations. For each attack signature set that is assigned to a security policy, you enable one or more of the blocking actions:
When the signatures have passed the staging period and before the system applies the blocking actions, you have a chance to review the attack signatures list and decide which ones to enable or disable. For information on how to do this, refer to Enabling or disabling signatures in staging.
Note: The blocking policy applies to all of the signatures in the signature set. You cannot specify a blocking policy for individual signatures.
1.
On the Main tab, expand Security, point to Application Security, and click Attack Signatures.
The Attack Signatures Configuration screen opens.
3.
In the Attack Signature Sets Assignment setting, for each signature set in the Assigned Signature Sets list, check or clear the check boxes in the Learn, Alarm, and Block columns as required.
Note: You can enable or disable the Block action only when the enforcement mode of the security policy is set to blocking.
4.
Click Save.
5.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
When you first activate a security policy, the system puts the attack signatures into staging (if staging is enabled). Staging means that the system applies the attack signatures to the web application traffic, but does not apply the blocking policy action to requests that trigger those attack signatures. The default staging period is seven days. Whenever you add or change signatures in assigned sets, those are also put into staging. You also have the option of putting updated signatures in staging. (For more information on updating signatures, see Updating the system-supplied attack signatures.)
1.
On the Main tab, expand Security, point to Application Security, and click Security Policies.
The Active Policies screen opens.
2.
In the Security Policy Name column, click the name of the security policy for which you want to modify the staging configuration.
3.
For the Enforcement Readiness Period setting, type the number of days for which you want new or updated attack signatures to remain in staging.
4.
For the Signature Staging setting, click the Attack Signatures Configuration link.
The Attack Signatures Configuration screen opens.
5.
For the Signature Staging setting, select the Enabled check box.
6.
Click Save to retain any changes you may have made.
7.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
Placing new and updated attack signatures in staging helps to reduce the number of violations triggered by false-positive matches. When signatures match attack patterns during the staging period, the system generates learning suggestions. You can view these attack signatures from the Attack Signature Detected screen. Upon evaluation, if the signature is a false-positive, you can disable the signature, and the system no longer applies that signature to traffic for the corresponding web application.
Alternately, if the detected signature match is legitimate, you can enable the corresponding attack signature. Note that enabling the signature removes it from staging, and puts the blocking policy into effect.
1.
On the Main tab, expand Security, point to Application Security, Policy Building, and click Manual Traffic Learning.
The Manual Traffic Learning screen opens.
2.
If attack signature violations have occurred, you will see a Negative Security Violations section in the Traffic Learning area. Click the Attack signature detected link.
The Attack Signature Detected screen opens, where you can review the signatures that matched attack patterns in a request.
If a new or updated attack signature in staging detects an attack pattern in the web application traffic, you should review the signature details and the requests that triggered the attack signature. If the detected attack pattern is not an actual threat, the signature has generated a false-positive alarm. If a particular attack signature triggers false-positives, you may want to disable that particular attack signature.
In some situations, you may want to take action to enable or disable an attack signature immediately, rather than wait for the staging period to complete. For example, if a signature detects a legitimate attack pattern, you may want to enable that signature right away, instead of waiting for the staging period to end.
Another example is when a trusted-traffic signature match is detected but the request is legitimate. In such a case, you should disable that signature immediately.
1.
On the Main tab, expand Security, point to Application Security, Policy Building, and click Manual Traffic Learning.
The Manual Traffic Learning screen opens.
2.
In the Negative Security Violations section of the Traffic Learning area, click the Attack signature staging link.
The Attack Signature Staging screen opens.
a)
In the Action column, select Enable or Disable from the list.
6.
Below the Attack Signature Staging area, click the Apply button.
A confirmation popup screen opens.
7.
Click OK.
The popup screen closes, and displays the Traffic Learning screen.
8.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
1.
On the Main tab, expand Security, point to Application Security, Policy Building, and click Enforcement Readiness.
The Enforcement Readiness screen opens.
2.
Select the Signatures check box, and click the Enforce Ready button.
A confirmation popup screen opens.
3.
Click OK.
The system removes from staging all signatures that did not cause violations, and enforces them once you apply the security policy changes.
4.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
User-defined attack signatures are those that the user creates and adds to the attack signature pool. User-defined attack signatures have the following attributes:
They are never updated by F5 Networks. All user-defined signatures are carried forward as-is whenever there is a software version upgrade.
1.
On the Main tab, expand Security, point to Options, Application Security, then click Attack Signatures.
The Attack Signatures Update screen opens.
2.
From the Attack Signatures menu, select Attack Signatures List.
3.
Above the Attack Signatures list, click Create.
The Create Attack Signature screen opens.
4.
In the Name field, type a unique name for the new attack signature.
Warning: If you create a user-defined attack signature with the same name as a system-supplied attack signature, subsequent signature updates may fail.
5.
In the Description field, type an optional description of the signature.
6.
To include this signature in all active security policies, make sure that Auto Apply New Signatures Configuration After Create is enabled.
7.
For the Signature Type setting, select Request or Response to determine whether the new signature applies to requests or responses.
8.
For the Systems setting, select from the Available Systems list any systems to which the new signature applies, and move them to the Assigned Systems list.
9.
For the Attack Type setting, select the type of threat that the new signature protects against.
10.
For the Rule setting, type a rule according to the syntax guidelines in Appendix C, Syntax for Creating User-Defined Attack Signatures. This setting is required.
11.
For the Accuracy setting, select an accuracy level. The accuracy level indicates the ability of the attack signature to identify the attack, including susceptibility to false-positive alarms.
12.
For the Risk setting, select a risk level. The risk level indicates the level of potential damage this attack may cause, if it were successful.
13.
Click the Create button.
The screen refreshes, and displays the Attack Signatures list.
You may need to update a user-defined attack signature, for example, to change the accuracy level after the signature has been in use for a while, based on observed traffic.
1.
On the Main tab, expand Security, point to Options, Application Security, then click Attack Signatures.
The Attack Signatures Update screen opens.
2.
From the Attack Signatures menu, select Attack Signatures List.
3.
Click the Show Filter Details link to display the Advanced Filter.
4.
For the User-defined setting, select Yes.
5.
Click Go.
The screen refreshes and lists only user-defined attack signatures.
6.
In the Attack Signatures list, click the name of the user-defined attack signature that you want to modify.
The Edit Attack Signature screen opens.
8.
Click Update to retain any changes you may have made.
You can permanently remove user-defined attack signatures from the attack signature pool. Note that when you delete a user-defined signature from the attack signature pool, the system removes that signature from any signature sets of which the attack signature is a member.
1.
On the Main tab, expand Security, point to Options, Application Security, then click Attack Signatures.
The Attack Signatures Update screen opens.
2.
From the Attack Signatures menu, select Attack Signatures List.
3.
Click the Show Filter Details link to display the Advanced Filter.
4.
For the User-defined setting, select Yes.
5.
Click Go.
The screen refreshes and lists only user-defined attack signatures.
6.
In the Attack Signatures list, in the Select column (far left), select the box next to the name of the user-defined attack signature that you want to delete.
7.
Below the Attack Signatures list, click the Delete button.
A confirmation popup screen displays.
8.
Click the OK button.
The system deletes the attack signature from the configuration, and displays the Attack Signatures list screen.
If you have a large number of user-defined attack signatures that you want to add to the configuration, you can import them in an XML-formatted file. You can also use the import functionality to import a previously exported user-defined attack signature file onto a system with the same version of Application Security Manager. Figure 10.1 shows an example of the XML file format for the user-defined attack signatures file.
Warning: The sig_name attribute uniquely identifies a user-defined attack signature. Therefore, when you import an attack signature XML file, if there are any signatures in the XML file whose sig_name attribute matches that of any existing user-defined signatures, the system overwrites the existing definition with the imported definition.
1.
On the Main tab, expand Security, point to Options, Application Security, then click Attack Signatures.
The Attack Signatures Update screen opens.
2.
From the Attack Signatures menu, select Attack Signatures List.
3.
Click Import.
The Import Attack Signatures screen opens.
4.
In the Choose File field, type the path to the XML file that contains the user-defined attack signatures. Alternately, click the Browse button and navigate to the XML file.
5.
To place in staging any signatures that are updated as a result of the import, for the Place updated signatures in staging setting, click Enabled.
After the import, the system puts updated signatures into staging for the Enforcement Readiness Period (specified in Policy properties).
Note: The system places all new signatures added by the update into staging regardless of this setting.
6.
To include this signature in the active security policies, for the Auto Apply New Signatures Configuration After Import setting, make sure that Enabled is selected.
7.
Click the Import button.
The system imports the user-defined signatures, and issues either a success message or a failed message.
8.
If the import is successful, click the OK button.
The screen refreshes, and displays the Attack Signatures list with the additional user-defined signatures.
9.
If the import was not successful, make any required changes to the XML file, and then try to import the file again.
You can export all user-defined attack signatures to transfer them to another system, or save them in a remote location. When you export user-defined attack signatures, the Application Security Manager saves them in an XML file using the format shown in Figure 10.1.
1.
On the Main tab, expand Security, point to Options, Application Security, then click Attack Signatures.
The Attack Signatures Update screen opens.
2.
From the Attack Signatures menu, select Attack Signatures List.
4.
Click Export.
The web browser opens a file download or a save file popup screen.
5.
Save the signature file in a location that meets your requirements. Application Security Manager uses a file name with this format:
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)