mod-security-developers — Development discussion about mod_security

[Mod-security-developers] Crash in msc_rules_add_file in v3.0.2

[Robert P. <rp...@li...>]

Hi, my name is Bob Perper and I'm a developer here at LiteSpeed
technologies.  We include a connector for ModSecurity v3.0 in our new
release of OpenLiteSpeed and have an error reported by a customer that when
we reproduced it, resulted in a crash.

The customer was using the Comodo rulesset and was reporting errors like
this one:

    "/usr/local/lsws/conf/modsec/comodo/05_Global_Exceptions.conf failed,
ret -1, reason: 'Rules error. File:
/usr/local/lsws/conf/modsec/comodo/02_Global_Generic.conf. Line: 70.
Column: 18. Rule id: 0 is duplicated
Rules error. File:
/usr/local/lsws/conf/modsec/comodo/05_Global_Exceptions.conf. Line: 16.
Column: 88. Expecting an action, got:  ,t:none"'."

So we downloaded the Comodo files and tried it on our system with our
connector and got similar but not exact errors.  So we isolated one
specific file (03_Global_Agents.conf), used it and commented out a long
line rule (two lines, line 30 and 31), (file is attached).  When we run
openlitespeed in the debugger we call 'msc_rules_add_file' on this file,
the code crashes in ModSecurity/src/rule.cc:137

So since we were skeptical about this and figured it might be a bug in
OpenLiteSpeed.  So we installed Open NGINX and using their connector set up
a similar rule.  With the exact same file, it crashed in the same call.

We tried the same action with the master branch and had the same results.
Feel free to contact me directly if you have any additional questions.

Thanks,

-- 
Bob Perper
rp...@li...

Re: [Mod-security-developers] Additional info on Code 44 Multipart Parser error

[Brad Z. <bra...@na...>]

Hi Ervin,

I will see about getting the latest 3.0.3 + stable outside of the
channels to see if it fixes our issue.

Thanks,
Brad

On 06/20/2018 03:46 PM, Ervin Hegedüs wrote:
> Hi Brad,
> 
> On Wed, Jun 20, 2018 at 12:01:57PM -0400, Brad Zynda wrote:
>> Hey Everyone,
>>
>> Currently we are using mod_security.x86_64 2.9.2-1.el7 @centos7-x86_64
>>
>> Happy to see it is parallel with 2 and written in C!  (may need a box of
>> kleenex)
>>
>>
>> So we are seeing the multipart -- error specific to
>> https://github.com/SpiderLabs/ModSecurity/issues/652
>>
>> It really does not get into details as to which parses should be used or
>> specific ones that cause this error.
> 
> perhaps you have this one:
> 
> SecRule MULTIPART_UNMATCHED_BOUNDARY ....
> 
> but it's fixed (only in 3.0.3):
> 
> https://github.com/SpiderLabs/ModSecurity/pull/1747
> 
> Note, that you can read about this at here:
> 
> https://github.com/SpiderLabs/ModSecurity/pull/1801/commits/e0b3580370f01deeaa45d8f9a7893a77ad097937
> 
> so, of you want to avoid the error above (request denied with
> file which contains "--" at the begin of line) you have to use
> this rule:
> 
> SecRule MULTIPART_UNMATCHED_BOUNDARY "@eq 1" "id:'200004',phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'"
> 
> instead of the uncommented (original) line.
> 
> 
> 
> 
> regards,
> 
> 
> a.
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> 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] Additional info on Code 44 Multipart Parser error

[Ervin H. <ai...@gm...>]

Hi Brad,

On Wed, Jun 20, 2018 at 12:01:57PM -0400, Brad Zynda wrote:
> Hey Everyone,
> 
> Currently we are using mod_security.x86_64 2.9.2-1.el7 @centos7-x86_64
> 
> Happy to see it is parallel with 2 and written in C!  (may need a box of
> kleenex)
> 
> 
> So we are seeing the multipart -- error specific to
> https://github.com/SpiderLabs/ModSecurity/issues/652
> 
> It really does not get into details as to which parses should be used or
> specific ones that cause this error.

perhaps you have this one:

SecRule MULTIPART_UNMATCHED_BOUNDARY ....

but it's fixed (only in 3.0.3):

https://github.com/SpiderLabs/ModSecurity/pull/1747

Note, that you can read about this at here:

https://github.com/SpiderLabs/ModSecurity/pull/1801/commits/e0b3580370f01deeaa45d8f9a7893a77ad097937

so, of you want to avoid the error above (request denied with
file which contains "--" at the begin of line) you have to use
this rule:

SecRule MULTIPART_UNMATCHED_BOUNDARY "@eq 1" "id:'200004',phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'"

instead of the uncommented (original) line.




regards,


a.

Re: [Mod-security-developers] [non-nasa source] Re: Additional info on Code 44 Multipart Parser error

[Brad Z. <bra...@na...>]

Nevermind found I can just chain them.

Thanks for leading "this" horse to water.

-Brad

On 06/20/2018 01:59 PM, Brad Zynda wrote:
> Hey Walter,
> 
> very cool
> 
> I see I have a few options with path foo or @endswith /file..
> 
> Can I also restrict it by adding an allowed IP CIDR and IP
> 
> Ex.
> 
> I want to allow the whole 192.168.1.0/24 and an IP 10.10.100.105?
> 
> SecRule REMOTE_ADDR "@ipMatch 192.168.1.0/24, 10.10.100.105" or would I
> need to separate those?
> 
> Thanks,
> Brad
> 
> 
> 
> On 06/20/2018 12:56 PM, Walter Hop wrote:
>>> Also can the rule instead of just being disabled allow conditions for
>>> whitelisting, such as, from IP or filename?
>>
>> Yes definitely.. You could add a static piece of configuration like:
>>
>> <Location "/foo/">
>>     SecRuleRemoveById 200003
>> </Location>
>>
>> Or you could add exclusions dynamically if you have more complex conditions:
>>
>> SecRule REQUEST_FILENAME "@rx ^/foo/\d+$" \
>>         "id:12345,phase:1,t:none,nolog,pass,\
>>                 ctl:ruleRemoveById=200003"
>>
>> Cheers,
>> WH
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>>
>>
>> _______________________________________________
>> 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
>>
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> 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] Additional info on Code 44 Multipart Parser error

[Brad Z. <bra...@na...>]

Hey Walter,

very cool

I see I have a few options with path foo or @endswith /file..

Can I also restrict it by adding an allowed IP CIDR and IP

Ex.

I want to allow the whole 192.168.1.0/24 and an IP 10.10.100.105?

SecRule REMOTE_ADDR "@ipMatch 192.168.1.0/24, 10.10.100.105" or would I
need to separate those?

Thanks,
Brad



On 06/20/2018 12:56 PM, Walter Hop wrote:
>> Also can the rule instead of just being disabled allow conditions for
>> whitelisting, such as, from IP or filename?
> 
> Yes definitely.. You could add a static piece of configuration like:
> 
> <Location "/foo/">
>     SecRuleRemoveById 200003
> </Location>
> 
> Or you could add exclusions dynamically if you have more complex conditions:
> 
> SecRule REQUEST_FILENAME "@rx ^/foo/\d+$" \
>         "id:12345,phase:1,t:none,nolog,pass,\
>                 ctl:ruleRemoveById=200003"
> 
> Cheers,
> WH
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> _______________________________________________
> 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] Additional info on Code 44 Multipart Parser error

[Walter H. <mo...@sp...>]

> Also can the rule instead of just being disabled allow conditions for
> whitelisting, such as, from IP or filename?

Yes definitely.. You could add a static piece of configuration like:

<Location "/foo/">
    SecRuleRemoveById 200003
</Location>

Or you could add exclusions dynamically if you have more complex conditions:

SecRule REQUEST_FILENAME "@rx ^/foo/\d+$" \
        "id:12345,phase:1,t:none,nolog,pass,\
                ctl:ruleRemoveById=200003"

Cheers,
WH

-- 
Псы Всегда Попадают В Рай

[Mod-security-developers] Additional info on Code 44 Multipart Parser error

[Brad Z. <bra...@na...>]

Hey Everyone,

Glad to see 3 is out and is doing well cant wait to give it a spin on
Cent7 once it hits the channels.

Currently we are using mod_security.x86_64 2.9.2-1.el7 @centos7-x86_64

Happy to see it is parallel with 2 and written in C!  (may need a box of
kleenex)


So we are seeing the multipart -- error specific to
https://github.com/SpiderLabs/ModSecurity/issues/652

It really does not get into details as to which parses should be used or
specific ones that cause this error.

Also can the rule instead of just being disabled allow conditions for
whitelisting, such as, from IP or filename?

Thanks,
Brad

Re: [Mod-security-developers] Question regarding transaction::processConnection()

[Jai H. <jai...@mu...>]

I hate to keep bringing this up, but I still don't see how my problem can
be addressed.
I will rephrase my question in the form of an example:

StartLine is received:    Post /Post HTTP/1.1
 -> Invoke ModSec->ProcessConnection() with client IP which is available at
this time to my application.
     For a request that is forwarded, this client IP will identify the load
balancer, and not the true client.
 -> Invoke ModSec to parse the start line.

Header is received:    host: localhost
 -> Invoke ModSec to parse header.

Header is received:    X-Forwarded-For: 172.23.116.55
 -> What should be done?
     Should I re-invoke ModSec->ProcessConnection() with this true client
IP = 172.23.116.55?
     Is there an alternative way to inform ModSec of this is the true
client IP?
     Should I delay the call to ModSec->ProcessConnection() until all
headers are parsed and then call it with either
       the original client IP or an XFF IP if one was received?
     Any other options?  None of the above seem like good ones.

Seems like this should be a typical scenario that already has a solution.

On Thu, Mar 8, 2018 at 8:42 AM, Jai Harpalani <jai...@mu...>
wrote:

