mod_security

[javaj]

I was wondering if anyone had a good mod_security ruleset that covers most of the bases on a cpanel/fantastico server or vps? I browsed the forums at cpanel and most suggest the rules from http://www.gotroot.com/ (http://www.gotroot.com/tiki-index.php?page=mod_security%20rules) I have a feeling adding too many of these would bring a vps to its knees though, There are a few others posted at the forums too, so anybody have a good all around ruleset they use or recommend, or should I go for the GotRoot rulesets and thin out most of the lists? Any suggestions?

Cam

[Jeff]

Hi Cam,

Here's my 2 cents, and I definitely encourage others to reply as well with ideas, rules, whatever you've got.

I think modsec is best used when it's customized for your needs. The gotroot ruleset is a good effort, but it's simply far too much for any type of server, not just a VDS. The badips.conf alone is almost 8,000 rules that need to be inspected before allowing or rejecting each request. Considering there are several billion IP addresses someone can launch an attack from, this is really just a drop in the ocean. For all the other rules, I would guess that 99% apply to software that most either aren't using, or has been patched already anyway for the specific exploit the ruleset is trying to stop.

I think modsec is best approached when determining what applications are being hosted on your server, and what types of threats exist at any given time for those applications. Common threats in web based apps are:

1. PHP Remote File Inclusion attacks
2. SQL Injection attacks
3. CRLF injection into PHP forms that send mail

There are some decent rules in the default ruleset as well as the gotroot ruleset for handling SQL Injection style attacks, while the Remote File Inclusion attacks are really just done on a per known-vulnerable software basis.


One thing I like to do is observe an environment for a while to get a feel for what types of things belong, and which don't. The better you know your environment, the faster and easier it is to recognize when something is out of place. Unfortunately, with web traffic, unless you're running a single low traffic website, it's very difficult to know what types of requests are getting passed through your webserver at any given time.

Here's a few modsec tips you may find handy for observing your web traffic, which can help for building a customized ruleset:


SecFilterSelective THE_REQUEST "string_to_look_for" "log,pass"


What that will do is log all requests that match "string_to_look_for" and allow the traffic to pass without being blocked. A log of the event will be written to /usr/local/apache/logs/audit_log. If you're using cPanel, there is an hourly cron job in /etc/cron.hourly called "modsecparse.pl" which will throw the events into the "modsec" db, and then truncate the audit_log. You can log into the db at any time by grepping the password from /etc/cron.hourly/modsecparse.pl, then using mysql from the command line to connect and view the events:



# head -20 /etc/cron.hourly/modsecparse.pl
#!/usr/bin/perl
BEGIN {
push(@INC,"/usr/local/cpanel");
push(@INC,"/usr/local/cpanel/whostmgr/docroot/cgi");
}

use SafeFile;
use DBI;


$dbhost="localhost";
$dbuser="modsec";
$dbpassword="TdxbdGStQaCrRqbRc3eB";
$dbname="modsec";
$tblname="modsec";

$dsn = "DBI:mysql:${dbname}:${dbhost}";
$dbh = DBI->connect($dsn, $dbuser, $dbpassword);




# mysql -u modsec -p modsec
Enter password:

mysql> describe modsec;
+----------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------------------+--------------+------+-----+---------+----------------+
| id | int(11) | | PRI | NULL | auto_increment |
| ip | varchar(15) | YES | | NULL | |
| date | date | YES | | NULL | |
| time | time | YES | | NULL | |
| handler | varchar(254) | YES | | NULL | |
| get | text | YES | | NULL | |
| host | varchar(254) | YES | | NULL | |
| mod_security_message | text | YES | | NULL | |
| mod_security_action | text | YES | | NULL | |
+----------------------+--------------+------+-----+---------+----------------+
9 rows in set (0.00 sec)

mysql> select * from modsec where date like '%2006-09-29%' and mod_security_message like '%string_to_look_for:%' \G



I know this doesn't really answer your question about what some good modsec rules to use are, but for me that's a difficult question to answer, It's really a balance of keeping out the bad stuff, while not interfering with your customer's traffic. And what is the bad stuff? It's hard (for me) to precisely define since there's so much of it, and not all of it is a threat anyway. If someone wants to launch ASP style attacks against a static html file, I consider the act itself bad, so to speak, but the traffic is harmless.

