In an earlier blog called 12 Simple WordPress Security Tips, we provided some pointers for securing WordPress. In this blog, we cover some more advanced methods for locking down your WordPress website. 

Most involve editing or moving configuration files, either manually or by using plugins. You’ll notice that some plugins address multiple security areas, so when you do your research on which one(s) to use, you may find that one of these plugins can provide all or most of the functionality you need. It’s best to use a minimal number of plugins.

Finally, always make a backup before applying changes, even if you’re testing it out first on your staging/dev site. Ideally, you should have a staging/dev site that is not accessible to the Internet where you can make and test changes before rolling them out to production. The benefit of this is that you can set very stringent access for your production site because dev and backend changes actually happen on the staging/dev site. 

1)    Remove the Wordpress Version string 
Hackers use the WordPress version string to determine whether your website is running a version they can exploit. As with all other security measures, this one action on its own is not enough to protect you from every potential threat. But it’s easy enough to fix, so why not?

The WordPress version number appears in three places:
 

1. The generator meta tag in the header

   1) Example:  <meta name="generator" content="WordPress 4.1" />

   To remove: add this to the functions.php file:
   <?php remove_action(‘wp_head’, ‘wp_generator’); ?>

   2)    The generator tag in RSS feeds.  
   Example: <generator>http://wordpress.org/?v=4.1</generator>

   To remove: add this to the functions.php file:
   function wpbeginner_remove_version() {
   return '';
   }
   add_filter('the_generator', 'wpbeginner_remove_version');

   3)    Query strings on scripts and styles. Some plugins use query strings to carry version information. This is something that’s helpful for the plugin’s developer but not essential to you.
   Example:   subscriptions.css?ver=4.0

   To remove: add this to the functions.php file:

   // Remove query string from static files
   function remove_cssjs_ver( $src ) {
     if( strpos( $src, '?ver=' ) )
    $src = remove_query_arg( 'ver', $src );
    return $src;
   }
   add_filter( 'style_loader_src', 'remove_cssjs_ver', 10, 2 );
   add_filter( 'script_loader_src', 'remove_cssjs_ver', 10, 2 );

   Or use the Remove Query Strings from Static Resources plugin.
    

2. Delete inactive plug-ins and themes

   Because WordPress doesn’t load inactive plugins and themes, these are often overlooked when web admins do their security planning. However, if a theme or plugin remains on the server, it’s still accessible and therefore executable on your server. Remove them and you reduce the risk of hackers exploiting them. In fact, it’s a good policy for all software. Nothing will make you feel worse than getting infected through something you don’t use and totally forgot you had. 
   
   •    Plugins: Many plugins provide an option to uninstall completely. If not, then from the Plugins option on your Admin Dashboard, deactivate any plugins you’re not using (if you haven’t done so already). Then click Delete to uninstall. Sometimes deleting a plugin still leaves entries in the database. If this is a concern, a plugin such as WPDBSpringClean will help you identify and do a thorough cleanup. If you prefer to do this manually, consult the WordPress Codex on Managing Plugins for instructions.
   
   •    Themes: From the Themes option under Appearance, hover your mouse over the theme you want to delete to see Theme Details. Click on Theme Details and at the bottom of the screen, click on the Delete button. 
    

3. Disable Plugin and Theme Editor

   By default the WordPress Dashboard allows editing of plugins and themes. Usually there’s no good reason why users and content editors need to do this. Plus, the Dashboard is the first place hackers head for once they get login access. From here, they can modify code. By disabling the EDIT function, you prevent accidental or malicious changes to plugins and themes. 
   
   Edit the wp-config.php file by adding this line, and the EDIT function is no longer active from the Dashboard:
   define('DISALLOW_FILE_EDIT', true);
    

4. Disable Plugin and Theme Update and Installation

   If malicious users gain login access, you can be sure they will try to upload their own plugin or theme. Block by adding this line to your wp-config.php file 
   define('DISALLOW_FILE_MODS',true);
   
   This disables plugin and theme update and installation, which by default also disables the plugin and theme editor; so if you do this, you don’t need to set DISALLOW_FILE_EDIT (see 3 above).
    