> Sounds like it is a good idea to always call ProcessConnection(). If this
> is the case, then I'm still confused on how I can do this for the XFF case.
> My application has ModSec built into it. So, if I want to call
> ProcessConnection() from my application, I believe I must:
>
>  1 - Invoke it early in the transaction phase (before processing request
> headers, body, etc).
>  2 - Pass it serverIP/serverPort which identifies my application that has
> ModSec built into it.
>  3 - Pass it clientIP/clientPort which identifies the client making the
> request.
>
> For #3, an earlier email stated:
>
> In that case, it is safe to use the ip that initiated the request (tcp
> request). That is the same scenario as having ModSecurity behind a reverse
> proxy of some sort.
>
> For XFF requests, the ip that initiated the request will not accurately
> identify the client. Instead, it may identify a load balancer or similar
> entity which is in front of my application. If this ip is used to identify
> the client, it is not accurate, and all rules will be operating against a
> load balancer or similar entity rather than the true client.
>
>
>
> On Thu, Mar 8, 2018 at 8:03 AM, Felipe Costa <FC...@tr...> wrote:
>
>> Hi Jai,
>>
>>
>>
>> That is an assumption that may be true on a given time frame. The library
>> can do something else in a near future and it will assume that this method
>> is being called from whomever is consume it. That is one of the reasons
>> that calling this method is important.
>>
>>
>>
>> Br.,
>>
>> *Felipe “Zimmerle” Costa*
>>
>> Security Researcher, Lead Developer ModSecurity.
>>
>>
>>
>> *Trustwave* | SMART SECURITY ON DEMAND
>>
>> *www.trustwave.com <http://www.trustwave.com/>*
>>
>>
>>
>> *From: *Jai Harpalani <jai...@mu...>
>> *Date: *Thursday, March 8, 2018 at 1:53 AM
>> *To: *Felipe Costa <FC...@tr...>
>> *Cc: *Robert Paprocki <rpa...@fe...>, "
>> mod...@li..." <
>> mod...@li...>
>> *Subject: *Re: [Mod-security-developers] Question regarding
>> transaction::processConnection()
>>
>>
>>
>> Searching through the CRS rules, I see that real_ip is used for DOS and
>> IP_REPUTATION rules. I am excluding those rules for my specific
>> application. Due to these exclusions, it seems like the call to
>> ProcessConnection() is required only to set the uniqueID. Is this an
>> accurate statement?
>>
>>
>>
>> (…)
>>
>
>

Re: [Mod-security-developers] [mod-security-users] ModSecurity version 3.0.1 announcement

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

I'm taking this to the user's list in order to stop crossposting.

On Tue, Apr 03, 2018 at 05:50:07PM -0700, Robert Paprocki wrote:
> Christian, 
> 
> > On Apr 3, 2018, at 13:18, Christian Folini <chr...@ne...> wrote:
> > 
> > Congratulations on this release Felipe.
> > 
> > I confirm the great improvement in terms of requests per second. A brief
> > test against nginx/modsecurity running on localhost brought me a speedup of
> > factor 5 with a CRS 3.0.2 default installation.
> 
> Can you share the specifics of your evaluation? Performance in modsec + crs will vary greatly depending on the request payload. Soon I would like to do some before and after trace profiling of these releases to better illustrate how libmodsec performs in various conditions.
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> 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

-- 
https://www.feistyduck.com/training/modsecurity-training-course
https://www.feistyduck.com/books/modsecurity-handbook/
mailto:chr...@ne...
twitter: @ChrFolini

Re: [Mod-security-developers] [mod-security-users] ModSecurity version 3.0.1 announcement

[Robert P. <rpa...@fe...>]

Christian, 

> On Apr 3, 2018, at 13:18, Christian Folini <chr...@ne...> wrote:
> 
> Congratulations on this release Felipe.
> 
> I confirm the great improvement in terms of requests per second. A brief
> test against nginx/modsecurity running on localhost brought me a speedup of
> factor 5 with a CRS 3.0.2 default installation.

Can you share the specifics of your evaluation? Performance in modsec + crs will vary greatly depending on the request payload. Soon I would like to do some before and after trace profiling of these releases to better illustrate how libmodsec performs in various conditions.

Re: [Mod-security-developers] [mod-security-users] ModSecurity version 3.0.1 announcement

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

Congratulations on this release Felipe.

I confirm the great improvement in terms of requests per second. A brief
test against nginx/modsecurity running on localhost brought me a speedup of
factor 5 with a CRS 3.0.2 default installation.

The changelog mentions three performance improvements. Which one had this
dramatic effect? 

And finally: Apache/ModSec 2.9.2 still trumps Nginx/ModSec 3.0.1 big time in
my lab setup. What is your projection for future performance improvements on 
the new 3.0 release line? When will this be ready to replace existing
installations with a similar performance?

Cheers,

Christian



On Mon, Apr 02, 2018 at 12:30:07PM +0000, Felipe Costa wrote:
> 
> 
> It is a pleasure to announce the release of ModSecurity version 3.0.1
> (libModSecurity). This version contains improvements, fixes and new features.
> 
> The most important new feature is the support for the libMaxMinddb,
> popularly kown as the new version of the GeoIP library. 
> 
> There is a splendid performance upgrade on v3.0.1. A significant amount of
> work was placed on how to handle the memory usage more efficiently, which
> leaded to great improvements in terms of latency and requests per second.
> 
> The list with the full changes can be found on the project CHANGES
> file, available here:
> - https://github.com/SpiderLabs/ModSecurity/releases/tag/v3.0.1/CHANGES
> 
> The list of open issues is available on GitHub:
> - https://github.com/SpiderLabs/ModSecurity/labels/3.x
> 
> Thanks to everybody who helped in this process: reporting issues, making
> comments and suggestions, sending patches and so on.
> 
> Further details on the compilation process for ModSecurity v3, can be found on
> the project README:
>  - https://github.com/SpiderLabs/ModSecurity/tree/v3/master#compilation
> 
> Complementary documentation for the connectors are available here:
>  - nginx: https://github.com/SpiderLabs/ModSecurity-nginx/#compilation
>  - Apache: https://github.com/SpiderLabs/ModSecurity-apache/#compilation
> 
> 
> IMPORTANT: ModSecurity version 2 will be available and maintained parallel
> to version 3. There is no ETA to deprecate the version 2.x. New features
> and major improvements will be implemented on version 3.x. Security or major
> bugs are planned to be back ported. Version 2 and version 3 has a completely
> independent development/release cycle.
> 
> 
> Br.,
> Felipe “Zimmerle” Costa
> Security Researcher, Lead Developer ModSecurity.
> 
> Trustwave | SMART SECURITY ON DEMAND
> www.trustwave.com
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/

-- 
https://www.feistyduck.com/training/modsecurity-training-course
https://www.feistyduck.com/books/modsecurity-handbook/
mailto:chr...@ne...
twitter: @ChrFolini

[Mod-security-developers] Completely Remove Nginx/Standalone Support from v2

[Robert P. <rpa...@fe...>]

Hi all,

Given the stability and success of libmodsecurity, are there any
thoughts/plans on completely removing the standalone functionality from
v2/master code at this point?

Re: [Mod-security-developers] Xml parse errors detected by libxml2 are being written to console

[William C. <wil...@mu...>]

NO_COUT has no effect (v3.0.1). Also didn't find it, or similarly named in
the ModSec source tree.

Could you perhaps please point me to the src where this callback can be
initialized to a null writer?

Our product use case is one where various internal log appenders write
structured data (xml and/or json) to standard out and error, which are in
turn consumed (parsed) by other entities. So unexpected writes to console
by other components/libraries makes these latter entities a bit grumpy ;)

Kind Regards - Jay

On Mon, Apr 2, 2018 at 10:45 PM, Felipe Costa <FC...@tr...> wrote:

> Hi Jai,
>
> You may want to try this:
>
> ./configure CFLAGS='-DNO_COUT' CXXFLAGS='-DNO_COUT'
>
> That was a callback on the libxml that was not set, let me know if you
> have a multi thread environment that we can use for test so we can proper
> address this issue.
>
>
>  Br.,
>   Felipe “Zimmerle”  Costa
>   Security Researcher, Lead Developer ModSecurity.
>
>   Trustwave | SMART  SECURITY ON DEMAND
>   www.trustwave.com
>
>
>
>
>
>
>
>
> From: Jai Harpalani via mod-security-developers <mod-security-developers@
> lists.sourceforge.net>
> Sent: Monday, April 2, 2018 8:38 PM
> To: mod-security-d.
> Cc: Jai Harpalani; William Case
> Subject: [Mod-security-developers] Xml parse errors detected by libxml2
> are being written to console
>
>
> While parsing a malformed xml request body, errors such as the following
> are written to the console:
>
>
> body.xml:3:  parser error : error parsing attribute name
>       <soapenv:Body>
>       ^
> body.xml:3:  parser error : attributes construct error
>       <soapenv:Body>
>       ^
> body.xml:3:  parser error : Couldn't find end of Start Tag Envelope
>       <soapenv:Body>
>       ^
>
>
>
> Is  there a way to prevent these from being displayed on the console?
>

Re: [Mod-security-developers] Xml parse errors detected by libxml2 are being written to console

[Felipe C. <FC...@tr...>]

Hi Jai,

You may want to try this:

./configure CFLAGS='-DNO_COUT' CXXFLAGS='-DNO_COUT' 

That was a callback on the libxml that was not set, let me know if you have a multi thread environment that we can use for test so we can proper address this issue.

 
 Br.,
  Felipe “Zimmerle”  Costa   
  Security Researcher, Lead Developer ModSecurity.
   
  Trustwave | SMART  SECURITY ON DEMAND
  www.trustwave.com
 
 
  
  
    



From: Jai Harpalani via mod-security-developers <mod...@li...>
Sent: Monday, April 2, 2018 8:38 PM
To: mod-security-d.
Cc: Jai Harpalani; William Case
Subject: [Mod-security-developers] Xml parse errors detected by libxml2 are being written to console
  

While parsing a malformed xml request body, errors such as the following are written to the console:


body.xml:3:  parser error : error parsing attribute name
      <soapenv:Body>
      ^
body.xml:3:  parser error : attributes construct error
      <soapenv:Body>
      ^
body.xml:3:  parser error : Couldn't find end of Start Tag Envelope
      <soapenv:Body>
      ^



Is  there a way to prevent these from being displayed on the console?     

[Mod-security-developers] Xml parse errors detected by libxml2 are being written to console

[Jai H. <jai...@mu...>]

While parsing a malformed xml request body, errors such as the following
are written to the console:

body.xml:3: parser error : error parsing attribute name
     <soapenv:Body>
     ^
body.xml:3: parser error : attributes construct error
     <soapenv:Body>
     ^
body.xml:3: parser error : Couldn't find end of Start Tag Envelope
     <soapenv:Body>
     ^

Is there a way to prevent these from being displayed on the console?

[Mod-security-developers] ModSecurity version 3.0.1 announcement

