A día de hoy WordPress sigue sin ofrecer una protección contra ataques de fuerza bruta al panel de administración. Solo si se instala JetPack lo incorpora. No obstante es recomendable ponerselo lo más complicado posible a quién quiera acceder a la administración de un WordPress.
Lo primero: No usar nunca como usuario administrador el usuario admin. Ni tampoco publicar entradas con el usuario administrador que hayamos creado en vez del usuario admin. Siempre hay que usuario usuarios con permisos de editor o inferiores para publicar contenidos. No queremos que nadie conozca el usuario que puede administrar el blog. De esta forma ya complicaremos algo un ataque de fuerza bruta.
Una opción que también se debe utilizar si no usamos JetPack o cualquiera de los plugins de seguridad que incorporan un sistema que impide ataques de fuerza bruta (WordFence, iThemes Security formerly Better WP Security, etc) es el plugin Limit Login Attempts de Johan Eenfeldt. Aunque no se ha actualizado en 4 años sigue funcionando perfectamente (ahora hay una versión más nueva basada en este plugin llamado: Limit Login Attempts Reloaded que estamos probando ahora mismo).
Y además de estas opciones lo que estamos haciendo en todos los WordPress que instalamos es proteger la carpeta /wp-admin/ con una contraseña a nivel de servidor.
Como proteger una carpeta en un servidor Linux
Esta protección es bastante sencilla de realizar. En Plesk y CPANEL se puede proteger directamente desde el panel de administración del servidor.
Sino se puede utilizar una herramienta como el Htpasswd Generator de Andreas Gehrke que con un usuario y una contraseña crea el contenido del archivo .htpasswd con el usuario y la contraseña encriptada. Este archivo lo llama el archivo .htaccess especial que creamos dentro de /wp-admin/ y solo permite acceder a usuarios con credenciales.
Protección de /wp-admin/: Problema con admin-ajax.php
Pero hay un pequeño problema con este tema: Y es que en /wp-admin/ hay un archivo llamado admin-ajax.php que muchos temas de WordPress con soporte de Ajax usan cuando muestran la web. Y si bloqueamos todo el contenido de /wp-admin/ a los usuarios al cargar la página se les pide usuario y contraseña para ejecutar el AJAX. Por tanto hay que excluirlo.
Hay otra gente que dice que también se debería de excluir el archivo admin-post.php pero esto es un tema que no tengo claro y que nunca excluyo. Más que nada porque WordPress dentro del Codex en el apartado Brute Force Attacks solo menciona que hay que excluir admin-ajax.php de la protección. No obstante si que me gusta también dejar acceso a los archivos CSS, gif, png, jpg y js de la carpeta. Por si acaso.
Contenido del archivo .htaccess para poner en /wp-admin/
Por tanto el contenido del archivo .htaccess que ponemos en la carpeta /wp-admin/ quedaría así (con el añadido de la protección de los archivo que empiezan por .ht):
AuthType Basic AuthName "Acceso restringido" AuthUserFile .htpasswd Require valid-user # Allow access to wp-admin/admin-ajax.php and wp-admin/admin-post.php <Files admin-ajax.php> Order allow,deny Allow from all Satisfy any </Files> <Files admin-post.php> Order allow,deny Allow from all Satisfy any </Files> # Allow access to css, gif, png, jpg and js files <Files "\.(css|gif|png|jpg|js)$"> Order allow,deny Allow from all Satisfy any </Files> # Stop Apache from serving .ht* files <Files ~ "^\.ht"> Order allow,deny Deny from all </Files>
OJO: La ruta al archivo .htpasswd la tenéis que personalizar. Más que nada nos interesa que esté fuera de los archivos accesibles directamente a través de Internet (carpeta httpdocs en Plesk). Por ejemplo en Plesk solemos poner el archivo un nivel por encima de la carpeta httpdocs y entonces la ruta al AuthUserFile sería: AuthUserFile /var/www/vhosts/NOMBREDOMINIO.EXTENSION/.htpasswd y habría que cambiar NOMBREDOMINIO.EXTENSION por el nombre de dominio donde está el /wp-admin/ que se quiere proteger.
Quedaría así:
AuthType Basic AuthName "Acceso restringido" AuthUserFile /var/www/vhosts/NOMBREDOMINIO.EXTENSION/.htpasswd Require valid-user # Allow access to wp-admin/admin-ajax.php and wp-admin/admin-post.php <Files admin-ajax.php> Order allow,deny Allow from all Satisfy any </Files> <Files admin-post.php> Order allow,deny Allow from all Satisfy any </Files> # Allow access to css, gif, png, jpg and js files <Files "\.(css|gif|png|jpg|js)$"> Order allow,deny Allow from all Satisfy any </Files> # Stop Apache from serving .ht* files <Files ~ "^\.ht"> Order allow,deny Deny from all </Files>
OJO: Si Apache no encuentra el archivo con los usuarios y contraseñas en la ruta indicada, dará un error de servidor 500, pero no dirá que no encuentra el archivo, simplemente da un error de servidor. Si os pasa esto revisar la ruta al archivo.
Como siempre espero que le sirva a alguien.
🙂
Creo que dar una opción, tal ves no sea la mas optima pero podría ayudar en cuanto aumentar la seguridad de un sitio web en wordpress. con esto no quiero que paresa spam pero por lo regular lo que yo utilizo es utilizar un plugin llamado itheme security llevo usando varios años este plugin y aun que talves puede haber otro que sea mas efectivo es el que por el momento me ha servido, en este plugin tiene la opcion de poder cambiar la ruta de acceso a nuestro seccion de logeo, por ejemplo midomino.com/wp-admin o midomino.com/wp-login a un ruta que nosotros especifiquemos, un ejemplo de ello seria: midominio.com/tuacceso el cual sola mente en esa ruta te permitira acceder a la seccion de logeo y si colocas algunas de las rutas anteriores como midomino.com/wp-admin o midomino.com/wp-login no te dejara logearte.
Muy buenas. Utilizar un plugin de seguridad siempre es recomendable. Aunque muchas veces (dependiendo del hosting) puede ralentizar mucho la web si no está bien configurado y además hay hostings que directamente prohiben el uso de ese tipo de plugins (por ejemplo el hosting de Envato/ThemeForest).
Probablemente escriba otro post sobre el tema, pero nosotros siempre usamos la combinación de:
En aquellas webs alojadas en hostings no potentes siempre usamos:
Volviendo al tema de cambiar la URL de acceso a la administración: Yo no la cambiaría porque desde hace tiempo en nuestras instalaciones los ataques no vienen a través de la URL de acceso a la administración. Teniendo instalado: Limit Login Attempts o Jetpack by WordPress.com de Automattic / WordPress se puede evitar casi por completo, sino a través de la REST API o de accesos a
xmlrpc.php. Pero cualquier acción que incremente la seguridad es siempre bienvenido.