I setup a new SSL certificate on my Apache server, and now when I try to access my website from HTTPS I get the error message "403 Forbidden".
From the apache log file I get:
[Fri Jul 31 20:54:51.069453 2015] [:error] [pid 12132] [client **.24.36.***] ModSecurity: Rule 7fdb76085a90 [id "981172"][file "/usr/share/modsecurity-crs/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf"][line "157"] - Execution error - PCRE limits exceeded (-8): (null). [hostname "example.com"] [uri "/test"] [unique_id "Vbggm6wfDPoAAC9k-CQBAAAB"]
This is the line 157 of the above file:
SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES "([\~\!\@\#\$\%\^\&\*\(\)\-\+\=\{\}\[\]\|\:\;\"\'\´\’\‘\`\<\>].*?){8,}" "phase:2,t:none,t:urlDecodeUni,block,id:'981172',rev:'2',ver:'OWASP_CRS/2.2.8',maturity:'9',accuracy:'8',msg:'Restricted SQL Character Anomaly Detection Alert - Total # of special characters exceeded',capture,logdata:'Matched Data: %{TX.1} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',tag:'OWASP_CRS/WEB_ATTACK/SQL_INJECTION',setvar:tx.anomaly_score=+%{tx.warning_anomaly_score},setvar:tx.sql_injection_score=+1,setvar:'tx.msg=%{rule.msg}',setvar:tx.%{rule.id}-OWASP_CRS/WEB_ATTACK/RESTRICTED_SQLI_CHARS-%{matched_var_name}=%{tx.0}"
So I tried to disable mod_security and indeed after it works fine.
Since I need to keep mod_security enabled, how can I fix this problem?
UPDATE
I edit the file /usr/share/modsecurity-crs/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf and I delete the line 157, now it works but what about the risk?
Not seen that issue before, but this link: https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/155 seems to suggest that upgrading to the latest OWASP CRS resolves the issue.
The latest rule set is here: https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project
The only difference I can see between 2.2.8 version you are running and the latest 2.2.9 version is that it also excludes _pk_ref cookie in that rule. Doing a quick search on Google suggests that is used by piwik.org - an analytics tracking tool, presumably similar to Google analytics. If you are using that software, then that might explain this. Otherwise I can see no reason why upgrading to the latest rule set would resolve the issue. Then again I don't know why you would want to run the old version the OWASP rules so might as well upgrade and see if that helps.
Disabling rules
If that doesn't resolve it then you can also disable the rule. To do that you should not edit the original file but instead add the following to your config AFTER the rule is defined, perhaps in your own modsec_customisations.conf file:
SecRuleRemoveById 981172
This is better then editing the actual file, as when you upgrade the rules (e.g. going from version 2.2.8 to 2.2.9 as I'm suggesting), then you don't lose your customisations.
Risk of disabling rules
As to the risk of disabling the rule, well this rule protects against cookies with multiple special characters. Sending of special characters in cookies are rarely security risks in themselves, but may be attempts to circumvent other rules (e.g. you can hide sql injection attempts in cookies by escaping, or by double escaping characters, so other rules don't recognise the sql injection, but because the escape characters may be resolved by your server programs they would still cause problems).
It's important to realise that neither ModSecurity nor the OWASP CRS that you can use to configure it, will 100% protect your website. They are designed to reduce the risk using known signatures they can check with rules. There are a lot of rules in the OWASP CRS and not all may be appropriate for your website. Obviously the more of these rules you turn off, the less you may be protected, but that doesn't mean you shouldn't turn off rules where appropriate. Part of installing ModSecurity is tuning and tweaking the ruleset: including turning off rules were appropriate. As long as you understand the rules you are tweaking, then you need to make the judgement call as to whether that's appropriate.