[Felipe C. <FC...@tr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



It is a pleasure to announce the release of ModSecurity version 3.0.1
(libModSecurity). This version contains improvements, fixes and new features.

The most important new feature is the support for the libMaxMinddb,
popularly kown as the new version of the GeoIP library. 

There is a splendid performance upgrade on v3.0.1. A significant amount of
work was placed on how to handle the memory usage more efficiently, which
leaded to great improvements in terms of latency and requests per second.

The list with the full changes can be found on the project CHANGES
file, available here:
- - https://github.com/SpiderLabs/ModSecurity/releases/tag/v3.0.1/CHANGES

The list of open issues is available on GitHub:
- - https://github.com/SpiderLabs/ModSecurity/labels/3.x

Thanks to everybody who helped in this process: reporting issues, making
comments and suggestions, sending patches and so on.

Further details on the compilation process for ModSecurity v3, can be found on
the project README:
 - https://github.com/SpiderLabs/ModSecurity/tree/v3/master#compilation

Complementary documentation for the connectors are available here:
 - nginx: https://github.com/SpiderLabs/ModSecurity-nginx/#compilation
 - Apache: https://github.com/SpiderLabs/ModSecurity-apache/#compilation


IMPORTANT: ModSecurity version 2 will be available and maintained parallel
to version 3. There is no ETA to deprecate the version 2.x. New features
and major improvements will be implemented on version 3.x. Security or major
bugs are planned to be back ported. Version 2 and version 3 has a completely
independent development/release cycle.


Br.,
Felipe “Zimmerle” Costa
Security Researcher, Lead Developer ModSecurity.

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iF0EARECAB0WIQQZDvrMoen6RmqOzZzm37CM6LESdwUCWsIiCAAKCRDm37CM6LES
d8DzAKCpQmKnYFVcWD99ue+nxihZZep8BACgsJxQu9UrapxBBZu0cJMEekwHBzo=
=OTkS
-----END PGP SIGNATURE-----

Re: [Mod-security-developers] [mod-security-users] ModSecurity phase timing

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

Hi Gregory,

Including modsec-dev list in my response too.

On Tue, Mar 20, 2018 at 08:19:14PM -0700, Gregory LeFevre wrote:
> Is access to phase timing known to work in ModSecurity 3.x with Nginx?

No, I do not think it is. I did not give it a through testing, but I saw the
same you did and then I also noticed that event DURATION is ignored with
3.0.0.

Ahoj,

Christian


-- 
If you have men who will only come if they know there is a good road, 
I don't want them. I want men who will come if there is no road at all.
-- David Livingstone

Re: [Mod-security-developers] Question regarding transaction::processConnection()

[Jai H. <jai...@mu...>]

Sounds like it is a good idea to always call ProcessConnection(). If this
is the case, then I'm still confused on how I can do this for the XFF case.
My application has ModSec built into it. So, if I want to call
ProcessConnection() from my application, I believe I must:

 1 - Invoke it early in the transaction phase (before processing request
headers, body, etc).
 2 - Pass it serverIP/serverPort which identifies my application that has
ModSec built into it.
 3 - Pass it clientIP/clientPort which identifies the client making the
request.

For #3, an earlier email stated:

In that case, it is safe to use the ip that initiated the request (tcp
request). That is the same scenario as having ModSecurity behind a reverse
proxy of some sort.

For XFF requests, the ip that initiated the request will not accurately
identify the client. Instead, it may identify a load balancer or similar
entity which is in front of my application. If this ip is used to identify
the client, it is not accurate, and all rules will be operating against a
load balancer or similar entity rather than the true client.



On Thu, Mar 8, 2018 at 8:03 AM, Felipe Costa <FC...@tr...> wrote:

> Hi Jai,
>
>
>
> That is an assumption that may be true on a given time frame. The library
> can do something else in a near future and it will assume that this method
> is being called from whomever is consume it. That is one of the reasons
> that calling this method is important.
>
>
>
> Br.,
>
> *Felipe “Zimmerle” Costa*
>
> Security Researcher, Lead Developer ModSecurity.
>
>
>
> *Trustwave* | SMART SECURITY ON DEMAND
>
> *www.trustwave.com <http://www.trustwave.com/>*
>
>
>
> *From: *Jai Harpalani <jai...@mu...>
> *Date: *Thursday, March 8, 2018 at 1:53 AM
> *To: *Felipe Costa <FC...@tr...>
> *Cc: *Robert Paprocki <rpa...@fe...>, "
> mod...@li..." <mod-security-developers@
> lists.sourceforge.net>
> *Subject: *Re: [Mod-security-developers] Question regarding transaction::
> processConnection()
>
>
>
> Searching through the CRS rules, I see that real_ip is used for DOS and
> IP_REPUTATION rules. I am excluding those rules for my specific
> application. Due to these exclusions, it seems like the call to
> ProcessConnection() is required only to set the uniqueID. Is this an
> accurate statement?
>
>
>
> (…)
>

Re: [Mod-security-developers] Question regarding transaction::processConnection()

[Felipe C. <FC...@tr...>]

Hi Jai,

That is an assumption that may be true on a given time frame. The library can do something else in a near future and it will assume that this method is being called from whomever is consume it. That is one of the reasons that calling this method is important.

Br.,
Felipe “Zimmerle” Costa
Security Researcher, Lead Developer ModSecurity.

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com<http://www.trustwave.com/>

From: Jai Harpalani <jai...@mu...>
Date: Thursday, March 8, 2018 at 1:53 AM
To: Felipe Costa <FC...@tr...>
Cc: Robert Paprocki <rpa...@fe...>, "mod...@li..." <mod...@li...>
Subject: Re: [Mod-security-developers] Question regarding transaction::processConnection()

Searching through the CRS rules, I see that real_ip is used for DOS and IP_REPUTATION rules. I am excluding those rules for my specific application. Due to these exclusions, it seems like the call to ProcessConnection() is required only to set the uniqueID. Is this an accurate statement?

(…)

Re: [Mod-security-developers] Question regarding transaction::processConnection()

[Jai H. <jai...@mu...>]

Searching through the CRS rules, I see that real_ip is used for DOS and
IP_REPUTATION rules. I am excluding those rules for my specific
application. Due to these exclusions, it seems like the call to
ProcessConnection() is required only to set the uniqueID. Is this an
accurate statement?

On Wed, Mar 7, 2018 at 6:44 PM, Felipe Costa <FC...@tr...> wrote:

> In that case, it is safe to use the ip that initiated the request (tcp
> request). That is the same scenario as having ModSecurity behind a reverse
> proxy of some sort.
>
>
>
> …for CRS, you can set the real ip here:
>
> https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.
> 0/master/rules/REQUEST-901-INITIALIZATION.conf#L249
>
>
>
>
>
> Br.,
>
> *Felipe “Zimmerle” Costa*
>
> Security Researcher, Lead Developer ModSecurity.
>
>
>
> *Trustwave* | SMART SECURITY ON DEMAND
>
> *www.trustwave.com <http://www.trustwave.com/>*
>
>
>
> *From: *Jai Harpalani <jai...@mu...>
> *Date: *Wednesday, March 7, 2018 at 6:05 PM
> *To: *Robert Paprocki <rpa...@fe...>
> *Cc: *"mod...@li..." <
> mod...@li...>, Felipe Costa <
> FC...@tr...>
>
> *Subject: *Re: [Mod-security-developers] Question regarding transaction::
> processConnection()
>
>
>
> I am integrating ModSec into a security fabric edge application.
>
>
>
> The specific problem I am encountering is for the X-Forwarded-For case. In
> that case, the client's IP address is only available after request headers
> are read (eg X-Forwarded-For: 123.45.67.8). Seems like processConnection()
> should be called prior to addRequestHeader() and processRequestHeader(),
> but I will not have accurate client IP information that early.
>
>
>
> On Wed, Mar 7, 2018 at 2:55 PM, Robert Paprocki <rpaprocki@
> fearnothingproductions.net> wrote:
>
> Server and client port/up information is made available as data
> collections for modsec rules to use. Not calling processConnection hampers
> the rule engine in later phases if it's missing the unique ID variable,
> and/or if you have secrules that rely on layer 4 data.
>
>
>
> Just curious, what app are you integrating that you don't have access to
> the needed data?
>
>
> Sent from my iPhone
>
>
> On Mar 7, 2018, at 12:45, Jai Harpalani via mod-security-developers <
> mod...@li...> wrote:
>
> The problem is that it is difficult for my application to access all of
> the parameters required for processConnection().
>
>
>
> I see that this method is setting client and server Ips and ports as well
> as setting m_variableUniqueID. How are these variables used by the
> evaluate() call within processConnection()? How are these variables used in
> further processing?
>
>
>
> On Wed, Mar 7, 2018 at 2:42 PM, Felipe Costa <FC...@tr...> wrote:
>
> Hi,
>
>
>
> The phases are not necessaraly in use today. Some are reserved for further
> updates. Having say that, I would strongly recommend to call all process(*)
> that represents each of the phases. If there is nothing to be computed
> ModSecurity will return promptly with no harm.
>
>
>
> Br.,
>
> *Felipe “Zimmerle” Costa*
>
> Security Researcher, Lead Developer ModSecurity.
>
>
>
> *Trustwave* | SMART SECURITY ON DEMAND
>
> www.trustwave.com
>
>
>
>
>
> *From: *Jai Harpalani <jai...@mu...>
> *Date: *Wednesday, March 7, 2018 at 5:34 PM
>
>
> *To: *Felipe Costa <FC...@tr...>
> *Cc: *"mod...@li..." <
> mod...@li...>
> *Subject: *Re: [Mod-security-developers] Question regarding transaction::
> processConnection()
>
>
>
> Sorry, forgot to reply-all.
>
>
>
> So, if all I have are rules associated with SecMarkers, then is it true
> that I don't have any SecRules associated with Phase 0?  And, if this is
> true, then what is the purpose of transaction::processConnection()? I am
> trying to determine what this method actually does and whether I need to
> invoke it for my use-case.
>
>
>
> On Wed, Mar 7, 2018 at 2:26 PM, Felipe Costa <FC...@tr...> wrote:
>
> Hi Jai,
>
>
>
> In that specific case, those are the representation of SecMarkers.
>
>
>
> Br.,
>
> *Felipe “Zimmerle” Costa*
>
> Security Researcher, Lead Developer ModSecurity.
>
>
>
> *Trustwave* | SMART SECURITY ON DEMAND
>
> www.trustwave.com
>
>
>
> *From: *Jai Harpalani <jai...@mu...>
> *Date: *Wednesday, March 7, 2018 at 12:16 PM
> *To: *Felipe Costa <FC...@tr...>
> *Cc: *"mod...@li..." <
> mod...@li...>
> *Subject: *Re: [Mod-security-developers] Question regarding transaction::
> processConnection()
>
>
>
> Using version 3.0.0 of libModSecurity.
>
>
>
> Below is output after each set of OWASP CRS rules are added. As you can
> see, some rules are added to Phase 0 after each CRS rule set is added. I am
> not sure what these rules do.
>
>
>
> what> modSecShowRules
>
> Rules:
>
> Phase: 0 (0 rules)
>
> Phase: 1 (0 rules)
>
> Phase: 2 (0 rules)
>
> Phase: 3 (0 rules)
>
> Phase: 4 (0 rules)
>
> Phase: 5 (0 rules)
>
> Phase: 6 (0 rules)
>
> Phase: 7 (0 rules)
>
> what> modSecAddRules -p /opt/esg/current/runtime/owasp-modsecurity-crs/
> modsecurity.conf
>
> what> modSecShowRules
>
> Rules:
>
> Phase: 0 (0 rules)
>
> Phase: 1 (0 rules)
>
> Phase: 2 (2 rules)
>
>     Rule ID: 200000--0x561d935fce20
>
>     Rule ID: 200001--0x561d935fd430
>
> Phase: 3 (4 rules)
>
>     Rule ID: 200002--0x561d935d0690
>
>     Rule ID: 200003--0x561d93642530
>
>     Rule ID: 200004--0x561d93642d60
>
>     Rule ID: 200005--0x561d935d6160
>
> Phase: 4 (0 rules)
>
> Phase: 5 (0 rules)
>
> Phase: 6 (0 rules)
>
> Phase: 7 (0 rules)
>
> what> modSecAddRules -p /opt/esg/current/runtime/
> owasp-modsecurity-crs/crs-setup.conf
>
> what> modSecShowRules
>
> Rules:
>
> Phase: 0 (0 rules)
>
> Phase: 1 (0 rules)
>
> Phase: 2 (4 rules)
>
>     Rule ID: 200000--0x561d935fce20
>
>     Rule ID: 200001--0x561d935fd430
>
>     Rule ID: 900950--0x561d935d62c0
>
>     Rule ID: 900990--0x561d935d66a0
>
> Phase: 3 (4 rules)
>
>     Rule ID: 200002--0x561d935d0690
>
>     Rule ID: 200003--0x561d93642530
>
>     Rule ID: 200004--0x561d93642d60
>
>     Rule ID: 200005--0x561d935d6160
>
> Phase: 4 (0 rules)
>
> Phase: 5 (0 rules)
>
> Phase: 6 (0 rules)
>
> Phase: 7 (0 rules)
>
> what> modSecAddRules -p /opt/esg/current/runtime/
> owasp-modsecurity-crs/rules/REQUEST-901-INITIALIZATION.conf
>
> what> modSecShowRules
>
> Rules:
>
> Phase: 0 (1 rules)
>
>     Rule ID: 0--0x561d92adf2a0
>
> Phase: 1 (1 rules)
>
>     Rule ID: 0--0x561d92adf3b0
>
> Phase: 2 (39 rules)
>
> (..)
>
> Phase: 3 (5 rules)
>
>     Rule ID: 200002--0x561d935d0690
>
>     Rule ID: 200003--0x561d93642530
>
>     Rule ID: 200004--0x561d93642d60
>
>     Rule ID: 200005--0x561d935d6160
>
>     Rule ID: 0--0x561d92adf5d0
>
> Phase: 4 (1 rules)
>
>     Rule ID: 0--0x561d92adf6e0
>
> Phase: 5 (1 rules)
>
>     Rule ID: 0--0x561d92adf7f0
>
> Phase: 6 (1 rules)
>
>     Rule ID: 0--0x561d92b7def0
>
> Phase: 7 (0 rules)
>
> what>
>
> what> modSecAddRules -p /opt/esg/current/runtime/
> owasp-modsecurity-crs/rules/REQUEST-913-SCANNER-DETECTION.conf
>
> what> modSecShowRules
>
> Rules:
>
> Phase: 0 (2 rules)
>
>     Rule ID: 0--0x561d92adf2a0
>
>     Rule ID: 0--0x561d93599630
>
> Phase: 1 (2 rules)
>
>     Rule ID: 0--0x561d92adf3b0
>
>     Rule ID: 0--0x561d93599760
>
> Phase: 2 (49 rules)
>
> (..)
>
>     Rule ID: 0--0x561d93599da0
>
> Phase: 7 (0 rules)
>
> what> modSecAddRules -p /opt/esg/current/runtime/
> owasp-modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf
>
> what> modSecShowRules
>
> Rules:
>
> Phase: 0 (4 rules)
>
>     Rule ID: 0--0x561d92adf2a0
>
>     Rule ID: 0--0x561d93599630
>
>     Rule ID: 0--0x561d935bc6b0
>
>     Rule ID: 0--0x561d92dface0
>
> Phase: 1 (4 rules)
>
>     Rule ID: 0--0x561d92adf3b0
>
>     Rule ID: 0--0x561d93599760
>
> (…)
>
>
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org
> <http://scanmail.trustwave.com/?c=4062&d=g9Sg2vOkqgSsyTMC95fR_J5xoBDhpxrIR0MyBBhirQ&s=5&u=http%3a%2f%2fSlashdot%2eorg>!
> http://sdm.link/slashdot
> <http://scanmail.trustwave.com/?c=4062&d=g9Sg2vOkqgSsyTMC95fR_J5xoBDhpxrIR0czARxlqw&s=5&u=http%3a%2f%2fsdm%2elink%2fslashdot>
>
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> <https://scanmail.trustwave.com/?c=4062&d=g9Sg2vOkqgSsyTMC95fR_J5xoBDhpxrIRxBkCxow-A&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers>
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php
>
>
>

Re: [Mod-security-developers] Question regarding transaction::processConnection()

[Jai H. <jai...@mu...>]

Robert,

Thanks for the tip about XFF headers, but I don't think this will help with
invoking processConnection().

In an earlier reply, you stated:

Server and client port/up [sic] information is made available as data
collections for modsec rules to use. Not calling processConnection hampers
the rule engine in later phases if it's missing the unique ID variable,
and/or if you have secrules that rely on layer 4 data.


Are there any SecRules which rely on layer 4 data in the OWASP CRS?  If so,
can you provide RuleIds for a few of them?

Thanks,
Jai


On Wed, Mar 7, 2018 at 3:08 PM, Robert Paprocki <
rpa...@fe...> wrote:

> Don't have resources on hand, but there are some good articles online
> about integrating XFF headers with modsec rules. In generic you define the
> IP collection as the value of the XFF header (assuming you trust the
> header) via a phase 1 SecRule/SecAction.
>
> processConnection should be geared more for layer 4 data. It's perfectly
> fine to use ModSec to translate the client IP via layer 7 data in the rule
> DSL.
>
> Sent from my iPhone
>
> On Mar 7, 2018, at 13:05, Jai Harpalani <jai...@mu...>
> wrote:
>
> I am integrating ModSec into a security fabric edge application.
>
> The specific problem I am encountering is for the X-Forwarded-For case. In
> that case, the client's IP address is only available after request headers
> are read (eg X-Forwarded-For: 123.45.67.8). Seems like processConnection()
> should be called prior to addRequestHeader() and processRequestHeader(),
> but I will not have accurate client IP information that early.
>
> On Wed, Mar 7, 2018 at 2:55 PM, Robert Paprocki <rpaprocki@
> fearnothingproductions.net> wrote:
>
>> Server and client port/up information is made available as data
>> collections for modsec rules to use. Not calling processConnection hampers
>> the rule engine in later phases if it's missing the unique ID variable,
>> and/or if you have secrules that rely on layer 4 data.
>>
>> Just curious, what app are you integrating that you don't have access to
>> the needed data?
>>
>> Sent from my iPhone
>>
>> On Mar 7, 2018, at 12:45, Jai Harpalani via mod-security-developers <
>> mod...@li...> wrote:
>>
>> The problem is that it is difficult for my application to access all of
>> the parameters required for processConnection().
>>
>> I see that this method is setting client and server Ips and ports as well
>> as setting m_variableUniqueID. How are these variables used by the
>> evaluate() call within processConnection()? How are these variables used in
>> further processing?
>>
>> On Wed, Mar 7, 2018 at 2:42 PM, Felipe Costa <FC...@tr...>
>> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> The phases are not necessaraly in use today. Some are reserved for
>>> further updates. Having say that, I would strongly recommend to call all
>>> process(*) that represents each of the phases. If there is nothing to be
>>> computed ModSecurity will return promptly with no harm.
>>>
>>>
>>>
>>> Br.,
>>>
>>> *Felipe “Zimmerle” Costa*
>>>
>>> Security Researcher, Lead Developer ModSecurity.
>>>
>>>
>>>
>>> *Trustwave* | SMART SECURITY ON DEMAND
>>>
>>> *www.trustwave.com <http://www.trustwave.com/>*
>>>
>>>
>>>
>>>
>>>
>>> *From: *Jai Harpalani <jai...@mu...>
>>> *Date: *Wednesday, March 7, 2018 at 5:34 PM
>>>
>>> *To: *Felipe Costa <FC...@tr...>
>>> *Cc: *"mod...@li..." <
>>> mod...@li...>
>>> *Subject: *Re: [Mod-security-developers] Question regarding
>>> transaction::processConnection()
>>>
>>>
>>>
>>> Sorry, forgot to reply-all.
>>>
>>>
>>>
>>> So, if all I have are rules associated with SecMarkers, then is it true
>>> that I don't have any SecRules associated with Phase 0?  And, if this is
>>> true, then what is the purpose of transaction::processConnection()? I
>>> am trying to determine what this method actually does and whether I need to
>>> invoke it for my use-case.
>>>
>>>
>>>
>>> On Wed, Mar 7, 2018 at 2:26 PM, Felipe Costa <FC...@tr...>
>>> wrote:
>>>
>>> Hi Jai,
>>>
>>>
>>>
>>> In that specific case, those are the representation of SecMarkers.
>>>
>>>
>>>
>>> Br.,
>>>
>>> *Felipe “Zimmerle” Costa*
>>>
>>> Security Researcher, Lead Developer ModSecurity.
>>>
>>>
>>>
>>> *Trustwave* | SMART SECURITY ON DEMAND
>>>
>>> www.trustwave.com
>>>
>>>
>>>
>>> *From: *Jai Harpalani <jai...@mu...>
>>> *Date: *Wednesday, March 7, 2018 at 12:16 PM
>>> *To: *Felipe Costa <FC...@tr...>
>>> *Cc: *"mod...@li..." <
>>> mod...@li...>
>>> *Subject: *Re: [Mod-security-developers] Question regarding
>>> transaction::processConnection()
>>>
>>>
>>>
>>> Using version 3.0.0 of libModSecurity.
>>>
>>>
>>>
>>> Below is output after each set of OWASP CRS rules are added. As you can
>>> see, some rules are added to Phase 0 after each CRS rule set is added. I am
>>> not sure what these rules do.
>>>
>>>
>>>
>>> what> modSecShowRules
>>>
>>> Rules:
>>>
>>> Phase: 0 (0 rules)
>>>
>>> Phase: 1 (0 rules)
>>>
>>> Phase: 2 (0 rules)
>>>
>>> Phase: 3 (0 rules)
>>>
>>> Phase: 4 (0 rules)
>>>
>>> Phase: 5 (0 rules)
>>>
>>> Phase: 6 (0 rules)
>>>
>>> Phase: 7 (0 rules)
>>>
>>> what> modSecAddRules -p /opt/esg/current/runtime/owasp
>>> -modsecurity-crs/modsecurity.conf
>>>
>>> what> modSecShowRules
>>>
>>> Rules:
>>>
>>> Phase: 0 (0 rules)
>>>
>>> Phase: 1 (0 rules)
>>>
>>> Phase: 2 (2 rules)
>>>
>>>     Rule ID: 200000--0x561d935fce20
>>>
>>>     Rule ID: 200001--0x561d935fd430
>>>
>>> Phase: 3 (4 rules)
>>>
>>>     Rule ID: 200002--0x561d935d0690
>>>
>>>     Rule ID: 200003--0x561d93642530
>>>
>>>     Rule ID: 200004--0x561d93642d60
>>>
>>>     Rule ID: 200005--0x561d935d6160
>>>
>>> Phase: 4 (0 rules)
>>>
>>> Phase: 5 (0 rules)
>>>
>>> Phase: 6 (0 rules)
>>>
>>> Phase: 7 (0 rules)
>>>
>>> what> modSecAddRules -p /opt/esg/current/runtime/owasp
>>> -modsecurity-crs/crs-setup.conf
>>>
>>> what> modSecShowRules
>>>
>>> Rules:
>>>
>>> Phase: 0 (0 rules)
>>>
>>> Phase: 1 (0 rules)
>>>
>>> Phase: 2 (4 rules)
>>>
>>>     Rule ID: 200000--0x561d935fce20
>>>
>>>     Rule ID: 200001--0x561d935fd430
>>>
>>>     Rule ID: 900950--0x561d935d62c0
>>>
>>>     Rule ID: 900990--0x561d935d66a0
>>>
>>> Phase: 3 (4 rules)
>>>
>>>     Rule ID: 200002--0x561d935d0690
>>>
>>>     Rule ID: 200003--0x561d93642530
>>>
>>>     Rule ID: 200004--0x561d93642d60
>>>
>>>     Rule ID: 200005--0x561d935d6160
>>>
>>> Phase: 4 (0 rules)
>>>
>>> Phase: 5 (0 rules)
>>>
>>> Phase: 6 (0 rules)
>>>
>>> Phase: 7 (0 rules)
>>>
>>> what> modSecAddRules -p /opt/esg/current/runtime/owasp
>>> -modsecurity-crs/rules/REQUEST-901-INITIALIZATION.conf
>>>
>>> what> modSecShowRules
>>>
>>> Rules:
>>>
>>> Phase: 0 (1 rules)
>>>
>>>     Rule ID: 0--0x561d92adf2a0
>>>
>>> Phase: 1 (1 rules)
>>>
>>>     Rule ID: 0--0x561d92adf3b0
>>>
>>> Phase: 2 (39 rules)
>>>
>>> (..)
>>>
>>> Phase: 3 (5 rules)
>>>
>>>     Rule ID: 200002--0x561d935d0690
>>>
>>>     Rule ID: 200003--0x561d93642530
>>>
>>>     Rule ID: 200004--0x561d93642d60
>>>
>>>     Rule ID: 200005--0x561d935d6160
>>>
>>>     Rule ID: 0--0x561d92adf5d0
>>>
>>> Phase: 4 (1 rules)
>>>
>>>     Rule ID: 0--0x561d92adf6e0
>>>
>>> Phase: 5 (1 rules)
>>>
>>>     Rule ID: 0--0x561d92adf7f0
>>>
>>> Phase: 6 (1 rules)
>>>
>>>     Rule ID: 0--0x561d92b7def0
>>>
>>> Phase: 7 (0 rules)
>>>
>>> what>
>>>
>>> what> modSecAddRules -p /opt/esg/current/runtime/owasp
>>> -modsecurity-crs/rules/REQUEST-913-SCANNER-DETECTION.conf
>>>
>>> what> modSecShowRules
>>>
>>> Rules:
>>>
>>> Phase: 0 (2 rules)
>>>
>>>     Rule ID: 0--0x561d92adf2a0
>>>
>>>     Rule ID: 0--0x561d93599630
>>>
>>> Phase: 1 (2 rules)
>>>
>>>     Rule ID: 0--0x561d92adf3b0
>>>
>>>     Rule ID: 0--0x561d93599760
>>>
>>> Phase: 2 (49 rules)
>>>
>>> (..)
>>>
>>>     Rule ID: 0--0x561d93599da0
>>>
>>> Phase: 7 (0 rules)
>>>
>>> what> modSecAddRules -p /opt/esg/current/runtime/owasp
>>> -modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf
>>>
>>> what> modSecShowRules
>>>
>>> Rules:
>>>
>>> Phase: 0 (4 rules)
>>>
>>>     Rule ID: 0--0x561d92adf2a0
>>>
>>>     Rule ID: 0--0x561d93599630
>>>
>>>     Rule ID: 0--0x561d935bc6b0
>>>
>>>     Rule ID: 0--0x561d92dface0
>>>
>>> Phase: 1 (4 rules)
>>>
>>>     Rule ID: 0--0x561d92adf3b0
>>>
>>>     Rule ID: 0--0x561d93599760
>>>
>>> (…)
>>>
>>>
>>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>> _______________________________________________
>> 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] Question regarding transaction::processConnection()

