Re: [mod-security-users] mod_security enhancement idea
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
Re: [mod-security-users] mod_security enhancement idea
|
From: Ryan B. <rcb...@gm...> - 2006-04-10 19:33:19
|
Joe, A few quick comments - 1) You really don't need a new directive/option to get what you are looking for. Keeping with your firewall concept, in order to get an inclusive ruleset, you first need to implement a catch-all deny rule that would block all requests. In mod_security it would be this - SecFilter ".". This woul= d match any request and then take the action that you specified in the SecFilterDefaultAction rule. The next step is to create a whitelist of filters that will match allowed, acceptable requests. This is what you are attempting to do in your post with the mod_security inverted filters. 2) Your examples of inverted filters will not work correctly with the chain action. The chain feature will create a larger, complex check on the request. In your examples, you tried to chain all of the acceptable URLs together. The problem is that all of those files will never be requested within one sigle request packet. The mod_security action that you should use is "allow" to tell mod_security to allow the request through and the final filter is the catch-all deny. Here is an updated ruleset for you - SecFilterSelective REQUEST_URI "^/00.00_Header.htm" allow SecFilterSelective REQUEST_URI "^/00.00_Header.php" allow SecFilterSelective REQUEST_URI "^/00.00-web_style_sheet.css" allow SecFilterSelective REQUEST_URI "^/button.php" allow SecFilterSelective REQUEST_URI "^/index.htm" allow SecFilterSelective REQUEST_URI "^/mls_auction_bidding_info.htm" allow SecFilterSelective REQUEST_URI "^/mls_breakin_attempt.php" allow SecFilterSelective REQUEST_URI "^/mls_contact_sales_dept.htm" allow SecFilterSelective REQUEST_URI "^/mls_fsbo_forgot_logon.php" allow SecFilterSelective REQUEST_URI "^/mls_fsbo_listing_info.htm" allow SecFilterSelective REQUEST_URI "^/mls_fsbo_logon.php" allow SecFilterSelective REQUEST_URI "^/mls_fsbo_member_update.php" allow SecFilterSelective REQUEST_URI "^/mls_fsbo_menu.php" allow SecFilterSelective REQUEST_URI "^/mls_fsbo_signup.php" allow SecFilterSelective REQUEST_URI "^/mls_fsbo_terminate_member1.php" allow SecFilterSelective REQUEST_URI "^/mls_fsbo_terminate_member2.php" allow SecFilterSelective REQUEST_URI "^/mls_home_page.php" allow SecFilterSelective REQUEST_URI "^/mls_std_exit.php" allow SecFilterSelective REQUEST_URI "^/mls_verifyemail.php" allow SecFilterSelective REQUEST_URI "^/mls_verifyemail0.php" allow SecFilter "." 3) Even with these rules, this will not provide total protection. What happens if there is a new PHP exploit for your mls_verifyemail0.php script? The rules above will not protect against this. It is for this reason that the "exclusive", blacklist rules should be listed BEFORE these whitelist rules. These attacks signatures will be processed prior to these rules and check for common exploit issues (meta-characthers, directory traversal, command execution, etc...). If these rules are specified AFTER the rules above, they will be skipped with the "allow" directive. Hope this helps. -- Ryan C. Barnett Web Application Security Consortium (WASC) Member CIS Apache Benchmark Project Lead SANS Instructor: Securing Apache GCIA, GCFA, GCIH, GSNA, GCUX, GSEC Author: Preventing Web Attacks with Apache On 4/10/06, joe barbish <joe...@ya...> wrote: > > mod_security enhancement idea > > > In software packet firewalls there are 2 different types of filter rule > sets. > > The exclusive firewall and the inclusive firewall. This is well documente= d > in the FreeBSD manual firewall section. > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls.html > > An exclusive firewall allows all packets through except for those matchin= g > a set of rules that block certain packets, (IE, default pass all). > > An inclusive firewall does the reverse. It only allows packets matching > the rules through and blocks everything else, (IE, default deny all). > Inclusive firewalls are much, much securer than exclusive firewalls and > simpler to code. > > Applying that concept to the mod_security filter rules I see explained in > the manual and the examples provided at the mod_security home page it bec= ame > very obvious that mod_security defaults to an exclusive type of firewall= . > Rules are used to code the particular signatures of malice attempts to > circumvent the normal standard http processes of a web server. > > This is fine if you are an internet security expert and want to analyze > and capture the different methods used by attackers of web application. > Mod_security is the perfectly designed tool for this task. > > But for the user who is looking for a simple user friendly web server > firewall to block all the currently know & future malice attack methods > while allowing his web application to pass unmolested does not readily fi= nd > this available in mod_security. > > Now don't take me wrong, it is possible to configure an mod_security rule > set that address the technical part of the stated goal, but the simple & > user friendly part is by no means met as shown in the following example. = All > the scripts used in the web application are coded by individual rules. > > > secfilterengine on > secfiltercheckurlencoding on > secfiltercheckunicodeencoding off > secfilterforcebyterange 0 255 > secfilterscanpost on > SecFilterDefaultAction deny,log,status:404 > > SecFilterSelective REQUEST_URI "!^/00.00_Header.htm" chai= n > SecFilterSelective REQUEST_URI "!^/00.00_Header.php" chai= n > SecFilterSelective REQUEST_URI "!^/00.00-web_style_sheet.css" chai= n > SecFilterSelective REQUEST_URI "!^/button.php" chai= n > > SecFilterSelective REQUEST_URI "!^/index.htm" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_auction_bidding_info.htm" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_breakin_attempt.php" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_contact_sales_dept.htm" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_fsbo_forgot_logon.php" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_fsbo_listing_info.htm" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_fsbo_logon.php" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_fsbo_member_update.php" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_fsbo_menu.php" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_fsbo_signup.php" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_fsbo_terminate_member1.php" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_fsbo_terminate_member2.php" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_home_page.php" chai= n > SecFilterSelective REQUEST_URI "!^/mls_std_exit.php" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_verifyemail.php" chai= n > > SecFilterSelective REQUEST_URI "!^/mls_verifyemail0.php" > > > In some programming circles this would be called a reverse polish coding > technique. > > This is not simple coding logic and this technique is not documented or > even hinted at in the manual. But it does fulfill the stated technical go= al > requirement of blocking all currently know and unknown malice attack meth= ods > while allowing the web application to pass unmolested. As a side benefit = not > only does the above example pass the users normal web traffic but it also > allows search engine robot traffic to pass as they inventory the website = for > indexing. > > Security can be tightened further by coding all the script names using > this rule format > > SecFilterSelective SCRIPT_FILENAME > "!^/usr/local/www/data/mls_Read_forgot_logon_email.php" chain > > This would stop all search engine traffic because they do not include the > path in their requests. > > > > The usefulness of mod_security can be increased while becoming more user > friendly by making few tweaks to mod_security's source code. > > > What I purpose is this, > > Change secfilterengine on|off to > > > secfilterengine on_exclusive | on_inclusive | off > > > on_exclusive =3D (defaults to allow all) which is how mod_security > currently functions > > on_inclusive =3D (defaults to block all) > > This would then allow the above example rules to be re-coded like this: > > SecFilterSelective REQUEST_URI "^/00.00_Header.htm" SecFi= lterSelective > REQUEST_URI "^/00.00_Header.php" SecFilterSelective > REQUEST_URI "^/00.00-web_style_sheet.css" > SecFilterSelective REQUEST_URI "^/button.php" > SecFilterSelective REQUEST_URI "^/class.phpmailer.php" > SecFilterSelective REQUEST_URI "^/index.htm" > > Where a match means pass the packet to the web server and any non-matches > get passed to what ever SecFilterDefaultAction deny,log,status:404 says > to do. > > To an non-technical user this is straight forward and makes logical sense= s > when read. > The concept of only having to add a rule for each script that makes up th= e > web application requires no technical comprehension of how an web server > processes requests and is really on target for the general home hobbyist > level of understanding and needs. And of course the mod_security manual > would need a major rewrite to include this new function. > > > I post this for discussion by members of this list who have more knowledg= e > of mod_security internals and usage background in hopes of achieving > agreement on making this an official enhancement request. > > > > ------------------------------ > New Yahoo! Messenger with Voice. Call regular phones from your PC<http://= us.rd.yahoo.com/mail_us/taglines/postman5/*http://us.rd.yahoo.com/evt=3D396= 66/*http://beta.messenger.yahoo.com>and save big. > > |
