mod-security-developers — Development discussion about mod_security

[Mod-security-developers] [JIRA] Resolved: (MODSEC-183) Denying on RESPONSE_STATUS != 200 leads to broken error page

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

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

Breno Silva Pinto resolved MODSEC-183.
--------------------------------------

    Resolution: Cannot Reproduce

> Denying on RESPONSE_STATUS != 200 leads to broken error page
> ------------------------------------------------------------
>
>                 Key: MODSEC-183
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-183
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>          Components: Core
>    Affects Versions: 2.5.12
>         Environment: RHEL 5.3, Apache 2.2.16, mod_security 2.5.12, mod_fcgid 2.3.6
>            Reporter: Edgar Frank
>            Assignee: Breno Silva Pinto
>             Fix For: 2.6.4
>
>
> Denying a request (e.g. r->status == 500) in phase 3 with RESPONSE_STATUS and status:403 leads to a broken error page. (you want this setup to disguise application specific error behaviour)
> When mod_security denies such a request, it sends an error bucket with e.g. code 403 down the output filter chain, leaving r->status as is (e.g. 500).
> Finally, ap_die kicks in and tries to generate an error page. As r->status is != HTTP_OK (200) and ap_die is called with an error code, it regards this as a recursive error, thus disabling a custom error page and choosing the builtin one. (some thing like "an error occured, additionally a 403 occured while trying to handle the ErrorDocument"). See ap_die in http_protocol.c in modules/http of httpd.
> First, you have no chance to present a custom error page. It will always look awkward, if a customer sees such a site.
> Second, this presents a possible information disclosure and defeating the purpose of what you wanted to set up. Because of this point, I chose to set the severity to major.
> I understand that ap_die is designed to work with internal redirects and we're in an unfortunate situation, as we're already in the output filter chain. But on the other hand, as ap_die is effectively called with the information mod_security provided, mod_security should cope with its API.
> My naive first approach would be to set r->status to 200 in send_error_bucket, but I can't judge the side effects of this.

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

        

[Mod-security-developers] [JIRA] Resolved: (MODSEC-285) The allow action does not behave as expected in detection-only mode

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

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

Breno Silva Pinto resolved MODSEC-285.
--------------------------------------

    Resolution: Not a Bug

Allow is a disruptive action. The documentation says : .. "Disruptive actions will NOT be executed if the SecRuleEngine is set to DetectionOnly... " 

So this behavior is expected. User should use ctl:SecRuleEngine=On if necessary to execute any kind of disruptive action

> The allow action does not behave as expected in detection-only mode
> -------------------------------------------------------------------
>
>                 Key: MODSEC-285
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-285
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>          Components: Actions
>            Reporter: Ivan Ristic
>            Assignee: Breno Silva Pinto
>             Fix For: 2.6.4
>
>
> The allow action does not do anything in detection-only mode. When a match occurs, processing continues with the next rule as if pass was specified.

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

        

[Mod-security-developers] [JIRA] Resolved: (MODSEC-281) the logdata action cuts of long data without closing the message with a "]

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

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

Breno Silva Pinto resolved MODSEC-281.
--------------------------------------

    Resolution: Fixed