[Robert P. <rpa...@fe...>]

Don't have resources on hand, but there are some good articles online about integrating XFF headers with modsec rules. In generic you define the IP collection as the value of the XFF header (assuming you trust the header) via a phase 1 SecRule/SecAction. 

processConnection should be geared more for layer 4 data. It's perfectly fine to use ModSec to translate the client IP via layer 7 data in the rule DSL. 

Sent from my iPhone

> On Mar 7, 2018, at 13:05, Jai Harpalani <jai...@mu...> wrote:
> 
> I am integrating ModSec into a security fabric edge application. 
> 
> The specific problem I am encountering is for the X-Forwarded-For case. In that case, the client's IP address is only available after request headers are read (eg X-Forwarded-For: 123.45.67.8). Seems like processConnection() should be called prior to addRequestHeader() and processRequestHeader(), but I will not have accurate client IP information that early. 
> 
>> On Wed, Mar 7, 2018 at 2:55 PM, Robert Paprocki <rpa...@fe...> wrote:
>> Server and client port/up information is made available as data collections for modsec rules to use. Not calling processConnection hampers the rule engine in later phases if it's missing the unique ID variable, and/or if you have secrules that rely on layer 4 data. 
>> 
>> Just curious, what app are you integrating that you don't have access to the needed data?
>> 
>> Sent from my iPhone
>> 
>>> On Mar 7, 2018, at 12:45, Jai Harpalani via mod-security-developers <mod...@li...> wrote:
>>> 
>>> The problem is that it is difficult for my application to access all of the parameters required for processConnection(). 
>>> 
>>> I see that this method is setting client and server Ips and ports as well as setting m_variableUniqueID. How are these variables used by the evaluate() call within processConnection()? How are these variables used in further processing?
>>> 
>>>> On Wed, Mar 7, 2018 at 2:42 PM, Felipe Costa <FC...@tr...> wrote:
>>>> Hi,
>>>> 
>>>>  
>>>> 
>>>> The phases are not necessaraly in use today. Some are reserved for further updates. Having say that, I would strongly recommend to call all process(*) that represents each of the phases. If there is nothing to be computed ModSecurity will return promptly with no harm.
>>>> 
>>>>  
>>>> 
>>>> Br.,
>>>> 
>>>> Felipe “Zimmerle” Costa
>>>> 
>>>> Security Researcher, Lead Developer ModSecurity.
>>>> 
>>>>  
>>>> 
>>>> Trustwave | SMART SECURITY ON DEMAND
>>>> 
>>>> www.trustwave.com
>>>> 
>>>>  
>>>> 
>>>>  
>>>> 
>>>> From: Jai Harpalani <jai...@mu...>
>>>> Date: Wednesday, March 7, 2018 at 5:34 PM
>>>> 
>>>> 
>>>> To: Felipe Costa <FC...@tr...>
>>>> Cc: "mod...@li..." <mod...@li...>
>>>> Subject: Re: [Mod-security-developers] Question regarding transaction::processConnection()
>>>>  
>>>> 
>>>> Sorry, forgot to reply-all.
>>>> 
>>>>  
>>>> 
>>>> So, if all I have are rules associated with SecMarkers, then is it true that I don't have any SecRules associated with Phase 0?  And, if this is true, then what is the purpose of transaction::processConnection()? I am trying to determine what this method actually does and whether I need to invoke it for my use-case.
>>>> 
>>>>  
>>>> 
>>>> On Wed, Mar 7, 2018 at 2:26 PM, Felipe Costa <FC...@tr...> wrote:
>>>> 
>>>> Hi Jai,
>>>> 
>>>>  
>>>> 
>>>> In that specific case, those are the representation of SecMarkers.
>>>> 
>>>>  
>>>> 
>>>> Br.,
>>>> 
>>>> Felipe “Zimmerle” Costa
>>>> 
>>>> Security Researcher, Lead Developer ModSecurity.
>>>> 
>>>>  
>>>> 
>>>> Trustwave | SMART SECURITY ON DEMAND
>>>> 
>>>> www.trustwave.com
>>>> 
>>>>  
>>>> 
>>>> From: Jai Harpalani <jai...@mu...>
>>>> Date: Wednesday, March 7, 2018 at 12:16 PM
>>>> To: Felipe Costa <FC...@tr...>
>>>> Cc: "mod...@li..." <mod...@li...>
>>>> Subject: Re: [Mod-security-developers] Question regarding transaction::processConnection()
>>>> 
>>>>  
>>>> 
>>>> Using version 3.0.0 of libModSecurity.
>>>> 
>>>>  
>>>> 
>>>> Below is output after each set of OWASP CRS rules are added. As you can see, some rules are added to Phase 0 after each CRS rule set is added. I am not sure what these rules do.
>>>> 
>>>>  
>>>> 
>>>> what> modSecShowRules
>>>> 
>>>> Rules: 
>>>> 
>>>> Phase: 0 (0 rules)
>>>> 
>>>> Phase: 1 (0 rules)
>>>> 
>>>> Phase: 2 (0 rules)
>>>> 
>>>> Phase: 3 (0 rules)
>>>> 
>>>> Phase: 4 (0 rules)
>>>> 
>>>> Phase: 5 (0 rules)
>>>> 
>>>> Phase: 6 (0 rules)
>>>> 
>>>> Phase: 7 (0 rules)
>>>> 
>>>> what> modSecAddRules -p /opt/esg/current/runtime/owasp-modsecurity-crs/modsecurity.conf
>>>> 
>>>> what> modSecShowRules
>>>> 
>>>> Rules: 
>>>> 
>>>> Phase: 0 (0 rules)
>>>> 
>>>> Phase: 1 (0 rules)
>>>> 
>>>> Phase: 2 (2 rules)
>>>> 
>>>>     Rule ID: 200000--0x561d935fce20
>>>> 
>>>>     Rule ID: 200001--0x561d935fd430
>>>> 
>>>> Phase: 3 (4 rules)
>>>> 
>>>>     Rule ID: 200002--0x561d935d0690
>>>> 
>>>>     Rule ID: 200003--0x561d93642530
>>>> 
>>>>     Rule ID: 200004--0x561d93642d60
>>>> 
>>>>     Rule ID: 200005--0x561d935d6160
>>>> 
>>>> Phase: 4 (0 rules)
>>>> 
>>>> Phase: 5 (0 rules)
>>>> 
>>>> Phase: 6 (0 rules)
>>>> 
>>>> Phase: 7 (0 rules)
>>>> 
>>>> what> modSecAddRules -p /opt/esg/current/runtime/owasp-modsecurity-crs/crs-setup.conf
>>>> 
>>>> what> modSecShowRules
>>>> 
>>>> Rules: 
>>>> 
>>>> Phase: 0 (0 rules)
>>>> 
>>>> Phase: 1 (0 rules)
>>>> 
>>>> Phase: 2 (4 rules)
>>>> 
>>>>     Rule ID: 200000--0x561d935fce20
>>>> 
>>>>     Rule ID: 200001--0x561d935fd430
>>>> 
>>>>     Rule ID: 900950--0x561d935d62c0
>>>> 
>>>>     Rule ID: 900990--0x561d935d66a0
>>>> 
>>>> Phase: 3 (4 rules)
>>>> 
>>>>     Rule ID: 200002--0x561d935d0690
>>>> 
>>>>     Rule ID: 200003--0x561d93642530
>>>> 
>>>>     Rule ID: 200004--0x561d93642d60
>>>> 
>>>>     Rule ID: 200005--0x561d935d6160
>>>> 
>>>> Phase: 4 (0 rules)
>>>> 
>>>> Phase: 5 (0 rules)
>>>> 
>>>> Phase: 6 (0 rules)
>>>> 
>>>> Phase: 7 (0 rules)
>>>> 
>>>> what> modSecAddRules -p /opt/esg/current/runtime/owasp-modsecurity-crs/rules/REQUEST-901-INITIALIZATION.conf
>>>> 
>>>> what> modSecShowRules
>>>> 
>>>> Rules: 
>>>> 
>>>> Phase: 0 (1 rules)
>>>> 
>>>>     Rule ID: 0--0x561d92adf2a0
>>>> 
>>>> Phase: 1 (1 rules)
>>>> 
>>>>     Rule ID: 0--0x561d92adf3b0
>>>> 
>>>> Phase: 2 (39 rules)
>>>> 
>>>> (..)
>>>> 
>>>> Phase: 3 (5 rules)
>>>> 
>>>>     Rule ID: 200002--0x561d935d0690
>>>> 
>>>>     Rule ID: 200003--0x561d93642530
>>>> 
>>>>     Rule ID: 200004--0x561d93642d60
>>>> 
>>>>     Rule ID: 200005--0x561d935d6160
>>>> 
>>>>     Rule ID: 0--0x561d92adf5d0
>>>> 
>>>> Phase: 4 (1 rules)
>>>> 
>>>>     Rule ID: 0--0x561d92adf6e0
>>>> 
>>>> Phase: 5 (1 rules)
>>>> 
>>>>     Rule ID: 0--0x561d92adf7f0
>>>> 
>>>> Phase: 6 (1 rules)
>>>> 
>>>>     Rule ID: 0--0x561d92b7def0
>>>> 
>>>> Phase: 7 (0 rules)
>>>> 
>>>> what> 
>>>> 
>>>> what> modSecAddRules -p /opt/esg/current/runtime/owasp-modsecurity-crs/rules/REQUEST-913-SCANNER-DETECTION.conf
>>>> 
>>>> what> modSecShowRules
>>>> 
>>>> Rules: 
>>>> 
>>>> Phase: 0 (2 rules)
>>>> 
>>>>     Rule ID: 0--0x561d92adf2a0
>>>> 
>>>>     Rule ID: 0--0x561d93599630
>>>> 
>>>> Phase: 1 (2 rules)
>>>> 
>>>>     Rule ID: 0--0x561d92adf3b0
>>>> 
>>>>     Rule ID: 0--0x561d93599760
>>>> 
>>>> Phase: 2 (49 rules)
>>>> 
>>>> (..)
>>>> 
>>>>     Rule ID: 0--0x561d93599da0
>>>> 
>>>> Phase: 7 (0 rules)
>>>> 
>>>> what> modSecAddRules -p /opt/esg/current/runtime/owasp-modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf
>>>> 
>>>> what> modSecShowRules
>>>> 
>>>> Rules: 
>>>> 
>>>> Phase: 0 (4 rules)
>>>> 
>>>>     Rule ID: 0--0x561d92adf2a0
>>>> 
>>>>     Rule ID: 0--0x561d93599630
>>>> 
>>>>     Rule ID: 0--0x561d935bc6b0
>>>> 
>>>>     Rule ID: 0--0x561d92dface0
>>>> 
>>>> Phase: 1 (4 rules)
>>>> 
>>>>     Rule ID: 0--0x561d92adf3b0
>>>> 
>>>>     Rule ID: 0--0x561d93599760
>>>> 
>>>> (…)
>>>> 
>>>>  
>>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> 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] Question regarding transaction::processConnection()

