Urgent : mod_security 403 errors

Portal Home > Knowledgebase > Articles Database > Urgent : mod_security 403 errors

Posted by zahirw, 09-09-2011, 10:12 AM
We were successfully running mod_security on the server till a few weeks ago, where it started throwing 403 errors everytime a form was submitted using HTML tags such as or characters like --- As long as there are no html tags in the field being submitted, it submits fine, the minute there is any html tag, it causes a 403 error. We had no idea what was causing the 403 errors so we finally uninstalled the mod_security module and now the site works fine. However, we're nervous that we have exposed ourselves to XSS and other attacks by uninstalling it. Can you possibly guide us on how we can accommodate mod_sec and still be able to use HTML tags on our forms? We are using the CRS rules. To install it, we were using the following instructions -- First, load the EPEL libraries into Centos rpm -Uvh http://download.fedora.redhat.com/pu...5-4.noarch.rpm Run install command yum install mod_security say yes to the instructions Add Secure dir mkdir /usr/local/apache mkdir /usr/local/apache/modsec_data chown apache:apache /usr/local/apache/modsec_data chown apache:apache /usr/local/apache Configuration Open /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf file, enter: # vi /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf Make sure SecRuleEngine set to "On" to protect webserver for the attacks: SecRuleEngine On Add secdatadir SecDataDir /usr/local/apache/modsec_data Check httpd.conf Ensure httpd.conf has the following line # Load config files from the config directory "/etc/httpd/conf.d". # Include conf.d/*.conf Restart Apache service httpd restart -- Thanks
Posted by anythingss, 09-09-2011, 10:35 AM
i consider the mod security CRS rules to be an tight ultra pedantic set of rules that probably have gone as far as possible to prevent security issues, without actually modifying your code in my opinion they started off with an absolutely fantastic idea for a core ruleset, that if done properly could have been accompanied with default installs of webservers in all distros. it could have changed the whole face of website "hacking", possibly even made it an extremely rare thing to hear of. But it seems they got distracted by what "the internet" says people/browsers/webservers should do, compared to what they actually do instead. which aren't necessarily the same thing. they've forgotten that -all- facets of the internet is just a mishmash of "it works for me" stuff, combined with other "it works for me stuff" that happens to make a network of servers which we call "the internet". even in the best case scenario it will still block a heap of legitimate people, just because their web browser doesnt follow X standard, or their isp's transparent proxy works strangely, or... etc.etc. Ive even seen google analytics set one if its random cookie values in such a way that crs blocks that visitor from now on! i would recommend against simply installing it on a server with existing websites/etc. If you want to use the full core ruleselt you should do extensive testing on a test server, and possibly redevelop your website to suit its specific requirements. the immediate solution is to take a look at your error log and audit logs and work out which rules were interfering with your website and decide if its safe to disable them. or, in fact the opposite, enable the rules you feel are the most important and leave out the ultra pedantic ones. which i think is how its designed to be used now? Last edited by anythingss; 09-09-2011 at 10:43 AM.
Posted by zahirw, 09-09-2011, 10:41 AM
Thanks for the response. Very insightful! Well I'm not sure which rules to leave out or how I'd even remove a rule. Some help on how to do this? Can I just disable a certain rule? We face a 403 whenever a user posts a form with html tags in it. Which rule do I edit under CRS to allow particular html characters?
Posted by HelpingHost, 09-09-2011, 11:07 AM
check your apache error log for mod_sec entries. Depending how it is configure, we for example have a separate mod_sec log, you should see lines like this for example: The important part to notice is [id "330039"]. This is the rule ID being used. Next, in one of your apache conf files (we use a special mod_sec_execptions.conf include file just for this purpose to keep things organized) and add a block like this for example: Now, this is just an example, you can use Apaches Location directive instead or even set it up as global setting by not including any Directive. Notice however, how the ID matches the ID in the log entry.
Posted by anythingss, 09-09-2011, 11:10 AM
the apache error log for the website should identify which rule it was that triggered it. I believe it even identifies which file and even the line number the rule is configured in you then need to exclude it from your config
Posted by zahirw, 09-09-2011, 01:26 PM
This is the error I get when I submit a form -- error log-- [client 115.242.51.223] ModSecurity: Warning. Operator LT matched 20 at TX:inbound_anomaly_score. [file "/etc/httpd/modsecurity.d/base_rules/modsecurity_crs_60_correlation.conf"] [line "31"] [msg "Inbound Anomaly Score (Total Inbound Score: 5, SQLi=, XSS=): 900016-Detects possible includes and typical script methods"] [hostname "www.x.com"] [uri "/live-chat/cometchat_receive.php"] [unique_id "U3DKZ38AAAEAAE@D2jwAAAAF"] [Fri Sep 09 22:45:45 2011] [error] [client 115.242.51.223] ModSecurity: Warning. Operator LT matched 20 at TX:inbound_anomaly_score. [file "/etc/httpd/modsecurity.d/base_rules/modsecurity_crs_60_correlation.conf"] [line "31"] [msg "Inbound Anomaly Score (Total Inbound Score: 5, SQLi=, XSS=): 900016-Detects possible includes and typical script methods"] [hostname "www.x.com"] [uri "/live-chat/cometchat_receive.php"] [unique_id "U@eTIX8AAAEAAE8amvIAAAAO"] [Fri Sep 09 22:45:52 2011] [error] [client 115.242.51.223] ModSecurity: Warning. Operator LT matched 20 at TX:inbound_anomaly_score. [file "/etc/httpd/modsecurity.d/base_rules/modsecurity_crs_60_correlation.conf"] [line "31"] [msg "Inbound Anomaly Score (Total Inbound Score: 5, SQLi=, XSS=): 900016-Detects possible includes and typical script methods"] [hostname "www.x.com"] [uri "/live-chat/cometchat_receive.php"] [unique_id "VFpLr38AAAEAAE@E3PYAAAAK"] [Fri Sep 09 22:46:00 2011] [error] [client 115.242.51.223] ModSecurity: Warning. Operator LT matched 20 at TX:inbound_anomaly_score. [file "/etc/httpd/modsecurity.d/base_rules/modsecurity_crs_60_correlation.conf"] [line "31"] [msg "Inbound Anomaly Score (Total Inbound Score: 5, SQLi=, XSS=): 900016-Detects possible includes and typical script methods"] [hostname "www.x.com"] [uri "/live-chat/cometchat_receive.php"] [unique_id "VM096H8AAAEAAE@G4dgAAAAM"]
Posted by zahirw, 09-09-2011, 04:18 PM
According to the above log, I need to exclude this file /etc/httpd/modsecurity.d/base_rules/modsecurity_crs_60_correlation.conf. Is it ok to exclude it?
Posted by zahirw, 09-10-2011, 04:22 PM
I seem to have followed the audit log correctly and have added the exceptions, however, I continued getting a 403 -- Message: Rule execution error - PCRE limits exceeded (-8): (null). Message: Access denied with code 403 (phase 2). Match of "streq 0" against "TX:MSC_PCRE_LIMITS_EXCEEDED" required. [file "/etc/httpd/conf.d/mod_security.conf"] [line "91"] [msg "ModSecurity internal error flagged: TX:MSC_PCRE_LIMITS_EXCEEDED"] Action: Intercepted (phase 2) Stopwatch: 1315685490784141 210134 (77823* 209624 -) Producer: ModSecurity for Apache/2.5.12 (http://www.modsecurity.org/); core ruleset/2.0.5. Server: Apache/2.2.3 (CentOS) I commented the following line in the mod_sec conf file #SecRule TX:/^MSC_/ "!@streq 0" \ # "phase:2,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'" Is this ill advised?
Posted by zahirw, 09-10-2011, 04:27 PM
BTW, the final list of exceptions. Safe? SecRuleRemoveById 960010 SecRuleRemoveById 900016 SecRuleRemoveById 900033 SecRuleRemoveById 900047 SecRuleRemoveById 900019 SecRuleRemoveById 973015 SecRuleRemoveById 960008 SecRuleRemoveById 900061 SecRuleRemoveById 973300 SecRuleRemoveById 960038 SecRuleRemoveById 973306 SecRuleRemoveById 90001 SecRuleRemoveById 90002 SecRuleRemoveById 900045 SecRuleRemoveById 900020 ~
Posted by zahirw, 09-10-2011, 04:59 PM
Added this line SecPcreMatchLimit 150000 SecPcreMatchLimitRecursion 150000 Works fine now, removed comments from the mod_sec conf
Posted by mikegotroot, 10-07-2011, 04:07 PM
No, you've excluded several rules you need to protect the system. You should modify these rules based on your applications requirements. Specifically, you dropped the XSS rules and the automated security scanner detection rules. Plus you have two rules list 90001, and 90002) that are not used anywhere. And several other others are used to detect suspicious things that may tell you an attack is occurring, so I wouldnt disable them, at the very least run them in log only mode. Disabling rules is the same thing as not running modsecurity for those types of attacks. When you disable a rule, you are not protected against that kind of attack, so you shouldnt disable a rule you should modify it to work with your system.
Posted by zahirw, 10-07-2011, 04:35 PM
Can you elaborate on how I can modify these based on my app? With these enabled, my sites running into 403s with practically any form submit.
Posted by mikegotroot, 10-07-2011, 06:04 PM
You'd ewant to look at the payload, evaluate if your application can safely handle that type of content and then exclude that part of the payload inspection from the rule. For example, if you had an application that took a bunch of arguments, and argument FOO accepted SQL safely and securely, you could exclude FOO from inspection for that rule. If the rule (a simple trivial example) was something like this: SecRule ARGS "sql stuff" Then you could exclude FOO with a simple negative: SecRule ARGS|!ARGS:foo "sql stuff" Keep in mind that simply excluding a variable without knowing if the application can safely handle the input is no different from just disabling the rule. So you would need to investigate if the application can do this securely. Another method would be to modify the rule itself, but you'd need to understand the attack methods and your application to do that. For example, if you had a rule to stop LDAP attacks and you knew your application didnt use LDAP you might be able to exclude those rules (although there are good reasons to not do that either, see my blog post below for a discussion of why you want to leave rules like that enabled): http://atomicorp.com/company/blogs/231-tripwires.html Keep in mind the core rules are written for security engineers, and its expected that you'll tune them for your needs. The CRS rules are not designed to be run out of the box without modification.