How to fix ‘client denied by server configuration’ error

Uh-oh, that sounds ominous when your site is broken and you’re seeing 100s of these entries in your Apache error log file.

Fortunately the culprit is usually pretty easy to track down.  We say usually, because there’s one case where it might not be quite as obvious, especially if you’re desperately searching Google for the answer whilst your site(s) are down or broken.

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)

Order Allow,Deny
Allow from all
Deny from 192.0.2.1

Apache 2.4 (or LiteSpeed)

<RequireAll>
  Require all granted
  Require not ip 192.0.2.1
<RequireAll>

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 dos-192.0.2.1 etc.

If it is mod_evasive blocking then you have a couple of options:

1. Allow the IP address in the configuration using: DOSWhitelist 192.0.2.1
2. 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.

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:

/etc/apache2/conf.modules.d/300-mod_evasive.conf

and changed the cPanel defaults from:

DOSHashTableSize    3097
DOSPageCount        4
DOSSiteCount        100

to:

DOSHashTableSize    12289
DOSPageCount        128
DOSSiteCount        512

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:

<IfModule mod_evasive24.c>
    DOSHashTableSize    12289
    DOSPageCount        128
    DOSSiteCount        512
</IfModule>

Once again, users were able to use the application without issues.