Applies To:
Show VersionsBIG-IP ASM
- 14.0.1, 14.0.0, 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0, 13.0.1, 13.0.0
About custom attack signatures
Custom attack signatures are those that your organization creates and adds to the attack signature pool. Custom 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 custom attack signatures, if needed, for specific purposes in your environment. The signatures that you define are stored in the attack signatures pool along with the system-supplied signatures. You can also export and import custom signatures to and from other Application Security Manager™ systems.
Creating a custom attack signature
Attack signature example: Protecting the management interface
This example describes an attack signature that blocks attempts to access the management interface, which is located at http://example.com/manage/. The web server is IIS, and the signature ignores URL case, treating manage the same as MaNAGE.
uricontent:"/manage/"; nocase; objonly;This signature can detect URLs that contain /manage/ (the nocase modifier causes it to be not case-sensitive so that it also catches /mAnage/, for example). The signature catches, for example: http://example.com/portal/manage/panel/index.php.
This signature also catches a request that contains:
http://example.com/manage/admin.php
http://example.com/admin.php?a=%2Fmanage%2FIn the example, %2f is URL-encoded in place of / because the query string part cannot include an explicit forward slash.
Attack signature example: Protecting against cross-site scripting
This example describes an attack signature that blocks a cross-site scripting attempt that use HTML events such as onmousemove, onmousedown, onmouseup and other similar events within a parameter.
HTML is not case-sensitive, so the signature should not distinguish between upper- and lower-case. That way, the browser treats the onMousemOve event the same as onmousemove.
This example signature is not case-sensitive and looks inside a parameter. The signature also uses a regular expression for these reasons:
- To support several events in a single signature
- To ignore special characters such as the space (the browser normalizes several spaces into a single space)
- To match a certain pattern: "[event_name] =" (for example, to reduce false positives, so the single word onmousemove or blablaonmousemove does not match the signature)
The signature has two parts:
- The constant keyword that matches the word onmouse (not case-sensitive)
- A regular expression that matches several events (separated by a vertical bar |), ignores non-word characters (\W*), and matches a certain pattern (\b for word boundary and = for [event_name] = pattern)
valuecontent:"onmouse"; nocase; norm; re2:"/\bonmouse(?:move|down|up|out|over|enter|leave|wheel) \\W*=/Vsi"; norm;
http://example.com/index.php?a=onmousedown%3D%22alert(document.cookie)%22After parameter a is URL-decoded, you can see onmousedown="alert(document.cookie)". The same signature would also catch requests where this expression is located in the request body, for instance:
POST /index.php HTTP/1.1 Host: example.com a=onmousedown%3D%22alert(document.cookie)%22
http://example.com/onmousedown%3d/since it is located in the URI part of the request, and not in the query string part.
Exporting custom attack signatures
Importing custom attack signatures
After the import, the system puts updated signatures into staging for the Enforcement Readiness Period (specified in Policy properties). Custom signatures are put into staging for all policies that have this signature in their assigned signature sets. It is a good idea to make sure that the new signature was added to the appropriate security policies.
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:"soda";</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>f <attack_type>Cross Site Scripting (XSS)</attack_type> <systems> <system_name>IIS</system_name> <system_name>Microsoft Windows</system_name> </systems> </rev> </sig> </signatures>