The bottom line really is this:

With modsec, you are protecting against 2 things:

1. Known vulnerabilities, and
2. Unknown threats

In the case of known vulnerabilities, if they're known, then rectifying the problem is simple - upgrade the software.

The other alternative is to learn everything you can about a new vulnerability, and create a rule to mitigate the threat across your entire server. Here are 2 examples the gotroot ruleset failed miserably on, and why I would never recommend strictly relying on it:

If you remember the phpxmlrpc issues from last year that affected many, many applications:

http://www.gulftech.org/?node=research&article_id=00088-07022005

a quick, simple rule: SecFilter "',''));"

The miniBB Zend_Hash_Del_Key_Or_Index Vulnerability:

http://www.hardened-php.net/hphp/zend_hash_del_key_or_index_vulnerability.html

one quick rule: SecFilter "index.php\?includeHeader=http"

Building and maintaining a good ruleset requires constant attention to existing threats. Monitoring security mailing lists and vulnerability databases are one good way to learn about when threats go public (and by then have probably already been used against many servers for quite some time), and will give you a jump on creating new rules before the kiddies have time to google inurl:xmlrpc.php and start mass exploiting servers.


In the case of unknown threats, well, there's no easy way to stop these, which is why I choose to observe, then log, or block based on what I see that could be a threat. If you do a bit of research on common threats toward web applications, such as the 3 I mentioned above, you will find that each have commonalities -

PHP Remote File Inclusion attacks - these could have a string such as
=http://
=https://
=data://
=php://

SQL Injection - these are much much more broad, and a few rules can be found in the gotroot ruleset as starting points to work with.

CRLF Injection - if you look in your modsec database now, you may see a few examples of these already, as we build each VDS with 2 basic rules for mitigating this issue ("bcc:" and "multipart/").


I'd also like to say that modsec is best when used as one layer of many. What happens when an attacker gets through modsec, either because no rule was in place to stop it, or because they were able to evade the rule? Now inspection must be done on the host itself. Preferably some soft of detection will be set up on the host itself to catch the unusual activity. An example of unusual activity could be a process in the process list that has never been seen before, or is not something that is expected. There are numerous possibilities for detecting successful attacks.

Preventing unknown attacks, however, is no easy task. Good rulesets take a lot of time and patience to build and maintain. The best thing I can recommend is reviewing the modsec documentation, creating test rules, testing those rules, and logging common attack signatures until you are comfortable with blocking them without interfering with legitimate traffic.

Key points:

1. Know your environment extremely well
2. Know what types of threats exist
3. Stay on top of existing threats, such as new public vulnerabilities and the applications they affect (and there are many new ones all the time)
4. Security is best done in layers, and requires constant care and feeding


I will be more than happy to answer any questions anyone has about modsec, creating rules, etc. Please share your rules and ideas. You can always do so via private message if you don't want to post detailed information in this public forum, but I encourage everyone to post here for all to see where possible.

[javaj]

Thanks Jeff, that was basicly the info I was looking for, I knew it had to be quite a bit more in depth than the info I was seeing on most forums which is just a usual response with something like use these rules and just kind of forget about it as if it is a set of firewall rules, I guess thats where most of my confusion came from. I am going to experiment abit with it without getting to complex where it conflicts with basic traffic or scripts.

I guess on another note you mentioned and not to drive this thread off course, but what is a good site with a list to watch for the latest vulnerabilities on most scripts? I subscribe to security mailing lists on every script I run but doing that for every possible script a user may install from fantastico or elsewhere is simply impossible, I know there are quite a few out there but is there one you guys watch that you would recommend?

[Ryan]

Thanks Jeff, that was basicly the info I was looking for, I knew it had to be quite a bit more in depth than the info I was seeing on most forums which is just a usual response with something like use these rules and just kind of forget about it as if it is a set of firewall rules, I guess thats where most of my confusion came from. I am going to experiment abit with it without getting to complex where it conflicts with basic traffic or scripts.

I guess on another note you mentioned and not to drive this thread off course, but what is a good site with a list to watch for the latest vulnerabilities on most scripts? I subscribe to security mailing lists on every script I run but doing that for every possible script a user may install from fantastico or elsewhere is simply impossible, I know there are quite a few out there but is there one you guys watch that you would recommend?

