F5 Logo MyF5
Search
  1. MyF5 Home
  2. Knowledge Centers
  3. BIG-IP ASM
  4. BIG-IP Application Security Manager: Attack and Bot Signatures
  5. Assigning Attack Signatures to Security Policies
Manual Chapter : Assigning Attack Signatures to Security Policies

Applies To:

Show Versions Show Versions

BIG-IP ASM

  • 15.0.1, 15.0.0, 14.1.2, 14.1.0
Manual Chapter
Table of Contents | Next Chapter >>

Assigning Attack Signatures to Security Policies

About attack signatures

Attack signatures are rules or patterns that identify attacks on a web application. When Application Security Manager™ (ASM) receives a client request (or a server response), the system compares the request or response against the attack signatures associated with your security policy. If a matching pattern is detected, ASM™ triggers an Attack signature detected violation, and either alarms or blocks based on the enforcement mode of your security policy.

For example, the SQL injection attack signature looks for certain expressions like ' or 1=1, and if a user enters that string into a field (such as the username field) on your web application, ASM can block the request based on the SQL injection attempt.

An ideal security policy includes only the attack signatures needed to defend your application. If too many are included, you waste resources on keeping up with signatures that you do not need. Likewise, if you do not include enough, you might let an attack compromise your application without knowing it. If you are in doubt about a certain signature set, it is a good idea to include it in the policy rather than omitting it.

ASM provides over 2,500 attack signatures that are designed to guard against many different types of attacks and protect networking elements such as operating systems, web servers, databases, frameworks, and applications. Updates are provided periodically.

You can also create custom signatures, if needed, to secure your application. Additionally, you can create signatures to protect specific alphanumeric user-input parameters.

All of the attack signatures are organized into sets and are stored in the attack signature pool on ASM. If you know what systems your application is built on (Windows, SQL, IIS, UNIX/Linux, Apache, and so on), you can allow the system to choose the appropriate attack signatures to include in the security policy.

About attack signature staging

When you first activate a security policy, the system puts the attack signatures into staging (if staging is enabled for the security policy). 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 revise signatures in assigned sets, those are also put into staging. You also have the option of putting updated signatures in staging.

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. From the Traffic Learning tab, if you see that an attack signature violation has occurred, you can click the violation to see details about it, and decide what to do about it.

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.

Types of attacks that attack signatures detect

Attack signatures in a security policy are compared with requests or responses to attempt to identify classes of attacks, for example, SQL injection, command injection, cross-site scripting, and directory traversal. This table describes the types of attacks that attack signatures can detect. You can filter lists of attack signatures by these attack types.

Attack Type Description
Abuse of Functionality Uses a web site's own features and functionality to consume, defraud, or circumvent the application’s access control mechanisms.
Authentication/Authorization Attacks 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.
Buffer Overflow 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.
Command Execution 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.
Cross-site Scripting (XSS) Forces a web site to echo attacker-supplied executable code, which loads in a user's browser.
Denial of Service Overwhelms system resources to prevent a web site from serving normal user activity.
Detection Evasion Attempts to disguise or hide an attack to avoid detection by an attack signature.
Directory Indexing Involves a web server function that lists all of the files within a requested directory if the normal base file is not present.
HTTP Response Splitting Pertains to an attempt to deliver a malicious response payload to an application user.
Information Leakage Occurs when a web site reveals sensitive data, such as developer comments or error messages, which may aid an attacker in exploiting the system.
LDAP Injection Concerns an attempt to exploit web sites that construct LDAP statements from user-supplied input.
Non-browser Client 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.
Other Application Attacks 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.
Path Traversal Forces access to files, directories, and commands that potentially reside outside the web document root directory.
Predictable Resource Location Attempts to uncover hidden web site content and functionality.
Remote File Include Occurs as a result of unclassified application attacks such as when applications use parameters to pass URLs between pages.
Server Side Code Injection Attempts to exploit the server and allow an attacker to send code to a web application, which the web server runs locally.
SQL-Injection Attempts to exploit web sites that construct SQL statements from user-supplied input.
Trojan/Backdoor/Spyware Tries to circumvent a web server’s or web application’s 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.
Vulnerability Scan Uses an automated security program to probe a web application for software vulnerabilities.
XPath Injection Occurs when an attempt is made to inject XPath queries into the vulnerable web application.

