0

I've been trying to disable mod_security sql injection rule by adding this to the conf file

SecRuleRemoveById 981172
SecRuleRemoveById 981243
SecRuleRemoveById 981173
SecRuleRemoveById 981249
SecRuleRemoveById 981318
SecRuleRemoveById 981246
SecRuleRemoveById 981231

But theres seem to be more rules, is there anyway i can disable the sql injection rule without adding each rules id? or am i going about this the wrong way.

The reason i want to disable this is because i am attempting to install IPS(forums) and everything i do, whether it's adding a user or editing a category i get a 403 error caused by mod security and the errors usually say that there was a pattern match in the post header or cookies.

Edit: Here is one of the errors

Message: Access denied with code 403 (phase 2). Pattern match "(/\\*!?|\\*/|[';]--|--[\\s\\r\\n\\v\\f]|(?:--[^-]*?-)|([^\\-&])#.*?[\\s\\r\\n\\v\\f]|;?\\x00)" at ARGS:core_theme_setting_title_167. [file "/usr/share/modsecurity-crs/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf"] [line "49"] [id "981231"] [rev "2"] [msg "SQL Comment Sequence Detected."] [data "Matched Data: '#'>This  found within ARGS:core_theme_setting_title_167: <h4>Mega Footer Links</h4>\x0d\x0a<ul class='footerLinks'>\x0d\x0a\x09<li><a href='http://www.ipsfocus.com'>IPS 4.x themes</a></li>\x0d\x0a\x09<li><a href='#'>This is a link list</a></li>\x0d\x0a\x09<li><a href='#'>This is a longer link inside of the list</a></li>\x0d\x0a\x09<li><a href='#'>This is a link list</a></li>\x0d\x0a</ul>"] [severity "CRITICAL"] [ver "OWASP_CRS/2.2.8"] [maturity "8"] [accuracy "8"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"]
  • Is there any chance you could create a question with the original problem? (The cause of the 403 errors) Maybe some fresh eyes could help you find what the problem is, without actually stripping important security rules. – Reaces Apr 21 '16 at 11:58
  • I have amended the post with one of the errors – DavidSmith Apr 21 '16 at 12:34
0

The correct way to do this is as you've been doing, or perhaps better is to whitelist only the arguements causing you problems:

SecRuleUpdateTargetById 981231 "!ARGS:core_theme_setting_title_167"

As you've seen this can take some time to get all the whitelistings you need.

You should of course run in DetectionOnly mode and fine tune the rules until you get few (no?) false positives and are comfortable switching on to blocking mode. It would appear you're already running in blocking mode so I would suggest you switch back to DetectionOnly, leave it for a week, review the logs to whitelist all the rules that are false positives in one go, and then repeat again a few times. Much better to do that than to chase your tail one by one.

If you really do want to just turn off all the SQL Injection rules (they are very prone to over alerting!), you could just not include this file:

/usr/share/modsecurity-crs/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf

Depending how ModSecurity is set up in your config file, this could be done by removing that file (or the link to it) from the activated_rules directory as (usually) all files in that directory are included.

Of course that means you don't have the protection of these rules and how much of an issue that is for you, only you can judge. As I say they are noisy rules that take a while to fine tune, but SQL injection is also one of the most common and dangerous exploits out there.

Alternatively you could turn ModSecurity off completely. Personally I find it handy and have been protected by it in the past, but others think WAFs like it are more hassle than they are worth.

  • Thanks for your very detailed comment i really do appreciate it, i'll do what you recommended and run in DetectionOnly mode for a week or so. :) – DavidSmith Apr 25 '16 at 1:18
  • Np. Another good thing about DetectionOnly is it will allow all the rules to run. Whereas blocking mode will block on first failure and not run the other rules. So you can end up fixing a rule, just to find another also fires, so you fix that just to find another... etc. With DetectionOnly you get all the rules that would have fired, can clean them up, and then give it another week and hopefully get fewer (or no!) false alerts this time. And repeat. – Barry Pollard Apr 25 '16 at 7:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.