mod-security-users — General discussion about mod_security

RE: [mod-security-users] Mod Security and WebSphere

[De V. R. <Ric...@bm...>]

Sorry, I do not *yet* know what hook the websphere plug-in runs at. I'll
see if I can find out -- though I am no debug-guru, so I'll have to see
how far I get.

Yes, I was indeed talking about the "ENABLE_EARLY_HOOK" compile-time
switch, but I prefer to use that as a last resort.

-----Original Message-----
From: Ivan Ristic [mailto:iva...@gm...]=20
Sent: Monday, April 10, 2006 5:44 PM
To: De Vries, Richard
Cc: mod...@li...
Subject: Re: [mod-security-users] Mod Security and WebSphere

On 4/10/06, De Vries, Richard <Ric...@bm...> wrote:
> While doing some debugging on a web-application, I noticed that the
> mod_security plug-in appears to sit below the WebSphere plugin in the
http
> process stack. Is that indeed correct?

I don't know, I've never had an opportunity to install ModSecurity
into a web server running the WebSphere plug-in. Do you know which
hook the plug-in runs at? There's only one hook in Apache that
"handles" requests and ModSecurity runs before it. However, it is
entirely possible for someone to write a plug-in that handles the
request during one of the previous phases. It would be a wrong thing
to do but it's still possible.


> I can block a request in Mod_Security, yet see it hit the websphere
plug-in
> still. It does eventually block the request. Other than re-compiling
it with
> that particular setting to hook it higher into the webserver
(drastically
> high if you ask me), is there any other way to get it to execute prior
to
> the webserver plugin?

Perhaps you mean the experimental ENABLE_EARLY_HOOK compile-time
switch? Custom-compiling ModSecurity is probably the only solution for
this problem. ModSecurity v2 will come with a built-in early
processing phase so you shouldn't need to recompile.

--
Ivan Ristic, Technical Director
Thinking Stone, http://www.thinkingstone.com
ModSecurity: Open source Web Application Firewall

Re: [mod-security-users] Mod Security and WebSphere

[Ivan R. <iva...@gm...>]

On 4/10/06, De Vries, Richard <Ric...@bm...> wrote:
> While doing some debugging on a web-application, I noticed that the
> mod_security plug-in appears to sit below the WebSphere plugin in the htt=
p
> process stack. Is that indeed correct?

I don't know, I've never had an opportunity to install ModSecurity
into a web server running the WebSphere plug-in. Do you know which
hook the plug-in runs at? There's only one hook in Apache that
"handles" requests and ModSecurity runs before it. However, it is
entirely possible for someone to write a plug-in that handles the
request during one of the previous phases. It would be a wrong thing
to do but it's still possible.


> I can block a request in Mod_Security, yet see it hit the websphere plug-=
in
> still. It does eventually block the request. Other than re-compiling it w=
ith
> that particular setting to hook it higher into the webserver (drastically
> high if you ask me), is there any other way to get it to execute prior to
> the webserver plugin?

Perhaps you mean the experimental ENABLE_EARLY_HOOK compile-time
switch? Custom-compiling ModSecurity is probably the only solution for
this problem. ModSecurity v2 will come with a built-in early
processing phase so you shouldn't need to recompile.

--
Ivan Ristic, Technical Director
Thinking Stone, http://www.thinkingstone.com
ModSecurity: Open source Web Application Firewall

[mod-security-users] Mod Security and WebSphere

[De V. R. <Ric...@bm...>]

While doing some debugging on a web-application, I noticed that the
mod_security plug-in appears to sit below the WebSphere plugin in the
http process stack. Is that indeed correct?

=20

I can block a request in Mod_Security, yet see it hit the websphere
plug-in still. It does eventually block the request. Other than
re-compiling it with that particular setting to hook it higher into the
webserver (drastically high if you ask me), is there any other way to
get it to execute prior to the webserver plugin?

=20

Thank you,

=20

 Richard de Vries

Re: [mod-security-users] mod_security enhancement idea

[Ivan R. <iva...@gm...>]

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

Re: [mod-security-users] mod_security enhancement idea

[Ryan B. <rcb...@gm...>]

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.
>
>

Re: [mod-security-users] mod_security enhancement idea

[Andras G. <an...@an...>]

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.

Re: [mod-security-users] mod_security enhancement idea

[joe b. <joe...@ya...>]

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! Messenger’s low  PC-to-Phone call rates.

Re: [mod-security-users] mod_security enhancement idea

[Andras G. <an...@an...>]

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.

Re: [mod-security-users] Access denied with code 403. Error normalising REQUEST_URI: Invalid URL encoding detected: not enough characters

[Ivan R. <iv...@we...>]

Ivan Ristic wrote:
>
> Thanks for pointing out the content of the "Location" header. You are right
> in that the content is truncated but it's not ModSecurity or Apache that's
> doing it. It is received that way so it's probably the client that is sending
> it. There appears to be a limit of 432 bytes (imposed by the client).

  FYI, we've come to a conclusion that Siteminder, which works as an Apache
  module, does something to change the URI so that it is different from the URI
  received in the request. We've left it at that.

