Re: [mod-security-users] mod_security enhancement idea
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
Re: [mod-security-users] mod_security enhancement idea
|
From: Andras G. <an...@an...> - 2006-04-10 18:12:14
|
Hi, I don't really see you point. Let's say someone runs a webserver. I don't really want, that a newbie do= it's config. Maybe the apache and mod_sec will be configured reasonably secure, but all the othe= r parts, will be like cheese. So let's suppose everything got set up correctly, then this admin= has a good knowledge about webserver security. On the other hand, the current logic behind mod_sec it's just good. You g= ot a tool which could prevent some attack patterns or full technics (checkurlencodeing, byteran= ge). You can make your rules against known software bugs and some for prevention. The URL-s are = so hectic, that you can easily kill all you customers sites with a single bad rule. Some months a= go I tried to introduce a rule, which filters out "../" like strings from GET and POST. Within the = hour, one customer called me, that "something wierd" happens. It turned out, that he extensively us= ed "../" in hidden form elements, on his site. I couldn't beleive, that a so dumb and insecure so= lution could take shape in ones mind. So this was only one story, but users has a big surprise for a= lmost every month. :) So my point is, that on a paid hosting server (or any webserver with many= pages) the admin just can't setup all these restrictions, so the exclusive way is just good. Yo= u shouldn't compare the TCP/IP layer 2-3 filtering, which is highly predictable (say so you don't= want anything from a /24 network, or you just allow traffic to a single port from a /24 network). I hope I didn't misunderstand your point. Regards, Andras joe barbish wrote: > mod_security enhancement idea > =20 > =20 > In software packet firewalls there are 2 different types of filter ru= le sets. > =20 > The exclusive firewall and the inclusive firewall. This is well docum= ented in the FreeBSD manual firewall section. > =20 > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls.= html > =20 > An exclusive firewall allows all packets through except for those mat= ching a set of rules that block certain packets, (IE, default pass all). = =20 > =20 > An inclusive firewall does the reverse. It only allows packets matchi= ng the rules through and blocks everything else, (IE, default deny all). = Inclusive firewalls are much, much securer than exclusive firewalls and s= impler to code. > =20 > Applying that concept to the mod_security filter rules I see explaine= d in the manual and the examples provided at the mod_security home page i= t became very obvious that mod_security defaults to an exclusive type of= firewall. Rules are used to code the particular signatures of malice att= empts to circumvent the normal standard http processes of a web server.=20 > =20 > This is fine if you are an internet security expert and want to analy= ze and capture the different methods used by attackers of web application= . Mod_security is the perfectly designed tool for this task.=20 > =20 > But for the user who is looking for a simple user friendly web server= firewall to block all the currently know & future malice attack methods = while allowing his web application to pass unmolested does not readily fi= nd this available in mod_security.=20 > =20 > Now don=E2=80=99t take me wrong, it is possible to configure an mod_s= ecurity rule set that address the technical part of the stated goal, but = the simple & user friendly part is by no means met as shown in the follow= ing example. All the scripts used in the web application are coded by ind= ividual rules. > =20 > =20 > secfilterengine on > secfiltercheckurlencoding on > secfiltercheckunicodeencoding off > secfilterforcebyterange 0 255 > secfilterscanpost on > SecFilterDefaultAction deny,log,status:404 > =20 > SecFilterSelective REQUEST_URI "!^/00.00_Header.htm" = chain > SecFilterSelective REQUEST_URI "!^/00.00_Header.php" = chain > SecFilterSelective REQUEST_URI "!^/00.00-web_style_sheet.css" = chain > SecFilterSelective REQUEST_URI "!^/button.php" = chain=20 > SecFilterSelective REQUEST_URI "!^/index.htm" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_auction_bidding_info.htm" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_breakin_attempt.php" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_contact_sales_dept.htm" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_fsbo_forgot_logon.php" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_fsbo_listing_info.htm" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_fsbo_logon.php" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_fsbo_member_update.php" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_fsbo_menu.php" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_fsbo_signup.php" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_fsbo_terminate_member1.php" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_fsbo_terminate_member2.php" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_home_page.php" = chain > SecFilterSelective REQUEST_URI "!^/mls_std_exit.php" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_verifyemail.php" = chain=20 > SecFilterSelective REQUEST_URI "!^/mls_verifyemail0.php" =20 > =20 > =20 > In some programming circles this would be called a reverse polish cod= ing technique. > =20 > This is not simple coding logic and this technique is not documented = or even hinted at in the manual. But it does fulfill the stated technical= goal requirement of blocking all currently know and unknown malice attac= k methods while allowing the web application to pass unmolested. As a sid= e benefit not only does the above example pass the users normal web traff= ic but it also allows search engine robot traffic to pass as they invento= ry the website for indexing. > =20 > Security can be tightened further by coding all the script names usin= g this rule format > =20 > SecFilterSelective SCRIPT_FILENAME "!^/usr/local/www/data/mls_Read_fo= rgot_logon_email.php" chain=20 > =20 > This would stop all search engine traffic because they do not include= the path in their requests. > =20 > =20 > =20 > The usefulness of mod_security can be increased while becoming more u= ser friendly by making few tweaks to mod_security=E2=80=99s source code. > =20 > =20 > What I purpose is this, > =20 > Change secfilterengine on|off to > =20 > =20 > secfilterengine on_exclusive | on_inclusive | off > =20 > =20 > on_exclusive =3D (defaults to allow all) which is how mod_security c= urrently functions > =20 > on_inclusive =3D (defaults to block all)=20 > =20 > This would then allow the above example rules to be re-coded like thi= s: > =20 > SecFilterSelective REQUEST_URI "^/00.00_Header.htm" S= ecFilterSelective REQUEST_URI "^/00.00_Header.php" SecFil= terSelective REQUEST_URI "^/00.00-web_style_sheet.css" =20 > SecFilterSelective REQUEST_URI "^/button.php" =20 > SecFilterSelective REQUEST_URI "^/class.phpmailer.php" =20 > SecFilterSelective REQUEST_URI "^/index.htm" > =20 > Where a match means pass the packet to the web server and any non-mat= ches get passed to what ever SecFilterDefaultAction deny,log,status:404 = says to do. > =20 > To an non-technical user this is straight forward and makes logical s= enses when read. > The concept of only having to add a rule for each script that makes u= p the web application requires no technical comprehension of how an web s= erver processes requests and is really on target for the general home hob= byist level of understanding and needs. And of course the mod_security ma= nual would need a major rewrite to include this new function. > =20 > =20 > I post this for discussion by members of this list who have more know= ledge of mod_security internals and usage background in hopes of achievin= g agreement on making this an official enhancement request. > =20 > =20 >=20 > =09 > --------------------------------- > New Yahoo! Messenger with Voice. Call regular phones from your PC and s= ave big. |
