Here, client X.X.X.X request to server Y.Y.Y.Y did trigger the rule 42000227 in the var named user-agent in theHEADERS zone. id X might seem obscure, but you can see the meaning in naxsi_core.rules:
MainRule "str:<" "msg:html open tag" "mz:ARGS|URL|BODY|$HEADERS_VAR:Cookie" "s:$XSS:8" id:1302;
NAXSI_FMT is composed of different items :
ip : Client's ip
server : Requested Hostname (as seen in http header Host)
uri: Requested URI (without arguments, stops at ?)
learning: tells if naxsi was in learning mode (0/1)
total_processed: Total number of requests processed by nginx's worker
total_blocked: Total number of requests blocked by (naxsi) nginx's worker
zoneN: Zone in which match happened (see "Zones" in the table below)
idN: The rule id that matched
var_nameN: Variable name in which match happened (optional)
cscoreN : named score tag
scoreN : associated named score value
Several groups of zone, id, var_name, cscore and score can be present in a single line.
NAXSI_EXLOG
NAXSI_EXLOG is a complement to naxsilogs. Along with exceptions, it contains actual content of the matched request. While NAXSI_FMT only contains IDs and location of exception, NAXSI_EXLOG provides actual content, allowing you to easily decide if it's a false positive or not.
Learning tools uses this at his advantage. Extensive log is enabled by adding the following line in your server {} section but out of your location.
"User defined" rules are supposed to have IDs > 1000.
IDs inferior 1000 are reserved for naxsi internal rules, which are usually related to protocol sanity and things that cannot be expressed through regular expressions or string matches.
Think twice before whitelisting one of those IDs, as it might partially/totally disable naxsi.
Rules are meant to search for patterns in parts of a request to detect attacks.
ie. DROP any request containing the string 'zz' in any GET or POST argument : MainRule id:424242 "str:zz" "mz:ARGS|BODY" "s:DROP";
Rules can be present at location level (BasicRule) or at http level (MainRule).
Rules have the following schema :
Everything must be quoted with double quotes, except the id part.
ID (id:...)
id:num is the unique numerical ID of the rule, that will be used in NAXSI_FMT or whitelists.
IDs inferior to 1000 are reserved for naxsi internal rules (protocol mismatch etc.)
Match Pattern
Match pattern can be a regular expression, a string match, or a call to a lib (libinjection) :
rx:foo|bar : will match foo or bar
str:foo|bar : will match foo|bar
d:libinj_xss : will match if libinjection says it's XSS (>= 0.55rc2)
d:libinj_sql : will match if libinjection says it's SQLi (>= 0.55rc2)
Using plain string match when possible is recommended, as it's way faster. All strings must be lowercase, since naxsi's matches are case insensitive.
Score (s:...)
s is the score section. You can create "named" counters: s:$FOOBAR:4 will increase counter $FOOBAR value by 4. One rule can increase several scores: s:$FOO:4,$BAR:8 will increase both $FOO by 4 and $BAR by 8. A rule can as well directly specifiy an action such a BLOCK (blocks the request in non-learning mode) or DROP (blocks the request even in learning mode) Named scores are later handled by CheckRules.
Rules in the RAW_BODY zone will only applied when:
The Content-type is unknown (which means naxsi doesn't know how to properly parse the request)
id 11 (which is the internal blocking rule for 'unknown content-type') is whitelisted.
Then, the full body (url decoded and with null-bytes replaced by '0') is passed to this set of rules. The full body is matched again the regexes or string matches.
Whitelists for RAW_BODY rules are actually written just like normal body rules, such as:
BasicRule wl:4241 "mz:$URL:/rata|BODY";
Human readable message (msg:...)
msg is a string describing the pattern. This is mostly used for analyzing and to have some human-understandable text.
Negative Keyword (negative)
negative is a keyword that can be used to make a negative rule. Score is applied when the rule doesn't match :
MainRule negative "rx:multipart/form-data|application/x-www-form-urlencoded" "msg:Content is neither mulipart/x-www-form.." "mz:$HEADERS_VAR:Content-type" "s:$EVADE:4" id:1402;
./naxsi/naxsi_src/naxsi_runtime.c:234:9:error: implicit declaration of function ‘pcre2_get_ovector_count’ [-Werror=implicit-function-declaration]
234 | n = pcre2_get_ovector_count(ngx_pcre2_match_data);
| ^~~~~~~~~~~~~~~~~~~~~~~
./naxsi/naxsi_src/naxsi_runtime.c:235:10:error: implicit declaration of function ‘pcre2_get_ovector_pointer’ [-Werror=implicit-function-declaration]
235 | ov = pcre2_get_ovector_pointer(ngx_pcre2_match_data);
|^~~~~~~~~~~~~~~~~~~~~~~~~
./naxsi/naxsi_src/naxsi_runtime.c:235:8:error: assignment to ‘size_t *’ {aka ‘long unsigned int *’} from ‘int’ makes pointer from integer without a cast [-Werror=int-conversion]
235 | ov = pcre2_get_ovector_pointer(ngx_pcre2_match_data);
