[Owasp-modsecurity-core-rule-set] CRS News for February 2019 published

[Christian Folini]

Hello,

The OWASP ModSecurity Core Rule Set project news for February 2019 are out

https://coreruleset.org/20190228/crs-project-news-february-2019/

Retweets are welcome:

https://twitter.com/CoreRuleSet/status/1101226355155496960

This month, we announce the CRS community summit at AppSecGlobal in Tel Aviv
in late May and news of a ModSecurity fork by Microsoft's Azure team.

Best,

Christian

-- 
One sign that you’ve approached actual mastery of a subject is that
you get less arrogant; because you’ve spent so much time being wrong.
-- Matthew D. Green

___
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] Reminder: CRS community chat Monday, Feb 3, 3019

[Christian Folini]

Hi there,

This is a friendly reminder of our CRS community / project chat tomorrow
at 20:30 CET.

Access and agenda are listed here:

https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1291

If you have topics you would like us to cover, then please add them to the
list.

Best,

Christian


-- 
By the work one knows the workman.
-- Jean de La Fontaine
___
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] is there any tool to analyse apache access logs against CRS?

[Christian Folini]

Hi there,

The information you are looking for is not in the access log, but in the
error or the audit log.

I you look through my tutorials at https://netnea.com, you will find a few
techniques and scripts that help you with the task at hand.

Otherwise, the JWall Audit Console does a pretty good job extracting this
information.

Best,

Christian

On Thu, Jan 31, 2019 at 04:59:14PM +0530, Shrinivasan T wrote:
> Hello CRS Team,
> 
> Thanks for the great works.
> 
> I am looking for a tool to analyse my apache access logs against CRS to get
> report on any XSS/CSRF/etc issues.
> 
> Is there any tool to do this?
> 
> Thanks.
> 
> -- 
> Regards,
> T.Shrinivasan
> 
> 
> My Life with GNU/Linux : http://goinggnu.wordpress.com
> Free E-Magazine on Free Open Source Software in Tamil : http://kaniyam.com
> 
> Get Free Tamil Ebooks for Android, iOS, Kindle, Computer :
> http://FreeTamilEbooks.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

___
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] Modsecurity 403 server errors in WordPress

[Christian Folini]

Hello Ritesh,

This is likely a false positive. If you do not have control over the
configuration, then you need to complain to your vendor.

If you do have control over the configuration, you will need to educate
yourself about ModSecurity and likely the Core Rule Set a bit.

Our website https://coreruleset.org is a good starting point.

Best,

Christian


On Wed, Jan 30, 2019 at 08:28:18PM +0530, Ritesh Saini wrote:
> Hello,
> 
> This page of my site: https://www.digitalkube.com/elegant-themes-coupon/ 
>  is returning 404 errors 
> randomly.
> 
> It shows: Access denied with code 403
> 
> I did some Google search and found that it is due to mod security rules. My 
> site is hosted on a DigitalOcean droplet with nginx server.
> 
> Please suggest me a fix. If you need any details from my side then kindly let 
> me know.
> 
> Thanks & Regards,
> Ritesh

> ___
> 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] CRS News for January 2019 published

[Christian Folini]

Hello,

The OWASP ModSecurity Core Rule Set project news for January 2019 are out

https://coreruleset.org/20190124/crs-project-news-january-2019/

Retweets are welcome:

https://twitter.com/CoreRuleSet/status/1088786400433094656

This month, we announce detailed plans for the Cloudfest Hackathon in late
March in Germany and many, many pull requests covering bypasses and other
problems.

Best,

Christian


-- 
One sign that you’ve approached actual mastery of a subject is that 
you get less arrogant; because you’ve spent so much time being wrong.
-- Matthew D. Green
___
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] XML Variable

[Christian Folini]

Hello Jai,

That's a good question.

We are not overly happy with the way this is done. So there are discussions to
overhaul this completely.

However, when you have an non-xml request, then ARGS and ARGS_NAMES will be
populated. And there are a few cases where REQUEST_BODY is indeed covered
and this can result in double hits on the same rule on the same payload.

Cheers,

Christian