Attack signature properties

This table describes the security policy attack signature properties that you can use to filter a security policy's attack signatures listed on the Attack Signature Properties screen.

Property Description
Name Displays the signature name.
ID Specifies the signature number automatically provided by the system.
Signature Type Specifies whether the signatures are for all traffic, for requests only, or for responses only.
Apply To Indicates whether the rule inspects the client’s request (Request) or the server’s response (Response).
Attack Type Forces a web site to echo attacker-supplied executable code, which loads in a user's browser.
Systems Displays which systems (for example, web applications, web server databases, or application frameworks) the signature or set protects.
Accuracy Indicates the ability of the attack signature to identify the attack including susceptibility to false-positive alarms:
  • Low: Indicates a high likelihood of false positives.
  • Medium: Indicates some likelihood of false positives.
  • High: Indicates a low likelihood of false positives.
Risk Indicates the level of potential damage this attack might cause if it is successful:
  • 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.
User-defined Indicates whether this signature is a system supplied rule (No) or was defined by a user (Yes).
Revision Indicates the version of the attack signature.
Last Updated Indicates the date when the attack signature was most recently updated.
Documentation Indicates whether the system provides documentation explaining this attack signature (View) or not (N/A). Click the View link to display the available documentation.
References Displays a clickable link to an external web site explaining this attack signature, or displays (N/A) if no link is available. If a CVE is associated with a signature, it is listed in the signature's References. Signatures can be searched and filtered by CVE.

Overview: Creating and assigning attack signature sets

You can create security policy attack 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 of using 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 affected by the update.

When manually creating a signature set, you must select each of the signatures to include from the signature pool. To simplify using this method, you can still filter the signatures first, then select the individual signatures from the filtered list.

Once you create the attack signature sets that you need, you can assign them to security policies.

About attack signature sets

An attack signature set is a group of attack signatures. The Application Security Manager ships with several system-supplied signature sets tailored to specific types of systems. Rather than applying several individual attack signatures to a security policy, you can apply the most relevant attack signature sets for the systems running your applications.

Each security policy has a default (generic) set of attack signatures associated with it. When you create a security policy, you can use the default signature set alone or assign additional signature sets to the security policy. Certain sets are more applicable to certain types of applications or types of attack.

For example, some signature sets focus on detecting attacks perpetrated on Unix/Linux systems. The sets are named logically so you can tell which ones to choose. Additionally, you can create your own attack signature sets.

List of attack signature sets

This table lists the attack signature sets included with Application Security Manager. Note that attack signature updates may contain new signature sets.

