Issues with modsecurity OWASP and false positives.

[Spork Schivago]

I see in /usr/local/apache/logs/error_logs a lot of error messages. Here's a small chunk.

[Mon Jul 18 19:19:34.821609 2016] [:error] [pid 6823] [client 127.0.0.1] ModSecurity: Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"] [line "317"] [id "960009"] [rev "1"] [msg "Request Missing a User Agent Header"] [severity "NOTICE"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "9"] [tag "Host: "] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_UA"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "franklin.example.com"] [uri "/"] [unique_id "V41kBmjudWkAABqnkC4AAAAE"]


[Mon Jul 18 19:19:34.822806 2016] [:error] [pid 6823] [client 127.0.0.1] ModSecurity: Warning. Operator GE matched 5 at TX:inbound_anomaly_score. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/RESPONSE-80-CORRELATION.conf"] [line "35"] [id "981204"] [msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 5): Request Missing a User Agent Header"] [tag "Host: "] [tag "event-correlation"] [hostname "franklin.example.com"] [uri "/index.html"] [unique_id "V41kBmjudWkAABqnkC4AAAAE"]


[Mon Jul 18 19:20:01.427810 2016] [:error] [pid 6819] [client 127.0.0.1] ModSecurity: Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"] [line "283"] [id "960008"] [rev "2"] [msg "Request Missing a Host Header"] [severity "WARNING"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "9"] [tag "Host: "] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_HOST"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "franklin.example.com"] [uri "/whm-server-status"] [unique_id "V41kIWjudWkAABqjYU0AAAAA"]


[Mon Jul 18 19:20:01.427892 2016] [:error] [pid 6819] [client 127.0.0.1] ModSecurity: Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"] [line "317"] [id "960009"] [rev "1"] [msg "Request Missing a User Agent Header"] [severity "NOTICE"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "9"] [tag "Host: "] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_UA"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "franklin.example.com"] [uri "/whm-server-status"] [unique_id "V41kIWjudWkAABqjYU0AAAAA"]


[Mon Jul 18 19:20:01.428676 2016] [:error] [pid 6819] [client 127.0.0.1] ModSecurity: Warning. Operator GE matched 5 at TX:inbound_anomaly_score. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/RESPONSE-80-CORRELATION.conf"] [line "35"] [id "981204"] [msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 5): Request Missing a User Agent Header"] [tag "Host: "] [tag "event-correlation"] [hostname "franklin.example.com"] [uri "/whm-server-status"] [unique_id "V41kIWjudWkAABqjYU0AAAAA"]


[Mon Jul 18 19:20:34.546597 2016] [:error] [pid 6820] [client 127.0.0.1] ModSecurity: Warning. Match of "pm AppleWebKit Android" against "REQUEST_HEADERS:User-Agent" required. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"] [line "299"] [id "960015"] [rev "3"] [msg "Request Missing an Accept Header"] [severity "NOTICE"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "8"] [tag "Host: 127.0.0.1"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "127.0.0.1"] [uri "/whm-server-status"] [unique_id "V41kQmjudWkAABqkc0UAAAAB"]


[Mon Jul 18 19:21:34.542318 2016] [:error] [pid 6821] [client 127.0.0.1] ModSecurity: Warning. Match of "pm AppleWebKit Android" against "REQUEST_HEADERS:User-Agent" required. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"] [line "299"] [id "960015"] [rev "3"] [msg "Request Missing an Accept Header"] [severity "NOTICE"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "8"] [tag "Host: 127.0.0.1"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "127.0.0.1"] [uri "/whm-server-status"] [unique_id "V41kfmjudWkAABqlx7cAAAAC"]


[Mon Jul 18 19:22:34.564614 2016] [:error] [pid 6822] [client 127.0.0.1] ModSecurity: Warning. Match of "pm AppleWebKit Android" against "REQUEST_HEADERS:User-Agent" required. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"] [line "299"] [id "960015"] [rev "3"] [msg "Request Missing an Accept Header"] [severity "NOTICE"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "8"] [tag "Host: 127.0.0.1"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "127.0.0.1"] [uri "/whm-server-status"] [unique_id "V41kumjudWkAABqmocAAAAAD"]