5. Secure wp-config.php

   This file contains critical information about your WordPress website: database settings and connection settings, security keys, table prefix and more. This is where you entered your database details when you installed Wordpress, along with other configuration parameters. It’s a standard filename for all WordPress sites which means hackers know what it’s called and where it lives – so take steps to secure this file.
   
   • Move wp-config.php out of the core WordPress folder. The WordPress Codex recommends moving the file one directory above the WordPress installation. So if you’ve installed WordPress in a folder called /production/home for example, you can store the file as /production/wp-config.php and WordPress will know to look for the file there. So will a good WordPress backup utility. 
   
   • Deny access to wp-config.php. To prevent access, edit the .htaccess file in the WordPress root directory using the following:
   # protect wp-config.php
   <files wp-config.php>
   order deny,allow
   deny from all
   </files>

   NOTE: .htaccess is a configuration file used by Apache-based web servers. It’s short for Hypertext Access and don’t forget the “.” prefix.
   
   •    Set permissions for wp-config.php. Use an FTP client (such as Filezilla), or FTP, or cPanel to login directly to your File Manager and set this file’s permission to either 400 or 440; this prevents all users except for the server from reading it. To learn more about permission modes, see the WordPress Codex on Changing File Permissions.
    

6. Set proper permissions for files

   Your wp-config.php file is only one file within the WordPress hierarchy of files. Lock down all your folders and files so that only the owner can edit/write. If you’re on a shared hosting service, this is even more important. Here are the critical files and WordPress’ recommended permission settings:
   
   •    /wp-admin/ – all files should be writable only by owner
   •    /wp-includes/ – all files should be writable only by owner
   •    /wp-content/themes – all files should be writable only by owner and the web server
   •    /wp-content/plugins – all files should be writable only by owner
   
   Set all folders to 755 or 750 and all files to 644 or 640, except for wp-config.php which should be 440 or 400 (see point 4 above). You can try a plugin such as Bulletproof Security, which includes a feature that checks all your folder and file settings. 
    

7. Protect the admin folder from unauthorized IP addresses

   If you have a static IP address and the only users who edit content or manage the website are in the same office, there’s no reason why any other IP addresses should need access to your admin folder. You can edit the .htaccess file to block any IP addresses that aren’t authorized. You can even include the IP addresses of your remote offices or home offices if they are static.
   
   (If you don’t know your IP address, just visit WhatIsMyIP and/or check with your ISP/hosting service to verify. Also verify whether you have static or dynamic addresses)
   
   Here is an example of lines to add to the.htaccess file. Add/edit the allow statements to include authorized IP addresses (xx.xxx.xxx.xxx):

   AuthUserFile /dev/null
   AuthGroupFile /dev/null
   AuthName “Access Control”
   AuthType Basic
   order deny,allow
   deny from all
   # whitelist home IP address
   allow from xx.xxx.xxx.xxx
   # whitelist work IP addresses
   allow from xx.xxx.xxx.xxx
   allow from xx.xxx.xxx.xxx

   If you find that your IP address is dynamic, then a good option is to lock down more tightly at the login stage. You’ll find suggestions in our earlier blog about WordPress security.
    

8. Change database prefix

   Standard filenames pose security risks. When it comes to the WordPress database, its tables default to standard names with the ‘wp_’ prefix: wp_options, wp_posts, wp_users, etc.  Change the database prefix to something complicated or random. The easiest time to do this is when you install WordPress, by changing the setting for $table_prefix.
   
   For example, if you edit this line in the wp-config.php file

   From:     $table_prefix  = 'wp_'; 
   To:     $table_prefix  = 'ax49if_';

   Your tables will now be created as: ax49if_options, ax49if _posts, ax49if _users, etc.
   
   If you’ve already installed WordPress, you will need to backup and then manually edit a lot of files. Or you can use the WP Security plugin, which will: 
   •    Edit the wp-config.php file as above
   •    Change all your WordPress table names to use the new prefix
   •    Edit relevant entries in the (former) wp_options table
   •    Edit relevant entries in the (former) wp_usermeta file
   
   9)    Prevent directory browsing
   Don’t let outsiders browse your website’s directory structure. If you enter “index of” into a search engine such as Google, you’ll get back results which include entries that look like this: “Index of /”; these are websites whose directories are visible to browse. The fix is simple.
   
   Add this line of code to your .htaccess file:

   Options All -Indexes

