On to the third installment on how to make your WordPress installation secure.
So far we have seen in the first article how to create a secure password and how to make it difficult to know which user is the administrator of your WordPress installation, and in the second article how to protect the wp-admin folder and how to protect one of the most critical files, as far as security is concerned, of any WordPress installation: the wp-config file. As well as certain plugins that can help us to perform these tasks.
This month I am going to be a little lighter and tackle tasks which, although somewhat simpler, are still important and, in many cases, forgotten:
- Modify the prefix of the tables in the WordPress database.
- Disable the WordPress file editor.
- Configure keys and security salts.
Modifying the prefix of tables in the WordPress database
By default when we install WordPress, the prefix of the database tables is "wp_".
If someone wanted to attack a website created with WordPress, the first thing they would try to do is to create a user in the wp_users table and give this user administrator privileges. That's why, if we don't want to make it easy for attackers, we should change the "wp_" prefix to something else.
If we are faced with a new installation, the option is simple: Change this prefix for the one we want.
The problem comes when we already have a website running and this was not done. In this case, we will have to modify the prefixes of the tables and the references to this prefix that are stored in the database. Let's do it.
First of all, create a backup copy of the database. To do this, access phpMyAdmin from your hosting cpanel , select the database you are going to work on and click on the "Export" button that appears in the right panel. This will take you to a page with the export options, which you can leave as default (Quick export method, format: SQL). Click on the "Continue" button and in a few moments, depending on its size, you will have the database downloaded to your computer.
And now to the task. When you were making the backup you will have been able to see, and write down, the prefix of the DB tables. So the first thing you have to do is to modify this prefix in the WordPress installation.
This is very easy, because the CMS saves this information in a single place: the wp-config,php file. Access it via FTP, edit it and look for the following:
/**
* WordPress Database Table prefix.
*
* You can have multiple installations in one database if you give each
* a unique prefix. Only numbers, letters, and underscores please!
*/
$table_prefix = 'wp_';In an installation that has not been modified, you will find this string on line 66 of our wp-config.php, Once located, we change the value "wp_" by the prefix you have chosen, in this article as an example we will use "prefix_".
/**
* WordPress Database Table prefix.
*
* You can have multiple installations in one database if you give each
* a unique prefix. Only numbers, letters, and underscores please!
*/
$table_prefix = 'nuevoprefijo_';
Once you have done this, you will have to access phpMyAdmin again to modify the database prefixes.
WordPress before version 4.4 created 11 tables. From this version onwards it creates an additional table, so you will have to rename at least 12 tables, as you will have been applied and you will have your WordPress up to date. And I say at least because if you have installed plugins that create tables, you must also change the prefix of these additional tables.
To change these prefixes, although you can do it by changing one by one the names of the tables in phpMyAdmin, it is best to do it en bloc using a SQL query. Don't worry, I leave you a guide that will allow you to do it in one go. Remember to change where it says "newprefix_" by the prefix of your choice.
//Si tu WordPress es anterior a la versión 4.4
RENAME TABLE `wp_commentmeta` TO `nuevoprefijo_commentmeta`;
RENAME TABLE `wp_comments` TO `nuevoprefijo_comments`;
RENAME TABLE `wp_links` TO `nuevoprefijo_links`;
RENAME TABLE `wp_options` TO `nuevoprefijo_options`;
RENAME TABLE `wp_postmeta` TO `nuevoprefijo_postmeta`;
RENAME TABLE `wp_posts` TO `nuevoprefijo_posts`;
RENAME TABLE `wp_terms` TO `nuevoprefijo_terms`;
RENAME TABLE `wp_term_relationships` TO `nuevoprefijo_term_relationships`;
RENAME TABLE `wp_term_taxonomy` TO `nuevoprefijo_term_taxonomy`;
RENAME TABLE `wp_usermeta` TO `nuevoprefijo_usermeta`;
RENAME TABLE `wp_users` TO `nuevoprefijo_users`;//Si tu WordPress es versión 4.4 o posterior, deberás renombrar la tabla wp_termmeta
RENAME TABLE `wp_termmeta` TO `nuevoprefijo_termmeta`;And remember that you will also have to rename the rest of the tables that would have been created by the plugins you have installed if they exist.
Once this is done, you have to modify the references to the tables that are stored in the database. Specifically in the following tables: nuevoprefijo_options; nuevoprefijo_usermeta and nuevoprefijo_termmeta (the latter if you have updated your WordPress to version 4.4 or later). To do this, from phpMyAdmin, run the following SQL queries.
SELECT * FROM `nuevoprefijo_options` WHERE `option_name` LIKE '%wp_%' # Para la Tabla nuevoprefijo_options
SELECT * FROM `nuevoprefijo_usermeta` WHERE `meta_key` LIKE '%wp_%' # Para la tabla nuevoprefijo_usermeta
SELECT * FROM `nuevoprefijo_termmeta` WHERE `meta_key` LIKE '%wp_%' # Para la tabla nuevoprefijo_ternmeta (a partir de WordPress 4.4)Each of these queries will return more than one result, so you will need to modify the wp_ value to the new prefix you have chosen.
Deactivate the file editor
Let's go with something that is quick and easy to do, disable the WordPress file editor.
You may have seen it at some point, and you may or may not have dared to use it. I'm talking about the system file editor that comes with WordPress and that you can access through the administrator in the Appearance ⇒ Editormenu.
From this simple editor you can modify the Theme files you have chosen in your WordPress (both css and page templates). Well, if you can modify these files, anyone who has access can also modify them, and I don't mean just anyone who attacks your website, but also someone who is collaborating with you, and they can make a big mess, a really big mess.
The solution is to disable access to this editor and it is done in a very simple way: Opening the wp-config.php file and adding the line below.
/** La siguiente instrucción deshabilita el editor de archivos de WordPress**/
define(‘DISALLOW_FILE_EDIT’, True);And with this you will have disabled the WordPress file editor. As promised, it's very simple.
Configure keys and security salts
WordPress uses eight security keys that prevent, or hinder, access to passwords by robots or programs that try to assault the Web by brute force, also protect access cookies that WordPress generates when a user is identified, are the famous Keys and their corresponding encryption values or salts. And they were added in the following versions:
- WordPress 2.6: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY
- WordPress 2.7: NONCE_KEY
- WordPress 3.0: AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT, NONCE_SALT
These values must be set by the administrator and can be changed as often as you like.
To do this you must access the already mentioned wp-config,php file, maybe now you will understand why I insisted in the previous article that it was a critical file that had to be protected... and look for the following the first time.
/**#@+
* Authentication Unique Keys and Salts.
*
* Change these to different unique phrases!
* You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}
* You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
* * @since 2.6.0
*/
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');
/**#@-
*/As you can see it's very descriptive, in the comments you have the instructions and the url of the key generator provided by WordPress itself to generate a new set of keys/salts
Once you access the generator, simply copy the result and paste it into your wp-config.php, replacing the example code snippet above. It will look something like this:
/**#@+
* Authentication Unique Keys and Salts.
*
* Change these to different unique phrases!
* You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}
* You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
* * @since 2.6.0
*/
define('AUTH_KEY', 'g]-Muu}vU~-LXBc>nLO98S)qWR1w)@tRc;3%QU|1Q6s:*d|np-OyWavP42p=+-h[');
define('SECURE_AUTH_KEY', 'iB1rU4r+yg>8,2|yc{&t4)8i&6{q&BC!wIFNc4xv@!ch#F.>S3Q>G^bSu2l#zNDA');
define('LOGGED_IN_KEY', 'U%m<vKJctbx&UwE+U|cIy]vYkqK?|=;DR[9|%?|/}/_mjAm|buEv8+k%(Bi_+}I4');
define('NONCE_KEY', 'm-sdzgeLvg+?:_F#{Nc.eqeRc6+9V^b-^D .o*CbN!q-WJ&?_-Bn.w`0hZ=b}lUr');
define('AUTH_SALT', '}SBsc:9#Fi@H&4D*iS:<X542.F#2|F@<oQG-p>]6ax]cpMo#|:C_ii{nC<N-oB8/');
define('SECURE_AUTH_SALT', '(5|5$Am-jNOQ/[0iU[Y7v;Cb|XBB!*]1Q`~`8X7+bz=&mh*w[O)4}VG%>6RO;RC+');
define('LOGGED_IN_SALT', '>2Se-K_{hV+q+t4`W>^|*|u8**Z.iV^[MPpz[)FR6OJqwIx 6kWAWC[j.{?;7w*d');
define('NONCE_SALT', '/u50}WYM.wDR-#R`sM_N*dH2Io(_Pi%7JgF%6QR&a9y4JWsHPg T;4-w}!h:yKk#');
/**#@-
*/As I mentioned before, you can do this operation as many times as you want. When you do so, all users who have logged in to your website, and who have activated the "Remember my password" option, will have to log in again.
As a recommendation, change the keys and salts of your #WordpPress regularly, for example every three/six months.
And, of course, never, but never, give these codes to anyone (the example you have in this article is a generation I have made AdHoc, that is to say, they are not those of any Web).
Don't go yet
Well, as I told you, today was going to be light and easy. We're almost done, but we still have the next thing to do:
- Add HTTP security headers to our server.
- Assign the appropriate permissions to the folders and files on our Web server.
- Make your WordPress not look like a WordPress, and not give clues
- Schedule a backup system.
I invite you to leave your impressions and/or doubts in the contact form and to suggest new topics that you would like me to cover in these tutorials. I will be happy to answer you by email and write in this blog.