On Wed, Jan 02, 2019 at 02:09:06PM -0600, Jai Harpalani wrote:
> There are many OWASP CRS rules which have XML in the list of operators, but
> not REQUEST_BODY. An example of one is below.
> 
> SecRule
> REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/*
> "@pmf lfi-os-files.data" \
> "phase:request,\
> msg:'OS File Access Attempt',\
> rev:'4',\
> ver:'OWASP_CRS/3.0.0',\
> maturity:'9',\
> accuracy:'9',\
> capture,\
> t:none,t:utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,\
> block,\
> id:930120,\
> . . .
> 
> This rule is searching for patterns specified in lfi-os-files.data. It is
> not using Xpath expressions. The XML operator will be empty for non-xml
> requests or when the xml parser is disabled. In these cases, wouldn't we
> still want to search the request body for patterns specified in
> lfi-os-files.data? Is there a reason that the patterns are only searched
> for in the request body for XML requests?

> ___
> 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] CRS News for December 2018 published

[Christian Folini]

Hello everybody,

I just published the news of the OWASP ModSecurity Core Rule Set project
for the month of November:

https://coreruleset.org/20181226/crs-project-news-december-2018/

It includes the CRS 3.1 release, updates to the docker container, an
interesting success story and the first CRS 3.2 pull requests.

Best,

Christian



-- 
History repeats itself, first as tragedy, second as XML.
--- Comment found on slashdot
___
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] Reminder Monthly CRS community chat

[Christian Folini]

Hi there,

This is a friendly reminder for the monthly CRS community chat on Monday
Dec 3 on Slack. Connection and Agenda:

https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1238

Please add more issues to the agenda if you want them discussed.

The chat meeting is open for everybody, btw.

Best,

Christian


-- 
An error does not become truth by reason of multiplied propagation,
nor does truth become error because nobody sees it.
Truth stands, even if there be no public support. It is self sustained.
-- Mahatma Gandhi
___
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] OWASP ModSecurity Core Rule Set Version 3.1.0 released

[Christian Folini]

Dear all,

The OWASP Core Rule Set team is happy to announce the CRS release v3.1.0
at last.

A wee bit over 2 years in the making, this major release represents a big step
forward in terms of capabilities, usability and protection. 

Key features include:

* A new set of rules defending against Java injections
* Initial set of file upload checks
* Add built-in exceptions for Dokuwiki, Owncloud, Nextcloud and CPanel
* Easier handling of the paranoia mode
* Many false positives fixed
* Successful source code archaeology with regular expressions
* Detailed rule cleanup for easier maintenance
* Speed improvements via the removal of unneeded regex capture groups
* Regression tests for rules, Travis support
* CRS docker image based on Ubuntu

For a complete list of new features and the changes in this release, see
the CHANGES document:
https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.1/dev/CHANGES

CRS 3.1 is the best stable release of the OWASP ModSecurity Core Rule Set.
We advise all users and providers of boxed CRS versions to update their
setups.  CRS 3.0 won't see any future updates and we recommend you to
migrate onto our new release.

CRS 3.1 requires an Apache/IIS/NGINX web server with ModSecurity 2.8.0 or
higher. CRS 3.1 will run on libModSecurity 3.0 on NGINX.

Our GitHub repository is the preferred way to download and update CRS:
$> wget
https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.1.0.tar.gz

For detailed installation instructions, see the INSTALL document.
https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.1/dev/INSTALL

Our desire is to see the Core Rules project as a simple baseline security
feature, effectively fighting OWASP TOP 10 weaknesses with few side effects.
We are committed to cut down on false positives as much as possible in the
default install. We welcome reports of false positives on github.

For more information about our project, please go to https://coreruleset.org.

Sincerely,

Chaim Sanders, Walter Hop and Christian Folini on behalf of the Core Rule Set
development team


-- 
https://coreruleset.or://coreruleset.org
___
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] CRS News for November 2018 published

[Christian Folini]

Hello everybody,

I just published the news of the OWASP ModSecurity Core Rule Set project
for the month of November:

https://coreruleset.org/20181114/crs-project-news-november-2018/

It includes the CRS 3.1-RC2 release, the announcement of the full release for
November 24 and many online articles about CRS and ModSecurity.

Best,

Christian


-- 
A man must be big enough to admit to his mistakes, smart enough to
profit from them and strong enough to correct them.
-- Probably by John C. Maxwell

___
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] CRS: please add detectivy to scanners-user-agents.data

[Christian Folini]

Thank you for the hint, Eero.

Would you mind opening an issue (or pull request) at 
https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/ ?

Best,

Christian

On Fri, Nov 09, 2018 at 07:22:32AM +0200, Eero Volotinen wrote:
> # Detectify https://detectify.com
> 
> "Mozilla/5.0 (compatible; *Detect*ify) +https://*detect*
> ify.com/bot/ed2230ece7206bf5da08e6ca677b08ee7dbae2d8"
> 
> 
> Eero

> ___
> 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] Reminder Monthly CRS community chat

[Christian Folini]

Hi there,

This is a friendly reminder for the monthly CRS community chat next Monday
on Slack. Connection and Agenda: 

https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1206

Please add more issues to the agenda if you want them discussed.

The chat meeting is open for everybody, btw.

Best,

Christian


-- 
I would rather have a mind opened by wonder than one closed by belief.
-- Gerry Spence
___
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] False positives triggered only by anomaly score

[Christian Folini]

Cool. Glad that solved this issue.

If you have additional FPs at paranoia level 1, please do report them.
We want to weed out all FPs in the default installation.

Best,

Christian

On Thu, Oct 18, 2018 at 03:20:25PM -0400, Jonah Potter wrote:
> The upgrade from CRS 3.0.0 to 3.0.2 resolved the false positive - the
> request no longer returns a 403. I have yet to see any more lonely anomaly
> score errors in the logs, and hopefully that trend will continue. Thanks
> again for the assistance.
> - Jonah
> 
> On Thu, Oct 18, 2018 at 1:55 PM Christian Folini <
> christian.fol...@netnea.com> wrote:
> 
> > Hey Jonah,
> >
> > Good luck and please report back with the results.
> >
> > Christian
> >
> > On Thu, Oct 18, 2018 at 10:48:40AM -0400, Jonah Potter wrote:
> > > Gregory - good idea. Unfortunately, after adding part K to
> > SecAuditLogParts
> > > and reproducing the issue, I didn't get any output in part K. Oddly
> > enough,
> > > no logged requests are outputting anything under the part K heading, even
> > > when they have warnings listed in part H.
> > >
> > > Christian - My mistake - I meant CRS 3.0.0. I'll update to 3.0.2, and if
> > > that doesn't take care of it, I'll give 3.1-RC1 a shot, and let you know
> > > what happens.
> > >
> > > Thanks again,
> > > Jonah
> > >
> > > On Wed, Oct 17, 2018 at 2:57 PM Christian Folini <
> > > christian.fol...@netnea.com> wrote:
> > >
> > > > Hey Jonah,
> > > >
> > > > I suppose you mean CRS 3.0.2 when you say OWASP v3.
> > > >
> > > > I think there is a silent rule in 3.0.x that raises the anomaly score
> > > > without
> > > > issuing an alert message. But I can't remember if we fixed that for
> > 3.0.2
> > > > or
> > > > only for the upcoming 3.1. Could you try with 3.1-RC1 and reproduce it?
> > > > Alternatively, you could raise the debug log level and follow the
> > > > execution of
> > > > the rules.
> > > >
> > > > Best,
> > > >
> > > > Christian
> > > >
> > > > On Wed, Oct 17, 2018 at 01:46:42PM -0400, Jonah Potter wrote:
> > > > > Hey guys, hoping you can help me out with a issue I'm having. I'm
> > running
> > > > > OWASP v3 with libmodsecurity 3.0 on top of nginx-1.15.3 via
> > > > > Modsecurity-nginx. I'm experiencing false positives of this variety
> > with
> > > > > some regularity. A given request will be 403'd, but when I check
> > > > > modsec_audit.log, the only rule violations logged are the two
> > "inbound
> > > > > anomaly score exceeded" codes. The rule that was presumably violated
> > > > > leading to the anomaly score being incremented is not logged at all.
> > > > Here's
> > > > > an example:
> > > > >
> > > > > ---S4x9aI9l---A--
> > > > > > [17/Oct/2018:11:41:19 -0400] 153979087991.549389 [ip] 61929 [ip]
> > 443
> > > > > > ---S4x9aI9l---B--
> > > > > > POST /path/file.php?args=args HTTP/2.0
> > > > > > accept-encoding: gzip, deflate, br
> > > > > > cookie: PHPSESSID=xyz; notBot=notBot; _ga=xyz;
> > > > > >
> > > >
> > 73d45a3f924337c011d46201c4a77d88c8b17afce961417c3e4fb7bbce09a31a=0thocmt2erfgbcpmrts35lqgh1;
> > > > > > SideMenu=0; SearchLocation=49316; _gid=GA1.2.1268970541.1539790780;
> > > > Me=xyz;
> > > > > > _gat_UA-1302423-1=1
> > > > > > accept:
> > > > > >
> > > >
> > text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
> > > > > > cache-control: max-age=0
> > > > > > user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6)
> > > > > > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100
> > > > Safari/537.36
> > > > > > content-type: multipart/form-data;
> > > > > > boundary=WebKitFormBoundaryCoCuOxmv7pZRNW9G
> > > > > > upgrade-insecure-requests: 1
> > > > > > referer: https://www.mydomain.com/path/file.php?args=args
> > > > > > origin: https://www.mydomain.com
> > > > > > content-length: 1033
> > > > > > host: www.mydomain.com
> > > > > > accept-language: en-US,en;q=0.9
> > > > > > ---S4x9aI9l---

Re: [Owasp-modsecurity-core-rule-set] False positives triggered only by anomaly score

[Christian Folini]

Hey Jonah,

Good luck and please report back with the results.

Christian

On Thu, Oct 18, 2018 at 10:48:40AM -0400, Jonah Potter wrote:
> Gregory - good idea. Unfortunately, after adding part K to SecAuditLogParts
> and reproducing the issue, I didn't get any output in part K. Oddly enough,
> no logged requests are outputting anything under the part K heading, even
> when they have warnings listed in part H.
> 
> Christian - My mistake - I meant CRS 3.0.0. I'll update to 3.0.2, and if
> that doesn't take care of it, I'll give 3.1-RC1 a shot, and let you know
> what happens.
> 
> Thanks again,
> Jonah
> 
> On Wed, Oct 17, 2018 at 2:57 PM Christian Folini <
> christian.fol...@netnea.com> wrote:
> 
> > Hey Jonah,
> >
> > I suppose you mean CRS 3.0.2 when you say OWASP v3.
> >
> > I think there is a silent rule in 3.0.x that raises the anomaly score
> > without
> > issuing an alert message. But I can't remember if we fixed that for 3.0.2
> > or
> > only for the upcoming 3.1. Could you try with 3.1-RC1 and reproduce it?
> > Alternatively, you could raise the debug log level and follow the
> > execution of
> > the rules.
> >
> > Best,
> >
> > Christian
> >
> > On Wed, Oct 17, 2018 at 01:46:42PM -0400, Jonah Potter wrote:
> > > Hey guys, hoping you can help me out with a issue I'm having. I'm running
> > > OWASP v3 with libmodsecurity 3.0 on top of nginx-1.15.3 via
> > > Modsecurity-nginx. I'm experiencing false positives of this variety with
> > > some regularity. A given request will be 403'd, but when I check
> > > modsec_audit.log, the only rule violations logged are the two "inbound
> > > anomaly score exceeded" codes. The rule that was presumably violated
> > > leading to the anomaly score being incremented is not logged at all.
> > Here's
> > > an example:
> > >
> > > ---S4x9aI9l---A--
> > > > [17/Oct/2018:11:41:19 -0400] 153979087991.549389 [ip] 61929 [ip] 443
> > > > ---S4x9aI9l---B--
> > > > POST /path/file.php?args=args HTTP/2.0
> > > > accept-encoding: gzip, deflate, br
> > > > cookie: PHPSESSID=xyz; notBot=notBot; _ga=xyz;
> > > >
> > 73d45a3f924337c011d46201c4a77d88c8b17afce961417c3e4fb7bbce09a31a=0thocmt2erfgbcpmrts35lqgh1;
> > > > SideMenu=0; SearchLocation=49316; _gid=GA1.2.1268970541.1539790780;
> > Me=xyz;
> > > > _gat_UA-1302423-1=1
> > > > accept:
> > > >
> > text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
> > > > cache-control: max-age=0
> > > > user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6)
> > > > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100
> > Safari/537.36
> > > > content-type: multipart/form-data;
> > > > boundary=WebKitFormBoundaryCoCuOxmv7pZRNW9G
> > > > upgrade-insecure-requests: 1
> > > > referer: https://www.mydomain.com/path/file.php?args=args
> > > > origin: https://www.mydomain.com
> > > > content-length: 1033
> > > > host: www.mydomain.com
> > > > accept-language: en-US,en;q=0.9
> > > > ---S4x9aI9l---D--
> > > > ---S4x9aI9l---E--
> > > > \x0d\x0a403 Forbidden\x0d\x0a > > > bgcolor="white">\x0d\x0a403
> > > >
> > Forbidden\x0d\x0anginx/1.15.3\x0d\x0a\x0d\x0a\x0d\x0a\x0d\x0a\x0d\x0a\x0d\x0a\x0d\x0a\x0d\x0a\x0d\x0a
> > > > ---S4x9aI9l---F--
> > > > HTTP/2.0 403
> > > > Server: nginx/1.15.3
> > > > Date: Wed, 17 Oct 2018 15:41:19 GMT
> > > > Content-Length: 571
> > > > Content-Type: text/html
> > > > Connection: close
> > > > ---S4x9aI9l---H--
> > > > ModSecurity: Access denied with code 403 (phase 2). Matched "Operator
> > `Ge'
> > > > with parameter `5' against variable `TX:ANOMALY_SCORE' (Value: `5' )
> > [file
> > > >
> > "/usr/local/owasp-modsecurity-crs-3.0.0/rules/REQUEST-949-BLOCKING-EVALUATION.conf"]
> > > > [line "36"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded
> > > > (Total Score: 5)"] [data ""] [severity "2"] [ver ""] [maturity "0"]
> > > > [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag
> > > > "platform-multi"] [tag "attack-generic"] [hostname "173.167.228.139"]
> > [uri
> > > > "

Re: [Owasp-modsecurity-core-rule-set] Rule id:942130 possible inadequate match

[Christian Folini]

Hey Silvan,

Thank you for reporting.

Could you send the full payload / request. Ideally as a curl command, so we
can reproduce. It could be that you are up to something here.

Best,

Christian

On Tue, Sep 11, 2018 at 02:07:11PM +0200, Silvan Nagl wrote:
> Hi,
> 
> maybe i am wrong but it seams like the match for id:942130 "SQL
> Tautology" is cutting of to early.
> 
> Matched Data: h=H found within ARGS:p: protokolle.git;a=commitdiff;h=HEAD
> 
> instead of comparing "h" and "HEAD" in this example it just compares the
> beginning of HEAD which leads to a FP.
> 
> Regards,
> 
> Silvan
> 
> 
> ___
> 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] News from the Core Rule Set (2018-07-26)

[Christian Folini]

Dear all,

The revamped news from the OWASP ModSecurity Core Rule Set project have been
published at https://coreruleset.org/20180726/crs-project-news-july-2018/

There is a report from the CRS community summit in London earlier this month,
a group photo from said meeting and the link to a new CRS channel on the OWASP
slack.

Best,

Christian Folini

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

[Owasp-modsecurity-core-rule-set] Registration for the Core Rule Set community summit open

[Christian Folini]

Hello,

We have been planning to do an OWASP ModSecurity Core Rule Set community
summit at the upcoming AppSecEU conference in London. The program is still
in the making, but registrations is now open:

https://coreruleset.org/20180607/registration-open-for-the-crs-community-summit-on-july-4/

This is going to be on Wednesday July 4, at 4pm at the Queen Elisabeth II
Center in central London. We plan to talk about CRS, the recent proposal for
a rule Meta Language, roadmap of the project, your use cases and your burning
questions. Afterwards we plan to go out and eat / drink together and we are
very happy that cPanel agreed to sponsor that for us!

Please note, that you do not have to register for AppSecEU to participate
the our CRS summit.

If there are any questions or if you think you have something to contribute
to the program, then please get in touch with me directly.

Best regards,

Christian Folini


-- 
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] Wordpress admin-ajax.php issues

[Christian Folini]

Hey Taya,

Getting a 500 is a bit odd. But I take it you have made sure it is ModSec and
not something else. The full error log / audit log would help.

Ahoj,

Christian


On Thu, May 24, 2018 at 11:13:12PM +0100, Taisiya Latysh wrote:
> I can provide access to my AWS instance if required.
> 
> Thanks for your help.
> 
> Best regards,
> Taya

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


-- 
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] False Negatives (was: OWASP ModSecurity Core Rule Set Community Summit: July 4, 2018, in London)

[Christian Folini]

The 2nd edition of the ModSec Handbook covers this somewhat, but it does not
go very deep. Also, the mileage really depends on the application.

Regs,

Christian


On Thu, Mar 22, 2018 at 05:46:55PM +, Hiranmayi Palanki wrote:
> I’ll try the custom rule you provided.
> 
> Also, is there generally any guidance available on the performance 
> measurement metrics for each paranoia level.
> 
> From: Hiranmayi Palanki
> Sent: Thursday, March 22, 2018 1:40 PM
> To: 'Manuel Spartan' <spartan...@gmail.com>; 'Christian Folini' 
> <christian.fol...@netnea.com>
> Cc: 'OWASP CRS' <owasp-modsecurity-core-rule-set@lists.owasp.org>
> Subject: RE: [Owasp-modsecurity-core-rule-set] False Negatives (was: OWASP 
> ModSecurity Core Rule Set Community Summit: July 4, 2018, in London)
> 
> Thanks Manuel and Christian for your responses.
> 
> The application will have a thin layer of business rule whitelist regex based 
> input validation – therefore the issue with XSS noted below may not be that 
> much of a problem. For SQLinjection, it’s hard to guarantee that developers 
> will always use parameterized queries consistently throughout the SDLC. In my 
> opinion, encoded XSS attacks should be tackled at the lower paranoia levels.
> 
> I’d have to familiarize myself with the process of creating custom rules.
> 
> Is there a plan to enforce Content Security Policy Directives and other HTTP 
> security response headers (e.g. X-Frame-Options/Frame-Ancestors). In some of 
> the testing that I did, it is evident that these security headers are not 
> being injected.
> 
> 
> 
> From: 
> owasp-modsecurity-core-rule-set-bounces+hiranmayi.palanki=aexp@lists.owasp.org<mailto:owasp-modsecurity-core-rule-set-bounces+hiranmayi.palanki=aexp@lists.owasp.org>
>  
> [mailto:owasp-modsecurity-core-rule-set-bounces+hiranmayi.palanki=aexp@lists.owasp.org]
>  On Behalf Of Manuel Spartan
> Sent: Thursday, March 22, 2018 1:31 PM
> To: Christian Folini 
> <christian.fol...@netnea.com<mailto:christian.fol...@netnea.com>>
> Cc: OWASP CRS 
> <owasp-modsecurity-core-rule-set@lists.owasp.org<mailto:owasp-modsecurity-core-rule-set@lists.owasp.org>>
> Subject: Re: [Owasp-modsecurity-core-rule-set] False Negatives (was: OWASP 
> ModSecurity Core Rule Set Community Summit: July 4, 2018, in London)
> 
> Hi Hiranmayi,
> 
> Do you think in implementing input validation at all in your app?
> 
> > Encoded XSS attacks (stopped at PL2 as Christian said)
> 
> > http://localhost:8082/xss2?uid=%3Balert%281%29%3B
> 
> 
> 
> > SQLi
> 
> > http://localhost:8082/sqli2?uid=3-2
> If the response display the same as uid=1 you have a nice injection as the 
> back-end engine is evaluating the operation, however sending long complicated 
> payloads will be difficult in Paranoia Level 2 due to libinjection 
> inspections on ARGS and very hard in PL 4 as all non alphanumeric characters 
> will cause a blocked request but that will be extremely annoying to implement 
> if you use non-alphanumeric characters.
> 
> Why don't you simply make positive validation rules additional to CRS in 
> paranoia level 2? That will be easier, faster and more effective if your app 
> is not so complex but requires tailor made configurations and application 
> knowledge while the CRS is generic and do not require much application 
> knowledge.
> 
> i.e. This rule will accept only numeric values on the uid parameter on GET 
> requests, with this you will get rid of both issues with the least effort, 
> this is the kick... positive security power in action :)
> SecRule ARGS:uid "!@rx [0-9]+" "id:1,phase:1,deny,log,msg:'Bad value 
> received'"
> 
> Notice that the phase:1 is only for GET parameters and cannot be placed 
> inside Apache locations or it may be silently ignored but is faster as most 
> CRS rules are in phase:2 it will execute earlier and save you the execution 
> of many rules.
> 
> You may find very useful to learn the basics on ModSecurity rule writing, 
> other than the netnea tutorial to deal with False Positives shared by 
> Christian:
> Web Application Defender's Cookbook: Battling Hackers and Protecting Users 
> (RBarnett) for quick receipes
> ModSecurity Handbook (CFolini, IRistic) for general knowledge
> https://coreruleset.org/category/blog/<https://isolate.menlosecurity.com/1/3735928037/https:/coreruleset.org/category/blog/>
>  (CRS blog)
> https://spartantri.com/ModSecurity/<https://isolate.menlosecurity.com/1/3735928037/https:/spartantri.com/ModSecurity/>
>  (My blog, read the whitepaper on white listing)
> 
> Have fun!
> 
> 
> 2018-03-21 20:20 GMT+01:00 Christian Folini 
> <christi

Re: [Owasp-modsecurity-core-rule-set] [mod-security-users] crs ruleset and trace method?

[Christian Folini]

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 <
> christian.fol...@netnea.com> 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-security-us...@lists.sourceforge.net
> > > 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:christian.fol...@netnea.com
> > 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-security-us...@lists.sourceforge.net
> > 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-security-us...@lists.sourceforge.net
> 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: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] OWASP ModSecurity Core Rule Set Community Summit: July 4, 2018, in London

[Christian Folini]

Hi there,

Please save the date of our first Community Summit: July 4, 2018, at 4pm
in London.

https://coreruleset.org/20180320/save-the-date-crs-community-summit-on-july-4-2018/

This is meant to be a get-together of the community. We want to learn about
you and how you use CRS in your setups - and we want to talk with you about
the road map for the project and various feature requests.

The date is the night before AppSecEU. So you can join this get-together on
Wednesday and then attend AppSec EU on Thursday / Friday.

Please do consider to join us when Chaim, Walter and I meet for the first
time face2face. :)

Best,

Christian


-- 
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] please add f-secure radar to scanners-user-agents.data

[Christian Folini]

Hey Eero,

Thank you for the suggestion. I just made this into a pull request.

https://github.com/SpiderLabs/owasp-modsecurity-crs/pull/1039

Please try it out and confirm detection works as intended.
Ideally on github.

Ahoj,

Christian



On Tue, Mar 13, 2018 at 02:20:30PM +0200, Eero Volotinen wrote:
>Hi,
>Please add entry for f-secure radar:
>#[1]https://www.f-secure.com/en/web/business_global/radar
>User-Agent: Mozilla/4.0 (Mozilla/4.0; MSIE 7.0; Windows NT 5.1; FDM;
>SV1; .NET CLR 3.0.04506.30) F-Secure Radar
>br,
>Eero
> 
> References
> 
>1. https://www.f-secure.com/en/web/business_global/radar

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


-- 
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] Error creating rule: Unknown variable: pk_ref)/

[Christian Folini]

No worries. And glad it worked out in the end.

Christian

On Thu, Feb 08, 2018 at 09:21:58AM +, Wisse J.S. (Jeroen) wrote:
> Hey Christian,
> 
> Although you could not figure out what went wrong, I did!
> Somehow I downloaded an old version of the CRS, after downloading the one via 
> the link in your tutorial everything works like it should.
> 
> Thanks for the help and sorry for making such a simple mistake :)
> 
> Jeroen
> 
> -Oorspronkelijk bericht-
> Van: Christian Folini [mailto:christian.fol...@netnea.com] 
> Verzonden: donderdag 8 februari 2018 6:04
> Aan: Wisse J.S. (Jeroen) <js.wi...@zeeland.nl>
> CC: 'owasp-modsecurity-core-rule-set@lists.owasp.org' 
> <owasp-modsecurity-core-rule-set@lists.owasp.org>
> Onderwerp: Re: [Owasp-modsecurity-core-rule-set] Error creating rule: Unknown 
> variable: pk_ref)/
> 
> Hey Jeroen,
> 
> This is an ancient bug actually:
> 
> https://scanmail.trustwave.com/?c=8790=xdr72mAWs0HXAlwBnphS_9XonIB-Ft9nJEyjaeoR0g=https%3a%2f%2fgithub%2ecom%2fSpiderLabs%2fowasp-modsecurity-crs%2fissues%2f181
> 
> It is fixed since the release of CRS 3.
> 
> Given you base on my tutorial which follows that version, I do not know how 
> you could encounter it.
> 
> Regs,
> 
> Christian
> 
> On Wed, Feb 07, 2018 at 01:51:17PM +, Wisse J.S. (Jeroen) wrote:
> >Hello all,
> > 
> > 
> >I get the following error message in Windows event viewer when i try to
> >launch apache with the core ruleset enabled:
> > 
> >Error creating rule: Unknown variable: pk_ref)/
> > 
> > 
> >I am using the following tutorial to setup apache and mod_security:
> > 
> >[1]https://www.netnea.com/cms/apache-tutorial-7_including-modsecurity-c
> >ore-rules/
> > 
> > 
> >HTTPD –V:
> > 
> > 
> >Server version: Apache/2.4.23 (Win64)
> > 
> >Apache Lounge VC11 Server built:   Jul  8 2016 11:33:36
> > 
> >Server's Module Magic Number: 20120211:61
> > 
> >Server loaded:  APR 1.5.2, APR-UTIL 1.5.4
> > 
> >Compiled using: APR 1.5.2, APR-UTIL 1.5.4
> > 
> >Architecture:   64-bit
> > 
> >Server MPM: WinNT
> > 
> >  threaded: yes (fixed thread count)
> > 
> >forked: no
> > 
> >Server compiled with
> > 
> >-D APR_HAS_SENDFILE
> > 
> >-D APR_HAS_MMAP
> > 
> >-D APR_HAVE_IPV6 (IPv4-mapped addresses disabled)
> > 
> >-D APR_HAS_OTHER_CHILD
> > 
> >-D AP_HAVE_RELIABLE_PIPED_LOGS
> > 
> >-D DYNAMIC_MODULE_LIMIT=256
> > 
> >-D HTTPD_ROOT="/apache"
> > 
> >-D SUEXEC_BIN="/apache/bin/suexec"
> > 
> >-D DEFAULT_PIDLOG="logs/httpd.pid"
> > 
> >-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
> > 
> >-D DEFAULT_ERRORLOG="logs/error.log"
> > 
> >-D AP_TYPES_CONFIG_FILE="conf/mime.types"
> > 
> >-D SERVER_CONFIG_FILE="conf/httpd.conf"
> > 
> > 
> >HTTPD –M:
> > 
> > 
> >Loaded Modules:
> > 
> >core_module (static)
> > 
> >win32_module (static)
> > 
> >mpm_winnt_module (static)
> > 
> >http_module (static)
> > 
> >so_module (static)
> > 
> >access_compat_module (shared)
> > 
> >actions_module (shared)
> > 
> >alias_module (shared)
> > 
> >allowmethods_module (shared)
> > 
> >asis_module (shared)
> > 
> >auth_basic_module (shared)
> > 
> >authn_core_module (shared)
> > 
> >authn_file_module (shared)
> > 
> >authz_core_module (shared)
> > 
> >authz_groupfile_module (shared)
> > 
> >authz_host_module (shared)
> > 
> >authz_user_module (shared)
> > 
> >autoindex_module (shared)
> > 
> >env_module (shared)
> > 
> >headers_module (shared)
> > 
> >include_module (shared)
> > 
> >isapi_module (shared)
> > 
> >log_config_module (shared)
> > 
> >mime_module (shared)
> > 
> >negotiation_module (shared)
> > 
> >setenvif_module (shared)
> > 
> >socache_shmcb_module (shared)
> > 
> >proxy_module (shared)
> > 
> >proxy_http_module (shared)
> > 
> >logio_module (shared)
> > 
> >unique_id_module (shared)
> &g

Re: [Owasp-modsecurity-core-rule-set] Error creating rule: Unknown variable: pk_ref)/

[Christian Folini]

Hey Jeroen,

This is an ancient bug actually:

https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/181

It is fixed since the release of CRS 3.

Given you base on my tutorial which follows that version, I do not know
how you could encounter it.

Regs,

Christian

On Wed, Feb 07, 2018 at 01:51:17PM +, Wisse J.S. (Jeroen) wrote:
>Hello all,
> 
> 
>I get the following error message in Windows event viewer when i try to
>launch apache with the core ruleset enabled:
> 
>Error creating rule: Unknown variable: pk_ref)/
> 
> 
>I am using the following tutorial to setup apache and mod_security:
> 
>[1]https://www.netnea.com/cms/apache-tutorial-7_including-modsecurity-c
>ore-rules/
> 
> 
>HTTPD –V:
> 
> 
>Server version: Apache/2.4.23 (Win64)
> 
>Apache Lounge VC11 Server built:   Jul  8 2016 11:33:36
> 
>Server's Module Magic Number: 20120211:61
> 
>Server loaded:  APR 1.5.2, APR-UTIL 1.5.4
> 
>Compiled using: APR 1.5.2, APR-UTIL 1.5.4
> 
>Architecture:   64-bit
> 
>Server MPM: WinNT
> 
>  threaded: yes (fixed thread count)
> 
>forked: no
> 
>Server compiled with
> 
>-D APR_HAS_SENDFILE
> 
>-D APR_HAS_MMAP
> 
>-D APR_HAVE_IPV6 (IPv4-mapped addresses disabled)
> 
>-D APR_HAS_OTHER_CHILD
> 
>-D AP_HAVE_RELIABLE_PIPED_LOGS
> 
>-D DYNAMIC_MODULE_LIMIT=256
> 
>-D HTTPD_ROOT="/apache"
> 
>-D SUEXEC_BIN="/apache/bin/suexec"
> 
>-D DEFAULT_PIDLOG="logs/httpd.pid"
> 
>-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
> 
>-D DEFAULT_ERRORLOG="logs/error.log"
> 
>-D AP_TYPES_CONFIG_FILE="conf/mime.types"
> 
>-D SERVER_CONFIG_FILE="conf/httpd.conf"
> 
> 
>HTTPD –M:
> 
> 
>Loaded Modules:
> 
>core_module (static)
> 
>win32_module (static)
> 
>mpm_winnt_module (static)
> 
>http_module (static)
> 
>so_module (static)
> 
>access_compat_module (shared)
> 
>actions_module (shared)
> 
>alias_module (shared)
> 
>allowmethods_module (shared)
> 
>asis_module (shared)
> 
>auth_basic_module (shared)
> 
>authn_core_module (shared)
> 
>authn_file_module (shared)
> 
>authz_core_module (shared)
> 
>authz_groupfile_module (shared)
> 
>authz_host_module (shared)
> 
>authz_user_module (shared)
> 
>autoindex_module (shared)
> 
>env_module (shared)
> 
>headers_module (shared)
> 
>include_module (shared)
> 
>isapi_module (shared)
> 
>log_config_module (shared)
> 
>mime_module (shared)
> 
>negotiation_module (shared)
> 
>setenvif_module (shared)
> 
>socache_shmcb_module (shared)
> 
>proxy_module (shared)
> 
>proxy_http_module (shared)
> 
>logio_module (shared)
> 
>unique_id_module (shared)
> 
>ssl_module (shared)
> 
>security2_module (shared)
> 
> 
>Does anyone have any idea how I can fix this issue? I tried searching
>google but could not find a solution.
> 
> 
>Met vriendelijke groet,
> 
> 
>Jeroen Wisse | GIS infrastructuur ontwikkeling en beheer
> 
>T. +31 118 631725 | E. [2]js.wi...@zeeland.nl
> 
> 
>cid:image001.png@01D1E102.89F8E770
> 
>Provinciehuis | Abdij 6, 4331 BK Middelburg | +31 118 631011
>Postbus 6001, 4330 LA Middelburg | [3]www.zeeland.nl | [4]@provzeeland
>| [5]facebook.com/provinciezeeland | [6]instagram.com/provinciezeeland
>| [7]dataportaal.zeeland.nl
> 
> References
> 
>1. 
> https://www.netnea.com/cms/apache-tutorial-7_including-modsecurity-core-rules/
>2. mailto:/
>3. http://www.zeeland.nl/
>4. https://twitter.com/provzeeland
>5. https://www.facebook.com/provinciezeeland
>6. https://www.instagram.com/provinciezeeland/
>7. https://dataportaal.zeeland.nl/



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


-- 
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] Substantial and unacceptable latency impact using mod_security and core rule set

[Christian Folini]

Hello Mark,

On Thu, Feb 01, 2018 at 09:27:13PM +, Mark Blackman wrote:
> Thanks, as an update, a second round of testing where logging was reduced
> and where we used a more proven httpd configuration resulted in more
> sensible results, typically 2 ms for a request without scanning and 4 ms for
> a request with scanning.

That is good news and I think also realistic. You can bring it further down
with tuning. But it takes some effort.

> We’re using version 2.9, but I wonder how much improvement you might expect
> for version 3.0 and is version 3.0 considered production ready yet?

ModSec 3.0 has been released as production ready. CRS3 works and namely
the NGINX Plus offering has been using it for quite some time.

The developers claim a seed gain over ModSec 2.9.x yet there are also people
talking of performance issues. Personally, I do not have trustworthy data,
so I do not want to add to any rumours one way or the other. I think it is
best to test for yourself for the time being. Also I expect further
optimizations with the 3.0.1 release.

> Finally, does mod_security use any kind of hashing to cache results?

No, it does not. At least 2.9 does not and I do not think I have read of
3.0 bringing this. It's an interesting feature, but also one that is very
hard to get right, namely as this is a security product and hashing/caching
often get into a conflict with one another.

> On the
> assumption that computing a digest of request is faster than running a large
> series of regexes over it. In other words, there’s no point repeatedly
> running the same rules over the same request line when it comes in each
> time. Alternately, can mod_security exploit Apache server-side caching to
> cache results?

Again, no.

However, if you really want to speed things up and you have a good
understanding of your application, authentication is in place and you really
know whom you are talking to, then you could think of bypassing certain
rules under certain conditions. That is a trade-off between security and
speed, but given the complete rule language is at your disposal interesting
constructs can be created.

Cheers,

Christian


-- 
Human beings, who are almost unique in having the ability to learn
from the experience of others, are also remarkable for their apparent
disinclination to do so.
--- Douglas Adams
___
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] RegEx in CRS 3.0.2 942200 too broad?

[Christian Folini]

Hi Ken,

We used to have ML problems, but it seems at least your message went through.
Hopefully OWASP HQ has fixed it for good.

I confirm the FP here and can only add that 942200 has been set to PL2
for causing FPs from time to time.

Franziska Bühler disassembled the regexes of the SQL rules, so you can
take a better look at the sources behind the performance optimized
regexes:

https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.1/dev/util/regexp-assemble/regexp-942200.data

Maybe she can chime in here and add her thoughts on this rule.

Best,

Christian

On Wed, Jan 10, 2018 at 11:23:48AM -0800, Ken Brucker wrote:
>I've been looking at some false positives related to rule 942200.
> 
>Side note, I'm running CRS 3.0.2 but the rules still have a version
>3.0.0 tag. I was surprised to see that.
>Here's an exemplar from the audit file:
>Message: Warning. Pattern match
>"(?i:(?:,.*?[)\\da-f\"'`][\"'`](?:[\"'`].*?[\"'`]|\\Z|[^\"'`]+))|(?:\\W
>select.+\\W*?from)|((?:select|create|rename|truncate|load|alter|delete|
>update|insert|desc)\\s*?\\(\\s*?space\\s*?\\())" at ARGS:data[]. [file
>"/etc/httpd/modsecurity.d/crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI
>.conf"] [line "649"] [id "942200"] [rev "2"] [msg "Detects MySQL
>comment-/space-obfuscated injections and backtick termination"] [data
>"Matched Data: ,4947,4937,4935,4929,4463,4430,5905,5766,7878,7570\x22]
>found within ARGS:data[]: [gallery columns=\x225\x22
>size=\x22medium\x22
>ids=\x224953,4947,4937,4935,4929,4463,4430,5905,5766,7878,7570\x22]"]
>[severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy
>"8"] [tag "application-multi"] [tag "language-multi"] [tag
>"platform-multi"] [tag "attack-sqli"] [tag
>"OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag
>"OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"] [tag
>"paranoia-level/2"]
>After looking at this rule a bit, it will trigger on a string like:
>To quote William Shakespeare, "to be, or not to be".
>The first alternative in the regex matches a very broad range of text
>and seems far too general. Is this intentional? It looks like the
>intent is to capture variations on quoted numbers but it's going above
>and beyond.
> 
>The rule:
> 
>SecRule
>REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|ARGS_NAM
>E
>S|ARGS|XML:/*
>"(?i:(?:,.*?[)\da-f\"'`][\"'`](?:[\"'`].*?[\"'`]|\Z|[^\"'`]+))|(?:
>\Wselect.+\W*?from)|((?:select|create|rename|truncate|load|alter|delete
>|update|i
>nsert|desc)\s*?\(\s*?space\s*?\())" \
>"phase:request,\
>rev:'2',\
>ver:'OWASP_CRS/3.0.0',\
>maturity:'9',\
>accuracy:'8',\
>capture,\
>t:none,t:urlDecodeUni,\
>block,\
>msg:'Detects MySQL comment-/space-obfuscated injections and
>backtick ter
>mination',\
>id:942200,\
>tag:'application-multi',\
>tag:'language-multi',\
>tag:'platform-multi',\
>tag:'attack-sqli',\
>tag:'OWASP_CRS/WEB_ATTACK/SQL_INJECTION',\
>tag:'WASCTC/WASC-19',\
>tag:'OWASP_TOP_10/A1',\
>tag:'OWASP_AppSensor/CIE1',\
>tag:'PCI/6.5.2',\
>tag:'paranoia-level/2',\
>logdata:'Matched Data: %{TX.0} found within
>%{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
>severity:'CRITICAL',\
>setvar:'tx.msg=%{rule.msg}',\
>setvar:tx.sql_injection_score=+%{tx.critical_anomaly_score},\
>setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},\
> 
>setvar:'tx.%{[1]rule.id}-OWASP_CRS/WEB_ATTACK/SQLI-%{matched_var_name}=
>%{tx.0}'"
> 
> References
> 
>1. http://rule.id/

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


-- 
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] Substantial and unacceptable latency impact using mod_security and core rule set

[Christian Folini]

Mark,

Latency is an issue and the amount depends on the server. Factor 5 is a bit
steep, but still possible.

My mileage is usually a 5-10% hit on the throughput of a reverse proxy. If
your server serves only static files and no backend connection, then your
numbers could be real.

I would want to look at the individual requests, though.
Is 40 ms the mean? Is it some requests or all of them? If some, which ones?

The tutorials at https://www.netnea.com come with an extended Apache Access
Log format that lets you gauge the performance impact a bit better. Once you
have the data, you can dig down and identify the individual requests / rules
that cause the delay. Raising the debug-log-level on individual requests let
you identify the individual rule of an individual request with a high
performance impact quite easily. And then tune them away.

Also, CRS3 comes with a feature called Sampling Mode that allows you to run
the rules only on a percentage of the requests. This allows you to test / tune
with real world data without bringing the whole service down. This is
specifically aimed at services where the performance impact is unclear
and a potential risk.

Performance issues are generally solvable with a compromise between
performance and security. And ModSec gives you a ton of performance
information so it is generally possible to nail down the problem.

Hope this helps for a start. If you need more infos, then just ask.

Good luck!

Christian

On Mon, Dec 18, 2017 at 01:24:48PM +, Mark Blackman wrote:
> Hi,
> 
> In an initial set of performance tests with mod_security 2.9.2 and the core
> rule set under Apache 2.2.34, we are seeing the latency for individual
> requests rise from 8 milliseconds to 40 milliseconds which seems like too
> much.   Is this kind of latency impact to be expected? What options do we
> have for reducing it without throwing away mod_security?
> 
> - Mark ___
> 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

-- 
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] Web Application Firewall Bypassing

[Christian Folini]

Hello Brent,

Thank you for the link to the presentation and the article.

Khalil Bijjou also presented at DeepSec Vienna in November and I have been in
touch with him briefly afterwards.

I used the tool a bit, yet it is not quite easy as the documentation is
lacking in my eyes (--help does not give you all the options. You need to
look in the source code) and I could not get my head around the fuzzing
options. Also the article on blackmoreops is very brief and the video
does not answer all the questions.

So what I would really love to see is a demonstration of this WAFNinja tool
against CRS3 with a report on the bypasses discovered by WAFNinja.

I should probably dig deeper myself, but too much on my plate these days.

Ahoj,

Christian




On Thu, Dec 14, 2017 at 09:40:30AM +0200, Brent Clark wrote:
> Good day Guys
> 
> I just thought I would share a video tutorial that may be of interest.
> 
> 
> https://www.youtube.com/watch?time_continue=4=SD7ForrwUMY
> 
> I came to know of the above tut via
> 
> https://www.blackmoreops.com/2017/12/13/bypass-web-application-firewall-using-wafninja/
> 
> Hope this helps and is of some help to the project and community.
> 
> Regards
> 
> Brent
> 
> 
> 
> ___
> 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

-- 
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] Setting tx.anomaly_score before including crs-setup.conf somehow works, should it?

[Christian Folini]

Cristian,

You are getting there. Yet the DebugLogLevel is still not high enough.
Put it to 9and then you grep for the threshold variable in the logfile.
This will allow you to see which rule sets the threshold and in what order.

It is possible it's a phase issue. But when I looked over it in your
previous message the suspicion was not confirmed. But I am not ruling it out.

Ahoj,

Christian

On Mon, Dec 04, 2017 at 07:03:33PM +0100, Cristian Mammoli wrote:
>Ok, so this is my config:
>End of /etc/httpd/conf/httpd.conf:
>IncludeOptional conf.d/*.conf
>[root@waf01 ~]# ls -1 /etc/httpd/conf.d/
>000_mod_evasive.conf
>000_mod_security.conf
>000_mod_ssl.conf
>000_mod_status.conf
>vhost1.conf
>vhost2.conf
>ecc
>End of /etc/httpd/conf.d/000_mod_security.conf:
>IncludeOptional /etc/httpd/modsecurity.d/*.conf
>IncludeOptional /etc/httpd/crs/crs-setup.conf
>IncludeOptional /etc/httpd/crs/rules/*.conf
>[root@waf01 ~]# ls -1 /etc/httpd/modsecurity.d/
>000_whitelist_rules.conf
>cutwail_zenobi.data
>local_rules.confnou
>runav.conf
>whitelist_ip.data
>In /etc/httpd/modsecurity.d/local_rules.conf I have:
># Debug test
>SecRule REMOTE_ADDR "@ipMatch 217.133.31.142" \
>  "msg:'Client IP in Test list',\
>  severity:'CRITICAL',\
>  id:10099,\
>  phase:request,\
>  pass,\
>  t:none,\
>  tag:'application-multi',\
>  tag:'language-multi',\
>  tag:'platform-multi',\
>  tag:'attack-reputation-ip',\
>  setvar:'tx.msg=%{rule.msg}',\
>  setvar:tx.anomaly_score=+20,\
> 
>setvar:tx.%{rule.id}-AUTOMATION/MALICIOUS-%{matched_var_name}=%{matched
>_var}"
>Then I did
>curl [1]https://www.vhost.com and the request got rejected (20/11
>score, 11 is my threshold)
>Now I have the full debug trace of the request but it's a huge amount
>of data.
>I think the culprit is this:
>[2]https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Proc
>essing_Phases
>Note : Keep in mind that rules are executed according to phases, so
>even if two rules are adjacent in a configuration file, but are set to
>execute in different phases, they would not happen one after the other.
>The order of rules in the configuration file is important only within
>the rules of each phase. This is especially important when using the
>skip and skipAfter actions.
>My rules use phase:request, which I suppose is equivalent to phase:2,
>while REQUEST-901-INITIALIZATION.conf are all phase:1
>Anyway this is the (mostly cleaned) log:
>Starting phase REQUEST_HEADERS.
>This phase consists of 159 rule(s).
>Recipe: Invoking rule 5589ef173f78; [file
>"/etc/httpd/conf.d/000_mod_security.conf"] [line "27"] [id "20"].
>Recipe: Invoking rule 5589ef1d7ed0; [file
>"/etc/httpd/conf.d/000_mod_security.conf"] [line "34"] [id "21"].
>Recipe: Invoking rule 5589ef278288; [file
>"/etc/httpd/modsecurity.d/000_whitelist_rules.conf"] [line "3"] [id
>"10050"]. <- This is my only phase:1 rule
>Recipe: Invoking rule 5589f629ba98; [file
>"/etc/httpd/crs/crs-setup.conf"] [line "263"] [id "900110"].
>Recipe: Invoking rule 5589f62813a0; [file
>"/etc/httpd/crs/crs-setup.conf"] [line "303"] [id "900130"].
>Recipe: Invoking rule 5589f62c4e70; [file
>"/etc/httpd/crs/crs-setup.conf"] [line "329"] [id "900200"].
>Recipe: Invoking rule 5589f62c65a0; [file
>"/etc/httpd/crs/crs-setup.conf"] [line "342"] [id "900220"].
>Recipe: Invoking rule 5589f62e8488; [file
>"/etc/httpd/crs/crs-setup.conf"] [line "542"] [id "900500"].
>Recipe: Invoking rule 5589f62e42d0; [file
>"/etc/httpd/crs/crs-setup.conf"] [line "622"] [id "900700"].
>Recipe: Invoking rule 5589f6329f58; [file
>"/etc/httpd/crs/crs-setup.conf"] [line "679"] [id "900960"].
>Recipe: Invoking rule 5589f63474d0; [file
>"/etc/httpd/crs/crs-setup.conf"] [line "774"] [id "900990"].
>Recipe: Invoking rule 5589f6366d28; [file
>"/etc/httpd/crs/rules/REQUEST-901-INITIALIZATION.conf"] [line "61"] [id
>"901001"].
>Recipe: Invoking rule 5589f6351348; [file
>"/etc/httpd/crs/rules/REQUEST-901-INITIALIZATION.conf"] [line "78"] [id
>"901100"].
>Recipe: Invoking rule 5589f63529d0; [file
>"/etc/httpd/crs/rules/REQUEST-901-INITIALIZATION.conf"] [line "86"] [id
>"901110"].
>Recipe: Invoking rule 5589f637c180; [file
>"/etc/httpd/crs/rules/REQUEST-901-INITIALIZATION.conf"] [line "94"] [id
>"901120"].
>Recipe: Invoking rule 5589f63c78d0; [file
>"/etc/httpd/crs/rules/REQUEST-901-INITIALIZATION.conf"] [line "102"]
>[id "901130"].
>Recipe: Invoking rule 5589f639cd48; [file
>"/etc/httpd/crs/rules/REQUEST-901-INITIALIZATION.conf"] [line "110"]
>[id "901140"].
>Recipe: Invoking rule 5589f639e2c8; [file
>"/etc/httpd/crs/rules/REQUEST-901-INITIALIZATION.conf"] [line "117"]
>[id 

Re: [Owasp-modsecurity-core-rule-set] Setting tx.anomaly_score before including crs-setup.conf somehow works, should it?

[Christian Folini]

Hi,

On Mon, Dec 04, 2017 at 04:07:00PM +0100, Cristian Mammoli wrote:
> In REQUEST-901 thresholds are set to default if not already set, I know.

Sorry, I jumped to conclusions too quickly then.

> There are no conditionals like in 901100.
> 
> What am I missing?

The problem sounds as if you would have to raise the debug log level and
work your way through the file to see which rule sets which value and in
what order.

Ahoj,

Christian


> 
> Ty
> 
> 
> Il 04/12/2017 14:47, Christian Folini ha scritto:
> > Hey Cristian,
> > 
> > No, this works perfectly. Let me tell you why:
> > 
> > The crs-setup.conf does not actually set the threshold. Instead the
> > REQUEST-901 initialization file sets the threshold to the default value
> > if it is not set.
> > 
> > You are setting the anomaly score in your rule file in modsecurity, so no
> > need to set it to the default during the initialization.
> > 
> > This is very close to what I personally favor: Setting it in the server
> > config and not in an include. That way the threshold is always in plane 
> > sight.
> > Same for paranoia level btw.
> > 
> > Ahoj,
> > 
> > Christian

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

[Owasp-modsecurity-core-rule-set] Update tonight / today: Monthly Project Chat

[Christian Folini]

Hi there,

I just realized, there has not been a reminder with regards to today's project
chat.

Here you go: 20:30 CET (14:30 EDT, 18:30 GMT)
on Freenode IRC, channel #modsecurity
If you're interested in learning more about the project or you are
interested in a particular issue/feature, we'd love to hear from you.
The current agenda can be found here:

https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/972

Take a peek, there is a nice surprise coming up!

Hope to see you there,

Christian

-- 
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] Setting tx.anomaly_score before including crs-setup.conf somehow works, should it?

[Christian Folini]

Hey Cristian,

No, this works perfectly. Let me tell you why:

The crs-setup.conf does not actually set the threshold. Instead the
REQUEST-901 initialization file sets the threshold to the default value
if it is not set.

You are setting the anomaly score in your rule file in modsecurity, so no
need to set it to the default during the initialization.

This is very close to what I personally favor: Setting it in the server
config and not in an include. That way the threshold is always in plane sight.
Same for paranoia level btw.

Ahoj,

Christian


On Mon, Dec 04, 2017 at 02:21:39PM +0100, Cristian Mammoli wrote:
> Hi, I'm using CRS 3.0.2 on ModSec 2.9.2
> 
> I'm including crs like this:
> 
> [root@waf01 ~]# tail -n 3 /etc/httpd/conf.d/000_mod_security.conf
> IncludeOptional /etc/httpd/modsecurity.d/*.conf
> IncludeOptional /etc/httpd/crs/crs-setup.conf
> IncludeOptional /etc/httpd/crs/rules/*.conf
> 
> I'm using rules in modsecurity.d/ for custom rules and so on
> I would expect that setting tx.anomaly_score in a rule file in modsecurity.d
> would make no sense, since the var get reset in
> crs/rules/REQUEST-901-INITIALIZATION.conf (901200) which gets loaded AFTER
> my rules.
> 
> But it somehow works, for example this rule in
> modsecurity.d/local_rules.conf
> 
> # Spamhaus XBL (scoring)
> SecRule REMOTE_ADDR "@rbl xbl.spamhaus.org" \
>   "msg:'Client IP in xbl.spamhaus.org.',\
>   severity:'CRITICAL',\
>   id:10003,\
>   phase:request,\
>   pass,\
>   t:none,\
>   tag:'application-multi',\
>   tag:'language-multi',\
>   tag:'platform-multi',\
>   tag:'attack-reputation-ip',\
>   setvar:'tx.msg=%{rule.msg}',\
>   setvar:tx.anomaly_score=+10,\
> setvar:tx.%{rule.id}-AUTOMATION/MALICIOUS-%{matched_var_name}=%{matched_var}
> 
> The additional 10 points get counted in the final TX:inbound_anomaly_score
> and causes the request to be rejected.
> 
> This is _exactly_ what I want :) But as far as I understand it shouldn't
> work or I don't get in which order the rules are included and evaluated
> ___
> 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

-- 
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] missing tag OWASP_CRS

[Christian Folini]

Hey Philippe,

On Thu, Nov 30, 2017 at 10:13:46AM +0100, Philippe Naudin wrote:
> This is because 3.0.0 rules had a tag starting with OWASP_CRS/, and I
> use this tag to exclude all C.R.S. rules in rare cases like :
> ctl:ruleRemoveTargetByTag=OWASP_CRS;ARGS:sql_query
> But this tag is gone in some rules of version 3.0.2 (for exemple rules
> 921110 and following in REQUEST-921-PROTOCOL-ATTACK.conf).

I do not see this widespread tag to be in use on 921110 in 3.0.0 nor
in 3.0.2. In fact the whole 921xxx rule file did not see any change between
these two versions.

Tags are not used in a systematic manner in CRS unfortunately. But a big
rule cleanup project has finished and systematization of the tagging is
high on the wishlist now.

If you want to disable CRS completely for a given request, there are
multiple options. A very good one is to remove all rule ids 
from 90-99 while in phase 1.
e.g.: ctl:ruleRemoveTargetById=90-99;ARGS:sql_query

Ahoj,

Christian




> 
> Is there a better way to achieve this (completely excluding an element
> of a request from exam) ?
> 
> Thanks for your advices,
> 
> -- 
> Philippe Naudin
> ___
> 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

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

[Owasp-modsecurity-core-rule-set] OWASP Top 10 is out - featuring ModSecurity and Core Rule Set

[Christian Folini]

Hi there,

The new edition of the OWASP Top Ten has been released.

https://owasp.blogspot.ch/2017/11/owasp-is-pleased-to-announce-release-of.html

It features ModSecurity and the OWASP ModSecurity Core Rule Set under 
A10: Insufficient Logging & Monitoring under "How to Prevent":

"... There are commercial and open source application protection
frameworks such as OWASP AppSensor, web application
firewalls such as ModSecurity with the OWASP ModSecurity
Core Rule Set, and log correlation software with custom
dashboards and alerting."

Of course we all know, that ModSec and CRS can do a lot more than logging,
but as you probably know, OWASP is not especially friendly towards the
use of Web Application Firewalls and getting into A10 is already a big
step forward.

I do not know if Trustwave has been lobbying for the inclusion, but I do
know that we owe a lot of this to Osama Elnaggar who played an important
role in the review of the document.

In fact I was ready to get involved myself, but Osama asked me to keep a
low profile and not to raise any suspicion and a potential backfire.
This strategy worked perfectly well. Well done!

I plan to follow up with a blog post on https://coreruleset.org to take
up the momentum and explain to OWASP Top Ten readers just how we can support
them. Maybe Trustwave can do the same on its blog.

Best regards,

Christian

P.S. On a similar note, four new members of the OWASP board of directors
have been announced today as well. I have spoken about CRS with three
of them before and I think they see our project in a favorable light.



-- 
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] No logging for SQLi rules

[Christian Folini]

Hey Brent,

There is the sanitize group of actions that applies to the Audit log and will
replace certain parameter values with asterisks.

However, the alert message written to the Apache Error-Log and the Debug-Log
(Level 3) are unaffected by this.

It's one of the major issues I have with ModSecurity.

The following issue described this shortcoming:
https://github.com/SpiderLabs/ModSecurity/issues/1132

Ahoj,

Christian

On Tue, Nov 07, 2017 at 05:30:43PM +0200, Brent Clark wrote:
> Good day Guys
> I'm in bit of a pickle, in that, I've received a request that no modsecurity 
> log
> s may contains passwords or attempted passwords etc in the log.
> This is for if we get audited.
> 
> I can set:
> SecDefaultAction "phase:1,deny,nolog,auditlog"
> SecDefaultAction "phase:2,deny,nolog,auditlog"
> 
> But then I would loose visibility of other issues.
> 
> This is mostly for the SQLi rules that I am trying to tackle.
> 
> Does anyone know of a way of disabling logging, without having to search and 
> rep
> lace the rules provided by Owasp.
> 
> If anyone can assist, it would be greatly appreciated.
> 
> Regards
> Brent Clark

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


-- 
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] mod_security_crs 2.2.9 modsecurity_crs_48_local_exceptions.conf question

[Christian Folini]

Hello,

I see how this tuning approach via negative scoring is meant to work. However
it is quite botched if you excuse my wording. It actually looks like a huge
backdoor. All you need to do is an alert on 981172 and then submit a
cookie Mycookie1/2/3/4 and then get a discount of -20 anomaly scoring point
for each cookie. Bonus points: Each of the four cookies can be submitted more
than once. That should have you covered for really crazy attacks.

Also, your exception does not log at all, so I can not really tell if it
triggered at all. Your "H" audit log blog only points to the rule 981172
that was executed, but the way you handle it in the exceptions you did not
attempt to suppress this alert, but attempted to reduce the score again
post factum.

Under the line, I think you need to start over from scratch. Also, life is
much easier with CRS3 that has a ton less false positive. Namely the annoying
rule 981172 has been banned into the rarely activated Paranoia Level 4.
Unfortunately, CRS3 depends on ModSec 2.8.0 (unless you want to comment
out two key rules by hand in the rule set).

Ahoj,

Christian


On Fri, Oct 20, 2017 at 12:48:41PM +0200, devzero2000 wrote:
>Hi to all
> 
>  just updated a Centos 7.4 to mod_security_crs 2.2.9 and mod_security
>  2.7.3-5. In the
>  
> /etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_48_local_exceptions.conf
>  file I have a rule like this that worked in earlier versions but no
>  longer.
> 
>  Any idea ?
> 
>  Thank you very much
> 
>  SecRule TX:'/^981172.*/'             "@rx .*"
>  "chain,phase:2,t:none,nolog,noauditlog,pass,msg:'WHITELISTING  
>  %{rule.id}: Allowed false positive %{TX:0}',severity:'6',id:450010"
> 
>  SecRule
>  REQUEST_COOKIES:'/^(Mycookie1|Mycookie2|Mycookie3|Mycookie4)/'    
>  "!^$"   "t:none,setvar:!tx.%{tx.1},setvar:tx.anomaly_score=-20"
> 
>   
> 
>  Log
> 
>   
> 
>  --9d781c6e-H--
> 
>  Message: Warning. Pattern match
>  
> "([\\~\\!\\@\\#\\$\\%\\^\\&\\*\\(\\)\\-\\+\\=\\{\\}\\[\\]\\|\\:\\;\"\\'\\\xc2\xb4\\\xe2\x80\x99\\\xe2\x80\x98\\`\\<\\>].*?){8,}"
>  at REQUEST_COOKIES:Mycookie1. [file
>  
> "/etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf"]
>  [line "157"] [id "981172"] [rev "2"] [msg "Restricted SQL Character
>  Anomaly Detection Alert - Total # of special characters exceeded"] [data
>  "Matched Data: + found within REQUEST_COOKIES:Mycookie1:
>  
> ve11n8OdWASErRyEZrw+29j8ihH2+RlST465bWRDDityPELrC/mXxSDAELEf1CSGT+knYFgt/3EWotqMvcFBiLlX0YDfDNxEnZ32pBzsp3B+45oPGeOc/lx16tGOY8Q+u1sfbcVEzHeNIpebO3DephHXQ3fz0v66Qh2Qc5umtNSPP4p4pVd7C3gxxuspE4wWJlN7uF2iwVxkm+VN1W6wRt4USriw9aQQX0Csz1wKQdMlK5nv/S+uK+QBA7OdVsfOK7BXVrrXkLo7J9GS9oGYrnrkzNZ5rzOZRyllaqYRVV2pnm0qrdEq0Fiont4Z2+iHYEpnSuQRJpGi+mAL+FMnI1TNOlxIAzOgwV0ENaKXOgyQe3JVHStFc5cVVCptTtkL"]
>  [ver "OWASP_CRS/2.2.9"] [maturity "9"] [accuracy "8"] [tag
>  "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"]
> 
>  Apache-Handler: proxy-server
> 
>  Stopwatch: 1508316101057039 22395601 (- - -)
> 
>  Stopwatch2: 1508316101057039 22395601; combined=49089, p1=638, p2=48093,
>  p3=3, p4=98, p5=177, sr=141, sw=80, l=0, gc=0
> 
>  Response-Body-Transformed: Dechunked
> 
>  Producer: ModSecurity for Apache/2.7.3 (http://www.modsecurity.org/);
>  OWASP_CRS/2.2.9.
> 
>  Server: Apache
> 
>  Engine-Mode: "ENABLED"

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

[Owasp-modsecurity-core-rule-set] OWASP Top 10 RC2 is out - ModSecurity and CRS are referenced

[Christian Folini]

Hello,

The RC2 for the 2017 edition of OWASP Top 10 is out.

The new issue A10: Insufficient Logging & Monitoring mentions
ModSecurity and CRS.

https://github.com/OWASP/Top10/blob/master/2017/OWASP%20Top%2010%202017%20RC2%20Final.pdf

I think thanks are due to Osama Elnaggar who worked behind the lines to 
get us into the document.

Best,

Christian

-- 
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] DINAcon Hacknight Oct 20 in Berne, Switzerland

[Christian Folini]

Hello,

This is a reminder, that Fränzi and I will be at the DINAcon Hacknight tonight
(Middle European Time). If anybody wants to join, then come on site, or
get in touch with us for remote participation.

We have plans to work on existing PRs, look into issues and get down to
business with testing.

Ahoj,

Christian

On Sat, Oct 14, 2017 at 11:56:36AM +0200, Christian Folini wrote:
> Hi there,
> 
> Fränzi Bühler and I will take part at the HackNight at the Swiss DINAcon
> next Friday in Berne, from 6pm local time.
> 
> We have plenty of PRs to review, but we also plan to work on new ideas.
> 
> Having more people join us on site would of course be fun, but participating
> remotely could also be an option. If interested, then please get in join.
> 
> Here is the tweet introducing the idea. Please retweet.
> https://twitter.com/CoreRuleSet/status/919138876819759107
> 
> Ahoj,
> 
> Christian
> 
> 
> -- 
> 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

-- 
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] CRS3 Issues - modsecurity cannot detect SQLi in request body (HTTP POST)