[Mon Jul 18 19:22:51.937856 2016] [:error] [pid 6823] [client 169.54.244.75] ModSecurity: Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"] [line "317"] [id "960009"] [rev "1"] [msg "Request Missing a User Agent Header"] [severity "NOTICE"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "9"] [tag "Host: ip-104-238-117-105.ip.secureserver.net"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_UA"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "ip-104-238-117-105.ip.secureserver.net"] [uri "/"] [unique_id "V41ky2judWkAABqnkC8AAAAE"]


[Mon Jul 18 19:23:34.612950 2016] [:error] [pid 6819] [client 127.0.0.1] ModSecurity: Warning. Match of "pm AppleWebKit Android" against "REQUEST_HEADERS:User-Agent" required. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"] [line "299"] [id "960015"] [rev "3"] [msg "Request Missing an Accept Header"] [severity "NOTICE"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "8"] [tag "Host: 127.0.0.1"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "127.0.0.1"] [uri "/whm-server-status"] [unique_id "V41k9mjudWkAABqjYU4AAAAA"]

I believe the ones from 127.0.0.1 are false positive. I believe a cPanel script is checking /whm-server-status to make sure the server is up but there's maybe something wrong with the request header in the script and because of it, perhaps a false positive is being triggered.

I'd like to safely figure out how to whitelist this, so I don't see the log filled with these error messages whenever 127.0.0.1 tries connecting to /whm-server-status. I think the answer lies within the /usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-01-COMMON-EXCEPTIONS.conf file but I'm not sure how to properly write a rule. Can someone show me what I'd need to put in there?

I've also sent this message to the OWASP mailing list and if I get an answer from them, I'll update this message with that answer.

Thank you!

 

[Spork Schivago]

I mean I think the proper fix would be to figure out what scripts are causing this and just add a proper user agent and header field. I think I posted about this a long time ago but never really got that far with it. Any help is greatly appreciated. It is extremely hard finding real attacks when the log file is filled with these posts!!!! They come very often and are very frequent. I don't want to disable the rule completely because that makes my system more vulnerable. I just want to whitelist the stuff from 127.0.0.1, optimally, when we know for certain it's from a cPanel script.

Thanks!

 

[cPanelMichael]

Hello,

It's important to understand the risks involved with using the OWASP ruleset. We document the risks at:

OWASP ModSecurity CRS - cPanel Knowledge Base - cPanel Documentation

Also, one thread I recommend checking out is:

OWASP - mod security and wordpress

Though it's regarding WordPress, it includes several posts related to excluding rules that you may find helpful.

Let us know if you have additional questions.

Thank you.

 

[keat63]

I found that I had to disable a small number of rules, 960015 being one of them.
I have no idea what any of them do, and I've no idea whether they are false positives or real ones.
I'm literally working on the basis that any rules left intact are helping to protect us, which is better than having none at all.

 

[Spork Schivago]

I found that I had to disable a small number of rules, 960015 being one of them.
I have no idea what any of them do, and I've no idea whether they are false positives or real ones.
I'm literally working on the basis that any rules left intact are helping to protect us, which is better than having none at all.

This is something I considered and didn't want to do. From looking at the contents of the REQUEST-01-COMMON-EXCEPTIONS.conf file, it seems modsecurity is extremely configurable and I should be able to write a custom rule that says something like,
If the client is 127.0.0.1 AND it's missing the user agent or the header, AND it's trying to access /whm-server-status, let it through. Or if I could whitelist based on the MAC address and the IP, plus the other stuff, that'd be great.

The problem is I'm not very familiar with modsecurity and I have googled a good bit and read a good bit of information but I don't think a lot of users who run it really know a lot about it. It comes with cPanel and cPanel includes the OWASP rule set by default. I think most people probably just enable it and might not even ever look at log files or know where they're located or any of that.

I've seen many posts saying I fixed this by disabling this rule. And although that would work, don't get me wrong, it'd also disable that rule for real threats, you know what I'm saying? There's got to be a way to just write a custom rule in that file and get it to ignore the cPanel stuff.

If I could figure out what script was causing the issues, I would just try and modify it myself. It might not be a script though, it might be a compiled executable. You know, binary. And without the source, there's not much I could do there. That'd be something cPanel would have to do.

I'm going to read the links that cPanelMichael posted. Perhaps there's something in them besides disabling the actual rule.

Thanks.

 

[Spork Schivago]

Just in case anyone runs into this issue, I've added a new rule to the /usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-01-COMMON-EXCEPTIONS.conf file. I think perhaps this is better than completely disabling the rules that are causing the false positives. This is what I added:

