mod-security-users — General discussion about mod_security

Re: [mod-security-users] ModSecurity mod_security-2.9.2, Apache 2.4, oswap crs

[Ervin H. <ai...@gm...>]

Hi Joe,

On Fri, Oct 04, 2019 at 01:52:05PM +0000, Madden, Joe wrote:
> Hi Ervin,
> 
> This information worked perfectly after I put the rules within the modsecurity_crs_10_config.conf
> 
> Thanks

YW,


a.
 

Re: [mod-security-users] ModSecurity mod_security-2.9.2, Apache 2.4, oswap crs

[Madden, J. <Joe...@mo...>]

Hi Ervin,

This information worked perfectly after I put the rules within the modsecurity_crs_10_config.conf

Thanks

Joe.

-----Original Message-----
From: Ervin Hegedüs <ai...@gm...> 
Sent: 03 October 2019 16:33
To: Madden, Joe via mod-security-users <mod...@li...>
Cc: Madden, Joe <Joe...@mo...>
Subject: Re: [mod-security-users] ModSecurity mod_security-2.9.2, Apache 2.4, oswap crs

Hi Madden,

On Thu, Oct 03, 2019 at 02:43:45PM +0000, Madden, Joe via mod-security-users wrote:
> Hi all,
> 
> I've got an issue where a password field with complex characters was triggering the following:
> 
...
 
> I added this into the virtual host configuration (and tried the crs-setup.conf) but it doesn't exclude the password field.
> 
>       SecRule REQUEST_URI "@beginsWith /webclient/login" \
>               "phase:2,nolog,pass,id:10001,ctl:ruleRemoveTargetById=981173;ARGS:password"
> 
> 
> Can anyone tell me why?

I think your custom rule in vhost context exists later than the target rule.

ModSecurity *have to* know the exclusions before the rule activated.

> What is the correct way to exclude this from that specific field (and 
> not all other fields on the URL)

try to write a chained rule to the global exclusions list:

SecRule REMOTE_HOST "www\.yourhost\.com" \
    "phase:2,nolog,pass,id:10001,chain"
    SecRule ... like above without phase, pass and id



a.
 

Re: [mod-security-users] mod_security2 and python app

[Osama E. <oel...@gm...>]

How is your Python web application published?  I'm guessing through
Gunicorn or some other WSGI HTTP server, in which case you would to
configure Apache to act as a reverse proxy to Gunicorn and make requests go
through Apache instead of going directly to Gunicorn

-- 
Osama Elnaggar

On October 4, 2019 at 11:52:48 AM, Eli Agbayani (eag...@gm...)
wrote:

Dear mod...@li...,

I've recently installed mod_security2 in Rhel.
Followed this
<https://tecadmin.net/install-modsecurity-with-apache-on-centos-rhel/>
instructions and it worked great.
Most of the websites in the machine instantly detects and reinforces the
security measures of mod_security2.
Unfortunately there is one application, CKAN <https://ckan.org/> which is a
python application that is not affected by mod_security.
How can I make this python application detect mod_security so that website
can also be protected from attacks.
I can send my CKAN apache conf file if needed.

Thanks,
Eli Agbayani
_______________________________________________
mod-security-users mailing list
mod...@li...
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/

[mod-security-users] mod_security2 and python app

[Eli A. <eag...@gm...>]

Dear mod...@li...,

I've recently installed mod_security2 in Rhel.
Followed this
<https://tecadmin.net/install-modsecurity-with-apache-on-centos-rhel/>
instructions and it worked great.
Most of the websites in the machine instantly detects and reinforces the
security measures of mod_security2.
Unfortunately there is one application, CKAN <https://ckan.org/> which is a
python application that is not affected by mod_security.
How can I make this python application detect mod_security so that website
can also be protected from attacks.
I can send my CKAN apache conf file if needed.

Thanks,
Eli Agbayani

Re: [mod-security-users] ModSecurity mod_security-2.9.2, Apache 2.4, oswap crs

[Madden, J. <Joe...@mo...>]

Hi Ervin,

Thanks - I'll give this a try in the morning!

Thank you.

-----Original Message-----
From: Ervin Hegedüs <ai...@gm...> 
Sent: 03 October 2019 16:33
To: Madden, Joe via mod-security-users <mod...@li...>
Cc: Madden, Joe <Joe...@mo...>
Subject: Re: [mod-security-users] ModSecurity mod_security-2.9.2, Apache 2.4, oswap crs

