ModSecuity errors in Imunify log

Issue

Console.log is mainly used for the internal diagnostic, although if the Imunify agent registers an error for the ModSecurity and writes this error to the log, the question might appear whether this error is significant.

Environment

• Imunify360
• ModSecurity

Solution

Let's start with the rule itself and then follow the log message. 

1. The rule:

SecRule REQUEST_HEADERS:'/^(?:x-dns-prefetch-control|...|server-timing|...
|sec-websocket-accept)$/' "!@rx ^$" "id:77316852,

In this example, the rule is monitoring HTTP illegitimate headers in phase 1*. As well as script names:

[file "/etc/httpd/conf/modsecurity.d/rules/custom/006_i360_4_custom.conf"] [line "557"]
 [id "77316852"] [msg "IM360 WAF: Request header interception| |Header:REQUEST_HEADERS:
Server| |Data:www| |SC:| |T:APACHE||"]

*the header Server and the value www that were spotted. SC is empty.

 2. The log entry:

[Wed Apr 13 06:32:09.256277 2022] [:error] [pid 965037:tid 139868093019904] 
[client xx.xx.xx.xx:43192] [client xx.xx.xx.xx] ModSecurity: Warning.

Such an error mark in log entries means that ModSecurity or Apache register errors and the Imunify agent sends those to the log. The error is likely to appear because of missing some data or a variable, such as SC (SCRIPT_FILENAME) in the example above, yet overall this may be considered insignificant.

A bit more details.

Match of "rx ^$" against "REQUEST_HEADERS:Server" required.

Such Regex will help us to collect variable values. Imunify30 console log refers to the server header, this helps to define which service was triggering an event and as for the meaning of the Regex used in this rule, it is monitoring a variable presence with a non-empty value. Such Regex will help us to collect variable values. This need for attack analysis and when a False Positive fix is requested.

phase:1,pass,log,severity:5,t:none,msg:'IM360 WAF: Request header interception||
Header:%{MATCHED_VAR_NAME}||Data:%{MATCHED_VAR}||SC:%{SCRIPT_FILENAME}||T:APACHE||',tag:

HTTP response header names in requests can be used to smuggle payloads to malicious scripts, we should not be observing HTTP headers like Server-Timing or X-DNS-Prefetch-Control  in the request (phase: 1), since they would mostly be in phase: 3, therefore we trigger this rule to count such attempts by collecting headers values and users in the counters

[severity "NOTICE"] [tag "noshow"] [tag "service_i360custom"] [hostname "primadiervoeding.nl"] 
[uri "/index.php"] [unique_id "YlZSSePxTM5yDe8KPuzTuAAAAcc"]

This non-blocking rule (working in a pass mode) is typically used to track "suspicious activity". These rules check requests as well and generate entries in the logs as soon as those get triggered. We collect the information about these rules triggered and process them further. This event will be omitted in the UI. And a bit more on severity levels and tags can be found in our article on ModSecurity rules with and without the no-show tag.

Useful links

• https://cloudlinux.zendesk.com/hc/en-us/articles/360013049860-ModSecurity-rules-with-and-without-the-noshow-tag
• https://github.com/SpiderLabs/ModSecurity