Re: [Owasp-modsecurity-core-rule-set] MSC_PCRE_LIMITS_EXCEEDED with SecPcreMatchLimit 10000000

2018-06-17 Thread Ehsan Mahdavi 
Hi
Which version of modsecurity do you use?
We experienced a lot of this with modsecurity_nginx_refactoring branch!

good luck

On Sun, Jun 17, 2018 at 12:03 PM Quinn Comendant 
wrote:

> I'm getting the famous MSC_PCRE_LIMITS_EXCEEDED error on a specific
> request, and not able to circumvent it by raising the SecPcreMatchLimit
> value; I've raised it to SecPcreMatchLimit 1000 (ten million!) and it's
> still blocked.
>
> Looks to me like a broken regex.
>
> 1. So maybe this is a bug report. Can you guys confirm the issue, based on
> the data included below?
>
> 2. How do I find which rule has the regex blocking this request? (I don't
> mean rule 24, which blocks MSC_*, I mean the rule with the broken regex
> that caused too much recursion.
>
> error_log:
> [Fri Jun 15 23:26:43.506695 2018] [:error] [pid 22588] [client
> 1.2.3.4:54790] [client 1.2.3.4] ModSecurity: Access denied with code 403
> (phase 2). Match of "streq 0" against "TX:MSC_PCRE_LIMITS_EXCEEDED"
> required. [file "/etc/httpd/conf.d/mod_security.conf"] [line "43"] [id
> "24"] [msg "ModSecurity internal error flagged:
> TX:MSC_PCRE_LIMITS_EXCEEDED"] [hostname "www.example.com"] [uri
> "/cp/orders.php"] [unique_id "WyRLM2JpNbHeGYomo7lCxQU"], referer:
> https://www.example.com/order/new
>
> OS:
> CentOS Linux release 7.5.1804 (Core)
>
> Software versions:
> httpd-2.4.6-80.el7.centos.x86_64
> mod_security-2.9.2-1.el7.x86_64
> mod_security_crs-2.2.9-1.el7.noarch
>
> Config:
> $ sudo grep -r SecPcreMatchLimit /etc/httpd
> /etc/httpd/conf.d/mod_security.conf:SecPcreMatchLimit 1000
> /etc/httpd/conf.d/mod_security.conf:SecPcreMatchLimitRecursion 1000
>
> Request:
> The request causing the error, as a curl command:
> https://pastebin.com/raw/fymAQtsJ
>
> curl 'https://www.example.com/order/confirm' -H 'Connection: keep-alive'
> -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' -H 'Origin:
> https://www.example.com' -H 'Upgrade-Insecure-Requests: 1' -H 'DNT: 1' -H
> 'Content-Type: application/x-www-form-urlencoded' -H 'User-Agent:
> Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML,
> like Gecko) Chrome/67.0.3396.87 Safari/537.36' -H 'Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8'
> -H 'Referer: https://www.example.com/order/new' -H 'Accept-Encoding:
> gzip, deflate, br' -H 'Accept-Language: en-US,en;q=0.9,es;q=0.8' -H
> 'Cookie: _prefs-login-username=%22%22; _session=sgj9tdvgrc26m57atct02niat3'
> --data
>
> 'csrf_token=1528995053-BrkRHVojxjfm5jmXVrK08SjLCo33daL2lHOPjosXweGZihQptAuqSwAKE6aNoWup=confirm=%5B%7B%22id%22%3A%221i75f9wlcaa2a6c7%22%2C%22ndc%22%3A%228576453101%22%2C%22description%22%3A%22TORGUGESIC-SA%22%2C%22strength%22%3A%222MG%2FML%22%2C%22dosage%22%3A%22Injection%22%2C%22package_size%22%3A%2210%22%2C%22units_of_measure%22%3A%22ml%22%2C%22quantity%22%3A%221%22%2C%22quantity_units%22%3A%22full+packages%22%2C%22notes%22%3A%22%22%7D%2C%7B%22id%22%3A%221i75fwwk6yf2c487%22%2C%22ndc%22%3A%22641228941%22%2C%22description%22%3A%22DIAZEPAM%22%2C%22strength%22%3A%225+MG%2FML%22%2C%22dosage%22%3A%22Solution%22%2C%22package_size%22%3A%2210%22%2C%22units_of_measure%22%3A%22ml%22%2C%22quantity%22%3A%221%22%2C%22quantity_units%22%3A%22full+packages%22%2C%22notes%22%3A%22%22%7D%2C%7B%22id%22%3A%221i75ftk3c0393b6a%22%2C%22ndc%22%3A%22856203310%22%2C%22description%22%3A%22TORBUTROL%22%2C%22strength%22%3A%2210MG%5C%5CML%22%2C%22dosage%22%3A%22Injection%22%2C%22packag
>
>
> e_size%22%3A%2210%22%2C%22units_of_measure%22%3A%22ml%22%2C%22quantity%22%3A%222.5%22%2C%22quantity_units%22%3A%22ml%22%2C%22notes%22%3A%22%22%7D%2C%7B%22id%22%3A%221i75eew2wa8940aa%22%2C%22ndc%22%3A%221169507021%22%2C%22description%22%3A%22KETAMINE+HCL%22%2C%22strength%22%3A%2210MG%2FML%22%2C%22dosage%22%3A%22Injection%22%2C%22package_size%22%3A%2210%22%2C%22units_of_measure%22%3A%22ml%22%2C%22quantity%22%3A%222.29%22%2C%22quantity_units%22%3A%22ml%22%2C%22notes%22%3A%22%22%7D%2C%7B%22id%22%3A%221i75ezq4k0a504cd%22%2C%22ndc%22%3A%226157008101%22%2C%22description%22%3A%22TUSSIGON%22%2C%22strength%22%3A%221.5+MG-5+MG%22%2C%22dosage%22%3A%22Tablet%22%2C%22package_size%22%3A%22100%22%2C%22units_of_measure%22%3A%22ea%22%2C%22quantity%22%3A%223%22%2C%22quantity_units%22%3A%22full+packages%22%2C%22notes%22%3A%22%22%7D%2C%7B%22id%22%3A%221i75f28rfw2ed68a%22%2C%22ndc%22%3A%226157008101%22%2C%22description%22%3A%22TUSSIGON%22%2C%22strength%22%3A%221.5+MG-5+MG%22%2C%22dosage%22%3A%22T
>
>
>