9. Change WordPress Security Keys

   WordPress uses security keys for authentication and to encrypt user information such as passwords and session cookies. Out of the box, they work OK. With your customization, they’ll be much stronger.  And it’s easy – all WordPress wants is a long random string to use. Essentially, you are replacing these lines in the wp-config.php file (below) with the ones generated by the WordPress Key Generator. 

   
   define('AUTH_KEY', 'put your unique phrase here');
   define('SECURE_AUTH_KEY', 'put your unique phrase here');
   define('LOGGED_IN_KEY', 'put your unique phrase here');
   define('NONCE_KEY', 'put your unique phrase here');
   define('AUTH_SALT', 'put your unique phrase here');
   define('SECURE_AUTH_SALT', 'put your unique phrase here');
   define('LOGGED_IN_SALT', 'put your unique phrase here');
   define('NONCE_SALT', 'put your unique phrase here');

   When you click on the link to the WordPress Key Generator, it returns text that looks like this, which you can cut and paste:

   define('AUTH_KEY',         '3M.Y4@Tvn;!46vd)k*$nLus,G`A+?J}D$5-/C]^,(<e,Fy^vq[:p,fhUBQLTOot:');
   define('SECURE_AUTH_KEY',  'q>%k=6Cdce%o_^@(qY0|6n&gDYCxTbm|edT.~sK?XoN-aYDcUN4PO?{`(I-5CYu=');
   define('LOGGED_IN_KEY',    'ueddB5|$Wl_xLoHMKSw,wpHf(a#bZb0vR*+y1nd/b@iDT>/e01(ZEBhf>c,a6!#B');
   define('NONCE_KEY',        ':7)*XR~0x.D#o=*-,BT e)yhP+wt.: 5Q-zYv/3^.Lcuzj292hwZ%3hNYw^JA]7;');
   define('AUTH_SALT',        '^ 8cGdmn9<H+z-ZV#yZ*X/1b}9mI#d-ccBx%>a7_B^Vev,A%YC#q1*KbMOizb4eh');
   define('SECURE_AUTH_SALT', 'fNR_|c<I$o*~D[<-5oFg2u5}|!~-_l~i?ol1jb{n|D!.UP(&tcAh+VY EoxqM~tJ');
   define('LOGGED_IN_SALT',   ']!pZBJ8CUq*s};W3#*F$;Y2H|E[Z J<oFrD9Ez%A?15g?mT4qKebjoD!JM,_NCQE');
   define('NONCE_SALT',       '-8kKb16P7DVe*GHWt+p1=X|[HgFt2vD=rW!6#&R#,L2!Zagm9r-6)r$E84X%fq7L');

   You don’t need to remember these keys. They’re used by WordPress. 
   
   If your site gets hacked, it’s highly advisable to invalidate all cookies associated with the site by replacing these keys with fresh ones. This means your users will need to login again because the information saved on their PCs no longer match the hashed encryption keys on the server.

   Most hackers don’t want to spend their time and energy defeating a site that appears to have implemented security measures. They’ll give up and go after the low-hanging fruit, the vulnerable sites that have not implemented basic security. Therefore if you secure your website using some of these tactics, you will be able to deter the majority of attacks. 

   The WordPress Codex contains this article about security, which points out the most common areas of vulnerability in a WordPress website. It also warns that it’s not a comprehensive guide. Every business, website, and IT department has different needs. If you have questions about this article or want to know how Smartt’s hosted web services can be part of your security planning, contact us. We’d be happy to chat.