#
# Exception for cPanel whm-server-status check.
#
SecRule REMOTE_ADDR "^127.0.0.1" phase:1,nolog,allow,id:'981022',ctl:ruleEngine=off

This not only stopped the error messages about the whm-server-status stuff but all the other false positives (I think maybe three or four in total) from appearing. It allows all traffic from 127.0.0.1. I think someone with a little more knowledge could perhaps fine tune this a bit more and specifically write it just so it whitelists stuff from 127.0.0.1 if it's trying to pull in whm-server-status or if we know for certain it's a cPanel script.

Can anyone think of any negative effects this rule might have? I was thinking a hacker could try spoofing their IP address to 127.0.0.1, but I don't see what could that'd do. I don't see how they'd be able to connect to my server at all. And what would my server do? Respond to itself...I honestly can't see this having any negative side effects, but what do you guys think?

Also, shouldn't something like this be in the REQUEST-01-COMMON-EXCEPTIONS.conf file? My understanding is everyone with a server running cPanel with mod_security enabled have this issue and most people are just disabling the rule.

 

[quizknows]

Generally you should be OK whitelisting the localhost IP (127.0.0.1). The only way an attacker could legitimately send requests from localhost is if they were already operating in a hacked site on your server, in which case, you have bigger problems. Spoofing an IP is really only relevant (typically) for syn floods, UDP attacks / DNS reflections... DDoS attacks basically.

If you wanted to allow it only for whm-server-status you can add additional conditions for a match with the "chain" feature, like this:

SecRule REMOTE_ADDR "^127.0.0.1" phase:1,nolog,allow,chain,id:'981022',ctl:ruleEngine=off
SecRule REQUEST_URI "whm-server-status"

This would make it so the request has to come from localhost AND be going to that URI to qualify for your "allow" action for the rule.

 

[Spork Schivago]

Generally you should be OK whitelisting the localhost IP (127.0.0.1). The only way an attacker could legitimately send requests from localhost is if they were already operating in a hacked site on your server, in which case, you have bigger problems. Spoofing an IP is really only relevant (typically) for syn floods, UDP attacks / DNS reflections... DDoS attacks basically.

If you wanted to allow it only for whm-server-status you can add additional conditions for a match with the "chain" feature, like this:

SecRule REMOTE_ADDR "^127.0.0.1" phase:1,nolog,allow,chain,id:'981022',ctl:ruleEngine=off
SecRule REQUEST_URI "whm-server-status"

This would make it so the request has to come from localhost AND be going to that URI to qualify for your "allow" action for the rule.

That's awesome! Thank you for sharing!!! There's more than one rule getting triggered but they're all from cPanel. I think cPanel should update the rules with something like we have here (there's already two rules in that file for cPanel stuff I believe but don't quote me) or change the script / program so it doesn't cause the false positives. I mean, honestly, the way it is by default just isn't right. It doesn't really cause physical problems but it makes it a lot harder going through logs because of how often this happens. The whm-server-status seems to happen once per minute. That adds up to a lot of log entries! It's very easy to miss real stuff.

What's a DNS reflection? I couldn't think of anyway whitelisting the local loopback could hurt, I tried thinking of cases too....all I could come up with DDoS attacks, but generally, I don't think there's really a lot you can do to prevent those types of attacks via software anyway.

There was another way I thought spoofing an IP could help an attack. What happens if I found away to spoof my IP to some random address and then I tried a bunch of exploits....and every one I tried, I assumed they went through and setup a remote shell so I could connect or something. Would something like that work? Would the server just ignore the packet or would it process it, even though I personally wouldn't get anything back on my end...I would this is one of the points of handshakes or something, right? To make sure the communications are two-way, with TCP I mean. Thanks for helping!

 

[quizknows]

Like I said, whitelisting 127.0.0.1 is not a huge risk. You are right, OWASP could certainly be better "off the bat." It's a shame that it isn't, and seems to not have improved much in recent months/years.

DNS reflections are attacks carried out by sending a packet with a spoofed source address to many DNS servers, so that the replies all go to whoever's IP is being spoofed as the source. This is made easier because DNS uses UDP, and UDP is not as robust as TCP in regards to handshakes etc. It pretty much just spews data and hopes that it gets there.

Since protocols like HTTP use TCP, You're not going to be able to simply spoof your address for webapp attacks... the initial TCP SYN would get there and that's about it. Like you said that's where the handshake comes into play.

 

