mod-security-developers Mailing List for ModSecurity (Page 6)
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
mod-security-developers — Development discussion about mod_security
You can subscribe to this list here.
| 2006 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(8) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(9) |
Sep
|
Oct
(1) |
Nov
|
Dec
(3) |
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
(12) |
Mar
(42) |
Apr
(68) |
May
(30) |
Jun
(50) |
Jul
(17) |
Aug
(3) |
Sep
(5) |
Oct
(7) |
Nov
(3) |
Dec
(4) |
| 2012 |
Jan
(11) |
Feb
(11) |
Mar
(37) |
Apr
|
May
(21) |
Jun
(21) |
Jul
(12) |
Aug
(41) |
Sep
(19) |
Oct
(31) |
Nov
(24) |
Dec
(10) |
| 2013 |
Jan
(12) |
Feb
(18) |
Mar
(3) |
Apr
(8) |
May
(35) |
Jun
(5) |
Jul
(38) |
Aug
(5) |
Sep
(2) |
Oct
(4) |
Nov
(11) |
Dec
(6) |
| 2014 |
Jan
(3) |
Feb
(12) |
Mar
(11) |
Apr
(18) |
May
(2) |
Jun
(1) |
Jul
(11) |
Aug
(5) |
Sep
|
Oct
(15) |
Nov
(13) |
Dec
(9) |
| 2015 |
Jan
(2) |
Feb
(8) |
Mar
(7) |
Apr
(3) |
May
|
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
(11) |
Oct
(14) |
Nov
(4) |
Dec
(1) |
| 2016 |
Jan
(11) |
Feb
(19) |
Mar
(20) |
Apr
(6) |
May
(3) |
Jun
(17) |
Jul
(5) |
Aug
|
Sep
(7) |
Oct
(2) |
Nov
(2) |
Dec
(12) |
| 2017 |
Jan
(4) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(3) |
Oct
(1) |
Nov
|
Dec
(15) |
| 2018 |
Jan
(13) |
Feb
(2) |
Mar
(14) |
Apr
(9) |
May
|
Jun
(6) |
Jul
(3) |
Aug
(1) |
Sep
(3) |
Oct
|
Nov
(13) |
Dec
(1) |
| 2019 |
Jan
(2) |
Feb
(9) |
Mar
(28) |
Apr
(4) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
(2) |
| 2020 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(3) |
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(10) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jai H. <jai...@mu...> - 2018-03-07 20:34:24
|
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 <http://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 > > (…) > |
|
From: Felipe C. <FC...@tr...> - 2018-03-07 20:28:20
|
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<http://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 (…) |
|
From: Jai H. <jai...@mu...> - 2018-03-07 15:16:38
|
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)
Rule ID: 200000--0x561d935fce20
Rule ID: 200001--0x561d935fd430
Rule ID: 900950--0x561d935d62c0
Rule ID: 900990--0x561d935d66a0
Rule ID: 900220--0x561d92c545b0
Rule ID: 900240--0x561d935d6cb0
Rule ID: 900300--0x561d92aeb250
Rule ID: 900310--0x561d92aeb770
Rule ID: 900320--0x561d92aebbe0
Rule ID: 900330--0x561d92aec110
Rule ID: 900340--0x561d92e13060
Rule ID: 900350--0x561d92c535f0
Rule ID: 901001--0x561d92c53dd0
Rule ID: 901100--0x561d936003d0
Rule ID: 901110--0x561d93600a40
Rule ID: 901120--0x561d936010f0
Rule ID: 901130--0x561d92e13960
Rule ID: 901140--0x561d92e13fe0
Rule ID: 901141--0x561d92e11da0
Rule ID: 901142--0x561d92e12400
Rule ID: 901143--0x561d92e12a80
Rule ID: 901150--0x561d935dd7a0
Rule ID: 901152--0x561d935dde50
Rule ID: 901160--0x561d935de500
Rule ID: 901162--0x561d92b96ce0
Rule ID: 901163--0x561d92b973d0
Rule ID: 901164--0x561d92b97ba0
Rule ID: 901165--0x561d93630480
Rule ID: 901166--0x561d93630b30
Rule ID: 901200--0x561d92f3a680
Rule ID: 901318--0x561d92f3aa90
Rule ID: 901321--0x561d92f3b1a0
Rule ID: 901400--0x561d92e273b0
Rule ID: 901410--0x561d92e27a20
Rule ID: 901420--0x561d92e28020
Rule ID: 901430--0x561d92ade3a0
Rule ID: 901440--0x561d92ade9d0
Rule ID: 901450--0x561d92adf110
Rule ID: 0--0x561d92adf4c0
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: 200000--0x561d935fce20
Rule ID: 200001--0x561d935fd430
Rule ID: 900950--0x561d935d62c0
Rule ID: 900990--0x561d935d66a0
Rule ID: 900220--0x561d92c545b0
Rule ID: 900240--0x561d935d6cb0
Rule ID: 900300--0x561d92aeb250
Rule ID: 900310--0x561d92aeb770
Rule ID: 900320--0x561d92aebbe0
Rule ID: 900330--0x561d92aec110
Rule ID: 900340--0x561d92e13060
Rule ID: 900350--0x561d92c535f0
Rule ID: 901001--0x561d92c53dd0
Rule ID: 901100--0x561d936003d0
Rule ID: 901110--0x561d93600a40
Rule ID: 901120--0x561d936010f0
Rule ID: 901130--0x561d92e13960
Rule ID: 901140--0x561d92e13fe0
Rule ID: 901141--0x561d92e11da0
Rule ID: 901142--0x561d92e12400
Rule ID: 901143--0x561d92e12a80
Rule ID: 901150--0x561d935dd7a0
Rule ID: 901152--0x561d935dde50
Rule ID: 901160--0x561d935de500
Rule ID: 901162--0x561d92b96ce0
Rule ID: 901163--0x561d92b973d0
Rule ID: 901164--0x561d92b97ba0
Rule ID: 901165--0x561d93630480
Rule ID: 901166--0x561d93630b30
Rule ID: 901200--0x561d92f3a680
Rule ID: 901318--0x561d92f3aa90
Rule ID: 901321--0x561d92f3b1a0
Rule ID: 901400--0x561d92e273b0
Rule ID: 901410--0x561d92e27a20
Rule ID: 901420--0x561d92e28020
Rule ID: 901430--0x561d92ade3a0
Rule ID: 901440--0x561d92ade9d0
Rule ID: 901450--0x561d92adf110
Rule ID: 0--0x561d92adf4c0
Rule ID: 913011--0x561d92b7e230
Rule ID: 913100--0x561d935d3df0
Rule ID: 913110--0x561d92c5cd20
Rule ID: 913120--0x561d935adcf0
Rule ID: 913013--0x561d935ae0f0
Rule ID: 913101--0x561d92ea3230
Rule ID: 913102--0x561d92e8d180
Rule ID: 913015--0x561d92e8d580
Rule ID: 913017--0x561d92e8dff0
Rule ID: 0--0x561d93599890
Phase: 3 (10 rules)
Rule ID: 200002--0x561d935d0690
Rule ID: 200003--0x561d93642530
Rule ID: 200004--0x561d93642d60
Rule ID: 200005--0x561d935d6160
Rule ID: 0--0x561d92adf5d0
Rule ID: 913012--0x561d92b7e7d0
Rule ID: 913014--0x561d935ae610
Rule ID: 913016--0x561d92e8da80
Rule ID: 913018--0x561d93599550
Rule ID: 0--0x561d935999c0
Phase: 4 (2 rules)
Rule ID: 0--0x561d92adf6e0
Rule ID: 0--0x561d93599b40
Phase: 5 (2 rules)
Rule ID: 0--0x561d92adf7f0
Rule ID: 0--0x561d93599c70
Phase: 6 (2 rules)
Rule ID: 0--0x561d92b7def0
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
Rule ID: 0--0x561d935bc380
Rule ID: 0--0x561d92dfb020
Phase: 2 (86 rules)
Rule ID: 200000--0x561d935fce20
Rule ID: 200001--0x561d935fd430
Rule ID: 900950--0x561d935d62c0
Rule ID: 900990--0x561d935d66a0
Rule ID: 900220--0x561d92c545b0
Rule ID: 900240--0x561d935d6cb0
Rule ID: 900300--0x561d92aeb250
Rule ID: 900310--0x561d92aeb770
Rule ID: 900320--0x561d92aebbe0
Rule ID: 900330--0x561d92aec110
Rule ID: 900340--0x561d92e13060
Rule ID: 900350--0x561d92c535f0
Rule ID: 901001--0x561d92c53dd0
Rule ID: 901100--0x561d936003d0
Rule ID: 901110--0x561d93600a40
Rule ID: 901120--0x561d936010f0
Rule ID: 901130--0x561d92e13960
Rule ID: 901140--0x561d92e13fe0
Rule ID: 901141--0x561d92e11da0
Rule ID: 901142--0x561d92e12400
Rule ID: 901143--0x561d92e12a80
Rule ID: 901150--0x561d935dd7a0
Rule ID: 901152--0x561d935dde50
Rule ID: 901160--0x561d935de500
Rule ID: 901162--0x561d92b96ce0
Rule ID: 901163--0x561d92b973d0
Rule ID: 901164--0x561d92b97ba0
Rule ID: 901165--0x561d93630480
Rule ID: 901166--0x561d93630b30
Rule ID: 901200--0x561d92f3a680
Rule ID: 901318--0x561d92f3aa90
Rule ID: 901321--0x561d92f3b1a0
Rule ID: 901400--0x561d92e273b0
Rule ID: 901410--0x561d92e27a20
Rule ID: 901420--0x561d92e28020
Rule ID: 901430--0x561d92ade3a0
Rule ID: 901440--0x561d92ade9d0
Rule ID: 901450--0x561d92adf110
Rule ID: 0--0x561d92adf4c0
Rule ID: 913011--0x561d92b7e230
Rule ID: 913100--0x561d935d3df0
Rule ID: 913110--0x561d92c5cd20
Rule ID: 913120--0x561d935adcf0
Rule ID: 913013--0x561d935ae0f0
Rule ID: 913101--0x561d92ea3230
Rule ID: 913102--0x561d92e8d180
Rule ID: 913015--0x561d92e8d580
Rule ID: 913017--0x561d92e8dff0
Rule ID: 0--0x561d93599890
Rule ID: 920011--0x561d92c11740
Rule ID: 920100--0x561d9360e8a0
Rule ID: 920160--0x561d93599e80
Rule ID: 920170--0x561d9359abc0
Rule ID: 920180--0x561d9359bf20
Rule ID: 920190--0x561d935b3340
Rule ID: 920210--0x561d935b49e0
Rule ID: 920220--0x561d935b5450
Rule ID: 920240--0x561d935b6730
Rule ID: 920250--0x561d935b7c20
Rule ID: 920280--0x561d935bb780
Rule ID: 920290--0x561d935bc7c0
Rule ID: 0--0x561d935bc910
Rule ID: 920310--0x561d935bda90
Rule ID: 920311--0x561d934e93e0
Rule ID: 920330--0x561d934eaea0
Rule ID: 920340--0x561d934eb890
Rule ID: 920350--0x561d934ed3e0
Rule ID: 920380--0x561d934edf00
Rule ID: 920360--0x561d934ef270
Rule ID: 920370--0x561d934f0630
Rule ID: 920390--0x561d934f19c0
Rule ID: 920400--0x561d934f2cb0
Rule ID: 920410--0x561d934f4350
Rule ID: 920420--0x561d934f5aa0
Rule ID: 920450--0x561d934c0db0
Rule ID: 920013--0x561d934c1970
Rule ID: 920200--0x561d934c31b0
Rule ID: 920201--0x561d934c4580
Rule ID: 920230--0x561d934c5cf0
Rule ID: 920300--0x561d934c6c50
Rule ID: 920271--0x561d934c9800
Rule ID: 920320--0x561d934caa60
Rule ID: 920015--0x561d92df3870
Rule ID: 920017--0x561d92df55d0
Rule ID: 920460--0x561d92dfae60
Rule ID: 0--0x561d92dfb100
Phase: 3 (28 rules)
Rule ID: 200002--0x561d935d0690
Rule ID: 200003--0x561d93642530
Rule ID: 200004--0x561d93642d60
Rule ID: 200005--0x561d935d6160
Rule ID: 0--0x561d92adf5d0
Rule ID: 913012--0x561d92b7e7d0
Rule ID: 913014--0x561d935ae610
Rule ID: 913016--0x561d92e8da80
Rule ID: 913018--0x561d93599550
Rule ID: 0--0x561d935999c0
Rule ID: 920012--0x561d92c11c80
Rule ID: 920120--0x561d92b38010
Rule ID: 920130--0x561d92b39060
Rule ID: 920140--0x561d935fbab0
Rule ID: 920260--0x561d935b93e0
Rule ID: 920270--0x561d935ba580
Rule ID: 0--0x561d935bc9f0
Rule ID: 920430--0x561d934be2c0
Rule ID: 920440--0x561d934bf480
Rule ID: 920014--0x561d934c1f10
Rule ID: 920121--0x561d934cbd20
Rule ID: 920016--0x561d92df3db0
Rule ID: 920272--0x561d92df5260
Rule ID: 920018--0x561d92df5b70
Rule ID: 920202--0x561d92df6b70
Rule ID: 920273--0x561d92df8500
Rule ID: 920274--0x561d92df98f0
Rule ID: 0--0x561d92dfb230
Phase: 4 (4 rules)
Rule ID: 0--0x561d92adf6e0
Rule ID: 0--0x561d93599b40
Rule ID: 0--0x561d935bcb00
Rule ID: 0--0x561d92dfb360
Phase: 5 (4 rules)
Rule ID: 0--0x561d92adf7f0
Rule ID: 0--0x561d93599c70
Rule ID: 0--0x561d935bcc10
Rule ID: 0--0x561d92dfb490
Phase: 6 (4 rules)
Rule ID: 0--0x561d92b7def0
Rule ID: 0--0x561d93599da0
Rule ID: 0--0x561d935bcd20
Rule ID: 0--0x561d92dfb5c0
On Wed, Mar 7, 2018 at 4:50 AM, Felipe Costa <FC...@tr...> wrote:
> Hi Jai,
>
>
>
> What is the version of yours libModSecurity? Do you happen to have any
> public rule set loaded? If so, can you share the version info?
>
>
>
> Br.,
>
> *Felipe “Zimmerle” Costa*
>
> Security Researcher, Lead Developer ModSecurity.
>
>
>
> *Trustwave* | SMART SECURITY ON DEMAND
>
> *www.trustwave.com <http://www.trustwave.com/>*
>
>
>
> *From: *Jai Harpalani via mod-security-developers <
> mod...@li...>
> *Reply-To: *"mod...@li..." <
> mod...@li...>
> *Date: *Tuesday, March 6, 2018 at 9:16 PM
> *To: *"mod...@li..." <
> mod...@li...>
> *Cc: *Jai Harpalani <jai...@mu...>
> *Subject: *[Mod-security-developers] Question regarding transaction::
> processConnection()
>
>
>
> What is the purpose of transaction::processConnection()? I see that after
> populating IP addresses and Port addresses, it invokes evaluate() with
> ConnectionPhase. Can someone elaborate on what this evaluate() call will
> check? I see the below rules for the ConnectionPhase in my system, but all
> RuleIds = 0 so I do not know what these rules do.
>
>
>
> Phase: 0 (18 rules)
>
> Rule ID: 0--0x555556494c20
>
> Rule ID: 0--0x5555563d9d20
>
> Rule ID: 0--0x555556426550
>
> Rule ID: 0--0x55555632f880
>
> Rule ID: 0--0x5555563fe760
>
> Rule ID: 0--0x5555562776f0
>
> Rule ID: 0--0x55555627f750
>
> Rule ID: 0--0x5555560997f0
>
> Rule ID: 0--0x5555566eec00
>
> Rule ID: 0--0x5555567247b0
>
> Rule ID: 0--0x555556731f50
>
> Rule ID: 0--0x5555567c1b70
>
> Rule ID: 0--0x55555673e0d0
>
> Rule ID: 0--0x555556740250
>
> Rule ID: 0--0x555555e96650
>
> Rule ID: 0--0x5555567dbc40
>
> Rule ID: 0--0x5555567dc260
>
> Rule ID: 0--0x5555567e75c0
>
>
>
> Thanks,
>
> Jai
>
>
>
>
>
|
|
From: Felipe C. <FC...@tr...> - 2018-03-07 10:50:44
|
Hi Jai, What is the version of yours libModSecurity? Do you happen to have any public rule set loaded? If so, can you share the version info? Br., Felipe “Zimmerle” Costa Security Researcher, Lead Developer ModSecurity. Trustwave | SMART SECURITY ON DEMAND www.trustwave.com<http://www.trustwave.com/> From: Jai Harpalani via mod-security-developers <mod...@li...> Reply-To: "mod...@li..." <mod...@li...> Date: Tuesday, March 6, 2018 at 9:16 PM To: "mod...@li..." <mod...@li...> Cc: Jai Harpalani <jai...@mu...> Subject: [Mod-security-developers] Question regarding transaction::processConnection() What is the purpose of transaction::processConnection()? I see that after populating IP addresses and Port addresses, it invokes evaluate() with ConnectionPhase. Can someone elaborate on what this evaluate() call will check? I see the below rules for the ConnectionPhase in my system, but all RuleIds = 0 so I do not know what these rules do. Phase: 0 (18 rules) Rule ID: 0--0x555556494c20 Rule ID: 0--0x5555563d9d20 Rule ID: 0--0x555556426550 Rule ID: 0--0x55555632f880 Rule ID: 0--0x5555563fe760 Rule ID: 0--0x5555562776f0 Rule ID: 0--0x55555627f750 Rule ID: 0--0x5555560997f0 Rule ID: 0--0x5555566eec00 Rule ID: 0--0x5555567247b0 Rule ID: 0--0x555556731f50 Rule ID: 0--0x5555567c1b70 Rule ID: 0--0x55555673e0d0 Rule ID: 0--0x555556740250 Rule ID: 0--0x555555e96650 Rule ID: 0--0x5555567dbc40 Rule ID: 0--0x5555567dc260 Rule ID: 0--0x5555567e75c0 Thanks, Jai |
|
From: Jai H. <jai...@mu...> - 2018-03-07 00:16:17
|
What is the purpose of transaction::processConnection()? I see that after
populating IP addresses and Port addresses, it invokes evaluate() with
ConnectionPhase. Can someone elaborate on what this evaluate() call will
check? I see the below rules for the ConnectionPhase in my system, but all
RuleIds = 0 so I do not know what these rules do.
Phase: 0 (18 rules)
Rule ID: 0--0x555556494c20
Rule ID: 0--0x5555563d9d20
Rule ID: 0--0x555556426550
Rule ID: 0--0x55555632f880
Rule ID: 0--0x5555563fe760
Rule ID: 0--0x5555562776f0
Rule ID: 0--0x55555627f750
Rule ID: 0--0x5555560997f0
Rule ID: 0--0x5555566eec00
Rule ID: 0--0x5555567247b0
Rule ID: 0--0x555556731f50
Rule ID: 0--0x5555567c1b70
Rule ID: 0--0x55555673e0d0
Rule ID: 0--0x555556740250
Rule ID: 0--0x555555e96650
Rule ID: 0--0x5555567dbc40
Rule ID: 0--0x5555567dc260
Rule ID: 0--0x5555567e75c0
Thanks,
Jai
|
|
From: Marc S. <mar...@ap...> - 2018-02-27 07:43:51
|
Hello, Did anybody investigate the effort to support the new geolite2 format in v2, as the legacy one will not be updated from April? Thanks Marc |
|
From: Felipe Z. <fe...@zi...> - 2018-02-05 13:37:13
|
As explained in another thread the correct pick will be 'clang version 5.0.1'. Br., Felipe On Sun, Jan 14, 2018 at 7:19 PM Ervin Hegedüs <ai...@gm...> wrote: > Hi there, > > I'm playing with ModSecurity 3, and try to build first with all > available features. > > I've installed all necessary libraries, and gave: > > ./configure --with-lmdb --enable-parser-generation --enable-mutex-on-pm > --enable-afl-fuzz > > then > > export CXX=afl-clang-fast++ > export CC=afl-clang-fast > > > and > > make. > > I'm using GNU GCC - tried with different versions: > * gcc version 7.2.0 > * gcc version 6.3.0 > * gcc version 4.9.2 > > > but none of above supports the option "-fsanitize-coverage=4". > > I've read the GCC documantation here: > > https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html > > but looks like GCC doesn't support this option, only the > > -fsanitize-coverage=trace-pc > > and > > -fsanitize-coverage=trace-cmp > > Which C compiler supports the original option? > > > Thanks, > > > 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 > |
|
From: Jai H. <jai...@mu...> - 2018-01-29 16:46:08
|
I am invoking intervention() as follows:
Transaction aTransaction;
ModSecurityIntervention aModSecIntervention;
aTransaction = msc_new_transaction(modsec, rules, NULL);
msc_process_uri(transaction,
"http://www.modsecurity.org/test?key1=value1&key2=value2&key3=value3
",
"WRONG METHOD", "1.1");
msc_process_request_headers(transaction);
ret = msc_intervention(transaction, &aModSecIntervention);
As expected, I see some console messages indicating that a rule has fired
due to method set to "WRONG METHOD". But, msc_intervention() is returning
0, and aModSecIntervention's attributes are:
status = 0, pause = 0, disruptive = false
I am looking for some values either returned from msc_intervention() or set
within aModSecIntervention which would let the caller know a rule is
triggered. How will a caller know when a rule has been triggered?
Thanks,
Jai
|
|
From: Andrew J. <4an...@gm...> - 2018-01-29 14:40:18
|
Hello, What will be the release schedule for Stable version of ModSecurity-apache connector ? Thanks in Advance Regards, Andrew Joshwa |
|
From: Ervin H. <ai...@gm...> - 2018-01-14 22:18:47
|
Hi there, I'm playing with ModSecurity 3, and try to build first with all available features. I've installed all necessary libraries, and gave: ./configure --with-lmdb --enable-parser-generation --enable-mutex-on-pm --enable-afl-fuzz then export CXX=afl-clang-fast++ export CC=afl-clang-fast and make. I'm using GNU GCC - tried with different versions: * gcc version 7.2.0 * gcc version 6.3.0 * gcc version 4.9.2 but none of above supports the option "-fsanitize-coverage=4". I've read the GCC documantation here: https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html but looks like GCC doesn't support this option, only the -fsanitize-coverage=trace-pc and -fsanitize-coverage=trace-cmp Which C compiler supports the original option? Thanks, a. |
|
From: Christian F. <chr...@ne...> - 2018-01-03 13:42:12
|
On Wed, Jan 03, 2018 at 12:17:07PM +0000, Felipe Costa wrote: > As of version 3, collections [SESSION and others] can be saved using > our own backend. It means that you can use memcache, redis or any other > `thing’ capable to store key-pair values. So the data will be > persistent in the backend server; Up to the backend server to limit the > time and amount of data. This is one of the biggest improvements of ModSec3 over ModSec2. Really looking forward to use this in production! Christian > > > Br., > > Felipe “Zimmerle” Costa > > Security Researcher, Lead Developer ModSecurity. > > > Trustwave | SMART SECURITY ON DEMAND > > [1]www.trustwave.com > > > > From: Jai Harpalani <jai...@mu...> > Reply-To: "mod...@li..." > <mod...@li...> > Date: Tuesday, January 2, 2018 at 3:52 PM > To: "mod...@li..." > <mod...@li...> > Subject: Re: [Mod-security-developers] API Usage and Descriptions? > > > Are the two rules below examples of how historical information can be > incorporated into rules? In general, are variables modified and then > re-examined by rules to take advantage of historical information? Are > there other ways in which historical information can be used within > rules? > > > # Increment session score on attack > SecRule REQUEST_URI "^/cgi-bin/finger$" "phase:2,id:71,t:none,t:lowercase,t:norm > alizePath,pass,setvar:SESSION.score=+10" > > # Detect too many attacks in a session > SecRule SESSION:score "@gt 50" "phase:2,id:72,pass,setvar:SESSION.blocked=1" > > > On Tue, Jan 2, 2018 at 12:08 PM, Christian Folini > <[2]chr...@ne...> wrote: > > On Tue, Jan 02, 2018 at 11:50:00AM -0600, Jai Harpalani wrote: > > Does mod security use historical information when it applies > rules? > > For example, does mod security know and use information about > prior > > http requests when applying rules to the current one? > ModSecurity is only the engine. What you are asking is part of the > rule > set. There is depends on the rules you are employing. > Generally no, but they can be written in a way to use that > information. > The Core Rule Set - the rule set with the biggest user base - > generally > does not do this. > Best, > Christian > > > > On Thu, Dec 28, 2017 at 1:21 PM, Jai Harpalani > > <[1][3]jai...@mu...> wrote: > > > > Felipe, > > Thanks for the information. I will most likely have more > questions as > > I continue working on this. > > Thanks, > > Jai > > > > On Fri, Dec 22, 2017 at 8:24 AM, Felipe Costa > <[2][4]FC...@tr...> > > wrote: > > > > Hi Jai, > > > > The idea is to have a transaction for each HTTP request. So, > > msc_new_transaction() should be called every time that a new > connection > > is established. In additional to the ModSecurity v2.x phases, > > ModSecurity v3 can also process rules for this additional URI > phase. > > That is after you got the connection details and before you get > the > > client headers. > > > > You can find more details about how to implement a connector in > the > > Transaction code: > > > > - > [3][5]https://github.com/SpiderLabs/ModSecurity/blob/v3/master/ > > src/transaction.cc > > You may also want to generate the doxygen docs: > > $ cd doc ; doxygen doxygen.cfg > > > > Notice that there is no phase on SecRules to hit the uri > processing. At > > least not yet. We are aiming to support in upcoming versions. > > > > Br., > > > > Felipe “Zimmerle” Costa > > > > Security Researcher, Lead Developer ModSecurity. > > > > > > Trustwave | SMART SECURITY ON DEMAND > > > > [4][6]www.trustwave.com > > > __________________________________________________________________ > > > > From: Jai Harpalani <[5][7]jai...@mu...> > > Sent: Wednesday, December 20, 2017 3:52:27 PM > > To: [6][8]mod...@li... > > Subject: [Mod-security-developers] API Usage and Descriptions? > > > > I have an application which already retrieves requests and > responses > > from "the wire". I'm trying to add modSecurity to check the > > requests/responses for WAF errors using: > > msc_process_request_headers(); > > msc_process_request_body(); > > msc_process_response_headers(); > > msc_process_response_body(); > > I don't want WAF to necessarily take any action, just inform > the caller > > if any problems were found. If this is possible, how is it > done? > > Also, not sure what the purpose of the below APIs is for my > specific > > application. > > msc_new_transaction(); > > msc_process_connection(t); > > msc_process_uri(); > > I was not able to locate a description of the above APIs. If > detailed > > descriptions exist, please let me know where they are located. > > Thanks. > > > > ------------------------------------------------------------ > > ------------------ > > Check out the vibrant tech community on one of the world's > most > > engaging tech sites, [9]Slashdot.org! > [7][10]http://sdm.link/slashdot > > _______________________________________________ > > mod-security-developers mailing list > > [8][11]mod...@li... > > > [9][12]https://lists.sourceforge.net/lists/listinfo/mod-security-de > > velopers > > ModSecurity Services from Trustwave's SpiderLabs: > > [10][13]https://www.trustwave.com/spiderLabs.php > > > > References > > > > 1. mailto:[14]jai...@mu... > > 2. mailto:[15]FC...@tr... > > 3. > [16]https://github.com/SpiderLabs/ModSecurity/blob/v3/master/src/tra > nsaction.cc > > 4. [17]http://www.trustwave.com/ > > 5. mailto:[18]jai...@mu... > > 6. mailto:[19]mod...@li... > > 7. [20]http://sdm.link/slashdot > > 8. mailto:[21]mod...@li... > > 9. > [22]https://lists.sourceforge.net/lists/listinfo/mod-security-develo > pers > > 10. [23]https://www.trustwave.com/spiderLabs.php > > > -------------------------------------------------------------------- > ---------- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, [24]Slashdot.org! > [25]http://sdm.link/slashdot > > _______________________________________________ > > mod-security-developers mailing list > > [26]mod...@li... > > > [27]https://lists.sourceforge.net/lists/listinfo/mod-security-develo > pers > > ModSecurity Services from Trustwave's SpiderLabs: > > [28]https://www.trustwave.com/spiderLabs.php > -- > [29]https://www.feistyduck.com/training/modsecurity-training-course > [30]https://www.feistyduck.com/books/modsecurity-handbook/ > mailto:[31]chr...@ne... > twitter: @ChrFolini > > ----------------------------------------------------------------------- > ------- > Check out the vibrant tech community on one of the world's most > engaging tech sites, [32]Slashdot.org! [33]http://sdm.link/slashdot > _______________________________________________ > mod-security-developers mailing list > [34]mod...@li... > [35]https://lists.sourceforge.net/lists/listinfo/mod-security-developer > s > ModSecurity Services from Trustwave's SpiderLabs: > [36]https://www.trustwave.com/spiderLabs.php > > References > > 1. http://www.trustwave.com/ > 2. mailto:chr...@ne... > 3. mailto:jai...@mu... > 4. mailto:FC...@tr... > 5. https://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABihQEuWt1Q&s=5&u=https://github.com/SpiderLabs/ModSecurity/blob/v3/master/ > 6. http://www.trustwave.com/ > 7. mailto:jai...@mu... > 8. mailto:mod...@li... > 9. http://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABiFSH7L9hQ&s=5&u=http://Slashdot.org! > 10. http://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABncBGbb7gQ&s=5&u=http://sdm.link/slashdot > 11. mailto:mod...@li... > 12. https://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABiNQHeathA&s=5&u=https://lists.sourceforge.net/lists/listinfo/mod-security-de > 13. https://www.trustwave.com/spiderLabs.php > 14. mailto:jai...@mu... > 15. mailto:FC...@tr... > 16. https://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABiNVSbWujw&s=5&u=https://github.com/SpiderLabs/ModSecurity/blob/v3/master/src/transaction.cc > 17. http://www.trustwave.com/ > 18. mailto:jai...@mu... > 19. mailto:mod...@li... > 20. http://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABncBGbb7gQ&s=5&u=http://sdm.link/slashdot > 21. mailto:mod...@li... > 22. https://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABiBWE7Cu0g&s=5&u=https://lists.sourceforge.net/lists/listinfo/mod-security-developers > 23. https://www.trustwave.com/spiderLabs.php > 24. http://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABiFSH7L9hQ&s=5&u=http://Slashdot.org! > 25. http://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABncBGbb7gQ&s=5&u=http://sdm.link/slashdot > 26. mailto:mod...@li... > 27. https://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABiBWE7Cu0g&s=5&u=https://lists.sourceforge.net/lists/listinfo/mod-security-developers > 28. https://www.trustwave.com/spiderLabs.php > 29. https://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABiRSHLb6gw&s=5&u=https://www.feistyduck.com/training/modsecurity-training-course > 30. https://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABiNRG7z8jw&s=5&u=https://www.feistyduck.com/books/modsecurity-handbook/ > 31. mailto:chr...@ne... > 32. http://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABiFSH7L9hQ&s=5&u=http://Slashdot.org! > 33. http://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABncBGbb7gQ&s=5&u=http://sdm.link/slashdot > 34. mailto:mod...@li... > 35. https://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABiBWE7Cu0g&s=5&u=https://lists.sourceforge.net/lists/listinfo/mod-security-developers > 36. 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 -- https://www.feistyduck.com/training/modsecurity-training-course https://www.feistyduck.com/books/modsecurity-handbook/ mailto:chr...@ne... twitter: @ChrFolini |
|
From: Felipe C. <FC...@tr...> - 2018-01-03 12:17:18
|
As of version 3, collections [SESSION and others] can be saved using our own backend. It means that you can use memcache, redis or any other `thing’ capable to store key-pair values. So the data will be persistent in the backend server; Up to the backend server to limit the time and amount of data. 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...> Reply-To: "mod...@li..." <mod...@li...> Date: Tuesday, January 2, 2018 at 3:52 PM To: "mod...@li..." <mod...@li...> Subject: Re: [Mod-security-developers] API Usage and Descriptions? Are the two rules below examples of how historical information can be incorporated into rules? In general, are variables modified and then re-examined by rules to take advantage of historical information? Are there other ways in which historical information can be used within rules? # Increment session score on attack SecRule REQUEST_URI "^/cgi-bin/finger$" "phase:2,id:71,t:none,t:lowercase,t:normalizePath,pass,setvar:SESSION.score=+10" # Detect too many attacks in a session SecRule SESSION:score "@gt 50" "phase:2,id:72,pass,setvar:SESSION.blocked=1" On Tue, Jan 2, 2018 at 12:08 PM, Christian Folini <chr...@ne...<mailto:chr...@ne...>> wrote: On Tue, Jan 02, 2018 at 11:50:00AM -0600, Jai Harpalani wrote: > Does mod security use historical information when it applies rules? > For example, does mod security know and use information about prior > http requests when applying rules to the current one? ModSecurity is only the engine. What you are asking is part of the rule set. There is depends on the rules you are employing. Generally no, but they can be written in a way to use that information. The Core Rule Set - the rule set with the biggest user base - generally does not do this. Best, Christian > > On Thu, Dec 28, 2017 at 1:21 PM, Jai Harpalani > <[1]jai...@mu...<mailto:jai...@mu...>> wrote: > > Felipe, > Thanks for the information. I will most likely have more questions as > I continue working on this. > Thanks, > Jai > > On Fri, Dec 22, 2017 at 8:24 AM, Felipe Costa <[2]FC...@tr...<mailto:FC...@tr...>> > wrote: > > Hi Jai, > > The idea is to have a transaction for each HTTP request. So, > msc_new_transaction() should be called every time that a new connection > is established. In additional to the ModSecurity v2.x phases, > ModSecurity v3 can also process rules for this additional URI phase. > That is after you got the connection details and before you get the > client headers. > > You can find more details about how to implement a connector in the > Transaction code: > > - [3]https://github.com/SpiderLabs/ModSecurity/blob/v3/master/<https://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABihQEuWt1Q&s=5&u=https%3a%2f%2fgithub%2ecom%2fSpiderLabs%2fModSecurity%2fblob%2fv3%2fmaster%2f> > src/transaction.cc > You may also want to generate the doxygen docs: > $ cd doc ; doxygen doxygen.cfg > > Notice that there is no phase on SecRules to hit the uri processing. At > least not yet. We are aiming to support in upcoming versions. > > Br., > > Felipe “Zimmerle” Costa > > Security Researcher, Lead Developer ModSecurity. > > > Trustwave | SMART SECURITY ON DEMAND > > [4]www.trustwave.com<http://www.trustwave.com> > __________________________________________________________________ > > From: Jai Harpalani <[5]jai...@mu...<mailto:jai...@mu...>> > Sent: Wednesday, December 20, 2017 3:52:27 PM > To: [6]mod...@li...<mailto:mod...@li...> > Subject: [Mod-security-developers] API Usage and Descriptions? > > I have an application which already retrieves requests and responses > from "the wire". I'm trying to add modSecurity to check the > requests/responses for WAF errors using: > msc_process_request_headers(); > msc_process_request_body(); > msc_process_response_headers(); > msc_process_response_body(); > I don't want WAF to necessarily take any action, just inform the caller > if any problems were found. If this is possible, how is it done? > Also, not sure what the purpose of the below APIs is for my specific > application. > msc_new_transaction(); > msc_process_connection(t); > msc_process_uri(); > I was not able to locate a description of the above APIs. If detailed > descriptions exist, please let me know where they are located. > Thanks. > > ------------------------------------------------------------ > ------------------ > 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=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABiFSH7L9hQ&s=5&u=http%3a%2f%2fSlashdot%2eorg%21> [7]http://sdm.link/slashdot<http://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABncBGbb7gQ&s=5&u=http%3a%2f%2fsdm%2elink%2fslashdot> > _______________________________________________ > mod-security-developers mailing list > [8]mod...@li...<mailto:mod...@li...> > [9]https://lists.sourceforge.net/lists/listinfo/mod-security-de<https://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABiNQHeathA&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-de> > velopers > ModSecurity Services from Trustwave's SpiderLabs: > [10]https://www.trustwave.com/spiderLabs.php > > References > > 1. mailto:jai...@mu...<mailto:jai...@mu...> > 2. mailto:FC...@tr...<mailto:FC...@tr...> > 3. https://github.com/SpiderLabs/ModSecurity/blob/v3/master/src/transaction.cc<https://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABiNVSbWujw&s=5&u=https%3a%2f%2fgithub%2ecom%2fSpiderLabs%2fModSecurity%2fblob%2fv3%2fmaster%2fsrc%2ftransaction%2ecc> > 4. http://www.trustwave.com/ > 5. mailto:jai...@mu...<mailto:jai...@mu...> > 6. mailto:mod...@li...<mailto:mod...@li...> > 7. http://sdm.link/slashdot<http://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABncBGbb7gQ&s=5&u=http%3a%2f%2fsdm%2elink%2fslashdot> > 8. mailto:mod...@li...<mailto:mod...@li...> > 9. https://lists.sourceforge.net/lists/listinfo/mod-security-developers<https://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABiBWE7Cu0g&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers> > 10. 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://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABiFSH7L9hQ&s=5&u=http%3a%2f%2fSlashdot%2eorg%21> http://sdm.link/slashdot<http://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABncBGbb7gQ&s=5&u=http%3a%2f%2fsdm%2elink%2fslashdot> > _______________________________________________ > mod-security-developers mailing list > mod...@li...<mailto:mod...@li...> > https://lists.sourceforge.net/lists/listinfo/mod-security-developers<https://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABiBWE7Cu0g&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 -- https://www.feistyduck.com/training/modsecurity-training-course<https://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABiRSHLb6gw&s=5&u=https%3a%2f%2fwww%2efeistyduck%2ecom%2ftraining%2fmodsecurity-training-course> https://www.feistyduck.com/books/modsecurity-handbook/<https://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABiNRG7z8jw&s=5&u=https%3a%2f%2fwww%2efeistyduck%2ecom%2fbooks%2fmodsecurity-handbook%2f> mailto:chr...@ne...<mailto:chr...@ne...> twitter: @ChrFolini ------------------------------------------------------------------------------ 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=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABiFSH7L9hQ&s=5&u=http%3a%2f%2fSlashdot%2eorg%21> http://sdm.link/slashdot<http://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABncBGbb7gQ&s=5&u=http%3a%2f%2fsdm%2elink%2fslashdot> _______________________________________________ mod-security-developers mailing list mod...@li...<mailto:mod...@li...> https://lists.sourceforge.net/lists/listinfo/mod-security-developers<https://scanmail.trustwave.com/?c=4062&d=_dTL2pbwruNIrz4_zH9y5TG6LjuiTdmABiBWE7Cu0g&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 |
|
From: Christian F. <chr...@ne...> - 2018-01-03 05:30:15
|
Jai, You'll find subscription info at http://modsecurity.org/help.html Otherwise, just ask over there. Ahoj, Christian On Tue, Jan 02, 2018 at 11:06:05PM -0600, Jai Harpalani wrote: > How do I submit the question to the mailing list? > > On Tue, Jan 2, 2018 at 11:02 PM, Christian Folini > <[1]chr...@ne...> wrote: > > Jai, > Let's use the mailinglist. It's maybe interesting for other people > too. > Ahoj, > Christian > > On Tue, Jan 02, 2018 at 07:07:24PM -0600, Jai Harpalani wrote: > > Christian, > > I have another unrelated question regarding: > > SecRule REQUEST_HEADERS:User-Agent "@pmFromFile > > scanners-user-agents.data" \ > > ... > > Can I ask you via email or should it go to the user's mailing > list? > > > ------------------------------------------------------------ > ------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! [2]http://sdm.link/slashdot > > _______________________________________________ > > mod-security-developers mailing list > > [3]mod...@li... > > [4]https://lists.sourceforge.net/lists/listinfo/mod-security- > developers > > ModSecurity Services from Trustwave's SpiderLabs: > > [5]https://www.trustwave.com/spiderLabs.php > -- > [6]https://www.feistyduck.com/training/modsecurity-training-course > [7]https://www.feistyduck.com/books/modsecurity-handbook/ > mailto:[8]chr...@ne... > twitter: @ChrFolini > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! [9]http://sdm.link/slashdot > _______________________________________________ > mod-security-developers mailing list > [10]mod...@li... > [11]https://lists.sourceforge.net/lists/listinfo/mod-security- > developers > ModSecurity Services from Trustwave's SpiderLabs: > [12]https://www.trustwave.com/spiderLabs.php > > References > > 1. mailto:chr...@ne... > 2. http://sdm.link/slashdot > 3. mailto:mod...@li... > 4. https://lists.sourceforge.net/lists/listinfo/mod-security-developers > 5. https://www.trustwave.com/spiderLabs.php > 6. https://www.feistyduck.com/training/modsecurity-training-course > 7. https://www.feistyduck.com/books/modsecurity-handbook/ > 8. mailto:chr...@ne... > 9. http://sdm.link/slashdot > 10. mailto:mod...@li... > 11. https://lists.sourceforge.net/lists/listinfo/mod-security-developers > 12. 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 -- https://www.feistyduck.com/training/modsecurity-training-course https://www.feistyduck.com/books/modsecurity-handbook/ mailto:chr...@ne... twitter: @ChrFolini |
|
From: Jai H. <jai...@mu...> - 2018-01-03 05:06:13
|
How do I submit the question to the mailing list? On Tue, Jan 2, 2018 at 11:02 PM, Christian Folini < chr...@ne...> wrote: > Jai, > > Let's use the mailinglist. It's maybe interesting for other people too. > > Ahoj, > > Christian > > On Tue, Jan 02, 2018 at 07:07:24PM -0600, Jai Harpalani wrote: > > Christian, > > I have another unrelated question regarding: > > SecRule REQUEST_HEADERS:User-Agent "@pmFromFile > > scanners-user-agents.data" \ > > ... > > Can I ask you via email or should it go to the user's mailing list? > > > ------------------------------------------------------------ > ------------------ > > 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 > > ------------------------------------------------------------ > ------------------ > 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 > |
|
From: Christian F. <chr...@ne...> - 2018-01-03 05:02:10
|
Jai, Let's use the mailinglist. It's maybe interesting for other people too. Ahoj, Christian On Tue, Jan 02, 2018 at 07:07:24PM -0600, Jai Harpalani wrote: > Christian, > I have another unrelated question regarding: > SecRule REQUEST_HEADERS:User-Agent "@pmFromFile > scanners-user-agents.data" \ > ... > Can I ask you via email or should it go to the user's mailing list? > ------------------------------------------------------------------------------ > 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 |
|
From: Jai H. <jai...@mu...> - 2018-01-03 01:07:32
|
Christian, I have another unrelated question regarding: SecRule REQUEST_HEADERS:User-Agent "@pmFromFile scanners-user-agents.data" \ ... Can I ask you via email or should it go to the user's mailing list? |
|
From: Christian F. <chr...@ne...> - 2018-01-02 19:22:44
|
Hey Jai, On Tue, Jan 02, 2018 at 12:52:24PM -0600, Jai Harpalani wrote: > Are the two rules below examples of how historical information can be > incorporated into rules? In general, are variables modified and then > re-examined by rules to take advantage of historical information? Are > there other ways in which historical information can be used within > rules? Yes, that's a standard way to accomplish this. The problem is getting it right for production use. The devil is in the details and there will be a lot of side-effects and edge cases. There are also performance considerations to take care of. Other ways: Lua and a real database springs to mind. If you want to continue this thread, it's probably time to move it over to the user's mailing list. Best, Christian > # Increment session score on attack > SecRule REQUEST_URI "^/cgi-bin/finger$" "phase:2,id:71,t:none,t:lowercase,t:norm > alizePath,pass,setvar:SESSION.score=+10" > > # Detect too many attacks in a session > SecRule SESSION:score "@gt 50" "phase:2,id:72,pass,setvar:SESSION.blocked=1" > > On Tue, Jan 2, 2018 at 12:08 PM, Christian Folini > <[1]chr...@ne...> wrote: > > On Tue, Jan 02, 2018 at 11:50:00AM -0600, Jai Harpalani wrote: > > Does mod security use historical information when it applies > rules? > > For example, does mod security know and use information about > prior > > http requests when applying rules to the current one? > ModSecurity is only the engine. What you are asking is part of the > rule > set. There is depends on the rules you are employing. > Generally no, but they can be written in a way to use that > information. > The Core Rule Set - the rule set with the biggest user base - > generally > does not do this. > Best, > Christian > > > > On Thu, Dec 28, 2017 at 1:21 PM, Jai Harpalani > > <[1][2]jai...@mu...> wrote: > > > > Felipe, > > Thanks for the information. I will most likely have more > questions as > > I continue working on this. > > Thanks, > > Jai > > > > On Fri, Dec 22, 2017 at 8:24 AM, Felipe Costa > <[2][3]FC...@tr...> > > wrote: > > > > Hi Jai, > > > > The idea is to have a transaction for each HTTP request. So, > > msc_new_transaction() should be called every time that a new > connection > > is established. In additional to the ModSecurity v2.x phases, > > ModSecurity v3 can also process rules for this additional URI > phase. > > That is after you got the connection details and before you get > the > > client headers. > > > > You can find more details about how to implement a connector in > the > > Transaction code: > > > > - [3][4]https://github.com/SpiderLabs/ModSecurity/blob/ > v3/master/ > > src/transaction.cc > > You may also want to generate the doxygen docs: > > $ cd doc ; doxygen doxygen.cfg > > > > Notice that there is no phase on SecRules to hit the uri > processing. At > > least not yet. We are aiming to support in upcoming versions. > > > > Br., > > > > Felipe “Zimmerle” Costa > > > > Security Researcher, Lead Developer ModSecurity. > > > > > > Trustwave | SMART SECURITY ON DEMAND > > > > [4][5]www.trustwave.com > > ____________________________________________________________ > ______ > > > > From: Jai Harpalani <[5][6]jai...@mu...> > > Sent: Wednesday, December 20, 2017 3:52:27 PM > > To: [6][7]mod...@li... > > Subject: [Mod-security-developers] API Usage and Descriptions? > > > > I have an application which already retrieves requests and > responses > > from "the wire". I'm trying to add modSecurity to check the > > requests/responses for WAF errors using: > > msc_process_request_headers(); > > msc_process_request_body(); > > msc_process_response_headers(); > > msc_process_response_body(); > > I don't want WAF to necessarily take any action, just inform > the caller > > if any problems were found. If this is possible, how is it > done? > > Also, not sure what the purpose of the below APIs is for my > specific > > application. > > msc_new_transaction(); > > msc_process_connection(t); > > msc_process_uri(); > > I was not able to locate a description of the above APIs. If > detailed > > descriptions exist, please let me know where they are located. > > Thanks. > > > > ------------------------------------------------------------ > > ------------------ > > Check out the vibrant tech community on one of the world's > most > > engaging tech sites, Slashdot.org! > [7][8]http://sdm.link/slashdot > > _______________________________________________ > > mod-security-developers mailing list > > [8][9]mod...@li... > > [9][10]https://lists.sourceforge.net/lists/listinfo/mod- > security-de > > velopers > > ModSecurity Services from Trustwave's SpiderLabs: > > [10][11]https://www.trustwave.com/spiderLabs.php > > > > References > > > > 1. mailto:[12]jai...@mu... > > 2. mailto:[13]FC...@tr... > > 3. [14]https://github.com/SpiderLabs/ > ModSecurity/blob/v3/master/src/transaction.cc > > 4. [15]http://www.trustwave.com/ > > 5. mailto:[16]jai...@mu... > > 6. mailto:[17]mod...@li... > > 7. [18]http://sdm.link/slashdot > > 8. mailto:[19]mod...@li... > > 9. [20]https://lists.sourceforge.net/ > lists/listinfo/mod-security-developers > > 10. [21]https://www.trustwave.com/spiderLabs.php > > ------------------------------------------------------------ > ------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! [22]http://sdm.link/slashdot > > _______________________________________________ > > mod-security-developers mailing list > > [23]mod...@li... > > [24]https://lists.sourceforge.net/lists/listinfo/mod-security- > developers > > ModSecurity Services from Trustwave's SpiderLabs: > > [25]https://www.trustwave.com/spiderLabs.php > -- > [26]https://www.feistyduck.com/training/modsecurity-training-course > [27]https://www.feistyduck.com/books/modsecurity-handbook/ > mailto:[28]chr...@ne... > twitter: @ChrFolini > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! [29]http://sdm.link/slashdot > _______________________________________________ > mod-security-developers mailing list > [30]mod...@li... > [31]https://lists.sourceforge.net/lists/listinfo/mod-security- > developers > ModSecurity Services from Trustwave's SpiderLabs: > [32]https://www.trustwave.com/spiderLabs.php > > References > > 1. mailto:chr...@ne... > 2. mailto:jai...@mu... > 3. mailto:FC...@tr... > 4. https://github.com/SpiderLabs/ModSecurity/blob/v3/master/ > 5. http://www.trustwave.com/ > 6. mailto:jai...@mu... > 7. mailto:mod...@li... > 8. http://sdm.link/slashdot > 9. mailto:mod...@li... > 10. https://lists.sourceforge.net/lists/listinfo/mod-security-de > 11. https://www.trustwave.com/spiderLabs.php > 12. mailto:jai...@mu... > 13. mailto:FC...@tr... > 14. https://github.com/SpiderLabs/ModSecurity/blob/v3/master/src/transaction.cc > 15. http://www.trustwave.com/ > 16. mailto:jai...@mu... > 17. mailto:mod...@li... > 18. http://sdm.link/slashdot > 19. mailto:mod...@li... > 20. https://lists.sourceforge.net/lists/listinfo/mod-security-developers > 21. https://www.trustwave.com/spiderLabs.php > 22. http://sdm.link/slashdot > 23. mailto:mod...@li... > 24. https://lists.sourceforge.net/lists/listinfo/mod-security-developers > 25. https://www.trustwave.com/spiderLabs.php > 26. https://www.feistyduck.com/training/modsecurity-training-course > 27. https://www.feistyduck.com/books/modsecurity-handbook/ > 28. mailto:chr...@ne... > 29. http://sdm.link/slashdot > 30. mailto:mod...@li... > 31. https://lists.sourceforge.net/lists/listinfo/mod-security-developers > 32. 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 -- https://www.feistyduck.com/training/modsecurity-training-course https://www.feistyduck.com/books/modsecurity-handbook/ mailto:chr...@ne... twitter: @ChrFolini |
|
From: Jai H. <jai...@mu...> - 2018-01-02 18:52:32
|
Are the two rules below examples of how historical information can be incorporated into rules? In general, are variables modified and then re-examined by rules to take advantage of historical information? Are there other ways in which historical information can be used within rules? # Increment session score on attack SecRule REQUEST_URI "^/cgi-bin/finger$" "phase:2,id:71,t:none,t:lowercase,t:normalizePath,pass,setvar:SESSION.score=+10" # Detect too many attacks in a session SecRule SESSION:score "@gt 50" "phase:2,id:72,pass,setvar:SESSION.blocked=1" On Tue, Jan 2, 2018 at 12:08 PM, Christian Folini < chr...@ne...> wrote: > On Tue, Jan 02, 2018 at 11:50:00AM -0600, Jai Harpalani wrote: > > Does mod security use historical information when it applies rules? > > For example, does mod security know and use information about prior > > http requests when applying rules to the current one? > > ModSecurity is only the engine. What you are asking is part of the rule > set. There is depends on the rules you are employing. > > Generally no, but they can be written in a way to use that information. > > The Core Rule Set - the rule set with the biggest user base - generally > does not do this. > > Best, > > Christian > > > > > On Thu, Dec 28, 2017 at 1:21 PM, Jai Harpalani > > <[1]jai...@mu...> wrote: > > > > Felipe, > > Thanks for the information. I will most likely have more questions as > > I continue working on this. > > Thanks, > > Jai > > > > On Fri, Dec 22, 2017 at 8:24 AM, Felipe Costa <[2] > FC...@tr...> > > wrote: > > > > Hi Jai, > > > > The idea is to have a transaction for each HTTP request. So, > > msc_new_transaction() should be called every time that a new > connection > > is established. In additional to the ModSecurity v2.x phases, > > ModSecurity v3 can also process rules for this additional URI phase. > > That is after you got the connection details and before you get the > > client headers. > > > > You can find more details about how to implement a connector in the > > Transaction code: > > > > - [3]https://github.com/SpiderLabs/ModSecurity/blob/v3/master/ > > src/transaction.cc > > You may also want to generate the doxygen docs: > > $ cd doc ; doxygen doxygen.cfg > > > > Notice that there is no phase on SecRules to hit the uri processing. > At > > least not yet. We are aiming to support in upcoming versions. > > > > Br., > > > > Felipe “Zimmerle” Costa > > > > Security Researcher, Lead Developer ModSecurity. > > > > > > Trustwave | SMART SECURITY ON DEMAND > > > > [4]www.trustwave.com > > __________________________________________________________________ > > > > From: Jai Harpalani <[5]jai...@mu...> > > Sent: Wednesday, December 20, 2017 3:52:27 PM > > To: [6]mod...@li... > > Subject: [Mod-security-developers] API Usage and Descriptions? > > > > I have an application which already retrieves requests and responses > > from "the wire". I'm trying to add modSecurity to check the > > requests/responses for WAF errors using: > > msc_process_request_headers(); > > msc_process_request_body(); > > msc_process_response_headers(); > > msc_process_response_body(); > > I don't want WAF to necessarily take any action, just inform the > caller > > if any problems were found. If this is possible, how is it done? > > Also, not sure what the purpose of the below APIs is for my specific > > application. > > msc_new_transaction(); > > msc_process_connection(t); > > msc_process_uri(); > > I was not able to locate a description of the above APIs. If detailed > > descriptions exist, please let me know where they are located. > > Thanks. > > > > ------------------------------------------------------------ > > ------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! [7]http://sdm.link/slashdot > > _______________________________________________ > > mod-security-developers mailing list > > [8]mod...@li... > > [9]https://lists.sourceforge.net/lists/listinfo/mod-security-de > > velopers > > ModSecurity Services from Trustwave's SpiderLabs: > > [10]https://www.trustwave.com/spiderLabs.php > > > > References > > > > 1. mailto:jai...@mu... > > 2. mailto:FC...@tr... > > 3. https://github.com/SpiderLabs/ModSecurity/blob/v3/master/ > src/transaction.cc > > 4. http://www.trustwave.com/ > > 5. mailto:jai...@mu... > > 6. mailto:mod...@li... > > 7. http://sdm.link/slashdot > > 8. mailto:mod...@li... > > 9. https://lists.sourceforge.net/lists/listinfo/mod-security- > developers > > 10. 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 > > > -- > https://www.feistyduck.com/training/modsecurity-training-course > https://www.feistyduck.com/books/modsecurity-handbook/ > mailto:chr...@ne... > twitter: @ChrFolini > > ------------------------------------------------------------ > ------------------ > 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 > |
|
From: Christian F. <chr...@ne...> - 2018-01-02 18:08:56
|
On Tue, Jan 02, 2018 at 11:50:00AM -0600, Jai Harpalani wrote: > Does mod security use historical information when it applies rules? > For example, does mod security know and use information about prior > http requests when applying rules to the current one? ModSecurity is only the engine. What you are asking is part of the rule set. There is depends on the rules you are employing. Generally no, but they can be written in a way to use that information. The Core Rule Set - the rule set with the biggest user base - generally does not do this. Best, Christian > > On Thu, Dec 28, 2017 at 1:21 PM, Jai Harpalani > <[1]jai...@mu...> wrote: > > Felipe, > Thanks for the information. I will most likely have more questions as > I continue working on this. > Thanks, > Jai > > On Fri, Dec 22, 2017 at 8:24 AM, Felipe Costa <[2]FC...@tr...> > wrote: > > Hi Jai, > > The idea is to have a transaction for each HTTP request. So, > msc_new_transaction() should be called every time that a new connection > is established. In additional to the ModSecurity v2.x phases, > ModSecurity v3 can also process rules for this additional URI phase. > That is after you got the connection details and before you get the > client headers. > > You can find more details about how to implement a connector in the > Transaction code: > > - [3]https://github.com/SpiderLabs/ModSecurity/blob/v3/master/ > src/transaction.cc > You may also want to generate the doxygen docs: > $ cd doc ; doxygen doxygen.cfg > > Notice that there is no phase on SecRules to hit the uri processing. At > least not yet. We are aiming to support in upcoming versions. > > Br., > > Felipe “Zimmerle” Costa > > Security Researcher, Lead Developer ModSecurity. > > > Trustwave | SMART SECURITY ON DEMAND > > [4]www.trustwave.com > __________________________________________________________________ > > From: Jai Harpalani <[5]jai...@mu...> > Sent: Wednesday, December 20, 2017 3:52:27 PM > To: [6]mod...@li... > Subject: [Mod-security-developers] API Usage and Descriptions? > > I have an application which already retrieves requests and responses > from "the wire". I'm trying to add modSecurity to check the > requests/responses for WAF errors using: > msc_process_request_headers(); > msc_process_request_body(); > msc_process_response_headers(); > msc_process_response_body(); > I don't want WAF to necessarily take any action, just inform the caller > if any problems were found. If this is possible, how is it done? > Also, not sure what the purpose of the below APIs is for my specific > application. > msc_new_transaction(); > msc_process_connection(t); > msc_process_uri(); > I was not able to locate a description of the above APIs. If detailed > descriptions exist, please let me know where they are located. > Thanks. > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! [7]http://sdm.link/slashdot > _______________________________________________ > mod-security-developers mailing list > [8]mod...@li... > [9]https://lists.sourceforge.net/lists/listinfo/mod-security-de > velopers > ModSecurity Services from Trustwave's SpiderLabs: > [10]https://www.trustwave.com/spiderLabs.php > > References > > 1. mailto:jai...@mu... > 2. mailto:FC...@tr... > 3. https://github.com/SpiderLabs/ModSecurity/blob/v3/master/src/transaction.cc > 4. http://www.trustwave.com/ > 5. mailto:jai...@mu... > 6. mailto:mod...@li... > 7. http://sdm.link/slashdot > 8. mailto:mod...@li... > 9. https://lists.sourceforge.net/lists/listinfo/mod-security-developers > 10. 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 -- https://www.feistyduck.com/training/modsecurity-training-course https://www.feistyduck.com/books/modsecurity-handbook/ mailto:chr...@ne... twitter: @ChrFolini |
|
From: Jai H. <jai...@mu...> - 2018-01-02 17:50:08
|
Does mod security use historical information when it applies rules? For example, does mod security know and use information about prior http requests when applying rules to the current one? On Thu, Dec 28, 2017 at 1:21 PM, Jai Harpalani <jai...@mu...> wrote: > Felipe, > > Thanks for the information. I will most likely have more questions as I > continue working on this. > > Thanks, > Jai > > On Fri, Dec 22, 2017 at 8:24 AM, Felipe Costa <FC...@tr...> > wrote: > >> Hi Jai, >> >> >> The idea is to have a transaction for each HTTP request. So, >> msc_new_transaction() should be called every time that a new connection is >> established. In additional to the ModSecurity v2.x phases, ModSecurity v3 >> can also process rules for this additional URI phase. That is after you got >> the connection details and before you get the client headers. >> >> >> You can find more details about how to implement a connector in the >> Transaction code: >> >> - https://github.com/SpiderLabs/ModSecurity/blob/v3/master/ >> src/transaction.cc >> >> You may also want to generate the doxygen docs: >> $ cd doc ; doxygen doxygen.cfg >> >> >> >> Notice that there is no phase on SecRules to hit the uri processing. At >> least not yet. We are aiming to support in upcoming versions. >> >> >> >> Br., >> >> *Felipe **“**Zimmerle” Costa * >> >> Security Researcher, Lead Developer ModSecurity. >> >> >> >> *Trustwave* | SMART SECURITY ON DEMAND >> >> www.trustwave.com >> >> >> ------------------------------ >> *From:* Jai Harpalani <jai...@mu...> >> *Sent:* Wednesday, December 20, 2017 3:52:27 PM >> *To:* mod...@li... >> *Subject:* [Mod-security-developers] API Usage and Descriptions? >> >> >> I have an application which already retrieves requests and responses from >> "the wire". I'm trying to add modSecurity to check the requests/responses >> for WAF errors using: >> >> msc_process_request_headers(); >> msc_process_request_body(); >> msc_process_response_headers(); >> msc_process_response_body(); >> >> I don't want WAF to necessarily take any action, just inform the caller >> if any problems were found. If this is possible, how is it done? >> >> Also, not sure what the purpose of the below APIs is for my specific >> application. >> >> msc_new_transaction(); >> msc_process_connection(t); >> msc_process_uri(); >> >> I was not able to locate a description of the above APIs. If detailed >> descriptions exist, please let me know where they are located. >> >> Thanks. >> >> ------------------------------------------------------------ >> ------------------ >> 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 >> > > |
|
From: Jai H. <jai...@mu...> - 2017-12-28 19:50:22
|
Felipe, Thanks for the information. I will most likely have more questions as I continue working on this. Thanks, Jai On Fri, Dec 22, 2017 at 8:24 AM, Felipe Costa <FC...@tr...> wrote: > Hi Jai, > > > The idea is to have a transaction for each HTTP request. So, > msc_new_transaction() should be called every time that a new connection is > established. In additional to the ModSecurity v2.x phases, ModSecurity v3 > can also process rules for this additional URI phase. That is after you got > the connection details and before you get the client headers. > > > You can find more details about how to implement a connector in the > Transaction code: > > - https://github.com/SpiderLabs/ModSecurity/blob/ > v3/master/src/transaction.cc > > You may also want to generate the doxygen docs: > $ cd doc ; doxygen doxygen.cfg > > > > Notice that there is no phase on SecRules to hit the uri processing. At > least not yet. We are aiming to support in upcoming versions. > > > > Br., > > *Felipe **“**Zimmerle” Costa * > > Security Researcher, Lead Developer ModSecurity. > > > > *Trustwave* | SMART SECURITY ON DEMAND > > www.trustwave.com > > > ------------------------------ > *From:* Jai Harpalani <jai...@mu...> > *Sent:* Wednesday, December 20, 2017 3:52:27 PM > *To:* mod...@li... > *Subject:* [Mod-security-developers] API Usage and Descriptions? > > > I have an application which already retrieves requests and responses from > "the wire". I'm trying to add modSecurity to check the requests/responses > for WAF errors using: > > msc_process_request_headers(); > msc_process_request_body(); > msc_process_response_headers(); > msc_process_response_body(); > > I don't want WAF to necessarily take any action, just inform the caller if > any problems were found. If this is possible, how is it done? > > Also, not sure what the purpose of the below APIs is for my specific > application. > > msc_new_transaction(); > msc_process_connection(t); > msc_process_uri(); > > I was not able to locate a description of the above APIs. If detailed > descriptions exist, please let me know where they are located. > > Thanks. > > ------------------------------------------------------------ > ------------------ > 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 > |
|
From: Felipe C. <FC...@tr...> - 2017-12-22 17:12:51
|
No open issues on that matter. Did you notice something unexpected? Br., Felipe “Zimmerle” Costa Security Researcher, Lead Developer ModSecurity. Trustwave | SMART SECURITY ON DEMAND www.trustwave.com<http://www.trustwave.com/> ________________________________ From: Frédéric Gicquel <sup...@gm...> Sent: Friday, December 22, 2017 2:38:40 PM To: mod...@li... Subject: Re: [Mod-security-developers] [v3/master] shift in the numbering of the phases ? Hi Felipe, Thank for your quick reply. Is there really no incidence on the logic of treatment of the rules ? Br. On Fri, Dec 22, 2017 at 3:30 PM, Felipe Costa <FC...@tr...<mailto:FC...@tr...>> wrote: Hi Fred, Indeed the enumerator has a number associated to each item, however this number is not the same number that we have on the SecRule. From the user perspective there is no change. The additional phases will be supported by SecRule language in further versions. Notice that there is no UriPhase on src/actions/phase.cc. Br., Felipe “Zimmerle” Costa Security Researcher, Lead Developer ModSecurity. Trustwave | SMART SECURITY ON DEMAND www.trustwave.com<http://www.trustwave.com/> ________________________________ From: Frédéric Gicquel <sup...@gm...<mailto:sup...@gm...>> Sent: Friday, December 22, 2017 10:46:19 AM To: mod...@li...<mailto:mod...@li...> Subject: [Mod-security-developers] [v3/master] shift in the numbering of the phases ? Hello, Adding the **UriPhase** phase into the enum Phases (see headers/modsecurity/modsecurity.h) seems to have introduced a shift in the numbering of the historical phases : RequestHeadersPhase is numbered 2 (instead of 1) and so on (see src/actions/phase.cc). This has been tested with ModSecurity-3.0 (branch v3/master) in library mode and ModSecurity connector for nginx (branch master). Extract of headers/modsecurity/modsecurity.h file ``` #ifdef __cplusplus #include <ctime> #include <iostream> #include <string> #include <memory> #endif #ifndef HEADERS_MODSECURITY_MODSECURITY_H_ #define HEADERS_MODSECURITY_MODSECURITY_H_ #ifndef __cplusplus typedef struct ModSecurity_t modsecurity; #else namespace modsecurity { /** * * The Phases enumerator consists in mapping the different stages of a * given request. ModSecurity is expected to inspect data based on those * "phases". If your module/application use this in a different order, it * will lead ModSecurity to act in an unexpected behavior. * * It is mandatory to call all the phases, even if you don't have this * phases segmented in your end. * */ enum Phases { /** * * The connection is the very first information that ModSecurity can * inspect. It is expected to happens before the virtual host name be * resolved. This phase is expected to happen immediately after a * connection is established. * */ ConnectionPhase, /** * * The "URI" phase happens just after the web server (or any other * application that you may use with ModSecurity) have the acknowledgement * of the full request URI. * */ UriPhase, /** * * The "RequestHeaders" phase happens when the server has all the * information about the headers. Notice however, that it is expected to * happen prior to the reception of the request body (if any). * */ RequestHeadersPhase, [...] ``` Extract of src/actions/phase.cc file ``` #include "src/actions/phase.h" #include <iostream> #include <string> #include "modsecurity/transaction.h" #include "modsecurity/rule.h" #include "modsecurity/modsecurity.h" #include "src/utils/string.h" namespace modsecurity { namespace actions { bool Phase::init(std::string *error) { std::string a = utils::string::tolower(m_parser_payload); m_phase = -1; try { m_phase = std::stoi(m_parser_payload); if (m_phase == 0) { m_phase = modsecurity::Phases::ConnectionPhase; m_secRulesPhase = 0; } else if (m_phase == 1) { m_phase = modsecurity::Phases::RequestHeadersPhase; m_secRulesPhase = 1; } else if (m_phase == 2) { m_phase = modsecurity::Phases::RequestBodyPhase; m_secRulesPhase = 2; } else if (m_phase == 3) { m_phase = modsecurity::Phases::ResponseHeadersPhase; m_secRulesPhase = 3; } else if (m_phase == 4) { m_phase = modsecurity::Phases::ResponseBodyPhase; m_secRulesPhase = 4; } else if (m_phase == 5) { m_phase = modsecurity::Phases::LoggingPhase; m_secRulesPhase = 5; } } catch (...) { if (a == "request") { m_phase = modsecurity::Phases::RequestBodyPhase; m_secRulesPhase = 2; } else if (a == "response") { m_phase = modsecurity::Phases::ResponseBodyPhase; m_secRulesPhase = 4; } else if (a == "logging") { m_phase = modsecurity::Phases::LoggingPhase; m_secRulesPhase = 5; } } ``` Br. -- Fred sup...@gm...<mailto:sup...@gm...> ------------------------------------------------------------------------------ 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=nbW92ozP8p0s_gOxCAWgaJeMMeySmeUgZd0GrrqrQQ&s=5&u=http%3a%2f%2fSlashdot%2eorg%21> http://sdm.link/slashdot<http://scanmail.trustwave.com/?c=4062&d=nbW92ozP8p0s_gOxCAWgaJeMMeySmeUgZYtVqL6tRQ&s=5&u=http%3a%2f%2fsdm%2elink%2fslashdot> _______________________________________________ mod-security-developers mailing list mod...@li...<mailto:mod...@li...> https://lists.sourceforge.net/lists/listinfo/mod-security-developers<https://scanmail.trustwave.com/?c=4062&d=nbW92ozP8p0s_gOxCAWgaJeMMeySmeUgZdwCorj4Fg&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 -- Support Développement sup...@gm...<mailto:sup...@gm...> |
|
From: Frédéric G. <sup...@gm...> - 2017-12-22 16:38:48
|
Hi Felipe, Thank for your quick reply. Is there really no incidence on the logic of treatment of the rules ? Br. On Fri, Dec 22, 2017 at 3:30 PM, Felipe Costa <FC...@tr...> wrote: > Hi Fred, > > > Indeed the enumerator has a number associated to each item, however this > number is not the same number that we have on the SecRule. From the user > perspective there is no change. > > > The additional phases will be supported by SecRule language in further > versions. Notice that there is no UriPhase on src/actions/phase.cc. > > > > Br., > > *Felipe **“**Zimmerle” Costa * > > Security Researcher, Lead Developer ModSecurity. > > > > *Trustwave* | SMART SECURITY ON DEMAND > > www.trustwave.com > > > ------------------------------ > *From:* Frédéric Gicquel <sup...@gm...> > *Sent:* Friday, December 22, 2017 10:46:19 AM > *To:* mod...@li... > *Subject:* [Mod-security-developers] [v3/master] shift in the numbering > of the phases ? > > Hello, > > Adding the **UriPhase** phase into the enum Phases (see > headers/modsecurity/modsecurity.h) seems to have introduced a shift in > the numbering of the historical phases : RequestHeadersPhase is numbered 2 > (instead of 1) and so on (see src/actions/phase.cc). > > This has been tested with ModSecurity-3.0 (branch v3/master) in library > mode and ModSecurity connector for nginx (branch master). > > > Extract of headers/modsecurity/modsecurity.h file > > ``` > #ifdef __cplusplus > #include <ctime> > #include <iostream> > #include <string> > #include <memory> > #endif > > > #ifndef HEADERS_MODSECURITY_MODSECURITY_H_ > #define HEADERS_MODSECURITY_MODSECURITY_H_ > > > #ifndef __cplusplus > typedef struct ModSecurity_t modsecurity; > #else > namespace modsecurity { > /** > * > * The Phases enumerator consists in mapping the different stages of a > * given request. ModSecurity is expected to inspect data based on > those > * "phases". If your module/application use this in a different order, > it > * will lead ModSecurity to act in an unexpected behavior. > * > * It is mandatory to call all the phases, even if you don't have this > * phases segmented in your end. > * > */ > enum Phases { > /** > * > * The connection is the very first information that ModSecurity can > * inspect. It is expected to happens before the virtual host name be > * resolved. This phase is expected to happen immediately after a > * connection is established. > * > */ > ConnectionPhase, > /** > * > * The "URI" phase happens just after the web server (or any other > * application that you may use with ModSecurity) have the > acknowledgement > * of the full request URI. > * > */ > UriPhase, > /** > * > * The "RequestHeaders" phase happens when the server has all the > * information about the headers. Notice however, that it is expected > to > * happen prior to the reception of the request body (if any). > * > */ > RequestHeadersPhase, > [...] > ``` > > > > Extract of src/actions/phase.cc file > > ``` > #include "src/actions/phase.h" > > #include <iostream> > #include <string> > > #include "modsecurity/transaction.h" > #include "modsecurity/rule.h" > #include "modsecurity/modsecurity.h" > #include "src/utils/string.h" > > > namespace modsecurity { > namespace actions { > > bool Phase::init(std::string *error) { > std::string a = utils::string::tolower(m_parser_payload); > m_phase = -1; > > try { > m_phase = std::stoi(m_parser_payload); > if (m_phase == 0) { > m_phase = modsecurity::Phases::ConnectionPhase; > m_secRulesPhase = 0; > } else if (m_phase == 1) { > m_phase = modsecurity::Phases::RequestHeadersPhase; > m_secRulesPhase = 1; > } else if (m_phase == 2) { > m_phase = modsecurity::Phases::RequestBodyPhase; > m_secRulesPhase = 2; > } else if (m_phase == 3) { > m_phase = modsecurity::Phases::ResponseHeadersPhase; > m_secRulesPhase = 3; > } else if (m_phase == 4) { > m_phase = modsecurity::Phases::ResponseBodyPhase; > m_secRulesPhase = 4; > } else if (m_phase == 5) { > m_phase = modsecurity::Phases::LoggingPhase; > m_secRulesPhase = 5; > } > } catch (...) { > if (a == "request") { > m_phase = modsecurity::Phases::RequestBodyPhase; > m_secRulesPhase = 2; > } else if (a == "response") { > m_phase = modsecurity::Phases::ResponseBodyPhase; > m_secRulesPhase = 4; > } else if (a == "logging") { > m_phase = modsecurity::Phases::LoggingPhase; > m_secRulesPhase = 5; > } > } > ``` > > Br. > > -- > Fred > sup...@gm... > > ------------------------------------------------------------ > ------------------ > 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 > -- Support Développement sup...@gm... |
|
From: Felipe C. <FC...@tr...> - 2017-12-22 14:30:29
|
Hi Fred, Indeed the enumerator has a number associated to each item, however this number is not the same number that we have on the SecRule. From the user perspective there is no change. The additional phases will be supported by SecRule language in further versions. Notice that there is no UriPhase on src/actions/phase.cc. Br., Felipe “Zimmerle” Costa Security Researcher, Lead Developer ModSecurity. Trustwave | SMART SECURITY ON DEMAND www.trustwave.com<http://www.trustwave.com/> ________________________________ From: Frédéric Gicquel <sup...@gm...> Sent: Friday, December 22, 2017 10:46:19 AM To: mod...@li... Subject: [Mod-security-developers] [v3/master] shift in the numbering of the phases ? Hello, Adding the **UriPhase** phase into the enum Phases (see headers/modsecurity/modsecurity.h) seems to have introduced a shift in the numbering of the historical phases : RequestHeadersPhase is numbered 2 (instead of 1) and so on (see src/actions/phase.cc). This has been tested with ModSecurity-3.0 (branch v3/master) in library mode and ModSecurity connector for nginx (branch master). Extract of headers/modsecurity/modsecurity.h file ``` #ifdef __cplusplus #include <ctime> #include <iostream> #include <string> #include <memory> #endif #ifndef HEADERS_MODSECURITY_MODSECURITY_H_ #define HEADERS_MODSECURITY_MODSECURITY_H_ #ifndef __cplusplus typedef struct ModSecurity_t modsecurity; #else namespace modsecurity { /** * * The Phases enumerator consists in mapping the different stages of a * given request. ModSecurity is expected to inspect data based on those * "phases". If your module/application use this in a different order, it * will lead ModSecurity to act in an unexpected behavior. * * It is mandatory to call all the phases, even if you don't have this * phases segmented in your end. * */ enum Phases { /** * * The connection is the very first information that ModSecurity can * inspect. It is expected to happens before the virtual host name be * resolved. This phase is expected to happen immediately after a * connection is established. * */ ConnectionPhase, /** * * The "URI" phase happens just after the web server (or any other * application that you may use with ModSecurity) have the acknowledgement * of the full request URI. * */ UriPhase, /** * * The "RequestHeaders" phase happens when the server has all the * information about the headers. Notice however, that it is expected to * happen prior to the reception of the request body (if any). * */ RequestHeadersPhase, [...] ``` Extract of src/actions/phase.cc file ``` #include "src/actions/phase.h" #include <iostream> #include <string> #include "modsecurity/transaction.h" #include "modsecurity/rule.h" #include "modsecurity/modsecurity.h" #include "src/utils/string.h" namespace modsecurity { namespace actions { bool Phase::init(std::string *error) { std::string a = utils::string::tolower(m_parser_payload); m_phase = -1; try { m_phase = std::stoi(m_parser_payload); if (m_phase == 0) { m_phase = modsecurity::Phases::ConnectionPhase; m_secRulesPhase = 0; } else if (m_phase == 1) { m_phase = modsecurity::Phases::RequestHeadersPhase; m_secRulesPhase = 1; } else if (m_phase == 2) { m_phase = modsecurity::Phases::RequestBodyPhase; m_secRulesPhase = 2; } else if (m_phase == 3) { m_phase = modsecurity::Phases::ResponseHeadersPhase; m_secRulesPhase = 3; } else if (m_phase == 4) { m_phase = modsecurity::Phases::ResponseBodyPhase; m_secRulesPhase = 4; } else if (m_phase == 5) { m_phase = modsecurity::Phases::LoggingPhase; m_secRulesPhase = 5; } } catch (...) { if (a == "request") { m_phase = modsecurity::Phases::RequestBodyPhase; m_secRulesPhase = 2; } else if (a == "response") { m_phase = modsecurity::Phases::ResponseBodyPhase; m_secRulesPhase = 4; } else if (a == "logging") { m_phase = modsecurity::Phases::LoggingPhase; m_secRulesPhase = 5; } } ``` Br. -- Fred sup...@gm...<mailto:sup...@gm...> |
|
From: Felipe C. <FC...@tr...> - 2017-12-22 14:24:53
|
Hi Jai, The idea is to have a transaction for each HTTP request. So, msc_new_transaction() should be called every time that a new connection is established. In additional to the ModSecurity v2.x phases, ModSecurity v3 can also process rules for this additional URI phase. That is after you got the connection details and before you get the client headers. You can find more details about how to implement a connector in the Transaction code: - https://github.com/SpiderLabs/ModSecurity/blob/v3/master/src/transaction.cc You may also want to generate the doxygen docs: $ cd doc ; doxygen doxygen.cfg Notice that there is no phase on SecRules to hit the uri processing. At least not yet. We are aiming to support in upcoming versions. 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...> Sent: Wednesday, December 20, 2017 3:52:27 PM To: mod...@li... Subject: [Mod-security-developers] API Usage and Descriptions? I have an application which already retrieves requests and responses from "the wire". I'm trying to add modSecurity to check the requests/responses for WAF errors using: msc_process_request_headers(); msc_process_request_body(); msc_process_response_headers(); msc_process_response_body(); I don't want WAF to necessarily take any action, just inform the caller if any problems were found. If this is possible, how is it done? Also, not sure what the purpose of the below APIs is for my specific application. msc_new_transaction(); msc_process_connection(t); msc_process_uri(); I was not able to locate a description of the above APIs. If detailed descriptions exist, please let me know where they are located. Thanks. |
10 messages has been excluded from this view by a project administrator.