Signature Set Contains These Signatures
All Response Signatures All signatures in the attack signature pool that can review responses.
All Signatures All attack signatures in the attack signature pool.
Generic Detection Signatures Signatures that target well-known or common web and application attacks.
Generic Detection Signatures (High Accuracy) Signatures that target well-known or common web and application attacks but filtered by high accuracy.
Generic Detection Signatures (High / Medium Accuracy) Signatures that target well-known or common web and application attacks but filtered by high / medium accuracy.
High Accuracy Signatures Signatures with a high level of accuracy that produce few false positives when identifying attacks.
Low Accuracy Signatures Signatures that may result in more false positives when identifying attacks.
Medium Accuracy Signatures Signatures with a medium level of accuracy when identifying attacks.
OWA Signatures Signatures that target attacks against the Microsoft Outlook Web Access (OWA) application.
WebSphere Signatures Signatures that target attacks on many computing platforms that are integrated using WebSphere including general database, Microsoft Windows, IIS, Microsoft SQL Server, Apache, Oracle, Unix/Linux, IBM DB2, PostgreSQL, and XML.
Command Execution Signatures Signatures involving attacks perpetrated by executing commands.
Cross Site Scripting Signatures Signatures that target attacks caused by cross-site scripting techniques which force a user to execute unwanted actions in a web application where the user is currently authenticated.
Directory Indexing Signatures Signatures targeting attacks that browse directory listings.
HTTP Response Splitting Signatures Signatures targeting attacks that take advantage of responses for which input values have not been sanitized
Information Leakage Signatures Signatures targeting attacks that are looking for system data or debugging information that shows where the system is vulnerable to attack.
OS Command Injection Signatures Signatures targeting attacks that attempt to run system level commands through a vulnerable application.
Other Application Attacks Signatures Signatures targeting miscellaneous attacks including session fixation, local file access, injection attempts, header tampering, and so on that could affect many applications.
Path Traversal Signatures Signatures targeting attacks that attempt to access files and directories that are stored outside the web root folder.
Predictable Resource Location Signatures Signatures targeting attacks that attempt to uncover hidden website content and functionality by forceful browsing, or by directory and file enumeration.
Remote File Include Signatures Signatures targeting attacks that attempt to exploit a remote file include vulnerability that could enable a remote attacker to execute arbitrary commands on the server hosting the application.
SQL Injection Signatures Signatures targeting attacks that attempt to insert (inject) a SQL query using the input data from a client to an application.
Server Side Code Injection Signatures Signatures that target code injection attacks on the server side.
XPath Injection Signatures Signatures targeting 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.
Systems... Signature set that the system creates if you use other than the default signature sets when creating a security policy. It lists the systems assigned and all the signatures associated with those systems.

Creating a set of attack signatures

When you create an attack signature set, you can include the attack signatures that are relevant to your specific systems and applications.
  1. On the Main tab, click Security > Options > Application Security > Attack Signatures > Attack Signatures Sets .
    The Attack Signature Sets screen opens and displays the attack signature sets on the system.
  2. Click Create.
    The Create New Signature Set screen opens.
  3. In the Name field, type a unique name for the signature set.
    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.
  4. For the Type setting, select the appropriate option:
    Option Use
    Filter-based To create a signature set by using a filter only.
    Manual To create a signature set by selecting signatures from the signature pool, and optionally using a filter as well.
  5. For the Default Blocking Actions setting, select the 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 affect.
  6. 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.
  7. In the Signatures Filter area, select the filter options to narrow the scope of the signatures to include in the new signature set.
    Filter Option What It Does
    Signature Type Select to include signatures that apply to all traffic, requests only, or responses only.
    Signature Scope Manual only. Select whether to display all signatures or only those that do or do not apply tospecific data, such as JSON, header or request content.
    Attack Type Select the threat classifications for which to include signatures in the set.
    Systems Select the systems (for example web applications, web server databases, and application frameworks) that you want protected by the set.
    Accuracy Select the level of accuracy you want for the signatures in the set. Higher accuracy results in fewer false positives.
    Risk Select the level of potential damage for attacks protected by the signatures in the set.
    User-defined Specify whether to include signatures based on who created them (the user, system, or both).
    Update Date Specify whether to include signatures in the set based on the date the signature was changed.
  8. In the Signatures setting,
    • If creating the set using the filter only (Type = Filter-based), review the signatures list that the filter settings generate to make sure it is correct.
    • If creating the set manually(Type = Manual), move the signatures to include in the set from the Available Signatures list into the Assigned Signatures list.
  9. Click Create to create the new signature set.
The new signature set is added to the bottom of the list of attack signature sets that are available on the system. You can assign attack signature sets to security policies. The signature set is also available to be applied when creating new security policies.
If, in the future, you no longer need a user-defined signature set, you can delete it. When you delete a signature set, you are not deleting the attack signatures that make up the set, just the set.

Assigning signature sets to a security policy