Hi Madden,

On Thu, Oct 03, 2019 at 02:43:45PM +0000, Madden, Joe via mod-security-users wrote:
> Hi all,
> 
> I've got an issue where a password field with complex characters was triggering the following:
> 
...
 
> I added this into the virtual host configuration (and tried the crs-setup.conf) but it doesn't exclude the password field.
> 
>       SecRule REQUEST_URI "@beginsWith /webclient/login" \
>               "phase:2,nolog,pass,id:10001,ctl:ruleRemoveTargetById=981173;ARGS:password"
> 
> 
> Can anyone tell me why?

I think your custom rule in vhost context exists later than the target rule.

ModSecurity *have to* know the exclusions before the rule activated.

> What is the correct way to exclude this from that specific field (and 
> not all other fields on the URL)

try to write a chained rule to the global exclusions list:

SecRule REMOTE_HOST "www\.yourhost\.com" \
    "phase:2,nolog,pass,id:10001,chain"
    SecRule ... like above without phase, pass and id



a.
 

Re: [mod-security-users] ModSecurity mod_security-2.9.2, Apache 2.4, oswap crs

[Ervin H. <ai...@gm...>]

Hi Madden,

On Thu, Oct 03, 2019 at 02:43:45PM +0000, Madden, Joe via mod-security-users wrote:
> Hi all,
> 
> I've got an issue where a password field with complex characters was triggering the following:
> 
...
 
> I added this into the virtual host configuration (and tried the crs-setup.conf) but it doesn't exclude the password field.
> 
>       SecRule REQUEST_URI "@beginsWith /webclient/login" \
>               "phase:2,nolog,pass,id:10001,ctl:ruleRemoveTargetById=981173;ARGS:password"
> 
> 
> Can anyone tell me why?

I think your custom rule in vhost context exists later than the
target rule.

ModSecurity *have to* know the exclusions before the rule
activated.

> What is the correct way to exclude this from that specific field (and not all other fields on the URL)

try to write a chained rule to the global exclusions list:

SecRule REMOTE_HOST "www\.yourhost\.com" \
    "phase:2,nolog,pass,id:10001,chain"
    SecRule ... like above without phase, pass and id



a.
 

[mod-security-users] ModSecurity mod_security-2.9.2, Apache 2.4, oswap crs

[Madden, J. <Joe...@mo...>]

Hi all,

I've got an issue where a password field with complex characters was triggering the following:


