[mod-security-users] mod_security enhancement idea
Brought to you by:
victorhora,
zimmerletw
|
From: joe b. <joe...@ya...> - 2006-04-10 17:30:16
|
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 dont 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_securitys 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. |