F5 Logo MyF5
Search
  1. MyF5 Home
  2. Knowledge Centers
  3. BIG-IP ASM
  4. BIG-IP Application Security Manager: Implementations
  5. Working with Attack Signatures
Manual Chapter : Working with Attack Signatures

Applies To:

Show Versions Show Versions

BIG-IP ASM

  • 11.6.5, 11.6.4, 11.6.3, 11.6.2, 11.6.1
Manual Chapter
Table of Contents | << Previous Chapter | Next Chapter >>

Working with Attack Signatures

About attack signatures

Attack signatures are rules or patterns that identify attacks or classes of attacks on a web application and its components. A security policy compares patterns in the attack signatures against the contents of requests and responses looking for potential attacks. Some of the signatures are designed to protect specific operating systems, web servers, databases, frameworks or applications. Additionally, you can assign some signatures to protect certain alpha-numeric user-input parameters.

All of the attack signatures on the Application Security Manager™ are stored in the attack signature pool.

You can develop customized (user-defined) attack signatures, however, this is an advanced feature only needed for specific cases. User-defined signatures are stored in the attack signatures pool along with the system-supplied signatures. You can import and export user-defined attack signatures.

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 change 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 Manual Traffic Learning, if you see that an attack signature violation has occurred, 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.

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. The following 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

The following table describes the attack signature properties, listed on the Attack Signature Properties screen, that you can view for more information about the signatures in the pool.

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.

Overview: Creating and assigning attack signature sets

You can create 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 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 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. 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.

Each security policy has its own attack signature set assignments. By default, a generic signature set is assigned to new security policies. You can assign additional signature sets to the security policy. Certain sets are more applicable to certain types of applications or types of attack. 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

The following table lists the attack signature sets included with Application Security Manager™.

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.
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.
HTTP Response Splitting Signatures Signatures targeting attacks that take advantage of responses for which input values have not been sanitized
OS Command Injection Signatures Signatures targeting attacks that attempt to run system level commands through a vulnerable application.
Path Traversal Signatures Signatures targeting attacks that attempt to access files and directories that are stored outside the web root folder.
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.

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 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 ID Manual only. Leave blank unless you want to include a signature with a specific ID number in the signature set.
    Signature Type Select to include signatures that apply to all traffic, requests only, or responses only.
    Apply To Manual only. Select whether to include in the set all signatures or only signatures that apply to alpha-numeric user-input parameters defined in the security policy, XML documents, or JSON data.
    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, review the signatures list that the filter settings generate to make sure it is correct.
    • If creating the set manually, 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 creating a security policy, you select the attack signature sets to include. You can assign additional attack signature sets to the security policy. For each attack signature set, you can also specify the blocking policy, which is what you want to happen if an attack signature in the set discovers a potential attack.
  1. On the Main tab, click Security > Application Security > Attack Signatures > Attack Signatures Configuration .
    The Attack Signatures Configuration screen opens.
  2. In the Current edited policy list near the top of the screen, verify that the edited security policy is the one you want to work on.
  3. If you want signatures to be put into staging before being enforced, select the Signature Staging check box.
    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.
  4. 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 and move them into the Assigned Signature Sets list.
  5. In the Attack Signature Sets Assignment setting, for each signature set in the Available Signature Sets list, 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.
  6. To specify the file types for which to enforce response attack signatures:
    1. For Check Response Settings, select the Apply Response Signatures check box.
      You need at least one file type in the security policy to use this setting.
    2. Click Create if you need to create file types.
    3. Use the Move buttons to adjust the file types for which to apply or not apply response signatures.
  7. Click Save to save your settings.
  8. To configure headers that you do not want attack signatures to examine, in the Excluded Headers setting, click the Configure HTTP Headers link.
    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.
    The HTTP Headers screen opens where you can create the custom, cookie, or referrer headers to exclude.
  9. 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 signature sets in a security policy

You can review the attack signature sets that are associated with a security policy.
  1. On the Main tab, click Security > Application Security > Attack Signatures > Attack Signatures Configuration .
    The Attack Signatures Configuration screen opens.
  2. In the Current edited policy list near the top of the screen, verify that the edited security policy is the one you want to work on.
  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 them.
  4. Click a signature set name to review its properties and the attack signatures in that set.

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 > Attack Signatures List .
    The Attack Signatures List screen opens.
  2. In the Current edited policy list near the top of the screen, verify that the edited security policy 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.
  1. On the Main tab, click Security > Application Security > Attack Signatures > Attack Signatures List .
    The Attack Signatures List screen opens.
  2. In the Current edited policy list near the top of the screen, verify that the edited security policy 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 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 List screen.
  7. To put the security policy changes into effect immediately, click Apply Policy.
