Ataques DDoS en WordPress – Manual de superviencia para saber cómo prevenirlos, detectarlos y frenarlos paso a paso

Si tienes una web WordPress por pequeña que sea, tarde o temprano te toca lidiar con los ataques DDoS.

No hace falta que seas un medio importante ni una tienda con mucha facturación para que te caiga uno encima. Los ataques automatizados no discriminan, a veces eres tú el objetivo y otras veces solo eres una IP más en una lista, pero el efecto es el mismo en cualquiera de los dos casos: tu web se arrastra o se cae del todo.

Lo bueno es que con las defensas adecuadas puedes frenar la mayoría de estos ataques, y lo que no puedas parar al 100% al menos lo vas a aguantar sin que se te venga todo abajo.

Vamos a ver cómo montar esa protección por capas, desde el DNS hasta la propia configuración de WordPress, con ejemplos que puedes adaptar a tu web.

Algunas cifras para que te hagas una idea

• Cloudflare bloqueó 20,5 millones de ataques DDoS solo en el primer trimestre de 2025, casi lo mismo que en todo 2024 junto.
• Los ataques a la capa de aplicación, que son los que más afectan a WordPress, crecieron un 118% interanual a principios de 2025.
• El 94% del tráfico de ataque ya va cifrado con HTTPS, lo que complica enormemente el filtrado.
• En sitios sin protección, el 98% de las peticiones a /wp-admin/ es tráfico de ataque y no usuarios reales.
• El 89% de los ataques duran menos de 10 minutos, menos de lo que tardas en llamar al soporte.
• Contratar un DDoS-as-a-service en la red cuesta desde unos 35 euros la hora, al alcance de cualquier aburrido con tarjeta.
• El ataque más grande registrado hasta la fecha alcanzó los 31,4 Tbps en diciembre de 2025.

Con estos números encima de la mesa, no se qué pensarás, pero yo creo que ignorar el tema no es una opción.

Qué es exactamente un ataque DDoS

DDoS son las siglas de Distributed Denial of Service, o sea, denegación de servicio distribuida.

La traducción al román paladino es bastante simple, porque lo que hace el atacante (que puede ser un tipo, un grupo o una red automatizada) es mandar tantísimas peticiones a tu web desde muchísimos sitios distintos a la vez que tu servidor no puede con todo y acaba petando, o va tan lento que es como si se hubiera caído.

La palabra clave aquí es «distribuido». Un ataque desde una sola IP lo paras con bloquear esa IP y listo, pero lo que hace peligroso al DDoS es que vienen miles o millones de peticiones desde IPs diferentes, muchas de ellas de ordenadores y dispositivos infectados sin que sus dueños lo sepan, lo que se conoce como botnets.

Qué NO es un ataque DDoS

Esto es importante que lo tengas claro desde el principio, porque se mezcla mucho. Estas cosas no son DDoS aunque los efectos a veces se parezcan:

• Un artículo tuyo que se vuelve viral y te manda miles de visitas en una hora es tráfico legítimo, por mucho que te tumbe el hosting.
• Un bot de entrenamiento de IA que pasa por tu web sacando datos a pelo es scraping agresivo, no un ataque.
• Una herramienta de SEO mal configurada que te machaca con peticiones es un bot gamberro, no un atacante.
• Un plugin con un bucle infinito que genera peticiones a wp-cron cada dos segundos es un fallo de configuración, no un DDoS.

¿Y el scraping agresivo de las IAs?

Para que te hagas una idea del lío que hay con esto, en julio de 2024 el CEO de iFixit denunció que ClaudeBot (el rastreador de Anthropic) había hecho casi un millón de peticiones a su web en 24 horas. Mucha gente lo llamó DDoS, pero técnicamente no lo era porque era un bot de entrenamiento sacando datos sin freno.

El efecto (servidores reventados y equipo corriendo a apagar el fuego) sí que recuerda mucho a un DDoS, y las defensas se solapan bastante, porque un rate limiting bien puesto te frena tanto a un atacante como a un bot chungo.

Pero no son lo mismo. Un DDoS lo lanza alguien con intención de hacerte daño, mientras que un bot de IA, aunque se pase catorce pueblos, solo quiere datos. Por eso en este tutorial me centro en los ataques con malas intenciones, que es lo que de verdad duele, aunque muchas de las soluciones te van a servir también para mantener a raya a los bots pesados.