Each security policy enforces one or more attack signature sets. When you first create a security policy, you select the attack signature sets to include. Later, you can assign additional attack signature sets to the security policy. For each attack signature set, you can also specify the blocking policy, which determines how the system will handle a potential attack.
  1. On the Main tab, click Security > Application Security > Policy Building > Learning and Blocking Settings .
    The Learning and Blocking Settings screen opens.
  2. In the Current edited security policy list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. On the right side of the Learning and Blocking Settings screen, select Advanced.
    The screen displays the advanced configuration details for policy building.
  4. In the Policy Building Settings area, expand Attack Signatures.
    The attack signature configuration is displayed, including the attack signature sets and blocking settings that the policy uses.
  5. Review the attack signature sets associated with the policy:
    1. Look over the blocking settings associated with each signature set.
    2. To view the signature set properties and a list of the signatures that are in each set, click the signature set name.
  6. For each signature set, configure the blocking policy: select or clear the Learn, Alarm, and Block check boxes.
    Note: You can enable or disable the Block action only when the enforcement mode of the security policy is set to blocking.
  7. To assign different signature sets to the security policy, click Change, select the ones to assign, then click Change again..
  8. If you want signatures to be put into staging before being enforced, select the Signature Staging check box.
    Staging means that the system compares the assigned attack signatures to the web application traffic, but does not apply the blocking policy action if requests trigger those attack signatures during the staging period. The default staging period is seven days.
  9. Specify how to enforce signature updates with the Updated Signature Enforcement setting:
    • To use updated signatures immediately, choose Enforce updated rule signature immediately.
    • To put the updated signature in staging and continue using the exiting signature, choose Retain previous rule enforcement and place updated rule in staging.
    Note: Regardless of this setting, the system always places newly added signatures in staging.
    If you put the updated signature in staging, the system still enforces the protection of the previous version of the signature. When the updated signature is enforced, the previous version is deleted and the new one is enforced instead.
  10. In the Apply Response Signatures for these File Types setting, specify the file types to which to enforce response attack signatures: Type the file type, and click Add.
  11. Click Save to save your settings.
  12. To put the security policy changes into effect immediately, click Apply Policy.
The signature sets are assigned to the security policy, and the blocking policy applies to all of the signatures in the signature set.
What happens depends on the blocking policy options you selected.
  • If you selected Learn, the security policy learns all requests that match enabled signatures included in the signature set, and displays the request data on the Traffic Learning Attack Signature Detected screen.
  • If Alarm is selected, the security policy logs the request data if a request matches a signature in the signature set.
  • If you selected Block, and the enforcement mode is Blocking, the security policy blocks all requests that match a signature included in the signature set, and sends the client a support ID number.

Viewing the attack signatures in a security policy

You can review all of the attack signatures in a security policy, including their current blocking policy and their state.
  1. On the Main tab, click Security > Application Security > Attack Signatures .
    The Attack Signatures screen opens.
  2. In the Current edited security policy list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. In the Policy Attack Signatures area, you can review the signatures that are associated with the security policy, the signature ID, the blocking policy actions, and whether or not they are enabled.
  4. Click a signature name to view its properties on the Policy Attack Signature Properties screen, and get more information about the signature.
    Here you can also enable or disable the signature for the active security policy. Clicking on the signature name again displays additional properties.
  5. Click Cancel (if you made no changes) or Update (if you changed the Enable setting) to return to the Attack Signatures List screen.

Enabling or disabling a specific attack signature

You can enable or disable specific attack signatures in a security policy one at a time. For example, if one of the attack signatures in a selected set causes false positives in your environment, you can disable it. At the same time, you can also enable or disable staging for a particular attack signature. Settings for a particular attack signature override the general attack signature settings.
  1. On the Main tab, click Security > Application Security > Attack Signatures .
    The Attack Signatures screen opens.
  2. In the Current edited security policy list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. In the Policy Attack Signatures area, you can review the signatures that are associated with the security policy, the signature ID, whether it is in staging, the blocking policy actions, and whether or not they are enabled.
  4. Click the name of the signature you want to enable or disable.
    The Policy Attack Signature Properties screen opens.
  5. Select or clear the Enable check box to enable or disable the signature for the active policy.
  6. Click Update (if you changed the Enable setting) to return to the Attack Signatures screen.
  7. To put the security policy changes into effect immediately, click Apply Policy.
