Manual de SEGURIDAD para WordPress 2022

Aprende todo lo que necesitas saber sobre la seguridad de WordPress y cómo proteger eficazmente tus sitios web de WordPress de los ataques de hackers.

Bienvenido al manual de seguridad de WordPress 2021. Intentaré enseñarte cómo proteger eficazmente tus sitios web de WordPress de actores maliciosos y hackers. Conocer la seguridad de WordPress y saber cómo protegerte a ti mismo y a tus clientes de actores maliciosos, hace que tu trabajo sea mucho más tranquilo.

Este manual no es sólo una guía práctica. También trato de darte una visión general de todo lo importante cuando se trata de la seguridad de WordPress. En primer lugar, te guiaré por los tipos de ataques más comunes de los que tienes que proteger tus sitios web de WordPress. Después repasaremos el alojamiento, las copias de seguridad, las actualizaciones, el HTTPS y otros temas que te harán mucho menos vulnerable a esos ataques.

Si has encontrado algo que falta en este manual de seguridad de WordPress, déjalo en los comentarios debajo del post. Ahora vamos a empezar.



Introducción al manual de seguridad de WordPress

WordPress es el CMS más utilizado del mundo. En julio de 2021 alrededor de 42% de todos los sitios web en Internet utilizan WordPress como base. La popularidad de WordPress lo convierte en un objetivo atractivo para los hackers de sombrero negro. Si encontraran una vulnerabilidad en una versión del núcleo de WordPress bastante reciente, podrían dirigirse a 10 o incluso 100 millones de sitios web. Se puede hacer dinero. Las estadísticas de Internet sobre sitios web pirateados en tiempo real, que se pueden ver en , ilustran la magnitud del problema.Sin embargo, el núcleo de WordPress en sí mismo no es una gran preocupación para nosotros la mayor parte del tiempo. Es lo que está debajo de WordPress y lo que se construye sobre él. Si el servidor web subyacente es vulnerable, el sitio web de WordPress en la parte superior podría estar en peligro también. Lo mismo ocurre con los plugins y temas vulnerables y cómo está configurado.

No hay manera de estar completamente a salvo de los ciberataques. Esto es cierto para cada pieza de software. Sin embargo, algunas normas y convenciones te ayudan a proteger tu sitio web de WordPress de la mayoría de los ataques. Eso es lo que te voy a mostrar en este manual.



Tipos comunes de ataques / Aprendiendo sobre ataques

Déjame mostrarte contra qué tratamos de proteger nuestros sitios web antes de aprender a salvaguardar tus sitios web de WordPress. Con este conocimiento, tendrás una idea mucho mejor de qué procedimientos tomar cuando se trata de problemas de seguridad. Así que no te saltes esta parte!

Esta no es una lista completa de todos los posibles tipos de ataques de hacking, sino los más extendidos que se realizan, que tú como desarrollador de WordPress debes conocer.



Ataques XSS

Si los atacantes pueden inyectar scripts maliciosos en un sitio web, pueden realizar los llamados ataques de Cross-Site Scripting (XSS). Los atacantes pueden entonces robar información de la sesión o realizar peticiones en nombre del usuario.


¿Qué son los scripts en un sitio web?

Cuando hablamos de scripts en un sitio web, normalmente nos referimos a JavaScript en el documento HTML. Con JavaScript, se puede ejecutar la lógica en el navegador del cliente. Por ejemplo, el editor de bloques de WordPress está escrito principalmente en JavaScript.


Los ataques XSS pueden ser especialmente críticos si el objetivo tiene derechos de administrador en el sitio web. El atacante podría entonces tomar el control de todo el sitio web de varias maneras.

Los ataques XSS se evitan mediante la sanitización y el escape.

La sanitización es el proceso de eliminar <> y cosas peligrosas de los scripts o HTML de la entrada del usuario antes de que se introduzca en una base de datos.

Así es como se vería el JavaScript antes de la sanitización:

<script>
 alert("Hola mundo");
</script>

 

 

Se convierte en esto después de la sanitización:

&lt;script&gt;
 alert(&quot;Hola mundo&quot;);
&lt;/script&gt; 

 

 

Ahora, se puede inyectar de forma segura en un sitio web sin que ningún navegador lo ejecute.

Como segunda medida, sin embargo, los datos también deben ser escapados antes de inyectarlos en el HTML. La explicación del Manual de temas de WordPress es la que mejor define el escape:

“Escapar es el proceso de asegurar la salida despojando los datos no deseados, como etiquetas HTML o script mal formados, evitando que estos datos sean vistos como código.”

Encuentra una explicación más detallada y general de XSS en la web de OWASP.



Ataques de XSS

Cada vez que se hace una petición HTTP a un servidor, se realiza algo en él. Por ejemplo, al visitar esta entrada del blog, has dado instrucciones al servidor para que obtenga la entrada de la base de datos y la ensamble en un documento HTML válido (olvidémonos de la caché por un momento). Este tipo de peticiones son las llamadas peticiones no destructivas. No cambian nada.

Pero también hay peticiones HTTP con/destructivas que puedes hacer y que pueden crear, cambiar o borrar datos. Por ejemplo, si creas una entrada de blog en el backend de WordPress y haces clic en guardar, envías una petición HTTP al servidor para guardar la entrada en la base de datos. O si haces clic en el botón “Eliminar”, envías una petición HTTP para borrarlo de la base de datos.

Ahora, normalmente, estos puntos finales están protegidos de peticiones no autenticadas y no autorizadas. Hay que iniciar sesión, por ejemplo, para realizarlas.

Supongamos que eres un administrador de un blog, y que tienes derecho a eliminar entradas del blog. ¿Qué pasaría si te enviara un enlace que, si lo pulsaras, enviara dicha solicitud de borrado a tu sitio web?

Eso se consideraría una versión muy simplificada del llamado ataque de falsificación de solicitud de sitio cruzado (CSRF). Los atacantes manipulan a sus víctimas para que hagan algo que ellos quieren que hagan.

Los nonces te ayudan a protegerte contra los ataques CSRF. Son claves aleatorias que se generan y se anexan a los enlaces o formularios que realizan una acción. Sólo funcionan una vez, y luego se genera una nueva. Si el nonce no está presente o no es válido, la solicitud es rechazada.

Tomemos como ejemplo el botón de purga de caché en la barra superior de mi backend de WordPress.

Este botón enlaza con la siguiente URL:

https://omniploy.com/wp-admin/index.php
?nginx_helper_action=purge
&nginx_helper_urls=all
&_wpnonce=4b4sh4x6bd

He colocado los parámetros en líneas separadas para facilitar su lectura. Normalmente, todo esto está en una sola línea.

Esta URL incluye el nonce al final. Eso significa que sólo puedo realizar la petición con este enlace una vez ya que el nonce sólo es válido una vez.

Si alguien intentara engañarme para realizar una purga de caché, necesitaría conocer un nonce válido, de lo contrario, la solicitud sería rechazada, incluso si he iniciado sesión.

Lo mismo ocurre con los formularios. El nonce está allí normalmente inyectado como un campo oculto. Un ejemplo del formulario de edición de perfil en el backend de WordPress:

¡

 

<! -- ... -->
 <form id="tu-perfil" action="https://omniploy.com/wpadmin/profile.php" method="post" novalidate="novalidate">
   <input type="hidden" id="_wpnonce" name="_wpnonce" value="391e11d52e">
   ¡<! -- ... -->

 

 

Si alguna vez encuentras un endpoint que realiza alguna acción destructiva inmediatamente al ser solicitado y no requiere un nonce, infórmalo a los desarrolladores. De lo contrario, te arriesgas a ser engañado para realizar involuntariamente una acción que no quieres.

Encuentra una explicación más detallada de los ataques CSRF en Wikipedia.



Inyección SQL