We normally keep an eye on http://milw0rm.com/, and http://secunia.com/. Both of those seem good, and have RSS feeds for simple reading.

Ryan

[javaj]

Thanks Ryan, bookmarking now :)

[Jeff]

In addition to what Ryan said:

Technical discussion
http://lists.immunitysec.com/pipermail/dailydave

Unmoderated discussion
http://lists.grok.org.uk/pipermail/full-disclosure

RSS feed
http://osvdb.com

If you're familiar with what applications are installed on your VDS (no easy task if you have a lot of customers), I'd check the vendors' sites on a daily basis, to include any News sections, Forums, RSS feeds, and so forth.

[javaj]

thanks guys,

I will post some rules I come up with after I comb a few different sets I have seen, I want to try and keep it a fairly small list for memory and load while trying to also not interfere with most scripts and normal traffic, I am guessing a root kit list is fairly important since I have seen the same list in every set ive seen, could be wrong, I will come up with a draft and see what you guys think :)

[Jeff]

Sounds good. Something else that is important is to put together a list of PHP functions that aren't in use on your server and disable them.

A few good ones, from /usr/local/Zend/etc/php.ini, are:

disable_functions = system,exec,shell_exec,passthru

There are others, and lists can be found floating around by googling for: php disable_functions

While not directly modsec related, it will prevent a lot of attacks that the kiddies use. That may break a few things such as install scripts for some applications, but those functions can be removed during the installation and added again afterwards.

You can also add dl to that line, or find the line that says:

enable_dl = On

and set it to off. dl is an evil feature that has gained a lot of infamy over the years for being used to afflict multiple websites on 1 server - regardless of the ownership of the account that was compromised.

We'll be glad to review your ruleset and will keep an eye out for it.

[javaj]

Here is what I came up with so far, I didnt change the defaults I just added on to them, its a mixture of got root, Kris S. at HostMerit.com, and a few others I have seen at cpanel forums:


SecFilterScanPOST On

SecFilter "multipart/"
SecFilter "bcc:"
# WEB-ATTACKS wget command attempt
SecFilterSelective THE_REQUEST "wget "

# WEB-ATTACKS uname -a command attempt
SecFilterSelective THE_REQUEST "uname -a"
# WEB-ATTACKS .htgroup access
SecFilterSelective THE_REQUEST "\.htgroup"

# WEB-ATTACKS .htaccess access
SecFilterSelective THE_REQUEST "\.htaccess"

# WEB-CLIENT Javascript URL host spoofing attempt
SecFilter "javascript\://"

# WEB-MISC cross site scripting \(img src=javascript\) attempt
SecFilter "img src=javascript"

# WEB-MISC cd..
SecFilterSelective THE_REQUEST "cd\.\."

# WEB-MISC ///cgi-bin access
SecFilterSelective THE_REQUEST "///cgi-bin"

# WEB-MISC /cgi-bin/// access
SecFilterSelective THE_REQUEST "/cgi-bin///"

# WEB-MISC /~root access
SecFilterSelective THE_REQUEST "/~root"

# WEB-MISC /~ftp access
SecFilterSelective THE_REQUEST "/~ftp"

# WEB-MISC htgrep attempt
SecFilterSelective THE_REQUEST "/htgrep" chain
SecFilter "hdr=/"

# WEB-MISC htgrep access
SecFilterSelective THE_REQUEST "/htgrep" log,pass

# WEB-MISC .history access
SecFilterSelective THE_REQUEST "/\.history"

# WEB-MISC .bash_history access
SecFilterSelective THE_REQUEST "/\.bash_history"

# WEB-MISC /~nobody access
SecFilterSelective THE_REQUEST "/~nobody"

# WEB-PHP PHP-Wiki cross site scripting attempt
SecFilterSelective THE_REQUEST "<script"

# WEB-PHP strings overflow
SecFilterSelective THE_REQUEST "\?STRENGUR"

# WEB-PHP PHPLIB remote command attempt
SecFilter "_PHPLIB\[libdir\]"

########################
# Original Defaults End
########################

# More BCC/PHP Spam prevention
SecFilterSelective THE_REQUEST "bcc:|Bcc:|BCc:|BCC:|bCc:|bCC:|bcC:|BcC:"