Message: Access denied with code 403 (phase 2). Pattern match "([\\~\\!\\@\\#\\$\\%\\^\\&\\*\\(\\)\\-\\+\\=\\{\\}\\[\\]\\|\\:\\;\"\\'\\\xc2\xb4\\\xe2\x80\x99\\\xe2\x80\x98\\`\\<\\>].*?){4,}" at ARGS:password. [file "/etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf"] [line "159"] [id "981173"] [rev "2"] [msg "Restricted SQL Character Anomaly Detection Alert - Total # of special characters exceeded"] [data "Matched Data: - found within ARGS:password: ##########################"] [ver "OWASP_CRS/2.2.9"] [maturity "9"] [accuracy "8"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"]

I added this into the virtual host configuration (and tried the crs-setup.conf) but it doesn't exclude the password field.

      SecRule REQUEST_URI "@beginsWith /webclient/login" \
              "phase:2,nolog,pass,id:10001,ctl:ruleRemoveTargetById=981173;ARGS:password"


Can anyone tell me why?

What is the correct way to exclude this from that specific field (and not all other fields on the URL)

Thanks

Joe.

Re: [mod-security-users] Syntax error for rule by trustwave

[Ervin H. <ai...@gm...>]

Hi Homesh,


On Tue, Oct 01, 2019 at 07:29:53PM +0530, homesh joshi wrote:
> 
> here is is the final thing that worked for me. Now I am testing the rule
> for various conditions.

good to see,

> #Step1
> ## This rule will identify the outbound Set-Cookie SessionID data and capture it in a setsid#
> SecRule RESPONSE_HEADERS:/Set-Cookie2?/ > "(?i:(j?sessionid|(php)?sessid|(asp|jserv|jw)?session[-_]?(id)?|cf(id|token)|sid).*?=([^\s].*?)\;\s?)" "chain,phase:3,id:'881062',t:none,pass,nolog,capture,setsid:%{TX.6},setvar:session.sessionid=%{TX.6},setvar:tx.ip=%{remote_addr},setvar:tx.ua=%{request_headers.user-agent}"

just my 2 cents: you would better to use the actions that you
quote its arguments, eg:

setvar:'tx.ua=%{request_headers.user-agent}'

It's not mandatory, but more clear.



a.

Re: [mod-security-users] Syntax error for rule by trustwave

[homesh j. <ho...@gm...>]

Hi Ervin,

Thanks a lot. Now I am clear on the use of  \ and chain.

here is is the final thing that worked for me. Now I am testing the rule
for various conditions.
#Step1
## This rule will identify the outbound Set-Cookie SessionID data and
capture it in a setsid#
SecRule RESPONSE_HEADERS:/Set-Cookie2?/
"(?i:(j?sessionid|(php)?sessid|(asp|jserv|jw)?session[-_]?(id)?|cf(id|token)|sid).*?=([^\s].*?)\;\s?)"
"chain,phase:3,id:'881062',t:none,pass,nolog,capture,setsid:%{TX.6},setvar:session.sessionid=%{TX.6},setvar:tx.ip=%{remote_addr},setvar:
tx.ua=%{request_headers.user-agent}"
SecRule UNIQUE_ID "(.*)"
"t:none,t:sha1,t:hexEncode,capture,setvar:session.csrf_token=%{TX.1}"

#Step 2
SecContentInjection On
SecStreamOutBodyInspection On
SecResponseBodyAccess On
SecRule RESPONSE_STATUS "200" "chain,id:'881802',t:none,pass"
SecRule RESPONSE_HEADERS:Content-Type "@beginsWith text/html"
"chain,t:none,nolog"
SecRule &SESSION:KEY "@eq 1" "chain"
SecRule STREAM_OUTPUT_BODY "@rsub s/<\/body>/<script
type=\"text\/javascript\"
src=\"https\:\/\/www.abc123.com\/client.min.js\"><\/script>|0A|<\/body>/"
"capture,setvar:session.fingerprint_code_sent=1"
#Step 3
## -=[ Save the initial Browser Fingerprint Hash in the Session Collection
]=-#
SecRule &SESSION:BROWSER_HASH "@eq 0"
"chain,id:'881803',phase:1,t:none,nolog,pass"
SecRule REQUEST_COOKIES:BROWSER_HASH ".*"
"setvar:session.browser_hash=%{matched_var}"

#Step 4
## -=[ If Browser Fingerprint JS was sent previously, then enforce the #
  existence of the browser_hash Cookie field. ]=-#
SecRule SESSION:FINGERPRINT_CODE_SENT "@eq 1"
"chain,id:'881804',phase:1,t:none,block,msg:'Warning: Browser Fingering
Cookie Missing.'"
SecRule &REQUEST_COOKIES:BROWSER_HASH "@eq 0"
SecRule SESSION:FINGERPRINT_CODE_SENT "@eq 1"
"chain,id:'881805',phase:1,t:none,block,msg:'Warning: Browser Fingering
Cookie Mismatch.',logdata:'Expected Browser Fingerprint:
%{session.browser_hash}. Browser Fingerprint Received:
%{request_cookies.browser_hash}'"
SecRule &REQUEST_COOKIES:BROWSER_HASH "@eq 1" "chain"
SecRule REQUEST_COOKIES:BROWSER_HASH "!@streq %{session.browser_hash}"

Thanks,
Homesh

On Tue, Oct 1, 2019 at 2:24 PM Ervin Hegedüs <ai...@gm...> wrote:

