Thread: [mod-security-users] crs ruleset and trace method?
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
mod-security-users
|
From: Eero V. <eer...@ik...> - 2018-03-21 07:16:02
|
Hi, Just noticed that crs ruleset is not blocking trace method, even setvar:'tx.allowed_methods=GET POST'" Is this a bug? Eero |
|
From: Christian F. <chr...@ne...> - 2018-03-21 09:53:23
|
Hey Eero, The TRACE method is somewhat special. At least in Apache. The request skips phase 2 and thus the CRS rule covering tx.allowed_methods. There are discussions to move this block of rules to phase 1 though. https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1015 You may want to chime in there. Ahoj, Christian On Wed, Mar 21, 2018 at 09:15:52AM +0200, Eero Volotinen wrote: > Hi, > > Just noticed that crs ruleset is not blocking trace method, even > setvar:'tx.allowed_methods=GET POST'" > > Is this a bug? > > Eero > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > http://www.modsecurity.org/projects/commercial/rules/ > http://www.modsecurity.org/projects/commercial/support/ -- https://www.feistyduck.com/training/modsecurity-training-course https://www.feistyduck.com/books/modsecurity-handbook/ mailto:chr...@ne... twitter: @ChrFolini |
|
From: Eero V. <eer...@ik...> - 2018-03-21 10:11:32
|
Not enought familiar with modsecurity. Just wondering, that there is no any rule to block trace in crs. is there easy way to implement that? -- Eero On Wed, Mar 21, 2018 at 11:53 AM, Christian Folini < chr...@ne...> wrote: > Hey Eero, > > The TRACE method is somewhat special. At least in Apache. The request > skips phase 2 and thus the CRS rule covering tx.allowed_methods. > > There are discussions to move this block of rules to phase 1 though. > https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1015 > > You may want to chime in there. > > Ahoj, > > Christian > > On Wed, Mar 21, 2018 at 09:15:52AM +0200, Eero Volotinen wrote: > > Hi, > > > > Just noticed that crs ruleset is not blocking trace method, even > > setvar:'tx.allowed_methods=GET POST'" > > > > Is this a bug? > > > > Eero > > > ------------------------------------------------------------ > ------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > > mod-security-users mailing list > > mod...@li... > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > > http://www.modsecurity.org/projects/commercial/rules/ > > http://www.modsecurity.org/projects/commercial/support/ > > > -- > https://www.feistyduck.com/training/modsecurity-training-course > https://www.feistyduck.com/books/modsecurity-handbook/ > mailto:chr...@ne... > twitter: @ChrFolini > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > http://www.modsecurity.org/projects/commercial/rules/ > http://www.modsecurity.org/projects/commercial/support/ > |
|
From: Osama E. <oel...@gm...> - 2018-03-21 10:21:04
|
For Apache 2, add the following to Apache’s configuration: TraceEnable Off nginx: use limit_except - https://nginx.org/en/docs/http/ngx_http_core_module.html#limit_except -- Osama Elnaggar On March 21, 2018 at 9:13:52 PM, Eero Volotinen (eer...@ik...) wrote: Not enought familiar with modsecurity. Just wondering, that there is no any rule to block trace in crs. is there easy way to implement that? -- Eero On Wed, Mar 21, 2018 at 11:53 AM, Christian Folini < chr...@ne...> wrote: > Hey Eero, > > The TRACE method is somewhat special. At least in Apache. The request > skips phase 2 and thus the CRS rule covering tx.allowed_methods. > > There are discussions to move this block of rules to phase 1 though. > https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1015 > > You may want to chime in there. > > Ahoj, > > Christian > > On Wed, Mar 21, 2018 at 09:15:52AM +0200, Eero Volotinen wrote: > > Hi, > > > > Just noticed that crs ruleset is not blocking trace method, even > > setvar:'tx.allowed_methods=GET POST'" > > > > Is this a bug? > > > > Eero > > > ------------------------------------------------------------ > ------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > > mod-security-users mailing list > > mod...@li... > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > > http://www.modsecurity.org/projects/commercial/rules/ > > http://www.modsecurity.org/projects/commercial/support/ > > > -- > https://www.feistyduck.com/training/modsecurity-training-course > https://www.feistyduck.com/books/modsecurity-handbook/ > mailto:chr...@ne... > twitter: @ChrFolini > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > http://www.modsecurity.org/projects/commercial/rules/ > http://www.modsecurity.org/projects/commercial/support/ > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ mod-security-users mailing list mod...@li... https://lists.sourceforge.net/lists/listinfo/mod-security-users Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: http://www.modsecurity.org/projects/commercial/rules/ http://www.modsecurity.org/projects/commercial/support/ |
|
From: Christian F. <chr...@ne...> - 2018-03-21 10:25:20
|
Hello Eero, On Wed, Mar 21, 2018 at 12:11:15PM +0200, Eero Volotinen wrote: > Just wondering, that there is no any rule to block trace in crs. is there > easy way to implement that? You can blog TRACE in 3 ways in Apache: - TraceEnable Off (-> This is the default in 2.4) - mod_allowmethods (never did this with TRACE. Maybe it has special treatment. better check.) - Write ModSec Rule in phase 1 (Take existing CRS rule as a base or look at ModSec integration tutorial at netnea.com and take the method check in the whitelisting example) Cheers, Christian > > -- > Eero > > On Wed, Mar 21, 2018 at 11:53 AM, Christian Folini < > chr...@ne...> wrote: > > > Hey Eero, > > > > The TRACE method is somewhat special. At least in Apache. The request > > skips phase 2 and thus the CRS rule covering tx.allowed_methods. > > > > There are discussions to move this block of rules to phase 1 though. > > https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1015 > > > > You may want to chime in there. > > > > Ahoj, > > > > Christian > > > > On Wed, Mar 21, 2018 at 09:15:52AM +0200, Eero Volotinen wrote: > > > Hi, > > > > > > Just noticed that crs ruleset is not blocking trace method, even > > > setvar:'tx.allowed_methods=GET POST'" > > > > > > Is this a bug? > > > > > > Eero > > > > > ------------------------------------------------------------ > > ------------------ > > > Check out the vibrant tech community on one of the world's most > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > > _______________________________________________ > > > mod-security-users mailing list > > > mod...@li... > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > > > http://www.modsecurity.org/projects/commercial/rules/ > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > -- > > https://www.feistyduck.com/training/modsecurity-training-course > > https://www.feistyduck.com/books/modsecurity-handbook/ > > mailto:chr...@ne... > > twitter: @ChrFolini > > > > ------------------------------------------------------------ > > ------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > mod-security-users mailing list > > mod...@li... > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > > http://www.modsecurity.org/projects/commercial/rules/ > > http://www.modsecurity.org/projects/commercial/support/ > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > http://www.modsecurity.org/projects/commercial/rules/ > http://www.modsecurity.org/projects/commercial/support/ -- https://www.feistyduck.com/training/modsecurity-training-course https://www.feistyduck.com/books/modsecurity-handbook/ mailto:chr...@ne... twitter: @ChrFolini |
|
From: Reindl H. <h.r...@th...> - 2018-03-21 10:25:34
|
Am 21.03.2018 um 11:11 schrieb Eero Volotinen: > Not enought familiar with modsecurity. > > Just wondering, that there is no any rule to block trace in crs. is > there easy way to implement that? why would someone do that when you can and should disable it entirely on your webserver? i guess you are coming from OpenVAS warnings but then also search for options to disable thins proper instead burry them within a firewall layer [root@srv-rhsoft:~]$ cat conf/httpd-core.conf | grep Trace TraceEnable Off > On Wed, Mar 21, 2018 at 11:53 AM, Christian Folini > <chr...@ne... <mailto:chr...@ne...>> wrote: > > Hey Eero, > > The TRACE method is somewhat special. At least in Apache. The request > skips phase 2 and thus the CRS rule covering tx.allowed_methods. > > There are discussions to move this block of rules to phase 1 though. > https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1015 > <https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1015> > > You may want to chime in there. > > Ahoj, > > Christian > > On Wed, Mar 21, 2018 at 09:15:52AM +0200, Eero Volotinen wrote: > > Hi, > > > > Just noticed that crs ruleset is not blocking trace method, even > > setvar:'tx.allowed_methods=GET POST'" > > > > Is this a bug? |
|
From: Eero V. <eer...@ik...> - 2018-03-21 10:50:29
|
Well, Maybe it's time to fix documentation: # HTTP methods that a client is allowed to use. # Default: GET HEAD POST OPTIONS # Example: for RESTful APIs, add the following methods: PUT PATCH DELETE # Example: for WebDAV, add the following methods: CHECKOUT COPY DELETE LOCK # MERGE MKACTIVITY MKCOL MOVE PROPFIND PROPPATCH PUT UNLOCK # Uncomment this rule to change the default. SecAction \ "id:900200,\ phase:1,\ nolog,\ pass,\ t:none,\ setvar:'tx.allowed_methods=GET POST'" It's not working as expected. How about saying that rules is not blocking trace method? Eero On Wed, Mar 21, 2018 at 12:25 PM, Reindl Harald <h.r...@th...> wrote: > > > Am 21.03.2018 um 11:11 schrieb Eero Volotinen: > >> Not enought familiar with modsecurity. >> >> Just wondering, that there is no any rule to block trace in crs. is there >> easy way to implement that? >> > > why would someone do that when you can and should disable it entirely on > your webserver? i guess you are coming from OpenVAS warnings but then also > search for options to disable thins proper instead burry them within a > firewall layer > > [root@srv-rhsoft:~]$ cat conf/httpd-core.conf | grep Trace > TraceEnable Off > > On Wed, Mar 21, 2018 at 11:53 AM, Christian Folini < >> chr...@ne... <mailto:chr...@ne...>> wrote: >> >> Hey Eero, >> >> The TRACE method is somewhat special. At least in Apache. The request >> skips phase 2 and thus the CRS rule covering tx.allowed_methods. >> >> There are discussions to move this block of rules to phase 1 though. >> https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1015 >> <https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1015> >> >> You may want to chime in there. >> >> Ahoj, >> >> Christian >> >> On Wed, Mar 21, 2018 at 09:15:52AM +0200, Eero Volotinen wrote: >> > Hi, >> > >> > Just noticed that crs ruleset is not blocking trace method, even >> > setvar:'tx.allowed_methods=GET POST'" >> > >> > Is this a bug? >> > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > http://www.modsecurity.org/projects/commercial/rules/ > http://www.modsecurity.org/projects/commercial/support/ > |
|
From: Christian F. <chr...@ne...> - 2018-03-21 12:22:14
|
That's a reasonable suggestion. Would you mind making a pull request with your proposed wording? Best, Christian On Wed, Mar 21, 2018 at 12:50:19PM +0200, Eero Volotinen wrote: > Well, > > Maybe it's time to fix documentation: > > # HTTP methods that a client is allowed to use. > # Default: GET HEAD POST OPTIONS > # Example: for RESTful APIs, add the following methods: PUT PATCH DELETE > # Example: for WebDAV, add the following methods: CHECKOUT COPY DELETE LOCK > # MERGE MKACTIVITY MKCOL MOVE PROPFIND PROPPATCH PUT UNLOCK > # Uncomment this rule to change the default. > SecAction \ > "id:900200,\ > phase:1,\ > nolog,\ > pass,\ > t:none,\ > setvar:'tx.allowed_methods=GET POST'" > > It's not working as expected. How about saying that rules is not blocking > trace method? > > Eero > > > > On Wed, Mar 21, 2018 at 12:25 PM, Reindl Harald <h.r...@th...> > wrote: > > > > > > > Am 21.03.2018 um 11:11 schrieb Eero Volotinen: > > > >> Not enought familiar with modsecurity. > >> > >> Just wondering, that there is no any rule to block trace in crs. is there > >> easy way to implement that? > >> > > > > why would someone do that when you can and should disable it entirely on > > your webserver? i guess you are coming from OpenVAS warnings but then also > > search for options to disable thins proper instead burry them within a > > firewall layer > > > > [root@srv-rhsoft:~]$ cat conf/httpd-core.conf | grep Trace > > TraceEnable Off > > > > On Wed, Mar 21, 2018 at 11:53 AM, Christian Folini < > >> chr...@ne... <mailto:chr...@ne...>> wrote: > >> > >> Hey Eero, > >> > >> The TRACE method is somewhat special. At least in Apache. The request > >> skips phase 2 and thus the CRS rule covering tx.allowed_methods. > >> > >> There are discussions to move this block of rules to phase 1 though. > >> https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1015 > >> <https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1015> > >> > >> You may want to chime in there. > >> > >> Ahoj, > >> > >> Christian > >> > >> On Wed, Mar 21, 2018 at 09:15:52AM +0200, Eero Volotinen wrote: > >> > Hi, > >> > > >> > Just noticed that crs ruleset is not blocking trace method, even > >> > setvar:'tx.allowed_methods=GET POST'" > >> > > >> > Is this a bug? > >> > > > > ------------------------------------------------------------ > > ------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > mod-security-users mailing list > > mod...@li... > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > > http://www.modsecurity.org/projects/commercial/rules/ > > http://www.modsecurity.org/projects/commercial/support/ > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > http://www.modsecurity.org/projects/commercial/rules/ > http://www.modsecurity.org/projects/commercial/support/ -- https://www.feistyduck.com/training/modsecurity-training-course https://www.feistyduck.com/books/modsecurity-handbook/ mailto:chr...@ne... twitter: @ChrFolini |
|
From: Reindl H. <h.r...@th...> - 2018-03-21 11:00:32
|
Am 21.03.2018 um 11:50 schrieb Eero Volotinen: > Maybe it's time to fix documentation: > > # HTTP methods that a client is allowed to use. > # Default: GET HEAD POST OPTIONS > # Example: for RESTful APIs, add the following methods: PUT PATCH DELETE > # Example: for WebDAV, add the following methods: CHECKOUT COPY DELETE LOCK > # MERGE MKACTIVITY MKCOL MOVE PROPFIND PROPPATCH PUT UNLOCK > # Uncomment this rule to change the default. > SecAction \ > "id:900200,\ > phase:1,\ > nolog,\ > pass,\ > t:none,\ > setvar:'tx.allowed_methods=GET POST'" > > It's not working as expected. How about saying that rules is not > blocking trace method? the above implies you would block HEAD (since it's not listed) - i guess that also don't do what you expect as well as you can't disable HEAD requests with <Limit> and i even go so far that you don't want block HEAD requests at all even if you think you do anyways, the way to go is this one and no reason for a third place TraceEnable Off <IfModule mod_allowmethods.c> <Location /> AllowMethods GET HEAD POST </Location> </IfModule> > On Wed, Mar 21, 2018 at 12:25 PM, Reindl Harald <h.r...@th... > <mailto:h.r...@th...>> wrote: > > > > Am 21.03.2018 um 11:11 schrieb Eero Volotinen: > > Not enought familiar with modsecurity. > > Just wondering, that there is no any rule to block trace in crs. > is there easy way to implement that? > > > why would someone do that when you can and should disable it > entirely on your webserver? i guess you are coming from OpenVAS > warnings but then also search for options to disable thins proper > instead burry them within a firewall layer > > [root@srv-rhsoft:~]$ cat conf/httpd-core.conf | grep Trace > TraceEnable Off > > On Wed, Mar 21, 2018 at 11:53 AM, Christian Folini > <chr...@ne... > <mailto:chr...@ne...> > <mailto:chr...@ne... > <mailto:chr...@ne...>>> wrote: > > Hey Eero, > > The TRACE method is somewhat special. At least in Apache. > The request > skips phase 2 and thus the CRS rule covering > tx.allowed_methods. > > There are discussions to move this block of rules to phase > 1 though. > https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1015 > <https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1015> > > <https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1015 > <https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1015>> > > You may want to chime in there. > > Ahoj, > > Christian > > On Wed, Mar 21, 2018 at 09:15:52AM +0200, Eero Volotinen wrote: > > Hi, > > > > Just noticed that crs ruleset is not blocking trace > method, even > > setvar:'tx.allowed_methods=GET POST'" > > > > Is this a bug? |
|
From: Eero V. <eer...@ik...> - 2018-03-21 11:34:30
|
It blocks HEAD requests also, so it works as expected in that case, but not TRACE Eero On Wed, Mar 21, 2018 at 1:00 PM, Reindl Harald <h.r...@th...> wrote: > > > Am 21.03.2018 um 11:50 schrieb Eero Volotinen: > >> Maybe it's time to fix documentation: >> >> # HTTP methods that a client is allowed to use. >> # Default: GET HEAD POST OPTIONS >> # Example: for RESTful APIs, add the following methods: PUT PATCH DELETE >> # Example: for WebDAV, add the following methods: CHECKOUT COPY DELETE >> LOCK >> # MERGE MKACTIVITY MKCOL MOVE PROPFIND PROPPATCH PUT UNLOCK >> # Uncomment this rule to change the default. >> SecAction \ >> "id:900200,\ >> phase:1,\ >> nolog,\ >> pass,\ >> t:none,\ >> setvar:'tx.allowed_methods=GET POST'" >> >> It's not working as expected. How about saying that rules is not blocking >> trace method? >> > > the above implies you would block HEAD (since it's not listed) - i guess > that also don't do what you expect as well as you can't disable HEAD > requests with <Limit> and i even go so far that you don't want block HEAD > requests at all even if you think you do > > > anyways, the way to go is this one and no reason for a third place > > TraceEnable Off > <IfModule mod_allowmethods.c> > <Location /> > AllowMethods GET HEAD POST > </Location> > </IfModule> > > On Wed, Mar 21, 2018 at 12:25 PM, Reindl Harald <h.r...@th... >> <mailto:h.r...@th...>> wrote: >> >> >> >> Am 21.03.2018 um 11:11 schrieb Eero Volotinen: >> >> Not enought familiar with modsecurity. >> >> Just wondering, that there is no any rule to block trace in crs. >> is there easy way to implement that? >> >> >> why would someone do that when you can and should disable it >> entirely on your webserver? i guess you are coming from OpenVAS >> warnings but then also search for options to disable thins proper >> instead burry them within a firewall layer >> >> [root@srv-rhsoft:~]$ cat conf/httpd-core.conf | grep Trace >> TraceEnable Off >> >> On Wed, Mar 21, 2018 at 11:53 AM, Christian Folini >> <chr...@ne... >> <mailto:chr...@ne...> >> <mailto:chr...@ne... >> >> <mailto:chr...@ne...>>> wrote: >> >> Hey Eero, >> >> The TRACE method is somewhat special. At least in Apache. >> The request >> skips phase 2 and thus the CRS rule covering >> tx.allowed_methods. >> >> There are discussions to move this block of rules to phase >> 1 though. >> https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1015 >> <https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1015> >> <https://github.com/SpiderLabs >> /owasp-modsecurity-crs/issues/1015 >> <https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1015 >> >> >> >> You may want to chime in there. >> >> Ahoj, >> >> Christian >> >> On Wed, Mar 21, 2018 at 09:15:52AM +0200, Eero Volotinen >> wrote: >> > Hi, >> > >> > Just noticed that crs ruleset is not blocking trace >> method, even >> > setvar:'tx.allowed_methods=GET POST'" >> > >> > Is this a bug? >> > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > http://www.modsecurity.org/projects/commercial/rules/ > http://www.modsecurity.org/projects/commercial/support/ > |
|
From: Reindl H. <h.r...@th...> - 2018-03-21 11:38:32
|
Am 21.03.2018 um 12:34 schrieb Eero Volotinen: > It blocks HEAD requests also, so it works as expected in that case, but > not TRACE blocking HEAD requests is stupid - period the httpd-developers had a good reason why they implicit included it in <Limit> wevn when you tried to only allow "GET POST" by not knowing about the purpose of HEAD requests and vreaking things for no sane reason > On Wed, Mar 21, 2018 at 1:00 PM, Reindl Harald <h.r...@th... > <mailto:h.r...@th...>> wrote: > > > > Am 21.03.2018 um 11:50 schrieb Eero Volotinen: > > Maybe it's time to fix documentation: > > # HTTP methods that a client is allowed to use. > # Default: GET HEAD POST OPTIONS > # Example: for RESTful APIs, add the following methods: PUT > PATCH DELETE > # Example: for WebDAV, add the following methods: CHECKOUT COPY > DELETE LOCK > # MERGE MKACTIVITY MKCOL MOVE PROPFIND PROPPATCH PUT UNLOCK > # Uncomment this rule to change the default. > SecAction \ > "id:900200,\ > phase:1,\ > nolog,\ > pass,\ > t:none,\ > setvar:'tx.allowed_methods=GET POST'" > > It's not working as expected. How about saying that rules is not > blocking trace method? > > > the above implies you would block HEAD (since it's not listed) - i > guess that also don't do what you expect as well as you can't > disable HEAD requests with <Limit> and i even go so far that you > don't want block HEAD requests at all even if you think you do > > > anyways, the way to go is this one and no reason for a third place > > TraceEnable Off > <IfModule mod_allowmethods.c> > <Location /> > AllowMethods GET HEAD POST > </Location> > </IfModule> > > On Wed, Mar 21, 2018 at 12:25 PM, Reindl Harald > <h.r...@th... <mailto:h.r...@th...> > <mailto:h.r...@th... <mailto:h.r...@th...>>> > wrote: > > > > Am 21.03.2018 um 11:11 schrieb Eero Volotinen: > > Not enought familiar with modsecurity. > > Just wondering, that there is no any rule to block > trace in crs. > is there easy way to implement that? > > > why would someone do that when you can and should disable it > entirely on your webserver? i guess you are coming from OpenVAS > warnings but then also search for options to disable thins > proper > instead burry them within a firewall layer > > [root@srv-rhsoft:~]$ cat conf/httpd-core.conf | grep Trace > TraceEnable Off > > On Wed, Mar 21, 2018 at 11:53 AM, Christian Folini > <chr...@ne... > <mailto:chr...@ne...> > <mailto:chr...@ne... > <mailto:chr...@ne...>> > <mailto:chr...@ne... > <mailto:chr...@ne...> > > <mailto:chr...@ne... > <mailto:chr...@ne...>>>> wrote: > > Hey Eero, > > The TRACE method is somewhat special. At least in > Apache. > The request > skips phase 2 and thus the CRS rule covering > tx.allowed_methods. > > There are discussions to move this block of rules > to phase > 1 though. > https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1015 > <https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1015> > > <https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1015 > <https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1015>> > > <https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1015 > <https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1015> > > <https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1015 > <https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1015>>> > > You may want to chime in there. > > Ahoj, > > Christian > > On Wed, Mar 21, 2018 at 09:15:52AM +0200, Eero > Volotinen wrote: > > Hi, > > > > Just noticed that crs ruleset is not blocking trace > method, even > > setvar:'tx.allowed_methods=GET POST'" > > > > Is this a bug? |
Thanks for helping keep SourceForge clean.
X