How to Create Efficient Signatures
by Michael Gorelick
Knowledge Engineer
There are 3 types of signatures: Web, SQL, and Stream signatures.
Web and SQL signature support enhanced pattern matching using regular expressions.
Note: Stream signatures are basic pattern matching where an exact pattern must match.
- Stream signatures don’t have rgxp, only “part”, “rmin”, and “rmax” (the latter two being the min and max distance between the “part”s).
- Stream signatures are applied to stream signature policies, which are enforced at the server group level, and are therefore tested against almost all traffic.
The Imperva WAF GW detection capabilities have improved over time, while early on stream signatures were the best method to match some attack patterns this is no longer the case. New security engines allow us to craft more precise and efficient rules. Hence the default stream signatures are considered legacy and have been disabled by default from version 10.5. The stream dictionary ADC content is now covered by the ADC content of the applicative dictionaries.
Here are some tips on how to make the signature effective, reduce the chance of false positives, and reduce performance impact:
We have seen too many cases where bad signature practice caused major failures at customer's systems:
1) Use as long a "part" statement as possible: a Web or SQL signature first tries to match all its "part" statements of the signature before it attempts to match the regex statement.
A "part" matching is considered a "partial matching" and only if the rgxp matches – it will become a "full-match" and the signature will match.
Part matching is “cheap” in resources compared to regular expression matching.
The longer the "part" you use, you reduce the chance for "partial matching" and minimize unnecessary use of the rgxp expensive engine.
Anyway, The minimum length for a "part" statement must include at least 3 characters.
Not recommended: part="asp"
Recommended: part="uploadfiles.asp
2) Always use "part" statements - avoid using signatures with an rgxp statement only.
Not recommended: rgxp="select.*students"
Recommended: part="students", rgxp="select.*students"
3) Avoid using obvious parts or parts that are too common.
For example, if you are setting a signature for select action on some table, eg: select user_id from students, avoid setting a part statement for "select", it will result in a partial match for any (!) select statement.
Not recommended: part="select", part=" *students"*, rgxp="select.*students"
Recommended: part="students", rgxp="select.*from.*students"
4) Use multiple relevant part statements whenever applicable.
For example: to create a signature to match admin login: http://kermit.com/user_login.asp?user=admin
Not recommended: part="admin*"*
Recommended: Part="user_login.asp", part="user" , part="admin", rgxp="user=\s*admin".
In this example, this signature will start processing the rgxp only if the specific user_login.asp page was called, and the value for parameter user is "admin".
5) Signature locations: when creating a signature, you have to set the "Search signature in".
There are six locations for Web signature and two locations for SQL signatures - use the most appropriate location for your signature.
Web signature:
URL- Request URLs after being normalized by On-Prem WAF.
Parameters - Parameters in the request.
Headers - HTTP headers.
Response Content - content returned by the webserver – response content signature causes some performance impact, avoid using it if possible.
Non-Normalized URL - the URL raw, as it is received in the actual request.
SQL signature:
Query - the SQL raw query as it received in the actual request.
Parsed Query - the SQL request after being normalized by On-Premises WAF. Redundant spaces removed, all in lower-case, literals are replaced by "?" sign.