La instalación de WordPress utiliza SQL como lenguaje para comunicarse con su base de datos. Por cada cambio en un post, página, etc. se realiza una consulta SQL. Unas veces para leer algo de la base de datos y otras para escribir algo en ella. Ahora bien, sería muy malo que alguien no autorizado pudiera realizar dicha consulta SQL sin control.

Si un atacante fuera capaz de inyectar SQL sin validar, se llama un ataque de inyección SQL.

Una consulta SQL bastante común tiene el siguiente aspecto:

INSERT INTO users (firstname, lastname, email, ...)
VALUES ("John", "Doe", "john@doe.com", ...);

 

 

Insertar una entrada de usuario sin sanearla correctamente puede acabar mal.

Ahora qué pasaría si alguien introdujera el siguiente valor en el campo nombre:

“); DELETE FROM users; —

Este ejemplo llevaría a un borrado completo de la tabla “usuarios” si el valor no fuera saneado:

INSERT INTO users (firstname, lastname, email, ...)
VALUES (""); DELETE FROM users; -- ", "Doe", "john@doe.com", ...);

 

 

Como resultado, la entrada del usuario es desinfectada de las consultas SQL antes de que se ejecute la consulta, lo mismo que ocurre con el peligroso JavaScript. Así se evitan los ataques de inyección SQL.

Más información sobre inyección SQL en el sitio web de W3Schools.



Ataques de fuerza bruta

En un ataque de fuerza bruta, un actor malicioso intenta adivinar una contraseña probando muchas candidatas para una cuenta en particular. Los atacantes suelen utilizar bases de datos de contraseñas con contraseñas comunes, por lo que también se denominan ataques de diccionario.

 

Sin límites en los intentos de inicio de sesión (o Captchas en el formulario de inicio de sesión), un atacante podría probar potencialmente miles de contraseñas en cuestión de segundos.

Por eso es importante utilizar contraseñas fuertes, que no se relacionen con usted de ninguna manera. Nada de cumpleaños o nombres de hijos en la contraseña. Sólo caracteres o palabras al azar. Los atacantes podrían realizar fácilmente ataques de diccionario personalizados.

También deberías comprobar si tus contraseñas están en algún tipo de base de datos de contraseñas. Esto se puede comprobar en la base de datos Pwned Passwords de Have I Been Pwned, por ejemplo. Muchos gestores de contraseñas también admiten comprobaciones de este tipo de forma inmediata.

Más información sobre ataques de fuerza bruta en Wikipedia.



Ataques hombre en el medio (MITM)

Los ataques man-in-the-middle, o también llamados ataques monkey-in-the-middle, son ataques en los que el atacante se coloca entre el cliente y el servidor. Esto puede hacerse de múltiples maneras. Por ejemplo, a través de un switch, gateway o cualquier otro nodo entre el servidor y el cliente.


 

Los ataques man-in-the-middle son la razón, por la que hoy en día utilizamos conexiones cifradas. HTTPS asegura el cifrado de extremo a extremo para evitar que cualquier actor en el medio de leer a lo largo.

Más información sobre Ataques man-in-the-middle en Wikipedia.



Ataques de denegación de servicio (DoS)

Los ataques de denegación de servicio tienen el objetivo de hacer caer su sitio web de WordPress para negar el acceso a otros visitantes. Los ataques DoS se llevan a cabo abrumando su servidor con peticiones hasta que ya no puede manejar ninguna otra petición.


 

Cloudflare tiene un gran post sobre los ataques DoS de Slowloris que explica bastante bien el concepto.



Ataques de denegación de servicio distribuidos (DDos)

Los ataques DDoS son como los ataques DoS normales, pero con potencia de cálculo distribuida. En lugar de que un ordenador intente hacer caer el servidor, lo hace un conjunto de ordenadores. El número de nodos controlados puede variar desde unos pocos hasta 1000s o 100.000s.


 

Las grandes empresas se enfrentan regularmente a grandes campañas DDoS contra ellas.



Ingeniería social

La ingeniería social significa manipular a alguien o a todo un grupo para que haga algo que el atacante quiere que haga. La ingeniería social se practica a menudo en combinación con ataques XSS o CSRF.

Considere un correo electrónico de phishing de PayPal que le pide que confirme su contraseña o algo similar. Quieren que vayas a alguna página de inicio de sesión falsa y que introduzcas tus credenciales. Si introduces tus credenciales, has sido objeto de ingeniería social. Los hackers pescan las credenciales de inicio de sesión, de ahí que también se llamen ataques de phishing.

Las campañas sofisticadas de ingeniería social suelen dirigirse a personas influyentes. Administradores o usuarios con muchos privilegios. Cuanto más poder se tenga (por ejemplo, administrando sitios web) más hay que cuidarse de ser engañado.

Más información sobre ingeniería social en este post de imperva.



Ataques a la cadena de suministro

Otro tipo de ataque a veces practicado en el entorno de WordPress es tomar la infraestructura de actualización de un plugin, por ejemplo. También se llama ataque a la cadena de suministro. Esto se puede hacer comprando un plugin a otro desarrollador o hackeando la cuenta del desarrollador.

 

Por eso es tan importante elegir plugins de desarrolladores reputados. Cuando se instala una actualización de un plugin, básicamente reemplaza los archivos fuente del antiguo plugin por los nuevos. Es decir, una actualización de un plugin puede contener cualquier código fuente que el desarrollador quiera poner, incluyendo código fuente malicioso.

Los recientes ataques de SolarWinds también fueron ataques a la cadena de suministro.

Más información sobre ataques a la cadena de suministro en Wikipedia.



Hackear software desactualizado

El hackeo de software obsoleto es probablemente el tipo más común de vulnerabilidad de seguridad de WordPress. Los plugins, temas, o incluso el software del servidor subyacente contienen vulnerabilidades de seguridad públicamente conocidas que han sido parcheadas en versiones más recientes. Si el software (plugins, temas, software de servidor) no se actualiza regularmente, estas vulnerabilidades no se parchean. Por lo tanto, te hace vulnerable.

Más información sobre las actualizaciones más adelante en esta guía.



Ataques de vulnerabilidad de día cero

Las vulnerabilidades de día cero son fallos que aún no han sido descubiertos por el desarrollador o el público. Un ataque de día cero se produce cuando un actor malicioso descubre una vulnerabilidad y la explota en lugar de informar al desarrollador.

Los ataques de día cero no son tan comunes en los sitios web de WordPress más pequeños. Suelen dirigirse a los “peces gordos”. Esto se debe a que encontrar vulnerabilidades de día cero es difícil y costoso. Al atacante le interesa mantener una vulnerabilidad de día cero el mayor tiempo posible sin que el público la conozca. Pero cuanto más se explote una vulnerabilidad, más posibilidades tendrá de ser detectada y parcheada.

Más información sobre vulnerabilidades de día cero en Wikipedia.



Proveedores-de-alojamiento-en-el-contexto-de-seguridad-de-WordPress

Los proveedores de hosting son una de las partes más críticas cuando se habla de seguridad en WordPress. Puedes invertir todo el tiempo y dinero que quieras en hacer que WordPress y todos los plugins sean lo más seguros posible, si la infraestructura subyacente está comprometida.



Tipos de hosting

Hay diferentes tipos de hosting entre los que puedes elegir. Cuál es el mejor para ti, depende de tu presupuesto y del tiempo que quieras invertir en el mantenimiento.



Hosting gestionado de WordPress

Un proveedor de alojamiento gestionado de WordPress es la opción más cara, pero también con el equipo más dedicado a WordPress. También suelen proporcionar herramientas y sistemas específicos para WordPress, como procesos de actualización automática extendidos, WAFs (Web Application Firewalls – más adelante se hablará de ello), entornos de staging y mucho más.

Ejemplos:



Hospedaje gestionado-general