# BCC/BCC Chain
SecFilterSelective POST_PAYLOAD "Bcc:" chain
SecFilter "aol.com"

# Block various methods file downloading
SecFilterSelective THE_REQUEST "wget "
SecFilterSelective THE_REQUEST "lynx "
SecFilterSelective THE_REQUEST "scp "
SecFilterSelective THE_REQUEST "ftp "
SecFilterSelective THE_REQUEST "cvs "
SecFilterSelective THE_REQUEST "rcp "
SecFilterSelective THE_REQUEST "curl "
SecFilterSelective THE_REQUEST "ssh "
SecFilterSelective THE_REQUEST "echo "
SecFilterSelective THE_REQUEST "links http:// "
SecFilterSelective THE_REQUEST "links ftp:// "
SecFilterSelective THE_REQUEST "mkdir "
SecFilterSelective THE_REQUEST "cd /tmp "
SecFilterSelective THE_REQUEST "cd /var/tmp "
SecFilterSelective THE_REQUEST "cd /etc/httpd/proxy "

#generic block for fwrite fopen uploads
SecFilterSelective THE_REQUEST "fwrite" chain
SecFilterSelective THE_REQUEST "fopen"

# Prevent OS specific keywords
SecFilter /etc/password

# Prevent path traversal (..) attacks
#SecFilter "\.\./\.\."

# Weaker XSS protection but allows common HTML tags
SecFilter "<script"

# Protecting from XSS attacks through the PHP session cookie
SecFilterSelective ARG_PHPSESSID "!^[0-9a-z]*$"
SecFilterSelective COOKIE_PHPSESSID "!^[0-9a-z]*$"

#Known rootkits
SecFilterSelective THE_REQUEST "perl (xpl\.pl|kut|viewde|httpd\.txt)"
SecFilterSelective THE_REQUEST "\./xkernel\;"
SecFilterSelective THE_REQUEST "/kaiten\.c"
SecFilterSelective THE_REQUEST "/mampus\?&(cmd|command)"

#Generic remote perl execution with .pl extension
SecFilterSelective REQUEST_URI "perl .*\.pl(\s|\t)*\;"
SecFilterSelective REQUEST_URI "\;(\s|\t)*perl .*\.pl"

#Known rootkit Defacing Tool 2.0
SecFilterSelective REQUEST_URI "/tool(12)?[0-9]?\.(d(ao)t|gif|jpg|bmp|txt|png|asp)\?&?(cmd|command)="
SecFilterSelective REQUEST_URI "/tool\.(d(ao)t|gif|jpg|bmp|txt|png|asp)\?&?(cmd|command)="
SecFilterSelective REQUEST_URI "/tool25\.(d(ao)t|gif|jpg|bmp|txt|png|asp)\?&?(cmd|command)="
SecFilterSelective REQUEST_URI "/therules25\.(d(ao)t|gif|jpg|bmp|txt|png|asp)\?&?(cmd|command)="

#other known tools
SecFilterSelective REQUEST_URI "/xpl\.php\?&(cmd|command)="
SecFilterSelective REQUEST_URI "/(ssh2?|sfdg2)\.php"

#New kit
SecFilterSelective THE_REQUEST "/\.dump/(bash|httpd)(\;|\w)"
SecFilterSelective THE_REQUEST "/\.dump/(bash|httpd)\.(txt|php|gif|jpg|dat|bmp|png)(\;|\w)"

#new kit
SecFilterSelective REQUEST_URI "/dblib\.php\?&(cmd|command)="

#suntzu
SecFilterSelective THE_REQUEST|HTTP_Content-Disposition "/(suntzu.*|suntzu)\.php\?cmd="

#proxysx.gif?
SecFilterSelective THE_REQUEST "/proxysx\.(gif|jpg|bmp|txt|asp|png)\?"

#phpbackdoor
SecFilterSelective THE_REQUEST "/(phpbackdoor|phpbackdoor.*)\.php\?cmd="

#new unknown kit
SecFilterSelective REQUEST_URI "/oops?&"

# known PHP attack shells
#value of these sigs, pretty low, but here to catch
# any lose threads, honeypoting, etc.
SecFilterSelective THE_REQUEST "wiki_up/.*\.(php(3|4)?|tml|cgi|sh)"
SecFilterSelective THE_REQUEST "(wiki_up|temp)/(gif|ion|jpg|lala)\.ph(p(3|4)?|tml)"
SecFilterSelective THE_REQUEST "/(too20|phpshell|shell)\.ph(p(3|4)?|tml)"
SecFilterSelective REQUEST_URI "/phpterm"

