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-11 15:53:41
|
Ryan
Thanks for the help.
But I don't understand some thing you said.
You said that SecFilter "." will deny everything then you say "What happens if there is a new PHP exploit for your mls_verifyemail0.php script? The rules above will not protect against this."
The whole idea of the rules is to control what is allowed to pass.
The SecFilter "." is suppose to deny everything. Everything means anything which is not one of the coded 'accept' rules, including all known and un-known exploits.
If SecFilter "." is not the correct rule to deny everything then what rule will?
Ryan Barnett <rcb...@gm...> wrote:
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 would 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 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.
---------------------------------
Love cheap thrills? Enjoy PC-to-Phone calls to 30+ countries for just 2¢/min with Yahoo! Messenger with Voice. |
