Posts Tagged ‘php file’

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 fix php “Fatal error: Class ‘SimpleXMLElement’ not found” and “Fatal error: Class ‘JLoader’ not found” on FreeBSD

Tuesday, June 21st, 2011

One of the contact forms running on a FreeBSD server configured to work on top of Apache+MySQL suddenly stopped working.

The errors that appeared on the webpage during a page request to the form url was:

Fatal error: Class 'SimpleXMLElement' not found in /var/www/joomla/plugins/system/plugin_googlemap2_helper.php on line 2176 Fatal error: Class 'JLoader' not found in /var/www/joomla/plugins/libraries/loader.php on line 161

As you see in the output the website which was causing the issues was running a Joomla version 1.5.23 Stable configured with RSForm!ver 1.5.x (as a contact form solution) and Google Maps version 2.13b plugins.

The Google Map from Google Maps plugin and the RSform were configured to appear on one physical configured article in Joomla and seemed to work just until now. However yesterday suddenly the error messages:
Fatal error: Class ‘SimpleXMLElement’ not found
Fatal error: Class ‘JLoader’ not found

came out of nothing, it’s really strange as I don’t remember doing any changes to either Joomla or the PHP installation on this server.
There is one more guy who has access to the Joomla installation which I suspect might have changed something in the Joomla, but this scenario is not very likely.

Anyways as the problem was there I had to fix it up. Obviously as the error message Fatal error: Class ‘SimpleXMLElement’ not found reported the server php simplexml was missing!

Just to assure myself the php simplexml extension is not present on the server I used the classical method of setting up a php file with phpinfo(); in it to check all the installed php extensions on the server.

Finally to solve the issue I had to install the module from ports php5-simplexml , e.g.:

freebsd# cd /usr/ports/textproc/php5-simplexml
freebsd# make install clean

Afterwards to make the new settings take place I did restart of my Apache server:

freebsd# /usr/local/etc/rc.d/apache2 restart
Syntax OK
Stopping apache2.
Waiting for PIDS: 63883.
Performing sanity check on apache2 configuration:
Syntax OK
Starting apache2.

Now my Joomla contact form is back to normal 😉

If someone has any idea why this error occured without any php or server modifications, and how comes that all worked fine beforehand even though I did not have the simplexml module instlaled on the server o_O, I would be enormously greatful.

Howto check if mod_rewrite is installed and loaded in Apache 2.x and serving directories correctly

Wednesday, February 10th, 2010

During my professional experience as a system administrator, it was a common misfortune in newly
configured unix servers mod_rewrite not to be serving .htaccess files.
Everytime I had to fix issue in which mod_rewrite was not working I loosed a lot of my precious time
The same story happened once again I had to check why mod_rewrite is not configured correctly and I cannot
apply some redirection rules in WordPress necessery for me
to exercise some SEO on my wordpress blog .
Therefore this time I decided to blog a step by step check on in order to:

1. Determine if mod_rewrite is installed & loaded correctly in Apache
2. Find out if mod_rewrite is configured to serve .htaccess files correctly
Going through this two scenarios I would be able to determine why I cannot get wordpress SEO optimization
mod_rewrite redirection rules to work as they should.
Okay, so let’s go through the two scenarios:

1. Here is a tiny script in PHP to determine if mod_rewrite is installed and loaded in Apache correctly
To use the script save it somewhere in your Domain document root with a .php extension
Here is the code of the script as well:

< ?phpprint_r(apache_get_modules());?>

If your mod_rewrite module is configured correctly you’ll see it in the php array containing
all your apache loaded modules.

Without PHP from the shell in order to get installed Apache modules on Linux, the following command applies:

apache2ctl -t -D DUMP_MODULES

For apache 2.2.x
httpd (or apache.exe) -M will show static and shared modules loaded via LoadModule.
httpd -l will show only static (compiled in) modules

For apache 2.0.x
httpd (apache.exe) -l is available but -M is not.
You will need to manually check the LoadModule directives and the files.

2. Now we continue, further on with another script that has to be installed somewhere in Apache’s DocumentRoot
I decided to install it in a directory /test/ so in my case it’s installed in
Here is a link to the script you need to find out if mod_rewrite is configured to serve .htaccess files for your preferred domain name’s DocumentRoot.

Now save this file and again make sure it has a .php extension.

Now you need to create an .htaccess file in the directory where you have rewrite.php file stored.
The content of the .htaccess file should be the following:

RewriteEngine OnRewriteOptions InheritRewriteRule ^link([^/]*).html$ rewrite.php?link=$1 [L]

Make sure the permissions of the .htaccess are correct, for example the file should have at least read
permissions for your webserver.
So let’s execute:

chmod a+r .htaccess to ensure the newly created file has proper permissions
So let’s check if mod_rewrite is enabled for my domain DocumentRoot by visiting:
this link
Hopefully if all is okay you’ll see:
Congratulations!! You are using Apache mod_rewrite whenever you press the TEST2 link
on the upmentioned webpage.

In case if you get a 404 error message, then most probably you don’t have mod_rewrite configured
to serve .htaccess files for your domain.
This often happens because of missing:
AllowOverride All in your main Directory directives in your webserver configuration file.
In my case I had a problem where mod_rewrite rules were not red from the .htaccess file:
To solve my issue I had to change:

Directory /
AllowOverride None
Order Deny,Allow
Deny from all
in my httpd.conf to

Directory /
AllowOverride All
Order Deny,Allow
Deny from all

So well, That’s all Folks!