[Owasp-modsecurity-core-rule-set] Rule 951100 is corrupted

2017-03-07 Thread Ehsan Mahdavi 
Hi All
Rule 951100 in CRS 3 is not working.

be careful with that.
___
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] Drupal 7, nginx with ModSecurity - How to resolve that 404 error page please?

2016-12-01 Thread Ehsan Mahdavi 
Dear Christian
It isn't very odd to me if Matej uses Nginx with Modsec V2.x.

As an experienced Nginx + Modsec V2.x(nginx_refactoring) user, it looks
like to a known bug. While using nginx+modsecV2.x in reverse proxy mode
(which is not the case for Matej) we have the very same issue for some post
requests.
I can refer you to these links:

http://permalink.gmane.org/gmane.comp.apache.mod-security.user/12502
https://github.com/SpiderLabs/ModSecurity/issues/115
https://github.com/SpiderLabs/ModSecurity/issues/582
https://github.com/SpiderLabs/ModSecurity/issues/664
https://github.com/SpiderLabs/ModSecurity/issues/748


All complaining about this problem and no one takes the responsibility.
The only way is to disable modsec for the requested uri and wait for the
community to release modsec V3.0 or higher and hope that this bug will be
fixed.

Meantime he/she might find ctl:ruleEngine=off
 useful
.

Br. Ehsan

On Thu, Dec 1, 2016 at 11:56 AM, Christian Folini <
christian.fol...@netnea.com> wrote:

> Hello Matej,
>
> I had hoped somebody with an NginX could shed some light on this. But
> apparently not.
>
> It is very odd. Your server says he can not open a certain file
> (does it exist? permissions ok?) but then it seems that ModSec
> influences the behaviour of the server down to opening files.
> And that sounds quite crazy.
>
> On Mon, Nov 28, 2016 at 11:59:56AM +0100, Matej Zuzčák wrote:
> > OWASP rule set. But when I active ModSecurity in my virtual host config
> > file for my Drupal 7 web I do not login, register or reset password with
> > this error in log:
>
> You English is a bit hard to understand here. Could you rephrase,
> please?
>
> > I found some solutions for Apache web server (these solutions use
> > modifications of htaccess file), but not for Nginx.
>
> What was the problem with Apache exactly and what did you modify in
> the .htaccess file to make it go away?
>
> Cheers,
>
> Christian
>
>
> --
> https://www.feistyduck.com/training/modsecurity-training-course
> 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
>
___
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