Re: [mod-security-users] inclusive filter rule set "default deny all mode"
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
Re: [mod-security-users] inclusive filter rule set "default deny all mode"
|
From: joe b. <joe...@ya...> - 2006-04-09 16:59:28
|
Thanks Ryan Can I have a sample rule for doing this? "For large sites, I use the same concept except with directories instead of files. I list out all of the directory names in the DocumentRoot and make an inverted mod_security filter to deny connections for requests that don't list these." In the http-access-log I see that the search engines requesting just the file.html with out the complete http path. I do not want to deny the search engines so what ever rule format used must allow both search engines and normal website users and stop everything else. I checked my Apache httpd.conf file. The freebsd port of the Apache13 activates a lot of standard dso modules and one of then is the proxy module. I had thought those dso modules had to have a directive coded for it before it became active. I see now that is not true. My website has been on the public internet for 5 years and this is the first I have been hit with an attack. I commented out the load for the proxy module in my httpd.conf file. Thanks for catching that. I have tried to active SecChrootDir /chroot/apache and received an syntax error. Read the modsecurity manual and the details of how to use it as very vague. My Apache server contains all the application files in /usr/local/www/data is that the path I should use in the SecChrootDir command? Ryan Barnett <rcb...@gm...> wrote: Close. The concept is sound, except that you need to use a different mod_security location specifier rather than Arg_pg. The "ARG_XXX" locations are variable arguments to applications (which is the data passed to interactive/dynamic pages after the "?" characters - such as /directory1/file2.php?login=XXX). From looking at your URLs below, it only looks like you would have one web page that might accept data (the login.php page). In order to set a mod_security filter location for these files, you should use of of the following directives - - SCRIPT_FILENAME - REQUEST_URI - REQUEST_FILENAME - THE_REQUEST So, for your examples, you could use the following to combine all 5 of those to a one line filter - SecFilterSelective SCRIPT_FILENAME "!^(00_main_menu.htm|01_install_intro.htm|02_select_hw.htm|03_boot_1st_time.htm|04_login.php)$" Two other things to think about - 1) For large sites, I use the same concept except with directories instead of files. I list out all of the directory names in the DocumentRoot and make an inverted mod_security filter to deny connections for requests that don't list these. 2) Going back to the very beginning of your first post - those web requests you listed as seeing are a bit troublesome. They all seem to be probes against your web server to verify if you can be used as an open proxy server. The first two requests are from SOCKS proxy checkers, the 3rd is an HTTP CONNECT check to see if your server will connect to an SMTP host (for use by SPAMMERS) and the last is a request to a normal website. The probes themselves are not what worries me, as these happen all the time. What worrries me are the status codes returned by your web server - 200 OK. This normally means that your server processed these requests successfully. Are you using mod_security to return bogus HTTP Response Codes??? I sure hope so, otherwise you need to disable the mod_proxy module ASAP. -- 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/8/06, joe barbish <joe...@ya...> wrote: Thanks Ryan If I understood your references and the manual correctly then these filter rules is what I need. 1 SecFilterEngine On 2 SecChrootDir /chroot/apache 3 SecFilterDefaultAction "deny,log,status:404" 4 SecFilterSelective Arg_pg "!^http://www.domanname.com:80/00_main_menu.htm" 5 SecFilterSelective Arg_pg "!^http://www.domanname.com:80/01_install_intro.htm" 6 SecFilterSelective Arg_pg "!^http://www.domanname.com:80/02_select_hw.htm" 7 SecFilterSelective Arg_pg "!^http://www.domanname.com:80/03_boot_1st_time.htm" 8 SecFilterSelective Arg_pg "!^http://www.domanname.com:80/04_login.php" What these rules are telling mod_security is 1 Turn on the filter engine 2 automatically chroot apache 3 says what action to take for all the other junk that comes into my webserver. 4-8 rules say that if the http request is not for one of these path file names which make up my web application then its to be denied So as long as the remote users browser follows the natural flow of the web application it will be using the correct path file names and mod_security will allow it to execute. Everything else is denied by default and logged and the remote user gets the standard error screen that only tells him that what ever trick/attack he was trying was not successfully. Am I correct in my understanding of the above filter rules??? Ryan Barnett <rcb...@gm...> wrote: Joe, The short answer is yes, you can create whitelist/positive (or as the term you used - inclusive ) filters with mod_security by using the inverted rulesets ( http://www.modsecurity.org/documentation/modsecurity-apache/stable/04-rules.html#N103C4). These rules essentially mean match the regular expression that "doesn't" match this string. For some examples, you can take a look at the free chapter from my book - Preventing Web Attacks with Apache - http://www.informit.com/articles/article.asp?p=442984 In this chapter, I give examples of how to mitigate the WASC Web Security Threat Classification with Apache (and mod_security). Many of the examples I present use inverted mod_security filters. Here is one example - Apache Countermeasures for SQL Injection Attacks SQL Injection is best solved through two practices: Input Validation and Stored Procedures with parameterized queries. Input validation is a practice that will prevent SQL Injection exploits as well as a multitude of other application attacks. This process should be followed for all applications, not just those that use SQL queries. Using stored procedures for SQL queries ensures that the user input is not executed as part of the SQL query. (Note: Make sure to use parameterized queries to ensure that the stored procedure itself is not vulnerable to SQL Injection.) The following recommendations will help prevent successful SQL Injection attacks. User-Input Sanitization Checking The best way to filter data is with a default-deny regular expression that includes only the type of data the web application expects to receive. Character-Set and Length Restriction Restrict the valid types of characters a user may submit to a web application. Using regular expressions, make the input filters as strict as possible with anchors at the beginning and end. Table 7.1 lists some example regular expressions and their meaning. Table 7.1 Example Regular Expressions and Their Meaning Purpose of Expression Regular Expression Only allow letters with a length restriction between 1 and 10 characters. /^[a-zA-Z]{1,10}$/ Allow letters and numbers with a length restriction between 1 and 10 characters. /^[a-zA-Z0-9]{1,10}$/ Allow letters, numbers, and some punctuation with a length restriction between 1 and 10 characters. /^[a-zA-Z0-9\.@!]{1,10}$/ The following is an example of using these regular expressions with Mod_Security to protect the ID parameter for the article.asp page from earlier: SecFilterSelective SCRIPT_FILENAME "article.asp " chain SecFilterSelective ARG_ID "!^[a-zA-Z0-9\.@!]{1,10}$" If for some reason you cannot take that approach and must instead use a "deny-what-is-bad" method, then at minimum remove or escape single quotes ('), semicolons (;), dashes, hyphens(-), and parenthesis("()"). 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/8/06, joe barbish <joe...@ya...> wrote: > > My Apache server came under attack starting April fools day. I first noticed > my ipfilter inclusive firewall logging outbound packets on the the default > deny all rule. Checking the http-access.log I saw these requests being > serviced by my server. > > 218-166-163-180.dynamic.hinet.net - - [06/Apr/2006:10:11:25 > -0400] "\x04\x01" 200 0 "-" "-" > 218-166-163-180.dynamic.hinet.net - - [06/Apr/2006:10:11:45 > -0400] "\x05\x01" 200 0 "-" "-" > 218-166-163-180.dynamic.hinet.net - - [06/Apr/2006:10:11:45 > -0400] "CONNECT 4.79.181.15:25 HTTP/1.1" 200 7014 "-" "-" > 218-166-163-180.dynamic.hinet.net - - [06/Apr/2006:10:11:46 > -0400] "GET http://www.ebay.com/ HTTP/1.1" 200 7014 "-" "Mozilla/4.0 > (compatible; MSIE 5.00; Windows 98)" > > I posted a msg on the freebsd questions list and someone suggest I look at > mod_security. At first review I was interested enough to install the freebsd > port of the software. As I read the manual, slowly I began to realize > something was absent. > > The mod_security home page calls mod_security a web application firewall. > > In software firewalls there are 2 different types of filter rule sets. > > The exclusive firewall and the inclusive firewall. > > An exclusive firewall allows all services through except for those matching > a set of rules that block certain services. > > An inclusive firewall does the reverse. It only allows services matching the > rules through and blocks everything else. Inclusive firewalls are much, > much safer than exclusive firewalls. > > Now applying that to the mod_security filter rules I see explained in the > manual and the examples provided at the mod_security home page it becomes > very obvious that all the mod_security filter rules are of the exclusive > type. > > My web application is very vanilla. It uses hmtl and php for a counter of > page hits. It has no upload function, but does have a download function > launched from a link. No url's have any embedded tags. > > So I am interested in writing mod_security filter rules in reverse. > Basically I want to say deny everything except the get requests for the > files.htm or files.php names I see in the HTTP-access log for normal valid > usage of my web application. This sure would be a shorter filter include > file than including all the includes necessary to specify all the different > variations of attack request strings. > > Is there any example of how to accomplish building a inclusive mod_security > filter rules file. > > Maybe the next question should be is this even possible? > > And if not, then why not, and can it be changed to take the inclusive > approach as well as the current exclusive approach? > > If mod_security is going to be called a web application firewall then it > needs to be able to do both inclusive and exclusive filter rule > configurations. > > If it's indeed possible to build an inclusive filter rule set, I have a > workbench development website that I can use to be the test vehicle. Would > need the filter rules to specify deny everything and one filter rule for > accepting the get file.html request. > > Thanks for your help > Joe > > > > > > > Joe > > > > > > > > ________________________________ > How low will we go? Check out Yahoo! Messenger's low PC-to-Phone call rates. > > ________________________________ > Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates > starting at 1�/min. > > > > --------------------------------- Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates. --------------------------------- Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min. |