> Hi Homesh,
>
> On Tue, Oct 01, 2019 at 01:16:31PM +0530, homesh joshi wrote:
>
> > AH00526: Syntax error on line 13 of /etc/modsecurity/1234.conf:
> > SecRule takes two or three arguments, rule target, operator and optional
> > action list
> > Action 'configtest' failed.
> >
> > Line # 13 is
> > SecRule RESPONSE_STATUS "200" "chain,id:'881802',t:none" \
>
> yes, this is invalid. The "\" (backslash) char used to indicate to
> parser that the next line is part of the current. So, if you want
> to continue the list of actions, then it need, elsewhere you
> _can_not_ to place that.
>
> As I see your config, the next token is a new "SecRule" option,
> therefore this isn't the continuation of the previous line.
>
> May be you might be confused with the 'chain' action, which means
> "the next SecRule entity is a continuation of this", but that's
> totally different, than the backslash at the EOL.
>
> so, your rules:
>
> > SecRule RESPONSE_STATUS "200" "chain,id:'881802',t:none" \
> > SecRule RESPONSE_HEADERS:Content-Type "@beginsWith text/html"
> "chain,id:'881802',t:none,nolog,pass" \
> > SecRule &SESSION:KEY "@eq 1" "chain"
> > SecRule STREAM_OUTPUT_BODY "@rsub s/<\/body>/<script
> type=\"text\/javascript\" src=\"https\:\/\/www.abcd1234.COM\/client.min.js\"><\/script>|0A|<\/body>/"
> "capture,setvar:session.fingerprint_code_sent=1"
>
> in the right form:
>
> > SecRule RESPONSE_STATUS "200" "chain,id:'881802',t:none"
> > SecRule RESPONSE_HEADERS:Content-Type "@beginsWith text/html"
> "chain,t:none,nolog,pass"
> > SecRule &SESSION:KEY "@eq 1" "chain"
> > SecRule STREAM_OUTPUT_BODY "@rsub s/<\/body>/<script
> type=\"text\/javascript\" src=\"https\:\/\/www.abcd1234.COM\/client.min.js\"><\/script>|0A|<\/body>/"
> "capture,setvar:session.fingerprint_code_sent=1"
>
> also note, that you don't need to put the "id" with same value to
> the chained rule - I removed it.
>
>
>
> Hope this helps,
>
>
>
> a.
>
>
>
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> 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/
>

Re: [mod-security-users] Syntax error for rule by trustwave

[Ervin H. <ai...@gm...>]

Hi Homesh,

On Tue, Oct 01, 2019 at 01:16:31PM +0530, homesh joshi wrote:

> AH00526: Syntax error on line 13 of /etc/modsecurity/1234.conf:
> SecRule takes two or three arguments, rule target, operator and optional
> action list
> Action 'configtest' failed.
> 
> Line # 13 is
> SecRule RESPONSE_STATUS "200" "chain,id:'881802',t:none" \

yes, this is invalid. The "\" (backslash) char used to indicate to
parser that the next line is part of the current. So, if you want
to continue the list of actions, then it need, elsewhere you
_can_not_ to place that.

As I see your config, the next token is a new "SecRule" option,
therefore this isn't the continuation of the previous line.

May be you might be confused with the 'chain' action, which means
"the next SecRule entity is a continuation of this", but that's
totally different, than the backslash at the EOL.

so, your rules:

> SecRule RESPONSE_STATUS "200" "chain,id:'881802',t:none" \
> SecRule RESPONSE_HEADERS:Content-Type "@beginsWith text/html" "chain,id:'881802',t:none,nolog,pass" \
> SecRule &SESSION:KEY "@eq 1" "chain"
> SecRule STREAM_OUTPUT_BODY "@rsub s/<\/body>/<script type=\"text\/javascript\" src=\"https\:\/\/www.abcd1234.COM\/client.min.js\"><\/script>|0A|<\/body>/" "capture,setvar:session.fingerprint_code_sent=1"

in the right form:

> SecRule RESPONSE_STATUS "200" "chain,id:'881802',t:none"
> SecRule RESPONSE_HEADERS:Content-Type "@beginsWith text/html" "chain,t:none,nolog,pass"
> SecRule &SESSION:KEY "@eq 1" "chain"
> SecRule STREAM_OUTPUT_BODY "@rsub s/<\/body>/<script type=\"text\/javascript\" src=\"https\:\/\/www.abcd1234.COM\/client.min.js\"><\/script>|0A|<\/body>/" "capture,setvar:session.fingerprint_code_sent=1"

also note, that you don't need to put the "id" with same value to
the chained rule - I removed it.



Hope this helps,



a.

[mod-security-users] Syntax error for rule by trustwave

[homesh j. <ho...@gm...>]

Hi,

I am trying to implement rules mentioned in the trustwave blog here
<https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/modsecurity-advanced-topic-of-the-week-detecting-browser-fingerprint-changes-during-sessions/>.


But I get the below error when I do service apache2 reload.

AH00526: Syntax error on line 13 of /etc/modsecurity/1234.conf:
SecRule takes two or three arguments, rule target, operator and optional
action list
Action 'configtest' failed.

Line # 13 is
SecRule RESPONSE_STATUS "200" "chain,id:'881802',t:none" \

I was also getting the same error for below line which I commented out as I
feel it is not that that useful.

##   SecRule UNIQUE_ID "(.*)"
"t:none,t:sha1,t:hexEncode,capture,setvar:session.csrf_token=%{TX.1}"

