Posts Tagged ‘good security’

WordPress Security: Fix WordPress wp-config.php improper permissions to protect your sites from Database password steal / Website deface

Thursday, March 12th, 2015

Keeping WordPress Site / Blog and related installed plugins up-to-date
is essential to prevent an attacker to hack into your Site / Database and deface your site, however if you're a company providing shell access from Cpanel / Plesk / Kloxo Panel to customers often customers are messing up permissions leaving important security credential files such as wp-config.php (which is storing user / pass credentials about connection to MySQL / PostgreSQL to have improper permissions and be world readable e.g. have permissions such as 666 or 777 while in reality the WordPress recommended permissions for wp-config.php is 600. I will skip here to explain in details difference between file permissions on Linux as this is already well described in any Linux book, however I just will recommend for any Share hosting Admin where Wordperss is hosted on Lighttpd / Apache Webserver + Some kind of backend database to be extra cautious.

Hence it is very useful to list all your WordPress sites on server wp-config.php permissions with find like this:


find /  -iname 'wp-config.php' -print1;


I find it a generally good practice to also automatically set all wp-config.php permissions to 600 (6= Read / Write  permissions only for File Owner  user 0 = No permissions for All groups, 0 = No Permissions for all non-owner users)

If find command output gives you some file permissions such as:

ls -al /var/www/wordpress-bak/wp-config.php
-rw-rw-rw- 1 www-data www-data 2654 jul 28  2009 wp-config.php


E.g. file permission has 666 permissions (Readable for all users), then it is wise to fix this with:

chmod 600 /var/www/wordpress-bak/wp-config.php

It is generally a very good practice to run also a chmod 600 to each and every found wp-config.php file on server:

find /  -iname 'wp-config.php' -print1 -exec chmod 600 '{}' \;

Above command will also print each file to whcih permission is set to Read / Write for Owner (this si done with -print1 option).

It is a good practice for shared hosting server to always configure a root cronjob to run above find chmod command at least once daily (whenever server hosts 50 – 100 wordpress+ more sites).

crontab -u root -l | { cat; echo “05 03 * * * find /  -iname 'wp-config.php' -print1 -exec chmod 600 '{}' \; } | crontab – 

If you don't have the 600 permissions set for all wp-config.php files this security "backdoor" can be used by any existing non-root user to be read and to break up (crack)  in your database and even when there are Deface bot-nets involved to deface all your hosted server wordpress sites.

One of my servers with wordpress has just recently suffered with this little but very important security hole due to a WordPress site directory backup  with improper permissions which allowed anyone to enter MySQL database, so I guess there are plenty of servers with this hidden vulnerability silently living.