#Frantastico worm
SecFilterSelective THE_REQUEST "(netenberg |psybnc |fantastico_de_luxe |arta\.zip )"

#new kit
SecFilterSelective REQUEST_URI "/c99shell\.txt"
SecFilterSelective REQUEST_URI "/c99\.txt\?"

#remote bash shell
SecFilterSelective REQUEST_URI "/shell\.php\&cmd="
SecFilterSelective ARGS "/shell\.php\&cmd="

#generic suntzu payload
SecFilterSelective THE_REQUEST "HiMaster\!\<\?php system\("
SecFilterSelective THE_REQUEST "error_reporting\(.*\)\;if\(isset\(.*\)\)\{system"
SecFilterSelective REQUEST_URI "help_text_vars\.php\?suntzu="

#25dec new one
SecFilterSelective REQUEST_URI "anggands\.(gif|jpg|txt|bmp|png)\?"

#26dec new kit
SecFilterSelective REQUEST_URI "newfile[0-9]\.(gif|jpg|txt|bmp|png)\?"
SecFilterSelective REQUEST_URI "/vsf\.vsf\?&"

#27dec
SecFilterSelective REQUEST_URI "/scan1\.0/scan/"
SecFilterSelective REQUEST_URI "test\.txt\?&"

#30dec
SecFilterSelective REQUEST_URI "\.k4ka\.txt\?"

#31dec
SecFilterSelective REQUEST_URI "/php\.txt\?"

#1 jan
SecFilterSelective REQUEST_URI "/sql\.txt\?"
SecFilterSelective REQUEST_URI "bind\.(gif|jpg|txt|bmp|png)\?"

#22feb
SecFilterSelective REQUEST_URI "/juax\.(gif|jpg|txt|bmp|png)\?"
SecFilterSelective REQUEST_URI "/linuxdaybot/\.(gif|jpg|txt|bmp|png)\?"

#24mar
SecFilterSelective REQUEST_URI "/docLib/cmd\.asp"
SecFilterSelective REQUEST_URI "\.asp\?pageName=AppFileExplorer"
SecFilterSelective REQUEST_URI "\.asp\?.*showUpload&thePath="
SecFilterSelective REQUEST_URI "\.asp\?.*theAct=inject&thePath="

SecFilter "local_path"
SecFilter "\/tmp\/cx"
SecFilter "LOCAL_PATH"
SecFilter "r57shell\.txt"
SecFilter "w00tw00t"

#March 29
SecFilter "Spaiz_Step57\.txt"
SecFilter "Step57\.txt"
SecFilterSelective THE_REQUEST "<scr"
SecFilter "orderSuccess\.inc\.php?" chain
SecFilter "=http"

SecFilter "cart_order_id=1"

SecFilterSelective THE_REQUEST "rootDir"
SecFilter "rootDir"

#some broken attack program
SecFilterSelective THE_REQUEST "PUT /.*_@@RNDSTR@@"
SecFilterSelective THE_REQUEST "trojan\.htm"

SecFilterSelective REQUEST_URI "/r57en\.php"

#c99 rootshell
SecFilterSelective REQUEST_URI "\.php\?act=(chmod&f|cmd|f&f=|ls|img&img=)"

#generic shell
SecFilterSelective REQUEST_URI "shell\.txt"

#wormsign
SecFilterSelective POST_PAYLOAD "((stripslashes|passthru)\(\$_REQUEST\[\"|if \(get_magic_quotes_gpc\()"

#new kit
SecFilterSelective REQUEST_URI "/c99shell\.txt"

#remote bash shell
SecFilterSelective REQUEST_URI "/shell\.php\&cmd="
SecFilterSelective ARGS "/shell\.php\&cmd="

#some broken attack program
SecFilterSelective THE_REQUEST "PUT /.*_@@RNDSTR@@"
SecFilterSelective THE_REQUEST "trojan\.htm"

#General [url] php forum protections (phpbb and others, to protect against script injection attacks in url links)
SecFilterSelective THE_REQUEST "\.php\?" chain
SecFilter "\[url=(script|javascript|applet|about|chrome|activex )\:/.*\].*\[/url\]"

