Re: [mod-security-users] mod_security enhancement idea
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
Re: [mod-security-users] mod_security enhancement idea
|
From: Terry D. <tdo...@na...> - 2006-04-11 16:46:23
|
joe barbish wrote:
> 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?
>
SecFilter "." _is_ the correct rule to block everything. However, if you this
on its own, your users may experience some (sarcasm) loss of functionality...
Let's assume that the sample rule:
SecFilterSelective REQUEST_URI "^/mls_verifyemail0.php" allow
is the only one you have other than the SecFilter "."; this will make mod_sec
block any request for anything other than that file.
Generally, if the PHP is to be any use at all, then it must take some input
from the client. You can whitelist the specifc files (REQUEST_URI)[1] and you
can whitelist the expected variables (ARGS_NAMES), but if you want to
whitelist the input (ARGS_VALUES) you have to know _every_ valid permutation
of inputs and filter them specifically.
Here, you can whitelist certain character sets which will again narrow down
the possible attack vectors, but unless you have a very simple input
pattern[2] then you're facing a huge job. Trying to tell it in such exact
terms will likely leave you with an unmanageably huge ruleset. It's like
trying to use iptables as a spam filter.
Possibly clear as mud, but that's how I understand it. I'll leave the
internals questions to the big boys and perhaps a fresh thread.
[1] Am I right in believing that REQUEST_URI is just the requested file with
POST, but includes the query string with GET requests? (I'm working from a
1.87 manual)
[2] Example simple input whitelist:
SecFilterSelective POST_PAYLOAD "!(^m=[0-9a-f]{32}$)"
The above rule will only allow one variable m and a valid md5 hash. I consider
this a fairly strong inclusive filter, but only because it's such a simple
application.
Terry.
>
>
>
> */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...
> <mailto: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
> <http://us.rd.yahoo.com/mail_us/taglines/postman5/*http://us.rd.yahoo.com/evt=39666/*http://beta.messenger.yahoo.com>
> and save big.
>
>
>
> ------------------------------------------------------------------------
> Love cheap thrills? Enjoy PC-to-Phone calls to 30+ countries
> <http://us.rd.yahoo.com/mail_us/taglines/postman9/*http://us.rd.yahoo.com/evt=39666/*http://beta.messenger.yahoo.com/>
> for just 2¢/min with Yahoo! Messenger with Voice.
|
