Le 03/06/2015 16:22, Charles Farinella a écrit : > Thanks for the suggestions, but I don't think either of these will > solve our problem permanently. > > The 'nolog' option is rule or status code dependent and we want to > make sure that *no* request bodies are ever printed to the Nginx log. > The 'SecAuditLogParts' option seems to only affect what gets sent to > the audit logs, we've tried this. Mod_security docs say that > "Messages at levels 1-3 are *always* copied to the Apache error > log." We are assuming that this applies equally to Nginx logs, and > this is what we need to address. > > We have clients sending credit card numbers in request bodies and they > are triggering mod_security SQL injection rules which then write these > bodies to the Nginx logs exposing the CC number. > > We know that we can disable these specific rules, but are afraid that > at some future time, or after an upgrade, these or some other rules > will be triggered again exposing sensitive information. > > Does OWASP have a "best practices" procedure for protecting this kind > of data in a PCI environment? > How can we prevent *all* level 1-3 messages from being sent to the > Nginx log? > > Thanks again for your help. > > --charlie >
Hello Charlie,
We had the exact same issue at my workplace, and I found a semi solution
only : disable logging of rules, and add a new rule to log only final
result of anomaly score with last matched rule ID (see attached
15-custom-config.conf).
Now remains the audit rules adding specifically audit flags we don't
want, so I made a script and run it against my rules directory to
generate an additionnal rule file included AT THE END (99-xxx). It
generates something like that (script is attached):
SecRuleUpdateActionById 950120 ctl:auditLogParts=-E,chain
[...]
SecRuleUpdateActionById 973337 nolog
[...]
SecRuleUpdateActionById 981205 "logdata:'Matched rules:
%{tx.counter}; Rule list: %{matched_rule-1} %{matched_rule-2}
%{matched_rule-3} %{matched_rule-4} %{matched_rule-5}
%{matched_rule-6} %{matched_rule-7} %{matched_rule-8}
%{matched_rule-9} %{matched_rule-10} %{matched_rule-11}
%{matched_rule-12} %{matched_rule-13} %{matched_rule-14}
%{matched_rule-15} %{matched_rule-16} %{matched_rule-17}
%{matched_rule-18} %{matched_rule-19} %{matched_rule-20}',log,auditlog"
On some rules, the keyword "chain" is specified. In fact current
modsecurity needs us to specify again this keyword when we update a
chained action.
The last parts here are an attempt to fetch the rule IDs that matched
since they don't get logged. Although it doesn't work, but keep it so it
replaces the logdata of these rules, which can contain sensitive
information. It was coupled with a rule included before all
(20-track-ids.conf) containing only this (currently disabled) :
#SecRule TX:/^\d/ "."
"phase:2,id:'45',t:none,nolog,noauditlog,pass,setvar:tx.counter=+1,setvar:tx.matched_rule-%{tx.counter}=%{matched_var_name}"
I'm interested by feedback if you manage to log a list of matched rule ids !
Since we don't get that much information of matched rules, except when
the request get blocked, I added some rules which kinda copies the
blocking rule (without the block part of course) from
base_rules/modsecurity_crs_49_inbound_blocking.conf when the anomaly
score is not exceeded. See attached 99-log-low-anomalies.conf.
As you can see in the 99- file, I also had to alter the last matched
data variable when SecRule was matching a parameter containing sensitive
data. We use JSON parsing so we can use that, but XML parsing does not
provide parameter name, so I hope you're in REST API and not SOAP.
The result is : we always get a summary of what happened when score is
not 0, with the ID of last matched rule, but not all the IDs.
Maybe modsecurity / OWASP team could make a PCI compliant version of the
rules / software, because it is indeed hard to work with as it is when
you need to avoid sensitive data being logged.
I hope I didn't forget anything, and it helps you on your modsecurity
journey ^^
--
Loïc Gomez
15-custom-config.conf.gz
Description: application/gzip
99-log-low-anomalies.conf.gz
Description: application/gzip
modsecurity-no-bodies.sh.gz
Description: application/gzip
_______________________________________________ Owasp-modsecurity-core-rule-set mailing list Owasp-modsecurity-core-rule-set@lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