#Experimental XML-RPC generic attack sigs
#SecFilter "\'\,\'\'\)\)\;"
SecFilter "\<param\>\<name\>.*\'\)\;"

#Specific XML-RPC attacks on xmlrpc.php
SecFilterSelective THE_REQUEST "(/xmlrpc|.*xmlrpc_services)\.php" chain
SecFilter "(\<xml|\<.*xml)" chain
SecFilter "(echo( |\(|\').*\;|chr|fwrite|fopen|system|echr|passthru| popen|proc_open|shell_exec|exec|proc_nice|proc_ter minate|proc_get_status|proc_close|pfsockopen|leak| apache_child_terminate|posix_kill|posix_mkfifo|pos ix_setpgid|posix_setsid|posix_setuid|phpinfo)\(.*\ )\;"

#Generic PHP attack sig
SecFilterSelective THE_REQUEST "system\(getenv\(HTTP_PHP\)\)"

#Generic PHP exploit signatures
SecFilter "\)\;(chr|fwrite|fopen|system|echr|passthru|popen|p roc_open|shell_exec)\(.*\)\;"

#generic XSS PHP attack types
SecFilterSelective THE_REQUEST "\.php\?" chain
SecFilter "javascript\:/(.*new\x20ActiveXObject.*Sh\.regwrite|.*window\.op ener\.document\.body.\innerHTML=window\.opener\.do cument\.body\.innerHTML\.replace)"

#PHP remote path attach generic signature
SecFilterSelective THE_REQUEST "\.ph(p(3|4)?)*/path=(http|https|ftp)"

#XML RPC exploit tool
SecFilterSelective HTTP_USER_AGENT "xmlrpc exploit*"
SecFilterSelective HTTP_USER_AGENT "Zeus .*Webster Pro*"

#Generic PHP attack sig
SecFilterSelective THE_REQUEST "system\(getenv\(HTTP_PHP\)\)"

#Generic PHP payload command injection and upload vulnerabilities
SecFilterSelective POST_PAYLOAD "<\?php" chain
SecFilter "((fputs|fread)\(.*\,.*\)\;|fsockopen\(gethostbynam e|chr\(.*\)\.chr\(.*\)\.chr\(|(fclose|fgets)\(.*\) \;|(system|exec)\(.*\)\;)" chain
SecFilter "\<\?php"

#Generic XML RPC attack sig
SecFilterSelective POST_PAYLOAD "\'(______BEGIN______|_____FIM_____)\'\;"

#HTTP header PHP code injection attacks
SecFilterSelective HTTP_CLIENT_IP|HTTP_USER_AGENT|HTTP_Referer "(<\?php|<[[:space:]]?\?[[:space:]]?php|<\? php)"
#wormsign
SecFilter "XXXXXXXXXXXXXXX\: \+\+\+\+\+\+\+\+\+\+\+\+\+"
SecFilterSelective THE_REQUEST "THMC\.\$dbhost\.THMC\.\$dbname\.THMC\.\$dbuser\.TH MC\.\$dbpasswd\.THMC"

#Fake image file shell attacvk
SecFilterSelective HTTP_Content-Type "image/.*"
SecFilterSelective POST_PAYLOAD "chr\("

#bogus graphics file
SecFilterSelective HTTP_Content-Disposition "\.php" chain
SecFilterSelective HTTP_Content-Type "(image/gif|image/jpg|image/png|image/bmp)"


it is 299 lines which is the shortest I have trimmed it so far, some of these may also be dated and unecessary, and as it is now it could be way to much for my vps, I trimmed it to about 250 lines shorter from the shortest list I have seen so far, I also removed alot of script specific rules thinking most are patched by now and fantastico is also up to date, so there is alot of generic stuff there. Hopeing most of these wont interefere with most scripts or normal traffic, I would guess alot of this is just diving in, whatching the database and seeing what happens. I may load these later just to see what happens with load average and memory...

[Jeff]

I'm going to throw in my critique for the sake of constructive
criticism, something to generate thoughts and ideas. Overall I'd say
the ruleset is decent. I mean, when it comes down to it, there are 2 types
of things being blocked:

1. Known attacks, whether they be against specific files, or
use specific malicious files