[Christian Folini]

Hey Jeff,

Could you raise you SecDebugLogLevel to 9 and then post your payload and
select that part of the debug log that handles the rule 942100?

Also: Said libinjection rules does not work on the raw request body (your
post implies this somehow). But it only works on argument names and
argument values.

Best,

Christian

On Tue, Oct 17, 2017 at 12:20:40PM -0700, Jeff Liu wrote:
>Dear CRS leaders,
>I am trying to test the latest version of rule set (version 3) with
>modsecurity to detect SQLi injection. I find that the CRS is able to
>correctly detect SQLi attacks in request headers (HTTP GET), while it's
>not able to detect any SQLi attacks in the request body (HTTP POST) even
>for the most simple ones such as "or 1=1--".
>I checked some online solutions and already set the SecRequestBodyAccess
>On but it still doesn't work.
>Could anyone help me with it? Thanks in advance!
>Regards,
>Tianyu

> ___
> 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] XSS Attack and PHP source code leakage with Nextcloud 10.0.3 (HTTP methods and content-types allowed)

[Christian Folini]

Hey Aurel,

We have a pull request waiting for my review that addresses Nextcloud.

https://github.com/SpiderLabs/owasp-modsecurity-crs/pull/899

The idea is to get a rule exclusion package for Nextcloud. Ideally you could
give that contributed pull request a go and report back your experience
in the pull request. I'll review and eventually merge, but I do not
use Nextcloud, so my insight will be limited.