Son proveedores de alojamiento que no se centran exclusivamente en WordPress. Suelen ofrecer una interfaz de gestión como cPanel y te permiten instalar un montón de tipos de sistemas diferentes. Si eliges este tipo de alojamiento, debes prestar mucha atención a la seguridad. Muchos de estos proveedores de hosting son lentos con las actualizaciones de los servidores, y no queremos que haya vulnerabilidades ya parcheadas sin parchear en nuestro servidor.

Ejemplos:



Hosting dedicado / VPS

Un servidor físico dedicado o virtual privado (VPS) es un servidor físico (o virtual) en algún lugar de un centro de datos que puedes alquilar y hacer lo que quieras. Tienes que instalar un sistema operativo, el software necesario para hacer funcionar un servidor web, y tienes que mantenerlo en el futuro.

Esta es la opción de más bajo nivel a la hora de montar un hosting, además de comprar servidores físicos y construir la infraestructura in situ.

También hay soluciones de VPS gestionados. Esto es como el alojamiento compartido, pero sin compartir tu servidor con otros. El proveedor de alojamiento se encarga del sistema operativo subyacente y del software necesario en un servidor web.

Ejemplos:



Hosting en la nube

El alojamiento en la nube es como el alojamiento dedicado pero con la diferencia de que sólo pagas por los recursos que utilizas. Usted puede escalar fácilmente en los momentos de mayor demanda y escalar hacia abajo cuando los recursos no son necesarios. Sin embargo, esto tiene un coste adicional. Los recursos en la nube son, en comparación con los servidores dedicados o VPS, relativamente caros.

Gracias a la infraestructura virtual, las diferencias entre el alojamiento dedicado y el alojamiento en la nube se están reduciendo. Muchos proveedores de alojamiento proporcionan ambos, y a veces se puede cambiar entre ellos con un solo clic o sólo unos pocos pasos.

Ejemplos:



Tiempo de actividad

El tiempo de actividad debe ser al menos del 99%. El tiempo de inactividad del sitio web es malo para el SEO, la experiencia del usuario y los ingresos.

El SEO es especialmente crítico para los sitios web que obtienen la mayor parte de su tráfico de Google. Google utiliza el tiempo de inactividad como un factor de clasificación. Dependen de que estés ahí cuando te envíen tráfico. Estar fuera de servicio varias veces al año puede dañar su clasificación en el motor de búsqueda a largo plazo.

Para las tiendas de comercio electrónico, esto podría ser aún más perjudicial. Cada minuto que una tienda está caída, no se pueden hacer pedidos.

Compruebe que su proveedor de alojamiento es transparente con los tiempos de inactividad. Suelen tener una página de estado con el tiempo de actividad. Ahí puedes comprobar qué ha estado caído y cuándo.

Comprueba la página de estado de WPMU DEV como ejemplo.



Software actualizado

Tu proveedor de alojamiento (o tú si te alojas tú mismo) debería instalar regularmente actualizaciones de software y reemplazar el software antiguo y obsoleto que ya no recibe actualizaciones. PHP, MySQL o MariaDB y tu sistema operativo. Todo necesita actualizaciones regularmente.



Protocolos de seguridad

Tu proveedor de hosting debe contar con sólidos protocolos de prevención para evitar ataques en primer lugar, pero también con un plan de respuesta a incidentes. Tiene que saberlo todo cuando se produzca una violación de datos y también informar a sus usuarios. Estás obligado a hacerlo, así que no te lo saltes si alguna vez te enfrentas a ello



Las copias de seguridad en el contexto de seguridad de WordPress

¿Has tenido alguna vez una situación en la que hayas borrado o perdido datos accidentalmente? Te imaginas qué pasa si pierdes la web de un cliente en directo? ¿Qué harías?

En el contexto de la seguridad de WordPress, hacemos copias de seguridad para el peor de los casos. Por ejemplo, si los datos son encriptados por un atacante o si se borra todo.

Perder los datos es una de las peores cosas que te pueden pasar. Te perjudica a ti, a tu cliente y además es bastante poco profesional. El primer plugin que deberías instalar en cualquier sitio web nuevo de WordPress es un plugin de copia de seguridad si no tienes ninguna estrategia en el lado del alojamiento para las copias de seguridad.

Probablemente querrás utilizar un plugin automatizado o una solución de copia de seguridad de alojamiento si quieres hacer copias de seguridad de forma regular. La mayoría de los proveedores de alojamiento ofrecen algún tipo de herramienta de copia de seguridad para sus sitios web de WordPress. Si no, puedes optar por un plugin.

Dependiendo de la frecuencia con la que cambias algo en un sitio web, el intervalo para las copias de seguridad puede variar. Si publicas mucho en tu sitio, yo recomendaría una copia de seguridad diaria de la base de datos y una copia de seguridad de los archivos cada semana (excepto si trabajas mucho con medios de comunicación. Entonces también puedes ir con una copia de seguridad diaria para los archivos).



Copias-de-sitio

Las copias de seguridad in situ son aquellas que se mantienen en el sitio, como en el servidor web o en un almacenamiento al que se puede acceder de forma remota.

Las copias de seguridad in situ son rápidas para la recuperación ya que se puede acceder directamente a la copia de seguridad. Las copias de seguridad in situ deben crearse en intervalos más regulares que las copias de seguridad externas.

Incluso si crea copias de seguridad in situ, debería crear copias de seguridad externas.



Copias-de-sitio

El sistema de copias de seguridad no tiene acceso directo a las copias de seguridad externas. Se almacenan fuera del sitio y las copias de seguridad no se pueden restaurar directamente. Antes de poder restaurar, debe obtener activamente la copia de seguridad de algún lugar (por ejemplo, un disco duro externo) y ponerla en el sistema al que desea restaurar.

Si ya tiene copias de seguridad in situ, debería seguir creando copias de seguridad externas a intervalos regulares. De este modo, siempre tendrá copias de seguridad disponibles incluso si se da el peor de los casos y las copias de seguridad in situ se ven comprometidas.



Complementos de copia de seguridad

Hay muchos plugins de copia de seguridad que puedes utilizar para hacer una copia de seguridad de tu sitio web de WordPress.

Aquí tienes una lista con los más populares:

Todos ellos hacen más o menos lo mismo. Hacer una copia de seguridad de los archivos y de la base de datos. Puedes configurarlos en base a tus necesidades.

Sin embargo, ten en cuenta que si tu sitio se hace demasiado grande (en términos de espacio utilizado) el proceso de copia de seguridad puede reducir drásticamente la velocidad de tu sitio web y tomar mucho tiempo para hacer una copia de seguridad. Si ese es el caso, yo recomendaría ir con una solución sólida en el sitio de alojamiento.



Copias de seguridad del hosting

La mayoría de los servicios de alojamiento gestionado de WordPress proporcionan algún tipo de solución de copia de seguridad del lado del alojamiento. Dependiendo del proveedor, puede configurar copias de seguridad para el sitio web completo, la base de datos, los archivos o incluso el servidor completo.

Los proveedores de alojamiento que no se especializan en WordPress, generalmente también tienen opciones de copias de seguridad.

Aquí algunos proveedores de hosting con grandes soluciones de copias de seguridad:



Prueba de integridad de las copias de seguridad

También deberías hacer restauraciones periódicas en un entorno de pruebas para verificar la integridad de tus copias de seguridad, cada pocos meses aproximadamente.

Mejor aún, integra las copias de seguridad en tu ciclo de desarrollo. No mueva los archivos y las bases de datos manualmente cuando pase de dev a live o a staging. Utiliza las copias de seguridad en su lugar. De esta manera siempre sabrás que las copias de seguridad son consistentes.



Actualizaciones en el contexto de seguridad de WordPress

Mantener tus sitios web de WordPress actualizados es una de las cosas más críticas que puedes hacer para evitar que tu sitio sea hackeado.

