New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introducing an additional monitoring or hybrid paranoia level setting #1076

Merged
merged 26 commits into from Jul 12, 2018

Conversation

Projects
None yet
9 participants
@dune73
Copy link
Collaborator

dune73 commented May 5, 2018

This implements #1050.

  • The new feature is explained in crs-setup.conf.
  • The key functionality is in 949 and 959.
  • I have tested this, but it should see more testing. Ideally, much more.
  • I am not sure "monitoring paranoia level" is a good term. I do not like "hybrid" either. But what is a proper term for this? I am willing to change the PR based on a better term here. Maybe "execution paranoia level"?
  • We are doing very little plausibility / configuration checks. Possibly for performance reasons. I have added one essential test that aborts when the monitoring level is lower than the standard level.

@studersi studersi referenced this pull request May 7, 2018

Merged

Remove duplicate words. #1078

dune73 added some commits May 7, 2018

Merge pull request #1079 from studersi/monitoring-paranoia-levels-pat…
…ch-2

Set `monitoring_paranoia_level` to `paranoia_level` by default.
Merge pull request #1080 from studersi/monitoring-paranoia-levels-pat…
…ch-3

Refactor 'PARANOIA_LEVEL' to 'MONITORING_PARANOIA_LEVEL'.
@spartantri

This comment has been minimized.

Copy link
Collaborator

spartantri commented May 7, 2018

Except for the deny on 949050, it looks good to go :) 👍

@dune73

This comment has been minimized.

Copy link
Collaborator

dune73 commented May 8, 2018

You have the eyes of an eagle, @spartantri. Thank you.

Fixed.

@dune73

This comment has been minimized.

Copy link
Collaborator

dune73 commented May 8, 2018

We have an issue with this PR and rule 944400. Said PL4 rule in phase 1 changes the engine behaviour and can thus trigger new alerts at PL1 in phase 2.

A comment next to 944400 implies this rule is meant to be moved to 901. But regardless, we have constructed a behaviour change in PL4 that affects PL1 rules and this collides with this PR.

Opinions welcome.

@spartantri : Can you elaborate a bit on 944400, please?

@franbuehler

This comment has been minimized.

Copy link
Collaborator

franbuehler commented May 8, 2018

I tested this PR and it works as advertised!
This is an awesome feature!

Here are my tests:
curl http://localhost/bla?\$select

Test with a lower monitoring_paranoia_level than paranoia_level:
PL=2, monitoring PL=1:
Blocks as advertised. Good:
[2018-05-08 04:59:33.587993] [-:error] 127.0.0.1:34554 WvEutX8AAQEAAD7uVBAAAABA [client 127.0.0.1] ModSecuriy: Access denied with code 500 (phase 1). Operator LT matched 2 at TX:monitoring_paranoia_level. [file "/hom/fb/git/owasp-modsecurity-crs/rules/REQUEST-901-INITIALIZATION.conf"] [line "397"] [id "949050"] [msg "Monitring paranoia level configured is lower than the paranoia level itself. This is illegal. Blocking request. Aorting."] [hostname "localhost"] [uri "/bla"] [unique_id "WvEutX8AAQEAAD7uVBAAAABA"]

