See why the UpdraftPlus backup plugin is reporting an error when trying to save settings, and the ModSecurity rule that gets triggered at your host, plus two workarounds for it.
On hosts that run ModSecurity, when you attempt to save your settings in UpdraftPlus, you get a pop up with this warning message: updraft_send_command_error: Error (Forbidden)
The way UpdraftPlus (UDP) saves is via admin-ajax.
And that is now tripping a security wire at hosts who are running an extra security app called ModSecurity.
The rule flagged is: Remote File Access Attempt
What is ModSecurity?
ModSecurity is an important Web Application Firewall (WAF) app that most good hosts with cPanel or Plesk interfaces run on their servers to help protect your site from malicious hack attacks.
It includes the top 10 OWASP security threats, plus several other security rules.
OWASP stands for Open Web Application Security Project that produces reports and tools for better cyber security. All documentation and tools are freely available.
The particular OWASP rule sets used by the ModSecurity app are dictated by Imunify360, which specializes in malware scanning services.
In other words, we appreciate having this extra layer of security at our host to protect us, and alert the host, of cyber security attacks.
Reporting the Issue to UpdraftPlus Support
I contacted UDP support when I first discovered this issue, and even identified that ModSecurity was involved.
They said I was the only person out of their millions of users who had reported it, so it would be treated as an edge case.
In other words, they planned to do nothing.
I informed them that Imunify360 had recently released several new rule sets into ModSecurity.
And I reminded them that UDP settings are not something most folks ever change once set.
So, there may not have been enough time for hundreds of users to begin reporting this issue.
They still blew me off.
I hated to do it, and for everyone to have to spend more time on tickets, but it was the only way for me to not be the only one reporting it.
And that finally got their attention.
After multiple touches on each ticket that my clients reported, UDP support did contact Imunify360 about it.
And Imunify360 gave this reply:
“Disabling this rule will not affect server security.”
Scratching My Head
So, if we don’t need that rule for security, why doesn’t Imunify360 just remove it?
Fix the Plugin or the Security Rule
I’ve worked with a LOT of plugin and theme devs to help them make better wares for us, and to save them tons of support tickets by working with a qualified site tech who can help them get to the bottom of an issue quickly.
But lately I’ve run into too many devs who think their code doesn’t stink, and that the problem has to be elsewhere.
And that’s what I’ve run into with UDP support.
They finally did reach out to Imunify360 and found that the rule is triggering a false positive.
Imunify360 has said they will fix this in the next release of rules.
So, it wasn’t the plugin at fault, but it took the plugin devs to make extra efforts to get the 3rd party to fix it on their end.
Two Ways to Save Settings
There are ways to get around the error in the meantime
Don’t Turn Off the Security Rule!!!
All too often both plugin devs and hosts simply turn off the offending security rule, or worse, turn off ModSecurity altogether.
Their goal is to have a quick and easy fix for their users.
But, creating a security hole in your hosting or site is NOT a good fix.
SEE: What is ModSecurity and Should You Turn it Off? for details.
The suggestion from Imunify360, and then UpdraftPlus, is to have your host whitelist the triggered rule.
Sorry, I won’t be doing that, and neither will my clients.
Turn Off ModSecurity Temporarily
We rarely change our UpdraftPlus settings.
So, the better thing to do would be to temporarily turn off ModSecurity, save the settings, then turn ModSecurity back on.
And it’s super easy to do!
SEE: Fix ModSecurity Errors When Adding Scripts to Your Site Head Area for a tutorial.
Even though you are not adding a script, the tutorial is the same for turning off ModSecurity, which is in your cPanel at your host.
And this trick works great when you do try to add a script, like when you want to hard code Google Analytics on your site instead of using a plugin.
Want a Fast, Secure Site?
Get a site audit.
On average I find 26 security holes and performance drag that no tester can see.