mod-security-developers — Development discussion about mod_security

[Mod-security-developers] [JIRA] Closed: (MODSEC-204) mlogc-batch-load.pl missing some entries

[Ryan B. (JIRA) <no...@mo...>]

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

Ryan Barnett closed MODSEC-204.
-------------------------------

    Resolution: Fixed

> mlogc-batch-load.pl missing some entries
> ----------------------------------------
>
>                 Key: MODSEC-204
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-204
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>          Components: Mlogc
>    Affects Versions: 2.5.13
>            Reporter: Jonathan Marcil
>            Assignee: Breno Silva Pinto
>             Fix For: 2.6.0
>
>
> Sometime I get events logged like "20110220-233130-TWHqogoUAMsAAD1lF@EAAAAE" as the filename.
> mlogc-batch-load.pl then miss it.
> In the source at line 45 I see the matching pattern for the file as :
> {code}/^\d{8}-\d+-\w{24}$/s{code}
> The solution is rater simple just change \w to . :
> {code}/^\d{8}-\d+-.{24}$/s{code}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Closed: (MODSEC-202) Order of execution not following Apache rules

[Ryan B. (JIRA) <no...@mo...>]

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

Ryan Barnett closed MODSEC-202.
-------------------------------

    Resolution: Won't Fix

As you stated, the Apache document may be a bit confusing but ModSecurity is handling it in the correct way.  We will try to also update our Reference Manual concerning rules processing and Apache Scope locations.