> the logdata action cuts of long data without closing the message with a "]
> --------------------------------------------------------------------------
>
>                 Key: MODSEC-281
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-281
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>          Components: Actions
>    Affects Versions: 2.6.3
>            Reporter: Jamuse
>            Assignee: Breno Silva Pinto
>             Fix For: 2.6.4
>
>
> The logdata action cuts off matched text at an "undocumented"? point. When the message is cut off due to its length, ModSecurity does not append an double-quote square-bracket to close the section, which makes it difficult to parse. The following snippit demonstrates the issue, notice there is no closing quote or bracket after the the work "amenit" on the second to last line below:
> --951ef57e-H--
> Message: Access denied with code 403 (phase 2). Pattern match "(?i:(?:(\"|'|`|\xc2\xb4|\xe2\x80\x99|\xe2\x80\x98)\\s+and\\s*=\\W)|(?:\\(\\s*select\\s*\\w+\\s*\\()|(?:\\*\\/from)|(?:\\+\\s*\\d+\\s*\\+\\s*@)|(?:\\w(\"|'|`|\xc2\xb4|\xe2\x80\x99|\xe2\x80\x98)\\s*(?:[-+=|@]+\\s*)+[\\d(])|(?:coalesce\\s*\\(|@@\\w+\\s*[^ ..." at ARGS:ctl00$ctl00$SpecContent$memberEnquiries_4$txtComments. [file "/opt/modsecurity/etc/crs/base_rules/modsecurity_crs_41_sql_injection_attacks.conf"] [line "561"] [id "981249"] [msg "Detects chained SQL injection attempts 2/2"] [data " case you are interested in 100 percent free passes for your self, and also partner prices, and upgrades \x0d\x0a \x0d\x0aThrough Exactly how much consumer credit rating you need towards the scholarships you\xe2\x80\x99re concerned inOff-site airport parking is often a bonus with regard to travelers. Usually many demonstrate to be much less expensive compared to airport parking tons jog by way of international airports and internet based bargains and also other amenit
> Action: Intercepted (phase 2)

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

       

Re: [Mod-security-developers] SecWriteStateLimit Logging

[Anestis B. <bec...@gm...>]

Appreciate the response Ryan.

No they are not false positives as indicated by the analyzed network
traffic matching the attack pattern.

Thanks for the info regarding the logging features.


Kind Regards,
Anestis Bechtsoudis

On 01/09/2012 06:59 PM, Ryan Barnett wrote:
> Can you confirm that you are under an active attack?  You may need to
> modify the SecWriteStateLimit settings if you are finding that you are
> having false positives.  Since these log messages are generated from a
> directive and not a rule, we don't have any options for altering logging
> or response actions.  It is hard coded to generate the alert for each
> thread that is is terminating.
> 
> --
> Ryan Barnett
> Senior Security Researcher
> Trustwave - SpiderLabs
> 
> 
> 
> On 1/9/12 7:16 AM, "Anestis Bechtsoudis" <bec...@gm...> wrote:
> 
>> Hello list,
>>
>> recently applied the SecWriteStateLimit workaround for slow HTTP read
>> DoS attack, as proposed from spiderlabs [1]. Although, we face a great
>> logging overhead on our servers originating from such attacks.
>>
>> Is there any method to limit the logging events at the error_log that am
>> I missing? Searching the list archives didn't show up something relevant.
>>
>> Speaking about Version 2.2.3.
>>
>>
>>
>> Kind Regards,
>> Anestis
>>
>>
>> [1]
>> http://blog.spiderlabs.com/2012/01/modsecurity-advanced-topic-of-the-week-
>> mitigation-of-slow-read-denial-of-service-attack.html
>> --
>> ===============================================
>> * Anestis Bechtsoudis                         *
>> *                                             *
>> * Network Operation Center                    *
>> * Dept. of Computer Engineering & Informatics *
>> * University of Patras, Greece                *
>> *                                             *
>> * Website: http://bechtsoudis.com             *
>> ===============================================
>>
>> --------------------------------------------------------------------------
>> ----
>> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
>> infrastructure or vast IT resources to deliver seamless, secure access to
>> virtual desktops. With this all-in-one solution, easily deploy virtual
>> desktops for less than the cost of PCs and save 60% on VDI infrastructure
>> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
>> _______________________________________________
>> 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
>>
> 
> 
> 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.
> 
> 
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual 
> desktops for less than the cost of PCs and save 60% on VDI infrastructure 
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php

Re: [Mod-security-developers] SecWriteStateLimit Logging

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

Can you confirm that you are under an active attack?  You may need to
modify the SecWriteStateLimit settings if you are finding that you are
having false positives.  Since these log messages are generated from a
directive and not a rule, we don't have any options for altering logging
or response actions.  It is hard coded to generate the alert for each
thread that is is terminating.

--
Ryan Barnett
Senior Security Researcher
Trustwave - SpiderLabs



On 1/9/12 7:16 AM, "Anestis Bechtsoudis" <bec...@gm...> wrote:

>Hello list,
>
>recently applied the SecWriteStateLimit workaround for slow HTTP read
>DoS attack, as proposed from spiderlabs [1]. Although, we face a great
>logging overhead on our servers originating from such attacks.
>
>Is there any method to limit the logging events at the error_log that am
>I missing? Searching the list archives didn't show up something relevant.
>
>Speaking about Version 2.2.3.
>
>
>
>Kind Regards,
>Anestis
>
>
>[1]
>http://blog.spiderlabs.com/2012/01/modsecurity-advanced-topic-of-the-week-
>mitigation-of-slow-read-denial-of-service-attack.html
>--
>===============================================
>* Anestis Bechtsoudis                         *
>*                                             *
>* Network Operation Center                    *
>* Dept. of Computer Engineering & Informatics *
>* University of Patras, Greece                *
>*                                             *
>* Website: http://bechtsoudis.com             *
>===============================================
>
>--------------------------------------------------------------------------
>----
>Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
>infrastructure or vast IT resources to deliver seamless, secure access to
>virtual desktops. With this all-in-one solution, easily deploy virtual
>desktops for less than the cost of PCs and save 60% on VDI infrastructure
>costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
>_______________________________________________
>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
>


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] SecWriteStateLimit Logging

[Anestis B. <bec...@gm...>]

Hello list,

recently applied the SecWriteStateLimit workaround for slow HTTP read
DoS attack, as proposed from spiderlabs [1]. Although, we face a great
logging overhead on our servers originating from such attacks.

Is there any method to limit the logging events at the error_log that am
I missing? Searching the list archives didn't show up something relevant.

Speaking about Version 2.2.3.



Kind Regards,
Anestis


[1]
http://blog.spiderlabs.com/2012/01/modsecurity-advanced-topic-of-the-week-mitigation-of-slow-read-denial-of-service-attack.html
-- 
===============================================
* Anestis Bechtsoudis                         *
*                                             *
* Network Operation Center                    *
* Dept. of Computer Engineering & Informatics *
* University of Patras, Greece                *
*                                             *
* Website: http://bechtsoudis.com             *
===============================================

