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 00000000039898E0 00000000039898E9-00000000039898E9 0000000000000000 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 <ch...@chaimsanders.com> 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 <geo...@serversolution.info > <mailto: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 > > <https://www.bountysource.com/issues/1573623-nginx-with-modsecurity-post-request-gives-500-error> > >> On Aug 22, 2017, at 7:53 PM, Christian Folini <christian.fol...@netnea.com >> <mailto:christian.fol...@netnea.com>> 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 >>> <geo...@serversolution.info <mailto:geo...@serversolution.info>> 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 <http://www.plevensport.eu/> >>> content-length: 86 >>> cache-control: max-age=0 >>> origin: https://www.plevensport.eu <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 >>> <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&task=search&option=com_search&Itemid=1 >>> --bc7c6349-F-- >>> HTTP/1.1 400 >>> Server: ws-httpd >>> Content-Type: text/html >>> Content-Length: 568 >>> Connection: close >>> --bc7c6349-E-- >>> <html> >>> <head><title>400 Bad Request</title></head> >>> <body bgcolor="white"> >>> <center><h1>400 Bad Request</h1></center> >>> <hr><center>nginx</center> >>> </body> >>> </html> >>> <!-- a padding to disable MSIE and Chrome friendly error page --> >>> <!-- a padding to disable MSIE and Chrome friendly error page --> >>> <!-- a padding to disable MSIE and Chrome friendly error page --> >>> <!-- a padding to disable MSIE and Chrome friendly error page --> >>> <!-- a padding to disable MSIE and Chrome friendly error page --> >>> <!-- a padding to disable MSIE and Chrome friendly error page --> >>> --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/ <http://www.modsecurity.org/>); >>> OWASP_CRS/3.0.2. <http://3.0.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 >>> <mailto:Owasp-modsecurity-core-rule-set@lists.owasp.org> >>> >>> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set >>> <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 >>> <mailto:Owasp-modsecurity-core-rule-set@lists.owasp.org> >>> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set >>> <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/training/modsecurity-training-course> >> https://www.feistyduck.com/books/modsecurity-handbook/ >> <https://www.feistyduck.com/books/modsecurity-handbook/> >> mailto:christian.fol...@netnea.com <mailto:christian.fol...@netnea.com> >> twitter: @ChrFolini > > > _______________________________________________ > Owasp-modsecurity-core-rule-set mailing list > Owasp-modsecurity-core-rule-set@lists.owasp.org > <mailto:Owasp-modsecurity-core-rule-set@lists.owasp.org> > https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set > <https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set> > > > > > -- > -- > Chaim Sanders > http://www.ChaimSanders.com <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
