date:20170822

Re: [Owasp-modsecurity-core-rule-set] 400 bad request when owasp is enabled in detection only mode - why?

2017-08-22 Thread Georgi Georgiev

I fixed the mutex error by changing the log type to concurrent, but it does not 
solved the problem with 400 bad request, also then there is another error in 
nginx (maybe not related to the bad request but not sure):

2017/08/22 22:17:49 [alert] 29957#0: *1 zero size buf in writer t:1 r:0 f:0 
039898E0 039898E9-039898E9  0-0 while 
sending to client, client: 1.1.1.1, server: plevensport.elektrostil.com, 
request: "GET /favicon.ico HTTP/2.0", upstream: 
"https://2.2.2.2:8443/favicon.ico;, host: "www.domain.eu", referrer: 
"https://www.domain.eu/index.php”


I am not sure 2.X version of mod security, but 3 and the problem still appear 
here.


> On Aug 22, 2017, at 8:06 PM, Chaim Sanders  wrote:
> 
> If you are using ModSecurity 2.x on Nginx there are known issues with request 
> body processing in many situations, make sure to try 2.9.2. ModSecurity 3.x 
> is being developed to solve these issues. 
> 
> On Tue, Aug 22, 2017 at 12:55 PM, Georgi Georgiev  > wrote:
> As I read I think the problem is related to this. Don’t you think so?
> 
> https://www.bountysource.com/issues/1573623-nginx-with-modsecurity-post-request-gives-500-error
>  
> 
> 
>> On Aug 22, 2017, at 7:53 PM, Christian Folini > > wrote:
>> 
>> Hey Georgi,
>> 
>> The
>> 
>> "Message: Audit log: Failed to lock global mutex: Permission denied"
>> 
>> in combination with the SecRequestBodyAccess is a bad sign.
>> 
>> You should try and solve that permission problem. I would not be
>> surprised if it would be linked.
>> 
>> Ahoj,
>> 
>> Christian
>> 
>> 
>> On Tue, Aug 22, 2017 at 07:27:11PM +0300, Georgi Georgiev wrote:
>>>   If I comment this line everything works:
>>>   SecRequestBodyAccess On
>>>   But this should be enabled. Any suggestions?
>>> 
>>> On Aug 22, 2017, at 6:16 PM, Georgi Georgiev
>>> > wrote:
>>> Hello,
>>> If I enable crs for this domain on the Joomla search of the site it
>>> returns 400 bad request, but the modsec is in detection only mode. No
>>> rule is matched as I see. If I turn off the modsec everything is ok.
>>> This is the audit log if it helps: 
>>> [22/Aug/2017:17:08:15 +0300] IcAcAcVcAcccAcAcAAxcAcAc 77.70.108.119
>>> 53428 127.0.0.1 80
>>> --bc7c6349-B--
>>> POST /index.php HTTP/2.0
>>> host: www.plevensport.eu 
>>> content-length: 86
>>> cache-control: max-age=0
>>> origin: https://www.plevensport.eu 
>>> upgrade-insecure-requests: 1
>>> user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5)
>>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101
>>> Safari/537.36
>>> content-type: application/x-www-form-urlencoded
>>> accept:
>>> 
>>> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
>>> referer: https://www.plevensport.eu/index.php 
>>> 
>>> accept-encoding: gzip, deflate, br
>>> accept-language: en-US,en;q=0.8
>>> cookie:
>>> 53f8f9fad3d3789bffbdbce160246b7e=3b72edc95ab809ce6dc6b3755305adf1;
>>> __utmt=1; _c=y;
>>> __utma=155943930.1578748701.1503409083.1503409083.1503409083.1;
>>> __utmb=155943930.9.10.1503409083; __utmc=155943930;
>>> 
>>> __utmz=155943930.1503409083.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
>>> --bc7c6349-C--
>>> 
>>> searchword=%D0%BF%D0%BB%D0%B5%D0%B2%D0%B5%D0%BD=search=com_search=1
>>> --bc7c6349-F--
>>> HTTP/1.1 400
>>> Server: ws-httpd
>>> Content-Type: text/html
>>> Content-Length: 568
>>> Connection: close
>>> --bc7c6349-E--
>>> 
>>> 400 Bad Request
>>> 
>>> 400 Bad Request
>>> nginx
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --bc7c6349-H--
>>> Message: Audit log: Failed to lock global mutex: Permission denied
>>> Apache-Handler: IIS
>>> Stopwatch: 1503410895000281 417063 (- - -)
>>> Stopwatch2: 1503410895000281 417063; combined=44304, p1=732, p2=42473,
>>> p3=47, p4=723, p5=229, sr=148, sw=100, l=0, gc=0
>>> Response-Body-Transformed: Dechunked
>>> Producer: ModSecurity for nginx (STABLE)/2.9.1
>>> (http://www.modsecurity.org/ ); 
>>> OWASP_CRS/3.0.2. 
>>> Server: ModSecurity Standalone
>>> Engine-Mode: "ENABLED"
>>> --bc7c6349-Z--
>>> As itâ**s not exactly error which can occur because of modsec but itâ**s
>>> obviously the problem what can be the reason? Some directive?
>>> ___
>>> Owasp-modsecurity-core-rule-set mailing

Re: [Owasp-modsecurity-core-rule-set] 400 bad request when owasp is enabled in detection only mode - why?

2017-08-22 Thread Chaim Sanders

If you are using ModSecurity 2.x on Nginx there are known issues with
request body processing in many situations, make sure to try 2.9.2.
ModSecurity 3.x is being developed to solve these issues.

On Tue, Aug 22, 2017 at 12:55 PM, Georgi Georgiev <
geo...@serversolution.info> wrote:

> As I read I think the problem is related to this. Don’t you think so?
>
> https://www.bountysource.com/issues/1573623-nginx-with-
> modsecurity-post-request-gives-500-error
>
> On Aug 22, 2017, at 7:53 PM, Christian Folini 
> wrote:
>
> Hey Georgi,
>
> The
>
> "Message: Audit log: Failed to lock global mutex: Permission denied"
>
> in combination with the SecRequestBodyAccess is a bad sign.
>
> You should try and solve that permission problem. I would not be
> surprised if it would be linked.
>
> Ahoj,
>
> Christian
>
>
> On Tue, Aug 22, 2017 at 07:27:11PM +0300, Georgi Georgiev wrote:
>
>   If I comment this line everything works:
>   SecRequestBodyAccess On
>   But this should be enabled. Any suggestions?
>
> On Aug 22, 2017, at 6:16 PM, Georgi Georgiev
>  wrote:
> Hello,
> If I enable crs for this domain on the Joomla search of the site it
> returns 400 bad request, but the modsec is in detection only mode. No
> rule is matched as I see. If I turn off the modsec everything is ok.
> This is the audit log if it helps:
> [22/Aug/2017:17:08:15 +0300] IcAcAcVcAcccAcAcAAxcAcAc 77.70.108.119
> 53428 127.0.0.1 80
> --bc7c6349-B--
> POST /index.php HTTP/2.0
> host: www.plevensport.eu
> content-length: 86
> cache-control: max-age=0
> origin: https://www.plevensport.eu
> upgrade-insecure-requests: 1
> user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101
> Safari/537.36
> content-type: application/x-www-form-urlencoded
> accept:
> text/html,application/xhtml+xml,application/xml;q=0.
> 9,image/webp,image/apng,*/*;q=0.8
> referer: https://www.plevensport.eu/index.php
> accept-encoding: gzip, deflate, br
> accept-language: en-US,en;q=0.8
> cookie:
> 53f8f9fad3d3789bffbdbce160246b7e=3b72edc95ab809ce6dc6b3755305adf1;
> __utmt=1; _c=y;
> __utma=155943930.1578748701.1503409083.1503409083.1503409083.1;
> __utmb=155943930.9.10.1503409083; __utmc=155943930;
> __utmz=155943930.1503409083.1.1.utmcsr=(direct)
> |utmccn=(direct)|utmcmd=(none)
> --bc7c6349-C--
> searchword=%D0%BF%D0%BB%D0%B5%D0%B2%D0%B5%D0%BD=
> search=com_search=1
> --bc7c6349-F--
> HTTP/1.1 400
> Server: ws-httpd
> Content-Type: text/html
> Content-Length: 568
> Connection: close
> --bc7c6349-E--
> 
> 400 Bad Request
> 
> 400 Bad Request
> nginx
> 
> 
> 
> 
> 
> 
> 
> 
> --bc7c6349-H--
> Message: Audit log: Failed to lock global mutex: Permission denied
> Apache-Handler: IIS
> Stopwatch: 1503410895000281 417063 (- - -)
> Stopwatch2: 1503410895000281 417063; combined=44304, p1=732, p2=42473,
> p3=47, p4=723, p5=229, sr=148, sw=100, l=0, gc=0
> Response-Body-Transformed: Dechunked
> Producer: ModSecurity for nginx (STABLE)/2.9.1
> (http://www.modsecurity.org/); OWASP_CRS/3.0.2.
> Server: ModSecurity Standalone
> Engine-Mode: "ENABLED"
> --bc7c6349-Z--
> As itâ**s not exactly error which can occur because of modsec but
> itâ**s
> obviously the problem what can be the reason? Some directive?
> ___
> 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
>
>
> ___
> 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
>
>
>
> --
> ModSecurity courses Oct 2017 in London and Zurich
> 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
>
>


-- 
-- 
Chaim Sanders
http://www.ChaimSanders.com
___
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] 400 bad request when owasp is enabled in detection only mode - why?

2017-08-22 Thread Georgi Georgiev

As I read I think the problem is related to this. Don’t you think so?

https://www.bountysource.com/issues/1573623-nginx-with-modsecurity-post-request-gives-500-error
 


> On Aug 22, 2017, at 7:53 PM, Christian Folini  
> wrote:
> 
> Hey Georgi,
> 
> The
> 
> "Message: Audit log: Failed to lock global mutex: Permission denied"
> 
> in combination with the SecRequestBodyAccess is a bad sign.
> 
> You should try and solve that permission problem. I would not be
> surprised if it would be linked.
> 
> Ahoj,
> 
> Christian
> 
> 
> On Tue, Aug 22, 2017 at 07:27:11PM +0300, Georgi Georgiev wrote:
>>   If I comment this line everything works:
>>   SecRequestBodyAccess On
>>   But this should be enabled. Any suggestions?
>> 
>> On Aug 22, 2017, at 6:16 PM, Georgi Georgiev
>>  wrote:
>> Hello,
>> If I enable crs for this domain on the Joomla search of the site it
>> returns 400 bad request, but the modsec is in detection only mode. No
>> rule is matched as I see. If I turn off the modsec everything is ok.
>> This is the audit log if it helps: 
>> [22/Aug/2017:17:08:15 +0300] IcAcAcVcAcccAcAcAAxcAcAc 77.70.108.119
>> 53428 127.0.0.1 80
>> --bc7c6349-B--
>> POST /index.php HTTP/2.0
>> host: www.plevensport.eu
>> content-length: 86
>> cache-control: max-age=0
>> origin: https://www.plevensport.eu
>> upgrade-insecure-requests: 1
>> user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5)
>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101
>> Safari/537.36
>> content-type: application/x-www-form-urlencoded
>> accept:
>> 
>> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
>> referer: https://www.plevensport.eu/index.php
>> accept-encoding: gzip, deflate, br
>> accept-language: en-US,en;q=0.8
>> cookie:
>> 53f8f9fad3d3789bffbdbce160246b7e=3b72edc95ab809ce6dc6b3755305adf1;
>> __utmt=1; _c=y;
>> __utma=155943930.1578748701.1503409083.1503409083.1503409083.1;
>> __utmb=155943930.9.10.1503409083; __utmc=155943930;
>> 
>> __utmz=155943930.1503409083.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
>> --bc7c6349-C--
>> 
>> searchword=%D0%BF%D0%BB%D0%B5%D0%B2%D0%B5%D0%BD=search=com_search=1
>> --bc7c6349-F--
>> HTTP/1.1 400
>> Server: ws-httpd
>> Content-Type: text/html
>> Content-Length: 568
>> Connection: close
>> --bc7c6349-E--
>> 
>> 400 Bad Request
>> 
>> 400 Bad Request
>> nginx
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> --bc7c6349-H--
>> Message: Audit log: Failed to lock global mutex: Permission denied
>> Apache-Handler: IIS
>> Stopwatch: 1503410895000281 417063 (- - -)
>> Stopwatch2: 1503410895000281 417063; combined=44304, p1=732, p2=42473,
>> p3=47, p4=723, p5=229, sr=148, sw=100, l=0, gc=0
>> Response-Body-Transformed: Dechunked
>> Producer: ModSecurity for nginx (STABLE)/2.9.1
>> (http://www.modsecurity.org/); OWASP_CRS/3.0.2.
>> Server: ModSecurity Standalone
>> Engine-Mode: "ENABLED"
>> --bc7c6349-Z--
>> As itâ**s not exactly error which can occur because of modsec but itâ**s
>> obviously the problem what can be the reason? Some directive?
>> ___
>> 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
> 
>> ___
>> 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
> 
> 
> -- 
> ModSecurity courses Oct 2017 in London and Zurich
> 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] 400 bad request when owasp is enabled in detection only mode - why?

2017-08-22 Thread Christian Folini

Hey Georgi,

The

"Message: Audit log: Failed to lock global mutex: Permission denied"

in combination with the SecRequestBodyAccess is a bad sign.

You should try and solve that permission problem. I would not be
surprised if it would be linked.

Ahoj,

Christian


On Tue, Aug 22, 2017 at 07:27:11PM +0300, Georgi Georgiev wrote:
>If I comment this line everything works:
>SecRequestBodyAccess On
>But this should be enabled. Any suggestions?
> 
>  On Aug 22, 2017, at 6:16 PM, Georgi Georgiev
>   wrote:
>  Hello,
>  If I enable crs for this domain on the Joomla search of the site it
>  returns 400 bad request, but the modsec is in detection only mode. No
>  rule is matched as I see. If I turn off the modsec everything is ok.
>  This is the audit log if it helps: 
>  [22/Aug/2017:17:08:15 +0300] IcAcAcVcAcccAcAcAAxcAcAc 77.70.108.119
>  53428 127.0.0.1 80
>  --bc7c6349-B--
>  POST /index.php HTTP/2.0
>  host: www.plevensport.eu
>  content-length: 86
>  cache-control: max-age=0
>  origin: https://www.plevensport.eu
>  upgrade-insecure-requests: 1
>  user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5)
>  AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101
>  Safari/537.36
>  content-type: application/x-www-form-urlencoded
>  accept:
>  
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
>  referer: https://www.plevensport.eu/index.php
>  accept-encoding: gzip, deflate, br
>  accept-language: en-US,en;q=0.8
>  cookie:
>  53f8f9fad3d3789bffbdbce160246b7e=3b72edc95ab809ce6dc6b3755305adf1;
>  __utmt=1; _c=y;
>  __utma=155943930.1578748701.1503409083.1503409083.1503409083.1;
>  __utmb=155943930.9.10.1503409083; __utmc=155943930;
>  
> __utmz=155943930.1503409083.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
>  --bc7c6349-C--
>  
> searchword=%D0%BF%D0%BB%D0%B5%D0%B2%D0%B5%D0%BD=search=com_search=1
>  --bc7c6349-F--
>  HTTP/1.1 400
>  Server: ws-httpd
>  Content-Type: text/html
>  Content-Length: 568
>  Connection: close
>  --bc7c6349-E--
>  
>  400 Bad Request
>  
>  400 Bad Request
>  nginx
>  
>  
>  
>  
>  
>  
>  
>  
>  --bc7c6349-H--
>  Message: Audit log: Failed to lock global mutex: Permission denied
>  Apache-Handler: IIS
>  Stopwatch: 1503410895000281 417063 (- - -)
>  Stopwatch2: 1503410895000281 417063; combined=44304, p1=732, p2=42473,
>  p3=47, p4=723, p5=229, sr=148, sw=100, l=0, gc=0
>  Response-Body-Transformed: Dechunked
>  Producer: ModSecurity for nginx (STABLE)/2.9.1
>  (http://www.modsecurity.org/); OWASP_CRS/3.0.2.
>  Server: ModSecurity Standalone
>  Engine-Mode: "ENABLED"
>  --bc7c6349-Z--
>  As itâ**s not exactly error which can occur because of modsec but itâ**s
>  obviously the problem what can be the reason? Some directive?
>  ___
>  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

> ___
> 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


-- 
ModSecurity courses Oct 2017 in London and Zurich
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] 400 bad request when owasp is enabled in detection only mode - why?

2017-08-22 Thread Georgi Georgiev

If I comment this line everything works:

SecRequestBodyAccess On


But this should be enabled. Any suggestions?

> On Aug 22, 2017, at 6:16 PM, Georgi Georgiev  
> wrote:
> 
> Hello,
> If I enable crs for this domain on the Joomla search of the site it returns 
> 400 bad request, but the modsec is in detection only mode. No rule is matched 
> as I see. If I turn off the modsec everything is ok. This is the audit log if 
> it helps: 
> 
> [22/Aug/2017:17:08:15 +0300] IcAcAcVcAcccAcAcAAxcAcAc 77.70.108.119 53428 
> 127.0.0.1 80
> --bc7c6349-B--
> POST /index.php HTTP/2.0
> host: www.plevensport.eu 
> content-length: 86
> cache-control: max-age=0
> origin: https://www.plevensport.eu 
> upgrade-insecure-requests: 1
> user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) 
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36
> content-type: application/x-www-form-urlencoded
> accept: 
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
> referer: https://www.plevensport.eu/index.php 
> 
> accept-encoding: gzip, deflate, br
> accept-language: en-US,en;q=0.8
> cookie: 53f8f9fad3d3789bffbdbce160246b7e=3b72edc95ab809ce6dc6b3755305adf1; 
> __utmt=1; _c=y; 
> __utma=155943930.1578748701.1503409083.1503409083.1503409083.1; 
> __utmb=155943930.9.10.1503409083; __utmc=155943930; 
> __utmz=155943930.1503409083.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
> 
> --bc7c6349-C--
> searchword=%D0%BF%D0%BB%D0%B5%D0%B2%D0%B5%D0%BD=search=com_search=1
> --bc7c6349-F--
> HTTP/1.1 400
> Server: ws-httpd
> Content-Type: text/html
> Content-Length: 568
> Connection: close
> 
> --bc7c6349-E--
> 
> 400 Bad Request
> 
> 400 Bad Request
> nginx
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --bc7c6349-H--
> Message: Audit log: Failed to lock global mutex: Permission denied
> Apache-Handler: IIS
> Stopwatch: 1503410895000281 417063 (- - -)
> Stopwatch2: 1503410895000281 417063; combined=44304, p1=732, p2=42473, p3=47, 
> p4=723, p5=229, sr=148, sw=100, l=0, gc=0
> Response-Body-Transformed: Dechunked
> Producer: ModSecurity for nginx (STABLE)/2.9.1 (http://www.modsecurity.org/ 
> ); OWASP_CRS/3.0.2.
> Server: ModSecurity Standalone
> Engine-Mode: "ENABLED"
> 
> --bc7c6349-Z--
> 
> As it’s not exactly error which can occur because of modsec but it’s 
> obviously the problem what can be the reason? Some directive?
> ___
> 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

___
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

[Owasp-modsecurity-core-rule-set] 400 bad request when owasp is enabled in detection only mode - why?

2017-08-22 Thread Georgi Georgiev

Hello,
If I enable crs for this domain on the Joomla search of the site it returns 400 
bad request, but the modsec is in detection only mode. No rule is matched as I 
see. If I turn off the modsec everything is ok. This is the audit log if it 
helps: 

[22/Aug/2017:17:08:15 +0300] IcAcAcVcAcccAcAcAAxcAcAc 77.70.108.119 53428 
127.0.0.1 80
--bc7c6349-B--
POST /index.php HTTP/2.0
host: www.plevensport.eu
content-length: 86
cache-control: max-age=0
origin: https://www.plevensport.eu
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 
(KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36
content-type: application/x-www-form-urlencoded
accept: 
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
referer: https://www.plevensport.eu/index.php
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.8
cookie: 53f8f9fad3d3789bffbdbce160246b7e=3b72edc95ab809ce6dc6b3755305adf1; 
__utmt=1; _c=y; __utma=155943930.1578748701.1503409083.1503409083.1503409083.1; 
__utmb=155943930.9.10.1503409083; __utmc=155943930; 
__utmz=155943930.1503409083.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)

--bc7c6349-C--
searchword=%D0%BF%D0%BB%D0%B5%D0%B2%D0%B5%D0%BD=search=com_search=1
--bc7c6349-F--
HTTP/1.1 400
Server: ws-httpd
Content-Type: text/html
Content-Length: 568
Connection: close

--bc7c6349-E--

400 Bad Request

400 Bad Request
nginx









--bc7c6349-H--
Message: Audit log: Failed to lock global mutex: Permission denied
Apache-Handler: IIS
Stopwatch: 1503410895000281 417063 (- - -)
Stopwatch2: 1503410895000281 417063; combined=44304, p1=732, p2=42473, p3=47, 
p4=723, p5=229, sr=148, sw=100, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for nginx (STABLE)/2.9.1 (http://www.modsecurity.org/); 
OWASP_CRS/3.0.2.
Server: ModSecurity Standalone
Engine-Mode: "ENABLED"

--bc7c6349-Z--

As it’s not exactly error which can occur because of modsec but it’s obviously 
the problem what can be the reason? Some directive?___
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

[Owasp-modsecurity-core-rule-set] Announcing www.coreruleset.org and new project logo

2017-08-22 Thread Christian Folini

Dear all,

The OWASP ModSecurity Core Rule Set project is proud to present
its own website:

https://www.coreruleset.org

The information about CRS has been scattered over almost half a dozen
sites (OWASP wiki, Spiderlabs blog, github, modsecurity.org, netnea.com
website, etc.) during the years and new users have a hard time finding
the documentation they need. The idea of the project is to establish
coreruleset.org website as the go-to place for all things CRS. We thank
Walter Hop for the work he invested into this site on behalf of our
project.

An open source project needs a logo and following the success of the
CRS3 release poster, we decided that it's time to come up with a
professional logo for CRS. Hugo Costa, who also designed the release
poster, has created our new logo.

The logo comes with several different variants. The full blown version
is this:

https://coreruleset.org/assets/uploads/2017/08/CRS-logo-full__size-820x350.png

A simpler version is this one with only the symbol plus CRS:

https://coreruleset.org/assets/uploads/2017/08/CRS-logo-CRS__size-512x710.png

So what's the idea of the logo? We have the OWASP wasp in the center.
The wasp is protecting itself, but there is an outer ring made up from
three sectors. This is the 1st line of defense, the Core Rule Set.
Three sectors because of CRS3.

"The 1st Line of Defense" is also our claim. "Claim" is a marketing
term that tries to transport the core message of a product. Our idea
is that CRS should be be installed on every webserver as a simple yet
effective security measure that takes out 80% of the attacks with 
minimal hassle - like a "1st Line of Defense".

But back to the website. The information you will find so far is very 
limited. But it is meant to grow fast as there are many sources we
can pull from and a lot of knowledge in the team. We have the plan to
publish blog posts regularly and we welcome interested community members
to share their knowledge, tricks, success stories or newsworthy items
on our blog.

Kirk Jackson makes a start with a summary of his solution to apply
CRS only to an individual parameter on a single path:

https://coreruleset.org/20170821/running-crs-rules-only-on-certain-parameters/

Project lead Chaim Sanders explains the idea behind the new FTW project,
a Framework for Testing WAFs that we started to use as a base for our
CRS unit tests:

https://coreruleset.org/20170810/testing-wafs-ftw-version-1-0-released/

Please help us spread the word about our new website and about CRS in
general. Feel free to use our logo in your presentations or on your
website. There is a zip file with all variants in multiple sizes at

https://www.owasp.org/index.php/ModSecurity_CRS_Logo
  

We will put this on the new site too as soon as we receive the SVG
version of the logo.

Best regards,

Christian Folini, for the CRS team

-- 
ModSecurity courses Oct 2017 in London and Zurich
https://www.feistyduck.com/training/modsecurity-training-course
https://www.feistyduck.com/books/modsecurity-handbook/
mailto:christian.fol...@netnea.com
twitter: @ChrFolini










-- 
ModSecurity courses Oct 2017 in London and Zurich
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] 400 bad request when owasp is enabled in detection only mode - why?

Re: [Owasp-modsecurity-core-rule-set] 400 bad request when owasp is enabled in detection only mode - why?

Re: [Owasp-modsecurity-core-rule-set] 400 bad request when owasp is enabled in detection only mode - why?

Re: [Owasp-modsecurity-core-rule-set] 400 bad request when owasp is enabled in detection only mode - why?

Re: [Owasp-modsecurity-core-rule-set] 400 bad request when owasp is enabled in detection only mode - why?

[Owasp-modsecurity-core-rule-set] 400 bad request when owasp is enabled in detection only mode - why?

[Owasp-modsecurity-core-rule-set] Announcing www.coreruleset.org and new project logo

7 matches

Site Navigation

Mail list logo

Footer information