Los 3 tipos de DDoS que existen

No todos los ataques son iguales, así que para defenderte bien tienes que saber contra qué te estás defendiendo.

Ataques volumétricos

Son los más antiguos y los más aparatosos. El atacante inunda tu conexión con una cantidad bestial de tráfico que satura el ancho de banda antes de que los datos lleguen a tu servidor, como si intentase meter el agua del mar por una manguera de jardín.

Contra esto no puedes hacer absolutamente nada desde WordPress, ni siquiera desde tu hosting.

El tráfico ya te ha petado la red antes de que tú puedas reaccionar, así que la única defensa real está en la capa CDN, que es donde Cloudflare y demás tienen infraestructura suficiente como para absorber estos volúmenes.

Ataques de protocolo

Estos van contra las debilidades de los protocolos de red, y el más conocido es el SYN flood, que manda millones de peticiones de conexión TCP sin completarlas para llenar la tabla de conexiones del servidor hasta que no puede aceptar ni una legítima.

Tampoco se paran desde WordPress, se paran en el firewall del servidor, en el hosting o en la CDN.

Ataques a la capa de aplicación (capa 7)

Los ataques de capa 7 mandan peticiones HTTP o HTTPS que parecen totalmente legítimas, no saturan tu ancho de banda ni inundan la red, sino que simplemente le piden a tu WordPress que haga cosas caras una detrás de otra sin parar, hasta que PHP y MySQL se rinden.

Los puntos más castigados en WordPress son:

• wp-login.php, para ataques de fuerza bruta disfrazados de DDoS.
• xmlrpc.php, que permite probar cientos de contraseñas en una sola petición.
• admin-ajax.php, que muchos plugins usan sin autenticación.
• La búsqueda interna, que genera consultas pesadas a la base de datos.
• La API REST, si no está bien protegida.
• wp-cron.php, si se ejecuta en cada petición.

Este es el tipo de ataque que puedes (y debes) parar desde tu propia web, tu servidor y tu CDN.

¡Pero si mi web no le importa a nadie! ¿por qué me van a atacar a mi?

Si piensas «a mí quién me va a atacar, si mi web no es nadie» estás cometiendo un error muy común, porque los ataques DDoS no siempre van contra objetivos importantes y ni siquiera tienen siempre un motivo racional.

Estas son las razones habituales, de más a menos graves:

• Extorsión: Alguien te escribe diciendo que si no le pagas X cantidad en criptomonedas te tumba la web, y si no pagas la tumba un rato para demostrar que puede. Es más habitual de lo que parece, sobre todo en tiendas online antes de eventos de venta importantes.
• Competencia desleal: Un competidor cabronazo contrata un ataque el día de tu campaña pre-navideña o el lanzamiento de un producto. Parece película, pero pasa, hay gente muy joputa por ahí.
• Hacktivismo: Si tu web tiene contenido que alguien considera ofensivo o contrario a sus ideas, te puede caer un ataque por motivos ideológicos.
• Cortina de humo: El DDoS es ruidoso y lo ve todo el mundo, así que mientras tú y tu equipo estáis apagando ese fuego, otro atacante aprovecha para meterse por la puerta de atrás sin que nadie le mire.
• Venganza personal: Un ex-empleado cabreado o un cliente insatisfecho que ha echado mano de un servicio de DDoS por horas.
• Pruebas de gilipollas aburridos: Los llamados script kiddies, niñatos con tiempo libre que prueban herramientas contra cualquier web que encuentren, sin motivo, por diversión.
• Daño colateral: Estás en un hosting compartido (de los malos) y el ataque va contra otro cliente, pero tu web se va al carajo porque comparte servidor.
• Automatización: Hay botnets que escanean internet buscando WordPress vulnerables y lanzan ataques de prueba para ver qué aguanta, y si tu web aguanta mal se centran en ti.

Con los servicios de DDoS-as-a-service por unos pocos euros la hora, la barrera de entrada para atacar a alguien es ridícula y cualquiera puede lanzar un ataque sin saber ni lo que está haciendo.

Cómo saber si estás bajo ataque

Lo primero para defenderte es darte cuenta de que estás pasando por un ataque. Estos son los síntomas más habituales:

