mod-security-developers Mailing List for ModSecurity (Page 30)
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
mod-security-developers — Development discussion about mod_security
You can subscribe to this list here.
| 2006 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(8) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(9) |
Sep
|
Oct
(1) |
Nov
|
Dec
(3) |
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
(12) |
Mar
(42) |
Apr
(68) |
May
(30) |
Jun
(50) |
Jul
(17) |
Aug
(3) |
Sep
(5) |
Oct
(7) |
Nov
(3) |
Dec
(4) |
| 2012 |
Jan
(11) |
Feb
(11) |
Mar
(37) |
Apr
|
May
(21) |
Jun
(21) |
Jul
(12) |
Aug
(41) |
Sep
(19) |
Oct
(31) |
Nov
(24) |
Dec
(10) |
| 2013 |
Jan
(12) |
Feb
(18) |
Mar
(3) |
Apr
(8) |
May
(35) |
Jun
(5) |
Jul
(38) |
Aug
(5) |
Sep
(2) |
Oct
(4) |
Nov
(11) |
Dec
(6) |
| 2014 |
Jan
(3) |
Feb
(12) |
Mar
(11) |
Apr
(18) |
May
(2) |
Jun
(1) |
Jul
(11) |
Aug
(5) |
Sep
|
Oct
(15) |
Nov
(13) |
Dec
(9) |
| 2015 |
Jan
(2) |
Feb
(8) |
Mar
(7) |
Apr
(3) |
May
|
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
(11) |
Oct
(14) |
Nov
(4) |
Dec
(1) |
| 2016 |
Jan
(11) |
Feb
(19) |
Mar
(20) |
Apr
(6) |
May
(3) |
Jun
(17) |
Jul
(5) |
Aug
|
Sep
(7) |
Oct
(2) |
Nov
(2) |
Dec
(12) |
| 2017 |
Jan
(4) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(3) |
Oct
(1) |
Nov
|
Dec
(15) |
| 2018 |
Jan
(13) |
Feb
(2) |
Mar
(14) |
Apr
(9) |
May
|
Jun
(6) |
Jul
(3) |
Aug
(1) |
Sep
(3) |
Oct
|
Nov
(13) |
Dec
(1) |
| 2019 |
Jan
(2) |
Feb
(9) |
Mar
(28) |
Apr
(4) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
(2) |
| 2020 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(3) |
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(10) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2012-06-05 12:38:56
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-313.
--------------------------------------
Resolution: Not a Bug
Good to know how it was fixed.
Thanks to report.
> mlogc skips all entries
> -----------------------
>
> Key: MODSEC-313
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-313
> Project: ModSecurity
> Issue Type: Bug
> Security Level: Normal
> Components: Mlogc
> Affects Versions: 2.6.1, 2.6.5
> Environment: Linux (Centos 5.6)
> Reporter: Dennis Moers
> Assignee: Breno Silva Pinto
>
> I am trying to use mlogc to log attacks in the jwall AuditConsole. But each request which is recogniced by mod_security causes an error in mlogc.
> Examples:
> [Tue May 29 09:19:04 2012] [2] [14118/8971980] Invalid entry (failed to match regex): [modsecurity] [client x.x.x.x] [domain y.y.y.y] [403] [/20120529/20120529-0919/20120529-091904-T8R4aH8AAAEAADcnCDUAAAAA] [file \"/etc/httpd/modsecurity.d/base_rules/modsecurity_crs_40_generic_attacks.conf\"] [line \"221\"] [id \"958700\"] [rev \"2.2.2\"] [msg \"Remote File Access Attempt\"] [data \"/etc/\"] [severity \"CRITICAL\"] [tag \"WEB_ATTACK/FILE_INJECTION\"] [tag \"WASCTC/WASC-33\"] [tag \"OWASP_TOP_10/A4\"] [tag \"PCI/6.5.4\"] Access denied with code 403 (phase 2). Pattern match \"\\\\/etc\\\\/\" at ARGS:s.
> [Tue May 29 09:56:55 2012] [2] [14237/a091990] Invalid entry (failed to match regex): [modsecurity] [client x.x.x.x] [domain y.y.y.y] [403] [/20120529/20120529-0956/20120529-095655-T8SBR38AAAEAADerCAwAAAAA] [file \"/etc/httpd/modsecurity.d/base_rules/modsecurity_crs_21_protocol_anomalies.conf\"] [line \"47\"] [id \"960015\"] [rev \"2.2.2\"] [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\"] Access denied with code 403 (phase 2). Operator EQ matched 0 at REQUEST_HEADERS.
> I am running mod_security 2.6.1 and tried mlogc 2.6.1 and 2.6.5. Both of them showed the same error.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Ryan B. <RBa...@tr...> - 2012-06-05 12:28:33
|
From: leon xu <xc...@gm...<mailto:xc...@gm...>>
Reply-To: "mod...@li...<mailto:mod...@li...>" <mod...@li...<mailto:mod...@li...>>
Date: Mon, 4 Jun 2012 21:10:06 -0500
To: "mod...@li...<mailto:mod...@li...>" <mod...@li...<mailto:mod...@li...>>
Subject: [Mod-security-developers] Var in dos rule exipired earlier then expected
Hello, everyone
we use modsecurity 2.6 protect against dos attack for some specific pages.
Just an FYI – the OWASP ModSecurity CRS already has a DoS ruleset - http://mod-security.svn.sourceforge.net/viewvc/mod-security/crs/trunk/experimental_rules/modsecurity_crs_11_dos_protection.conf?revision=1797
You might want to try it and see if you still have issues.
-=Ryan
This is the rule. I test it in my box, it works. But when in some product environment(3000 concurrent connections in worker MPM), it failed.
In the early time I use expiredvar:dos_block every 1800 seconds, as the modsecurity docs suggests. I found the var "dos_block" expired within 1-10 second(I dump the resource db),not 1800. So I changed it with deprecatevar.
But it does not works too.
Does it because of the concurrent problem?
Thanks.
----------------------------------------------------------------
SecRule REQUEST_URI "^/login.php" \
"phase:1,capture,t:lowercase,t:urlDecodeUni,pass,nolog,setvar:tx.dos_uri=%{TX.1},skip:1"
SecAction "phase:1,pass,nolog,skipAfter:Dos_Marker"
SecAction "phase:1,pass,nolog,t:none,setvar:tx.real_ip=%{REMOTE_ADDR}"
SecAction "phase:1,nolog,initcol:resource='%{tx.real_ip}/'"
SecRule RESOURCE:SHOULD_LOG "@eq 1" "phase:1,pass,nolog,setvar:resource.should_log=0,skip:2"
#already blocked, nolog here
SecRule RESOURCE:DOS_BLOCKED "@eq 1" \
"phase:1,deny,nolog,severity:'2',status:403,deprecatevar:resource.dos_blocked=1/1800,skipAfter:Dos_Marker"
SecAction "phase:1,pass,nolog,skip:1"
#log version, logdata is real client ip
SecRule RESOURCE:DOS_BLOCKED "@eq 1" \
"phase:1,deny,log,auditlog,severity:'2',msg:'99010',id:'99010001',tag:'9901',status:403,deprecatevar:resource.dos_blocked=1/1800,logdata:%{tx.real_ip},skipAfter:Dos_Marker"
#counter++
SecAction "phase:1,nolog,setvar:resource.dos_request_counter=+1,deprecatevar:resource.dos_request_counter=10/60"
# if counter == max then block
SecRule RESOURCE:DOS_REQUEST_COUNTER "@ge 10" \
"phase:5,nolog,setvar:resource.dos_request_counter=0,setvar:resource.dos_blocked=1,setvar:resource.should_log=1"
SecMarker Dos_Marker
________________________________
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.
|
|
From: Breno S. <bre...@gm...> - 2012-06-05 12:16:50
|
Are you using modsecurity 2.6.5 ?
Thanks
Breno
On Mon, Jun 4, 2012 at 9:10 PM, leon xu <xc...@gm...> wrote:
> Hello, everyone
>
> we use modsecurity 2.6 protect against dos attack for some specific
> pages.
> This is the rule. I test it in my box, it works. But when in some product
> *environment(3000 *concurrent connections in worker MPM)*, it failed.*
> *In the early time I use expiredvar:dos_block every 1800 seconds, as the
> modsecurity docs suggests. I found the var "dos_block" expired within 1-10
> second(**I dump the resource db),n**ot 1800. So I changed it with *
> deprecatevar.
> But it does not works too.
> Does it because of the concurrent problem?
>
> Thanks.
>
>
> ----------------------------------------------------------------
>
> SecRule REQUEST_URI "^/login.php" \
>
> "phase:1,capture,t:lowercase,t:urlDecodeUni,pass,nolog,setvar:tx.dos_uri=%{TX.1},skip:1"
> SecAction "phase:1,pass,nolog,skipAfter:Dos_Marker"
>
>
>
>
>
> SecAction "phase:1,pass,nolog,t:none,setvar:tx.real_ip=%{REMOTE_ADDR}"
> SecAction "phase:1,nolog,initcol:resource='%{tx.real_ip}/'"
>
>
>
> SecRule RESOURCE:SHOULD_LOG "@eq 1"
> "phase:1,pass,nolog,setvar:resource.should_log=0,skip:2"
>
> #already blocked, nolog here
> SecRule RESOURCE:DOS_BLOCKED "@eq 1" \
>
> "phase:1,deny,nolog,severity:'2',status:403,deprecatevar:resource.dos_blocked=1/1800,skipAfter:Dos_Marker"
>
> SecAction "phase:1,pass,nolog,skip:1"
>
> #log version, logdata is real client ip
> SecRule RESOURCE:DOS_BLOCKED "@eq 1" \
>
> "phase:1,deny,log,auditlog,severity:'2',msg:'99010',id:'99010001',tag:'9901',status:403,deprecatevar:resource.dos_blocked=1/1800,logdata:%{tx.real_ip},skipAfter:Dos_Marker"
>
> #counter++
> SecAction
> "phase:1,nolog,setvar:resource.dos_request_counter=+1,deprecatevar:resource.dos_request_counter=10/60"
>
>
> # if counter == max then block
> SecRule RESOURCE:DOS_REQUEST_COUNTER "@ge 10" \
>
> "phase:5,nolog,setvar:resource.dos_request_counter=0,setvar:resource.dos_blocked=1,setvar:resource.should_log=1"
>
> SecMarker Dos_Marker
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> 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
>
|
|
From: leon xu <xc...@gm...> - 2012-06-05 02:10:12
|
Hello, everyone
we use modsecurity 2.6 protect against dos attack for some specific
pages.
This is the rule. I test it in my box, it works. But when in some product *
environment(3000 *concurrent connections in worker MPM)*, it failed.*
*In the early time I use expiredvar:dos_block every 1800 seconds, as the
modsecurity docs suggests. I found the var "dos_block" expired within 1-10
second(**I dump the resource db),n**ot 1800. So I changed it with *
deprecatevar.
But it does not works too.
Does it because of the concurrent problem?
Thanks.
----------------------------------------------------------------
SecRule REQUEST_URI "^/login.php" \
"phase:1,capture,t:lowercase,t:urlDecodeUni,pass,nolog,setvar:tx.dos_uri=%{TX.1},skip:1"
SecAction "phase:1,pass,nolog,skipAfter:Dos_Marker"
SecAction "phase:1,pass,nolog,t:none,setvar:tx.real_ip=%{REMOTE_ADDR}"
SecAction "phase:1,nolog,initcol:resource='%{tx.real_ip}/'"
SecRule RESOURCE:SHOULD_LOG "@eq 1"
"phase:1,pass,nolog,setvar:resource.should_log=0,skip:2"
#already blocked, nolog here
SecRule RESOURCE:DOS_BLOCKED "@eq 1" \
"phase:1,deny,nolog,severity:'2',status:403,deprecatevar:resource.dos_blocked=1/1800,skipAfter:Dos_Marker"
SecAction "phase:1,pass,nolog,skip:1"
#log version, logdata is real client ip
SecRule RESOURCE:DOS_BLOCKED "@eq 1" \
"phase:1,deny,log,auditlog,severity:'2',msg:'99010',id:'99010001',tag:'9901',status:403,deprecatevar:resource.dos_blocked=1/1800,logdata:%{tx.real_ip},skipAfter:Dos_Marker"
#counter++
SecAction
"phase:1,nolog,setvar:resource.dos_request_counter=+1,deprecatevar:resource.dos_request_counter=10/60"
# if counter == max then block
SecRule RESOURCE:DOS_REQUEST_COUNTER "@ge 10" \
"phase:5,nolog,setvar:resource.dos_request_counter=0,setvar:resource.dos_blocked=1,setvar:resource.should_log=1"
SecMarker Dos_Marker
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2012-06-04 19:40:51
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-310.
--------------------------------------
Resolution: Fixed
added ver, maturity and accuracy
> Need to add a version "ver" action to hold specific rules version information
> -----------------------------------------------------------------------------
>
> Key: MODSEC-310
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-310
> Project: ModSecurity
> Issue Type: New Feature
> Security Level: Normal
> Components: Actions
> Reporter: Ryan Barnett
> Assignee: Breno Silva Pinto
> Fix For: 2.7.0
>
>
> We already have the "rev" action which holds data related to the revision information for a specific rule. We should also add a version "ver" action that will hold the appropriate CRS rule version data.
> For example - "phase:2,id:'1234',ver:'CRS/2.2.4',rev:'1',t:none,...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Ryan B. <RBa...@tr...> - 2012-06-04 15:25:42
|
Our team is growing! We are expanding our SpiderLabs Research team and are looking to add another full-time security researcher/developer to help with the ModSecurity project. Details here: http://hire.jobvite.com/Jobvite/Job.aspx?m=npHzNiwf&j=oKNrWfwE -- Ryan Barnett Researcher Lead Trustwave - SpiderLabs ModSecurity Project Leader ________________________________ 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. |
|
From: Breno S. P. (JIRA) <no...@mo...> - 2012-06-01 20:28:42
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-244.
--------------------------------------
Resolution: Fixed
> Need to allow @ipMatch data from file
> -------------------------------------
>
> Key: MODSEC-244
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-244
> Project: ModSecurity
> Issue Type: New Feature
> Security Level: Normal
> Components: Operators
> Affects Versions: 2.6.0
> Reporter: Ryan Barnett
> Assignee: Breno Silva Pinto
> Fix For: 2.7.0
>
>
> Need to add a new operator that combines the capabilities of both @ipMatch and @pmFromFile/@pmf so that users can list large numbers of IP addresses.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2012-05-11 00:02:26
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-283.
--------------------------------------
Resolution: Fixed
> Documentation for rbl refers to SecHttpBlKey, which exists only in the trunk
> ----------------------------------------------------------------------------
>
> Key: MODSEC-283
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-283
> Project: ModSecurity
> Issue Type: Bug
> Security Level: Normal
> Components: Documentation
> Affects Versions: 2.6.3
> Reporter: Ivan Ristic
> Assignee: Breno Silva Pinto
>
> The documentation for rbl refers to SecHttpBlKey, which exists only in the trunk. This may confuse users, as most of them only use official releases.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2012-05-11 00:00:30
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-216.
--------------------------------------
Resolution: Fixed
> Update the RESOURCE collection to use SecWebAppId Name Space
> ------------------------------------------------------------
>
> Key: MODSEC-216
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-216
> Project: ModSecurity
> Issue Type: Improvement
> Security Level: Normal
> Components: Rules
> Reporter: Ryan Barnett
> Assignee: Breno Silva Pinto
> Fix For: 2.7.0
>
>
> The RESOURCE collection should be able to use the name space specified by SecWebAppId in the same way that the SESSION and USERID collections do. This is needed so that URLs with the same name but are on different virtual hosts are not confused. If no SecWebAppId is defined, then a resource collection should be -
> default_RESOURCE.dir
> default_RESOURCE.pag
> If a SecWebAppId directive is used, Example -
> <VirtualHost www.foo.com>
> SecWebAppId foo
> </VirtualHost>
> <VirtualHost www.bar.com>
> SecWebAppId bar
> </VirtualHost>
> Then the persistent storage names should be:
> foo_RESOURCE.dir
> foo_RESOURCE.pag
> bar_RESOURCE.dir
> bar_RESOURCE.pag
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2012-05-11 00:00:30
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-296.
--------------------------------------
Resolution: Fixed
> rsub operator not working/garbage at the end
> --------------------------------------------
>
> Key: MODSEC-296
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-296
> Project: ModSecurity
> Issue Type: Bug
> Security Level: Normal
> Components: Operators
> Affects Versions: 2.6.5
> Reporter: Jerome Freilinger
> Assignee: Breno Silva Pinto
> Fix For: 2.7.0
>
> Attachments: rsub_patch.diff
>
>
> * If the regular expression of the rsub operator contains capturing parentheses garbage data is still added a the end.
> * The parameters \1 .. \9 are only evaluated once per rsub operator call. They should be evalutated for every match and not only for the first match.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2012-05-11 00:00:28
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto closed MODSEC-22.
-----------------------------------
Resolution: Fixed
> Cache Lua virtual machines for better performance
> -------------------------------------------------
>
> Key: MODSEC-22
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-22
> Project: ModSecurity
> Issue Type: Improvement
> Security Level: Normal
> Reporter: Ivan Ristic
> Assignee: Breno Silva Pinto
> Fix For: 2.7.0
>
>
> Although Lua scripts are converted to bytecode at startup, we still create a new virtual machine per Lua rule. We should instead do the following:
> 1. Create a pool of virtual machines at startup
> 2. Assign a virtual machine to a transaction so that all Lua scripts (in the same transaction) use the same virtual machine
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2012-05-11 00:00:28
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto closed MODSEC-98.
-----------------------------------
Resolution: Fixed
> Process phase 1 in the same Apache hook as phase 2
> --------------------------------------------------
>
> Key: MODSEC-98
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-98
> Project: ModSecurity
> Issue Type: Improvement
> Security Level: Normal
> Reporter: Ivan Ristic
> Assignee: Breno Silva Pinto
> Fix For: 2.7.0
>
>
> I have this idea that ModSecurity should not use post_read for its phase 1. Instead, phase 1 should use the same hook as phase 2. With this change, users would be able to override configuration from a
> <Location> or <Directory> container, removing the problem that has been causing confusion for years. The only advantage of having phase 1 early is to allow for rules that are protecting Apache itself, but I am yet to see a single such rule. Besides, we can still keep one such early phase (although we'd better move to using names for phases, instead of numbers).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2012-05-11 00:00:25
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-266.
--------------------------------------
Resolution: Fixed
> SecRuleUpdateTargetById allowing ranges
> ---------------------------------------
>
> Key: MODSEC-266
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-266
> Project: ModSecurity
> Issue Type: New Feature
> Security Level: Normal
> Components: Core
> Affects Versions: 2.6.1
> Reporter: steve hodges
> Assignee: Breno Silva Pinto
> Fix For: 2.7.0
>
>
> Hi...
> It would be very useful if the SecRuleUpdateTargetById directive of 2.6.x could accept a range of rules rather than a single rule, e.g.,
> SecRuleUpdateTargetById 12345-12349 "!ARGS:foo"
> Thanks very much--
> -steve
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2012-05-11 00:00:23
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-288.
--------------------------------------
Resolution: Fixed
> Redirect macro expansion does not work in SecDefaultAction when SecRule uses block action
> -----------------------------------------------------------------------------------------
>
> Key: MODSEC-288
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-288
> Project: ModSecurity
> Issue Type: Bug
> Security Level: Normal
> Components: Actions
> Affects Versions: 2.6.3
> Reporter: Ryan Barnett
> Assignee: Breno Silva Pinto
> Fix For: 2.7.0
>
>
> Macro expansion in a redirect action in SecDefaultAction -
> SecDefaultAction "phase:2,log,redirect:http://www2.site.com/pm/form.asp?i=3&eID=%{unique_id}
> This does not macro expand if the SecRule that matches uses "block" action and inherits the disruptive action. If the SecRule does not have any disruptive action specified, then the redirect macro expansion works.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2012-05-10 23:58:30
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-232.
--------------------------------------
Resolution: Fixed
> Preserve names/identity of the variables going into MATCHED_VARS
> ----------------------------------------------------------------
>
> Key: MODSEC-232
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-232
> Project: ModSecurity
> Issue Type: Improvement
> Security Level: Normal
> Components: Core
> Affects Versions: 2.6.0
> Reporter: Ivan Ristic
> Assignee: Breno Silva Pinto
> Fix For: 2.7.0
>
>
> For this rule:
> SecRule ARGS "xxx" chain,phase:1,log,pass
> SecRule MATCHED_VARS "yyy" chain
> SecRule MATCHED_VARS "zzz"
> The debug output contains (among other things):
> Expanded "MATCHED_VARS" to "MATCHED_VARS:a|MATCHED_VARS:b"
> It would be preferred to preserve the identity of matched variables, because that will help the user know where they came from. Thus, the above line should ideally be:
> Expanded "MATCHED_VARS" to "ARGS:a|ARGS:b"
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2012-05-10 23:58:30
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-114.
--------------------------------------
Resolution: Fixed
> ModSecurity should not accept non-numerical rule IDs
> ----------------------------------------------------
>
> Key: MODSEC-114
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-114
> Project: ModSecurity
> Issue Type: Bug
> Security Level: Normal
> Affects Versions: 2.5.11
> Reporter: Ivan Ristic
> Assignee: Breno Silva Pinto
> Fix For: 2.7.0
>
>
> ModSecurity currently accepts non-numerical rule IDs in several places (at least in the id action and in SecRuleRemoveByID), but internally it assumes rule IDs are always numerical. Conversion to a number is used in at least one location. As a consequence, the removal of the rules with non-numerical IDs does not work. Or, rather, it works, but (because of the aforementioned conversion) all the non-numerical rules are removed. (I've spent limited time looking at the code. I may not be 100% correct here, but the removal definitely does not work.)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2012-05-10 23:58:30
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-300.
--------------------------------------
Resolution: Fixed
> ModSec Variable "DURATION" comes in milliseconds, while the Apache equivalent (%D) comes in microseconds as come the various PERF_PHASE variables in ModSec
> -----------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: MODSEC-300
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-300
> Project: ModSecurity
> Issue Type: Bug
> Security Level: Normal
> Components: Core
> Affects Versions: 2.6.0, 2.6.1, 2.6.2, 2.6.3, 2.6.4, 2.6.5
> Environment: Any
> Reporter: Christian Folini
> Assignee: Breno Silva Pinto
> Fix For: 2.7.0
>
>
> The use of milliseconds for the Variable "DURATION" is an anomaly.
> Apache itself uses microseconds for its %D variable (=Duration; see http://httpd.apache.org/docs/2.4/mod/mod_log_config.html).
> The various PERF variables in ModSec also use microseconds. (see http://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual#PERF_PHASE1)
> Googling for "SecRule Duration" (https://www.google.ch/search?q="SecRule+Duration") reveals, that there are no published recipes using this variable. So changing this should not break too many things.
> The variable is set in re_variables.c with the help of apr_time_msec. Using apr_time_usec should do the trick.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2012-05-10 23:58:27
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-176.
--------------------------------------
Resolution: Fixed
> Macro expansion in pause
> ------------------------
>
> Key: MODSEC-176
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-176
> Project: ModSecurity
> Issue Type: Improvement
> Security Level: Normal
> Components: Core
> Affects Versions: 2.5.12
> Reporter: Marc Stern
> Assignee: Breno Silva Pinto
> Fix For: 2.7.0
>
>
> It would be handy to be able to use macro expansion in the "pause" action, for instance to introduce a random time - does somebody think about Oracle padding attack protection? ;-)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2012-05-10 23:58:27
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-155.
--------------------------------------
Resolution: Cannot Reproduce
> MULTIPART_UNMATCHED_BOUNDARY in multipart form
> ----------------------------------------------
>
> Key: MODSEC-155
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-155
> Project: ModSecurity
> Issue Type: Improvement
> Security Level: Normal
> Components: Core
> Affects Versions: 2.5.11
> Environment: RHEL4 + builded httpd-2.2.14
> Reporter: kuRt
> Assignee: Breno Silva Pinto
> Fix For: 2.7.0
>
> Attachments: 1adb435b.gz, 20e02773.gz, b661a066.gz
>
>
> Some petitions are filtered like a MULTIPART_UNMATCHED_BOUNDARY (SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" "phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.)
> This petitions tries to send POST data via multipart form.
> The main problem is that we can't extract the scenario that sets this variable = 1, because just some petitions are blocked and not been observed obvious diferences/similitudes.
> I've been searching online but no similar problems are submited.
> I've been follow the source code of the parser to tries to understand the reason:
> , the function that activates the MULTIPART_UNMATCHED_BOUNDARY modSec var:
> (apache2/re_variables.c #1407)
> ***************************************************************
> static int var_multipart_unmatched_boundary_generate(modsec_rec *msr, msre_var *var, msre_rule *rule,
> apr_table_t *vartab, apr_pool_t *mptmp)
> {
> -> if ((msr->mpd != NULL)&&(msr->mpd->flag_unmatched_boundary != 0)) {
> return var_simple_generate(var, vartab, mptmp, "1");
> } else {
> return var_simple_generate(var, vartab, mptmp, "0");
> }
> }
> ***************************************************************
> , and the sets of the flag_unmatched_boundary:
> (apache2/msc_multipart.c #979)
> ***************************************************************
> /* Do we have something that looks like a boundary? */
> if ( msr->mpd->buf_contains_line
> && (strlen(msr->mpd->buf) > 3)
> && (*(msr->mpd->buf) == '-')
> && (*(msr->mpd->buf + 1) == '-') )
> {
>
> /* Does it match our boundary? */
> if ( (strlen(msr->mpd->buf) >= strlen(msr->mpd->boundary) + 2)
> && (strncmp(msr->mpd->buf + 2, msr->mpd->boundary, strlen(msr->mpd->boundary)) == 0) )
> {
> ....
> ....
> ....
> } else { /* It looks like a boundary but we couldn't match it. */
> char *p = NULL;
> /* Check if an attempt to use quotes around the boundary was made. */
> if ( (msr->mpd->flag_boundary_quoted)
> && (strlen(msr->mpd->buf) >= strlen(msr->mpd->boundary) + 3)
> && (*(msr->mpd->buf + 2) == '"')
> && (strncmp(msr->mpd->buf + 3, msr->mpd->boundary, strlen(msr->mpd->boundary)) == 0)
> ) {
> msr->mpd->flag_error = 1;
> *error_msg = apr_psprintf(msr->mp, "Multipart: Invalid boundary (quotes).");
> return -1;
> }
> /* Check the beginning of the boundary for whitespace. */
> p = msr->mpd->buf + 2;
> while(isspace(*p)) {
> p++;
> }
> if ( (p != msr->mpd->buf + 2)
> && (strncmp(p, msr->mpd->boundary, strlen(msr->mpd->boundary)) == 0)
> ) {
> /* Found whitespace in front of a boundary. */
> msr->mpd->flag_error = 1;
> *error_msg = apr_psprintf(msr->mp, "Multipart: Invalid boundary (whitespace).");
> return -1;
> }
> -> msr->mpd->flag_unmatched_boundary = 1;
> }
>
> } else { /* We do not think the buffer contains a boundary. */
> /* Look into the buffer to see if there's anything
> * there that resembles a boundary.
> */
> if (msr->mpd->buf_contains_line) {
> int i, len = (MULTIPART_BUF_SIZE - msr->mpd->bufleft);
> char *p = msr->mpd->buf;
> for(i = 0; i < len; i++) {
> if ((p[i] == '-') && (i + 1 < len) && (p[i + 1] == '-'))
> {
> if (strncmp(p + i + 2, msr->mpd->boundary, strlen(msr->mpd->boundary)) == 0) {
> -> msr->mpd->flag_unmatched_boundary = 1;
> break;
> }
> }
> }
> }
> }
> ***************************************************************
> As a temporal solution, I've modified this rule to not deny the petition, but i'm worried about if this can we a security problem.
> PD: This problem is related by the ModSec of every vhost instance of the HTTPd, but the POST petition is just launched over one vhost. Is it normal?
> PD2: I'm not sure about the issue type, it might be a improvement or a bug?
> Anyone have similar problems?
> Any feedback will be appreciated.
> Thanks in advance and excuse my bad english.
> Regards,
> --
> kurt
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2012-05-10 23:58:27
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-149.
--------------------------------------
Resolution: Won't Fix
> It should be possible to define SecDataDir in other Scopes than Main
> --------------------------------------------------------------------
>
> Key: MODSEC-149
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-149
> Project: ModSecurity
> Issue Type: Improvement
> Security Level: Normal
> Components: Configuration
> Affects Versions: 2.5.12
> Reporter: Peter Meier
> Assignee: Breno Silva Pinto
> Fix For: 2.7.0
>
>
> If you are running apache with mod-itk [1] each vhost might run as own user, hence if you need to define a SecDataDir you need to make this data directroy global writeable, which is not that nice.
> It might be nicer to be able to define SecDataDir per vhost and hence have a directory that can only be written and READ by the user that the current vhost is running with.
> [1] http://mpm-itk.sesse.net/
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2012-05-10 23:56:28
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-276.
--------------------------------------
Resolution: Fixed
> Add RuleRemoveByMsg ctl action
> ------------------------------
>
> Key: MODSEC-276
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-276
> Project: ModSecurity
> Issue Type: New Feature
> Security Level: Normal
> Components: Actions
> Reporter: Jamuse
> Assignee: Breno Silva Pinto
> Priority: High
> Fix For: 2.7.0
>
>
> It would be nice to be able to use ModSecurity's built in whitelisting mechanism to bypass rules, when the rule does not have an ID and adjusting the anomaly score is not an option. In order to create a rule that first matches the parameter we want to check and then remove the rule based on the message, a ctl:RuleRemoveByMsg option is required.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2012-05-10 23:56:25
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-157.
--------------------------------------
Resolution: Fixed
> In SecDefaultAction, logdata is deprecated
> ------------------------------------------
>
> Key: MODSEC-157
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-157
> Project: ModSecurity
> Issue Type: Improvement
> Security Level: Normal
> Components: Core
> Affects Versions: 2.5.12
> Reporter: Marc Stern
> Assignee: Breno Silva Pinto
> Fix For: 2.7.0
>
>
> When using heuristic counters, it is very handy to be able to log them for each issue.
> It is possible by using "logdata" in "SecDefaultAction", but it is indicated as deprecated. It may thus disappear in the future (?).
> I see no reason to forbid this feature. This breaks the compatibility with existing environments), and can be considered as a regression.
> Thanks
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2012-05-10 23:56:25
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-218.
--------------------------------------
Resolution: Fixed
> Expanding directive scope locations
> -----------------------------------
>
> Key: MODSEC-218
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-218
> Project: ModSecurity
> Issue Type: Improvement
> Security Level: Normal
> Components: Configuration
> Reporter: Ryan Barnett
> Assignee: Breno Silva Pinto
> Fix For: 2.7.0
>
>
> Oftentimes there are different apps hosts (or proxies to) from apache. In order to minimize impedance mismatch issues, we need to be able to define multiple directive specifications (such as SecArgumentSeparator, SecCookieFormat, SecServerSignature) that can only be specified once in the Main configuration.
> These should be able to be specified within other Apache scope locations such a vhost, directory and location containers.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2012-05-10 23:56:25
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-69.
-------------------------------------
Resolution: Fixed
> Add a transformation to remove other styles comments.
> -----------------------------------------------------
>
> Key: MODSEC-69
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-69
> Project: ModSecurity
> Issue Type: Improvement
> Security Level: Normal
> Components: Transformations
> Reporter: Brian Rectanus
> Assignee: Breno Silva Pinto
> Fix For: 2.7.0
>
>
> Add a transformation (or extend existing) for removing other style comments:
> * <!-- ... -->
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2012-05-10 23:56:23
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-200.
--------------------------------------
Resolution: Fixed
> Add Link/Cookie Crypto Capabilities
> -----------------------------------
>
> Key: MODSEC-200
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-200
> Project: ModSecurity
> Issue Type: New Feature
> Security Level: Normal
> Components: Core
> Reporter: Ryan Barnett
> Assignee: Breno Silva Pinto
> Fix For: 2.7.0
>
>
> Add link/cookie crypto capabilities as described in the previous modsecurity mail-list posting -
> http://osdir.com/ml/apache.mod-security.user/2006-07/msg00031.html
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
10 messages has been excluded from this view by a project administrator.