2. Classes of attacks


I went through the entire list and picked out a few rules I think
are either redundant and could cut down on the total number
either via consolidation or complete removal, and some that are
weak and easily able to be bypassed.



# WEB-ATTACKS uname -a command attempt
SecFilterSelective THE_REQUEST "uname -a"


Filters like this are trivially defeatable. Ex: "uname -a"
Note the extra space (ok vBulletin apparently doesn't insert the extra space
in the post, but let's just pretend there are 2 or more spaces in
the command). A better signature would be:


SecFilterSelective THE_REQUEST "uname[[:space:]]+-a"


And of course that won't prevent anyone from doing the
equivalent of "uname -a" - "uname -snrvpmio".

So perhaps this is an even better rule:

SecFilterSelective THE_REQUEST "uname[[:space:]]+-"



# More BCC/PHP Spam prevention
SecFilterSelective THE_REQUEST "bcc:|Bcc:|BCc:|BCC:|bCc:|bCC:|bcC:|BcC:"


The rule above is unnecessary for 2 reasons:

1. A "bcc:" rule is covered in the ruleset already, and
2. modsec doesn't care about case sensitivity.

The following rule covers all of those already:


SecFilter "bcc:"



# BCC/BCC Chain
SecFilterSelective POST_PAYLOAD "Bcc:" chain
SecFilter "aol.com"


The above rule can be safely removed as well, as the "SecFilterScanPOST On" rule is already enabled. Coupled with the "SecFilter "bcc:"" rule, this rule is a duplicate.



SecFilterSelective THE_REQUEST "links http:// "
SecFilterSelective THE_REQUEST "links ftp:// "


See above about using [[:space:]]+

Also, these 2 rules could be further condensed into 1 line:


SecFilterSelective THE_REQUEST "links (ht|f)tp:// "


But what if the attacker uses SSL (does links support SSL? Not sure myself).

We could filter ftp, http, and https all at the same time in 1 of 2 ways:


Method 1:

SecFilterSelective THE_REQUEST "links[[:space:]]+(ht|f)tp(s*):"


Method 2:

SecFilterSelective THE_REQUEST "links[[:space:]]+(ht|f)tp"



Good idea, Bad rule:


# Prevent path traversal (..) attacks
#SecFilter "\.\./\.\."


This rule is looking for the following:
../..

Directory traversal rules are good to have in place, because of attacks on scripts
that open files and don't do any sanity checking in the process. For poorly coded scripts
that allow a remote user to specify a file to be opened, the following attack can be done:

example.com/file.php?file=../../../../etc/passwd

However, what if we did this?

example.com/file.php?file=.././.././.././.././../etc/passwd


There goes /etc/passwd flying out of another webserver :)

Actually, I noticed an /etc/passwd filter in your ruleset, so you should be ok there. Unless...

If an attacker can execute commands via your webserver, they could always do "/bin/cat /etc/passw*" or something similiar. And there goes the "/etc/passwd" filter.



Overall I think you have a decent ruleset in terms of what most are using. However, I always emphasize not to rely too much on modsec, because it can be evaded at any time, regardless of how many rules are in place. It is there to stop most common attacks, some classes of attacks, and to help ensure that what's reaching out and actually communicating with Apache itself is valid per the HTTP protocol and not something anomalous.

[Jeff]

Hopeing most of these wont interefere with most scripts or normal traffic, I would guess alot of this is just diving in, whatching the database and seeing what happens


That's pretty much it. What's considered to be a good ruleset on one server may break many things on the next. Generally you just have to build the ruleset, then either check the modsec database frequently, or tail -f /usr/local/apache/logs/audit_log and keep a watchful eye on what's getting blocked. Remember, you can always place "log,pass" after a rule to have it logged and allowed rather than outright blocking it at first. This can really help when making new rules if there's concern about blocking legitimate traffic.

[javaj]

thanks Jeff, I am learning quite abit about syntax here :) I also removed those redundant rules.

but what if the attacker uses SSL (does links support SSL? Not sure myself).

I guess now it does, http://links.sourceforge.net/

I never checked whether it was even installed or not before I posted or when you brought it up, on mine with cpanel its not so I just removed it, good syntax lesson to learn from though. Note to self, dont add rules for server apps you dont have installed :D

Some great advice here, thanks...

Cam