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