403: Forbidden Fruit, a WordPress & cPanel Story

It’s a dreadful feeling when you’re locked out of your WordPress website, isn’t it?

Sensitive information, development work, leads coming in that you can’t get to, all because you can’t even see those annoying login fields you need to remember your credentials for… how do you get back in with this nonsense in your way?

We’re experts at fixing this stuff

Let’s have a look at a scenario that happened to me recently, and how I solved it.

Good old Ben comes along, a great friend of mine I’ve shared some beers with, looking like Hide the Pain Harold. He tells me he has no idea why he’s seeing a 403 error when he visits benswebsite.com/wp-admin/

I do a quick Google in case it’s an easy fix; mention changing lines in a hidden file that controls how WordPress processes its file structure. It’s .htaccess, it’s always .htaccess… however, this time it’s more too. I just can’t leave it at advice, as often happens. So I ask if it’s something I have access to. I do, of course. I’m me.

Identifying the Problem

I have a look at the URL and it’s pretty dire – a server error page – “403: Permission Denied”. It’s more than your usual white screen or descriptive error that gives you a hint. But still, I go through the motions.

He’s using a temporary URL with cPanel, you know, one of those crazy things that looks like this: http://111.22.333.444/~cpanelusername/. Oh, these just love to cause trouble, always use subdomains folks. But it’s not the root cause.

I login to cPanel and navigate through to File Manager. I open up ‘public_html’, click the gear at the top right and ‘Show Hidden Files (dotfiles)’, edit his .htaccess, notice it isn’t configured correctly and fix that right up. It turns out he had two errors. Other pages were showing “404: Not Found” and would not show up. Well, that’s because WordPress needs more than just a slash when using a temporary URL. Tricky stuff.

Incorrect

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
#RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Correct

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /~cpanelusername/
#RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /~cpanelusername/index.php [L]
</IfModule>

Everything fixed right? Haha. It’s never that easy. I visit /wp-admin/ and hey, it’s my familiar and juicy pal, 403 Permission Denied, still locking down that ever useful admin area.

All right so, it’s got to be plugins causing this. If it’s not .htaccess, it’s always plugins. I pop into cPanel’s file manager, create a new directory inside of /wp-content/plugins/ called ‘!Disabled’ and drag all of the plugin folders in there. Refresh the /wp-admin/ part of the website. Can I crack open the melon yet? Nope, 403: Permission Denied.

I start digging into the error_log, a file in WordPress’ public_html directory that often tells you when things fail. But there are no entries dated the same day… the mystery deepens. Where do you even go next to figure this sort of thing out?

When it’s beyond the end user

This is probably where things stop for anyone with limited access to their website. Things are about to get mildly server admin-y.

So, the cause for this particular problem could be found in /usr/local/apache/logs/error_log – a real pain in the tail for your average end user to find.

An easier way than diving into connecting to a scary monochrome terminal is to hop into WHM (usually found at http://yourserverhostname:2087 or http://123.456.789.10:2087/ with your web host’s provided IP address) and find ConfigServer Security & Firewall (CSF) using the search function. You’re very much forgiven if things sound complex at this point.

If CSF is installed, you’re in luck. It has a wonderful ‘Watch System Logs’ feature, which lets you see what errors are cropping up in real time.

So I went with the first log because the most important errors will show up in here. It was ModSecurity. We’re deep in now aren’t we. I won’t go into details but suffice to say, when this happens the quickest fix is to disable the rule. This can be done by finding the ID listed in the error, which looks like this, with a much less fakey number: [id “1234500”]

This ID can then be searched for via ModSecurity Tools -> Rules List. Hitting ‘Disable’ will stop the offending rule from running. Of course ModSecurity is important protection, so always consider debugging further rather than disabling too many rules. It would be great to find the unique combination of theme, plugins and user action that caused the rule to be triggered right away, but we live in a fast paced world, don’t we?

That level of investigation’s getting into testing server territory, which is thoroughly in the web hosting space – something we handle in the background for our clients. WordPress does encounter false positives with ModSecurity sometimes, so you’d be forgiven for disabling a few rules over time.

Anyway, having disabled the rule I found the 403: Forbidden Fruit, and ate it. Ben’s in good hands with this sort of thing, and you should be too.

If you find yourself stuck with cPanel and no WHM access and you tried the initial steps, have a chat to your web host. They’ll fix it for you. And on the off chance they can’t, or if you have any quirky issues of your own like this, have a chat to us. We’ll host your website and deal with issues like this with a snap of our claws.