mod-security-developers — Development discussion about mod_security

Re: [Mod-security-developers] Make test failed

[Pavel M. <pa...@ne...>]

> Hello Pavel,
> 
> Are you running make CFLAGS=-DMSC_TEST test right ?

Yes, I am.

> Can you send me your backtrace ?

Sure. What exactly do you need?
 
> Thanks
> 
> On Wed, May 22, 2013 at 8:05 AM, Rainer Jung <rai...@ki...>wrote:
> > On 22.05.2013 10:22, Pavel Mateja wrote:
> > > Hi guys,
> > > I've upgraded our debian servers from wheezy to squeeze and I can't
> > > pass
> > 
> > "make
> > 
> > > test" of modsecurity any more:
> > > 
> > > Loaded 8 tests from ./op/rx.t
> > > 
> > >      1) op "rx": passed (Pattern match "" at UNIT_TEST.)
> > >      2) op "rx": passed
> > >      3) op "rx": passed (Pattern match "" at UNIT_TEST.)
> > >      4) op "rx": passed (Pattern match "abc" at UNIT_TEST.)
> > >      5) op "rx": passed (Pattern match "def" at UNIT_TEST.)
> > >      6) op "rx": passed (Pattern match "ghi" at UNIT_TEST.)
> > >      7) op "rx": passed
> > > 
> > > ERROR: Failed to create rule for op "rx": Error creating rule: Error
> > 
> > compiling
> > 
> > > pattern (offset 2): unrecognized character after (? or (?-
> > > Test exited with signal 11.
> > > Executed: ./msc_test "-t" "op" "-n" "rx" "-p"
> > > "(?^i:^([^=])\s*=\s*((?:abc)+(?:def|ghi){2})$)" "-D" "0" "-r" "1"
> > > 
> > >      8) op "rx": failed
> > > 
> > > Passed:  7; Failed:  1
> > > 
> > > I've tried version 2.7.2 which passed test on old debian and latest
> > 
> > 2.7.3.
> > 
> > > Both failed on the same place.
> > > 
> > > Compilation parameters were:
> > > ./configure --prefix=/apache/modules/ --with-apxs=/apache/bin/apxs
> > 
> > --with-
> > 
> > > apr=/apache/bin/apr-1-config --with-apu=/apache/bin/apu-1-config
> > 
> > --enable-pcre-
> > 
> > > match-limit=50000 --enable-pcre-match-limit-recursion=10000
> > 
> > --disable-mlogc
> > 
> > Since it exits with signal 11 it might be related to this bug:
> > 
> > https://github.com/SpiderLabs/ModSecurity/issues/23
> > 
> > It was fixed in this commit
> > 
> > 
> > https://github.com/SpiderLabs/ModSecurity/commit/3f6c14de5993b8b2c66e6317
> > af1680f2a007aead
> > 
> > and should be part of 2.7.2 and later. Maybe the fix didn't catch all
> > similar situations?
> > 
> > Regards,
> > 
> > Rainer
> > 
> > 
> > -------------------------------------------------------------------------
> > ----- Try New Relic Now & We'll Send You this Cool Shirt
> > New Relic is the only SaaS-based application performance monitoring
> > service that delivers powerful full stack analytics. Optimize and
> > monitor your browser, app, & servers with just a few lines of code. Try
> > New Relic and get this awesome Nerd Life shirt!
> > http://p.sf.net/sfu/newrelic_d2d_may
> > _______________________________________________
> > 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
-- 
Pavel Mateja

Re: [Mod-security-developers] Make test failed

[Breno S. <bre...@gm...>]

Hello Pavel,

Are you running make CFLAGS=-DMSC_TEST test right ?
Can you send me your backtrace ?

Thanks


On Wed, May 22, 2013 at 8:05 AM, Rainer Jung <rai...@ki...>wrote:

> On 22.05.2013 10:22, Pavel Mateja wrote:
> > Hi guys,
> > I've upgraded our debian servers from wheezy to squeeze and I can't pass
> "make
> > test" of modsecurity any more:
> >
> > Loaded 8 tests from ./op/rx.t
> >      1) op "rx": passed (Pattern match "" at UNIT_TEST.)
> >      2) op "rx": passed
> >      3) op "rx": passed (Pattern match "" at UNIT_TEST.)
> >      4) op "rx": passed (Pattern match "abc" at UNIT_TEST.)
> >      5) op "rx": passed (Pattern match "def" at UNIT_TEST.)
> >      6) op "rx": passed (Pattern match "ghi" at UNIT_TEST.)
> >      7) op "rx": passed
> > ERROR: Failed to create rule for op "rx": Error creating rule: Error
> compiling
> > pattern (offset 2): unrecognized character after (? or (?-
> > Test exited with signal 11.
> > Executed: ./msc_test "-t" "op" "-n" "rx" "-p"
> > "(?^i:^([^=])\s*=\s*((?:abc)+(?:def|ghi){2})$)" "-D" "0" "-r" "1"
> >      8) op "rx": failed
> > Passed:  7; Failed:  1
> >
> > I've tried version 2.7.2 which passed test on old debian and latest
> 2.7.3.
> > Both failed on the same place.
> >
> > Compilation parameters were:
> > ./configure --prefix=/apache/modules/ --with-apxs=/apache/bin/apxs
> --with-
> > apr=/apache/bin/apr-1-config --with-apu=/apache/bin/apu-1-config
> --enable-pcre-
> > match-limit=50000 --enable-pcre-match-limit-recursion=10000
> --disable-mlogc
>
> Since it exits with signal 11 it might be related to this bug:
>
> https://github.com/SpiderLabs/ModSecurity/issues/23
>
> It was fixed in this commit
>
>
> https://github.com/SpiderLabs/ModSecurity/commit/3f6c14de5993b8b2c66e6317af1680f2a007aead
>
> and should be part of 2.7.2 and later. Maybe the fix didn't catch all
> similar situations?
>
> Regards,
>
> Rainer
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> 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
>

Re: [Mod-security-developers] Make test failed

[Rainer J. <rai...@ki...>]

On 22.05.2013 10:22, Pavel Mateja wrote:
> Hi guys,
> I've upgraded our debian servers from wheezy to squeeze and I can't pass "make 
> test" of modsecurity any more:
> 
> Loaded 8 tests from ./op/rx.t
>      1) op "rx": passed (Pattern match "" at UNIT_TEST.)
>      2) op "rx": passed
>      3) op "rx": passed (Pattern match "" at UNIT_TEST.)
>      4) op "rx": passed (Pattern match "abc" at UNIT_TEST.)
>      5) op "rx": passed (Pattern match "def" at UNIT_TEST.)
>      6) op "rx": passed (Pattern match "ghi" at UNIT_TEST.)
>      7) op "rx": passed
> ERROR: Failed to create rule for op "rx": Error creating rule: Error compiling 
> pattern (offset 2): unrecognized character after (? or (?-
> Test exited with signal 11.
> Executed: ./msc_test "-t" "op" "-n" "rx" "-p" 
> "(?^i:^([^=])\s*=\s*((?:abc)+(?:def|ghi){2})$)" "-D" "0" "-r" "1"
>      8) op "rx": failed
> Passed:  7; Failed:  1
> 
> I've tried version 2.7.2 which passed test on old debian and latest 2.7.3.
> Both failed on the same place.
> 
> Compilation parameters were:
> ./configure --prefix=/apache/modules/ --with-apxs=/apache/bin/apxs --with-
> apr=/apache/bin/apr-1-config --with-apu=/apache/bin/apu-1-config --enable-pcre-
> match-limit=50000 --enable-pcre-match-limit-recursion=10000 --disable-mlogc

Since it exits with signal 11 it might be related to this bug:

https://github.com/SpiderLabs/ModSecurity/issues/23

It was fixed in this commit

https://github.com/SpiderLabs/ModSecurity/commit/3f6c14de5993b8b2c66e6317af1680f2a007aead

and should be part of 2.7.2 and later. Maybe the fix didn't catch all
similar situations?

Regards,

Rainer

[Mod-security-developers] Make test failed

[Pavel M. <pa...@ne...>]

Hi guys,
I've upgraded our debian servers from wheezy to squeeze and I can't pass "make 
test" of modsecurity any more:

Loaded 8 tests from ./op/rx.t
     1) op "rx": passed (Pattern match "" at UNIT_TEST.)
     2) op "rx": passed
     3) op "rx": passed (Pattern match "" at UNIT_TEST.)
     4) op "rx": passed (Pattern match "abc" at UNIT_TEST.)
     5) op "rx": passed (Pattern match "def" at UNIT_TEST.)
     6) op "rx": passed (Pattern match "ghi" at UNIT_TEST.)
     7) op "rx": passed
ERROR: Failed to create rule for op "rx": Error creating rule: Error compiling 
pattern (offset 2): unrecognized character after (? or (?-
Test exited with signal 11.
Executed: ./msc_test "-t" "op" "-n" "rx" "-p" 
"(?^i:^([^=])\s*=\s*((?:abc)+(?:def|ghi){2})$)" "-D" "0" "-r" "1"
     8) op "rx": failed
Passed:  7; Failed:  1

I've tried version 2.7.2 which passed test on old debian and latest 2.7.3.
Both failed on the same place.

Compilation parameters were:
./configure --prefix=/apache/modules/ --with-apxs=/apache/bin/apxs --with-
apr=/apache/bin/apr-1-config --with-apu=/apache/bin/apu-1-config --enable-pcre-
match-limit=50000 --enable-pcre-match-limit-recursion=10000 --disable-mlogc
-- 
Pavel Mateja

Re: [Mod-security-developers] Tagging Thoughts

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

On Wed, May 01, 2013 at 12:33:49PM +0000, Ryan Barnett wrote:
> Actually, that would be the SecDefaultAction update -

I've played this through again here at home and it works via
SecDefaultAction. I've tried 2.6.7 and 2.7.3 and they both
behave the way you said.

What does not work though is your first proposal.

I'll try and find out why it misbehaved at work.

Meanwhile, I have updated the reference wiki by adding a tagging
example to the Example Usage of SecDefaultAction.

Thanks for your support, Ryan. It really helps to have somebody
respond to silly questions / ideas like this.

Christian

-- 
We must be diligent, we must keep learning, we will prevail.
-- Jeremia Grossman

Re: [Mod-security-developers] Tagging Thoughts

[<chr...@po...>]

Ryan,

> Unless I am missing something obvious, why can't you just use the regular
> "tag" action?
> https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-tag
>
> SecAction "id:'10001',pass,nolog,tag:'Safety Class: 3',tag:'Service
> License Agreement: 24/7',tag:'Service-ID: 38475',tag:'Documentation
> https://ourwiki/.../ExampleComService'"
>
> Why would this not work for your use-case?

When I tested this, it  would only add the tag to the rule with
the id 10001. My idea is to add this to every rule notice in the
error/audit log.

So I would write

SecAction "id:'10001',pass,nolog,addtag:'Safety Class: 3',addtag:'Service
License Agreement: 24/7',addtag:'Service-ID: 38475',addtag:'Documentation
https://ourwiki/.../ExampleComService'"

and get

[Wed May 01 02:00:28 2013] [error] [client 98.154.171.101] ModSecurity:
Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file
"/.../modsecurity-rules/base_rules/modsecurity_crs_21_protocol_anomalies.c
onf"] [line "47"] [id "960015"] [rev "2.2.3"] [msg "Request Missing an
Accept Header"] [severity "CRITICAL"] [tag
"PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT"] [tag "WASCTC/WASC-21"] [tag
"OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [tag: "Safety Class: 3"] 
[tag "Service License Agreement: 24/7"] [tag "Service-ID: 38475"] 
[tag "Documentation https://ourwiki/.../ExampleComService"]
[hostname "www.example.com "] [uri
"/.../application.do"] [unique_id "UYBk2x5RkRSAbHkhE9IAAXDQ"]

Reading your 2nd message, I also tried the SecDefaultAction.
This would be very neat and bring the functionality I am looking for.
However, it does not work either. 
I tested under 2.6.7; would it work under 2.7?
Do you have a fully working example?

Cheers,

Christian


-----Ursprüngliche Nachricht-----
Von: Ryan Barnett [mailto:RBa...@tr...] 
Gesendet: Mittwoch, 1. Mai 2013 14:25
An: mod...@li...; mod...@li...
Betreff: Re: [Mod-security-developers] Tagging Thoughts


On 5/1/13 4:54 AM, "chr...@po..." <chr...@po...>
wrote:

>Dear all,
>
>Last week, I've attended a workshop where the local security operations
>team, the server operators and the engineering team talked about
>ModSecurity tuning.
>
>During the session, I had an idea: it would really help the security
>operations team to get the alerts enriched with meta-data about the
>service. This could be interesting for all setups, but I believe that
>especially hosting providers / ISPs would benefit from this feature.
>
>Right now, our security operations team gets the errorlog entry and a
>link to the auditlog in their SIEM.
>
>As you know, a typical errorlog entry looks as follows:
>[Wed May 01 02:00:28 2013] [error] [client 98.154.171.101] ModSecurity:
>Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file
>"/.../modsecurity-rules/base_rules/modsecurity_crs_21_protocol_anomalies.c
>onf"] [line "47"] [id "960015"] [rev "2.2.3"] [msg "Request Missing an
>Accept Header"] [severity "CRITICAL"] [tag
>"PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT"] [tag "WASCTC/WASC-21"] [tag
>"OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "www.example.com "] [uri
>"/.../application.do"] [unique_id "UYBk2x5RkRSAbHkhE9IAAXDQ"]
>
>I would like every entry to be extended with the following tags:
>[tag: "Safety Class: 3"] [tag "Service License Agreement: 24/7"] [tag
>"Service-ID: 38475"] [tag "Documentation
>https://ourwiki/.../ExampleComService"]
>or
>[tag: "Metadata: Safety Class 3; Service License Agreement 24/7;
>service-id: 38475"; documentation https://ourwiki/.../ExampleComService"]
>with a strong preference for the former.
>
>It would be possible to configure the SIEM to add this data itself. But
>the SIEM is operated by the Security Operations and they would have to
>look up all this information. Besides, I think it should be part of the
>error-log of the server generally.
>
>If I get the ModSec tagging system correctly, the tags are always bound
>to a rule. Tags are a property of the rule. Additionally, I would like to
>see tags as a request property or even a service-property.
>Obviously, I could update all the rules (right now, most of them are
>shared between different services) or I could write UpdateRules, that add
>the tag to every rule at request time. Both variants seem quite
>inefficient to me.
>
>What would be efficient is a directive resembling the following ones:
>SecAction "id:'10001',pass,nolog,addtag:'Safety Class: 3',addtag:'Service
>License Agreement: 24/7',addtag:'Service-ID: 38475',addtag:'Documentation
>https://ourwiki/.../ExampleComService'"
>or
>SecTag "Safety Class: 3"
>SecTag "Service License Agreement: 24/7"
>SecTag "Service-ID: 38475"
>SecTag "Documentation https://ourwiki/.../ExampleComService"
>
>Now I do not know if this is feasible or even possible from a development
>viewpoint. But it sure looks desirable to me as a person configuring
>ModSec in corporate environments.
>
>Sorry for crossposting this to developers and users. I think both groups
>might have something to say. Feedback / support from other users would be
>especially welcome.
>
>Best regards,
>
>Christian

Christian,
Unless I am missing something obvious, why can't you just use the regular
"tag" action?
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-tag


SecAction "id:'10001',pass,nolog,tag:'Safety Class: 3',tag:'Service
License Agreement: 24/7',tag:'Service-ID: 38475',tag:'Documentation
https://ourwiki/.../ExampleComService'"


Why would this not work for your use-case?

-Ryan


________________________________

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.


------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
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

Re: [Mod-security-developers] Tagging Thoughts

[Ryan B. <RBa...@tr...>]

On 5/1/13 8:25 AM, "Ryan Barnett" <RBa...@tr...> wrote:

>
>On 5/1/13 4:54 AM, "chr...@po..." <chr...@po...>
>wrote:
>
>>Dear all,
>>
>>Last week, I've attended a workshop where the local security operations
>>team, the server operators and the engineering team talked about
>>ModSecurity tuning.
>>
>>During the session, I had an idea: it would really help the security
>>operations team to get the alerts enriched with meta-data about the
>>service. This could be interesting for all setups, but I believe that
>>especially hosting providers / ISPs would benefit from this feature.
>>
>>Right now, our security operations team gets the errorlog entry and a
>>link to the auditlog in their SIEM.
>>
>>As you know, a typical errorlog entry looks as follows:
>>[Wed May 01 02:00:28 2013] [error] [client 98.154.171.101] ModSecurity:
>>Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file
>>"/.../modsecurity-rules/base_rules/modsecurity_crs_21_protocol_anomalies.
>>c
>>onf"] [line "47"] [id "960015"] [rev "2.2.3"] [msg "Request Missing an
>>Accept Header"] [severity "CRITICAL"] [tag
>>"PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT"] [tag "WASCTC/WASC-21"] [tag
>>"OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "www.example.com "] [uri
>>"/.../application.do"] [unique_id "UYBk2x5RkRSAbHkhE9IAAXDQ"]
>>
>>I would like every entry to be extended with the following tags:
>>[tag: "Safety Class: 3"] [tag "Service License Agreement: 24/7"] [tag
>>"Service-ID: 38475"] [tag "Documentation
>>https://ourwiki/.../ExampleComService"]
>>or
>>[tag: "Metadata: Safety Class 3; Service License Agreement 24/7;
>>service-id: 38475"; documentation https://ourwiki/.../ExampleComService"]
>>with a strong preference for the former.
>>
>>It would be possible to configure the SIEM to add this data itself. But
>>the SIEM is operated by the Security Operations and they would have to
>>look up all this information. Besides, I think it should be part of the
>>error-log of the server generally.
>>
>>If I get the ModSec tagging system correctly, the tags are always bound
>>to a rule. Tags are a property of the rule. Additionally, I would like to
>>see tags as a request property or even a service-property.
>>Obviously, I could update all the rules (right now, most of them are
>>shared between different services) or I could write UpdateRules, that add
>>the tag to every rule at request time. Both variants seem quite
>>inefficient to me.
>>
>>What would be efficient is a directive resembling the following ones:
>>SecAction "id:'10001',pass,nolog,addtag:'Safety Class: 3',addtag:'Service
>>License Agreement: 24/7',addtag:'Service-ID: 38475',addtag:'Documentation
>>https://ourwiki/.../ExampleComService'"
>>or
>>SecTag "Safety Class: 3"
>>SecTag "Service License Agreement: 24/7"
>>SecTag "Service-ID: 38475"
>>SecTag "Documentation https://ourwiki/.../ExampleComService"
>>
>>Now I do not know if this is feasible or even possible from a development
>>viewpoint. But it sure looks desirable to me as a person configuring
>>ModSec in corporate environments.
>>
>>Sorry for crossposting this to developers and users. I think both groups
>>might have something to say. Feedback / support from other users would be
>>especially welcome.
>>
>>Best regards,
>>
>>Christian
>
>Christian,
>Unless I am missing something obvious, why can't you just use the regular
>"tag" action?
>https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-tag
>
>
>SecAction "id:'10001',pass,nolog,tag:'Safety Class: 3',tag:'Service
>License Agreement: 24/7',tag:'Service-ID: 38475',tag:'Documentation
>https://ourwiki/.../ExampleComService'"
>
>
>Why would this not work for your use-case?
>
>-Ryan

Actually, that would be the SecDefaultAction update -

SecDefaultAction "id:'10001',pass,nolog,tag:'Safety Class: 3',tag:'Service
License Agreement: 24/7',tag:'Service-ID: 38475',tag:'Documentation
https://ourwiki/.../ExampleComService'"





________________________________

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.

Re: [Mod-security-developers] Tagging Thoughts

[Ryan B. <RBa...@tr...>]

On 5/1/13 4:54 AM, "chr...@po..." <chr...@po...>
wrote:

>Dear all,
>
>Last week, I've attended a workshop where the local security operations
>team, the server operators and the engineering team talked about
>ModSecurity tuning.
>
>During the session, I had an idea: it would really help the security
>operations team to get the alerts enriched with meta-data about the
>service. This could be interesting for all setups, but I believe that
>especially hosting providers / ISPs would benefit from this feature.
>
>Right now, our security operations team gets the errorlog entry and a
>link to the auditlog in their SIEM.
>
>As you know, a typical errorlog entry looks as follows:
>[Wed May 01 02:00:28 2013] [error] [client 98.154.171.101] ModSecurity:
>Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file
>"/.../modsecurity-rules/base_rules/modsecurity_crs_21_protocol_anomalies.c
>onf"] [line "47"] [id "960015"] [rev "2.2.3"] [msg "Request Missing an
>Accept Header"] [severity "CRITICAL"] [tag
>"PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT"] [tag "WASCTC/WASC-21"] [tag
>"OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "www.example.com "] [uri
>"/.../application.do"] [unique_id "UYBk2x5RkRSAbHkhE9IAAXDQ"]
>
>I would like every entry to be extended with the following tags:
>[tag: "Safety Class: 3"] [tag "Service License Agreement: 24/7"] [tag
>"Service-ID: 38475"] [tag "Documentation
>https://ourwiki/.../ExampleComService"]
>or
>[tag: "Metadata: Safety Class 3; Service License Agreement 24/7;
>service-id: 38475"; documentation https://ourwiki/.../ExampleComService"]
>with a strong preference for the former.
>
>It would be possible to configure the SIEM to add this data itself. But
>the SIEM is operated by the Security Operations and they would have to
>look up all this information. Besides, I think it should be part of the
>error-log of the server generally.
>
>If I get the ModSec tagging system correctly, the tags are always bound
>to a rule. Tags are a property of the rule. Additionally, I would like to
>see tags as a request property or even a service-property.
>Obviously, I could update all the rules (right now, most of them are
>shared between different services) or I could write UpdateRules, that add
>the tag to every rule at request time. Both variants seem quite
>inefficient to me.
>
>What would be efficient is a directive resembling the following ones:
>SecAction "id:'10001',pass,nolog,addtag:'Safety Class: 3',addtag:'Service
>License Agreement: 24/7',addtag:'Service-ID: 38475',addtag:'Documentation
>https://ourwiki/.../ExampleComService'"
>or
>SecTag "Safety Class: 3"
>SecTag "Service License Agreement: 24/7"
>SecTag "Service-ID: 38475"
>SecTag "Documentation https://ourwiki/.../ExampleComService"
>
>Now I do not know if this is feasible or even possible from a development
>viewpoint. But it sure looks desirable to me as a person configuring
>ModSec in corporate environments.
>
>Sorry for crossposting this to developers and users. I think both groups
>might have something to say. Feedback / support from other users would be
>especially welcome.
>
>Best regards,
>
>Christian

Christian,
Unless I am missing something obvious, why can't you just use the regular
"tag" action?
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-tag


SecAction "id:'10001',pass,nolog,tag:'Safety Class: 3',tag:'Service
License Agreement: 24/7',tag:'Service-ID: 38475',tag:'Documentation
https://ourwiki/.../ExampleComService'"


Why would this not work for your use-case?

-Ryan


________________________________

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.

[Mod-security-developers] Tagging Thoughts

[<chr...@po...>]

Dear all,

Last week, I've attended a workshop where the local security operations team, the server operators and the engineering team talked about ModSecurity tuning.

During the session, I had an idea: it would really help the security operations team to get the alerts enriched with meta-data about the service. This could be interesting for all setups, but I believe that especially hosting providers / ISPs would benefit from this feature.

Right now, our security operations team gets the errorlog entry and a link to the auditlog in their SIEM.

As you know, a typical errorlog entry looks as follows:
[Wed May 01 02:00:28 2013] [error] [client 98.154.171.101] ModSecurity: Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file "/.../modsecurity-rules/base_rules/modsecurity_crs_21_protocol_anomalies.conf"] [line "47"] [id "960015"] [rev "2.2.3"] [msg "Request Missing an Accept Header"] [severity "CRITICAL"] [tag "PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "www.example.com "] [uri "/.../application.do"] [unique_id "UYBk2x5RkRSAbHkhE9IAAXDQ"]

I would like every entry to be extended with the following tags:
[tag: "Safety Class: 3"] [tag "Service License Agreement: 24/7"] [tag "Service-ID: 38475"] [tag "Documentation https://ourwiki/.../ExampleComService"]
or
[tag: "Metadata: Safety Class 3; Service License Agreement 24/7; service-id: 38475"; documentation https://ourwiki/.../ExampleComService"]
with a strong preference for the former.

It would be possible to configure the SIEM to add this data itself. But the SIEM is operated by the Security Operations and they would have to look up all this information. Besides, I think it should be part of the error-log of the server generally.

If I get the ModSec tagging system correctly, the tags are always bound to a rule. Tags are a property of the rule. Additionally, I would like to see tags as a request property or even a service-property.
Obviously, I could update all the rules (right now, most of them are shared between different services) or I could write UpdateRules, that add the tag to every rule at request time. Both variants seem quite inefficient to me.

What would be efficient is a directive resembling the following ones:
SecAction "id:'10001',pass,nolog,addtag:'Safety Class: 3',addtag:'Service License Agreement: 24/7',addtag:'Service-ID: 38475',addtag:'Documentation https://ourwiki/.../ExampleComService'"
or
SecTag "Safety Class: 3"
SecTag "Service License Agreement: 24/7"
SecTag "Service-ID: 38475"
SecTag "Documentation https://ourwiki/.../ExampleComService"

Now I do not know if this is feasible or even possible from a development viewpoint. But it sure looks desirable to me as a person configuring ModSec in corporate environments.

Sorry for crossposting this to developers and users. I think both groups might have something to say. Feedback / support from other users would be especially welcome.

Best regards,

Christian



Christian Folini
Unix Engineer, Apache Security Specialist

Die Schweizerische Post
Services
Informationstechnologie
Betrieb, IT 222 extern
Webergutstrasse 12
3030 Bern (Zollikofen)
Mobile +41 79 300 32 03
E-Mail: chr...@po...<http://folini.tikon.ch>
Internet: http://www.post.ch / http://folini.tikon.ch

[Mod-security-developers] [JIRA] Resolved: (MODSEC-339) Replace the value of remote_ip with the contents of a header when modsecurity logs to apache error log.

[Breno S. P. (JIRA) <no...@mo...>]

     [ https://www.modsecurity.org/tracker/browse/MODSEC-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Breno Silva Pinto resolved MODSEC-339.
--------------------------------------

    Resolution: Fixed

> Replace the value of remote_ip with the contents of a header when modsecurity logs to apache error log.
> -------------------------------------------------------------------------------------------------------
>
>                 Key: MODSEC-339
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-339
>             Project: ModSecurity
>          Issue Type: New Feature
>      Security Level: Normal
>          Components: Configuration, Logging
>            Reporter: Bruno Almeida
>            Assignee: Breno Silva Pinto
>             Fix For: 2.7.4
>
>
> When running apache behind a CDN, the remote_ip is never the real client IP, it's always one of the CDN's pop.
> The CDN normally sends a header with every request that contains the real client IP. Something like "X-TrueClient-IP"
> I can customize the access logs to use that header, I can also see the header in the audit logs, but error log format is not customizable (added in apache 2.4)
> What I'd like to propose is a new configuration parameter, something like SecErrorLogHeaderIP "X-TrueClient-IP" and use the value from the header if available, otherwise use remote_ip as normal.
>  I came up with this little hack, but without the configuration parameter option:
> *Disclaimer: I am not a developer and I have no idea what I could have broken in modsecurity with this little hack.*
> apache2_util.c:
> {noformat}
> *** apache2/apache2_util.c	2012-08-02 23:45:08.000000000 +0100
> --- apache2/apache2_util.c	2012-10-09 16:51:04.000000000 +0100
> ***************
> *** 263,275 ****
>           }
>           else hostname = "";
>   
>   #if AP_SERVER_MAJORVERSION_NUMBER > 1 && AP_SERVER_MINORVERSION_NUMBER > 2
>           ap_log_error(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO, 0, r->server,
>               "[client %s] ModSecurity: %s%s [uri \"%s\"]%s", r->connection->client_ip, str1,
>               hostname, log_escape(msr->mp, r->uri), unique_id);
>   #else
>           ap_log_error(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO, 0, r->server,
> !             "[client %s] ModSecurity: %s%s [uri \"%s\"]%s", r->connection->remote_ip, str1,
>               hostname, log_escape(msr->mp, r->uri), unique_id);
>   #endif
>   
> --- 263,284 ----
>           }
>           else hostname = "";
>   
> + /* Extract X-Forwarded-For header and put it in xforewardedip */
> +         char *xforwardedip = (apr_table_get(r->headers_in, "X-Forwarded-IP"));
> +         char *remoteclient;
> +         if  (xforwardedip != NULL) {
> +              remoteclient = xforwardedip;
> +         }
> +         else remoteclient = r->connection->remote_ip;
> + 
> + 
>   #if AP_SERVER_MAJORVERSION_NUMBER > 1 && AP_SERVER_MINORVERSION_NUMBER > 2
>           ap_log_error(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO, 0, r->server,
>               "[client %s] ModSecurity: %s%s [uri \"%s\"]%s", r->connection->client_ip, str1,
>               hostname, log_escape(msr->mp, r->uri), unique_id);
>   #else
>           ap_log_error(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO, 0, r->server,
> !             "[client %s] ModSecurity: %s%s [uri \"%s\"]%s", remoteclient, str1,
>               hostname, log_escape(msr->mp, r->uri), unique_id);
>   #endif
> {noformat}
> Thanks,
> Bruno

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Resolved: (MODSEC-362) Add a new directive that allows the user to define REMOTE_ADDR data

[Breno S. P. (JIRA) <no...@mo...>]

     [ https://www.modsecurity.org/tracker/browse/MODSEC-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Breno Silva Pinto resolved MODSEC-362.
--------------------------------------

    Resolution: Fixed

Added SecRemoteAddrDefine X-forwarded-For.
Don't need to specify the Collection name. It will search directly into REQUEST_HEADERS

> Add a new directive that allows the user to define REMOTE_ADDR data
> -------------------------------------------------------------------
>
>                 Key: MODSEC-362
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-362
>             Project: ModSecurity
>          Issue Type: New Feature
>      Security Level: Normal
>          Components: Configuration
>            Reporter: Ryan Barnett
>            Assignee: Breno Silva Pinto
>             Fix For: 2.7.4
>
>
> When in proxy environments, users need to be able to define how to populate the REMOTE_ADDR variable data from request headers such as:
> - X-Forwarded-For
> - X-Originating-IP
> - CF-Connecting-IP
> We should add a new directive called something like - SecRemoteAddrDefine where the user can specify what data should be used to populate the REMOTE_ADDR variable.
> Example -
> SecRemoteAddrDefine Default
> Would work as normal and uses the remove client's IP address.
> SecRemoteAddrDefine REQUEST_HEADERS:X-Forwarded-For
> Would populate REMOTE_ADDR with the data from that header field.  This will allow users to specify the right content for this variable and then all rules can use REMOTE_ADDR.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Resolved: (MODSEC-327) Review libinjection tool for possible inclusion in ModSecurity

[Breno S. P. (JIRA) <no...@mo...>]

     [ https://www.modsecurity.org/tracker/browse/MODSEC-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Breno Silva Pinto resolved MODSEC-327.
--------------------------------------

    Resolution: Fixed

> Review libinjection tool for possible inclusion in ModSecurity
> --------------------------------------------------------------
>
>                 Key: MODSEC-327
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-327
>             Project: ModSecurity
>          Issue Type: New Feature
>      Security Level: Normal
>          Components: Operators
>            Reporter: Ryan Barnett
>            Assignee: Breno Silva Pinto
>             Fix For: 2.7.4
>
>
> https://github.com/client9/libinjection
> http://media.blackhat.com/bh-us-12/Turbo/Galbreath/BH_US_12_Galbreath_Libinjection_Slides.pdf

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Resolved: (MODSEC-392) Configure-Documentation Bug: --enable-request-early does not list default

[Breno S. P. (JIRA) <no...@mo...>]

     [ https://www.modsecurity.org/tracker/browse/MODSEC-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Breno Silva Pinto resolved MODSEC-392.
--------------------------------------

    Resolution: Fixed

> Configure-Documentation Bug: --enable-request-early does not list default
> -------------------------------------------------------------------------
>
>                 Key: MODSEC-392
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-392
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>          Components: Configuration
>    Affects Versions: 2.7.3
>         Environment: Any environment I guess.
>            Reporter: Christian Folini
>            Assignee: Breno Silva Pinto
>             Fix For: 2.7.4
>
>
> If you run ./configure --help, you do not get a default value for --enable-request-early. Some other configuration items list their default value (i.e. "--enable-shared[=PKGS]  build shared libraries [default=yes]"). Here, a default value would be particularly useful as tracker issue dealing with this config item is not 100% clear what behaviour you get by default: https://www.modsecurity.org/tracker/browse/MODSEC-98

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Re: [Mod-security-developers] prce unit test error: Error creatingrule: Error compiling pattern (offset 2): unrecognizedcharacter after (? or (?-

[Rainer J. <rai...@ki...>]

On 06.04.2013 15:42, nickg wrote:
> there is an existing thread on this problem, but I can't figure out to reply to it via source forge.'
> 
> https://sourceforge.net/mailarchive/forum.php?thread_name=CAHQz1rJ-bNV2xaYc8A5jwVVY1AXNOOco8FynWudTUxwj5Js4dQ%40mail.gmail.com&forum_name=mod-security-developers
> 
> 
> Loaded 8 tests from ./op/rx.t
>      1) op "rx": passed (Pattern match "" at UNIT_TEST.)
>      2) op "rx": passed
>      3) op "rx": passed (Pattern match "" at UNIT_TEST.)
>      4) op "rx": passed (Pattern match "abc" at UNIT_TEST.)
>      5) op "rx": passed (Pattern match "def" at UNIT_TEST.)
>      6) op "rx": passed (Pattern match "ghi" at UNIT_TEST.)
>      7) op "rx": passed
> ERROR: Failed to create rule for op "rx": Error creating rule: Error compiling pattern (offset 2): unrecognized character after (? or (?-
> Test exited with signal 11.
> Executed: ./msc_test "-t" "op" "-n" "rx" "-p" "(?^i:^([^=])\s*=\s*((?:abc)+(?:def|ghi){2})$)" "-D" "0" "-r" "1"
>      8) op "rx": failed
> Passed:  7; Failed:  1
> 
> 
> $ apt-cache show libpcre3 
> Package: libpcre3
> Priority: required
> Section: libs
> Installed-Size: 455
> Maintainer: Ubuntu Developers <ubu...@li...>
> Original-Maintainer: Mark Baker <ma...@mn...>
> Architecture: amd64
> Source: pcre3
> Version: 1:8.30-5ubuntu1
> 
> Some other guy had a problem 1.8.31
> 
> perl seems to be ok with this regexp on same box
> 
>  perl -p -i -e 's/(?^i:^([^=])\s*=\s*((?:abc)+(?:def|ghi){2})$)//' AFILE
> 
> any tips here?

Which version of mod_security?

Could it be this bug:

https://github.com/SpiderLabs/ModSecurity/issues/23

It was fixed in this commit

https://github.com/SpiderLabs/ModSecurity/commit/3f6c14de5993b8b2c66e6317af1680f2a007aead

and should be part of 2.7.2 and later.

But maybe it is just a similar bug.

Regards,

Rainer

[Mod-security-developers] prce unit test error: Error creating rule: Error compiling pattern (offset 2): unrecognized character after (? or (?-

[nickg <ni...@cl...>]

Hi,

there is an existing thread on this problem, but I can't figure out to reply to it via source forge.'

https://sourceforge.net/mailarchive/forum.php?thread_name=CAHQz1rJ-bNV2xaYc8A5jwVVY1AXNOOco8FynWudTUxwj5Js4dQ%40mail.gmail.com&forum_name=mod-security-developers


Loaded 8 tests from ./op/rx.t
     1) op "rx": passed (Pattern match "" at UNIT_TEST.)
     2) op "rx": passed
     3) op "rx": passed (Pattern match "" at UNIT_TEST.)
     4) op "rx": passed (Pattern match "abc" at UNIT_TEST.)
     5) op "rx": passed (Pattern match "def" at UNIT_TEST.)
     6) op "rx": passed (Pattern match "ghi" at UNIT_TEST.)
     7) op "rx": passed
ERROR: Failed to create rule for op "rx": Error creating rule: Error compiling pattern (offset 2): unrecognized character after (? or (?-
Test exited with signal 11.
Executed: ./msc_test "-t" "op" "-n" "rx" "-p" "(?^i:^([^=])\s*=\s*((?:abc)+(?:def|ghi){2})$)" "-D" "0" "-r" "1"
     8) op "rx": failed
Passed:  7; Failed:  1


$ apt-cache show libpcre3 
Package: libpcre3
Priority: required
Section: libs
Installed-Size: 455
Maintainer: Ubuntu Developers <ubu...@li...>
Original-Maintainer: Mark Baker <ma...@mn...>
Architecture: amd64
Source: pcre3
Version: 1:8.30-5ubuntu1

Some other guy had a problem 1.8.31

perl seems to be ok with this regexp on same box

 perl -p -i -e 's/(?^i:^([^=])\s*=\s*((?:abc)+(?:def|ghi){2})$)//' AFILE

any tips here?

thanks,

nickg

[Mod-security-developers] [JIRA] Resolved: (MODSEC-388) Nginx Modsec 2.7.3 regular expression problem

[Breno S. P. (JIRA) <no...@mo...>]

     [ https://www.modsecurity.org/tracker/browse/MODSEC-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Breno Silva Pinto resolved MODSEC-388.
--------------------------------------

    Fix Version/s: 2.7.4
       Resolution: Fixed

> Nginx Modsec 2.7.3 regular expression problem
> ---------------------------------------------
>
>                 Key: MODSEC-388
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-388
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>          Components: Rules
>    Affects Versions: 2.7.3
>         Environment: Nginx 1.2.6, CentOS 6.4 64-bits
>            Reporter: Hung Le
>            Assignee: Breno Silva Pinto
>             Fix For: 2.7.4
>
>
> Nginx Modsec 2.7.3 compiled on CentOS 6.4 64-bit seems to have problem with regular expression:
> The following rule return "404" instead of "403"
> SecRule REQUEST_URI "(^/admin)" \
>   "id:'10', \
>   t:none, \
>   phase:1, \
>   log, \
>   deny, \
>   status:403"
> The following rule works just fine:
> SecRule REQUEST_URI "admin" \
>   "id:'10', \
>   t:none, \
>   phase:1, \
>   log, \
>   deny, \
>   status:403"
> I did not have this problem with ModSec 2.7.2.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Re: [Mod-security-developers] [mod-security-users] Availability of ModSecurity 2.7.3 Stable Release

[Ryan B. <RBa...@tr...>]

Important note – as mentioned below, this release includes a security fix for a libxml2 external entity execution attack - http://secunia.com/advisories/52847/

It is highly recommended that you upgrade.

--
Ryan Barnett
Trustwave SpiderLabs
ModSecurity Project Leader
OWASP ModSecurity CRS Project Leader

From: Breno Silva <bre...@gm...<mailto:bre...@gm...>>
Date: Friday, March 29, 2013 12:55 PM
To: "mod...@li...<mailto:mod...@li...>" <mod...@li...<mailto:mod...@li...>>, mod-security-developers <mod...@li...<mailto:mod...@li...>>, <mod...@li...<mailto:mod...@li...>>
Subject: [mod-security-users] Availability of ModSecurity 2.7.3 Stable Release

The ModSecurity Development Team is pleased to announce the availability of ModSecurity 2.7.3 Stable Release.The stability of this release is good and includes many bug fixes.

Many issues and missing features for NGINX module were fixed. NGINX module version is now RC. We have fixed some minor issues for IIS.

We also added some important new features, the ability to load some specific directives into .htaccess files and the SecXmlExternalEntity security feature that will disable by default the possibility to load xml external entities. We recommend all users use this version.

Please see the release notes included into CHANGES file. For known problems and more information about bug fixes, please see the online ModSecurity Jira. Please report any bug to mod...@li...<mailto:mod...@li...>.

Thanks

Breno Silva

------------------------------------------------------------------------------ Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2_______________________________________________ mod-security-users mailing list mod...@li...<mailto: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/

________________________________

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.

[Mod-security-developers] Availability of ModSecurity 2.7.3 Stable Release

[Breno S. <bre...@gm...>]

The ModSecurity Development Team is pleased to announce the availability of
ModSecurity 2.7.3 Stable Release.The stability of this release is good and
includes many bug fixes.

Many issues and missing features for NGINX module were fixed. NGINX module
version is now RC. We have fixed some minor issues for IIS.

We also added some important new features, the ability to load some
specific directives into .htaccess files and the SecXmlExternalEntity
security feature that will disable by default the possibility to load xml
external entities. We recommend all users use this version.

Please see the release notes included into CHANGES file. For known problems
and more information about bug fixes, please see the online ModSecurity
Jira. Please report any bug to mod...@li...
.

Thanks

Breno Silva

[Mod-security-developers] [JIRA] Closed: (MODSEC-374) Nginx worker process segfault when using SecAuditEngine

[Breno S. P. (JIRA) <no...@mo...>]

     [ https://www.modsecurity.org/tracker/browse/MODSEC-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Breno Silva Pinto closed MODSEC-374.
------------------------------------

    Resolution: Fixed

Closing this. No feedback, however looks fixed.

> Nginx worker process segfault when using SecAuditEngine
> -------------------------------------------------------
>
>                 Key: MODSEC-374
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-374
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>          Components: Logging
>         Environment: Debian Linux 6, Nginx 1.3.8, mod_security from trunk (07.01.2013)
>            Reporter: Andreas Jaggi
>            Assignee: Breno Silva Pinto
>              Labels: nginx
>             Fix For: 2.7.3
>
>         Attachments: config.log
>
>
> When having SecAuditEngine set to On or RelevantOnly, everytime a ModSec rule (I'm using OWASP CRS rules) matches, the nginx worker segfaults and does not write to SecAuditLog (I have SecAuditLogType set to Serial), the request is properly handled though and the ModSec debuglog shows the matched CRS rule.
> Logfiles:
> ==> /var/log/nginx/error.log <==
> 2013/01/08 14:24:33 [info] 7558#0: [client 213.156.230.133] ModSecurity: Warning. Pattern match "(?i:(?:union\\s*?(?:all|distinct|[(!@]*?)?\\s*?[([]*?\\s*?select)|(?:\\w+\\s+like\\s+[\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98])|(?:like\\s*?[\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98]\\%)|(?:[\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98]\\s*?like\\W*?[\"'`\xc2\xb4\xe2 ..." at ARGS:foo. [file "/etc/nginx/mod_security.rpx.real.jaggi.info.conf.d/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf"] [line "223"] [id "981245"] [msg "Detects basic SQL authentication bypass attempts 2/3"] [data "Matched Data: select from found within ARGS:foo: select from"] [severity "CRITICAL"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [hostname "standalone"] [uri "/ip/?foo=select%20from"] [unique_id "12345"]
> ==> /var/log/nginx/rpx.real.jaggi.info-ip.access.log <==
> 213.156.230.133 - - [08/Jan/2013:14:24:33 +0100]  "GET /ip/?foo=select%20from HTTP/1.1" 200 27 "-" "curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8r zlib/1.2.5" 0.038
> ==> /var/log/nginx/error.log <==
> 2013/01/08 14:24:33 [alert] 7554#0: worker process 7558 exited on signal 11
> ModSec Debug Log:
> [08/Jan/2013:14:24:33 +0100] [standalone/sid#19d3470][rid#22e8db0][/ip/?foo=select%20from][2] Warning. Pattern match "(?i:(?:union\\s*?(?:all|distinct|[(!@]*?)?\\s*?[([]*?\\s*?select)|(?:\\w+\\s+like\\s+[\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98])|(?:like\\s*?[\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98]\\%)|(?:[\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98]\\s*?like\\W*?[\"'`\xc2\xb4\xe2 ..." at ARGS:foo. [file "/etc/nginx/mod_security.rpx.real.jaggi.info.conf.d/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf"] [line "223"] [id "981245"] [msg "Detects basic SQL authentication bypass attempts 2/3"] [data "Matched Data: select from found within ARGS:foo: select from"] [severity "CRITICAL"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Resolved: (MODSEC-58) Allow .htaccess like functionality again

[Breno S. P. (JIRA) <no...@mo...>]

     [ https://www.modsecurity.org/tracker/browse/MODSEC-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Breno Silva Pinto resolved MODSEC-58.
-------------------------------------

    Fix Version/s: 2.7.3
                       (was: 3.0.0)
       Resolution: Fixed

> Allow .htaccess like functionality again
> ----------------------------------------
>
>                 Key: MODSEC-58
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-58
>             Project: ModSecurity
>          Issue Type: Improvement
>      Security Level: Normal
>          Components: Core
>            Reporter: Brian Rectanus
>            Assignee: Breno Silva Pinto
>            Priority: Low
>             Fix For: 2.7.3
>
>
> We need to allow limited .htaccess like functionality for hosting providers, but without the risks of full .htaccess functionality.
> Need to:
> * Limit what directives are available
> * Have the ability to require certain rules
> * Not affect Apache config (ie ModSecurity only)
> Ideas/comments are welcome :)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Re: [Mod-security-developers] ModSec triggering apr_pool_cleanup_nullloop in Apache

[Curtis W. <cw...@si...>]

Hey guys,

Sorry for the long delay in responding, we have ended up going with
prefork and everything seems to be stable with it - a slightly higher
load perhaps, but stable none the less :)

We were never able to figure much out, even with 'guessing' and randomly
disabling the extra modules :-/

On 02/13/2013 06:49 PM, Breno Silva wrote:
> We have a lot of users running Apache worker and prefork. However to
> be honest i don't remember anyone that contact me using event. So, as
> i never saw a report about this issue using worker and prefork... you
> can try both and send us a feedback.
>
> Thanks
>
> Breno
>
> On Wed, Feb 13, 2013 at 10:14 PM, Rainer Jung <rai...@ki...
> <mailto:rai...@ki...>> wrote:
>
>     On 13.02.2013 19:21, Curtis Wood wrote:
>     > Hi Guys,
>     >
>     > Yes, mpm-event is experimental - and now with everything coming to
>     > light, that may be the whole problem along with the apr not
>     being thread
>     > safe it sounds like?
>
>     The event MPM itself should not be the problem. The APR libraries were
>     originally developed as a basis for Apache 2 and many of the
>     Apache devs
>     are also APR devs.
>
>     But the threaded nature of the Apache processes when using the
>     event or
>     worker MPMs means that all modules must be programmed thread-safe too.
>     Most of the popular ones are though.
>
>     > After talking it over some we may just go with the prefork.
>
>     If that is an option for you, chances are good the problem vanishes.
>
>     > On the actual system - sry about that :-P We are on Linux
>     X86_64, CentOS
>     > 5.9 - On the extra modules, we have
>     ssl,fcgi,passenger,bw_limited and qos
>
>     Ah, lots of 3rd party. You could try to update to latest versions of
>     those. I don't have an indication, that those have a problem though.
>
>     > On when it happens - it can be at any time, originally when this
>     came to
>     > light on a single site VPS, you could randomly click links to
>     trigger it
>     > after a few minutes - while, clicking the same link twice would not
>     > guarantee anything. On the main servers which get a lot more
>     traffic, it
>     > can be anywhere from hours to days.
>
>     ACK.
>
>     Rainer
>
>
>     ------------------------------------------------------------------------------
>     Free Next-Gen Firewall Hardware Offer
>     Buy your Sophos next-gen firewall before the end March 2013
>     and get the hardware for free! Learn more.
>     http://p.sf.net/sfu/sophos-d2d-feb
>     _______________________________________________
>     mod-security-developers mailing list
>     mod...@li...
>     <mailto:mod...@li...>
>     https://lists.sourceforge.net/lists/listinfo/mod-security-developers
>     ModSecurity Services from Trustwave's SpiderLabs:
>     https://www.trustwave.com/spiderLabs.php
>
>
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013 
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
>
>
> _______________________________________________
> 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

Re: [Mod-security-developers] Rule processing failed

[Diego E. P. <fla...@fl...>]

On 16/02/2013 22:40, Breno Silva wrote:
> 
> Yes. We should review the all operators and check the error msgs.
> Is it something you can reproduce ? If so, maybe you can enable debug
> log at this moment and try to identify which rule/operator is returning
> the error.

Reproduce, yes... easily not sure. The problem is that I get quite a bit
of bots that end up going through... it would be easier if I could
enable full debug only for one hit.. I'll try.

-- 
Diego Elio Pettenò — Flameeyes
fla...@fl... — http://blog.flameeyes.eu/

Re: [Mod-security-developers] Rule processing failed

[Breno S. <bre...@gm...>]

Hello Diego,

Yes. We should review the all operators and check the error msgs.
Is it something you can reproduce ? If so, maybe you can enable debug log
at this moment and try to identify which rule/operator is returning the
error.

Thanks

Breno

On Sat, Feb 16, 2013 at 5:02 PM, Diego Elio Pettenò
<fla...@fl...>wrote:

> Hi all,
>
> I just noticed that probably one of my rules is causing "Rule processing
> failed" errors to be printed on modsec_audit.. Unfortunately it does not
> say which.
>
> Bug 237 [1] was fixed for ipMatch, but does not seem to have solved the
> general case yet...
>
> [1] https://www.modsecurity.org/tracker/browse/MODSEC-237
>
> --
> Diego Elio Pettenò — Flameeyes
> fla...@fl... — http://blog.flameeyes.eu/
>
>
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> is your hub for all things parallel software development, from weekly
> thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - join the conversation now.
> http://goparallel.sourceforge.net/
> _______________________________________________
> 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-developers] Rule processing failed

[Diego E. P. <fla...@fl...>]

Hi all,

I just noticed that probably one of my rules is causing "Rule processing
failed" errors to be printed on modsec_audit.. Unfortunately it does not
say which.

Bug 237 [1] was fixed for ipMatch, but does not seem to have solved the
general case yet...

[1] https://www.modsecurity.org/tracker/browse/MODSEC-237

-- 
Diego Elio Pettenò — Flameeyes
fla...@fl... — http://blog.flameeyes.eu/

Re: [Mod-security-developers] ModSec triggering apr_pool_cleanup_nullloop in Apache

[Breno S. <bre...@gm...>]

We have a lot of users running Apache worker and prefork. However to be
honest i don't remember anyone that contact me using event. So, as i never
saw a report about this issue using worker and prefork... you can try both
and send us a feedback.

Thanks

Breno

On Wed, Feb 13, 2013 at 10:14 PM, Rainer Jung <rai...@ki...>wrote:

> On 13.02.2013 19:21, Curtis Wood wrote:
> > Hi Guys,
> >
> > Yes, mpm-event is experimental - and now with everything coming to
> > light, that may be the whole problem along with the apr not being thread
> > safe it sounds like?
>
> The event MPM itself should not be the problem. The APR libraries were
> originally developed as a basis for Apache 2 and many of the Apache devs
> are also APR devs.
>
> But the threaded nature of the Apache processes when using the event or
> worker MPMs means that all modules must be programmed thread-safe too.
> Most of the popular ones are though.
>
> > After talking it over some we may just go with the prefork.
>
> If that is an option for you, chances are good the problem vanishes.
>
> > On the actual system - sry about that :-P We are on Linux X86_64, CentOS
> > 5.9 - On the extra modules, we have ssl,fcgi,passenger,bw_limited and qos
>
> Ah, lots of 3rd party. You could try to update to latest versions of
> those. I don't have an indication, that those have a problem though.
>
> > On when it happens - it can be at any time, originally when this came to
> > light on a single site VPS, you could randomly click links to trigger it
> > after a few minutes - while, clicking the same link twice would not
> > guarantee anything. On the main servers which get a lot more traffic, it
> > can be anywhere from hours to days.
>
> ACK.
>
> Rainer
>
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> 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
>