[Mod-security-developers] [JIRA] Resolved: (MODSEC-227) gsbLookup does not perform canonicalization and lookups correctly

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

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

Breno Silva Pinto resolved MODSEC-227.
--------------------------------------

    Fix Version/s: 2.6.0
                       (was: 2.7.0)
       Resolution: Fixed

> gsbLookup does not perform canonicalization and lookups correctly
> -----------------------------------------------------------------
>
>                 Key: MODSEC-227
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-227
>             Project: ModSecurity
>          Issue Type: Improvement
>      Security Level: Normal
>          Components: Operators
>    Affects Versions: 2.6.0
>            Reporter: Ivan Ristic
>            Assignee: Breno Silva Pinto
>             Fix For: 2.6.0
>
>
> The gsbLookup operator does not perform canonicalization correctly. The example from the Safe Browsing manual (http://a.b.c/1/2.html?param=1) results in two lookups:
> GSB: Successfully extracted url: a.B.c/1/2.Html?param=1
> GSB: Canonicalize url #2: a.B.c/
> whereas the manual specifies many more:
> a.b.c/1/2.html?param=1
> a.b.c/1/2.html
> a.b.c/
> a.b.c/1/
> b.c/1/2.html?param=1
> b.c/1/2.html
> b.c/
> b.c/1/
> Also notice that gsbLookup does not currently transform input to lowercase (but it should).

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

        

[Mod-security-developers] [JIRA] Resolved: (MODSEC-137) mlogc conf file should default

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

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

Breno Silva Pinto resolved MODSEC-137.
--------------------------------------

    Resolution: Won't Fix

> mlogc conf file should default
> ------------------------------
>
>                 Key: MODSEC-137
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-137
>             Project: ModSecurity
>          Issue Type: Improvement
>      Security Level: Normal
>          Components: Mlogc
>    Affects Versions: 2.5.12
>         Environment: Windows (applies to any platform) - mod_security-2.5.12
>            Reporter: Tom Donovan
>            Assignee: Breno Silva Pinto
>            Priority: Wish
>             Fix For: 2.7.0
>
>
> It requires a .bat file to pass command arguments to a piped log on Windows.  If argc < 2  (i.e. piped to just the program name) it would be better to default to a config file in the standard Apache conf/ directory.  The -h switch can still be used for the usage display.
> in apache2\mlogc-src\mlogc.c  function main()
>     /* Conf file is last - defaults to conf directory */
>     if (argc < 2)
>         conffile = "../conf/mlogc.conf";
>     else
>         conffile = argv[argc - 1];
> This presumes that mlogc.exe ( or mlogc on Unix) is in the Apache bin/ directory and that the config file is in conf/mlogc.conf.
> This code should be removed:
>     if (argc < 2) {
>         usage();
>         logc_shutdown(1);
>     }

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

        

[Mod-security-developers] [JIRA] Resolved: (MODSEC-282) Fix regex for section A in mlogc-batch-load.pl

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

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

Breno Silva Pinto resolved MODSEC-282.
--------------------------------------

    Resolution: Fixed

> Fix regex for section A in mlogc-batch-load.pl
> ----------------------------------------------
>
>                 Key: MODSEC-282
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-282
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>          Components: Mlogc
>    Affects Versions: 2.6.3
>            Reporter: ebrahim khalilzadeh
>            Assignee: Breno Silva Pinto
>             Fix For: 2.6.4
>
>


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

        

Re: [Mod-security-developers] mlogc-batch-load rex problem in section A

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

Created MODSEC-282

On Mon, Jan 2, 2012 at 9:57 AM, Breno Silva <bre...@gm...> wrote:

> Hi Ebrahim,
>
> Thanks for your feedback. There was a problem in modsecurity timestamp
> math and i was changed in 2.6.3.
>
> Any chance you send me a patch ?
>
> Thanks
>
> Breno
>
> On Mon, Jan 2, 2012 at 9:41 AM, Ebrahim Khalilzadeh <kha...@au...
> > wrote:
>
>>
>> Hi,
>> Due to some problems about piping mlogc with apache, i decided to use
>> mlogc-batch-load.pl on crontab. I installed modsecurity-apache_2.6.2 and
>> it works correctly and generates audit log files like this:
>>
>> --3f82651b-A--
>> [01/Jan/2012:15:11:28 +031800] 8lbP5n8AAAIAABL0J7gAAAAD 172.20.125.77
>> 22409 172.20.125.126 80
>> --3f82651b-B--
>> GET /%3Cscript%3Etest%3C/script%3E HTTP/1.1
>>
>> Then i ran mlogc-batch-load.pl which It couldn't send audit logs to
>> AuditConsole and it generated some error like this:
>>
>> [Mon Jan 02 17:41:33 2012] [2] [28961/80d4e50] Invalid entry (failed to
>> match regex): waf - - - - \"GET /%3Cscript%3Etest%3C/script%3E HTTP/1.1\"
>> 500 602 \"-\" \"-\" - \"-\"
>> /20120102/20120102-1714/20120102-171401-xm8Xqn8AAAIAAG9lIs8AAAAD 0 1653
>> md5:e7fe62f1bf231a6993e5623a7b872b61
>>
>> I installed modsecurity-apache_2.6.3 and it generated audit log files
>> like this:
>>
>> --cc123a05-A--
>> [02/Jan/2012:17:14:01 +0330] xm8Xqn8AAAIAAG9lIs8AAAAD 172.20.125.77 36872
>> 172.20.125.126 80
>> --cc123a05-B--
>> GET /%3Cscript%3Etest%3C/script%3E HTTP/1.1
>>
>> i ran mlogc-batch-load.pl and same error was generated.
>>
>> I found out mlogc-bach-load.pl couldn't parse these audit log correctly
>> and fortunately I could find the line that has this problem which is :
>>
>> if ($sect eq 'A') {
>>             if ($line =~ m%^(\[[-\d/: a-zA-Z]{27}\]) (\S+) (\S+) (\d+)
>> (\S+) (\d+)%) {
>>
>> The regular expression for matching with my audit logs is not correct. my
>> audit logs has time field like [01/Jan/2012:15:11:28 +031800]  for
>> 2.6.2v and [02/Jan/2012:17:14:01 +0330] for 2.6.3v  which non of them
>> can match with \[[-\d/: a-zA-Z]{27}\].  I changed above line with below
>> and audit logs be sent correctly:
>>
>> if ($sect eq 'A') {
>>             #if ($line =~ m%^(\[[-\d/: a-zA-Z]{27}\]) (\S+) (\S+) (\d+)
>> (\S+) (\d+)%) {
>>             if ($line =~ m%^(\[[^:]+:\d+:\d+:\d+ [^\]]+\]) (\S+) (\S+)
>> (\d+) (\S+) (\d+)%) {
>>
>> Is it a bug in mlog-batch-load.pl file or a problem in my system
>> date/time?!
>>
>> Best Regards,
>> khalilzadeh
>>
>>
>>
>>
>> --
>>
>>
>> --
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
>> infrastructure or vast IT resources to deliver seamless, secure access to
>> virtual desktops. With this all-in-one solution, easily deploy virtual
>> desktops for less than the cost of PCs and save 60% on VDI infrastructure
>> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
>> _______________________________________________
>> mod-security-developers mailing list
>> mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
>> ModSecurity Services from Trustwave's SpiderLabs:
>> https://www.trustwave.com/spiderLabs.php
>>
>
>

Re: [Mod-security-developers] mlogc-batch-load rex problem in section A

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

Hi Ebrahim,

Thanks for your feedback. There was a problem in modsecurity timestamp math
and i was changed in 2.6.3.

Any chance you send me a patch ?

Thanks

Breno

On Mon, Jan 2, 2012 at 9:41 AM, Ebrahim Khalilzadeh
<kha...@au...>wrote:

>
> Hi,
> Due to some problems about piping mlogc with apache, i decided to use
> mlogc-batch-load.pl on crontab. I installed modsecurity-apache_2.6.2 and
> it works correctly and generates audit log files like this:
>
> --3f82651b-A--
> [01/Jan/2012:15:11:28 +031800] 8lbP5n8AAAIAABL0J7gAAAAD 172.20.125.77
> 22409 172.20.125.126 80
> --3f82651b-B--
> GET /%3Cscript%3Etest%3C/script%3E HTTP/1.1
>
> Then i ran mlogc-batch-load.pl which It couldn't send audit logs to
> AuditConsole and it generated some error like this:
>
> [Mon Jan 02 17:41:33 2012] [2] [28961/80d4e50] Invalid entry (failed to
> match regex): waf - - - - \"GET /%3Cscript%3Etest%3C/script%3E HTTP/1.1\"
> 500 602 \"-\" \"-\" - \"-\"
> /20120102/20120102-1714/20120102-171401-xm8Xqn8AAAIAAG9lIs8AAAAD 0 1653
> md5:e7fe62f1bf231a6993e5623a7b872b61
>
> I installed modsecurity-apache_2.6.3 and it generated audit log files
> like this:
>
> --cc123a05-A--
> [02/Jan/2012:17:14:01 +0330] xm8Xqn8AAAIAAG9lIs8AAAAD 172.20.125.77 36872
> 172.20.125.126 80
> --cc123a05-B--
> GET /%3Cscript%3Etest%3C/script%3E HTTP/1.1
>
> i ran mlogc-batch-load.pl and same error was generated.
>
> I found out mlogc-bach-load.pl couldn't parse these audit log correctly
> and fortunately I could find the line that has this problem which is :
>
> if ($sect eq 'A') {
>             if ($line =~ m%^(\[[-\d/: a-zA-Z]{27}\]) (\S+) (\S+) (\d+)
> (\S+) (\d+)%) {
>
> The regular expression for matching with my audit logs is not correct. my
> audit logs has time field like [01/Jan/2012:15:11:28 +031800]  for 2.6.2v
> and [02/Jan/2012:17:14:01 +0330] for 2.6.3v  which non of them can match
> with \[[-\d/: a-zA-Z]{27}\].  I changed above line with below and audit
> logs be sent correctly:
>
> if ($sect eq 'A') {
>             #if ($line =~ m%^(\[[-\d/: a-zA-Z]{27}\]) (\S+) (\S+) (\d+)
> (\S+) (\d+)%) {
>             if ($line =~ m%^(\[[^:]+:\d+:\d+:\d+ [^\]]+\]) (\S+) (\S+)
> (\d+) (\S+) (\d+)%) {
>
> Is it a bug in mlog-batch-load.pl file or a problem in my system
> date/time?!
>
> Best Regards,
> khalilzadeh
>
>
>
>
> --
>
>
> --
>
>
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php
>

[Mod-security-developers] mlogc-batch-load rex problem in section A

[Ebrahim K. <kha...@au...>]

Hi, 
Due to some problems about piping mlogc with apache, i decided to use mlogc-batch-load.pl on crontab. I installed modsecurity-apache_2.6.2 and it works correctly and generates audit log files like this:

--3f82651b-A--
[01/Jan/2012:15:11:28 +031800] 8lbP5n8AAAIAABL0J7gAAAAD 172.20.125.77 22409 172.20.125.126 80
--3f82651b-B--
GET /%3Cscript%3Etest%3C/script%3E HTTP/1.1

Then i ran mlogc-batch-load.pl which It couldn't send audit logs to AuditConsole and it generated some error like this:

[Mon Jan 02 17:41:33 2012] [2] [28961/80d4e50] Invalid entry (failed to match regex): waf - - - - \"GET /%3Cscript%3Etest%3C/script%3E HTTP/1.1\" 500 602 \"-\" \"-\" - \"-\" /20120102/20120102-1714/20120102-171401-xm8Xqn8AAAIAAG9lIs8AAAAD 0 1653 md5:e7fe62f1bf231a6993e5623a7b872b61

I installed modsecurity-apache_2.6.3 and it generated audit log files like this:

--cc123a05-A--
[02/Jan/2012:17:14:01 +0330] xm8Xqn8AAAIAAG9lIs8AAAAD 172.20.125.77 36872 172.20.125.126 80
--cc123a05-B--
GET /%3Cscript%3Etest%3C/script%3E HTTP/1.1

i ran mlogc-batch-load.pl and same error was generated.

I found out mlogc-bach-load.pl couldn't parse these audit log correctly and fortunately I could find the line that has this problem which is :

if ($sect eq 'A') {
            if ($line =~ m%^(\[[-\d/: a-zA-Z]{27}\]) (\S+) (\S+) (\d+) (\S+) (\d+)%) { 

The regular expression for matching with my audit logs is not correct. my audit logs has time field like [01/Jan/2012:15:11:28 +031800]  for 2.6.2v and [02/Jan/2012:17:14:01 +0330] for 2.6.3v  which non of them can match with \[[-\d/: a-zA-Z]{27}\].  I changed above line with below and audit logs be sent correctly:

if ($sect eq 'A') {
            #if ($line =~ m%^(\[[-\d/: a-zA-Z]{27}\]) (\S+) (\S+) (\d+) (\S+) (\d+)%) { 
            if ($line =~ m%^(\[[^:]+:\d+:\d+:\d+ [^\]]+\]) (\S+) (\S+) (\d+) (\S+) (\d+)%) { 

Is it a bug in mlog-batch-load.pl file or a problem in my system date/time?!

Best Regards,
khalilzadeh
        



-- 


-- 

[Mod-security-developers] Availability of ModSecurity 2.6.3 Release

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

Availability of ModSecurity 2.6.3 Release

The ModSecurity Development Team is pleased to announce the availability of
ModSecurity 2.6.3 Release.
The stability of this release must be good and it includes some new
features and bug fixes, specially came from SDBM garbage collection code,
some
Apache API changes supporting the next Apache HTTP 2.4 series.
Please see the release notes included into CHANGES file. The download can
be done from ModSecurity website http://www.modsecurity.org/

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

Thanks

Breno Silva

[Mod-security-developers] Availability of ModSecurity 2.6.3-rc1 Release

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

Availability of ModSecurity 2.6.3-rc1 Release

The ModSecurity Development Team is pleased to announce the availability of
ModSecurity 2.6.3-rc1 Release.
The stability of this release should be good and it includes some new
features and bug fixes, specially came from SDBM garbage collection code.
Please see the release notes included into CHANGES file. The download can
be done from ModSecurity website http://www.modsecurity.org/

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

Thanks

Breno Silva

[Mod-security-developers] [JIRA] Resolved: (MODSEC-188) Incorrect status code in phase 3/4

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

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

Breno Silva Pinto resolved MODSEC-188.
--------------------------------------

    Resolution: Cannot Reproduce

Marc,

I'm closing this now to release the next release. If you have news about it let me know and we can reopen.

thanks

> Incorrect status code in phase 3/4
> ----------------------------------
>
>                 Key: MODSEC-188
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-188
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>          Components: Core
>    Affects Versions: 2.5.12
>         Environment: Windows + Linux
>            Reporter: Marc Stern
>            Assignee: Breno Silva Pinto
>            Priority: High
>             Fix For: 2.6.3
>
>
> In a reverse proxy mode, blocking in phase 3/4 does not change the status and does not display Apache error page.
> Ex:  SecAction "phase:3,t:none,log,deny,status:500"
> This always returns the back-end status with an empty page, even if the debug log says it denies with 500.
> Debug log:
> - Rule 25a4890: SecAction "phase:3,status:500,auditlog,t:none,log,deny"
> - Transformation completed in 0 usec.
> - Executing operator "unconditionalMatch" with param "" against REQUEST_URI.
> - Target value: "/test/test.html"
> - Operator completed in 0 usec.
> - Rule returned 1.
> - Match, intercepted -> returning.
> - Access denied with code 500 (phase 3). Unconditional match in SecAction. [file "..."] [line "1"]
> - Initialising logging.
> - Starting phase LOGGING.
> - This phase consists of 0 rule(s).
> - Audit log: Logging this transaction.
> This is with version 2.5.12, on an almost empty config.
> I did not notice this problem with previous versions.

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

        

[Mod-security-developers] [JIRA] Resolved: (MODSEC-197) Logging sometimes misses some info / inconsisten logging

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

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

Breno Silva Pinto resolved MODSEC-197.
--------------------------------------

    Resolution: Cannot Reproduce

> Logging sometimes misses some info / inconsisten logging
> --------------------------------------------------------
>
>                 Key: MODSEC-197
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-197
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>    Affects Versions: 2.5.13
>         Environment: All
>            Reporter: Marc Stern
>            Assignee: Breno Silva Pinto
>             Fix For: 2.6.3
>
>
> The same rule does not always logs the same information about the rule.
> Short example, one rule, twice the same request:
>  SecRule ARGS:ref "@gt 16" "phase:2,t:none,t:length,msg:'Invalid reference number',proxy:'http://...'"
>  Log:
>   1. Operator GT matched 16 at ARGS:referenceNumber. [msg "Invalid reference number"]
>   2. Access denied using proxy to (phase 2) http://localhost/SecError/apps/ref.html. [msg "Invalid reference number"]
> Full log (sanitised):
> --4ae31369-A--
> [12/Jan/2011:15:01:46 +0000] etqrMArAPisAAAc-K8sAAADD 10.192.61.111 15946 10.192.62.43 80
> --4ae31369-B--
> POST /xxxxxx HTTP/1.1
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/msword, application/vnd.ms-excel, application/vnd.ms-powerpoint, */*
> Referer: http://xxxxxx
> Accept-Language: nl-be
> Content-Type: application/x-www-form-urlencoded
> Accept-Encoding: gzip, deflate
> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
> Host: xxxxxx
> Content-Length: 34
> Pragma: no-cache
> Connection: close
> --4ae31369-C--
> ref=123456789012345678
> --4ae31369-F--
> HTTP/1.1 200 OK
> Content-Type: text/html;charset=ISO-8859-1
> Vary: Accept-Encoding,User-Agent
> Content-Encoding: gzip
> Connection: close
> Transfer-Encoding: chunked
> --4ae31369-H--
> Message: Operator GT matched 16 at ARGS:ref. [msg "Invalid reference number"]
> --4ae31369-Z--
> --1e310e07-A--
> [12/Jan/2011:16:02:51 +0100] frwvrArAPisAAAgTEDoAAABA 10.192.61.111 16272 10.192.62.43 80
> --1e310e07-B--
> POST /xxxxxx HTTP/1.1
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/msword, application/vnd.ms-excel, application/vnd.ms-powerpoint, */*
> Referer: http://xxxxxx
> Accept-Language: nl-be
> Content-Type: application/x-www-form-urlencoded
> Accept-Encoding: gzip, deflate
> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
> Host: xxxxxx
> Content-Length: 34
> Pragma: no-cache
> Connection: close
> --1e310e07-C--
> ref=123456789012345678
> --1e310e07-F--
> HTTP/1.1 200 OK
> Accept-Ranges: bytes
> Vary: Accept-Encoding,User-Agent
> Content-Type: text/html
> Content-Encoding: gzip
> Connection: close
> Transfer-Encoding: chunked
> --1e310e07-H--
> Message: Access denied using proxy to (phase 2) http://localhost/SecError/apps/ref.html. [msg "Invalid reference number"]
> Action: Intercepted (phase 2)
> WebApp-Info: "default" "unknown" "-"
> --1e310e07-Z--

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

        

[Mod-security-developers] [JIRA] Resolved: (MODSEC-22) Cache Lua virtual machines for better performance

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

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

Breno Silva Pinto resolved 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

        

[Mod-security-developers] What is this rule means?

[Tzury B. Y. <tzu...@re...>]

Hi,

Within the SLR rules I have came across several joomla rules which all
share a similar syntax
that looks like a query-string, e.g.

SecRule REQUEST_LINE "@contains /index.php" "chain,phase:2..."
> SecRule
> ARGS:option=com_joomlub&controller=auction&view=auction&task=edit&aid
> "(?i:UNION.+SELECT)" "ctl:auditLog..."


In regards to the second part (chained), I wonder if this means:
Check if within ARGS, option=comjoomla, and controller=auction
and view=auction and task=edit and also do @rx matching for ARGS:aid
and "(?i:UNION.+SELECT)"

Did i get the meanings of this rule right?

[Mod-security-developers] few questions about the code

[Tzury B. Y. <tzu...@re...>]

Hi All,

I am new to the material, yet, went over the code and have few simple
questions

1.  re_tfns.c -- are those transformation functions compatible with the
owasp codecs?

2.  I also noticed that owasp's canonical decoding functionality from the
aspect of
    recognizing dual encoding seems to be implemented within the rules, are
those two
    have the same effect?

thanks,
tzury

[Mod-security-developers] PCRE Jit support - experimental

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

Hi ModSecurity Community

I'm adding PCRE JIT (http://sljit.sourceforge.net/pcre.html) support to
ModSecurity v2.7 (trunk).
I did some tests and looks like a very good performance feature. The initial
support is for @rx operator.
Some rules executed 100% faster with JIT support.

It requires PCRE >= 8.20.

If you want to test, send me e-mail i can create a tarball of 2.7.0-trunk.

Thanks

Breno

[Mod-security-developers] [JIRA] Resolved: (MODSEC-275) Add experimental support to PCRE JIT

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

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

Breno Silva Pinto resolved MODSEC-275.
--------------------------------------

    Fix Version/s: 2.7.0
       Resolution: Fixed

> Add experimental support to PCRE JIT
> ------------------------------------
>
>                 Key: MODSEC-275
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-275
>             Project: ModSecurity
>          Issue Type: New Feature
>      Security Level: Normal
>            Reporter: Breno Silva Pinto
>            Assignee: Breno Silva Pinto
>             Fix For: 2.7.0
>
>
> Add support to PCRE JIT
> need ./configure --enable-pcre-study --enable-pcre-jit

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

        

[Mod-security-developers] [JIRA] Resolved: (MODSEC-273) Wrong timestamp in log (concurrent) when using Australia/Adelaide timezone

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

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

Breno Silva Pinto resolved MODSEC-273.
--------------------------------------

    Resolution: Fixed

> Wrong timestamp in log (concurrent) when using Australia/Adelaide timezone 
> ---------------------------------------------------------------------------
>
>                 Key: MODSEC-273
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-273
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>          Components: Logging
>    Affects Versions: 2.5.12, 2.5.13, 2.6.0, 2.6.1, 2.6.2
>         Environment: Ubuntu 10.10 32bit, 
>            Reporter: Klaubert Herr
>            Assignee: Breno Silva Pinto
>             Fix For: 2.6.3
>
>
> When the timezone is defined to Australia/Adelaide, the modsecurity log get a bad formated timestamp
> root@nic:~# date
> Sex Out 14 14:22:41 CST 2011
> Apache access.log
> 127.0.0.1 - - [14/Oct/2011:14:20:55 +1030] "GET /cmd.exe HTTP/1.0" 404 521 "-" "Wget/1.12 (linux-gnu)"
> Modsecurity concurrent log (A section)
> --6d74a868-A--
> [14/Oct/2011:14:20:55 +101800] Tpexn38AAAEAAHx9AfMAAAAA 127.0.0.1 34830 127.0.0.1 80

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

        

[Mod-security-developers] [JIRA] Closed: (MODSEC-134) Do not track original values for the TX variables

[Ivan R. (JIRA) <no...@mo...>]

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

Ivan Ristic closed MODSEC-134.
------------------------------

    Resolution: Won't Fix

It's not important, really. I submitted this in February 2010, and it's only a minor performance optimization.

> Do not track original values for the TX variables
> -------------------------------------------------
>
>                 Key: MODSEC-134
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-134
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>    Affects Versions: 2.5.11
>            Reporter: Ivan Ristic
>            Assignee: Breno Silva Pinto
>             Fix For: 2.6.3
>
>
> I've noticed that setvar tracks relative changes:
> [9] Setting variable: tx.exp=%{TIME_EPOCH}
> [9] Resolved macro %{TIME_EPOCH} to: 1264578415
> [9] Set variable "tx.exp" to "1264578415".
> [9] Setting variable: tx.exp=-%{IP.CREATE_TIME}
> [9] Recorded original collection variable: tx.exp = "1264578415"
> [9] Resolved macro %{IP.CREATE_TIME} to: 1264578269
> [9] Relative change: exp=1264578415-1264578269
> [9] Set variable "tx.exp" to "146".
> That's needed for persistent collections, but not for TX.

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

        

[Mod-security-developers] [JIRA] Resolved: (MODSEC-272) MATCHED_VARS does not correctly handle multiple VARS with the same name

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

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

Breno Silva Pinto resolved MODSEC-272.
--------------------------------------

    Resolution: Fixed

> MATCHED_VARS does not correctly handle multiple VARS with the same name
> -----------------------------------------------------------------------
>
>                 Key: MODSEC-272
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-272
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>          Components: Targets
>            Reporter: Ryan Barnett
>            Assignee: Breno Silva Pinto
>             Fix For: 2.6.3
>
>
> Recipe: Invoking rule 100908e00; [file "/usr/local/apache/conf/crs/activated_rules/modsecurity_crs_15_customrules.conf"] [line "1"].
> Rule 100908e00: SecRule "ARGS" "@rx test" "phase:1,chain,log,pass"
> Expanded "ARGS" to "ARGS:param|ARGS:param|ARGS:param".
> Transformation completed in 1 usec.
> Executing operator "rx" with param "test" against ARGS:param.
> Target value: "test"
> Operator completed in 5 usec.
> Transformation completed in 0 usec.
> Executing operator "rx" with param "test" against ARGS:param.
> Target value: "test1234"
> Operator completed in 1 usec.
> Transformation completed in 0 usec.
> Executing operator "rx" with param "test" against ARGS:param.
> Target value: "lasttest"
> Operator completed in 1 usec.
> Rule returned 1.
> Match -> mode NEXT_RULE.
> Recipe: Invoking rule 1009114d8; [file "/usr/local/apache/conf/crs/activated_rules/modsecurity_crs_15_customrules.conf"] [line "2"].
> Rule 1009114d8: SecRule "MATCHED_VARS" "@rx .*"
> Set variable "MATCHED_VARS:param" value "lasttest" size 8 to collection.
> Transformation completed in 1 usec.
> Executing operator "rx" with param ".*" against MATCHED_VARS:param.
> Target value: "lasttest"
> Operator completed in 5 usec.
> Warning. Pattern match ".*" at MATCHED_VARS:param. [file "/usr/local/apache/conf/crs/activated_rules/modsecurity_crs_15_customrules.conf"] [line "1"]
> Rule returned 1.

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

        

Re: [Mod-security-developers] Presentation and Mod Security for Java Advance

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

Good Job Juan!

On Sun, Oct 9, 2011 at 11:46 PM, Juan calderon <jua...@ow...>wrote:

> Hello All
>
> Just keeping you updated, I didn't make it to release WAF this week as
> planned, yet this is how I am doing so far.
>
>
> The Following variables are now available:
> ARGS, ARGS_NAMES, QUERY_STRING, REMOTE_ADDR, REQUEST_BASENAME,
> REQUEST_COOKIES, REQUEST_COOKIES_NAMES, REQUEST_FILENAME,
> REQUEST_HEADERS_NAMES, REQUEST_HEADERS, REQUEST_METHOD, REQUEST_PROTOCOL,
> REQUEST_URI, REQUEST_URI_RAW, RESPONSE_CONTENT_TYPE.
>
> Operators
>
>    - rx
>    - eq
>    - ge
>    - gt
>    - le
>    - lt
>
> Actions
>
>    - msg
>    - id
>    - rev
>    - severity
>    - log
>    - block
>    - status
>    - phase
>    - t
>
> Transformation Functions
>
>    - lowercase
>    - urlDecode
>    - compressWhitespace
>    - removeWhitespace
>    - replaceNulls
>    - removeNulls
>
> Phases
>     phase:1 - Request headers stage
>     phase:2 - Request body stage
>     phase:4 - Response body stage
>
> Phase 3 is not available in Java, thus, Java 4 will be used as a fall back
> to phase 3 actions.
>
> Also support for individual Mode Security rules and external rule files is
> implemented so you can embed Mod_Security rules in current XML configuration
> file or "include" a whole rules file ot the WAF rule-set.
>
> Missing parts are:
> 1. Response variables are still not available
> 2. Some actions are missing like "skip" and "chain"
> 3. Mod_Security format logging is still not implemented.
>
> So as you can see we are almost there, yet, some work is still missing. Now
> since I am in charge of OWASP Day Mexico 2011, I do not expect to have any
> advance for the next 30 days until the event finishes on Nov 11. so my new
> target date is Dec 25 I think it will be a good christmas gift.
>
> Regards,
> Juan Carlos
>
>
> On Thu, Apr 21, 2011 at 10:24 PM, Juan calderon <jua...@ow...>wrote:
>
>> Hello Guys
>>
>> My name is Juan Carlos Calderon I live in Mexico and I am creating the
>> ModSecurity Java Port by including Level 1 Port Specification functionality
>> to OWASP Java WAF. I want to give you a small update on my advance.
>>
>> The Following variables are now available:
>> ARGS, ARGS_NAMES, QUERY_STRING, REMOTE_ADDR, REQUEST_BASENAME,
>> REQUEST_COOKIES, REQUEST_COOKIES_NAMES, REQUEST_FILENAME,
>> REQUEST_HEADERS_NAMES, REQUEST_HEADERS, REQUEST_METHOD, REQUEST_PROTOCOL,
>> REQUEST_URI, REQUEST_URI_RAW, RESPONSE_CONTENT_TYPE.
>>
>> Phases
>>     phase:1 - Request headers stage
>>     phase:2 - Request body stage
>>     phase:4 - Response body stage
>>
>> Phase 3 is not available in Java, thus, Java 4 will be used as a fall back
>> to phase 3 actions.
>>
>> Little by little the port is taking shape.
>>
>> Regards,
>> Juan Carlos Calderon
>>
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> 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
>