WAF (Web Application Firewall) is designed to neutralize threats to a web application. WAF is placed in a network before the protected web servers. Processing HTTP packets it imposes certain rules on interaction between a server and a client. The basic principle is the same as in ordinary firewalls — monitoring of all data from outside. It protects the web server from attacks by identifying abnormal or malicious traffic, then isolating and blocking that traffic to prevent it from reaching the server.
We use the Naxsi WAF. The firewall includes the set of basic rules which help to protect from the most critical web application security risks. In the Enabled mode each HTTP-request (GET|PUT|POST) is checked for main ban patterns. Main rules can be too strict for normal operation of some applications, that is why we recommend to go through the Learning mode during which the firewall will collect statistics and create custom rules taking into consideration your application peculiarities. Please be advised that each Custom rule is an exception for the correspondent Main rule. Enabling custom rules you can reduce protection level.
How to Enable
- Contact us to enable the option in the contol panel
- Go through the Learning mode for two days minimum
- Choose the Enabled mode
- Activate Custom Rules
You shouldn’t turn on the Learning mode during an attack because the rules collected within this period can significantly reduce a protection level.
MainRule "rx:select|union|update" "msg:sql keywords" "s:$SQL:4" id:1000 "mz:BODY|URL|ARGS"
This rule means that all requests with regular expressions select, union, update in body, url, query strings will be rejected.
id: num is the unique numerical ID of the rule from Naxsi
Match pattern can be a regular expression, a string match:
- rx:foo|bar — will match foo or bar
- str:foo|bar — will match foo|bar
msg is a string describing the pattern. This is mostly used for analyzing and contains some human-understandable text.
mz is the match zone, defining which part of the request will be inspected by the rule.
Match Zones are present in main rules and custom rules. It is used to specify where a pattern should be searched (main rules) or where it should be allowed (custom rules). Please note that match zones behave a bit differently in main rules and custom rules. In main rules each condition is OR (ie. in BODY or in HEADERS), while in custom rules it's AND (ie. url must be /foo and exception must happen in ARGS)
4 main zones exist: URL, ARGS, HEADERS, BODY, and match zone can be more or less restrictive.
A mz can be wide
- ARGS: GET args
- HEADERS: HTTP Headers
- BODY: POST args (and RAW_BODY)
- URL: The URL itself (before '?')
Or more specific
- $ARGS_VAR:string: named GET argument
- $HEADERS_VAR:string : named HTTP header
- $BODY_VAR:string: named POST argument
Sometime, regular expressions are needed (ie. variable names can vary)
- $HEADERS_VAR_X:regex: regex matching a named HTTP header $ARGS_VAR_X:regex: regex matching the name of a GET argument $BODY_VAR_X:regex: regex matching the name of a POST argument
A matchzone can be restricted to a specific URL: (but is not a zone on its own)
- $URL:string: restricted to this url
- $URL_X:regex: restricted to url matching regex
A matchzone that targets BODY, HEADERS, ARGS can add |NAME to specify the target is not the content of a variable, but its name itself. Read more on rules.
When you pass through the Learning mode you will see a list of exceptions for Main rules.
BasicRule wl:1000 "mz:$URL:/auth/|$BODY_VAR:true|NAME"
This custom rule deactivate the main rule with ID 1000 for URL and BODY
wl — ID(s) of the rule in the Naxsi main rules list.
Possible syntax are:
- wl:0 : Whitelist all rules
- wl:42 : Whitelist rule #42
- wl:42,41,43 : Whitelist rules 42, 41 and 43
- wl:-42 : Whitelist all user rules, excepting rule 42
mz is the match-zone, specifying in which part(s) of the request the specified ID(s) must be ignored. In whitelist context, all conditions specified in the mz must be satisfied. Read more on custom rules.
WAF Protects From
Remote file inclusion
Cross Site Scripting