If disabled, the signature is not part of the security policy and does not cause a violation even if patterns match the traffic. If the signature is enabled and enforced on the Traffic Learning screen, when traffic matches the pattern in the signature, an Attack Signature Detected violation occurs, and traffic is handled in accordance with the signature blocking policy. If you disable Perform Staging for a signature that is enabled, the system removes the signature from staging.

Enabling or disabling staging for attack signatures

For each security policy, you can enable or disable staging in general for attack signatures. By default, attack signature staging is enabled.
  1. On the Main tab, click Security > Application Security > Policy Building > Learning and Blocking Settings .
    The Learning and Blocking Settings screen opens.
  2. In the Current edited security policy list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. On the right side of the Learning and Blocking Settings screen, select Advanced.
    The screen displays the advanced configuration details for policy building.
  4. In the Policy Building Settings area, expand Attack Signatures.
    The attack signature configuration is displayed, including the attack signature sets and blocking settings that the policy uses.
  5. To enable (or disable) staging for all signatures, select (or clear) the Enable Signature Staging check box.
    Staging means that the system compares the assigned attack signatures to the web application traffic, but does not apply the blocking policy action if requests trigger those attack signatures during the staging period. The default staging period is seven days.
  6. Click Save to save your settings.
  7. Specify how to enforce signature updates with the Updated Signature Enforcement setting:
    • To use updated signatures immediately, choose Enforce updated rule signature immediately.
    • To put the updated signature in staging and continue using the exiting signature, choose Retain previous rule enforcement and place updated rule in staging.
    If you put the updated signature in staging, the system still enforces the protection of the previous version of the signature. When the updated signature is enforced, the previous version is deleted and the new one is enforced instead.
  8. To put the security policy changes into effect immediately, click Apply Policy.

When signature staging is enabled, the system places new or updated signatures in staging for the number of days specified in the enforcement readiness period. The system does not enforce signatures that are in staging, even if it detects a violation. Instead, the system records the request information.

If staging is disabled, updated attack signatures are not put into staging before they are enforced, regardless of the staging configuration for each individual signature. The system enforces the Learn, Alarm, and Block settings for each signature immediately. New signatures are always placed in staging even if this setting is disabled.

If staging is disabled for a specific signature or group of signatures, those signatures are also enforced according to the blocking settings. (If traffic causes an attack signature violation, it is blocked only if the security policy’s enforcement mode is Blocking.)

Overriding attack signatures based on content

Before you can perform this task, you must have previously created a JSON, XML, Google Web Toolkit (GWT), or Plain Text content profile.
You can have the system perform attack signature checks based on the content of a request as defined in content profiles (XML, JSON, GWT, or Plain Text). In addition, you can override the security policy settings so that the system avoids checking specific attack signatures in particular content.
  1. On the Main tab, point to Security > Application Security > Content Profiles and click a content profile type (XML, JSON, GWT, or Plain Text).
  2. In the profiles list, click the name of the content profile for which you want to specify attack signature checks.
    The profile properties screen opens.
  3. Click the Attack Signatures tab.
  4. Make sure that the Check attack signatures and threat campaigns check box is selected if you want the system to perform attack signature checking against the content profile.
  5. In the Global Security Policy Settings list, review the attack signatures that are assigned to the security policy, and which are enabled and enforced in the content profile.
  6. From the Global Security Policy Settings list, move any attack signatures that you want to override for this content profile into the Overridden Security Policy Settings list.
    Tip: In the Overridden Security Policy Settings list, click an attack signature link to display details about the attack signature.
  7. Click Update to update the content profile.
  8. To put the security policy changes into effect immediately, click Apply Policy.
Attack signatures in the overridden settings list are set to Disabled. The system does not issue a violation even when part of a request matches an overridden attack signature.
Table of Contents | Next Chapter >>
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5 Networks, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information