Fixing The “Client Denied By Server Configuration” Error On InterWorx

I had struggled for a while to find the answer to this vexing error clogging up my CSF logs. I’ve written before about the ConfigServer Security & Firewall plugin for VPS and dedicated servers, and how to add log files for monitoring. But whenever I opened my Apache httpd error_log file, it was filled with the following error:

This strange “Client denied by server configuration” kept cropping up and I didn’t know why. And it was always preceded by another error from the same IP address saying “Cannot serve directory…”. Looking at the timestamp, I was able to see the request come into my apache log but had no idea what path it was coming from. It wasn’t available in my website access logs, so I was completely stumped.

A couple of days back, however, it struck me that I should take a look at the Apache Server Status logs in InterWorx, and try and trace the error from there. And voila! I found a hint of something that led me to the solution. And here is my hard-won knowledge for you!

Fixing the “Default Sites” Setting in InterWorx

It turns out that InterWorx has a setting called “default sites”. This determines what happens when a visitor attempts to access your server directly through the IP address. The visitor can be directed either to a directory, a domain, or a URL. Since I hadn’t set this up initially during the first VPS configuration, the visitors were being sent to the standard /var/www/html folder, which didn’t return anything since access to that is forbidden in my .htaccess. Hence the server error “Cannot server directory” etc.

To fix this, navigate to the default sites setting in InterWorx as shown here:

In this screenshot, I’ve changed the “Site” column to reflect my site WP-Tweaks.com. It was this that was causing the errors to flood my CSF log. Once I edited and saved the changes, the VPS automatically restarted the Apache server, and the errors vanished. Finally, the error log will now only show important stuff.

You don’t have to redirect to a URL. You can also directly send the request to a custom error page. But why bother with wasting your server’s resources by giving it a page – even an HTML one? I prefer to just send it away into the ether. If you want, you can even redirect the request to a random website!

Requests to the IP Address Bypass a 3^rd Party Firewall

What makes direct requests to the IP address particularly annoying, is that they bypass any 3^rd part firewall you might have set up at a DNS level. For example, I use the Cloudflare WAF that sits between my site and the rest of the world. I feel safe because to reach my site, people have to go through a security buffer. This is made possible because Cloudflare works at the DNS level.

However, if someone accesses your server directly via an IP, there’s nothing that Cloudflare can do. It’s completely invisible. The only way to deal with these direct IP-based attacks is to have a firewall sitting right on your server itself. This is one of the reasons why hardening your server is so important. Particularly when it comes to securing SSH. The idea is to dispatch the attacker with as few resources consumed on your server as possible.

Hopefully, this tutorial will help you de-clutter your error logs and help you keep an eye on what’s important.