Re: [Owasp-modsecurity-core-rule-set] Setting tx.anomaly_score before including crs-setup.conf somehow works, should it?
I'm quite sure the phase is the issue. I run the log with Debug 9, just pasted here a "cleaned up" version. Setting the phase to 1 in my custom rules causes the anomaly score to reset in REQUEST-901-INITIALIZATION.conf I'll investigate further Il 05/12/2017 11:10, Christian Folini ha scritto: Cristian, You are getting there. Yet the DebugLogLevel is still not high enough. Put it to 9and then you grep for the threshold variable in the logfile. This will allow you to see which rule sets the threshold and in what order. It is possible it's a phase issue. But when I looked over it in your previous message the suspicion was not confirmed. But I am not ruling it out. Ahoj, Christian ___ 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
Re: [Owasp-modsecurity-core-rule-set] Setting tx.anomaly_score before including crs-setup.conf somehow works, should it?
Cristian,
You are getting there. Yet the DebugLogLevel is still not high enough.
Put it to 9and then you grep for the threshold variable in the logfile.
This will allow you to see which rule sets the threshold and in what order.
It is possible it's a phase issue. But when I looked over it in your
previous message the suspicion was not confirmed. But I am not ruling it out.
Ahoj,
Christian
On Mon, Dec 04, 2017 at 07:03:33PM +0100, Cristian Mammoli wrote:
>Ok, so this is my config:
>End of /etc/httpd/conf/httpd.conf:
>IncludeOptional conf.d/*.conf
>[root@waf01 ~]# ls -1 /etc/httpd/conf.d/
>000_mod_evasive.conf
>000_mod_security.conf
>000_mod_ssl.conf
>000_mod_status.conf
>vhost1.conf
>vhost2.conf
>ecc
>End of /etc/httpd/conf.d/000_mod_security.conf:
>IncludeOptional /etc/httpd/modsecurity.d/*.conf
>IncludeOptional /etc/httpd/crs/crs-setup.conf
>IncludeOptional /etc/httpd/crs/rules/*.conf
>[root@waf01 ~]# ls -1 /etc/httpd/modsecurity.d/
>000_whitelist_rules.conf
>cutwail_zenobi.data
>local_rules.confnou
>runav.conf
>whitelist_ip.data
>In /etc/httpd/modsecurity.d/local_rules.conf I have:
># Debug test
>SecRule REMOTE_ADDR "@ipMatch 217.133.31.142" \
> "msg:'Client IP in Test list',\
> severity:'CRITICAL',\
> id:10099,\
> phase:request,\
> pass,\
> t:none,\
> tag:'application-multi',\
> tag:'language-multi',\
> tag:'platform-multi',\
> tag:'attack-reputation-ip',\
> setvar:'tx.msg=%{rule.msg}',\
> setvar:tx.anomaly_score=+20,\
>
>setvar:tx.%{rule.id}-AUTOMATION/MALICIOUS-%{matched_var_name}=%{matched
>_var}"
>Then I did
>curl [1]https://www.vhost.com and the request got rejected (20/11
>score, 11 is my threshold)
>Now I have the full debug trace of the request but it's a huge amount
>of data.
>I think the culprit is this:
>[2]https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Proc
>essing_Phases
>Note : Keep in mind that rules are executed according to phases, so
>even if two rules are adjacent in a configuration file, but are set to
>execute in different phases, they would not happen one after the other.
>The order of rules in the configuration file is important only within
>the rules of each phase. This is especially important when using the
>skip and skipAfter actions.
>My rules use phase:request, which I suppose is equivalent to phase:2,
>while REQUEST-901-INITIALIZATION.conf are all phase:1
>Anyway this is the (mostly cleaned) log:
>Starting phase REQUEST_HEADERS.
>This phase consists of 159 rule(s).
>Recipe: Invoking rule 5589ef173f78; [file
>"/etc/httpd/conf.d/000_mod_security.conf"] [line "27"] [id "20"].
>Recipe: Invoking rule 5589ef1d7ed0; [file
>"/etc/httpd/conf.d/000_mod_security.conf"] [line "34"] [id "21"].
>Recipe: Invoking rule 5589ef278288; [file
>"/etc/httpd/modsecurity.d/000_whitelist_rules.conf"] [line "3"] [id
>"10050"]. <- This is my only phase:1 rule
>Recipe: Invoking rule 5589f629ba98; [file
>"/etc/httpd/crs/crs-setup.conf"] [line "263"] [id "900110"].
>Recipe: Invoking rule 5589f62813a0; [file
>"/etc/httpd/crs/crs-setup.conf"] [line "303"] [id "900130"].
>Recipe: Invoking rule 5589f62c4e70; [file
>"/etc/httpd/crs/crs-setup.conf"] [line "329"] [id "900200"].
>Recipe: Invoking rule 5589f62c65a0; [file
>"/etc/httpd/crs/crs-setup.conf"] [line "342"] [id "900220"].
>Recipe: Invoking rule 5589f62e8488; [file
>"/etc/httpd/crs/crs-setup.conf"] [line "542"] [id "900500"].
>Recipe: Invoking rule 5589f62e42d0; [file
>"/etc/httpd/crs/crs-setup.conf"] [line "622"] [id "900700"].
>Recipe: Invoking rule 5589f6329f58; [file
>"/etc/httpd/crs/crs-setup.conf"] [line "679"] [id "900960"].
>Recipe: Invoking rule 5589f63474d0; [file
>"/etc/httpd/crs/crs-setup.conf"] [line "774"] [id "900990"].
>Recipe: Invoking rule 5589f6366d28; [file
>"/etc/httpd/crs/rules/REQUEST-901-INITIALIZATION.conf"] [line "61"] [id
>"901001"].
>Recipe: Invoking rule 5589f6351348; [file
>"/etc/httpd/crs/rules/REQUEST-901-INITIALIZATION.conf"] [line "78"] [id
>"901100"].
>Recipe: Invoking rule 5589f63529d0; [file
>"/etc/httpd/crs/rules/REQUEST-901-INITIALIZATION.conf"] [line "86"] [id
>"901110"].
>Recipe: Invoking rule 5589f637c180; [file
>"/etc/httpd/crs/rules/REQUEST-901-INITIALIZATION.conf"] [line "94"] [id
>"901120"].
>Recipe: Invoking rule 5589f63c78d0; [file
>"/etc/httpd/crs/rules/REQUEST-901-INITIALIZATION.conf"] [line "102"]
>[id "901130"].
>Recipe: Invoking rule 5589f639cd48; [file
>"/etc/httpd/crs/rules/REQUEST-901-INITIALIZATION.conf"] [line "110"]
>[id "901140"].
>Recipe: Invoking rule 5589f639e2c8; [file
>"/etc/httpd/crs/rules/REQUEST-901-INITIALIZATION.conf"] [line "117"]
>[id
Re: [Owasp-modsecurity-core-rule-set] Setting tx.anomaly_score before including crs-setup.conf somehow works, should it?
Hi, On Mon, Dec 04, 2017 at 04:07:00PM +0100, Cristian Mammoli wrote: > In REQUEST-901 thresholds are set to default if not already set, I know. Sorry, I jumped to conclusions too quickly then. > There are no conditionals like in 901100. > > What am I missing? The problem sounds as if you would have to raise the debug log level and work your way through the file to see which rule sets which value and in what order. Ahoj, Christian > > Ty > > > Il 04/12/2017 14:47, Christian Folini ha scritto: > > Hey Cristian, > > > > No, this works perfectly. Let me tell you why: > > > > The crs-setup.conf does not actually set the threshold. Instead the > > REQUEST-901 initialization file sets the threshold to the default value > > if it is not set. > > > > You are setting the anomaly score in your rule file in modsecurity, so no > > need to set it to the default during the initialization. > > > > This is very close to what I personally favor: Setting it in the server > > config and not in an include. That way the threshold is always in plane > > sight. > > Same for paranoia level btw. > > > > Ahoj, > > > > Christian -- https://www.feistyduck.com/training/modsecurity-training-course https://www.feistyduck.com/books/modsecurity-handbook/ mailto:christian.fol...@netnea.com twitter: @ChrFolini ___ 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
Re: [Owasp-modsecurity-core-rule-set] Setting tx.anomaly_score before including crs-setup.conf somehow works, should it?
In REQUEST-901 thresholds are set to default if not already set, I know. Like in # Default Inbound Anomaly Threshold Level (rule 900110 in setup.conf) SecRule :inbound_anomaly_score_threshold "@eq 0" \ "id:901100,\ phase:1,\ pass,\ nolog,\ setvar:tx.inbound_anomaly_score_threshold=5" But the tresholds are not the issue here: I set *tx.anomaly.score* in my rules like this: setvar:tx.anomaly_score=+10,\ and 901200 should re(set) everything to 0: SecAction \ "id:901200,\ phase:1,\ nolog,\ pass,\ t:none,\ setvar:tx.anomaly_score=0,\ setvar:tx.sql_injection_score=0,\ setvar:tx.xss_score=0,\ setvar:tx.rfi_score=0,\ setvar:tx.lfi_score=0,\ setvar:tx.rce_score=0,\ setvar:tx.php_injection_score=0,\ setvar:tx.http_violation_score=0,\ setvar:tx.session_fixation_score=0,\ setvar:tx.inbound_anomaly_score=0,\ setvar:tx.outbound_anomaly_score=0,\ setvar:tx.sql_error_match=0" There are no conditionals like in 901100. What am I missing? Ty Il 04/12/2017 14:47, Christian Folini ha scritto: Hey Cristian, No, this works perfectly. Let me tell you why: The crs-setup.conf does not actually set the threshold. Instead the REQUEST-901 initialization file sets the threshold to the default value if it is not set. You are setting the anomaly score in your rule file in modsecurity, so no need to set it to the default during the initialization. This is very close to what I personally favor: Setting it in the server config and not in an include. That way the threshold is always in plane sight. Same for paranoia level btw. Ahoj, Christian ___ 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
Re: [Owasp-modsecurity-core-rule-set] Setting tx.anomaly_score before including crs-setup.conf somehow works, should it?
Hey Cristian,
No, this works perfectly. Let me tell you why:
The crs-setup.conf does not actually set the threshold. Instead the
REQUEST-901 initialization file sets the threshold to the default value
if it is not set.
You are setting the anomaly score in your rule file in modsecurity, so no
need to set it to the default during the initialization.
This is very close to what I personally favor: Setting it in the server
config and not in an include. That way the threshold is always in plane sight.
Same for paranoia level btw.
Ahoj,
Christian
On Mon, Dec 04, 2017 at 02:21:39PM +0100, Cristian Mammoli wrote:
> Hi, I'm using CRS 3.0.2 on ModSec 2.9.2
>
> I'm including crs like this:
>
> [root@waf01 ~]# tail -n 3 /etc/httpd/conf.d/000_mod_security.conf
> IncludeOptional /etc/httpd/modsecurity.d/*.conf
> IncludeOptional /etc/httpd/crs/crs-setup.conf
> IncludeOptional /etc/httpd/crs/rules/*.conf
>
> I'm using rules in modsecurity.d/ for custom rules and so on
> I would expect that setting tx.anomaly_score in a rule file in modsecurity.d
> would make no sense, since the var get reset in
> crs/rules/REQUEST-901-INITIALIZATION.conf (901200) which gets loaded AFTER
> my rules.
>
> But it somehow works, for example this rule in
> modsecurity.d/local_rules.conf
>
> # Spamhaus XBL (scoring)
> SecRule REMOTE_ADDR "@rbl xbl.spamhaus.org" \
> "msg:'Client IP in xbl.spamhaus.org.',\
> severity:'CRITICAL',\
> id:10003,\
> phase:request,\
> pass,\
> t:none,\
> tag:'application-multi',\
> tag:'language-multi',\
> tag:'platform-multi',\
> tag:'attack-reputation-ip',\
> setvar:'tx.msg=%{rule.msg}',\
> setvar:tx.anomaly_score=+10,\
> setvar:tx.%{rule.id}-AUTOMATION/MALICIOUS-%{matched_var_name}=%{matched_var}
>
> The additional 10 points get counted in the final TX:inbound_anomaly_score
> and causes the request to be rejected.
>
> This is _exactly_ what I want :) But as far as I understand it shouldn't
> work or I don't get in which order the rules are included and evaluated
> ___
> 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
--
https://www.feistyduck.com/training/modsecurity-training-course
https://www.feistyduck.com/books/modsecurity-handbook/
mailto:christian.fol...@netnea.com
twitter: @ChrFolini
___
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