Many thanks to my dear friend (Dimitar PaskalevNomen for sharing with me about this vulnerability! Very important note to make here is admins who are using some security enhancement modules such as SuPHP (which makes Apache webserver to run Separate Website instances with different user), should be careful with his set all wp-config.php modules to Owner, as it is possible the wp-config.php owner change to make customer WP based websites inaccessible.

Another good security measure to  protect your server WordPress based sites from malicious theme template injections (for both personal own hosted wordpress based blog / sites or a WordPress hosting company) is to install and activate WordPress Antivirus plugin.

How to remove parameters from URL on Apache (Reverse Proxy) with .htaccess and mod_rewrite – Remove query string from Link

Thursday, December 11th, 2014

Recently I had a task to delete number of set variables (listed parameters) from URL address on a Apache webserver serving as Reverse Proxy. 
To make it more clear exact task was when customers call the URL (all subdomains included) the following URL parameters should always be deleted by the reverse proxy

– ebppMode 
– ebppObjectKey 
– ebppObjectType 
– ebppSystem 
– logSys 

The paramets are part of SAP Biller Direct in a Portal (based on the famous SAP database) which is often deployed as a component of Internet Sales (ISA) / Supplier Relationship Management (SRM) / CRM
, if a user is logged in with his Credentials (KID (Key ID) / Admin KID)  into the system. The EBPP part of most variables stands for (Electronic Bill Presentment and Payment).

 By passing above parameters to Website, modes of use, user accounts switched with which user is logged into the system system logs read and other stuff which can turn to be a severe security hole.
As most of Big Companies, does pass there web traffic via a "transparent" Reverse Proxy,it is a good security practice for SAP Biller Direct (including CRM systems( to wipe out this variables

Here is the mod_rewrite working rules that I used to achieve the delete variable from URL address task:

   RewriteEngine On
   RewriteCond %{QUERY_STRING} ^(.*)bebppMode=(w*)b(.*)
   RewriteRule (.*) $1?%1%3

   RewriteCond %{QUERY_STRING} ^(.*)bebppObjectKey=(w*)b(.*)
   RewriteRule (.*) $1?%1%3

   RewriteCond %{QUERY_STRING} ^(.*)bebppObjectType=(w*)b(.*)
   RewriteRule (.*) $1?%1%3

   RewriteCond %{QUERY_STRING} ^(.*)bebppSystem=(w*)b(.*)
   RewriteRule (.*) $1?%1%3

   RewriteCond %{QUERY_STRING} ^(.*)logSys=(w*)b(.*)
   RewriteRule (.*) $1?%1%3

   RewriteCond %{QUERY_STRING} ^(.*)&&(.*)
   RewriteRule (.*) $1?%1%3

P.S. I've implemented above Rewrite rules into all Virtualhosts of Applications (in that case all living in the same httpd.conf on SuSE (SLES) 11 SP1 Enterprise Linux server).
To make changes affective, restarted HTTPD Webserver:

/etc/init.d/httpd restart

The sesult is:

leads to a internal URL redirection

without parameters ebppSystem, ebppMode, ebppObjectKey, ebppSystem,   logSys .

Other mod_rewrite rule that works but is too ugly and when I tried it on Debian Linux host was behaving strange (including in the rewrited URL address the directory address of the PHP twice):

RewriteCond %{QUERY_STRING} (.*)(^|&|%26|%20)ebppMode(=|%3D)([^&]+)(.*)$ [OR]
RewriteCond %{QUERY_STRING} (.*)(^|&|%26|%20)ebppObjectKey(=|%3D)([^&]+)(.*)$ [OR]
RewriteCond %{QUERY_STRING} (.*)(^|&|%26|%20)ebppObjectType(=|%3D)([^&]+)(.*)$ [OR]
RewriteCond %{QUERY_STRING} (.*)(^|&|%26|%20)ebppSystem(=|%3D)([^&]+)(.*)$ [OR]
RewriteCond %{QUERY_STRING} (.*)(^|&|%26|%20)logSys(=|%3D)([^&]+)(.*)$

RewriteRule (.*) /$1?%1%5 [R=307]

 Well anyways, with the first bunch of mod_rewrite rule it works fine.

Thanks God Problem Solved 🙂

Client Denied By Server Configuration Linux Apache error solution

Thursday, August 1st, 2013

Client denied by server configuration fix solution Apache feather logo

If you run Apache server on Debian Linux / Ubuntu / CentOS whatever Linux OS and you try to install a new PHP application under lets say /var/www/ getting an error in Apache error.log like:

[Wed Jul 31 03:36:21 2013] [error] [client] client denied by server configuration: /var/www/vea/index.php, referer:

This is due to misconfigured AllowOverrides in some of your main configuration files.

So what is causing the error?

Reason is by default in most current Linux distributions Apache is configured to have restrictive policy following the good security practice (Restrictive by default).
Apache is configured by default to not accept AllowOverrides – i.e. AllowOverride None for DocumentRoot /, because there are plenty of administrators who run Apache without having profound understanding leaving it to interpret by default mod_rewrite rules from .htaccess files etc.

To fix this issue, hence you have to add extra configuration for AllowOverride directive for directory giving the err. In this case /vea:

<Directory /var/www/vea/> 
Options -Indexes FollowSymLinks
AllowOverride AuthConfig
FileInfo Order allow,deny
Allow from all

Above rules are a bit restrictive and will allow only to have .htaccess with only for protecting directory with htaccess passsword for exmpl. – (AuthUserFile, AuthGroupFile, AuthName, AuthType) .htaccess.
-Indexes – instructs /var/www/vea directory listing to be disabled, below two lines:

Order allow, deny
Allow from all

Makes the directory Allowed to be visible by all, however note that it is possible in some of other Apache configuration files to have other rules configured for /vea documentroot /var/www/ which are preventive (Default Deny) – if this is the case just walk through all Apache configs and change where necessary to Allow from all.

In some cases it is possible Web application or Website placed requires AllowOverride All directive instead. If above <Directory>

does not help and you continue to get:

[Wed Jul 31 03:36:21 2013] [error] [client] client denied by server configuration: /var/www/php-application/index.php, referer:  

Try setting Directory rules with AllowOverride All ;

<Directory /var/www/php-application/> 
Options -Indexes FollowSymLinks
AllowOverride All
FileInfo Order allow,deny
Allow from all

Debian / Ubuntu server admins should check closely for AllowOverride rules in files /etc/apache2/conf.d/*

as well as in /etc/apache2/mods-available/*:

Usually there are AllowOverride rules set from files:


and also in


On Debian GNU / Linux, very common reason for getting client denied by server configuration is AllowOverride definitions in /etc/apache2/conf.d/security, default AllowOverride there are set to None, i.e.:

<Directory />
AllowOverride None
Order Deny,Allow
Deny from all

If that's the case with you make sure you config rules to become:

# <Directory />
# AllowOverride None
# Order Deny,Allow
# Deny from all
# </Directory>

A very useful command to find where there is occurance of AllowOverride in Apache many configs is:

root@linux:~# cd /etc/apache2
root@linux:/etc/apache2# grep -rli AllowOverride *


Once you did all necessary config Restart Apache:

root@linux:~# /etc/init.d/apache2 restart