• La web va muy lenta o directamente no carga, con errores 502 o 504.
• El panel del hosting muestra la CPU disparada o la base de datos al límite.
• Picos de tráfico enormes desde países o regiones donde no tienes audiencia.
• Miles de peticiones por minuto a una URL concreta, normalmente wp-login.php, xmlrpc.php o admin-ajax.php.
• El soporte del hosting te avisa de que estás consumiendo recursos excesivos.
• Caídas intermitentes cada pocos minutos sin motivo aparente.

Herramientas para confirmarlo

Antes de ponerte nervioso confirma que es un ataque real y no un problema tuyo. Puedes usar estas herramientas, todas gratuitas:

• Logs de acceso del hosting: Míralos directamente, cualquier panel decente te los da. Busca picos anormales y repeticiones sospechosas de la misma IP o User-Agent.
• Query Monitor: Esta joya bendita en forma de plugin de WordPress te enseña qué está pasando por dentro.
• AbuseIPDB: Para comprobar si las IPs que sospechas están reportadas por abuso.
• Sucuri SiteCheck: Escaneo rápido y gratis.
• El dashboard de Cloudflare: Si lo tienes configurado, que muestra con mucho detalle qué tipo de tráfico estás recibiendo.

Defensa por capas, que es lo que funciona

No hay una sola solución contra los DDoS, lo que funciona es montar varias capas de defensa para que cada una frene un tipo de ataque distinto. Si una falla las demás aguantan el tipo. Vamos capa por capa.

Capa 1: DNS y CDN

Esta es la primera barrera y la más importante contra los ataques volumétricos y de protocolo. Básicamente, en vez de que el tráfico llegue directamente a tu servidor, pasa primero por una red de servidores enorme que filtra lo malo antes de dejar pasar lo bueno.

Las opciones más habituales son:

• Cloudflare, que tiene un plan gratuito con protección básica contra DDoS y un WAF limitado.
• BunnyCDN, con precio asequible y buena infraestructura europea.
• QUIC.cloud, especialmente interesante si usas LiteSpeed Cache.
• Sucuri, algo más caro pero con WAF y limpieza incluida.

Si ya usas Cloudflare activa el modo «Under attack» en cuanto detectes algo raro, porque ese modo añade una página de verificación JavaScript que los bots no pasan pero los humanos sí. Tienes la guía detallada en el artículo sobre cabeceras de seguridad HTTP, que complementa muy bien esta configuración.

Capa 2: Hosting

Un buen hosting WordPress te pone el trabajo mucho más fácil, porque los hosting gestionados de calidad tienen su propio WAF, detección de anomalías, limitación de recursos por cuenta y soporte técnico que reacciona rápido si te están atacando. Los hosting compartidos de medio pelo, en cambio, te van a dejar tirado en cuanto la cosa se ponga seria.

Si buscas un hosting que se tome en serio la seguridad yo uso y recomiendo SiteGround, que incluye WAF con reglas específicas para WordPress, mitigación automática de ataques pequeños y un panel de seguridad bastante completo. Afortunadamente hay buenos hostings españoles y europeos dignos para estas cosas, en eso casi hasta tenemos suerte. ¿Fuera? todo es campo.

Capa 3: Servidor

Aquí empezamos con lo jugoso. El archivo .htaccess, si estás en Apache o LiteSpeed (que es lo más común en hosting para WordPress), te deja bloquear peticiones antes incluso de que PHP se entere de que existen. Es rapidísimo y consume pocos recursos, así que es la primera línea real de defensa dentro de tu servidor.

Todas las reglas que siguen se añaden al archivo .htaccess que tienes en la raíz de tu WordPress, antes de las reglas que ya hay de WordPress. Haz siempre una copia de seguridad del archivo antes de tocarlo.

Bloqueo por User-Agent

Muchos bots atacantes y scrapers se identifican con cadenas reconocibles, así que bloquearlos por User-Agent te quita de encima un montón de ruido.

# Bloquear bots conocidos por abusivos
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (ahrefsbot|semrushbot|mj12bot|dotbot|petalbot|megaindex) [NC]
RewriteCond %{HTTP_USER_AGENT} (seokicks|blexbot|sogou|baiduspider|yandexbot) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (zoominfobot|serpstatbot|barkrowler|dataforseobot) [NC]
RewriteRule .* - [F,L]
</IfModule>