El software nunca es perfecto. Los desarrolladores de renombre se esfuerzan por mantener el software tan libre de vulnerabilidades como sea posible. Sin embargo, a veces se encuentran vulnerabilidades peligrosas que podrían dañar su sitio web. Los desarrolladores lanzan entonces actualizaciones que cierran (parchean) estos agujeros.

Por eso es tan importante actualizar regularmente el software de su sistema. Tener un proceso de actualización de sus sitios web es clave para la seguridad.

LosWAFs (hablaremos de ellos más adelante) pueden protegerte de ser explotado por muchas de estas vulnerabilidades. Sin embargo, no es un sustituto de la actualización de tus sistemas. Las actualizaciones también suelen incluir correcciones de errores o traer nuevas funcionalidades. Así que hay muchas razones para mantener tu sitio web de WordPress actualizado.

Tienes que asegurarte de actualizar tus sistemas de arriba a abajo. Además de tu instalación central de WordPress, los plugins y los temas, otras partes también necesitan actualizaciones como PHP, el motor del servidor web o el propio sistema operativo.

WordPress te da la opción de Actualizaciones Automáticas. Sin embargo, esta opción debe utilizarse con precaución. Sólo debe hacerlo en sitios web pequeños con muy pocos plugins en su lugar que tienen un buen historial de actualizaciones no destructivas.

Desgraciadamente, no puede habilitar la actualización automática sólo para las actualizaciones de seguridad, ya que no hay diferenciación entre las actualizaciones de seguridad y las funcionales. Los cambios de versión menores todavía pueden introducir cambios de ruptura (incluso si son inusuales). Esto significa que tienes que tratar cualquier actualización de la misma manera. Así que mantenga el número de plugins y temas en sus sitios web de WordPress bajo.

Vamos a explorar más a fondo.



Actualizaciones del núcleo de WordPress

La exposición de WordPress hace que sea probablemente una de las piezas de software más seguras del mundo. Se parchean muchas vulnerabilidades de seguridad que posiblemente no se encontrarían o lo harían mucho más tarde en otros sistemas menos populares. Más ojos ven más.

Además, grandes empresas como Automattic (la empresa matriz de WordPress.com), WPEngine, y muchas más invierten mucho en el núcleo de WordPress, para mantenerlo lo más seguro posible. Es lo que más les conviene, ya que ellos mismos lo utilizan como base. WordPress.com es simplemente una instalación multisitio de WordPress con muchas personalizaciones y muchos recursos.

Esto significa que el núcleo de WordPress no es una gran preocupación para nosotros, en cuanto a la seguridad. Sin embargo, instalar las actualizaciones del núcleo de WordPress sigue siendo importante y una buena práctica. WordPress evoluciona todo el tiempo y en algún momento, los desarrolladores de plugins y temas dejan de dar soporte a las versiones anteriores. Esto significa que si no actualizas el núcleo de WordPress, en algún momento tampoco podrás actualizar plugins, temas e incluso versiones de PHP. Y actualizar en ese momento no será divertido!

Puede encontrar una lista con todas las vulnerabilidades identificadas del núcleo de WordPress en la base de datos de vulnerabilidades de WPScan (anterior base de datos de vulnerabilidades de WordPress – wpvulndb.com).



Actualizaciones de plugins y temas

Mantener los plugins y los temas actualizados es importante. La mayoría de los plugins y temas no están desarrollados con la misma conciencia de seguridad que el núcleo de WordPress. Por lo tanto, están creando una superficie de ataque perfecta.

Regularmente se detectan graves vulnerabilidades de seguridad en plugins y temas, y más vale que actualices regularmente si no quieres ser vulnerable a ellas después de que se hayan hecho públicas.

Consulta la sección Reputación del desarrollador para saber más sobre qué comprobar antes de instalar un plugin o tema.



Actualizaciones del sistema

Si elige una buena solución de alojamiento gestionado, esto no es tan importante para usted. Sin embargo, si elige gestionar el alojamiento por su cuenta, también tiene que gestionar las actualizaciones del software en su configuración. Esto incluye PHP, el servidor web (por ejemplo, Apache), el sistema operativo, y cualquier otra pieza de software en ese servidor.

Esa es una de las razones por las que le recomendaría ir con una solución de alojamiento gestionado a menos que quiera gestionar activamente el sistema subyacente.



HTTPS

Siempre debes asumir que te están vigilando si visitas un sitio web que utiliza HTTP sin cifrar. Nunca introduzcas las credenciales de acceso en sitios web no encriptados. Si lo hace accidentalmente, cambie su contraseña a través de una conexión HTTPS.

Además de que el HTTP es inseguro, también afecta a tu SEO. Desde 2014 Google utiliza HTTPS como un factor de clasificación. Yo lo consideraría una obviedad porque es muy sencillo de hacer hoy en día y estás mucho más seguro.



Cambiar WordPress a HTTPS

Cambiar a HTTPS es relativamente fácil hoy en día. Simplemente ya no hay razón para comunicarse a través de HTTP gracias a Let’s Encrypt. Hazte un favor a ti mismo y a tus visitantes y cámbiate a HTTPS si aún no lo has hecho.



Obtener un certificado TLS

Atrás quedaron los días en los que tenías que pagar cientos de dólares para comprar un certificado e instalarlo a través de la línea de comandos, sólo para renovarlo cada dos años y comenzar este proceso de nuevo. Let’s Encrypt te permite generar certificados TLS verificados por el dominio. Con su software cliente, incluso automatizan todo el proceso. Solicita el certificado, lo instala en el servidor y lo renueva automáticamente. Muchos proveedores de hosting incluso soportan esto con un solo clic ahora. Completamente gratis.


¿Cuál es la diferencia entre TLS y SSL?

SSL (Secure Sockets Layer) es el antiguo nombre del protocolo de encriptación. TLS se utilizó por primera vez en 1999 con la versión 1.0 de TLS. RIP SSL




Las URLs absolutas frente a las relativas

Las URLs absolutas incluyen el dominio. Las URL relativas, en cambio, no lo hacen, lo que las hace depender del contexto.

Ejemplo de URLs absolutas y relativas:

  • Red absoluta: https://omniploy.com/about/
  • URL relativa: /about/

El navegador se referirá automáticamente al dominio en el que se encuentra el enlace cuando se utilicen URLs relativas. Así, si el dominio fuera ejemplo.com en lugar de omniploy.com, la URL relativa también sería https://example.com/about/.

WordPress y muchos plugins suelen utilizar URLs absolutas en la base de datos y por lo tanto si queremos cambiar a HTTPS, tenemos que hacer una búsqueda y reemplazo en la base de datos para el protocolo y el dominio en la base de datos.



Buscar y reemplazar http-URLs con https-URLs

Dependiendo del tamaño de tu sitio web de WordPress, el proceso de búsqueda y reemplazo de URLs puede llevar mucho tiempo.

Better Search Replace para hacer búsquedas y reemplazos, sin embargo, cualquier plugin de búsqueda y reemplazo suele ser suficiente. Sólo es importante que el sistema que utilices sí soporte la serialización.

 

WordPress tiene una forma de guardar objetos en la base de datos de forma serializada. Junto a eso, se guarda la longitud de los datos. Es decir, si tu URL primero tiene 10 caracteres y de repente 11, hay que cambiarlo para que no se invaliden los datos.

Esta es también la razón por la que recomiendo encarecidamente no hacer una búsqueda y reemplazo en un archivo SQL. Teóricamente podrías hacer una búsqueda y reemplazo fácil en un editor, sin embargo, los datos serializados no se consideran allí, dejándote con datos inconsistentes.

Aquí hay un ejemplo de las cadenas que debe buscar y reemplazar para cambiar su sitio web de WordPress de HTTP a HTTPS:

  • Buscar: http://yourdomain.com
  • Sustituir por: https://sudominio.com

