Do You Need WordPress Security Hardening?

One common and recurring client oversight PINT has encountered throughout our 20 years of website development is lack of server security. It may sound like a dry topic, but this costly mistake causes a lot of headaches.

When a server gets owned by a hacker and infected with malicious software, there are many possible outcomes. Sometimes these attacks take shape as mass emails sent out to an entire database of contacts, which spreads the malware further. Other times, the server itself becomes a weapon that can be used by hackers during DDoS attacks. Most hackers are not as interested in your personal details or passwords so much as they are firepower for doing damage and getting bigger results with little or no accountability (unless they want to take credit).

These hackers are looking for “low hanging fruit” to build up their computing power. But even in cases where not much happens, the feeling of intrusion still stings.

In almost every case where customers have come to us with compromised servers, one attack surface found far too often having a high degree of vulnerability is an unmaintained WordPress blog or website. So let’s try to get ahead of this potential fire.

3 Steps for WordPress Security

An initial approach involves isolating the WordPress blog/site on its own virtual machine or server. This is especially true when WordPress is being used as a blog and integrated with a website. This way if the blog is compromised, it does not affect anything else on the site.

With this or any approach to a more secure site, someone needs to be responsible for ensuring the core WordPress software is updated along with any plugins. It is important to designate someone for this task, because the updates can be released at any time and usually require a manual process to complete. In cases where WP installation has been customized, updates may cause bugs or even break the site. To avoid these bugs, some people avoid running the updates. This creates the first “crack” or surface for an attack vector.

But these cracks can be sealed up. Recommendations for how to “harden” the security of a WordPress site can be found all over the web including on the WordPress site itself: http://codex.wordpress.org/Hardening_WordPress.

At PINT, we’ve isolated our own company blogs in the same way we recommend for our clients. However, it is worthwhile to take a closer look at additional security hardening efforts and some of the possible outcomes of implementing the proposed measures.

1. Securing wp-admin

The default admin login url for WordPress is http://xxxxxx.com/wp-admin.

The CNN Business blog appears to be using a hosted version of WordPress, with the default login.

Leaving this login configured with the default essentially allows a person or bot to come right up to your front door and begin picking the lock. Renaming this can essentially move or hide that door creating at least an initial barrier or deterrent. A search for “wp-admin” when logged into the backend of WordPress under plugins < add new < search yielded several plugins providing the functionality to change the default wp-admin url.

HC Custom WP-Admin URL was simple and worked well for the sites on a LAMP stack.

However, you may find an interesting issue crops up when this plugin is installed on certain sites. The plugin may add/duplicate some lines in the .htaccess file that prevent you from logging in at the newly-set url. This can be fixed by manually removing the duplicates in the .htaccess file. Here is the code prior to the fix:

#<IfModule mod_rewrite.c>   #RewriteEngine On   #RewriteBase /blog/   #RewriteCond %{REQUEST_FILENAME} !-f   #RewriteCond %{REQUEST_FILENAME} !-d   #RewriteRule . /blog/index.php [L]  #</IfModule>

# BEGIN WordPress

<IfModule mod_rewrite.c>  RewriteEngine On  RewriteBase /blog/  RewriteRule ^index\.php$ – [L]  RewriteRule ^x-admin-url/?$ /blog/wp-login.php [QSA,L]  RewriteCond %{REQUEST_FILENAME} !-f  RewriteCond %{REQUEST_FILENAME} !-d  RewriteRule . /blog/index.php [L]  </IfModule>

# END WordPress

For the rarer occurrence of sites running on IIS, a different plugin is needed, since there is no built in URL rewrite. For this, you can use Lockdown WP (doesn’t touch .htaccess):

http://wordpress.org/extend/plugins/lockdown-wp-admin/

If running IIS is an issue, ServerMask can be used to camouflage the server.

2. Remove “wp” from file names

Another tactic you can try is renaming and changing “wp” in file names, so they are no longer human or computer detectable. Some attackers may look at a website’s source code to determine which tools or CMSs (like WordPress) are being used.

Considering bots and browser tools (BuiltWith, Wappalyzer, Chrome Sniffer, etc.) can be deployed to detect such things, it makes sense to try and mask the use of WordPress.

Renaming the wp-content folder can mask most of the “wp” that appeared in the source. This can be accomplished through the following steps:

i) Copy “wp-content” folder and rename.

ii) Edit “wp-config.php” and add these lines near the bottom before this line:

require_once(ABSPATH . ‘wp-settings.php’);

Use the folder name you renamed wp-content in step 1.

 define (‘WP_CONTENT_FOLDERNAME’, ‘x-content’);   define(‘WP_CONTENT_DIR’, $_SERVER[‘DOCUMENT_ROOT’].’/x-content’);   define (‘WP_CONTENT_URL’, ‘http://blog.xxxxxx.com/x-content’);   define (‘WP_PLUGIN_DIR’, WP_CONTENT_DIR . ‘/plugins’);   define (‘WP_PLUGIN_URL’, WP_CONTENT_URL.’/plugins’);

3. Move the themes folder

This can prove to be a bit more challenging than you might expect. Simply moving the folder might seem like an easy way to remove additional “wp” references from many of the filenames, based on the path. Unfortunately, you can not directly move the themes folder. That is because its path is hardcoded relatively to the wp-content folder as:

$theme_root = WP_CONTENT_DIR . ‘/themes’;

For more on this see: http://codex.wordpress.org/Editing_wp-config.php#Moving_themes_folder

However, all the other theme references can be removed manually, verified by viewing the source, as follows:

i) Fix header and footer templates by switching hrefs in the themes editor to use the folder you renamed in step 1.

i.e. <a href=”http://www.xxxxxx.com/”><img src=”/x-content/themes/newx/images/logo_x.gif” width=”136″ height=”54″ alt=”xxxxxxxxxx” /></a>

ii) Restart IIS or Apache

This is further verified by the WordPress logo disappearing from Chrome Sniffer and Wappalyzer no longer detecting WordPress either.

This Stack Exchange post was used for reference:  http://wordpress.stackexchange.com/questions/1507/steps-to-take-to-hide-the-fact-a-site-is-using-wordpress/1509#1509

Note: There was one instance that it seems you cannot to change manually:

http://blog.xxxxxx.com/content/themes/foldername/style.less.css?ver=3.5.1 (modified)

This seems to be injected via the wp_head() function.

Regardless, the outcomes from these tactics show promise. Tactics can be considered successful when front-end tools used for detection and/or even a manual view-source no longer reveal that WordPress is in use for the sites/blogs.

What does it all mean?

Is the process of security hardening as important as the attitude or philosophy that drives the reasoning for implementing security protocols? A good mantra to roughly follow is “No information disclosed, no input or user trusted.” Both the philosophy and processes are important, but the tactics employed are only as good as the people that employ them.

We outlined some cursory methods for putting up some fences around a potentially high-risk and commonly targeted web security vulnerability. The security by obscurity counter argument is always presented after discussing tips like these: will hiding the use of WordPress help patch any existing holes in security? Certainly not. But the likelihood of being on a list of hack targets is much lower if your implementation is not obvious.

Additional safeguards are available, too. Our sister company Port80 Software specializes in web security, so if this topic interests you, please check out their blog.

Share With Us (Please, won’t somebody think of the children?)

We’d love to hear about your experience with WordPress security concerns and solutions, since WordPress is the most widely distributed and used open source blog/CMS tool at the moment. The more information we share, the better chance we have of evolving a more safe and secure web for the future.