Advertencia: esto no te sirve contra atacantes serios, que falsifican el User-Agent sin problema, pero te quita de encima mucho scraper honesto (dentro de lo que cabe) y algunos bots de SEO cansinos que te consumen recursos a saco.

Restricción de métodos HTTP

WordPress solo necesita los métodos GET, POST y HEAD para funcionar. Si tu web no tiene una API que use otros métodos bloquea el resto.

# Solo permitir métodos HTTP necesarios
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} !^(GET|POST|HEAD)$
RewriteRule .* - [F,L]
</IfModule>

Si usas la REST API con PUT o DELETE (por ejemplo desde un plugin como WooCommerce Bookings o una app móvil), añade esos métodos a la lista.

Protección de xmlrpc.php

XML-RPC es un vector de ataque clásico. Si no lo usas (la mayoría de webs no lo necesitan hoy en día), bloquéalo del todo.

# Bloquear acceso a xmlrpc.php
<Files xmlrpc.php>
    Require all denied
</Files>

Si lo necesitas (Jetpack, por ejemplo, aunque cada vez menos), permite solo los accesos desde las IPs autorizadas, entonces mete algo así:

# Permitir xmlrpc.php solo desde IPs concretas
<Files xmlrpc.php>
    Require ip 192.0.66.0/24
    Require ip 195.234.108.0/22
</Files>

Protección de wp-cron.php

El cron de WordPress se ejecuta por defecto cada vez que alguien visita tu web, y puede ser un punto de abuso. Lo mejor es desactivar esa ejecución automática y poner un cron real del servidor, pero de paso bloquea el acceso externo directo al archivo.

# Bloquear acceso externo a wp-cron.php
<Files wp-cron.php>
    Require all denied
</Files>

Para que el cron siga funcionando añade esto a tu wp-config.php:

define( 'DISABLE_WP_CRON', true );

Y luego configura un cron real en el panel del hosting que lance wp-cron.php cada 15 minutos o cada hora, según lo que necesite tu web.

Protección reforzada de wp-login.php

El login es el objetivo número uno de los ataques de fuerza bruta disfrazados de DDoS. Esta regla limita el acceso a wp-login.php solo desde tu IP, ideal si trabajas siempre desde el mismo sitio.

# Acceso a wp-login.php solo desde IPs autorizadas
<Files wp-login.php>
    Require ip 81.123.45.67
</Files>

Nota: Cambia 81.123.45.67 por tu IP pública real. Si tienes IP dinámica esto no te vale, y en ese caso mejor usa un plugin que cambie la URL del login (lo vemos más adelante).

Limitar el tamaño de las peticiones

Algunos ataques mandan peticiones POST enormes para tumbar el servidor, así que limita el tamaño máximo.

# Limitar tamaño máximo de petición a 10 MB
LimitRequestBody 10485760

Si tu web sube archivos grandes (vídeos, por ejemplo), ajusta el valor a lo que realmente necesites, pero no lo dejes nunca sin límite.

Bloqueo de IPs concretas

Cuando identifiques IPs atacantes en tus registros bloquéalas directamente.

# Bloquear IPs concretas
<RequireAll>
    Require all granted
    Require not ip 123.45.67.89
    Require not ip 98.76.54.32
    Require not ip 10.20.30.0/24
</RequireAll>

Bloqueo de hotlinking

El hotlinking es cuando otras webs enlazan tus imágenes directamente desde sus servidores, usando tu ancho de banda. No es un DDoS, pero el efecto acumulado es parecido.

# Evitar hotlinking de imágenes
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?tudominio\.com [NC]
RewriteRule \.(jpe?g|png|gif|webp|svg)$ - [F,NC,L]
</IfModule>

Nota: Cambia tudominio.com por el tuyo, claro.

Capa 4: WordPress

Aunque tengas bien montadas las capas anteriores, desde WordPress también puedes (y debes) apretar tuercas. Estas son las configuraciones que se notan más:

• Desactivar XML-RPC si no lo usas, y además de la regla htaccess hay plugins que lo hacen con un clic.
• Ocultar la URL del login, porque si los bots no encuentran wp-login.php no pueden atacarlo.
• Proteger la REST API, restringiendo quién puede acceder a /wp-json/ y sus endpoints, que es fundamental para evitar enumeración de usuarios y abuso de endpoints. Si te interesa profundizar tienes el artículo sobre enumeración de usuarios que cubre este tema.
• Limitar intentos de login, imprescindible contra la fuerza bruta.
• Desactivar pingbacks y trackbacks, que son una vía de amplificación de ataques.
• Usar 2FA en todas las cuentas con privilegios, que no para el DDoS directamente pero evita que si una cuenta cae bajo fuerza bruta el atacante entre de verdad.

Plugins anti-DDoS para WordPress ¿los hay?

No hay un plugin que por sí solo te proteja de todo, pero sí hay plugins que implementan varias de las defensas que hemos visto y te ahorran tener que configurarlas una por una. Estos son los más completos para la parte que te interesa.

Mi recomendación de amigo es que pruebes Vigilante, que es mío, por si no lo sabías. Lo hice precisamente porque los demás tenían limitaciones en la parte de métodos HTTP y REST API, que son puntos calientes para los DDoS en WordPress, y además es gratis total, sin versión premium ni cosas de pago escondidas.

Si ya usas Wordfence, Solid Security o AIOS ninguno está mal (bueno, WF sí, lo odio bastante), y pasarse a otro solo por el cambio no suele merecer la pena. Lo que no debes hacer nunca es ejecutar dos plugins de seguridad a la vez, porque te vas a encontrar conflictos raros y vas a bajar el rendimiento sin ganar nada a cambio.

Sobre los bots de IA, el añadido de VigIA

Aunque no sean un DDoS en sentido estricto, los bots de entrenamiento de IA (GPTBot, ClaudeBot, Bytespider, PerplexityBot y compañía) pueden generar una carga bestial en tu servidor. Y aquí viene lo interesante, porque lo comprobé con mi propio plugin VigIA y de los archivos robots.txt pasan completamente, así que lo único que los para de verdad es bloquearlos por IP o por User-Agent a nivel de servidor, devolviéndoles un 403.

Si has puesto las reglas .htaccess anteriores ya estás bloqueando parte, y para rematarlo VigIA te muestra qué bots de IA están entrando, cuántas veces y qué páginas rastrean, y te deja bloquearlos con un clic. Si la carga te viene por ahí y no por un ataque real, tener VigIA instalado te ahorra el trabajo de identificar manualmente cada bot en los logs.

Qué hacer si te está pasando ahora mismo

Vale, has leído hasta aquí porque tu web está hecha mierda, medio caída o del todo, y quieres saber qué hacer ya. Este es el protocolo de crisis, paso a paso.

Paso 1: confirma que sea de verdad un DDoS

Mira los logs del hosting y tira de Query Monitor si puedes acceder al admin, y comprueba que hay un pico anormal de peticiones y que muchas vienen de IPs o patrones repetidos. Si ves tráfico normal pero la web va mal, igual es un problema de plugin o base de datos y no un ataque.

Paso 2: activa el modo bajo ataque en tu CDN

Si tienes Cloudflare mételo en modo Under Attack desde el dashboard, porque eso añade una pantalla de verificación JavaScript que filtra automáticamente a los bots. Lo notarás porque las visitas legítimas verán una pantalla de «Comprobando tu navegador» durante un par de segundos antes de acceder a tu web.

Si no tienes CDN y el ataque es serio, darte de alta en Cloudflare gratis y apuntar los DNS hacia él puede ser la solución más rápida. Tarda unas horas en propagarse, pero en cuanto lo hace el ataque se para en seco en la mayoría de los casos.

Paso 3: avisa al soporte de tu hosting

Un buen hosting tiene herramientas para identificar y bloquear ataques que tú desde fuera no tienes, así que abre un ticket, cuéntales lo que ves y pídeles que revisen. Muchas veces ellos ven patrones que tú no y pueden aplicar medidas a nivel de red.

Paso 4: bloquea lo que puedas bloquear

Si identificas IPs o rangos atacantes en los logs bloquéalas en htaccess con las reglas que hemos visto, y si el ataque viene de un país donde no tienes audiencia plantéate bloquear el país entero temporalmente (esto se hace en Cloudflare con una regla de firewall).

Paso 5: activa la página de mantenimiento si no te queda otra

