SecRuleRemoveById being ignored

[steffen-nielsen]

Hi Spiderlab,

I'm experiencing that this option is being ignored on my Ubuntu 12.04 installation. I've tried with both version 2.6.3 (from repo) and 2.7.5 with Apache. Mod security runs fine and is triggered on different rules. But trying to disable the rules either globally or pr. site doesn't seem to have any effect - the rules keep triggering and prohobits access.

For instance i have defined the following in /etc/modsecurity/modsecurity_crs_99_whitelist.conf:
SecRuleRemoveById 981060 981205

But i still see the rules trigger in the audit log. Setting other options in this same file is being read fine, as "SecRuleEngine Off" does disable Mod security completely.

Could i be missing something or is this a bug?

/Steffen

[sarvasana]

I would also like to report this issue, but then on Windows 7, IIS 7.5 and ModSecurityIIS 2.7.5

Am overriding rule 981173 in a file named modsecurity_crs_60_customrules.conf.
I have given my override an id of 1. I also have used different notations such as:

SecRuleRemoveById 981173
SecRuleRemoveById '981173'
SecRuleRemoveById "981173"
SecRuleRemoveById "981172-981173"
SecRuleRemoveByID 981173

They all do not work.

[snippet]
SecRule ARGS_NAMES|ARGS|XML:/* "([~!@#%^&()-+={}[]|:;"'\´\’\‘`<>].?){4,}" "phase:2,t:none,t:urlDecodeUni,block,id:'2',rev:'2',ver:'OWASP_CRS/2.2.7',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}"

SecRuleRemoveById 981173
[/snippet]

[steffen-nielsen]

@Kriska
FYI i found this other version which seems to run fine: https://github.com/SpiderLabs/ModSecurity/tree/remotes/2.7.x

[sarvasana]

thanks, was it easy to compile?

[steffen-nielsen]

@Kriska
Yes, just followed the instructions.

[steffen-nielsen]

I might have something to investigate, but i don't know if it's related to Apache or not.

It seems that whenever i try to add more than one Include directory inside /etc/apache2/mods-available/mod-security.conf I am facing problems when disabling rules.
At the moment I just have a single Include line and mod_security is working fine.

root@srv # apache2 -v
Server version: Apache/2.2.22 (Ubuntu)
Server built: Jul 12 2013 13:37:10

Mod_security version: 2.7.5

[dmitrijn]

did you tried disable rules this way?

#deactive partially
<LocationMatch ".*">
SecRuleRemoveById 981173 981172
</LocationMatch>

[zimmerle]

@steffen-nielsen Just to summarize: By using a single include file everything is working as expected (including SecRuleRemoveById)? If you include another file then SecRuleRemoveById stops to work?

[steffen-nielsen]

@zimmerle
Yes, that's correct.

Originally i would include the following two directories, but leaving just the one of them fixed the problem. (Wildcards are translated, but should be in front of .conf)

Include /etc/modsecurity/.conf
Include /etc/modsecurity/activated_rules/.conf

[rcbarnett-zz]

@steffen-nielsen - based on the path info you supplied, I think the issue is the order in which these .conf files are executed/read. In your initial post, you listed the following exception file -

/etc/modsecurity/modsecurity_crs_99_whitelist.conf

This would be activated by the following Include directive -

Include /etc/modsecurity/*.conf

The issue may be that the SecRuleRemoveById directive must be declared after the rule it is disabling is already read into memory. This means that if rule ID 981060 is within a .conf file under /etc/modsecurity/activated_rules/ then the SecRuleRemoveById directive must be called up afterwards.

I would recommend that you used explicit Includes vs. wildcarding to ensure that your modsecurity_crs_99_whitelist.conf file is listed last.

[steffen-nielsen]

@rcbarnett
Thank you for the explanation, it makes good sense.

I hope this will help future readers, as I was struggeling to find help on the internet on this issue.

[thierrybo]

Uhm,

i didn't got that chance. I use only one include (Include "/etc/modsecurity/*.conf") and in /etc/modsecurity (sorry for the lon list but maybe something in this list could be wrong) i got this:

total 184
lrwxrwxrwx 1 root root 68 sept. 7 23:05 modsecurity_35_bad_robots.data -> /usr/share/modsecurity-crs/base_rules/modsecurity_35_bad_robots.data
lrwxrwxrwx 1 root root 66 sept. 7 23:05 modsecurity_35_scanners.data -> /usr/share/modsecurity-crs/base_rules/modsecurity_35_scanners.data
lrwxrwxrwx 1 root root 73 sept. 7 23:05 modsecurity_40_generic_attacks.data -> /usr/share/modsecurity-crs/base_rules/modsecurity_40_generic_attacks.data
lrwxrwxrwx 1 root root 79 sept. 7 23:05 modsecurity_41_sql_injection_attacks.data -> /usr/share/modsecurity-crs/base_rules/modsecurity_41_sql_injection_attacks.data
lrwxrwxrwx 1 root root 74 sept. 7 23:06 modsecurity_42_comment_spam.data -> /usr/share/modsecurity-crs/optional_rules/modsecurity_42_comment_spam.data
lrwxrwxrwx 1 root root 66 sept. 7 23:05 modsecurity_50_outbound.data -> /usr/share/modsecurity-crs/base_rules/modsecurity_50_outbound.data
lrwxrwxrwx 1 root root 74 sept. 7 23:05 modsecurity_50_outbound_malware.data -> /usr/share/modsecurity-crs/base_rules/modsecurity_50_outbound_malware.data
-rw-r--r-- 1 root root 8365 sept. 7 23:05 modsecurity.conf
-rw-r--r-- 1 root root 15 sept. 7 23:07 modsecurity.conf(DIST)
-rw-r--r-- 1 root root 7453 juil. 25 22:57 modsecurity.conf-recommended
lrwxrwxrwx 1 root root 79 sept. 7 23:06 modsecurity_crs_10_ignore_static.conf -> /usr/share/modsecurity-crs/optional_rules/modsecurity_crs_10_ignore_static.conf
lrwxrwxrwx 1 root root 56 sept. 7 23:05 modsecurity_crs_10_setup.conf -> /usr/share/modsecurity-crs/modsecurity_crs_10_setup.conf
lrwxrwxrwx 1 root root 77 sept. 7 23:06 modsecurity_crs_11_avs_traffic.conf -> /usr/share/modsecurity-crs/optional_rules/modsecurity_crs_11_avs_traffic.conf
lrwxrwxrwx 1 root root 77 sept. 7 23:06 modsecurity_crs_13_xml_enabler.conf -> /usr/share/modsecurity-crs/optional_rules/modsecurity_crs_13_xml_enabler.conf
lrwxrwxrwx 1 root root 89 sept. 7 23:06 modsecurity_crs_16_authentication_tracking.conf -> /usr/share/modsecurity-crs/optional_rules/modsecurity_crs_16_authentication_tracking.conf
lrwxrwxrwx 1 root root 83 sept. 7 23:06 modsecurity_crs_16_session_hijacking.conf -> /usr/share/modsecurity-crs/optional_rules/modsecurity_crs_16_session_hijacking.conf
lrwxrwxrwx 1 root root 83 sept. 7 23:06 modsecurity_crs_16_username_tracking.conf -> /usr/share/modsecurity-crs/optional_rules/modsecurity_crs_16_username_tracking.conf
lrwxrwxrwx 1 root root 81 sept. 7 23:05 modsecurity_crs_20_protocol_violations.conf -> /usr/share/modsecurity-crs/base_rules/modsecurity_crs_20_protocol_violations.conf
lrwxrwxrwx 1 root root 80 sept. 7 23:05 modsecurity_crs_21_protocol_anomalies.conf -> /usr/share/modsecurity-crs/base_rules/modsecurity_crs_21_protocol_anomalies.conf
lrwxrwxrwx 1 root root 76 sept. 7 23:05 modsecurity_crs_23_request_limits.conf -> /usr/share/modsecurity-crs/base_rules/modsecurity_crs_23_request_limits.conf
lrwxrwxrwx 1 root root 74 sept. 7 23:06 modsecurity_crs_25_cc_known.conf -> /usr/share/modsecurity-crs/optional_rules/modsecurity_crs_25_cc_known.conf
lrwxrwxrwx 1 root root 73 sept. 7 23:05 modsecurity_crs_30_http_policy.conf -> /usr/share/modsecurity-crs/base_rules/modsecurity_crs_30_http_policy.conf
lrwxrwxrwx 1 root root 72 sept. 7 23:05 modsecurity_crs_35_bad_robots.conf -> /usr/share/modsecurity-crs/base_rules/modsecurity_crs_35_bad_robots.conf
lrwxrwxrwx 1 root root 78 sept. 7 23:06 modsecurity_crs_40_experimental.conf -> /usr/share/modsecurity-crs/optional_rules/modsecurity_crs_40_experimental.conf
lrwxrwxrwx 1 root root 77 sept. 7 23:05 modsecurity_crs_40_generic_attacks.conf -> /usr/share/modsecurity-crs/base_rules/modsecurity_crs_40_generic_attacks.conf
lrwxrwxrwx 1 root root 83 sept. 7 23:05 modsecurity_crs_41_sql_injection_attacks.conf -> /usr/share/modsecurity-crs/base_rules/modsecurity_crs_41_sql_injection_attacks.conf
lrwxrwxrwx 1 root root 73 sept. 7 23:05 modsecurity_crs_41_xss_attacks.conf -> /usr/share/modsecurity-crs/base_rules/modsecurity_crs_41_xss_attacks.conf
lrwxrwxrwx 1 root root 78 sept. 7 23:06 modsecurity_crs_42_comment_spam.conf -> /usr/share/modsecurity-crs/optional_rules/modsecurity_crs_42_comment_spam.conf
lrwxrwxrwx 1 root root 76 sept. 7 23:05 modsecurity_crs_42_tight_security.conf -> /usr/share/modsecurity-crs/base_rules/modsecurity_crs_42_tight_security.conf
lrwxrwxrwx 1 root root 81 sept. 7 23:06 modsecurity_crs_43_csrf_protection.conf -> /usr/share/modsecurity-crs/optional_rules/modsecurity_crs_43_csrf_protection.conf
lrwxrwxrwx 1 root root 69 sept. 7 23:05 modsecurity_crs_45_trojans.conf -> /usr/share/modsecurity-crs/base_rules/modsecurity_crs_45_trojans.conf
lrwxrwxrwx 1 root root 77 sept. 7 23:06 modsecurity_crs_46_av_scanning.conf -> /usr/share/modsecurity-crs/optional_rules/modsecurity_crs_46_av_scanning.conf
lrwxrwxrwx 1 root root 79 sept. 7 23:05 modsecurity_crs_47_common_exceptions.conf -> /usr/share/modsecurity-crs/base_rules/modsecurity_crs_47_common_exceptions.conf
lrwxrwxrwx 1 root root 86 sept. 7 23:06 modsecurity_crs_47_skip_outbound_checks.conf -> /usr/share/modsecurity-crs/optional_rules/modsecurity_crs_47_skip_outbound_checks.conf
lrwxrwxrwx 1 root root 86 sept. 7 23:05 modsecurity_crs_48_local_exceptions.conf.example -> /usr/share/modsecurity-crs/base_rules/modsecurity_crs_48_local_exceptions.conf.example
lrwxrwxrwx 1 root root 80 sept. 7 23:06 modsecurity_crs_49_header_tagging.conf -> /usr/share/modsecurity-crs/optional_rules/modsecurity_crs_49_header_tagging.conf
lrwxrwxrwx 1 root root 78 sept. 7 23:05 modsecurity_crs_49_inbound_blocking.conf -> /usr/share/modsecurity-crs/base_rules/modsecurity_crs_49_inbound_blocking.conf
lrwxrwxrwx 1 root root 70 sept. 7 23:05 modsecurity_crs_50_outbound.conf -> /usr/share/modsecurity-crs/base_rules/modsecurity_crs_50_outbound.conf
lrwxrwxrwx 1 root root 85 sept. 7 23:06 modsecurity_crs_55_application_defects.conf -> /usr/share/modsecurity-crs/optional_rules/modsecurity_crs_55_application_defects.conf
lrwxrwxrwx 1 root root 75 sept. 7 23:06 modsecurity_crs_55_marketing.conf -> /usr/share/modsecurity-crs/optional_rules/modsecurity_crs_55_marketing.conf
lrwxrwxrwx 1 root root 79 sept. 7 23:05 modsecurity_crs_59_outbound_blocking.conf -> /usr/share/modsecurity-crs/base_rules/modsecurity_crs_59_outbound_blocking.conf
lrwxrwxrwx 1 root root 73 sept. 7 23:05 modsecurity_crs_60_correlation.conf -> /usr/share/modsecurity-crs/base_rules/modsecurity_crs_60_correlation.conf
-rw-r--r-- 1 root root 1608 sept. 30 00:17 modsecurity_crs_99_whitelist.conf
-rw-r--r-- 1 root root 15 sept. 9 19:36 modsecurity_crs_99_whitelist.conf(DIST)

[zimmerle]

Hi @thierrybo,

Try to place the SecRuleRemoveById rules after include everything else, such as:

Include "/etc/modsecurity/active_rules/*.conf"
Include "/etc/modsecurity/last_rules_to_be_loaded.conf"

[thierrybo]

OK, I use the default Debian Wheezy. In /etc/apache2/mods-enabled/mod-security.conf I have :

Include "/etc/modsecurity/*.conf"

in /etc/modsecurity/ i created modsecurity.conf and modsecurity_crs_99_whitelist.conf. All other files are symlinked from /usr/share/modsecurity-crs/modsecurity_crs_10_setup.conf , all files in /usr/share/modsecurity-crs/base_rules and all files in /usr/share/modsecurity-crs/optional_rules.

So there is only ONE flat level in /etc/modsecurity/ if didn't made a mistake here, so there shouldn't be an issue with folder priority ?