Nemesida WAF Community Edition supports a custom set of rules for detecting attacks: personal signatures (
RL), as well as signature exceptions (
Zones and additional conditions
During the creation of
WL rules special parameters can be used:
- conditions of using the rule (additional condition, specification of the zone):
Using zones and additional conditions allows to concretize maximally the creating rule. Additional conditions are set by adding prefix
$ (for example:
An example of using the rule with zone and additional condition:
WL ... "Z:ARGS|$URL:/123"; – the rule will work, if the entry zone of the
RL rule will be
ARGS zone and URL will contain an entry
For the additional conditions zone
URL, it is allowed to specify only the occurrence of a path without a domain.
Several parameters (zones, additional conditions) in one rule must be separated with the character
|, the following principle of interaction will be used:
- zones interact using the logical principle
OR, for example:
- zones interact with additional conditions using the logical principle
AND, for example:
- additional conditions interact using the logical principle
AND, for example:
When used in the additional conditions
| as a regular character, it is necessary to make its single shielding. For example:
$URL:abc\|d – search for the occurrence of
Regular expressions in the additional conditions
It is possible to use regular expressions in the additional conditions. This requires to add to the additional condition postfix
_X (for example:
For use regular expression operators in a rule as regular characters (
\, etc.), they must be double shielding.
$BODY_X:block\\|page – search of an entry
$BODY_X:data=\\(block-\\\a\\\-in-the-main\\) – search of an entry
$ACCEPT_X:image\\/webp\\\\\* – search of an entry
For use in additional conditions the separator as a metacharacter of a regular expression it is necessary to shield it double.
WL ... "Z:...|$URL_X:/(a\\|b)/"; will bring to
URL which contains
User-defined signature creation
The user-defined rules of detecting attack signs must be placed in the main configuration file Nemesida WAF (
/etc/nginx/nwaf/conf/global/nwaf.conf). They must be determined by the
RL parameter, must have
ID ranging from 50000 to 99999 and take the following form:
RL ID:50000 "P:select from" "SC:SQL:12" "Z:ARGS";
RL ID:50001 domain=example.com "P:select from" "SC:SQL:12" "Z:ARGS";
RL ID:50002 domain=.example.com "P:select from" "SC:SQL:12" "Z:ARGS";
RL ID:50003 domain=*.example.com "P:select from" "SC:SQL:12" "Z:ARGS";
RL ID:50004 "PX:select\s+from" "SC:SQL:12" "Z:ARGS|$URL:/admin";
RL ID:50005 "P:select from" "SC:SQL:12" "Z:ARGS|$URL:/(admin\\|dev)";
Creating a signature exclusion rule
In case the inquiry falls under action of a signature, in addition to sending the incident to the Nemesida WAF API, the following line will be displayed in the error log of the Nginx software:
Nemesida WAF: the request xxx contains a rule id 1 in zone HEADERS, ...
or, if the request contains a signature with a maximum allowable digital indicator of significance (
score = 12):
Nemesida WAF: the request xxx blocked by rule id 1 in zone HEADERS, ...
1 – attack signature ID;
HEADERS – signature entry zone.
To display absolutely all occurrences of signatures in the request (if there are occurrences), including those occurrences that did not lead to the subsequent blocking of the request, activate the
nwaf_log_mr_all; parameter, in the
nwaf.conf file Nemesida WAF.
The information about current signature list is on the page rlinfo.nemesida-security.com.
Switching the blocking rules to LM mode
Requests that fall under the
LM mode are recorded in the database, but are not blocked. When the rule is triggered, a message will be sent to the Nginx error log and to the Nemesida WAF API about switching the corresponding blocking rule to
LM mode, but the request will not be blocked. The rules for switching to the
LM mode must be defined by the
LM parameter, have the
ID of the corresponding blocking rule and take the following form:
Nemesida WAF virtual patching protects websites from existing uncorrected vulnerabilities (including “zero day”), blocking attempts to exploit them, while not disrupting the operation of the web application. The application of virtual patching rules allows developers to focus on fixing vulnerabilities without the need for urgent code changes. Virtual patching allows you to block all attempts to exploit a known vulnerability on the fly, controlling the attack zone in a special way.