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.
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.
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.
|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.|
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.
|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:
|Risk||Indicates the level of potential damage this attack might cause if it is
|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.|
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.
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.
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.|
|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.|
|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.|
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.
When signature staging is enabled, the system places all 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 traffic causes an attack signature violation, it is blocked only if the security policy’s enforcement mode is Blocking.)
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.
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.
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.
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>