Suspect 1: Access control
The most common cause of
client denied by server configuration error log entries is when you’re using Apache’s access control mechanisms to control who can and cannot view your site, or parts of it. We’ll give a quick example of why you might use it, then we’ll move on to why you might get errors.
Imagine we have a troublesome user visiting our site, and we know they have an IP address that doesn’t change (192.0.2.1), we can block them from our site with a simple bit of configuration in either our Apache configuration file, or in a
.htaccess (usually) in the root of our website:
Apache 2.2 (Apache 2.4 with mod_access_compat or LiteSpeed)
Allow from all
Deny from 192.0.2.1
Apache 2.4 (or LiteSpeed)
Require all granted
Require not ip 192.0.2.1
This will block any access from the IP address 192.0.2.1, and you can also block based on lots of other criteria as well, the Apache Access Control documentation covers it pretty well.
Now imagine a few years have passed, that problem user now no longer uses that IP address, it’s used by someone else who wants to access your site, but they’re getting a
403 Forbidden message in their browser telling them they can’t access your site:
That’s not good for business, so you or your host take a look at your error logs and in your error log the full error might look like this:
[Tue Jul 20 10:45:41.382781 2021] [:error] [pid 12345:tid 17933105366672] [client 192.0.2.1:42086] client denied by server configuration: https://example.org/a-web-page, referer: https://example.org
To find out why, we’d look in our
.htaccess file and in our Apache configuration to see if we can see that IP address 192.0.2.1 in relation to the access control examples shown above and we spot the entry denying them access, delete it, save the file and the user can access your site again.
If you can’t see an entry in relation to access control, then read on.
Now this one can be a tricky little character, because the error message is exactly the same as for access control, so if you don’t know you’re running mod_evasive then you might not think to check to see if it is the issue – That’s if you can even check or have any control over the settings for it.
mod_evasive is designed to protect your website from low level Denial-of-Service (DoS) attacks, where an attacker will make lots of requests to your site, hoping to use up all of your CPU and or memory resources and stop your site working and denying service to legitimate users. It does this by putting in place a number of limits such as:
- The number of requests for the same page a user is allowed in the ‘page interval’ (
DOSPageCount & DOSPageInterval)
- The number of requests to the whole site a user is allowed in the ‘site interval’ (
DOSSiteCount & DOSSiteInterval)
It will then block users for a defined number of seconds (
DOSBlockingPeriod) and can also email you (
DOSEmailNotify) or carry out another command on the server (
DOSSystemCommand) to pass the information to other tools e.g. your firewall.
What it doesn’t do, is give any indication in your normal error log, instead it logs DoS attacks in to a directory (
DOSLogDir), so if you think mod_evasive might be blocking your users, you need to find this location and look there, if it is then you’ll see files such as
If it is mod_evasive blocking then you have a couple of options:
- Allow the IP address in the configuration using:
- Change your page/site counts and intervals so they don’t trigger blocks as early
You might want to do #1 if it’s rare that it is causing an issue and #2 if it is catching lots of users.
Suspect 2.5: mod_evasive & cPanel
We recently came across an issue with an external cPanel server where all of a sudden they were getting 1000s of
403 Forbidden error messages for their users. As far as they were concerned, nothing had changed on the server, there had been no one logged in making any configuration changes.
We started investigating for them, and started out looking for issues with access control, as it’s the most likely culprit, but in this case it wasn’t. We tracked it down to a cPanel update overwriting a configuration file when an update was applied a few days earlier.
When the server had initially been setup by a 3rd party they had enabled mod_evasive using EasyApache and then edited the module configuration file:
and changed the cPanel defaults from:
The reason for the changes are because site makes extensive use of AJAX to load data in the background, so 100 requests in a 2 second period (the cPanel default) or 4 requests for the same AJAX endpoint in 2s were nowhere near enough and users were getting blocked for 10s at a time.
At some point, cPanel will always overwrite configuration files if you edit them, although in this instance it had remained unchanged since the server was setup 20 months earlier, so they had a good run.
We fixed the issue by putting the settings in to the cPanel provided
/etc/apache2/conf.d/includes/pre_virtualhost_global.conf file (also editable from WHM) which means that barring anything going badly wrong with cPanel, the changes will persist through updates:
Once again, users were able to use the application without issues.