[Jai H. <jai...@mu...>]

I am integrating ModSec into a security fabric edge application.

The specific problem I am encountering is for the X-Forwarded-For case. In
that case, the client's IP address is only available after request headers
are read (eg X-Forwarded-For: 123.45.67.8). Seems like processConnection()
should be called prior to addRequestHeader() and processRequestHeader(),
but I will not have accurate client IP information that early.

On Wed, Mar 7, 2018 at 2:55 PM, Robert Paprocki <
rpa...@fe...> wrote:

> Server and client port/up information is made available as data
> collections for modsec rules to use. Not calling processConnection hampers
> the rule engine in later phases if it's missing the unique ID variable,
> and/or if you have secrules that rely on layer 4 data.
>
> Just curious, what app are you integrating that you don't have access to
> the needed data?
>
> Sent from my iPhone
>
> On Mar 7, 2018, at 12:45, Jai Harpalani via mod-security-developers <
> mod...@li...> wrote:
>
> The problem is that it is difficult for my application to access all of
> the parameters required for processConnection().
>
> I see that this method is setting client and server Ips and ports as well
> as setting m_variableUniqueID. How are these variables used by the
> evaluate() call within processConnection()? How are these variables used in
> further processing?
>
> On Wed, Mar 7, 2018 at 2:42 PM, Felipe Costa <FC...@tr...> wrote:
>
>> Hi,
>>
>>
>>
>> The phases are not necessaraly in use today. Some are reserved for
>> further updates. Having say that, I would strongly recommend to call all
>> process(*) that represents each of the phases. If there is nothing to be
>> computed ModSecurity will return promptly with no harm.
>>
>>
>>
>> Br.,
>>
>> *Felipe “Zimmerle” Costa*
>>
>> Security Researcher, Lead Developer ModSecurity.
>>
>>
>>
>> *Trustwave* | SMART SECURITY ON DEMAND
>>
>> *www.trustwave.com <http://www.trustwave.com/>*
>>
>>
>>
>>
>>
>> *From: *Jai Harpalani <jai...@mu...>
>> *Date: *Wednesday, March 7, 2018 at 5:34 PM
>>
>> *To: *Felipe Costa <FC...@tr...>
>> *Cc: *"mod...@li..." <
>> mod...@li...>
>> *Subject: *Re: [Mod-security-developers] Question regarding
>> transaction::processConnection()
>>
>>
>>
>> Sorry, forgot to reply-all.
>>
>>
>>
>> So, if all I have are rules associated with SecMarkers, then is it true
>> that I don't have any SecRules associated with Phase 0?  And, if this is
>> true, then what is the purpose of transaction::processConnection()? I am
>> trying to determine what this method actually does and whether I need to
>> invoke it for my use-case.
>>
>>
>>
>> On Wed, Mar 7, 2018 at 2:26 PM, Felipe Costa <FC...@tr...>
>> wrote:
>>
>> Hi Jai,
>>
>>
>>
>> In that specific case, those are the representation of SecMarkers.
>>
>>
>>
>> Br.,
>>
>> *Felipe “Zimmerle” Costa*
>>
>> Security Researcher, Lead Developer ModSecurity.
>>
>>
>>
>> *Trustwave* | SMART SECURITY ON DEMAND
>>
>> www.trustwave.com
>>
>>
>>
>> *From: *Jai Harpalani <jai...@mu...>
>> *Date: *Wednesday, March 7, 2018 at 12:16 PM
>> *To: *Felipe Costa <FC...@tr...>
>> *Cc: *"mod...@li..." <
>> mod...@li...>
>> *Subject: *Re: [Mod-security-developers] Question regarding
>> transaction::processConnection()
>>
>>
>>
>> Using version 3.0.0 of libModSecurity.
>>
>>
>>
>> Below is output after each set of OWASP CRS rules are added. As you can
>> see, some rules are added to Phase 0 after each CRS rule set is added. I am
>> not sure what these rules do.
>>
>>
>>
>> what> modSecShowRules
>>
>> Rules:
>>
>> Phase: 0 (0 rules)
>>
>> Phase: 1 (0 rules)
>>
>> Phase: 2 (0 rules)
>>
>> Phase: 3 (0 rules)
>>
>> Phase: 4 (0 rules)
>>
>> Phase: 5 (0 rules)
>>
>> Phase: 6 (0 rules)
>>
>> Phase: 7 (0 rules)
>>
>> what> modSecAddRules -p /opt/esg/current/runtime/owasp
>> -modsecurity-crs/modsecurity.conf
>>
>> what> modSecShowRules
>>
>> Rules:
>>
>> Phase: 0 (0 rules)
>>
>> Phase: 1 (0 rules)
>>
>> Phase: 2 (2 rules)
>>
>>     Rule ID: 200000--0x561d935fce20
>>
>>     Rule ID: 200001--0x561d935fd430
>>
>> Phase: 3 (4 rules)
>>
>>     Rule ID: 200002--0x561d935d0690
>>
>>     Rule ID: 200003--0x561d93642530
>>
>>     Rule ID: 200004--0x561d93642d60
>>
>>     Rule ID: 200005--0x561d935d6160
>>
>> Phase: 4 (0 rules)
>>
>> Phase: 5 (0 rules)
>>
>> Phase: 6 (0 rules)
>>
>> Phase: 7 (0 rules)
>>
>> what> modSecAddRules -p /opt/esg/current/runtime/owasp
>> -modsecurity-crs/crs-setup.conf
>>
>> what> modSecShowRules
>>
>> Rules:
>>
>> Phase: 0 (0 rules)
>>
>> Phase: 1 (0 rules)
>>
>> Phase: 2 (4 rules)
>>
>>     Rule ID: 200000--0x561d935fce20
>>
>>     Rule ID: 200001--0x561d935fd430
>>
>>     Rule ID: 900950--0x561d935d62c0
>>
>>     Rule ID: 900990--0x561d935d66a0
>>
>> Phase: 3 (4 rules)
>>
>>     Rule ID: 200002--0x561d935d0690
>>
>>     Rule ID: 200003--0x561d93642530
>>
>>     Rule ID: 200004--0x561d93642d60
>>
>>     Rule ID: 200005--0x561d935d6160
>>
>> Phase: 4 (0 rules)
>>
>> Phase: 5 (0 rules)
>>
>> Phase: 6 (0 rules)
>>
>> Phase: 7 (0 rules)
>>
>> what> modSecAddRules -p /opt/esg/current/runtime/owasp
>> -modsecurity-crs/rules/REQUEST-901-INITIALIZATION.conf
>>
>> what> modSecShowRules
>>
>> Rules:
>>
>> Phase: 0 (1 rules)
>>
>>     Rule ID: 0--0x561d92adf2a0
>>
>> Phase: 1 (1 rules)
>>
>>     Rule ID: 0--0x561d92adf3b0
>>
>> Phase: 2 (39 rules)
>>
>> (..)
>>
>> Phase: 3 (5 rules)
>>
>>     Rule ID: 200002--0x561d935d0690
>>
>>     Rule ID: 200003--0x561d93642530
>>
>>     Rule ID: 200004--0x561d93642d60
>>
>>     Rule ID: 200005--0x561d935d6160
>>
>>     Rule ID: 0--0x561d92adf5d0
>>
>> Phase: 4 (1 rules)
>>
>>     Rule ID: 0--0x561d92adf6e0
>>
>> Phase: 5 (1 rules)
>>
>>     Rule ID: 0--0x561d92adf7f0
>>
>> Phase: 6 (1 rules)
>>
>>     Rule ID: 0--0x561d92b7def0
>>
>> Phase: 7 (0 rules)
>>
>> what>
>>
>> what> modSecAddRules -p /opt/esg/current/runtime/owasp
>> -modsecurity-crs/rules/REQUEST-913-SCANNER-DETECTION.conf
>>
>> what> modSecShowRules
>>
>> Rules:
>>
>> Phase: 0 (2 rules)
>>
>>     Rule ID: 0--0x561d92adf2a0
>>
>>     Rule ID: 0--0x561d93599630
>>
>> Phase: 1 (2 rules)
>>
>>     Rule ID: 0--0x561d92adf3b0
>>
>>     Rule ID: 0--0x561d93599760
>>
>> Phase: 2 (49 rules)
>>
>> (..)
>>
>>     Rule ID: 0--0x561d93599da0
>>
>> Phase: 7 (0 rules)
>>
>> what> modSecAddRules -p /opt/esg/current/runtime/owasp
>> -modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf
>>
>> what> modSecShowRules
>>
>> Rules:
>>
>> Phase: 0 (4 rules)
>>
>>     Rule ID: 0--0x561d92adf2a0
>>
>>     Rule ID: 0--0x561d93599630
>>
>>     Rule ID: 0--0x561d935bc6b0
>>
>>     Rule ID: 0--0x561d92dface0
>>
>> Phase: 1 (4 rules)
>>
>>     Rule ID: 0--0x561d92adf3b0
>>
>>     Rule ID: 0--0x561d93599760
>>
>> (…)
>>
>>
>>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
> _______________________________________________
> 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] Question regarding transaction::processConnection()