-- 
Ivan Ristic, Technical Director
Thinking Stone, http://www.thinkingstone.com
ModSecurity: Open source Web Application Firewall
Apache Security (O'Reilly): http://www.apachesecurity.net

[mod-security-users] mod_security enhancement idea

[joe b. <joe...@ya...>]

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.

Re: [mod-security-users] Access denied with code 403. Error normalising REQUEST_URI: Invalid URL encoding detected: not enough characters

[Tom A. <tan...@oa...>]

Ivan Ristic wrote:
>   Thanks for pointing out the content of the "Location" header. You are right
>   in that the content is truncated but it's not ModSecurity or Apache that's
>   doing it. It is received that way so it's probably the client that is sending
>   it. There appears to be a limit of 432 bytes (imposed by the client).

All browsers impose maximum URL length requirements.  I believe Internet 
Explorer is 2048 characters.  Apache can handle something like 8k by 
default before returning a 414, though that is adjustable at compile 
time I think.  However, I recall that the rule of thumb is 255 
characters max on a GET due to certain other clients and proxies.  So 
try using a POST instead for anything over 255 characters.

Tom

Re: [mod-security-users] Access denied with code 403. Error normalising REQUEST_URI: Invalid URL encoding detected: not enough characters

[<ze...@vo...>]

Thanks a lot Ivan and Alex,

You are right about the URL size. Mod Sec seems to block URL when the size =
is up to 483 characters. I think that even siteminder doesn't treat the end=
 of the URL, but it blocks nothing.

I have changed "SecFilterForceByteRange" from the range "1 to 255" to "0 to=
 255" but, of course, it doesn't resolve my problem.
=20
I will work on the application to have a smaller URL, or i will try to find=
 a solution to enlarge the size imposed by the client.

Many thanks for yours investigations.
Christophe


> Message du 10/04/06 =C3=A0 12h26
> De : "Ivan Ristic" <iv...@we...>
> A : "Alex" <al...@bs...>
> Copie =C3=A0 : ze...@vo..., mod...@li...
> Objet : Re: [mod-security-users] Access denied with code 403. Error      =
normalising REQUEST_URI: Invalid URL encoding detected: not enough      cha=
racters
>=20
> Alex wrote:
> > Hi christophe
> >=20
> > IMHO (but Ivan will confirm) mod_security seems to truncate your url (s=
ee
> > Location:
> >> /siteminderagent/pwcgi/smpwservicescgi.exe?SMENC=3DUTF-8&SMTOKEN=3D{RC=
2}GuFcF7I/F5Sl03RqtNrPsMPlYiQZg/B1e2KFVDxfbVrnyC2MPyEDnDn1fDzHRadtrowaa0dtX=
RcvNGiN+cwPaCYlGkzRryxlqAMQ33n/JFc//j8GS51FTS31e00c0C0x4dszYnBMJfwIFO/TQ0vy=
WFW1RyszdoiTDAp8ZSwqgO0=3D&USERNAME=3Dtest_YM00&SMAUTHREASON=3D20&SMAGENTNA=
ME=3D-SM-fshUMrkQm%2fB7%2bk8CAU%2fak459pCXPADL1l0bEfFr6ZGrq3HJ%2fv720ACDphq=
n4Rhzb&TARGET=3D-SM-https%3a%2f%2fwww%2emyserver%2ecom%2fURI%2fhome%2ehtml%=
3
> > that is truncated before the end... (fSMLOCALE=3DFR-FR is missing) and =
cause
> > the %3f not beeing accepted... Changing the %3f to ? make the query a
> > little bit shorter and is then accepted (but without taking care of the
> > LOCALE I think.
>=20
>   Thanks for pointing out the content of the "Location" header. You are r=
ight
>   in that the content is truncated but it's not ModSecurity or Apache tha=
t's
>   doing it. It is received that way so it's probably the client that is s=
ending
>   it. There appears to be a limit of 432 bytes (imposed by the client).
>=20
> --=20
> Ivan Ristic, Technical Director
> Thinking Stone, http://www.thinkingstone.com
> ModSecurity: Open source Web Application Firewall
> Apache Security (O'Reilly): http://www.apachesecurity.net
>=20
>

Re: [mod-security-users] Access denied with code 403. Error normalising REQUEST_URI: Invalid URL encoding detected: not enough characters

[Ivan R. <iv...@we...>]

ze...@vo... wrote:
> Hi Ivan,

> My web server architecture uses Siteminder

  Perhaps you could tell us more about your architecture? It would appear it's
  significant in this case.

  Is Siteminder based on Apache and you are using ModSecurity in it? Or do
  you have it configured to work as a proxy before or after Apache?

  I think the problem is in that something is truncating the URI. We just
  need to figure out what.


> I tried again to set the "SecFilterCheckURLEncoding" to "Off or On" but the error still occurs.

  But it's a different error :)

  As a workaround extend the allowed byte range to allow the null byte:

  SecFilterForceByteRange 0 255

-- 
Ivan Ristic, Technical Director
Thinking Stone, http://www.thinkingstone.com
ModSecurity: Open source Web Application Firewall
Apache Security (O'Reilly): http://www.apachesecurity.net

Re: [mod-security-users] Access denied with code 403. Error normalising REQUEST_URI: Invalid URL encoding detected: not enough characters

[Ivan R. <iv...@we...>]

Alex wrote:
> Hi christophe
> 
> IMHO (but Ivan will confirm) mod_security seems to truncate your url (see
> Location:
>> /siteminderagent/pwcgi/smpwservicescgi.exe?SMENC=UTF-8&SMTOKEN={RC2}GuFcF7I/F5Sl03RqtNrPsMPlYiQZg/B1e2KFVDxfbVrnyC2MPyEDnDn1fDzHRadtrowaa0dtXRcvNGiN+cwPaCYlGkzRryxlqAMQ33n/JFc//j8GS51FTS31e00c0C0x4dszYnBMJfwIFO/TQ0vyWFW1RyszdoiTDAp8ZSwqgO0=&USERNAME=test_YM00&SMAUTHREASON=20&SMAGENTNAME=-SM-fshUMrkQm%2fB7%2bk8CAU%2fak459pCXPADL1l0bEfFr6ZGrq3HJ%2fv720ACDphqn4Rhzb&TARGET=-SM-https%3a%2f%2fwww%2emyserver%2ecom%2fURI%2fhome%2ehtml%3
> that is truncated before the end... (fSMLOCALE=FR-FR is missing) and cause
> the %3f not beeing accepted... Changing the %3f to ? make the query a
> little bit shorter and is then accepted (but without taking care of the
> LOCALE I think.

  Thanks for pointing out the content of the "Location" header. You are right
  in that the content is truncated but it's not ModSecurity or Apache that's
  doing it. It is received that way so it's probably the client that is sending
  it. There appears to be a limit of 432 bytes (imposed by the client).

-- 
Ivan Ristic, Technical Director
Thinking Stone, http://www.thinkingstone.com
ModSecurity: Open source Web Application Firewall
Apache Security (O'Reilly): http://www.apachesecurity.net

Re: [mod-security-users] Access denied with code 403. Error normalising REQUEST_URI: Invalid URL encoding detected: not enough characters

[Alex <al...@bs...>]

Hi christophe

IMHO (but Ivan will confirm) mod_security seems to truncate your url (see
Location:
> /siteminderagent/pwcgi/smpwservicescgi.exe?SMENC=3DUTF-8&SMTOKEN=3D{RC2=
}GuFcF7I/F5Sl03RqtNrPsMPlYiQZg/B1e2KFVDxfbVrnyC2MPyEDnDn1fDzHRadtrowaa0dt=
XRcvNGiN+cwPaCYlGkzRryxlqAMQ33n/JFc//j8GS51FTS31e00c0C0x4dszYnBMJfwIFO/TQ=
0vyWFW1RyszdoiTDAp8ZSwqgO0=3D&USERNAME=3Dtest_YM00&SMAUTHREASON=3D20&SMAG=
ENTNAME=3D-SM-fshUMrkQm%2fB7%2bk8CAU%2fak459pCXPADL1l0bEfFr6ZGrq3HJ%2fv72=
0ACDphqn4Rhzb&TARGET=3D-SM-https%3a%2f%2fwww%2emyserver%2ecom%2fURI%2fhom=
e%2ehtml%3
that is truncated before the end... (fSMLOCALE=3DFR-FR is missing) and ca=
use
the %3f not beeing accepted... Changing the %3f to ? make the query a
little bit shorter and is then accepted (but without taking care of the
LOCALE I think.

Cheers

Alex

On Lun 10 avril 2006 11:31, ze...@vo... a =E9crit :
> Hi Ivan,
>
> Thanks for you answer.
>
> I tried again to set the "SecFilterCheckURLEncoding" to "Off or On" but
> the error still occurs.
>
> The Debug log (level 2) that be displayed is as follow:
>
> Detection phase starting (request 366218): "GET
> /siteminderagent/pwcgi/smpwservicescgi.exe?SMENC=3DUTF-8&SMTOKEN=3D{RC2=
}GuFcF7I/F5Sl03RqtNrPsMPlYiQZg/B1e2KFVDxfbVrnyC2MPyEDnDn1fDzHRadtrowaa0dt=
XRcvNGiN+cwPaCYlGkzRryxlqAMQ33n/JFc//j8GS51FTS31e00c0C0x4dszYnBMJfwIFO/TQ=
0vyWFW1RyszdoiTDAp8ZSwqgO0=3D&USERNAME=3Dtest_YM00&SMAUTHREASON=3D20&SMAG=
ENTNAME=3D-SM-fshUMrkQm%2fB7%2bk8CAU%2fak459pCXPADL1l0bEfFr6ZGrq3HJ%2fv72=
0ACDphqn4Rhzb&TARGET=3D-SM-https%3a%2f%2fwww%2emyserver%2ecom%2fURI%2fhom=
e%2ehtml%3fSMLOCALE=3DFR-FR
> HTTP/1.1"
> [10/Apr/2006:10:58:20 +0200]
> [www.myserver.com/sid#115800][rid#366218][/siteminderagent/pwcgi/smpwse=
rvicescgi.exe][1]
> Access denied with code 403. Error normalising REQUEST_URI: Invalid
> character detected [0]
>
>
> The modsec_log is as follow
>
> =3D=3D0000763d=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DRequest: www.myserver.com
> 1.10.11.12 - - [10/Apr/2006:11:06:56 +0200] "GET
> /siteminderagent/pwcgi/smpwservicescgi.exe?SMENC=3DUTF-8&SMTOKEN=3D{RC2=
}GuFcF7I/F5Sl03RqtNrPsMPlYiQZg/B1e2KFVDxfbVrnyC2MPyEDnDn1fDzHRadtrowaa0dt=
XRcvNGiN+cwPaCYlGkzRryxlqAMQ33n/JFc//j8GS51FTS31e00c0C0x4dszYnBMJfwIFO/TQ=
0vyWFW1RyszdoiTDAp8ZSwqgO0=3D&USERNAME=3Dtest_YM00&SMAUTHREASON=3D20&SMAG=
ENTNAME=3D-SM-fshUMrkQm%2fB7%2bk8CAU%2fak459pCXPADL1l0bEfFr6ZGrq3HJ%2fv72=
0ACDphqn4Rhzb&TARGET=3D-SM-https%3a%2f%2fwww%2emyserver%2ecom%2fURI%2fhom=
e%2ehtml%3fSMLOCALE=3DFR-FR
> HTTP/1.1" 403 2244
> "https://www.myserver.com/siteminderagent/pwcgi/smpwservicescgi.exe?SME=
NC=3DUTF-8&SMTOKEN=3D{RC2}GuFcF7I/F5Sl03RqtNrPsMPlYiQZg/B1e2KFVDxfbVrnyC2=
MPyEDnDn1fDzHRadtrowaa0dtXRcvNGiN+cwPaCYlGkzRryxlqAMQ33n/JFc//j8GS51FTS31=
e00c0C0x4dszYnBMJfwIFO/TQ0vyWFW1RyszdoiTDAp8ZSwqgO0=3D&USERNAME=3Dtest_YM=
00&SMAUTHREASON=3D20&SMAGENTNAME=3D-SM-fshUMrkQm%2fB7%2bk8CAU%2fak459pCXP=
ADL1l0bEfFr6ZGrq3HJ%2fv720ACDphqn4Rhzb&TARGET=3D-SM-https%3a%2f%2fwww%2em=
yserver%2ecom%2fURI%2fhome%2ehtml%3fSMLOCALE=3DFR-FR"
> "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)"=
 -
> "-"
> ----------------------------------------
> GET
> /siteminderagent/pwcgi/smpwservicescgi.exe?SMENC=3DUTF-8&SMTOKEN=3D{RC2=
}GuFcF7I/F5Sl03RqtNrPsMPlYiQZg/B1e2KFVDxfbVrnyC2MPyEDnDn1fDzHRadtrowaa0dt=
XRcvNGiN+cwPaCYlGkzRryxlqAMQ33n/JFc//j8GS51FTS31e00c0C0x4dszYnBMJfwIFO/TQ=
0vyWFW1RyszdoiTDAp8ZSwqgO0=3D&USERNAME=3Dtest_YM00&SMAUTHREASON=3D20&SMAG=
ENTNAME=3D-SM-fshUMrkQm%2fB7%2bk8CAU%2fak459pCXPADL1l0bEfFr6ZGrq3HJ%2fv72=
0ACDphqn4Rhzb&TARGET=3D-SM-https%3a%2f%2fwww%2emyserver%2ecom%2fURI%2fhom=
e%2ehtml%3fSMLOCALE=3DFR-FR
> HTTP/1.1
> Accept: */*
> Referer:
> https://www.myserver.com/siteminderagent/pwcgi/smpwservicescgi.exe?SMEN=
C=3DUTF-8&SMTOKEN=3D{RC2}GuFcF7I/F5Sl03RqtNrPsMPlYiQZg/B1e2KFVDxfbVrnyC2M=
PyEDnDn1fDzHRadtrowaa0dtXRcvNGiN+cwPaCYlGkzRryxlqAMQ33n/JFc//j8GS51FTS31e=
00c0C0x4dszYnBMJfwIFO/TQ0vyWFW1RyszdoiTDAp8ZSwqgO0=3D&USERNAME=3Dtest_YM0=
0&SMAUTHREASON=3D20&SMAGENTNAME=3D-SM-fshUMrkQm%2fB7%2bk8CAU%2fak459pCXPA=
DL1l0bEfFr6ZGrq3HJ%2fv720ACDphqn4Rhzb&TARGET=3D-SM-https%3a%2f%2fwww%2emy=
server%2ecom%2fURI%2fhome%2ehtml%3fSMLOCALE=3DFR-FR
> Accept-Language: fr,en-gb;q=3D0.5
> Accept-Encoding: gzip, deflate
> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR
> 1.1.4322)
> Host: www.myserver.com
> Connection: Keep-Alive
> SM_TRANSACTIONID: c2ce165c-0650-443a2030-000e-074810c5
> SM_SDOMAIN: .myserver.com
> Location:
> /siteminderagent/pwcgi/smpwservicescgi.exe?SMENC=3DUTF-8&SMTOKEN=3D{RC2=
}GuFcF7I/F5Sl03RqtNrPsMPlYiQZg/B1e2KFVDxfbVrnyC2MPyEDnDn1fDzHRadtrowaa0dt=
XRcvNGiN+cwPaCYlGkzRryxlqAMQ33n/JFc//j8GS51FTS31e00c0C0x4dszYnBMJfwIFO/TQ=
0vyWFW1RyszdoiTDAp8ZSwqgO0=3D&USERNAME=3Dtest_YM00&SMAUTHREASON=3D20&SMAG=
ENTNAME=3D-SM-fshUMrkQm%2fB7%2bk8CAU%2fak459pCXPADL1l0bEfFr6ZGrq3HJ%2fv72=
0ACDphqn4Rhzb&TARGET=3D-SM-https%3a%2f%2fwww%2emyserver%2ecom%2fURI%2fhom=
e%2ehtml%3
> SM_REALM:
> SM_REALMOID:
> SM_AUTHTYPE: Not Protected
> SM_USER:
> SM_USERDN:
> mod_security-message: Access denied with code 403. Error normalising
> REQUEST_URI: Invalid character detected [0]
> mod_security-action: 403
>
> It seems that the error is due to the invalid character "0" if i
> understand the log displayed. But why my URL works fine when i change
> "%3f" to "?" ?!
> I continue my investigation, but if you can help me i will be happy...
>
> Regards,
> Christophe
>
>
>> Message du 07/04/06 =C3=A0 18h41
>> De : "Ivan Ristic" <iv...@we...>
>> A : ze...@vo...
>> Copie =C3=A0 : mod...@li...
>> Objet : Re: [mod-security-users] Access denied with code 403. Error
>> normalising REQUEST_URI: Invalid URL encoding detected: not enough
>> characters
>>
>> ze...@vo... wrote:
>> >  Hi,
>> >
>> > I face a big problem using Mod Security 1.9.2.
>> >
>> > My web server architecture uses Siteminder and i use this kind of UR=
L
>> to
>> > change or modify password:
>> >
>> > https://www.myserver.com/siteminderagent/pwcgi/smpwservicescgi.exe
>>
>>   The URL works fine work me.
>>
>>   Are you sure you get the same result with "SecFilterCheckURLEncoding
>> Off"?
>>
>>
>> > ModSecurity logs as following:
>>
>>   Can you get me the audit log entry for this problem?
>>
>>
>> > [06/Apr/2006:17:45:06 +0200]
>> > [www.myserver.com/sid#115800][rid#32ef88][/siteminderagent/pwcgi/smp=
wservicescgi.
>> > exe][1] Access denied with code 403. Error normalising REQUEST_URI:
>> > Invalid URL encoding detected: not enough characters
>>
>>   This message would typically appear when there's an % at the end
>>   of the URI but the two hexadecimal characters that need to follow it
>>   aren't.
>>
>> --
>> Ivan Ristic, Technical Director
>> Thinking Stone, http://www.thinkingstone.com
>> ModSecurity: Open source Web Application Firewall
>> Apache Security (O'Reilly): http://www.apachesecurity.net
>>
>>
>
>
>
> -------------------------------------------------------
> 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=3Dlnk&kid=110944&bid$1720&dat=12164=
2
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>

Re: [mod-security-users] Access denied with code 403. Error normalising REQUEST_URI: Invalid URL encoding detected: not enough characters

[<ze...@vo...>]

Hi Ivan,

Thanks for you answer.

I tried again to set the "SecFilterCheckURLEncoding" to "Off or On" but the=
 error still occurs.

The Debug log (level 2) that be displayed is as follow:

Detection phase starting (request 366218): "GET /siteminderagent/pwcgi/smpw=
servicescgi.exe?SMENC=3DUTF-8&SMTOKEN=3D{RC2}GuFcF7I/F5Sl03RqtNrPsMPlYiQZg/=
B1e2KFVDxfbVrnyC2MPyEDnDn1fDzHRadtrowaa0dtXRcvNGiN+cwPaCYlGkzRryxlqAMQ33n/J=
Fc//j8GS51FTS31e00c0C0x4dszYnBMJfwIFO/TQ0vyWFW1RyszdoiTDAp8ZSwqgO0=3D&USERN=
AME=3Dtest_YM00&SMAUTHREASON=3D20&SMAGENTNAME=3D-SM-fshUMrkQm%2fB7%2bk8CAU%=
2fak459pCXPADL1l0bEfFr6ZGrq3HJ%2fv720ACDphqn4Rhzb&TARGET=3D-SM-https%3a%2f%=
2fwww%2emyserver%2ecom%2fURI%2fhome%2ehtml%3fSMLOCALE=3DFR-FR HTTP/1.1"
[10/Apr/2006:10:58:20 +0200] [www.myserver.com/sid#115800][rid#366218][/sit=
eminderagent/pwcgi/smpwservicescgi.exe][1] Access denied with code 403. Err=
or normalising REQUEST_URI: Invalid character detected [0]


The modsec_log is as follow

=3D=3D0000763d=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Request: www.myserver.com 1.10.11.12 - - [10/Apr/2006:11:06:56 +0200] "GET =
/siteminderagent/pwcgi/smpwservicescgi.exe?SMENC=3DUTF-8&SMTOKEN=3D{RC2}GuF=
cF7I/F5Sl03RqtNrPsMPlYiQZg/B1e2KFVDxfbVrnyC2MPyEDnDn1fDzHRadtrowaa0dtXRcvNG=
iN+cwPaCYlGkzRryxlqAMQ33n/JFc//j8GS51FTS31e00c0C0x4dszYnBMJfwIFO/TQ0vyWFW1R=
yszdoiTDAp8ZSwqgO0=3D&USERNAME=3Dtest_YM00&SMAUTHREASON=3D20&SMAGENTNAME=3D=
-SM-fshUMrkQm%2fB7%2bk8CAU%2fak459pCXPADL1l0bEfFr6ZGrq3HJ%2fv720ACDphqn4Rhz=
b&TARGET=3D-SM-https%3a%2f%2fwww%2emyserver%2ecom%2fURI%2fhome%2ehtml%3fSML=
OCALE=3DFR-FR HTTP/1.1" 403 2244 "https://www.myserver.com/siteminderagent/=
pwcgi/smpwservicescgi.exe?SMENC=3DUTF-8&SMTOKEN=3D{RC2}GuFcF7I/F5Sl03RqtNrP=
sMPlYiQZg/B1e2KFVDxfbVrnyC2MPyEDnDn1fDzHRadtrowaa0dtXRcvNGiN+cwPaCYlGkzRryx=
lqAMQ33n/JFc//j8GS51FTS31e00c0C0x4dszYnBMJfwIFO/TQ0vyWFW1RyszdoiTDAp8ZSwqgO=
0=3D&USERNAME=3Dtest_YM00&SMAUTHREASON=3D20&SMAGENTNAME=3D-SM-fshUMrkQm%2fB=
7%2bk8CAU%2fak459pCXPADL1l0bEfFr6ZGrq3HJ%2fv720ACDphqn4Rhzb&TARGET=3D-SM-ht=
tps%3a%2f%2fwww%2emyserver%2ecom%2fURI%2fhome%2ehtml%3fSMLOCALE=3DFR-FR" "M=
ozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)" - "-"
----------------------------------------
GET /siteminderagent/pwcgi/smpwservicescgi.exe?SMENC=3DUTF-8&SMTOKEN=3D{RC2=
}GuFcF7I/F5Sl03RqtNrPsMPlYiQZg/B1e2KFVDxfbVrnyC2MPyEDnDn1fDzHRadtrowaa0dtXR=
cvNGiN+cwPaCYlGkzRryxlqAMQ33n/JFc//j8GS51FTS31e00c0C0x4dszYnBMJfwIFO/TQ0vyW=
FW1RyszdoiTDAp8ZSwqgO0=3D&USERNAME=3Dtest_YM00&SMAUTHREASON=3D20&SMAGENTNAM=
E=3D-SM-fshUMrkQm%2fB7%2bk8CAU%2fak459pCXPADL1l0bEfFr6ZGrq3HJ%2fv720ACDphqn=
4Rhzb&TARGET=3D-SM-https%3a%2f%2fwww%2emyserver%2ecom%2fURI%2fhome%2ehtml%3=
fSMLOCALE=3DFR-FR HTTP/1.1
Accept: */*
Referer: https://www.myserver.com/siteminderagent/pwcgi/smpwservicescgi.exe=
?SMENC=3DUTF-8&SMTOKEN=3D{RC2}GuFcF7I/F5Sl03RqtNrPsMPlYiQZg/B1e2KFVDxfbVrny=
C2MPyEDnDn1fDzHRadtrowaa0dtXRcvNGiN+cwPaCYlGkzRryxlqAMQ33n/JFc//j8GS51FTS31=
e00c0C0x4dszYnBMJfwIFO/TQ0vyWFW1RyszdoiTDAp8ZSwqgO0=3D&USERNAME=3Dtest_YM00=
&SMAUTHREASON=3D20&SMAGENTNAME=3D-SM-fshUMrkQm%2fB7%2bk8CAU%2fak459pCXPADL1=
l0bEfFr6ZGrq3HJ%2fv720ACDphqn4Rhzb&TARGET=3D-SM-https%3a%2f%2fwww%2emyserve=
r%2ecom%2fURI%2fhome%2ehtml%3fSMLOCALE=3DFR-FR
Accept-Language: fr,en-gb;q=3D0.5
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1=
.4322)
Host: www.myserver.com
Connection: Keep-Alive
SM_TRANSACTIONID: c2ce165c-0650-443a2030-000e-074810c5
SM_SDOMAIN: .myserver.com
Location: /siteminderagent/pwcgi/smpwservicescgi.exe?SMENC=3DUTF-8&SMTOKEN=
=3D{RC2}GuFcF7I/F5Sl03RqtNrPsMPlYiQZg/B1e2KFVDxfbVrnyC2MPyEDnDn1fDzHRadtrow=
aa0dtXRcvNGiN+cwPaCYlGkzRryxlqAMQ33n/JFc//j8GS51FTS31e00c0C0x4dszYnBMJfwIFO=
/TQ0vyWFW1RyszdoiTDAp8ZSwqgO0=3D&USERNAME=3Dtest_YM00&SMAUTHREASON=3D20&SMA=
GENTNAME=3D-SM-fshUMrkQm%2fB7%2bk8CAU%2fak459pCXPADL1l0bEfFr6ZGrq3HJ%2fv720=
ACDphqn4Rhzb&TARGET=3D-SM-https%3a%2f%2fwww%2emyserver%2ecom%2fURI%2fhome%2=
ehtml%3
SM_REALM:
SM_REALMOID:
SM_AUTHTYPE: Not Protected
SM_USER:
SM_USERDN:
mod_security-message: Access denied with code 403. Error normalising REQUES=
T_URI: Invalid character detected [0]
mod_security-action: 403

It seems that the error is due to the invalid character "0" if i understand=
 the log displayed. But why my URL works fine when i change "%3f" to "?" ?!
I continue my investigation, but if you can help me i will be happy...

Regards,
Christophe


> Message du 07/04/06 =C3=A0 18h41
> De : "Ivan Ristic" <iv...@we...>
> A : ze...@vo...
> Copie =C3=A0 : mod...@li...
> Objet : Re: [mod-security-users] Access denied with code 403. Error norma=
lising REQUEST_URI: Invalid URL encoding detected: not enough characters
>=20
> ze...@vo... wrote:
> >  Hi,
> >=20
> > I face a big problem using Mod Security 1.9.2.
> >=20
> > My web server architecture uses Siteminder and i use this kind of URL t=
o
> > change or modify password:
> >=20
> > https://www.myserver.com/siteminderagent/pwcgi/smpwservicescgi.exe
>=20
>   The URL works fine work me.
>=20
>   Are you sure you get the same result with "SecFilterCheckURLEncoding Of=
f"?
>=20
>=20
> > ModSecurity logs as following:
>=20
>   Can you get me the audit log entry for this problem?
>=20
>=20
> > [06/Apr/2006:17:45:06 +0200]
> > [www.myserver.com/sid#115800][rid#32ef88][/siteminderagent/pwcgi/smpwse=
rvicescgi.
> > exe][1] Access denied with code 403. Error normalising REQUEST_URI:
> > Invalid URL encoding detected: not enough characters
>=20
>   This message would typically appear when there's an % at the end
>   of the URI but the two hexadecimal characters that need to follow it
>   aren't.
>=20
> --=20
> Ivan Ristic, Technical Director
> Thinking Stone, http://www.thinkingstone.com
> ModSecurity: Open source Web Application Firewall
> Apache Security (O'Reilly): http://www.apachesecurity.net
>=20
>

Re: [mod-security-users] inclusive filter rule set "default deny all mode"

[Carles B. <cbo...@is...>]

joe barbish wrote:
> I added debug level 9 and got a little better understanding of what is 
> happening.
> In testing I got this rule to work.
>  
> SecFilterSelective REQUEST_URI 
> "!^(/mls_fsbo_signup.php|/00.00-web_style_sheet.css|/button.php)$"
>  
> Still the problem is I have 54 scripts to include in this rule and the 
> rule will not get clean syntax if I code it with one script name per 
> contuined line.
> I am running version 1.9.2
> How can I contuine rule across many lines?
>  
> Would coding the rules this way work?
> SecFilterSelective REQUEST_URI "!^/mls_fsbo_signup.php"  plus
> SecFilterSelective REQUEST_URI "!^/0.00-web_style_sheet.css" plus
> SecFilterSelective REQUEST_URI "!^/button.php"
>  do the trick
Yes you can, just use the keyword "chain" to actually chain two or more 
rules together. Check it out at the manual, but the sintax is the
same that you are suggesting, use

SecFilterSelective REQUEST_URI "!^/mls_fsbo_signup.php"  chain
SecFilterSelective REQUEST_URI "!^/0.00-web_style_sheet.css" chain
SecFilterSelective REQUEST_URI "!^/button.php"
...... all the rest ...

With this ruleset, if request does not match any of you provided 
pathnames, it will finally be filtered out (taking action according to 
your action settings).

Regards.

Carles Bonamusa

Re: [mod-security-users] inclusive filter rule set "default deny all mode"

[joe b. <joe...@ya...>]

I added debug level 9 and got a little better understanding of what is happening.
  In testing I got this rule to work.
   
  SecFilterSelective REQUEST_URI "!^(/mls_fsbo_signup.php|/00.00-web_style_sheet.css|/button.php)$"
   
  Still the problem is I have 54 scripts to include in this rule and the rule will not get clean syntax if I code it with one script name per contuined line.
  I am running version 1.9.2
  How can I contuine rule across many lines?
   
  Would coding the rules this way work?
  SecFilterSelective REQUEST_URI "!^/mls_fsbo_signup.php"  plus
  SecFilterSelective REQUEST_URI "!^/0.00-web_style_sheet.css" plus
  SecFilterSelective REQUEST_URI "!^/button.php"
   do the trick

Ivan Ristic <iv...@we...> wrote:
  joe barbish wrote:
> I tried this to list all the application files
> 
> SecFilterSelective SCRIPT_FILENAME "!^00.00_Header.htm"
> SecFilterSelective SCRIPT_FILENAME "!^00.00_Header.php"
> SecFilterSelective SCRIPT_FILENAME "!^00.00-web_style_sheet.css"
> SecFilterSelective SCRIPT_FILENAME "!^99.00-mls_ home_page_count.php"
> SecFilterSelective SCRIPT_FILENAME "!^background5.jpg"
> SecFilterSelective SCRIPT_FILENAME "!^background6.jpg"
> SecFilterSelective SCRIPT_FILENAME "!^background7.jpg"
> 
> and first rule terminates everything.

Joe,

A very useful ModSecurity feature called debug logging allows
you to learn about how rules are processed. Since you are new
to ModSecurity you need to turn debug logging on, set debug
log level to 9, and observe what happens as you experiment.

Here are some tips:

* A dot is a metacharacter in regular expressions. You
need to write it as \.

* SCRIPT_FILENAME contains a full path to the
file. Your rules only look at the base name. So you
need to anchor the regular expression at the end:

"!background\.jpg$"

Even better, use SCRIPT_BASENAME with 1.9.3-rc2 or better.
This variable contains only the basename, which is what
you seem to want.


> There are a lot more that 7
> files, so tried this
> 
> SecFilterSelective SCRIPT_FILENAME "!^(00.00_Header.htm
> |00.00_Header.php
> |00.00-web_style_sheet.css
> |99.00-mls_ home_page_count.php
> |background5.jpg
> |background6.jpg
> |background7.jpg
> |background8.jpg
> |button.php
> |class.phpmailer.php
> |index.htm)$"
> 
> and got syntax error on this !^(

You have to let the parser know the next line is a continuation
of the directive. Apache supports using "\" as the last character on
the line for this purpose.

-- 
Ivan Ristic, Technical Director
Thinking Stone, http://www.thinkingstone.com
ModSecurity: Open source Web Application Firewall
Apache Security (O'Reilly): http://www.apachesecurity.net


-------------------------------------------------------
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


		
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.  Great rates starting at 1&cent;/min.

Re: [mod-security-users] inclusive filter rule set "default deny all mode"

[Ivan R. <iv...@we...>]

joe barbish wrote:
> I tried this to list all the application files
> 
> SecFilterSelective SCRIPT_FILENAME "!^00.00_Header.htm"
> SecFilterSelective SCRIPT_FILENAME "!^00.00_Header.php"
> SecFilterSelective SCRIPT_FILENAME "!^00.00-web_style_sheet.css"
> SecFilterSelective SCRIPT_FILENAME "!^99.00-mls_ home_page_count.php"
> SecFilterSelective SCRIPT_FILENAME "!^background5.jpg"
> SecFilterSelective SCRIPT_FILENAME "!^background6.jpg"
> SecFilterSelective SCRIPT_FILENAME "!^background7.jpg"
>  
> and first rule terminates everything.

  Joe,

  A very useful ModSecurity feature called debug logging allows
  you to learn about how rules are processed. Since you are new
  to ModSecurity you need to turn debug logging on, set debug
  log level to 9, and observe what happens as you experiment.

  Here are some tips:

  * A dot is a metacharacter in regular expressions. You
    need to write it as \.

  * SCRIPT_FILENAME contains a full path to the
    file. Your rules only look at the base name. So you
    need to anchor the regular expression at the end:

    "!background\.jpg$"

    Even better, use SCRIPT_BASENAME with 1.9.3-rc2 or better.
    This variable contains only the basename, which is what
    you seem to want.


> There are a lot more that 7
> files, so tried this
>  
> SecFilterSelective SCRIPT_FILENAME "!^(00.00_Header.htm
> |00.00_Header.php
> |00.00-web_style_sheet.css
> |99.00-mls_ home_page_count.php
> |background5.jpg
> |background6.jpg
> |background7.jpg
> |background8.jpg
> |button.php
> |class.phpmailer.php
> |index.htm)$"
>  
> and got syntax error on this  !^(

  You have to let the parser know the next line is a continuation
  of the directive. Apache supports using "\" as the last character on
  the line for this purpose.

-- 
Ivan Ristic, Technical Director
Thinking Stone, http://www.thinkingstone.com
ModSecurity: Open source Web Application Firewall
Apache Security (O'Reilly): http://www.apachesecurity.net

Re: [mod-security-users] inclusive filter rule set "default deny all mode"

[joe b. <joe...@ya...>]

I tried this to list all the application files
  
SecFilterSelective SCRIPT_FILENAME "!^00.00_Header.htm"
SecFilterSelective SCRIPT_FILENAME "!^00.00_Header.php"
SecFilterSelective SCRIPT_FILENAME "!^00.00-web_style_sheet.css"
SecFilterSelective SCRIPT_FILENAME "!^99.00-mls_ home_page_count.php"
SecFilterSelective SCRIPT_FILENAME "!^background5.jpg"
SecFilterSelective SCRIPT_FILENAME "!^background6.jpg"
SecFilterSelective SCRIPT_FILENAME "!^background7.jpg"
   
  and first rule terminates everything.  There are a lot more that 7 files, so tried this
   
  SecFilterSelective SCRIPT_FILENAME "!^(00.00_Header.htm
|00.00_Header.php
|00.00-web_style_sheet.css
|99.00-mls_ home_page_count.php
|background5.jpg
|background6.jpg
|background7.jpg
|background8.jpg
|button.php
|class.phpmailer.php
|index.htm)$"
   
  and got syntax error on this  !^(

   
  Looks like rule can not cross over multiple lines, unless there is some continue on next line symbol I need to add in. This maybe a programming oversight in the parsing of the rule.

			
---------------------------------
Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates.

Re: [mod-security-users] inclusive filter rule set "default deny all mode"

[joe b. <joe...@ya...>]

Thanks Ryan
 
Can I have a sample rule for doing this?  
"For large sites, I use the same concept except with directories instead of files.  I list out all of the directory names in the DocumentRoot and make an inverted mod_security filter to deny connections for requests that don't list these." 
 
In the http-access-log I see that the search engines requesting just the file.html with out the complete http path. I do not want to deny the search engines so what ever rule format used must allow both search engines and normal website users and stop everything else.
 
I checked my Apache httpd.conf file. The freebsd port of the Apache13 activates a lot of standard dso modules and one of then is the proxy module. I had thought those dso modules had to have a directive coded for it before it became active. I see now that is not true. My website has been on the public internet for 5 years and this is the first I have been hit with an attack. I commented out the load for the proxy module in my  httpd.conf file. Thanks for catching that.
 
I have tried to active SecChrootDir /chroot/apache and received an syntax error.
Read the modsecurity manual and the details of how to use it as very vague.
 
My Apache server contains all the application files in /usr/local/www/data  is that the path I should use in the SecChrootDir  command?
 


Ryan Barnett <rcb...@gm...> wrote:    Close.  The concept is sound, except that you need to use a different mod_security location specifier rather than Arg_pg.  The "ARG_XXX" locations are variable arguments to applications (which is the data passed to interactive/dynamic pages after the "?" characters - such as /directory1/file2.php?login=XXX).  From looking at your URLs below, it only looks like you would have one web page that might accept data (the login.php page).
   
  In order to set a mod_security filter location for these files, you should use of of the following directives -
  - SCRIPT_FILENAME
  - REQUEST_URI
  - REQUEST_FILENAME
  - THE_REQUEST
 
  So, for your examples, you could use the following to combine all 5 of those to a one line filter -
   
  SecFilterSelective SCRIPT_FILENAME "!^(00_main_menu.htm|01_install_intro.htm|02_select_hw.htm|03_boot_1st_time.htm|04_login.php)$"
   
  Two other things to think about - 
   
  1) For large sites, I use the same concept except with directories instead of files.  I list out all of the directory names in the DocumentRoot and make an inverted mod_security filter to deny connections for requests that don't list these. 
   
  2) Going back to the very beginning of your first post - those web requests you listed as seeing are a bit troublesome.  They all seem to be probes against your web server to verify if you can be used as an open proxy server.  The first two requests are from SOCKS proxy checkers, the 3rd is an HTTP CONNECT check to see if your server will connect to an SMTP host (for use by SPAMMERS) and the last is a request to a normal website.  The probes themselves are not what worries me, as these happen all the time.  What worrries me are the status codes returned by your web server - 200 OK.  This normally means that your server processed these requests successfully.  Are you using mod_security to return bogus HTTP Response Codes???  I sure hope so, otherwise you need to disable the mod_proxy module ASAP. 
   
  -- 
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/8/06, joe barbish <joe...@ya...> wrote:       Thanks Ryan
   
  If I understood your references and the manual correctly then these filter rules is what I need.
   
  1 SecFilterEngine On
  2 SecChrootDir /chroot/apache
  3 SecFilterDefaultAction "deny,log,status:404"
4 SecFilterSelective Arg_pg "!^http://www.domanname.com:80/00_main_menu.htm"
5 SecFilterSelective Arg_pg "!^http://www.domanname.com:80/01_install_intro.htm" 
6 SecFilterSelective Arg_pg "!^http://www.domanname.com:80/02_select_hw.htm"
7 SecFilterSelective Arg_pg "!^http://www.domanname.com:80/03_boot_1st_time.htm"
8 SecFilterSelective Arg_pg "!^http://www.domanname.com:80/04_login.php" 
   
   
  What these rules are telling mod_security is 
  1 Turn on the filter engine
  2 automatically chroot apache
  3 says what action to take for all the other junk that comes into my webserver.
  4-8 rules say that if the http request is not for one of these path file names which make up my web application then its to be denied
   
   
  So as long as the remote users browser follows the natural flow of the web application it will be using the correct path file names and mod_security will allow it to execute. Everything else is denied by default and logged and the remote user gets the standard error screen that only tells him that what ever trick/attack he was trying was not successfully. 
   
  Am I correct in my understanding of the above filter rules???

     
   
  
Ryan Barnett <rcb...@gm...> wrote:
    Joe,
The short answer is yes, you can create whitelist/positive (or as the term you used - inclusive ) filters with mod_security by using the inverted rulesets ( http://www.modsecurity.org/documentation/modsecurity-apache/stable/04-rules.html#N103C4).  These rules essentially mean match the regular expression that "doesn't" match this string.

For some examples, you can take a look at the free chapter from my book - Preventing Web Attacks with Apache - 
http://www.informit.com/articles/article.asp?p=442984
  
In this chapter, I give examples of how to mitigate the WASC Web Security Threat Classification with Apache (and mod_security).  Many of the examples I present use inverted mod_security filters.  Here is one example - 
 
  Apache Countermeasures for SQL Injection Attacks  SQL Injection is best solved through two practices: Input Validation and Stored Procedures with parameterized queries. Input validation is a practice that will prevent SQL Injection exploits as well as a multitude of other application attacks. This process should be followed for all applications, not just those that use SQL queries. Using stored procedures for SQL queries ensures that the user input is not executed as part of the SQL query. (Note: Make sure to use parameterized queries to ensure that the stored procedure itself is not vulnerable to SQL Injection.) The following recommendations will help prevent successful SQL Injection attacks. 
  User-Input Sanitization Checking   The best way to filter data is with a default-deny regular expression that includes only the type of data the web application expects to receive. 
  Character-Set and Length Restriction   Restrict the valid types of characters a user may submit to a web application. Using regular expressions, make the input filters as strict as possible with anchors at the beginning and end. Table 7.1 lists some example regular expressions and their meaning. 
  Table 7.1 Example Regular Expressions and Their Meaning
            Purpose of Expression
    Regular Expression
      Only allow letters with a length restriction between 1 and 10 characters.
    /^[a-zA-Z]{1,10}$/
      Allow letters and numbers with a length restriction between 1 and 10 characters.
    /^[a-zA-Z0-9]{1,10}$/
      Allow letters, numbers, and some punctuation with a length restriction between 1 and 10 characters.
    /^[a-zA-Z0-9\.@!]{1,10}$/

  
 
  The following is an example of using these regular expressions with Mod_Security to protect the ID parameter for the article.asp page from earlier:

SecFilterSelective SCRIPT_FILENAME "article.asp    " chain  SecFilterSelective ARG_ID "!^[a-zA-Z0-9\.@!]{1,10}$"
  If for some reason you cannot take that approach and must instead use a "deny-what-is-bad" method, then at minimum remove or escape single quotes ('), semicolons (;), dashes, hyphens(-), and parenthesis("()"). 
  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/8/06, joe barbish <joe...@ya...> wrote:
> 
> My Apache server came under attack starting April fools day. I first noticed 
> my ipfilter inclusive firewall logging outbound packets on the the default 
> deny all rule. Checking the http-access.log I saw these requests being
> serviced by my server.
>  
> 218-166-163-180.dynamic.hinet.net - - [06/Apr/2006:10:11:25 
> -0400] "\x04\x01" 200 0 "-" "-"
> 218-166-163-180.dynamic.hinet.net - - [06/Apr/2006:10:11:45
> -0400] "\x05\x01" 200 0 "-" "-" 
> 218-166-163-180.dynamic.hinet.net - - [06/Apr/2006:10:11:45
> -0400] "CONNECT 4.79.181.15:25 HTTP/1.1" 200 7014 "-" "-" 
> 218-166-163-180.dynamic.hinet.net - - [06/Apr/2006:10:11:46
> -0400] "GET http://www.ebay.com/ HTTP/1.1" 200 7014 "-" "Mozilla/4.0 
> (compatible; MSIE 5.00; Windows 98)" 
>  
> I posted a msg on the freebsd questions list and someone suggest I look at
> mod_security. At first review I was interested enough to install the freebsd 
> port of the software. As I read the manual, slowly I began to realize 
> something was absent.
>  
> The mod_security home page calls mod_security a web application firewall. 
>  
> In software firewalls there are 2 different types of filter rule sets. 
>   
> The exclusive firewall and the inclusive firewall. 
>  
> An exclusive firewall allows all services through except for those matching
> a set of rules that block certain services.  
>  
> An inclusive firewall does the reverse. It only allows services matching the
> rules through and blocks everything else.  Inclusive firewalls are much,
> much safer than exclusive firewalls.
>  
> Now applying that to the mod_security filter rules I see explained in the
> manual and the examples provided at the mod_security home page it becomes
> very obvious that all the mod_security filter rules are of the exclusive 
> type. 
>  
> My web application is very vanilla. It uses hmtl and php for a counter of
> page hits. It has no upload function, but does have a download function
> launched from a link. No url's have any embedded tags. 
>  
> So I am interested in writing mod_security filter rules in reverse.
> Basically I want to say deny everything except the get requests for the
> files.htm or files.php names I see in the HTTP-access log for normal valid 
> usage of my web application. This sure would be a shorter filter include
> file than including all the includes necessary to specify all the different
> variations of attack request strings.
>   
> Is there any example of how to accomplish building a inclusive mod_security
> filter rules file.
>  
> Maybe the next question should be is this even possible?
>  
> And if not, then why not, and can it be changed to take the inclusive 
> approach as well as the current exclusive approach?
>  
> If mod_security is going to be called a web application firewall then it
> needs to be able to do both inclusive and exclusive filter rule 
> configurations.
>  
> If it's indeed possible to build an inclusive filter rule set, I have a
> workbench development website that I can use to be the test vehicle. Would
> need the filter rules to specify deny everything and one filter rule for 
> accepting the get file.html request. 
>  
> Thanks for your help
> Joe
>  
>  
>  
>  
>  
> 
> Joe
>  
>  
>  
>  
>  
> 
> 
> ________________________________
> How low will we go? Check out Yahoo! Messenger's low PC-to-Phone call rates.
> 
> ________________________________
> Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates 
> starting at 1�/min. 
> 
> 
> 
> 


      
---------------------------------
  Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates.   
  







		
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.  Great rates starting at 1&cent;/min.

Re: [mod-security-users] inclusive filter rule set "default deny all mode"

[Ryan B. <rcb...@gm...>]

Q2xvc2UuICBUaGUgY29uY2VwdCBpcyBzb3VuZCwgZXhjZXB0IHRoYXQgeW91IG5lZWQgdG8gdXNl
IGEgZGlmZmVyZW50Cm1vZF9zZWN1cml0eSBsb2NhdGlvbiBzcGVjaWZpZXIgcmF0aGVyIHRoYW4g
QXJnX3BnLiAgVGhlICJBUkdfWFhYIiBsb2NhdGlvbnMKYXJlIHZhcmlhYmxlIGFyZ3VtZW50cyB0
byBhcHBsaWNhdGlvbnMgKHdoaWNoIGlzIHRoZSBkYXRhIHBhc3NlZCB0bwppbnRlcmFjdGl2ZS9k
eW5hbWljIHBhZ2VzIGFmdGVyIHRoZSAiPyIgY2hhcmFjdGVycyAtIHN1Y2ggYXMKL2RpcmVjdG9y
eTEvZmlsZTIucGhwP2xvZ2luPVhYWCkuICBGcm9tIGxvb2tpbmcgYXQgeW91ciBVUkxzIGJlbG93
LCBpdCBvbmx5Cmxvb2tzIGxpa2UgeW91IHdvdWxkIGhhdmUgb25lIHdlYiBwYWdlIHRoYXQgbWln
aHQgYWNjZXB0IGRhdGEgKHRoZQpsb2dpbi5waHBwYWdlKS4KCkluIG9yZGVyIHRvIHNldCBhIG1v
ZF9zZWN1cml0eSBmaWx0ZXIgbG9jYXRpb24gZm9yIHRoZXNlIGZpbGVzLCB5b3Ugc2hvdWxkCnVz
ZSBvZiBvZiB0aGUgZm9sbG93aW5nIGRpcmVjdGl2ZXMgLQotIFNDUklQVF9GSUxFTkFNRQotIFJF
UVVFU1RfVVJJCi0gUkVRVUVTVF9GSUxFTkFNRQotIFRIRV9SRVFVRVNUCgpTbywgZm9yIHlvdXIg
ZXhhbXBsZXMsIHlvdSBjb3VsZCB1c2UgdGhlIGZvbGxvd2luZyB0byBjb21iaW5lIGFsbCA1IG9m
IHRob3NlCnRvIGEgb25lIGxpbmUgZmlsdGVyIC0KClNlY0ZpbHRlclNlbGVjdGl2ZSBTQ1JJUFRf
RklMRU5BTUUKIiFeKDAwX21haW5fbWVudS5odG18MDFfaW5zdGFsbF9pbnRyby5odG18MDJfc2Vs
ZWN0X2h3Lmh0bXwwM19ib290XzFzdF90aW1lLmh0bXwwNF9sb2dpbi5waHApJCIKClR3byBvdGhl
ciB0aGluZ3MgdG8gdGhpbmsgYWJvdXQgLQoKMSkgRm9yIGxhcmdlIHNpdGVzLCBJIHVzZSB0aGUg
c2FtZSBjb25jZXB0IGV4Y2VwdCB3aXRoIGRpcmVjdG9yaWVzIGluc3RlYWQKb2YgZmlsZXMuICBJ
IGxpc3Qgb3V0IGFsbCBvZiB0aGUgZGlyZWN0b3J5IG5hbWVzIGluIHRoZSBEb2N1bWVudFJvb3Qg
YW5kCm1ha2UgYW4gaW52ZXJ0ZWQgbW9kX3NlY3VyaXR5IGZpbHRlciB0byBkZW55IGNvbm5lY3Rp
b25zIGZvciByZXF1ZXN0cyB0aGF0CmRvbid0IGxpc3QgdGhlc2UuCgoyKSBHb2luZyBiYWNrIHRv
IHRoZSB2ZXJ5IGJlZ2lubmluZyBvZiB5b3VyIGZpcnN0IHBvc3QgLSB0aG9zZSB3ZWIgcmVxdWVz
dHMKeW91IGxpc3RlZCBhcyBzZWVpbmcgYXJlIGEgYml0IHRyb3VibGVzb21lLiAgVGhleSBhbGwg
c2VlbSB0byBiZSBwcm9iZXMKYWdhaW5zdCB5b3VyIHdlYiBzZXJ2ZXIgdG8gdmVyaWZ5IGlmIHlv
dSBjYW4gYmUgdXNlZCBhcyBhbiBvcGVuIHByb3h5CnNlcnZlci4gIFRoZSBmaXJzdCB0d28gcmVx
dWVzdHMgYXJlIGZyb20gU09DS1MgcHJveHkgY2hlY2tlcnMsIHRoZSAzcmQgaXMgYW4KSFRUUCBD
T05ORUNUIGNoZWNrIHRvIHNlZSBpZiB5b3VyIHNlcnZlciB3aWxsIGNvbm5lY3QgdG8gYW4gU01U
UCBob3N0IChmb3IKdXNlIGJ5IFNQQU1NRVJTKSBhbmQgdGhlIGxhc3QgaXMgYSByZXF1ZXN0IHRv
IGEgbm9ybWFsIHdlYnNpdGUuICBUaGUgcHJvYmVzCnRoZW1zZWx2ZXMgYXJlIG5vdCB3aGF0IHdv
cnJpZXMgbWUsIGFzIHRoZXNlIGhhcHBlbiBhbGwgdGhlIHRpbWUuICBXaGF0CndvcnJyaWVzIG1l
IGFyZSB0aGUgc3RhdHVzIGNvZGVzIHJldHVybmVkIGJ5IHlvdXIgd2ViIHNlcnZlciAtIDIwMCBP
Sy4gIFRoaXMKbm9ybWFsbHkgbWVhbnMgdGhhdCB5b3VyIHNlcnZlciBwcm9jZXNzZWQgdGhlc2Ug
cmVxdWVzdHMgc3VjY2Vzc2Z1bGx5LiAgQXJlCnlvdSB1c2luZyBtb2Rfc2VjdXJpdHkgdG8gcmV0
dXJuIGJvZ3VzIEhUVFAgUmVzcG9uc2UgQ29kZXM/Pz8gIEkgc3VyZSBob3BlCnNvLCBvdGhlcndp
c2UgeW91IG5lZWQgdG8gZGlzYWJsZSB0aGUgbW9kX3Byb3h5IG1vZHVsZSBBU0FQLgoKLS0KUnlh
biBDLiBCYXJuZXR0CldlYiBBcHBsaWNhdGlvbiBTZWN1cml0eSBDb25zb3J0aXVtIChXQVNDKSBN
ZW1iZXIKQ0lTIEFwYWNoZSBCZW5jaG1hcmsgUHJvamVjdCBMZWFkClNBTlMgSW5zdHJ1Y3Rvcjog
U2VjdXJpbmcgQXBhY2hlCkdDSUEsIEdDRkEsIEdDSUgsIEdTTkEsIEdDVVgsIEdTRUMKQXV0aG9y
OiBQcmV2ZW50aW5nIFdlYiBBdHRhY2tzIHdpdGggQXBhY2hlCgoKT24gNC84LzA2LCBqb2UgYmFy
YmlzaCA8am9lYl83MjJAeWFob28uY29tPiB3cm90ZToKPgo+ICBUaGFua3MgUnlhbgo+Cj4gSWYg
SSB1bmRlcnN0b29kIHlvdXIgcmVmZXJlbmNlcyBhbmQgdGhlIG1hbnVhbCBjb3JyZWN0bHkgdGhl
biB0aGVzZSBmaWx0ZXIKPiBydWxlcyBpcyB3aGF0IEkgbmVlZC4KPgo+IDEgU2VjRmlsdGVyRW5n
aW5lIE9uCj4gMiBTZWNDaHJvb3REaXIgL2Nocm9vdC9hcGFjaGUKPiAzIFNlY0ZpbHRlckRlZmF1
bHRBY3Rpb24gImRlbnksbG9nLHN0YXR1czo0MDQiCj4gNCBTZWNGaWx0ZXJTZWxlY3RpdmUgQXJn
X3BnCj4gIiFeaHR0cDovL3d3dy5kb21hbm5hbWUuY29tOjgwLzAwX21haW5fbWVudS5odG0iCj4g
NSBTZWNGaWx0ZXJTZWxlY3RpdmUgQXJnX3BnCj4gIiFeaHR0cDovL3d3dy5kb21hbm5hbWUuY29t
OjgwLzAxX2luc3RhbGxfaW50cm8uaHRtIgo+IDYgU2VjRmlsdGVyU2VsZWN0aXZlIEFyZ19wZwo+
ICIhXmh0dHA6Ly93d3cuZG9tYW5uYW1lLmNvbTo4MC8wMl9zZWxlY3RfaHcuaHRtIgo+IDcgU2Vj
RmlsdGVyU2VsZWN0aXZlIEFyZ19wZwo+ICIhXmh0dHA6Ly93d3cuZG9tYW5uYW1lLmNvbTo4MC8w
M19ib290XzFzdF90aW1lLmh0bSIKPiA4IFNlY0ZpbHRlclNlbGVjdGl2ZSBBcmdfcGcgIiFeaHR0
cDovL3d3dy5kb21hbm5hbWUuY29tOjgwLzA0X2xvZ2luLnBocCIKPgo+Cj4gV2hhdCB0aGVzZSBy
dWxlcyBhcmUgdGVsbGluZyBtb2Rfc2VjdXJpdHkgaXMKPiAxIFR1cm4gb24gdGhlIGZpbHRlciBl
bmdpbmUKPiAyIGF1dG9tYXRpY2FsbHkgY2hyb290IGFwYWNoZQo+IDMgc2F5cyB3aGF0IGFjdGlv
biB0byB0YWtlIGZvciBhbGwgdGhlIG90aGVyIGp1bmsgdGhhdCBjb21lcyBpbnRvIG15Cj4gd2Vi
c2VydmVyLgo+IDQtOCBydWxlcyBzYXkgdGhhdCBpZiB0aGUgaHR0cCByZXF1ZXN0IGlzIG5vdCBm
b3Igb25lIG9mIHRoZXNlIHBhdGggZmlsZQo+IG5hbWVzIHdoaWNoIG1ha2UgdXAgbXkgd2ViIGFw
cGxpY2F0aW9uIHRoZW4gaXRzIHRvIGJlIGRlbmllZAo+Cj4KPiBTbyBhcyBsb25nIGFzIHRoZSBy
ZW1vdGUgdXNlcnMgYnJvd3NlciBmb2xsb3dzIHRoZSBuYXR1cmFsIGZsb3cgb2YgdGhlIHdlYgo+
IGFwcGxpY2F0aW9uIGl0IHdpbGwgYmUgdXNpbmcgdGhlIGNvcnJlY3QgcGF0aCBmaWxlIG5hbWVz
IGFuZCBtb2Rfc2VjdXJpdHkKPiB3aWxsIGFsbG93IGl0IHRvIGV4ZWN1dGUuIEV2ZXJ5dGhpbmcg
ZWxzZSBpcyBkZW5pZWQgYnkgZGVmYXVsdCBhbmQgbG9nZ2VkCj4gYW5kIHRoZSByZW1vdGUgdXNl
ciBnZXRzIHRoZSBzdGFuZGFyZCBlcnJvciBzY3JlZW4gdGhhdCBvbmx5IHRlbGxzIGhpbSB0aGF0
Cj4gd2hhdCBldmVyIHRyaWNrL2F0dGFjayBoZSB3YXMgdHJ5aW5nIHdhcyBub3Qgc3VjY2Vzc2Z1
bGx5Lgo+Cj4gQW0gSSBjb3JyZWN0IGluIG15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIGFib3ZlIGZp
bHRlciBydWxlcz8/Pwo+Cj4KPgo+ICpSeWFuIEJhcm5ldHQgPHJjYmFybmV0dEBnbWFpbC5jb20+
KiB3cm90ZToKPgo+IEpvZSwKPiBUaGUgc2hvcnQgYW5zd2VyIGlzIHllcywgeW91IGNhbiBjcmVh
dGUgd2hpdGVsaXN0L3Bvc2l0aXZlIChvciBhcyB0aGUgdGVybQo+IHlvdSB1c2VkIC0gaW5jbHVz
aXZlICkgZmlsdGVycyB3aXRoIG1vZF9zZWN1cml0eSBieSB1c2luZyB0aGUgaW52ZXJ0ZWQKPiBy
dWxlc2V0cyAoaHR0cDovL3d3dy5tb2RzZWN1cml0eS5vcmcvZG9jdW1lbnRhdGlvbi9tb2RzZWN1
cml0eS1hcGFjaGUvc3RhYmxlLzA0LXJ1bGVzLmh0bWwjTjEwM0M0KS4gIFRoZXNlCj4gcnVsZXMg
ZXNzZW50aWFsbHkgbWVhbiBtYXRjaCB0aGUgcmVndWxhciBleHByZXNzaW9uIHRoYXQgImRvZXNu
J3QiIG1hdGNoCj4gdGhpcyBzdHJpbmcuCj4KPiBGb3Igc29tZSBleGFtcGxlcywgeW91IGNhbiB0
YWtlIGEgbG9vayBhdCB0aGUgZnJlZSBjaGFwdGVyIGZyb20gbXkgYm9vayAtCj4gUHJldmVudGlu
ZyBXZWIgQXR0YWNrcyB3aXRoIEFwYWNoZSAtCj4gaHR0cDovL3d3dy5pbmZvcm1pdC5jb20vYXJ0
aWNsZXMvYXJ0aWNsZS5hc3A/cD00NDI5ODQKPgo+IEluIHRoaXMgY2hhcHRlciwgSSBnaXZlIGV4
YW1wbGVzIG9mIGhvdyB0byBtaXRpZ2F0ZSB0aGUgV0FTQyBXZWIgU2VjdXJpdHkKPiBUaHJlYXQg
Q2xhc3NpZmljYXRpb24gd2l0aCBBcGFjaGUgKGFuZCBtb2Rfc2VjdXJpdHkpLiAgTWFueSBvZiB0
aGUgZXhhbXBsZXMKPiBJIHByZXNlbnQgdXNlIGludmVydGVkIG1vZF9zZWN1cml0eSBmaWx0ZXJz
LiAgSGVyZSBpcyBvbmUgZXhhbXBsZSAtCj4KPiBBcGFjaGUgQ291bnRlcm1lYXN1cmVzIGZvciBT
UUwgSW5qZWN0aW9uIEF0dGFja3MgU1FMIEluamVjdGlvbiBpcyBiZXN0Cj4gc29sdmVkIHRocm91
Z2ggdHdvIHByYWN0aWNlczogSW5wdXQgVmFsaWRhdGlvbiBhbmQgU3RvcmVkIFByb2NlZHVyZXMg
d2l0aAo+IHBhcmFtZXRlcml6ZWQgcXVlcmllcy4gSW5wdXQgdmFsaWRhdGlvbiBpcyBhIHByYWN0
aWNlIHRoYXQgd2lsbCBwcmV2ZW50IFNRTAo+IEluamVjdGlvbiBleHBsb2l0cyBhcyB3ZWxsIGFz
IGEgbXVsdGl0dWRlIG9mIG90aGVyIGFwcGxpY2F0aW9uIGF0dGFja3MuIFRoaXMKPiBwcm9jZXNz
IHNob3VsZCBiZSBmb2xsb3dlZCBmb3IgYWxsIGFwcGxpY2F0aW9ucywgbm90IGp1c3QgdGhvc2Ug
dGhhdCB1c2UgU1FMCj4gcXVlcmllcy4gVXNpbmcgc3RvcmVkIHByb2NlZHVyZXMgZm9yIFNRTCBx
dWVyaWVzIGVuc3VyZXMgdGhhdCB0aGUgdXNlciBpbnB1dAo+IGlzIG5vdCBleGVjdXRlZCBhcyBw
YXJ0IG9mIHRoZSBTUUwgcXVlcnkuIChOb3RlOiBNYWtlIHN1cmUgdG8gdXNlCj4gcGFyYW1ldGVy
aXplZCBxdWVyaWVzIHRvIGVuc3VyZSB0aGF0IHRoZSBzdG9yZWQgcHJvY2VkdXJlIGl0c2VsZiBp
cyBub3QKPiB2dWxuZXJhYmxlIHRvIFNRTCBJbmplY3Rpb24uKSBUaGUgZm9sbG93aW5nIHJlY29t
bWVuZGF0aW9ucyB3aWxsIGhlbHAKPiBwcmV2ZW50IHN1Y2Nlc3NmdWwgU1FMIEluamVjdGlvbiBh
dHRhY2tzLgo+IFVzZXItSW5wdXQgU2FuaXRpemF0aW9uIENoZWNraW5nIFRoZSBiZXN0IHdheSB0
byBmaWx0ZXIgZGF0YSBpcyB3aXRoIGEKPiBkZWZhdWx0LWRlbnkgcmVndWxhciBleHByZXNzaW9u
IHRoYXQgaW5jbHVkZXMgb25seSB0aGUgdHlwZSBvZiBkYXRhIHRoZSB3ZWIKPiBhcHBsaWNhdGlv
biBleHBlY3RzIHRvIHJlY2VpdmUuCj4gQ2hhcmFjdGVyLVNldCBhbmQgTGVuZ3RoIFJlc3RyaWN0
aW9uIFJlc3RyaWN0IHRoZSB2YWxpZCB0eXBlcyBvZgo+IGNoYXJhY3RlcnMgYSB1c2VyIG1heSBz
dWJtaXQgdG8gYSB3ZWIgYXBwbGljYXRpb24uIFVzaW5nIHJlZ3VsYXIKPiBleHByZXNzaW9ucywg
bWFrZSB0aGUgaW5wdXQgZmlsdGVycyBhcyBzdHJpY3QgYXMgcG9zc2libGUgd2l0aCBhbmNob3Jz
IGF0Cj4gdGhlIGJlZ2lubmluZyBhbmQgZW5kLiBUYWJsZSA3LjEgbGlzdHMgc29tZSBleGFtcGxl
IHJlZ3VsYXIgZXhwcmVzc2lvbnMKPiBhbmQgdGhlaXIgbWVhbmluZy4KPiAqVGFibGUgNy4xICpF
eGFtcGxlIFJlZ3VsYXIgRXhwcmVzc2lvbnMgYW5kIFRoZWlyIE1lYW5pbmcKPiAgICAqUHVycG9z
ZSBvZiBFeHByZXNzaW9uKgo+ICAqUmVndWxhciBFeHByZXNzaW9uKgo+ICBPbmx5IGFsbG93IGxl
dHRlcnMgd2l0aCBhIGxlbmd0aCByZXN0cmljdGlvbiBiZXR3ZWVuIDEgYW5kIDEwIGNoYXJhY3Rl
cnMuCj4gIC9eW2EtekEtWl17MSwxMH0kLwo+ICBBbGxvdyBsZXR0ZXJzIGFuZCBudW1iZXJzIHdp
dGggYSBsZW5ndGggcmVzdHJpY3Rpb24gYmV0d2VlbiAxIGFuZCAxMAo+IGNoYXJhY3RlcnMuCj4g
IC9eW2EtekEtWjAtOV17MSwxMH0kLwo+ICBBbGxvdyBsZXR0ZXJzLCBudW1iZXJzLCBhbmQgc29t
ZSBwdW5jdHVhdGlvbiB3aXRoIGEgbGVuZ3RoIHJlc3RyaWN0aW9uCj4gYmV0d2VlbiAxIGFuZCAx
MCBjaGFyYWN0ZXJzLgo+ICAvXlthLXpBLVowLTlcLkAhXXsxLDEwfSQvCj4KPgo+IFRoZSBmb2xs
b3dpbmcgaXMgYW4gZXhhbXBsZSBvZiB1c2luZyB0aGVzZSByZWd1bGFyIGV4cHJlc3Npb25zIHdp
dGgKPiBNb2RfU2VjdXJpdHkgdG8gcHJvdGVjdCB0aGUgSUQgcGFyYW1ldGVyIGZvciB0aGUgYXJ0
aWNsZS5hc3AgcGFnZSBmcm9tCj4gZWFybGllcjoKPgo+IFNlY0ZpbHRlclNlbGVjdGl2ZSBTQ1JJ
UFRfRklMRU5BTUUgImFydGljbGUuYXNwICAiIGNoYWluICBTZWNGaWx0ZXJTZWxlY3RpdmUgQVJH
X0lEICIhXlthLXpBLVowLTlcLkAhXXsxLDEwfSQiCj4KPiBJZiBmb3Igc29tZSByZWFzb24geW91
IGNhbm5vdCB0YWtlIHRoYXQgYXBwcm9hY2ggYW5kIG11c3QgaW5zdGVhZCB1c2UgYQo+ICJkZW55
LXdoYXQtaXMtYmFkIiBtZXRob2QsIHRoZW4gYXQgbWluaW11bSByZW1vdmUgb3IgZXNjYXBlIHNp
bmdsZSBxdW90ZXMKPiAoJyksIHNlbWljb2xvbnMgKDspLCBkYXNoZXMsIGh5cGhlbnMoLSksIGFu
ZCBwYXJlbnRoZXNpcygiKCkiKS4KPiBIb3BlIHRoaXMgaGVscHMuCj4KPiAtLQo+IFJ5YW4gQy4g
QmFybmV0dAo+IFdlYiBBcHBsaWNhdGlvbiBTZWN1cml0eSBDb25zb3J0aXVtIChXQVNDKSBNZW1i
ZXIKPiBDSVMgQXBhY2hlIEJlbmNobWFyayBQcm9qZWN0IExlYWQKPiBTQU5TIEluc3RydWN0b3I6
IFNlY3VyaW5nIEFwYWNoZQo+IEdDSUEsIEdDRkEsIEdDSUgsIEdTTkEsIEdDVVgsIEdTRUMKPiBB
dXRob3I6IFByZXZlbnRpbmcgV2ViIEF0dGFja3Mgd2l0aCBBcGFjaGUKPgo+Cj4gT24gNC84LzA2
LCBqb2UgYmFyYmlzaCA8am9lYl83MjJAeWFob28uY29tPiB3cm90ZToKPiA+Cj4gPiBNeSBBcGFj
aGUgc2VydmVyIGNhbWUgdW5kZXIgYXR0YWNrIHN0YXJ0aW5nIEFwcmlsIGZvb2xzIGRheS4gSSBm
aXJzdAo+IG5vdGljZWQKPiA+IG15IGlwZmlsdGVyIGluY2x1c2l2ZSBmaXJld2FsbCBsb2dnaW5n
IG91dGJvdW5kIHBhY2tldHMgb24gdGhlIHRoZQo+IGRlZmF1bHQKPiA+IGRlbnkgYWxsIHJ1bGUu
IENoZWNraW5nIHRoZSBodHRwLWFjY2Vzcy5sb2cgSSBzYXcgdGhlc2UgcmVxdWVzdHMgYmVpbmcK
PiA+IHNlcnZpY2VkIGJ5IG15IHNlcnZlci4KPiA+Cj4gPiAyMTgtMTY2LTE2My0xODAuZHluYW1p
Yy5oaW5ldC5uZXQgLSAtIFswNi9BcHIvMjAwNjoxMDoxMToyNQo+ID4gLTA0MDBdICJceDA0XHgw
MSIgMjAwIDAgIi0iICItIgo+ID4gMjE4LTE2Ni0xNjMtMTgwLmR5bmFtaWMuaGluZXQubmV0IC0g
LSBbMDYvQXByLzIwMDY6MTA6MTE6NDUKPiA+IC0wNDAwXSAiXHgwNVx4MDEiIDIwMCAwICItIiAi
LSIKPiA+IDIxOC0xNjYtMTYzLTE4MC5keW5hbWljLmhpbmV0Lm5ldCAtIC0gWzA2L0Fwci8yMDA2
OjEwOjExOjQ1Cj4gPiAtMDQwMF0gIkNPTk5FQ1QgNC43OS4xODEuMTU6MjUgSFRUUC8xLjEiIDIw
MCA3MDE0ICItIiAiLSIKPiA+IDIxOC0xNjYtMTYzLTE4MC5keW5hbWljLmhpbmV0Lm5ldCAtIC0g
WzA2L0Fwci8yMDA2OjEwOjExOjQ2Cj4gPiAtMDQwMF0gIkdFVCBodHRwOi8vd3d3LmViYXkuY29t
LyBIVFRQLzEuMSIgMjAwIDcwMTQgIi0iICJNb3ppbGxhLzQuMAo+ID4gKGNvbXBhdGlibGU7IE1T
SUUgNS4wMDsgV2luZG93cyA5OCkiCj4gPgo+ID4gSSBwb3N0ZWQgYSBtc2cgb24gdGhlIGZyZWVi
c2QgcXVlc3Rpb25zIGxpc3QgYW5kIHNvbWVvbmUgc3VnZ2VzdCBJIGxvb2sKPiBhdAo+ID4gbW9k
X3NlY3VyaXR5LiBBdCBmaXJzdCByZXZpZXcgSSB3YXMgaW50ZXJlc3RlZCBlbm91Z2ggdG8gaW5z
dGFsbCB0aGUKPiBmcmVlYnNkCj4gPiBwb3J0IG9mIHRoZSBzb2Z0d2FyZS4gQXMgSSByZWFkIHRo
ZSBtYW51YWwsIHNsb3dseSBJIGJlZ2FuIHRvIHJlYWxpemUKPiA+IHNvbWV0aGluZyB3YXMgYWJz
ZW50Lgo+ID4KPiA+IFRoZSBtb2Rfc2VjdXJpdHkgaG9tZSBwYWdlIGNhbGxzIG1vZF9zZWN1cml0
eSBhIHdlYiBhcHBsaWNhdGlvbgo+IGZpcmV3YWxsLgo+ID4KPiA+IEluIHNvZnR3YXJlIGZpcmV3
YWxscyB0aGVyZSBhcmUgMiBkaWZmZXJlbnQgdHlwZXMgb2YgZmlsdGVyIHJ1bGUgc2V0cy4KPiA+
Cj4gPiBUaGUgZXhjbHVzaXZlIGZpcmV3YWxsIGFuZCB0aGUgaW5jbHVzaXZlIGZpcmV3YWxsLgo+
ID4KPiA+IEFuIGV4Y2x1c2l2ZSBmaXJld2FsbCBhbGxvd3MgYWxsIHNlcnZpY2VzIHRocm91Z2gg
ZXhjZXB0IGZvciB0aG9zZQo+IG1hdGNoaW5nCj4gPiBhIHNldCBvZiBydWxlcyB0aGF0IGJsb2Nr
IGNlcnRhaW4gc2VydmljZXMuCj4gPgo+ID4gQW4gaW5jbHVzaXZlIGZpcmV3YWxsIGRvZXMgdGhl
IHJldmVyc2UuIEl0IG9ubHkgYWxsb3dzIHNlcnZpY2VzIG1hdGNoaW5nCj4gdGhlCj4gPiBydWxl
cyB0aHJvdWdoIGFuZCBibG9ja3MgZXZlcnl0aGluZyBlbHNlLiAgSW5jbHVzaXZlIGZpcmV3YWxs
cyBhcmUgbXVjaCwKPiA+IG11Y2ggc2FmZXIgdGhhbiBleGNsdXNpdmUgZmlyZXdhbGxzLgo+ID4K
PiA+IE5vdyBhcHBseWluZyB0aGF0IHRvIHRoZSBtb2Rfc2VjdXJpdHkgZmlsdGVyIHJ1bGVzIEkg
c2VlIGV4cGxhaW5lZCBpbgo+IHRoZQo+ID4gbWFudWFsIGFuZCB0aGUgZXhhbXBsZXMgcHJvdmlk
ZWQgYXQgdGhlIG1vZF9zZWN1cml0eSBob21lIHBhZ2UgaXQKPiBiZWNvbWVzCj4gPiB2ZXJ5IG9i
dmlvdXMgdGhhdCBhbGwgdGhlIG1vZF9zZWN1cml0eSBmaWx0ZXIgcnVsZXMgYXJlIG9mIHRoZSBl
eGNsdXNpdmUKPgo+ID4gdHlwZS4KPiA+Cj4gPiBNeSB3ZWIgYXBwbGljYXRpb24gaXMgdmVyeSB2
YW5pbGxhLiBJdCB1c2VzIGhtdGwgYW5kIHBocCBmb3IgYSBjb3VudGVyCj4gb2YKPiA+IHBhZ2Ug
aGl0cy4gSXQgaGFzIG5vIHVwbG9hZCBmdW5jdGlvbiwgYnV0IGRvZXMgaGF2ZSBhIGRvd25sb2Fk
IGZ1bmN0aW9uCj4gPiBsYXVuY2hlZCBmcm9tIGEgbGluay4gTm8gdXJsJ3MgaGF2ZSBhbnkgZW1i
ZWRkZWQgdGFncy4KPiA+Cj4gPiBTbyBJIGFtIGludGVyZXN0ZWQgaW4gd3JpdGluZyBtb2Rfc2Vj
dXJpdHkgZmlsdGVyIHJ1bGVzIGluIHJldmVyc2UuCj4gPiBCYXNpY2FsbHkgSSB3YW50IHRvIHNh
eSBkZW55IGV2ZXJ5dGhpbmcgZXhjZXB0IHRoZSBnZXQgcmVxdWVzdHMgZm9yIHRoZQo+ID4gZmls
ZXMuaHRtIG9yIGZpbGVzLnBocCBuYW1lcyBJIHNlZSBpbiB0aGUgSFRUUC1hY2Nlc3MgbG9nIGZv
ciBub3JtYWwKPiB2YWxpZAo+ID4gdXNhZ2Ugb2YgbXkgd2ViIGFwcGxpY2F0aW9uLiBUaGlzIHN1
cmUgd291bGQgYmUgYSBzaG9ydGVyIGZpbHRlciBpbmNsdWRlCj4gPiBmaWxlIHRoYW4gaW5jbHVk
aW5nIGFsbCB0aGUgaW5jbHVkZXMgbmVjZXNzYXJ5IHRvIHNwZWNpZnkgYWxsIHRoZQo+IGRpZmZl
cmVudAo+ID4gdmFyaWF0aW9ucyBvZiBhdHRhY2sgcmVxdWVzdCBzdHJpbmdzLgo+ID4KPiA+IElz
IHRoZXJlIGFueSBleGFtcGxlIG9mIGhvdyB0byBhY2NvbXBsaXNoIGJ1aWxkaW5nIGEgaW5jbHVz
aXZlCj4gbW9kX3NlY3VyaXR5Cj4gPiBmaWx0ZXIgcnVsZXMgZmlsZS4KPiA+Cj4gPiBNYXliZSB0
aGUgbmV4dCBxdWVzdGlvbiBzaG91bGQgYmUgaXMgdGhpcyBldmVuIHBvc3NpYmxlPwo+ID4KPiA+
IEFuZCBpZiBub3QsIHRoZW4gd2h5IG5vdCwgYW5kIGNhbiBpdCBiZSBjaGFuZ2VkIHRvIHRha2Ug
dGhlIGluY2x1c2l2ZQo+ID4gYXBwcm9hY2ggYXMgd2VsbCBhcyB0aGUgY3VycmVudCBleGNsdXNp
dmUgYXBwcm9hY2g/Cj4gPgo+ID4gSWYgbW9kX3NlY3VyaXR5IGlzIGdvaW5nIHRvIGJlIGNhbGxl
ZCBhIHdlYiBhcHBsaWNhdGlvbiBmaXJld2FsbCB0aGVuIGl0Cj4gPiBuZWVkcyB0byBiZSBhYmxl
IHRvIGRvIGJvdGggaW5jbHVzaXZlIGFuZCBleGNsdXNpdmUgZmlsdGVyIHJ1bGUKPiA+IGNvbmZp
Z3VyYXRpb25zLgo+ID4KPiA+IElmIGl0J3MgaW5kZWVkIHBvc3NpYmxlIHRvIGJ1aWxkIGFuIGlu
Y2x1c2l2ZSBmaWx0ZXIgcnVsZSBzZXQsIEkgaGF2ZSBhCj4gPiB3b3JrYmVuY2ggZGV2ZWxvcG1l
bnQgd2Vic2l0ZSB0aGF0IEkgY2FuIHVzZSB0byBiZSB0aGUgdGVzdCB2ZWhpY2xlLgo+IFdvdWxk
Cj4gPiBuZWVkIHRoZSBmaWx0ZXIgcnVsZXMgdG8gc3BlY2lmeSBkZW55IGV2ZXJ5dGhpbmcgYW5k
IG9uZSBmaWx0ZXIgcnVsZSBmb3IKPgo+ID4gYWNjZXB0aW5nIHRoZSBnZXQgZmlsZS5odG1sIHJl
cXVlc3QuCj4gPgo+ID4gVGhhbmtzIGZvciB5b3VyIGhlbHAKPiA+IEpvZQo+ID4KPiA+Cj4gPgo+
ID4KPiA+Cj4gPgo+ID4gSm9lCj4gPgo+ID4KPiA+Cj4gPgo+ID4KPiA+Cj4gPgo+ID4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KPiA+IEhvdyBsb3cgd2lsbCB3ZSBnbz8gQ2hlY2sg
b3V0IFlhaG9vISBNZXNzZW5nZXIncyBsb3cgUEMtdG8tUGhvbmUgY2FsbAo+IHJhdGVzLgo+ID4K
PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gPiBUYWxrIGlzIGNoZWFwLiBV
c2UgWWFob28hIE1lc3NlbmdlciB0byBtYWtlIFBDLXRvLVBob25lIGNhbGxzLiBHcmVhdAo+IHJh
dGVzCj4gPiBzdGFydGluZyBhdCAx77+9L21pbi4KPiA+Cj4gPgo+ID4KPiA+Cj4KPgo+ICAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBZYWhvbyEgTWVzc2VuZ2VyIHdpdGggVm9pY2Uu
PGh0dHA6Ly91cy5yZC55YWhvby5jb20vbWFpbF91cy90YWdsaW5lcy9wb3N0bWFuMy8qaHR0cDov
L3VzLnJkLnlhaG9vLmNvbS9ldnQ9Mzk2NjYvKmh0dHA6Ly9iZXRhLm1lc3Nlbmdlci55YWhvby5j
b20+UEMtdG8tUGhvbmUgY2FsbHMgZm9yIHJpZGljdWxvdXNseSBsb3cgcmF0ZXMuCj4KPgo=

Re: [mod-security-users] inclusive filter rule set "default deny all mode"

[joe b. <joe...@ya...>]

Thanks Ryan
   
  If I understood your references and the manual correctly then these filter rules is what I need.
   
  1 SecFilterEngine On
  2 SecChrootDir /chroot/apache
  3 SecFilterDefaultAction "deny,log,status:404"
4 SecFilterSelective Arg_pg "!^http://www.domanname.com:80/00_main_menu.htm"
5 SecFilterSelective Arg_pg "!^http://www.domanname.com:80/01_install_intro.htm"
6 SecFilterSelective Arg_pg "!^http://www.domanname.com:80/02_select_hw.htm"
7 SecFilterSelective Arg_pg "!^http://www.domanname.com:80/03_boot_1st_time.htm"
8 SecFilterSelective Arg_pg "!^http://www.domanname.com:80/04_login.php"
   
   
  What these rules are telling mod_security is 
  1 Turn on the filter engine
  2 automatically chroot apache
  3 says what action to take for all the other junk that comes into my webserver.
  4-8 rules say that if the http request is not for one of these path file names which make up my web application then its to be denied
   
   
  So as long as the remote users browser follows the natural flow of the web application it will be using the correct path file names and mod_security will allow it to execute. Everything else is denied by default and logged and the remote user gets the standard error screen that only tells him that what ever trick/attack he was trying was not successfully.
   
  Am I correct in my understanding of the above filter rules???
   
   
  
Ryan Barnett <rcb...@gm...> wrote:
    Joe,
The short answer is yes, you can create whitelist/positive (or as the term you used - inclusive ) filters with mod_security by using the inverted rulesets ( http://www.modsecurity.org/documentation/modsecurity-apache/stable/04-rules.html#N103C4).  These rules essentially mean match the regular expression that "doesn't" match this string.

For some examples, you can take a look at the free chapter from my book - Preventing Web Attacks with Apache - 
http://www.informit.com/articles/article.asp?p=442984
  
In this chapter, I give examples of how to mitigate the WASC Web Security Threat Classification with Apache (and mod_security).  Many of the examples I present use inverted mod_security filters.  Here is one example - 
 
  Apache Countermeasures for SQL Injection Attacks  SQL Injection is best solved through two practices: Input Validation and Stored Procedures with parameterized queries. Input validation is a practice that will prevent SQL Injection exploits as well as a multitude of other application attacks. This process should be followed for all applications, not just those that use SQL queries. Using stored procedures for SQL queries ensures that the user input is not executed as part of the SQL query. (Note: Make sure to use parameterized queries to ensure that the stored procedure itself is not vulnerable to SQL Injection.) The following recommendations will help prevent successful SQL Injection attacks. 
  User-Input Sanitization Checking   The best way to filter data is with a default-deny regular expression that includes only the type of data the web application expects to receive. 
  Character-Set and Length Restriction   Restrict the valid types of characters a user may submit to a web application. Using regular expressions, make the input filters as strict as possible with anchors at the beginning and end. Table 7.1 lists some example regular expressions and their meaning. 
  Table 7.1 Example Regular Expressions and Their Meaning
            Purpose of Expression
    Regular Expression
      Only allow letters with a length restriction between 1 and 10 characters.
    /^[a-zA-Z]{1,10}$/
      Allow letters and numbers with a length restriction between 1 and 10 characters.
    /^[a-zA-Z0-9]{1,10}$/
      Allow letters, numbers, and some punctuation with a length restriction between 1 and 10 characters.
    /^[a-zA-Z0-9\.@!]{1,10}$/

  
 
  The following is an example of using these regular expressions with Mod_Security to protect the ID parameter for the article.asp page from earlier:

SecFilterSelective SCRIPT_FILENAME "article.asp  " chain  SecFilterSelective ARG_ID "!^[a-zA-Z0-9\.@!]{1,10}$"
  If for some reason you cannot take that approach and must instead use a "deny-what-is-bad" method, then at minimum remove or escape single quotes ('), semicolons (;), dashes, hyphens(-), and parenthesis("()"). 
  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/8/06, joe barbish <joe...@ya...> wrote:
> 
> My Apache server came under attack starting April fools day. I first noticed
> my ipfilter inclusive firewall logging outbound packets on the the default 
> deny all rule. Checking the http-access.log I saw these requests being
> serviced by my server.
>  
> 218-166-163-180.dynamic.hinet.net - - [06/Apr/2006:10:11:25 
> -0400] "\x04\x01" 200 0 "-" "-"
> 218-166-163-180.dynamic.hinet.net - - [06/Apr/2006:10:11:45
> -0400] "\x05\x01" 200 0 "-" "-" 
> 218-166-163-180.dynamic.hinet.net - - [06/Apr/2006:10:11:45
> -0400] "CONNECT 4.79.181.15:25 HTTP/1.1" 200 7014 "-" "-" 
> 218-166-163-180.dynamic.hinet.net - - [06/Apr/2006:10:11:46
> -0400] "GET http://www.ebay.com/ HTTP/1.1" 200 7014 "-" "Mozilla/4.0 
> (compatible; MSIE 5.00; Windows 98)"
>  
> I posted a msg on the freebsd questions list and someone suggest I look at
> mod_security. At first review I was interested enough to install the freebsd 
> port of the software. As I read the manual, slowly I began to realize
> something was absent.
>  
> The mod_security home page calls mod_security a web application firewall. 
>  
> In software firewalls there are 2 different types of filter rule sets. 
>  
> The exclusive firewall and the inclusive firewall. 
>  
> An exclusive firewall allows all services through except for those matching
> a set of rules that block certain services.  
>  
> An inclusive firewall does the reverse. It only allows services matching the
> rules through and blocks everything else.  Inclusive firewalls are much,
> much safer than exclusive firewalls.
>  
> Now applying that to the mod_security filter rules I see explained in the
> manual and the examples provided at the mod_security home page it becomes
> very obvious that all the mod_security filter rules are of the exclusive 
> type. 
>  
> My web application is very vanilla. It uses hmtl and php for a counter of
> page hits. It has no upload function, but does have a download function
> launched from a link. No url's have any embedded tags. 
>  
> So I am interested in writing mod_security filter rules in reverse.
> Basically I want to say deny everything except the get requests for the
> files.htm or files.php names I see in the HTTP-access log for normal valid 
> usage of my web application. This sure would be a shorter filter include
> file than including all the includes necessary to specify all the different
> variations of attack request strings.
>   
> Is there any example of how to accomplish building a inclusive mod_security
> filter rules file.
>  
> Maybe the next question should be is this even possible?
>  
> And if not, then why not, and can it be changed to take the inclusive 
> approach as well as the current exclusive approach?
>  
> If mod_security is going to be called a web application firewall then it
> needs to be able to do both inclusive and exclusive filter rule 
> configurations.
>  
> If it's indeed possible to build an inclusive filter rule set, I have a
> workbench development website that I can use to be the test vehicle. Would
> need the filter rules to specify deny everything and one filter rule for 
> accepting the get file.html request. 
>  
> Thanks for your help
> Joe
>  
>  
>  
>  
>  
> 
> Joe
>  
>  
>  
>  
>  
> 
> 
> ________________________________
> How low will we go? Check out Yahoo! Messenger's low PC-to-Phone call rates.
> 
> ________________________________
> Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates 
> starting at 1¢/min. 
> 
> 
> 
> 


			
---------------------------------
Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates.

Re: [mod-security-users] inclusive filter rule set "default deny all mode"

[Ryan B. <rcb...@gm...>]

Joe,
The short answer is yes, you can create whitelist/positive (or as the term
you used - inclusive ) filters with mod_security by using the inverted
rulesets (
http://www.modsecurity.org/documentation/modsecurity-apache/stable/04-rules=
.html#N103C4).
 These
rules essentially mean match the regular expression that "doesn't" match
this string.

For some examples, you can take a look at the free chapter from my book -
Preventing Web Attacks with Apache -
http://www.informit.com/articles/article.asp?p=3D442984

In this chapter, I give examples of how to mitigate the WASC Web Security
Threat Classification with Apache (and mod_security).  Many of the examples
I present use inverted mod_security filters.  Here is one example -

Apache Countermeasures for SQL Injection Attacks

SQL Injection is best solved through two practices: Input Validation and
Stored Procedures with parameterized queries. Input validation is a practic=
e
that will prevent SQL Injection exploits as well as a multitude of other
application attacks. This process should be followed for all applications,
not just those that use SQL queries. Using stored procedures for SQL querie=
s
ensures that the user input is not executed as part of the SQL query. (Note=
:
Make sure to use parameterized queries to ensure that the stored procedure
itself is not vulnerable to SQL Injection.) The following recommendations
will help prevent successful SQL Injection attacks.
User-Input Sanitization Checking

The best way to filter data is with a default-deny regular expression that
includes only the type of data the web application expects to receive.
Character-Set and Length Restriction

Restrict the valid types of characters a user may submit to a web
application. Using regular expressions, make the input filters as strict as
possible with anchors at the beginning and end. Table 7.1 lists some exampl=
e
regular expressions and their meaning.

*Table 7.1 *Example Regular Expressions and Their Meaning

*Purpose of Expression*

*Regular Expression*

Only allow letters with a length restriction between 1 and 10 characters.

/^[a-zA-Z]{1,10}$/

Allow letters and numbers with a length restriction between 1 and 10
characters.

/^[a-zA-Z0-9]{1,10}$/

Allow letters, numbers, and some punctuation with a length restriction
between 1 and 10 characters.

/^[a-zA-Z0-9\.@!]{1,10}$/



The following is an example of using these regular expressions with
Mod_Security to protect the ID parameter for the article.asp page from
earlier:

SecFilterSelective SCRIPT_FILENAME "article.asp" chain
SecFilterSelective ARG_ID "!^[a-zA-Z0-9\.@!]{1,10}$"

If for some reason you cannot take that approach and must instead use a
"deny-what-is-bad" method, then at minimum remove or escape single quotes
('), semicolons (;), dashes, hyphens(-), and parenthesis("()").
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/8/06, joe barbish <joe...@ya...> wrote:
>
> My Apache server came under attack starting April fools day. I first
noticed
> my ipfilter inclusive firewall logging outbound packets on the the defaul=
t
> deny all rule. Checking the http-access.log I saw these requests being
> serviced by my server.
>
> 218-166-163-180.dynamic.hinet.net - - [06/Apr/2006:10:11:25
> -0400] "\x04\x01" 200 0 "-" "-"
> 218-166-163-180.dynamic.hinet.net - - [06/Apr/2006:10:11:45
> -0400] "\x05\x01" 200 0 "-" "-"
> 218-166-163-180.dynamic.hinet.net - - [06/Apr/2006:10:11:45
> -0400] "CONNECT 4.79.181.15:25 HTTP/1.1" 200 7014 "-" "-"
> 218-166-163-180.dynamic.hinet.net - - [06/Apr/2006:10:11:46
> -0400] "GET http://www.ebay.com/ HTTP/1.1" 200 7014 "-" "Mozilla/4.0
> (compatible; MSIE 5.00; Windows 98)"
>
> I posted a msg on the freebsd questions list and someone suggest I look a=
t
> mod_security. At first review I was interested enough to install the
freebsd
> port of the software. As I read the manual, slowly I began to realize
> something was absent.
>
> The mod_security home page calls mod_security a web application firewall.
>
> In software firewalls there are 2 different types of filter rule sets.
>
> The exclusive firewall and the inclusive firewall.
>
> An exclusive firewall allows all services through except for those
matching
> a set of rules that block certain services.
>
> An inclusive firewall does the reverse. It only allows services matching
the
> rules through and blocks everything else.  Inclusive firewalls are much,
> much safer than exclusive firewalls.
>
> Now applying that to the mod_security filter rules I see explained in the
> manual and the examples provided at the mod_security home page it becomes
> very obvious that all the mod_security filter rules are of the exclusive
> type.
>
> My web application is very vanilla. It uses hmtl and php for a counter of
> page hits. It has no upload function, but does have a download function
> launched from a link. No url's have any embedded tags.
>
> So I am interested in writing mod_security filter rules in reverse.
> Basically I want to say deny everything except the get requests for the
> files.htm or files.php names I see in the HTTP-access log for normal vali=
d
> usage of my web application. This sure would be a shorter filter include
> file than including all the includes necessary to specify all the
different
> variations of attack request strings.
>
> Is there any example of how to accomplish building a inclusive
mod_security
> filter rules file.
>
> Maybe the next question should be is this even possible?
>
> And if not, then why not, and can it be changed to take the inclusive
> approach as well as the current exclusive approach?
>
> If mod_security is going to be called a web application firewall then it
> needs to be able to do both inclusive and exclusive filter rule
> configurations.
>
> If it's indeed possible to build an inclusive filter rule set, I have a
> workbench development website that I can use to be the test vehicle. Woul=
d
> need the filter rules to specify deny everything and one filter rule for
> accepting the get file.html request.
>
> Thanks for your help
> Joe
>
>
>
>
>
>
> Joe
>
>
>
>
>
>
>
> ________________________________
> How low will we go? Check out Yahoo! Messenger's low PC-to-Phone call
rates.
>
> ________________________________
> Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rate=
s
> starting at 1=A2/min.
>
>
>
>

[mod-security-users] inclusive filter rule set "default deny all mode"

[joe b. <joe...@ya...>]

My Apache server came under attack starting April fools day. I first noticed my ipfilter inclusive firewall logging outbound packets on the the default deny all rule. Checking the http-access.log I saw these requests being serviced by my server.
   
  218-166-163-180.dynamic.hinet.net - - [06/Apr/2006:10:11:25 -0400] "\x04\x01" 200 0 "-" "-"
  218-166-163-180.dynamic.hinet.net - - [06/Apr/2006:10:11:45 -0400] "\x05\x01" 200 0 "-" "-"
  218-166-163-180.dynamic.hinet.net - - [06/Apr/2006:10:11:45 -0400] "CONNECT 4.79.181.15:25 HTTP/1.1" 200 7014 "-" "-"
  218-166-163-180.dynamic.hinet.net - - [06/Apr/2006:10:11:46 -0400] "GET http://www.ebay.com/ HTTP/1.1" 200 7014 "-" "Mozilla/4.0 (compatible; MSIE 5.00; Windows 98)"
   
  I posted a msg on the freebsd questions list and someone suggest I look at mod_security. At first review I was interested enough to install the freebsd port of the software. As I read the manual, slowly I began to realize something was absent.
   
  The mod_security home page calls mod_security a web application firewall. 
   
  In software firewalls there are 2 different types of filter rule sets.
   
  The exclusive firewall and the inclusive firewall. 
   
  An exclusive firewall allows all services through except for those matching a set of rules that block certain services.  
   
  An inclusive firewall does the reverse. It only allows services matching the rules through and blocks everything else.  Inclusive firewalls are much, much safer than exclusive firewalls.
   
  Now applying that to the mod_security filter rules I see explained in the manual and the examples provided at the mod_security home page it becomes very obvious that all the mod_security filter rules are of the exclusive type. 
   
  My web application is very vanilla. It uses hmtl and php for a counter of page hits. It has no upload function, but does have a download function launched from a link. No url's have any embedded tags.
   
  So I am interested in writing mod_security filter rules in reverse. Basically I want to say deny everything except the get requests for the files.htm or files.php names I see in the HTTP-access log for normal valid usage of my web application. This sure would be a shorter filter include file than including all the includes necessary to specify all the different variations of attack request strings.
   
  Is there any example of how to accomplish building a inclusive mod_security filter rules file.
   
  Maybe the next question should be is this even possible?
   
  And if not, then why not, and can it be changed to take the inclusive approach as well as the current exclusive approach?
   
  If mod_security is going to be called a web application firewall then it needs to be able to do both inclusive and exclusive filter rule configurations.
   
  If it's indeed possible to build an inclusive filter rule set, I have a workbench development website that I can use to be the test vehicle. Would need the filter rules to specify deny everything and one filter rule for accepting the get file.html request. 
   
  Thanks for your help
  Joe
   
   
   
   
   

		
---------------------------------
How low will we go? Check out Yahoo! Messenger’s low  PC-to-Phone call rates.
		
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.  Great rates starting at 1¢/min.