[Spork Schivago]

Like I said, whitelisting 127.0.0.1 is not a huge risk. You are right, OWASP could certainly be better "off the bat." It's a shame that it isn't, and seems to not have improved much in recent months/years.

DNS reflections are attacks carried out by sending a packet with a spoofed source address to many DNS servers, so that the replies all go to whoever's IP is being spoofed as the source. This is made easier because DNS uses UDP, and UDP is not as robust as TCP in regards to handshakes etc. It pretty much just spews data and hopes that it gets there.

Since protocols like HTTP use TCP, You're not going to be able to simply spoof your address for webapp attacks... the initial TCP SYN would get there and that's about it. Like you said that's where the handshake comes into play.

I gotcha. Thanks for the information. Are only authoritative DNS servers prone to DNS reflections? If not, is there a good document on how I could work on "hardening" bind? Thanks.

 

[quizknows]

Generally as long as you are not an open resolver (allowing recursion) you are fine. You can check by performing a lookup for a domain you do not manage and ensuring your nameserver does not return a response, i.e.

#dig not-your-site.com @your.server.ip.address

if you get a proper response back (be sure to try a domain that actually exists, like google.com or something) then you need to disable or restrict recursion in your named (bind) config.

 

[Spork Schivago]

Generally as long as you are not an open resolver (allowing recursion) you are fine. You can check by performing a lookup for a domain you do not manage and ensuring your nameserver does not return a response, i.e.

#dig not-your-site.com @your.server.ip.address

if you get a proper response back (be sure to try a domain that actually exists, like google.com or something) then you need to disable or restrict recursion in your named (bind) config.

Good to go! I ran dig on google.com and received QUERY: 1, ANSWER: 0
WARNING: recursion requested but not available.

Thanks for sharing!

 

[keat63]

any chance of a dummies guide on what you did please. ?

 

[quizknows]

Keat63, basically just make sure recursion is disabled in the options section of named.conf like this:

options {
allow-recursion { none; };
allow-transfer  { none; };
};

