Currently, WordPress accounts for 34.35 % of the TOP 1 million websites using a CMS, over 65% of the CMS market and over 41.9% of the world's websites, and growing, of the world's active websites, almost 12 times more than the next CMS (Shopify) which has 5.6% of the market. This, which in some respects is good news, means that we should be concerned about making our WordPress secure.
Two factors come together: Being the most used CMS, by far, in the market and being an open source platform, and free, with many developers around the world collaborating on the project, programming themes, plugins... This means that we have a lot of information about it, but beware that the same information is also available to friends of the outside 🙁
In addition, its ease of installation means that anyone can set up a WordPress site in less than 15 minutes, almost in the same way as installing an application in Windows, simply by pressing the next button... And this is where the problems come from.
Allow me to go back to the end of the last century, like grandfather onion :).
At that time I was working at Microsoft and version 6.5 of SQL Server was launched, the first really powerful version that the Redmond company had and which was a sales success. Thanks to its simple installation, anyone could have a DB server, well, I still remember from that time the multitude of Web servers in production that you saw configured with the default values of the server administrator (administrator = sa and password blank).
This is related to two of the main security flaws that are often made when installing WordPress: the definition of the password and the definition of the administrator user.
Table of contents
Strongs Passwords.
About 8% of successful attacks on a WordPress site are due to weak passwords.
More than once in a client I've come across passwords like "webname2010+" or similar, or passwords like 12345678 or the date of birth or the name of the latest hero of the latest TV series... or even the word "password" itself. If you want to laugh for a while, or pull your hair out when you discover that you use one of them, at TeamsID you have a ranking of the least secure, and most used, passwords of 2017.
To prevent this, i.e. to prevent your password from being insecure, I propose two solutions:
The easiest way is to generate a secure password from WordPress itself, which already has a strong password generator when you install it or when you create a user from the administration console, but if you don't have it at hand, you can use a website such as Secure Password.
The other solution is to know how secure our password is, i.e. how long it would take a computer to crack it.
For this we can turn to how secure is my password (descontinuado) Password Generator, introducir nuestra contraseña e inmediatamente nos dirá cuánto tardaría un único ordenador en descifrar dicha password. La que yo uso para mi portátil la le costaría a un único ordenador seis años, mientras que la que puse en la administración de mi blog tardaría ¡1 TRILLÓN DE AÑOS!.
But don't be totally optimistic, attacks are usually carried out from hundreds, or thousands, of computers at the same time, so this time would be reduced. Therefore, as in companies, it is advisable to change the administrator's password on a regular basis. And if we don't want to have our passwords written down in a txt file, we can use Lastpass or 1password or BitWarden or another application that will allow us to store all the passwords securely.
That they don't know who your administrator is, or that they find it difficult
The second most common security error concerns the name of the WordPress admin user.
If it is not called admin or any of its variables, that would mean putting a huge sign on our website with the CTA "Hack me", there are methods in which, if we do nothing and leave everything by default, a clever attacker can find out the name of our user without the need for a lot of science.
It would be enough to type "domainname.com/?author=1", or any number until it matches so that, in the case of having configured permalinks in our WordPress, it returns the author's page, something like "domainname.com/username". In this way, we are giving the attacker half the work done, he no longer has to find out the user and can focus on finding out what the password is.
We can prevent this in two ways: By changing the name of the user who publishes the posts so that it is not the same as the one who logs in, or by preventing users from being listed. Either manually or via plugins.
I'm not a big fan of indiscriminate use of plugins and prefer, if it's easy, to use "manual" methods for certain things, but if you're not my type, the plugin options for these defences are called Edit Author Slug,o Stop User Enumeration.
If you prefer to do it without plugins, welcome to my tribe, the thing is simple but you have to have a little bit of idea, at least to know, both the WordPress DB and the wp-config.php file.
You can change the username, or nickname, from your WordPress database. To do this you must access it from phpMyAdmin and then go to the wp_users table (we will talk about the table prefix later).
There you will see the users and you just have to select the field you want to modify, either the user_login or the user_nicename and change it so that they don't match. By the way, the password field that is in between and in which you will see a churro, is the password but it is encoded, someday I will explain you how it works.
A few lines of PHP code in fuctions.php or your custom function plugin is all it takes to disallow the display of your WordPress users based on their ID.
<?php
//Stop User Enumeration
if ( ! is_admin() && isset($_SERVER['REQUEST_URI'])){
if (preg_match('/(wp-comments-post)/', $_SERVER['REQUEST_URI']) === 0 && !empty($_REQUEST['author']) ) {
wp_die('forbidden');
}
}And if you want to remove the Author Pages, the code to insert in functions.php or your custom functions plugin is as follows.
<?php
/* Remove Author pages
Description: Provoca un error 404 cuando se solicita una author page y modifica los enlaces del
autor en los posts para redirigirlos a la home de la web */
function cmdh_remove_author_pages_ page {
if ( is_author() ) {
global $wp_query;
$wp_query->set_404();
status_header( 404 );
}
}
function cmdh_remove-author_pages_link( $content ) {
return get_option( 'none' );
}
add_action( 'template_redirect , 'cmdh_remove_author_pages_ page' );
add_filter( 'author_link' , 'cmdh_remove-author_pages_link' );Don't go yet
Well, we have already secured our user, or users, administrator and our passwords, but is there much more to go?
- Secure and protect access to the administration panel (wp-admin) and to the WordPress configuration (wp-config.php).
- Change the database prefix.
- Schedule a backup system.
- Deactivate the file editor of our WordPress.
- Assign the appropriate permissions to the folders and files on our Web server.
- Add HTTP security headers to our server.
- Set keys and security jumps to strengthen cookies.
- Make your WordPress not look like a WordPress, not like a WordPress, and not like a...
...and of course, as I said in another first post dedicated to WordPress, keep the CMS, themes and plugins updated.
All of this will be discussed in a future article.
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.