[Robert P. <rpa...@fe...>]

Server and client port/up information is made available as data collections for modsec rules to use. Not calling processConnection hampers the rule engine in later phases if it's missing the unique ID variable, and/or if you have secrules that rely on layer 4 data. 

Just curious, what app are you integrating that you don't have access to the needed data?

Sent from my iPhone

> On Mar 7, 2018, at 12:45, Jai Harpalani via mod-security-developers <mod...@li...> wrote:
> 
> The problem is that it is difficult for my application to access all of the parameters required for processConnection(). 
> 
> I see that this method is setting client and server Ips and ports as well as setting m_variableUniqueID. How are these variables used by the evaluate() call within processConnection()? How are these variables used in further processing?
> 
>> On Wed, Mar 7, 2018 at 2:42 PM, Felipe Costa <FC...@tr...> wrote:
>> Hi,
>> 
>>  
>> 
>> The phases are not necessaraly in use today. Some are reserved for further updates. Having say that, I would strongly recommend to call all process(*) that represents each of the phases. If there is nothing to be computed ModSecurity will return promptly with no harm.
>> 
>>  
>> 
>> Br.,
>> 
>> Felipe “Zimmerle” Costa
>> 
>> Security Researcher, Lead Developer ModSecurity.
>> 
>>  
>> 
>> Trustwave | SMART SECURITY ON DEMAND
>> 
>> www.trustwave.com
>> 
>>  
>> 
>>  
>> 
>> From: Jai Harpalani <jai...@mu...>
>> Date: Wednesday, March 7, 2018 at 5:34 PM
>> 
>> 
>> To: Felipe Costa <FC...@tr...>
>> Cc: "mod...@li..." <mod...@li...>
>> Subject: Re: [Mod-security-developers] Question regarding transaction::processConnection()
>>  
>> 
>> Sorry, forgot to reply-all.
>> 
>>  
>> 
>> So, if all I have are rules associated with SecMarkers, then is it true that I don't have any SecRules associated with Phase 0?  And, if this is true, then what is the purpose of transaction::processConnection()? I am trying to determine what this method actually does and whether I need to invoke it for my use-case.
>> 
>>  
>> 
>> On Wed, Mar 7, 2018 at 2:26 PM, Felipe Costa <FC...@tr...> wrote:
>> 
>> Hi Jai,
>> 
>>  
>> 
>> In that specific case, those are the representation of SecMarkers.
>> 
>>  
>> 
>> Br.,
>> 
>> Felipe “Zimmerle” Costa
>> 
>> Security Researcher, Lead Developer ModSecurity.
>> 
>>  
>> 
>> Trustwave | SMART SECURITY ON DEMAND
>> 
>> www.trustwave.com
>> 
>>  
>> 
>> From: Jai Harpalani <jai...@mu...>
>> Date: Wednesday, March 7, 2018 at 12:16 PM
>> To: Felipe Costa <FC...@tr...>
>> Cc: "mod...@li..." <mod...@li...>
>> Subject: Re: [Mod-security-developers] Question regarding transaction::processConnection()
>> 
>>  
>> 
>> Using version 3.0.0 of libModSecurity.
>> 
>>  
>> 
>> Below is output after each set of OWASP CRS rules are added. As you can see, some rules are added to Phase 0 after each CRS rule set is added. I am not sure what these rules do.
>> 
>>  
>> 
>> what> modSecShowRules
>> 
>> Rules: 
>> 
>> Phase: 0 (0 rules)
>> 
>> Phase: 1 (0 rules)
>> 
>> Phase: 2 (0 rules)
>> 
>> Phase: 3 (0 rules)
>> 
>> Phase: 4 (0 rules)
>> 
>> Phase: 5 (0 rules)
>> 
>> Phase: 6 (0 rules)
>> 
>> Phase: 7 (0 rules)
>> 
>> what> modSecAddRules -p /opt/esg/current/runtime/owasp-modsecurity-crs/modsecurity.conf
>> 
>> what> modSecShowRules
>> 
>> Rules: 
>> 
>> Phase: 0 (0 rules)
>> 
>> Phase: 1 (0 rules)
>> 
>> Phase: 2 (2 rules)
>> 
>>     Rule ID: 200000--0x561d935fce20
>> 
>>     Rule ID: 200001--0x561d935fd430
>> 
>> Phase: 3 (4 rules)
>> 
>>     Rule ID: 200002--0x561d935d0690
>> 
>>     Rule ID: 200003--0x561d93642530
>> 
>>     Rule ID: 200004--0x561d93642d60
>> 
>>     Rule ID: 200005--0x561d935d6160
>> 
>> Phase: 4 (0 rules)
>> 
>> Phase: 5 (0 rules)
>> 
>> Phase: 6 (0 rules)
>> 
>> Phase: 7 (0 rules)
>> 
>> what> modSecAddRules -p /opt/esg/current/runtime/owasp-modsecurity-crs/crs-setup.conf
>> 
>> what> modSecShowRules
>> 
>> Rules: 
>> 
>> Phase: 0 (0 rules)
>> 
>> Phase: 1 (0 rules)
>> 
>> Phase: 2 (4 rules)
>> 
>>     Rule ID: 200000--0x561d935fce20
>> 
>>     Rule ID: 200001--0x561d935fd430
>> 
>>     Rule ID: 900950--0x561d935d62c0
>> 
>>     Rule ID: 900990--0x561d935d66a0
>> 
>> Phase: 3 (4 rules)
>> 
>>     Rule ID: 200002--0x561d935d0690
>> 
>>     Rule ID: 200003--0x561d93642530
>> 
>>     Rule ID: 200004--0x561d93642d60
>> 
>>     Rule ID: 200005--0x561d935d6160
>> 
>> Phase: 4 (0 rules)
>> 
>> Phase: 5 (0 rules)
>> 
>> Phase: 6 (0 rules)
>> 
>> Phase: 7 (0 rules)
>> 
>> what> modSecAddRules -p /opt/esg/current/runtime/owasp-modsecurity-crs/rules/REQUEST-901-INITIALIZATION.conf
>> 
>> what> modSecShowRules
>> 
>> Rules: 
>> 
>> Phase: 0 (1 rules)
>> 
>>     Rule ID: 0--0x561d92adf2a0
>> 
>> Phase: 1 (1 rules)
>> 
>>     Rule ID: 0--0x561d92adf3b0
>> 
>> Phase: 2 (39 rules)
>> 
>> (..)
>> 
>> Phase: 3 (5 rules)
>> 
>>     Rule ID: 200002--0x561d935d0690
>> 
>>     Rule ID: 200003--0x561d93642530
>> 
>>     Rule ID: 200004--0x561d93642d60
>> 
>>     Rule ID: 200005--0x561d935d6160
>> 
>>     Rule ID: 0--0x561d92adf5d0
>> 
>> Phase: 4 (1 rules)
>> 
>>     Rule ID: 0--0x561d92adf6e0
>> 
>> Phase: 5 (1 rules)
>> 
>>     Rule ID: 0--0x561d92adf7f0
>> 
>> Phase: 6 (1 rules)
>> 
>>     Rule ID: 0--0x561d92b7def0
>> 
>> Phase: 7 (0 rules)
>> 
>> what> 
>> 
>> what> modSecAddRules -p /opt/esg/current/runtime/owasp-modsecurity-crs/rules/REQUEST-913-SCANNER-DETECTION.conf
>> 
>> what> modSecShowRules
>> 
>> Rules: 
>> 
>> Phase: 0 (2 rules)
>> 
>>     Rule ID: 0--0x561d92adf2a0
>> 
>>     Rule ID: 0--0x561d93599630
>> 
>> Phase: 1 (2 rules)
>> 
>>     Rule ID: 0--0x561d92adf3b0
>> 
>>     Rule ID: 0--0x561d93599760
>> 
>> Phase: 2 (49 rules)
>> 
>> (..)
>> 
>>     Rule ID: 0--0x561d93599da0
>> 
>> Phase: 7 (0 rules)
>> 
>> what> modSecAddRules -p /opt/esg/current/runtime/owasp-modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf
>> 
>> what> modSecShowRules
>> 
>> Rules: 
>> 
>> Phase: 0 (4 rules)
>> 
>>     Rule ID: 0--0x561d92adf2a0
>> 
>>     Rule ID: 0--0x561d93599630
>> 
>>     Rule ID: 0--0x561d935bc6b0
>> 
>>     Rule ID: 0--0x561d92dface0
>> 
>> Phase: 1 (4 rules)
>> 
>>     Rule ID: 0--0x561d92adf3b0
>> 
>>     Rule ID: 0--0x561d93599760
>> 
>> (…)
>> 
>>  
>> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> 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] Question regarding transaction::processConnection()

