Problem with Bluehost and mod_security

They should be able to look at the logs and see what’s triggering the mod security failure, so I think hearing that’s the first step.

Have you heard back yet?

You can experiment with the URL, reduction testing until it doesn’t trigger the error. i.e. https://test.mywebsite.com/system/index.php?S=906390blahblahblah0cf162b20eb32&D=cp&C=javascript&M=combo_load&file=fields/file/file_field_drag_and_drop,fields/file/concurrency_queue,fields/file/file_upload_progress_table,fields/file/drag_and_drop_upload&v=1553901812. I’m curious if it’s objecting to the url or the content.

But by far the easiest option will be if they can tell you why there’s an issue.

Keep is in the loop on their response.

Bluehost support finally came through and our 5.2.2 site is functional once more.

Apparently they had to manually whitelist two rules in mod_security which were being triggered by our site. When i asked for more specifics, they stated:

The mod security rule that was getting blocked was the number: 340029 and the basic description is: Atomicorp.com WAF Rules: Attack Blocked - command in REQUEST_URI or Argument.

They couldn’t provide much more detail than that, and we’re a bit apprehensive about depending on them as a hosting provider, but it is nice that they were at least able to get our site functional once more.

I believe some of the javascript utilities located in /themes/ee/asset/javascript/compressed/fields/file were being blocked by mod_security, and were preventing us from uploading files onto our site.

We’re moving ahead with our migration to the new hosting platform, and abandoning our ancient 1.6 version of our site, but I’m a bit nervous that something like this may happen again.

Perhaps it would be prudent to mirror the site in an alternate hosting platform in case of a similar issue. We chose bluehost for our primary hosting site, as our needs are modest. Perhaps we can keep a copy up on Azure as well (we are a non-profit, and get azure server space for free). Although expressionengine seems to have problems with the one-click updater when hosted through an azure webapp.

I’m glad we’re up and running again.

I’m having a similar experience on a hosting platform running on Linux. The mod_security rule there is:

[Tue Apr 23 10:40:01 2019] [error] [client 91.184.7.3] ModSecurity: Access
denied with code 403 (phase 2). Pattern match "(?:;|/|\\\\|
)(?:\\\\b(?:cat|ls|perl|uname|pwd|cp|kill|tclsh8?|cpp|f(?:etch|tp)|python|chown|rm|kill|ping|rsync|r
diff-backup|scp|wget|curl|links|g\\\\+\\\\+|ch(?:grp|own)|passwd|r?(?:b|d)ash|t?c?sh|telnet|clang|nc)
\\\\b
|\\\\bsleep\\\\b [0-9])" at REQUEST_URI. [file
"/etc/httpd/modsecurity.d/rules/10_asl_rules.conf"] [line "437"] [id "340029"]
[rev "29"] [msg "Atomicorp.com WAF Rules: Attack Blocked - command in
REQUEST_URI or Argument"] [data "/cp "] [severity "CRITICAL"] [hostname
"*********"] [uri "/system/index.php"] [unique_id
"XL7PYVu4ACIADjOUyEkAAACU"]

The part that is causing the trouble is “/cp” which is potentially harmful as it is a “copy” line in Linux (so I’ve been told).

Unfortunately in my case it is on shared hosting, so they are unable to whitelist it…

Interesting. ‘cp’ is mentioned several times in my blocked url request:

https://test.mywebsite.com/system/index.php?S=906390blahblahblah0cf162b20eb32&D=cp&C=javascript&M=combo_load&file=cp/global_end,cp/files/picker,fields/textarea/cp,fields/file/cp,fields/file/file_field_drag_and_drop,fields/file/concurrency_queue,fields/file/file_upload_progress_table,fields/file/drag_and_drop_upload,fields/grid/file_grid,cp/date_picker&v=1553901812

The offending javascripts I believe are associated with the new file drag and drop capabilities within the newer versions of ExpressionEngine 5. Perhaps this is something that should be looked at in terms of the file structure of the themes folder for default installations. It may continue to pop up for various users on various hosting platforms.

I was on a shared hosting provider through bluehost, and they were able to whitelist the mod_security rules in my case. I get the impression that support staff can be somewhat clueless when it comes to edge cases like this. It took me several weeks to iron out the issue for each of my subdomains.

> I get the impression that support staff can be somewhat clueless when it comes to edge cases like this.

I have definitely run into that. Not all hosts, but it’s not rare.

The problem with trying to approach the problem from the EE side of things is mod security is a moving target. It’s just really not possible to try and accomidate whatever quirky filters might be in play.

It’s best to whitelist the entire ExpressionEngine control panel from mod_security, as it can do really weird things. Let me tell you how annoying it is for me when they break the query form in the cp so I can’t poke around the database!!!!!

Ahem. Anyway- it’s best to whitelist the cp. Ask the host, they may be able to help. If they don’t seem on top of it, it’s often possible to use htaccess to disable/control it. Which your host should be able to advise on, but sometimes you need to take it with a grain of salt.

Thank you for posting this! It really helped me narrow down this odd issue!

Is contacting our host the only way to deal with this? I’m bummed. Isn’t there something that the EE team can do or maybe offer us a better suggestion? This is extremely disappointing.