This is a follow-up from the Essential WordPress Security Tips article.
In general WordPress is pretty secure as long as you apply common
sense and follow standard security practices. The tips mentioned in this
article are for added security (you don’t need to apply them all).
However, if you are in the mood for some advanced tweaking then the following security tips should come in handy
NOTE and DISCLAIMER
Most of these techniques require you to understand what you are doing.
It is strongly recommended that you first test these techniques on a
test or development site before applying them to your live site. Doing
some of the tips suggested here can break your site if not performed
correctly.
We take no responsibility for any mishaps as a result of your efforts in applying the techniques discussed in this article.
Also note that these techniques assume that your WordPress installation is running Apache and you have mod_alias and mod_rewrite installed.
1. Disable HTTP Trace Method
There is a security attack technique called Cross Site Tracing (XST)
which can be used together with another attack mechanism called Cross
Site Scripting (XSS) which exploits systems which have HTTP TRACE
functionality. HTTP TRACE is a default functional feature on most
webservers and is used for things like debugging. Hackers who use XST
will usually steal cookie and other sensitive server information via
header requests.
You can disable the trace functionality either via your Apache
configuration file or by putting the following in your .htaccess file:
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* - [F]
2. Remove header outputs from your WordPress installation
WordPress can often add quite a lot of output in your header
pertaining to various services. The following code shows how you can
remove a lot of this output.
Warning: This
can break some functionality if you are not careful. Eg, if you’re
using RSS feeds then you may want to comment that line out.
Add the following code to your theme’s functions.php file:
remove_action('wp_head', 'index_rel_link');
remove_action('wp_head', 'feed_links', 2);
remove_action('wp_head', 'feed_links_extra', 3);
remove_action('wp_head', 'rsd_link');
remove_action('wp_head', 'wlwmanifest_link');
remove_action('wp_head', 'parent_post_rel_link', 10, 0);
remove_action('wp_head', 'start_post_rel_link', 10, 0);
remove_action('wp_head', 'adjacent_posts_rel_link_wp_head', 10, 0);
remove_action('wp_head', 'wp_generator');
remove_action('wp_head', 'wp_shortlink_wp_head', 10, 0);
remove_action('wp_head', 'noindex', 1);
3. Deny comment posting via proxy server
You can reduce spam and general proxy requests by attempting to
prevent comments which are posted via a proxy server. Use the code below
(compliments of perishablepress.com) in your .htaccess file:
RewriteCond %{REQUEST_METHOD} =POST
RewriteCond %{HTTP:VIA}%{HTTP:FORWARDED}%{HTTP:USERAGENT_VIA}%{HTTP:X_FORWARDED_FOR}%{HTTP:PROXY_CONNECTION} !^$ [OR]
RewriteCond %{HTTP:XPROXY_CONNECTION}%{HTTP:HTTP_PC_REMOTE_ADDR}%{HTTP:HTTP_CLIENT_IP} !^$
RewriteCond %{REQUEST_URI} !^/(wp-login.php|wp-admin/|wp-content/plugins/|wp-includes/).* [NC]
RewriteRule .* - [F,NS,L]
4. Change your default WordPress DB prefix
You may already be aware that WP uses a default prefix value of “wp_”
for the DB tables. This can in turn be used by malicious bots and
hackers to guess your DB table names.
In general, changing your WP DB prefix value is much easier to do at
installation time because you can set it in your wp-config.php file.
Conversely if you already have a live WP site and you wish to change
your DB prefix, then the procedure is a little more complicated.
A basic guide for changing the DB prefix after an install for those who are curious is briefly outlined below:
1) Do a full DB backup and save the backup somewhere offboard. Using something like BackupBuddy can useful.
2) Do a complete dump of your WP DB using PHPMyAdmin into a text file and save 2 copies – one for editing and the other as an original just in case.
3) Using a good code editor, replace all instances of “wp_” with your own prefix.
4) From your WP admin panel, deactivate all plugins
5) Using PHPMyAdmin, drop your old DB and import your new one using the file you edited in step 3.
6) Edit your wp-config.php file with the new DB prefix value.
7) Re-activate your WP plugins
8) Perform another save on your permalink settings by going to Settings->Permalinks in order to refresh your permalink structure.
2) Do a complete dump of your WP DB using PHPMyAdmin into a text file and save 2 copies – one for editing and the other as an original just in case.
3) Using a good code editor, replace all instances of “wp_” with your own prefix.
4) From your WP admin panel, deactivate all plugins
5) Using PHPMyAdmin, drop your old DB and import your new one using the file you edited in step 3.
6) Edit your wp-config.php file with the new DB prefix value.
7) Re-activate your WP plugins
8) Perform another save on your permalink settings by going to Settings->Permalinks in order to refresh your permalink structure.
Caution:
Sometimes plugins add their own prefix after the wordpress prefix where both are identical.
example, you might have a table name from a certain plugin has a name like the following: wp_wp_abc_table_name.
Be sure when replacing the “wp_” instances in step 2 above that you
only replace the first “wp_” prefix and not the one following it.
For instance if we take the example we just mentioned we would replace the first prefix with our new prefix which for this example might be called “trx_”.
For instance if we take the example we just mentioned we would replace the first prefix with our new prefix which for this example might be called “trx_”.
The new name would look like:
trx_wp_abc_tablename
Note that there are also WP plugins out there which can achieve the
above steps for those who are not prepared to get their hands dirty.
5. Deny Potentially Dangerous Query Strings
You can put the following code in your .htacces file to help prevent XSS attacks.
BEWARE: Functionality of some plugins or themes could break if you are not careful to exclude strings which are used by them.
# QUERY STRING EXPLOITS
<IfModule mod_rewrite.c>
RewriteCond %{QUERY_STRING} ../ [NC,OR]
RewriteCond %{QUERY_STRING} boot.ini [NC,OR]
RewriteCond %{QUERY_STRING} tag= [NC,OR]
RewriteCond %{QUERY_STRING} ftp: [NC,OR]
RewriteCond %{QUERY_STRING} http: [NC,OR]
RewriteCond %{QUERY_STRING} https: [NC,OR]
RewriteCond %{QUERY_STRING} mosConfig [NC,OR]
RewriteCond %{QUERY_STRING} ^.*([|]|(|)|<|>|'|"|;|?|*).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%22|%27|%3C|%3E|%5C|%7B|%7C).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%0|%A|%B|%C|%D|%E|%F|127.0).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(globals|encode|config|localhost|loopback).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(request|select|insert|union|declare|drop).* [NC]
RewriteRule ^(.*)$ - [F,L]
</IfModule>
6. Apply PHP hardening to your system
You can install and enable Suhosin which is a PHP
hardening system on your server. This can further increase the security
of your system by protecting against various vulnerabilities.
Suhosin typically installs on most PHP installations and is sometimes
included by webhosting companies by default. (Check with your hosting
provider)
If you can read more about Suhosin here.
Make sure to read the Essential WordPress Security Tips article if you haven’t done so already.
No comments:
Post a Comment