> Order of execution not following Apache rules
> ---------------------------------------------
>
>                 Key: MODSEC-202
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-202
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>          Components: Core
>    Affects Versions: 2.5.13
>            Reporter: Marc Stern
>            Assignee: Breno Silva Pinto
>
> SecAction "phase:2,pass,msg:'* global (1)'"
> <Location /test/test.html>
>  SecAction "phase:2,pass,msg:'* /test/html (1)'"
> </Location>
> <Location /test>
>  SecAction "phase:2,pass,msg:'* /test'"
> </Location>
> <Location /test/test.html>
>  SecAction "phase:2,pass,msg:'* /test/html (2)'"
> </Location>
> SecAction "phase:2,pass,msg:'* global (2)'"
> Following Apache rules (http://httpd.apache.org/docs/2.2/sections.html#mergin), the order of execution should be
>  global (1)
>  global (2)
>  /test
>  /test/html (1)
>  /test/html (2)
> However, the result is
>  Unconditional match in SecAction. [msg "* global (1)"] 
>  Unconditional match in SecAction. [msg "* global (2)"]
>  Unconditional match in SecAction. [msg "* /test/html (1)"]
>  Unconditional match in SecAction. [msg "* /test"]
>  Unconditional match in SecAction. [msg "* /test/html (2)"]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Closed: (MODSEC-148) Additional validation (verify) routines similar to verifyCC

[Ryan B. (JIRA) <no...@mo...>]

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

Ryan Barnett closed MODSEC-148.
-------------------------------

    Resolution: Fixed

> Additional validation (verify) routines similar to verifyCC
> -----------------------------------------------------------
>
>                 Key: MODSEC-148
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-148
>             Project: ModSecurity
>          Issue Type: New Feature
>      Security Level: Normal
>          Components: Operators
>            Reporter: Brian Rectanus
>            Assignee: Breno Silva Pinto
>             Fix For: 2.6.0
>
>
> Some additional verify routines to implement to help reduce FPs:
> @verifySSN: Verify the US Social Security Number ( "001"-"999"[ -]?"01"-"99"[ -]?"0001"-"9999" )
> What others?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Closed: (MODSEC-56) SecRuleRemoveById vs. ctl:ruleRemoveById order

[Ryan B. (JIRA) <no...@mo...>]

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

Ryan Barnett closed MODSEC-56.
------------------------------

    Resolution: Not a Bug

We added notes to the reference manual which specifies when to use before/after the target rule(s) -
https://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual#SecRuleRemoveById
https://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual#ctl

> SecRuleRemoveById vs. ctl:ruleRemoveById order
> ----------------------------------------------
>
>                 Key: MODSEC-56
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-56
>             Project: ModSecurity
>          Issue Type: Improvement
>      Security Level: Normal
>          Components: Core
>    Affects Versions: 2.5.9
>         Environment: Any
>            Reporter: Marc Stern
>            Assignee: Breno Silva Pinto
>             Fix For: 2.6.0
>
>
> SecRuleRemoveById needs to appear after the rule it disables, whereas ctl:ruleRemoveById must appear before.
> This is not only confusing, but also obliges to put some rules before and some after the rule to disable, which complexifies the management.
> Couldn't SecRuleRemoveById be supported before the rule, by storing the id in a table during config build?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Resolved: (MODSEC-181) ModSecurity causing 500 error codes for invalid requests even in DetectionOnly mode

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

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

Breno Silva Pinto resolved MODSEC-181.
--------------------------------------

    Resolution: Fixed

Fixed in 2.6.0. Thanks

> ModSecurity causing 500 error codes for invalid requests even in DetectionOnly mode
> -----------------------------------------------------------------------------------
>
>                 Key: MODSEC-181
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-181
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>          Components: Core
>    Affects Versions: 2.5.12
>         Environment: Linux / Apache 2.2.15
>            Reporter: Sampo Niskanen
>            Assignee: Breno Silva Pinto
>             Fix For: 2.6.0
>
>         Attachments: modsecurity-500-error.patch
>
>
> ModSecurity is causing certain invalid requests to always be logged as 500 Internal Server Error, even when in DetectionOnly mode.
> When a POST request is made to the server and the client disconnects before sending all of the payload (as indicated by the Content-Length header), ModSecurity causes the request to be logged as 500 internal server error and the following is logged into the Apache error log:
> [Thu Oct 21 05:35:51 2010] [error] [client xx.xx.xx.xx] ModSecurity: Error reading request body: End of file found [hostname "xx.yy.zz.com"] [uri "/foo/bar"] [unique_id "xx-yy-zz"]
> If ModSecurity is disabled (SecRuleEngine Off) this is logged as 200 OK and nothing is reported in the error log.  If ModSecurity is enabled even in DetectionOnly mode and SecRequestBodyAccess is on, this request becomes a 500 Internal Server Error.  This is a severe issue, since 500 errors are often monitored and cause alarms.  This defect means that an attacker can deterministically generate any amount of 500 errors on any server protected by ModSecurity.  ModSecurity itself should never generate a 500 error, since that indicates an error in the server, not in the request.
> I hunted the source of the error condition to the function read_request_body() in apache2_is.c and function hook_request_late() in mod_security2.c.  ModSecurity should handle the APR_EOF error code separately in read_request_body() and return some other return value than -1 (which causes hook_request_late() to generate the 500 error code).
> The only workaround seems to be to disable request body scanning, which limits the usefulness of ModSecurity severely.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Closed: (MODSEC-86) The SCRIPT_* family of variables is not valid in reverse proxy mode

[Ryan B. (JIRA) <no...@mo...>]

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

Ryan Barnett closed MODSEC-86.
------------------------------

    Resolution: Won't Fix

This is a rules issue.  If a user wants to use these variables - they should create a rule to warn if the variables are empty/non-existent.

> The SCRIPT_* family of variables is not valid in reverse proxy mode
> -------------------------------------------------------------------
>
>                 Key: MODSEC-86
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-86
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>          Components: Targets
>    Affects Versions: 2.5.10-dev2
>            Reporter: Ivan Ristic
>            Assignee: Breno Silva Pinto
>             Fix For: 2.6.0
>
>
> In a reverse proxy (phase 2), SCRIPT_FILENAME contains the backend URI. For example: proxy:http://192.168.3.111/phpinfo.php/123 While this may be useful, the information does not beling in SCRIPT_FILENAME.
> I think that we need to detect this case, pretend that SCRIPT_FILENAME does not exist (rule does not run) and emit a warning.
> I would do the same for PATH_INFO, which does not seem to be available in RP mode.
> I also think it might be useful to have a phase 2 flag to tell if the request is about to be proxied. Such a flag could be used to have some rules only run in one of the modes (i.e., embedded vs RP).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Closed: (MODSEC-104) Never block in detection mode

[Ryan B. (JIRA) <no...@mo...>]

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

Ryan Barnett closed MODSEC-104.
-------------------------------

    Resolution: Fixed

> Never block in detection mode
> -----------------------------
>
>                 Key: MODSEC-104
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-104
>             Project: ModSecurity
>          Issue Type: Improvement
>      Security Level: Normal
>          Components: Core
>            Reporter: Ivan Ristic
>            Assignee: Breno Silva Pinto
>             Fix For: 2.6.0
>
>
> It is counter-intuitive that ModSecurity blocks when the rule engine is configured with DetectionOnly (see MODSEC-36 for one user's opinion). ModSecurity will currently block if there's more inbound data that it is configured to handle, and if there is more outbound data than it is configured the handle and SecResponseBodyLimitAction is set to Reject. Here's what I propose:
> - Never block in detection mode
> - If SecResponseBodyLimitAction is set to Reject, in detection mode change that internally to ProcessPartial
> - If there's more inbound data than ModSecurity can handle, stop reading it and set a DATA_ERROR flag (we will probably need one flag for the inbound and another for the outbound, but that's a detail). The data already read will remain in a buffer so that it can be passed on later.
> - Future improvements that limit data processing in any way will not cause ModSecurity to block, but only to raise flags
> - Add one or more system rules to the default configuration to catch a raised DATA_ERROR flag

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Resolved: (MODSEC-203) Make sure ModSecurity can compile under Darwin

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

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

Breno Silva Pinto resolved MODSEC-203.
--------------------------------------

    Resolution: Fixed

Added a OS type checking at autotools and remove the undefied directive of libtool when we detected mac os.


> Make sure ModSecurity can compile under Darwin
> ----------------------------------------------
>
>                 Key: MODSEC-203
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-203
>             Project: ModSecurity
>          Issue Type: Improvement
>      Security Level: Normal
>          Components: Build System
>    Affects Versions: 2.6.0
>            Reporter: Breno Silva Pinto
>            Assignee: Breno Silva Pinto
>             Fix For: 2.6.0
>
>
> Had some compile problems under Darwin
> bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..  -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK    -I/usr/include/apache2  -I/usr/include/apr-1   -I/usr/include/apr-1 -I/usr/include/libxml2   -MT mod_security2_la-re_operators.lo -MD -MP -MF .deps/mod_security2_la-re_operators.Tpo -c -o mod_security2_la-re_operators.lo `test -f 're_operators.c' || echo './'`re_operators.c
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -I/usr/include/libxml2 -MT mod_security2_la-re_operators.lo -MD -MP -MF .deps/mod_security2_la-re_operators.Tpo -c re_operators.c  -fno-common -DPIC -o .libs/mod_security2_la-re_operators.o
> re_operators.c: In function 'msre_op_ipmatch_param_init':
> mod_security2.c: In function 'hook_request_late':
> mod_security2.c:806: warning: format '%d' expects type 'int', but argument 3 has type 'apr_size_t'
> mod_security2.c: In function 'sec_guardian_logger':
> mod_security2.c:916: warning: format '%ld' expects type 'long int', but argument 4 has type 'long long int'
> apache2_io.c: In function 'input_filter':
> apache2_io.c:69: warning: format '%ld' expects type 'long int', but argument 6 has type 'apr_off_t'
> apache2_io.c: In function 'inject_content_to_of_brigade':
> apache2_io.c:474: warning: format '%d' expects type 'int', but argument 4 has type 'apr_size_t'
> e_operators.c: In function 'msre_op_ipmatch_param_init':
> re_operators.c:195: error: 'struct in6_addr' has no member named '__in6_u'
> re_operators.c:199: error: 'struct in6_addr' has no member named '__in6_u'
> re_operators.c:200: error: 'struct in6_addr' has no member named '__in6_u'
> re_operators.c:204: error: 'struct in6_addr' has no member named '__in6_u'
> re_operators.c:209: error: 'struct in6_addr' has no member named '__in6_u'
> re_operators.c:209: error: 'struct in6_addr' has no member named '__in6_u'
> re_operators.c:247: error: 'struct in6_addr' has no member named '__in6_u'
> re_operators.c:251: error: 'struct in6_addr' has no member named '__in6_u'
> re_operators.c:252: error: 'struct in6_addr' has no member named '__in6_u'
> re_operators.c:256: error: 'struct in6_addr' has no member named '__in6_u'
> re_operators.c:261: error: 'struct in6_addr' has no member named '__in6_u'
> re_operators.c:261: error: 'struct in6_addr' has no member named '__in6_u'
> re_operators.c: In function 'msre_op_ipmatch_execute':
> re_operators.c:395: error: 'struct in6_addr' has no member named '__in6_u'
> re_operators.c:395: error: 'struct in6_addr' has no member named '__in6_u'
> re_operators.c:396: error: 'struct in6_addr' has no member named '__in6_u'
> make[2]: *** [mod_security2_la-re_operators.lo] Error 1

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Resolved: (MODSEC-57) Disable a rule for one particular argument

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

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

Breno Silva Pinto resolved MODSEC-57.
-------------------------------------

    Resolution: Fixed

Now we have

ctl:ruleUpdateTargetById
ctl syntax to append is - ruleID;append_value
multiple append values -ruleID;append_value1,append_value2,append_value3
and with the directive SecRuleUpdateTargetById replaced values are separated by a space instead of a ;

   the same for replace (ctl and SecRuleUpdateTargetById) as a third parameter:
 ruleID;append_value;replace_valed
 ruleID;append_value1,append_value2,append_value3;replace_value


> Disable a rule for one particular argument
> ------------------------------------------
>
>                 Key: MODSEC-57
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-57
>             Project: ModSecurity
>          Issue Type: Improvement
>      Security Level: Normal
>          Components: Core
>    Affects Versions: 2.5.9
>         Environment: Any
>            Reporter: Marc Stern
>            Assignee: Breno Silva Pinto
>             Fix For: 2.6.0
>
>
> There is no way to disable a rule for one particular argument (or header,...).
> Let's suppose you want to disable one core rule for one particular argument in one of your page. The only solution is to disable the rule for all arguments, which would be a security hole. Obviously, you could clone the original rule with an exception for that argument, but that means that you need to maitain yourself a copy of the core rule.
> Obviously, the core rule is just an example; you have that problem with any "framework" you build.
> Duplicating rules is a big management issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Closed: (MODSEC-146) New sanitize functions

[Ryan B. (JIRA) <no...@mo...>]

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

Ryan Barnett closed MODSEC-146.
-------------------------------

    Resolution: Fixed

> New sanitize functions
> ----------------------
>
>                 Key: MODSEC-146
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-146
>             Project: ModSecurity
>          Issue Type: New Feature
>      Security Level: Normal
>          Components: Actions
>            Reporter: Brian Rectanus
>            Assignee: Breno Silva Pinto
>            Priority: High
>             Fix For: 2.6.0
>
>
> Need some new sanitize functions that will work with large data...
> sanitizeMatchedBytes -- This would x out only the bytes that matched.
> sanitizeMatchedBytes:1/4 -- This would x out the bytes that matched, but keep the first byte and last 4 bytes.
> This will only be able to work on un-transformed data.  If the data is transformed, then it should result the same as if sanitizeMatched was used.
> Others?
> Consider that we may add functionality that may alter the response data (i.e. x out CC numbers, etc) in the future.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Closed: (MODSEC-147) Basic streaming detection on raw request/response

[Ryan B. (JIRA) <no...@mo...>]

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

Ryan Barnett closed MODSEC-147.
-------------------------------

    Resolution: Fixed

> Basic streaming detection on raw request/response
> -------------------------------------------------
>
>                 Key: MODSEC-147
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-147
>             Project: ModSecurity
>          Issue Type: New Feature
>      Security Level: Normal
>          Components: Core
>            Reporter: Brian Rectanus
>            Assignee: Breno Silva Pinto
>             Fix For: 2.6.0
>
>
> I'd like to begin the process of streaming inspection.  Initially only on the raw request and response (i.e. connection level filter data).
> See MODSEC-17 and MODSEC-18 for the basic ideas.
> Here, I only want these to work:
> SecStreamInspect REQUEST "@pmf huge-prequal-list.dat" "nolog,pass,setvar:TX.prequal=1"
> SecStreamInspect RESPONSE "@verifyCC \b(\d{13,16})\b" "log,drop,msg='CC# detected in response',sanitizeMatchedBytes"
> Or maybe these are better:
> SecRule STREAM_REQUEST "@pmf huge-prequal-list.dat" "phase:rawrequest,nolog,pass,setvar:TX.prequal=1"
> SecRule STREAM_RESPONSE "@verifyCC \b(\d{13,16})\b" "phase:rawresponse,log,drop,msg='CC# detected in response',sanitizeMatchedBytes"
> sanitizeMatchedBytes (MODSEC-146) MUST sanitize (x out) all of the bytes that matched.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Closed: (MODSEC-140) Add a fast IP address and network based matching operator

[Ryan B. (JIRA) <no...@mo...>]

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

Ryan Barnett closed MODSEC-140.
-------------------------------

    Resolution: Fixed

> Add a fast IP address and network based matching operator
> ---------------------------------------------------------
>
>                 Key: MODSEC-140
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-140
>             Project: ModSecurity
>          Issue Type: New Feature
>      Security Level: Normal
>            Reporter: Brian Rectanus
>            Assignee: Breno Silva Pinto
>             Fix For: 2.6.0
>
>
> We need to be able to match IPs and networks quickly, including large lists.
> Something like:
> @ip <ip | ip/cidr | ip/netmask>, ...
> This would match if the target was listed in any ip or network.
> This must support both IPv4 and IPv6.
> I am thinking radix tree and/or modifying @pm to support IPs (former sounds better right now).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Closed: (MODSEC-196) GeoIP mistake

[Ryan B. (JIRA) <no...@mo...>]

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

Ryan Barnett closed MODSEC-196.
-------------------------------

    Resolution: Fixed

Changed Security Level to Normal

> GeoIP mistake
> -------------
>
>                 Key: MODSEC-196
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-196
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>          Components: Transformations
>    Affects Versions: 2.5.13
>         Environment: All
>            Reporter: Marc Stern
>            Assignee: Breno Silva Pinto
>             Fix For: 2.6.0
>
>
> Internal  addresses are reported as "Congo":
>   127.0.0.1
>   10.*

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Closed: (MODSEC-184) New RegEx operator that allows for data substitution

[Ryan B. (JIRA) <no...@mo...>]

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

Ryan Barnett closed MODSEC-184.
-------------------------------

    Resolution: Fixed

changed Security level to normal

> New RegEx operator that allows for data substitution
> ----------------------------------------------------
>
>                 Key: MODSEC-184
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-184
>             Project: ModSecurity
>          Issue Type: New Feature
>      Security Level: Normal
>          Components: Operators
>    Affects Versions: 2.5.13
>            Reporter: Ryan Barnett
>            Assignee: Breno Silva Pinto
>            Priority: High
>             Fix For: 2.6.0
>
>
> Currently, the PCRE engine in ModSecurity is *matching only*.  It would be useful to have a new operator that would allow for a data substitution expression.  This data modification capability may only be doable once we implement stream inspection mode (https://www.modsecurity.org/tracker/browse/MODSEC-147) and act as a Filter.  If we do, then we could use a rule like this -
> SecRule STREAM_RESPONSE "@rx_sub s/<!-.*-->//g" "phase:rawresponse,t:none,log,pass,msg:'Removed HTML Comment Data.'"
> This would use the @rx_sub operator to do data substitution and strip out raw data from the response body.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Closed: (MODSEC-184) New RegEx operator that allows for data substitution

[Ryan B. (JIRA) <no...@mo...>]

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

Ryan Barnett closed MODSEC-184.
-------------------------------

    Resolution: Fixed

> New RegEx operator that allows for data substitution
> ----------------------------------------------------
>
>                 Key: MODSEC-184
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-184
>             Project: ModSecurity
>          Issue Type: New Feature
>      Security Level: Normal
>          Components: Operators
>    Affects Versions: 2.5.13
>            Reporter: Ryan Barnett
>            Assignee: Breno Silva Pinto
>            Priority: High
>             Fix For: 2.6.0
>
>
> Currently, the PCRE engine in ModSecurity is *matching only*.  It would be useful to have a new operator that would allow for a data substitution expression.  This data modification capability may only be doable once we implement stream inspection mode (https://www.modsecurity.org/tracker/browse/MODSEC-147) and act as a Filter.  If we do, then we could use a rule like this -
> SecRule STREAM_RESPONSE "@rx_sub s/<!-.*-->//g" "phase:rawresponse,t:none,log,pass,msg:'Removed HTML Comment Data.'"
> This would use the @rx_sub operator to do data substitution and strip out raw data from the response body.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Closed: (MODSEC-180) Support setvar using Lua API

[Ryan B. (JIRA) <no...@mo...>]

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

Ryan Barnett closed MODSEC-180.
-------------------------------

    Resolution: Fixed

Changed Security Level to Normal

> Support setvar using Lua API
> ----------------------------
>
>                 Key: MODSEC-180
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-180
>             Project: ModSecurity
>          Issue Type: New Feature
>      Security Level: Normal
>          Components: Core
>    Affects Versions: 2.5.13
>            Reporter: Breno Silva PInto
>            Assignee: Breno Silva PInto
>             Fix For: 2.5.13
>
>
> We must support setvar into LUA API. It must allow buffers to be inserted back into modsecurity core using a collection. Also getvar(s) must be able to access the new var created by setvar

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Closed: (MODSEC-185) Redirect action is not working with chained rules

[Ryan B. (JIRA) <no...@mo...>]

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

Ryan Barnett closed MODSEC-185.
-------------------------------

    Resolution: Fixed

Changed Security Level to Normal

> Redirect action is not working with chained rules
> -------------------------------------------------
>
>                 Key: MODSEC-185
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-185
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>          Components: Actions
>    Affects Versions: 2.5.12
>            Reporter: Breno Silva Pinto
>            Assignee: Breno Silva Pinto
>            Priority: High
>             Fix For: 2.5.13
>
>
> Rule:
> SecRule REQUEST_URI "^([^=\.]+\..*$)" "phase:1,chain,t:none,redirect:https://www.xxxxx.com%{REQUEST_FILENAME},status:301 <https://www.xxxx.com%{REQUEST_FILENAME},status:301> "
> SecRule REQUEST_URI "!^/images/.*\.(gif|GIF|jpg|JPG|png|ico|bmp|wbmp)$" chain
> SecRule REQUEST_URI "!/(bnr|btn|icon|logo|promo|scr)/.*\.(gif|GIF|jpg|JPG|png|ico|bmp|wbmp)$" chain
> SecRule REQUEST_URI "!/zh/co/logo_150x40.gif$" chain
> SecRule REQUEST_URI "!/en_US/mid.swf$" chain
> SecRule REQUEST_URI "!/js/tns/mid.js$" chain
> SecRule REQUEST_URI "!/wsdl/C/Components.xsd$" chain
> SecRule REQUEST_URI "!/wsdl/C/Types.xsd$" chain
> SecRule REQUEST_URI "!/wsdl/M/Svc.wsdl$" chain
> SecRule REQUEST_URI "!/wsdl/C/Public/Types.xsd$" chain
> SecRule REQUEST_URI "!/wsdl/M/endpoints.xml$"
> The problem we're getting is the 301 we get looks like this:
> HTTP/1.1 301 Moved Permanently
> Date: Fri, 12 Nov 2010 05:49:24 GMT
> Server: Apache
> Location: https://www.xxxxx.com%{REQUEST_FILENAME} <https://www.xxxxx.com%{REQUEST_FILENAME}>  <https://www.xxxxx.com%{REQUEST_FILENAME} <https://www.xxxxxobjects.com%{REQUEST_FILENAME}> > 
> Content-Length: 256
> Content-Type: text/html; charset=iso-8859-1
> <snip>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Closed: (MODSEC-196) GeoIP mistake

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

On 2/23/11 3:07 PM, "Mod Blogadmin" <no...@mo...> wrote:

>
>     [
>https://www.modsecurity.org/tracker/browse/MODSEC-196?page=com.atlassian.j
>ira.plugin.system.issuetabpanels:all-tabpanel ]
>
>Ryan Barnett closed MODSEC-196.
>-------------------------------
>
>    Resolution: Fixed
>
>Changed Security Level to Normal
>
>> GeoIP mistake
>> -------------
>>
>>                 Key: MODSEC-196
>>                 URL:
>>https://www.modsecurity.org/tracker/browse/MODSEC-196
>>             Project: ModSecurity
>>          Issue Type: Bug
>>      Security Level: Normal
>>          Components: Transformations
>>    Affects Versions: 2.5.13
>>         Environment: All
>>            Reporter: Marc Stern
>>            Assignee: Breno Silva Pinto
>>             Fix For: 2.6.0
>>
>>
>> Internal  addresses are reported as "Congo":
>>   127.0.0.1
>>   10.*
>
>--
>This message is automatically generated by JIRA.
>-
>If you think it was sent incorrectly contact one of the administrators:
>https://www.modsecurity.org/tracker/secure/Administrators.jspa
>-
>For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>


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

[Mod-security-developers] [JIRA] Closed: (MODSEC-186) Add SecReadStateLimit option to control the number os BUSY state connections (

[Ryan B. (JIRA) <no...@mo...>]

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

Ryan Barnett closed MODSEC-186.
-------------------------------

    Resolution: Fixed

Changed Security Level to Normal

> Add SecReadStateLimit option to control the number os BUSY state connections (
> ------------------------------------------------------------------------------
>
>                 Key: MODSEC-186
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-186
>             Project: ModSecurity
>          Issue Type: New Feature
>      Security Level: Normal
>          Components: Core
>    Affects Versions: 2.5.12
>            Reporter: Breno Silva Pinto
>            Assignee: Breno Silva Pinto
>             Fix For: 2.5.13
>
>
> We are going to test a new option "SecReadStateLimit"  to control the number of connections in Busy state. It will help to mitigate the slowloris attack

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Re: [Mod-security-developers] [mod-security-users] Stepping Down From the ModSecurity Team

[Sergio <se...@gm...>]

Good luck and thank you for your support when I needed.

Best Regards,

Sergio Cabrera

On Fri, Jul 23, 2010 at 10:16 AM, Brian Rectanus <bre...@gm...> wrote:

> All,
>
> I wanted to let everyone know that today is my last day working for
> Breach Security/Trustwave and  I am stepping down from my role in
> ModSecurity.  Trustwave's Spider Labs will be continuing the
> ModSecurity project.  Please see my blog...
>
> http://blog.modsecurity.org/2010/07/modsecurity-has-a-new-home.html
>
> It has been fantastic working with everyone in the community and I
> look forward to continuing, just with a different role.
>
> -B
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Appliances, Rule Sets and Support:
> http://www.modsecurity.org/breach/index.html
>

[Mod-security-developers] Stepping Down From the ModSecurity Team

[Brian R. <bre...@gm...>]

All,

I wanted to let everyone know that today is my last day working for
Breach Security/Trustwave and  I am stepping down from my role in
ModSecurity.  Trustwave's Spider Labs will be continuing the
ModSecurity project.  Please see my blog...

http://blog.modsecurity.org/2010/07/modsecurity-has-a-new-home.html

It has been fantastic working with everyone in the community and I
look forward to continuing, just with a different role.

-B

Re: [Mod-security-developers] Is there are a reason for phase 5 to execute prior to Apache logging?

[Ivan R. <iva...@gm...>]

On Fri, Dec 11, 2009 at 6:52 PM, Brian Rectanus <bre...@gm...> wrote:
> On Fri, Dec 11, 2009 at 10:14 AM, Ivan Ristic <iva...@gm...> wrote:
>> I have a few rules that set environment variables, which are then used
>> in logging (via "{VARNAME}e"), but it is impossible to set environment
>> variables from ModSecurity's phase 5 before it takes place after
>> Apache's logging.
>>
>> Is there are a reason for phase 5 to execute prior to Apache logging,
>> or can we move phase 5 later?
>
> Actually, I would rather do it after apache logging anyhow.

I am sorry, I messed up my original email. Phase 5 is executed _after_
log_config at the moment, and that makes it impossible for an
environment variable defined in phase 5 to be logged via log_config.

Thus I was asking to move phase 5 _before_ log_config.


> Right now
> it does not really work to look at the log contents and this (I
> think?) would allow that better.

How would you look at it?


> Also, it may be better to see
> Apache's error log prior to ModSecurity's as many times the Apache
> error has caused the ModSecurity one (client disconnects, etc) and
> this would make that a bit more clear.

I think Apache will log to error log as needed (i.e., it will not wait
for its logging phase to log all error message).

>
> -B
>
> ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
>



-- 
Ivan Ristic
ModSecurity Handbook [https://www.feistyduck.com]
SSL Labs [https://www.ssllabs.com/ssldb/]

Re: [Mod-security-developers] Is there are a reason for phase 5 to execute prior to Apache logging?

[Brian R. <bre...@gm...>]

On Fri, Dec 11, 2009 at 10:14 AM, Ivan Ristic <iva...@gm...> wrote:
> I have a few rules that set environment variables, which are then used
> in logging (via "{VARNAME}e"), but it is impossible to set environment
> variables from ModSecurity's phase 5 before it takes place after
> Apache's logging.
>
> Is there are a reason for phase 5 to execute prior to Apache logging,
> or can we move phase 5 later?

Actually, I would rather do it after apache logging anyhow.  Right now
it does not really work to look at the log contents and this (I
think?) would allow that better.  Also, it may be better to see
Apache's error log prior to ModSecurity's as many times the Apache
error has caused the ModSecurity one (client disconnects, etc) and
this would make that a bit more clear.

-B

[Mod-security-developers] Is there are a reason for phase 5 to execute prior to Apache logging?

[Ivan R. <iva...@gm...>]

I have a few rules that set environment variables, which are then used
in logging (via "{VARNAME}e"), but it is impossible to set environment
variables from ModSecurity's phase 5 before it takes place after
Apache's logging.

Is there are a reason for phase 5 to execute prior to Apache logging,
or can we move phase 5 later?

-- 
Ivan Ristic
ModSecurity Handbook [https://www.feistyduck.com]
SSL Labs [https://www.ssllabs.com/ssldb/]

[Mod-security-developers] Moving phase 1 to use the same Apache hook as phase 2?

[Ivan R. <iva...@gm...>]

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

-- 
Ivan Ristic
Security assessment of your SSL servers
https://www.ssllabs.com/ssldb/