Applies To:

Show Versions Show Versions

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

12 
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 users. 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 individual 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 12.1 describes common web application attacks that attack signatures can detect.
Abuse of functionality is an attack technique that uses a web site's own features and functionality to consume, defraud, or circumvent the applications access control mechanisms.
Authentication attacks target 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.
A brute force attack is an outside attempt by hackers to access post-logon pages of a web site by guessing user names and passwords; brute force attacks are performed when a malicious user attempts to log on to a URL numerous times, running many combinations of user names and passwords until they successfully log on.
Buffer overflow exploits are attacks that alter 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 attacks are those where an attacker manipulates the data for 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 datafor example, a list of users on a server.
Cross-site scripting (XSS) is an attack technique that forces a web site to echo attacker-supplied executable code, which loads in a user's browser.
Denial of Service (DoS) is an attack technique that overwhelms system resources to prevent a web site from serving normal user activity.
Automatic directory listing/indexing is a web server function that lists all of the files within a requested directory if the normal base file is not present.
Forced browsing is an attack where the aim is 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.
An HTTP parser attack is an attempt 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.
HTTP request smuggling 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.
Information leakage is when a web site reveals sensitive data, such as developer comments or error messages, which may aid an attacker in exploiting the system.
An injection attempt is an attempt to include in a request information that is not permitted by the security policy, such as including a null in a request or including an illegal attachment.
Non-browser client is an attempt by automated client access to obtain sensitive information. HTML comments, error messages, source code, or accessible files may contain sensitive information.
This attack category 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.
Parameter tampering attacks involve 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.
The path traversal attack technique forces access to files, directories, and commands that potentially reside outside the web document root directory.
Remote file include attacks occur as a result of unclassified application attacks such as when applications use parameters to pass URLs between pages.
SSI injection (server-side include) is a server-side exploitation technique that allows an attacker to send code into a web application, which is then run locally by 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 as a cookie, in other parts of the header of an HTTP request, or in the body of the HTTP request. Session hijacking compromises the session token by stealing or predicting a valid session token to gain unauthorized access to the web server.
Attackers use Trojan horse, backdoor, and spyware attacks to try 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 launches.
A vulnerability scan is an attack technique that uses an automated security program to probe a web application for software vulnerabilities.
An XML parser attack is an attempt 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 12.2 describes the built-in filters.
Show signatures of accuracy greater than/equal to
Use this built-in filter to display 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.
Use this built-in filter to display 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.
In the Application Security navigation pane, click Options.
The Attack Signatures screen opens, where you can review the entire attack signatures pool.
2.
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.
3.
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 12.3 describes the custom filter options.
Attack signature
custom filter option
Use this custom filter option to display only attack signatures that match a specific signature ID number. Signature ID numbers are system-supplied, and cannot be modified.
Use this custom filter option to display only attack signatures that match the selected attack type. See Table 12.1, for a description of the attack types having signatures associated with them.
Table 12.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.
In the Application Security navigation pane, click Options.
The Attack Signatures screen opens.
2.
In the Signature Name column, click (the Show/Hide Details icon) next to the signature for which you want to view information.
Basic information display on the screen below the signature.
Tip: You can also click the name of the signature to display the signature properties.
3.
For the Documentation setting, click View to see additional information that applies to the selected attack signature.
A new screen opens (Documentation for Attack Signature), and displays the additional documentation.
Note: Some attack signatures have no additional documentation. You see N/A for the Documentation setting if this is the case.
4.
When you finish reviewing the documentation, click the Close button.
The Attack Signatures screen reopens.
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 provides 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 the signatures manually.
Two conditions may cause an attack signature update to fail: insufficient network access and duplicate attack signature names.
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 1) a valid service agreement with F5 Networks, and 2) 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. Contact F5 Networks Technical Support, https://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.
1.
In the Application Security navigation pane, point to Options, Attack Signatures, and then click Attack Signatures Update.
The Attack Signatures Update screen opens.
2.
In the Attack Signatures Update area, for the Update Mode setting, click Scheduled.
The screen refreshes, and displays the Update Interval setting.
3.
For the Update Interval setting, select the rate at which the system updates the system-supplied attack signatures pool.
4.
If you want the system to automatically apply all active security policies after updating the system-supplied signatures, leave the Auto Apply Policy After Update box checked.
5.
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 on an as needed basis, you can use the manual update option. You can obtain the latest attack signatures update file from http://downloads.f5.com.
1.
In the Application Security navigation pane, point to Options, Attack Signatures, and then click Attack Signatures Update.
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 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.
If you want the system to automatically apply the currently active security policy after updating the system-supplied signatures, leave the Auto Apply Policy After Update box checked.
5.
Click the Save Settings to save your changes.
6.
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.
In the Application Security navigation pane, point to Options, Attack Signatures, and then click Attack Signatures Update.
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.
For the Readme option, 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 Ask F5SM web site for the Security email distribution list. Once you sign up for the distribution list, you will receive an email message whenever F5 updates the available attack signatures database.
Important: You must have a valid service contract, and an Ask F5SM account, to receive the attack signatures notifications.
1.
Open a browser, and log in to the Ask F5SM web site at https://support.f5.com.
The Ask F5 Knowledge Base screen opens.
2.
In the navigation pane, 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 does not recommend that you do 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 12.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.
You can create two types of signature sets: filter-based and manual. Filter-based signature sets are based solely on criteria defined 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 the attack signatures themselves. Another advantage to filter-based sets is that when you update the attack signatures database, the system also updates any signature sets to which the update applies.
1.
In the Application Security navigation pane, point to Options, Attack Signatures, and then click Attack Signature Sets.
The Attack Signature Sets screen opens.
2.
Above the Attack Signature Sets list, click Create.
The Create Signature Set screen opens.
3.
In the Create Signature Set area, in the Name box, type a unique name for the signature set.
4.
For the Type setting, select Filter-based.
5.
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 settings 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.
6.
If you want the system to automatically include this signature set in any new security policies you create, check the Assign To Policy By Default box.
7.
In the Signatures Filter area, select the filter options to create a new signature set. For descriptions of the individual filter options, see the online help.
8.
In the Signatures area, for the Signatures setting, you can review the signatures list that the filter settings generates.
The list content changes dynamically with the filter selection.
9.
Click Create.
The screen refreshes, and you see the new signature set in the Signatures Set list.
Manual 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.
In the Application Security navigation pane, point to Options, Attack Signatures, and then click Attack Signature Sets.
The Attack Signature Sets screen opens.
2.
Above the Attack Signature Sets list, click Create.
The Create Signature Set screen opens.
3.
In the Create Signature Set area, in the Name box, type a unique name for the signature set.
4.
For the Type setting, select Manual.
5.
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 settings 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.
6.
If you want the system to automatically include this signature set in any new security policies you create, check the Assign To Policy By Default box.
7.
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.
8.
For the Signatures setting, move the signatures you want to include in the set into the assigned signatures list.
9.
Click Create.
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.
In the Application Security navigation pane, point to Options, Attack Signatures, and then click Attack Signature Sets.
The Attack Signature Sets screen opens.
2.
In the Name column, click the name of the signature set that you want to edit.
The Signature Set Properties screen opens.
4.
Click the Save button below the Signatures area.
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.
In the Application Security navigation pane, point to Options, Attack Signatures, and then click Attack Signature Sets.
The Attack Signature Sets screen opens.
2.
Select the check box preceding the signature set that you want to remove, and click the Delete button.
A confirmation popup screen displays.
3.
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.
In the Application Security navigation pane, click Attack Signatures.
The Attack Signature Sets Assignment screen opens.
3.
In the Attack Signature Sets Assignment area, in 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 Update button to save 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.
In the Application Security navigation pane, click Attack Signatures.
The Attack Signature Sets Assignment 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 Assigned Signature Sets list, 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 system builds a list of all of the attack signatures. You can review the signatures, their current blocking policy, and their state on the Policy Attack Signatures screen. Figure 12.1 shows a sample of the attack signature list for a security policy.
1.
In the Application Security navigation pane, point to Attack Signatures, and then click Policy Attack Signatures.
The Policy Attack Signatures 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 Show all signatures to display all signatures associated with the security policy.
1.
In the Application Security navigation pane, point to Attack Signatures, and then click Policy Attack Signatures.
The Policy Attack Signatures 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 Show all signatures to display all signatures associated with the security policy.
4.
In the Policy Attack Signatures list, clear the Enabled box next to each signature you want to disable.
5.
Click Save.
6.
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 Enforcer 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, the Security Enforcer applies the blocking actions whenever a signature in the set detects an attack pattern in a request. For more information on the Blocking Policy and the blocking actions, refer to Configuring security policy blocking.
Note: The blocking policy applies to all of the signatures in the signature set. You cannot specify a blocking policy for individual signatures.
1.
In the Application Security navigation pane, click Attack Signatures.
The Attack Signature Sets Assignment screen opens.
3.
In the Attack Signature Sets Assignment area, for each signature set in the Assigned Signature Sets list, check or clear the boxes in the Learn, Alarm, and Block columns as required.
Note: If the enforcement mode for the security policy is transparent, the Block action is not configurable. You can enable or disable the Block action only when the enforcement mode is blocking.
4.
Click the Update button to save any changes you may have made.
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 block 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. (For more information on updating signatures, see Updating the system-supplied attack signatures.)
1.
In the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
3.
For the Staging-Tightening Period setting, type the number of days for which you want new or updated attack signatures to remain in staging.
4.
Check the Enable Signature Staging box.
5.
Click Save 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.
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 Staging screen. Upon evaluation, if the signature is a false-positive, you can disable the signature, and the Security Enforcer 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.
In the Application Security navigation pane, click Manual.
The Traffic Learning screen opens.
2.
In Negative Security Violations section of the Traffic Learning area, click the Attack signature staging link.
The Attack Signature Staging screen opens, where you can review the signatures that detected attack patterns in a request.
Figure 12.2 shows the Attack signature staging link on the Traffic Learning screen.
Figure 12.3 shows the attack signatures that are in staging for the current edited security policy. Click the number under Recent Incidents to view details about requests that
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 considered to be legitimate. In such a case, you should disable that signature immediately.
1.
In the Application Security navigation pane, click Manual.
The 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.
Tip: To disable a signature for a specific parameter when at least one incident occurred, select the Disable on parameter action.
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.
In the Application Security navigation pane, click Manual.
The 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.
3.
Click the Enforce Signatures button.
The system removes from staging all signatures that did not cause violations and enforces them.
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.
In the Application Security navigation pane, click Options.
The Attack Signatures screen opens.
2.
Above the Attack Signatures list, click Create.
The Create Attack Signature screen opens.
3.
In the Name box, 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.
4.
In the Description box, type an optional description of the signature.
5.
For the Apply To setting, select whether the new signature applies to requests or responses.
6.
For the Systems setting, select from the Available Systems list any systems to which the new signature applies, and use the Move buttons (<< and >>) to add them to the Assigned Systems list.
7.
For the Attack Type setting, select the type of threat that the new signature protects against.
8.
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.
9.
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.
10.
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.
11.
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.
In the Application Security navigation pane, click Options.
The Attack Signatures screen opens.
2.
In the Attack Signatures list, click the name of the user-defined attack signature that you want to modify.
The Update Attack Signature screen opens.
4.
Click Save to retain the changes.
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.
In the Application Security navigation pane, click Options.
The Attack Signatures screen opens.
2.
In the Attack Signatures list, in the Select column (far left), check the Select box next name of the user-defined attack signature that you want to delete.
3.
Below the Attack Signatures list, click the Delete button.
A confirmation popup screen displays.
4.
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 from the same version of Application Security Manager. Figure 12.4 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.
In the Application Security navigation pane, click Options.
The Attack Signatures screen opens.
2.
Above the Attack Signatures list, click Import.
The Import Attack Signatures screen opens.
3.
In the Choose File box, 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.
4.
Click the Import button.
The system imports the user-defined signatures, and issues either a success message or a failed message.
5.
If the import is successful, click the OK button.
The screen refreshes, and displays the Attack Signatures list with the additional user-defined signatures.
6.
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 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 12.4.
1.
In the Application Security navigation pane, click Options.
The Attack Signatures screen opens.
2.
Above the Attack Signatures list, click Export.
The web browser opens a file download or a save file popup screen.
Note: Each web browser manages this functionality differently.
3.
Save the signature file in a location that meets your requirements. Application Security Manager saves the signature in 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)