Including CRS inside Location/If directive doesn't work

107 views
Skip to first unread message

Sudharshan K S

unread,
Mar 5, 2024, 11:55:21 AMMar 5
to modsecurity-core...@owasp.org
Hi team,

I'm using CRS v3.3.2 with ModSecurity v2.9.3 and Apache v2.4.41.

I've tried including CRS configuration and rules (i.e., Include /path/to/crs-setup.conf; Include /path/to/coreruleset/rules/*.conf) inside a vhost and it functions as expected.

Now, I'm experimenting to include the CRS configuration and the rules inside a Location and If directives. I ran into a few issues related to the directives SecGeoLookupDB and SecComponentSignature as they don't support Location/If scopes. I've moved them to the global scope. After which when I run the apache2ctl -t, it doesn't report any errors and apache starts successfully. But, I see that the functionality is broken, and all the requests even the malformed ones pass through. Specifically,  I observed that the variables related to anomaly scores(maybe others too) are not getting initialized.

The following are the test cases, 
Case 1:
vhost - example1.com --- use ruleset R1
vhost - example2.com --- use ruleset R2

Case 2:
vhost - example1.com
                  --- for /path1/* - Use ruleset R1
                  --- for /path2/* - Use ruleset R2
Note: Case 1 works as expected while in Case 2 the WAF functionality fails.  

The following is the apache configuration snippet for Case 2
```
<Location "/path1/">
        Include    /path/to/R1/coreruleset/crs-setup.conf
        Include    /path/to/R1/coreruleset/coreruleset/rules/*.conf
        ProxyPass           http://localhost:8000/
        ProxyPassReverse    http://localhost:8000/
</Location>

<Location "/path2/">
        Include    /path/to/R2/coreruleset/crs-setup.conf
        Include    /path/to/R2/coreruleset/coreruleset/rules/*.conf
        ProxyPass           http://localhost:8001/
        ProxyPassReverse    http://localhost:8001/
</Location>
```

Logs for Case 2:
To test Case 2, the apache configuration was set up as shown above. The allowed method was set to POST in the R1 CRS ruleset. A GET request was sent which should've ideally been blocked by Modsec. The error logs are written stating that the request method is not allowed but the response was sent back with a 200 status code instead of 403. The Rule engine was in the block mode (On) throughout.

Here are the logs. Please notice that the Anamoly score is empty.

Error Logs
```
example1.com [2024-03-05 15:40:01.239039] [-:error] 127.0.0.1:54860 Zebveaqkyd1jeHzTAI5-jgAAABY [client 127.0.0.1] ModSecurity: Warning. Match of "within %{tx.allowed_methods}" against "REQUEST_METHOD" required. [file "/path/to/R1/coreruleset/rules/REQUEST-911-METHOD-ENFORCEMENT.conf"] [line "43"] [id "911100"] [msg "Method is not allowed by policy. Anamoly score = "] [data "GET"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.2"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/210/272/220/274"] [tag "PCI/12.1"] [hostname "example1.com"] [uri "/path1/"] [unique_id "Zebveaqkyd1jeHzTAI5-jgAAABY"]
```

Debug logs
```
<...snip...>
[01/Mar/2024:13:03:56 +0530] [example1.com/sid#7f53a23373b8][rid#7f53a7b4b0a0][/path1/][4] Recipe: Invoking rule 7f53a4003198; [file "/path/to/R1/coreruleset/rules/REQUEST-911-METHOD-ENFORCEMENT.conf"] [line "43"] [id "911100"].
[01/Mar/2024:13:03:56 +0530] [example1.com/sid#7f53a23373b8][rid#7f53a7b4b0a0][/path1/][5] Rule 7f53a4003198: SecRule "REQUEST_METHOD" "!@within %{tx.allowed_methods}" "phase:2,log,auditlog,id:911100,block,msg:'Method is not allowed by policy',logdata:%{MATCHED_VAR},tag:application-multi,tag:language-multi,tag:platform-multi,tag:attack-generic,tag:paranoia-level/1,tag:OWASP_CRS,tag:capec/1000/210/272/220/274,tag:PCI/12.1,ver:OWASP_CRS/3.3.2,severity:CRITICAL,setvar:tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}"
[01/Mar/2024:13:03:56 +0530] [example1.com/sid#7f53a23373b8][rid#7f53a7b4b0a0][/path1/][4] Transformation completed in 1 usec.
[01/Mar/2024:13:03:56 +0530] [example1.com/sid#7f53a23373b8][rid#7f53a7b4b0a0][/path1/][4] Executing operator "!within" with param "%{tx.allowed_methods}" against REQUEST_METHOD.
[01/Mar/2024:13:03:56 +0530] [example1.com/sid#7f53a23373b8][rid#7f53a7b4b0a0][/path1/][9] Target value: "GET"
[01/Mar/2024:13:03:56 +0530] [example1.com/sid#7f53a23373b8][rid#7f53a7b4b0a0][/path1/][4] Operator completed in 5 usec.
[01/Mar/2024:13:03:56 +0530] [example1.com/sid#7f53a23373b8][rid#7f53a7b4b0a0][/path1/][9] Setting variable: tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}
[01/Mar/2024:13:03:56 +0530] [example1.com/sid#7f53a23373b8][rid#7f53a7b4b0a0][/path1/][9] Recorded original collection variable: tx.anomaly_score_pl1 = "0"
[01/Mar/2024:13:03:56 +0530] [example1.com/sid#7f53a23373b8][rid#7f53a7b4b0a0][/path1/][9] Relative change: anomaly_score_pl1=0+
[01/Mar/2024:13:03:56 +0530] [example1.com/sid#7f53a23373b8][rid#7f53a7b4b0a0][/path1/][9] Set variable "tx.anomaly_score_pl1" to "0".
[01/Mar/2024:13:03:56 +0530] [example1.com/sid#7f53a23373b8][rid#7f53a7b4b0a0][/path1/][9] Resolved macro %{MATCHED_VAR} to: GET
[01/Mar/2024:13:03:56 +0530] [example1.com/sid#7f53a23373b8][rid#7f53a7b4b0a0][/path1/][2] Warning. Match of "within %{tx.allowed_methods}" against "REQUEST_METHOD" required. [file "/path/to/R1/coreruleset/rules/REQUEST-911-METHOD-ENFORCEMENT.conf"] [line "43"] [id "911100"] [msg "Method is not allowed by policy"] [data "GET"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.2"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/210/272/220/274"] [tag "PCI/12.1"]
[01/Mar/2024:13:03:56 +0530] [example1.com/sid#7f53a23373b8][rid#7f53a7b4b0a0][/path1/][4] Rule returned 1.
<...snip...>
```
I also noticed that the variable tx.critical_anomaly_score is not getting initialized at all.

Please let me know what I'm missing here. 

Thanks in advance. 

Regards
Sudharshan K S

Jozef Sudolsky

unread,
Mar 5, 2024, 2:17:43 PMMar 5
to modsecurity-core...@owasp.org
Hi Sudharshan,

it looks really odd. Can you show full debug log so we can see also
initialization of variables? Thank you.

azurit





Citát Sudharshan K S <kssudhar...@gmail.com>:

> Hi team,
>
> I'm using CRS v3.3.2 with ModSecurity v2.9.3 and Apache v2.4.41.
>
> I've tried including CRS configuration and rules (i.e., Include
> /path/to/crs-setup.conf; Include /path/to/coreruleset/rules/*.conf) inside
> a vhost and it functions as expected.
>
> Now, I'm experimenting to include the CRS configuration and the rules
> inside a Location and If directives. I ran into a few issues related to the
> directives SecGeoLookupDB and SecComponentSignature as they don't support
> Location/If scopes. I've moved them to the global scope. After which when I
> run the *apache2ctl -t*, it doesn't report any errors and apache starts
> successfully. But, I see that the functionality is broken, and all the
> requests even the malformed ones pass through. Specifically, I observed
> that the variables related to anomaly scores(maybe others too) are not
> getting initialized.
>
> The following are the test cases,
> *Case 1:*
> vhost - example1.com --- use ruleset R1
> vhost - example2.com --- use ruleset R2
>
> *Case 2:*
> vhost - example1.com
> --- for /path1/* - Use ruleset R1
> --- for /path2/* - Use ruleset R2
> *Note:* *Case 1 works as expected while in Case 2 the WAF functionality
> fails*.
>
> The following is the *apache* *configuration* snippet for Case 2
> ```
>
>
>
>
>
>
>
>
>
>
>
>
> *<Location "/path1/"> Include
> /path/to/R1/coreruleset/crs-setup.conf Include
> /path/to/R1/coreruleset/coreruleset/rules/*.conf ProxyPass
> http://localhost:8000/ <http://localhost:8000/> ProxyPassReverse
> http://localhost:8000/ <http://localhost:8000/></Location><Location
> "/path2/"> Include /path/to/R2/coreruleset/crs-setup.conf
> Include /path/to/R2/coreruleset/coreruleset/rules/*.conf
> ProxyPass http://localhost:8001/ <http://localhost:8001/>
> ProxyPassReverse http://localhost:8001/
> <http://localhost:8001/></Location>*
> ```
>
> *Logs for Case 2:*
> To test Case 2, the apache configuration was set up as shown above. The
> allowed method was set to POST in the R1 CRS ruleset. A GET request was
> sent which should've ideally been blocked by Modsec. The error logs are
> written stating that the request method is not allowed but the response was
> sent back with a 200 status code instead of 403. The Rule engine was in the
> block mode (On) throughout.
>
> Here are the logs. Please notice that the Anamoly score is empty.
>
> *Error Logs*
> ```
> *example1.com <http://example1.com/> [2024-03-05 15:40:01.239039]
> [-:error] 127.0.0.1:54860
> <http://127.0.0.1:54860/> Zebveaqkyd1jeHzTAI5-jgAAABY [client 127.0.0.1]
> ModSecurity: Warning. Match of "within %{tx.allowed_methods}" against
> "REQUEST_METHOD" required. [file
> "/path/to/R1/coreruleset/rules/REQUEST-911-METHOD-ENFORCEMENT.conf"] [line
> "43"] [id "911100"] [msg "Method is not allowed by policy. Anamoly score =
> "] [data "GET"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.2"] [tag
> "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag
> "attack-generic"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag
> "capec/1000/210/272/220/274"] [tag "PCI/12.1"] [hostname "example1.com
> <http://example1.com/>"] [uri "/path1/"] [unique_id
> "Zebveaqkyd1jeHzTAI5-jgAAABY"]*
> ```
>
> *Debug logs*
> ```
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *<...snip...>[01/Mar/2024:13:03:56 +0530]
> [example1.com/sid#7f53a23373b8][rid#7f53a7b4b0a0][/path1/][4
> <http://example1.com/sid#7f53a23373b8][rid%237f53a7b4b0a0][/path1/][4>]
> Recipe: Invoking rule 7f53a4003198; [file
> "/path/to/R1/coreruleset/rules/REQUEST-911-METHOD-ENFORCEMENT.conf"] [line
> "43"] [id "911100"].[01/Mar/2024:13:03:56 +0530]
> [example1.com/sid#7f53a23373b8][rid#7f53a7b4b0a0][/path1/][5
> <http://example1.com/sid#7f53a23373b8][rid%237f53a7b4b0a0][/path1/][5>]
> Rule 7f53a4003198: SecRule "REQUEST_METHOD" "!@within
> %{tx.allowed_methods}" "phase:2,log,auditlog,id:911100,block,msg:'Method is
> not allowed by
> policy',logdata:%{MATCHED_VAR},tag:application-multi,tag:language-multi,tag:platform-multi,tag:attack-generic,tag:paranoia-level/1,tag:OWASP_CRS,tag:capec/1000/210/272/220/274,tag:PCI/12.1,ver:OWASP_CRS/3.3.2,severity:CRITICAL,setvar:tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}"[01/Mar/2024:13:03:56
> +0530] [example1.com/sid#7f53a23373b8][rid#7f53a7b4b0a0][/path1/][4
> <http://example1.com/sid#7f53a23373b8][rid%237f53a7b4b0a0][/path1/][4>]
> Transformation completed in 1 usec.[01/Mar/2024:13:03:56 +0530]
> [example1.com/sid#7f53a23373b8][rid#7f53a7b4b0a0][/path1/][4
> <http://example1.com/sid#7f53a23373b8][rid%237f53a7b4b0a0][/path1/][4>]
> Executing operator "!within" with param "%{tx.allowed_methods}" against
> REQUEST_METHOD.[01/Mar/2024:13:03:56 +0530]
> [example1.com/sid#7f53a23373b8][rid#7f53a7b4b0a0][/path1/][9
> <http://example1.com/sid#7f53a23373b8][rid%237f53a7b4b0a0][/path1/][9>]
> Target value: "GET"[01/Mar/2024:13:03:56 +0530]
> [example1.com/sid#7f53a23373b8][rid#7f53a7b4b0a0][/path1/][4
> <http://example1.com/sid#7f53a23373b8][rid%237f53a7b4b0a0][/path1/][4>]
> Operator completed in 5 usec.[01/Mar/2024:13:03:56 +0530]
> [example1.com/sid#7f53a23373b8][rid#7f53a7b4b0a0][/path1/][9
> <http://example1.com/sid#7f53a23373b8][rid%237f53a7b4b0a0][/path1/][9>]
> Setting variable:
> tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}[01/Mar/2024:13:03:56
> +0530] [example1.com/sid#7f53a23373b8][rid#7f53a7b4b0a0][/path1/][9
> <http://example1.com/sid#7f53a23373b8][rid%237f53a7b4b0a0][/path1/][9>]
> Recorded original collection variable: tx.anomaly_score_pl1 =
> "0"[01/Mar/2024:13:03:56 +0530]
> [example1.com/sid#7f53a23373b8][rid#7f53a7b4b0a0][/path1/][9
> <http://example1.com/sid#7f53a23373b8][rid%237f53a7b4b0a0][/path1/][9>]
> Relative
> change: anomaly_score_pl1=0+[01/Mar/2024:13:03:56 +0530]
> [example1.com/sid#7f53a23373b8][rid#7f53a7b4b0a0][/path1/][9
> <http://example1.com/sid#7f53a23373b8][rid%237f53a7b4b0a0][/path1/][9>] Set
> variable "tx.anomaly_score_pl1" to "0".[01/Mar/2024:13:03:56 +0530]
> [example1.com/sid#7f53a23373b8][rid#7f53a7b4b0a0][/path1/][9
> <http://example1.com/sid#7f53a23373b8][rid%237f53a7b4b0a0][/path1/][9>]
> Resolved macro %{MATCHED_VAR} to: GET[01/Mar/2024:13:03:56 +0530]
> [example1.com/sid#7f53a23373b8][rid#7f53a7b4b0a0][/path1/][2
> <http://example1.com/sid#7f53a23373b8][rid%237f53a7b4b0a0][/path1/][2>]
> Warning. Match of "within %{tx.allowed_methods}" against "REQUEST_METHOD"
> required. [file
> "/path/to/R1/coreruleset/rules/REQUEST-911-METHOD-ENFORCEMENT.conf"] [line
> "43"] [id "911100"] [msg "Method is not allowed by policy"] [data "GET"]
> [severity "CRITICAL"] [ver "OWASP_CRS/3.3.2"] [tag "application-multi"]
> [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [tag
> "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/210/272/220/274"]
> [tag "PCI/12.1"][01/Mar/2024:13:03:56 +0530]
> [example1.com/sid#7f53a23373b8][rid#7f53a7b4b0a0][/path1/][4
> <http://example1.com/sid#7f53a23373b8][rid%237f53a7b4b0a0][/path1/][4>]
> Rule returned 1.<...snip...>*
> ```
> I also noticed that the variable *tx.critical_anomaly_score* is not getting
> initialized at all.
>
> Please let me know what I'm missing here.
>
> Thanks in advance.
>
> Regards
> Sudharshan K S
>
> --
> You received this message because you are subscribed to the Google
> Groups "ModSecurity Core Rule Set project" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to
> modsecurity-core-rule-...@owasp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/owasp.org/d/msgid/modsecurity-core-rule-set-project/CAKtqziMPdOTatHGdv2M0OpRQMuB%3DS-6Ydm9AAjJYnokhKivnQQ%40mail.gmail.com.



Andrew Howe

unread,
Mar 5, 2024, 2:49:56 PMMar 5
to ModSecurity Core Rule Set project, Sudharshan K S
Hi Sudharshan,

> I'm using CRS v3.3.2 with ModSecurity v2.9.3 and Apache v2.4.41.

It should be highlighted that those are all really quite old versions of their respective projects.

**All of those release versions contain known and published security vulnerabilities.**

Possibly this is just a test WAF / toy WAF, but even then you should at least consider using the latest supported CRS version from the v3 line (v3.3.5). We've squashed many bugs since 3.3.2.

Thanks,
Andrew

Sudharshan K S

unread,
Mar 7, 2024, 1:01:25 PMMar 7
to Andrew Howe, jo...@sudolsky.sk, ModSecurity Core Rule Set project
Hi Andrew,
Thanks for your valuable suggestion. I've upgraded to CRS v3.3.5 with Modsec v2.9.7 and Apache 2.4.52. I see that the issue persists.

Hi Jozef,
I'm attaching the debug logs for both the test cases with the upgraded versions. There was no difference in the logs between the older and the upgraded versions. 
The files modsec_debug_case1.log and modsec_debug_case2.log are for Cases 1 and 2 described above, respectively.

Please let me know if any more information is needed.

Regards
Sudharshan K S

modsec_debug_case1.log
modsec_debug_case2.log

Jozef Sudolsky

unread,
Mar 7, 2024, 2:21:31 PMMar 7
to modsecurity-core...@owasp.org
Hi Sudharshan,

file /path/to/R1/coreruleset/crs-setup.conf is simply not included in
case 2. Try these:

- Double check permissions i.e. that Apache is able to read
/path/to/R1/coreruleset/crs-setup.conf also outside of VirtualHost
directive (for example if vhost is running under different system user
than base Apache).
- Turn on debug logging in Apache and check logs.
- Try putting your Location under the VirtualHost from case 1 and
report back.

Jozef



Citát Sudharshan K S <kssudhar...@gmail.com>:

> Hi Andrew,
> Thanks for your valuable suggestion. I've upgraded to CRS v3.3.5 with
> Modsec v2.9.7 and Apache 2.4.52. I see that the issue persists.
>
> Hi Jozef,
> I'm attaching the debug logs for both the test cases with the upgraded
> versions. There was no difference in the logs between the older and the
> upgraded versions.
> The files *modsec_debug_case1.log and **modsec_debug_case2.log** are* for
> Cases 1 and 2 described *above, respectively.*
>
> Please let me know if any more information is needed.
>
> Regards
> Sudharshan K S
>
>
> On Wed, Mar 6, 2024 at 1:19 AM Andrew Howe <andre...@owasp.org> wrote:
>
>> Hi Sudharshan,
>>
>> > I'm using CRS v3.3.2 with ModSecurity v2.9.3 and Apache v2.4.41.
>>
>> It should be highlighted that those are all really quite old versions of
>> their respective projects.
>>
>> **All of those release versions contain known and published security
>> vulnerabilities.**
>>
>> Possibly this is just a test WAF / toy WAF, but even then you should at
>> least consider using the latest supported CRS version from the v3 line
>> (v3.3.5). We've squashed many bugs since 3.3.2.
>>
>> Thanks,
>> Andrew
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "ModSecurity Core Rule Set project" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to
> modsecurity-core-rule-...@owasp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/owasp.org/d/msgid/modsecurity-core-rule-set-project/CAKtqziMfuMspoZ_rtDG5%2B_3EnVrjeBNKGtRkEYcUnHtfhDGQ9g%40mail.gmail.com.



Sudharshan K S

unread,
Mar 13, 2024, 2:54:30 PMMar 13
to Jozef Sudolsky, modsecurity-core...@owasp.org
Hi Jozef,

I've tried the suggested steps
  1. Apache has permissions to read `/path/to/R1/coreruleset/crs-setup.conf`
  2. The inclusion of `/path/to/R1/coreruleset/crs-setup.conf ` was tried out outside the vhost context. This works as expected. (Will refer to this as Case 3 henceforth)
  3. The inclusion of `/path/to/R1/coreruleset/crs-setup.conf ` was tried out outside the vhost context, but inside the Location context. This doesn't work (Will refer to this as Case 4 henceforth). The results are similar to Case 2.
  4. Apache debug log level was set to trace8 and nothing interesting/relevant was found related to the inclusion of these configuration files. 
  5. The modsecurity debug logs for Case 3 and Case 4 are similar to Case 1 and Case 2 respectively. 
Observation: The inclusion of crs-setup.conf and the other rules doesn't work inside the Location context irrespective of its position w.r.t vhost.  

Let me know if sharing the vhost configurations will help. 

Regards
Sudharshan K S


To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/modsecurity-core-rule-set-project/20240307202128.Horde.fQr3QFGSGxvF4-iRZKfA-xa%40webmail.inetadmin.eu.

Jozef Sudolsky

unread,
Mar 15, 2024, 4:34:38 AMMar 15
to modsecurity-core...@owasp.org
Sorry, i'm out of ideas. File crs-setup.conf is simply not loaded
according to modsec debug log, but other files are loaded ok, so
including itself works. The 'Include' directive fill fail with an
error is file doesn't exists BUT will NOT fail if file exists but
cannot be read (for example because of permissions). This means:

1.) File /path/to/R1/coreruleset/crs-setup.conf exists.
2.) Apache is probably, for some reason, not able to read.

Jozef





Citát Sudharshan K S <kssudhar...@gmail.com>:

> Hi Jozef,
>
> I've tried the suggested steps
>
> 1. Apache has permissions to read `
> */path/to/R1/coreruleset/crs-setup.conf`*
> 2. The inclusion of* `**/path/to/R1/coreruleset/crs-setup.conf ` *was
> tried out outside the *vhost* context. This works as expected. (Will
> refer to this as Case 3 henceforth)
> 3. The inclusion of* `**/path/to/R1/coreruleset/crs-setup.conf ` *was
> tried out outside the *vhost* context, but inside the *Location *context.
> This doesn't work (Will refer to this as Case 4 henceforth). The results
> are similar to Case 2.
> 4. Apache debug log level was set to trace8 and nothing
> interesting/relevant was found related to the inclusion of these
> configuration files.
> 5. The modsecurity debug logs for Case 3 and Case 4 are similar to Case
> 1 and Case 2 respectively.
>
> *Observation: The inclusion of crs-setup.conf and the other rules doesn't
> work inside the Location context irrespective of its position w.r.t vhost. *
>> https://groups.google.com/a/owasp.org/d/msgid/modsecurity-core-rule-set-project/20240307202128.Horde.fQr3QFGSGxvF4-iRZKfA-xa%40webmail.inetadmin.eu
>> .
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "ModSecurity Core Rule Set project" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to
> modsecurity-core-rule-...@owasp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/owasp.org/d/msgid/modsecurity-core-rule-set-project/CAKtqziPqkoZ3%3Dfp_sa-BqqkcCRQ9Hdz_g-AqkSDD-RfTy_5eDQ%40mail.gmail.com.



Andrew Howe

unread,
Mar 16, 2024, 1:58:24 PMMar 16
to Sudharshan K S, modsecurity-core...@owasp.org
Hi Sudharshan,

> Observation: The inclusion of crs-setup.conf and the other rules doesn't work inside the Location context irrespective of its position w.r.t vhost.

That looks correct.

<Location> directives can be very powerful, *however*, they don't play
nicely with phase 1 rules. Phase 1 takes place early on, *before*
<Location> directives are evaluated. To quote the ModSecurity
Handbook: "Any phase 1 rules placed in <Location> will be ignored
silently."
(If you're operating ModSecurity in a serious capacity then the
Handbook is a must-read.)

If you're putting the entirety of CRS inside a <Location> container
then, I think, absolutely none of the variable initialisation work
will take place.

Consider 'Include'-ing your main rule set in either the main
configuration context or in a <VirtualHost> container. Then, you can
optionally use <Location> directives to create location-specific
configuration/overrides, e.g. rule exclusions for specific parts of
your web application.

Thanks,
Andrew
Reply all
Reply to author
Forward
0 new messages