Ahoj,

Christian


On Tue, Oct 17, 2017 at 01:52:34PM +0200, Aurel wrote:
> Dear all,
> 
> I am trying to make ModSecurity v3/Nginx 1.12.1 working together with 
> NextCloud 10.0.3 on a Debian Jessie. I am using the latest available code 
> from the git repository for ModSecurity v3 and its nginx connector and the 
> owasp 3.0.2 rules.
> 
> I am getting the following ModSecurity exceptions when refreshing the 
> administration page of NextCloud which execute some automatic testing on 
> webdav and others. I don’t know how to make ModSecurity working with 
> Nextcloud :
> 
> None None None
> None 949110 Inbound Anomaly Score Exceeded (Total Score: 15)
> None 920420 Request content type is not allowed by policy
> None 980130 Inbound Anomaly Score Exceeded (Total Inbound Score: 15 - 
> SQLI=0,XSS=15,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): XSS Filter - Category 
> 3: Attribute Vector
> None 941130 XSS Filter - Category 3: Attribute Vector
> None 953120 PHP source code leakage
> None 941100 XSS Attack Detected via libinjection
> 
> To resume the details given below, I got two problems :
>   1) ModSecurity: Warning. Matched "Operator `Rx' with parameter [msg 
> "PHP source code leakage"] 
>   2) Warning. detected XSS using libinjection [msg "XSS Attack Detected 
> via libinjection"] [data "Matched Data: requesttoken found within ARGS: version: "1.0"?> xmlns:d="DAV:">"]
> 
> In crs-setup-cloud.conf I allowed all the HTTP methods and content-types. Its 
> works as it reduced a lot my previous exceptions on HTTP methods and 
> content-types but still these two problems are occurring. How should I 
> process to make Nextcloud working and let ModSecurity as tightened as 
> possible ?
> 
> Thanks for your help,
> 
> A.
> 
> Here my crs-setup-cloud.conf :
> 
> SecDefaultAction "phase:1,log,auditlog,pass"
> SecDefaultAction "phase:2,log,auditlog,pass"
> SecAction \
>  "id:900110,\
>   phase:1,\
>   nolog,\
>   pass,\
>   t:none,\
>   setvar:tx.inbound_anomaly_score_threshold=7,\
>   setvar:tx.outbound_anomaly_score_threshold=6"
> SecAction \
>  "id:900200,\
>   phase:1,\
>   nolog,\
>   pass,\
>   t:none,\
>   setvar:'tx.allowed_methods=GET HEAD POST OPTIONS PROPFIND PUT REPORT DELETE 
> MKCOL CHECKOUT COPY LOCK MERGE MKACTIVITY MOVE PROPPATCH UNLOCK PUT PATCH'"
> SecAction \
>  "id:900220,\
>   phase:1,\
>   nolog,\
>   pass,\
>   t:none,\
>   
> setvar:'tx.allowed_request_content_type=application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/soap+xml|application/x-amf|application/json|application/octet-stream|text/plain'"
> SecCollectionTimeout 600
> SecAction \
>  "id:900990,\
>   phase:1,\
>   nolog,\
>   pass,\
>   t:none,\
>   setvar:tx.crs_setup_version=302 »
> 
> Here my ModSecurity conf file :
> 
> SecRuleEngine On
> SecRequestBodyAccess On
> SecRule REQUEST_HEADERS:Content-Type "(?:application(?:/soap\+|/)|text/)xml" \
>  
> "id:'20',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"
> SecRule REQUEST_HEADERS:Content-Type "application/json" \
>  
> "id:'21',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON"
> SecRequestBodyLimit 13107200
> SecRequestBodyNoFilesLimit 131072
> SecRequestBodyLimitAction Reject
> SecRule REQBODY_ERROR "!@eq 0" \
> "id:'22', phase:2,t:none,log,deny,status:400,msg:'Failed to parse request 
> body.',logdata:'%{reqbody_error_msg}',severity:2"
> SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
> "id:'23',phase:2,t:none,log,deny,status:400, \
> msg:'Multipart request body failed strict validation: \
> PE %{REQBODY_PROCESSOR_ERROR}, \
> BQ %{MULTIPART_BOUNDARY_QUOTED}, \
> BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
> DB %{MULTIPART_DATA_BEFORE}, \
> DA %{MULTIPART_DATA_AFTER}, \
> HF %{MULTIPART_HEADER_FOLDING}, \
> LF %{MULTIPART_LF_LINE}, \
> SM %{MULTIPART_MISSING_SEMICOLON}, \
> IQ %{MULTIPART_INVALID_QUOTING}, \
> IP %{MULTIPART_INVALID_PART}, \
> IH %{MULTIPART_INVALID_HEADER_FOLDING}, \
> FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'"
> SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
> "id:'24',phase:2,t:none,log,deny,msg:'Multipart parser detected a 
> possible unmatched boundary.'"
> SecPcreMatchLimit 1000
> SecPcreMatchLimitRecursion 1000
> SecRule TX:/^MSC_/ "!@streq 0" \
> "id:'25',phase:2,t:none,deny,msg:'ModSecurity internal error 
> flagged: %{MATCHED_VAR_NAME}'"
> SecResponseBodyAccess On
> SecResponseBodyMimeType text/plain text/html text/xml
> SecResponseBodyLimit 524288
> SecResponseBodyLimitAction ProcessPartial
> SecTmpDir /data/tmp/www/mydomain.com/cloud/modsecurity
> 

[Owasp-modsecurity-core-rule-set] DINAcon Hacknight Oct 20 in Berne, Switzerland

[Christian Folini]

Hi there,

Fränzi Bühler and I will take part at the HackNight at the Swiss DINAcon
next Friday in Berne, from 6pm local time.

We have plenty of PRs to review, but we also plan to work on new ideas.

Having more people join us on site would of course be fun, but participating
remotely could also be an option. If interested, then please get in join.

Here is the tweet introducing the idea. Please retweet.
https://twitter.com/CoreRuleSet/status/919138876819759107

Ahoj,

Christian


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

[Owasp-modsecurity-core-rule-set] Trustwave Position: Security Researcher - ModSecurity

[Christian Folini]

Hi there,

Just caught a tweet about a position for a Security Researcher
with Trustwave:

https://jobs.jobvite.com/careers/trustwave/job/oHPI5fw3?__jvst=Employee&__jvsd=sTFykfwa&__jvsc=Twitter=ntlpMBw5

Would be cool if some active member from the community would apply.

Cheers,

Christian

-- 
Demagoguery is easy.
-- Bruce Schneier
___
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] Up tonight (Monday): Monthly Project Chat

[Christian Folini]

Obviously, one should not copy too much.

I meant Monday, October 2. The first Monday of every month, actually.

On Mon, Oct 02, 2017 at 06:42:46AM +0200, Christian Folini wrote:
> Tonight is our monthly project chat. Monday, September 4, we'll do our 
> regular 
> Core Rule Set project chat.
> 20:30 CET (14:30 EDT, 18:30 GMT)
> on Freenode IRC, channel #modsecurity
> 
> The development is taking up speed with new contributors submitting
> PRs (and a lot of review work to be done). So there is a lot to talk about.
> 
> Hope to see / read many of you tonight!
> 
> Cheers,
> 
> Christian
> 
> -- 
> 1 seat for ModSec course in London and 
> 1 seat for ModSec course in Zurich still free!
> 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

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

[Owasp-modsecurity-core-rule-set] Up tonight (Monday): Monthly Project Chat

[Christian Folini]

Hi there,

Tonight is our monthly project chat. Monday, September 4, we'll do our regular 
Core Rule Set project chat.
20:30 CET (14:30 EDT, 18:30 GMT)
on Freenode IRC, channel #modsecurity

The development is taking up speed with new contributors submitting
PRs (and a lot of review work to be done). So there is a lot to talk about.

Hope to see / read many of you tonight!

Cheers,

Christian

-- 
1 seat for ModSec course in London and 
1 seat for ModSec course in Zurich still free!
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

[Owasp-modsecurity-core-rule-set] Up Tomorrow (Monday): Monthly Project Chat

[Christian Folini]

Hi there,

I almost forgot the reminder for our monthly chat.
Monday, September 4, we'll do our regular Core Rule Set project chat.
20:30 CET (14:30 EDT, 18:30 GMT)
on Freenode IRC, channel #modsecurity

Hope to see / read many of you tomorrow!

Cheers,

Christian

-- 
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] Remove rule 970901 - CRS 2.2.8

[Christian Folini]

On Wed, Aug 23, 2017 at 10:31:17PM +0200, Osama Elnaggar wrote:
>Try changing the phase to phase 1 as phase 4 rules are for processing the
>response body and the request has already reached your backend by phase 4.

Yeah, but the rule in question is also phase 4:

modsecurity_crs_50_outbound.conf:

SecRule RESPONSE_STATUS "^5\d{2}$"
"phase:4,rev:'2',ver:'OWASP_CRS/2.2.7',maturity:'9',accuracy:'9',t:none,capture,ctl:auditLogParts=+E,block,msg:'The
application is not available',logdata:'Matched Data: %{TX.0} found
within %{MATCHED_VAR_NAME}:
%{MATCHED_VAR}',id:'970901',tag:'WASCTC/WASC-13',tag:'OWASP_TOP_10/A6',tag:'PCI/6.5.6',severity:'3',setvar:'tx.msg=%{rule.msg}',setvar:tx.outbound_anomaly_score=+%{tx.error_anomaly_score},setvar:tx.anomaly_score=+%{tx.error_anomaly_score},setvar:tx.%{rule.id}-AVAILABILITY/APP_NOT_AVAIL-%{matched_var_name}=%{tx.0}"

Not sure where the problem is.

I'm tempted to say that an upgrade to CRS3 is likely to solve the
problem, though.

Ahoj,

Christian


>-- 
>Osama Elnaggar
> 
>On August 24, 2017 at 6:20:26 AM, Cristiano Galdino
>(cristiano.gald...@gmail.com) wrote:
> 
>  Hi!
>  I have an application
>  â**returning status 500 and I can not fix it or take it out. I try
>  disable rule 970901 but
>  â** â**
>  modsecurity keeps logging events
>  â**.â**
>  â**
>  File:
>  â**modsecurity_crs_15_local_exceptions.conf
>  SecRule REQUEST_FILENAME "@beginsWith /monitor/" \
>  "id:2500,phase:4,nolog,noauditlog,t:none,t:lowercase,msg:'Desativa
>  regras de para o contexto SIPAG-MONITOR-WEB',pass, \
>  ctl:ruleRemoveById=970901"
>  What can I do?
> 
>  â**Tks!â**
> 
>  --
>  Cristiano Galdino - cristi...@galdino.net
>  http://cristiano.galdino.net
>  ___
>  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?

[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

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

[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] What is the right process of dealing with the false postivies

[Christian Folini]

Hey Georgi,

On Thu, Aug 17, 2017 at 07:27:49PM +0300, Georgi Georgiev wrote:
> 1. Is really paranoia level 1 less false postitive for a shared hosting
>environment and in such time enough for protection? 

That depends on your assessment of your data, its value and the threat
model.

I think PL1 is base level of security, PL2 is security for data with
some value, PL3 is online banking, PL4 is nuclear power plant. Just as a
rough guidance. ;)


> Does it protect from
>sql injection and xss as I read that they are included in paranoia level2?

Yes, the biggest part of the SQLi protection is the use of the
libinjection library that is included in PL1.

>What is the best practice - initially start with paranoia level 1, tune it
>and then switch to 2?

That is a very good question. In fact if you aim to run in PL2, it is
far easier to start in PL2 immediately and then tune down. The problem
is that if you run in PL1 and have tuned the service to a hard blocking
setting, the enabling of PL2 will bring you new rules, new false
positives and legitimate users being blocked.

>2. What is your anomaly inbound score set? Have you changed it to
>something other than 5 or you leaved it to 5 and changed the score of the
>rules?

For a productive system it should be 5. After the tuning.

>3. I am not sure how to tune the tx.score for every rule in the OWASP as
>they are with variables such as follow:
>  SecRule IP:REPUT_BLOCK_FLAG "@eq 1" \
>"setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},\
>   
>
> setvar:tx.%{rule.id}-AUTOMATION/MALICIOUS-%{matched_var_name}=%{matched_var}"
>Is this the correct default scores for the specific rulesets and attacks
>that I should tune?

Don't touch the rules. You only want to change the anomaly score limit
in the crs-setup.conf file - and then create your rule exclusions as
documented in the tutorials.

>4. Should I adjust the percentage of requests that are funnelled into the
>Core Rules below 100 as itâ**s recommended on some pages? Does this affect
>the false positives or only the performance?

This is a feature that is only useful when gauging the performance
impact of ModSec / CRS. You definitely need to have this at 100 or an
attacker can submit an exploit n times and eventually he will bypasss
the rule set based on your sampling rate being below 100%.

Ahoj,

Christian


-- 
History teaches us that men and nations behave wisely once they have
exhausted all other alternatives.
-- Abba Eban
___
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] Run core rule set on just one page / parameter

[Christian Folini]

Hey Kirk,

Thank you for your fully documented recipe. Glad it works.
This is almost ready for a complete blogpost on the subject:

- Step 1: Running rules only on certain parameters
- Step 2: Running rules only on certain parameters on certain paths

Interested to write that?

Ahoj,

Christian

