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.
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/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.
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:
The signature has two parts:
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.
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.
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>