logo
logo
Sign in

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

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

I struggled for a while to found an answer to this annoying error that was clogging up my CSF logs. I've previously written about the ConfigServer safety & Firewall plugin for VPS and dedicated server and how to add log files for monitoring. But on every ocassion I opened my Apache HTTPd error_log file, it was filled with the following error:


This weird "client is rejected by server configuration" kept cropping up, and I had no idea why. And it was preceded by another error saying "Cannot serve directory..." always from the same IP address. Looking at the timestamp, I was up to see the request in my apache log but didn't know which way it was coming from. It wasn't available in my website access log, so I was completely stumped.


A few days ago, though, it struck me that I should look at the apache concurrent connections server-status log at InterWorks, and try to trace the error from there. And voila! I find a hint of something that led me to a solution. And here's the wisdom of my hard work for you!


Fixing the "Default Sites" setting in InterWorx

It turns out that InterWorks has a setting called "Default Sites". This determines what happens when a visitor tries to access your server via a direct IP address. The visitor can be directed to a directory, domain, or URL. Unfortunately, since I didn't initially set it up during the first VPS configuration, visitors were sent to the standard /var/www/html folder, which did not return anything because access is restricted in me .htaccess. Hence the server error "Cannot commit server directory", etc.


To Fix This, Navigate to The Default Site Setting in Interworks as Shown Here:

In this screenshot, I have changed the "Site" column to reflect my site, WP-Tweaks.com. This was what was causing the errors to be flooding my CSF logs. Once I edited and saved the changes, the VPS automatically re-started the Apache server, and the errors disappeared. So finally, the error log will now only show the important stuff.


You don't need to redirect to a URL. You can also send a request directly to the custom error page. But why bother wasting your server's resources by giving them a page - even an HTML one? Instead, I like to send it away in the ether. You can even re-direct the request to a random website if you want git branching strategy for continuous delivery!


IP Address Requests Bypass a Third-Party Firewall

What makes direct requests for IP addresses particularly annoying is that they can bypass any third part firewalls you may have set up at the DNS level. For example, I use Cloudflare WAF, which sits between my site and the rest of the world. I feel safe because people have to go through a security buffer to access my site. This is made possible since Cloudflare works at the DNS level.


However, if someone accesses your server directly via IP, there is nothing that Cloudflare can do. It is completely invisible. The only way to deal with these direct IP-based attacks is to have the firewall sit on your server itself. This is one reason why hardening your server is so important. Especially when it comes to securing ssh. The idea is to send the attacker to your server with the least resource consumption.


Hopefully, this tutorial will help you de-clutter your error log and help you keep track of what's important.


collect
0
avatar
Avinash Mittal
guide
Zupyak is the world’s largest content marketing community, with over 400 000 members and 3 million articles. Explore and get your content discovered.
Read more