If disabled, the signature does not cause a violation even if patterns match the traffic. If enabled, if traffic matches the pattern in the signature, an Attack Signature Detected violation occurs, and traffic is handled in accordance with the signature blocking policy. Note that enabling a signature that is in staging removes it from staging, and puts the blocking policy into effect.

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. You can also control whether specific signatures are in staging.
  1. On the Main tab, click Security > Application Security > Attack Signatures > Attack Signatures Configuration .
    The Attack Signatures Configuration screen opens.
  2. In the Current edited policy list near the top of the screen, verify that the edited security policy is the one you want to work on.
  3. For the Signature Staging setting, specify your staging preference:
    • To enforce staging on new or changed signatures, select the Enabled check box.
    • To disable signature staging, clear the Enabled check box.

    All security policy signatures that are individually configured to be in staging are in staging.

  4. Click Save to save your settings.
  5. To configure staging for specific signatures or a group of signatures, on the menu bar, click Attack Signatures List.
    • To change the staging status for a single attack signature, click the name of the signature, select or clear the Perform Staging check box, and click Update.
    • To change the staging status for a group of signatures, use the filter settings to display the group, click Change Properties, adjust the staging status, and click Apply Changes to Filtered Attack Signatures.
  6. 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, 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. 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, or Google Web Toolkit (GWT) 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, or GWT). 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, or GWT).
  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 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.

Overview: Managing the attack signature pool

The system includes an attack signatures pool from which you can select signatures to include in any security policy. 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.

F5 develops new attack signatures to handle the latest attacks, and you can schedule periodic updates to the attack signatures pool, or update it manually. You can have the system send you an email when an update to the attack signature pool is available.

Updating the attack signature pool

Before you can update the attack signature pool, you must have a valid service agreement with F5 Networks, and a service check date within 18 months of the update request. The Application Security Manager™ must also have external network access for the update process to work.
You can schedule automatic updates to the attack signature pool, or update the pool manually.
  1. On the Main tab, click Security > Options > Application Security > Attack Signatures .
    The Attack Signatures Update screen opens.
  2. For the Update Mode setting, specify the type of update:
    • To schedule automatic updates, select Scheduled, and then from Update Interval, select how often to perform an update.
    • For manual updates or systems without Internet access, select Manual, and then select the Delivery Mode: select Automatic to get the update directly from F5, or Manual to specify a file from F5 containing the updates (specify the file in the Upload File setting).
  3. To put into staging signatures that are changed by the update, enable the Place updated signatures in staging setting.
    Note: The system places any new signatures added by the update into staging regardless of this setting.
    After the update, the system puts changed signatures into staging for the Enforcement Readiness Period (specified in Policy properties).
  4. 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.
  5. Click the Save Settings button to preserve any changes you may have made to the configuration.
  6. If performing manual updates, click the Update Signatures button when you want to start the update process.
If you scheduled automatic updates, the system connects to the F5 server periodically to see if there are any updates, and if there are, it downloads and applies available updates. When updated either manually or automatically, the attack signature pool includes any new signatures and updates to any existing attack signatures that were revised. The new signatures are placed in staging.

The Application Security Manager records details about the most recent update activity, and displays this information on the Attack Signatures Update screen. There you can review the last update time as well as the readme file that pertains to the update.

Getting email about signature updates

If you want to receive notification from F5 Networks about attack signature updates available for download, you can sign up for the Security Updates mailing list.
  1. From a web browser, open the Search the AskF5 Knowledge Base site, http://support.f5.com/.
  2. From the SELF-HELP menu, select Subscribe: Mailing Lists
    The AskF5 Publication Preference Center page opens.
  3. Provide the email address to which you want the notifications sent.
  4. Select the Security Updates list, as well as any others in which you are interested.
  5. Click Submit.
    Whenever F5 has new attack signatures available, or has information related to security, you will receive an email notification at the address you specified.

Viewing the attack signature pool and signature details