Test with PL=2, monitoring PL=2 and a high inbound threshold:
Only rules up to PL 2 are executed. Good:
[2018-05-08 05:00:52.285334] [-:error] 127.0.0.1:34558 WvEvBH8AAQEAAD@vKIgAAACD [client 127.0.0.1] ModSecurity: Warning. Pattern match "(?i:(?:^[\\\\W\\\\d]+\\\\s*?(?:alter\\\\s*(?:a(?:(?:pplication\\\\s*rol|ggregat)e|s(?:ymmetric\\\\s*ke|sembl)y|u(?:thorization|dit)|vailability\\\\s*group)|c(?:r(?:yptographic\\\\s*provider|edential)|o(?:l(?:latio|um)|nversio)n|ertificate|luster)|s(?:e(?:rv(?:ice|er)| ..." at ARGS_NAMES:$select. [file "/home/fb/git/owasp-modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "499"] [id "942360"] [rev "2"] [msg "Detects concatenated basic SQL injection and SQLLFI attempts"] [data "Matched Data: $select found within ARGS_NAMES:$select: $select"] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-sqli"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"] [hostname "localhost"] [uri "/bla"] [unique_id "WvEvBH8AAQEAAD@vKIgAAACD"]

Test with PL=2, monitoring PL=4 and a high threshold:
Rules up to PL 4 are executed. No blocking. Good:
[2018-05-08 05:02:43.752840] [-:error] 127.0.0.1:34560 WvEvc38AAQEAAEAE96YAAAAH [client 127.0.0.1] ModSecurity: Warning. Found 1 byte(s) in ARGS_NAMES:$select outside range: 38,44-46,48-58,61,65-90,95,97-122. [file "/home/fb/git/owasp-modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "1415"] [id "920273"] [rev "2"] [msg "Invalid character in request (outside of very strict set)"] [data "ARGS_NAMES:$select=$select"] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/EVASION"] [tag "paranoia-level/4"] [hostname "localhost"] [uri "/bla"] [unique_id "WvEvc38AAQEAAEAE96YAAAAH"] [2018-05-08 05:02:43.779991] [-:error] 127.0.0.1:34560 WvEvc38AAQEAAEAE96YAAAAH [client 127.0.0.1] ModSecurity: Warning. Pattern match "(?i:(?:^[\\\\W\\\\d]+\\\\s*?(?:alter\\\\s*(?:a(?:(?:pplication\\\\s*rol|ggregat)e|s(?:ymmetric\\\\s*ke|sembl)y|u(?:thorization|dit)|vailability\\\\s*group)|c(?:r(?:yptographic\\\\s*provider|edential)|o(?:l(?:latio|um)|nversio)n|ertificate|luster)|s(?:e(?:rv(?:ice|er)| ..." at ARGS_NAMES:$select. [file "/home/fb/git/owasp-modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "499"] [id "942360"] [rev "2"] [msg "Detects concatenated basic SQL injection and SQLLFI attempts"] [data "Matched Data: $select found within ARGS_NAMES:$select: $select"] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-sqli"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"] [hostname "localhost"] [uri "/bla"] [unique_id "WvEvc38AAQEAAEAE96YAAAAH"]

Test with PL=2, monitoring PL=4 and a low threshold of 1:
Rules up to 4 are executed, but Total Inbound Score is only 5. This means anomaly score from PL4 rule is not counted. Good:
[2018-05-08 05:03:40.124573] [-:error] 127.0.0.1:34562 WvEvrH8AAQEAAEBxyawAAACM [client 127.0.0.1] ModSecuri ty: Warning. Found 1 byte(s) in ARGS_NAMES:$select outside range: 38,44-46,48-58,61,65-90,95,97-122. [file " /home/fb/git/owasp-modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "1415"] [id "920273"] [rev "2"] [msg "Invalid character in request (outside of very strict set)"] [data "ARGS_NAMES:$select=$sele ct"] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [tag "application-multi"] [tag "language-multi"] [tag "pl atform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/EVASION"] [tag "paranoia-level/4"] [hostname "localhost"] [uri "/bla"] [unique_id "WvEvrH8AAQEAAEBxyawAAACM"] [2018-05-08 05:03:40.178960] [-:error] 127.0.0.1:34562 WvEvrH8AAQEAAEBxyawAAACM [client 127.0.0.1] ModSecuri ty: Warning. Pattern match "(?i:(?:^[\\\\W\\\\d]+\\\\s*?(?:alter\\\\s*(?:a(?:(?:pplication\\\\s*rol|ggregat) e|s(?:ymmetric\\\\s*ke|sembl)y|u(?:thorization|dit)|vailability\\\\s*group)|c(?:r(?:yptographic\\\\s*provide r|edential)|o(?:l(?:latio|um)|nversio)n|ertificate|luster)|s(?:e(?:rv(?:ice|er)| ..." at ARGS_NAMES:$select. [file "/home/fb/git/owasp-modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "499"] [id "942360"] [rev "2"] [msg "Detects concatenated basic SQL injection and SQLLFI attempts"] [data "Matched Dat a: $select found within ARGS_NAMES:$select: $select"] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [tag "ap plication-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-sqli"] [tag "OWASP_CRS/WEB_ATTA CK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5 .2"] [hostname "localhost"] [uri "/bla"] [unique_id "WvEvrH8AAQEAAEBxyawAAACM"] [2018-05-08 05:03:40.198793] [-:error] 127.0.0.1:34562 WvEvrH8AAQEAAEBxyawAAACM [client 127.0.0.1] ModSecuri ty: Access denied with code 403 (phase 2). Operator GE matched 1 at TX:anomaly_score. [file "/home/fb/git/ow asp-modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "97"] [id "949110"] [msg "Inbound Ano maly Score Exceeded (Total Score: 5)"] [severity "CRITICAL"] [tag "application-multi"] [tag "language-multi" ] [tag "platform-multi"] [tag "attack-generic"] [hostname "localhost"] [uri "/bla"] [unique_id "WvEvrH8AAQEA AEBxyawAAACM"] [2018-05-08 05:03:40.209917] [-:error] 127.0.0.1:34562 WvEvrH8AAQEAAEBxyawAAACM [client 127.0.0.1] ModSecuri ty: Warning. Operator GE matched 1 at TX:inbound_anomaly_score. [file "/home/fb/git/owasp-modsecurity-crs/ru les/RESPONSE-980-CORRELATION.conf"] [line "74"] [id "980130"] [msg "Inbound Anomaly Score Exceeded (Total In bound Score: 5 - SQLI=5,XSS=0,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): Detects concatenated basic SQL inject ion and SQLLFI attempts; individual paranoia level scores: 5, 0, 0, 5"] [tag "event-correlation"] [hostname "localhost"] [uri "/bla"] [unique_id "WvEvrH8AAQEAAEBxyawAAACM"]

Test with PL=2, monitoring PL=3 and a low threshold of 1:
PL4 rule 920273 is not executed. We see a PL 4 score of 0. Total Inbound Score is 5. Good. [2018-05-08 05:05:43.806648] [-:error] 127.0.0.1:34564 WvEwJ38AAQEAAEDJ4NYAAACB [client 127.0.0.1] ModSecurity: Warning. Pattern match "(?i:(?:^[\\\\W\\\\d]+\\\\s*?(?:alter\\\\s*(?:a(?:(?:pplication\\\\s*rol|ggregat)e|s(?:ymmetric\\\\s*ke|sembl)y|u(?:thorization|dit)|vailability\\\\s*group)|c(?:r(?:yptographic\\\\s*provider|edential)|o(?:l(?:latio|um)|nversio)n|ertificate|luster)|s(?:e(?:rv(?:ice|er)| ..." at ARGS_NAMES:$select. [file "/home/fb/git/owasp-modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "499"] [id "942360"] [rev "2"] [msg "Detects concatenated basic SQL injection and SQLLFI attempts"] [data "Matched Data: $select found within ARGS_NAMES:$select: $select"] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-sqli"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"] [hostname "localhost"] [uri "/bla"] [unique_id "WvEwJ38AAQEAAEDJ4NYAAACB"] [2018-05-08 05:05:43.828201] [-:error] 127.0.0.1:34564 WvEwJ38AAQEAAEDJ4NYAAACB [client 127.0.0.1] ModSecurity: Access denied with code 403 (phase 2). Operator GE matched 1 at TX:anomaly_score. [file "/home/fb/git/owasp-modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "97"] [id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [severity "CRITICAL"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "localhost"] [uri "/bla"] [unique_id "WvEwJ38AAQEAAEDJ4NYAAACB"] [2018-05-08 05:05:43.838890] [-:error] 127.0.0.1:34564 WvEwJ38AAQEAAEDJ4NYAAACB [client 127.0.0.1] ModSecurity: Warning. Operator GE matched 1 at TX:inbound_anomaly_score. [file "/home/fb/git/owasp-modsecurity-crs/rules/RESPONSE-980-CORRELATION.conf"] [line "74"] [id "980130"] [msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 5 - SQLI=5,XSS=0,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): Detects concatenated basic SQL injection and SQLLFI attempts; individual paranoia level scores: 5, 0, 0, 0"] [tag "event-correlation"] [hostname "localhost"] [uri "/bla"] [unique_id "WvEwJ38AAQEAAEDJ4NYAAACB"]

I even tested it on a real service and it worked too! This means higher paranoia levels appeared in the log!

@emphazer

This comment has been minimized.

Copy link
Collaborator

emphazer commented May 8, 2018

@dune73
i tested it on different servers and it works like a charm so far

studersi and others added some commits May 9, 2018

Merge pull request #1088 from studersi/monitoring-paranoia-levels-pat…
…ch-7

Allow paranoia level to be 0 if monitoring PL is higher.
Changing PL Score Addition to Phase 4
Changed these Actions to fill the variable tx.outbound_anomaly_score in Phase 4, because the *_plX-Variables aren't filled before that.

The way it was before, the variable would always end up being 0.

Some Credit goes to @emphazer
Merge pull request #1089 from Fungoid/patch-1
Changing PL Score Addition to Phase 4
@dune73

This comment has been minimized.

Copy link
Collaborator

dune73 commented May 15, 2018

I thought a long time about correct naming here.

Right now we use the terms Paranoia Mode and Paranoia Level. Technically, there is no Paranoia Mode, there is just a default PL and the higher PLs.

So we have the variable tx.paranoia_level. If we turn in anomaly scoring mode, then this would be the PL that affects the scoring. Like the Scoring Paranoia Level. Now we bring in the 2nd PL that affects the rules being executed, but not immediately the scoring. I've called it the Monitoring Paranoia Level, but I think it's a bad term because it implies monitoring mode despite the WAF being in blocking mode.

How about calling it the Execution Paranoia Level because the rules at this level are being executed.
We would leave tx.paranoia_level untouched, but update my PR to call the new variable tx.execution_paranoia_level and update all comments accordingly.

@spartantri

This comment has been minimized.

Copy link
Collaborator

spartantri commented May 15, 2018

Hi all,

Sorry for the delay on giving any feedback, I had several trips in America and Europe and a full agenda so I had no time to check PR's, I will try to fix the issues found by @franbuehler in 914 rules by end of week.

Rule 944400 is not java specific is something generic that's why it should be moved to 901 to my point of view. Now about the phase, as this rule is meant to check if there is already a body processor loaded and if there is none then force urlencoded as default engine and the creation of a request_body variable it is mandatory to run in phase:1. This rule is meant to execute only in PL4 because it will cause that potentially many requests that are currently ignored to be inspected.
By the way I wrote this before we had NGNIX on board so the rule have to change from using stream to request_body.

For this particular PR, what can circumvent the monitoring paranoia from executing it is modify the rule as shown in the proposed rule at the end to check if the paranoia level is set to 4 to execute BUT that will partially defeat the purpose of monitoring paranoia and you may have the surprise of additional non previously seen rules being triggered. We can create PL5 and move 944400 to 901500 which means inspect everything no matter if it is a text file which currently is a big time rule bypass if the app behind does not handle CT properly or if it get reflected back to user or somewhere else without setting it to text.

We should add a warning somewhere that the perf impact of running monitoring paranoia = 4 or paranoia = 4 are very close even in PL=1 if MPL=4.

It maybe useful for slow/old/loaded/low memory servers to add a performance booster on RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf and remove the entire PL at configuration time instead of runtime (SecRuleRemoveByTag "paranoia-level/3").

Proposed 944400 change:

# Renamed 944410 to 944400, to move to 901
SecRule REQBODY_PROCESSOR "!@rx (?:URLENCODED|MULTIPART|XML|JSON)" \
    "id:944400,\
    phase:1,\
    block,\
    t:none,t:urlDecodeUni,\
    nolog,\
    noauditlog,\
    msg:'Enabling forced body inspection for ASCII content',\
    tag:'paranoia-level/4',\
    rev:'1',\
    ver:'OWASP_CRS/3.1.0',\
    chain"
    SecRule TX:PARANOIA_LEVEL "@ge 4" "ctl:requestBodyProcessor=URLENCODED,\
        ctl:forceRequestBodyVariable=On,\
        chain"
        SecRule REQUEST_BODY "@validateByteRange 1-255"
Adding logging for monitored PLs
The Total Score Message is now logged, even if the Anomaly Score is 0, so long as any Paranoia Level that is being monitored has produced a higher score.
@dune73

This comment has been minimized.

Copy link
Collaborator

dune73 commented May 21, 2018

Hi @spartantri, thank you for your consideration. I took a lot of time to think this through. And it seems we are between a rock and a hard place with this rule 944400.

You mention that having this rule defeats the idea of the monitoring paranoia levels. The reason being it brings a change to the behavior of the engine. Enable a higher monitoring PL and you start to see new FPs at a lower PL. We can tell people in the release notes / small print of the documentation, but nobody will read it and they will bump into production problems and blame our project.

The way the rule exists now (and after your proposed update) the rule has a troubling behavior too, because you suddenly start to see alerts in lower PLs when you enable PL4. I think this should have been discussed before the merge. Sorry for not speaking up back then, I did not notice and I do not know who reviewed this formally.

The rule changes the behavior of the engine via changing the request body processor. It picks one when there is none defined. This functionality is thus very close to the ModSecurity recommended rules. I do not know how many FPs this rule brings (and I did not check), so I am unsure if it could be added to said rules by default. Alternatively, it could be added to the recommended rules in a commented out form and people would enable it when they feel like high-security. If we would follow this path, then I think our PL4 documentation should highlight this important option in the recommended rules.

If we do not want to throw it over to the ModSec project, we could also enable it via a special lever / option. It would be disabled by default. You get an option to enable it in crs-setup.conf and the PL documentation refers to this option as being important when running high security setups.

As far as I can see it is one of very few rules that introduces a state / behavior change of the engine. I like to think of CRS as body of rules that does not have any effect on rules outside CRS. Encapsulated and no unforseen side effects. "Principle of least astonishment" if you know the term.

I fear 944400 breaks with this behavior / principle.

So here are the options I see:
1 - Move rule 944400 to a new PL5 (and block "PL5" for all other use in the future. I do not like this.)
2 - Move rule 944400 to 901 under a new id and leave behavior as is.
3 - Ask ModSecurity project to take this rule into the set of recommended rules
4 - Disable the rule by default and allow to enable it via level in crs-setup.conf

None of this is ideal, I agree. Yet the rule has some merits and we need a solution. Personally, I opt to go with option 4 and trigger option 3 too. Then, a few years down the lane when people have updated their recommended rules, we remove it from CRS in favor of the recommended rules.

@spartantri: You also touch on performance on monitoring PL in the last two paragraphs of your comment. That's true and it warrants a remark in the documentation in crs-setup.conf.

@spartantri

This comment has been minimized.

Copy link
Collaborator

spartantri commented May 24, 2018

944410 could be handed to ModSec directly as this is to close a hole on the default configuration.

@spartantri
Copy link
Collaborator

spartantri left a comment

980 line 65 have tailing white spaces

"id:949050,\
phase:1,\
deny,\
status:500,\

This comment has been minimized.

@spartantri

spartantri May 24, 2018

Collaborator

Why allowing in any case to fall into an illegal state? Force it to be MPL>=PL
Then, avoid having a deny simply because a bad setting in MPL.

This comment has been minimized.

@dune73

dune73 Jun 5, 2018

Collaborator

This is gone now.

setvar:'tx.monitor_anomaly_score=+%{tx.anomaly_score_pl2}',\
setvar:'tx.monitor_anomaly_score=+%{tx.anomaly_score_pl3}',\
setvar:'tx.monitor_anomaly_score=+%{tx.anomaly_score_pl4}'"

This comment has been minimized.

@spartantri

spartantri May 24, 2018

Collaborator

This line contains spaces and makes travis to fail

This comment has been minimized.

@dune73

dune73 Jun 5, 2018

Collaborator

fixed

@dune73

This comment has been minimized.

Copy link
Collaborator

dune73 commented May 30, 2018

Solved in #1106 following the agreed resolution.

Will now contact ModSecurity about the recommended rules.

I will wait for #1106 to be merged, then update this PR including the empty spaces identified by @spartantri.

@@ -177,6 +177,28 @@ SecDefaultAction "phase:2,log,auditlog,pass"
# setvar:tx.paranoia_level=1"


# It is possible to run rules from a higher paranoia level but not include them
# in the anomaly scoring. This allows you to take a well-tuned system on
# paranoia level 1 and add rules from paranoia level 2 without having o fear

This comment has been minimized.

@fgsch

fgsch Jun 1, 2018

Collaborator

typo, o -> to

This comment has been minimized.

@dune73

dune73 Jun 5, 2018

Collaborator

fixed

@spartantri

This comment has been minimized.

Copy link
Collaborator

spartantri commented Jun 4, 2018

What about?

Previous comments on performance?
@spartantri "It maybe useful for slow/old/loaded/low memory servers to add a performance booster on RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf and remove the entire PL at configuration time instead of runtime (SecRuleRemoveByTag "paranoia-level/3")."
@dune73 "You also touch on performance on monitoring PL in the last two paragraphs of your comment. That's true and it warrants a remark in the documentation in crs-setup.conf."

@dune73

This comment has been minimized.

Copy link
Collaborator

dune73 commented Jun 5, 2018

I've done several updates:

  • Fixed typos and trailing whitespace
  • Changed name of feature (incl. all variables) from 'monitoring PL' to 'executing PL'. I think this is not perfect but definitely clearer. It is based on the idea to have an executing PL that defines which rules are actually being executed. And a (scoring) PL that defines which rules are used in the anomaly score. Executing PL is equal or greater to (scoring) PL.
  • Removed a FIXME that was no longer needed
  • Resolved a conflict after recent introduction of new rule into 933
  • Added a comment about performance as per @spartantri's request

What I do not get is @spartantri's proposal to suggest adding SecRuleRemoveByTag "paranoia-level/3" into RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf to tackle performance issues. What's the point of raising the executing PL and then removing the rules?

Other than that, I think this PR is ready for a final review and hopefully a merge.

dune73 added some commits Jun 5, 2018

@spartantri

This comment has been minimized.

Copy link
Collaborator

spartantri commented Jun 7, 2018

Looks good, I will do some tests sending several 100'sK requests but this is working fine so far.

@csanders-git

This comment has been minimized.

Copy link
Collaborator

csanders-git commented Jul 4, 2018

I did a bit of testing with this last night and it's working as expected. Nice job. I ran through a good bunch of requests ~10K

This was fixed it seems

@csanders-git

This comment has been minimized.

Copy link
Collaborator

csanders-git commented Jul 7, 2018

merged after IIS changes seems to have checked not sure what conflicts are but once they're fixed it can be merged. can you take a look @dune73

@csanders-git

This comment has been minimized.

Copy link
Collaborator

csanders-git commented Jul 10, 2018

@dune73 fix conflicts then ready to merge.

@dune73

This comment has been minimized.

Copy link
Collaborator

dune73 commented Jul 10, 2018

Conflict resolved.

@csanders-git csanders-git merged commit 397b6b1 into v3.1/dev Jul 12, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@csanders-git csanders-git deleted the monitoring-paranoia-levels branch Jul 12, 2018

@dune73

This comment has been minimized.

Copy link
Collaborator

dune73 commented Jul 12, 2018

Thank you for merging.

cPanelScott added a commit to cPanelScott/owasp-modsecurity-crs that referenced this pull request Jul 23, 2018

Introducing an additional monitoring or hybrid paranoia level setting (
…SpiderLabs#1076)

* Introducing an additional monitoring or hybrid paranoia level setting
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment