mod-security-users — General discussion about mod_security

Re: [mod-security-users] Can we consume Third Part IP reputation list?

[Blason R <bla...@gm...>]

Hi there,

Sorry for the confusion. What I mean about third party is; I saw modsec can
only consume rbl but since we are running our own honeypot we are
generating out own feeds and waned to know if those can be consumed instead
of default one.

Since I am pretty novice my apology for any confusion.

On Mon, Apr 13, 2020 at 5:37 PM Reindl Harald <h.r...@th...>
wrote:

>
>
> Am 13.04.20 um 13:54 schrieb Blason R:
> > Well since we are gathering the events through specific high interaction
> > Honeypots wanted to specifically rely on our IP list. Please suggest the
> > changes that I need to make to achieve this?
>
> you are asking "can consume any third party IP reputation list" in
> context of "Just like we internally generate our own IP reputation list"
>
> jesus, you do the same with the same syntax and if you want to know "how
> can i use RBL with modsec" than ask that instead talking about "third
> party IP reputation list Just like we internally generate our own IP
> reputation list"
>
> https://malware.expert/howto/modsecurity-rbl-database/
>
> > On Mon, Apr 13, 2020 at 4:44 PM Reindl Harald <h.r...@th...
> > <mailto:h.r...@th...>> wrote:
> >
> >
> >
> >     Am 13.04.20 um 13:04 schrieb Blason R:
> >     > Wondering if we can consume any third party IP reputation list
> through
> >     > modsec?
> >     > Just like we internally generate our own IP reputation list through
> >     > honeypot and wanted to know if I can use that?
> >
> >     you can but besides performance consideration you won#t find any RBL
> you
> >     can trust enough
> >
> >     why do you think modsec, postfix or any other software distincts
> between
> >     your RBL or a external RBL? same techniqe and same syntax
> >
> >     was cool last year as spamhaus XBL started at friday evening with
> >     positive responses for every IP and we had used it only for
> form-submits
> >     (because of performance consideration)
>
>
>
> _______________________________________________
> 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] Can we consume Third Part IP reputation list?

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

Am 13.04.20 um 13:54 schrieb Blason R:
> Well since we are gathering the events through specific high interaction
> Honeypots wanted to specifically rely on our IP list. Please suggest the
> changes that I need to make to achieve this?

you are asking "can consume any third party IP reputation list" in
context of "Just like we internally generate our own IP reputation list"

jesus, you do the same with the same syntax and if you want to know "how
can i use RBL with modsec" than ask that instead talking about "third
party IP reputation list Just like we internally generate our own IP
reputation list"

https://malware.expert/howto/modsecurity-rbl-database/

> On Mon, Apr 13, 2020 at 4:44 PM Reindl Harald <h.r...@th...
> <mailto:h.r...@th...>> wrote:
> 
> 
> 
>     Am 13.04.20 um 13:04 schrieb Blason R:
>     > Wondering if we can consume any third party IP reputation list through
>     > modsec?
>     > Just like we internally generate our own IP reputation list through
>     > honeypot and wanted to know if I can use that?
> 
>     you can but besides performance consideration you won#t find any RBL you
>     can trust enough
> 
>     why do you think modsec, postfix or any other software distincts between
>     your RBL or a external RBL? same techniqe and same syntax
> 
>     was cool last year as spamhaus XBL started at friday evening with
>     positive responses for every IP and we had used it only for form-submits
>     (because of performance consideration)

Re: [mod-security-users] Can we consume Third Part IP reputation list?

[Blason R <bla...@gm...>]

Well since we are gathering the events through specific high interaction
Honeypots wanted to specifically rely on our IP list. Please suggest the
changes that I need to make to achieve this?

On Mon, Apr 13, 2020 at 4:44 PM Reindl Harald <h.r...@th...>
wrote:

>
>
> Am 13.04.20 um 13:04 schrieb Blason R:
> > Wondering if we can consume any third party IP reputation list through
> > modsec?
> > Just like we internally generate our own IP reputation list through
> > honeypot and wanted to know if I can use that?
>
> you can but besides performance consideration you won#t find any RBL you
> can trust enough
>
> why do you think modsec, postfix or any other software distincts between
> your RBL or a external RBL? same techniqe and same syntax
>
> was cool last year as spamhaus XBL started at friday evening with
> positive responses for every IP and we had used it only for form-submits
> (because of performance consideration)
>
>
>
>
> _______________________________________________
> 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] Can we consume Third Part IP reputation list?

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

Am 13.04.20 um 13:04 schrieb Blason R:
> Wondering if we can consume any third party IP reputation list through
> modsec?
> Just like we internally generate our own IP reputation list through
> honeypot and wanted to know if I can use that?

you can but besides performance consideration you won#t find any RBL you
can trust enough

why do you think modsec, postfix or any other software distincts between
your RBL or a external RBL? same techniqe and same syntax

was cool last year as spamhaus XBL started at friday evening with
positive responses for every IP and we had used it only for form-submits
(because of performance consideration)

[mod-security-users] Can we consume Third Part IP reputation list?

[Blason R <bla...@gm...>]

Hi Folks,

Wondering if we can consume any third party IP reputation list through
modsec?
Just like we internally generate our own IP reputation list through
honeypot and wanted to know if I can use that?

TIA
Blason R

Re: [mod-security-users] Don't understand why this rule is triggering - 973347

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

Hi all,

I've had a rule trigger as part of an webapp that sits in front of mod security.

The log entry is below, at first I though it was a issue with 

    SecPcreMatchLimit 1000
    SecPcreMatchLimitRecursion 1000

But setting these to 9999999999999999 to rule it out made no difference - and in actual fact even set to 1000 now it is fine.

I ended up excluding owsap rule 973347 from the page which seems to have fixed the issue.

Could anyone explain why? I don't see why the following request would trigger the rule in question.

--5b210061-A--
[20/Mar/2020:12:06:56 +0000] XnSx3xYuJtXNqpDeWlecIwAAABA 1.1.1.1 10752 10.0.39.10 443
--5b210061-B--
POST /webclient/secure/strategies/edit?scn=DURHAM0000025797 HTTP/1.1
Host: web.internet.info
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
Content-Length: 6595
Origin: https://web.internet.info
Connection: keep-alive
Referer: ###############
Cookie: JSESSIONID=986ACBF183789B53A607AAA54283698F
Upgrade-Insecure-Requests: 1

--5b210061-C--
deleteStrategy=N&strategyRule=%7B%22data%22%3A%22AND%22%2C%22state%22%3A%22leaf%22%2C%22attr%22%3A%7B%22systemCodeNumber%22%3A%225396%22%2C%22nodeType%22%3A%22OPERATOR%22%7D%2C%22children%22%3A%5B%7B%22data%22%3A%22test+12%22%2C%22state%22%3A%22leaf%22%2C%22attr%22%3A%7B%22systemCodeNumber%22%3A%225370%22%2C%22nodeType%22%3A%22EXPRESSION%22%7D%2C%22children%22%3A%5B%5D%7D%2C%7B%22data%22%3A%22test+11%22%2C%22state%22%3A%22leaf%22%2C%22attr%22%3A%7B%22systemCodeNumber%22%3A%225369%22%2C%22nodeType%22%3A%22EXPRESSION%22%7D%2C%22children%22%3A%5B%5D%7D%2C%7B%22data%22%3A%22test+10%22%2C%22state%22%3A%22leaf%22%2C%22attr%22%3A%7B%22systemCodeNumber%22%3A%225368%22%2C%22nodeType%22%3A%22EXPRESSION%22%7D%2C%22children%22%3A%5B%5D%7D%2C%7B%22data%22%3A%22test+9%22%2C%22state%22%3A%22leaf%22%2C%22attr%22%3A%7B%22systemCodeNumber%22%3A%225367%22%2C%22nodeType%22%3A%22EXPRESSION%22%7D%2C%22children%22%3A%5B%5D%7D%2C%7B%22data%22%3A%22test+8%22%2C%22state%22%3A%22leaf%22%2C%22attr%22%3A%7B%22systemCodeNumber%22%3A%225366%22%2C%22nodeType%22%3A%22EXPRESSION%22%7D%2C%22children%22%3A%5B%5D%7D%2C%7B%22data%22%3A%22test+7%22%2C%22state%22%3A%22leaf%22%2C%22attr%22%3A%7B%22systemCodeNumber%22%3A%225365%22%2C%22nodeType%22%3A%22EXPRESSION%22%7D%2C%22children%22%3A%5B%5D%7D%2C%7B%22data%22%3A%22test+12%22%2C%22state%22%3A%22leaf%22%2C%22attr%22%3A%7B%22systemCodeNumber%22%3A%225370%22%2C%22nodeType%22%3A%22EXPRESSION%22%7D%2C%22children%22%3A%5B%5D%7D%2C%7B%22data%22%3A%22test+8%22%2C%22state%22%3A%22leaf%22%2C%22attr%22%3A%7B%22systemCodeNumber%22%3A%225366%22%2C%22nodeType%22%3A%22EXPRESSION%22%7D%2C%22children%22%3A%5B%5D%7D%2C%7B%22data%22%3A%22test+11%22%2C%22state%22%3A%22leaf%22%2C%22attr%22%3A%7B%22systemCodeNumber%22%3A%225369%22%2C%22nodeType%22%3A%22EXPRESSION%22%7D%2C%22children%22%3A%5B%5D%7D%2C%7B%22data%22%3A%22test+12%22%2C%22state%22%3A%22leaf%22%2C%22attr%22%3A%7B%22systemCodeNumber%22%3A%225370%22%2C%22nodeType%22%3A%22EXPRESSION%22%7D%2C%22children%22%3A%5B%5D%7D%2C%7B%22data%22%3A%22test+11%22%2C%22state%22%3A%22leaf%22%2C%22attr%22%3A%7B%22systemCodeNumber%22%3A%225369%22%2C%22nodeType%22%3A%22EXPRESSION%22%7D%2C%22children%22%3A%5B%5D%7D%2C%7B%22data%22%3A%22test+10%22%2C%22state%22%3A%22leaf%22%2C%22attr%22%3A%7B%22systemCodeNumber%22%3A%225368%22%2C%22nodeType%22%3A%22EXPRESSION%22%7D%2C%22children%22%3A%5B%5D%7D%2C%7B%22data%22%3A%22test+9%22%2C%22state%22%3A%22leaf%22%2C%22attr%22%3A%7B%22systemCodeNumber%22%3A%225367%22%2C%22nodeType%22%3A%22EXPRESSION%22%7D%2C%22children%22%3A%5B%5D%7D%2C%7B%22data%22%3A%22test+8%22%2C%22state%22%3A%22leaf%22%2C%22attr%22%3A%7B%22systemCodeNumber%22%3A%225366%22%2C%22nodeType%22%3A%22EXPRESSION%22%7D%2C%22children%22%3A%5B%5D%7D%2C%7B%22data%22%3A%22test+7%22%2C%22state%22%3A%22leaf%22%2C%22attr%22%3A%7B%22systemCodeNumber%22%3A%225365%22%2C%22nodeType%22%3A%22EXPRESSION%22%7D%2C%22children%22%3A%5B%5D%7D%2C%7B%22data%22%3A%22test+6%22%2C%22state%22%3A%22leaf%22%2C%22attr%22%3A%7B%22systemCodeNumber%22%3A%225364%22%2C%22nodeType%22%3A%22EXPRESSION%22%7D%2C%22children%22%3A%5B%5D%7D%2C%7B%22data%22%3A%22test+5%22%2C%22state%22%3A%22leaf%22%2C%22attr%22%3A%7B%22systemCodeNumber%22%3A%225363%22%2C%22nodeType%22%3A%22EXPRESSION%22%7D%2C%22children%22%3A%5B%5D%7D%2C%7B%22data%22%3A%22test+3%22%2C%22state%22%3A%22leaf%22%2C%22attr%22%3A%7B%22systemCodeNumber%22%3A%225361%22%2C%22nodeType%22%3A%22EXPRESSION%22%7D%2C%22children%22%3A%5B%5D%7D%2C%7B%22data%22%3A%22test2%22%2C%22state%22%3A%22leaf%22%2C%22attr%22%3A%7B%22systemCodeNumber%22%3A%225360%22%2C%22nodeType%22%3A%22EXPRESSION%22%7D%2C%22children%22%3A%5B%5D%7D%2C%7B%22data%22%3A%22test%22%2C%22state%22%3A%22leaf%22%2C%22attr%22%3A%7B%22systemCodeNumber%22%3A%225359%22%2C%22nodeType%22%3A%22EXPRESSION%22%7D%2C%22children%22%3A%5B%5D%7D%5D%7D&strategyResponse=%7B%22strategy%22%3A%22DURHAM0000025797%22%2C%22responseDuration%22%3A0%2C%22responseFixedPeriod%22%3A%22N%22%2C%22logOnly%22%3A%22N%22%2C%22activateOnStartup%22%3A%22N%22%2C%22confirmStart%22%3A%22S%22%2C%22confirmStartWhenFault%22%3A%22N%22%2C%22noStartWhenFault%22%3A%22N%22%2C%22informWhenStartFailure%22%3A%22S%22%2C%22stopWhenStartFailure%22%3A%22N%22%2C%22informWhenStopFailure%22%3A%22N%22%2C%22fixedPeriodEndConfirm%22%3A%22N%22%2C%22fxdPeriodEndConfirmRunOnTime%22%3A0%2C%22responseRunOn%22%3A%22N%22%2C%22fixedPeriodEndAutomaticRunOn%22%3A%22N%22%2C%22fixedPeriodEndAutoRunOnTime%22%3A0%2C%22fixedPeriodEndAutoRunOnCount%22%3A0%2C%22responseRuleNoLongerTrue%22%3A%22N%22%2C%22responseRuleNoLongerTrueTime%22%3A0%2C%22responseRepeatFixedPeriod%22%3A%22N%22%2C%22fixedPeriodRepeatCount%22%3A0%2C%22responseRunFixedPeriodOnly%22%3A%22N%22%2C%22defaultAfter%22%3A5%2C%22startOrder%22%3A%22A1044+%22%2C%22stopOrder%22%3A%22A1044+%22%2C%22readyForUse%22%3A%22N%22%2C%22createdBy%22%3A%22mm80700%22%2C%22creationDate%22%3A%22Mar+20%2C+2020+10%3A55%3A24+AM%22%2C%22createdByDataSource%22%3A%22MottMac%22%2C%22updatedBy%22%3A%22mm56570%22%2C%22lastUpdated%22%3A%22Mar+20%2C+2020+11%3A19%3A05+AM%22%2C%22modifiedByDataSource%22%3A%22MottMac%22%2C%22deleteResponse%22%3A%22N%22%2C%22evaluateOnStateChangeOnly%22%3A%22Y%22%2C%22evaluateOnDataUpdateOnly%22%3A%22N%22%2C%22systemCodeNumber%22%3A%226160%22%2C%22utmcType%22%3A%22RESPONSE_DEFINITION%22%2C%22userAcknowledgements%22%3A%5B%5D%7D&description=Ta+Test+Strategy+3&strategyType=Local&publishTo=Not+Published&bypassRuleEvaluation=N&responseDefinition.logOnly=N&responseDefinition.activateOnStartup=N&responseDefinition.confirmStart=S&responseDefinition.confirmStartWhenFault=N&responseDefinition.noStartWhenFault=N&responseDefinition.informWhenStartFailure=S&responseDefinition.stopWhenStartFailure=N&responseDefinition.informWhenStopFailure=N&responseDefinition.evaluateOnStateChangeOnly=Y&responseDefinition.evaluateOnDataUpdateOnly=N&responseDefinition.evaluateOnDataUpdateOnly=N&ruleEvaluation=on&_=on&_=on&_=on&_=on&responseDefinition.responseFixedPeriod=N&responseDefinition.responseDuration=0&responseDefinition.responseRunFixedPeriodOnly=N&responseDefinition.fixedPeriodEndConfirm=N&responseDefinition.fxdPeriodEndConfirmRunOnTime=0&responseDefinition.fixedPeriodEndAutomaticRunOn=N&responseDefinition.fixedPeriodEndAutoRunOnTime=0&responseDefinition.fixedPeriodEndAutoRunOnCount=0&responseDefinition.responseRepeatFixedPeriod=N&responseDefinition.fixedPeriodRepeatCount=0&responseDefinition.responseRuleNoLongerTrue=N&responseDefinition.responseRuleNoLongerTrueTime=0&responseDefinition.defaultAfter=5&excludeSpecialDaysFromSchedule=Y&_=on&furtherComments=+&location.easting=400000.0&location.northing=525000.0
--5b210061-F--
HTTP/1.1 403 Forbidden
Strict-Transport-Security: max-age=63072000; includeSubdomains;
X-Frame-Options: SAMEORIGIN
Content-Length: 234
Keep-Alive: timeout=5, max=96
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

--5b210061-E--

--5b210061-H--
Message: Rule 56290b2ef638 [id "973347"][file "/etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_41_xss_attacks.conf"][line "504"] - Execution error - PCRE limits exceeded (-8): (null).
Message: Access denied with code 403 (phase 2). Match of "streq 0" against "TX:MSC_PCRE_LIMITS_EXCEEDED" required. [file "/etc/httpd/conf.d/mod_security.conf"] [line "40"] [id "200004"] [msg "ModSecurity internal error flagged: TX:MSC_PCRE_LIMITS_EXCEEDED"]
Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client 51.148.60.129] ModSecurity: Rule 56290b2ef638 [id "973347"][file "/etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_41_xss_attacks.conf"][line "504"] - Execution error - PCRE limits exceeded (-8): (null). [hostname "web.internet.info"] [uri "/webclient/secure/strategies/edit"] [unique_id "XnSx3xYuJtXNqpDeWlecIwAAABA"]
Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client 51.148.60.129] ModSecurity: Access denied with code 403 (phase 2). Match of "streq 0" against "TX:MSC_PCRE_LIMITS_EXCEEDED" required. [file "/etc/httpd/conf.d/mod_security.conf"] [line "40"] [id "200004"] [msg "ModSecurity internal error flagged: TX:MSC_PCRE_LIMITS_EXCEEDED"] [hostname "web.internet.info"] [uri "/webclient/secure/strategies/edit"] [unique_id "XnSx3xYuJtXNqpDeWlecIwAAABA"]
Action: Intercepted (phase 2)
Apache-Handler: proxy-server
Stopwatch: 1584706015759030 619818 (- - -)
Stopwatch2: 1584706015759030 619818; combined=618588, p1=260, p2=618291, p3=0, p4=0, p5=37, sr=108, sw=0, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.9.2 (http://www.modsecurity.org/); OWASP_CRS/2.2.9.
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips
Engine-Mode: "ENABLED"

--5b210061-Z--


Thanks for any help.

Joe.

Re: [mod-security-users] https://www.modsecurity.org/ TLS 1.0

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

Am 13.03.20 um 14:18 schrieb Dan Ehrlich via mod-security-users:
> Agreed more stupid people in US.
> 
> But also didn't China like murder upwards of 1 million Uyghurs over the
> last 12 months + harvest their organs while alive in Xinjiang?
> 
> Supposedly they used ECMO machines to harvest them. It's a device which
> keeps you alive and partially frozen while they take all of your organs...
> 
> Lol it's like the new Holocaust 

can we keep a technical list technical and place political bullshit
somewehre else?

Re: [mod-security-users] https://www.modsecurity.org/ TLS 1.0

[Dan E. <da...@eh...>]

Agreed more stupid people in US.

But also didn't China like murder upwards of 1 million Uyghurs over the
last 12 months + harvest their organs while alive in Xinjiang?

Supposedly they used ECMO machines to harvest them. It's a device which
keeps you alive and partially frozen while they take all of your organs...

Lol it's like the new Holocaust




On Fri, Mar 13, 2020 at 8:13 AM Reindl Harald <h.r...@th...>
wrote:

>
>
> Am 13.03.20 um 13:36 schrieb Dan Ehrlich via mod-security-users:
> > It's probably a Chinese front company and they did it on purpose
>
> stop this china bullshit when it's proven that the biggest idiots are
> located in the united states, not only in this but also in this case
>
> https://www.trustwave.com/en-us/
> "Cybersecurity and Managed Security Services | Trustwave" - *loool*
>
> Name:   modsecurity.org
> Address: 204.13.200.240
>
> NetRange:       204.13.200.0 - 204.13.203.255
> CIDR:           204.13.200.0/22
> NetName:        NET-204-13-200-0-1
> NetHandle:      NET-204-13-200-0-1
> Parent:         NET204 (NET-204-0-0-0-0)
> NetType:        Direct Assignment
> OriginAS:       AS33151
> Organization:   Trustwave Holdings, Inc. (TRUST-7)
>
> > On Fri, Mar 13, 2020 at 6:24 AM Reindl Harald <h.r...@th...
> > <mailto:h.r...@th...>> wrote:
> >
> >
> >
> >     Am 13.03.20 um 03:13 schrieb Reindl Harald:
> >     > Am 12.03.20 um 22:57 schrieb az...@po... <mailto:
> az...@po...>:
> >     >> Citát Reindl Harald <h.r...@th...
> >     <mailto:h.r...@th...>>:
> >     >>
> >     >>> Am 12.03.20 um 17:57 schrieb Reindl Harald:
> >     >>>> https://www.modsecurity.org/
> >     >>>>
> >     >>>> seriously?
> >     >>>>
> >     >>>> it's not a breaking news that firefox and other browsers are
> >     planning
> >     >>>> disable TLS1.0/1.1 for many months
> >     >>>
> >     >>> https://i.imgur.com/wC4IJbs.png shows the by far the dumbest
> >     webserver
> >     >>> setup i have faced in the past 15 years
> >     >>>
> >     >>> The server supports only older protocols, but not the current
> >     best TLS
> >     >>> 1.2. Grade capped to C.
> >     >>>
> >     >>> This server accepts RC4 cipher, but only with older protocols.
> Grade
> >     >>> capped to B.
> >     >>>
> >     >>> This server does not support Forward Secrecy with the reference
> >     >>> browsers. Grade capped to B.
> >     >>>
> >     >>> This server does not support Authenticated encryption (AEAD)
> cipher
> >     >>> suites. Grade capped to B.
> >     >>>
> >     >>> This server supports TLS 1.0. Grade capped to B.
> >     >>>
> >     >>> ------------------------
> >     >>>
> >     >>> and yes *i know* that we are *currently* Grade B because
> >     *allowing* TLS
> >     >>> < 1.2 for now for a short time to redirect support calls of
> >     endusers as
> >     >>> dumb as your webadmins to somewhere else
> >     >>
> >     >>
> >     >> Hi guys,
> >     >>
> >     >> i can setup it for you, contact me if you are interested, i have
> >     almost
> >     >> 20 years of experiences with linux administration focusing on
> >     security.
> >     >
> >     > a trained monkey can setup whatever webserver supporting TLS 1.2
> >     and the
> >     > main question is what nonsense one needs to to for such a result
> >     with no
> >     > TLS 1.2 and no ECDHE
> >     >
> >     > https://www.trustwave.com/en-us/
> >     > "Cybersecurity and Managed Security Services | Trustwave" - *loool*
> >     >
> >     > Name:   modsecurity.org <http://modsecurity.org>
> >     > Address: 204.13.200.240
> >     >
> >     > NetRange:       204.13.200.0 - 204.13.203.255
> >     > CIDR:           204.13.200.0/22 <http://204.13.200.0/22>
> >     > NetName:        NET-204-13-200-0-1
> >     > NetHandle:      NET-204-13-200-0-1
> >     > Parent:         NET204 (NET-204-0-0-0-0)
> >     > NetType:        Direct Assignment
> >     > OriginAS:       AS33151
> >     > Organization:   Trustwave Holdings, Inc. (TRUST-7)
> >     > RegDate:        2005-05-04
> >     > Updated:        2012-02-24
> >     > Ref:            https://rdap.arin.net/registry/ip/204.13.200.0
> >
> >     besides that it's a shame that Trustwave don't run automated security
> >     audits nor is able to respond here and it's hard to take a secruity
> >     company serious acting that incompetent
> >
> >     let me guess: the funny clown who modified the "Server" headerand
> nobody
> >     cas a clue what that guy all changed and why....
> >
> >     [harry@srv-rhsoft:~]$ curl --head https://www.modsecurity.org/
> >     HTTP/1.1 200 OK
> >     Date: Fri, 13 Mar 2020 11:20:13 GMT
> >     Server: What-Chu-Talkin'-Bout-Willis?/Arnold Drummondv.1.0
> >     Accept-Ranges: bytes
> >     Content-Length: 5605
> >     Connection: close
> >     Content-Type: text/html; charset=ISO-8859-1
>
>
> _______________________________________________
> 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] https://www.modsecurity.org/ TLS 1.0

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

Am 13.03.20 um 13:36 schrieb Dan Ehrlich via mod-security-users:
> It's probably a Chinese front company and they did it on purpose

stop this china bullshit when it's proven that the biggest idiots are
located in the united states, not only in this but also in this case

https://www.trustwave.com/en-us/
"Cybersecurity and Managed Security Services | Trustwave" - *loool*

Name:   modsecurity.org
Address: 204.13.200.240

NetRange:       204.13.200.0 - 204.13.203.255
CIDR:           204.13.200.0/22
NetName:        NET-204-13-200-0-1
NetHandle:      NET-204-13-200-0-1
Parent:         NET204 (NET-204-0-0-0-0)
NetType:        Direct Assignment
OriginAS:       AS33151
Organization:   Trustwave Holdings, Inc. (TRUST-7)