Mejor búsqueda y reemplazo de captura de pantalla para omniploy.com
Si has mezclado las versiones www y no www también deberías reemplazarlas. Si quieres, también puedes aportar más consistencia a los enlaces eliminando las www (o añadiéndolas, según tus preferencias) de las URLs.

  • Buscar: http://www.yourdomain.com
  • Sustituye por: https://tudominio.com o https://www.yourdomain.com


WordPress 5.7+: Interruptor de un clic

WordPress 5.7 ha introducido una función de un clic para cambiar de HTTP a HTTPS. Sin embargo, esto no cambiará las URLs reemplazadas en la base de datos. Sólo cambia la URL del sitio y la URL de inicio a HTTPS y reemplaza las URLs HTTP en el back- y front-end sobre la marcha. Eso está bien mientras se migra a HTTPS, pero la base de datos debe ser actualizada de todos modos.

Esta característica es más bien una extensión de gancho, que permite a los proveedores de alojamiento gestionado o a los desarrolladores de plugins engancharse a estos procesos y hacer la migración específicamente. Esto abre grandes nuevas formas para los desarrolladores de plugins para crear soluciones de migración.



HSTS

HTTP Strict Transport Security (HSTS) protege a tus visitantes (y a ti) de ataques MitM como ataques de bajada de protocolo.

Cuando se escribe por ejemplo omniploy.com en la barra de direcciones por primera vez y se visita la página, la primera petición suele ser una petición HTTP de texto plano. El servidor, sin embargo, responde con una redirección a la conexión HTTPS mejorada y cifrada.

 

Ahora con HTTP Strict Transport Security (HSTS) el servidor le dice al navegador que cada conexión a este dominio tiene que ser a través de una conexión HTTPS durante un periodo de tiempo determinado.

HSTS se aplica en el navegador si el servidor responde con el campo de cabecera de respuesta HTTPS “Strict-Transport-Security”.

Te recomendaría habilitar HSTS en tus sitios web, sin embargo, no es tan importante hoy en día. Muchos navegadores (o extensiones como HTTPS Everywhere) utilizan HTTPS sobre HTTP en texto plano ahora por defecto. Así que en lugar de realizar primero una petición HTTP que redirige a la versión HTTPS, el navegador se conecta directamente en HTTPS. Esto hace que los ataques de downgrade sean mucho más difíciles (aunque no imposibles).



Protección de cuentas de usuario

Al hablar de la seguridad de WordPress, también tenemos que hablar de la protección de las cuentas de usuario. En esta sección, vamos a hablar de contraseñas, nombres de usuario, autenticación de 2 factores, y mucho más.



Contraseñas fuertes

El uso de contraseñas seguras es una parte integral de la protección de las cuentas de los usuarios para evitar que se vean comprometidas. Los hackers suelen emplear sofisticados y automatizados ataques de fuerza bruta para descifrar las contraseñas.

Aquí están las tres reglas de las contraseñas seguras:



Regla de las contraseñas fuertes #1: Compleja

Una contraseña fuerte y compleja cumple con las siguientes reglas:

    • Al menos 12 caracteres de longitud.

.

    • Tanto las letras mayúsculas como las minúsculas.

.

    • Al menos un número.

.

    • Al menos un carácter especial.

.



Regla de la contraseña fuerte #2: Única

No utilices una contraseña varias veces. Cada cuenta que crees debe tener una contraseña única. Esto te protege de que varias cuentas se vean comprometidas cuando una filtra tu contraseña.


¿Dónde guardar todas mis contraseñas?

Nadie puede recordar todas las contraseñas que utiliza. Y menos si son complejas y únicas para cada cuenta. Nosotros utilizamos 1Password internamente, sin embargo, hay muchas soluciones. Comprueba siempre la reputación.




Regla de la contraseña fuerte #3: Desconocida

Nunca debes utilizar contraseñas que estén en algún lugar de una base de datos. Algunos servicios permiten comprobar tus contraseñas con bases de datos de contraseñas. Si está en una base de datos, no la uses

Muchos gestores de contraseñas automatizan este proceso de comprobación de tus contraseñas. Las contraseñas que cumplen la regla de complejidad no deberían tener tanto problema con ser desconocidas. Aun así, es una buena práctica comprobarlo.



Autenticación de dos factores (2FA) / Autenticación de múltiples factores (MFA)

La autenticación de dos factores o la autenticación multifactor es un mecanismo en el que hay que introducir una segunda contraseña, por ejemplo, basada en el tiempo, para poder acceder.

 

Hay diferentes tipos de autenticación multifactor. Está el OTP (One-time-password) basado en el tiempo, el SMS, el correo electrónico, y más. Personalmente prefiero las OTPs basadas en el tiempo, ya que siempre funcionan son un estándar abierto y todas se pueden guardar fácilmente en un gestor de contraseñas.

Trate de evitar el uso de SMS o correo electrónico para 2FA ya que a menudo son interceptables.

Hay muchos complementos 2FA para WordPress. Si ya estás usando algo como Wordfence o iThemes Security, te recomendaría ir con eso, ya que ya está incluido y no requiere la instalación de ningún otro plugin.



Nombres de usuario por-defecto

Trate de usar siempre algo diferente para los usuarios administradores que los nombres de usuario por defecto como “admin”, “wpadmin”, “root”, o “administrator”. Aunque no se trata de hacer que su nombre de usuario de administrador sea su segunda contraseña, ya que WordPress ve los nombres de usuario como parte de la información pública y no privada, todavía evita que muchos de los bots más tontos intenten ataques de fuerza bruta. Estos son los nombres de usuario que son el objetivo de la mayoría de los bots que intentan entrar en el sitio web de WordPress. Utilice algo aleatorio como “adm1n1strat0r”. Realmente no importa lo que uses, simplemente no uses los comunes.

Plugins como Wordfence también tienen una opción de nombres de usuario prohibidos. Si alguien intenta iniciar sesión con estos nombres de usuario prohibidos, se les bloquea inmediatamente el inicio de sesión. Los nombres de usuario prohibidos deben ser los típicos nombres de usuario de administrador “admin”, “root”, “wpadmin”, etc.

Los nombres de usuario no son para la autenticación por lo que no deben ser tratados como contraseñas. Esto es más bien una táctica de honeypot.



Límite-de-inicio-de-sesión

Para hacer que tus sitios web de WordPress sean menos atractivos para los ataques de fuerza bruta, deberías limitar los intentos que alguien puede hacer para iniciar sesión. Esto hace que sea mucho más difícil para los hackers adivinar su contraseña y aumentar el rendimiento del sitio web, ya que las solicitudes se bloquean después de un cierto número de intentos.

Los plugins que incluyen límites y bloqueos de inicio de sesión son Wordfence y iThemes Security. Sin embargo, hay muchos más en la WordPress Repo.



Usar usuarios admin correctamente

Sólo debes utilizar los usuarios Admin si realmente necesitas los derechos que tienen. Por ejemplo para hacer trabajos de mantenimiento, instalar plugins o crear usuarios. Pero si sólo creas páginas o posts deberías cambiar a un usuario con derechos más restrictivos como el rol de Editor o Autor.

Con plugins como el plugin Members, puedes crear roles personalizados con los permisos exactos que se requieren para la tarea.

Usar diferentes cuentas de usuario con diferentes niveles de derechos también te hace mucho menos vulnerable a los ataques CSRF.



Plugin y temas en el contexto de seguridad de WordPress

Los plugins y los temas juegan un papel importante cuando se habla de la seguridad de WordPress. Dado que, al igual que el propio núcleo de WordPress, ejecutan código PHP plano, siempre hay que comprobar si se confía en el desarrollador. En esta sección, vamos a hablar de lo que hay que buscar en los plugins y temas para mantener tus sitios web de WordPress seguros.



Plugins y temas no utilizados