Below is the entire file content

#Step1
## This rule will identify the outbound Set-Cookie SessionID data and
capture it in a setsid#
SecRule RESPONSE_HEADERS:/Set-Cookie2?/
"(?i:(j?sessionid|(php)?sessid|(asp|jserv|jw)?session[-_]?(id)?|cf(id|token)|sid).*?=([^\s].*?)\;\s?)"
"phase:3,id:'881062',t:none,pass,nolog,capture,setsid:%{TX.6},setvar:session.sessionid=%{TX.6},setvar:tx.ip=%{remote_addr},setvar:
tx.ua=%{request_headers.user-agent}"
##      SecRule UNIQUE_ID "(.*)"
"t:none,t:sha1,t:hexEncode,capture,setvar:session.csrf_token=%{TX.1}"

#Step 2
SecContentInjection On
SecStreamOutBodyInspection On
SecResponseBodyAccess On
SecRule RESPONSE_STATUS "200" "chain,id:'881802',t:none" \
SecRule RESPONSE_HEADERS:Content-Type "@beginsWith text/html"
"chain,id:'881802',t:none,nolog,pass" \
SecRule &SESSION:KEY "@eq 1" "chain" \
SecRule STREAM_OUTPUT_BODY "@rsub s/<\/body>/<script
type=\"text\/javascript\"
src=\"https\:\/\/www.abcd1234.COM\/client.min.js\"><\/script>|0A|<\/body>/"
"capture,setvar:session.fingerprint_code_sent=1"
#Step 3
## -=[ Save the initial Browser Fingerprint Hash in the Session Collection
]=-#
SecRule &SESSION:BROWSER_HASH "@eq 0"
"chain,id:'881803',phase:1,t:none,nolog,pass" SecRule
REQUEST_COOKIES:BROWSER_HASH ".*"
"setvar:session.browser_hash=%{matched_var}"

#Step 4
## -=[ If Browser Fingerprint JS was sent previously, then enforce the #
  existence of the browser_hash Cookie field. ]=-#
#SecRule SESSION:FINGERPRINT_CODE_SENT "@eq 1"
"chain,id:'881804',phase:1,t:none,block,msg:'Warning: Browser Fingering
Cookie Missing.'" SecRule &REQUEST_COOKIES:BROWSER_HASH "@eq 0"

#SecRule SESSION:FINGERPRINT_CODE_SENT "@eq 1"
"chain,id:'881805',phase:1,t:none,block,msg:'Warning: Browser Fingering
Cookie Mismatch.',logdata:'Expected Browser Fingerprint:
%{session.browser_hash}. Browser Fingerprint Received:
%{request_cookies.browser_hash}'" \
#SecRule &REQUEST_COOKIES:BROWSER_HASH "@eq 1" "chain" SecRule
REQUEST_COOKIES:BROWSER_HASH "!@streq %{session.browser_hash}"

Please help me in understanding why I am getting the syntax error.
My environment is
Ubuntu 18.04 64 bit Apache 2.4.29
Modsecurity version 2.9.2

Thanks,
Homesh

[mod-security-users] Announcement: msc_pyparser

[Ervin H. <ai...@gm...>]

Hi all,

(sorry for the cross posting)

let me announce the msc_pyparser tool, a ModSecurity ruleset parser.
msc_pyparser can made a full lexical and syntactic analisys on the rules
(currently it tested only on CRS and some custom rules). Note, that
msc_pyparser supports only four MSC keyword (and the comments) - see the
docs.
Beyond these abilities, msc_pyparser builds an AST (abstract syntax tree),
and made an own structure in memory - especially a list of dictionaries.
Every dict item stores several datas about the recognized token, including
number of line.

You can dump this structure (eg. JSON, YAML - or SQL), or can make any
contextual depend modification. After this, you can save back the modified
version to the original ModSecurity format.

There are some usefull examples in source.

I think this tool can helps you to maintain your rulesets, eg. merge with
custom modifications, formatting, or - as above - make any context
dependent changes. Please review the examples directory.

If you have any question, issue, bugreport or other feedback, please
contact me at the given e-mail address in README, or open an issue on
Github (do not disturb this list).

The tool available here:
https://github.com/digitalwave/msc_pyparser

a.

Re: [mod-security-users] ModSecurity cost in Nginx

[Christian F. <chr...@ne...>]

Hello Xiang,

