airween
commented
2 months ago Hi @n-rodriguez,
thanks for reporting!
I don't know if it's a bug but the
[client <ip address>]field is missing inmodsec_audit.loginsection H.
it's definitely not a bug - it's by feature.
I know the client ip address is present in
section Abut it's not very handy to use because it forces you to do some correlations between the different sections especially when the logs reach our Graylog server :* `section A` contains the client ip * `section H` the actual error/reason for denyOn the other side, Nginx error logs do contain the client ip but :
but not that format. [client <ip addr>] format appears in Apache's error log. Nginx uses this syntax:
... ... [ref ""], client: 127.0.0.1, server: _, request: "POST /post HTTP/1.1",where the field [ref ""] is the last field from engine, and the rest part comes from the HTTP server itself.
* you only have the last error from ModSecurity * Nginx error log is filled when `SecRuleEngine` is set to `On` => it doesn't fill Nginx error logs in `DetectionOnly` modeExample :
[...]
Thanks for examples, those helped me understand the issue.
could you show us how looks like the error_log entry in your config?
The expected setting is this:
error_log /path/to/your/error.log info;so you must set up the severity, which should be info.
I'm almost sure you don't have any severity, then the default value is applied (error) which means only lines will be logged which has severity:ERROR action. This is why you see only the "last error from ModSecurity".
2024/06/20 18:20:33 [error] 23698#23698: *1 [client 10.3.27.225] ModSecurity:
In this example the [client 10.3.27.255] is there just because you already applied your patch, right? It's not there by default.
It would be nice to have the client ip in
modsec_audit.loglike :---M6IDyUV5---H-- [client 10.3.27.225] ModSecurity: Warning. Matched "Operator `PmFromFile' with parameter `unix-shell.data' against variable `ARGS:bar' (Value: `/bin/sh' ) [file "/data/nginx/coreruleset/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf"] [line "556"] [id "932160"] [rev ""] [msg "Remote Command Execution: Unix Shell Code Found"] [data "Matched Data: bin/sh found within ARGS:bar: /bin/sh"] [severity "2"] [ver "OWASP_CRS/4.3.0"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-shell"] [tag "platform-unix"] [tag "attack-rce"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/152/248/88"] [tag "PCI/6.5.2"] [hostname "10.3.27.225"] [uri "/"] [unique_id "171890043325.867807"] [ref "o1,6v10,7t:cmdLine,t:normalizePath"] [client 10.3.27.225] ModSecurity: Access denied with code 403 (phase 2). Matched "Operator `Ge' with parameter `5' against variable `TX:BLOCKING_INBOUND_ANOMALY_SCORE' (Value: `5' ) [file "/data/nginx/coreruleset/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "222"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [data ""] [severity "0"] [ver "OWASP_CRS/4.3.0"] [maturity "0"] [accuracy "0"] [tag "anomaly-evaluation"] [tag "OWASP_CRS"] [hostname "10.3.27.225"] [uri "/"] [unique_id "171890043325.867807"] [ref ""]
I'm not sure this is a good idea globally - just think about other users who already has their own logparser subsystem, and now an update changes the existing log format.
Btw I don't know exactly is that a tradition or not, but all log entry starts with the string "ModSecurity: ...". It's true in both case of engines: mod_security2 and libmodsecurity3. A parser could know that "this is the entry point" :)
Moreover, audit log is a very special type of log, so I'm sure everyone who uses that to analyze the traffic can extract every necessary info, including client IP. And therefore it would be good to break this format.
To do so I've rebuilt the Debian package with a small patch :
Description: Add client ip to modsec_audit.log Add client ip to modsec_audit.log Author: Nicolas Rodriguez <nico@nicoladmin.fr> Origin: upstream --- This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ Index: modsecurity-3.0.9/src/rule_message.cc =================================================================== --- modsecurity-3.0.9.orig/src/rule_message.cc +++ modsecurity-3.0.9/src/rule_message.cc @@ -67,9 +67,9 @@ std::string RuleMessage::log(const RuleM std::string msg(""); msg.reserve(2048); - if (props & ClientLogMessageInfo) { + //if (props & ClientLogMessageInfo) { msg.append("[client " + std::string(*rm->m_clientIpAddress.get()) + "] "); - } + //} if (rm->m_isDisruptive) { msg.append("ModSecurity: Access denied with code ");
Beside the others this is not so elegant way to solve this problem. If a line is not necessary, then you should remove it, not just make a comment.
But if you follow the function call stack, you can see that this function is at the end. There are some other implementations of log() method in that class, see this or this. For some reason all other method calls only the first one (without any arguments). If you really want to modify (in your instance locally), you should find the point where the engine build the audit log entry, and change the log() format to log(props, responseCode).
Hope this helped to clarify the context.
n-rodriguez
Hi there!
I don't know if it's a bug but the
[client <ip address>]field is missing inmodsec_audit.loginsection H.I know the client ip address is present in
section Abut it's not very handy to use because it forces you to do some correlations between the different sections especially when the logs reach our Graylog server :section Acontains the client ipsection Hthe actual error/reason for denyOn the other side, Nginx error logs do contain the client ip but :
SecRuleEngineis set toOn=> it doesn't fill Nginx error logs inDetectionOnlymodeExample :
Detection mode :
modsec_audit.log:Nginx
error.log: emptyBlock mode :
modsec_audit.log:Nginx
error.log:It would be nice to have the client ip in
modsec_audit.loglike :To do so I've rebuilt the Debian package with a small patch :
It seems to work in both mode (Detection mode and Block mode, the logs above were generated with this patch) but I'd like to have your opinion on this.
Thank you!