On Wed, Aug 16, 2017 at 11:09:45AM +1200, Kirk Jackson wrote:
> > - Remove SearchTerm from all paths but /product/search at runtime
> >   -> "!@beginsWith /product/search"
> >
> > Good luck and please report back!
> >
> 
> That works well.
> 
> Here's my canonical "How you run the Core Rule Set's SQLi rules only on
> vulnerable pages and parameters" for historical / archival reference:
> 
> These rules disable the SQL injection rules in the Core Rule Set v3, except
> for two parameters: "SearchTerm" and "foo". This is done at configuration
> time, so the SecRuleUpdateTargetByID statements have to go after the Core
> Rule Set is included.
> 
> Then at runtime, we narrow down the list of pages that the SQLi rules are
> run against, by removing the two parameters "SearchTerm" and "foo"
> depending on which URL is being requested. As this is at runtime, these two
> rules need to go before the Core Rule Set rules are included, so that the
> change to their Target is done before they run.
> 
> # Rutime: Only run the SQLi rules against SearchTerm if on the Product
> Search page
> SecRule REQUEST_FILENAME "!@beginsWith /product/search" \
> "id:2011,phase:2,\
> pass,nolog,\
> t:none,t:lowercase,t:normalisePath,\
> ctl:ruleRemoveTargetById=942100-942999;ARGS:SearchTerm"
> 
> # Runtime: Only run the SQLi rules against argument foo if on the About page
> 
> SecRule REQUEST_FILENAME "!@beginsWith /home/about" \
> "id:2012,phase:2,\
> pass,nolog,\
> t:none,t:lowercase,t:normalisePath,\
> ctl:ruleRemoveTargetById=942100-942999;ARGS:foo"
> 
> Include modsecurity/crs-setup.conf
> Include crs/*.conf
> 
> # Configure-Time: Disable CRS's SQLi rules:
> SecRuleUpdateTargetByID 942100-942999 "!REQUEST_COOKIES"
> SecRuleUpdateTargetByID 942100-942999 "!REQUEST_COOKIES_NAMES"
> SecRuleUpdateTargetByID 942100-942999 "!ARGS_NAMES"
> SecRuleUpdateTargetByID 942100-942999 "!ARGS"
> SecRuleUpdateTargetByID 942100-942999 "!XML"
> 
> # Configure-Time: Only test SQLi for the SearchTerm & foo parameters
> SecRuleUpdateTargetByID 942100-942999 "ARGS:SearchTerm"
> SecRuleUpdateTargetByID 942100-942999 "ARGS:foo"
> 
> # (Jump back up to ID 2011 and 2012 above the include for CRS, to see the
> rest of the rules)
> 
> 
> I appreciate your help getting this working.
> 
> Cheers,
> 
> Kirk

-- 
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] What is the right process of dealing with the false postivies

[Christian Folini]

Georgi,

Yes, this is all correct.

Glad to help (just not always with enough time at my hands...)

Cheers,

Christian

On Tue, Aug 15, 2017 at 03:42:08PM +0300, Georgi Georgiev wrote:
> Thank you about your reply again, it was useful. First of all I would like to 
> apologize for the stupid for you questions. Currently I see that I have the 
> following in the config which means from what I read that I am not in anomaly 
> mode, but in traditional:
> 
> SecDefaultAction "log,deny,phase:1"
> 
> So, by your recommendation I understand that I should remove this lines to 
> start using anomaly mode. Then, on every rule I can/ should add with 
> setvar:tx.anomaly_score=5(for example) so I can control it’s score?
> 
> Also to decrease the false positives as a second step from the setup should I 
> increase the threshold value here - or I am wrong?
> 
> # Default Inbound Anomaly Threshold Level (rule 900110 in setup.conf)
> SecRule :inbound_anomaly_score_threshold "@eq 0" \
> "id:901100,\
> phase:1,\
> pass,\
> nolog,\
> setvar:tx.inbound_anomaly_score_threshold=5"
> 
> 
> 
> > On Aug 15, 2017, at 9:52 AM, Christian Folini <christian.fol...@netnea.com> 
> > wrote:
> > 
> > Hello Georgi,
> > 
> > CRS3 comes with default rule exclusions for WP and Drupal that solve
> > many of the base installations FPs. Collaborating with the project on
> > a set of Joomla rule exclusions would be most helpful.
> > 
> > Starting with a higher anomaly threshold while you weed out the false
> > positives is a method that I advocate in my documentation.
> > 
> > Making sure that you do not base your tuning efforts on attack traffic
> > is an obvious problems. There are multiple approaches to this, and none
> > of them is hard science. I usually try to start off with tuning based on
> > known IP ranges.
> > 
> > This is all discussed in great detail in the series of ModSecurity
> > tutorials at https://www.netnea.com/cms/apache-tutorials/
> > 
> > Besides, I am also running two public ModSec courses in October.
> > 
> > Good luck!
> > 
> > Christian
> > 
> > 
> > On Mon, Aug 14, 2017 at 03:29:39PM +0300, Georgi Georgiev wrote:
> >> Hello,
> >> I am deploying mod security with nginx in shared hosting environment and 
> >> most of the websites are Wordpress, Joomla and drupal. I don’t want to 
> >> rewrite all the rules of owasp to minimize the false positives. Also, I 
> >> searched for specific for Wordpress or Joomla ruleset but couldn’t find 
> >> such thing (it would be very resourceful to research for every Wordpress 
> >> and Joomla hack, even the most famouse one and to write rules about it, 
> >> also to read how to write rules :)). Even, if I put mod security initially 
> >> in a mode that does not block , only to log it would be very hard to see 
> >> very queer if it’s false positive or whether it come from evil sources.
> >> 
> >> I read that right practice is to change the score of the anomaly but 
> >> didn’t understand it at all.
> >> 
> >> So, I would like to ask you how you deal with this? I know that false 
> >> positives will be there all the time, but how you minimize them? Write 
> >> your own ruleset? Is there any paid ruleset that you can recommend (it 
> >> think that I found only one paid and many people cry from it). Just I want 
> >> to explain me the process you follow with the rules :)
> >> 
> >> Thank you in advance!
> >> ___
> >> 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
> > 
> > -- 
> > 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] Run core rule set on just one page / parameter

[Christian Folini]

Hey Kirk,

Thank you for trying this out so quickly. This is very helpful.

On Tue, Aug 15, 2017 at 09:12:37PM +1200, Kirk Jackson wrote:
> I think by "steering commando rules" you mean the rules that check which
> paranoia level is set, and then jump to the marker at the end of the file?

Exactly.

> The following config then works!
> 
> Include modsecurity/crs-setup.conf
> Include crs/*.conf
> 
> # Disable CRS's SQLi rules:
> SecRuleUpdateTargetByID 942100-942999 "!REQUEST_COOKIES"
> SecRuleUpdateTargetByID 942100-942999 "!REQUEST_COOKIES_NAMES"
> SecRuleUpdateTargetByID 942100-942999 "!ARGS_NAMES"
> SecRuleUpdateTargetByID 942100-942999 "!ARGS"
> SecRuleUpdateTargetByID 942100-942999 "!XML"
> 
> # Only test SQLi for the SearchTerm parameter
> SecRuleUpdateTargetByID 942100-942999 "ARGS:SearchTerm"

Sweet. Glad it works.

> However, the ctl:ruleUpdateTargetById action doesn't work - I was lead
> astray by the Mod Security Handbook, which is a bit out of date (at this
> url:
> https://www.feistyduck.com/library/modsecurity-handbook-2ed/online/xx1-directives.html#N15992).
> It looks like that got removed:
> 
> Note : There was a ctl:ruleUpdateTargetById introduced in 2.6.0 and removed
> from the code in 2.7.0. JSON was added as part of v2.8.0-rc1
> (from https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#ctl)

Oops. That's a clear factual mistake in the book.
I think I need to talk to the author.

But on a more serious note: This is the first real technical bug in the
book. We had a bug report before but it was more a missing comment. Your
discovery points to a factual error I should have noticed. Sorry.

Do you have a paper copy of the book? If not, then please give me your
address and I will have a copy be sent your way. Ironically, it will
come with the bug, but I really appreciate people submitting errors the
encounter in the book.

> If you have any ideas on how to further restrict it so I can rule the SQLi
> rules for only one page + parameter combo, I'm interested to know!

With ctl:ruleUpdateTargetById being no longer an option, we need a
different approach. This is turning more and more into a wild hack, but
let's try out the following:

- Remove all the ARGS at startup time
- Add ARGS:SearchTerm at startup time
- Remove SearchTerm from all paths but /product/search at runtime
  -> "!@beginsWith /product/search"

Good luck and please report back!

Christian

-- 
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] What is the right process of dealing with the false postivies

[Christian Folini]

Hey, hey,

On Tue, Aug 15, 2017 at 10:31:34AM +0300, Georgi Georgiev wrote:
> Thank you about your reply. I know about the exclusion, but I don’t
> think this is the perfect solution, because if I exclude all the false
> positive rules there will be 2-3 maybe working rules at all :) 

That is not greatly exaggerated. We have about 150 rules in the default
install. Multiply this with the application's parameter. And then look
at the few dozens of rule/parameter exclusions we provide you with.
It's the minimal set of bricks broken out of the defense wall.

> Maybe they should be tunned?

Or WordPress / Drupal could be fixed to make sure they do not submit any
suspicious payloads. :)

> What is going on when the anomaly score is
> higher - this I couldn’t understand - users are not blocked or what?

The anomaly score is linked to an individual request.
The anomaly threshold is the anomaly limit where you start to block
requests.

If the threshold is at 25 and a request sets of 4 critical rules, you
get 4 error entries, a score of 20 and the request passes.

Got it?

If it is still not clear, could you read the explanations in
crs-config.conf again. If you are unable to understand that, please
point it out exactly for this would be a sign or documentation is not
good enough.

Ahoj,

Christian


> If I understand right I can start with high anomaly score for all rule
> with equal score until I tune them perfectly.
> 
> In the nginx I have ratelimits and I prefer to start with most common
> Wordpress / Joomla hacks rule that can stop some part of the hacks,
> because this is the biggest problem
> 
> Best regards, Georgi Georgiev .
> > On Aug 15, 2017, at 9:52 AM, Christian Folini
> > <christian.fol...@netnea.com> wrote:
> > 
> > Hello Georgi,
> > 
> > CRS3 comes with default rule exclusions for WP and Drupal that solve
> > many of the base installations FPs. Collaborating with the project
> > on a set of Joomla rule exclusions would be most helpful.
> > 
> > Starting with a higher anomaly threshold while you weed out the
> > false positives is a method that I advocate in my documentation.
> > 
> > Making sure that you do not base your tuning efforts on attack
> > traffic is an obvious problems. There are multiple approaches to
> > this, and none of them is hard science. I usually try to start off
> > with tuning based on known IP ranges.
> > 
> > This is all discussed in great detail in the series of ModSecurity
> > tutorials at https://www.netnea.com/cms/apache-tutorials/
> > 
> > Besides, I am also running two public ModSec courses in October.
> > 
> > Good luck!
> > 
> > Christian
> > 
> > 
> > On Mon, Aug 14, 2017 at 03:29:39PM +0300, Georgi Georgiev wrote:
> >> Hello, I am deploying mod security with nginx in shared hosting
> >> environment and most of the websites are Wordpress, Joomla and
> >> drupal. I don’t want to rewrite all the rules of owasp to minimize
> >> the false positives. Also, I searched for specific for Wordpress or
> >> Joomla ruleset but couldn’t find such thing (it would be very
> >> resourceful to research for every Wordpress and Joomla hack, even
> >> the most famouse one and to write rules about it, also to read how
> >> to write rules :)). Even, if I put mod security initially in a mode
> >> that does not block , only to log it would be very hard to see very
> >> queer if it’s false positive or whether it come from evil sources.
> >> 
> >> I read that right practice is to change the score of the anomaly
> >> but didn’t understand it at all.
> >> 
> >> So, I would like to ask you how you deal with this? I know that
> >> false positives will be there all the time, but how you minimize
> >> them? Write your own ruleset? Is there any paid ruleset that you
> >> can recommend (it think that I found only one paid and many people
> >> cry from it). Just I want to explain me the process you follow with
> >> the rules :)
> >> 
> >> Thank you in advance!
> >> ___
> >> 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
> > 
> > -- https://www.feistyduck.com/books/modsecurity-handbook/
> > mailto:christian.fol...@netnea.com twitter: @ChrFolini

-- 
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] Run core rule set on just one page / parameter

[Christian Folini]

Kirk,

This is a tricky one. Actually your recipe should work. But then it does
not. I dug a bit deeper and found out an issue.

SecRuleUpdateTargetByID 942000-942999 "ARGS:SearchTerm"

adds the arg SearchTerm to all rules including steering commando rules
used for Paranoia Levels. And this seems to f**k them up. At least this
is my first impression.

Could you try and apply the Update only to those rules that really
apply and report back?

There might be a deeper issue here, so let's try and work together
to find a good recipe to solve your use case - which is actually a very
useful one.

Ahoj,

Christian


On Mon, Aug 14, 2017 at 10:03:15AM +1200, Kirk Jackson wrote:
> Hi,
> 
> I'd like to run the SQLi checks on only the one parameter on my site that
> is vulnerable to those attacks.
> 
> I was wondering if there's a pattern to do this, or if I need to copy the
> rules from REQUEST-942-APPLICATION-ATTACK-SQLI.conf into my own file, and
> change the variables to my ARGS:ParamName?
> 
> I tried doing this, to disable the rules, and then re-enable for just my
> param, but that didn't work:
> 
> SecRuleUpdateTargetByID 942000-942999 "!REQUEST_COOKIES"
> SecRuleUpdateTargetByID 942000-942999 "!REQUEST_COOKIES_NAMES"
> SecRuleUpdateTargetByID 942000-942999 "!ARGS_NAMES"
> SecRuleUpdateTargetByID 942000-942999 "!ARGS"
> SecRuleUpdateTargetByID 942000-942999 "!XML"
> 
> SecRuleUpdateTargetByID 942000-942999 "ARGS:SearchTerm"
> 
> Many thanks!
> 
> Kirk

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


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

[Owasp-modsecurity-core-rule-set] News from the Core Rule Set (2017-08-13)

[Christian Folini]

Dear all,

This is the CRS newsletter covering the period from July until today.

What has happened during the last few weeks:

- We held our community chat last Monday. We have been eight people
  including Manuel Spartan who participated on the development
  of the paranoia mode.
  The big topic was disassembly of the optimized regular expressions
  that are very hard to read. See below for details.
  The next community chats will be held on the following dates:
  - Sep 4, 2017, 20:30 CEST (14:30 EST, 19:30 GMT)
  - Oct 2, 2017, 20:30 CEST
  - Nov 6, 2017, 20:30 CET
  - Dec 4, 2017, 20:30 CET

- The OWASP ModSecurity Core Rule Set 3.0.2 is still the latest stable
  version. We talked about an eventual 3.1 version in the chat, but we
  agreed that we are far from that and that we want to add a substantial
  set of new features to make transition worthwhile for users.

- ModSecurity 2.9.2 came out on July 19. Among several bugfixes, it
  brings an updated libinjection support that helped CRS close a
  few holes. See this CRS issue for an example:
  https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/797
  We recommend all users to update to 2.9.2. AFAICS there are no
  backported packages for the major distros yet, so this is only 
  viable for those users compiling themselves.

- Summer holidays are taking their toll and we are quite behind with the
  inclusion of pull requests. This brings us to a very high number
  of 10 open pull requests. Most of them have been reviewed, but
  they have not yet been incorporated.

- A PR that is still in preparation, but almost done is a big disassembly 
  of over 2 dozens of the  complex regular expressions that are so hard 
  to read in the CRS.
  Look at this beauty for example:
  
https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.0/master/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf#L589
  The point is these rules are very old, they are machine generated
  with the help of an ancient perl module optimizing regular expressions
  for performance and the sources / original regular expressions are
  long gone. To add to the problem, some of the rules have been
  edited by hand afterwards so there is just no telling what they
  really do. It takes a rule archaeologist to reconstruct the original
  sources. Franziska Bühler took over this task and it seems she got 
  to the  bottom of all the complex SQLi regexes within a couple of 
  weeks.
  The idea is now a PR to add the sources to util/regexp-assemble.
  This would then allow us to consolidate / optimize the regular
  expressions.

- Believe it or not: We got the new logo for the project. As we kind
  of expected it took longer than expected, but it's done now and
  it sure looks cool. Expect a separate announcement very soon.
  This also holds true for the website which is ready and only waits
  for the logo for the real announcement.

- OWASP London invited me to present my CRS3 intro presentation that
  I held in Belfast for AppSecEU. This took place on July 27 and
  according to the audience it was a big success. Here are a few
  photos taken after the presentation when I signed the new 
  ModSecurity Handbook and then in the pub nearby:

  https://twitter.com/ChrFolini/status/892686195133739009
  https://twitter.com/OWASPLondon/status/890693408683163648

Upcoming Stuff

- OWASP Switzerland is also hosting CRS introduction talk.
  This is happening on Wednesday, August 16 in Zurich at 6pm.
  Here are the details:
  https://www.meetup.com/de-DE/OWASPSwitzerland/events/241771446/

- There are still a few seats available for the Apache / ModSecurity / CRS
  courses in October. One in London, one in Zurich.
  https://www.feistyduck.com/training/modsecurity-training-course

- There is now a plan to run a real poll where CRS users can vote on
  feature requests. There are a ton of feature requests recorded on
  github, but we really are a bit at a loss on what people are really
  interested in. Stay tuned to learn more about this.

I have been on a holiday for two weeks and it is likely, I overlooked
things on the mailinglists and on github. Feel free to speak up and
respond to this message highlighting the omissions.

Cheers,

Christian


-- 
The ability to quote is a serviceable substitute for wit.
-- W. Somerset Maugham 
___
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] Up next Monday: Monthly Project Chat

[Christian Folini]

Hi there,

Next Monday, August 7, we'll do our regular Core Rule Set project chat.
20:30 CET (14:30 EDT, 18:30 GMT)
on Freenode IRC, channel #modsecurity

It's holiday season (I'm currently in Finland), but we'll see who
will have time. There are quite a few PRs we need to cover and then
the launch of the new website... Work is not running out.

Cheers,

Christian

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

[Owasp-modsecurity-core-rule-set] Live-Stream of CRS3 presentation to night at OWASP Chapter London

[Christian Folini]

Hi there,

OWASP London informed me that my CRS3 presentation will be life-streamed
on Facebook at https://www.facebook.com/OWASPLondon/  

My talk will begin around 8pm UK time.

The presentation will be very similar to the one I held at AppSecEU
in Belfast, but this time, we have a backup plan for the installation
demo which failed due to beamer issues back in May.

A record of the stream will be available on youtube afterwards.
Likely the OWASP London channel.

Please keep your fingers crossed for me.

Cheers,

Christian



-- 
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] Correct place for custom scoring rules

[Christian Folini]

Hey Cristian,

On Mon, Jul 17, 2017 at 12:29:16PM +0200, Cristian Mammoli wrote:
> Hi, I'm using crs 3 in "anomaly score mode" and I would like to add a couple
> of custom rules to "lower" the anomaly score before the final evaliuation

Makes sense. I thought about such scenarios as well, but I never really
tried it in practice.

> But where do I put it to have it processed before the final score is
> analyzed for rejection?

So the incoming score is evaluated in rule 949110 towards the end of
phase 2. Squeezing a rule after 948xxx and before 949110 is quite
difficult without changing the rule file(s).

I see two approaches:
- You remove rule 949110 on startup and re-create it yourself at the end
  of phase 2 together with your custom rules.
  Notice that there is report rule in the 98 range that you
  might have to handle as well or it will mess up your log file
  with garbage reports based on the wrong scores.
- You do not lower the score before 949110 hits, but you start with
  -2 instead of 0 in a rule that runs after crs-setup.conf but before
  the rules files. However, I am not really sure ModSec allows for 
  negative numbers.

I am sure other methods are possible that these are the two I would
probably try out.

Cheers,

Christian


-- 
Und es gehen die Menschen zu bestaunen die Gipfel der Berge und die
ungeheuren Fluten des Meeres und die weit dahinfliessenden Ströme 
und den Saum des Ozeans und die Kreisbahnen der Gestirne und haben
nicht acht ihrer selbst.
--- Augustinus (354-430)
___
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] Woe with 920270 (Null Byte...) (was: Re: Matched rule modification)

[Christian Folini]

Hey Ervin,

It certainly does not hurt to be on the same page.

Cheers,

Christian

On Mon, Jul 10, 2017 at 09:59:03AM +0200, Ervin Hegedüs wrote:
> Hi Christian,
> 
> many thanks for your reply,
> 
> On Mon, Jul 10, 2017 at 07:30:29AM +0200, Christian Folini wrote:
> > Hey Ervin,
> > 
> > Like I mentioned last week, we want to come up with a solution to all
> > this non-ascii problems with CRS for 3.1. Chaim has explained the
> > problem pretty well and unfortunately, this stretches to more rules.
> > 
> > You manage to run curl and you have servers with non-ascii payloads.
> > So you will be an excellent partner when we come up with new rules
> > and approaches to this problem. It is likely to take a while, but 
> > once we have something to show, testing it on real servers
> > is very important.
> 
> right, I'm waiting for your result.
> 
> Till I can build the Modsecurity with Apache too, and can check -
> would it be helpful to you, or not?
> 
> 
> Thanks again,
> 
> 
> a.

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

Re: [Owasp-modsecurity-core-rule-set] Woe with 920270 (Null Byte...) (was: Re: Matched rule modification)

[Christian Folini]

Hey Ervin,

Like I mentioned last week, we want to come up with a solution to all
this non-ascii problems with CRS for 3.1. Chaim has explained the
problem pretty well and unfortunately, this stretches to more rules.

You manage to run curl and you have servers with non-ascii payloads.
So you will be an excellent partner when we come up with new rules
and approaches to this problem. It is likely to take a while, but 
once we have something to show, testing it on real servers
is very important.

Best,

Christian


On Fri, Jul 07, 2017 at 08:44:10PM +0200, Ervin Hegedüs wrote:
> Hi Chaim,
> 
> On Fri, Jul 07, 2017 at 10:46:22AM -0400, Chaim Sanders wrote:
> > Taking a quick look here, it appears that the problem is probably with
> > urldecodeuni but it also might not be solvable. Let me explain, If I recall
> > correctly the reason that we added request_uri and ARGS as a parameter is
> > that they require provided elements to be ASCII. The alternative is that in
> > PL1 we thought that only ASCII should be submitted as args, which seems
> > wrong.
> > However we see that there is the use of urldecodeuni, which will decode
> > even unicode chars into the base char points. Stepping aside from the other
> > Unicode problems we've been seeing as a result of some ModSec issues
> > (purportedly), the use of this transformation will defeat the purpose of
> > this rule, as it will fire whenever a unicode element has been received.
> > The real question/possible problem, is that as we learned before
> > Apache/Nginx will provide us with automatically urldecoded arguments (and
> > url's maybe). This in turn might mean that it is never possible to ensure
> > that URL's and Args were all ASCII as is required by spec.
> > Requires a little bit more testing and verification of the purpose of the
> > rule, but i'd guess this is the cause of your issue.
>  
> thanks for your detailed anwser, I think I understand most of it :).
> 
> Probably I can't do anything till you can't find the final
> solution.
> 
> What can I help you? I mean, may be I can build the old
> Modsecurity version with Apache, or Nginx, and can try with old
> CRS...
> 
> 
> Thanks,
> 
> 
> a.
> 
> > On Fri, Jul 7, 2017 at 8:24 AM, Ervin Hegedüs <airw...@gmail.com> wrote:
> > 
> > > Hi Christian and Chaim,
> > > other CRS users,
> > >
> > >
> > > here is my previous e-mail with an issue (with more issues
> > > exactly, but this one whis is interesting now)
> > >
> > > On Thu, Jun 01, 2017 at 08:49:03AM +0200, Christian Folini wrote:
> > > >
> > > > On Wed, May 31, 2017 at 08:32:03AM +0200, Ervin Hegedüs wrote:
> > > > > And there is an another issue with 3.0.2 (but may be that affects
> > > > > another versions too).
> > > > >
> > > > > The request is similar that I detailed in my first post. The
> > > > > "extraParams" value (JSON field) is this:
> > > ...
> > >
> > > and you sent me your test:
> > >
> > > > I was kind of expecting problems with 920270, but probably not as
> > > > deep rooted ones as this. But first, I need to be able to reproduce
> > > > this, and I can't.
> > > >
> > > > Here is my curl call taking up your example:
> > > >
> > > > curl 'localhost/index.html' -d 'extraParams=%7B%22node%22%3A%
> > > 223%22%2C%22text%22%3A%22v%C3%A9gs%C5%91%20fejezet%22' --trace-ascii -
> > > > == Info:   Trying 127.0.0.1...
> > > > == Info: Connected to localhost (127.0.0.1) port 80 (#0)
> > > > => Send header, 153 bytes (0x99)
> > >
> > > ...
> > >
> > >
> > > now the situation is totally same like above, but the server is
> > > another, and the web application is an up-to-date RoundCube
> > > webmail.
> > >
> > > The issue is when I'ld like to compose a new mail and I'm using
> > > special hungarian characters, Modsecurity denies the request.
> > >
> > > Here is the curl test:
> > >
> > > curl "https://roundcube.mydomain.hu/; -d "_token=
> > > 0uuYa9sHayQF7AU6s5Kb4XtJeKt6PZak&_task=mail&_action=send&_
> > > id=1466771890595f68c41f875&_attachments=&_from=5&_to=airween%40gmail.com
> > > &_cc=&_bcc=&_replyto=&_followupto=&_subject=Pr%C3%B3ba+0707+1256&
> > > editorSelector=plain&_priority=0&_store_target=Sent&
> > > _draft_saveid=&_draft=&_is_html=0&_framed=1&_message=Pr%C3%B3ba+%C3%BC

[Owasp-modsecurity-core-rule-set] News from the Core Rule Set (2017-07-07)

[Christian Folini]

Dear all,

This is the CRS newsletter covering the period from June until today.

I was not sure I had the time to compile this message in time as I
am currently attending a medieval reenactment event with the
Company of St. George. But the camp is now set up for the weekend,
all is quite and I sneaked off to write the newsletter. Hope
nobody sees me any my notebook...

What has happened during the last few weeks:

- We held our community chat last Monday. Outside of administrative
  topics, we looked into some of the open issues and talked about
  plans for the 3.1 release.
  The next community chats will be held on the following dates:
  - Aug 7, 2017, 20:30 CEST (14:30 EST, 19:30 GMT)
  - Sep 4, 2017, 20:30 CEST
  - Oct 2, 2017, 20:30 CEST
  - Nov 6, 2017, 20:30 CET
  - Dec 4, 2017, 20:30 CET

- So what are the plans for 3.1?
  - Chaim thinks that the whole SQL rules are hard to overview and even
  chaotic despite a consolidation effort by Ryan Barnett around the
  2.2.4 release. So Chaim wants to review and possibly re-organise
  sqli detection.
  - Walter is sick of not detecting Java exploits and he plans to
  write new rules to stop that attack vector.
  - Franziska volunteered to try and disassemble the roughly three dozens
  of highly optimized regular expressions in CRS. She worked on issue
  811 and thinks that this archaeological work is just her thing. Given 
  my background in history, I appreciate all efforts in rule archaeologicy.
  - And finally, we all agreed that the situation with false positives
  with non-western languages is unbearable. Victor has made some
  very useful observations, we think that some ModSecurity transformations
  might be at fault here too and we want to come up a clean and
  workable solution here. But this is going to be tough.

  Generally, there has to be a balance between closing existing holes with the
  detection and extending the detection capabilities towards new areas. It
  looks as if the scanning of uploaded files with Fuzzy Hashing was not 
  immediately on the table (unless somebody thinks this would be great and 
  takes up the task to implement it).

- When I talked about a couple of weeks until we have the new logo
  I did not define "couple". What I can say now is that a couple of
  weeks is more than 4 and that it's only a matter of a couple of days
  now until the new logo. But the latest drafts are really promising.

- Our twitter account @CoreRuleSet is online, but we did not start tweeting
  yet. We want to wait for the logo, because who want's to tweet from a
  naked account.

- The new project website is being prepared as I write this. Walter 
  settled on a design theme and he is actively looking into creating 
  content together with Chaim. The idea is to use the website actively
  as a site for blogging about the project.
  Walter is aiming for a launch of the site in early August.

- In May, we announced Franziska Buehler (franbuehler) and Christoph
  Hansen (emphazer) had joined the project as developers. In the
  meantime, we also added Victor Hora to the rooster. However, we
  encountered difficulties when granting them commit permission. The
  case with Victor was easy. Given he is a Trustwave employee, he
  is part of Trustwave Spiderlabs and got immediate commit rights
  on our project as our repository is hosted on github under the
  Spiderlabs organisation. Bringing new people into our projects
  means they need to be granted commit rights by the Spiderlabs
  admins. This was never an issue as long as project lead Chaim
  worked for Spiderlabs, but he quit and now we depend on the
  goodwill of Trustwave with this. We could move the repository
  of course, but that is a huge hassle for little gain.
  After lobbying for several weeks, Franziska and Christoph
  finally got the requested permissions on Wednesday and we have
  been promised that granting the permissions to non-Spiderlabs
  developers was now generally resolved and the next
  ones will be easier. Keeping our fingers crossed.
  We thank Franziska and Christoph for their patience. And we
  also thank Trustwave / Spiderlabs for the goodwill they continue
  to show towards our project. Trustwave has been stewarding 
  ModSecurity and CRS for many years and when Chaim quit his job 
  in February, we knew there might be hassles. But we are still in 
  close contact and resolving issues as this helps building the 
  mutual trust.

- The groups of new bypasses reported here last month is still open.
  There is a new ModSecurity release pending that will include an
  updated libinjection with better detection capabilities. But there
  is also going to be a new rule or several rules in CRS. It's just
  not ready yet.

Upcoming stuff

- Having attended my CRS talk at AppSecEU, the OWASP chapter London
  has invited me to present at their regular chapter meeting on
  July 27.
  

Re: [Owasp-modsecurity-core-rule-set] Need more features ModSecurity WAF

[Christian Folini]

Hey Noël,

Some of this functionality is already here, but you need to dig in the
ruleset a bit. However, most of it is not existing, neither in our
project nor in ModSecurity itself.

Like half of the features are your job as they depend on your
environment and you need to integrate them yourself.

Some of the features might be interesting for our project but we would
need somebody to develop them. Feel free to volunteer; we would be
happy to help you through the process.

If you are instead looking for an integration partner who builds this
all for you as a commercial gig, then please get in touch via PM.
I have experience with some of this and I would love to receive funding
to work on the rest.

Best,

Christian Folini

On Fri, Jun 16, 2017 at 09:19:09AM +, noel.kpa...@orange.com wrote:
> Hello team,
> 
> Could you revert to us about below request?
> 
> Thank you!
> 
> Regards,
> Noël
> 
> De : KPAZAI Noel /DDT/EQ [OCI]
> Envoyé : mardi 13 juin 2017 12:04
> À : 'owasp-modsecurity-core-rule-set@lists.owasp.org'
> Cc : TOURE Sidik /DDT/EQ [OCI]
> Objet : RE: Need more features ModSecurity WAF
> 
> Hello team,
> 
> We have deployed ModSecurity in our environment to protect our different 
> websites from attacks.
> But, we want to have more functionality for our business.
> Could you accompany us by including these features :
> 
> - Rich graphical interface
> - Creating / customizing / Filtering report (pdf, word, excel)
> - Email alerting and scan report virtual patching
> - Geo location and malicious IPs detection
> - Custom rules building from graphical interface
> - Block anonymous proxy and TOR network
> - Viewing all request in real time from graphical interface
> - Adding and managing web application from graphical interface
> - Dynamic User / IP profiling and tracking, and forensic service
> - Automatic update of core rules from graphical interface
> - Web error page and response in alerts
> - Creating / customizing / Filtering alerts and violations
> 
> 
> We remain available for additional information.
> 
> 
> Thank you !
> 
> Best regards,
> 
> Bien cordialement
> --
> Noël KPAZAÏ
> Sécurité ITN/DRSI
> 
> (: +225 48 77 23 35
> ' : +225 20 34 81 36
> [cid:image003.jpg@01D159F1.510A8790]
> 
> 
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
> 



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


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

Re: [Owasp-modsecurity-core-rule-set] Another odd false positive.

[Christian Folini]

Hello Ed,

This looks a lot like Issue 794.
https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/794

We think it is an issue in ModSecurity (and not with libinjection
as the rule ID suggests).

Could you create a full debug log of the false positive and attach
it with 794 like I did for the known bad payloads there?

As for your problem at hand, I suspect you need to disable the rule
at least temporarily. You know how to do that, don't you.

Ahoj,

Christian


On Thu, Jun 08, 2017 at 12:02:10PM -0400, Ed Greenberg wrote:
> Full log is in https://pastebin.com/SW4rQ0ZS
> 
> The failure is 942100.  It fired on this: [data "Matched Data: 1)o1 found
> within ARGS:Phone: (800)-252-8014"]
> 
> Of course, that Matched Data doesn't match what is the Phone field.
> 
> I've seen a few of these before, but most of them have people's private
> phone numbers, that I could not post, but this number is from an
> institution, and I don't have any problem posting it. I 'ed out the
> person's name in the pasted report, but that's it.
> 
> Any help with this appreciated. It fires pretty frequently on some of our
> forms.
> 
> ___
> 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

-- 
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] Up next Monday: CRS chat

[Christian Folini]

Hi there,

Next Monday, June 5, we'll do our regular Core Rule Set project chat.
20:30 CET (14:30 EDT, 18:30 GMT)
on Freenode IRC, channel #modsecurity

The topics will be the launch of the 3.1 development, the idea to create
our own CRS website, a severe SQLi that passes CRS3 (-> issue 782)
and whatever somebody else brings to the table.

We are inviting everybody to join the chat to get a feeling what the
project is up to. It does not matter if you are not a regular expression
expert. It is not really a technical chat, it's more a chat about
plans and policies and the more opinions we have on those, the better.

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

Re: [Owasp-modsecurity-core-rule-set] Woe with 920270 (Null Byte...) (was: Re: Matched rule modification)

[Christian Folini]

Ervin,

You are touching multiple issues in your latest message. I would like
to dig on the bottom of this one:

On Wed, May 31, 2017 at 08:32:03AM +0200, Ervin Hegedüs wrote:
> And there is an another issue with 3.0.2 (but may be that affects
> another versions too).
> 
> The request is similar that I detailed in my first post. The
> "extraParams" value (JSON field) is this:
> 
> extraParams {"node":"3","text":"végső fejezet"}
> 
> As you can see, this is a UTF8 text, and client sends it as UTF8:
> 
> Content-Type: application/x-www-form-urlencoded; charset=UTF-8
> X-Requested-With: XMLHttpRequest
> Accept-Encoding: gzip, deflate
> 
> The encoded URI will be:
> 
> extraParams=%7B%22node%22%3A%223%22%2C%22text%22%3A%22v%C3%A9gs%C5%91%20fejezet%22
> 
> The characters "é" and "ő" are two bytes utf8 characters:
> \xC3\xA9 and \xC5\x91.
> 
> But in audit log I get:
> 
> ModSecurity: Warning. Matched "Operator `ValidadeByteRange' with parameter 
> `1-255' against variable `ARGS:extraParams' (Value: 
> `{"node":"3","text":"v\xffc3\xffa9gs\xffc5\xff91 
> fejezet","parentNode":"0","tid":"144 (3 characters omitted)' ) [file 
> "/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"]
>  [line "488"] [id "920270"] [rev "2"] [msg "Invalid character in request 
> (null character)"] [data ""] [severity "2"] [ver "OWASP_CRS/3.0.0"] [maturity 
> "9"] [accuracy "9"] [tag "application-multi"] [tag "language-multi"] [tag 
> "platform-multi"] [tag "attack-protocol"] [tag 
> "OWASP_CRS/PROTOCOL_VIOLATION/EVASION"] [ref 
> "o21,1o22,1o25,1o26,1v921,67t:urlDecodeUni"]

I was kind of expecting problems with 920270, but probably not as
deep rooted ones as this. But first, I need to be able to reproduce
this, and I can't.

Here is my curl call taking up your example:

curl 'localhost/index.html' -d 
'extraParams=%7B%22node%22%3A%223%22%2C%22text%22%3A%22v%C3%A9gs%C5%91%20fejezet%22'
 --trace-ascii -
== Info:   Trying 127.0.0.1...
== Info: Connected to localhost (127.0.0.1) port 80 (#0)
=> Send header, 153 bytes (0x99)
: POST /index.html HTTP/1.1
001b: Host: localhost
002c: User-Agent: curl/7.50.1
0045: Accept: */*
0052: Content-Length: 82
0066: Content-Type: application/x-www-form-urlencoded
0097: 
=> Send data, 82 bytes (0x52)
: extraParams=%7B%22node%22%3A%223%22%2C%22text%22%3A%22v%C3%A9gs%
0040: C5%91%20fejezet%22
== Info: upload completely sent off: 82 out of 82 bytes