You may have other options in there but as long as allow-recursion is set to none (or a trusted ACL but that's more advanced) you should not be used in DNS reflection attacks.

 

[keat63]

Yesterday, I looked at the recursion thing and added those entries to the options section, but got errors relating to recursion being unknown when i restarted DNS.
So Instead I searched named.conf and found 2 entries relating to recursion='yes', I changed these to 'no', then monitored the server.
DIG revealed no recursion, and i saw no detrimental effects, that i'm aware of. Domains seem intact and running, no apparent disruption to emails.

So provided this is still the case and that i've not done anything stupid, could someone talk me through making the changes to OWASP.

 

[Spork Schivago]

...So provided this is still the case and that i've not done anything stupid, could someone talk me through making the changes to OWASP.

Yup.

Since you were able to edit the named.conf file manually, I'm going to assume you have shell access and know how to edit files via your shell access.

Edit the file:

/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-01-COMMON-EXCEPTIONS.conf

I use nano, so for me, I type:

nano -w /usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-01-COMMON-EXCEPTIONS.conf

At the very bottom of that file, copy and paste (or type this):

#
# Exception for cPanel whm-server-status check.
#
SecRule REMOTE_ADDR "^127.0.0.1" phase:1,nolog,allow,id:'981022',ctl:ruleEngine=off

If you type it, be extremely careful and make sure you type it exactly like that. Save the file (in nano, hit CTRL-X and enter). You might need to restart Apache, I'm not certain. For my CentOS system, to restart Apache, I type:

service httpd restart

Because I'm on v58, there's a bug that I discovered and that command might not work. So, if that command gives you some stuff about PID not being found or httpd is already running or something like that, use the cPanel script.

/scripts/restartsrv_apache

After that, you should be good.

 

[Spork Schivago]

Yesterday, I looked at the recursion thing and added those entries to the options section, but got errors relating to recursion being unknown when i restarted DNS.
So Instead I searched named.conf and found 2 entries relating to recursion='yes', I changed these to 'no', then monitored the server.
DIG revealed no recursion, and i saw no detrimental effects, that i'm aware of. Domains seem intact and running, no apparent disruption to emails...

I believe you should do more than just set recursion=no.

In /etc/named.conf, where you found the recursion=no, in that section, if you scroll down to the bottom of that section (not the file), you should see something like:

pid-file                 "/var/run/named/named.pid";
dump-file                "data/cache_dump.db";
statistics-file          "data/named_stats.txt";
/* memstatistics-file    "data/named_mem_stats.txt";

This is where I made my changes. I also hid my version of named to make it a bit harder for hackers to get in. This is what my section looks like:

pid-file                 "/var/run/named/named.pid";
dump-file                "data/cache_dump.db";
statistics-file          "data/named_stats.txt";
/* memstatistics-file    "data/named_mem_stats.txt";
allow-transfer    { "none"; };
allow-recursion   { "none"; };

/* Hide the version number so it's harder to attack us. */
version none;

Afterwards, you can check the config file to make sure you typed everything correctly:

named-checkconf /etc/named.conf

If it doesn't give you any errors, restart named. On CentOS, I'd do this by running:

service named restart

I hope this helps.

 

[keat63]

I'm pretty much tied up for a short while, so I'll look at this when I can dedicate some monitoring time and can quickly react to any issues.

Thanks

 

[Spork Schivago]

Okay Keat63. Please keep me updated with your progress and let me know if you have any trouble.

 

[rclemings]

I'm having some trouble dealing with two false positives. This is cPanel's implementation of OWASP ver.3.0.0, as nearly as I can tell (from /etc/apache2/conf.d/modsec_vendor_configs/OWASP/modsecurity_crs_10_setup.conf). I've masked some possibly sensitive data.

523939:[Thu Dec 01 10:25:39.244073 2016] [:error] [pid 24880] [client xx.xx.xxx.xxx] ModSecurity: Access denied with redirection to Example Domain using status 302 (phase 2). Pattern match "\\\\%((?!$|\\\\W)|[0-9a-fA-F]{2}|u[0-9a-fA-F]{4})" at ARGS:returnUrl. [file "/etc/apache2/conf.d/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"] [line "219"] [id "950109"] [rev "2"] [msg "Multiple URL Encoding Detected"] [severity "WARNING"] [ver "OWASP_CRS/3.0.0"] [maturity "6"] [accuracy "8"] [tag "Host: www.example.com"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/EVASION"] [hostname "www.example.com"] [uri "/xxx.php"] [unique_id "WEBA83cQjKbwhNpTYWkudQAAAAQ"]

526747:[Thu Dec 01 10:41:28.958952 2016] [:error] [pid 26285] [client xx.xx.xxx.xxx] ModSecurity: Access denied with redirection to Example Domain using status 302 (phase 2). Match of "beginsWith %{request_headers.host}" against "TX:1" required. [file "/etc/apache2/conf.d/modsec_vendor_configs/OWASP/rules/REQUEST-31-APPLICATION-ATTACK-RFI.conf"] [line "30"] [id "950120"] [rev "3"] [msg "Possible Remote File Inclusion (RFI) Attack: Off-Domain Reference/Link"] [data "Matched Data: https://another.example.com/a/account/validatethirdpartycorporateauthresult?redirectUrl=http://another.example.com/a found within TX:1: another.example.com/a/account/validatethirdpartycorporateauthresult?redirectUrl=http:%2F%2Fanother.example.com%2Fa"] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "9"] [tag "Host: www.example.com"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-remote file inclusion"] [tag "OWASP_CRS/WEB_ATTACK/RFI"] [hostname "www.example.com"] [uri "/xxx.php"] [unique_id "WEBEqF9us8Ws-b6n3kgKmAAAAAI"]

I've confirmed that those rules are the problem by temporarily disabling them, but I would like to create an exception instead. I am trying to use the "add rule" function in cPanel's WHM/Security Center/ModSecurity/Tools/Rules List. Here is what I'm trying to add (singly and both at once):

SecRuleUpdateTargetById 950109 !ARGS:'another.example.com'
SecRuleUpdateTargetByID 950120 !ARGS_NAMES:'another.example.com'

When I try to save and deploy, here is what I get in the cPanel error log:

[2016-12-01 16:09:21 -0500] warn [xml-api] The system failed to deploy the changes for “modsec/modsec2.user.conf”: The system could not validate the new Apache configuration because httpd exited with a nonzero value. Apache produced the following error: AH00526: Syntax error on line 1 of /etc/apache2/conf.d/modsec/modsec2.user.conf:
Updating target by ID with no ruleset in this context

I've tried various combinations of single quotes, double quotes, no quotes, but to no avail. The server vendor thinks it's a syntax error.

Suggestions?