Little amounts of traffic won't get nginx to sweat, but the higher you go, the
larger percentage of CPU will be spent on ModSecurity. Nginx is a very lean
reverse proxy, but with ModSecurity on top, it gains significant overhead.

The best is probably to run a real stress test with locust or some other tool
and see how the server behaves. There are a lot of factors that play into
this.

I have come to see that ModSecurity 2.9 on Apache 2.4 is substantially faster
than ModSecurity 3 on Nginx.

Good luck!

Christian



On Tue, Sep 24, 2019 at 10:34:03PM -0400, Wang Xiang wrote:
> Hi all,
> 
> I am testing ModSecurity with Nginx.
> 
> I downloaded open source rule-set owasp-modsecurity-crs at Github and fed a captured real http traffic into Nginx to see the overhead of ModSecurity within Nginx. But a total of less than 1% CPU cycles are spent on ModSecurity. Do you have any insights of the percentage of time spent on ModSecurity within Nginx based on your experience?
> 
> Thanks,
> Xiang
> 
> 
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> 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/

[mod-security-users] ModSecurity cost in Nginx

[Wang X. <xia...@in...>]

Hi all,

I am testing ModSecurity with Nginx.

I downloaded open source rule-set owasp-modsecurity-crs at Github and fed a captured real http traffic into Nginx to see the overhead of ModSecurity within Nginx. But a total of less than 1% CPU cycles are spent on ModSecurity. Do you have any insights of the percentage of time spent on ModSecurity within Nginx based on your experience?

Thanks,
Xiang

[mod-security-users] Announcement: OWASP ModSecurity Core Rule Set Version 3.2.0

[Walter H. <mo...@sp...>]

Dear all,

The OWASP ModSecurity Core Rule Set team is proud to announce the general availability of the OWASP ModSecurity Core Rule Set Version 3.2.0.

The new release is available for download at https://coreruleset.org/installation/ <https://coreruleset.org/installation/>

This release represents a very big step forward in terms of both capabilities and protections including:

	• Improved compatibility with ModSecurity 3.x 
	• Improved CRS docker container that is fully configureable at creation
	• Expanded Java RCE blacklist 
	• Expanded unix shell RCE blacklist 
	• Improved PHP RCE detection 
	• New javascript/Node.js RCE detection
	• Expanded LFI blacklists 
	• Added XenForo rule exclusion profile 
	• Fixes for many false positives and bypasses
	• Detection of more security scanners
	• Regexp performance improvements preventing ReDoS in most cases

Please see the CHANGES document with around 150 entries for a detailed list of new features and improvements:
https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.2.0/CHANGES <https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.2.0/CHANGES>

Our desire is to see the Core Rule Set project used as a baseline security feature, effectively protecting from OWASP TOP 10 risks with few side effects. As such we attempt to cut down on false positives as much as possible in the default install. 

Please use the CRS GitHub (https://github.com/SpiderLabs/owasp-modsecurity-crs), our slack channel (#coreruleset on owasp.slack.com), or the Core Rule Set mailing list to tell us about your experiences, including false positives or other issues with this release candidate.

Sincerely, 
Walter Hop, release manager, on behalf of the Core Rule Set development team

[mod-security-users] OWASP ModSecurity Core Rule Set v3.2.0-RC3

[Walter H. <mo...@sp...>]

Dear all,

The OWASP ModSecurity Core Rule Set team is proud to announce the general availability of release candidate 3 for the upcoming CRS v3.2.0. The new release is available at:

* https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.2.0-rc3.zip
* https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.2.0-rc3.tar.gz

Changes in RC3 compared to RC2 are:

* Add .swp to default restricted_extensions (Andrea Menin)
* Avoid php leak false positive with WOFF files (Manuel Spartan)
* Java: change tag from COMMAND_INJECTION to JAVA_INJECTION (Manuel Spartan)
* 941380: fix anomaly score variable (Franziska Bühler)
* 942510, 942511: fix anomaly score variable (Walter Hop)
* As per the ref manual, it is compressWhitespace (Federico G. Schwindt)
* Tests: fix failing regression tests (Ervin Hegedus)
* Tests: fix YAML 1.2 compliance with "true" (Federico G. Schwindt)
* INSTALL: advise to use release zips, remove upgrade.py, update Nginx (Walter Hop)

This release represents a very big step forward in terms of both capabilities and protections including:

* Improved compatibility with ModSecurity 3.x
* Improved CRS docker container that is fully configureable at creation
* Expanded Java RCE blacklist
* Expanded unix shell RCE blacklist
* Improved PHP RCE detection
* New javascript/Node.js RCE detection
* Expanded LFI blacklists
* Added XenForo rule exclusion profile
* Fixes for many false positives and bypasses
* Detection of more security scanners
* Regexp performance improvements, preventing ReDoS in most cases

Please see the CHANGES document with around 160 entries for a detailed list of new features and improvements.
https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.2.0-rc3/CHANGES

Our desire is to see the Core Rule Set project used as a baseline security feature, effectively protecting from OWASP TOP 10 risks with few side effects. As such we attempt to cut down on false positives as much as possible in the default install.

The release candidates offer an opportunity for individuals to provide feedback and to report any issue they face with this release. We will then try and fix them for the upcoming full release.

Please use the CRS GitHub (https://github.com/SpiderLabs/owasp-modsecurity-crs), our Slack channel (#coreruleset on owasp.slack.com), or the Core Rule Set mailing list to tell us about your experiences, including false positives or other issues with this release candidate.

Our current timeline is to make the final release on September 24. We look forward to hearing your feedback!

Sincerely,

Walter Hop
Release manager, on behalf of the Core Rule Set development team

Re: [mod-security-users] Announce of ftwrunner

[Ervin H. <ai...@gm...>]

Hi Manuel,


On Thu, Sep 19, 2019 at 10:17:09AM -0400, Manuel Spartan wrote:
> Thanks Ervin, this is good stuff:)

thanks - hope that will helps you a lot :)