So the payload is exactly as your payload, but the said rule is not
being triggered.

Can you help me out here. Ideally with a curl call that triggers
920270 in the way you described.

Validating the byte range in combination with UTF8 and friends is
something we might have to drop for PL1. We let ASCII 0 stay in the
default install, but maybe it has to go in light of this false positive
which I think is generic to many languages not using the standard latin
ascii set.

Ahoj,

Christian


-- 
It is not useful for liberty that we abolish it in order to protect it.
--- Wolfgang Thierse, President of the German Parliament 
___
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] OWASP AppSecEU Videos + OWASP CRS Presentation

[Christian Folini]

Thank you Osama. I was not even aware they have been uploaded.

That was quick (given there were over 60 talks!)

Christian

On Sat, May 27, 2017 at 11:02:08PM -0400, Osama Elnaggar wrote:
> Hi,
> 
> OWASP AppSec Europe (https://2017.appsec.eu/) just released the videos for
> all the sessions.  Lots of good presentations (all application security
> specific), including one on the OWASP CRS by Christian Folini -
> https://www.youtube.com/watch?v=eO9gBAmKS58=27=PLpr-xdpM8wG8RHOguwOZhUHkKiDeWpvFp
> 
> 
> The full video list is available over here -
> https://www.youtube.com/playlist?list=PLpr-xdpM8wG8RHOguwOZhUHkKiDeWpvFp
> 
> -- 
> Osama Elnaggar

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


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

Re: [Owasp-modsecurity-core-rule-set] 503, 404, etc from underlying web server

[Christian Folini]

Ed,

On Tue, May 23, 2017 at 03:30:27PM -0400, Ed Greenberg wrote:
> When a web server throws an error (>399)  does that automagically trigger an
> entry in modsec_audit.log?

It depends on your setting of SecAuditLogRelevantStatus (and
also the setting of SecAuditEngine).

Ahoj,

Christian


-- 
The intersection of all majorities is the empty set - The 
union of even the smallest minorities is the universal set.
--- Linus Thorvalds
___
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] Inbound Anomaly Score Exceeded

[Christian Folini]

+1

On Tue, May 23, 2017 at 10:06:00AM -0400, Ed Greenberg wrote:
> We've deployed 3.0.2 today. I had it in testing, and forgot that I needed to
> push it out.  I'll keep an eye on things.
> 
> Thanks,
> Ed
> 
> On 05/23/2017 10:03 AM, Christian Folini wrote:
> > Hi Ed,
> > 
> > That's a mean one.
> > 
> > You are suffering from this bug:
> > https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/704
> > 
> > It's raising your score silently to 5 - without showing you the rule
> > that triggered.
> > 
> > Upgrading to 3.0.2 will solve this. If you still have problems, then
> > you should hand the false positives. The tutorials at netnea.com
> > can teach you how.
> > 
> > Ahoj,
> > 
> > Christian
> > 
> > On Tue, May 23, 2017 at 09:40:07AM -0400, Ed Greenberg wrote:
> > > On 05/23/2017 09:37 AM, Christian Folini wrote:
> > > > Hey Ed,
> > > > 
> > > > It is hard to help you without seeing the rule alert. The alerts you
> > > > showed us are only the evaluation at the end.
> > > Christian,
> > > 
> > > Thanks for all you do to support these rules. I appreciate it.
> > > 
> > > The entire log entry can be found at https://pastebin.com/6RSqP9Js
> > > 
> > > Even pastebin required me to solve a captcha to post it, so it must 
> > > trigger
> > > some sort of filter.
> > > 
> > > Thanks,
> > > 
> > > Ed
> 

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

Re: [Owasp-modsecurity-core-rule-set] Inbound Anomaly Score Exceeded

[Christian Folini]

Hi Ed,

That's a mean one.

You are suffering from this bug:
https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/704

It's raising your score silently to 5 - without showing you the rule
that triggered.

Upgrading to 3.0.2 will solve this. If you still have problems, then
you should hand the false positives. The tutorials at netnea.com
can teach you how.

Ahoj,

Christian

On Tue, May 23, 2017 at 09:40:07AM -0400, Ed Greenberg wrote:
> On 05/23/2017 09:37 AM, Christian Folini wrote:
> > Hey Ed,
> > 
> > It is hard to help you without seeing the rule alert. The alerts you
> > showed us are only the evaluation at the end.
> 
> Christian,
> 
> Thanks for all you do to support these rules. I appreciate it.
> 
> The entire log entry can be found at https://pastebin.com/6RSqP9Js
> 
> Even pastebin required me to solve a captcha to post it, so it must trigger
> some sort of filter.
> 
> Thanks,
> 
> Ed

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

Re: [Owasp-modsecurity-core-rule-set] Inbound Anomaly Score Exceeded

[Christian Folini]

Hey Ed,

It is hard to help you without seeing the rule alert. The alerts you
showed us are only the evaluation at the end.

Ahoj,

Christian

On Tue, May 23, 2017 at 09:06:21AM -0400, Ed Greenberg wrote:
> Something I don't understand. Here is a sample:
> 
> 
> 
> --6e7a4c70-E--
> 
> --6e7a4c70-H--
> Message: Warning. Operator GE matched 5 at TX:anomaly_score. [file 
> "/etc/httpd/owasp-modsecurity-crs-3.0.0/rules/REQUEST-949-BLOCKING-EVALUATION.conf"]
> [line "57"] [id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score:
> 5)"] [severity "CRITICAL"] [tag "application-multi"] [tag "language-multi"]
> [tag "platform-multi"] [tag "attack-generic"]
> Message: Warning. Operator GE matched 5 at TX:inbound_anomaly_score. [file
> "/etc/httpd/owasp-modsecurity-crs-3.0.0/rules/RESPONSE-980-CORRELATION.conf"]
> [line "73"] [id "980130"] [msg "Inbound Anomaly Score Exceeded (Total
> Inbound Score: 5 - SQLI=0,XSS=5,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0):
> Engine-Mode: "DETECTION_ONLY"
> 
> --6e7a4c70-Z--
> 
> I tried to post the entire log entry, but the barracuda that protects this
> list objected. I'm hoping that cutting down the content will work.
> 
> So I know that this is some sort of XSS problem, but no more than that. I
> checked with our web apps people, and the url parameters are quite
> legitimate.
> 
> What is the underlying rule that triggered this?  More importantly, how
> would I tell?
> 
> Finally, how do I turn this off so that the call continues to work once we
> take ModSecurity out of DETECTION_ONLY?
> 
> 
> Thanks
> 
> Ed
> 
> 
> ___
> 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

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

Re: [Owasp-modsecurity-core-rule-set] Announcing OWASP Core Rule Set Version 3.0.1

[Christian Folini]

Hi there,

Spot on. Thanks for reporting.
We noticed this issue last night and are currently preparing 3.0.2.

In the default install, a request passes that debug message.
A custom crs-setup.conf can lead to a block, though.

The messup came via mis-merging of a commit to solve the github issue 
719. Let's say Chaim and I cooperated to make this happen and
sneak it pass our pre-release testing
(See https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/771
for a writeup).

For the time being (until 3.0.2 is out like tonight or so):
 - Do as Jens described.
 or
 - SecRuleRemoveById 22
 or
 - Clone the latest v3.0/dev tree

We are sorry for pushing a broken rule out with a release. 
We are reviewing our release procedure now and hope to learn from this.
https://github.com/SpiderLabs/owasp-modsecurity-crs/wiki/Release-Procedure

If you have feedback on that, it's very welcome.

Best,

Christian







