Re: [mod-security-users] crs ruleset and trace method?
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
Re: [mod-security-users] crs ruleset and trace method?
|
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? |