[Jai H. <jai...@mu...>]

The problem is that it is difficult for my application to access all of the
parameters required for processConnection().

I see that this method is setting client and server Ips and ports as well
as setting m_variableUniqueID. How are these variables used by the
evaluate() call within processConnection()? How are these variables used in
further processing?

On Wed, Mar 7, 2018 at 2:42 PM, Felipe Costa <FC...@tr...> wrote:

> Hi,
>
>
>
> The phases are not necessaraly in use today. Some are reserved for further
> updates. Having say that, I would strongly recommend to call all process(*)
> that represents each of the phases. If there is nothing to be computed
> ModSecurity will return promptly with no harm.
>
>
>
> Br.,
>
> *Felipe “Zimmerle” Costa*
>
> Security Researcher, Lead Developer ModSecurity.
>
>
>
> *Trustwave* | SMART SECURITY ON DEMAND
>
> *www.trustwave.com <http://www.trustwave.com/>*
>
>
>
>
>
> *From: *Jai Harpalani <jai...@mu...>
> *Date: *Wednesday, March 7, 2018 at 5:34 PM
>
> *To: *Felipe Costa <FC...@tr...>
> *Cc: *"mod...@li..." <
> mod...@li...>
> *Subject: *Re: [Mod-security-developers] Question regarding transaction::
> processConnection()
>
>
>
> Sorry, forgot to reply-all.
>
>
>
> So, if all I have are rules associated with SecMarkers, then is it true
> that I don't have any SecRules associated with Phase 0?  And, if this is
> true, then what is the purpose of transaction::processConnection()? I am
> trying to determine what this method actually does and whether I need to
> invoke it for my use-case.
>
>
>
> On Wed, Mar 7, 2018 at 2:26 PM, Felipe Costa <FC...@tr...> wrote:
>
> Hi Jai,
>
>
>
> In that specific case, those are the representation of SecMarkers.
>
>
>
> Br.,
>
> *Felipe “Zimmerle” Costa*
>
> Security Researcher, Lead Developer ModSecurity.
>
>
>
> *Trustwave* | SMART SECURITY ON DEMAND
>
> www.trustwave.com
>
>
>
> *From: *Jai Harpalani <jai...@mu...>
> *Date: *Wednesday, March 7, 2018 at 12:16 PM
> *To: *Felipe Costa <FC...@tr...>
> *Cc: *"mod...@li..." <
> mod...@li...>
> *Subject: *Re: [Mod-security-developers] Question regarding transaction::
> processConnection()
>
>
>
> Using version 3.0.0 of libModSecurity.
>
>
>
> Below is output after each set of OWASP CRS rules are added. As you can
> see, some rules are added to Phase 0 after each CRS rule set is added. I am
> not sure what these rules do.
>
>
>
> what> modSecShowRules
>
> Rules:
>
> Phase: 0 (0 rules)
>
> Phase: 1 (0 rules)
>
> Phase: 2 (0 rules)
>
> Phase: 3 (0 rules)
>
> Phase: 4 (0 rules)
>
> Phase: 5 (0 rules)
>
> Phase: 6 (0 rules)
>
> Phase: 7 (0 rules)
>
> what> modSecAddRules -p /opt/esg/current/runtime/owasp-modsecurity-crs/
> modsecurity.conf
>
> what> modSecShowRules
>
> Rules:
>
> Phase: 0 (0 rules)
>
> Phase: 1 (0 rules)
>
> Phase: 2 (2 rules)
>
>     Rule ID: 200000--0x561d935fce20
>
>     Rule ID: 200001--0x561d935fd430
>
> Phase: 3 (4 rules)
>
>     Rule ID: 200002--0x561d935d0690
>
>     Rule ID: 200003--0x561d93642530
>
>     Rule ID: 200004--0x561d93642d60
>
>     Rule ID: 200005--0x561d935d6160
>
> Phase: 4 (0 rules)
>
> Phase: 5 (0 rules)
>
> Phase: 6 (0 rules)
>
> Phase: 7 (0 rules)
>
> what> modSecAddRules -p /opt/esg/current/runtime/
> owasp-modsecurity-crs/crs-setup.conf
>
> what> modSecShowRules
>
> Rules:
>
> Phase: 0 (0 rules)
>
> Phase: 1 (0 rules)
>
> Phase: 2 (4 rules)
>
>     Rule ID: 200000--0x561d935fce20
>
>     Rule ID: 200001--0x561d935fd430
>
>     Rule ID: 900950--0x561d935d62c0
>
>     Rule ID: 900990--0x561d935d66a0
>
> Phase: 3 (4 rules)
>
>     Rule ID: 200002--0x561d935d0690
>
>     Rule ID: 200003--0x561d93642530
>
>     Rule ID: 200004--0x561d93642d60
>
>     Rule ID: 200005--0x561d935d6160
>
> Phase: 4 (0 rules)
>
> Phase: 5 (0 rules)
>
> Phase: 6 (0 rules)
>
> Phase: 7 (0 rules)
>
> what> modSecAddRules -p /opt/esg/current/runtime/
> owasp-modsecurity-crs/rules/REQUEST-901-INITIALIZATION.conf
>
> what> modSecShowRules
>
> Rules:
>
> Phase: 0 (1 rules)
>
>     Rule ID: 0--0x561d92adf2a0
>
> Phase: 1 (1 rules)
>
>     Rule ID: 0--0x561d92adf3b0
>
> Phase: 2 (39 rules)
>
> (..)
>
> Phase: 3 (5 rules)
>
>     Rule ID: 200002--0x561d935d0690
>
>     Rule ID: 200003--0x561d93642530
>
>     Rule ID: 200004--0x561d93642d60
>
>     Rule ID: 200005--0x561d935d6160
>
>     Rule ID: 0--0x561d92adf5d0
>
> Phase: 4 (1 rules)
>
>     Rule ID: 0--0x561d92adf6e0
>
> Phase: 5 (1 rules)
>
>     Rule ID: 0--0x561d92adf7f0
>
> Phase: 6 (1 rules)
>
>     Rule ID: 0--0x561d92b7def0
>
> Phase: 7 (0 rules)
>
> what>
>
> what> modSecAddRules -p /opt/esg/current/runtime/
> owasp-modsecurity-crs/rules/REQUEST-913-SCANNER-DETECTION.conf
>
> what> modSecShowRules
>
> Rules:
>
> Phase: 0 (2 rules)
>
>     Rule ID: 0--0x561d92adf2a0
>
>     Rule ID: 0--0x561d93599630
>
> Phase: 1 (2 rules)
>
>     Rule ID: 0--0x561d92adf3b0
>
>     Rule ID: 0--0x561d93599760
>
> Phase: 2 (49 rules)
>
> (..)
>
>     Rule ID: 0--0x561d93599da0
>
> Phase: 7 (0 rules)
>
> what> modSecAddRules -p /opt/esg/current/runtime/
> owasp-modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf
>
> what> modSecShowRules
>
> Rules:
>
> Phase: 0 (4 rules)
>
>     Rule ID: 0--0x561d92adf2a0
>
>     Rule ID: 0--0x561d93599630
>
>     Rule ID: 0--0x561d935bc6b0
>
>     Rule ID: 0--0x561d92dface0
>
> Phase: 1 (4 rules)
>
>     Rule ID: 0--0x561d92adf3b0
>
>     Rule ID: 0--0x561d93599760
>
> (…)
>
>
>