On Thu, May 11, 2017 at 01:05:16PM +0200, Jens Schleusener wrote:
> Hi,
> 
> > The OWASP Core Rule Set team is pleased to announce the immediate 
> > availability of CRS release v3.0.1
> > (https://github.com/SpiderLabs/owasp-modsecurity-crs/releases/tag/v3.0.1).
> 
> [... lines deleted ...]
> 
> > Ideally you should be able to update your 3.0.0 rules with the new 3.0.1 
> > rules without experiencing any
> > problems.
> .`

> Unfortunately not: The access to my server was blocked!
> 
> But fortunately the problem was easily to find and after removing the
> ("forgotten" debugging) line number 500
> 
>  SecRule REQUEST_URI "(.*)" "msg:'got %{tx.0}',id:22,capture"
> 
> in the file REQUEST-920-PROTOCOL-ENFORCEMENT.conf all seems to work again.
> 
> The difference in that file between 3.0.0 and 3.0.1 can be seen for e.g. on
> this page
> 
>  
> https://fossies.org/diffs/owasp-modsecurity-crs/3.0.0_vs_3.0.1/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf-diff.html
> 
> But the problem seems known
> 
>  https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/771
> 
> and I report it here only to save some people from potential trouble.
> 
> Regards
> 
> Jens
> ___
> 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

-- 
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] News from the Core Rule Set (2017-05-05)

[Christian Folini]

Dear all,

This is the CRS newsletter covering the period from April until today.

What has happened during the last few weeks:

- We held our 3rd community chat last Monday. We have been eight people
  and we had an extremely efficient meeting. We sorted out a strategy
  for the remaining 3.0dev issues and cleared the path for the 3.0.1
  release.  The next community chats will be held on the following
  dates:
  - Jun 5, 2017, 20:30 CEST (14:30 EST, 19:30 GMT)
  - Jul 3, 2017, 20:30 CEST
  - Aug 7, 2017, 20:30 CEST
  - Sep 4, 2017, 20:30 CEST
  - Oct 2, 2017, 20:30 CEST
  - Nov 6, 2017, 20:30 CET
  - Dec 4, 2017, 20:30 CET

- There are three open pull requests and three issues keeping us
  from releasing 3.0.1. The idea is to clear this during the weekend
  and release 3.0.1 on Tuesday, May 9.

- The release policy discussed last month has been described briefly
  at:
  https://github.com/SpiderLabs/owasp-modsecurity-crs/wiki/Release-Policy

- After the release policy last month, we decided on a way to organise
  CRS developers. We settled on the following roles
  - Project lead
  - Core team
  - Project contributors with commit permission
  - Contributors without commit permission

  As you know, Chaim is project lead and he forms the core team with
  Walter Hop and me. We also promoted regular contributors Franziska
  Bühler and Christoph Hansen to project contributors with commit
  permission.  There have been more people contributing to CRS 3.0.1
  and we hope to work with them so they can eventually be promoted to a
  commit permission level.

  The idea with the core team is, that every PR needs to be reviewed by
  at least one core team member. This also applies to PRs by core team
  members: They have to be reviewed by at least one additional
  core team member.

- There is general interest to publish more blog posts around CRS
  and also additional information.  We are working on a useful 
  platform here.

- Once CRS 3.0.1 is out the door, testing will be formalized and
  automated, we will close the very old issues and then start with the
  development for 3.1; incorporating new features and new rules.

- Hugo Costa is working on our new logo, but he is also working on
  various other tasks for AppSecEU. In the end AppSecEU won and we
  have to wait until after the conference.

- The security scanner research project resulted in 13 new issues so
  far: false negatives. That is requests which should be blocked but
  were not - or at least not on a reasonably low paranoia level.
  See all these tickets here:
  
https://github.com/SpiderLabs/owasp-modsecurity-crs/issues?q=is%3Aissue+is%3Aopen+label%3Azhaw-research-project
  The most severe false negative seems to be this payload
  which goes undetected at Paranoia Level 3:
  userinput=textvalue95920'%3balert(1)%2f%2f153
  Obviously, there is a transformation missing before the XSS rule
  in question is being executed.
  Other findings are not as dangerous, but also much harder to
  detect like out-of-band communication, where a request parameter
  is passed to nslookup to perform a DNS request.

Upcoming stuff

- CRS 3.0.1 release planned for Tuesday, May 9.

- The CRS meetup at AppSecEU will be rather informal. We were probably
  to late to announce it and fairly few people from the community
  will be making it. Chaim and I will be at the conference from
  Tuesday / Wednesday though. Please get in touch if you are around.
  The idea is to hang out together Wednesday night.

- My Core Rule Set 3.0 Intro talk at AppSecEU in Belfast has been
  scheduled for Thursday May 11, 4.15pm. Would be cool to see
  you.

  I will present the first part of the research (Burp vs. CRS3)
  at the SIGS Technology Conference in Zurich, May 18, 2017:
  www.sig-switzerland.ch/de/technology_conference/

- Next CRS chat: June 5, 2017, 20:30 CEST on Freenode IRC, channel
  #modsecurity (14:30 EST, 19:30 GMT)

Ahoj,

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] Up next Monday: CRS chat

[Christian Folini]

Hi there,

Next Monday, May 1, we'll do our regular Core Rule Set project chat.
20:30 CET (14:30 EDT, 18:30 GMT)
on Freenode IRC, channel #modsecurity

The topics will be the last preparations for the upcoming CRS 3.0.1 
which is almost done now, then better support for Travis testing,
the possibility of a regular CRS blog and two or three additional
things. If you have anything else to talk about, then please bring it
along. New faces welcome.

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

Re: [Owasp-modsecurity-core-rule-set] Modsecurity CRS for. Joomla! ??

[Christian Folini]

Arthur,

On Sat, Apr 22, 2017 at 09:42:42AM -0700, Arthur E. Johnston wrote:
> Does a CRS ver.3.0 exist for Joomla!
> 
> The only version currently available for Joomla! is 2.9 and that is very 
> outdated/not usable with current versions. 

Honestly, I do not really understand what you are trying to express.

CRS version jumped from 2.2.9 to 3.0.

We do not build versions specific for certain applications (but we started
to include rule exclusion packs to go with certain applications.
Joomla is not on the list, though).

Are you possibly talking about the commercial Trustwave rules?

Ahoj,

Christian


-- 
Freedom is the freedom to say that two plus two make four. If that
is granted, all else follows.
--- George Orwell in Nineteen Eighty-Four
___
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] OWASP Top 10 2017 RC1

[Christian Folini]

Osama,

Thank you for the link. I was not aware of that development.
I love the new risk matrix and the added content. Very good read.

Ahoj,

Christian

On Mon, Apr 10, 2017 at 09:31:56PM -0400, Osama Elnaggar wrote:
> Hi,
> 
> Not sure if you guys saw this, but the new OWASP Top 10 (2017 RC1) was
> released yesterday -
> https://github.com/OWASP/Top10/raw/master/2017/OWASP%20Top%2010%20-%202017%20RC1-English.pdf
> 
> 
> I found it interesting that under A7: Insufficient Attack Protection, it
> specifically mentions looking into WAFs, RASP and OWASP AppSensor to detect
> automatic attacks and block them.  This is the first time that the OWASP
> Top 10 mentions WAFs as far as I can tell.
> 
> Perhaps this is a good for some ModSecurity marketing and promotion?
> 
> -- 
> Osama Elnaggar

> --
> 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-security-us...@lists.sourceforge.net
> 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
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] fwd: [oelnagga...@gmail.com: [mod-security-users] OWASP Top 10 2017 RC1]

[Christian Folini]

This might be of interest for this mailinglist too.

Cheers,

Christian

- Forwarded message from Osama Elnaggar  -

Date: Mon, 10 Apr 2017 21:31:56 -0400
From: Osama Elnaggar 
To: mod-security-us...@lists.sourceforge.net
Subject: [mod-security-users] OWASP Top 10 2017 RC1
Reply-To: mod-security-us...@lists.sourceforge.net

Hi,

Not sure if you guys saw this, but the new OWASP Top 10 (2017 RC1) was
released yesterday -
https://github.com/OWASP/Top10/raw/master/2017/OWASP%20Top%2010%20-%202017%20RC1-English.pdf


I found it interesting that under A7: Insufficient Attack Protection, it
specifically mentions looking into WAFs, RASP and OWASP AppSensor to detect
automatic attacks and block them.  This is the first time that the OWASP
Top 10 mentions WAFs as far as I can tell.

Perhaps this is a good for some ModSecurity marketing and promotion?

-- 
Osama Elnaggar

--
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-security-us...@lists.sourceforge.net
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/


- End forwarded message -

-- 
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] News from the Core Rule Set (2017-04-07)

[Christian Folini]

Dear all,

This is the CRS newsletter covering the period from March until today.

What has happened during the last few weeks:

- We held our 2nd community chat last Monday. We have been six people
  this time around and what feels even more important: five out of those
  accepted tasks to solve open issues.
  The next community chats will be held on the following dates:
  - May 1, 2017, 20:30 CEST (14:30 EST, 19:30 GMT)
  - June 5, 2017, 20:30 CEST
  - Jul 3, 2017, 20:30 CEST
  - Aug 7, 2017, 20:30 CEST
  - Sep 4, 2017, 20:30 CEST
  - Oct 2, 2017, 20:30 CEST
  - Nov 6, 2017, 20:30 CET
  - Dec 4, 2017, 20:30 CET

- We settled on a general release policy. Point releases (3.0.1, 3.0.2,
  etc.) will be maintenance releases concentrating on reducing false
  positives. No new rules will be introduced in a point release, unless
  we split a rule to solve a false positive. We will of course also look
  into bugs and documentation issues, but the idea with point release is
  to reduce strain on users updating CRS and give them confidence that
  no new blocks of legitimate traffic will occur. It is thus safe to
  update. The next release with new rules / features will be 3.1.0.

- We plan to take up development for an eventual 3.1.0 after the 3.0.1 
  release.

- 3.0.1 will come out in the next few weeks. We have assigned the
  remaining issues 
  
https://github.com/SpiderLabs/owasp-modsecurity-crs/issues?q=is%3Aissue+is%3Aopen+label%3A%22v3.0-dev+Development%22
  and are confident to solve them quite fast now.
  We will also freeze for new false positives on Monday, April 10.
  This means: False positives reported until April 10 will likely
  be fixed in time for 3.0.1. FPs reported after that date will have
  to wait for 3.0.2.

- We discovered a new bug on rule 941150. Github user @UncleIS had
  pointed to a bug in this rule before, but now we realised that
  this PL1 rule raises the incoming anomaly score without writing an alert.
  FPs are relatively rare here, but you might not notice unless
  you pay very close attention to the anomaly scores.
  You can follow the discussions via github issue 704:
  https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/704

- Github user @emphazer points to RFC 3902 and the fact that SOAP
  requests are meant to be sent with content-type application/soap+xml
  We will adopt the allowed content-types accordingly, but you also
  have to define the value in the offical base rules of the ModSecurity
  project itself, where you defing the XML request body processor
  based on the content-type request header.
  https://github.com/SpiderLabs/owasp-modsecurity-crs/pull/721

- CRS project lead Chaim Sanders has quit his job at Trustwave and
  continues his commitment to our project. We remain in close touch with
  Trustwave via ModSecurity lead developer Felipe and new TW team member
  Victor.

- The TYPO 3 side project kind of stalled, but lately github user
  @emphazer contributed with new TYPO3 pull requests against my
  CRS/TYPO3 branch.

- The testing of CRS3 with several security scanners is making good
  progress, though. We have done Burp, Kkipfish and the bleeding
  edge Zap 2.6.0. Arachni is being tested as I write this.

- We have been pondering over the idea to have a CRS project logo.
  We want to lean on the OWASP logo and getting OWASP's permission
  to do so took a surprisingly long time. But now Hugo Costa, the
  designer of the CRS3 release poster, is working on the project.

What is thus planned for the next few weeks:

- The release of CRS 3.0.1, maybe with a preliminary RC first.

- First results of the security scanner tests.

- More news from the logo project.

- The CRS meetup at AppSecEU is going to be on Wednesday May 10
  in Belfast. Time and place not yet defined.

- My Core Rule Set 3.0 Intro talk at AppSecEU in Belfast has been
  scheduled for Thursday May 11, 4.15pm. Would be cool to see
  you.

- Next CRS chat: May 1, 2017, 20:30 CEST on Freenode IRC, channel
  #modsecurity (14:30 EST, 19:30 GMT)

Ahoj,

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

Re: [Owasp-modsecurity-core-rule-set] Up next Monday: CRS chat

[Christian Folini]

Hello,

Just a reminder, the chat is up in 6.5 hours.

I have been notified that will be 20:30 CEST (not 20:30 CET as I
previously stated).

Ahoj,

Christian

out, that the correct name of the time zone is CEST not CET

On Fri, Mar 31, 2017 at 06:50:11AM +0200, Christian Folini wrote:
> Hi there,
> 
> Next Monday, April 3, we'll do our regular Core Rule Set project chat.
> 20:30 CET (14:30 EDT, 18:30 GMT) 
> on Freenode IRC, channel #modsecurity
> 
> The topics will be preparations for the upcoming CRS 3.0.1 release
> and anything else that springs to mind. If you have other things to
> discuss that interests the whole project then please bring it along
> (it might be useful to announce big topics first, though, so people
> can make up their mind beforehand).
> 
> 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

-- 
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] Up next Monday: CRS chat

[Christian Folini]

Hi there,

Next Monday, April 3, we'll do our regular Core Rule Set project chat.
20:30 CET (14:30 EDT, 18:30 GMT) 
on Freenode IRC, channel #modsecurity

The topics will be preparations for the upcoming CRS 3.0.1 release
and anything else that springs to mind. If you have other things to
discuss that interests the whole project then please bring it along
(it might be useful to announce big topics first, though, so people
can make up their mind beforehand).

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

Re: [Owasp-modsecurity-core-rule-set] Send back the correct response code

[Christian Folini]

Sheldon,

The default action does not really matter much in this regard. You
can oversteer it in your rules. I really do not see the issue.

Somebody else understands the problem correctly?

Ahoj,

Christian

On Mon, Mar 27, 2017 at 02:28:33PM +, Briand, Sheldon (NRC/CNRC) wrote:
> Hi,
> 
> Still playing with this one.  I can set my status in a rule (based on the 
> backup tomcat status) but ultimately the user sees a 403 no matter what I do.
> 
> I'm guess it is because of the default disruptive action when a deny action 
> is in effect.  The default action is to send a 403.  I see in 
> RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf there are ways to change the 
> default action.
> 
> Is there a way of saying: if backend_status is XXX then set the 
> SetRuleUpdateActionById to a relevant rule? (Is that the best way to handle 
> what I want to do?) I assume I would do that in the RESPONSE-999-EXCLUSION 
> conf file.
> 
> Thanks,
> -Sheldon
> 
> -Original Message-
> From: fol...@netnea.com [mailto:fol...@netnea.com] 
> Sent: Wednesday, March 01, 2017 5:28 PM
> To: Briand, Sheldon (NRC/CNRC) <sheldon.bri...@canada.ca>
> Cc: Christian Folini <christian.fol...@netnea.com>
> Subject: RE: [Owasp-modsecurity-core-rule-set] Send back the correct response 
> code
> 
> Hey Sheldon,
> 
> Your rule work in phase 4. But in phase 4, the status header is already sent 
> out. If you want to manipulate it, you need to do this in phase 3.
> 
> Ahoj,
> 
> Christian
> 
> > Hi,
> >
> > Thanks for the suggestions so far.  I haven't managed to make it work 
> > and just wanted to see if what I did makes sense.  (BTW backend server 
> > is
> > tomcat)
> >
> > I put the following rule in a local.conf in the rules directory:
> > SecRule RESPONSE_HEADERS:status "^(.*?)$"
> > "phase:3,pass,id:1,setvar:tx.backend_status=%{MATCHED_VAR}"
> >
> > I changed RESPONSE-959-BLOCKING-EVALUATION.conf:
> > SecRule TX:OUTBOUND_ANOMALY_SCORE "@ge 
> > %{tx.outbound_anomaly_score_threshold}" \
> >   "phase:4,\
> >   id:959100,\
> >   tag:'anomaly-evaluation',\
> >   t:none,\
> >   deny,\
> >   status:%{TX.backend_status}"
> >
> > RESPONSE-952-DATA-LEAKAGES-JAVA.conf:
> > SecRule RESPONSE_BODY "@pmFromFile java-code-leakages.data" \
> > "phase:4,\
> > rev:'3',\
> > ver:'OWASP_CRS/3.0.0',\
> > maturity:'9',\
> > accuracy:'9',\
> > t:none,\
> > capture,\
> > ctl:auditLogParts=+E,\
> > block,\
> > msg:'Java Source Code Leakage',\
> > logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}:
> > %{MATCHED_VAR}',\
> > id:952100,\
> > tag:'application-multi',\
> > tag:'language-java',\
> > tag:'platform-multi',\
> > tag:'attack-disclosure',\
> > tag:'OWASP_CRS/LEAKAGE/SOURCE_CODE_JAVA',\
> > tag:'WASCTC/WASC-13',\
> > tag:'OWASP_TOP_10/A6',\
> > tag:'PCI/6.5.6',\
> > severity:'ERROR',\
> > setvar:'tx.msg=Access denied with code %{tx.backend_status}',\
> > setvar:tx.outbound_anomaly_score=+%{tx.error_anomaly_score},\
> > setvar:tx.anomaly_score=+%{tx.error_anomaly_score},\
> > 
> > setvar:tx.%{rule.id}-OWASP_CRS/LEAKAGE/SOURCE_CODE-%{matched_var_name}=%{tx.0}"
> >
> > I'm seeing errors like this where the status isn't passed:
> > Message: Access denied with code 403 (phase 4). Matched phrase 
> > "javax.servlet" a t RESPONSE_BODY. [file 
> > "/etc/httpd/modsecurity.d/owasp-modsecurity-crs/rules/RES
> > PONSE-952-DATA-LEAKAGES-JAVA.conf"] [line "50"] [id "952100"] [rev 
> > "3"] [msg "Ja va Source Code Leakage"] [data "Matched Data: 
> > javax.servlet found within RESPONS
> > E_BODY: Apache Tomcat/8.0.41 - Error 
> > report > itle>

[Owasp-modsecurity-core-rule-set] News from the Core Rules (2017-03-10)

[Christian Folini]

s (Firefox does), then you can
  define one as follows:
  https://www.netnea.com/crs/%s with keyword crs and then call it with
  lookup like "crs 949110" in the address bar of the browser.
  Very helpful and I use this several time as day.
  I also plan to expand the information displayed in this list. What
  are the bits of infos that you think should be included? Please
  respond on the list or in private.


What's coming in the next few weeks:

- Damiano and I hope to give you a sneek preview of some research
  results.
- We're closing false positives based on the issues reported on github.
- More details of the CRS summit at AppSecEU will be defined and
  published.
- Next CRS3 chat: April 3, 2017, 20:30 MET on Freenode IRC, channel
  #modsecurity (14:30 EST, 19:30 GMT) 

So this is it for the first CRS newsletter. If I missed something,
please let me know. Feedback - good and bad - is much appreciated (which
means: If you like this, then please let me know and share 
this message).

Best regards,

Christian Folini, for the OWASP ModSecurity Core Rule Set team

-- 
CRS website: https://www.modsecurity.org/crs
CRS at OWASP: 
https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project
CRS tutorials: https://netnea.com/apache-tutorials
___
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] Rule 951100 is corrupted

[Christian Folini]

Ehsan,

On Tue, Mar 07, 2017 at 09:43:39PM +0330, Ehsan Mahdavi wrote:
> It does nothing
> It doesn't increment any inbound scores
> So if you use anomaly mechanism nothing will happen.

No, that is not correct.

If you examine it, you will notice that the rule 951100
sets the variable sql_error_match. The remaining rules in
the 951xxx group use this variable and link it to an information
about the DBMS used by the backend.

> On the other hand,  sql-error.data file contains general terms like "error"
> and "warning". If the rule works, it will generate tons of false positives.

Again, this has to be seen in the light of the following rules.
"Error" is not enough. It takes "Error" in combination with a string
like "JET Database Engine". And if you have "Error" in combination
with a DB engine, then I think it is a real positive and the
response should be blocked.

Did I convince you? If not, please explain where I make a mistake
in my thinking. An example response with an error ignored by CRS
(-> false negative) or a false positive would really help.

Ahoj,

Christian



> 
> On Tuesday, March 7, 2017, Christian Folini <christian.fol...@netnea.com>
> wrote:
> 
> > Hi there,
> >
> > Ooops. What is the problem? Here is the rule in question?
> >
> > SecRule RESPONSE_BODY "@pmFromFile sql-errors.data" \
> > "phase:response,\
> > id:951100,\
> > rev:'5',\
> > ver:'OWASP_CRS/3.0.0',\
> > pass,\
> > nolog,\
> > tag:'application-multi',\
> > tag:'language-multi',\
> > tag:'platform-multi',\
> > tag:'attack-disclosure',\
> > setvar:tx.sql_error_match=1,\
> > t:none"
> >
> > Is there something wrong with the mechanism or have you found an
> > sql-error not being listed in the data file? The latter is very well
> > possible and we would welcome submissions of additional error strings.
> >
> > Ahoj,
> >
> > Christian
> >
> >
> > On Tue, Mar 07, 2017 at 06:57:29PM +0330, Ehsan Mahdavi wrote:
> > > 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 <javascript:;>
> > > 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 <javascript:;>
> > https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
> >
> 
> 
> -- 
> regards
>  Ehsan.Mahdavi
> PhD candidated for Computer Engineering
> by Isfahan University of Technology
> http://emahdavi.ece.iut.ac.ir/
___
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] Fwd: exception rules result in application errors.

[Christian Folini]

Hello Hagen,

On Thu, Feb 16, 2017 at 08:57:14PM +0100, Hagen Bauer wrote:
> Unfortunately with this rules
> 
> SecRule REQUEST_URI "@beginsWith /callback/paypal/ipn.php"
> "phase:2,nolog,pass,id:10003,ctl:ruleRemoveTargetById=942460;ARGS:item_name1"
> SecRule REQUEST_URI "@beginsWith /callback/paypal/ipn.php"
> "phase:2,nolog,pass,id:10004,ctl:ruleRemoveTargetById=942460;ARGS:item_name2"
> 
> the functionality behind this url stops working.

Hmm. Your approach seems correct to me. I do not see how this
rule could possibly destroy the functionality.

> Any ideas where my error is?

I strongly suspect you have made a mistake somewhere along the
line.

I would do the following:
 - comment out the two exclusion rules
 - rerun request
 - if it still does not work, then the error is somewhere else.
 - if it does indeed work, then activate the exclusion rules again
   - if it still works, then your report was wrong
   - if it stops working, then please send the complete apache config
 and a complete audit log of the request with the rules activated
 and I will try to reproduce.

Good luck!

Christian

___
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] [CRS 3.0, Nginx] Anomaly detection rule does not trigger

[Christian Folini]

On Mon, Jan 16, 2017 at 08:15:22PM +, Géza Búza wrote:
> As I see it states that the anomaly score is 5 at that point.
> It looks like REQUEST-949-BLOCKING-EVALUATION is evaluated before
> REQUEST-941-APPLICATION-ATTACK-XSS, at least it appears earlier in the log.

Bingo.

The install file says you need to install on NginX by naming the
rules files one by one:

include modsecurity.conf
include owasp-modsecurity-crs/crs-setup.conf
include 
owasp-modsecurity-crs/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
include owasp-modsecurity-crs/rules/REQUEST-901-INITIALIZATION.conf
include owasp-modsecurity-crs/rules/REQUEST-905-COMMON-EXCEPTIONS.conf
include owasp-modsecurity-crs/rules/REQUEST-910-IP-REPUTATION.conf
include owasp-modsecurity-crs/rules/REQUEST-911-METHOD-ENFORCEMENT.conf
include owasp-modsecurity-crs/rules/REQUEST-912-DOS-PROTECTION.conf
include owasp-modsecurity-crs/rules/REQUEST-913-SCANNER-DETECTION.conf
include owasp-modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf
include owasp-modsecurity-crs/rules/REQUEST-921-PROTOCOL-ATTACK.conf
include owasp-modsecurity-crs/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf
include owasp-modsecurity-crs/rules/REQUEST-931-APPLICATION-ATTACK-RFI.conf
include owasp-modsecurity-crs/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf
include owasp-modsecurity-crs/rules/REQUEST-933-APPLICATION-ATTACK-PHP.conf
include owasp-modsecurity-crs/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf
include owasp-modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf
include 
owasp-modsecurity-crs/rules/REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION.conf
include owasp-modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf
include owasp-modsecurity-crs/rules/RESPONSE-950-DATA-LEAKAGES.conf
include owasp-modsecurity-crs/rules/RESPONSE-951-DATA-LEAKAGES-SQL.conf
include owasp-modsecurity-crs/rules/RESPONSE-952-DATA-LEAKAGES-JAVA.conf
include owasp-modsecurity-crs/rules/RESPONSE-953-DATA-LEAKAGES-PHP.conf
include owasp-modsecurity-crs/rules/RESPONSE-954-DATA-LEAKAGES-IIS.conf
include owasp-modsecurity-crs/rules/RESPONSE-959-BLOCKING-EVALUATION.conf
include owasp-modsecurity-crs/rules/RESPONSE-980-CORRELATION.conf
include 
owasp-modsecurity-crs/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf

Is this what you did?

Your logfiles looks like you did include rules/*.conf.

Ahoj,

Christian



> 
> 
> Michael, I'm using this Docker based installation:
> https://github.com/theonemule/docker-waf
> Could you take a look at the configuration files located at
> https://github.com/theonemule/docker-waf/tree/master/waf? You may spot a
> mistake there.
> 
> Regards,
> Geza
> 
> 
> Muenz, Michael  ezt írta (időpont: 2017. jan.
> 16., H, 9:09):
> 
> > Am 15.01.2017 um 19:11 schrieb Géza Búza:
> > > Hi all,
> > >
> > > I'm new to ModSecurity and wanted to try it out by installing Nginx
> > > 1.10.2, latest ModSecurity (master branch), with latest CRS
> > > (v3.0/master branch).
> > >
> > > With the default settings on, I tried to send an attack request and
> > > expected to see it blocked.
> > > So I sent the request below to the demo application
> > > GET http://172.17.0.1/?param=;>alert(1);
> > > and it responded with 200 OK (which is okay since it's in detection
> > > only mode by default),
> > > but I expected to see the error "Inbound Anomaly Score Exceeded (Total
> > > Score: 5)" in the audit log. There is no such message, but other rules
> > > have triggered as I expected.
> > > I attached the complete log of the HTTP GET request.
> > >
> > > Could you give me guidance what am I missing?
> > Hi,
> >
> > I've tested in on my installation with
> > ?param=">alert(1); and I'm hitting 19 rules, so there's
> > and error somewhere in your configuration.
> >
> > Michael
> >
> > --
> > www.routerperformance.net
> > - Cisco, Linux, Networks
> > ___
> > 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
> >
> -- 
> Üdvözlettel,
> Búza Géza

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


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

Re: [Owasp-modsecurity-core-rule-set] [CRS 3.0, Nginx] Anomaly detection rule does not trigger

[Christian Folini]

Hi there,

This is odd, I agree. I am personally not much into NginX, but I
take it, rule 949110 should be present.

Could you please set the debug log level to 9 and repeat the
request. Then look for 949110 in the debug log maybe send you that
piece of the log (remember to return to a reasonable loglevel
afterwards, or the file will grow like mad quickly.

Ahoj,

Christian


On Sun, Jan 15, 2017 at 06:11:51PM +, Géza Búza wrote:
> Hi all,
> 
> I'm new to ModSecurity and wanted to try it out by installing Nginx 1.10.2,
> latest ModSecurity (master branch), with latest CRS (v3.0/master branch).
> 
> With the default settings on, I tried to send an attack request and
> expected to see it blocked.
> So I sent the request below to the demo application
> GET http://172.17.0.1/?param=;>alert(1);
> and it responded with 200 OK (which is okay since it's in detection only
> mode by default),
> but I expected to see the error "Inbound Anomaly Score Exceeded (Total
> Score: 5)" in the audit log. There is no such message, but other rules have
> triggered as I expected.
> I attached the complete log of the HTTP GET request.
> 
> Could you give me guidance what am I missing?
> -- 
> Üdvözlettel,
> Búza Géza
> -- 
> Üdvözlettel,
> Búza Géza


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


-- 
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] CRS3 article on lwn.net

[Christian Folini]

Hi there,

Linux Weekly News ran an article about the Core Rule Set 3.0 before
Christmas. It has been made freely available yesterday:

https://lwn.net/Articles/709348/

I think it gives a good intro into the topic.

Ahoj,

Christian

P.S. The week before, there was a ModSecurity article that I wrote:
https://lwn.net/Articles/708673/

-- 
Only 4 tickets left for the next ModSec course:
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

Re: [Owasp-modsecurity-core-rule-set] Problem with ModSecurity internal error flagged: TX: MSC_PCRE_LIMITS_EXCEEDED

[Christian Folini]

Hello Gessy,

Sorry to hear about your problems. PCRE limit issues are common with the
CRS. They are an inherent problems when using PCRE and not all rules
are optimised to avoid it.

The limit is here to protect you from DoS via Regex (-> REDoS). But in
the default ModSec setting the limit will stop a rule from being
executed. So if an attacker can construct the payload in a way that
fails with a PCRE limit exception - and still work as an exploit on the
backend - he has successfully circumvented one of your rules. Your
defense is raising the PCRE limits. Both, as you did. But this makes you
more vulnerable to REDoS. However in the age of the Mirai botnet,
REDoS might be your least DoS concern, so it is generally OK to
raise the limits to even higher levels. Personally, I run some prod
servers with a limit of 1M.

I investigated this throughly for the 2nd edition of the ModSecurity
Handbook. It was only at 1M that I started to see a performance impact.
You can monitor it fairly easily via the overall duration of the request
or the ModSecurity performance data for phase 2.

With that being said, I suggest you raise some more and then you look
at the rules in question. I would not mind you issuing some tickets
on github with the exact payload and the rules where you ran into
the PCRE limits.

I do not think you should disable the susceptible rules, but it is
generally OK to ignore the PCRE limit alerts. If you stick with the
default setting of ModSec and CRS, the rule is simply aborted and
execution continues with the next rule.

If this is still unclear, then just ask.

Ahoj,

Christian


On Wed, Jan 04, 2017 at 01:52:34PM +, Gessy wrote:
> Hi
> Thanks to the community for all support and would like to ask one more
> question
> I used modsecurity with CRS 2.2.5 rules and everything worked as expected.
> I have decided to upgrade to modsecurity 2.9.1 and CRS 3.0.0 by following
> the INSTALL file.
> 
> Then I started having many blocking events with the message "ModSecurity
> internal error flagged: TX: MSC_PCRE_LIMITS_EXCEEDED"
> 
> I googled it and tried the solution
> 
>  SecPcreMatchLimit 15
>  SecPcreMatchLimitRecursion 15
> 
> But it did not work and it did not help to further increase the limits
> 
> So I thought about disabling the rule that generates this block but I saw
> that several rules can generate this
> 
> I'm having many events of this mainly with sites that use shibboleth
> authentication and I do not know how to solve it anymore ... Does anyone
> know how to solve this problem?
> 
> Thank you so much!!!

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


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

Re: [Owasp-modsecurity-core-rule-set] News from the Core Rules (2016-12-23)

[Christian Folini]

On Thu, Dec 22, 2016 at 11:15:56PM -0600, Bill Miller wrote:
> Thanks for that inventory.  It will be helpful.

Glad you like it. :)

-- 
Experience is what you get while looking for something else.
-- Federico Fellini
___
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] News from the Core Rules (2016-12-23)

[Christian Folini]

Hi there,

It's been a few weeks, and I thought I'd do another status update.

The CRS3 release was six weeks ago. We were a bit afraid, that adoption
would lead to many reports of new false positives. That is clearly not
the case. Feeling better now. You can check the open issues with CRS
3.0.0 on github:
https://github.com/SpiderLabs/owasp-modsecurity-crs/issues?q=is%3Aissue+is%3Aopen+label%3A%22v3.0-dev+Development%22

There is a mini-tutorial at How-To-Forge on how to run CRS3 with
ISPConfig. We may look into integrating the documented rule exclusions
in a future CRS version.
https://www.howtoforge.com/community/threads/mini-howto-modsecurity-crs-3-0-on-debian-jessie.74898

Longtime Debian packager Alberto Gonzalez Iniesta has packaged CRS3 for
debian and published the new package. I worked with him on package
optimization (better paths, simpler includes, better description, etc.).
That work will be uploaded right before Debian Stretch (the next Debian
release) will be frozen. The Debian package is of course very important
as it will be picked up by many other distributions depending on Debian.
https://packages.debian.org/jessie-backports/modsecurity-crs

The tutorials about Apache/ModSecurity that I updated for CRS3 have been
translated to German. You can get them here:
https://www.netnea.com/cms/apache-tutorials-de/

While staying at a hotel in Germany during a ModSec course I ran, I
hacked together a Core Rule Set inventory. It gives you an overview
over all CRS3 rules and serves as link to the definition of the rule
on github. There are also options for easy access like typing
"crs 942100" in the address bar of the browser and being taken to
the right rule entry in the rule inventory immediately. So if you
face an alert, you can type the rule id in the browser and it
gives you all you need to know about the rule that triggered the alarm:
https://www.netnea.com/cms/core-rule-set-inventory

The next course will be in Zurich, Switzerland, near the end of
February. There is now a single early bird ticket left. And afterwards
a hand full of regular price tickets:
https://www.feistyduck.com/training/modsecurity-training-course

Chaim, Walter and I are planning to make an appearance at the
OWASP AppSecEurope conference in Belfast in May. We are planning various
talks and activities around the Core Rule Set. If you want to join
(or support and contribute!), you can follow our plans on the OWASP
wiki:
https://www.owasp.org/index.php/CRSAppSecEU2017

And finally, Linux Weekly News published an article on ModSecurity last
week: 
https://lwn.net/Articles/708673/ 
A second one about CRS3 came out yesterday. It is paywalled for seven
days, afterwards it will become freely available. If you are not a
subscriber, but you want instant access nevertheless, then let me know
and I can send you a subscriber's link.

That's all that springs to mind right now.

All the best!

Christian

-- 
CRS website: https://www.modsecurity.org/crs
CRS at OWASP: 
https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project
CRS tutorials: https://netnea.com/apache-tutorials
___
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?

[Christian Folini]

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

Re: [Owasp-modsecurity-core-rule-set] [mod-security-users] CRS3 WordPress Exclusions

[Christian Folini]

Jason,

This is an core rule set question, that you asked on the general
ModSecurity mailinglist. I'll move over to the CRS
mailinglist for a response:

The optional WordPress rule exclusions need to be activated in the
crst-setup.conf. There is not yet a blog post or detailed documentation
about it, but it basically follows the Drupal stuff, which I depicted
in this blog post this week:
https://www.netnea.com/cms/2016/11/22/securing-drupal-with-modsecurity-and-the-core-rule-set-crs3/

If you follow that documentation and apply it to WP you should be good.

What is central is, that we are only covering the core stuff so far.
We have bigger plans, but this is only a start. There is a bunch of
additional rule exclusions being discussed on github right now. So you
can expect to get a lot of improvement with subsequent point releases.

So far, you can install and publish and read articles without any
false positives. But the deeper you dig into the admin stuff, the
more likely will you encounter FPs.

Good luck - and let's move over to the CRS mailinglist.

Cheers,

Christian



On Fri, Nov 25, 2016 at 08:12:16PM +, Jason Mull wrote:
> Hello,
> 
> 
> 
> While reading over the mailing list post regarding the release of CRS3, I 
> noticed mention of application-level exclusions for WordPress.  Is there 
> anywhere I can find more info on this functionality (Where / how to enable, 
> how to view / add exclusions)?
> 
> 
> Jason

> --

> ___
> mod-security-users mailing list
> mod-security-us...@lists.sourceforge.net
> 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
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] No rule-id in audit/error log with Nginx und MS3/CRS3

[Christian Folini]

Glad that's solved. Thanks for the update!

Christian

On Fri, Nov 25, 2016 at 11:21:04AM +0100, Muenz, Michael wrote:
> Am 24.11.2016 um 17:37 schrieb Christian Folini:
> >On Thu, Nov 24, 2016 at 05:02:43PM +0100, Muenz, Michael wrote:
> >>SecAuditLogParts ABIJDEFHZ
> >It's a little known detail that Audit Log Parts need to be set
> >in alphabetic order. But I do not think this is the problem here.
> >
> >For me, this sounds like a ModSec/NginX bug - unless you have some other
> >base config which tweaks the audit log in the said fashion. But I
> >do not see how you could.
> >
> >So to me, this is not a CRS problem, but a ModSec on NginX problem.
> >
> 
> LogParts is the default from modsecurity.conf.
> Yesterday Nginx updated their guide for the current version, now
> everything gets logged.
> It's a bug/change in the MS-Nginx connector where everything is
> logged with info severity.
> 
> Thanks,
> Michael
> ___
> 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

Re: [Owasp-modsecurity-core-rule-set] No rule-id in audit/error log with Nginx und MS3/CRS3

[Christian Folini]

On Thu, Nov 24, 2016 at 05:02:43PM +0100, Muenz, Michael wrote:
> SecAuditLogParts ABIJDEFHZ

It's a little known detail that Audit Log Parts need to be set
in alphabetic order. But I do not think this is the problem here.

For me, this sounds like a ModSec/NginX bug - unless you have some other
base config which tweaks the audit log in the said fashion. But I
do not see how you could.

So to me, this is not a CRS problem, but a ModSec on NginX problem.

Next step would be to remove the complete CRS and then copy
the said rule into the remaining config. And then you change
the rule action form pass to deny and give it another shot.

> What I changed in crs-setup.conf was:
> 
> SecDefaultAction "phase:1,log,auditlog,deny,status:403"
> SecDefaultAction "phase:2,log,auditlog,deny,status:403"
> 
> ... instead of the default.

That is perfectly OK configurationwise (outside of the fact that
anomaly scoring mode is the default for a good reason. Unless you
have thought about this a lot and you really know what you are
doing, I suggest you stay in anomaly scoring mode).

Ahoj,

Christian


-- 
You don't have to be great to start, but you have to 
start to be great. 
-- Zig Ziglar
___
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] False positive on rule 920300

[Christian Folini]

On Tue, Nov 15, 2016 at 07:53:52PM +, Jose Pablo Valcárcel Lázaro wrote:
> Sorry Christian. I didn't look in your tutorial CRS3:
> 
> 152 x 942260 Detects basic SQL authentication bypass attempts 2/3
> -
>   # ModSec Rule Exclusion: 942260 : Detects basic SQL authentication
> bypass attempts 2/3
>   SecRule REQUEST_URI "@beginsWith /drupal/index.php/search/node"
> "phase:2,nolog,pass,id:10003,ctl:ruleRemoveTargetById=942260;ARGS:keys"

Nevermind. ;)

And the fact, that my tutorial works with the same rule
is a pure coincidence.

Ahoj,

Christian


> 
> Regards
> 
> El mar., 15 de noviembre de 2016 20:44, Christian Folini <
> christian.fol...@netnea.com> escribió:
> 
> > Kamil,
> >
> > Thanks for reporting.
> >
> > You are facing the following alerts:
> >
> > 920300 REQUEST_HEADERS:User-Agent Request Missing an Accept Header
> > 920300 REQUEST_HEADERS:User-Agent Request Missing an Accept Header
> > 942260 REQUEST_COOKIES:OutlookSession Detects basic SQL auth bypass
> > 942260 REQUEST_COOKIES:OutlookSession Detects basic SQL auth bypass
> >
> > 920300 is usually legitimate and likely points to a client not sending
> > the accept header like it should. This is a widespread misbehaviour.
> > That is why we pushed the rule to paranoia level 2. You are apparently
> > running PL2 or higher. You should thus tune this alert away via a rule
> > exclusion.
> >
> > The 942260 is likely also legitimate. It's just that your poor client
> > has a session cookie smelling of SQL authentication bypass. You
> > should exclude the said cookie from the list of parameters examined
> > by 942260.
> >
> > My tutorials at https://www.netnea.com/cms/apache-tutorials give
> > you detailed step by step instructions how to do this.
> >
> > Best,
> >
> > Christian
> >
> >
> >
> > On Tue, Nov 15, 2016 at 05:54:52PM +0100, kamil kapturkiewicz wrote:
> > > Hi,
> > > I have had this issue with previous 2.2.9 version, but I am not really
> > sure is related to mod_security it self or to CRS. The problem is with some
> > Windows machines, below is the example from one of our corporate user, who
> > is working on Windows 7 machine. I am pretty sure machine is not infected
> > by malware or something, and this problem occures on FF, Chrome, Opera and
> > IE. But in combination with fail2ban, this cut him off from web server
> > every time he is trying to access company website. Do
> > > you guys have any idea what is causing this?
> > >
> > > [Tue Nov 15 16:26:41.962933 2016] [:error] [pid 31434] [client
> > 213.81.82.201] ModSecurity: Warning. Match of "pm
> > > AppleWebKit Android" against "REQUEST_HEADERS:User-Agent" required.
> > [file
> > "/usr/share/owasp-modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"]
> > [line "1251"] [id "920300"] [rev "3"] [msg "Request Missing an Accept
> > Header"] [severity "NOTICE"] [ver "OWASP_CRS/3.0.0"] [maturity "9"]
> > [accuracy "8"] [tag "application-multi"] [tag "language-multi"] [tag
> > "platform-multi"] [tag "attack-protocol"] [tag
> > "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT"] [tag
> > "WASCTC/WASC-21"] [tag
> > > "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [tag "paranoia-level/2"] [hostname
> > "domain.com"] [uri "/autodiscover/autodiscover.xml"] [unique_id
> > "WCs3QX8AAQEAAHrKJTMF"]
> > > [Tue Nov 15 16:26:41.963976 2016] [:error] [pid 31434] [client
> > 213.81.82.201] ModSecurity: Access denied with code 403 (phase 2). Pattern
> > match
> > "(?i:(?:unions*?(?:all|distinct|[(!@]*?)?s*?[([]*?s*?selects+)|(?:w+s+likes+[\\"'`])|(?:likes*?[\\"'`]%)|(?:[\\"'`]s*?likeW*?[\\"'`d])|(?:[\\"'`]s*?(?:n?and|x?x?or|div|like|between|and|not||||&&)s+[sw]+=s*?w+s*?h
> > ..." at REQUEST_COOKIES:OutlookSession. [file
> > >
> > "/usr/share/owasp-modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"]
> > [line "705"] [id "942260"] [rev "2"] [msg "Detects basic SQL authentication
> > bypass attempts 2/3"] [data "Matched Data: \\x22{BB1B2590-E found within
> > REQUEST_COOKIES:OutlookSession:
> > \\x22{BB1

[Owasp-modsecurity-core-rule-set] OWASP ModSecurity Core Rule Set Version 3.0.0 Released

[Christian Folini]

The OWASP ModSecurity Core Rule Set team is excited to announce the
CRS release v3.0.0, short CRS3.

Over 4 years in the making, this release represents a huge step forward
in terms of capabilities, usability and protection. Key features
include:

* Over 90% reduction of false alarms in a default install 
  when compared to CRS2
* A user-defined Paranoia Level to enable additional strict checks
* Application-specific exclusions for WordPress Core and Drupal
* Sampling mode: runs the CRS on a user-defined percentage of traffic
* SQLi/XSS parsing using libinjection embedded in ModSecurity

For a complete list of new features and the changes in this release, see 
the new site of the project
https://modsecurity.org/crs
or the CHANGES document on github
https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.0/master/CHANGES

CRS3 is the best stable release of the OWASP ModSecurity Core Rule Set.
We advise all users and providers of boxed CRS versions to update their
setups. CRS2 will reach its end of life soon.

CRS3 requires an Apache/IIS/Nginx web server with ModSecurity 2.8.0 or
higher.

Our GitHub repository is the preferred way to download and update CRS:
$> git clone https://github.com/SpiderLabs/owasp-modsecurity-crs.git

For detailed installation instructions, see the INSTALL document.
https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.0/master/INSTALL

The release is accompanied by a series of tutorials that guide you 
through the 
* Setup of ModSecurity
  https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/
* Inclusion of the CRS
  https://www.netnea.com/cms/apache-tutorial-7_including-modsecurity-core-rules/
* Handling of false positives
  
https://www.netnea.com/cms/apache-tutorial-8_handling-false-positives-modsecurity-core-rule-set/

Our desire is to see the Core Rules project as a simple baseline
security feature, effectively fighting OWASP TOP 10 weaknesses with few
side effects. As such we attempted to cut down on false positives as
much as possible in the default install. Of course this must not affect
the detection capabilities of the WAF. We honestly believe that the
default install of CRS3 brings at least the same level of security and
higher paranoia levels let you protect your site even more tightly.

We are very excited about this release. So excited, we want to make it 
into a movie. As a first step, we designed the following poster:
https://modsecurity.org/crs/poster
Please share this link and feel free to print it for your personal use!

Sincerely,

Christian Folini on behalf of Chaim Sanders and Walter Hop
(The Core CRS team, so to say)

-- 
https://modsecurity.org/crs
___
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] OWASP ModSecurity CRS Version 3.0 RC3 Released

[Christian Folini]

Hello,

On Thu, Nov 03, 2016 at 09:01:52AM +0100, Christian Folini wrote:
> So we are still aiming for November 8, 2016, with gold.

Given the US election today, we decided to shift to Thursday, November
10.

So far, we have zero issues reported with RC3, so it looks like the
rules of the final release would be identical with RC3.

Ahoj,

Christian


-- 
History teaches us that men and nations behave wisely once they have
exhausted all other alternatives.
-- Abba Eban
___
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] OWASP ModSecurity CRS Version 3.0 RC3 Released

[Christian Folini]

Dear all,

The 3rd release candidate of the upcoming
OWASP ModSecurity Core Rule Set v3.0.0
has been published.

https://github.com/SpiderLabs/owasp-modsecurity-crs/releases/tag/v3.0.0-rc3

This is essentially RC2 with 
* more false positives weeded out (Walter Hop + github user
   @shimshon70)
* Added rules to detect Shellshock attack (Walter Hop / RedHat)

We somehow missed out on the shellshock probes / exploits until very
late in our release cycle. RedHat kindly allowed us to re-use their
ModSec rules in CRS, so we added them to the RCE rules.

However, being a "new" group of rules we decided it is better to
issue another RCA. This allows us to do the final release very similar
to the last RC and no surprise with the full release.

So we are still aiming for November 8, 2016, with gold.

FYI: Chaim might start to re-arrange the github repository somewhat
a day or two in advance. You have been warned.

As indicated yesterday, I have updated my CRS tutorial to work with
CRS 3.0.0-rc3:
https://www.netnea.com/cms/apache-tutorial-7_including-modsecurity-core-rules/
I will make sure it is ready for CRS 3.0.0 when it comes out.

I'm also writing an extensive tutorial with practical advice on how
to weed out false positives with a Core Rule Set installation. Hope
I get this over until the release.

Cheers,

Christian Folini

-- 
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] Core Rules Tutorial Published