Si nada de lo anterior frena el ataque, pon una página de mantenimiento estática para ganar tiempo. Una página HTML simple sin PHP ni base de datos la puede servir cualquier servidor bajo cualquier carga. No es una solución, es un parche para que al menos los usuarios que llegan vean algo en vez de un error.

Paso 6: documenta todo

Mientras pasa el ataque guarda capturas del escritorio, logs, IPs atacantes y horarios, porque lo vas a necesitar para el análisis posterior y, si llega el caso, para denunciarlo.

Después del ataque, el post-mortem

El ataque se ha acabado y tu web funciona otra vez, así que ahora toca aprender para que la próxima no te pille igual.

• Analiza los logs: ¿Qué URL fue el objetivo principal? ¿Qué IPs o User-Agent destacaron? ¿Qué hora del día fue? ¿Se nota un patrón?
• Revisa qué defensas funcionaron y cuáles no: Si tu WAF paró el 90% del tráfico, bien, pero si lo que te salvó fue activar el modo bajo ataque a lo loco, mala señal, porque la próxima vez igual no estás despierto para hacerlo.
• Ajusta las reglas: Añade las IPs atacantes a la lista negra permanente, y si el ataque fue a un endpoint concreto, refuérzalo.
• Considera si necesitas subir de plan: Si estabas en Cloudflare gratuito y el ataque casi te tumba, el plan Pro (unos 22 euros al mes) te da protección DDoS avanzada y un WAF mejor.
• Revisa si el DDoS fue cortina de humo: Comprueba logs de otros servicios, accesos al admin, usuarios nuevos y archivos modificados, para asegurarte de que mientras tú estabas apagando el incendio nadie entró por otro lado.
• Contrata ayuda profesional: Si después de todo te das cuenta de que necesitas ayuda aprende de la experiencia y no esperes al próximo desastre, déjate ayudar por alguien profesional que te ayude a protegerte, reforzar tu web y estar ahí cuando más lo necesites. Hay gente muy buena, y suele ser un servicio realmente barato si tienes en cuenta lo que obtienes frente a la (terrible) alternativa.

Lista rápida: protección anti-DDoS para WordPress

Te dejo el resumen de todo lo que hemos visto por capas, para que lo uses como guía de verificación en tu web.

Capa DNS y CDN

• Tengo Cloudflare (u otra CDN) configurado y apuntando los DNS.
• Tengo identificado cómo activar el modo bajo ataque si hiciera falta.
• Tengo reglas de firewall básicas configuradas en la CDN.

Capa hosting

• Estoy en un hosting WordPress con WAF propio y soporte 24/7.
• Tengo backups automáticos diarios.
• Tengo el número de soporte o el email a mano.

Capa servidor

• He bloqueado bots abusivos por User-Agent.
• He restringido los métodos HTTP a los necesarios.
• He protegido o bloqueado xmlrpc.php.
• He bloqueado el acceso externo a wp-cron.php y configurado cron real.
• He limitado el tamaño máximo de las peticiones.
• He protegido wp-login.php si mi IP es fija.
• He puesto reglas anti-hotlinking.

Capa WordPress

• Tengo un plugin de seguridad activo y configurado.
• Tengo 2FA activado para administradores.
• Tengo la URL del login cambiada.
• Tengo XML-RPC desactivado.
• Tengo la REST API protegida.
• Tengo límite de intentos de login configurado.
• Tengo pingbacks y trackbacks desactivados.
• Tengo WordPress, tema y todos los plugins actualizados.

Y hasta aquí

Tengo malas noticias, y es que los ataques DDoS no se evitan al 100%, y un ataque lo suficientemente grande te tumba aunque tengas todo bien configurado. Pero con las capas adecuadas la mayoría de ataques ni te enteras de que han pasado, y los que sí notas duran mucho menos y hacen mucho menos daño.

La clave está en no dejar nada a la improvisación.

Monta las defensas antes de necesitarlas, porque cuando estás bajo ataque no es el momento de ponerse a aprender cómo funciona Cloudflare o a editar .htaccess por primera vez. Empieza por las reglas básicas que he compartido, añade un buen plugin de seguridad y ten claro qué harías si mañana te pasa.

Si te surgen dudas con alguna configuración concreta déjame un comentario y lo vemos.

¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!