Re: [mod-security-users] mod_security enhancement idea
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
Re: [mod-security-users] mod_security enhancement idea
|
From: joe b. <joe...@ya...> - 2006-04-10 19:02:23
|
Yep Andras you misunderstand the point completely. The purposed change does not terminate how the existing software works. The current functions will remain as is. The change just extended the flexibility of the software. Andras Got <an...@an...> wrote: Hi, I don't really see you point. Let's say someone runs a webserver. I don't really want, that a newbie do it's config. Maybe the apache and mod_sec will be configured reasonably secure, but all the other parts, will be like cheese. So let's suppose everything got set up correctly, then this admin has a good knowledge about webserver security. On the other hand, the current logic behind mod_sec it's just good. You got a tool which could prevent some attack patterns or full technics (checkurlencodeing, byterange). You can make your rules against known software bugs and some for prevention. The URL-s are so hectic, that you can easily kill all you customers sites with a single bad rule. Some months ago I tried to introduce a rule, which filters out "../" like strings from GET and POST. Within the hour, one customer called me, that "something wierd" happens. It turned out, that he extensively used "../" in hidden form elements, on his site. I couldn't beleive, that a so dumb and insecure solution could take shape in ones mind. So this was only one story, but users has a big surprise for almost every month. :) So my point is, that on a paid hosting server (or any webserver with many pages) the admin just can't setup all these restrictions, so the exclusive way is just good. You shouldn't compare the TCP/IP layer 2-3 filtering, which is highly predictable (say so you don't want anything from a /24 network, or you just allow traffic to a single port from a /24 network). I hope I didn't misunderstand your point. Regards, Andras joe barbish wrote: > mod_security enhancement idea > > > In software packet firewalls there are 2 different types of filter rule sets. > > The exclusive firewall and the inclusive firewall. This is well documented in the FreeBSD manual firewall section. > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls.html > > An exclusive firewall allows all packets through except for those matching a set of rules that block certain packets, (IE, default pass all). > > An inclusive firewall does the reverse. It only allows packets matching the rules through and blocks everything else, (IE, default deny all). Inclusive firewalls are much, much securer than exclusive firewalls and simpler to code. > > Applying that concept to the mod_security filter rules I see explained in the manual and the examples provided at the mod_security home page it became very obvious that mod_security defaults to an exclusive type of firewall. Rules are used to code the particular signatures of malice attempts to circumvent the normal standard http processes of a web server. > > This is fine if you are an internet security expert and want to analyze and capture the different methods used by attackers of web application. Mod_security is the perfectly designed tool for this task. > > But for the user who is looking for a simple user friendly web server firewall to block all the currently know & future malice attack methods while allowing his web application to pass unmolested does not readily find this available in mod_security. > > Now donât take me wrong, it is possible to configure an mod_security rule set that address the technical part of the stated goal, but the simple & user friendly part is by no means met as shown in the following example. All the scripts used in the web application are coded by individual rules. > > > secfilterengine on > secfiltercheckurlencoding on > secfiltercheckunicodeencoding off > secfilterforcebyterange 0 255 > secfilterscanpost on > SecFilterDefaultAction deny,log,status:404 > > SecFilterSelective REQUEST_URI "!^/00.00_Header.htm" chain > SecFilterSelective REQUEST_URI "!^/00.00_Header.php" chain > SecFilterSelective REQUEST_URI "!^/00.00-web_style_sheet.css" chain > SecFilterSelective REQUEST_URI "!^/button.php" chain > SecFilterSelective REQUEST_URI "!^/index.htm" chain > SecFilterSelective REQUEST_URI "!^/mls_auction_bidding_info.htm" chain > SecFilterSelective REQUEST_URI "!^/mls_breakin_attempt.php" chain > SecFilterSelective REQUEST_URI "!^/mls_contact_sales_dept.htm" chain > SecFilterSelective REQUEST_URI "!^/mls_fsbo_forgot_logon.php" chain > SecFilterSelective REQUEST_URI "!^/mls_fsbo_listing_info.htm" chain > SecFilterSelective REQUEST_URI "!^/mls_fsbo_logon.php" chain > SecFilterSelective REQUEST_URI "!^/mls_fsbo_member_update.php" chain > SecFilterSelective REQUEST_URI "!^/mls_fsbo_menu.php" chain > SecFilterSelective REQUEST_URI "!^/mls_fsbo_signup.php" chain > SecFilterSelective REQUEST_URI "!^/mls_fsbo_terminate_member1.php" chain > SecFilterSelective REQUEST_URI "!^/mls_fsbo_terminate_member2.php" chain > SecFilterSelective REQUEST_URI "!^/mls_home_page.php" chain > SecFilterSelective REQUEST_URI "!^/mls_std_exit.php" chain > SecFilterSelective REQUEST_URI "!^/mls_verifyemail.php" chain > SecFilterSelective REQUEST_URI "!^/mls_verifyemail0.php" > > > In some programming circles this would be called a reverse polish coding technique. > > This is not simple coding logic and this technique is not documented or even hinted at in the manual. But it does fulfill the stated technical goal requirement of blocking all currently know and unknown malice attack methods while allowing the web application to pass unmolested. As a side benefit not only does the above example pass the users normal web traffic but it also allows search engine robot traffic to pass as they inventory the website for indexing. > > Security can be tightened further by coding all the script names using this rule format > > SecFilterSelective SCRIPT_FILENAME "!^/usr/local/www/data/mls_Read_forgot_logon_email.php" chain > > This would stop all search engine traffic because they do not include the path in their requests. > > > > The usefulness of mod_security can be increased while becoming more user friendly by making few tweaks to mod_securityâs source code. > > > What I purpose is this, > > Change secfilterengine on|off to > > > secfilterengine on_exclusive | on_inclusive | off > > > on_exclusive = (defaults to allow all) which is how mod_security currently functions > > on_inclusive = (defaults to block all) > > This would then allow the above example rules to be re-coded like this: > > SecFilterSelective REQUEST_URI "^/00.00_Header.htm" SecFilterSelective REQUEST_URI "^/00.00_Header.php" SecFilterSelective REQUEST_URI "^/00.00-web_style_sheet.css" > SecFilterSelective REQUEST_URI "^/button.php" > SecFilterSelective REQUEST_URI "^/class.phpmailer.php" > SecFilterSelective REQUEST_URI "^/index.htm" > > Where a match means pass the packet to the web server and any non-matches get passed to what ever SecFilterDefaultAction deny,log,status:404 says to do. > > To an non-technical user this is straight forward and makes logical senses when read. > The concept of only having to add a rule for each script that makes up the web application requires no technical comprehension of how an web server processes requests and is really on target for the general home hobbyist level of understanding and needs. And of course the mod_security manual would need a major rewrite to include this new function. > > > I post this for discussion by members of this list who have more knowledge of mod_security internals and usage background in hopes of achieving agreement on making this an official enhancement request. > > > > > --------------------------------- > New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ mod-security-users mailing list mod...@li... https://lists.sourceforge.net/lists/listinfo/mod-security-users --------------------------------- How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates. |