[Christian Folini]

Dear all,

There has been extensive feedback to the draft version of my 
Core Rules 3.0 tutorial (special thanks to Walter Hop).

So here is the finalised version:
https://www.netnea.com/cms/apache-tutorial-7_including-modsecurity-core-rules/

This is written for OWASP ModSecurity Core Rule Set 3.0.0-rc2.
RC3 should be out anytime now. I will update accordingly and when
the full version comes out (scheduled for November 8), then
I'll update again. The differences between rc2 and rc3 and final
are minimal. You can try this out immediately without worrying about
rules upgrades, etc.

Cheers,

Christian

P.S. There is a Rules Exclusion cheatsheet included in the tutorial.
You should check this out.

-- 
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] CRS Status Update (2016-10-29)

[Christian Folini]

Dear all,

This is just a brief status of what is happening with the 
Core Rule Set 3.0 release.

We had good feedback for the RC2 release. No major regressions
just a few more false positives. False negatives are also in
the mix and - somewhat unpleasant - 1-2 attack attempts, that
the CRS2 would block. This is mainly due to Walter Hop from
Dutch hosting provider slik.eu who updated their production
servers to CRS3 and keeps a close eye on the logs now.

So we have decided to update the rules a bit and push an RC3, 
likely on Tuesday. Because, every FP sorted out before the release 
is less pain for our users - and every false negative fixes means
less successful attacks on the servers.

This means the final release, OWASP ModSecurity Core Rule Set 3.0.0,
will be out on Tuesday, November 8. Unless new and big regressions
appear of course.

We are also preparing ideas and means to spread the word about
the release as wide as possible. If you have ideas to support this,
then let us know. Otherwise, it would be just nice if you would
be ready to tell your friends and contacts about this, once
it is out: November 8.

On some other note, I'm receiving feedback for my draft CRS tutorial 
and it seems like it will be ready for publication around 
November 1 as well.

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

Re: [Owasp-modsecurity-core-rule-set] define format of modsec_audit.log

[Christian Folini]

Hi there,

The only options are:
 - controlling the parts you want to log
 - native or new JSON format of audit log

I wish there was more control. ;)

Ahoj,

Christian

On Thu, Oct 27, 2016 at 09:44:56PM +0100, Ilyass Kaouam wrote:
> Hello,
> is there a way to set the log format in the file 'modsec_audit.log?
> - separator
> - Arguement to log?
> 
> thank's
> 
> -- 
> *Ilyass kaouam*
> *Systems administrator*
>  *European Masters in Information Technology*

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