|
From: Jai H. <jai...@mu...> - 2018-03-07 21:05:16
|
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 > > |