The attack signatures pool contains all of the attack signatures that are on the system. You can view the attack signature pool contents, and see details about each signature.
  1. On the Main tab, click Security > Application Security > Attack Signatures > Attack Signatures List .
    The Attack Signatures List screen opens.
  2. If you are looking for specific signatures, use the filter to display the ones you are interested in.
    You can use one of the predefined filters, or click Show Filter Details to develop a custom filter.
  3. In the Signature Name column, click the signature for which you want to view information.
    The Policy Attack Signature Properties screen opens and shows details about that signature.
  4. For the Signature Name setting, click the signature name link.
    The Attack Signature Properties screen opens and shows additional details about that signature.
  5. In the Documentation setting (if available), click View to see additional information that applies to the selected attack signature.
    The Documentation for Attack Signature screen opens in a new browser window, and displays the additional related documentation.
  6. On the Attack Signature Properties screen, click the References setting link to an external web site that describes the attack signature.
    If no additional documentation is available, you see N/A.
  7. When you finish reviewing the details, close the additional documentation screens and click Cancel to close the Attack Signature Properties screens.

Overview: Creating user-defined attack signatures

User-defined attack signatures are those that your organization creates and adds to the attack signature pool. User-defined attack signatures must adhere to a specific rule syntax. They are never updated by F5 Networks. All user-defined signatures are carried forward as-is when the system is updated to a new software version.

You can develop user-defined attack signatures if needed for specific purposes in your environment. You can also export and import user-defined signatures to and from other Application Security Manager™ systems.

Creating a user-defined attack signature

You can create a user-defined attack signature using the F5 attack signature syntax.
  1. On the Main tab, click Security > Options > Application Security > Attack Signatures > Attack Signature List .
    The Attack Signature List screen opens.
  2. Click Create.
    The Create New Attack Signature screen opens.
  3. In the Name field, type a unique name for the attack signature.
    Note: If you create a user-defined attack signature with the same name as a system-supplied attack signature, subsequent signature updates may fail.
  4. In the Description field, type an optional description of the signature.
  5. To include this signature in all active security policies, make sure that Auto Apply New Signatures Configuration After Edit is enabled.
  6. For the Signature Type setting, select Request or Response to determine whether the new signature applies to client requests or server responses.
  7. 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
  8. For the Attack Type setting, select the type of threat that the new signature protects against.
  9. For the Rule setting, type a rule according to the syntax guidelines to specify the content of the signature.
  10. 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.
  11. 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.
  12. Click Create to create the new attack signature.
The new attack signature is added to the attack signature pool. If you left the Auto Apply New Signatures Configuration After Edit check box selected, the system applies this signature to all active security policies.

Importing user-defined attack signatures

Before you can import user-defined signatures, you must first export them in XML file format.
You can import user-defined attack signatures from other Application Security Manager™ systems. Both systems must be running the same software version.
  1. On the Main tab, click Security > Options > Application Security > Attack Signatures > Attack Signature List .
    The Attack Signature List screen opens.
  2. Click Import.
    The Import Attack Signatures screen opens.
  3. In the Choose File field, specify the path to the XML file that contains the exported user-defined attack signature.
  4. To place in staging any signatures that are updated as a result of the import, select the Place updated signatures in staging check box.
    Note: The system places all new signatures added by the update into staging regardless of this setting.
    After the import, the system puts updated signatures into staging for the Enforcement Readiness Period (specified in Policy properties).
  5. To include this signature in all active security policies, make sure that Auto Apply New Signatures Configuration After Import is enabled.
  6. Click Import.
The system imports the user-defined signature, and issues either a success message or a failed message. If the import was not successful, make any required changes to the XML file, and then try to import the file again.

Exporting user-defined attack signatures

You can export all user-defined attack signatures from one Application Security Manager™ system for use on another system. Both systems must be running the same software version.
  1. On the Main tab, click Security > Options > Application Security > Attack Signatures > Attack Signature List .
    The Attack Signature List screen opens.
  2. Click Export.
    The web browser opens a file download screen.
  3. Save the file in a convenient location.
    Application Security Manager uses a file name with this format:

    sigfile_<date>_<time>.xml

The system exports all user-defined attack signatures to the XML file.

About attack signatures in XML format

The XML file format is the only accepted import format for attack signatures. Following is an example of the XML format used when saving user-defined attack signatures for import onto another system.

<?xml version="1.0" encoding="utf-8"?>
<signatures export_version="11.X.X">
  <sig id="300000000">
    <rev num="1">
      <sig_name>Unique signature name</sig_name>
      <rule>msg:"Signature Name"; content:"foo";</rule>
      <last_update>2011-04-15 13:37:17</last_update>
      <apply_to>Request</apply_to>
      <risk>3</risk>
      <accuracy>2</accuracy>
      <doc>Any additional descriptive text</doc>
      <attack_type>Cross Site Scripting (XSS)</attack_type>
      <systems>
        <system_name>IIS</system_name>
        <system_name>Microsoft Windows</system_name>
      </systems>
    </rev>
  </sig>
</signatures>
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.
Table of Contents | << Previous Chapter | 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