Thread: [mod-security-users] mod_security enhancement idea
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
mod-security-users
|
From: joe b. <joe...@ya...> - 2006-04-10 17:30:16
|
mod_security enhancement idea
In software packet firewalls there are 2 different types of filter rule sets.
The exclusive firewall and the inclusive firewall. This is well documented in the FreeBSD manual firewall section.
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls.html
An exclusive firewall allows all packets through except for those matching a set of rules that block certain packets, (IE, default pass all).
An inclusive firewall does the reverse. It only allows packets matching the rules through and blocks everything else, (IE, default deny all). Inclusive firewalls are much, much securer than exclusive firewalls and simpler to code.
Applying that concept to the mod_security filter rules I see explained in the manual and the examples provided at the mod_security home page it became very obvious that mod_security defaults to an exclusive type of firewall. Rules are used to code the particular signatures of malice attempts to circumvent the normal standard http processes of a web server.
This is fine if you are an internet security expert and want to analyze and capture the different methods used by attackers of web application. Mod_security is the perfectly designed tool for this task.
But for the user who is looking for a simple user friendly web server firewall to block all the currently know & future malice attack methods while allowing his web application to pass unmolested does not readily find this available in mod_security.
Now dont take me wrong, it is possible to configure an mod_security rule set that address the technical part of the stated goal, but the simple & user friendly part is by no means met as shown in the following example. All the scripts used in the web application are coded by individual rules.
secfilterengine on
secfiltercheckurlencoding on
secfiltercheckunicodeencoding off
secfilterforcebyterange 0 255
secfilterscanpost on
SecFilterDefaultAction deny,log,status:404
SecFilterSelective REQUEST_URI "!^/00.00_Header.htm" chain
SecFilterSelective REQUEST_URI "!^/00.00_Header.php" chain
SecFilterSelective REQUEST_URI "!^/00.00-web_style_sheet.css" chain
SecFilterSelective REQUEST_URI "!^/button.php" chain
SecFilterSelective REQUEST_URI "!^/index.htm" chain
SecFilterSelective REQUEST_URI "!^/mls_auction_bidding_info.htm" chain
SecFilterSelective REQUEST_URI "!^/mls_breakin_attempt.php" chain
SecFilterSelective REQUEST_URI "!^/mls_contact_sales_dept.htm" chain
SecFilterSelective REQUEST_URI "!^/mls_fsbo_forgot_logon.php" chain
SecFilterSelective REQUEST_URI "!^/mls_fsbo_listing_info.htm" chain
SecFilterSelective REQUEST_URI "!^/mls_fsbo_logon.php" chain
SecFilterSelective REQUEST_URI "!^/mls_fsbo_member_update.php" chain
SecFilterSelective REQUEST_URI "!^/mls_fsbo_menu.php" chain
SecFilterSelective REQUEST_URI "!^/mls_fsbo_signup.php" chain
SecFilterSelective REQUEST_URI "!^/mls_fsbo_terminate_member1.php" chain
SecFilterSelective REQUEST_URI "!^/mls_fsbo_terminate_member2.php" chain
SecFilterSelective REQUEST_URI "!^/mls_home_page.php" chain
SecFilterSelective REQUEST_URI "!^/mls_std_exit.php" chain
SecFilterSelective REQUEST_URI "!^/mls_verifyemail.php" chain
SecFilterSelective REQUEST_URI "!^/mls_verifyemail0.php"
In some programming circles this would be called a reverse polish coding technique.
This is not simple coding logic and this technique is not documented or even hinted at in the manual. But it does fulfill the stated technical goal requirement of blocking all currently know and unknown malice attack methods while allowing the web application to pass unmolested. As a side benefit not only does the above example pass the users normal web traffic but it also allows search engine robot traffic to pass as they inventory the website for indexing.
Security can be tightened further by coding all the script names using this rule format
SecFilterSelective SCRIPT_FILENAME "!^/usr/local/www/data/mls_Read_forgot_logon_email.php" chain
This would stop all search engine traffic because they do not include the path in their requests.
The usefulness of mod_security can be increased while becoming more user friendly by making few tweaks to mod_securitys source code.
What I purpose is this,
Change secfilterengine on|off to
secfilterengine on_exclusive | on_inclusive | off
on_exclusive = (defaults to allow all) which is how mod_security currently functions
on_inclusive = (defaults to block all)
This would then allow the above example rules to be re-coded like this:
SecFilterSelective REQUEST_URI "^/00.00_Header.htm" SecFilterSelective REQUEST_URI "^/00.00_Header.php" SecFilterSelective REQUEST_URI "^/00.00-web_style_sheet.css"
SecFilterSelective REQUEST_URI "^/button.php"
SecFilterSelective REQUEST_URI "^/class.phpmailer.php"
SecFilterSelective REQUEST_URI "^/index.htm"
Where a match means pass the packet to the web server and any non-matches get passed to what ever SecFilterDefaultAction deny,log,status:404 says to do.
To an non-technical user this is straight forward and makes logical senses when read.
The concept of only having to add a rule for each script that makes up the web application requires no technical comprehension of how an web server processes requests and is really on target for the general home hobbyist level of understanding and needs. And of course the mod_security manual would need a major rewrite to include this new function.
I post this for discussion by members of this list who have more knowledge of mod_security internals and usage background in hopes of achieving agreement on making this an official enhancement request.
---------------------------------
New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. |
|
From: Andras G. <an...@an...> - 2006-04-10 18:12:14
|
Hi, I don't really see you point. Let's say someone runs a webserver. I don't really want, that a newbie do= it's config. Maybe the apache and mod_sec will be configured reasonably secure, but all the othe= r parts, will be like cheese. So let's suppose everything got set up correctly, then this admin= has a good knowledge about webserver security. On the other hand, the current logic behind mod_sec it's just good. You g= ot a tool which could prevent some attack patterns or full technics (checkurlencodeing, byteran= ge). You can make your rules against known software bugs and some for prevention. The URL-s are = so hectic, that you can easily kill all you customers sites with a single bad rule. Some months a= go I tried to introduce a rule, which filters out "../" like strings from GET and POST. Within the = hour, one customer called me, that "something wierd" happens. It turned out, that he extensively us= ed "../" in hidden form elements, on his site. I couldn't beleive, that a so dumb and insecure so= lution could take shape in ones mind. So this was only one story, but users has a big surprise for a= lmost every month. :) So my point is, that on a paid hosting server (or any webserver with many= pages) the admin just can't setup all these restrictions, so the exclusive way is just good. Yo= u shouldn't compare the TCP/IP layer 2-3 filtering, which is highly predictable (say so you don't= want anything from a /24 network, or you just allow traffic to a single port from a /24 network). I hope I didn't misunderstand your point. Regards, Andras joe barbish wrote: > mod_security enhancement idea > =20 > =20 > In software packet firewalls there are 2 different types of filter ru= le sets. > =20 > The exclusive firewall and the inclusive firewall. This is well docum= ented in the FreeBSD manual firewall section. > =20 > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls.= html > =20 > An exclusive firewall allows all packets through except for those mat= ching a set of rules that block certain packets, (IE, default pass all). = =20 > =20 > An inclusive firewall does the reverse. It only allows packets matchi= ng the rules through and blocks everything else, (IE, default deny all). = Inclusive firewalls are much, much securer than exclusive firewalls and s= impler to code. > =20 > Applying that concept to the mod_security filter rules I see explaine= d in the manual and the examples provided at the mod_security home page i= t became very obvious that mod_security defaults to an exclusive type of= firewall. Rules are used to code the particular signatures of malice att= empts to circumvent the normal standard http processes of a web server.=20 > =20 > This is fine if you are an internet security expert and want to analy= ze and capture the different methods used by attackers of web application= . Mod_security is the perfectly designed tool for this task.=20 > =20 > But for the user who is looking for a simple user friendly web server= firewall to block all the currently know & future malice attack methods = while allowing his web application to pass unmolested does not readily fi= nd this available in mod_security.=20 > =20 > Now don=E2=80=99t take me wrong, it is possible to configure an mod_s= ecurity rule set that address the technical part of the stated goal, but = the simple & user friendly part is by no means met as shown in the follow= ing example. All the scripts used in the web application are coded by ind= ividual rules. > =20 > =20 > secfilterengine on > secfiltercheckurlencoding on > secfiltercheckunicodeencoding off > secfilterforcebyterange 0 255 > secfilterscanpost on > SecFilterDefaultAction deny,log,status:404 > =20 > SecFilterSelective REQUEST_URI "!^/00.00_Header.htm" = chain > SecFilterSelective REQUEST_URI "!^/00.00_Header.php" = chain > SecFilterSelective REQUEST_URI "!^/00.00-web_style_sheet.css" = chain > SecFilterSelective REQUEST_URI "!^/button.php" = chain=20 > SecFilterSelective REQUEST_URI "!^/index.htm" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_auction_bidding_info.htm" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_breakin_attempt.php" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_contact_sales_dept.htm" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_fsbo_forgot_logon.php" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_fsbo_listing_info.htm" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_fsbo_logon.php" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_fsbo_member_update.php" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_fsbo_menu.php" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_fsbo_signup.php" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_fsbo_terminate_member1.php" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_fsbo_terminate_member2.php" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_home_page.php" = chain > SecFilterSelective REQUEST_URI "!^/mls_std_exit.php" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_verifyemail.php" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_verifyemail0.php" =20 > =20 > =20 > In some programming circles this would be called a reverse polish cod= ing technique. > =20 > This is not simple coding logic and this technique is not documented = or even hinted at in the manual. But it does fulfill the stated technical= goal requirement of blocking all currently know and unknown malice attac= k methods while allowing the web application to pass unmolested. As a sid= e benefit not only does the above example pass the users normal web traff= ic but it also allows search engine robot traffic to pass as they invento= ry the website for indexing. > =20 > Security can be tightened further by coding all the script names usin= g this rule format > =20 > SecFilterSelective SCRIPT_FILENAME "!^/usr/local/www/data/mls_Read_fo= rgot_logon_email.php" chain=20 > =20 > This would stop all search engine traffic because they do not include= the path in their requests. > =20 > =20 > =20 > The usefulness of mod_security can be increased while becoming more u= ser friendly by making few tweaks to mod_security=E2=80=99s source code. > =20 > =20 > What I purpose is this, > =20 > Change secfilterengine on|off to > =20 > =20 > secfilterengine on_exclusive | on_inclusive | off > =20 > =20 > on_exclusive =3D (defaults to allow all) which is how mod_security c= urrently functions > =20 > on_inclusive =3D (defaults to block all)=20 > =20 > This would then allow the above example rules to be re-coded like thi= s: > =20 > SecFilterSelective REQUEST_URI "^/00.00_Header.htm" S= ecFilterSelective REQUEST_URI "^/00.00_Header.php" SecFil= terSelective REQUEST_URI "^/00.00-web_style_sheet.css" =20 > SecFilterSelective REQUEST_URI "^/button.php" =20 > SecFilterSelective REQUEST_URI "^/class.phpmailer.php" =20 > SecFilterSelective REQUEST_URI "^/index.htm" > =20 > Where a match means pass the packet to the web server and any non-mat= ches get passed to what ever SecFilterDefaultAction deny,log,status:404 = says to do. > =20 > To an non-technical user this is straight forward and makes logical s= enses when read. > The concept of only having to add a rule for each script that makes u= p the web application requires no technical comprehension of how an web s= erver processes requests and is really on target for the general home hob= byist level of understanding and needs. And of course the mod_security ma= nual would need a major rewrite to include this new function. > =20 > =20 > I post this for discussion by members of this list who have more know= ledge of mod_security internals and usage background in hopes of achievin= g agreement on making this an official enhancement request. > =20 > =20 >=20 > =09 > --------------------------------- > New Yahoo! Messenger with Voice. Call regular phones from your PC and s= ave big. |
|
From: joe b. <joe...@ya...> - 2006-04-10 19:02:23
|
Yep Andras you misunderstand the point completely. The purposed change does not terminate how the existing software works. The current functions will remain as is. The change just extended the flexibility of the software. Andras Got <an...@an...> wrote: Hi, I don't really see you point. Let's say someone runs a webserver. I don't really want, that a newbie do it's config. Maybe the apache and mod_sec will be configured reasonably secure, but all the other parts, will be like cheese. So let's suppose everything got set up correctly, then this admin has a good knowledge about webserver security. On the other hand, the current logic behind mod_sec it's just good. You got a tool which could prevent some attack patterns or full technics (checkurlencodeing, byterange). You can make your rules against known software bugs and some for prevention. The URL-s are so hectic, that you can easily kill all you customers sites with a single bad rule. Some months ago I tried to introduce a rule, which filters out "../" like strings from GET and POST. Within the hour, one customer called me, that "something wierd" happens. It turned out, that he extensively used "../" in hidden form elements, on his site. I couldn't beleive, that a so dumb and insecure solution could take shape in ones mind. So this was only one story, but users has a big surprise for almost every month. :) So my point is, that on a paid hosting server (or any webserver with many pages) the admin just can't setup all these restrictions, so the exclusive way is just good. You shouldn't compare the TCP/IP layer 2-3 filtering, which is highly predictable (say so you don't want anything from a /24 network, or you just allow traffic to a single port from a /24 network). I hope I didn't misunderstand your point. Regards, Andras joe barbish wrote: > mod_security enhancement idea > > > In software packet firewalls there are 2 different types of filter rule sets. > > The exclusive firewall and the inclusive firewall. This is well documented in the FreeBSD manual firewall section. > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls.html > > An exclusive firewall allows all packets through except for those matching a set of rules that block certain packets, (IE, default pass all). > > An inclusive firewall does the reverse. It only allows packets matching the rules through and blocks everything else, (IE, default deny all). Inclusive firewalls are much, much securer than exclusive firewalls and simpler to code. > > Applying that concept to the mod_security filter rules I see explained in the manual and the examples provided at the mod_security home page it became very obvious that mod_security defaults to an exclusive type of firewall. Rules are used to code the particular signatures of malice attempts to circumvent the normal standard http processes of a web server. > > This is fine if you are an internet security expert and want to analyze and capture the different methods used by attackers of web application. Mod_security is the perfectly designed tool for this task. > > But for the user who is looking for a simple user friendly web server firewall to block all the currently know & future malice attack methods while allowing his web application to pass unmolested does not readily find this available in mod_security. > > Now donât take me wrong, it is possible to configure an mod_security rule set that address the technical part of the stated goal, but the simple & user friendly part is by no means met as shown in the following example. All the scripts used in the web application are coded by individual rules. > > > secfilterengine on > secfiltercheckurlencoding on > secfiltercheckunicodeencoding off > secfilterforcebyterange 0 255 > secfilterscanpost on > SecFilterDefaultAction deny,log,status:404 > > SecFilterSelective REQUEST_URI "!^/00.00_Header.htm" chain > SecFilterSelective REQUEST_URI "!^/00.00_Header.php" chain > SecFilterSelective REQUEST_URI "!^/00.00-web_style_sheet.css" chain > SecFilterSelective REQUEST_URI "!^/button.php" chain > SecFilterSelective REQUEST_URI "!^/index.htm" chain > SecFilterSelective REQUEST_URI "!^/mls_auction_bidding_info.htm" chain > SecFilterSelective REQUEST_URI "!^/mls_breakin_attempt.php" chain > SecFilterSelective REQUEST_URI "!^/mls_contact_sales_dept.htm" chain > SecFilterSelective REQUEST_URI "!^/mls_fsbo_forgot_logon.php" chain > SecFilterSelective REQUEST_URI "!^/mls_fsbo_listing_info.htm" chain > SecFilterSelective REQUEST_URI "!^/mls_fsbo_logon.php" chain > SecFilterSelective REQUEST_URI "!^/mls_fsbo_member_update.php" chain > SecFilterSelective REQUEST_URI "!^/mls_fsbo_menu.php" chain > SecFilterSelective REQUEST_URI "!^/mls_fsbo_signup.php" chain > SecFilterSelective REQUEST_URI "!^/mls_fsbo_terminate_member1.php" chain > SecFilterSelective REQUEST_URI "!^/mls_fsbo_terminate_member2.php" chain > SecFilterSelective REQUEST_URI "!^/mls_home_page.php" chain > SecFilterSelective REQUEST_URI "!^/mls_std_exit.php" chain > SecFilterSelective REQUEST_URI "!^/mls_verifyemail.php" chain > SecFilterSelective REQUEST_URI "!^/mls_verifyemail0.php" > > > In some programming circles this would be called a reverse polish coding technique. > > This is not simple coding logic and this technique is not documented or even hinted at in the manual. But it does fulfill the stated technical goal requirement of blocking all currently know and unknown malice attack methods while allowing the web application to pass unmolested. As a side benefit not only does the above example pass the users normal web traffic but it also allows search engine robot traffic to pass as they inventory the website for indexing. > > Security can be tightened further by coding all the script names using this rule format > > SecFilterSelective SCRIPT_FILENAME "!^/usr/local/www/data/mls_Read_forgot_logon_email.php" chain > > This would stop all search engine traffic because they do not include the path in their requests. > > > > The usefulness of mod_security can be increased while becoming more user friendly by making few tweaks to mod_securityâs source code. > > > What I purpose is this, > > Change secfilterengine on|off to > > > secfilterengine on_exclusive | on_inclusive | off > > > on_exclusive = (defaults to allow all) which is how mod_security currently functions > > on_inclusive = (defaults to block all) > > This would then allow the above example rules to be re-coded like this: > > SecFilterSelective REQUEST_URI "^/00.00_Header.htm" SecFilterSelective REQUEST_URI "^/00.00_Header.php" SecFilterSelective REQUEST_URI "^/00.00-web_style_sheet.css" > SecFilterSelective REQUEST_URI "^/button.php" > SecFilterSelective REQUEST_URI "^/class.phpmailer.php" > SecFilterSelective REQUEST_URI "^/index.htm" > > Where a match means pass the packet to the web server and any non-matches get passed to what ever SecFilterDefaultAction deny,log,status:404 says to do. > > To an non-technical user this is straight forward and makes logical senses when read. > The concept of only having to add a rule for each script that makes up the web application requires no technical comprehension of how an web server processes requests and is really on target for the general home hobbyist level of understanding and needs. And of course the mod_security manual would need a major rewrite to include this new function. > > > I post this for discussion by members of this list who have more knowledge of mod_security internals and usage background in hopes of achieving agreement on making this an official enhancement request. > > > > > --------------------------------- > New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ mod-security-users mailing list mod...@li... https://lists.sourceforge.net/lists/listinfo/mod-security-users --------------------------------- How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates. |
|
From: Andras G. <an...@an...> - 2006-04-10 19:12:31
|
I knew that you'd extend, but I can't see the point in an extension like = this. The more you extend,=20 the more it get's complicated and raise the possible number of secholes. joe barbish wrote: > Yep Andras you misunderstand the point completely. The purposed change = does not terminate how the existing software works. The current functions= will remain as is. The change just extended the flexibility of the softw= are. =20 >=20 > Andras Got <an...@an...> wrote: Hi, >=20 > I don't really see you point. >=20 > Let's say someone runs a webserver. I don't really want, that a newbie = do it's config. Maybe the > apache and mod_sec will be configured reasonably secure, but all the ot= her parts, will be like > cheese. So let's suppose everything got set up correctly, then this adm= in has a good knowledge about > webserver security. >=20 > On the other hand, the current logic behind mod_sec it's just good. You= got a tool which could > prevent some attack patterns or full technics (checkurlencodeing, byter= ange). You can make your > rules against known software bugs and some for prevention. The URL-s ar= e so hectic, that you can > easily kill all you customers sites with a single bad rule. Some months= ago I tried to introduce a > rule, which filters out "../" like strings from GET and POST. Within th= e hour, one customer called > me, that "something wierd" happens. It turned out, that he extensively = used "../" in hidden form > elements, on his site. I couldn't beleive, that a so dumb and insecure = solution could take shape in > ones mind. So this was only one story, but users has a big surprise for= almost every month. :) >=20 > So my point is, that on a paid hosting server (or any webserver with ma= ny pages) the admin just > can't setup all these restrictions, so the exclusive way is just good. = You shouldn't compare the > TCP/IP layer 2-3 filtering, which is highly predictable (say so you don= 't want anything from a /24 > network, or you just allow traffic to a single port from a /24 network)= . >=20 > I hope I didn't misunderstand your point. >=20 > Regards, > Andras >=20 >=20 >=20 > joe barbish wrote: >> mod_security enhancement idea >> >> >> In software packet firewalls there are 2 different types of filter rul= e sets. >> >> The exclusive firewall and the inclusive firewall. This is well docume= nted in the FreeBSD manual firewall section. >> >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls.ht= ml >> >> An exclusive firewall allows all packets through except for those matc= hing a set of rules that block certain packets, (IE, default pass all).=20 >> >> An inclusive firewall does the reverse. It only allows packets matchin= g the rules through and blocks everything else, (IE, default deny all). I= nclusive firewalls are much, much securer than exclusive firewalls and si= mpler to code. >> >> Applying that concept to the mod_security filter rules I see explained= in the manual and the examples provided at the mod_security home page it= became very obvious that mod_security defaults to an exclusive type of f= irewall. Rules are used to code the particular signatures of malice attem= pts to circumvent the normal standard http processes of a web server.=20 >> >> This is fine if you are an internet security expert and want to analyz= e and capture the different methods used by attackers of web application.= Mod_security is the perfectly designed tool for this task.=20 >> >> But for the user who is looking for a simple user friendly web server = firewall to block all the currently know & future malice attack methods w= hile allowing his web application to pass unmolested does not readily fin= d this available in mod_security.=20 >> >> Now don=C3=A2=E2=82=AC=E2=84=A2t take me wrong, it is possible to conf= igure an mod_security rule set that address the technical part of the sta= ted goal, but the simple & user friendly part is by no means met as shown= in the following example. All the scripts used in the web application ar= e coded by individual rules. >> >> >> secfilterengine on >> secfiltercheckurlencoding on >> secfiltercheckunicodeencoding off >> secfilterforcebyterange 0 255 >> secfilterscanpost on >> SecFilterDefaultAction deny,log,status:404 >> >> SecFilterSelective REQUEST_URI "!^/00.00_Header.htm" chain >> SecFilterSelective REQUEST_URI "!^/00.00_Header.php" chain >> SecFilterSelective REQUEST_URI "!^/00.00-web_style_sheet.css" chain >> SecFilterSelective REQUEST_URI "!^/button.php" chain=20 >> SecFilterSelective REQUEST_URI "!^/index.htm" chain=20 >> SecFilterSelective REQUEST_URI "!^/mls_auction_bidding_info.htm" chain= =20 >> SecFilterSelective REQUEST_URI "!^/mls_breakin_attempt.php" chain=20 >> SecFilterSelective REQUEST_URI "!^/mls_contact_sales_dept.htm" chain=20 >> SecFilterSelective REQUEST_URI "!^/mls_fsbo_forgot_logon.php" chain=20 >> SecFilterSelective REQUEST_URI "!^/mls_fsbo_listing_info.htm" chain=20 >> SecFilterSelective REQUEST_URI "!^/mls_fsbo_logon.php" chain=20 >> SecFilterSelective REQUEST_URI "!^/mls_fsbo_member_update.php" chain=20 >> SecFilterSelective REQUEST_URI "!^/mls_fsbo_menu.php" chain=20 >> SecFilterSelective REQUEST_URI "!^/mls_fsbo_signup.php" chain=20 >> SecFilterSelective REQUEST_URI "!^/mls_fsbo_terminate_member1.php" cha= in=20 >> SecFilterSelective REQUEST_URI "!^/mls_fsbo_terminate_member2.php" cha= in=20 >> SecFilterSelective REQUEST_URI "!^/mls_home_page.php" chain >> SecFilterSelective REQUEST_URI "!^/mls_std_exit.php" chain=20 >> SecFilterSelective REQUEST_URI "!^/mls_verifyemail.php" chain=20 >> SecFilterSelective REQUEST_URI "!^/mls_verifyemail0.php"=20 >> >> >> In some programming circles this would be called a reverse polish codi= ng technique. >> >> This is not simple coding logic and this technique is not documented o= r even hinted at in the manual. But it does fulfill the stated technical = goal requirement of blocking all currently know and unknown malice attack= methods while allowing the web application to pass unmolested. As a side= benefit not only does the above example pass the users normal web traffi= c but it also allows search engine robot traffic to pass as they inventor= y the website for indexing. >> >> Security can be tightened further by coding all the script names using= this rule format >> >> SecFilterSelective SCRIPT_FILENAME "!^/usr/local/www/data/mls_Read_for= got_logon_email.php" chain=20 >> >> This would stop all search engine traffic because they do not include = the path in their requests. >> >> >> >> The usefulness of mod_security can be increased while becoming more us= er friendly by making few tweaks to mod_security=C3=A2=E2=82=AC=E2=84=A2s= source code. >> >> >> What I purpose is this, >> >> Change secfilterengine on|off to >> >> >> secfilterengine on_exclusive | on_inclusive | off >> >> >> on_exclusive =3D (defaults to allow all) which is how mod_security cur= rently functions >> >> on_inclusive =3D (defaults to block all)=20 >> >> This would then allow the above example rules to be re-coded like this= : >> >> SecFilterSelective REQUEST_URI "^/00.00_Header.htm" SecFilterSelective= REQUEST_URI "^/00.00_Header.php" SecFilterSelective REQUEST_URI "^/00.00= -web_style_sheet.css"=20 >> SecFilterSelective REQUEST_URI "^/button.php"=20 >> SecFilterSelective REQUEST_URI "^/class.phpmailer.php"=20 >> SecFilterSelective REQUEST_URI "^/index.htm" >> >> Where a match means pass the packet to the web server and any non-matc= hes get passed to what ever SecFilterDefaultAction deny,log,status:404 sa= ys to do. >> >> To an non-technical user this is straight forward and makes logical se= nses when read. >> The concept of only having to add a rule for each script that makes up= the web application requires no technical comprehension of how an web se= rver processes requests and is really on target for the general home hobb= yist level of understanding and needs. And of course the mod_security man= ual would need a major rewrite to include this new function. >> >> >> I post this for discussion by members of this list who have more knowl= edge of mod_security internals and usage background in hopes of achieving= agreement on making this an official enhancement request. >> >> >> >> >> --------------------------------- >> New Yahoo! Messenger with Voice. Call regular phones from your PC and = save big. >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting lang= uage > that extends applications into web and mobile media. Attend the live we= bcast > and join the prime developer group breaking into this new coding territ= ory! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=12164= 2 > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users >=20 >=20 > =09 > --------------------------------- > How low will we go? Check out Yahoo! Messenger=E2=80=99s low PC-to-Pho= ne call rates. |
|
From: Ryan B. <rcb...@gm...> - 2006-04-10 19:33:19
|
Joe, A few quick comments - 1) You really don't need a new directive/option to get what you are looking for. Keeping with your firewall concept, in order to get an inclusive ruleset, you first need to implement a catch-all deny rule that would block all requests. In mod_security it would be this - SecFilter ".". This woul= d match any request and then take the action that you specified in the SecFilterDefaultAction rule. The next step is to create a whitelist of filters that will match allowed, acceptable requests. This is what you are attempting to do in your post with the mod_security inverted filters. 2) Your examples of inverted filters will not work correctly with the chain action. The chain feature will create a larger, complex check on the request. In your examples, you tried to chain all of the acceptable URLs together. The problem is that all of those files will never be requested within one sigle request packet. The mod_security action that you should use is "allow" to tell mod_security to allow the request through and the final filter is the catch-all deny. Here is an updated ruleset for you - SecFilterSelective REQUEST_URI "^/00.00_Header.htm" allow SecFilterSelective REQUEST_URI "^/00.00_Header.php" allow SecFilterSelective REQUEST_URI "^/00.00-web_style_sheet.css" allow SecFilterSelective REQUEST_URI "^/button.php" allow SecFilterSelective REQUEST_URI "^/index.htm" allow SecFilterSelective REQUEST_URI "^/mls_auction_bidding_info.htm" allow SecFilterSelective REQUEST_URI "^/mls_breakin_attempt.php" allow SecFilterSelective REQUEST_URI "^/mls_contact_sales_dept.htm" allow SecFilterSelective REQUEST_URI "^/mls_fsbo_forgot_logon.php" allow SecFilterSelective REQUEST_URI "^/mls_fsbo_listing_info.htm" allow SecFilterSelective REQUEST_URI "^/mls_fsbo_logon.php" allow SecFilterSelective REQUEST_URI "^/mls_fsbo_member_update.php" allow SecFilterSelective REQUEST_URI "^/mls_fsbo_menu.php" allow SecFilterSelective REQUEST_URI "^/mls_fsbo_signup.php" allow SecFilterSelective REQUEST_URI "^/mls_fsbo_terminate_member1.php" allow SecFilterSelective REQUEST_URI "^/mls_fsbo_terminate_member2.php" allow SecFilterSelective REQUEST_URI "^/mls_home_page.php" allow SecFilterSelective REQUEST_URI "^/mls_std_exit.php" allow SecFilterSelective REQUEST_URI "^/mls_verifyemail.php" allow SecFilterSelective REQUEST_URI "^/mls_verifyemail0.php" allow SecFilter "." 3) Even with these rules, this will not provide total protection. What happens if there is a new PHP exploit for your mls_verifyemail0.php script? The rules above will not protect against this. It is for this reason that the "exclusive", blacklist rules should be listed BEFORE these whitelist rules. These attacks signatures will be processed prior to these rules and check for common exploit issues (meta-characthers, directory traversal, command execution, etc...). If these rules are specified AFTER the rules above, they will be skipped with the "allow" directive. Hope this helps. -- Ryan C. Barnett Web Application Security Consortium (WASC) Member CIS Apache Benchmark Project Lead SANS Instructor: Securing Apache GCIA, GCFA, GCIH, GSNA, GCUX, GSEC Author: Preventing Web Attacks with Apache On 4/10/06, joe barbish <joe...@ya...> wrote: > > mod_security enhancement idea > > > In software packet firewalls there are 2 different types of filter rule > sets. > > The exclusive firewall and the inclusive firewall. This is well documente= d > in the FreeBSD manual firewall section. > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls.html > > An exclusive firewall allows all packets through except for those matchin= g > a set of rules that block certain packets, (IE, default pass all). > > An inclusive firewall does the reverse. It only allows packets matching > the rules through and blocks everything else, (IE, default deny all). > Inclusive firewalls are much, much securer than exclusive firewalls and > simpler to code. > > Applying that concept to the mod_security filter rules I see explained in > the manual and the examples provided at the mod_security home page it bec= ame > very obvious that mod_security defaults to an exclusive type of firewall= . > Rules are used to code the particular signatures of malice attempts to > circumvent the normal standard http processes of a web server. > > This is fine if you are an internet security expert and want to analyze > and capture the different methods used by attackers of web application. > Mod_security is the perfectly designed tool for this task. > > But for the user who is looking for a simple user friendly web server > firewall to block all the currently know & future malice attack methods > while allowing his web application to pass unmolested does not readily fi= nd > this available in mod_security. > > Now don't take me wrong, it is possible to configure an mod_security rule > set that address the technical part of the stated goal, but the simple & > user friendly part is by no means met as shown in the following example. = All > the scripts used in the web application are coded by individual rules. > > > secfilterengine on > secfiltercheckurlencoding on > secfiltercheckunicodeencoding off > secfilterforcebyterange 0 255 > secfilterscanpost on > SecFilterDefaultAction deny,log,status:404 > > SecFilterSelective REQUEST_URI "!^/00.00_Header.htm" chai= n > SecFilterSelective REQUEST_URI "!^/00.00_Header.php" chai= n > SecFilterSelective REQUEST_URI "!^/00.00-web_style_sheet.css" chai= n > SecFilterSelective REQUEST_URI "!^/button.php" chai= n > > SecFilterSelective REQUEST_URI "!^/index.htm" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_auction_bidding_info.htm" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_breakin_attempt.php" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_contact_sales_dept.htm" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_fsbo_forgot_logon.php" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_fsbo_listing_info.htm" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_fsbo_logon.php" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_fsbo_member_update.php" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_fsbo_menu.php" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_fsbo_signup.php" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_fsbo_terminate_member1.php" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_fsbo_terminate_member2.php" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_home_page.php" chai= n > SecFilterSelective REQUEST_URI "!^/mls_std_exit.php" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_verifyemail.php" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_verifyemail0.php" > > > In some programming circles this would be called a reverse polish coding > technique. > > This is not simple coding logic and this technique is not documented or > even hinted at in the manual. But it does fulfill the stated technical go= al > requirement of blocking all currently know and unknown malice attack meth= ods > while allowing the web application to pass unmolested. As a side benefit = not > only does the above example pass the users normal web traffic but it also > allows search engine robot traffic to pass as they inventory the website = for > indexing. > > Security can be tightened further by coding all the script names using > this rule format > > SecFilterSelective SCRIPT_FILENAME > "!^/usr/local/www/data/mls_Read_forgot_logon_email.php" chain > > This would stop all search engine traffic because they do not include the > path in their requests. > > > > The usefulness of mod_security can be increased while becoming more user > friendly by making few tweaks to mod_security's source code. > > > What I purpose is this, > > Change secfilterengine on|off to > > > secfilterengine on_exclusive | on_inclusive | off > > > on_exclusive =3D (defaults to allow all) which is how mod_security > currently functions > > on_inclusive =3D (defaults to block all) > > This would then allow the above example rules to be re-coded like this: > > SecFilterSelective REQUEST_URI "^/00.00_Header.htm" SecFi= lterSelective > REQUEST_URI "^/00.00_Header.php" SecFilterSelective > REQUEST_URI "^/00.00-web_style_sheet.css" > SecFilterSelective REQUEST_URI "^/button.php" > SecFilterSelective REQUEST_URI "^/class.phpmailer.php" > SecFilterSelective REQUEST_URI "^/index.htm" > > Where a match means pass the packet to the web server and any non-matches > get passed to what ever SecFilterDefaultAction deny,log,status:404 says > to do. > > To an non-technical user this is straight forward and makes logical sense= s > when read. > The concept of only having to add a rule for each script that makes up th= e > web application requires no technical comprehension of how an web server > processes requests and is really on target for the general home hobbyist > level of understanding and needs. And of course the mod_security manual > would need a major rewrite to include this new function. > > > I post this for discussion by members of this list who have more knowledg= e > of mod_security internals and usage background in hopes of achieving > agreement on making this an official enhancement request. > > > > ------------------------------ > New Yahoo! Messenger with Voice. Call regular phones from your PC<http://= us.rd.yahoo.com/mail_us/taglines/postman5/*http://us.rd.yahoo.com/evt=3D396= 66/*http://beta.messenger.yahoo.com>and save big. > > |
|
From: joe b. <joe...@ya...> - 2006-04-11 15:53:41
|
Ryan
Thanks for the help.
But I don't understand some thing you said.
You said that SecFilter "." will deny everything then you say "What happens if there is a new PHP exploit for your mls_verifyemail0.php script? The rules above will not protect against this."
The whole idea of the rules is to control what is allowed to pass.
The SecFilter "." is suppose to deny everything. Everything means anything which is not one of the coded 'accept' rules, including all known and un-known exploits.
If SecFilter "." is not the correct rule to deny everything then what rule will?
Ryan Barnett <rcb...@gm...> wrote:
Joe,
A few quick comments -
1) You really don't need a new directive/option to get what you are looking for. Keeping with your firewall concept, in order to get an inclusive ruleset, you first need to implement a catch-all deny rule that would block all requests. In mod_security it would be this - SecFilter ".". This would match any request and then take the action that you specified in the SecFilterDefaultAction rule. The next step is to create a whitelist of filters that will match allowed, acceptable requests. This is what you are attempting to do in your post with the mod_security inverted filters.
2) Your examples of inverted filters will not work correctly with the chain action. The chain feature will create a larger, complex check on the request. In your examples, you tried to chain all of the acceptable URLs together. The problem is that all of those files will never be requested within one sigle request packet. The mod_security action that you should use is "allow" to tell mod_security to allow the request through and the final filter is the catch-all deny. Here is an updated ruleset for you -
SecFilterSelective REQUEST_URI "^/00.00_Header.htm" allow
SecFilterSelective REQUEST_URI "^/00.00_Header.php" allow
SecFilterSelective REQUEST_URI "^/00.00-web_style_sheet.css" allow
SecFilterSelective REQUEST_URI "^/button.php" allow
SecFilterSelective REQUEST_URI "^/index.htm" allow
SecFilterSelective REQUEST_URI "^/mls_auction_bidding_info.htm" allow
SecFilterSelective REQUEST_URI "^/mls_breakin_attempt.php" allow
SecFilterSelective REQUEST_URI "^/mls_contact_sales_dept.htm" allow
SecFilterSelective REQUEST_URI "^/mls_fsbo_forgot_logon.php" allow
SecFilterSelective REQUEST_URI "^/mls_fsbo_listing_info.htm" allow
SecFilterSelective REQUEST_URI "^/mls_fsbo_logon.php" allow
SecFilterSelective REQUEST_URI "^/mls_fsbo_member_update.php" allow
SecFilterSelective REQUEST_URI "^/mls_fsbo_menu.php" allow
SecFilterSelective REQUEST_URI "^/mls_fsbo_signup.php" allow
SecFilterSelective REQUEST_URI "^/mls_fsbo_terminate_member1.php" allow
SecFilterSelective REQUEST_URI "^/mls_fsbo_terminate_member2.php" allow
SecFilterSelective REQUEST_URI "^/mls_home_page.php" allow
SecFilterSelective REQUEST_URI "^/mls_std_exit.php" allow
SecFilterSelective REQUEST_URI "^/mls_verifyemail.php" allow
SecFilterSelective REQUEST_URI "^/mls_verifyemail0.php" allow
SecFilter "."
3) Even with these rules, this will not provide total protection. What happens if there is a new PHP exploit for your mls_verifyemail0.php script? The rules above will not protect against this. It is for this reason that the "exclusive", blacklist rules should be listed BEFORE these whitelist rules. These attacks signatures will be processed prior to these rules and check for common exploit issues (meta-characthers, directory traversal, command execution, etc...). If these rules are specified AFTER the rules above, they will be skipped with the "allow" directive.
Hope this helps.
--
Ryan C. Barnett
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor: Securing Apache
GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache
On 4/10/06, joe barbish <joe...@ya...> wrote: mod_security enhancement idea
In software packet firewalls there are 2 different types of filter rule sets.
The exclusive firewall and the inclusive firewall. This is well documented in the FreeBSD manual firewall section.
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls.html
An exclusive firewall allows all packets through except for those matching a set of rules that block certain packets, (IE, default pass all).
An inclusive firewall does the reverse. It only allows packets matching the rules through and blocks everything else, (IE, default deny all). Inclusive firewalls are much, much securer than exclusive firewalls and simpler to code.
Applying that concept to the mod_security filter rules I see explained in the manual and the examples provided at the mod_security home page it became very obvious that mod_security defaults to an exclusive type of firewall. Rules are used to code the particular signatures of malice attempts to circumvent the normal standard http processes of a web server.
This is fine if you are an internet security expert and want to analyze and capture the different methods used by attackers of web application. Mod_security is the perfectly designed tool for this task.
But for the user who is looking for a simple user friendly web server firewall to block all the currently know & future malice attack methods while allowing his web application to pass unmolested does not readily find this available in mod_security.
Now don't take me wrong, it is possible to configure an mod_security rule set that address the technical part of the stated goal, but the simple & user friendly part is by no means met as shown in the following example. All the scripts used in the web application are coded by individual rules.
secfilterengine on
secfiltercheckurlencoding on
secfiltercheckunicodeencoding off
secfilterforcebyterange 0 255
secfilterscanpost on
SecFilterDefaultAction deny,log,status:404
SecFilterSelective REQUEST_URI "!^/00.00_Header.htm" chain
SecFilterSelective REQUEST_URI "!^/00.00_Header.php" chain
SecFilterSelective REQUEST_URI "!^/00.00-web_style_sheet.css" chain
SecFilterSelective REQUEST_URI "!^/button.php" chain
SecFilterSelective REQUEST_URI "!^/index.htm" chain
SecFilterSelective REQUEST_URI "!^/mls_auction_bidding_info.htm" chain
SecFilterSelective REQUEST_URI "!^/mls_breakin_attempt.php" chain
SecFilterSelective REQUEST_URI "!^/mls_contact_sales_dept.htm" chain
SecFilterSelective REQUEST_URI "!^/mls_fsbo_forgot_logon.php" chain
SecFilterSelective REQUEST_URI "!^/mls_fsbo_listing_info.htm" chain
SecFilterSelective REQUEST_URI "!^/mls_fsbo_logon.php" chain
SecFilterSelective REQUEST_URI "!^/mls_fsbo_member_update.php" chain
SecFilterSelective REQUEST_URI "!^/mls_fsbo_menu.php" chain
SecFilterSelective REQUEST_URI "!^/mls_fsbo_signup.php" chain
SecFilterSelective REQUEST_URI "!^/mls_fsbo_terminate_member1.php" chain
SecFilterSelective REQUEST_URI "!^/mls_fsbo_terminate_member2.php" chain
SecFilterSelective REQUEST_URI "!^/mls_home_page.php" chain
SecFilterSelective REQUEST_URI "!^/mls_std_exit.php" chain
SecFilterSelective REQUEST_URI "!^/mls_verifyemail.php" chain
SecFilterSelective REQUEST_URI "!^/mls_verifyemail0.php"
In some programming circles this would be called a reverse polish coding technique.
This is not simple coding logic and this technique is not documented or even hinted at in the manual. But it does fulfill the stated technical goal requirement of blocking all currently know and unknown malice attack methods while allowing the web application to pass unmolested. As a side benefit not only does the above example pass the users normal web traffic but it also allows search engine robot traffic to pass as they inventory the website for indexing.
Security can be tightened further by coding all the script names using this rule format
SecFilterSelective SCRIPT_FILENAME "!^/usr/local/www/data/mls_Read_forgot_logon_email.php" chain
This would stop all search engine traffic because they do not include the path in their requests.
The usefulness of mod_security can be increased while becoming more user friendly by making few tweaks to mod_security's source code.
What I purpose is this,
Change secfilterengine on|off to
secfilterengine on_exclusive | on_inclusive | off
on_exclusive = (defaults to allow all) which is how mod_security currently functions
on_inclusive = (defaults to block all)
This would then allow the above example rules to be re-coded like this:
SecFilterSelective REQUEST_URI "^/00.00_Header.htm" SecFilterSelective REQUEST_URI "^/00.00_Header.php" SecFilterSelective REQUEST_URI "^/00.00-web_style_sheet.css"
SecFilterSelective REQUEST_URI "^/button.php"
SecFilterSelective REQUEST_URI "^/class.phpmailer.php"
SecFilterSelective REQUEST_URI "^/index.htm"
Where a match means pass the packet to the web server and any non-matches get passed to what ever SecFilterDefaultAction deny,log,status:404 says to do.
To an non-technical user this is straight forward and makes logical senses when read.
The concept of only having to add a rule for each script that makes up the web application requires no technical comprehension of how an web server processes requests and is really on target for the general home hobbyist level of understanding and needs. And of course the mod_security manual would need a major rewrite to include this new function.
I post this for discussion by members of this list who have more knowledge of mod_security internals and usage background in hopes of achieving agreement on making this an official enhancement request.
---------------------------------
New Yahoo! Messenger with Voice. Call regular phones from your PC and save big.
---------------------------------
Love cheap thrills? Enjoy PC-to-Phone calls to 30+ countries for just 2¢/min with Yahoo! Messenger with Voice. |
|
From: Tom A. <tan...@oa...> - 2006-04-11 16:03:08
|
joe barbish wrote: > The SecFilter "." is suppose to deny everything. Everything means > anything which is not one of the coded 'accept' rules, including all > known and un-known exploits. SecFilter "." will deny everything, but SecFilterSelective REQUEST_URI "^/index.php" allow will allow any possible exploits against index.php. If you want to protect index.php against, for example, directory traversals, then you'll want to add something like: SecFilter "\.\./" Or if you want to protect index.php against, for example, deceptive user agent strings, you'll want to add something like: SecFilterSelective "HTTP_USER_AGENT|HTTP_REFERER" "^-$" The point being that your "allow" string opens up the allowed page to any and all attacks. You still need exclusionary filters. Tom |
|
From: Ryan B. <rcb...@gm...> - 2006-04-11 16:16:52
|
VGhlIHByb2JsZW0gaXMgdGhhdCB0aGUgd2hpdGVsaXN0IGZpbHRlcnMgdGhhdCB5b3UgYXJlIGNy ZWF0aW5nIGFyZSBmb2N1c2luZwppbiB0aGUgcmVxdWVzdGVkIGZpbGVuYW1lIGFuZCB0aGF0IGlz IGFsbC4gIFRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIHZhc3QKbWFqb3JpdHkgb2Ygd2ViIGF0dGFj a3Mgb2NjdXIgaW4gdGhlIFFVRVJZX1NUUklORyBsb2NhdGlvbiBvZiB0aGUgcmVxdWVzdAphbmQg bm90IHRoZSBmaWxlbmFtZSBpdHNlbGYuCgpIZXJlIGlzIGFuIGV4YW1wbGUgKGFsYmVpdCBvbGQp IC0KVGhlIGlzIGEgbGluayB0byB3ZWIgbG9nIGRhdGEgb2YgYSByZWFsIHdlYiBkZWZhY2VtZW50 IHdoZXJlIHRoZSBhdHRhY2tlcgpleHBsb2l0ZWQgdGVoIFVsdGltYXRlIEJ1bGxldGluIEJvYXJk IENHSSBzY3JpcHQgLQpodHRwOi8vd3d3LmluZm9yZWFkaW5nLmNvbS9saWJyYXJ5L2luZm9hcnRp Y2xlcy9JbmZvUmVhZGluZy9sb2dzL2RlZmFjZS8wMS50eHQKCkFib3V0IDMvNCBvZiB0aGUgd2F5 IGRvd24gaW4gdGhlIGxvZ3MsIHlvdSB3aWxsIHNlZSB0aGlzIHJlcXVlc3QgLQoKMjEzLjEzMi42 Ny4xODkgLSAtIFsxNS9EZWMvMjAwMDoxODowMzoxNyAtMDYwMF0gIkdFVAovYm9hcmQvL3Bvc3Rp bmdzLmNnaT9hY3Rpb249cmVwbHkmZm9ydW09Z2Vla291dCZudW1iZXI9MSZ0b3BpYz0wMDAwNjMq Ci58bHlueCUyMC1zb3VyY2UlMjBodHRwOi8vd3d3LmdhbGFrdGljYS5vcmcvcGFnZTEuY2dpJTIw PiUyMHViYnRlc3QuY2dpfG1haWwlMjBtaXN0X2VyQApyYW1ibGVyLnJ1fCogSFRUUC8xLjEiIDIw MCA1NDY1ICItIiAiTW96aWxsYS80LjAgKGNvbXBhdGlibGU7IE1TSUUgNS4wMTsKV2luZG93cyBO VCA1LjApIgoKQXMgeW91IGNhbiBzZWUsIHRoZSBhdHRhY2tlciB1c2VkIHRoZSAifCIgY2hhcmFj dGVyIGluIHRoZSAidG9waWMiIGFyZ3VlbWVudAp0byBydW4gYW4gY29tbWFuZCBpbmplY3Rpb24g YXR0YWNrLgoKTm93LCBsZXQncyBpbWFnaW5lIHRoYXQgeW91IHdlcmUgdXNpbmcgdGhpcyBzYW1l IENHSSBzY3JpcHQgYW5kIHdhbnRlZCB0bwppbXBsZW1lbnQgc29tZSBtb2Rfc2VjdXJpdHkgcnVs ZXMgdG8gcHJldmVudCB0aGlzIGF0dGFjay4gIFRoZSBmb2xsb3dpbmcKcnVsZSBhbG9uZSB3b3Vs ZCBub3QgcHJldmVudCB0aGUgYXR0YWNrIC0KClNlY0ZpbHRlclNlbGVjdGl2ZSBSRVFVRVNUX1VS SSAiXi9ib2FyZC9wb3N0aW5ncy5jZ2kkIiBhbGxvdwoKVGhpcyB3b3VsZCBub3QgcHJldmVudCB0 aGlzIGF0dGFja3Mgc2luY2UgdGhlIHNjcmlwdCBpcyBhbGxvd2VkLCBob3dldmVyIGl0CmlzIHRo ZSBhcmd1ZW1lbnQgZGF0YSB0aGF0IGlzIHRoZSBwcm9ibGVtLiAgSWYgbW9kX3NlY3VyaXR5IHdl cmUgdG8gcHJvY2Vzcwp0aGUgcmVxdWVzdCBhYm92ZSwgaXQgd291bGQgaGl0IHRoaXMgcnVsZSBh bmQgdGhlbiBleHBsaWNpdGx5IGFsbG93IGl0LCB0aHVzCm5vdCBwcm9jZXNzaW5nIHRoZSBmaW5h bCBTZWNGaWx0ZXIgZGVueSBhbGwgcnVsZS4KClRoaXMgaXMgd2h5IHlvdSBuZWVkIHRvIGluY2x1 ZGUgc29tZSBvdGhlciB3aGl0ZWxpc3RpbmcvYWxsb3dlZCBmaWx0ZXJzIGZvcgphbGwgc2NyaXB0 cyB0aGF0IHdpbGwgcHJvY2VzcyBkeW5hbWljIGRhdGEgZnJvbSB0aGUgY2xpZW50LiAgWW91IHNo b3VsZApjcmVhdGUgYW4gaW52ZXJ0ZWQgZmlsdGVyIHRoYXQgd2lsbCBvbmx5IGFsbG93IGFjY2Vw dGFibGUgY2hhcmFjdGVycyBpbiB5b3VyClFVRVJZX1NUUklORyBzdWNoIGFzOyBfLCAtLCA9LCAm LCBldGMuLi4KCkRvZXMgdGhpcyBtYWtlIG1vcmUgc2Vuc2U/CgotLQpSeWFuIEMuIEJhcm5ldHQK V2ViIEFwcGxpY2F0aW9uIFNlY3VyaXR5IENvbnNvcnRpdW0gKFdBU0MpIE1lbWJlcgpDSVMgQXBh Y2hlIEJlbmNobWFyayBQcm9qZWN0IExlYWQKU0FOUyBJbnN0cnVjdG9yOiBTZWN1cmluZyBBcGFj aGUKR0NJQSwgR0NGQSwgR0NJSCwgR1NOQSwgR0NVWCwgR1NFQwpBdXRob3I6IFByZXZlbnRpbmcg V2ViIEF0dGFja3Mgd2l0aCBBcGFjaGUKCk9uIDQvMTEvMDYsIGpvZSBiYXJiaXNoIDxqb2ViXzcy MkB5YWhvby5jb20+IHdyb3RlOgo+Cj4gIFJ5YW4KPiBUaGFua3MgZm9yIHRoZSBoZWxwLgo+Cj4g QnV0IEkgZG9uJ3QgdW5kZXJzdGFuZCBzb21lIHRoaW5nIHlvdSBzYWlkLgo+Cj4gWW91IHNhaWQg dGhhdCAgIFNlY0ZpbHRlciAiLiIgIHdpbGwgZGVueSBldmVyeXRoaW5nICB0aGVuIHlvdSBzYXkg ICJXaGF0Cj4gaGFwcGVucyBpZiB0aGVyZSBpcyBhIG5ldyBQSFAgZXhwbG9pdCBmb3IgeW91ciBt bHNfdmVyaWZ5ZW1haWwwLnBocCBzY3JpcHQ/Cj4gVGhlIHJ1bGVzIGFib3ZlIHdpbGwgbm90IHBy b3RlY3QgYWdhaW5zdCB0aGlzLiIKPgo+IFRoZSB3aG9sZSBpZGVhIG9mIHRoZSBydWxlcyBpcyB0 byBjb250cm9sIHdoYXQgaXMgYWxsb3dlZCB0byBwYXNzLgo+Cj4gVGhlIFNlY0ZpbHRlciAiLiIg ICBpcyBzdXBwb3NlIHRvIGRlbnkgZXZlcnl0aGluZy4gIEV2ZXJ5dGhpbmcgbWVhbnMKPiBhbnl0 aGluZyB3aGljaCBpcyBub3Qgb25lIG9mIHRoZSBjb2RlZCAnYWNjZXB0JyBydWxlcywgaW5jbHVk aW5nIGFsbCBrbm93bgo+IGFuZCB1bi1rbm93biBleHBsb2l0cy4KPgo+IElmIFNlY0ZpbHRlciAi LiIgICBpcyBub3QgdGhlIGNvcnJlY3QgcnVsZSB0byBkZW55IGV2ZXJ5dGhpbmcgdGhlbiB3aGF0 Cj4gcnVsZSB3aWxsPwo+Cj4KPgo+Cj4KPiAqUnlhbiBCYXJuZXR0IDxyY2Jhcm5ldHRAZ21haWwu Y29tPiogd3JvdGU6Cj4KPiBKb2UsCj4gQSBmZXcgcXVpY2sgY29tbWVudHMgLQo+Cj4gMSkgWW91 IHJlYWxseSBkb24ndCBuZWVkIGEgbmV3IGRpcmVjdGl2ZS9vcHRpb24gdG8gZ2V0IHdoYXQgeW91 IGFyZQo+IGxvb2tpbmcgZm9yLiAgS2VlcGluZyB3aXRoIHlvdXIgZmlyZXdhbGwgY29uY2VwdCwg aW4gb3JkZXIgdG8gZ2V0IGFuCj4gaW5jbHVzaXZlIHJ1bGVzZXQsIHlvdSBmaXJzdCBuZWVkIHRv IGltcGxlbWVudCBhIGNhdGNoLWFsbCBkZW55IHJ1bGUgdGhhdAo+IHdvdWxkIGJsb2NrIGFsbCBy ZXF1ZXN0cy4gIEluIG1vZF9zZWN1cml0eSBpdCB3b3VsZCBiZSB0aGlzIC0gU2VjRmlsdGVyCj4g Ii4iLiAgVGhpcyB3b3VsZCBtYXRjaCBhbnkgcmVxdWVzdCBhbmQgdGhlbiB0YWtlIHRoZSBhY3Rp b24gdGhhdCB5b3UKPiBzcGVjaWZpZWQgaW4gdGhlIFNlY0ZpbHRlckRlZmF1bHRBY3Rpb24gcnVs ZS4gIFRoZSBuZXh0IHN0ZXAgaXMgdG8gY3JlYXRlIGEKPiB3aGl0ZWxpc3Qgb2YgZmlsdGVycyB0 aGF0IHdpbGwgbWF0Y2ggYWxsb3dlZCwgYWNjZXB0YWJsZSByZXF1ZXN0cy4gIFRoaXMgaXMKPiB3 aGF0IHlvdSBhcmUgYXR0ZW1wdGluZyB0byBkbyBpbiB5b3VyIHBvc3Qgd2l0aCB0aGUgbW9kX3Nl Y3VyaXR5IGludmVydGVkCj4gZmlsdGVycy4KPgo+IDIpIFlvdXIgZXhhbXBsZXMgb2YgaW52ZXJ0 ZWQgZmlsdGVycyB3aWxsIG5vdCB3b3JrIGNvcnJlY3RseSB3aXRoIHRoZQo+IGNoYWluIGFjdGlv bi4gIFRoZSBjaGFpbiBmZWF0dXJlIHdpbGwgY3JlYXRlIGEgbGFyZ2VyLCBjb21wbGV4IGNoZWNr IG9uIHRoZQo+IHJlcXVlc3QuICBJbiB5b3VyIGV4YW1wbGVzLCB5b3UgdHJpZWQgdG8gY2hhaW4g YWxsIG9mIHRoZSBhY2NlcHRhYmxlIFVSTHMKPiB0b2dldGhlci4gIFRoZSBwcm9ibGVtIGlzIHRo YXQgYWxsIG9mIHRob3NlIGZpbGVzIHdpbGwgbmV2ZXIgYmUgcmVxdWVzdGVkCj4gd2l0aGluIG9u ZSBzaWdsZSByZXF1ZXN0IHBhY2tldC4gIFRoZSBtb2Rfc2VjdXJpdHkgYWN0aW9uIHRoYXQgeW91 IHNob3VsZAo+IHVzZSBpcyAiYWxsb3ciIHRvIHRlbGwgbW9kX3NlY3VyaXR5IHRvIGFsbG93IHRo ZSByZXF1ZXN0IHRocm91Z2ggYW5kIHRoZQo+IGZpbmFsIGZpbHRlciBpcyB0aGUgY2F0Y2gtYWxs IGRlbnkuICBIZXJlIGlzIGFuIHVwZGF0ZWQgcnVsZXNldCBmb3IgeW91IC0KPgo+ICBTZWNGaWx0 ZXJTZWxlY3RpdmUgUkVRVUVTVF9VUkkgIl4vMDAuMDBfSGVhZGVyLmh0bSIgYWxsb3cKPiBTZWNG aWx0ZXJTZWxlY3RpdmUgUkVRVUVTVF9VUkkgIl4vMDAuMDBfSGVhZGVyLnBocCIgYWxsb3cKPiBT ZWNGaWx0ZXJTZWxlY3RpdmUgUkVRVUVTVF9VUkkgIl4vMDAuMDAtd2ViX3N0eWxlX3NoZWV0LmNz cyIgYWxsb3cKPiBTZWNGaWx0ZXJTZWxlY3RpdmUgUkVRVUVTVF9VUkkgIl4vYnV0dG9uLnBocCIg YWxsb3cKPiBTZWNGaWx0ZXJTZWxlY3RpdmUgUkVRVUVTVF9VUkkgIl4vaW5kZXguaHRtIiBhbGxv dwo+IFNlY0ZpbHRlclNlbGVjdGl2ZSBSRVFVRVNUX1VSSSAiXi9tbHNfYXVjdGlvbl9iaWRkaW5n X2luZm8uaHRtIiAgYWxsb3cKPiBTZWNGaWx0ZXJTZWxlY3RpdmUgUkVRVUVTVF9VUkkgIl4vbWxz X2JyZWFraW5fYXR0ZW1wdC5waHAiICAgYWxsb3cKPiBTZWNGaWx0ZXJTZWxlY3RpdmUgUkVRVUVT VF9VUkkgIl4vbWxzX2NvbnRhY3Rfc2FsZXNfZGVwdC5odG0iICBhbGxvdwo+IFNlY0ZpbHRlclNl bGVjdGl2ZSBSRVFVRVNUX1VSSSAiXi9tbHNfZnNib19mb3Jnb3RfbG9nb24ucGhwIiAgYWxsb3cK PiBTZWNGaWx0ZXJTZWxlY3RpdmUgUkVRVUVTVF9VUkkgIl4vbWxzX2ZzYm9fbGlzdGluZ19pbmZv Lmh0bSIgIGFsbG93Cj4gU2VjRmlsdGVyU2VsZWN0aXZlIFJFUVVFU1RfVVJJICJeL21sc19mc2Jv X2xvZ29uLnBocCIgIGFsbG93Cj4gU2VjRmlsdGVyU2VsZWN0aXZlIFJFUVVFU1RfVVJJICJeL21s c19mc2JvX21lbWJlcl91cGRhdGUucGhwIiAgYWxsb3cKPiBTZWNGaWx0ZXJTZWxlY3RpdmUgUkVR VUVTVF9VUkkgIl4vbWxzX2ZzYm9fbWVudS5waHAiICAgYWxsb3cKPiBTZWNGaWx0ZXJTZWxlY3Rp dmUgUkVRVUVTVF9VUkkgIl4vbWxzX2ZzYm9fc2lnbnVwLnBocCIgIGFsbG93Cj4gU2VjRmlsdGVy U2VsZWN0aXZlIFJFUVVFU1RfVVJJICJeL21sc19mc2JvX3Rlcm1pbmF0ZV9tZW1iZXIxLnBocCIg YWxsb3cKPiBTZWNGaWx0ZXJTZWxlY3RpdmUgUkVRVUVTVF9VUkkgIl4vbWxzX2ZzYm9fdGVybWlu YXRlX21lbWJlcjIucGhwIiBhbGxvdwo+IFNlY0ZpbHRlclNlbGVjdGl2ZSBSRVFVRVNUX1VSSSAi Xi9tbHNfaG9tZV9wYWdlLnBocCIgICBhbGxvdwo+IFNlY0ZpbHRlclNlbGVjdGl2ZSBSRVFVRVNU X1VSSSAiXi9tbHNfc3RkX2V4aXQucGhwIiAgIGFsbG93Cj4gU2VjRmlsdGVyU2VsZWN0aXZlIFJF UVVFU1RfVVJJICJeL21sc192ZXJpZnllbWFpbC5waHAiICAgYWxsb3cKPiBTZWNGaWx0ZXJTZWxl Y3RpdmUgUkVRVUVTVF9VUkkgIl4vbWxzX3ZlcmlmeWVtYWlsMC5waHAiIGFsbG93Cj4gU2VjRmls dGVyICIuIgo+Cj4gMykgRXZlbiB3aXRoIHRoZXNlIHJ1bGVzLCB0aGlzIHdpbGwgbm90IHByb3Zp ZGUgdG90YWwgcHJvdGVjdGlvbi4gIFdoYXQKPiBoYXBwZW5zIGlmIHRoZXJlIGlzIGEgbmV3IFBI UCBleHBsb2l0IGZvciB5b3VyIG1sc192ZXJpZnllbWFpbDAucGhwIHNjcmlwdD8KPiBUaGUgcnVs ZXMgYWJvdmUgd2lsbCBub3QgcHJvdGVjdCBhZ2FpbnN0IHRoaXMuICBJdCBpcyBmb3IgdGhpcyBy ZWFzb24gdGhhdAo+IHRoZSAiZXhjbHVzaXZlIiwgYmxhY2tsaXN0IHJ1bGVzIHNob3VsZCBiZSBs aXN0ZWQgQkVGT1JFIHRoZXNlIHdoaXRlbGlzdAo+IHJ1bGVzLiAgVGhlc2UgYXR0YWNrcyBzaWdu YXR1cmVzIHdpbGwgYmUgcHJvY2Vzc2VkIHByaW9yIHRvIHRoZXNlIHJ1bGVzIGFuZAo+IGNoZWNr IGZvciBjb21tb24gZXhwbG9pdCBpc3N1ZXMgKG1ldGEtY2hhcmFjdGhlcnMsIGRpcmVjdG9yeSB0 cmF2ZXJzYWwsCj4gY29tbWFuZCBleGVjdXRpb24sIGV0Yy4uLikuICBJZiB0aGVzZSBydWxlcyBh cmUgc3BlY2lmaWVkIEFGVEVSIHRoZSBydWxlcwo+IGFib3ZlLCB0aGV5IHdpbGwgYmUgc2tpcHBl ZCB3aXRoIHRoZSAiYWxsb3ciIGRpcmVjdGl2ZS4KPgo+IEhvcGUgdGhpcyBoZWxwcy4KPgo+IC0t Cj4gUnlhbiBDLiBCYXJuZXR0Cj4gV2ViIEFwcGxpY2F0aW9uIFNlY3VyaXR5IENvbnNvcnRpdW0g KFdBU0MpIE1lbWJlcgo+IENJUyBBcGFjaGUgQmVuY2htYXJrIFByb2plY3QgTGVhZAo+IFNBTlMg SW5zdHJ1Y3RvcjogU2VjdXJpbmcgQXBhY2hlCj4gR0NJQSwgR0NGQSwgR0NJSCwgR1NOQSwgR0NV WCwgR1NFQwo+IEF1dGhvcjogUHJldmVudGluZyBXZWIgQXR0YWNrcyB3aXRoIEFwYWNoZQo+Cj4K PiBPbiA0LzEwLzA2LCBqb2UgYmFyYmlzaCA8am9lYl83MjJAeWFob28uY29tPiB3cm90ZToKPiA+ Cj4gPiAgbW9kX3NlY3VyaXR5IGVuaGFuY2VtZW50IGlkZWEKPiA+Cj4gPgo+ID4gSW4gc29mdHdh cmUgcGFja2V0IGZpcmV3YWxscyB0aGVyZSBhcmUgMiBkaWZmZXJlbnQgdHlwZXMgb2YgZmlsdGVy IHJ1bGUKPiA+IHNldHMuCj4gPgo+ID4gVGhlIGV4Y2x1c2l2ZSBmaXJld2FsbCBhbmQgdGhlIGlu Y2x1c2l2ZSBmaXJld2FsbC4gVGhpcyBpcyB3ZWxsCj4gPiBkb2N1bWVudGVkIGluIHRoZSBGcmVl QlNEIG1hbnVhbCBmaXJld2FsbCBzZWN0aW9uLgo+ID4KPiA+ICBodHRwOi8vd3d3LmZyZWVic2Qu b3JnL2RvYy9lbl9VUy5JU084ODU5LTEvYm9va3MvaGFuZGJvb2svZmlyZXdhbGxzLmh0bWwKPiA+ Cj4gPiBBbiBleGNsdXNpdmUgZmlyZXdhbGwgYWxsb3dzIGFsbCBwYWNrZXRzIHRocm91Z2ggZXhj ZXB0IGZvciB0aG9zZQo+ID4gbWF0Y2hpbmcgYSBzZXQgb2YgcnVsZXMgdGhhdCBibG9jayBjZXJ0 YWluIHBhY2tldHMsIChJRSwgZGVmYXVsdCBwYXNzIGFsbCkuCj4gPgo+ID4KPiA+IEFuIGluY2x1 c2l2ZSBmaXJld2FsbCBkb2VzIHRoZSByZXZlcnNlLiBJdCBvbmx5IGFsbG93cyBwYWNrZXRzIG1h dGNoaW5nCj4gPiB0aGUgcnVsZXMgdGhyb3VnaCBhbmQgYmxvY2tzIGV2ZXJ5dGhpbmcgZWxzZSwg KElFLCBkZWZhdWx0IGRlbnkgYWxsKS4KPiA+IEluY2x1c2l2ZSBmaXJld2FsbHMgYXJlIG11Y2gs IG11Y2ggc2VjdXJlciB0aGFuIGV4Y2x1c2l2ZSBmaXJld2FsbHMgYW5kCj4gPiBzaW1wbGVyIHRv IGNvZGUuCj4gPgo+ID4gQXBwbHlpbmcgdGhhdCBjb25jZXB0IHRvIHRoZSBtb2Rfc2VjdXJpdHkg ZmlsdGVyIHJ1bGVzIEkgc2VlIGV4cGxhaW5lZAo+ID4gaW4gdGhlIG1hbnVhbCBhbmQgdGhlIGV4 YW1wbGVzIHByb3ZpZGVkIGF0IHRoZSBtb2Rfc2VjdXJpdHkgaG9tZSBwYWdlIGl0Cj4gPiBiZWNh bWUgdmVyeSBvYnZpb3VzIHRoYXQgICBtb2Rfc2VjdXJpdHkgZGVmYXVsdHMgdG8gYW4gZXhjbHVz aXZlIHR5cGUgb2YKPiA+IGZpcmV3YWxsLiBSdWxlcyBhcmUgdXNlZCB0byBjb2RlIHRoZSBwYXJ0 aWN1bGFyIHNpZ25hdHVyZXMgb2YgbWFsaWNlCj4gPiBhdHRlbXB0cyB0byBjaXJjdW12ZW50IHRo ZSBub3JtYWwgc3RhbmRhcmQgaHR0cCBwcm9jZXNzZXMgb2YgYSB3ZWIgc2VydmVyLgo+ID4KPiA+ IFRoaXMgaXMgZmluZSBpZiB5b3UgYXJlIGFuIGludGVybmV0IHNlY3VyaXR5IGV4cGVydCBhbmQg d2FudCB0byBhbmFseXplCj4gPiBhbmQgY2FwdHVyZSB0aGUgZGlmZmVyZW50IG1ldGhvZHMgdXNl ZCBieSBhdHRhY2tlcnMgb2Ygd2ViIGFwcGxpY2F0aW9uLgo+ID4gTW9kX3NlY3VyaXR5IGlzIHRo ZSBwZXJmZWN0bHkgZGVzaWduZWQgdG9vbCBmb3IgdGhpcyB0YXNrLgo+ID4KPiA+IEJ1dCBmb3Ig dGhlIHVzZXIgd2hvIGlzIGxvb2tpbmcgZm9yIGEgc2ltcGxlIHVzZXIgZnJpZW5kbHkgd2ViIHNl cnZlcgo+ID4gZmlyZXdhbGwgdG8gYmxvY2sgYWxsIHRoZSBjdXJyZW50bHkga25vdyAmIGZ1dHVy ZSBtYWxpY2UgYXR0YWNrIG1ldGhvZHMKPiA+IHdoaWxlIGFsbG93aW5nIGhpcyB3ZWIgYXBwbGlj YXRpb24gdG8gcGFzcyB1bm1vbGVzdGVkIGRvZXMgbm90IHJlYWRpbHkgZmluZAo+ID4gdGhpcyBh dmFpbGFibGUgaW4gbW9kX3NlY3VyaXR5Lgo+ID4KPiA+IE5vdyBkb24ndCB0YWtlIG1lIHdyb25n LCBpdCBpcyBwb3NzaWJsZSB0byBjb25maWd1cmUgYW4gbW9kX3NlY3VyaXR5Cj4gPiBydWxlIHNl dCB0aGF0IGFkZHJlc3MgdGhlIHRlY2huaWNhbCBwYXJ0IG9mIHRoZSBzdGF0ZWQgZ29hbCwgYnV0 IHRoZSBzaW1wbGUKPiA+ICYgdXNlciBmcmllbmRseSBwYXJ0IGlzIGJ5IG5vIG1lYW5zIG1ldCBh cyBzaG93biBpbiB0aGUgZm9sbG93aW5nIGV4YW1wbGUuCj4gPiBBbGwgdGhlIHNjcmlwdHMgdXNl ZCBpbiB0aGUgd2ViIGFwcGxpY2F0aW9uIGFyZSBjb2RlZCBieSBpbmRpdmlkdWFsIHJ1bGVzLgo+ ID4KPiA+Cj4gPiBzZWNmaWx0ZXJlbmdpbmUgb24KPiA+IHNlY2ZpbHRlcmNoZWNrdXJsZW5jb2Rp bmcgb24KPiA+IHNlY2ZpbHRlcmNoZWNrdW5pY29kZWVuY29kaW5nIG9mZgo+ID4gc2VjZmlsdGVy Zm9yY2VieXRlcmFuZ2UgMCAyNTUKPiA+IHNlY2ZpbHRlcnNjYW5wb3N0IG9uCj4gPiBTZWNGaWx0 ZXJEZWZhdWx0QWN0aW9uIGRlbnksbG9nLHN0YXR1czo0MDQKPiA+Cj4gPiBTZWNGaWx0ZXJTZWxl Y3RpdmUgUkVRVUVTVF9VUkkgIiFeLzAwLjAwX0hlYWRlci5odG0iCj4gPiBjaGFpbgo+ID4gU2Vj RmlsdGVyU2VsZWN0aXZlIFJFUVVFU1RfVVJJICIhXi8wMC4wMF9IZWFkZXIucGhwIgo+ID4gY2hh aW4KPiA+IFNlY0ZpbHRlclNlbGVjdGl2ZSBSRVFVRVNUX1VSSSAiIV4vMDAuMDAtd2ViX3N0eWxl X3NoZWV0LmNzcyIKPiA+IGNoYWluCj4gPiBTZWNGaWx0ZXJTZWxlY3RpdmUgUkVRVUVTVF9VUkkg IiFeL2J1dHRvbi5waHAiICAgICAgICAgICAgICAgICAgICAgICBjaGFpbgo+ID4KPiA+IFNlY0Zp bHRlclNlbGVjdGl2ZSBSRVFVRVNUX1VSSSAiIV4vaW5kZXguaHRtIiAgICAgICAgICAgICAgICAg ICAgICAgIGNoYWluCj4gPgo+ID4gU2VjRmlsdGVyU2VsZWN0aXZlIFJFUVVFU1RfVVJJICIhXi9t bHNfYXVjdGlvbl9iaWRkaW5nX2luZm8uaHRtIiAgICAgY2hhaW4KPiA+Cj4gPiBTZWNGaWx0ZXJT ZWxlY3RpdmUgUkVRVUVTVF9VUkkgIiFeL21sc19icmVha2luX2F0dGVtcHQucGhwIiAgICAgICAg ICBjaGFpbgo+ID4KPiA+IFNlY0ZpbHRlclNlbGVjdGl2ZSBSRVFVRVNUX1VSSSAiIV4vbWxzX2Nv bnRhY3Rfc2FsZXNfZGVwdC5odG0iICAgICAgIGNoYWluCj4gPgo+ID4gU2VjRmlsdGVyU2VsZWN0 aXZlIFJFUVVFU1RfVVJJICIhXi9tbHNfZnNib19mb3Jnb3RfbG9nb24ucGhwIiAgICAgICAgY2hh aW4KPiA+Cj4gPiBTZWNGaWx0ZXJTZWxlY3RpdmUgUkVRVUVTVF9VUkkgIiFeL21sc19mc2JvX2xp c3RpbmdfaW5mby5odG0iICAgICAgICBjaGFpbgo+ID4KPiA+IFNlY0ZpbHRlclNlbGVjdGl2ZSBS RVFVRVNUX1VSSSAiIV4vbWxzX2ZzYm9fbG9nb24ucGhwIiAgICAgICAgICAgICAgIGNoYWluCj4g Pgo+ID4gU2VjRmlsdGVyU2VsZWN0aXZlIFJFUVVFU1RfVVJJICIhXi9tbHNfZnNib19tZW1iZXJf dXBkYXRlLnBocCIgICAgICAgY2hhaW4KPiA+Cj4gPiBTZWNGaWx0ZXJTZWxlY3RpdmUgUkVRVUVT VF9VUkkgIiFeL21sc19mc2JvX21lbnUucGhwIiAgICAgICAgICAgICAgICBjaGFpbgo+ID4KPiA+ IFNlY0ZpbHRlclNlbGVjdGl2ZSBSRVFVRVNUX1VSSSAiIV4vbWxzX2ZzYm9fc2lnbnVwLnBocCIg ICAgICAgICAgICAgIGNoYWluCj4gPgo+ID4gU2VjRmlsdGVyU2VsZWN0aXZlIFJFUVVFU1RfVVJJ ICIhXi9tbHNfZnNib190ZXJtaW5hdGVfbWVtYmVyMS5waHAiICAgY2hhaW4KPiA+Cj4gPiBTZWNG aWx0ZXJTZWxlY3RpdmUgUkVRVUVTVF9VUkkgIiFeL21sc19mc2JvX3Rlcm1pbmF0ZV9tZW1iZXIy LnBocCIgICBjaGFpbgo+ID4KPiA+IFNlY0ZpbHRlclNlbGVjdGl2ZSBSRVFVRVNUX1VSSSAiIV4v bWxzX2hvbWVfcGFnZS5waHAiCj4gPiBjaGFpbgo+ID4gU2VjRmlsdGVyU2VsZWN0aXZlIFJFUVVF U1RfVVJJICIhXi9tbHNfc3RkX2V4aXQucGhwIiAgICAgICAgICAgICAgICAgY2hhaW4KPiA+Cj4g PiBTZWNGaWx0ZXJTZWxlY3RpdmUgUkVRVUVTVF9VUkkgIiFeL21sc192ZXJpZnllbWFpbC5waHAi ICAgICAgICAgICAgICBjaGFpbgo+ID4KPiA+IFNlY0ZpbHRlclNlbGVjdGl2ZSBSRVFVRVNUX1VS SSAiIV4vbWxzX3ZlcmlmeWVtYWlsMC5waHAiCj4gPgo+ID4KPiA+IEluIHNvbWUgcHJvZ3JhbW1p bmcgY2lyY2xlcyB0aGlzIHdvdWxkIGJlIGNhbGxlZCBhIHJldmVyc2UgcG9saXNoIGNvZGluZwo+ ID4gdGVjaG5pcXVlLgo+ID4KPiA+IFRoaXMgaXMgbm90IHNpbXBsZSBjb2RpbmcgbG9naWMgYW5k IHRoaXMgdGVjaG5pcXVlIGlzIG5vdCBkb2N1bWVudGVkIG9yCj4gPiBldmVuIGhpbnRlZCBhdCBp biB0aGUgbWFudWFsLiBCdXQgaXQgZG9lcyBmdWxmaWxsIHRoZSBzdGF0ZWQgdGVjaG5pY2FsIGdv YWwKPiA+IHJlcXVpcmVtZW50IG9mIGJsb2NraW5nIGFsbCBjdXJyZW50bHkga25vdyBhbmQgdW5r bm93biBtYWxpY2UgYXR0YWNrIG1ldGhvZHMKPiA+IHdoaWxlIGFsbG93aW5nIHRoZSB3ZWIgYXBw bGljYXRpb24gdG8gcGFzcyB1bm1vbGVzdGVkLiBBcyBhIHNpZGUgYmVuZWZpdCBub3QKPiA+IG9u bHkgZG9lcyB0aGUgYWJvdmUgZXhhbXBsZSBwYXNzIHRoZSB1c2VycyBub3JtYWwgd2ViIHRyYWZm aWMgYnV0IGl0IGFsc28KPiA+IGFsbG93cyBzZWFyY2ggZW5naW5lIHJvYm90IHRyYWZmaWMgdG8g cGFzcyBhcyB0aGV5IGludmVudG9yeSB0aGUgd2Vic2l0ZSBmb3IKPiA+IGluZGV4aW5nLgo+ID4K PiA+IFNlY3VyaXR5IGNhbiBiZSB0aWdodGVuZWQgZnVydGhlciBieSBjb2RpbmcgYWxsIHRoZSBz Y3JpcHQgbmFtZXMgdXNpbmcKPiA+IHRoaXMgcnVsZSBmb3JtYXQKPiA+Cj4gPiBTZWNGaWx0ZXJT ZWxlY3RpdmUgU0NSSVBUX0ZJTEVOQU1FCj4gPiAiIV4vdXNyL2xvY2FsL3d3dy9kYXRhL21sc19S ZWFkX2ZvcmdvdF9sb2dvbl9lbWFpbC5waHAiICBjaGFpbgo+ID4KPiA+IFRoaXMgd291bGQgc3Rv cCBhbGwgc2VhcmNoIGVuZ2luZSB0cmFmZmljIGJlY2F1c2UgdGhleSBkbyBub3QgaW5jbHVkZQo+ ID4gdGhlIHBhdGggaW4gdGhlaXIgcmVxdWVzdHMuCj4gPgo+ID4KPiA+Cj4gPiBUaGUgdXNlZnVs bmVzcyBvZiBtb2Rfc2VjdXJpdHkgY2FuIGJlIGluY3JlYXNlZCB3aGlsZSBiZWNvbWluZyBtb3Jl IHVzZXIKPiA+IGZyaWVuZGx5IGJ5IG1ha2luZyBmZXcgdHdlYWtzIHRvIG1vZF9zZWN1cml0eSdz IHNvdXJjZSBjb2RlLgo+ID4KPiA+Cj4gPiBXaGF0IEkgcHVycG9zZSBpcyB0aGlzLAo+ID4KPiA+ IENoYW5nZSBzZWNmaWx0ZXJlbmdpbmUgb258b2ZmICAgIHRvCj4gPgo+ID4KPiA+IHNlY2ZpbHRl cmVuZ2luZSBvbl9leGNsdXNpdmUgfCBvbl9pbmNsdXNpdmUgIHwgb2ZmCj4gPgo+ID4KPiA+IG9u X2V4Y2x1c2l2ZSA9ICAoZGVmYXVsdHMgdG8gYWxsb3cgYWxsKSB3aGljaCBpcyBob3cgbW9kX3Nl Y3VyaXR5Cj4gPiBjdXJyZW50bHkgZnVuY3Rpb25zCj4gPgo+ID4gb25faW5jbHVzaXZlID0gIChk ZWZhdWx0cyB0byBibG9jayBhbGwpCj4gPgo+ID4gVGhpcyB3b3VsZCB0aGVuIGFsbG93IHRoZSBh Ym92ZSBleGFtcGxlIHJ1bGVzIHRvIGJlIHJlLWNvZGVkIGxpa2UgdGhpczoKPiA+Cj4gPiBTZWNG aWx0ZXJTZWxlY3RpdmUgUkVRVUVTVF9VUkkgIl4vMDAuMDBfSGVhZGVyLmh0bSIgICAgICAgICAg ICAgICAgIFNlY0ZpbHRlclNlbGVjdGl2ZQo+ID4gUkVRVUVTVF9VUkkgIl4vMDAuMDBfSGVhZGVy LnBocCIgICAgICAgICAgICAgICAgICBTZWNGaWx0ZXJTZWxlY3RpdmUKPiA+IFJFUVVFU1RfVVJJ ICJeLzAwLjAwLXdlYl9zdHlsZV9zaGVldC5jc3MiCj4gPiBTZWNGaWx0ZXJTZWxlY3RpdmUgUkVR VUVTVF9VUkkgIl4vYnV0dG9uLnBocCIKPiA+IFNlY0ZpbHRlclNlbGVjdGl2ZSBSRVFVRVNUX1VS SSAiXi9jbGFzcy5waHBtYWlsZXIucGhwIgo+ID4gU2VjRmlsdGVyU2VsZWN0aXZlIFJFUVVFU1Rf VVJJICJeL2luZGV4Lmh0bSIKPiA+Cj4gPiBXaGVyZSBhIG1hdGNoIG1lYW5zIHBhc3MgdGhlIHBh Y2tldCB0byB0aGUgd2ViIHNlcnZlciBhbmQgYW55Cj4gPiBub24tbWF0Y2hlcyBnZXQgcGFzc2Vk IHRvIHdoYXQgZXZlciBTZWNGaWx0ZXJEZWZhdWx0QWN0aW9uCj4gPiBkZW55LGxvZyxzdGF0dXM6 NDA0ICBzYXlzIHRvIGRvLgo+ID4KPiA+IFRvIGFuIG5vbi10ZWNobmljYWwgdXNlciB0aGlzIGlz IHN0cmFpZ2h0IGZvcndhcmQgYW5kIG1ha2VzIGxvZ2ljYWwKPiA+IHNlbnNlcyB3aGVuIHJlYWQu Cj4gPiBUaGUgY29uY2VwdCBvZiBvbmx5IGhhdmluZyB0byBhZGQgYSBydWxlIGZvciBlYWNoIHNj cmlwdCB0aGF0IG1ha2VzIHVwCj4gPiB0aGUgd2ViIGFwcGxpY2F0aW9uIHJlcXVpcmVzIG5vIHRl Y2huaWNhbCBjb21wcmVoZW5zaW9uIG9mIGhvdyBhbiB3ZWIgc2VydmVyCj4gPiBwcm9jZXNzZXMg cmVxdWVzdHMgYW5kIGlzIHJlYWxseSBvbiB0YXJnZXQgZm9yIHRoZSBnZW5lcmFsIGhvbWUgaG9i Ynlpc3QKPiA+IGxldmVsIG9mIHVuZGVyc3RhbmRpbmcgYW5kIG5lZWRzLiBBbmQgb2YgY291cnNl IHRoZSBtb2Rfc2VjdXJpdHkgbWFudWFsCj4gPiB3b3VsZCBuZWVkIGEgbWFqb3IgcmV3cml0ZSB0 byBpbmNsdWRlIHRoaXMgbmV3IGZ1bmN0aW9uLgo+ID4KPiA+Cj4gPiBJIHBvc3QgdGhpcyBmb3Ig ZGlzY3Vzc2lvbiBieSBtZW1iZXJzIG9mIHRoaXMgbGlzdCB3aG8gaGF2ZSBtb3JlCj4gPiBrbm93 bGVkZ2Ugb2YgbW9kX3NlY3VyaXR5IGludGVybmFscyBhbmQgdXNhZ2UgYmFja2dyb3VuZCBpbiBo b3BlcyBvZgo+ID4gYWNoaWV2aW5nIGFncmVlbWVudCBvbiBtYWtpbmcgdGhpcyBhbiBvZmZpY2lh bCBlbmhhbmNlbWVudCByZXF1ZXN0Lgo+ID4KPiA+Cj4gPiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tCj4gPiBOZXcgWWFob28hIE1lc3NlbmdlciB3aXRoIFZvaWNlLiBDYWxsIHJlZ3Vs YXIgcGhvbmVzIGZyb20geW91ciBQQzxodHRwOi8vdXMucmQueWFob28uY29tL21haWxfdXMvdGFn bGluZXMvcG9zdG1hbjUvKmh0dHA6Ly91cy5yZC55YWhvby5jb20vZXZ0PTM5NjY2LypodHRwOi8v YmV0YS5tZXNzZW5nZXIueWFob28uY29tPmFuZCBzYXZlIGJpZy4KPiA+Cj4KPgo+ICAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBMb3ZlIGNoZWFwIHRocmlsbHM/IEVuam95IFBDLXRv LVBob25lIGNhbGxzIHRvIDMwKyBjb3VudHJpZXM8aHR0cDovL3VzLnJkLnlhaG9vLmNvbS9tYWls X3VzL3RhZ2xpbmVzL3Bvc3RtYW45LypodHRwOi8vdXMucmQueWFob28uY29tL2V2dD0zOTY2Ni8q aHR0cDovL2JldGEubWVzc2VuZ2VyLnlhaG9vLmNvbS8+Zm9yIGp1c3QgMu+/vS9taW4gd2l0aCBZ YWhvbyEgTWVzc2VuZ2VyIHdpdGggVm9pY2UuCj4K |
|
From: Terry D. <tdo...@na...> - 2006-04-11 16:46:23
|
joe barbish wrote:
> Ryan
> Thanks for the help.
>
> But I don't understand some thing you said.
>
> You said that SecFilter "." will deny everything then you say "What
> happens if there is a new PHP exploit for your mls_verifyemail0.php
> script? The rules above will not protect against this."
>
> The whole idea of the rules is to control what is allowed to pass.
>
> The SecFilter "." is suppose to deny everything. Everything means
> anything which is not one of the coded 'accept' rules, including all
> known and un-known exploits.
>
> If SecFilter "." is not the correct rule to deny everything then what
> rule will?
>
SecFilter "." _is_ the correct rule to block everything. However, if you this
on its own, your users may experience some (sarcasm) loss of functionality...
Let's assume that the sample rule:
SecFilterSelective REQUEST_URI "^/mls_verifyemail0.php" allow
is the only one you have other than the SecFilter "."; this will make mod_sec
block any request for anything other than that file.
Generally, if the PHP is to be any use at all, then it must take some input
from the client. You can whitelist the specifc files (REQUEST_URI)[1] and you
can whitelist the expected variables (ARGS_NAMES), but if you want to
whitelist the input (ARGS_VALUES) you have to know _every_ valid permutation
of inputs and filter them specifically.
Here, you can whitelist certain character sets which will again narrow down
the possible attack vectors, but unless you have a very simple input
pattern[2] then you're facing a huge job. Trying to tell it in such exact
terms will likely leave you with an unmanageably huge ruleset. It's like
trying to use iptables as a spam filter.
Possibly clear as mud, but that's how I understand it. I'll leave the
internals questions to the big boys and perhaps a fresh thread.
[1] Am I right in believing that REQUEST_URI is just the requested file with
POST, but includes the query string with GET requests? (I'm working from a
1.87 manual)
[2] Example simple input whitelist:
SecFilterSelective POST_PAYLOAD "!(^m=[0-9a-f]{32}$)"
The above rule will only allow one variable m and a valid md5 hash. I consider
this a fairly strong inclusive filter, but only because it's such a simple
application.
Terry.
>
>
>
> */Ryan Barnett <rcb...@gm...>/* wrote:
>
> Joe,
> A few quick comments -
>
> 1) You really don't need a new directive/option to get what you are
> looking for. Keeping with your firewall concept, in order to get an
> inclusive ruleset, you first need to implement a catch-all deny rule
> that would block all requests. In mod_security it would be this -
> SecFilter ".". This would match any request and then take the
> action that you specified in the SecFilterDefaultAction rule. The
> next step is to create a whitelist of filters that will match
> allowed, acceptable requests. This is what you are attempting to do
> in your post with the mod_security inverted filters.
>
> 2) Your examples of inverted filters will not work correctly with
> the chain action. The chain feature will create a larger, complex
> check on the request. In your examples, you tried to chain all of
> the acceptable URLs together. The problem is that all of those
> files will never be requested within one sigle request packet. The
> mod_security action that you should use is "allow" to tell
> mod_security to allow the request through and the final filter is
> the catch-all deny. Here is an updated ruleset for you -
>
> SecFilterSelective REQUEST_URI "^/00.00_Header.htm" allow
> SecFilterSelective REQUEST_URI "^/00.00_Header.php" allow
> SecFilterSelective REQUEST_URI "^/00.00-web_style_sheet.css" allow
> SecFilterSelective REQUEST_URI "^/button.php" allow
> SecFilterSelective REQUEST_URI "^/index.htm" allow
> SecFilterSelective REQUEST_URI "^/mls_auction_bidding_info.htm" allow
> SecFilterSelective REQUEST_URI "^/mls_breakin_attempt.php" allow
> SecFilterSelective REQUEST_URI "^/mls_contact_sales_dept.htm" allow
> SecFilterSelective REQUEST_URI "^/mls_fsbo_forgot_logon.php" allow
> SecFilterSelective REQUEST_URI "^/mls_fsbo_listing_info.htm" allow
> SecFilterSelective REQUEST_URI "^/mls_fsbo_logon.php" allow
> SecFilterSelective REQUEST_URI "^/mls_fsbo_member_update.php" allow
> SecFilterSelective REQUEST_URI "^/mls_fsbo_menu.php" allow
> SecFilterSelective REQUEST_URI "^/mls_fsbo_signup.php" allow
> SecFilterSelective REQUEST_URI "^/mls_fsbo_terminate_member1.php" allow
> SecFilterSelective REQUEST_URI "^/mls_fsbo_terminate_member2.php" allow
> SecFilterSelective REQUEST_URI "^/mls_home_page.php" allow
> SecFilterSelective REQUEST_URI "^/mls_std_exit.php" allow
> SecFilterSelective REQUEST_URI "^/mls_verifyemail.php" allow
> SecFilterSelective REQUEST_URI "^/mls_verifyemail0.php" allow
> SecFilter "."
>
> 3) Even with these rules, this will not provide total protection.
> What happens if there is a new PHP exploit for your
> mls_verifyemail0.php script? The rules above will not protect
> against this. It is for this reason that the "exclusive", blacklist
> rules should be listed BEFORE these whitelist rules. These attacks
> signatures will be processed prior to these rules and check for
> common exploit issues (meta-characthers, directory traversal,
> command execution, etc...). If these rules are specified AFTER the
> rules above, they will be skipped with the "allow" directive.
>
> Hope this helps.
>
> --
> Ryan C. Barnett
> Web Application Security Consortium (WASC) Member
> CIS Apache Benchmark Project Lead
> SANS Instructor: Securing Apache
> GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
> Author: Preventing Web Attacks with Apache
>
>
> On 4/10/06, *joe barbish* <joe...@ya...
> <mailto:joe...@ya...>> wrote:
>
> mod_security enhancement idea
>
>
> In software packet firewalls there are 2 different types of
> filter rule sets.
>
> The exclusive firewall and the inclusive firewall. This is well
> documented in the FreeBSD manual firewall section.
>
>
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls.html
>
> An exclusive firewall allows all packets through except for
> those matching a set of rules that block certain packets, (IE,
> default pass all).
>
> An inclusive firewall does the reverse. It only allows packets
> matching the rules through and blocks everything else, (IE,
> default deny all). Inclusive firewalls are much, much securer
> than exclusive firewalls and simpler to code.
>
> Applying that concept to the mod_security filter rules I see
> explained in the manual and the examples provided at the
> mod_security home page it became very obvious that
> mod_security defaults to an exclusive type of firewall. Rules
> are used to code the particular signatures of malice attempts to
> circumvent the normal standard http processes of a web server.
>
> This is fine if you are an internet security expert and want to
> analyze and capture the different methods used by attackers of
> web application. Mod_security is the perfectly designed tool for
> this task.
>
> But for the user who is looking for a simple user friendly web
> server firewall to block all the currently know & future malice
> attack methods while allowing his web application to pass
> unmolested does not readily find this available in mod_security.
>
> Now don't take me wrong, it is possible to configure an
> mod_security rule set that address the technical part of the
> stated goal, but the simple & user friendly part is by no means
> met as shown in the following example. All the scripts used in
> the web application are coded by individual rules.
>
>
> secfilterengine on
> secfiltercheckurlencoding on
> secfiltercheckunicodeencoding off
> secfilterforcebyterange 0 255
> secfilterscanpost on
> SecFilterDefaultAction deny,log,status:404
>
> SecFilterSelective REQUEST_URI
> "!^/00.00_Header.htm" chain
> SecFilterSelective REQUEST_URI
> "!^/00.00_Header.php" chain
> SecFilterSelective REQUEST_URI
> "!^/00.00-web_style_sheet.css" chain
> SecFilterSelective REQUEST_URI
> "!^/button.php" chain
> SecFilterSelective REQUEST_URI
> "!^/index.htm" chain
> SecFilterSelective REQUEST_URI
> "!^/mls_auction_bidding_info.htm" chain
> SecFilterSelective REQUEST_URI
> "!^/mls_breakin_attempt.php" chain
> SecFilterSelective REQUEST_URI
> "!^/mls_contact_sales_dept.htm" chain
> SecFilterSelective REQUEST_URI
> "!^/mls_fsbo_forgot_logon.php" chain
> SecFilterSelective REQUEST_URI
> "!^/mls_fsbo_listing_info.htm" chain
> SecFilterSelective REQUEST_URI
> "!^/mls_fsbo_logon.php" chain
> SecFilterSelective REQUEST_URI
> "!^/mls_fsbo_member_update.php" chain
> SecFilterSelective REQUEST_URI
> "!^/mls_fsbo_menu.php" chain
> SecFilterSelective REQUEST_URI
> "!^/mls_fsbo_signup.php" chain
> SecFilterSelective REQUEST_URI
> "!^/mls_fsbo_terminate_member1.php" chain
> SecFilterSelective REQUEST_URI
> "!^/mls_fsbo_terminate_member2.php" chain
> SecFilterSelective REQUEST_URI
> "!^/mls_home_page.php" chain
> SecFilterSelective REQUEST_URI
> "!^/mls_std_exit.php" chain
> SecFilterSelective REQUEST_URI
> "!^/mls_verifyemail.php" chain
> SecFilterSelective REQUEST_URI
> "!^/mls_verifyemail0.php"
>
>
> In some programming circles this would be called a reverse
> polish coding technique.
>
> This is not simple coding logic and this technique is not
> documented or even hinted at in the manual. But it does fulfill
> the stated technical goal requirement of blocking all currently
> know and unknown malice attack methods while allowing the web
> application to pass unmolested. As a side benefit not only does
> the above example pass the users normal web traffic but it also
> allows search engine robot traffic to pass as they inventory the
> website for indexing.
>
> Security can be tightened further by coding all the script names
> using this rule format
>
> SecFilterSelective SCRIPT_FILENAME
> "!^/usr/local/www/data/mls_Read_forgot_logon_email.php" chain
>
> This would stop all search engine traffic because they do not
> include the path in their requests.
>
>
>
> The usefulness of mod_security can be increased while becoming
> more user friendly by making few tweaks to mod_security's source
> code.
>
>
> What I purpose is this,
>
> Change secfilterengine on|off to
>
>
> secfilterengine on_exclusive | on_inclusive | off
>
>
> on_exclusive = (defaults to allow all) which is how
> mod_security currently functions
>
> on_inclusive = (defaults to block all)
>
> This would then allow the above example rules to be re-coded
> like this:
>
> SecFilterSelective REQUEST_URI
> "^/00.00_Header.htm" SecFilterSelective
> REQUEST_URI "^/00.00_Header.php"
> SecFilterSelective REQUEST_URI "^/00.00-web_style_sheet.css"
> SecFilterSelective REQUEST_URI "^/button.php"
> SecFilterSelective REQUEST_URI "^/class.phpmailer.php"
> SecFilterSelective REQUEST_URI "^/index.htm"
>
> Where a match means pass the packet to the web server and any
> non-matches get passed to what ever SecFilterDefaultAction
> deny,log,status:404 says to do.
>
> To an non-technical user this is straight forward and makes
> logical senses when read.
> The concept of only having to add a rule for each script that
> makes up the web application requires no technical comprehension
> of how an web server processes requests and is really on target
> for the general home hobbyist level of understanding and needs.
> And of course the mod_security manual would need a major rewrite
> to include this new function.
>
>
> I post this for discussion by members of this list who have more
> knowledge of mod_security internals and usage background in
> hopes of achieving agreement on making this an official
> enhancement request.
>
>
> ------------------------------------------------------------------------
> New Yahoo! Messenger with Voice. Call regular phones from your
> PC
> <http://us.rd.yahoo.com/mail_us/taglines/postman5/*http://us.rd.yahoo.com/evt=39666/*http://beta.messenger.yahoo.com>
> and save big.
>
>
>
> ------------------------------------------------------------------------
> Love cheap thrills? Enjoy PC-to-Phone calls to 30+ countries
> <http://us.rd.yahoo.com/mail_us/taglines/postman9/*http://us.rd.yahoo.com/evt=39666/*http://beta.messenger.yahoo.com/>
> for just 2¢/min with Yahoo! Messenger with Voice.
|
|
From: Tom A. <tan...@oa...> - 2006-04-11 18:34:39
|
Terry Dooher wrote: > Let's assume that the sample rule: > > SecFilterSelective REQUEST_URI "^/mls_verifyemail0.php" allow > > [1] Am I right in believing that REQUEST_URI is just the requested file > with POST, but includes the query string with GET requests? (I'm working > from a 1.87 manual) In the example above, it would allow query string arguments. If you add a trailing "$" after ".php", then only the file with no arguments would be allowed in a GET. Tom |
|
From: Terry D. <tdo...@na...> - 2006-04-12 13:23:38
|
Tom Anderson wrote: > Terry Dooher wrote: > >> Let's assume that the sample rule: >> >> SecFilterSelective REQUEST_URI "^/mls_verifyemail0.php" allow >> >> [1] Am I right in believing that REQUEST_URI is just the requested >> file with POST, but includes the query string with GET requests? (I'm >> working from a 1.87 manual) > > > In the example above, it would allow query string arguments. If you add > a trailing "$" after ".php", then only the file with no arguments would > be allowed in a GET. This much I understand, but I'm looking for some clarification on whether or not REQUEST_URI contains the query string in POST requests. I would assume not, but my confusion arises from the use of the term URI in this context. Going strictly by the RFC, I'd expect <scheme>://<authority><path>?query, but we're inside a VirtualHost directive, so it makes sense not to have the scheme and domain parts available, matching only from the beginning of the path. Does this also mean the query string from POST requests is tacked on to the end? (This seems unlikely to me, but I just want to be sure.) Terry. > Tom > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > |
|
From: Ivan R. <iva...@gm...> - 2006-04-12 13:46:13
|
On 4/12/06, Terry Dooher <tdo...@na...> wrote: > > This much I understand, but I'm looking for some clarification on whether= or > not REQUEST_URI contains the query string in POST requests. I would assum= e > not, but my confusion arises from the use of the term URI in this context= . It can do. But if it does those won't be the parameters transmitted in the request body. It is possible (and common) to have parameters in the query string *and* in the request body. -- Ivan Ristic, Technical Director Thinking Stone, http://www.thinkingstone.com ModSecurity: Open source Web Application Firewall |
|
From: Terry D. <tdo...@na...> - 2006-04-12 16:47:01
|
Ivan Ristic wrote: > On 4/12/06, Terry Dooher <tdo...@na...> wrote: > >>This much I understand, but I'm looking for some clarification on whether or >>not REQUEST_URI contains the query string in POST requests. I would assume >>not, but my confusion arises from the use of the term URI in this context. > > > It can do. But if it does those won't be the parameters transmitted in > the request body. It is possible (and common) to have parameters in > the query string *and* in the request body. Ah, of course. I must be having trouble accessing the part of my brain that knew that already. Thanks for clarifying. Terry. > -- > Ivan Ristic, Technical Director > Thinking Stone, http://www.thinkingstone.com > ModSecurity: Open source Web Application Firewall > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642 > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > |
|
From: joe b. <joe...@ya...> - 2006-04-11 23:33:04
|
ok I have changed the rules to this
# This services the frame home page
SecFilterSelective REQUEST_URI "^/index.htm$" allow
SecFilterSelective REQUEST_URI "^/00.00-web_style_sheet.css$" allow
SecFilterSelective REQUEST_URI "^/00.00_Header.htm$" allow
SecFilterSelective REQUEST_URI "^/mls_home_page.php$" allow
SecFilterSelective REQUEST_URI "^/mls_products.htm$" allow
SecFilterSelective REQUEST_URI "^/powered_by_FreeBSD.gif$" allow
SecFilterSelective REQUEST_URI "^/powered_by_apache_bsd.gif$" allow
SecFilterSelective REQUEST_URI "^/mls_fsbo_signup.php$" allow
Appending a $ to the end of the script name means only the file with no arguments is allowed in a GET request. This stops malice inserts correct?
mls_home_page.php script is all html code with only php code for a page hit counter. It open & reads the count record, bumps it by 1 and rewrites it. Then echo's the count value to the screen.
So appending a $ to it works fine.
The mls_fsbo_signup.php script is a self contained show form and process form. The debug log shows this when it's executed.
34][/mls_fsbo_logon.php] Parsing arguments...
34][/mls_fsbo_logon.php] Raw cookie header "PHPSESSID=95a21d7930bf5b3955335b8df4
34][/mls_fsbo_logon.php] Adding cookie "PHPSESSID"="95a21d7930bf5b3955335b8df4a7
34][/mls_fsbo_logon.php] Read 51 bytes from POST [r=817c034]
34][/mls_fsbo_logon.php] content-type = "application/x-www-form-urlencoded"
34][/mls_fsbo_logon.php] Parsing variables from POST payload
34][/mls_fsbo_logon.php] Adding parameter: [id][barbish1]
34][/mls_fsbo_logon.php] Adding parameter: [pw][jjb722]
34][/mls_fsbo_logon.php] Adding parameter: [userdigit][sixvn]
34][/mls_fsbo_logon.php] Adding parameter: [submit][Submit]
You well notice that the rule for mls_fsbo_logon.php has $ appended to it. The parameters id, pw, and userdigit are checked in the php script for lower case Alpha-Numeric characters. So according to previous post on this list I can add a line something like this to insure bogus stuff has not been inserted.
SecFilterSelective POST_PAYLOAD "!(^m=[0-9a-f]{32}$)"
So question is the following code correct.
SecFilterSelective REQUEST_URI "^/mls_fsbo_signup.php$" allow plus
SecFilterSelective POST_PAYLOAD "(^id=[0-9a-z]$)" allow plus
SecFilterSelective POST_PAYLOAD "(^pw=[0-9a-z]$)" allow plus
SecFilterSelective POST_PAYLOAD "(^userdigit=[0-9a-z]$)" allow
Terry Dooher <tdo...@na...> wrote:
joe barbish wrote:
> Ryan
> Thanks for the help.
>
> But I don't understand some thing you said.
>
> You said that SecFilter "." will deny everything then you say "What
> happens if there is a new PHP exploit for your mls_verifyemail0.php
> script? The rules above will not protect against this."
>
> The whole idea of the rules is to control what is allowed to pass.
>
> The SecFilter "." is suppose to deny everything. Everything means
> anything which is not one of the coded 'accept' rules, including all
> known and un-known exploits.
>
> If SecFilter "." is not the correct rule to deny everything then what
> rule will?
>
SecFilter "." _is_ the correct rule to block everything. However, if you this
on its own, your users may experience some (sarcasm) loss of functionality...
Let's assume that the sample rule:
SecFilterSelective REQUEST_URI "^/mls_verifyemail0.php" allow
is the only one you have other than the SecFilter "."; this will make mod_sec
block any request for anything other than that file.
Generally, if the PHP is to be any use at all, then it must take some input
from the client. You can whitelist the specifc files (REQUEST_URI)[1] and you
can whitelist the expected variables (ARGS_NAMES), but if you want to
whitelist the input (ARGS_VALUES) you have to know _every_ valid permutation
of inputs and filter them specifically.
Here, you can whitelist certain character sets which will again narrow down
the possible attack vectors, but unless you have a very simple input
pattern[2] then you're facing a huge job. Trying to tell it in such exact
terms will likely leave you with an unmanageably huge ruleset. It's like
trying to use iptables as a spam filter.
Possibly clear as mud, but that's how I understand it. I'll leave the
internals questions to the big boys and perhaps a fresh thread.
[1] Am I right in believing that REQUEST_URI is just the requested file with
POST, but includes the query string with GET requests? (I'm working from a
1.87 manual)
[2] Example simple input whitelist:
SecFilterSelective POST_PAYLOAD "!(^m=[0-9a-f]{32}$)"
The above rule will only allow one variable m and a valid md5 hash. I consider
this a fairly strong inclusive filter, but only because it's such a simple
application.
Terry.
---------------------------------
How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates. |
|
From: Ryan B. <rcb...@gm...> - 2006-04-11 23:49:24
|
On 4/11/06, joe barbish <joe...@ya...> wrote:
>
>
> So question is the following code correct.
>
> SecFilterSelective REQUEST_URI "^/mls_fsbo_signup.php$" allow plus
> SecFilterSelective POST_PAYLOAD "(^id=3D[0-9a-z]$)" allow
> plus
> SecFilterSelective POST_PAYLOAD "(^pw=3D[0-9a-z]$)" allow
> plus
> SecFilterSelective POST_PAYLOAD "(^userdigit=3D[0-9a-z]$)" allow
>
>
"plus" is not a valid mod_security action. I would suggest that you use
this directive -
SecFilterSelective REQUEST_URI "^/mls_fsbo_logon.php$" chain
SecFilterSelective POST_PAYLOAD "!^(id|pw|userdigit)=3D[0-9a-z]$"
This should work. Test it out and let me know.
-Ryan
>
>
>
> *Terry Dooher <tdo...@na...>* wrote:
>
> joe barbish wrote:
> > Ryan
> > Thanks for the help.
> >
> > But I don't understand some thing you said.
> >
> > You said that SecFilter "." will deny everything then you say "What
> > happens if there is a new PHP exploit for your mls_verifyemail0.php
> > script? The rules above will not protect against this."
> >
> > The whole idea of the rules is to control what is allowed to pass.
> >
> > The SecFilter "." is suppose to deny everything. Everything means
> > anything which is not one of the coded 'accept' rules, including all
> > known and un-known exploits.
> >
> > If SecFilter "." is not the correct rule to deny everything then what
> > rule will?
> >
>
> SecFilter "." _is_ the correct rule to block everything. However, if you
> this
> on its own, your users may experience some (sarcasm) loss of
> functionality...
>
> Let's assume that the sample rule:
>
> SecFilterSelective REQUEST_URI "^/mls_verifyemail0.php" allow
>
> is the only one you have other than the SecFilter "."; this will make
> mod_sec
> block any request for anything other than that file.
>
> Generally, if the PHP is to be any use at all, then it must take some
> input
> from the client. You can whitelist the specifc files (REQUEST_URI)[1] and
> you
> can whitelist the expected variables (ARGS_NAMES), but if you want to
> whitelist the input (ARGS_VALUES) you have to know _every_ valid
> permutation
> of inputs and filter them specifically.
> Here, you can whitelist certain character sets which will again narrow
> down
> the possible attack vectors, but unless you have a very simple input
> pattern[2] then you're facing a huge job. Trying to tell it in such exact
> terms will likely leave you with an unmanageably huge ruleset. It's like
> trying to use iptables as a spam filter.
>
> Possibly clear as mud, but that's how I understand it. I'll leave the
> internals questions to the big boys and perhaps a fresh thread.
>
> [1] Am I right in believing that REQUEST_URI is just the requested file
> with
> POST, but includes the query string with GET requests? (I'm working from =
a
>
> 1.87 manual)
>
> [2] Example simple input whitelist:
> SecFilterSelective POST_PAYLOAD "!(^m=3D[0-9a-f]{32}$)"
>
> The above rule will only allow one variable m and a valid md5 hash. I
> consider
> this a fairly strong inclusive filter, but only because it's such a simpl=
e
>
> application.
>
> Terry.
>
> ------------------------------
> How low will we go? Check out Yahoo! Messenger's low PC-to-Phone call
> rates.
> <http://us.rd.yahoo.com/mail_us/taglines/postman8/*http://us.rd.yahoo.com=
/evt=3D39663/*http://voice.yahoo.com>
>
>
--
Ryan C. Barnett
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor: Securing Apache
GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache
|
|
From: joe b. <joe...@ya...> - 2006-04-12 00:14:34
|
No Ryan that did not work. debug log shows this
Checking signature "^/mls_fsbo_logon.php$" at REQUEST_URI
Checking against "/mls_fsbo_logon.php"
Signature check returned 403
Chained rule with match, continue in the loop
Checking against "id=jones1&pw=bob888&userdigit=vmiis&submit=Submit"
Signature check returned 404
Access denied with code 404. Pattern match "!^(id|pw|userdigit)=[0-9a-z]$" at POST_PAYLOAD.
Rule match, returning code 404
Im thinking this may work
SecFilterSelective REQUEST_URI "^/mls_fsbo_logon.php$" chain
SecFilterSelective POST_PAYLOAD "^(id|pw|userdigit)=[0-9a-z]$" allow
Notice no ! and allow added at end
What do you think?
Ryan Barnett <rcb...@gm...> wrote:
On 4/11/06, joe barbish <joe...@ya...> wrote:
So question is the following code correct.
SecFilterSelective REQUEST_URI "^/mls_fsbo_signup.php$" allow plus
SecFilterSelective POST_PAYLOAD "(^id=[0-9a-z]$)" allow plus
SecFilterSelective POST_PAYLOAD "(^pw=[0-9a-z]$)" allow plus
SecFilterSelective POST_PAYLOAD "(^userdigit=[0-9a-z]$)" allow
"plus" is not a valid mod_security action. I would suggest that you use this directive -
SecFilterSelective REQUEST_URI "^/mls_fsbo_logon.php$" chain
SecFilterSelective POST_PAYLOAD "!^(id|pw|userdigit)=[0-9a-z]$"
This should work. Test it out and let me know.
-Ryan
---------------------------------
How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates. |
|
From: Ryan B. <rcb...@gm...> - 2006-04-12 00:24:29
|
On 4/11/06, joe barbish <joe...@ya...> wrote:
> No Ryan that did not work. debug log shows this
>
> Checking signature "^/mls_fsbo_logon.php$" at REQUEST_URI
> Checking against "/mls_fsbo_logon.php"
> Signature check returned 403
> Chained rule with match, continue in the loop
> Checking against "id=3Djones1&pw=3Dbob888&userdigit=3Dvmiis&submit=3DSub=
mit"
>
Ahh... the line above helps. It shows what the expected format of the
POST_PAYLOAD is.
> Signature check returned 404
> Access denied with code 404. Pattern match
> "!^(id|pw|userdigit)=3D[0-9a-z]$" at POST_PAYLOAD.
> Rule match, returning code 404
>
> Im thinking this may work
>
> SecFilterSelective REQUEST_URI "^/mls_fsbo_logon.php$" chain
> SecFilterSelective POST_PAYLOAD "^(id|pw|userdigit)=3D[0-9a-z]$" allow
>
> Notice no ! and allow added at end
>
> What do you think?
>
This should work (including size restrictions of the values to 20 character=
s
or less) -
SecFilterSelective REQUEST_URI "^/mls_fsbo_logon.php$" chain
SecFilterSelective POST_PAYLOAD
"^id=3D[0-9a-z]{20,}&pw=3D[0-9a-z]{20,}&userdigit=3D[0-9a-z]{20,}&submit=3D=
Submit$"
allow
See if this works. You can test it by submitting data other than letters o=
r
numbers and also input > 20 characters. These should be blocked.
- Ryan
>
>
>
>
> *Ryan Barnett <rcb...@gm...>* wrote:
>
> On 4/11/06, joe barbish <joe...@ya...> wrote:
> >
> >
> > So question is the following code correct.
> >
> > SecFilterSelective REQUEST_URI "^/mls_fsbo_signup.php$" allow plus
> > SecFilterSelective POST_PAYLOAD "(^id=3D[0-9a-z]$)" all=
ow
> > plus
> > SecFilterSelective POST_PAYLOAD "(^pw=3D[0-9a-z]$)" allo=
w
> > plus
> > SecFilterSelective POST_PAYLOAD "(^userdigit=3D[0-9a-z]$)" allow
> >
> >
>
> "plus" is not a valid mod_security action. I would suggest that you use
> this directive -
>
> SecFilterSelective REQUEST_URI "^/mls_fsbo_logon.php$" chain
> SecFilterSelective POST_PAYLOAD "!^(id|pw|userdigit)=3D[0-9a-z]$"
>
>
> This should work. Test it out and let me know.
>
> -Ryan
>
>
> >
> ------------------------------
> How low will we go? Check out Yahoo! Messenger's low PC-to-Phone call
> rates.
> <http://us.rd.yahoo.com/mail_us/taglines/postman8/*http://us.rd.yahoo.com=
/evt=3D39663/*http://voice.yahoo.com>
>
>
--
Ryan C. Barnett
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor: Securing Apache
GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache
|
|
From: joe b. <joe...@ya...> - 2006-04-12 01:07:16
|
I changed the field lengh to their real size and the test worked.
SecFilterSelective REQUEST_URI "^/mls_fsbo_logon.php$" chain
SecFilterSelective POST_PAYLOAD "^id=[0-9a-z]{15,}&pw=[0-9a-z]{15,}&userdigit=[0-9a-z]{5,}&submit=Submit$" allow
On my membership signup form I have 20 fields and I want to use the same coding format for them. IE using the chain and POST_PAYLOAD. Is there some way to code the POST_PAYLOAD statement to continue onto next line so it would be easy to read 20 fields. Some thing like this
SecFilterSelective REQUEST_URI "^/mls_fsbo_logon.php$" chain
SecFilterSelective POST_PAYLOAD "^id=[0-9a-z]{15,}
&pw=[0-9a-z]{15,}
&userdigit=[0-9a-z]{5,}&submit=Submit$" allow
In my php code to process the signup form I have these edits
elseif (!ereg("^([[:alnum:]\.\_\-]+)(\@[[:alnum:]\.\-]+\.+)", $email))
elseif (!ereg("^[[:alnum:]\ \-]{{$len}}$", $addr1))
(!ereg("^[[:digit:]\-]{{$len}}$", $phone_cell)))
How would I code the POST_PAYLOAD "^email=[0-9a-zA-Z]{45,} to include . _ - as allowable characters or the POST_PAYLOAD "^add1=[0-9a-zA-Z]{45,} to include a dash and a blank as allowable characters?
And thanks for your wonderful help. I would have never been able to get this from the manual.
Ryan Barnett <rcb...@gm...> wrote:
On 4/11/06, joe barbish <joe...@ya...> wrote:
No Ryan that did not work. debug log shows this
Checking signature "^/mls_fsbo_logon.php$" at REQUEST_URI
Checking against "/mls_fsbo_logon.php"
Signature check returned 403
Chained rule with match, continue in the loop
Checking against "id=jones1&pw=bob888&userdigit=vmiis&submit=Submit"
Ahh... the line above helps. It shows what the expected format of the POST_PAYLOAD is.
Signature check returned 404
Access denied with code 404. Pattern match "!^(id|pw|userdigit)=[0-9a-z]$" at POST_PAYLOAD.
Rule match, returning code 404
Im thinking this may work
SecFilterSelective REQUEST_URI "^/mls_fsbo_logon.php$" chain
SecFilterSelective POST_PAYLOAD "^(id|pw|userdigit)=[0-9a-z]$" allow
Notice no ! and allow added at end
What do you think?
This should work (including size restrictions of the values to 20 characters or less) -
SecFilterSelective REQUEST_URI "^/mls_fsbo_logon.php$" chain
SecFilterSelective POST_PAYLOAD "^id=[0-9a-z]{20,}&pw=[0-9a-z]{20,}&userdigit=[0-9a-z]{20,}&submit=Submit$" allow
See if this works. You can test it by submitting data other than letters or numbers and also input > 20 characters. These should be blocked.
- Ryan
Ryan Barnett <rcb...@gm...> wrote:
On 4/11/06, joe barbish <joe...@ya... > wrote:
So question is the following code correct.
SecFilterSelective REQUEST_URI "^/mls_fsbo_signup.php$" allow plus
SecFilterSelective POST_PAYLOAD "(^id=[0-9a-z]$)" allow plus
SecFilterSelective POST_PAYLOAD "(^pw=[0-9a-z]$)" allow plus
SecFilterSelective POST_PAYLOAD "(^userdigit=[0-9a-z]$)" allow
"plus" is not a valid mod_security action. I would suggest that you use this directive -
SecFilterSelective REQUEST_URI "^/mls_fsbo_logon.php$" chain
SecFilterSelective POST_PAYLOAD "!^(id|pw|userdigit)=[0-9a-z]$"
This should work. Test it out and let me know.
-Ryan
---------------------------------
How low will we go? Check out Yahoo! Messenger's low PC-to-Phone call rates.
--
Ryan C. Barnett
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor: Securing Apache
GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache
---------------------------------
How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates. |
|
From: Ryan B. <rcb...@gm...> - 2006-04-12 01:44:54
|
On 4/11/06, joe barbish <joe...@ya...> wrote:
> I changed the field lengh to their real size and the test worked.
>
> SecFilterSelective REQUEST_URI "^/mls_fsbo_logon.php$" chain
> SecFilterSelective POST_PAYLOAD
> "^id=3D[0-9a-z]{15,}&pw=3D[0-9a-z]{15,}&userdigit=3D[0-9a-z]{5,}&submit=
=3DSubmit$"
> allow
>
>
Cool.
>
> On my membership signup form I have 20 fields and I want to use the same
> coding format for them. IE using the chain and POST_PAYLOAD. Is there som=
e
> way to code the POST_PAYLOAD statement to continue onto next line so it
> would be easy to read 20 fields. Some thing like this
>
> SecFilterSelective REQUEST_URI "^/mls_fsbo_logon.php$" chain
> SecFilterSelective POST_PAYLOAD "^id=3D[0-9a-z]{15,}
> &pw=3D[0-9a-z]{15,}
> &userdigit=3D[0-9a-z]{5,}&submit=3DSubmit$" allow
>
For ease of following the regular expression, you can use the "\" character
to continue the expression on the next line, like this -
SecFilterSelective REQUEST_URI "^/mls_fsbo_logon.php$" chain
SecFilterSelective POST_PAYLOAD "^id=3D[0-9a-z]{15,} \
&pw=3D[0-9a-z]{15,} \
&userdigit=3D[0-9a-z]{5,}&submit=3DSubmit$" allow
>
> How would I code the POST_PAYLOAD "^email=3D[0-9a-zA-Z]{45,} to include .=
_
> - as allowable characters or the POST_PAYLOAD "^add1=3D[0-9a-zA-Z]{45,} =
to
> include a dash and a blank as allowable characters?
>
Like this, assuming that this data is on separate lines (since you are usin=
g
the "^" anchor ) -
SecFilterSelective POST_PAYLOAD "^email=3D[0-9a-zA-Z\.-_]{45,}" allow
SecFilterSelective POST_PAYLOAD "^add1=3D[0-9a-zA-Z- ]{45,}" allow
If these are all on one line together, then you will need to include it wit=
h
the others like this -
SecFilterSelective REQUEST_URI "^/mls_fsbo_logon.php$" chain
SecFilterSelective POST_PAYLOAD "^id=3D[0-9a-z]{15,} \
&pw=3D[0-9a-z]{15,} \
&userdigit=3D[0-9a-z]{5,} \
&email=3D[0-9a-zA-Z\.-_]{45,} \
&add1=3D[0-9a-zA-Z- ]{45,} \
&submit=3DSubmit$" allow
>
> And thanks for your wonderful help. I would have never been able to get
> this from the manual.
>
No problem. When I was new to mod_security, Ivan was kind enough to answer
all of my questions, so I am just "paying it forward" ;) Sorry for the
cheesy movie reference but it was the first thing that came to mind.
-Ryan
*Ryan Barnett <rcb...@gm...>* wrote:
>
> On 4/11/06, joe barbish <joe...@ya...> wrote:
>
> > No Ryan that did not work. debug log shows this
> >
> > Checking signature "^/mls_fsbo_logon.php$" at REQUEST_URI
> > Checking against "/mls_fsbo_logon.php"
> > Signature check returned 403
> > Chained rule with match, continue in the loop
> > Checking against "id=3Djones1&pw=3Dbob888&userdigit=3Dvmiis&submit=3DS=
ubmit"
> >
>
>
> Ahh... the line above helps. It shows what the expected format of the
> POST_PAYLOAD is.
>
>
>
>
> > Signature check returned 404
> > Access denied with code 404. Pattern match
> > "!^(id|pw|userdigit)=3D[0-9a-z]$" at POST_PAYLOAD.
> > Rule match, returning code 404
> >
> > Im thinking this may work
> >
> > SecFilterSelective REQUEST_URI "^/mls_fsbo_logon.php$" chain
> > SecFilterSelective POST_PAYLOAD "^(id|pw|userdigit)=3D[0-9a-z]$" allow
> >
> > Notice no ! and allow added at end
> >
> > What do you think?
> >
>
>
> This should work (including size restrictions of the values to 20
> characters or less) -
>
> SecFilterSelective REQUEST_URI "^/mls_fsbo_logon.php$" chain
> SecFilterSelective POST_PAYLOAD
> "^id=3D[0-9a-z]{20,}&pw=3D[0-9a-z]{20,}&userdigit=3D[0-9a-z]{20,}&submit=
=3DSubmit$"
> allow
>
> See if this works. You can test it by submitting data other than letters
> or numbers and also input > 20 characters. These should be blocked.
>
> - Ryan
>
>
> >
> >
> >
> >
> > *Ryan Barnett <rcb...@gm...>* wrote:
> >
> > On 4/11/06, joe barbish <joe...@ya... > wrote:
> > >
> > >
> > > So question is the following code correct.
> > >
> > > SecFilterSelective REQUEST_URI "^/mls_fsbo_signup.php$" allow
> > > plus
> > > SecFilterSelective POST_PAYLOAD "(^id=3D[0-9a-z]$)"
> > > allow plus
> > > SecFilterSelective POST_PAYLOAD "(^pw=3D[0-9a-z]$)" al=
low
> > > plus
> > > SecFilterSelective POST_PAYLOAD "(^userdigit=3D[0-9a-z]$)" all=
ow
> > >
> > >
> >
> > "plus" is not a valid mod_security action. I would suggest that you us=
e
> > this directive -
> >
> > SecFilterSelective REQUEST_URI "^/mls_fsbo_logon.php$" chain
> > SecFilterSelective POST_PAYLOAD "!^(id|pw|userdigit)=3D[0-9a-z]$"
> >
> >
> > This should work. Test it out and let me know.
> >
> > -Ryan
> >
> >
> > >
> > ------------------------------
> > How low will we go? Check out Yahoo! Messenger's low PC-to-Phone call
> > rates.
> > <http://us.rd.yahoo.com/mail_us/taglines/postman8/*http://us.rd.yahoo.c=
om/evt=3D39663/*http://voice.yahoo.com>
> >
>
>
>
> --
> Ryan C. Barnett
> Web Application Security Consortium (WASC) Member
> CIS Apache Benchmark Project Lead
> SANS Instructor: Securing Apache
> GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
> Author: Preventing Web Attacks with Apache
>
>
> ------------------------------
> How low will we go? Check out Yahoo! Messenger's low PC-to-Phone call
> rates.
> <http://us.rd.yahoo.com/mail_us/taglines/postman8/*http://us.rd.yahoo.com=
/evt=3D39663/*http://voice.yahoo.com>
>
>
--
Ryan C. Barnett
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor: Securing Apache
GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache
|
|
From: joe b. <joe...@ya...> - 2006-04-12 03:44:28
|
Wow that is great. I now have the tools to code rules for about 80% of my web application.
My member signup script and the member update script both have the same 20 POST_PAYLOAD fields. Can I do some thing like this?
SecFilterSelective REQUEST_URI "^(/mls_fsbo_logon.php$|/mls_fsbo_logon.php$)" chain
SecFilterSelective POST_PAYLOAD "^id=[0-9a-z]{15,}&pw=[0-9a-z]{15,}&userdigit=[0-9a-z]{5,}&submit=Submit$" allow
Is the above coding correct?
In the debug log I see this
fsbo_logon.php] Raw cookie header "PHPSESSID=4ecd90be905c5918652d743539e1051e"
_fsbo_logon.php] Adding cookie "PHPSESSID"="4ecd90be905c5918652d743539e1051e"
In the php logon script I do start php session control, but I do not write a cookie so I am suprised to see mod_security loging these messages. Do you have any idea what this means?
I have been using the apache httpd-access.log to see the raw request data.
Is there some other method you would recommend?
Is there some place I can find the maping of words like REQUEST_URI to their location in the httpd_access.log logged records?
I am interested in using SecChrootDir /chroot/apache
But the manual is not clear on setting it up. My web application lives here /usr/local/www/data and that is what is in httpd.conf
I am running apache13.
Is this how I should code the rule?
SecChrootDir /usr/local/www/data
And change the path of httpd-error.log & httpd-access.log from /var/log to /usr/local/www/data/ in the httpd.conf?
Since the logs will be in the jail how do I access the logs from outside the jail with out turning off mod_security?
---------------------------------
Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates. |
|
From: Ivan R. <iva...@gm...> - 2006-04-10 19:51:35
|
On 4/10/06, joe barbish <joe...@ya...> wrote: > mod_security enhancement idea Hi Joe, Thank you for your suggestions. As Ryan mentioned what you're after is already supported in ModSecurity. Simply allow what's allowed and deny everything else. > This is fine if you are an internet security expert and want to analyze a= nd > capture the different methods used by attackers of web application. > Mod_security is the perfectly designed tool for this task. That's very flattering. It's not there yet but v2 will come much closer. > This is not simple coding logic and this technique is not documented or e= ven > hinted at in the manual. There are many things that are not documented nor hinted in the manual. That's because it's a reference manual. It's main purpose is to document the individual features. A book on ModSecurity, when and if I write it, will be a comprehensive source of information on what's possible to do with ModSecurity. > The usefulness of mod_security can be increased while becoming more user > friendly by making few tweaks to mod_security's source code. > > > What I purpose is this, > > Change secfilterengine on|off to > > secfilterengine on_exclusive | on_inclusive | off That would actually make the configuration process more complex because the operation of individual rules would no longer depend on the rule itself, but on the configuration of the engine too. Meaning, one would not be able to just publish a rule set for any particular purpose. Furthermore, it would prevent a combination of approaches to be used (e.g. inclusive *and* exclusive, using your terminology, at the same time) . > To an non-technical user this is straight forward and makes logical sense= s > when read. It would be even easier to have a directive that simply points to the list of acceptable resources. However, that would not solve the bigger issue. The target resource is not the only relevant parameter, you are not taking into account script parameters, cookies, parameters embedded in headers or in the URI itself. > The concept of only having to add a rule for each script that makes up th= e > web application requires no technical comprehension of how an web server > processes requests and is really on target for the general home hobbyist > level of understanding and needs. I am afraid that is not the target user level for ModSecurity. A nice & friendly GUI is a much better choice for those that do not wish to immerse themselves deep into web security issues. -- Ivan Ristic, Technical Director Thinking Stone, http://www.thinkingstone.com ModSecurity: Open source Web Application Firewall |
Thanks for helping keep SourceForge clean.
X