a.
 

Re: [mod-security-users] Announce of ftwrunner

[Manuel S. <spa...@gm...>]

Thanks Ervin, this is good stuff:)

Sent from my iPhone

> On Sep 19, 2019, at 2:46 AM, Ervin Hegedüs <ai...@gm...> wrote:
> 
> Hi all,
> 
> (sorry for the cross posting)
> 
> let me announce the ftwrunner tool, a libmodsecurity3 testing helper. Ftwrunner can use the existing CRS tests (which made for ftw), but of course you can write your own rules. The tool uses libmodsecurity3 API, instead of sending HTTP requests to the configured webserver. You can check your whole config (base modsecurity.conf, your rulesets) as ftw.
> 
> I think this tool also can helps you to check the library - similar to existing regression test framework.
> 
> If you have any question, issue, bugreport or other feedback, please contact me at the given e-mail address in README, or open an issue on Github (do not disturb this list).
> 
> The tool available here:
> https://github.com/digitalwave/ftwrunner
> 
> a.
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> 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/

Re: [mod-security-users] Announce of ftwrunner

[Christian F. <chr...@ne...>]

Congratulations, Ervin.

This is a very welcome addition to our toolbox. Not the least for CRS
development.

Ervin is also presenting the tool at the OWASP ModSecurity Core Rule Set
community summit next Wednesday in Amsterdam. If anybody has not hooked up
so far and wants to join, please get in touch.

Best,

Christian

On Thu, Sep 19, 2019 at 08:45:00AM +0200, Ervin Hegedüs wrote:
> Hi all,
> 
> (sorry for the cross posting)
> 
> let me announce the ftwrunner tool, a libmodsecurity3 testing helper.
> Ftwrunner can use the existing CRS tests (which made for ftw), but of
> course you can write your own rules. The tool uses libmodsecurity3 API,
> instead of sending HTTP requests to the configured webserver. You can check
> your whole config (base modsecurity.conf, your rulesets) as ftw.
> 
> I think this tool also can helps you to check the library - similar to
> existing regression test framework.
> 
> If you have any question, issue, bugreport or other feedback, please
> contact me at the given e-mail address in README, or open an issue on
> Github (do not disturb this list).
> 
> The tool available here:
> https://github.com/digitalwave/ftwrunner
> 
> 
> a.


> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php

[mod-security-users] Announce of ftwrunner

[Ervin H. <ai...@gm...>]

Hi all,

(sorry for the cross posting)

let me announce the ftwrunner tool, a libmodsecurity3 testing helper.
Ftwrunner can use the existing CRS tests (which made for ftw), but of
course you can write your own rules. The tool uses libmodsecurity3 API,
instead of sending HTTP requests to the configured webserver. You can check
your whole config (base modsecurity.conf, your rulesets) as ftw.

I think this tool also can helps you to check the library - similar to
existing regression test framework.

If you have any question, issue, bugreport or other feedback, please
contact me at the given e-mail address in README, or open an issue on
Github (do not disturb this list).