> On Fri, Mar 13, 2020 at 6:24 AM Reindl Harald <h.r...@th...
> <mailto:h.r...@th...>> wrote:
> 
> 
> 
>     Am 13.03.20 um 03:13 schrieb Reindl Harald:
>     > Am 12.03.20 um 22:57 schrieb az...@po... <mailto:az...@po...>:
>     >> Citát Reindl Harald <h.r...@th...
>     <mailto:h.r...@th...>>:
>     >>
>     >>> Am 12.03.20 um 17:57 schrieb Reindl Harald:
>     >>>> https://www.modsecurity.org/
>     >>>>
>     >>>> seriously?
>     >>>>
>     >>>> it's not a breaking news that firefox and other browsers are
>     planning
>     >>>> disable TLS1.0/1.1 for many months
>     >>>
>     >>> https://i.imgur.com/wC4IJbs.png shows the by far the dumbest
>     webserver
>     >>> setup i have faced in the past 15 years
>     >>>
>     >>> The server supports only older protocols, but not the current
>     best TLS
>     >>> 1.2. Grade capped to C.
>     >>>
>     >>> This server accepts RC4 cipher, but only with older protocols. Grade
>     >>> capped to B.
>     >>>
>     >>> This server does not support Forward Secrecy with the reference
>     >>> browsers. Grade capped to B.
>     >>>
>     >>> This server does not support Authenticated encryption (AEAD) cipher
>     >>> suites. Grade capped to B.
>     >>>
>     >>> This server supports TLS 1.0. Grade capped to B.
>     >>>
>     >>> ------------------------
>     >>>
>     >>> and yes *i know* that we are *currently* Grade B because
>     *allowing* TLS
>     >>> < 1.2 for now for a short time to redirect support calls of
>     endusers as
>     >>> dumb as your webadmins to somewhere else
>     >>
>     >>
>     >> Hi guys,
>     >>
>     >> i can setup it for you, contact me if you are interested, i have
>     almost
>     >> 20 years of experiences with linux administration focusing on
>     security.
>     >
>     > a trained monkey can setup whatever webserver supporting TLS 1.2
>     and the
>     > main question is what nonsense one needs to to for such a result
>     with no
>     > TLS 1.2 and no ECDHE
>     >
>     > https://www.trustwave.com/en-us/
>     > "Cybersecurity and Managed Security Services | Trustwave" - *loool*
>     >
>     > Name:   modsecurity.org <http://modsecurity.org>
>     > Address: 204.13.200.240
>     >
>     > NetRange:       204.13.200.0 - 204.13.203.255
>     > CIDR:           204.13.200.0/22 <http://204.13.200.0/22>
>     > NetName:        NET-204-13-200-0-1
>     > NetHandle:      NET-204-13-200-0-1
>     > Parent:         NET204 (NET-204-0-0-0-0)
>     > NetType:        Direct Assignment
>     > OriginAS:       AS33151
>     > Organization:   Trustwave Holdings, Inc. (TRUST-7)
>     > RegDate:        2005-05-04
>     > Updated:        2012-02-24
>     > Ref:            https://rdap.arin.net/registry/ip/204.13.200.0
> 
>     besides that it's a shame that Trustwave don't run automated security
>     audits nor is able to respond here and it's hard to take a secruity
>     company serious acting that incompetent
> 
>     let me guess: the funny clown who modified the "Server" headerand nobody
>     cas a clue what that guy all changed and why....
> 
>     [harry@srv-rhsoft:~]$ curl --head https://www.modsecurity.org/
>     HTTP/1.1 200 OK
>     Date: Fri, 13 Mar 2020 11:20:13 GMT
>     Server: What-Chu-Talkin'-Bout-Willis?/Arnold Drummondv.1.0
>     Accept-Ranges: bytes
>     Content-Length: 5605
>     Connection: close
>     Content-Type: text/html; charset=ISO-8859-1

Re: [mod-security-users] https://www.modsecurity.org/ TLS 1.0

[Dan E. <da...@eh...>]

It's probably a Chinese front company and they did it on purpose.



On Fri, Mar 13, 2020 at 6:24 AM Reindl Harald <h.r...@th...>
wrote:

>
>
> Am 13.03.20 um 03:13 schrieb Reindl Harald:
> > Am 12.03.20 um 22:57 schrieb az...@po...:
> >> Citát Reindl Harald <h.r...@th...>:
> >>
> >>> Am 12.03.20 um 17:57 schrieb Reindl Harald:
> >>>> https://www.modsecurity.org/
> >>>>
> >>>> seriously?
> >>>>
> >>>> it's not a breaking news that firefox and other browsers are planning
> >>>> disable TLS1.0/1.1 for many months
> >>>
> >>> https://i.imgur.com/wC4IJbs.png shows the by far the dumbest webserver
> >>> setup i have faced in the past 15 years
> >>>
> >>> The server supports only older protocols, but not the current best TLS
> >>> 1.2. Grade capped to C.
> >>>
> >>> This server accepts RC4 cipher, but only with older protocols. Grade
> >>> capped to B.
> >>>
> >>> This server does not support Forward Secrecy with the reference
> >>> browsers. Grade capped to B.
> >>>
> >>> This server does not support Authenticated encryption (AEAD) cipher
> >>> suites. Grade capped to B.
> >>>
> >>> This server supports TLS 1.0. Grade capped to B.
> >>>
> >>> ------------------------
> >>>
> >>> and yes *i know* that we are *currently* Grade B because *allowing* TLS
> >>> < 1.2 for now for a short time to redirect support calls of endusers as
> >>> dumb as your webadmins to somewhere else
> >>
> >>
> >> Hi guys,
> >>
> >> i can setup it for you, contact me if you are interested, i have almost
> >> 20 years of experiences with linux administration focusing on security.
> >
> > a trained monkey can setup whatever webserver supporting TLS 1.2 and the
> > main question is what nonsense one needs to to for such a result with no
> > TLS 1.2 and no ECDHE
> >
> > https://www.trustwave.com/en-us/
> > "Cybersecurity and Managed Security Services | Trustwave" - *loool*
> >
> > Name:   modsecurity.org
> > Address: 204.13.200.240
> >
> > NetRange:       204.13.200.0 - 204.13.203.255
> > CIDR:           204.13.200.0/22
> > NetName:        NET-204-13-200-0-1
> > NetHandle:      NET-204-13-200-0-1
> > Parent:         NET204 (NET-204-0-0-0-0)
> > NetType:        Direct Assignment
> > OriginAS:       AS33151
> > Organization:   Trustwave Holdings, Inc. (TRUST-7)
> > RegDate:        2005-05-04
> > Updated:        2012-02-24
> > Ref:            https://rdap.arin.net/registry/ip/204.13.200.0
>
> besides that it's a shame that Trustwave don't run automated security
> audits nor is able to respond here and it's hard to take a secruity
> company serious acting that incompetent
>
> let me guess: the funny clown who modified the "Server" headerand nobody
> cas a clue what that guy all changed and why....
>
> [harry@srv-rhsoft:~]$ curl --head https://www.modsecurity.org/
> HTTP/1.1 200 OK
> Date: Fri, 13 Mar 2020 11:20:13 GMT
> Server: What-Chu-Talkin'-Bout-Willis?/Arnold Drummondv.1.0
> Accept-Ranges: bytes
> Content-Length: 5605
> Connection: close
> Content-Type: text/html; charset=ISO-8859-1
>
>
> _______________________________________________
> 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] https://www.modsecurity.org/ TLS 1.0

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

Am 13.03.20 um 03:13 schrieb Reindl Harald:
> Am 12.03.20 um 22:57 schrieb az...@po...:
>> Citát Reindl Harald <h.r...@th...>:
>>
>>> Am 12.03.20 um 17:57 schrieb Reindl Harald:
>>>> https://www.modsecurity.org/
>>>>
>>>> seriously?
>>>>
>>>> it's not a breaking news that firefox and other browsers are planning
>>>> disable TLS1.0/1.1 for many months
>>>
>>> https://i.imgur.com/wC4IJbs.png shows the by far the dumbest webserver
>>> setup i have faced in the past 15 years
>>>
>>> The server supports only older protocols, but not the current best TLS
>>> 1.2. Grade capped to C.
>>>
>>> This server accepts RC4 cipher, but only with older protocols. Grade
>>> capped to B.
>>>
>>> This server does not support Forward Secrecy with the reference
>>> browsers. Grade capped to B.
>>>
>>> This server does not support Authenticated encryption (AEAD) cipher
>>> suites. Grade capped to B.
>>>
>>> This server supports TLS 1.0. Grade capped to B.
>>>
>>> ------------------------
>>>
>>> and yes *i know* that we are *currently* Grade B because *allowing* TLS
>>> < 1.2 for now for a short time to redirect support calls of endusers as
>>> dumb as your webadmins to somewhere else
>>
>>
>> Hi guys,
>>
>> i can setup it for you, contact me if you are interested, i have almost
>> 20 years of experiences with linux administration focusing on security.
> 
> a trained monkey can setup whatever webserver supporting TLS 1.2 and the
> main question is what nonsense one needs to to for such a result with no
> TLS 1.2 and no ECDHE
> 
> https://www.trustwave.com/en-us/
> "Cybersecurity and Managed Security Services | Trustwave" - *loool*
> 
> Name:   modsecurity.org
> Address: 204.13.200.240
> 
> NetRange:       204.13.200.0 - 204.13.203.255
> CIDR:           204.13.200.0/22
> NetName:        NET-204-13-200-0-1
> NetHandle:      NET-204-13-200-0-1
> Parent:         NET204 (NET-204-0-0-0-0)
> NetType:        Direct Assignment
> OriginAS:       AS33151
> Organization:   Trustwave Holdings, Inc. (TRUST-7)
> RegDate:        2005-05-04
> Updated:        2012-02-24
> Ref:            https://rdap.arin.net/registry/ip/204.13.200.0

besides that it's a shame that Trustwave don't run automated security
audits nor is able to respond here and it's hard to take a secruity
company serious acting that incompetent

let me guess: the funny clown who modified the "Server" headerand nobody
cas a clue what that guy all changed and why....

[harry@srv-rhsoft:~]$ curl --head https://www.modsecurity.org/
HTTP/1.1 200 OK
Date: Fri, 13 Mar 2020 11:20:13 GMT
Server: What-Chu-Talkin'-Bout-Willis?/Arnold Drummondv.1.0
Accept-Ranges: bytes
Content-Length: 5605
Connection: close
Content-Type: text/html; charset=ISO-8859-1

Re: [mod-security-users] https://www.modsecurity.org/ TLS 1.0

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

Am 12.03.20 um 22:57 schrieb az...@po...:
> Citát Reindl Harald <h.r...@th...>:
> 
>> Am 12.03.20 um 17:57 schrieb Reindl Harald:
>>> https://www.modsecurity.org/
>>>
>>> seriously?
>>>
>>> it's not a breaking news that firefox and other browsers are planning
>>> disable TLS1.0/1.1 for many months
>>
>> https://i.imgur.com/wC4IJbs.png shows the by far the dumbest webserver
>> setup i have faced in the past 15 years
>>
>> The server supports only older protocols, but not the current best TLS
>> 1.2. Grade capped to C.
>>
>> This server accepts RC4 cipher, but only with older protocols. Grade
>> capped to B.
>>
>> This server does not support Forward Secrecy with the reference
>> browsers. Grade capped to B.
>>
>> This server does not support Authenticated encryption (AEAD) cipher
>> suites. Grade capped to B.
>>
>> This server supports TLS 1.0. Grade capped to B.
>>
>> ------------------------
>>
>> and yes *i know* that we are *currently* Grade B because *allowing* TLS
>> < 1.2 for now for a short time to redirect support calls of endusers as
>> dumb as your webadmins to somewhere else
> 
> 
> Hi guys,
> 
> i can setup it for you, contact me if you are interested, i have almost
> 20 years of experiences with linux administration focusing on security.

a trained monkey can setup whatever webserver supporting TLS 1.2 and the
main question is what nonsense one needs to to for such a result with no
TLS 1.2 and no ECDHE

https://www.trustwave.com/en-us/
"Cybersecurity and Managed Security Services | Trustwave" - *loool*

Name:   modsecurity.org
Address: 204.13.200.240

NetRange:       204.13.200.0 - 204.13.203.255
CIDR:           204.13.200.0/22
NetName:        NET-204-13-200-0-1
NetHandle:      NET-204-13-200-0-1
Parent:         NET204 (NET-204-0-0-0-0)
NetType:        Direct Assignment
OriginAS:       AS33151
Organization:   Trustwave Holdings, Inc. (TRUST-7)
RegDate:        2005-05-04
Updated:        2012-02-24
Ref:            https://rdap.arin.net/registry/ip/204.13.200.0

Re: [mod-security-users] https://www.modsecurity.org/ TLS 1.0

[<az...@po...>]

Citát Reindl Harald <h.r...@th...>:

> Am 12.03.20 um 17:57 schrieb Reindl Harald:
>> https://www.modsecurity.org/
>>
>> seriously?
>>
>> it's not a breaking news that firefox and other browsers are planning
>> disable TLS1.0/1.1 for many months
>
> https://i.imgur.com/wC4IJbs.png shows the by far the dumbest webserver
> setup i have faced in the past 15 years
>
> The server supports only older protocols, but not the current best TLS
> 1.2. Grade capped to C.
>
> This server accepts RC4 cipher, but only with older protocols. Grade
> capped to B.
>
> This server does not support Forward Secrecy with the reference
> browsers. Grade capped to B.
>
> This server does not support Authenticated encryption (AEAD) cipher
> suites. Grade capped to B.
>
> This server supports TLS 1.0. Grade capped to B.
>
> ------------------------
>
> and yes *i know* that we are *currently* Grade B because *allowing* TLS
> < 1.2 for now for a short time to redirect support calls of endusers as
> dumb as your webadmins to somewhere else


Hi guys,

i can setup it for you, contact me if you are interested, i have  
almost 20 years of experiences with linux administration focusing on  
security.

azur

Re: [mod-security-users] https://www.modsecurity.org/ TLS 1.0

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

Am 12.03.20 um 17:57 schrieb Reindl Harald:
> https://www.modsecurity.org/
> 
> seriously?
> 
> it's not a breaking news that firefox and other browsers are planning
> disable TLS1.0/1.1 for many months

https://i.imgur.com/wC4IJbs.png shows the by far the dumbest webserver
setup i have faced in the past 15 years

The server supports only older protocols, but not the current best TLS
1.2. Grade capped to C.

This server accepts RC4 cipher, but only with older protocols. Grade
capped to B.

This server does not support Forward Secrecy with the reference
browsers. Grade capped to B.

This server does not support Authenticated encryption (AEAD) cipher
suites. Grade capped to B.

This server supports TLS 1.0. Grade capped to B.

------------------------

and yes *i know* that we are *currently* Grade B because *allowing* TLS
< 1.2 for now for a short time to redirect support calls of endusers as
dumb as your webadmins to somewhere else

[mod-security-users] https://www.modsecurity.org/ TLS 1.0

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

https://www.modsecurity.org/

seriously?

it's not a breaking news that firefox and other browsers are planning
disable TLS1.0/1.1 for many months

Re: [mod-security-users] mod-security errors

[Paul B. <pau...@ou...>]

Manuel,
Thanks for your reply. Sorry I was a bit unclear in my first message, my concern isn't about how to write a whitelisting rule (I'm currently in the process of tuning the rules to avoid false positives), but rather Apache/ModSec seems to be throwing an error (related to apache2_util.c):
"[-:error]" in error log
"Apache-Error: [file "apache2_util.c"] [line 271] [level 3]" in audit log
this differs from the normal modsecurity entries I see when a rule matches.

Thanks,
Paul
________________________________
From: Manuel Spartan <spa...@gm...>
Sent: 27 February 2020 20:37
To: mod...@li... <mod...@li...>
Subject: Re: [mod-security-users] mod-security errors

Hi Paul, you have an argument that looks suspicious add a whitelist for the argument “query”
Cheers!
Sent from my iPhone

On Feb 27, 2020, at 7:41 AM, Paul Beckett <pau...@ou...> wrote:


I'm currently trying to update a web application firewall on a reverse-proxy.

It's running:
RHEL6
Apache 2.4.41 (built from source)
Mod-Security 2.9.3 (built from source)
Mod-Security CRS 3.2

I'm currently encountering an issue, which despite spending a while googling, have failed to understand/find a solution.

I'm seeing errors being thrown, attributed to apache2_util.c , line 271 (this can happen multiple times for same request, with multiple rule IDs in error output.

I've had to redact <IP>, <port>, <hostname.domain>, <dir> in the entries from my logs below.

In my error log:
[2020-02-27 12:55:58.354429] [-:error] <IP.IP.IP.IP>:<PORT> Xle8Xm1W8IE8Ef-M70HyFAAAAQA [client <IP.IP.IP.IP>] ModSecurity: Warning. Pattern match "(?i:(?:(?:(?:(?:trunc|cre|upd)at|renam)e|(?:inser|selec)t|de(?:lete|sc)|alter|load)\\\\s*?\\\\(\\\\s*?space\\\\s*?\\\\(|,.*?[)\\\\da-f\\"'`][\\"'`](?:[\\"'`].*?[\\"'`]|(?:\\\\r?\\\\n)?\\\\z|[^\\"'`]+)|\\\\Wselect.+\\\\W*?from))" at ARGS_NAMES:{"query":"query CacheChangeStream(\\\\n  $resumptionToken: String\\\\n) {\\\\n  cacheChangeStream(resumptionToken: $resumptionToken) {\\\\n    nextResumptionToken\\\\n    __invalidatedCacheDomains: invalidatedCacheDomains {\\\\n      __typename\\\\n      ... on ContentFamilyCacheDomainInvalidation {\\\\n        systemName\\\\n        invalidationId\\\\n        name\\\\n      }\\\\n    }\\\\n  }\\\\n}\\\\n","variables":{"resumptionToken":"236210"}}. [file "/usr/local/apache/conf/modsecurity-crs3/70_rules-crs/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "736"] [id "942200"] [msg "Detects MySQL comment-/space-obfuscated injections and backtick termination"] [data "Matched Data: ,\\x22variables\\x22:{\\x22resumptionToken\\x22:\\x22236210\\x22}} found within ARGS_NAMES:{\\x22query\\x22:\\x22query CacheChangeStre [hostname "<hostname.domain>"] [uri "/admin/<dir>/<dir>/"] [unique_id "Xle8Xm1W8IE8Ef-M70HyFAAAAQA"]

This seems to correspond with an audit log entry:
Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client 1<IP.IP.IP.IP>] ModSecurity: Warning. Pattern match "(?i:(?:(?:(?:(?:trunc|cre|upd)at|renam)e|(?:inser|selec)t|de(?:lete|sc)|alter|load)\\\\\\\\s*?\\\\\\\\(\\\\\\\\s*?space\\\\\\\\s*?\\\\\\\\(|,.*?[)\\\\\\\\da-f\\\\"'`][\\\\"'`](?:[\\\\"'`].*?[\\\\"'`]|(?:\\\\\\\\r?\\\\\\\\n)?\\\\\\\\z|[^\\\\"'`]+)|\\\\\\\\Wselect.+\\\\\\\\W*?from))" at ARGS_NAMES:{"query":"query CacheChangeStream(\\\\\\\\n  $resumptionToken: String\\\\\\\\n) {\\\\\\\\n  cacheChangeStream(resumptionToken: $resumptionToken) {\\\\\\\\n    nextResumptionToken\\\\\\\\n    __invalidatedCacheDomains: invalidatedCacheDomains {\\\\\\\\n      __typename\\\\\\\\n      ... on ContentFamilyCacheDomainInvalidation {\\\\\\\\n        systemName\\\\\\\\n        invalidationId\\\\\\\\n        name\\\\\\\\n      }\\\\\\\\n    }\\\\\\\\n  }\\\\\\\\n}\\\\\\\\n","variables":{"resumptionToken":"236210"}}. [file "/usr/local/apache/conf/modsecurity-crs3/70_rules-crs/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "736"] [id "942200"] [msg "Detects MySQL comment-/space-obfuscated injections and backtick termination"] [data "Matched Data: ,\\\\x22variables\\\\x22:{\\\\x22resumptionToken\\\\x22:\\\\x22236210\\\\x22}} found within ARGS_NAMES:{\\\\x22query\\\\x22:\\\\x22query CacheChangeStre [hostname "<hostname.domain>"] [uri "/admin/<dir>/<dir>/"] [unique_id "Xle8Xm1W8IE8Ef-M70HyFAAAAQA"]


Any insights/suggestions would be appreciated.
Thanks,
Paul
_______________________________________________
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] mod-security errors

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

Hi Paul, you have an argument that looks suspicious add a whitelist for the argument “query”
Cheers!
Sent from my iPhone

> On Feb 27, 2020, at 7:41 AM, Paul Beckett <pau...@ou...> wrote:
> 
> 
> I'm currently trying to update a web application firewall on a reverse-proxy.
> 
> It's running:
> RHEL6
> Apache 2.4.41 (built from source)
> Mod-Security 2.9.3 (built from source)
> Mod-Security CRS 3.2
> 
> I'm currently encountering an issue, which despite spending a while googling, have failed to understand/find a solution. 
> 
> I'm seeing errors being thrown, attributed to apache2_util.c , line 271 (this can happen multiple times for same request, with multiple rule IDs in error output.
> 
> I've had to redact <IP>, <port>, <hostname.domain>, <dir> in the entries from my logs below. 
> 
> In my error log:
> [2020-02-27 12:55:58.354429] [-:error] <IP.IP.IP.IP>:<PORT> Xle8Xm1W8IE8Ef-M70HyFAAAAQA [client <IP.IP.IP.IP>] ModSecurity: Warning. Pattern match "(?i:(?:(?:(?:(?:trunc|cre|upd)at|renam)e|(?:inser|selec)t|de(?:lete|sc)|alter|load)\\\\s*?\\\\(\\\\s*?space\\\\s*?\\\\(|,.*?[)\\\\da-f\\"'`][\\"'`](?:[\\"'`].*?[\\"'`]|(?:\\\\r?\\\\n)?\\\\z|[^\\"'`]+)|\\\\Wselect.+\\\\W*?from))" at ARGS_NAMES:{"query":"query CacheChangeStream(\\\\n  $resumptionToken: String\\\\n) {\\\\n  cacheChangeStream(resumptionToken: $resumptionToken) {\\\\n    nextResumptionToken\\\\n    __invalidatedCacheDomains: invalidatedCacheDomains {\\\\n      __typename\\\\n      ... on ContentFamilyCacheDomainInvalidation {\\\\n        systemName\\\\n        invalidationId\\\\n        name\\\\n      }\\\\n    }\\\\n  }\\\\n}\\\\n","variables":{"resumptionToken":"236210"}}. [file "/usr/local/apache/conf/modsecurity-crs3/70_rules-crs/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "736"] [id "942200"] [msg "Detects MySQL comment-/space-obfuscated injections and backtick termination"] [data "Matched Data: ,\\x22variables\\x22:{\\x22resumptionToken\\x22:\\x22236210\\x22}} found within ARGS_NAMES:{\\x22query\\x22:\\x22query CacheChangeStre [hostname "<hostname.domain>"] [uri "/admin/<dir>/<dir>/"] [unique_id "Xle8Xm1W8IE8Ef-M70HyFAAAAQA"]
> 
> This seems to correspond with an audit log entry:
> Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client 1<IP.IP.IP.IP>] ModSecurity: Warning. Pattern match "(?i:(?:(?:(?:(?:trunc|cre|upd)at|renam)e|(?:inser|selec)t|de(?:lete|sc)|alter|load)\\\\\\\\s*?\\\\\\\\(\\\\\\\\s*?space\\\\\\\\s*?\\\\\\\\(|,.*?[)\\\\\\\\da-f\\\\"'`][\\\\"'`](?:[\\\\"'`].*?[\\\\"'`]|(?:\\\\\\\\r?\\\\\\\\n)?\\\\\\\\z|[^\\\\"'`]+)|\\\\\\\\Wselect.+\\\\\\\\W*?from))" at ARGS_NAMES:{"query":"query CacheChangeStream(\\\\\\\\n  $resumptionToken: String\\\\\\\\n) {\\\\\\\\n  cacheChangeStream(resumptionToken: $resumptionToken) {\\\\\\\\n    nextResumptionToken\\\\\\\\n    __invalidatedCacheDomains: invalidatedCacheDomains {\\\\\\\\n      __typename\\\\\\\\n      ... on ContentFamilyCacheDomainInvalidation {\\\\\\\\n        systemName\\\\\\\\n        invalidationId\\\\\\\\n        name\\\\\\\\n      }\\\\\\\\n    }\\\\\\\\n  }\\\\\\\\n}\\\\\\\\n","variables":{"resumptionToken":"236210"}}. [file "/usr/local/apache/conf/modsecurity-crs3/70_rules-crs/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "736"] [id "942200"] [msg "Detects MySQL comment-/space-obfuscated injections and backtick termination"] [data "Matched Data: ,\\\\x22variables\\\\x22:{\\\\x22resumptionToken\\\\x22:\\\\x22236210\\\\x22}} found within ARGS_NAMES:{\\\\x22query\\\\x22:\\\\x22query CacheChangeStre [hostname "<hostname.domain>"] [uri "/admin/<dir>/<dir>/"] [unique_id "Xle8Xm1W8IE8Ef-M70HyFAAAAQA"]
> 
> 
> Any insights/suggestions would be appreciated.
> Thanks,
> Paul
> _______________________________________________
> 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-security errors

[Paul B. <pau...@ou...>]

I'm currently trying to update a web application firewall on a reverse-proxy.

It's running:
RHEL6
Apache 2.4.41 (built from source)
Mod-Security 2.9.3 (built from source)
Mod-Security CRS 3.2

I'm currently encountering an issue, which despite spending a while googling, have failed to understand/find a solution.

I'm seeing errors being thrown, attributed to apache2_util.c , line 271 (this can happen multiple times for same request, with multiple rule IDs in error output.

I've had to redact <IP>, <port>, <hostname.domain>, <dir> in the entries from my logs below.

In my error log:
[2020-02-27 12:55:58.354429] [-:error] <IP.IP.IP.IP>:<PORT> Xle8Xm1W8IE8Ef-M70HyFAAAAQA [client <IP.IP.IP.IP>] ModSecurity: Warning. Pattern match "(?i:(?:(?:(?:(?:trunc|cre|upd)at|renam)e|(?:inser|selec)t|de(?:lete|sc)|alter|load)\\\\s*?\\\\(\\\\s*?space\\\\s*?\\\\(|,.*?[)\\\\da-f\\"'`][\\"'`](?:[\\"'`].*?[\\"'`]|(?:\\\\r?\\\\n)?\\\\z|[^\\"'`]+)|\\\\Wselect.+\\\\W*?from))" at ARGS_NAMES:{"query":"query CacheChangeStream(\\\\n  $resumptionToken: String\\\\n) {\\\\n  cacheChangeStream(resumptionToken: $resumptionToken) {\\\\n    nextResumptionToken\\\\n    __invalidatedCacheDomains: invalidatedCacheDomains {\\\\n      __typename\\\\n      ... on ContentFamilyCacheDomainInvalidation {\\\\n        systemName\\\\n        invalidationId\\\\n        name\\\\n      }\\\\n    }\\\\n  }\\\\n}\\\\n","variables":{"resumptionToken":"236210"}}. [file "/usr/local/apache/conf/modsecurity-crs3/70_rules-crs/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "736"] [id "942200"] [msg "Detects MySQL comment-/space-obfuscated injections and backtick termination"] [data "Matched Data: ,\\x22variables\\x22:{\\x22resumptionToken\\x22:\\x22236210\\x22}} found within ARGS_NAMES:{\\x22query\\x22:\\x22query CacheChangeStre [hostname "<hostname.domain>"] [uri "/admin/<dir>/<dir>/"] [unique_id "Xle8Xm1W8IE8Ef-M70HyFAAAAQA"]

This seems to correspond with an audit log entry:
Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client 1<IP.IP.IP.IP>] ModSecurity: Warning. Pattern match "(?i:(?:(?:(?:(?:trunc|cre|upd)at|renam)e|(?:inser|selec)t|de(?:lete|sc)|alter|load)\\\\\\\\s*?\\\\\\\\(\\\\\\\\s*?space\\\\\\\\s*?\\\\\\\\(|,.*?[)\\\\\\\\da-f\\\\"'`][\\\\"'`](?:[\\\\"'`].*?[\\\\"'`]|(?:\\\\\\\\r?\\\\\\\\n)?\\\\\\\\z|[^\\\\"'`]+)|\\\\\\\\Wselect.+\\\\\\\\W*?from))" at ARGS_NAMES:{"query":"query CacheChangeStream(\\\\\\\\n  $resumptionToken: String\\\\\\\\n) {\\\\\\\\n  cacheChangeStream(resumptionToken: $resumptionToken) {\\\\\\\\n    nextResumptionToken\\\\\\\\n    __invalidatedCacheDomains: invalidatedCacheDomains {\\\\\\\\n      __typename\\\\\\\\n      ... on ContentFamilyCacheDomainInvalidation {\\\\\\\\n        systemName\\\\\\\\n        invalidationId\\\\\\\\n        name\\\\\\\\n      }\\\\\\\\n    }\\\\\\\\n  }\\\\\\\\n}\\\\\\\\n","variables":{"resumptionToken":"236210"}}. [file "/usr/local/apache/conf/modsecurity-crs3/70_rules-crs/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "736"] [id "942200"] [msg "Detects MySQL comment-/space-obfuscated injections and backtick termination"] [data "Matched Data: ,\\\\x22variables\\\\x22:{\\\\x22resumptionToken\\\\x22:\\\\x22236210\\\\x22}} found within ARGS_NAMES:{\\\\x22query\\\\x22:\\\\x22query CacheChangeStre [hostname "<hostname.domain>"] [uri "/admin/<dir>/<dir>/"] [unique_id "Xle8Xm1W8IE8Ef-M70HyFAAAAQA"]


Any insights/suggestions would be appreciated.
Thanks,
Paul

Re: [mod-security-users] Modsecurity Nginx: Audit log not being populated

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

Sorry the delay, thanks 😊 this worked!

Cheers!
Chris.

> El 12-02-2020, a la(s) 10:00, Christian Folini <chr...@ne...> escribió:
> 
> Actually, the problem has been reported before. There is working fix that is
> making it's way into the master src code tree as we speak.
> 
> https://github.com/SpiderLabs/ModSecurity-nginx/issues/170
> 
> 
>> On Wed, Feb 12, 2020 at 10:50:38AM +0100, Christian Folini wrote:
>> Hey guys,
>> 
>> the configuration looks correct. Normally the file permissions can pose
>> a problem. However, the fact that DetectionOnly makes it functional points to
>> a ModSec bug, which you may want to report on github.
>> 
>> The ModSec devs are hardly active on this ML, but they are usually quick to
>> react on github issues.
>> 
>> Please keep us posted.
>> 
>> Christian
>> 
>>> On Wed, Feb 12, 2020 at 09:49:02AM +0100, Peter Kreuser wrote:
>>> Let me add a "me too"!
>>> 
>>> nginx 1.17.x
>>> 
>>> Am 2020-02-11 20:05, schrieb Christian Varas:
>>>> Hello, I’ve conpiled a nginx and Modsecurity today, every works fine
>>>> except the audit log. The audit log is not being populated, the
>>>> attacks are logged only in the error log but not in the audit log.
>>>> If I change modsecurity to “DetectionOnly” the audit logs start to
>>>> being populated but if I set modsecurity in “On” the audit log does
>>>> not work…
>>>> This is my setup:
>>>> 
>>>> nginx version: 1.15.8.1
>>>> Modsecurity: branch v3/Master from GitHub
>>>> 
>>>> I have this lines to log the transactions:
>>>> 
>>>> SecRuleEngine On
>>>> SecDefaultAction "phase:1,log,auditlog,deny,status:403"
>>>> SecDefaultAction "phase:2,log,auditlog,deny,status:403"
>>>> 
>>>> 
>>>> SecAuditLogDirMode 1733
>>>> SecAuditLogFileMode 0550
>>>> SecAuditLogFormat JSON
>>>> SecAuditEngine RelevantOnly
>>>> SecAuditLogRelevantStatus "^(?:5|4)”
>>>> SecAuditLogParts ABCHIZ
>>>> SecAuditLogType Serial
>>>> SecAuditLog /opt/waf/nginx/var/log/nnoc.vtr.cl/nnoc.vtr.cl_audit.log
>>>> 
>>>> 
>>>> 
>>>> Maybe I need to fix my configuration ?
>>>> Does anybody else is experimenting the same ?
>>>> 
>>>> Thanks in advanced.
>>>> Cheers.
>>>> Chris.
>>>> 
>>>> _______________________________________________
>>>> 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 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 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 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] @pmFromFile for blocked vars

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

that way it works - unsure of the performance impact while i am not a
fan of chaining rules at all for that reason

SecRule ARGS (.*)
"id:'89',phase:2,chain,logdata:'%{matched_var}',block,msg:'blocked
variable'"
SecRule MATCHED_VARS_NAMES "@pmFromFile 99_blocked_vars.data"
"chain,capture"
SecRule MATCHED_VAR "@streq ARGS:%{tx.0}"

"ARGS_NAMES @pmf 99_blocked" as far as i remember matches also parts and
instead exactly "base_dir" every param which contains it

Am 17.02.20 um 19:38 schrieb Christian Folini:
> Hallo Harald,
> 
> I think the problem with your rule is order of execution of chained rules.
> 
> In your first example, the 1st SecRule is executed for base_dir and then
> for x. VAR is now x. Then the 2nd rule is executed for var = x, which
> does not bring a hit.
> 
> This is counterintuitive of course, but when you think about how things are
> probably handled internally, then it makes sense. At least some sense. But
> I wish it was different.
> 
> Is there a reason you do not do ARGS_NAMES @pmf 99_blocked... ?
> I did not think this through, tough.
> 
> Building on your hack, you could do setvar:tx.var_%{MATCHED_VAR_NAME}
> and then TX:/^var_/ "@pmf ...
> 
> Just my 2 cents,
> 
> Christian
> 
> 
> On Mon, Feb 17, 2020 at 07:08:57PM +0100, Reindl Harald wrote:
>> Hi
>>
>> the rule below needs some love
>>
>> no hit: ?base_dir=x&x=1
>> hit: ?base_dir=x
>>
>> why in the world does that only hit if the url ends with a listed param
>> and is the some nicer way for "exact macth" than the ***var*** hack?
>>
>> --------------------------------
>>
>> SecRule ARGS_NAMES ^(.*)$
>> "id:'89',chain,setvar:tx.var='***%{matched_var}***',msg:'blocked
>> variable: %{matched_var}'"
>> SecRule TX:VAR "@pmFromFile 99_blocked_vars.data"
>>
>> --------------------------------
>>
>> 99_blocked_vars.data:
>>
>> ***base_dir***

Re: [mod-security-users] @pmFromFile for blocked vars

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

Hallo Harald,

I think the problem with your rule is order of execution of chained rules.

In your first example, the 1st SecRule is executed for base_dir and then
for x. VAR is now x. Then the 2nd rule is executed for var = x, which
does not bring a hit.

This is counterintuitive of course, but when you think about how things are
probably handled internally, then it makes sense. At least some sense. But
I wish it was different.

Is there a reason you do not do ARGS_NAMES @pmf 99_blocked... ?
I did not think this through, tough.

Building on your hack, you could do setvar:tx.var_%{MATCHED_VAR_NAME}
and then TX:/^var_/ "@pmf ...

Just my 2 cents,

Christian


On Mon, Feb 17, 2020 at 07:08:57PM +0100, Reindl Harald wrote:
> Hi
> 
> the rule below needs some love
> 
> no hit: ?base_dir=x&x=1
> hit: ?base_dir=x
> 
> why in the world does that only hit if the url ends with a listed param
> and is the some nicer way for "exact macth" than the ***var*** hack?
> 
> --------------------------------
> 
> SecRule ARGS_NAMES ^(.*)$
> "id:'89',chain,setvar:tx.var='***%{matched_var}***',msg:'blocked
> variable: %{matched_var}'"
> SecRule TX:VAR "@pmFromFile 99_blocked_vars.data"
> 
> --------------------------------
> 
> 99_blocked_vars.data:
> 
> ***base_dir***
> 
> 
> _______________________________________________
> 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] @pmFromFile for blocked vars

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

Hi

the rule below needs some love

no hit: ?base_dir=x&x=1
hit: ?base_dir=x

why in the world does that only hit if the url ends with a listed param
and is the some nicer way for "exact macth" than the ***var*** hack?

--------------------------------

SecRule ARGS_NAMES ^(.*)$
"id:'89',chain,setvar:tx.var='***%{matched_var}***',msg:'blocked
variable: %{matched_var}'"
SecRule TX:VAR "@pmFromFile 99_blocked_vars.data"

--------------------------------

99_blocked_vars.data:

***base_dir***

Re: [mod-security-users] Modsecurity Nginx: Audit log not being populated

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

Actually, the problem has been reported before. There is working fix that is
making it's way into the master src code tree as we speak.

https://github.com/SpiderLabs/ModSecurity-nginx/issues/170


On Wed, Feb 12, 2020 at 10:50:38AM +0100, Christian Folini wrote:
> Hey guys,
> 
> the configuration looks correct. Normally the file permissions can pose
> a problem. However, the fact that DetectionOnly makes it functional points to
> a ModSec bug, which you may want to report on github.
> 
> The ModSec devs are hardly active on this ML, but they are usually quick to
> react on github issues.
> 
> Please keep us posted.
> 
> Christian
> 
> On Wed, Feb 12, 2020 at 09:49:02AM +0100, Peter Kreuser wrote:
> > Let me add a "me too"!
> > 
> > nginx 1.17.x
> > 
> > Am 2020-02-11 20:05, schrieb Christian Varas:
> > > Hello, I’ve conpiled a nginx and Modsecurity today, every works fine
> > > except the audit log. The audit log is not being populated, the
> > > attacks are logged only in the error log but not in the audit log.
> > > If I change modsecurity to “DetectionOnly” the audit logs start to
> > > being populated but if I set modsecurity in “On” the audit log does
> > > not work…
> > > This is my setup:
> > > 
> > > nginx version: 1.15.8.1
> > > Modsecurity: branch v3/Master from GitHub
> > > 
> > > I have this lines to log the transactions:
> > > 
> > > SecRuleEngine On
> > > SecDefaultAction "phase:1,log,auditlog,deny,status:403"
> > > SecDefaultAction "phase:2,log,auditlog,deny,status:403"
> > > 
> > > 
> > > SecAuditLogDirMode 1733
> > > SecAuditLogFileMode 0550
> > > SecAuditLogFormat JSON
> > > SecAuditEngine RelevantOnly
> > > SecAuditLogRelevantStatus "^(?:5|4)”
> > > SecAuditLogParts ABCHIZ
> > > SecAuditLogType Serial
> > > SecAuditLog /opt/waf/nginx/var/log/nnoc.vtr.cl/nnoc.vtr.cl_audit.log
> > > 
> > > 
> > > 
> > > Maybe I need to fix my configuration ?
> > > Does anybody else is experimenting the same ?
> > > 
> > > Thanks in advanced.
> > > Cheers.
> > > Chris.
> > > 
> > > _______________________________________________
> > > 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 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 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] Modsecurity Nginx: Audit log not being populated

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

Hey guys,

the configuration looks correct. Normally the file permissions can pose
a problem. However, the fact that DetectionOnly makes it functional points to
a ModSec bug, which you may want to report on github.

The ModSec devs are hardly active on this ML, but they are usually quick to
react on github issues.

Please keep us posted.

Christian

On Wed, Feb 12, 2020 at 09:49:02AM +0100, Peter Kreuser wrote:
> Let me add a "me too"!
> 
> nginx 1.17.x
> 
> Am 2020-02-11 20:05, schrieb Christian Varas:
> > Hello, I’ve conpiled a nginx and Modsecurity today, every works fine
> > except the audit log. The audit log is not being populated, the
> > attacks are logged only in the error log but not in the audit log.
> > If I change modsecurity to “DetectionOnly” the audit logs start to
> > being populated but if I set modsecurity in “On” the audit log does
> > not work…
> > This is my setup:
> > 
> > nginx version: 1.15.8.1
> > Modsecurity: branch v3/Master from GitHub
> > 
> > I have this lines to log the transactions:
> > 
> > SecRuleEngine On
> > SecDefaultAction "phase:1,log,auditlog,deny,status:403"
> > SecDefaultAction "phase:2,log,auditlog,deny,status:403"
> > 
> > 
> > SecAuditLogDirMode 1733
> > SecAuditLogFileMode 0550
> > SecAuditLogFormat JSON
> > SecAuditEngine RelevantOnly
> > SecAuditLogRelevantStatus "^(?:5|4)”
> > SecAuditLogParts ABCHIZ
> > SecAuditLogType Serial
> > SecAuditLog /opt/waf/nginx/var/log/nnoc.vtr.cl/nnoc.vtr.cl_audit.log
> > 
> > 
> > 
> > Maybe I need to fix my configuration ?
> > Does anybody else is experimenting the same ?
> > 
> > Thanks in advanced.
> > Cheers.
> > Chris.
> > 
> > _______________________________________________
> > 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 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] Modsecurity Nginx: Audit log not being populated

[Peter K. <pe...@kr...>]

Let me add a "me too"!

nginx 1.17.x

Am 2020-02-11 20:05, schrieb Christian Varas:
> Hello, I’ve conpiled a nginx and Modsecurity today, every works fine
> except the audit log. The audit log is not being populated, the
> attacks are logged only in the error log but not in the audit log.
> If I change modsecurity to “DetectionOnly” the audit logs start to
> being populated but if I set modsecurity in “On” the audit log does
> not work…
> This is my setup:
> 
> nginx version: 1.15.8.1
> Modsecurity: branch v3/Master from GitHub
> 
> I have this lines to log the transactions:
> 
> SecRuleEngine On
> SecDefaultAction "phase:1,log,auditlog,deny,status:403"
> SecDefaultAction "phase:2,log,auditlog,deny,status:403"
> 
> 
> SecAuditLogDirMode 1733
> SecAuditLogFileMode 0550
> SecAuditLogFormat JSON
> SecAuditEngine RelevantOnly
> SecAuditLogRelevantStatus "^(?:5|4)”
> SecAuditLogParts ABCHIZ
> SecAuditLogType Serial
> SecAuditLog /opt/waf/nginx/var/log/nnoc.vtr.cl/nnoc.vtr.cl_audit.log
> 
> 
> 
> Maybe I need to fix my configuration ?
> Does anybody else is experimenting the same ?
> 
> Thanks in advanced.
> Cheers.
> Chris.
> 
> _______________________________________________
> 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/