Los plugins y temas que no se utilizan deben ser eliminados por completo. No te limites a desactivarlos. Elimínelos. Los archivos de los plugins y temas todavía pueden ser llamados directamente incluso cuando el plugin está desactivado. Menos archivos ejecutables en su servidor significan una menor superficie de ataque.

Siempre puede instalarlo de nuevo más tarde.



Plugins y temas anticuados y abandonados

Probablemente hayas visto este mensaje en la parte superior de la página de un plugin de WordPress una o dos veces. Te recomiendo encarecidamente que no utilices plugins obsoletos y abandonados ya que nadie continúa con el desarrollo, dejándote sin parches para vulnerabilidades de seguridad encontradas posteriormente.

Por el camino, esto puede suponer incluso un bloqueo de actualizaciones. El plugin obsoleto se basa, por ejemplo, en una versión inferior de PHP, que ya no es compatible con un plugin más reciente o incluso con el propio núcleo de WordPress.

También hay que intentar cambiar a otros sistemas en cuanto veas que el desarrollador del plugin abandona el desarrollo.

También es una razón por la que recomiendo hacer un control de confianza en cada plugin que utilices. Esto conducirá a muchos menos problemas en el camino.



Reputación del desarrollador

Como hemos aprendido a lo largo de esta guía de seguridad de WordPress, el desarrollador tiene mucho poder sobre nuestros sitios web de WordPress. La confianza es un factor importante en este sentido. Los desarrolladores tienen el poder de cambiar el código de tu sistema con las actualizaciones, lo que significa que tienes que confiar en que la gente detrás del plugin o tema no haga algo tonto.

Aquí hay algunas preguntas que deberías hacerte antes de instalar un plugin:

    • ¿Está el plugin/tema en el mercado desde hace mucho tiempo?

.

    • ¿Se compromete el desarrollador a dar soporte al plugin a largo plazo?

.

  • ¿El plugin o tema aporta un flujo de ingresos al desarrollador para soportar los gastos y hacer que la continuación del desarrollo merezca la pena?
  • ¿Es el plugin o tema desarrollado por una empresa o una gran comunidad?
  • ¿Ha tenido el plugin o el tema pocas vulnerabilidades de seguridad en el pasado? (Compruebe la base de datos de vulnerabilidades de los plugins y temas)
  • ¿Tiene el desarrollador un buen historial de respuesta a las vulnerabilidades reportadas y de parcheo rápido?
  • ¿Tiene el desarrollador un buen historial de no romper cosas al actualizar el plugin o el tema?

Si la mayoría de las veces puede responder a estas preguntas con un sí, probablemente esté bien usando el plugin o el tema.

Como con cada pieza de software que usas o compras, debes comprobar si confías en los desarrolladores que están detrás.



Configuración del servidor y wp-config.php en el contexto de seguridad de WordPress

Cómo está configurado el servidor de tu sitio web, puede hacer una gran diferencia en términos de seguridad de WordPress. Dado que la seguridad del servidor puede ser un tema en sí mismo, nos centramos aquí un poco más en la parte relacionada con WordPress.



Ejecución de php en el directorio /uploads

El directorio /uploads en WordPress es para los archivos multimedia. Algo que no cabe ahí son los archivos ejecutables. Para evitar que los archivos ejecutables se ejecuten aunque superen los filtros de subida, tienes que configurar el motor de tu servidor web (Apache) para que no los ejecute.

Plugins como Wordfence proporcionan una opción sencilla para deshabilitar la ejecución en el directorio /uploads.

Sin embargo, también puedes hacerlo fácilmente de forma manual. Simplemente pon las siguientes líneas en un archivo llamado .htaccess directamente en tu directorio /wp-content/uploads/:

// .htaccess
<IfModule mod_php5.c>
 motor php_flag 0
</IfModule>
<IfModule mod_php7.c>
 motor php_flag 0
</IfModule>
<IfModule mod_php.c>
 motor php_flag 0
</IfModule>

AddHandler cgi-script .php .phtml .php3 .pl .py .jsp .asp .htm .shtml .sh .cgi
Opciones -ExecCGI

 

 

Esto desactiva el motor PHP para el directorio completamente. Esto es más o menos lo mismo que hace el plugin Wordfence si la opción está activada.



wp-config.php: La configuración de WordPress

El wp-config.php es el archivo de configuración para las cosas relacionadas con WordPress. Puedes encontrar una referencia completa para el wp-config.php y qué opción de configuración tiene out-of-the-box en la web oficial de WordPress. En esta guía de seguridad, hablamos del wp-config.php en el ámbito de la seguridad de WordPress.



Mover wp-config.php un directorio hacia arriba

Muchos usuarios de WordPress desconocen que el archivo wp-config.php puede ser movido un directorio más arriba, y WordPress lo seguirá localizando. Este es un paso bastante básico pero poderoso, en cuanto a seguridad. Su wp-config.php normalmente está en el mismo directorio que todos los demás. Es decir, en el espacio público.

Ahora bien, si ha configurado todo correctamente, normalmente no hay mucho de qué preocuparse, ya que incluso si llamara al wp-config.php directamente accediendo a suwebsite.com/wp-config.php, sólo mostraría una página en blanco. Esta es la razón por la que el material de configuración está todo en PHP y no se hace eco en la página.

Sin embargo, si hay una configuración errónea en el servidor y el archivo se devuelve mostrando código PHP, puedes meterte rápidamente en problemas. Teniendo en cuenta lo importantes y secretos que son los datos en el wp-config.php, siempre deberíamos considerar moverlos fuera del espacio público. Es una victoria fácil para la seguridad.



Deshabilitar la edición del código fuente en el backend (DISALLOW_FILE_EDIT)

WordPress tiene un editor de temas y plugins que se puede utilizar para editar directamente los archivos de los plugins y los temas. Te recomiendo encarecidamente que lo desactives.

En primer lugar, la edición de archivos fuente es peligrosa. Un carácter erróneo y su sitio web puede estar abajo. Otro problema es que cuando se actualizan los plugins y los temas, todas las ediciones de los archivos de código fuente se pierden, ya que los archivos del plugin/tema se sobrescriben y, por lo tanto, todos los cambios desaparecen.

Sólo hay un caso en el que se me ocurre que este editor de código backend podría ser viable. Y es cuando se tiene un tema hijo y se quiere modificar rápidamente. Pero también aquí sería una buena práctica usar un editor de código y versionar los cambios. Todo eso no ocurre con el editor de temas y plugins.

Así que para el 99,9%, recomendaría desactivar el editor de código por completo.

Y eso es bastante sencillo. Abre el archivo wp-config.php y añade la siguiente línea:

// wp-config.php
// Debajo de esta línea => /* ¡Eso es todo, deja de editar! Feliz blogueo. */
define('DISALLOW_FILE_EDIT', true);

 

 



Forzar HTTPS en el backend (FORCE_SSL_ADMIN)

Si su sitio web se comunica a través de HTTPS (que debería) debe establecer la opción FORCE_SSL_ADMIN a true. Esto fuerza todo el tráfico al backend sobre HTTPS y permite la transferencia de cookies sólo sobre HTTPS estableciendo la bandera Secure en la cookie.

Añade la siguiente línea a tu wp-config.php para forzar HTTPS en el backend:

// wp-config.php
// Debajo de esta línea => /* ¡Eso es todo, deja de editar! Feliz blogueo. */
define('FORCE_SSL_ADMIN', true);

 

 



Desactivar claves únicas de seguridad

WordPress utiliza claves únicas para firmar y cifrar las cookies. Estas claves deben mantenerse en secreto ya que un atacante podría generar por sí mismo cookies de sesión con estas claves. Si sigues el proceso normal de instalación de WordPress o algún otro proceso de instalación automatizado, estas claves deberían generarse automáticamente. Pero a veces, especialmente en las instalaciones más antiguas de WordPress, la generación de las claves nunca se hizo, lo que te deja con algo como esto:

