|
From: Robert P. <rpa...@fe...> - 2018-03-07 21:08:35
|
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 > |
