mod-security-users Mailing List for ModSecurity (Page 453)
Brought to you by:
victorhora,
zimmerletw
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(17) |
Aug
(7) |
Sep
(8) |
Oct
(11) |
Nov
(14) |
Dec
(19) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(46) |
Feb
(14) |
Mar
(20) |
Apr
(48) |
May
(15) |
Jun
(20) |
Jul
(36) |
Aug
(24) |
Sep
(31) |
Oct
(28) |
Nov
(23) |
Dec
(12) |
2005 |
Jan
(69) |
Feb
(61) |
Mar
(82) |
Apr
(53) |
May
(26) |
Jun
(71) |
Jul
(27) |
Aug
(52) |
Sep
(28) |
Oct
(49) |
Nov
(104) |
Dec
(74) |
2006 |
Jan
(61) |
Feb
(148) |
Mar
(82) |
Apr
(139) |
May
(65) |
Jun
(116) |
Jul
(92) |
Aug
(101) |
Sep
(84) |
Oct
(103) |
Nov
(174) |
Dec
(102) |
2007 |
Jan
(166) |
Feb
(161) |
Mar
(181) |
Apr
(152) |
May
(192) |
Jun
(250) |
Jul
(127) |
Aug
(165) |
Sep
(97) |
Oct
(135) |
Nov
(206) |
Dec
(56) |
2008 |
Jan
(160) |
Feb
(135) |
Mar
(98) |
Apr
(89) |
May
(115) |
Jun
(95) |
Jul
(188) |
Aug
(167) |
Sep
(153) |
Oct
(84) |
Nov
(82) |
Dec
(85) |
2009 |
Jan
(139) |
Feb
(133) |
Mar
(128) |
Apr
(105) |
May
(135) |
Jun
(79) |
Jul
(92) |
Aug
(134) |
Sep
(73) |
Oct
(112) |
Nov
(159) |
Dec
(80) |
2010 |
Jan
(100) |
Feb
(116) |
Mar
(130) |
Apr
(59) |
May
(88) |
Jun
(59) |
Jul
(69) |
Aug
(67) |
Sep
(82) |
Oct
(76) |
Nov
(59) |
Dec
(34) |
2011 |
Jan
(84) |
Feb
(74) |
Mar
(81) |
Apr
(94) |
May
(188) |
Jun
(72) |
Jul
(118) |
Aug
(109) |
Sep
(111) |
Oct
(80) |
Nov
(51) |
Dec
(44) |
2012 |
Jan
(80) |
Feb
(123) |
Mar
(46) |
Apr
(12) |
May
(40) |
Jun
(62) |
Jul
(95) |
Aug
(66) |
Sep
(65) |
Oct
(53) |
Nov
(42) |
Dec
(60) |
2013 |
Jan
(96) |
Feb
(96) |
Mar
(108) |
Apr
(72) |
May
(115) |
Jun
(111) |
Jul
(114) |
Aug
(87) |
Sep
(93) |
Oct
(97) |
Nov
(104) |
Dec
(82) |
2014 |
Jan
(96) |
Feb
(77) |
Mar
(71) |
Apr
(40) |
May
(48) |
Jun
(78) |
Jul
(54) |
Aug
(44) |
Sep
(58) |
Oct
(79) |
Nov
(51) |
Dec
(52) |
2015 |
Jan
(55) |
Feb
(59) |
Mar
(48) |
Apr
(40) |
May
(45) |
Jun
(63) |
Jul
(36) |
Aug
(49) |
Sep
(35) |
Oct
(58) |
Nov
(21) |
Dec
(47) |
2016 |
Jan
(35) |
Feb
(81) |
Mar
(43) |
Apr
(41) |
May
(77) |
Jun
(52) |
Jul
(39) |
Aug
(34) |
Sep
(107) |
Oct
(67) |
Nov
(54) |
Dec
(20) |
2017 |
Jan
(99) |
Feb
(37) |
Mar
(86) |
Apr
(47) |
May
(57) |
Jun
(55) |
Jul
(34) |
Aug
(31) |
Sep
(16) |
Oct
(49) |
Nov
(53) |
Dec
(33) |
2018 |
Jan
(25) |
Feb
(11) |
Mar
(79) |
Apr
(77) |
May
(5) |
Jun
(19) |
Jul
(17) |
Aug
(7) |
Sep
(13) |
Oct
(22) |
Nov
(13) |
Dec
(68) |
2019 |
Jan
(44) |
Feb
(17) |
Mar
(40) |
Apr
(39) |
May
(18) |
Jun
(14) |
Jul
(20) |
Aug
(31) |
Sep
(11) |
Oct
(35) |
Nov
(3) |
Dec
(10) |
2020 |
Jan
(32) |
Feb
(16) |
Mar
(10) |
Apr
(22) |
May
(2) |
Jun
(34) |
Jul
(1) |
Aug
(8) |
Sep
(36) |
Oct
(16) |
Nov
(13) |
Dec
(10) |
2021 |
Jan
(16) |
Feb
(23) |
Mar
(45) |
Apr
(28) |
May
(6) |
Jun
(17) |
Jul
(8) |
Aug
(1) |
Sep
(2) |
Oct
(35) |
Nov
|
Dec
(5) |
2022 |
Jan
|
Feb
(17) |
Mar
(23) |
Apr
(23) |
May
(9) |
Jun
(8) |
Jul
|
Aug
|
Sep
(7) |
Oct
(5) |
Nov
(16) |
Dec
(4) |
2023 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
(1) |
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
2024 |
Jan
(7) |
Feb
(13) |
Mar
(18) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: [NICK] <li...@gm...> - 2007-06-21 16:27:04
|
final question, sorry, how do I solve? --1953a257-H-- Message: Warning. Operator EQ match: 0. [id "960903"] [msg "ModSecurity does not support content encodings"] [severity "WARNING"] Stopwatch: 1182443089293507 57659 (3179 56429 -) Producer: ModSecurity v2.1.0 (Apache 2.x) Server: Apache --1953a257-Z-- would commenting out 960903 suffice? On 21/06/07, [NICK] <li...@gm...> wrote: > sorry that was a stuipd question, was missing... > > SecDataDir /tmp > SecTmpDir /tmp > > rdgs, > Nick > > On 21/06/07, [NICK] <li...@gm...> wrote: > > thanks Ryan, you are right, I installed modsecurity via a rpm, and > > removed CRS_10 as it clashed with with modsecurity.conf that came in > > the RPM... I added the line as you suggested, now I get... > > > > --ca8fff38-H-- > > Message: Unable to retrieve collection (name "resource", key > > "/forum/viewtopic.php"). Use SecDataDir to define data directory > > first. > > Message: Warning. Operator EQ match: 0. [id "960903"] [msg > > "ModSecurity does not support content encodings"] [severity "WARNING"] > > Apache-Handler: x-httpd-php > > Stopwatch: 1182435027973986 211986 (4187 43153 -) > > Producer: ModSecurity v2.1.0 (Apache 2.x) > > Server: Apache > > > > --ca8fff38-Z-- > > > > > > > > is there something else that I could be missing? > > > > thanks again, > > Nick > > > > On 21/06/07, Ryan Barnett <Rya...@br...> wrote: > > > > > > > > > > > > Nick, > > > > > > From the CHANGES file - > > > > > > > > > > > > ModSecurity does not support compressed content at the moment. Thus, > the > > > following rules have been added: > > > > > > - 960902 - Content-Encoding in request not supported > > > > > > Any incoming compressed request will be denied > > > > > > - 960903 - Content-Encoding in response not suppoted > > > > > > An outgoing compressed response will be logged to alert, but ONLY > ONCE. > > > > > > > > > > > > The error message you are receiving is most likely related to this ru= le > NOT > > > being in your modsecurity_crs_10_config.conf file =96 > > > > > > > > > > > > # Loades the variable collection relating to the requested resource > > > > > > # NOTE: We will not initiate a collection if there was an error (To > prevent > > > overloading) > > > > > > SecRule RESPONSE_STATUS "!^(?:30[12]|[45]\d\d)$" > > > "phase:3,pass,nolog,initcol:resource=3D%{REQUEST_FILENAME}" > > > > > > > > > > > > This rule initiates the RESOURCE collection for use by later rules. = As > your > > > error message indicates, rule 960903 is triggering and attempting to > use > > > setvar to add a compressed content tag to the RESOURCE collection, > however > > > the collection is not there. > > > > > > > > > > > > I would recommend that you check your modsecurity_crs_10_config.conf > file to > > > ensure that this rule is present. > > > > > > > > > > > > > > > > > > -- > > > Ryan C. Barnett > > > ModSecurity Community Manager > > > > > > Breach Security: Director of Application Security Training > > > Web Application Security Consortium (WASC) Member > > > CIS Apache Benchmark Project Lead > > > SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC > > > > > > Author: Preventing Web Attacks with Apache > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > From: mod...@li... > > > [mailto:mod...@li...] > > > On Behalf Of Frank Misa > > > Sent: Thursday, June 21, 2007 9:58 AM > > > To: [NICK]; mod...@li... > > > Subject: Re: [mod-security-users] id "960903" > > > > > > > > > > > > > > > Hi Nick, > > > > > > I'm very new to MOD_SECURITY myself. > > > It's like a full blown - virtual firewall - with language of it's own= ; > > > learning to customize the rules etc. and administrate the thing can b= e > a > > > full time job I think ;) > > > > > > What I've learned so far: > > > >> Re: resource.alerted_960903_compression > > > 1) You can search your modSecurity_Core_Rules directory for the *.con= f > file > > > that contains this rule - search for "960903" > > > 2) You'll find that file: > > > modsecurity_crs_30_http_policy.conf contains this rule.... > > > I've pasted it below - they are well documented and explain > themselves... > > > >># Restricted Content Encodings > > > >># > > > >># ModSecurity does not support compressed content. Therefore, > the > > > following > > > >># action will be taken: > > > >># - Inbound compressed content will be denied > > > >># - Outbound compressed content will be logged once, to ale= rt > the > > > user > > > >># Deny inbound compressed content > > > >>SecRule REQUEST_HEADERS:Content-Encoding > > > "!^Identity$" \ > > > >> > > > "phase:2,t:none,deny,log,auditlog,status:501,msg:'ModSecurity > > > does not support content > > > encodings',,id:'960902',severity:'3'" > > > >># Log outbound compressed content (once per location) > > > >>SecRule RESPONSE_HEADERS:Content-Encoding > > > "!^Identity$" \ > > > >> > > > "phase:5,t:none,pass,log,auditlog,msg:'ModSecurity does not > > > support content encodings',,id:'960903',severity:'4',chain" > > > >>SecRule &RESOURCE:alerted_960903_compression "@eq > > > 0" "setvar:resource.alerted_960903_compression" > > > > > > 3) Every site/installation will be different -- you have to decide if > you > > > want to ALLOW/ IGNORE / CUSTOMIZE this rule for your particular > situation. > > > If the rule makes sense for you -- you leave it in. > > > If the Rule does not make sense for you -- then you can ignore the ru= le > by > > > adding you own custom rules file (with appropriate naming convention > which > > > controls when your rules are executed) and state you want the rule to > be > > > ignored. > > > In your case -- you might do something like this: > > > a) create a file called: > > > modsecurity_crs_60_customrules.conf > > > b) in this file insert the line: SecRuleRemoveById 960903 > > > > > > You get the idea.... > > > > > > > > > ---------------------------- > > > In general I think the idea is to initially run the "core rules" in a > "LOG > > > ONLY" mode.... > > > A) See file: modsecurity_crs_10_config.confv > > > line: SecDefaultAction "phase:2,log,pass,status:500" > > > B) Examine the logs and decide what/if any traffic is "false > positive"..... > > > Decide if you want to modify the rules -- or ignore the rules > leading to > > > false positives. > > > * Note -- it's best to do this in your own custom *.conf files -- > that > > > way the core rules are not overwritten with new updates etc. > > > C) When you're confident your rule set is not actually blocking legal > > > traffic -- then switch to a DENY mode... > > > See file: modsecurity_crs_10_config.confv > > > * change line: SecDefaultAction "phase:2,log,deny,status:500" > > > > > > I'm still trying to figure out for myself: > > > 1) What the "blocking" set of core_rule files do... > > > 2) How the hell do you analyze all these logs produced ?? > > > ModSecurity's "Grep" like tool seems very tedious ? > > > ModSecurityConsole is have hard for me to install on Windows ?? > > > > > > See my threads -- if you have any ideas let me know.... > > > > > > Cheers > > > Frank > > > > > > > > > ________________________________ > > > > > > > > > > Date: Thu, 21 Jun 2007 14:35:08 +0100 > > > > From: li...@gm... > > > > To: mod...@li... > > > > Subject: [mod-security-users] id "960903" > > > > > > > > Hi, > > > > > > > > Sorry for the n00b questions, but I can't seem to find the answer, = my > > > > log files are being filled up with... > > > > > > > > --55f54137-H-- > > > > Message: Could not set variable > > > "resource.alerted_960903_compression" > > > > as the collection does not exist. > > > > Message: Warning. Operator EQ match: 0. [id "960903"] [msg > > > > "ModSecurity does not support content encodings"] [severity > "WARNING"] > > > > Apache-Handler: x-httpd-php > > > > Stopwatch: 1182431976356708 253670 (3393 55460 -) > > > > Producer: ModSecurity v2.1.0 (Apache 2.x) > > > > Server: Apache > > > > > > > > --55f54137-Z-- > > > > > > > > Please could you offer some advise on how to stop this? > > > > > > > > Cheers, > > > > Nick > > > > > > > > -- > > > > Shameless plug for google Juice: http://www.linickx.com > > > > > > > > > > > > ------------------------------------------------------------------------- > > > > This SF.net email is sponsored by DB2 Express > > > > Download DB2 Express C - the FREE version of DB2 express and take > > > > control of your XML. No limits. Just data. Click to get it now. > > > > http://sourceforge.net/powerbar/db2/ > > > > _______________________________________________ > > > > mod-security-users mailing list > > > > mod...@li... > > > > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > ________________________________ > > > > > > > > > Get news, entertainment and everything you care about at Live.com. Ch= eck > it > > > out! > > > > > > -- > > Shameless plug for google Juice: http://www.linickx.com > > > > > -- > Shameless plug for google Juice: http://www.linickx.com > --=20 Shameless plug for google Juice: http://www.linickx.com |
From: [NICK] <li...@gm...> - 2007-06-21 14:16:30
|
sorry that was a stuipd question, was missing... SecDataDir /tmp SecTmpDir /tmp rdgs, Nick On 21/06/07, [NICK] <li...@gm...> wrote: > thanks Ryan, you are right, I installed modsecurity via a rpm, and > removed CRS_10 as it clashed with with modsecurity.conf that came in > the RPM... I added the line as you suggested, now I get... > > --ca8fff38-H-- > Message: Unable to retrieve collection (name "resource", key > "/forum/viewtopic.php"). Use SecDataDir to define data directory > first. > Message: Warning. Operator EQ match: 0. [id "960903"] [msg > "ModSecurity does not support content encodings"] [severity "WARNING"] > Apache-Handler: x-httpd-php > Stopwatch: 1182435027973986 211986 (4187 43153 -) > Producer: ModSecurity v2.1.0 (Apache 2.x) > Server: Apache > > --ca8fff38-Z-- > > > > is there something else that I could be missing? > > thanks again, > Nick > > On 21/06/07, Ryan Barnett <Rya...@br...> wrote: > > > > > > > > Nick, > > > > From the CHANGES file - > > > > > > > > ModSecurity does not support compressed content at the moment. Thus, th= e > > following rules have been added: > > > > - 960902 - Content-Encoding in request not supported > > > > Any incoming compressed request will be denied > > > > - 960903 - Content-Encoding in response not suppoted > > > > An outgoing compressed response will be logged to alert, but ONLY O= NCE. > > > > > > > > The error message you are receiving is most likely related to this rule= NOT > > being in your modsecurity_crs_10_config.conf file =96 > > > > > > > > # Loades the variable collection relating to the requested resource > > > > # NOTE: We will not initiate a collection if there was an error (To pre= vent > > overloading) > > > > SecRule RESPONSE_STATUS "!^(?:30[12]|[45]\d\d)$" > > "phase:3,pass,nolog,initcol:resource=3D%{REQUEST_FILENAME}" > > > > > > > > This rule initiates the RESOURCE collection for use by later rules. As= your > > error message indicates, rule 960903 is triggering and attempting to us= e > > setvar to add a compressed content tag to the RESOURCE collection, howe= ver > > the collection is not there. > > > > > > > > I would recommend that you check your modsecurity_crs_10_config.conf fi= le to > > ensure that this rule is present. > > > > > > > > > > > > -- > > Ryan C. Barnett > > ModSecurity Community Manager > > > > Breach Security: Director of Application Security Training > > Web Application Security Consortium (WASC) Member > > CIS Apache Benchmark Project Lead > > SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC > > > > Author: Preventing Web Attacks with Apache > > > > > > > > > > > > ________________________________ > > > > > > From: mod...@li... > > [mailto:mod...@li...] > > On Behalf Of Frank Misa > > Sent: Thursday, June 21, 2007 9:58 AM > > To: [NICK]; mod...@li... > > Subject: Re: [mod-security-users] id "960903" > > > > > > > > > > Hi Nick, > > > > I'm very new to MOD_SECURITY myself. > > It's like a full blown - virtual firewall - with language of it's own; > > learning to customize the rules etc. and administrate the thing can be = a > > full time job I think ;) > > > > What I've learned so far: > > >> Re: resource.alerted_960903_compression > > 1) You can search your modSecurity_Core_Rules directory for the *.conf = file > > that contains this rule - search for "960903" > > 2) You'll find that file: > > modsecurity_crs_30_http_policy.conf contains this rule.... > > I've pasted it below - they are well documented and explain themselves.= .. > > >># Restricted Content Encodings > > >># > > >># ModSecurity does not support compressed content. Therefore, t= he > > following > > >># action will be taken: > > >># - Inbound compressed content will be denied > > >># - Outbound compressed content will be logged once, to alert= the > > user > > >># Deny inbound compressed content > > >>SecRule REQUEST_HEADERS:Content-Encoding > > "!^Identity$" \ > > >> > > "phase:2,t:none,deny,log,auditlog,status:501,msg:'ModSecurity > > does not support content > > encodings',,id:'960902',severity:'3'" > > >># Log outbound compressed content (once per location) > > >>SecRule RESPONSE_HEADERS:Content-Encoding > > "!^Identity$" \ > > >> > > "phase:5,t:none,pass,log,auditlog,msg:'ModSecurity does not > > support content encodings',,id:'960903',severity:'4',chain" > > >>SecRule &RESOURCE:alerted_960903_compression "@eq > > 0" "setvar:resource.alerted_960903_compression" > > > > 3) Every site/installation will be different -- you have to decide if y= ou > > want to ALLOW/ IGNORE / CUSTOMIZE this rule for your particular situati= on. > > If the rule makes sense for you -- you leave it in. > > If the Rule does not make sense for you -- then you can ignore the rule= by > > adding you own custom rules file (with appropriate naming convention wh= ich > > controls when your rules are executed) and state you want the rule to b= e > > ignored. > > In your case -- you might do something like this: > > a) create a file called: > > modsecurity_crs_60_customrules.conf > > b) in this file insert the line: SecRuleRemoveById 960903 > > > > You get the idea.... > > > > > > ---------------------------- > > In general I think the idea is to initially run the "core rules" in a "= LOG > > ONLY" mode.... > > A) See file: modsecurity_crs_10_config.confv > > line: SecDefaultAction "phase:2,log,pass,status:500" > > B) Examine the logs and decide what/if any traffic is "false positive".= .... > > Decide if you want to modify the rules -- or ignore the rules leadi= ng to > > false positives. > > * Note -- it's best to do this in your own custom *.conf files -- t= hat > > way the core rules are not overwritten with new updates etc. > > C) When you're confident your rule set is not actually blocking legal > > traffic -- then switch to a DENY mode... > > See file: modsecurity_crs_10_config.confv > > * change line: SecDefaultAction "phase:2,log,deny,status:500" > > > > I'm still trying to figure out for myself: > > 1) What the "blocking" set of core_rule files do... > > 2) How the hell do you analyze all these logs produced ?? > > ModSecurity's "Grep" like tool seems very tedious ? > > ModSecurityConsole is have hard for me to install on Windows ?? > > > > See my threads -- if you have any ideas let me know.... > > > > Cheers > > Frank > > > > > > ________________________________ > > > > > > > Date: Thu, 21 Jun 2007 14:35:08 +0100 > > > From: li...@gm... > > > To: mod...@li... > > > Subject: [mod-security-users] id "960903" > > > > > > Hi, > > > > > > Sorry for the n00b questions, but I can't seem to find the answer, my > > > log files are being filled up with... > > > > > > --55f54137-H-- > > > Message: Could not set variable > > "resource.alerted_960903_compression" > > > as the collection does not exist. > > > Message: Warning. Operator EQ match: 0. [id "960903"] [msg > > > "ModSecurity does not support content encodings"] [severity "WARNING"= ] > > > Apache-Handler: x-httpd-php > > > Stopwatch: 1182431976356708 253670 (3393 55460 -) > > > Producer: ModSecurity v2.1.0 (Apache 2.x) > > > Server: Apache > > > > > > --55f54137-Z-- > > > > > > Please could you offer some advise on how to stop this? > > > > > > Cheers, > > > Nick > > > > > > -- > > > Shameless plug for google Juice: http://www.linickx.com > > > > > > > > -----------------------------------------------------------------------= -- > > > This SF.net email is sponsored by DB2 Express > > > Download DB2 Express C - the FREE version of DB2 express and take > > > control of your XML. No limits. Just data. Click to get it now. > > > http://sourceforge.net/powerbar/db2/ > > > _______________________________________________ > > > mod-security-users mailing list > > > mod...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > ________________________________ > > > > > > Get news, entertainment and everything you care about at Live.com. Chec= k it > > out! > > > -- > Shameless plug for google Juice: http://www.linickx.com > --=20 Shameless plug for google Juice: http://www.linickx.com |
From: [NICK] <li...@gm...> - 2007-06-21 14:13:11
|
thanks Ryan, you are right, I installed modsecurity via a rpm, and removed CRS_10 as it clashed with with modsecurity.conf that came in the RPM... I added the line as you suggested, now I get... --ca8fff38-H-- Message: Unable to retrieve collection (name "resource", key "/forum/viewtopic.php"). Use SecDataDir to define data directory first. Message: Warning. Operator EQ match: 0. [id "960903"] [msg "ModSecurity does not support content encodings"] [severity "WARNING"] Apache-Handler: x-httpd-php Stopwatch: 1182435027973986 211986 (4187 43153 -) Producer: ModSecurity v2.1.0 (Apache 2.x) Server: Apache --ca8fff38-Z-- is there something else that I could be missing? thanks again, Nick On 21/06/07, Ryan Barnett <Rya...@br...> wrote: > > > > Nick, > > From the CHANGES file - > > > > ModSecurity does not support compressed content at the moment. Thus, the > following rules have been added: > > - 960902 - Content-Encoding in request not supported > > Any incoming compressed request will be denied > > - 960903 - Content-Encoding in response not suppoted > > An outgoing compressed response will be logged to alert, but ONLY ONC= E. > > > > The error message you are receiving is most likely related to this rule N= OT > being in your modsecurity_crs_10_config.conf file =96 > > > > # Loades the variable collection relating to the requested resource > > # NOTE: We will not initiate a collection if there was an error (To preve= nt > overloading) > > SecRule RESPONSE_STATUS "!^(?:30[12]|[45]\d\d)$" > "phase:3,pass,nolog,initcol:resource=3D%{REQUEST_FILENAME}" > > > > This rule initiates the RESOURCE collection for use by later rules. As y= our > error message indicates, rule 960903 is triggering and attempting to use > setvar to add a compressed content tag to the RESOURCE collection, howeve= r > the collection is not there. > > > > I would recommend that you check your modsecurity_crs_10_config.conf file= to > ensure that this rule is present. > > > > > > -- > Ryan C. Barnett > ModSecurity Community Manager > > Breach Security: Director of Application Security Training > Web Application Security Consortium (WASC) Member > CIS Apache Benchmark Project Lead > SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC > > Author: Preventing Web Attacks with Apache > > > > > > ________________________________ > > > From: mod...@li... > [mailto:mod...@li...] > On Behalf Of Frank Misa > Sent: Thursday, June 21, 2007 9:58 AM > To: [NICK]; mod...@li... > Subject: Re: [mod-security-users] id "960903" > > > > > Hi Nick, > > I'm very new to MOD_SECURITY myself. > It's like a full blown - virtual firewall - with language of it's own; > learning to customize the rules etc. and administrate the thing can be a > full time job I think ;) > > What I've learned so far: > >> Re: resource.alerted_960903_compression > 1) You can search your modSecurity_Core_Rules directory for the *.conf fi= le > that contains this rule - search for "960903" > 2) You'll find that file: > modsecurity_crs_30_http_policy.conf contains this rule.... > I've pasted it below - they are well documented and explain themselves... > >># Restricted Content Encodings > >># > >># ModSecurity does not support compressed content. Therefore, the > following > >># action will be taken: > >># - Inbound compressed content will be denied > >># - Outbound compressed content will be logged once, to alert t= he > user > >># Deny inbound compressed content > >>SecRule REQUEST_HEADERS:Content-Encoding > "!^Identity$" \ > >> > "phase:2,t:none,deny,log,auditlog,status:501,msg:'ModSecurity > does not support content > encodings',,id:'960902',severity:'3'" > >># Log outbound compressed content (once per location) > >>SecRule RESPONSE_HEADERS:Content-Encoding > "!^Identity$" \ > >> > "phase:5,t:none,pass,log,auditlog,msg:'ModSecurity does not > support content encodings',,id:'960903',severity:'4',chain" > >>SecRule &RESOURCE:alerted_960903_compression "@eq > 0" "setvar:resource.alerted_960903_compression" > > 3) Every site/installation will be different -- you have to decide if you > want to ALLOW/ IGNORE / CUSTOMIZE this rule for your particular situation= . > If the rule makes sense for you -- you leave it in. > If the Rule does not make sense for you -- then you can ignore the rule b= y > adding you own custom rules file (with appropriate naming convention whic= h > controls when your rules are executed) and state you want the rule to be > ignored. > In your case -- you might do something like this: > a) create a file called: > modsecurity_crs_60_customrules.conf > b) in this file insert the line: SecRuleRemoveById 960903 > > You get the idea.... > > > ---------------------------- > In general I think the idea is to initially run the "core rules" in a "LO= G > ONLY" mode.... > A) See file: modsecurity_crs_10_config.confv > line: SecDefaultAction "phase:2,log,pass,status:500" > B) Examine the logs and decide what/if any traffic is "false positive"...= .. > Decide if you want to modify the rules -- or ignore the rules leading= to > false positives. > * Note -- it's best to do this in your own custom *.conf files -- tha= t > way the core rules are not overwritten with new updates etc. > C) When you're confident your rule set is not actually blocking legal > traffic -- then switch to a DENY mode... > See file: modsecurity_crs_10_config.confv > * change line: SecDefaultAction "phase:2,log,deny,status:500" > > I'm still trying to figure out for myself: > 1) What the "blocking" set of core_rule files do... > 2) How the hell do you analyze all these logs produced ?? > ModSecurity's "Grep" like tool seems very tedious ? > ModSecurityConsole is have hard for me to install on Windows ?? > > See my threads -- if you have any ideas let me know.... > > Cheers > Frank > > > ________________________________ > > > > Date: Thu, 21 Jun 2007 14:35:08 +0100 > > From: li...@gm... > > To: mod...@li... > > Subject: [mod-security-users] id "960903" > > > > Hi, > > > > Sorry for the n00b questions, but I can't seem to find the answer, my > > log files are being filled up with... > > > > --55f54137-H-- > > Message: Could not set variable > "resource.alerted_960903_compression" > > as the collection does not exist. > > Message: Warning. Operator EQ match: 0. [id "960903"] [msg > > "ModSecurity does not support content encodings"] [severity "WARNING"] > > Apache-Handler: x-httpd-php > > Stopwatch: 1182431976356708 253670 (3393 55460 -) > > Producer: ModSecurity v2.1.0 (Apache 2.x) > > Server: Apache > > > > --55f54137-Z-- > > > > Please could you offer some advise on how to stop this? > > > > Cheers, > > Nick > > > > -- > > Shameless plug for google Juice: http://www.linickx.com > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > mod-security-users mailing list > > mod...@li... > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > ________________________________ > > > Get news, entertainment and everything you care about at Live.com. Check = it > out! --=20 Shameless plug for google Juice: http://www.linickx.com |
From: Frank M. <fra...@ho...> - 2007-06-21 14:05:38
|
Also...FYIThe following line (see: Include.... *.conf) -- in your apache co= nf file will ensure your custom-rules/modifications will be pulled in along= with the core_rule_set.... as long as your file extension is ".conf"#Secur= ity Settings....=0A= >><IfModule mod_security2.c>=0A= >> # use Core Rule Set by default:=0A= >> Include "C:/apache/conf/modsecurity/*.conf"=0A= >></IfModule>The number -- controls when the rules are evaluated - see:mods= ecurity_crs_##_???????.confI think....CheersFrank _________________________________________________________________ Explore the seven wonders of the world http://search.msn.com/results.aspx?q=3D7+wonders+world&mkt=3Den-US&form=3DQ= BRE= |
From: Ryan B. <Ryan.Barnett@Breach.com> - 2007-06-21 14:03:31
|
Nick, >From the CHANGES file - =20 ModSecurity does not support compressed content at the moment. Thus, the following rules have been added: - 960902 - Content-Encoding in request not supported Any incoming compressed request will be denied - 960903 - Content-Encoding in response not suppoted An outgoing compressed response will be logged to alert, but ONLY ONCE. =20 The error message you are receiving is most likely related to this rule NOT being in your modsecurity_crs_10_config.conf file - =20 # Loades the variable collection relating to the requested resource # NOTE: We will not initiate a collection if there was an error (To prevent overloading) SecRule RESPONSE_STATUS "!^(?:30[12]|[45]\d\d)$" "phase:3,pass,nolog,initcol:resource=3D%{REQUEST_FILENAME}" =20 This rule initiates the RESOURCE collection for use by later rules. As your error message indicates, rule 960903 is triggering and attempting to use setvar to add a compressed content tag to the RESOURCE collection, however the collection is not there. =20 I would recommend that you check your modsecurity_crs_10_config.conf file to ensure that this rule is present. =20 --=20 Ryan C. Barnett ModSecurity Community Manager Breach Security: Director of Application Security Training Web Application Security Consortium (WASC) Member CIS Apache Benchmark Project Lead SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC Author: Preventing Web Attacks with Apache =20 =20 ________________________________ From: mod...@li... [mailto:mod...@li...] On Behalf Of Frank Misa Sent: Thursday, June 21, 2007 9:58 AM To: [NICK]; mod...@li... Subject: Re: [mod-security-users] id "960903" =20 Hi Nick, I'm very new to MOD_SECURITY myself. It's like a full blown - virtual firewall - with language of it's own; learning to customize the rules etc. and administrate the thing can be a full time job I think ;) What I've learned so far:=20 >> Re: resource.alerted_960903_compression 1) You can search your modSecurity_Core_Rules directory for the *.conf file that contains this rule - search for "960903" 2) You'll find that file: modsecurity_crs_30_http_policy.conf contains this rule.... I've pasted it below - they are well documented and explain themselves... >># Restricted Content Encodings >># >># ModSecurity does not support compressed content. Therefore, the following >># action will be taken: >># - Inbound compressed content will be denied >># - Outbound compressed content will be logged once, to alert the user >># Deny inbound compressed content >>SecRule REQUEST_HEADERS:Content-Encoding "!^Identity$" \ >> "phase:2,t:none,deny,log,auditlog,status:501,msg:'ModSecurity does not support content encodings',,id:'960902',severity:'3'" >># Log outbound compressed content (once per location) >>SecRule RESPONSE_HEADERS:Content-Encoding "!^Identity$" \ >> "phase:5,t:none,pass,log,auditlog,msg:'ModSecurity does not support content encodings',,id:'960903',severity:'4',chain" >>SecRule &RESOURCE:alerted_960903_compression "@eq 0" "setvar:resource.alerted_960903_compression" 3) Every site/installation will be different -- you have to decide if you want to ALLOW/ IGNORE / CUSTOMIZE this rule for your particular situation. If the rule makes sense for you -- you leave it in. If the Rule does not make sense for you -- then you can ignore the rule by adding you own custom rules file (with appropriate naming convention which controls when your rules are executed) and state you want the rule to be ignored. In your case -- you might do something like this: a) create a file called: modsecurity_crs_60_customrules.conf b) in this file insert the line: SecRuleRemoveById 960903 You get the idea.... ---------------------------- In general I think the idea is to initially run the "core rules" in a "LOG ONLY" mode.... A) See file: modsecurity_crs_10_config.confv line: SecDefaultAction "phase:2,log,pass,status:500" B) Examine the logs and decide what/if any traffic is "false positive"..... Decide if you want to modify the rules -- or ignore the rules leading to false positives. * Note -- it's best to do this in your own custom *.conf files -- that way the core rules are not overwritten with new updates etc. C) When you're confident your rule set is not actually blocking legal traffic -- then switch to a DENY mode... See file: modsecurity_crs_10_config.confv * change line: SecDefaultAction "phase:2,log,deny,status:500" I'm still trying to figure out for myself: 1) What the "blocking" set of core_rule files do... 2) How the hell do you analyze all these logs produced ?? ModSecurity's "Grep" like tool seems very tedious ? ModSecurityConsole is have hard for me to install on Windows ?? See my threads -- if you have any ideas let me know.... Cheers Frank =20 ________________________________ > Date: Thu, 21 Jun 2007 14:35:08 +0100 > From: li...@gm... > To: mod...@li... > Subject: [mod-security-users] id "960903" >=20 > Hi, >=20 > Sorry for the n00b questions, but I can't seem to find the answer, my > log files are being filled up with... >=20 > --55f54137-H-- > Message: Could not set variable "resource.alerted_960903_compression" > as the collection does not exist. > Message: Warning. Operator EQ match: 0. [id "960903"] [msg > "ModSecurity does not support content encodings"] [severity "WARNING"] > Apache-Handler: x-httpd-php > Stopwatch: 1182431976356708 253670 (3393 55460 -) > Producer: ModSecurity v2.1.0 (Apache 2.x) > Server: Apache >=20 > --55f54137-Z-- >=20 > Please could you offer some advise on how to stop this? >=20 > Cheers, > Nick >=20 > --=20 > Shameless plug for google Juice: http://www.linickx.com >=20 > ------------------------------------------------------------------------ - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users ________________________________ Get news, entertainment and everything you care about at Live.com. Check it out! <http://www.live.com/getstarted.aspx%20>=20 |
From: Frank M. <fra...@ho...> - 2007-06-21 13:58:26
|
Hi Nick,I'm very new to MOD_SECURITY myself.It's like a full blown - virtua= l firewall - with language of it's own; learning to customize the rules et= c. and administrate the thing can be a full time job I think ;)What I've le= arned so far: >> Re: resource.alerted_960903_compression1) You can search y= our modSecurity_Core_Rules directory for the *.conf file that contains this= rule - search for "960903"2) You'll find that file: modsecurity_crs_30_htt= p_policy.conf contains this rule....I've pasted it below - they are well do= cumented and explain themselves... >># Restricted Content Encodings = >># >># ModSecurity does not support compressed content. Therefore,= the following >># action will be taken: >># - Inbound compress= ed content will be denied >># - Outbound compressed content will be = logged once, to alert the user >># Deny inbound compressed content = >>SecRule REQUEST_HEADERS:Content-Encoding "!^Identity$" \ >> "ph= ase:2,t:none,deny,log,auditlog,status:501,msg:'ModSecurity does not support= content encodings',,id:'960902',severity:'3'" >># Log outbound compre= ssed content (once per location) >>SecRule RESPONSE_HEADERS:Content-En= coding "!^Identity$" \ >> "phase:5,t:none,pass,log,auditlog,msg:'Mo= dSecurity does not support content encodings',,id:'960903',severity:'4',cha= in" >>SecRule &RESOURCE:alerted_960903_compression "@eq 0" "setvar:res= ource.alerted_960903_compression"3) Every site/installation will be differe= nt -- you have to decide if you want to ALLOW/ IGNORE / CUSTOMIZE this rule= for your particular situation. If the rule makes sense for you -- you lea= ve it in.If the Rule does not make sense for you -- then you can ignore the= rule by adding you own custom rules file (with appropriate naming conventi= on which controls when your rules are executed) and state you want the rule= to be ignored.In your case -- you might do something like this: a) cre= ate a file called: modsecurity_crs_60_customrules.conf b) in t= his file insert the line: SecRuleRemoveById 960903You get the idea....-----= -----------------------In general I think the idea is to initially run the = "core rules" in a "LOG ONLY" mode....A) See file: modsecurity_crs_10_con= fig.confv line: SecDefaultAction "phase:2,log,pass,status:500"B= ) Examine the logs and decide what/if any traffic is "false positive"..... = Decide if you want to modify the rules -- or ignore the rules leading to= false positives. * Note -- it's best to do this in your own custom *.co= nf files -- that way the core rules are not overwritten with new updates et= c.C) When you're confident your rule set is not actually blocking legal tra= ffic -- then switch to a DENY mode... See file: modsecurity_crs= _10_config.confv=0A= * change line: SecDefaultAction "phase:2,log,deny,status:500"I'm sti= ll trying to figure out for myself:1) What the "blocking" set of core_rule = files do...2) How the hell do you analyze all these logs produced ?? Mod= Security's "Grep" like tool seems very tedious ? ModSecurityConsole is h= ave hard for me to install on Windows ??See my threads -- if you have any i= deas let me know....CheersFrank> Date: Thu, 21 Jun 2007 14:35:08 +0100> Fro= m: li...@gm...> To: mod...@li...> Subject= : [mod-security-users] id "960903"> > Hi,> > Sorry for the n00b questions, = but I can't seem to find the answer, my> log files are being filled up with= ...> > --55f54137-H--> Message: Could not set variable "resource.alerted_96= 0903_compression"> as the collection does not exist.> Message: Warning. Ope= rator EQ match: 0. [id "960903"] [msg> "ModSecurity does not support conten= t encodings"] [severity "WARNING"]> Apache-Handler: x-httpd-php> Stopwatch:= 1182431976356708 253670 (3393 55460 -)> Producer: ModSecurity v2.1.0 (Apac= he 2.x)> Server: Apache> > --55f54137-Z--> > Please could you offer some ad= vise on how to stop this?> > Cheers,> Nick> > -- > Shameless plug for googl= e Juice: http://www.linickx.com> > ----------------------------------------= ---------------------------------> This SF.net email is sponsored by DB2 Ex= press> Download DB2 Express C - the FREE version of DB2 express and take> c= ontrol of your XML. No limits. Just data. Click to get it now.> http://sour= ceforge.net/powerbar/db2/> _______________________________________________>= mod-security-users mailing list> mod...@li...>= https://lists.sourceforge.net/lists/listinfo/mod-security-users _________________________________________________________________ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx= |
From: [NICK] <li...@gm...> - 2007-06-21 13:35:12
|
Hi, Sorry for the n00b questions, but I can't seem to find the answer, my log files are being filled up with... --55f54137-H-- Message: Could not set variable "resource.alerted_960903_compression" as the collection does not exist. Message: Warning. Operator EQ match: 0. [id "960903"] [msg "ModSecurity does not support content encodings"] [severity "WARNING"] Apache-Handler: x-httpd-php Stopwatch: 1182431976356708 253670 (3393 55460 -) Producer: ModSecurity v2.1.0 (Apache 2.x) Server: Apache --55f54137-Z-- Please could you offer some advise on how to stop this? Cheers, Nick -- Shameless plug for google Juice: http://www.linickx.com |
From: Markus H. <inf...@ya...> - 2007-06-21 04:40:59
|
Note If you do not trust your users (e.g. running in a web hosting environment) then you should never allow them access to ModSecurity. The .htaccess facility is useful for limited administration control decentralisation, keeping ModSecurity configuration with the application code. But it is not meant to be used in situations when the users may want to subvert the configuration. If you are running a hostile environment you should turn off the .htaccess facility completely by custom-compiling ModSecurity with the -DDISABLE_HTACCESS_CONFIG switch. ========================= i enabled -DDISABLE_HTACCESS_CONFIG option when installing modsecurity 1 (i'm still using apache 1), it seems that it also disabled php_flag option, as when i put php_flag option my website is disable (show internal server error which is the error that should be shown when user try to disable mod_security from .htaccess file) i put this on .htaccess: ----------------- php_flag register_globals Off ----------------- Markus Send instant messages to your online friends http://uk.messenger.yahoo.com |
From: Frank M. <fra...@ho...> - 2007-06-20 14:36:57
|
Very Sorry -- wrong thread... Ignore that last post...> Date: Wed, 20 Jun 2= 007 10:00:07 -0400> From: Bri...@br...> To: vp...@gm...> = CC: mod...@li...> Subject: Re: [mod-security-us= ers] Problem with undefined symbol: msr_log> > Victor Enrique Pazce Z=FA=F1= iga wrote:> > Hi everybody:> > > > I instaled mod_security on apache2 witch= mod_proxy and mod_proxy_http> > but when i tried to restart it send me tha= n message:> > > What modsecurity version?> > What apache version?> > How di= d you compile it?> > > > > > # /etc/init.d/apache2 restart> > httpd2-prefo= rk: Syntax error on line 116 of /etc/apache2/httpd.conf:> > Syntax error on= line 32 of /etc/apache2/sysconfig.d/loadmodule.conf:> > Cannot load /usr/l= ib/apache2/mod_security2.so into server:> > /usr/lib/apache2/mod_security2.= so: undefined symbol: msr_log> > > Looks like a linking issue.> > > > > > >= > Could you help me?> > > Sure, please answer the above and give any other= details you think are> needed.> > Thanks,> -B> > -- > Brian Rectanus> Brea= ch Security> > ------------------------------------------------------------= -------------> This SF.net email is sponsored by DB2 Express> Download DB2 = Express C - the FREE version of DB2 express and take> control of your XML. = No limits. Just data. Click to get it now.> http://sourceforge.net/powerbar= /db2/> _______________________________________________> mod-security-users = mailing list> mod...@li...> https://lists.sourc= eforge.net/lists/listinfo/mod-security-users _________________________________________________________________ Explore the seven wonders of the world http://search.msn.com/results.aspx?q=3D7+wonders+world&mkt=3Den-US&form=3DQ= BRE= |
From: Frank M. <fra...@ho...> - 2007-06-20 14:33:01
|
Hi Victor...I think I've supplied all this in previous posts.See my last er= ror message when running from command-line - could it be folder/process acc= ess control or permissions in Windows ?Versions...Apache: From: (= www.hunter.campbus.com) 2.0.59ModSecurity2: From: (www.apachelounge.com) = 2.1.1Perl: From: (www.activestate.com): 5.8.8 buil= t for MSWin32-x86-multi-threadModSecurityConsole: Latest from source...DLLs= (From: www.zlatkovic.com)libxml2 v2.6.28iconv v1.9.2zlib v1.= 2.3 _________________________________________________________________ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx= |
From: Ryan B. <Ryan.Barnett@Breach.com> - 2007-06-20 14:30:46
|
Did you use the Makefile to compile or did you use apxs directly? A = past post to the mail-list with the same error message was traced back = to the user using apxs directly. =20 --=20 Ryan C. Barnett ModSecurity Community Manager Breach Security: Director of Application Security Training Web Application Security Consortium (WASC) Member CIS Apache Benchmark Project Lead SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC Author: Preventing Web Attacks with Apache =20 =20 ________________________________ From: mod...@li... = [mailto:mod...@li...] On Behalf Of = Victor Enrique Pazce Z=FA=F1iga Sent: Tuesday, June 19, 2007 11:30 PM To: mod...@li... Subject: [mod-security-users] Problem with undefined symbol: msr_log =20 Hi everybody: I instaled mod_security on apache2 witch mod_proxy and mod_proxy_http = but when i tried to restart it send me than message: # /etc/init.d/apache2 restart httpd2-prefork: Syntax error on line 116 of /etc/apache2/httpd.conf: = Syntax error on line 32 of /etc/apache2/sysconfig.d/loadmodule.conf: = Cannot load /usr/lib/apache2/mod_security2.so into server: = /usr/lib/apache2/mod_security2.so: undefined symbol: msr_log=20 Could you help me? Thanks Victor Pazce Zu=F1iga TrialKiller |
From: Brian R. <Bri...@br...> - 2007-06-20 14:22:35
|
Victor Enrique Pazce Zúñiga wrote: > Hi everybody: > > I instaled mod_security on apache2 witch mod_proxy and mod_proxy_http > but when i tried to restart it send me than message: What modsecurity version? What apache version? How did you compile it? > > # /etc/init.d/apache2 restart > httpd2-prefork: Syntax error on line 116 of /etc/apache2/httpd.conf: > Syntax error on line 32 of /etc/apache2/sysconfig.d/loadmodule.conf: > Cannot load /usr/lib/apache2/mod_security2.so into server: > /usr/lib/apache2/mod_security2.so: undefined symbol: msr_log Looks like a linking issue. > > > Could you help me? Sure, please answer the above and give any other details you think are needed. Thanks, -B -- Brian Rectanus Breach Security |
From: <vp...@gm...> - 2007-06-20 03:29:47
|
Hi everybody: I instaled mod_security on apache2 witch mod_proxy and mod_proxy_http but when i tried to restart it send me than message: # /etc/init.d/apache2 restart httpd2-prefork: Syntax error on line 116 of /etc/apache2/httpd.conf: Syntax error on line 32 of /etc/apache2/sysconfig.d/loadmodule.conf: Cannot load /usr/lib/apache2/mod_security2.so into server: /usr/lib/apache2/mod_security2.so: undefined symbol: msr_log Could you help me? Thanks Victor Pazce Zu=F1iga TrialKiller |
From: Brian R. <Bri...@br...> - 2007-06-19 20:11:49
|
Frank Misa wrote: > > One more note... > > Screenshot of process viewer - perl script does not seem to be doing > much - when run from command line.... > C:/Perl/bin/perl.exe C:/apache/bin/modsec-auditlog-collector.pl > "C:/apache/logs/modSecurity/audit" > "C:/apache/logs/modSecurity/auditlog/audit.log" > > See attached image... > Thanks > Frank > > > > ------------------------------------------------------------------------ >> Date: Tue, 19 Jun 2007 15:07:41 -0400 >> From: Bri...@br... >> To: fra...@ho... >> CC: mod...@li... >> Subject: Re: [mod-security-users] Perl script issues - running > ModSecurity Console on a Windows box. >> >> I don't have a windows box in front of me at the moment, but here are >> some thoughts... >> >> >> Frank Misa wrote: >> > Hi All, >> > >> > Anyone running ModSecurity_Console successfully on a Windows box. >> > I suspect I'm running into PerlScript issues after following the install >> > instructions here: >> > >> > http://www.modsecurity.org/blog/archives/2007/03/modsecurity_con_1.html >> > >> > If I configure as described above -- with perl processing the >> > mod_security2 audit logs -- then apache never starts. >> > When I run apache/mod_security2 without the perl log processing - >> > everything works fine: >> >>> C:\apache\bin>.\Apache -S >> >>> VirtualHost configuration: >> >>> 192.168.15.52:80 192.168.15.52 (C:/apache/conf/httpd.conf:992) >> >>> 192.168.15.52:443 192.168.15.52 (C:/apache/conf/httpd.conf:1009) >> >>> Syntax OK >> > >> > However, when I switch to perl processing: >> >>> #SecAuditLog C:/apache/logs/modSecurity/auditlog/modsec_audit.log >> >>> #TRY1 - won't work with forward slash... >> >>> #SecAuditLog "|C:/apache/bin/modsec-auditlog-collector.pl >> > C:/apache/logs/modSecurity/audit/ >> > C:/apache/logs/modSecurity/auditlog/audit.log" >> >>> #TRY2 - tries but fails with back slash.... >> >>> SecAuditLog "|C:\apache\bin\modsec-auditlog-collector.pl \ >> >>> C:\apache\logs\modSecurity\audit\ >> > C:\apache\logs\modSecurity\auditlog\audit.log" >> > >> > Apache Check just returns silently.... no error/complaint.... the >> > apache service never starts... >> >>>C:\apache\bin>.\Apache -S >> >>>C:\apache\bin> >> >> >> Any error in the event log? >> >> >> > >> > Can I run the script directly from command prompt for more output ? >> >>> C:\apache\bin>perl modsec-auditlog-collector.pl "cibaSTAGING" >> > "C:\apache\logs\modSecurity\audit\" "C:\apache\logs\ >> >>> Failed to open: C:\apache\logs\modSecurity\audit" >> > C:\apache\logs\modSecurity\auditlog\modsec_audit.log >> > Note: Where cibaSTAGING is the name of my remote sensor.... >> >> >> Not sure why you added the extra parameter for the sensor name. Just >> run it from the command line with the same parameters as specified in >> the httpd.conf >> >> >> > >> > Please see attached files.... >> > System: Windows 2003 SP1 >> > Perl: This is perl, v5.8.8 built for MSWin32-x86-multi-thread >> > Hope someone can see my mistake..... >> > Thanks >> > Frank >> >> >> What apache binary (where is it from)? >> >> >> > #SecAuditLogType Serial >> > SecAuditLogType Concurrent >> > #SecAuditLog logs/modsec_audit.log >> > SecAuditLog C:/apache/logs/modSecurity/auditlog/modsec_audit.log >> > #SecAuditLog "|C:/apache/bin/modsec-auditlog-collector.pl > C:/apache/logs/modSecurity/audit/ > C:/apache/logs/modSecurity/auditlog/audit.log" >> > # SecAuditLogStorageDir logs/modsec_audit >> > SecAuditLogStorageDir C:/apache/logs/modSecurity/audit >> >> >> Try without the trailing '/'? >> >> Try with the perl interpreter: >> >> SecAuditLog "|C:/path/to/perl.exe >> C:/apache/bin/modsec-auditlog-collector.pl >> C:/apache/logs/modSecurity/audit >> C:/apache/logs/modSecurity/auditlog/audit.log" >> >> >> I'll get a windows setup and try it out later. >> >> -B >> >> -- >> Brian Rectanus >> Breach Security > > ------------------------------------------------------------------------ > Connect to the next generation of MSN Messenger Get it now! > <http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline> > ------------------------------------------------------------------------ > No, it just waits for input from stdin. You can input the current index file as stdin and it should read that. -B -- Brian Rectanus Breach Security |
From: Frank M. <fra...@ho...> - 2007-06-19 19:59:00
|
Thanks Brian & Ryan....Really appreciate the thoughts...Re: Any error in t= he event log?Great idea - I missed that source - the following event was th= rown in event viewer:>> Faulting application Apache.exe, version 2.0.59.200= , faulting module libapr.dll, version 0.9.12.0, fault address 0x0000d6f0.>>= For more information, see Help and Support Center at http://go.microsoft.c= om/fwlink/events.asp.Re: Not sure why you added the extra parameter for the= sensor name.Because - when I ran from command line initially - the script = was asking for 3 parameters.I took stab that modsec-auditlog-collector was = "sensor" name -- but figured the 1st of 3 parameters was the actual pipe-st= ream used in the .conf file (i.e. | c:/perl.exe script.pl 2ndParam 3rdPar= am)>>C:\>C:/Perl/bin/perl.exe C:/apache/bin/modsec-auditlog-collector.pl>>U= sage: modsec-auditlog-collector auditlog-folder auditlog-indexRe: What apa= che binary (where is it from)?I'm using Server version: Apache/2.0.59 from:= http://www.hunter.campbus.com/with mod_security2 version: 2.1.1 from: = http://www.apachelounge.com/Re: Try without the trailing '/'? T= ry with the perl interpreter:Following just hangs - does nothing....>>C:\ap= ache\bin>C:/Perl/bin/perl.exe C:/apache/bin/modsec-auditlog-collector.pl "C= :/apache/logs/modSecurity/audit" "C:/apache/logs/modSecurity/auditlog/audit= .log"I think -- if I can get the perl script -- modsec-auditlog-collector.p= l -- working from command line -- then Apache should not have any trouble w= ith it. In any case -- commenting out the perl processing returns apache b= ack to normal -- starts with no problem.Let me know if you have any other t= houghts...ThanksFrank> Date: Tue, 19 Jun 2007 15:07:41 -0400> From: Brian.R= ec...@br...> To: fra...@ho...> CC: mod-security-users@lists= .sourceforge.net> Subject: Re: [mod-security-users] Perl script issues - ru= nning ModSecurity Console on a Windows box.> > I don't have a windows box i= n front of me at the moment, but here are> some thoughts...> > > Frank Misa= wrote:> > Hi All,> > > > Anyone running ModSecurity_Console successfully o= n a Windows box.> > I suspect I'm running into PerlScript issues after foll= owing the install> > instructions here:> > > > http://www.modsecurity.org/b= log/archives/2007/03/modsecurity_con_1.html> > > > If I configure as descri= bed above -- with perl processing the> > mod_security2 audit logs -- then a= pache never starts.> > When I run apache/mod_security2 without the perl log= processing -> > everything works fine:> >>> C:\apache\bin>.\Apache -S> >>>= VirtualHost configuration:> >>> 192.168.15.52:80 192.168.15.52 (C:/a= pache/conf/httpd.conf:992)> >>> 192.168.15.52:443 192.168.15.52 (C:/ap= ache/conf/httpd.conf:1009)> >>> Syntax OK> > > > However, when I switch to = perl processing:> >>> #SecAuditLog C:/apache/logs/modSecurity/auditlog/mods= ec_audit.log> >>> #TRY1 - won't work with forward slash...> >>> #SecAuditLo= g "|C:/apache/bin/modsec-auditlog-collector.pl> > C:/apache/logs/modSecurit= y/audit/> > C:/apache/logs/modSecurity/auditlog/audit.log"> >>> #TRY2 - tri= es but fails with back slash....> >>> SecAuditLog "|C:\apache\bin\modsec-au= ditlog-collector.pl \> >>> C:\apache\logs\modSecurity\audit\> > C:\apache\l= ogs\modSecurity\auditlog\audit.log"> > > > Apache Check just returns silent= ly.... no error/complaint.... the> > apache service never starts...> >>>C:= \apache\bin>.\Apache -S> >>>C:\apache\bin>> > > Any error in the event log?= > > > > > > Can I run the script directly from command prompt for more outp= ut ?> >>> C:\apache\bin>perl modsec-auditlog-collector.pl "cibaSTAGING"> > = "C:\apache\logs\modSecurity\audit\" "C:\apache\logs\> >>> Failed to open: C= :\apache\logs\modSecurity\audit"> > C:\apache\logs\modSecurity\auditlog\mod= sec_audit.log> > Note: Where cibaSTAGING is the name of my remote sensor...= .> > > Not sure why you added the extra parameter for the sensor name. Jus= t> run it from the command line with the same parameters as specified in> t= he httpd.conf> > > > > > Please see attached files....> > System: Windows 2= 003 SP1> > Perl: This is perl, v5.8.8 built for MSWin32-x86-multi-thre= ad> > Hope someone can see my mistake.....> > Thanks> > Frank> > > What apa= che binary (where is it from)?> > > > #SecAuditLogType Serial> > SecAuditLo= gType Concurrent> > #SecAuditLog logs/modsec_audit.log> > SecAuditLog C:/ap= ache/logs/modSecurity/auditlog/modsec_audit.log> > #SecAuditLog "|C:/apache= /bin/modsec-auditlog-collector.pl C:/apache/logs/modSecurity/audit/ C:/apac= he/logs/modSecurity/auditlog/audit.log"> > # SecAuditLogStorageDir logs/mod= sec_audit> > SecAuditLogStorageDir C:/apache/logs/modSecurity/audit> > > Tr= y without the trailing '/'?> > Try with the perl interpreter:> > SecAuditLo= g "|C:/path/to/perl.exe> C:/apache/bin/modsec-auditlog-collector.pl> C:/apa= che/logs/modSecurity/audit> C:/apache/logs/modSecurity/auditlog/audit.log">= > > I'll get a windows setup and try it out later.> > -B> > -- > Brian Rec= tanus> Breach Security _________________________________________________________________ Explore the seven wonders of the world http://search.msn.com/results.aspx?q=3D7+wonders+world&mkt=3Den-US&form=3DQ= BRE= |
From: Brian R. <Bri...@br...> - 2007-06-19 19:07:52
|
I don't have a windows box in front of me at the moment, but here are some thoughts... Frank Misa wrote: > Hi All, > > Anyone running ModSecurity_Console successfully on a Windows box. > I suspect I'm running into PerlScript issues after following the install > instructions here: > > http://www.modsecurity.org/blog/archives/2007/03/modsecurity_con_1.html > > If I configure as described above -- with perl processing the > mod_security2 audit logs -- then apache never starts. > When I run apache/mod_security2 without the perl log processing - > everything works fine: >>> C:\apache\bin>.\Apache -S >>> VirtualHost configuration: >>> 192.168.15.52:80 192.168.15.52 (C:/apache/conf/httpd.conf:992) >>> 192.168.15.52:443 192.168.15.52 (C:/apache/conf/httpd.conf:1009) >>> Syntax OK > > However, when I switch to perl processing: >>> #SecAuditLog C:/apache/logs/modSecurity/auditlog/modsec_audit.log >>> #TRY1 - won't work with forward slash... >>> #SecAuditLog "|C:/apache/bin/modsec-auditlog-collector.pl > C:/apache/logs/modSecurity/audit/ > C:/apache/logs/modSecurity/auditlog/audit.log" >>> #TRY2 - tries but fails with back slash.... >>> SecAuditLog "|C:\apache\bin\modsec-auditlog-collector.pl \ >>> C:\apache\logs\modSecurity\audit\ > C:\apache\logs\modSecurity\auditlog\audit.log" > > Apache Check just returns silently.... no error/complaint.... the > apache service never starts... >>>C:\apache\bin>.\Apache -S >>>C:\apache\bin> Any error in the event log? > > Can I run the script directly from command prompt for more output ? >>> C:\apache\bin>perl modsec-auditlog-collector.pl "cibaSTAGING" > "C:\apache\logs\modSecurity\audit\" "C:\apache\logs\ >>> Failed to open: C:\apache\logs\modSecurity\audit" > C:\apache\logs\modSecurity\auditlog\modsec_audit.log > Note: Where cibaSTAGING is the name of my remote sensor.... Not sure why you added the extra parameter for the sensor name. Just run it from the command line with the same parameters as specified in the httpd.conf > > Please see attached files.... > System: Windows 2003 SP1 > Perl: This is perl, v5.8.8 built for MSWin32-x86-multi-thread > Hope someone can see my mistake..... > Thanks > Frank What apache binary (where is it from)? > #SecAuditLogType Serial > SecAuditLogType Concurrent > #SecAuditLog logs/modsec_audit.log > SecAuditLog C:/apache/logs/modSecurity/auditlog/modsec_audit.log > #SecAuditLog "|C:/apache/bin/modsec-auditlog-collector.pl C:/apache/logs/modSecurity/audit/ C:/apache/logs/modSecurity/auditlog/audit.log" > # SecAuditLogStorageDir logs/modsec_audit > SecAuditLogStorageDir C:/apache/logs/modSecurity/audit Try without the trailing '/'? Try with the perl interpreter: SecAuditLog "|C:/path/to/perl.exe C:/apache/bin/modsec-auditlog-collector.pl C:/apache/logs/modSecurity/audit C:/apache/logs/modSecurity/auditlog/audit.log" I'll get a windows setup and try it out later. -B -- Brian Rectanus Breach Security |
From: Ryan B. <Ryan.Barnett@Breach.com> - 2007-06-19 18:55:49
|
While not directly answering your issue, you may consider trying to run Apache under Cygwin - http://httpd.apache.org/docs/1.3/cygwin.html. This may help to alleviate some of the OS differences (paths, etc...). =20 --=20 Ryan C. Barnett ModSecurity Community Manager Breach Security: Director of Application Security Training Web Application Security Consortium (WASC) Member CIS Apache Benchmark Project Lead SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC Author: Preventing Web Attacks with Apache =20 =20 ________________________________ From: mod...@li... [mailto:mod...@li...] On Behalf Of Frank Misa Sent: Tuesday, June 19, 2007 2:18 PM To: mod...@li... Subject: [mod-security-users] Perl script issues - running ModSecurityConsole on a Windows box. =20 Hi All, Anyone running ModSecurity_Console successfully on a Windows box. I suspect I'm running into PerlScript issues after following the install instructions here: http://www.modsecurity.org/blog/archives/2007/03/modsecurity_con_1.html If I configure as described above -- with perl processing the mod_security2 audit logs -- then apache never starts. When I run apache/mod_security2 without the perl log processing - everything works fine: >> C:\apache\bin>.\Apache -S >> VirtualHost configuration: >> 192.168.15.52:80 192.168.15.52 (C:/apache/conf/httpd.conf:992) >> 192.168.15.52:443 192.168.15.52 (C:/apache/conf/httpd.conf:1009) >> Syntax OK However, when I switch to perl processing: >> #SecAuditLog C:/apache/logs/modSecurity/auditlog/modsec_audit.log >> #TRY1 - won't work with forward slash... >> #SecAuditLog "|C:/apache/bin/modsec-auditlog-collector.pl C:/apache/logs/modSecurity/audit/ C:/apache/logs/modSecurity/auditlog/audit.log" >> #TRY2 - tries but fails with back slash.... >> SecAuditLog "|C:\apache\bin\modsec-auditlog-collector.pl \ >> C:\apache\logs\modSecurity\audit\ C:\apache\logs\modSecurity\auditlog\audit.log" Apache Check just returns silently.... no error/complaint.... the apache service never starts... >>C:\apache\bin>.\Apache -S >>C:\apache\bin> Can I run the script directly from command prompt for more output ? >> C:\apache\bin>perl modsec-auditlog-collector.pl "cibaSTAGING" "C:\apache\logs\modSecurity\audit\" "C:\apache\logs\ >> Failed to open: C:\apache\logs\modSecurity\audit" C:\apache\logs\modSecurity\auditlog\modsec_audit.log Note: Where cibaSTAGING is the name of my remote sensor.... Please see attached files.... System: Windows 2003 SP1 Perl: This is perl, v5.8.8 built for MSWin32-x86-multi-thread Hope someone can see my mistake..... Thanks Frank =20 ________________________________ Connect to the next generation of MSN Messenger Get it now! <http://imagine-msn.com/messenger/launch80/default.aspx?locale=3Den-us&so= u rce=3Dwlmailtagline>=20 |
From: Frank M. <fra...@ho...> - 2007-06-19 18:18:03
|
IyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCiMgQ29yZSBNb2RTZWN1cml0eSBSdWxlIFNldA0KIyBDb3B5cmlnaHQgKEMpIDIw MDYgQnJlYWNoIFNlY3VyaXR5IEluYy4gQWxsIHJpZ2h0cyByZXNlcnZlZC4NCiMNCiMgVGhlIE1v ZFNlY3VpcnR5IENvcmUgUnVsZSBTZXQgaXMgZGlzdHJpYnV0ZWQgdW5kZXIgR1BMIHZlcnNpb24g Mg0KIyBQbGVhc2Ugc2VlIHRoZSBlbmNsb3NlZCBMSUNFTkNFIGZpbGUgZm9yIGZ1bGwgZGV0YWls cy4NCiMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQoNCg0KIyBDb25maWd1cmF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGZpbGUg c2hvdWxkIGJlIGN1c3RvbWl6ZWQNCiMgZm9yIHlvdXIgc3BlY2lmaWMgcmVxdWlyZW1lbnRzIGJl Zm9yZSBkZXBsb3ltZW50Lg0KIw0KIyBOZXh0IHRvIGVhY2ggcnVsZSB0aGVyZSBpcyBhIGRlc2Ny aXB0aW9uIG9mIHdoYXQgaXQgZG9lcy4gRWFjaA0KIyBsb2NhdGlvbiB3aGVyZSBjdXN0b21pemF0 aW9uIGlzIG5lZWRlZCBpcyBtYXJrZWQgd2l0aCAiVE9ETyIuIEl0DQojIGlzIHJlY29tbWVuZGVk IHRoYXQgeW91Og0KIw0KIyAgMSkgS2VlcCBhIGNvcHkgb2YgdGhlIG9yaWdpbmFsIGZpbGUuIFRo aXMgd2lsbCBhbGxvdyB5b3UgdG8gdXNlDQojICAgICB0aGUgImRpZmYiIGNvbW1hbmQgdG8gcXVp Y2tseSBzZWUgdGhlIGNoYW5nZXMuIEl0IHdpbGwgYWxzbw0KIyAgICAgbWFrZSB1cGdyYWRlcyB0 byBmdXR1cmUgcnVsZSBzZXRzIGVhc2llci4NCiMNCiMgIDIpIERvY3VtZW50IHlvdXIgY2hhbmdl cyB0aG9yb3VnaGx5Lg0KIw0KIyBZb3UgYXJlIGFkdmlzZWQgdG8gc3RhcnQgd2l0aCBNb2RTZWN1 cml0eSBpbiBkZXRlY3Rpb24gbW9kZSBvbmx5Lg0KIyBTd2l0Y2ggdG8gcHJvdGVjdGlvbiB3aGVu IHlvdSBhcmUgY29tZm9ydGFibGUgd2l0aCB5b3VyIHJ1bGUgc2V0Lg0KIyBGb3IgbWF4aW11bSBw cm90ZWN0aW9uIG1vbml0b3IgeW91ciBsb2dzIG9uIGRhaWx5IGJhc2lzIChvcg0KIyBiZXR0ZXIp Lg0KIw0KDQojIFRPRE8gWW91IG1heSB3YW50IHRvIHByb3ZpZGUgYW4gZXJyb3IgZnJpZW5kbHkg bWVzc2FnZSB0byB5b3VyDQojICAgICAgdXNlcnMgd2hlbiB5b3Ugc3RhcnQgcmVqZWN0aW5nIHJl cXVlc3RzLiBZb3UgY2FuIGRvIHRoaXMgdXNpbmcNCiMgICAgICB0aGUgQXBhY2hlIEVycm9yRG9j dW1lbnQgZGlyZWN0aXZlLiBZb3Ugc2hvdWxkIGFsc28gYWRkDQojICAgICAgbW9kX3VuaXF1ZV9p ZCB0byB5b3VyIGNvbmZpZ3VyYXRpb24gYW5kIGRpc3BsYXkgdGhlIHVuaXF1ZQ0KIyAgICAgIHJl cXVlc3QgSUQgb24gdGhlIGVycm9yIHBhZ2UuIFRoaXMgd291bGQgYWxsb3cgeW91ciB1c2VycyB0 bw0KIyAgICAgIHJlcG9ydCB0aGUgcmVxdWVzdCBJRCBiYWNrIHRvIHlvdSBzbyB0aGF0IHlvdSBj YW4gaW52ZXN0aWdhdGUNCiMgICAgICB0aGUgZmFsc2UgcG9zaXRpdmUgKGlmIHRoYXQncyB3aGF0 IGl0IGlzKS4gQSBuaWNlIGVycm9yIHBhZ2UNCiMgICAgICB1c3VhbGx5IHJlZHVjZXMgdGhlIGlt cGFjdCBvZiBmYWxzZSBwb3NpdGl2ZXMgb24gdGhlIHVzZXJzLg0KIw0KIyAgICAgIFRoZSBkcmF3 YmFjayBvZiB0aGlzIHVzZXIgZnJpZW5kbHkgYXBwcm9hY2ggaXMgdGhhdCBpdCBpcw0KIyAgICAg IGVhc2llciBmb3IgdGhlIGF0dGFja2VycyB0byBmaWd1cmUgb3V0IHRoZXJlIGlzIGFuIHdlYg0K IyAgICAgIGFwcGxpY2F0aW9uIGZpcmV3YWxsIHByb3RlY3RpbmcgdGhlIGFwcGxpY2F0aW9uLg0K Iw0KIyAgICAgIEVycm9yRG9jdW1lbnQgNDAzIC9wYXRoL3RvL2Vycm9yX2RvY3VtZW50LnBocA0K Iw0KIyAgICAgIEZvciBtb3JlIGluZm9ybWF0aW9uIHNlZSANCiMgICAgICBodHRwOi8vaHR0cGQu YXBhY2hlLm9yZy9kb2NzLTIuMC9jdXN0b20tZXJyb3IuaHRtbA0KDQoNCiMjIC0tIENvbmZpZ3Vy YXRpb24gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KDQojIFR1cm4gTW9kU2VjdXJpdHkgb24gKCJPbiIpLCBzZXQgdG8gbW9uaXRvcmlu ZyBvbmx5IA0KIyAoIkRldGVjdGlvbk9ubHkiKSBvciB0dXJuIG9mZiAoIk9mZiIpLg0KIw0KU2Vj UnVsZUVuZ2luZSBPbg0KDQojIERlZmluZSB3aGljaCBwYXJ0IG9mIHRoZSBIVFRQIHRyYW5zYWN0 aW9uIHRvIGluc3BlY3QuDQojDQojIEluc3BlY3RpbmcgcmVxdWVzdCBib2R5IChTZWNSZXF1ZXN0 Qm9keUFjY2Vzcykgc2hvdWxkIHByb2JhYmx5IGJlIGFsd2F5cyBzZXQNCiMgdG8gIm9uIi4gT25s eSB2ZXJ5IGhpZ2ggdm9sdW1lIHNpdGVzIHRoYXQgbmV2ZXIgdXNlIFBPU1QgcmVxdWVzdHMgbWln aHQgd2FudCANCiMgdG8gc2V0IGl0IHRvICJvZmYiIHRvIG9wdGltaXplIHBlcmZvcm1hbmNlLg0K Iw0KIyBJbnNwZWN0aW5nIHJlc3BvbnNlIGJvZHkgaXMgdXNlZnVsIGZvciBtb25pdG9yaW5nIGZv ciBpbmZvcm1hdGlvbiBsZWFrcywgDQojIG9yIGZvciBzaWducyBvZiBpbnRydXNpb24uIEhvd2V2 ZXIsIGl0IGRvZXMgcmVxdWlyZSBhbGwgcmVzcG9uc2VzIHRvIGJlIA0KIyBidWZmZXJlZCBpbiBt ZW1vcnkuIEZvciBtb3N0IHNpdGVzIHRoaXMgc2hvdWxkIG5vdCBiZSBhIHByb2JsZW0sIGJ1dCBz cGVjaWFsDQojIGNhcmUgbXVzdCBiZSB0YWtlbiB0byBhdm9pZCBidWZmZXJpbmcgZmlsZSBkb3du bG9hZHMgKHRocm91Z2gNCiMgTUlNRSB0eXBlIHNlbGVjdGlvbiwgYXMgc2hvd24gYmVsb3cpLg0K Iw0KIyBUT0RPIElmIHlvdSBkZWNpZGUgdG8gZW5hYmxlIG91dHB1dCBmaWx0ZXJpbmcgbWFrZSBz dXJlIHRvDQojICAgICAgcmV2aWV3IHRoZSBsaXN0IG9mIHNjYW5uZWQgTUlNRSB0eXBlcy4gSWYg cGFnZXMgb2YgdGhlIHR5cGVzIHNwZWNpZmllZCANCiMgICAgICBmb3Igb3V0Ym91bmQgaW5zcGVj dGlvbiBhcmUgc21hbGxlciB0aGFuIDUxMksgaW4geW91IGFwcGxpY2F0aW9uDQojICAgICAgKHdo aWNoIGlzIHVzdWFsbHkgdGhlIGNhc2UpIHlvdSBtYXkgcmVkdWNlIHRoZSBTZWNSZXNwb25zZUJv ZHlMaW1pdCANCiMgICAgICB0byBwcm90ZWN0IGZyb20gcG90ZW50aWFsIGRlbmlhbCBvZiBzZXJ2 aWNlIGF0dGFja3MuDQojDQpTZWNSZXF1ZXN0Qm9keUFjY2VzcyBPbg0KU2VjUmVzcG9uc2VCb2R5 QWNjZXNzIE9uDQpTZWNSZXNwb25zZUJvZHlNaW1lVHlwZSAobnVsbCkgdGV4dC9odG1sIHRleHQv cGxhaW4gdGV4dC94bWwNClNlY1Jlc3BvbnNlQm9keUxpbWl0IDUyNDI4OA0KDQoNCiMgV2hhdCB0 byBkbyB3aGVuIGFuIGVycm9yIGlzIGVuY291bnRlcmVkLg0KIw0KIyBUaGUgZGVmYXVsdCBpcyB0 byBsb2cgdGhlIGVycm9yIGFuZCBsZXQgdGhlIHJlcXVlc3QgZ28gdGhyb3VnaC4NCiMgVGhpcyBp cyBhIHJlYXNvbmFibGUgc2V0dGluZyB0byBzdGFydCB3aXRoIGJlY2F1c2UgeW91IGRvIG5vdA0K IyB3YW50IHRvIHJlamVjdCBsZWdpdGltYXRlIHJlcXVlc3RzIHdpdGggYW4gdW50dW5lZCBydWxl IHNldC4NCiMNCiMgSWYsIGFmdGVyIG1vbml0b3JpbmcgdGhlIHBlcmZvcm1hbmNlIG9mIHRoZSBy dWxlIHNldCBhZnRlciBhDQojIHN1ZmZpY2llbnQgcGVyaW9kLCB5b3UgZGV0ZXJtaW5lIHRoZSBy dWxlcyBuZXZlciAob3IgcmFyZWx5DQojIHRyaWdnZXIgb24gbGVnaXRpbWF0ZSByZXF1ZXN0cykg eW91IGNhbiBjaGFuZ2UgdG8gc29tZXRoaW5nDQojIGVsc2UsIHN1Y2ggYXMgImxvZyxkZW55LHN0 YXR1czo1MDAiLiBZb3UgY2FuIGFsc28gbGVhdmUgdGhlDQojIGRlZmF1bHQgc2V0dGluZyBoZXJl IGFzIGlzLCBidXQgdXNlIHBlciBydWxlIGFjdGlvbiBjb25maWd1cmF0aW9uDQojIHRvIG9ubHkg Y29uZmlndXJlIHNvbWUgcnVsZXMgdG8gcmVqZWN0IHJlcXVlc3RzLCBsZWF2aW5nIG1vc3QNCiMg b2YgdGhlbSB0byB3b3JrIGluIGRldGVjdGlvbiBtb2RlLg0KIw0KU2VjRGVmYXVsdEFjdGlvbiAi cGhhc2U6Mixsb2cscGFzcyxzdGF0dXM6NTAwIg0KI1NlY0RlZmF1bHRBY3Rpb24gInBoYXNlOjIs bG9nLGRlbnksc3RhdHVzOjUwMCINCg0KIyBTZXQgd2ViIHNlcnZlciBpZGVudGlmaWNhdGlvbiBz dHJpbmcNCiMNCiMgVE9ETyBJbiBjYXNlIHlvdSB1c2UgQXBhY2hlLCB5b3UgbWF5IHdhbnQgc3Bl Y2lmeSBhIHNpbXBsZSBzZXJ2ZXIgc2lnbmF0dXJlDQojICAgICAgaW5zdGVhZCBvZiB0aGUgZGV0 YWlsZWQgQXBhY2hlIGRlZmF1bHQgc2lnbmF0dXJlIHRoYXQgbGlzdCBtb3N0IG1vZHVsZXMNCiMg ICAgICB1c2VkIG9uIHRoZSBzcGVjaWZpYyBBcGFjaGUgZGVwbG95bWVudDoNCiMgICAgICAiQXBh Y2hlLzIuMi4wIChGZWRvcmEpIiAgIA0KIw0KU2VjU2VydmVyU2lnbmF0dXJlICJBcGFjaGUvMi4w LjU5IChPdXJTZXJ2ZXIgSFRUUFNlcnZlcikiDQoNCiMjIC0tIEZpbGUgdXBsb2FkcyBjb25maWd1 cmF0aW9uIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoj IFRlbXBvcmFyeSBmaWxlIHN0b3JhZ2UgcGF0aC4NCiMNCiMgVE9ETyBDaGFuZ2UgdGhlIHRlbXBv cmFyeSBmb2xkZXIgc2V0dGluZyB0byBhIHBhdGggd2hlcmUgb25seQ0KIyAgICAgIHRoZSB3ZWIg c2VydmVyIGhhcyBhY2Nlc3MuDQojDQojU2VjVXBsb2FkRGlyIC90bXANClNlY1VwbG9hZERpciBD Oi9hcGFjaGUvbG9ncy9tb2RTZWN1cml0eS91cGxvYWQNCg0KIyBXaGV0aGVyIG9yIG5vdCB0byBr ZWVwIHRoZSBzdG9yZWQgZmlsZXMuDQojDQojIEluIG1vc3QgY2FzZXMgeW91IGRvbid0IHdhbnQg dG8ga2VlcCB0aGUgdXBsb2FkZWQgZmlsZXMgKGVzcGVjaWFsbHkNCiMgd2hlbiB0aGVyZSBpcyBh IGxvdCBvZiB0aGVtKS4gSXQgbWF5IGJlIHVzZWZ1bCB0byBjaGFuZ2UgdGhlIHNldHRpbmcNCiMg dG8gIlJlbGV2YW50T25seSIsIGluIHdoaWNoIGNhc2UgdGhlIGZpbGVzIHVwbG9hZGVkIGluIHN1 c3BpY2lvdXMNCiMgcmVxdWVzdHMgd2lsbCBiZSBzdG9yZWQuDQojDQpTZWNVcGxvYWRLZWVwRmls ZXMgT2ZmDQoNCiMgSW5zcGVjdCB1cGxvYWRlZCBmaWxlcy4NCiMNCiMgVE9ETyBJZiB0aGVyZSBp cyBhIGRhbmdlciBvZiBhdHRhY2sgdGhyb3VnaCB1cGxvYWRlZCBmaWxlcyB0aGVuIGl0DQojICAg ICAgaXMgcG9zc2libGUgdG8gY29uZmlndXJlIGFuIGV4dGVybmFsIHNjcmlwdCB0byBpbnNwZWN0 IGVhY2ggZmlsZQ0KIyAgICAgIGJlZm9yZSBpdCBpcyBzZWVuIGJ5IHRoZSBhcHBsaWNhdGlvbi4g QW4gZXhhbXBsZSBzY3JpcHQgaXMNCiMgICAgICBpbmNsdWRlZCB3aXRoIE1vZFNlY3VyaXR5ICgv dXRpbC9tb2RzZWMtY2xhbXNjYW4ucGwpLg0KIw0KIyAgICAgIEluc3BlY3RpbmcgdXBsb2FkZWQg ZmlsZXMgaXMgZXNwZWNpYWxseSBpbXBvcnRhbnQgaW4gYSBob3N0aW5nLCAgDQojICAgICAgY29t bXVuaXR5IG9yIGJsb2dnaW5nIGVudmlyb25tZW50cyB3aGVyZSB1cGxvYWRpbmcgZmlsZXMgaXMg cGVybWl0dGVkLiANCiMNCiMgTk9URSB0aGUgdDpub25lIGFjdGlvbiBpcyByZXF1aXJlZCBpbiBv cmRlciBub3QgdG8gcHJvY2VzcyB0aGUgZmlsZXMgbmFtZXMgDQojICAgICAgcGFzc2VkIHRvIHRo ZSBzY3JpcHQgYmFzZWQgb24gcHJldmlvdXNseSBkZWZpbmVkIGFjdGlvbnMgaW4gYSANCiMgICAg ICBTZWNEZWZhdWx0QWN0aW9uIGRpcmVjdGl2ZS4NCiMNCiMgU2VjUnVsZSBGSUxFU19UTVBOQU1F UyAiQGluc3BlY3RGaWxlIC9vcHQvYXBhY2hlL2Jpbi9pbnNwZWN0X3NjcmlwdC5wbCIgXA0KIyAg ICAgICAidDpub25lIg0KDQojIyAtLSBMb2dnaW5nIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KIyBXaGV0aGVyIHRvIGxv ZyByZXF1ZXN0cyB0byB0aGUgZm9yZW5zaWMgbG9nLg0KIw0KIyBCeSBkZWZhdWx0LCBvbmx5IHJl cXVlc3RzIHRoYXQgdHJpZ2dlciBhIE1vZFNlY3VyaXR5IGV2ZW50cyAoYXMgZGV0ZWN0ZWQgDQoj IGJ5KSBvciBhIHNlcmVyIGVycm9yIGFyZSBsb2dnZWQgKCJSZWxldmFudE9ubHkiKS4gVGhpcyBp cyBhIHJlYXNvbmFibGUgDQojIHNldHRpbmcuIEZ1bGwgbG9nZ2luZyBjYW4gYmUgc2V0IGJ5IHVz aW5nICMgIm9uIi4gSWYgdGhlIHN5c3RlbSBpcyB1c2VkIA0KIyBmb3IgcHJvdGVjdGlvbiBvbmx5 IGFuZCBubyBsb2dnaW5nIGlzIGRlc2lyZWQgKG5vdCByZWNjb21lbmRlZCkgbG9nZ2luZyBjYW4g DQojIGJlIHR1cm5lZCBvZiB1c2luZyAib2ZmIg0KIw0KIyBOT1RFIEl0IGlzIGFsc28gcG9zc2li bGUgdG8gY29uZmlndXJlIGZvcmVuc2ljIGxvZ2dpbmcgb24gdGhlDQojICAgICAgcGVyIHJlcXVl c3QgYmFzaXMgdXNpbmcgdGhlICJhdWRpdGxvZyIgYW5kICJub2F1ZGl0bG9nIiBydWxlDQojICAg ICAgYWN0aW9ucy4NCiMNCiMgVE9ETyBUaGUgZGVmYXVsdCBydWxlIHNldCBsb2dzIHJlcXVlc3Rz IHRoYXQgZ2VuZXJhdGUgYSA0MDQgImZpbGUgbm90IGZvdW5kIg0KIyAgICAgIHJlc3BvbnNlLiBU aGVzZSBldmVudHMgYXJlIGludGVyZXN0aW5nLCBidXQgbWF5IGxvZyBhIGxvdCBvZiBpbmZvcm1h dGlvbi4NCiMgICAgICB5b3UgbWF5IGNvbnNpZGVyIHJlbW92aW5nIGl0IGJ5IHNldHRpbmcgU2Vj QXVkaXRMb2dSZWxldmFudFN0YXR1cw0KIyAgICAgIHRvICJeKD86NXw0XGRbXjRdKSIuDQojDQpT ZWNBdWRpdEVuZ2luZSBSZWxldmFudE9ubHkNCiNTZWNBdWRpdExvZ1JlbGV2YW50U3RhdHVzICJe KD86NXw0XGRbXjRdKSINClNlY0F1ZGl0TG9nUmVsZXZhbnRTdGF0dXMgIl5bNDVdIg0KDQojIExv ZyBmaWxlcyBzdHJ1Y3R1cmUNCiMNCiMgWW91IGNhbiBzZWxlY3QgdG8gbG9nIGFsbCBldmVudHMg dG8gYSBzaW5nbGUgbG9nIGZpbGUgKHNldCBTZWNBdWRpdExvZ1R5cGUgdG8gDQojICJTZXJpYWwi KSBvciB0byBsb2cgZWFjaCByZXF1ZXN0IHRvIGEgc2VwYXJhdGUgZmlsZSAoc2V0IGl0IHRvICJD b25jdXJyZW50IikuIA0KIyBUaGUgZm9ybWVyIGlzIHVzdWFsbHkgZWFzaWVyIHRvIHVzZSwgYnV0 IGlmIGZ1bGwgbG9nZ2luZyBpcyByZXF1aXJlZCBvciBpZiANCiMgdGhlIHByb3RlY3RlZCBzeXN0 ZW0gc3VwcG9ydHMgYSBsYXJnZSB0cmFuc2FjdGlvbiB2b2x1bWUgdGhlIGxhdGVyIG1heQ0KIyBi ZSBhIGJldHRlciBvcHRpb24uDQojDQojIFRPRE8gU2V0IHRoZSBTZWNBdWRpdExvZyAoZm9yICJT ZXJpYWwiIGxvZ2dpbmcpIG9yIFNlY0F1ZGl0TG9nU3RvcmFnZURpciAoZm9yDQojICAgICAgIkNv bmN1cnJlbnQiIGxvZ2dpbmcpLg0KIw0KIyBUT0RPIElmIHlvdSBjaGFuZ2UgZnJvbSAiU2VyaWFs IiB0byAiQ29uY3VycmVudCIgdW5jb21tZW50IHRoZSANCiMgICAgICBTZWNBdWRpdExvZ1N0b3Jh Z2VEaXIgZGlyZWN0aXZlIGFuZCBtYWtlIHN1cmUgdGhlIGRpcmVjb3J5IHNwZWNpZmllZCANCiMg ICAgICBleGlzdHMgYW5kIGhhcyB3cml0ZSBwZXJtaXNzaW9ucyBmb3IgdGhlIEFwYWNoZSB1c2Vy LiANCg0KI1NlY0F1ZGl0TG9nVHlwZSBTZXJpYWwNClNlY0F1ZGl0TG9nVHlwZSBDb25jdXJyZW50 DQojU2VjQXVkaXRMb2cgbG9ncy9tb2RzZWNfYXVkaXQubG9nDQpTZWNBdWRpdExvZyBDOi9hcGFj aGUvbG9ncy9tb2RTZWN1cml0eS9hdWRpdGxvZy9tb2RzZWNfYXVkaXQubG9nDQojU2VjQXVkaXRM b2cgInxDOi9hcGFjaGUvYmluL21vZHNlYy1hdWRpdGxvZy1jb2xsZWN0b3IucGwgQzovYXBhY2hl L2xvZ3MvbW9kU2VjdXJpdHkvYXVkaXQvIEM6L2FwYWNoZS9sb2dzL21vZFNlY3VyaXR5L2F1ZGl0 bG9nL2F1ZGl0LmxvZyINCiMgU2VjQXVkaXRMb2dTdG9yYWdlRGlyIGxvZ3MvbW9kc2VjX2F1ZGl0 DQpTZWNBdWRpdExvZ1N0b3JhZ2VEaXIgQzovYXBhY2hlL2xvZ3MvbW9kU2VjdXJpdHkvYXVkaXQN Cg0KIyBTZWxlY3Qgd2hhdCBwb3J0aW9ucyBvZiB0aGUgcmVxdWVzdCB0byBsb2cNCiMNCiMgTW9k aWZ5IHRoZSBzdHJpbmcgYnkgYWRkaW5nIGFueSBvZiB0aGUgbGV0dGVyIGJlbG93IHRvIGl0Og0K IyBBIC0gYXVkaXQgbG9nIGhlYWRlciAobWFuZGF0b3J5KQ0KIyBCIC0gcmVxdWVzdCBoZWFkZXJz DQojIEMgLSByZXF1ZXN0IGJvZHkgKHByZXNlbnQgb25seSBpZiB0aGUgcmVxdWVzdCBib2R5IGV4 aXN0cyBhbmQgTW9kU2VjdXJpdHkgaXMgDQojICAgICBjb25maWd1cmVkIHRvIGludGVyY2VwdCBp dCkNCiMgRSAtIGludGVybWVkaWFyeSByZXNwb25zZSBib2R5IChwcmVzZW50IG9ubHkgaWYgTW9k U2VjdXJpdHkgaXMgY29uZmlndXJlZCB0byANCiMgICAgIGludGVyY2VwdCByZXNwb25zZSBib2Rp ZXMsIGFuZCBpZiB0aGUgYXVkaXQgbG9nIGVuZ2luZSBpcyBjb25maWd1cmVkIHRvIA0KIyAgICAg cmVjb3JkIGl0KS4gSW50ZXJtZWRpYXJ5IHJlc3BvbnNlIGJvZHkgaXMgdGhlIHNhbWUgYXMgdGhl IGFjdHVhbCByZXNwb25zZSANCiMgICAgIGJvZHkgdW5sZXNzIE1vZFNlY3VyaXR5IGludGVyY2Vw dHMgdGhlIGludGVybWVkaWFyeSByZXNwb25zZSBib2R5LCBpbiANCiMgICAgIHdoaWNoIGNhc2Ug dGhlIGFjdHVhbCByZXNwb25zZSBib2R5IHdpbGwgY29udGFpbiB0aGUgZXJyb3IgbWVzc2FnZSAN CiMgICAgIChlaXRoZXIgdGhlIEFwYWNoZSBkZWZhdWx0IGVycm9yIG1lc3NhZ2UsIG9yIHRoZSBF cnJvckRvY3VtZW50IHBhZ2UpLg0KIyBGIC0gZmluYWwgcmVzcG9uc2UgaGVhZGVycyAoZXhjbHVk aW5nIHRoZSBEYXRlIGFuZCBTZXJ2ZXIgaGVhZGVycywgd2hpY2ggYXJlIA0KIyAgICAgYWx3YXlz IGFkZGVkIGJ5IEFwYWNoZSBpbiB0aGUgbGF0ZSBzdGFnZSBvZiBjb250ZW50IGRlbGl2ZXJ5KS4N CiMgSCAtIGF1ZGl0IGxvZyB0cmFpbGVyDQojIEkgLSBUaGlzIHBhcnQgaXMgYSByZXBsYWNlbWVu dCBmb3IgcGFydCBDLiBJdCB3aWxsIGxvZyB0aGUgc2FtZSBkYXRhIGFzIEMgaW4gDQojICAgICBh bGwgY2FzZXMgZXhjZXB0IHdoZW4gbXVsdGlwYXJ0L2Zvcm0tZGF0YSBlbmNvZGluZyBpbiB1c2Vk LiBJbiB0aGlzIGNhc2UgDQojICAgICBpdCB3aWxsIGxvZyBhIGZha2UgYXBwbGljYXRpb24veC13 d3ctZm9ybS11cmxlbmNvZGVkIGJvZHkgdGhhdCBjb250YWlucyANCiMgICAgIHRoZSBpbmZvcm1h dGlvbiBhYm91dCBwYXJhbWV0ZXJzIGJ1dCBub3QgYWJvdXQgdGhlIGZpbGVzLiBUaGlzIGlzIGhh bmR5IA0KIyAgICAgaWYgeW91IGRvbid0IHdhbnQgdG8gaGF2ZSAob2Z0ZW4gbGFyZ2UpIGZpbGVz IHN0b3JlZCBpbiB5b3VyIGF1ZGl0IGxvZ3MuDQojIFogLSBmaW5hbCBib3VuZGFyeSwgc2lnbmlm aWVzIHRoZSBlbmQgb2YgdGhlIGVudHJ5IChtYW5kYXRvcnkpDQoNCiNTZWNBdWRpdExvZ1BhcnRz ICJBQklGSFoiDQpTZWNBdWRpdExvZ1BhcnRzICJBQkNERUZHSFoiDQoNCiMgQ3JlYXRlIGEgc2Vw YXJhdGUgbG9nIHRvIG1vbml0b3IgcGVyZm9ybWFuY2UuDQojDQojIFRPRE8gUGVyZm9ybWFuY2Ug bW9uaXRvcmluZyBvbmx5IHdvcmtzIHdpdGggQXBhY2hlIDIueC4gWW91IG5lZWQNCiMgICAgICB0 byBhZGQgbW9kX3VuaXF1ZV9pZCBhbmQgbW9kX2xvZ2lvIHRvIHlvdXIgY29uZmlndXJhdGlvbi4g VGhlbg0KIyAgICAgIHVuY29tbWVudCB0aGUgZm9sbG93aW5nIHR3byBsaW5lcy4NCiMNCiMgTG9n Rm9ybWF0ICIlViAlaCAldCAle1VOSVFVRV9JRH1lIFwiJXJcIiAlPnMgJVggfCAlSSAlTyB8ICU8 e21vZF9zZWN1cml0eS10aW1lMX1uICU8e21vZF9zZWN1cml0eS10aW1lMn1uICU8e21vZF9zZWN1 cml0eS10aW1lM31uICVEIiBtcGVyZm9ybWFuY2UNCiMgQ3VzdG9tTG9nIGxvZ3MvbW9kc2VjX3Bl cmZvcm1hbmNlLmxvZyBtcGVyZm9ybWFuY2UNCg0KIyBDdXN0b20gYXBwbGljYXRpb24gYWNjZXNz IGxvZy4NCiMNCiMgVE9ETyBZb3Ugc2hvdWxkIGNvbnNpZGVyIGNyZWF0aW5nIGEgY3VzdG9tIGFj Y2VzcyBsb2cuIEl0IGNvdWxkIGNvbnRhaW4NCiMgICAgICB0aGUgcGVyZm9ybWFuY2UgbWV0cmlj cyBmcm9tIGFib3ZlLCBidXQgc2hvdWxkIGFsc28gcmVjb3JkIHRoZQ0KIyAgICAgIHNlc3Npb24g SUQgZm9yIGV2ZXJ5IHJlcXVlc3QuIFRoYXQgd291bGQgbWFrZSBpdCBwb3NzaWJsZSB0bw0KIyAg ICAgIGxpc3QgYWxsIHJlcXVlc3RzIHBlcmZvcm1lZCBhcyBwYXJ0IG9mIGEgc2Vzc2lvbi4NCiMN CiMgICAgICBPbmUgY3VzdG9tIGxvZyBzaG91bGQgYmUgdXNlZCBwZXIgYXBwbGljYXRpb24gYnV0 IGlmIHlvdSB3YW50DQojICAgICAgbXVsdGlwbGUgYXBwbGljYXRpb25zIHRvIHNoYXJlIG9uZSBs b2cgZmlsZSBtYWtlIHN1cmUgZWFjaA0KIyAgICAgIGxpbmUgaW5jbHVkZXMgYSB1bmlxdWUgYXBw bGljYXRpb24gSUQgKHVubGVzcyB0aGUgaG9zdG5hbWUgaXMNCiMgICAgICBzdWZmaWNpZW50IGZv ciBkaWZmZXJlbnRpYXRpb24pLg0KDQojIyAtLSBUdW5pbmcgYW5kIGRlYnVnZ2luZw0KDQojIFRo aXMgc2VjdGlvbiBpbmNsdWRlIHR1bmluZyBhbmQgZGVidWdnaW5nIGRpcmVjdGl2ZXMgdGhhdCB1 c3VhbGx5IHJlcXVpcmUgbm8NCiMgbW9kaWZpY2F0aW9ucyB1bmxlc3MgDQoNCiANCiMgUGFyYW1l dGVycyBzZXBhcmF0b3INCiMNCiMgU3BlY2lmaWVzIHdoaWNoIGNoYXJhY3RlciB0byB1c2UgYXMg c2VwYXJhdG9yIGZvciANCiMgYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkIGNvbnRl bnQuIA0KIyBEZWZhdWx0cyB0byAiJiIuIEFwcGxpY2F0aW9ucyBhcmUgc29tZXRpbWVzICh2ZXJ5 IHJhcmVseSkgd3JpdHRlbiB0byB1c2UgDQojIGEgc2VtaWNvbG9uICgiOyIpLg0KIw0KIyBOT1RF IENoYW5naW5nIHRoZSB2YWx1ZSBmb3IgdGhpcyBkaXJlY3RpdmUgaGFzIHNpZ25pZmljYW50IGlu Zmx1ZW5jZSBvbiBob3cNCiMgICAgICBNb2RTZWN1cml0eSB3b3Jrcy4gTWFrZSB0aGUgY2hhbmdl IG9ubHkgaWYgeW91IGFyZSBhYnNvbHV0ZWx5IHN1cmUgaXQNCiMgICAgICBpcyByZXF1aXJlZC4N ClNlY0FyZ3VtZW50U2VwYXJhdG9yICImIiANCg0KDQojIFNlbGVjdHMgdGhlIGNvb2tpZSBmb3Jt YXQgdGhhdCB3aWxsIGJlIHVzZWQgaW4gdGhlIGN1cnJlbnQgY29uZmlndXJhdGlvbiANCiMgY29u dGV4dC4gDQojDQojIFBvc3NpYmxlIHZhbHVlcyBhcmU6DQojIDAgLSB1c2UgdmVyc2lvbiAwIChO ZXRzY2FwZSkgY29va2llcy4gVGhpcyBpcyB3aGF0IG1vc3QgYXBwbGljYXRpb25zIHVzZS4gDQoj ICAgICBJdCBpcyB0aGUgZGVmYXVsdCB2YWx1ZS4NCiMgMSAtIHVzZSB2ZXJzaW9uIDEgY29va2ll cy4NCg0KU2VjQ29va2llRm9ybWF0IDANCg0KIyBNYXhpbXVtIHNpemUgb2YgdGhlIHJlcXVlc3Qg Ym9keSB0byBrZWVwIGluIG1lbW9yeQ0KIyANCiMgQSBoaWdoZXIgdmFsdWUgcmVxdWlyZXMgbW9y ZSBzZXJ2ZXIgbWVtb3J5IHdoaWxlIGEgbG93ZXIgbnVtYmVyIHdvdWxkIHNsb3cNCiMgdGhlIHNl cnZlciBkdWUgdG8gYWRkaXRpb25hbCBkaXNrIGFjY2Vzcy4gQnkgZGVmYXVsdCB0aGUgbGltaXQg aXMgMTI4IEtCOg0KU2VjUmVxdWVzdEJvZHlJbk1lbW9yeUxpbWl0IDEzMTA3Mg0KDQoNCiMgV2hl dGhlciB0byBzZW5kIE1vZFNlY3VyaXR5IG1lc3NhZ2VzIHRvIGEgc2VwYXJhdGUgZGVidWcgbG9n Lg0KIw0KIyBEZWJ1ZyBtZXNzYWdlcyBhcmUgdmVyeSB1c2VmdWwgZm9yLCB3ZWxsLCBkZWJ1Z2dp bmcuIFRoZSBkZWZhdWx0DQojIHNldHRpbmcgaGVyZSBjb3BpZXMgKHRoZXkgYWx3YXlzIGFwcGVh ciBpbiB0aGUgQXBhY2hlIGVycm9yIGxvZykNCiMgb25seSB0aGUgbW9zdCBpbXBvcnRhbnQgbWVz c2FnZXMgKGVycm9ycyBhbmQgd2FybmluZ3MpLg0KIw0KIyBOT1RFIERlYnVnIGxvZ2dpbmcgaXMg Z2VuZXJhbGx5IHZlcnkgc2xvdy4gWW91IHNob3VsZCBuZXZlcg0KIyAgICAgIHVzZSB2YWx1ZXMg Z3JlYXRlciB0aGFuICIzIiBpbiBwcm9kdWN0aW9uLg0KIw0KI1NlY0RlYnVnTG9nICAgICAgICAg ICAgIGxvZ3MvbW9kc2VjX2RlYnVnLmxvZw0KU2VjRGVidWdMb2cgICAgICAgICAgICAgQzovYXBh Y2hlL2xvZ3MvbW9kU2VjdXJpdHkvZGVidWcvbW9kc2VjX2RlYnVnLmxvZw0KI1NlY0RlYnVnTG9n TGV2ZWwgICAgICAgIDMNClNlY0RlYnVnTG9nTGV2ZWwgICAgICAgIDMNCg0KIyBQYXRoIHdoZXJl IHBlcnNpc3RlbnQgZGF0YSAoZS5nLiBJUCBhZGRyZXNzIGRhdGEsIHNlc3Npb24gZGF0YSwgZXRj KSBpcyB0bw0KIyBiZSBzdG9yZWQuIE11c3QgYmUgd3JpdGFibGUgYnkgdGhlIHdlYiBzZXJ2ZXIg dXNlci4NCiMNCiMgVE9ETyBJdCBpcyBhZHZpc2FibGUgdG8gY3JlYXRlIGEgZGlyZWN0b3J5IHN0 cnVjdHVyZSBmb3IgTW9kU2VjdXJpdHkgc3VjaCBhcw0KIyAgICAgIC92YXIvbG9nL21zYSBhbmQg Y3JlYXRlIHN1YiBkaXJlY3RvcmllcyBmb3IgU2VjRGF0YURpciwgU2VjVG1wRGlyLA0KIyAgICAg IFNlY1VwbG9hZERpciwgU2VjQXVkaXRMb2cgYW5kIFNlY0F1ZGl0TG9nU3RvcmFnZURpcg0KIyAg ICAgIHVuZGVybmVhdGggaXQgYW5kIHNldCB0aGUgcGVybWlzc2lvbiBmb3IgcmVhZCBhbmQgd3Jp dGUgb25seSBieSB0aGUNCiMgICAgICBBcGFjaGUgdXNlci4NCg0KI1NlY0RhdGFEaXIgL3RtcA0K U2VjRGF0YURpciBDOi9hcGFjaGUvbG9ncy9tb2RTZWN1cml0eS9kYXRhDQoNCiMgQ29uZmlndXJl cyB0aGUgZGlyZWN0b3J5IHdoZXJlIHRlbXBvcmFyeSBmaWxlcyB3aWxsIGJlIGNyZWF0ZWQuDQoj U2VjVG1wRGlyIC90bXANClNlY1RtcERpciBDOi9hcGFjaGUvbG9ncy9tb2RTZWN1cml0eS90bXAN Cg0KIyBMb2FkZXMgdGhlIHZhcmlhYmxlIGNvbGxlY3Rpb24gcmVsYXRpbmcgdG8gdGhlIHJlcXVl c3RlZCByZXNvdXJjZQ0KIyBOT1RFOiBXZSB3aWxsIG5vdCBpbml0aWF0ZSBhIGNvbGxlY3Rpb24g aWYgdGhlcmUgd2FzIGFuIGVycm9yIChUbyBwcmV2ZW50IG92ZXJsb2FkaW5nKQ0KU2VjUnVsZSBS RVNQT05TRV9TVEFUVVMgIiFeKD86MzBbMTJdfFs0NV1cZFxkKSQiICJwaGFzZTozLHBhc3Msbm9s b2csaW5pdGNvbDpyZXNvdXJjZT0le1JFUVVFU1RfRklMRU5BTUV9Ig== |
From: Ofer S. <OferS@Breach.com> - 2007-06-19 16:07:42
|
The duplicate ID is a bug in the Core Rule Set that was fixed in the current (stable) release =20 ~ Ofer =20 From: mod...@li... [mailto:mod...@li...] On Behalf Of Gonen Radai Sent: Tuesday, June 19, 2007 3:40 PM To: mod...@li... Subject: [mod-security-users] exclude rule and log =20 Hi,=20 I'm running modsecurity2 The core rule 960015 is configured in the following conf files: modsecurity_crs_20_protocol_violations.conf modsecurity_crs_21_protocol_anomalies.conf I don't want to log requests that match the rule on a specific url, for example: http://domain.com/index.html so I added the following SecRuleRemoveById to my VirtualHost: <VirtualHost 123.123.123.123:80> Servername domain.com ... <Files index.html> SecRuleRemoveById 960015 </Files> </VirtualHost> =20 But I still get log entries regarding that rule on that specific http://domain.com/index.html Changing it to: SecRuleRemoveById 960015 "allow,phase:1,nolog" Also didn't stop the logging. What do I miss ? --=20 If you can't read my mail, try changing encoding to UTF-8. Gonen. |
From: Gonen R. <go...@gm...> - 2007-06-19 13:01:04
|
Hi, I'm running modsecurity2 The core rule 960015 is configured in the following conf files: modsecurity_crs_20_protocol_violations.conf modsecurity_crs_21_protocol_anomalies.conf I don't want to log requests that match the rule on a specific url, for example: http://domain.com/index.html so I added the following SecRuleRemoveById to my VirtualHost: <VirtualHost 123.123.123.123:80> Servername domain.com ... <Files index.html> SecRuleRemoveById 960015 </Files> </VirtualHost> But I still get log entries regarding that rule on that specific http://domain.com/index.html Changing it to: SecRuleRemoveById 960015 "allow,phase:1,nolog" Also didn't stop the logging. What do I miss ? If you can't read my mail, try changing encoding to UTF-8. Gonen. Christian Folini wrote: >> <pre class="moz-signature" cols="72">-- >> If you can't read my mail, try changing encoding to UTF-8. >> > > It would help, if you would send the ascii/txt version of your > message too. There was only a html encoding in your message. > My mailer does not read html very well. Or rather, he displays > it natively and there were a lot of in that config > example of yours... > > Please reconfigure your mail software. > > regs, > > Christian > > > |
From: Gonen R. <go...@gm...> - 2007-06-19 12:40:20
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body dir="ltr" bgcolor="#ffffff" text="#000000"> Hi, <p style="margin-bottom: 0cm; margin-top: 0pt;"><br> I'm running modsecurity2<br> The core rule 960015 is configured in the following conf files:<br> modsecurity_crs_20_protocol_violations.conf<br> modsecurity_crs_21_protocol_anomalies.conf<br> <br> I don't want to log requests that match the rule on a specific url,<br> for example:<br> <a class="moz-txt-link-freetext" href="http://domain.com/index.html">http://domain.com/index.html</a><br> <br> so I added the following SecRuleRemoveById to my VirtualHost:<br> <br> <VirtualHost 123.123.123.123:80><br> Servername domain.com<br> ...<br> <Files index.html><br> SecRuleRemoveById 960015<br> </Files><br> </VirtualHost> <br> <br> But I still get log entries regarding that rule on that specific <a class="moz-txt-link-freetext" href="http://domain.com/index.html">http://domain.com/index.html</a><br> Changing it to:<br> SecRuleRemoveById 960015 "allow,phase:1,nolog"<br> <br> Also didn't stop the logging.<br> What do I miss ?<br> </p> <br> <pre class="moz-signature" cols="72">-- If you can't read my mail, try changing encoding to UTF-8. Gonen. </pre> </body> </html> |
From: Ofer S. <OferS@Breach.com> - 2007-06-19 09:12:57
|
Added it to the feature requests =20 ~ Ofer =20 From: Marc Stern [mailto:mar...@ad...]=20 Sent: Tuesday, June 19, 2007 9:58 AM To: Ofer Shezaf Cc: Christian Bockermann; Mod Security Subject: Re: [mod-security-users] Rules manageability =20 Yes, that's my question ;-) You seem to be quite positive about that, so I feel confident ... Marc Ofer Shezaf wrote:=20 Do you mean to offer the @contained operator for the a coming version? I think it is the only thing missing to make the method below work.=20 =20 ~ Ofer=20 =20 From: Marc Stern [mailto:mar...@ad...]=20 Sent: Monday, June 18, 2007 10:38 AM To: Ofer Shezaf Cc: Christian Bockermann; Mod Security Subject: Re: [mod-security-users] Rules manageability=20 =20 Here is one way to easily handle order: I use a separate conf file for security (pointing to other ones) - say "security.conf". I use a separate conf file for all proxy path handling - say "proxy.conf". The trick is to include "security.conf" *before* "proxy.conf", and have the rule inside a location, like:=20 * proxy.conf * <Location "/webdav"> ... SecAction "setvar:rx.allowed_method=3D'%{TX.ALLOWED_METHODS},PUT,DELETE,...'" phase:2 ... </Location> * security.conf * SecAction "setvar:rx.allowed_method=3D'GET,POST,HEAD',%{TX.ALLOWED_METHODS}" <Location "/"> SecRule REQUEST_METHOD "!@contained %{TX.ALLOWED_METHODS}" <mailto:%21@contained%25%7bTX.ALLOWED_METHODS%7d> phase:2 </Location>=20 Another solution is indeed to use:=20 * proxy.conf * SecRule REQUEST_FILENAME "/webdav" "phase:1,pass,nolog,setvar:tx.allowed_methods=3D...." * security.conf * SecAction "setvar:rx.allowed_method=3D'GET,POST,HEAD',%{TX.ALLOWED_METHODS}" SecRule REQUEST_METHOD "!@contained %{TX.ALLOWED_METHODS}" <mailto:%21@contained%25%7bTX.ALLOWED_METHODS%7d> phase:1=20 This one is better regarding security, as we can use it in phase 1. It may be a bit less readable, especially if you already have a big location with a lot of directive, so this is really a matter of personal style I guess. Anyway, both solutions would work. Ofer, could you propose this as an enhancement for (a) next version ? Thanks Marc Ofer Shezaf wrote:=20 =20 Christian wrote: =20 =20 Interestingly enough we are getting closer to your request: =20 =20 - We have request parameters - the tx collection. =20 - We have variable substitution in rules - the new non regexp =20 operators =20 such as @contains or @streq accept variable substitution in their =20 operand. =20 - We have variable substitution in actions so you can modify =20 =20 So you could maintain a tx variable containing your condition, =20 modify it =20 in a directory scope and use a single rule to test against the =20 =20 current =20 =20 value of the condition variable. =20 =20 Why aren't we there: =20 - The only thing you can do to your condition variable is add to it =20 =20 or =20 =20 replace it. No fancy string manipulation. =20 - The current operators that allow variables are pretty limited and =20 are =20 ill-adjusted to such logic as they assume the operand is part of the =20 input and not visa-versa. =20 =20 But let's assume that we would have the operator @contained =20 (opposite of =20 @contains). You could do something like that: =20 =20 SecAction "setvar:rx.allowed_method=3D'GET,POST,HEAD'" =20 =20 <Location "/webdav"> =20 SecAction =20 =09 "setvar:rx.allowed_method=3D'%{TX.ALLOWED_METHODS},PUT,DELETE.....'" =20 </Location> =20 =20 SecRule REQUEST_METHOD "!@contained %{TX.ALLOWED_METHODS}" <mailto:%21@contained%25%7bTX.ALLOWED_METHODS%7d> =20 One issue I'm not sure about is order of execution. Details... =20 =20 =20 Having looked at that I have some questions/additions: =20 =20 - setvar:rx.allowed... is meant to be setvar:tx.allowed... ? I do ask this, because using tables is sometimes a bit tricky. =20 =20 =20 =20 Yes, tx of-course. This is not a production code and as you pointed =20 later, not very useful. =20 =20 =20 - All this has to be done with phase:2 set as the =20 =20 Location-directives =20 =20 are not applied before phase-2. =20 =20 =20 True. Though sub-sectioning can be done also using a rule: =20 =20 SecRule REQUEST_FILENAME "/webdav" =20 "pass,nolog,setvar:tx.allowed_methods=3D...." =20 =20 =20 - According to Marc's e-mail I do not see the benefit of this =20 complex =20 =20 way of specifying the allowed methods for a sub-context. Just =20 =20 using =20 =20 SecRemoveRuleById and writing a new rule seems somewhat more readable =20 and cleaner to me: =20 =20 SecRule REQUEST_METHOD !^(GET|POST|HEAD)$ "phase:2,id:123" =20 =20 <Location "/webdav"> =20 SecRuleInheritance On =20 SecRuleRemoveById 123 =20 =20 SecRule REQUEST_METHOD !^(GET|POST|PUT|DELETE)$ "phase:2" =20 </Location> =20 =20 =20 The problem Marc raised, and I find very true, is that using =20 SecRemoveById completely eliminates the original, so updates to the =20 original are not preserved. Using TX, if a new method is added to the =20 original (GET|POST|HEAD), it would be propagated to the sub context. =20 Using SecRuleRemoveByID is would not. =20 =20 Saying that, my code was just a demonstration of a potential roadmap. I even used a non-existing operator. Today, only your way will work. =20 =20 =20 =20 The complex tx-table setup (Don't get me wrong - I really like =20 ModSecurity's tables and use them a lot) does not help on forgetting =20 "replacement-rules" - or did I miss anything? =20 =20 Using chained rules you could also have your specialized rules in =20 one part of your conf-file - which might help on the "forgetting"- =20 thing: =20 =20 # specialized rule for webdav-app/location =20 # =20 SecRule REQUEST_URI ^/webdav "phase:2,chain,skip:1,id:123" =20 SecRule ARGS "@validateByteRange 5,9,10,13,32-126" =20 =20 # general rule for all other webapps =20 # =20 SecRule ARGS "@validateByteRange 9, 10,13,32-126" "phase:2,id:123" =20 =20 As the first two lines are glued together by "chain", this snippet =20 defines exactly 2 rules of which the last one is skipped in case of =20 the uri starting with /webdav =20 =20 These a just my two cent. I think this is somewhat related to "style" =20 on writing rulesets and thus a quite nice topic for discussing. Perhaps there are other advices on how to handle that ;-) =20 =20 =20 =20 I hope I made it clear where I think it is not style anymore: when you =20 copy the original rule when making an exception, you lose any future =20 changes to the original rule. Ideally exceptions could be a delta from =20 the existing rule and not copy it. We are not there yet. =20 =20 Another upcoming addition to ModSecurity engine that will help in this =20 would be a RemoveByID action. It will enable the use other request parts such as source IP or a parameter value as exception conditions. Since =20 SecRemoveRuleByID is currently a directive it is limited to the global =20 scope or to Apache location scopes. =20 =20 ~ Ofer =20 =20 =20 =20 -----Original Message----- =20 From: mod...@li... [mailto:mod- =20 sec...@li...] On Behalf Of Marc =20 =20 Stern =20 =20 Sent: Friday, June 15, 2007 12:43 PM =20 To: Mod Security =20 Subject: [mod-security-users] Rules manageability =20 =20 I'm quite prolix today ;-) =20 =20 I'm trying to find a better way to manage some rules, depending on =20 the =20 location. This is very important in the context of a reverse proxy =20 serving several applications. =20 =20 Concrete example (just one between others): I'm blocking, by =20 =20 default, =20 =20 all characters outside some ranges =20 SecRule ARGS "@validateByteRange 9, 10, 13, 32-126" =20 phase:2,id:xxx =20 =20 In case I have an application using another character (say 5), the =20 =20 only =20 =20 ways I found to have it working are =20 - adding the character for all applications (easy but insecure =20 approach) =20 - inside the location, remove the rule, and create a brand new one =20 Although the second approach is better regarding security, it is =20 quite =20 difficult to manage; if I ever want to modify the main rule (xxx), =20 =20 I =20 =20 do =20 =20 not have to forget to change all "replacement" rules for the =20 different =20 locations. =20 =20 Is there a way, maybe with the new features in the development =20 =20 version, =20 =20 to do something like =20 - define a variable containing a range (or the complete rule =20 =20 string =20 =20 like "@validateByteRange 9, 10, 13, 32-126") =20 - inside each location, extend this variable with additional data =20 - check the rule against the variable =20 =20 Any other mechanism is obviously welcome. =20 =20 Marc =20 =20 =20 =20 =20 =20 |
From: Marc S. <mar...@ad...> - 2007-06-19 06:57:51
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Yes, that's my question ;-)<br> You seem to be quite positive about that, so I feel confident ...<br> <br> Marc<br> <br> Ofer Shezaf wrote: <blockquote cite="mid:50E...@mi..." type="cite"> <meta http-equiv="Context-Type" content="text/html; charset=us-ascii"> <div> <p><span>Do you mean to offer the @contained operator for the a coming version? I think it is the only thing missing to make the method below work. </span></p> <p><span> </span></p> <p><span>~ Ofer </span></p> <p><span> </span></p> <div> <div> <div> <p><b><span>From:</span></b><span> Marc Stern [<a class="moz-txt-link-freetext" href="mailto:mar...@ad...">mailto:mar...@ad...</a>] <br> <b>Sent:</b> Monday, June 18, 2007 10:38 AM<br> <b>To:</b> Ofer Shezaf<br> <b>Cc:</b> Christian Bockermann; Mod Security<br> <b>Subject:</b> Re: [mod-security-users] Rules manageability </span></p> </div> </div> <p> </p> <p>Here is one way to easily handle order:<br> <br> I use a separate conf file for security (pointing to other ones) - say "security.conf".<br> I use a separate conf file for all proxy path handling - say "proxy.conf".<br> The trick is to include "security.conf" *before* "proxy.conf", and have the rule inside a location, like: </p> <p>* proxy.conf *<br> <Location "/webdav"><br> ...<br> SecAction "setvar:rx.allowed_method='%{TX.ALLOWED_METHODS},PUT,DELETE,...'" phase:2<br> ...<br> </Location><br> <br> * security.conf *<br> SecAction "setvar:rx.allowed_method='GET,POST,HEAD',%{TX.ALLOWED_METHODS}"<br> <Location "/"><br> SecRule REQUEST_METHOD <a moz-do-not-send="true" href="mailto:%21@contained%25%7bTX.ALLOWED_METHODS%7d">"!@contained %{TX.ALLOWED_METHODS}"</a> phase:2<br> </Location> </p> <p><br> Another solution is indeed to use: </p> <p>* proxy.conf *<br> SecRule REQUEST_FILENAME "/webdav" "phase:1,pass,nolog,setvar:tx.allowed_methods=...."<br> <br> * security.conf *<br> SecAction "setvar:rx.allowed_method='GET,POST,HEAD',%{TX.ALLOWED_METHODS}"<br> SecRule REQUEST_METHOD <a moz-do-not-send="true" href="mailto:%21@contained%25%7bTX.ALLOWED_METHODS%7d">"!@contained %{TX.ALLOWED_METHODS}"</a> phase:1 </p> <p>This one is better regarding security, as we can use it in phase 1.<br> It may be a bit less readable, especially if you already have a big location with a lot of directive, so this is really a matter of personal style I guess. Anyway, both solutions would work.<br> <br> Ofer, could you propose this as an enhancement for (a) next version ?<br> <br> Thanks<br> <br> Marc<br> <br> <br> Ofer Shezaf wrote: </p> <pre> </pre> <pre>Christian wrote: </pre> <pre> </pre> <blockquote> <blockquote> <pre>Interestingly enough we are getting closer to your request: </pre> <pre> </pre> <pre>- We have request parameters - the tx collection. </pre> <pre>- We have variable substitution in rules - the new non regexp </pre> <pre>operators </pre> <pre>such as @contains or @streq accept variable substitution in their </pre> <pre>operand. </pre> <pre>- We have variable substitution in actions so you can modify </pre> <pre> </pre> <pre>So you could maintain a tx variable containing your condition, </pre> <pre>modify it </pre> <pre>in a directory scope and use a single rule to test against the </pre> <pre> </pre> </blockquote> <pre>current </pre> <pre> </pre> <blockquote> <pre>value of the condition variable. </pre> <pre> </pre> <pre>Why aren't we there: </pre> <pre>- The only thing you can do to your condition variable is add to it </pre> <pre> </pre> </blockquote> <pre>or </pre> <pre> </pre> <blockquote> <pre>replace it. No fancy string manipulation. </pre> <pre>- The current operators that allow variables are pretty limited and </pre> <pre>are </pre> <pre>ill-adjusted to such logic as they assume the operand is part of the </pre> <pre>input and not visa-versa. </pre> <pre> </pre> <pre>But let's assume that we would have the operator @contained </pre> <pre>(opposite of </pre> <pre>@contains). You could do something like that: </pre> <pre> </pre> <pre>SecAction "setvar:rx.allowed_method='GET,POST,HEAD'" </pre> <pre> </pre> <pre><Location "/webdav"> </pre> <pre> SecAction </pre> <pre>"setvar:rx.allowed_method='%{TX.ALLOWED_METHODS},PUT,DELETE.....'" </pre> <pre></Location> </pre> <pre> </pre> <pre>SecRule REQUEST_METHOD <a moz-do-not-send="true" href="mailto:%21@contained%25%7bTX.ALLOWED_METHODS%7d">"!@contained %{TX.ALLOWED_METHODS}"</a> </pre> <pre> </pre> <pre>One issue I'm not sure about is order of execution. Details... </pre> <pre> </pre> </blockquote> <pre> </pre> <pre>Having looked at that I have some questions/additions: </pre> <pre> </pre> <pre> - setvar:rx.allowed... is meant to be setvar:tx.allowed... ? </pre> <pre> I do ask this, because using tables is sometimes a bit tricky. </pre> <pre> </pre> <pre> </pre> </blockquote> <pre> </pre> <pre>Yes, tx of-course. This is not a production code and as you pointed </pre> <pre>later, not very useful. </pre> <pre> </pre> <pre> </pre> <blockquote> <pre> - All this has to be done with phase:2 set as the </pre> <pre> </pre> </blockquote> <pre>Location-directives </pre> <pre> </pre> <blockquote> <pre> are not applied before phase-2. </pre> <pre> </pre> </blockquote> <pre> </pre> <pre>True. Though sub-sectioning can be done also using a rule: </pre> <pre> </pre> <pre>SecRule REQUEST_FILENAME "/webdav" </pre> <pre>"pass,nolog,setvar:tx.allowed_methods=...." </pre> <pre> </pre> <pre> </pre> <blockquote> <pre> - According to Marc's e-mail I do not see the benefit of this </pre> <pre> </pre> </blockquote> <pre>complex </pre> <pre> </pre> <blockquote> <pre> way of specifying the allowed methods for a sub-context. Just </pre> <pre> </pre> </blockquote> <pre>using </pre> <pre> </pre> <blockquote> <pre> SecRemoveRuleById and writing a new rule seems somewhat more </pre> <pre>readable </pre> <pre> and cleaner to me: </pre> <pre> </pre> <pre>SecRule REQUEST_METHOD !^(GET|POST|HEAD)$ "phase:2,id:123" </pre> <pre> </pre> <pre><Location "/webdav"> </pre> <pre> SecRuleInheritance On </pre> <pre> SecRuleRemoveById 123 </pre> <pre> </pre> <pre> SecRule REQUEST_METHOD !^(GET|POST|PUT|DELETE)$ "phase:2" </pre> <pre></Location> </pre> <pre> </pre> </blockquote> <pre> </pre> <pre>The problem Marc raised, and I find very true, is that using </pre> <pre>SecRemoveById completely eliminates the original, so updates to the </pre> <pre>original are not preserved. Using TX, if a new method is added to the </pre> <pre>original (GET|POST|HEAD), it would be propagated to the sub context. </pre> <pre>Using SecRuleRemoveByID is would not. </pre> <pre> </pre> <pre>Saying that, my code was just a demonstration of a potential roadmap. I </pre> <pre>even used a non-existing operator. Today, only your way will work. </pre> <pre> </pre> <pre> </pre> <blockquote> <pre> </pre> <pre>The complex tx-table setup (Don't get me wrong - I really like </pre> <pre>ModSecurity's tables and use them a lot) does not help on forgetting </pre> <pre>"replacement-rules" - or did I miss anything? </pre> <pre> </pre> <pre>Using chained rules you could also have your specialized rules in </pre> <pre>one part of your conf-file - which might help on the "forgetting"- </pre> <pre>thing: </pre> <pre> </pre> <pre> # specialized rule for webdav-app/location </pre> <pre> # </pre> <pre> SecRule REQUEST_URI ^/webdav "phase:2,chain,skip:1,id:123" </pre> <pre> SecRule ARGS "@validateByteRange 5,9,10,13,32-126" </pre> <pre> </pre> <pre> # general rule for all other webapps </pre> <pre> # </pre> <pre> SecRule ARGS "@validateByteRange 9, 10,13,32-126" "phase:2,id:123" </pre> <pre> </pre> <pre>As the first two lines are glued together by "chain", this snippet </pre> <pre>defines exactly 2 rules of which the last one is skipped in case of </pre> <pre>the uri starting with /webdav </pre> <pre> </pre> <pre>These a just my two cent. I think this is somewhat related to "style" </pre> <pre>on writing rulesets and thus a quite nice topic for discussing. </pre> <pre>Perhaps there are other advices on how to handle that ;-) </pre> <pre> </pre> <pre> </pre> </blockquote> <pre> </pre> <pre>I hope I made it clear where I think it is not style anymore: when you </pre> <pre>copy the original rule when making an exception, you lose any future </pre> <pre>changes to the original rule. Ideally exceptions could be a delta from </pre> <pre>the existing rule and not copy it. We are not there yet. </pre> <pre> </pre> <pre>Another upcoming addition to ModSecurity engine that will help in this </pre> <pre>would be a RemoveByID action. It will enable the use other request parts </pre> <pre>such as source IP or a parameter value as exception conditions. Since </pre> <pre>SecRemoveRuleByID is currently a directive it is limited to the global </pre> <pre>scope or to Apache location scopes. </pre> <pre> </pre> <pre>~ Ofer </pre> <pre> </pre> <pre> </pre> <pre> </pre> <blockquote> <blockquote> <blockquote> <pre>-----Original Message----- </pre> <pre>From: <a moz-do-not-send="true" href="mailto:mod...@li...">mod...@li...</a> [<a moz-do-not-send="true" href="mailto:mod">mailto:mod</a>- </pre> <pre><a moz-do-not-send="true" href="mailto:sec...@li...">sec...@li...</a>] On Behalf Of Marc </pre> <pre> </pre> </blockquote> </blockquote> <pre>Stern </pre> <pre> </pre> <blockquote> <blockquote> <pre>Sent: Friday, June 15, 2007 12:43 PM </pre> <pre>To: Mod Security </pre> <pre>Subject: [mod-security-users] Rules manageability </pre> <pre> </pre> <pre>I'm quite prolix today ;-) </pre> <pre> </pre> <pre>I'm trying to find a better way to manage some rules, depending on </pre> <pre>the </pre> <pre>location. This is very important in the context of a reverse proxy </pre> <pre>serving several applications. </pre> <pre> </pre> <pre>Concrete example (just one between others): I'm blocking, by </pre> <pre> </pre> </blockquote> </blockquote> <pre>default, </pre> <pre> </pre> <blockquote> <blockquote> <pre>all characters outside some ranges </pre> <pre> SecRule ARGS "@validateByteRange 9, 10, 13, 32-126" </pre> <pre>phase:2,id:xxx </pre> <pre> </pre> <pre>In case I have an application using another character (say 5), the </pre> <pre> </pre> </blockquote> <pre>only </pre> <pre> </pre> <blockquote> <pre>ways I found to have it working are </pre> <pre> - adding the character for all applications (easy but insecure </pre> <pre>approach) </pre> <pre> - inside the location, remove the rule, and create a brand new one </pre> <pre>Although the second approach is better regarding security, it is </pre> <pre>quite </pre> <pre>difficult to manage; if I ever want to modify the main rule (xxx), </pre> <pre> </pre> </blockquote> </blockquote> </blockquote> <pre>I </pre> <pre> </pre> <blockquote> <blockquote> <pre>do </pre> <pre> </pre> <blockquote> <pre>not have to forget to change all "replacement" rules for the </pre> <pre>different </pre> <pre>locations. </pre> <pre> </pre> <pre>Is there a way, maybe with the new features in the development </pre> <pre> </pre> </blockquote> <pre>version, </pre> <pre> </pre> <blockquote> <pre>to do something like </pre> <pre> - define a variable containing a range (or the complete rule </pre> <pre> </pre> </blockquote> </blockquote> </blockquote> <pre>string </pre> <pre> </pre> <blockquote> <blockquote> <blockquote> <pre>like "@validateByteRange 9, 10, 13, 32-126") </pre> <pre> - inside each location, extend this variable with additional data </pre> <pre> - check the rule against the variable </pre> <pre> </pre> <pre>Any other mechanism is obviously welcome. </pre> <pre> </pre> <pre>Marc </pre> <pre> </pre> </blockquote> </blockquote> </blockquote> <p><br> <br> </p> <pre> </pre> <pre> </pre> <pre> </pre> </div> </div> </blockquote> </body> </html> |
From: Frank M. <fra...@ho...> - 2007-06-18 19:56:52
|
Hi Steffen,You're right....I guess it's just a case of me seeing what I wan= ted to see....Looking back at it now -- of course -- it's crystal clear....= and specified in several places on website and release notes as well.Not s= ure how I missed it... I could have sworn the notice I did see on the websi= te was for the HTTPServer only....Your website provides an invaluable servi= ce -- thanks very much for keeping current and in binary form so many great= apache modules.Great work !!ThanksFrankFrom: in...@ap...To: mod-= sec...@li...Date: Mon, 18 Jun 2007 21:42:49 +0200Su= bject: Re: [mod-security-users] Is mod_security broken on Windows 2003 SP1= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= You overlooked the notice.txt and Readme First.txt, both =0A= say that you must have the VC++ Dll's.=0A= =0A= Steffen=0A= www.apachelounge.com=0A= =0A= ----- Original Message ----- =0A= From: =0A= Frank =0A= Misa =0A= To: Avi Aminov ; mod...@li... =0A= =0A= Sent: Monday, 18 June, 2007 20:25=0A= Subject: Re: [mod-security-users] Is =0A= mod_security broken on Windows 2003 SP1=0A= =0A= Thanks Again Avi....I have this solved =0A= finally.... with your help...I ended up where I started -- =0A= mod_security2 v2.1.1 & the latest core_mod_rules set.I was finally =0A= able to get Apache to load the mod_security2.so library -- initially I wa= s =0A= getting: >>.\Apache =0A= -S >>Syntax error on line 180 of =0A= C:/apache/conf/httpd.conf: >>Cannot =0A= load C:/apache/modules/mod_security2.so into server: This application has= =0A= failed to startWell -- it turns out the binary I was using had =0A= prerequisites (not very documented) -- that were missing on my Win2003 = =0A= system.The binary -- I'm using for the apache server is downloaded =0A= from here: =0A= http://hunter.campbus.com/Some binaries - for the apache modules I need = =0A= are downloaded from here: =0A= http://www.apachelounge.com/download/The Apachelounge site specifies =0A= Visual C++ 2005 Redistributable Package as a requirement for the HTTP ser= ver =0A= only.I did not think their module builds required this -- because -- I wa= s =0A= not using their HTTP server.... but I was wrong.Apparently, =0A= mod_security2.so binary -- downloaded from apachelounge -- also requires = the =0A= same VC++ dlls on path...Once I installed the required dlls from =0A= here: http://www.apachelounge.com/download/vcredist_x86-sp1.exeEverything= =0A= loaded and worked correctly on Windows 2003 -- mod_security2.so and lates= t =0A= core rule set as well....Thanks for your =0A= helpCheersFrank=0A= =0A= =0A= Subject: RE: [mod-security-users] Is mod_security broken on Windows 200= 3 =0A= SP1Date: Mon, 18 Jun 2007 11:34:36 -0400From: av...@br...To: =0A= fra...@ho...; mod...@li...=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Hi =0A= Frank,=0A= =0A= In the new core =0A= rules version we started using the Resource collection to log an event = only =0A= once per location.=0A= The options I see =0A= are:=0A= 1. Try to recompile =0A= modsecurity on Win2K3 yourself (I myself don=92t know how to do it =0A= successfully, maybe Brian can help on that)=0A= 2. Remove the =0A= problematic rule. There is only 1 (will be explained later on in this = =0A= message)=0A= 3. An older version =0A= of the core rules is still available on the site. It is bundled with = =0A= modsecurity2.1.1. Simply download it, and use the rules in the =93rules= =94 =0A= folder in your own setup.=0A= =0A= =0A= Removing the =0A= problematic rule:=0A= Using =0A= SecRuleRemoveById will not help here. You will need to manually delete = =0A= it.=0A= As you already =0A= know, it appears in file 30, rule 960903 - Log outbound compressed cont= ent =0A= (once per location). 3 lines there.=0A= =0A= Hope this =0A= helps,=0A= Avi=0A= =0A= =0A= =0A= =0A= =0A= From: =0A= mod...@li... =0A= [mailto:mod...@li...] On Behalf Of = Frank MisaSent: Monday, June 18, 2007 5:39 =0A= PMTo: =0A= mod...@li...Subject: Re: [mod-security-user= s] Is =0A= mod_security broken on Windows 2003 SP1=0A= =0A= Hi All,I believe the =0A= problem I've described above is caused by not pairing the correct versi= ons =0A= of: 1) mod_security2.so with 2) mod_security_core_rules.I've =0A= reproduced my error on Win XP/2000 machines by just running the current= =0A= stable v2.1.x core rules against a v2.0.x generation =0A= module. =0A= >>.\Apache =0A= -S >>Syntax =0A= error on line 123 of =0A= C:/fmm/apache2SSL/conf/modsecurity/modsecurity_crs_30_http_policy.conf:= =0A= >>Error creating rule: Unknown variable: &RESOURCEMy =0A= Apache - on my Windows2003 box - can only load a 2.0.4 version of =0A= mod_security2.soBut the only mod_security_core_rules available for =0A= download are: modsecurity-core-rules_2.1-1.4.tarThe "rules" work =0A= with a v.2.1.x version of mod_security2.so but not version v2.0.x.* =0A= Am I correct -- the version of core rules being used needs to "match" t= he =0A= version of loaded module ?* Where are the mod_secuirty2 =0A= archives/source-repository ? -- where can I download older versions of = the =0A= core rules ?Hope someone here can help me out.....I'll start a =0A= new thread for these new/different =0A= questions.ThanksFrank=0A= =0A= =0A= =0A= =0A= From: =0A= fra...@ho...To: =0A= mod...@li...Subject: Is mod_security broken= =0A= on Windows 2003 SP1Date: Thu, 14 Jun 2007 03:54:21 =0A= +0000=0A= Hi =0A= All,Would really appreciate some help getting mod_security working =0A= on Windows 2003....My question:Does anyone have a link to a =0A= binary distribution that has been built against Windows2003: =0A= Apache/SSL/mod_security2/libxml2 etc.My setup works fine on =0A= Windows2000 and WindowsXP - no problem.I can use any number of binary = =0A= distributions -- and things just work fine....On Windows 2003 -- I =0A= have to juggle library versions to get the module to load properly.Usin= g =0A= http://www.apachelounge.com/download/build: =0A= mod_security-2.1.1-2.0.x-w32>>C:\apache\bin>.\Apache =0A= -S>>Syntax error on line 180 of =0A= C:/apache/conf/httpd.conf:>>Cannot load =0A= C:/apache/modules/mod_security2.so into server: This application has fa= iled =0A= to startUsing =0A= http://www.gknw.net/development/apache/httpd-2.0/win32/modules/build: = =0A= mod_security-2.0.4-2.0.59-w32module loads correctly -- but the CoreRule= s =0A= Fail....And no amount of tweaking can get the CoreRules to load =0A= properly.I've searched the forums and tried to force load libxml2 using= =0A= LoadFile directive -- it doesn't make a difference.This is the =0A= error:>>C:\apache\bin>.\Apache -S>>Syntax error on =0A= line 123 of =0A= C:/apache/conf/modsecurity/modsecurity_crs_30_http_policy.conf:>>Error = =0A= creating rule: Unknown variable: &RESOURCEHere is my system =0A= information: os: MS Windows Server 2003 =0A= SP1 - Enterprise Edition apache: Server version: =0A= Apache/2.0.59 Server built: Sep 28 2006 =0A= 17:35:51 =0A= mod_security-2.0.4-2.0.59-w32 =0A= modsecurity-core-rules_2.1-1.4.tar.gz (cannot find earlier versions to= =0A= match 2.0 series of mod_security ?) **I've verified that all required = =0A= DLLs are loading -- here are the versions that load with my apache =0A= instance: =0A= iconv.dll =0A= v1.9.2 =0A= zlib.dll =0A= v1.2.3 libxml2.dll =0A= v2.6.28**Note: I've tried many, many different =0A= locations/configurations -- but settled on just leaving the DLLs in =0A= Apache/bin...Process explorer verifies -- the expected DLLs are =0A= loading.Here are the relevant httpd.conf =0A= directives: LoadModule unique_id_module =0A= modules/mod_unique_id.so LoadModule =0A= security2_module modules/mod_security2.so =0A= ... <IfModule =0A= mod_security2.c> # =0A= use Core Rule Set by default: =0A= Include =0A= "C:/apache/conf/modsecurity/*.conf" =0A= </IfModule>I'm at a loss to explain why the same setup works =0A= fine on WindowsXP/2000 systems but fails on Windows2003SP1....Is anyone= =0A= here experiencing the same issue ?Hope to hear from =0A= someone...ThanksFrank=0A= =0A= =0A= =0A= =0A= Explore the seven wonders of =0A= the world Learn more! =0A= =0A= =0A= =0A= =0A= Explore the seven wonders of =0A= the world Learn more!=0A= =0A= Explore the seven wonders of the world Learn more! =0A= =0A= =0A= =0A= -------------------------------------------------------------------------= This =0A= SF.net email is sponsored by DB2 ExpressDownload DB2 Express C - the FREE= =0A= version of DB2 express and takecontrol of your XML. No limits. Just data.= =0A= Click to get it now.http://sourceforge.net/powerbar/db2/=0A= =0A= =0A= =0A= _______________________________________________mod-security-users =0A= mailing =0A= lis...@li...https://lists.sourceforge.net= /lists/listinfo/mod-security-users=0A= _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Space= s. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=3Dcreate&wx_url=3D/friends.= aspx&mkt=3Den-us= |
From: Steffen <in...@ap...> - 2007-06-18 19:43:14
|
You overlooked the notice.txt and Readme First.txt, both say that you = must have the VC++ Dll's. Steffen www.apachelounge.com ----- Original Message -----=20 From: Frank Misa=20 To: Avi Aminov ; mod...@li...=20 Sent: Monday, 18 June, 2007 20:25 Subject: Re: [mod-security-users] Is mod_security broken on Windows = 2003 SP1 Thanks Again Avi.... I have this solved finally.... with your help... I ended up where I started -- mod_security2 v2.1.1 & the latest = core_mod_rules set. I was finally able to get Apache to load the mod_security2.so library = -- initially I was getting: >>.\Apache -S >>Syntax error on line 180 of C:/apache/conf/httpd.conf: >>Cannot load C:/apache/modules/mod_security2.so into server: = This application has failed to start Well -- it turns out the binary I was using had prerequisites (not = very documented) -- that were missing on my Win2003 system. The binary -- I'm using for the apache server is downloaded from here: = http://hunter.campbus.com/ Some binaries - for the apache modules I need are downloaded from = here: http://www.apachelounge.com/download/ The Apachelounge site specifies Visual C++ 2005 Redistributable = Package as a requirement for the HTTP server only. I did not think their module builds required this -- because -- I was = not using their HTTP server.... but I was wrong. Apparently, mod_security2.so binary -- downloaded from apachelounge -- = also requires the same VC++ dlls on path... Once I installed the required dlls from here: http://www.apachelounge.com/download/vcredist_x86-sp1.exe Everything loaded and worked correctly on Windows 2003 --=20 mod_security2.so and latest core rule set as well.... Thanks for your help Cheers Frank -------------------------------------------------------------------------= --- Subject: RE: [mod-security-users] Is mod_security broken on Windows = 2003 SP1 Date: Mon, 18 Jun 2007 11:34:36 -0400 From: av...@br... To: fra...@ho...; mod...@li... Hi Frank, In the new core rules version we started using the Resource = collection to log an event only once per location. The options I see are: 1. Try to recompile modsecurity on Win2K3 yourself (I myself don=92t = know how to do it successfully, maybe Brian can help on that) 2. Remove the problematic rule. There is only 1 (will be explained = later on in this message) 3. An older version of the core rules is still available on the = site. It is bundled with modsecurity2.1.1. Simply download it, and use = the rules in the =93rules=94 folder in your own setup. Removing the problematic rule: Using SecRuleRemoveById will not help here. You will need to = manually delete it. As you already know, it appears in file 30, rule 960903 - Log = outbound compressed content (once per location). 3 lines there. Hope this helps, Avi -------------------------------------------------------------------------= --- From: mod...@li... = [mailto:mod...@li...] On Behalf Of = Frank Misa Sent: Monday, June 18, 2007 5:39 PM To: mod...@li... Subject: Re: [mod-security-users] Is mod_security broken on Windows = 2003 SP1 Hi All, I believe the problem I've described above is caused by not pairing = the correct versions of: 1) mod_security2.so with 2) = mod_security_core_rules. I've reproduced my error on Win XP/2000 machines by just running the = current stable v2.1.x core rules against a v2.0.x generation module. >>.\Apache -S >>Syntax error on line 123 of = C:/fmm/apache2SSL/conf/modsecurity/modsecurity_crs_30_http_policy.conf: >>Error creating rule: Unknown variable: &RESOURCE My Apache - on my Windows2003 box - can only load a 2.0.4 version of = mod_security2.so But the only mod_security_core_rules available for download are: = modsecurity-core-rules_2.1-1.4.tar The "rules" work with a v.2.1.x version of mod_security2.so but not = version v2.0.x. * Am I correct -- the version of core rules being used needs to = "match" the version of loaded module ? * Where are the mod_secuirty2 archives/source-repository ? -- where = can I download older versions of the core rules ? Hope someone here can help me out..... I'll start a new thread for these new/different questions. Thanks Frank -------------------------------------------------------------------------= --- From: fra...@ho... To: mod...@li... Subject: Is mod_security broken on Windows 2003 SP1 Date: Thu, 14 Jun 2007 03:54:21 +0000 Hi All, Would really appreciate some help getting mod_security working on = Windows 2003.... My question: Does anyone have a link to a binary distribution that has been built = against Windows2003: Apache/SSL/mod_security2/libxml2 etc. My setup works fine on Windows2000 and WindowsXP - no problem. I can use any number of binary distributions -- and things just work = fine.... On Windows 2003 -- I have to juggle library versions to get the = module to load properly. Using http://www.apachelounge.com/download/ build: mod_security-2.1.1-2.0.x-w32 >>C:\apache\bin>.\Apache -S >>Syntax error on line 180 of C:/apache/conf/httpd.conf: >>Cannot load C:/apache/modules/mod_security2.so into server: This = application has failed to start Using = http://www.gknw.net/development/apache/httpd-2.0/win32/modules/ build: mod_security-2.0.4-2.0.59-w32 module loads correctly -- but the CoreRules Fail.... And no amount of tweaking can get the CoreRules to load properly. I've searched the forums and tried to force load libxml2 using = LoadFile directive -- it doesn't make a difference. This is the error: >>C:\apache\bin>.\Apache -S >>Syntax error on line 123 of = C:/apache/conf/modsecurity/modsecurity_crs_30_http_policy.conf: >>Error creating rule: Unknown variable: &RESOURCE Here is my system information: os: MS Windows Server 2003 SP1 - Enterprise Edition apache: Server version: Apache/2.0.59 Server built: Sep 28 = 2006 17:35:51 mod_security-2.0.4-2.0.59-w32 modsecurity-core-rules_2.1-1.4.tar.gz (cannot find earlier = versions to match 2.0 series of mod_security ?)=20 **I've verified that all required DLLs are loading -- here are the = versions that load with my apache instance: iconv.dll v1.9.2 zlib.dll v1.2.3 libxml2.dll v2.6.28 **Note: I've tried many, many different locations/configurations -- = but settled on just leaving the DLLs in Apache/bin... Process explorer verifies -- the expected DLLs are loading. Here are the relevant httpd.conf directives: LoadModule unique_id_module modules/mod_unique_id.so LoadModule security2_module modules/mod_security2.so ... <IfModule mod_security2.c> # use Core Rule Set by default: Include "C:/apache/conf/modsecurity/*.conf" </IfModule> I'm at a loss to explain why the same setup works fine on = WindowsXP/2000 systems but fails on Windows2003SP1.... Is anyone here experiencing the same issue ? Hope to hear from someone... Thanks Frank -------------------------------------------------------------------------= --- Explore the seven wonders of the world Learn more!=20 -------------------------------------------------------------------------= --- Explore the seven wonders of the world Learn more! -------------------------------------------------------------------------= ----- Explore the seven wonders of the world Learn more!=20 -------------------------------------------------------------------------= ----- = -------------------------------------------------------------------------= This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -------------------------------------------------------------------------= ----- _______________________________________________ mod-security-users mailing list mod...@li... https://lists.sourceforge.net/lists/listinfo/mod-security-users |