En la actualidad, WordPress supone un 34.35% en el TOP 1 millón de sitios web que usan un CMS, más de un 65% en el mercado de CMS y más de un 41,9% de los sitios web del mundo, y la cifra sigue creciendo, de los sitios webs que hay activos en el mundo, casi 12 veces más que el siguiente CMS (Shopify) que tiene un 5.6% del mercado. Esto, que en ciertos aspectos es una buena noticia, implica que debamos preocuparnos en hacer nuestro WordPress seguro.
Se juntan dos factores: Ser el CMS más utilizado, con diferencia, del mercado y ser una plataforma de código abierto, y gratuito, con multitud de desarrolladores en todo el mundo colaborando en el proyecto, programando themes, plugins… Esto hace que contemos con multitud de información sobre él, pero cuidado que la misma información también está disponible para los amigos de lo ajeno 🙁
Además, su facilidad de instalación hace que cualquier persona pueda montar en menos de 15 minutos un sitio con WordPress, casi casi de la misma forma que se instala una aplicación en Windows, simplemente pulsando el botón de siguiente… Y de aquí vienen los problemas.
Permitidme que me remonte a finales del pasado siglo, en plan abuelo cebolleta :).
En aquellos momentos trabajaba en Microsoft y se lanzó la versión 6.5 de SQL Server, la primera realmente potente que tenía la compañía de Redmond y que fue un éxito de ventas. Gracias a su sencilla instalación, cualquiera podía tener un servidor de BBDD, pues bien, todavía recuerdo de esa época la multitud de servidores Web en producción que veías configurados con los valores por defecto del administrador del servidor (administrador = sa y password en blanco).
Esto viene a cuento de dos de los principales fallos de seguridad que se suelen cometer cuando se instala un WordPress: la definición de la password y la definición del usuario administrador.
Strongs Passwords o contraseñas seguras.
Cerca del 8% de los ataques con éxito a un sitio de WordPress se deben a passwords débiles.
Más de una vez en un cliente me he encontrado con password del tipo “nombredelaweb2010+” o similares, cuando no passwords del tipo 12345678 o la fecha de nacimiento o el nombre del último héroe de la serie de moda… o incluso la propia palabra «password». Si queréis reíros un rato, o tiraros de los pelos al descubrir que usáis alguna de ellas, en TeamsID tenéis un ranking de las passwords menos seguras, y más usadas, del año 2017.
Para prevenir esto, es decir que tu contraseña sea poco segura, te propongo dos soluciones:
La más sencilla, generar una contraseña segura desde el propio WordPress que ya lleva un generador de strong passwords cuando lo instalas o cuando creas un usuario desde la consola de administración, pero si no lo tienes a mano, puedes usar una Web como Clave Segura.
La otra solución es saber cuánto de segura es nuestra password, es decir cuánto tiempo necesitaría un ordenador para descifrarla.
Para eso podemos acudir a 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!.
Pero que no cunda el optimismo total, normalmente los ataques se realizan desde cientos, o miles, de ordenadores a la vez, con lo que ese tiempo se reduciría. Por ello, como ocurre en las empresas, es recomendable cambiar la contraseña del administrador con cierta regularidad. Y si no queremos tener nuestras contraseña apuntadas en un txt podemos acudir a Lastpass o 1password o BitWarden u otra aplicación que nos permitirá guardar todas las passwords de forma segura.
Que no sepan cual es tu administrador, o que lo tengan difícil
El segundo error de seguridad más común se refiere al nombre del usuario administrador de nuestro WordPress.
Pasando por alto que no se llame admin o alguna de sus variables, eso ya sería poner un cartel enorme en nuestra Web con el CTA “Hackeame”, existen métodos en los que, si no hacemos nada y dejamos todo por defecto, un atacante un poco avispado puede conocer el nombre de nuestro usuario sin necesidad de mucha ciencia.
Bastaría con escribir «nombrededominio.com/?author=1», o cualquier número hasta que coincida para que, en el caso de tener configurados los enlaces permanentes en nuestro WordPress, este devuelva la página del autor, algo del tipo «nombrededominio.com/minombredeusuario». De esta forma, estamos dando al atacante la mitad del trabajo hecho, ya no tiene que averiguar el usuario y se puede centrar en descubrir cuál es la contraseña.
Podemos evitarlo de dos formas: Cambiando el nombre del usuario que publica los post para que no sea el mismo que el que hace login o impidiendo que se puedan enumerar los usuarios. Bien de forma manual, bien mediante plugins.
Soy muy poco amigo del uso indiscriminado de plugins y prefiero, si es sencillo, usar métodos “manuales” para según que cosas, pero si no eres de los míos, las opciones en forma de plugins para estas defensas se llaman Edit Author Slug,o Stop User Enumeration.
Si prefieres hacerlo sin plugins, bienvenido a mi tribu, la cosa es sencilla pero tienes que tener un poco de idea, al menos sonarte, tanto la BBDD de WordPress como el archivo wp-config.php.
Puedes cambiar el nombre de usuario, o el nickname, desde la BBDD de tu WordPress. Para ello deberás acceder a la misma desde phpMyAdmin y una vez ahí ir a la tabla wp_users (del prefijo de la tabla hablaremos después).
Ahí verás los usuarios y bastará con seleccionar el campo que deseas modificar, bien el user_login bien el user_nicename y cambiarlo para que no coincidan. Por cierto, el campo password que está entre medias y en el que veréis un churro, es la contraseña pero está codificada, algún día os explicare como funciona eso.
Para no permitir que se muestren los usuarios de tu WordPress según su identificador basta con unas pocas líneas de código PHP en fuctions.php o tu plugin de funciones personalizadas.
<?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');
}
}Y si lo que deseas es eliminar las Author Pages, el código a insertar en functions.php o tu plugin de funciones personalizadas es el siguiente.
<?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' );No te vayas todavía
Bien, ya hemos securizado nuestro usuario, o usuarios, administrador y nuestras passwords, ¿queda más? pues si mucho más. nos queda todavía:
- Securizar y proteger el acceso al panel de administración (wp-admin) y a la configuración de nuestro WordPress (wp-config.php).
- Cambiar el prefijo de la base de datos.
- Programar un sistema de backups.
- Desactivar el editor de archivos de nuestro WordPress.
- Asignar los permisos adecuados a las carpetas y archivos de nuestro servidor Web.
- Añadir cabeceras de seguridad HTTP a nuestro servidor.
- Establecer las keys y salt de seguridad para fortalecer las cookies.
- Hacer que tu WordPress no parezca un WordPress, y no de pistas..
…y por supuesto, como ya dije en otro primer post dedicado a WordPress, mantener tanto el CMS, como los themes y los plugins actualizados.
De todo ello, hablaremos en un próximo artículo.