The tool available here:
https://github.com/digitalwave/ftwrunner

a.

[mod-security-users] Mod_security v3 and update SecGeoLookupDB file

[Marcello L. <ce...@gm...>]

Hi All,
actually we're installing Nginx 1.16 with the mod_security 3.x and we would
block some IP using the SecGeoLookupDB file. All this environment is
dockerized and we would update silently the file without restarting the
nginx instance. Is it possible to apply this action?

Thanks,
Marcello

[mod-security-users] OWASP ModSecurity Core Rule Set v3.2.0-RC2

[Walter H. <mo...@sp...>]

Dear all,

The OWASP ModSecurity Core Rule Set team is proud to announce the general availability of release candidate 2 for the upcoming CRS v3.2.0. The new release is available at:

* https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.2.0-rc2.zip <https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.2.0-rc2.zip>
* https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.2.0-rc2.tar.gz <https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.2.0-rc2.tar.gz>

This release represents a very big step forward in terms of both capabilities and protections including:

* Improved compatibility with ModSecurity 3.x
* Improved CRS docker container that is fully configureable at creation
* Expanded Java RCE blacklist
* Expanded unix shell RCE blacklist
* Improved PHP RCE detection
* New javascript/Node.js RCE detection
* Expanded LFI blacklists
* Added XenForo rule exclusion profile
* Fixes for many false positives and bypasses
* Detection of more security scanners
* Regexp performance improvements, preventing ReDoS in most cases

Please see the CHANGES document with around 150 entries for a detailed list of new features and improvements.
https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.2.0-rc2/CHANGES <https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.2.0-rc2/CHANGES>

Note how this RC2 is the first public release candidate for 3.2.0. RC1 was not formally released.

Our desire is to see the Core Rule Set project used as a baseline security feature, effectively protecting from OWASP TOP 10 risks with few side effects. As such we attempt to cut down on false positives as much as possible in the default install. This RC2 therefore offers an opportunity for individuals to provide feedback and to report any issue they face with this release. We will then try and fix them for the upcoming full release.

Please use the CRS GitHub (https://github.com/SpiderLabs/owasp-modsecurity-crs <https://github.com/SpiderLabs/owasp-modsecurity-crs>), our Slack channel (#coreruleset on owasp.slack.com <http://owasp.slack.com/>), or the Core Rule Set mailing list to tell us about your experiences, including false positives or other issues with this release candidate.

Our current timeline is to seek public feedback on RC2 for the next two weeks, followed by an RC3 (if needed) and subsequently a release on September 24. We look forward to hearing your feedback!

Sincerely,

Walter Hop
Release manager, on behalf of the Core Rule Set development team

Re: [mod-security-users] How to block ip addresses which always hack my website

[Christian V. <cv...@it...>]

If you want to block just that ip l, you can use iptables for that.

If you want to block any ip that modsecurity detect like an attack, I
recommend you to install fail2ban and configure it with modsecurity

Cheers.

El vie., 30 de ago. de 2019 08:04, wai phyo <wai...@gm...>
escribió:

> I would like to block IP Address that visited 404 pages more than 10 times
> in a minute.
> Please tell me how can I write rule???
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> 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/
>

Re: [mod-security-users] How to block ip addresses which always hack my website

[Ervin H. <ai...@gm...>]

Hi,

On Fri, Aug 30, 2019 at 12:32:14PM +0630, wai phyo wrote:
> I would like to block IP Address that visited 404 pages more than 10 times
> in a minute.
> Please tell me how can I write rule???

I'm not sure that I'ld do it with ModSecurity - if you really want to
build a mechanism to listen the 404 answer code, then it would be
better to catch it before the higher layer.

I mean, you can use an IDS, for example fail2ban[1], which checks
the http log, and if an IP triggers x+1 HTTP 404 in k+1 minute,
then it will be blocked until z+1 minute - on L3.



a.

[1] https://github.com/fail2ban/fail2ban

Re: [mod-security-users] How to block ip addresses which always hack my website

[Reindl H. <h.r...@th...>]

Am 30.08.19 um 08:02 schrieb wai phyo:
> I would like to block IP Address that visited 404 pages more than 10
> times in a minute.
> Please tell me how can I write rule???

when your site get hacked repeatly seek the problem and fix it

ten 404 requests per minute is for sure not a sign of hacking and such
rule won't achieve anything the f**k off legit clients behind a
carrier-grade NAT which are growing