Vamos a hablar de seguridad. Concretamente, de seguridad y hardening para WordPress.
Si entras a este artículo buscando plugins mágicos que te ayuden a mejorar la seguridad de tu blog, puedes salir ya. Lo que yo voy a intentar es dar tips rápidos y LÓGICOS acerca de cómo mantener una instalación WordPress segura y sin intrusiones de ningún tipo (ni tampoco infecciones).
Para qué vamos a engañarnos, a medida que la cuota de mercado de WordPress va subiendo, más “maleantes” le buscan las cosquillas al CMS. Por lo tanto, es más fácil que aparezcan más vulnerabilidades (el 34% de los sitios web del mundo utilizan WordPress en el momento de escribir este articulo).
Muchos dicen que WordPress NO es seguro, pero esto realmente es mentira. Simplemente, estamos hablando del CMS más utilizado del mundo y, por lo tanto, es normal que le encuentren más vulnerabilidades. Pero eso no quiere decir que haya más, sino que se encuentran de forma más “fluida” y regular.
Como he dicho antes, en este artículo voy a hablar de los típicos plugins de seguridad lo justo y necesario. Tras 9 años dedicándome a WordPress mi experiencia me dice que mantener un WordPress seguro es cuestión de lógica y prevención más que de avanzados sistemas de seguridad que consumen recursos y hasta nos gastan dinero del bolsillo si los dejamos.
Sin darle más vueltas, vamos al tema que importa. Vamos a ver unos cuantos puntos sobre cómo mantener una buena seguridad en WordPress.
Prevención: la base de la seguridad total de WordPress
He querido poner la PREVENCIÓN como el primer punto, ya que considero que es la base de todo. Un WordPress se mantiene seguro y libre de malware con prevención y lógica. ¡Nada más!
Te voy a explicar a qué me refiero de forma resumida, ya que en los siguientes puntos voy a profundizar más en algunos temas relacionados con la prevención de ciertas acciones.
¿Qué podemos prevenir para evitar un problema en la seguridad de nuestro sitio web?
- No instalar NUNCA themes y plugins de orígenes poco fiables o directamente orígenes “nulled” que FIJO que van a venir con malware. Y cuando digo instalar, me refiero a NI PROBAR un plugin nulled en una instalación en producción.
- Mantener siempre al día las fechas de actualización de WordPress, pero sobretodo de los themes y los plugins. Con esto me refiero también a comprobar si los plugins y el theme se siguen actualizando.
- No utilizar contraseñas débiles, ya que esta negligencia, combinada con tener el wp-admin sin proteger, puede hacer que con un simple ataque de fuerza bruta puedan entrar en tu WordPress y… El resto te lo imaginas.
Estos 3 simples tips de prevención van a ayudarte a mantener tu WordPress seguro en el 90% de los casos, ya que la mayoría de casos de intrusiones e infecciones en sitios WordPress son por alguna de estas tres razones.
Me atrevería a decir que, excepto casos donde la infección o intrusión en WordPress se realiza mediante una vulnerabilidad zero-day, el resto de casos se producen por culpa de uno de estos tres puntos relacionados directamente con la PREVENCIÓN.
Si nos infectan por una vulnerabilidad zero-day antes de que haya salido un “parche” para solucionarla, no lo considero un problema de prevención, ya que no podemos hacer nada. Pero si el parche es liberado y nosotros no actualizamos, eso SÍ que es un problema de prevención.
Fechas de actualización al día y acciones para solucionarlo
Vamos a dar por hecho que WordPress lo tenemos actualizado SÍ o SÍ, ya que los mensajes nos aparecen en el panel de administración de WordPress queramos o no. En algunos casos, pueden incluso auto actualizarse en versiones menores sin que nosotros nos demos cuenta.
Normalmente, todo el mundo recomienda tener todos los plugins y el theme actualizados a la última versión. Yo voy mas allá: te recomiendo directamente REVISAR LAS FECHAS DE ACTUALIZACIÓN de los plugins y del theme.
Con esto, quiero decir que debemos revisar que todos los plugins y el theme tengan actualizaciones al menos de los últimos 6 meses. En caso contrario, puede significar que el desarrollo ha sido descontinuado y que el desarrollador ya no continúa con el proyecto. Y aquí es donde empiezan los problemas de seguridad relacionados con las actualizaciones.
En caso de que un plugin o el theme se deje de actualizar, debemos cambiar ese plugin o el theme cueste lo que cueste cuando hayan pasado 6 u 8 meses desde la última actualización. Cueste lo que cueste.
El hecho de NO actualizar es el PRINCIPAL causante de infección e intrusión, justo por delante de infecciones e intrusiones que se producen por la instalación del plugins y themes nulled con malware.
Actualmente en el repositorio de plugins de WordPress, cuando entramos desde el panel de WordPress, ya no aparecen los plugins que NO están actualizados para las últimas versiones de WordPress. Por el contrario, si entramos desde la web nos muestran este mensaje:
En el caso de plugins Premium, si los compramos en un marketplace como CodeCanyon, lo normal es que directamente eliminen un plugin de sus repositorios cuando lleva mucho tiempo sin actualizarse. Sin embargo, debemos ser nosotros quienes cambiemos el plugin que no se actualiza por otro que sí que se actualice.
Como nota final, simplemente volver a repetir lo mismo que siempre digo: en caso de que un plugin se quede sin actualizaciones, debemos cambiarlo por otro que sí que se actualice SÍ o SÍ y cueste lo que cueste. Y en el caso del theme, igual. Incluso aunque el theme actual tenga modificaciones.
En caso de que tengamos que estar durante un tiempo sin hacer el cambio de plugins o del theme, podemos llegar a subir el nivel de seguridad con un WAF (Web Application Firewall) específico para WordPress implementado mediante plugin. No obstante, esto no nos garantiza la seguridad completa.
Ten en cuenta que cuantos más plugins tengas instalados (aunque no los utilices), más posibilidades tendrás de que un día “pierdas el control” y dejes algún plugin sin actualizar más tiempo de lo debido.
Por esta razón es recomendable tener siempre instalados los plugins indispensables. Y si vas a tener plugins desactivados, es mejor tenerlos desinstalados y así evitar problemas.
Protección contra ataques de fuerza bruta (Brute Force)
Los ataques por fuerza bruta o “Brute Force” contra el login o pantalla de autentificación pueden causarnos dos problemas. Por un lado, pueden entrarnos a nuestro WordPress a través del panel de administración. Por otro lado, un ataque por fuerza bruta puede consumir muchos recursos en el servidor o hosting que aloja la web, llegando incluso a tumbar la web si el ataque es muy fuerte.
En un ataque por fuerza bruta o “Brute Force”, un bot prueba contraseñas una tras otra en el login o autentificación del sitio web.
Si la contraseña que tenemos es muy débil, un ataque de fuerza bruta por diccionario podría darle acceso a un hacker a nuestro sitio web. Como he dicho antes, al probar contraseñas una tras otra se genera un consumo de recursos que puede llegar a tumbarnos la web si el servidor o hosting no lo aguanta.
Existen varias formas de proteger nuestro WordPress contra ataques por fuerza bruta:
- Normalmente, los proveedores de hosting (como nosotros en Raiola Networks) tenemos firewalls instalados como servicio en el servidor que nos permiten detectar “hits” con acceso denegado y bloquear las direcciones IP desde las que se hacen muchos intentos de inicio de sesión. Es la solución más limpia y casi no se consumirán recursos al bloquear usuarios.
- Existen plugins para WordPress para bloquear direcciones IP tras varios intentos de inicio de sesión. Es una solución eficiente a nivel de seguridad y es fácil de configurar, pero se consumirán recursos al bloquear a las direcciones atacantes. También existen plugins para desviar la atención cambiando la URL de login de WordPress: de esta forma, los bots no tendrán objetivo.
En el caso de los servidores, como he dicho, normalmente tenemos un WAF (Web Application Firewall) como modsecurity instalado en el servidor web.
En Raiola Networks, en la plataforma de hosting compartido, utilizamos unas reglas basadas en las de Comodo Security con modificaciones propias que protegen de las amenazas sin que el administrador del sitio web tenga que hacer nada.
Estas reglas no nos permiten cambiar la URL de administrador o login de WordPress, pero sí que nos permiten bloquear ataques de fuerza bruta de forma efectiva y consumiendo los mínimos recursos.
En el caso de utilizar un plugin para WordPress, tenemos dos opciones:
- Utilizar plugins “all in one” o suites de seguridad como iThemes Security, Sucuri Security o WordFence Security, de los cuales no quiero hablar en este artículo.
- Utilizar plugins para funciones específicas. Por ejemplo, uno para cambiar la URL de administrador o login y otro para bloquear ataques por fuerza bruta baneando direcciones IP.
Cambiar la URL de administrador de WordPress
Si queremos despistar a los bots, podemos cambiar la URL del wp-admin y el wp-login.php de WordPress para que, cuando el bot busque el login, no lo encuentre y le salga un error 404 de página no encontrada.
Existen varios plugins para esta tarea. Por un lado, podemos utilizar Perfmatters, ya que esta función se encuentra en su interfaz:
De hecho, si quieres ver un poco más a fondo el plugin Perfmatters para WordPress, puedes ver este vídeo que he colgado en mi canal de Youtube:
Si quieres una alternativa gratuita para hacer esto, yo normalmente utilizo el plugin HC Custom WP-Admin: https://es.wordpress.org/plugins/hc-custom-wp-admin-url/
Como puedes ver en la imagen anterior, el plugin no tiene ciencia alguna. De hecho, utiliza el propio panel de configuración de “Enlaces permanentes” de “Ajustes” de WordPress para añadir su campo de configuración.
El “string” que pongamos en el campo “WP-Admin slug” es el que sustituirá al wp-admin y al wp-login.php de WordPress.
Cada cierto tiempo cambio este plugin por otro, ya que no se suelen actualizar mucho y acaban cayendo en el olvido.
Por si HC Custom WP-Admin URL no te funciona, también confío bastante en WPS Hide Login, ya que el mismo desarrollador tiene una serie de plugins para mejorar la seguridad de WordPress: https://es.wordpress.org/plugins/wps-hide-login/
Como puedes ver, WPS Hide Login también aprovecha la sección de “Ajustes” de WordPress. Concretamente, la sección “General”.
Bloquear ataques de fuerza bruta en WordPress
Existen algunos plugins que detectan cuando un usuario o bot realiza varios intentos de inicio de sesión fallidos en el login de WordPress o en su API y bloquean automáticamente la dirección IP desde la que vienen esos intentos de inicio de sesión.
Evidentemente, el número de intentos de inicio de sesión fallidos hasta el bloqueo tiene que ser configurable. De lo contrario, el propio administrador de la web puede bloquearse a sí mismo al equivocarse con la contraseña de acceso.
Las principales “suites” de seguridad para WordPress, como por ejemplo iThemes Security o WordFence Security, permiten hacer esto. Sin embargo, como antes dije que no iba a hablar de ellas, quiero proponer ciertas alternativas que sirven específicamente para hacer eso: bloquear ataques por fuerza bruta contra el login o autentificacion de WordPress.
De los creadores de WPS Hide Login tenemos el plugin WPS Limit Login que, como su nombre indica, es un limitador de intentos de inicio de sesión.
Podemos encontrarlo de forma completamente gratuita en el repositorio de plugins de WordPress: https://es.wordpress.org/plugins/wps-limit-login/
Como puedes ver en la imagen anterior, en WPS Limit Login podemos personalizar el número de intentos y el periodo de tiempo.
Además, podemos configurar direcciones IP tanto en la whitelist como en la blacklist, es decir, tanto permitir el acceso a direcciones IP como bloquear manualmente direcciones IP:
WPS Limit Login tiene pocas funcionalidades, como puedes ver, pero cuenta con las necesarias para poder bloquear ataques por fuerza bruta contra nuestro login de WordPress.
WAF en WordPress (Web Application Firewall)
Un WAF o Web Application Firewall es un software o servicio que se encarga bloquear ataques contra aplicaciones web.
Es un firewall especializado en aplicaciones web que bloquea tráfico malicioso tras detectarlo usando patrones y reglas previamente definidos.
Un WAF o firewall de aplicación nos permite protegernos de vulnerabilidades que aún no han sido definidas como tal. Con reglas específicas, hasta nos protege totalmente contra ataques directos contra vulnerabilidades zero-day, incluso antes de que salga el parche correspondiente que lo soluciona.
Podemos implementar un WAF de varias formas. Por un lado, los proveedores de hosting y alojamiento web normalmente utilizamos modsecurity en el servicio del servidor web (Apache, Nginx, LiteSpeed, etc.). Por otro lado, para implementar un WAF en WordPress podemos utilizar plugins como WordFence Security o como Ninja Firewall (WP Edition).
Personalmente, considero que la implementación de un WAF en WordPress es una solución solo necesaria cuando ya tenemos previo aviso de un problema de seguridad en nuestra instalación de WordPress.
Sobre todo teniendo en cuenta que nuestro servidor web normalmente ya tiene un WAF con modsecurity (al menos en Raiola Networks tenemos modsecurity con las reglas de Comodo Security personalizadas por nosotros) y que un WAF implementado como plugin para WordPress puede llegar a consumir bastantes recursos en periodos de alta actividad en lo que a vulnerabilidades se refiere.
Si aun así quieres implementar un WAF en WordPress en formato plugin, te animo a que pruebes Ninja Firewall (WP Edition). Aunque ya te aviso que no es fácil de configurar. Puedes encontrar Ninja Firewall (WP Edition) aquí: https://es.wordpress.org/plugins/ninjafirewall/
Aquí tienes un vídeo que he grabado para ti, donde puedes ver cómo configurar NinjaFirewall (WP Edition) en WordPress:
La configuración que has visto en este vídeo es conservadora, es decir, no limita demasiado ni es demasiado específica, ya que de lo contrario podemos tener problemas en algunos casos.
Infecciones e intrusiones por factores externos del administrador
Aunque los factores externos son los que suelen tener menos impacto, hay infecciones e intrusiones que vienen directa o indirectamente dadas por una infección del ordenador del administrador de la web: a esto le llamamos un factor externo.
No quiero meterme en este campo, ya que no tiene nada que ver con WordPress que es de lo que estamos hablando en este artículo.
Con un antivirus o antimalware instalado en cualquier ordenador Windows que utilicemos podemos estar protegidos, aunque aquí es precisamente donde entran los factores relacionados con la prevención otra vez.
Si trabajamos en un ordenador con Macintosh o con Linux, tendremos muchas menos posibilidades de que un keylogger o malware pueda robarnos la contraseña de nuestro WordPress, aunque no es imposible tampoco. Si trabajamos con un ordenador Windows, como he comentado, es necesario tener la protección antivirus actualizada y funcionando correctamente.
En el caso de Windows, actualmente no es ninguna excusa el precio de un antivirus, ya que existen excelentes soluciones antimalware gratuitas como Karspersky Free.
Por otro lado, también debemos tener cuidado con las redes WIFI públicas abiertas, ya que pueden “trackear” nuestro tráfico e interceptar nuestras contraseñas. De hecho, yo personalmente siempre utilizo la red de datos 4G de mi móvil compartiendo la red con mi portátil, para evitar las redes de los hoteles que pueden estar monitorizadas.
Proteger WordPress del SPAM en formularios y comentarios
El SPAM es algo común actualmente. En el momento en que tienes un sitio web (sea cual sea el CMS) con tráfico y sin ningún tipo de protección, te va a entrar SPAM hasta por las orejas.
El spam en WordPress suele aparecer en dos sitios: comentarios y formularios de contacto.
Yo personalmente era fan de Disqus Comment System como sistema de comentarios para WordPress, precisamente porque me permite olvidarme del spam, aunque eso ha cambiado.
Además de eso, siempre recomiendo la instalación del plugin Honeypot Anti-Spam para WordPress porque es simple, gratuito y no tiene ni configuración: https://es.wordpress.org/plugins/honeypot-antispam/
Existen otras soluciones antispam para WordPress, como AntiSpam Bee o Akismet, que vienen con la instalación predeterminada de WordPress y están desarrollados por Automattic. Algunos administradores de sitios web incluso utilizan captchas para protegerse contra el spam, aunque debemos tener en cuenta que esto también dificulta la experiencia del usuario.
¿Cuáles son los efectos del SPAM? Pues depende del caso:
- El SPAM en formularios de contacto puede llenarnos de mierda la bandeja de entrada de nuestro email y, en algunos casos extremos y en función de las combinaciones, puede llegar a darnos problemas con bloqueos de IPs e inclusiones en listas de spammers.
- El SPAM en comentarios puede darnos problemas con el SEO del sitio web en caso de que estos comentarios lleguen a publicarse en nuestro blog o web.
Además de estos dos ejemplos de efectos, debemos tener en cuenta que un sistema anti-spam que no esté automatizado puede darnos mucho trabajo en sitios web con mucho tráfico. Esto se debe a que normalmente el spam lo hacen bots y un bot puede subirnos fácilmente entre 5 y 100 comentarios por minuto dependiendo de nuestro plan de hosting o servidor y de la potencia que tenga.
Los backups o copias de seguridad son amigas de tu WordPress
Como he dicho al principio, en caso de una vulnerabilidad zero-day, si nos infectan o tenemos una intrusión en nuestro WordPress antes de que se publique un parche para solucionar la vulnerabilidad, no podremos hacer nada. Nuestra única solución será restaurar una copia de seguridad o backup y…. ahí es donde aparece la necesidad de realizar backups continuos programados.
Existen dos formas de tener continuamente backups o copias de seguridad en WordPress:
- En el hosting o servidor puede haber un sistema de backups para las webs alojadas. En el caso del hosting compartido esto es algo común. En el caso de servidores VPS o servidores dedicados, podemos solicitar que nos instalen un sistema o instalarlo nosotros. La idea es tener backups programados diarios.
- Mediante plugins para WordPress podemos tener un sistema de backups potente que nos haga copias de seguridad continuas programadas y automáticas de nuestro WordPress e incluso que automáticamente suba el backup a un servicio externo como Dropbox o Google Drive.
Sobre el tema de configurar backups en el hosting o servidor no voy a decir nada. Solo quiero añadir que en Raiola Networks, en hosting compartido, disponemos de dos líneas de backups. Por un lado, ofrecemos el sistema de backups de Installatron. Por otro lado, tenemos un sistema automatizado con backups incrementales llamado JetBackup.
En cuanto a la posibilidad de implementar backups automatizados y programados con un plugin para WordPress, a mí personalmente me gustan dos plugins en sus modalidades gratuitas: BackWPup y UpDraftPlus. Ambos nos permiten programar copias de seguridad en WordPress e incluso subirlas automáticamente a servicios externos.
En el siguiente vídeo que he grabado para ti puedes ver cómo configurar copias de seguridad externas programadas con BackWPup para WordPress:
La configuración de UpdraftPlus es más o menos igual. La principal diferencia es que con la versión gratuita de BackWPup podremos realizar backups a Dropbox y con la versión gratuita de UpdraftPlus podremos realizar backups a Google Drive.
Tweaks para hacer WordPress más seguro
Vamos a identificar como “tweaks” ciertas “microacciones” que podemos realizar para mejorar la seguridad de nuestro WordPress.
Estas acciones podemos realizarlas todas o solo algunas, ya que unas son más efectivas que otras.
Cambiar el prefijo de la base de datos de WordPress
Quiero mencionar esto porque en caso de inyección SQL puede afectarnos si tenemos el prefijo por defecto “wp_” en nuestra base de datos de WordPress.
Lo que sí que debemos tener en cuenta es que, para que nos realicen una inyección SQL en nuestro sitio web WordPress, previamente debemos tener una vulnerabilidad. Por lo tanto, cambiar el prefijo de la base de datos es una prevención “de segundo nivel”.
Podemos cambiar el prefijo de la DB MySQL de WordPress durante la instalación del CMS. En caso de que ya tengamos WordPress instalado, podemos cambiarlo manualmente con cambios en la DB MySQL y con cambios en el wp-config.php de WordPress.
El proceso para cambiar el prefijo de la base de datos manualmente en WordPress es bastante lío si no tienes conocimientos sobre la DB de WordPress. Por esa razón, puedes utilizar un plugin para hacer esto.
El plugin Brozzme DB Prefix puede ayudarte a cambiar el prefijo de la base de datos MySQL de tu WordPress: https://es.wordpress.org/plugins/brozzme-db-prefix-change/
En el siguiente vídeo puedes ver cómo cambiar el prefijo de la DB MySQL de tu WordPress utilizando el plugin Brozzme DB Prefix:
Como ves, el proceso utilizando un plugin es mucho más fácil de realizar que manualmente, por lo que es ideal para usuarios sin conocimientos avanzados.
También existen algunas “suites” de seguridad para WordPress en formato plugin como Sucuri Security o iThemes Security que incluyen esta opción como parte de la securización de la instalación de WordPress.
Permisos de archivos y carpetas en WordPress
Los permisos CHMOD de Linux son los grandes desconocidos por la mayoría de administradores de sitios web WordPress y diseñadores web que trabajan con WordPress, ya que no conocen el sistema operativo Linux bajo el que operan la mayoría de los servidores web.
Aunque mucha gente utiliza los permisos CHMOD 777 sin sentido (a pesar de que pueda dar lugar a problemas de seguridad importantes), realmente existen unos permisos que debemos configurar con la consola de Linux o con el cliente FTP:
- Permisos 755 para las carpetas de la instalación de WordPress.
- Permisos 644 para los archivos de la instalación de WordPress.
Si quisiéramos añadir algo de seguridad, podríamos incluso darle permisos 600 al wp-config.php para evitar ediciones indeseadas del archivo y configurar permisos 604 para el archivo .htaccess.
También podríamos mejorar la seguridad de los archivos de WordPress con dos líneas que podemos añadir al archivo wp-config.php de WordPress.
Por un lado, podemos evitar que desde el panel de control de WordPress puedan instalarse o desinstalarse plugins con este código en el wp-config.php de WordPress:
| 1 | define(‘DISALLOW_FILE_MODS’,true); |
Y también podemos evitar que desde el panel de control de WordPress se pueda utilizar el editor de código para modificar el código de themes y plugins. Para ello, debemos utilizar el siguiente código en el functions.php del theme activo:
| 1 | define(‘DISALLOW_FILE_EDIT’, true); |
Con esto ya tendremos los archivos y carpetas protegidos. Salvo que exista algún otro problema en el hosting o aparezca algún tipo de vulnerabilidad en el código del theme o de los plugins, no podrán modificar el código de nuestro sitio web.
Deshabilitar la función XML-RPC Pingback de WordPress
Odio la funcionalidad XML-RPC de WordPress. Funciona con el archivo xml-rpc.php, que está presente en toda instalación de WordPress.
Desde hace algún tiempo, la funcionalidad XML-RPC es objetivo de distintos tipos de ataques que pueden llegar a tirarnos la web mediante ataques de denegación de servicio o de fuerza bruta.
Esta funcionalidad sirve como interfaz o API para aplicaciones externas que quieran interactuar con una instalación de WordPress. Sin embargo,con el API REST disponible actualmente para esto, no se suele utilizar el XML-RPC y este es solo un problema de seguridad.
Actualmente ya no se producen tantos ataques de este tipo, además de que WordPress se ha actualizado para protegerse al menos parcialmente contra este tipo de ataques.
La mayoría de “suites” de seguridad para WordPress como WordFence Security o Sucuri Security llevan integrada la funcionalidad para protegerse de ataques contra esta funcionalidad. No obstante, también existen plugins que nos permiten desactivar el XML-RPC para evitar que nos puedan atacar desde ahí: https://es.wordpress.org/plugins/disable-xml-rpc-pingback/
No mostrar la versión de WordPress
De forma nativa, WordPress muestra la versión en el código generado y enviado al navegador web del visitante.
Si queremos que los visitantes no vean esto, debemos evitar que se envíe la versión de WordPress en el código.
Simplemente añadiendo un código al archivo functions.php de WordPress podemos ocultar esta información:
| 1 2 3 4 | function version_wp() { return ''; } add_filter('the_generator', 'version_wp'); |
Si no sabemos hacer esto o no queremos meter código personalizado porque no usamos un tema hijo, podemos utilizar un plugin (aunque considero que no es necesario para esto): https://es.wordpress.org/plugins/remove-version-info/
Con el plugin Perfmatters que tanto me gusta también podremos ocultar esta información.
Hay algo más que debemos hacer: borrar el archivo readme.html que hay en la raíz de la instalación de WordPress.
Herramientas de escaneo de vulnerabilidades en WordPress
Existen varias herramientas que nos permiten realizar un escaneo de nuestro sitio web desde fuera para encontrar vulnerabilidades en el código de los plugins y los themes instalados, incluso en el núcleo de WordPress.
Estas herramientas no sirven para encontrar vulnerabilidades nuevas, sino para detectar vulnerabilidades que ya han sido publicadas oficialmente y que normalmente ya están solucionadas (a menos que el componente en cuestión ya no se encuentre en desarrollo).
WP Scan como escaner de vulnerabilidades de WordPress
Esta es la primera herramienta que quiero comentar: es la más potente a mi entender, pero también la más compleja.
WP Scan requiere instalarse en un equipo Macintosh o Linux, ya que es una herramienta en línea de comandos desarrollada en Ruby.
Para detectar vulnerabilidades, WP Scan utiliza la base de datos WPVULNDB, que creo que es la base de datos de vulnerabilidades para WordPress más completa y actualizada que existe: https://wpvulndb.com/
WPScans, servicio online para escanear WordPress
WPScans es más fácil de utilizar que WP Scan, aunque también es menos potente.
Se trata de un escáner online que, simplemente metiéndole la URL del sitio web que queramos analizar, nos da ciertos datos.
Yo no lo suelo utilizar, pero es la mejor herramienta de este tipo que me he encontrado. Cuanto menos, es la que ofrece más información centrada en WordPress y no general.
El problema que me he encontrado al escribir este artículo es que detecta mal la versión de WordPress utilizada, ya que se basa en algunos parámetros como el contenido del archivo readme.html y estos archivos pueden no actualizarse al cambiar la versión de WordPress.
Puedes encontrar más información sobre la herramienta en su sitio web: https://wpscans.com/
¿HTTPS? ¿SSL?
De esto directamente no voy a hablar. ¿La razón? Considero que actualmente es INDISPENSABLE tener un certificado SSL en tu sitio web para disponer de HTTP/2.
Además, ya no hay excusa porque existen los certificados SSL gratuitos Let’s Encrypt.
La mayoría de proveedores, como nosotros en Raiola Networks, ya ofrecemos Let’s Encrypt en TODOS nuestros servicios, ya que disponer de un certificado SSL es necesario actualmente para el SEO de nuestro sitio web.
No voy a hablar de las ventajas que ofrece HTTPS de cara a la seguridad en la comunicación entre el visitante y el servidor, ya que todas las conexiones son cifradas. Solo quiero recordar y volver a recordar, que el HTTPS no es opcional. Es igual de necesario que la DB MySQL de un WordPress.
Suites de seguridad para WordPress
Como he dicho al principio del artículo, NO quiero hablar de plugins. Sin embargo, no puedo omitir que existen varias “suites” de seguridad completas para WordPress que tengo que mencionar.
Bien, pues aquí va, quiero mencionar estos plugins: WordFence Security, iThemes Security, Sucuri Security y All in One SEO Pack.
Pero no quiero entrar en materia en ellos, ya que no los considero indispensables.
¿Quieres
recibir mis articulos?
No te pierdas todos mis trucos para WordPress, CMS, Marketing Digital y WPO.
23 Responses
Hola Álvaro!! Me lei de “pe a pa” el artículo y claro me surgieron curiosidades según fue leyendo 🙂
1. Hablas de tener una contraseña potente para los ataque de fuerza bruta pero yo la suelo cambiar cada 3 meses ¿Hago bien o estoy perdiendo el tiempo?
— Por otro lado hay momentos en los que la empresa de Hosting que tengo contratada (Raiola en mi caso) me piden credenciales, lo que hice fue crearles un usuario con perfil de administrador, aquí suelo cambiar la contraseña cada vez que me la piden por paranolla ¿Es tontería o hago bien?
2. En la parte de ataque de fuerza bruta hablas que Raiola ya trabaja para intentar evitar esos casos (no lo sabía) por lo que actualmente tengo instalado el plugin “Limit Login Attempts Reloaded” ¿Recomiendas tenerlo también o con la tecnología usada en Raiola llega?
Por el resto me quedó muy claro 🙂
Un saludo,
Alex Castro Valín.
Buenas Alejandro, voy a ver si puedo contestarte a cada cuestión explicandome lo mejor posible.
1 – Haces bien, es una medida de seguridad extra, aunque personalmente la considero “nivel paranoia”, ya que si tu contraseña es fuerte, existen mas posibilidades de que te entren por cualquier otro sitio como expongo en el articulo.
También haces bien creando un usuario especifico para todo tipo de desarrolladores que tengan que entrar a tu sitio web, y en este caso si que haces bien en cambiar la password cada vez que das acceso.
2 – En Raiola Networks bloqueamos ataques, pero si quieres ver tu mismo los bloqueos, puedes dejar instalado el plugin Limit Login Attemps Reloaded. Yo personalmente nunca lo instalo, aunque suelo hablar de este tipo de plugins cuando hablo de seguridad para WordPress.
Hola Álvaro!! Me lei de “pe a pa” el artículo y claro me surgieron curiosidades según fue leyendo 🙂
1. Hablas de tener una contraseña potente para los ataque de fuerza bruta pero yo la suelo cambiar cada 3 meses ¿Hago bien o estoy perdiendo el tiempo?
— Por otro lado hay momentos en los que la empresa de Hosting que tengo contratada (Raiola en mi caso) me piden credenciales, lo que hice fue crearles un usuario con perfil de administrador, aquí suelo cambiar la contraseña cada vez que me la piden por paranolla ¿Es tontería o hago bien?
2. En la parte de ataque de fuerza bruta hablas que Raiola ya trabaja para intentar evitar esos casos (no lo sabía) por lo que actualmente tengo instalado el plugin “Limit Login Attempts Reloaded” ¿Recomiendas tenerlo también o con la tecnología usada en Raiola llega?
Por el resto me quedó muy claro 🙂
Un saludo,
Alex Castro Valín.
Buenas Alejandro, voy a ver si puedo contestarte a cada cuestión explicandome lo mejor posible.
1 – Haces bien, es una medida de seguridad extra, aunque personalmente la considero “nivel paranoia”, ya que si tu contraseña es fuerte, existen mas posibilidades de que te entren por cualquier otro sitio como expongo en el articulo.
También haces bien creando un usuario especifico para todo tipo de desarrolladores que tengan que entrar a tu sitio web, y en este caso si que haces bien en cambiar la password cada vez que das acceso.
2 – En Raiola Networks bloqueamos ataques, pero si quieres ver tu mismo los bloqueos, puedes dejar instalado el plugin Limit Login Attemps Reloaded. Yo personalmente nunca lo instalo, aunque suelo hablar de este tipo de plugins cuando hablo de seguridad para WordPress.
¡Hola! Una duda, ¿y contra los ataques de tráfico Referral que aumentan la tasa de rebote?
Pues…hay dos cosas que puedes hacer.
Si lo que quieres es que no aumente la tasa de rebote, debes añadir en Google Analytics los dominios desde los que te atacan.
Ademas de eso, también puedes usar alguno de estos plugins que “dicen” que ayudan: https://es.wordpress.org/pl…
Por otro lado…meter esos dominios en disavow por si alguno fuera generando alguna URL tampoco estaría de mas, aunque esto ya no afecta a la tasa de rebote.
Un saludo y espero haberte ayudado.
Hola Álvaro! Soy web developer desde hace ya algunos años, y de casualidad me topé con tu blog.
La verdad quedé fascinado con lo útil del artículo, sobre todo por que estoy empezando a desarrollar sitios para mí mismo, y a medida que crece el tráfico, pues crecen los problemas con el spam y los bots.
Muchas gracias por tomarte el tiempo y dedicación de escribir sobre este y otros temas de Wordpress. Mi equipo y yo te lo agradecemos infinitamente.
Gracias!!
Muchas gracias por tus palabras Hernán, me alegro de que te sirva 🙂
Muy interesante aunque estaba buscando justamente la parte de permisos y usuarios. He escuchado que las carpetas de wordpress deberian pertenecer al usuario Linux y solo dejar a alguna como wp-content a www-data / httpd
Hola, depende del servidor web y la de la forma de ejecutar PHP que tengas, no existe una respuesta exacta, depende de la configuración.
Hola, Álvaro. Muy buen post.
Una pregunta. ¿Crees que cloudFlare añade seguridad extra a un sitio web?
Gracias.
Hola Carlos, CloudFlare en sus versiones de pago añade bastante seguridad contra ataques externos, pero…esa seguridad también la puede ofrecer el hosting fácilmente.
¿La diferencia? Que a ciertos niveles, un ataque de determinado tipo (como por ejemplo de fuerza bruta) puede llegar a tocarte mucho las narices, ya no por la intrusion, sino por el consumo de recursos que eso conlleva, y con CloudFlare te olvidas de eso porque se encargan ellos.
Por otro lado, a la hora de bloquear ataques CloudFlare es la ostia, date cuenta que tienen una de las redes anycast mas potentes que existen actualmente y que se dedican precisamente a eso, la mitigacion de ataques, el CDN es algo que ofrecen porque… pues porque pueden y ya tienen la infraestructura lista para hacerlo.
Todo el mundo conoce CloudFlare por el CDN, y….su CDN y sus DNS son buenas, pero realmente viven de la seguridad, cuando alguien tiene una web grande bajo ataque, CloudFlare junto con Incapsula y alguna mas como Sucuri, son de los pocos que pueden mitigar problemas de este tipo…
Un saludo.
Tío, muchas gracias por tu respuesta.
Me dedico al SEO pero la seguridad y optimización en wordpress es uno de mis puntos flacos. Tu blog es cojonudo para aprender sobre estos temas.
Respecto a cloudFlare, siempre lo he usado para mí y para mis clientes, y sabía sobre sus bondades en cuanto a rendimiento, pero no sabía si en seguridad era realmente efectivo.
Aunque la verdad es que mis cuentas son gratuitas y según dices, las opciones efectivas en seguridad están en las cuentas de pago ¿Verdad?
Bueno, igualmente, gracias por la info.
En las gratuitas vas a encontrar lo básico, y aunque en las gratuitas pueden pararte un DDOS, pueden pedirte que pases a premium.
Yo la verdad, es que cuando trabajo con CloudFlare como CDN, lo uso con CNAMEs o subdominios, es decir, sin pasar el principal por el CDN, solo los subdominios de contenido.
Es decir, lo configuro como si fuera un CDN normal, entonces no uso las funcionalidades de seguridad.
Un saludo.
Mil gracias de nuevo, Álvaro 🙂
A ver como te lo digo… Estás en mis favoritos y de ahí no te mueves 😀
Bromas aparte, es un gran artículo. De obligada lectura para todo el que empieza a usar wordpress con un mínimo de seriedad. Incluso los experimentados pueden sacarle buen provecho.
Te has ganado a un nuevo lector recurrente a tu blog, y no es algo que haga a menudo.
Hola Guillermo, muchas gracias por tus palabras 🙂
Álvaro, muy buen artículo me ha ayudado mucho a mejorar la seguridad de mi wordpress. Like!
Saludos.
Muchas gracias por tus palabras Ruben, me alegro de que te sirva 🙂
Hola Alvaro:
Tengo una duda. Uso Yoast para el SEO en WP y Woocomerce y he creado la metadescription y titulos de cada sección y el buscador de google no aparecen actualizados¿ Porque pasa eso? o ¿como puedo conseguir que se vean actualizados?.
Un saludo,
Lucas
Hola Lucas, te voy a dar una mala noticia…aunque nosotros le especifiquemos a Google esos datos, Google hace y coge lo que quiere… es decir, puede tardar días o meses en actualizar esos metadatos, o puede no hacerlo nunca. Ellos mismos dicen en su documentación, que son campos orientativos para ellos, pero no impositivos.
Buenas Álvaro, estoy revisando mis plugins y veo que el “Editor clásico” para volver Wordpress a su modo clásico, lleva 9 meses sin actualizase.
¿ Conoces algún otro plugin que realice bien esta función y se actualice de forma más periódica ?
¿Aconseja usar este tipo de pulgin?
Gracias
Hola Javier, es un plugin oficial y simple, no debería tener problema. Es simplemente una función.