// wp-config.php
// Nunca dejes tu config con esto
define( 'AUTH_KEY', 'pon tu frase única aquí' );
define( 'SECURE_AUTH_KEY', 'pon tu frase única aquí' );
define( 'LOGGED_IN_KEY', 'pon tu frase única aquí' );
define( 'NONCE_KEY', 'pon tu frase única aquí' );
define( 'AUTH_SALT', 'pon tu frase única aquí' );
define( 'SECURE_AUTH_SALT', 'pon tu frase única aquí' );
define( 'LOGGED_IN_SALT', 'pon tu frase única aquí' );
define( 'NONCE_SALT', 'pon tu frase única aquí' );

 

 

Si encuentras esto en tu configuración, te recomiendo encarecidamente que generes unas nuevas (WordPress.org tiene un endpoint fácil para ello) y restablezcas todas las contraseñas.



Cambiar el prefijo de la base de datos ($prefijo-de-table)

<

El prefijo de la base de datos te trae la posibilidad, de ejecutar múltiples instancias de WordPress en una base de datos, simplemente usando diferentes prefijos.

Cambiar el prefijo de la base de datos es una manera fácil de mejorar la seguridad en una nueva instalación de WordPress, simplemente cambiando el prefijo de la base de datos a algo diferente de wp_. WordPress le pregunta durante la instalación qué desea utilizar como prefijo de la base de datos. Utilice algo al azar, como c3po_.

También puedes cambiar el prefijo de la base de datos posteriormente. Sin embargo, te recomendaría utilizar algún plugin para ello y crear siempre una copia de seguridad antes de cambiar el prefijo de la base de datos.

Plugins como iThemes security te permiten cambiar el prefijo de la base de datos a posteriori.



Bloquear la visualización de mensajes de depuración (WP_DEBUG_DISPLAY)

Si tienes que hacer depuración en un sitio en vivo, no muestres los mensajes de depuración directamente en la pantalla. Los mensajes de depuración pueden incluir información que podría ser potencialmente interesante para los atacantes. Mejor deja que WordPress escriba en un archivo debug.log.

// wp-config.php
define('WP_DEBUG_DISPLAY', false);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG', false); // Cambia esto a true si quieres registrar los mensajes de depuración.

 

 

Deberías poner la opción WP_DEBUG_DISPLAY en false inmediatamente, aunque no depures ahora. Así no te arriesgas a que se muestre ningún mensaje de depuración por haberte olvidado de desactivarla.



Firewall de aplicaciones web (WAF)

Un firewall de aplicaciones web es como un software antivirus para su sitio web. Se sitúa delante de su sitio web y comprueba las solicitudes potencialmente dañinas.



Plugin WAF

Si tu proveedor de hosting no proporciona un WAF, también puedes optar por una solución de plugin. Nuestra opción favorita es Wordfence. Además de las actualizaciones de las reglas del firewall en tiempo real y las listas negras de IP, también proporcionan numerosas otras características como el bloqueo, la estrangulación, 2FA, y mucho más para bloquear su sitio web de WordPress.

Sin embargo, recomendamos la versión de pago ya que la versión gratuita obtiene la mayoría de las actualizaciones de reglas de firewall para las vulnerabilidades de seguridad recién detectadas sólo después de 30 días. Esto significa que si se detecta una vulnerabilidad en un plugin que ha instalado en su sistema, y no está actualizando ese plugin, su sitio web es vulnerable durante 30 días antes de obtener la regla de firewall.

Sin embargo, te recomendaría activar la protección extendida. De esa manera Wordfence puede comprobar las peticiones antes de que se cargue el propio WordPress y protegerte contra los ataques de plugins y temas.



Cloud WAF

Un WAF en la nube es un proxy entre su sitio web de WordPress y sus visitantes. En lugar de apuntar el dominio al servidor directamente, se configura la IP para que apunte a un WAF en la nube. Este WAF en la nube reenviará el tráfico legítimo al servidor y viceversa.

Ejemplos de WAFs en la nube son Cloudflare o Sucuri WAF.



Standalone WAF

Un WAF de servidor local es un software instalado localmente que filtra el tráfico antes de que llegue a su sitio web de WordPress.

Un ejemplo de WAF de servidor local es el NinjaFirewall. Están especializados en WordPress y PHP. En lugar de instalar un plugin en el entorno de WordPress como con Wordfence, colocan un WAF independiente frente a su servidor web. Otro ejemplo sería el cortafuegos 7G de Perishable Press.


 



Security Plugins

La siguiente lista no contiene todos los plugins de seguridad de WordPress que existen. Estos son los que hemos utilizado y revisado nosotros mismos y con ellos, puedes hacer prácticamente todo lo que necesitas en términos de seguridad de WordPress.



Wordfence Security

Wordfence es nuestro plugin de seguridad favorito. La gente de Wordfence se centra exclusivamente en la seguridad de WordPress y hace un trabajo impresionante identificando y cerrando vulnerabilidades en plugins y temas.

Wordfence Premium es un poco caro pero merece la pena si quieres mantener tu nivel de estrés bajo. Y se abaratan en cada licencia. El precio de Wordfence empieza en 99 dólares y baja a 75,25 dólares si compras 15 o más licencias. En su página web encontrarás una lista completa de sus precios.

Además de su WAF que está desarrollado exclusivamente para WordPress, también incluyen muchas más características para reforzar la seguridad de tu WordPress. Aquí hay una lista de algunas características incluidas en Wordfence:

    • Limitación de tarifas

.

    • 2FA (autenticación de 2 factores)

.

    • Bloqueo de países

.

    • Escaneo automático de malware

.

  • Protección contra la fuerza bruta
  •  
  • Y muchos más…

He escuchado algunas veces en la comunidad de WordPress que experimentan sitios web lentos con Wordfence activado en sus sitios web. No he podido confirmar, que Wordfence ralentice tu web. Creo que esto puede ser cierto si se ejecuta en recursos extremadamente baratos y limitados. Sin embargo, no deberías tener problemas si tu entorno de alojamiento está bien escalado.

También tienen un gran podcast llamado Piensa como un hacker con Wordfence. Hablan de los eventos de seguridad actuales. Si quieres estar al día de lo que ocurre en el mundo de la seguridad de WordPress, te recomiendo de verdad que te suscribas a su podcast.



iThemes Security

iThemes Security es un poco todoterreno. También hay una opción iThemes Security Pro que amplía la funcionalidad aún más. Sin embargo, no proporcionan un WAF actualizado en tiempo real.

Esa es también la razón por la que pueden proporcionar un plan por 199 dólares al año para sitios ilimitados. A diferencia de Wordfence, ellos sólo venden el plugin y no necesitan proporcionar infraestructura para cada WAF instalado.

Sigo pensando que iThemes Security, junto con un plugin, la nube o un WAF independiente es una gran manera de mejorar en gran medida la seguridad de sus sitios web de WordPress. Sobre todo si los precios de Wordfence te echan para atrás.



Otros plugins de seguridad

Hay muchos más plugins de seguridad por ahí que hacen el trabajo. No he trabajado mucho con ellos. Sin embargo, son de desarrolladores reputados, así que no tengo problemas en recomendarlos.

  • WPMU DEV Defender
  • Jetpack
  • Sucuri Security



Respuesta a sitios web WordPress hackeados

Hasta ahora, hemos aprendido a proteger nuestros sitios web de WordPress de ataques maliciosos. En esta parte, vamos a hablar de qué hacer en caso de una brecha. Tener una estrategia establecida ayuda a reducir el estrés y el pánico, así como el tiempo que se tarda en responder y detener el ataque.



El plan de respuesta a incidentes de seguridad de WordPress

