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 19:12:31
|
I knew that you'd extend, but I can't see the point in an extension like = this. The more you extend,=20 the more it get's complicated and raise the possible number of secholes. joe barbish wrote: > Yep Andras you misunderstand the point completely. The purposed change = does not terminate how the existing software works. The current functions= will remain as is. The change just extended the flexibility of the softw= are. =20 >=20 > Andras Got <an...@an...> wrote: Hi, >=20 > I don't really see you point. >=20 > Let's say someone runs a webserver. I don't really want, that a newbie = do it's config. Maybe the > apache and mod_sec will be configured reasonably secure, but all the ot= her parts, will be like > cheese. So let's suppose everything got set up correctly, then this adm= in has a good knowledge about > webserver security. >=20 > On the other hand, the current logic behind mod_sec it's just good. You= got a tool which could > prevent some attack patterns or full technics (checkurlencodeing, byter= ange). You can make your > rules against known software bugs and some for prevention. The URL-s ar= e so hectic, that you can > easily kill all you customers sites with a single bad rule. Some months= ago I tried to introduce a > rule, which filters out "../" like strings from GET and POST. Within th= e hour, one customer called > me, that "something wierd" happens. It turned out, that he extensively = used "../" in hidden form > elements, on his site. I couldn't beleive, that a so dumb and insecure = solution could take shape in > ones mind. So this was only one story, but users has a big surprise for= almost every month. :) >=20 > So my point is, that on a paid hosting server (or any webserver with ma= ny pages) the admin just > can't setup all these restrictions, so the exclusive way is just good. = You shouldn't compare the > TCP/IP layer 2-3 filtering, which is highly predictable (say so you don= 't want anything from a /24 > network, or you just allow traffic to a single port from a /24 network)= . >=20 > I hope I didn't misunderstand your point. >=20 > Regards, > Andras >=20 >=20 >=20 > joe barbish wrote: >> mod_security enhancement idea >> >> >> In software packet firewalls there are 2 different types of filter rul= e sets. >> >> The exclusive firewall and the inclusive firewall. This is well docume= nted in the FreeBSD manual firewall section. >> >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls.ht= ml >> >> An exclusive firewall allows all packets through except for those matc= hing a set of rules that block certain packets, (IE, default pass all).=20 >> >> An inclusive firewall does the reverse. It only allows packets matchin= g the rules through and blocks everything else, (IE, default deny all). I= nclusive firewalls are much, much securer than exclusive firewalls and si= mpler to code. >> >> Applying that concept to the mod_security filter rules I see explained= in the manual and the examples provided at the mod_security home page it= became very obvious that mod_security defaults to an exclusive type of f= irewall. Rules are used to code the particular signatures of malice attem= pts to circumvent the normal standard http processes of a web server.=20 >> >> This is fine if you are an internet security expert and want to analyz= e and capture the different methods used by attackers of web application.= Mod_security is the perfectly designed tool for this task.=20 >> >> But for the user who is looking for a simple user friendly web server = firewall to block all the currently know & future malice attack methods w= hile allowing his web application to pass unmolested does not readily fin= d this available in mod_security.=20 >> >> Now don=C3=A2=E2=82=AC=E2=84=A2t take me wrong, it is possible to conf= igure an mod_security rule set that address the technical part of the sta= ted goal, but the simple & user friendly part is by no means met as shown= in the following example. All the scripts used in the web application ar= e coded by individual rules. >> >> >> secfilterengine on >> secfiltercheckurlencoding on >> secfiltercheckunicodeencoding off >> secfilterforcebyterange 0 255 >> secfilterscanpost on >> SecFilterDefaultAction deny,log,status:404 >> >> SecFilterSelective REQUEST_URI "!^/00.00_Header.htm" chain >> SecFilterSelective REQUEST_URI "!^/00.00_Header.php" chain >> SecFilterSelective REQUEST_URI "!^/00.00-web_style_sheet.css" chain >> SecFilterSelective REQUEST_URI "!^/button.php" chain=20 >> SecFilterSelective REQUEST_URI "!^/index.htm" chain=20 >> SecFilterSelective REQUEST_URI "!^/mls_auction_bidding_info.htm" chain= =20 >> SecFilterSelective REQUEST_URI "!^/mls_breakin_attempt.php" chain=20 >> SecFilterSelective REQUEST_URI "!^/mls_contact_sales_dept.htm" chain=20 >> SecFilterSelective REQUEST_URI "!^/mls_fsbo_forgot_logon.php" chain=20 >> SecFilterSelective REQUEST_URI "!^/mls_fsbo_listing_info.htm" chain=20 >> SecFilterSelective REQUEST_URI "!^/mls_fsbo_logon.php" chain=20 >> SecFilterSelective REQUEST_URI "!^/mls_fsbo_member_update.php" chain=20 >> SecFilterSelective REQUEST_URI "!^/mls_fsbo_menu.php" chain=20 >> SecFilterSelective REQUEST_URI "!^/mls_fsbo_signup.php" chain=20 >> SecFilterSelective REQUEST_URI "!^/mls_fsbo_terminate_member1.php" cha= in=20 >> SecFilterSelective REQUEST_URI "!^/mls_fsbo_terminate_member2.php" cha= in=20 >> SecFilterSelective REQUEST_URI "!^/mls_home_page.php" chain >> SecFilterSelective REQUEST_URI "!^/mls_std_exit.php" chain=20 >> SecFilterSelective REQUEST_URI "!^/mls_verifyemail.php" chain=20 >> SecFilterSelective REQUEST_URI "!^/mls_verifyemail0.php"=20 >> >> >> In some programming circles this would be called a reverse polish codi= ng technique. >> >> This is not simple coding logic and this technique is not documented o= r even hinted at in the manual. But it does fulfill the stated technical = goal requirement of blocking all currently know and unknown malice attack= methods while allowing the web application to pass unmolested. As a side= benefit not only does the above example pass the users normal web traffi= c but it also allows search engine robot traffic to pass as they inventor= y the website for indexing. >> >> Security can be tightened further by coding all the script names using= this rule format >> >> SecFilterSelective SCRIPT_FILENAME "!^/usr/local/www/data/mls_Read_for= got_logon_email.php" chain=20 >> >> This would stop all search engine traffic because they do not include = the path in their requests. >> >> >> >> The usefulness of mod_security can be increased while becoming more us= er friendly by making few tweaks to mod_security=C3=A2=E2=82=AC=E2=84=A2s= source code. >> >> >> What I purpose is this, >> >> Change secfilterengine on|off to >> >> >> secfilterengine on_exclusive | on_inclusive | off >> >> >> on_exclusive =3D (defaults to allow all) which is how mod_security cur= rently functions >> >> on_inclusive =3D (defaults to block all)=20 >> >> This would then allow the above example rules to be re-coded like this= : >> >> SecFilterSelective REQUEST_URI "^/00.00_Header.htm" SecFilterSelective= REQUEST_URI "^/00.00_Header.php" SecFilterSelective REQUEST_URI "^/00.00= -web_style_sheet.css"=20 >> SecFilterSelective REQUEST_URI "^/button.php"=20 >> SecFilterSelective REQUEST_URI "^/class.phpmailer.php"=20 >> SecFilterSelective REQUEST_URI "^/index.htm" >> >> Where a match means pass the packet to the web server and any non-matc= hes get passed to what ever SecFilterDefaultAction deny,log,status:404 sa= ys to do. >> >> To an non-technical user this is straight forward and makes logical se= nses when read. >> The concept of only having to add a rule for each script that makes up= the web application requires no technical comprehension of how an web se= rver processes requests and is really on target for the general home hobb= yist level of understanding and needs. And of course the mod_security man= ual would need a major rewrite to include this new function. >> >> >> I post this for discussion by members of this list who have more knowl= edge of mod_security internals and usage background in hopes of achieving= agreement on making this an official enhancement request. >> >> >> >> >> --------------------------------- >> New Yahoo! Messenger with Voice. Call regular phones from your PC and = save big. >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting lang= uage > that extends applications into web and mobile media. Attend the live we= bcast > and join the prime developer group breaking into this new coding territ= ory! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=12164= 2 > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users >=20 >=20 > =09 > --------------------------------- > How low will we go? Check out Yahoo! Messenger=E2=80=99s low PC-to-Pho= ne call rates. |