.Un plan de respuesta a incidentes de seguridad en WordPress define 6 fases para cada incidente.

Veamos estos procesos desde la perspectiva de los desarrolladores y administradores de sitios web de WordPress.



Respuesta a incidentes #1: Preparar

Nunca pienses que no puedes ser hackeado. Sólo tiene que haber una vulnerabilidad grave de día cero en un plugin o tema de tu sitio web que comprometa todo el sistema. Debe prepararse para estos casos. Piensa en sistemas de copia de seguridad y en la formación del personal de los administradores para luchar contra la ingeniería social.

Aquí hay una lista de cosas a tener en cuenta a la hora de prepararse para los ataques de hacking:

    • Tener una solución de copia de seguridad sólida. En el sitio y fuera del sitio.
    •  
    • Tener una forma de analizar los registros.

.

  • Capacitar a los clientes que exigen derechos de administrador en su sitio web.
  • Cuidar de las políticas de seguridad en el sitio web.
  • Tener políticas de seguridad establecidas. ¿Quién puede hacer qué y cuándo?
  • Tener escáneres de malware en su lugar.

La preparación es la clave cuando se trata de ataques de hacking. Reduce el riesgo de que cunda el pánico en tales situaciones, lo que a su vez significa que es más rápido en hacerles frente. La preparación también suele decidir si incluso se detecta el ataque.

Si un hacker sólo quiere apoderarse de su sitio web para su red DDoS, es posible que nunca sepa que su sitio web está comprometido o sólo después de que sea demasiado tarde.



Respuesta al incidente #2: Identificar

Para combatir un ataque, primero hay que identificar qué es lo que se está atacando. Ahí es donde entran los logs y por eso recomendé en la parte de preparación tener una forma de analizar los logs. Te ayudan a identificar qué puntos finales son llamados y sus cargas útiles.

Otra forma de identificar los ataques es utilizar un escáner de malware. Configura un escáner de malware para que se ejecute cada pocos días y te informe en caso de que se encuentre malware. Por ejemplo, Wordfence te permite hacer esto.

Además, comprueba si otros sitios web o sistemas están afectados por el ataque. Si has identificado la pieza vulnerable, como un plugin, revisa todos tus otros sistemas y si puedes, desactívalo, para evitar otro ataque a estos sistemas.



Respuesta al incidente #3: Contener

Cuando se identifica hay que contener el malware. Hacer una copia de seguridad del sitio web de WordPress infectado, cambiar todas las claves de seguridad, claves API, contraseñas, etc. Si es posible sacarlo de la red. Actualizar las versiones de software y PHP en el servidor web.

Quieres hacer todo lo posible para tenerlo bajo control.



Respuesta al incidente #4: Erradicar

Cuando se contiene, hay que erradicar la causa raíz. Esto puede ser eliminar un plugin inseguro, cambiar las contraseñas vulneradas, actualizar el software obsoleto, etc.

También hay que comprobar si se ha instalado una puerta trasera. Los hackers lo hacen exactamente para ese caso que arreglar el agujero inicial o para ganar aún más poder sobre sus sistemas.



Respuesta al incidente #5: Recuperar

Si es posible, mueva su sitio web limpio a un servidor web fresco y actualizado. Asegúrese de que está protegido de forma segura contra una nueva brecha cuando vuelva a estar en línea.

¿Ha cambiado todas las contraseñas y claves API en el sitio web comprometido? Ha eliminado todas las cuentas de usuario desconocidas creadas por el atacante? ¿Está el núcleo, los plugins y el tema actualizados?

Además, define durante cuánto tiempo quieres monitorizar más de cerca los sitios web de WordPress recuperados.

Ahora también es el momento de mejorar y endurecer la seguridad de tus sitios web de WordPress. Introduce WAFs, 2FA, políticas de contraseñas más estrictas y políticas al software utilizado. Revisa todos los plugins y temas utilizados, y si no cumplen con estas nuevas políticas, sustitúyelos por otra cosa.



Respuesta al incidente #6: Lecciones aprendidas

Si un plugin o tema fue el responsable de la brecha, notifique a los desarrolladores sobre esa vulnerabilidad. Deberían arreglar rápidamente el problema para evitar que otros sitios web de WordPress sean hackeados.

Si se filtró información personal de tus visitantes o usuarios, en la mayoría de los países estás obligado a reportar estos incidentes a las autoridades e informar a los afectados. Los registros te ayudan a identificar los datos filtrados.

Además, pregúntese qué debería hacer de forma diferente en el futuro para prevenir estas situaciones. Por ejemplo, tras un ataque de ingeniería social contra la web de un cliente, comprueba si hay que formar mejor a los clientes.

Incluso si nunca necesitas este plan de respuesta, deberías tener uno. Elimina el estrés, y además es mucho más profesional de cara a tus clientes.



Antipatrones en el contexto de seguridad de WordPress

Hay algunos antipatrones de seguridad de WordPress que todavía se practican y se enseñan en la industria. Los anti-patrones son soluciones ineficaces o incluso contraproducentes que se emplean frecuentemente como reacción a un problema. Esta sección contiene algunas opiniones personales, así que léela y decide por ti mismo si quieres utilizarlos.



Seguridad por oscuridad

Yo consideraría que la seguridad por oscuridad, no es una buena práctica. Al menos para los sitios web de WordPress. Ya sea porque no tiene mucho impacto en la seguridad de tu sitio web, porque podría crear problemas con ciertos plugins o temas, o porque podría darte una falsa sensación de seguridad.

Hay plugins que intentan ocultar que tu sitio web está ejecutando WordPress. Lo hacen tratando de eliminar todo lo que podría llevar a alguien a la conclusión de que estás ejecutando en WordPress. Por ejemplo, cambiando la ruta predeterminada /wp-admin a algo diferente, o eliminando las etiquetas meta de WordPress.

Sin embargo, esto podría llevar a problemas con otros plugins o temas que esperan que esos datos estén ahí. Además, cada plugin que cargue algo en el frontend podría ser utilizado para detectar que es WordPress por su propia huella única.

No confíes en la seguridad por oscuridad.

Es demasiado esfuerzo para los beneficios que obtienes. Como he dicho tendrías que revisar cada plugin y tema por si dejan algo en el frontend que pueda exponer tu instalación de WordPress. ¿Y para qué? ¿Que nadie sepa que estás funcionando con WordPress? No merece la pena. Si sigues las reglas anteriores ya estás seguro.



Captchas en formularios de inicio de sesión

Si has seguido la sección sobre la protección de las cuentas de usuario ya deberías estar bien preparado contra los ataques de inicio de sesión más comunes. En los formularios de inicio de sesión, los captchas hacen tu vida y la de tus usuarios más difícil sin añadir mucho beneficio. Además, si eliges usar reCAPTCHA también envías datos valiosos a Google de forma gratuita.

Los captchas son útiles para formularios de contacto, formularios de registro y similares, pero no para formularios de inicio de sesión.



Otros grandes recursos de seguridad de WordPress

La seguridad en WordPress no es un tema que se pueda establecer y olvidar. Siempre debes estar al tanto de este tema. Sólo así, sabrás cuándo y cómo reaccionar ante nuevos hilos.



Blogs y sitios web

Hay muchos otros grandes blogs y sitios web en línea que cubren la seguridad de WordPress.



Podcasts

Los podcasts de seguridad son geniales para estar al día en temas relacionados con la seguridad y lo que ocurre en este mundo. A mí me gusta mucho escucharlos en mi trayecto al trabajo o mientras hago las tareas del hogar (los dos son yankees).

 

Categorías : # seguridad en wordpress, # wordpress, Sin categoría

Un comentario en “Manual de SEGURIDAD para WordPress 2022

  1. Anónimo says:

    joyita de artículo!

    3 de diciembre de 2021
    Reply

Deja una respuesta

Tu dirección de correo electrónico no será publicada.