WordPress es uno de los gestores de contenidos m\u00e1s utilizados del mundo y, precisamente por eso, tambi\u00e9n recibe una cantidad enorme de tr\u00e1fico automatizado, escaneos, intentos de acceso y ataques dirigidos contra plugins, temas y configuraciones vulnerables.<\/p>\n\n\n\n
No hace falta tener una web especialmente popular para comprobarlo. Basta con revisar durante unos d\u00edas los registros de un servidor conectado a Internet para empezar a encontrar peticiones extra\u00f1as contra Una de las formas que m\u00e1s me gustan de reducir este tipo de ruido es colocar Cloudflare WAF delante de WordPress<\/strong>.<\/p>\n\n\n\n La raz\u00f3n es sencilla: buena parte del tr\u00e1fico puede analizarse antes de llegar realmente al servidor.<\/p>\n\n\n\n Eso significa que determinadas peticiones maliciosas pueden quedarse fuera antes de consumir recursos de Apache, Nginx, PHP, WordPress o la propia base de datos.<\/p>\n\n\n\n No considero Cloudflare WAF una soluci\u00f3n m\u00e1gica ni mucho menos una excusa para dejar de actualizar WordPress. Lo veo como algo bastante m\u00e1s \u00fatil: una capa adicional dentro de una estrategia de seguridad por niveles<\/strong>.<\/p>\n\n\n\n Y esa diferencia es importante.<\/p>\n\n\n\n En esta gu\u00eda voy a explicar qu\u00e9 puede aportar un firewall de aplicaciones web, qu\u00e9 ataques puede ayudar a frenar, c\u00f3mo combinar reglas administradas y personalizadas y qu\u00e9 precauciones conviene tener para no terminar bloqueando usuarios leg\u00edtimos.<\/p>\n\n\n\n WAF son las siglas de Web Application Firewall<\/strong>, o firewall de aplicaciones web.<\/p>\n\n\n\n Su funci\u00f3n consiste, de forma simplificada, en analizar las peticiones web que recibe una aplicaci\u00f3n y aplicar reglas sobre ellas.<\/p>\n\n\n\n En una instalaci\u00f3n protegida mediante Cloudflare, el tr\u00e1fico no tiene por qu\u00e9 viajar directamente desde el visitante hasta nuestro servidor de origen. Cuando el dominio utiliza el proxy de Cloudflare, las peticiones pasan primero por su infraestructura.<\/p>\n\n\n\n Es ah\u00ed donde podemos aplicar parte de la protecci\u00f3n.<\/p>\n\n\n\n Podemos visualizarlo de esta forma:<\/p>\n\n\n\n Visitante \u2192 Cloudflare \u2192 servidor web \u2192 PHP \u2192 WordPress \u2192 base de datos<\/strong><\/p>\n\n\n\n Sin una capa externa delante del servidor, una gran parte de las peticiones llega hasta nuestra infraestructura y tiene que ser procesada all\u00ed.<\/p>\n\n\n\n Con Cloudflare podemos intentar cortar determinados patrones antes.<\/p>\n\n\n\n Por ejemplo, imaginemos un bot realizando miles de solicitudes contra diferentes URLs de plugins vulnerables. Si conseguimos bloquear una parte importante de esas peticiones en Cloudflare, evitamos que todas ellas terminen convirti\u00e9ndose en trabajo para nuestro servidor.<\/p>\n\n\n\n Esta es, precisamente, una de las caracter\u00edsticas que m\u00e1s valoro.<\/p>\n\n\n\n En mi caso, no veo \u00fanicamente el WAF como una herramienta para \u201cbloquear hackers\u201d. Me interesa tambi\u00e9n porque puede impedir que determinadas peticiones basura recorran toda la cadena hasta PHP, Apache, Nginx o la base de datos.<\/p>\n\n\n\n Eso puede ser especialmente relevante en WordPress porque muchas solicitudes din\u00e1micas terminan ejecutando c\u00f3digo PHP y consultando informaci\u00f3n en la base de datos.<\/p>\n\n\n\n Cuanto antes podamos descartar tr\u00e1fico claramente no deseado, mejor.<\/p>\n\n\n\n Aqu\u00ed conviene evitar expectativas poco realistas.<\/p>\n\n\n\n Un WAF puede ayudarnos a identificar y bloquear determinados patrones de ataque, pero no convierte una instalaci\u00f3n vulnerable en una instalaci\u00f3n segura<\/strong>.<\/p>\n\n\n\n Si tenemos un plugin abandonado con una vulnerabilidad cr\u00edtica<\/a>, la soluci\u00f3n correcta sigue siendo actualizarlo, sustituirlo o eliminarlo.<\/p>\n\n\n\n Si utilizamos la contrase\u00f1a Y si el servidor est\u00e1 mal configurado o permite acceder directamente a la IP de origen salt\u00e1ndose completamente Cloudflare, tendremos otro problema distinto.<\/p>\n\n\n\n Por eso prefiero considerar el WAF como una barrera adicional:<\/p>\n\n\n\n La seguridad funciona mucho mejor cuando depende de varias capas y no de un \u00fanico control.<\/p>\n\n\n\n Una instalaci\u00f3n de WordPress est\u00e1 expuesta a muchos tipos de tr\u00e1fico hostil.<\/p>\n\n\n\n Algunos ataques buscan vulnerabilidades concretas. Otros intentan adivinar credenciales. Otros simplemente recorren Internet probando autom\u00e1ticamente miles de rutas conocidas.<\/p>\n\n\n\n Cloudflare WAF puede ser \u00fatil frente a varios de estos escenarios.<\/p>\n\n\n\n Una SQL injection<\/strong> intenta introducir instrucciones SQL manipuladas en datos que posteriormente son utilizados por una aplicaci\u00f3n para construir consultas contra su base de datos.<\/p>\n\n\n\n En una aplicaci\u00f3n correctamente desarrollada, este tipo de entrada deber\u00eda tratarse de forma segura.<\/p>\n\n\n\n El problema aparece cuando existe una vulnerabilidad en WordPress, un plugin, un tema o cualquier componente que procese esos datos de manera insegura.<\/p>\n\n\n\n Un WAF puede reconocer determinados patrones caracter\u00edsticos de este tipo de ataques e impedir que algunas peticiones lleguen a la aplicaci\u00f3n.<\/p>\n\n\n\n Eso a\u00f1ade una barrera interesante, especialmente durante el intervalo que puede existir entre la publicaci\u00f3n de una vulnerabilidad y su correcci\u00f3n efectiva en todos los sitios afectados.<\/p>\n\n\n\n Y ese intervalo me parece importante.<\/p>\n\n\n\n Una instalaci\u00f3n puede estar perfectamente actualizada hoy y descubrir ma\u00f1ana que uno de sus plugins tiene una vulnerabilidad reci\u00e9n publicada. El WAF no sustituye el parche, pero tener una protecci\u00f3n adicional delante del servidor puede reducir la exposici\u00f3n frente a determinados intentos de explotaci\u00f3n.<\/p>\n\n\n\n Los ataques XSS o Cross-Site Scripting<\/strong> buscan introducir contenido que termine ejecut\u00e1ndose en el navegador de otros usuarios.<\/p>\n\n\n\n De nuevo, el origen del problema suele estar en la aplicaci\u00f3n: datos que se aceptan o muestran sin el tratamiento apropiado.<\/p>\n\n\n\n Las reglas de un WAF pueden reconocer ciertos patrones sospechosos y bloquear solicitudes que coincidan con ellos.<\/p>\n\n\n\n No significa que cualquier vulnerabilidad XSS quede autom\u00e1ticamente neutralizada.<\/p>\n\n\n\n Lo que significa es que disponemos de otra capa capaz de interceptar parte de los intentos de explotaci\u00f3n conocidos o reconocibles.<\/p>\n\n\n\n Este es probablemente uno de los escenarios m\u00e1s importantes en WordPress.<\/p>\n\n\n\n Los bots no necesitan saber qu\u00e9 plugins tenemos instalados antes de empezar.<\/p>\n\n\n\n Muchos simplemente prueban.<\/p>\n\n\n\n Solicitan rutas pertenecientes a plugins conocidos, intentan ejecutar endpoints vulnerables, buscan archivos expuestos y repiten el proceso contra miles o millones de dominios.<\/p>\n\n\n\n Podemos encontrarnos, por ejemplo, con intentos dirigidos contra componentes que nunca hemos instalado.<\/p>\n\n\n\n Eso ocurre porque el atacante no est\u00e1 investigando nuestra web manualmente. Est\u00e1 automatizando una lista de pruebas.<\/p>\n\n\n\n Las reglas administradas de un WAF pueden ayudarnos frente a determinados patrones conocidos, mientras que las reglas personalizadas nos permiten reaccionar cuando detectamos algo espec\u00edfico en nuestros propios registros.<\/p>\n\n\n\n No todo bot es malicioso.<\/p>\n\n\n\n Los buscadores utilizan bots. Los servicios de monitorizaci\u00f3n utilizan bots. Algunas integraciones leg\u00edtimas tambi\u00e9n funcionan de forma automatizada.<\/p>\n\n\n\n El problema es el tr\u00e1fico automatizado que escanea rutas agresivamente, busca vulnerabilidades o dispara cantidades desproporcionadas de solicitudes.<\/p>\n\n\n\n Aqu\u00ed hay que ser prudente.<\/p>\n\n\n\n Bloquear cualquier petici\u00f3n que \u201cparezca un bot\u201d puede terminar perjudicando servicios leg\u00edtimos.<\/p>\n\n\n\n Por eso, siempre que puedo, prefiero construir las reglas partiendo del comportamiento observado y no de una regla gen\u00e9rica del estilo \u201cbloquear todos los bots\u201d.<\/p>\n\n\n\n Un atacante puede enviar intentos repetidos de autenticaci\u00f3n para probar contrase\u00f1as comunes, combinaciones obtenidas de filtraciones o listas automatizadas.<\/p>\n\n\n\n Cloudflare puede convertirse aqu\u00ed en una primera barrera.<\/p>\n\n\n\n Dependiendo del caso, podemos aplicar restricciones, desaf\u00edos o l\u00edmites sobre determinadas solicitudes antes de que cada intento termine llegando al sistema de autenticaci\u00f3n de WordPress.<\/p>\n\n\n\n Eso no elimina la necesidad de utilizar contrase\u00f1as fuertes ni autenticaci\u00f3n de dos factores.<\/p>\n\n\n\n Lo que hace es reducir la cantidad de tr\u00e1fico hostil que consigue llegar hasta ese punto.<\/p>\n\n\n\n Uno de los errores que veo m\u00e1s f\u00e1ciles de cometer consiste en entrar al panel y empezar inmediatamente a crear reglas muy agresivas.<\/p>\n\n\n\n Yo prefiero justo lo contrario.<\/p>\n\n\n\n Empiezo con una base razonable, observo y solo despu\u00e9s endurezo.<\/p>\n\n\n\n Las reglas administradas son una de las partes que m\u00e1s me interesan de Cloudflare.<\/p>\n\n\n\n No todo administrador de una web tiene tiempo o conocimientos para analizar manualmente cada petici\u00f3n HTTP y construir desde cero firmas contra SQL injection, XSS o t\u00e9cnicas similares.<\/p>\n\n\n\n Las Managed Rules<\/strong> permiten partir de una base que el proveedor mantiene y actualiza.<\/p>\n\n\n\n Para un proyecto peque\u00f1o o mediano me parece especialmente pr\u00e1ctico.<\/p>\n\n\n\n No necesitamos convertirnos en especialistas en seguridad ofensiva para disponer de una primera capa de filtrado.<\/p>\n\n\n\n Esto no significa activar absolutamente todo sin mirar.<\/p>\n\n\n\n El comportamiento exacto de las reglas disponibles y las opciones que aparecen en el panel pueden variar seg\u00fan el plan y los cambios que Cloudflare realice en su producto.<\/p>\n\n\n\n Por eso conviene revisar qu\u00e9 reglas est\u00e1n disponibles en nuestra cuenta y observar qu\u00e9 efecto est\u00e1n teniendo.<\/p>\n\n\n\n Las reglas administradas buscan identificar familias conocidas de ataques y patrones sospechosos.<\/p>\n\n\n\n Este tipo de protecci\u00f3n es especialmente interesante para amenazas gen\u00e9ricas que no dependen exclusivamente de nuestra propia web.<\/p>\n\n\n\n En lugar de escribir manualmente una regla para cada posible forma de SQL injection, por ejemplo, podemos apoyarnos en conjuntos de reglas dise\u00f1ados espec\u00edficamente para detectar ese tipo de actividad.<\/p>\n\n\n\n Despu\u00e9s podemos a\u00f1adir nuestra capa espec\u00edfica para WordPress.<\/p>\n\n\n\n Ah\u00ed es donde entran las Custom Rules.<\/p>\n\n\n\n No configurar\u00eda nunca un WAF con la mentalidad de \u201ccuanto m\u00e1s bloquee, mejor\u201d.<\/p>\n\n\n\n Un firewall demasiado agresivo puede convertirse en un problema operativo.<\/p>\n\n\n\n Podemos bloquear formularios, integraciones, usuarios leg\u00edtimos o llamadas necesarias para alguna funcionalidad.<\/p>\n\n\n\n Por eso los registros y eventos son fundamentales.<\/p>\n\n\n\n Antes de endurecer una regla intento responder tres preguntas:<\/p>\n\n\n\n Cuanto m\u00e1s espec\u00edfica sea la respuesta, mejor ser\u00e1 normalmente la regla.<\/p>\n\n\n\n No considero las reglas administradas y las reglas personalizadas opciones enfrentadas.<\/p>\n\n\n\n Para m\u00ed, el verdadero potencial aparece cuando utilizamos ambas juntas<\/strong>.<\/p>\n\n\n\n Las reglas administradas funcionan especialmente bien como protecci\u00f3n general.<\/p>\n\n\n\n Su ventaja principal es que no necesitamos conocer previamente cada patr\u00f3n exacto que queremos bloquear.<\/p>\n\n\n\n Podemos pensar en ellas como una capa mantenida externamente contra categor\u00edas de ataques conocidas.<\/p>\n\n\n\n Nos proporcionan una base.<\/p>\n\n\n\n Y esa base es especialmente valiosa en instalaciones que no cuentan con una persona dedicada exclusivamente a revisar logs y escribir reglas de firewall.<\/p>\n\n\n\n Las reglas personalizadas entran en juego cuando conocemos mejor nuestro caso.<\/p>\n\n\n\n Supongamos que observamos cientos de peticiones contra una URL concreta.<\/p>\n\n\n\n O detectamos un bot que solicita determinadas rutas con un patr\u00f3n muy identificable.<\/p>\n\n\n\n O queremos proteger una zona administrativa que sabemos que solo utilizan ciertas personas.<\/p>\n\n\n\n En esos escenarios, una regla personalizada permite adaptar el firewall a nuestra instalaci\u00f3n.<\/p>\n\n\n\n Eso me parece mucho m\u00e1s interesante que copiar veinte reglas encontradas por Internet.<\/p>\n\n\n\n Una regla personalizada deber\u00eda responder a una necesidad real.<\/p>\n\n\n\n Mi enfoque ser\u00eda:<\/p>\n\n\n\n reglas administradas para la protecci\u00f3n general + reglas personalizadas para el contexto espec\u00edfico de nuestra web.<\/strong><\/p>\n\n\n\n Las primeras intentan cubrir ataques que podr\u00edan afectar a miles de aplicaciones.<\/p>\n\n\n\n Las segundas responden a lo que sabemos de nuestro WordPress.<\/p>\n\n\n\n Si adem\u00e1s utilizamos logs y eventos para alimentar esas decisiones, la configuraci\u00f3n mejora bastante.<\/p>\n\n\n\n No necesitamos adivinar constantemente qu\u00e9 est\u00e1 pasando. Podemos observarlo.<\/p>\n\n\n\n La sintaxis concreta del panel puede cambiar con el tiempo, por lo que prefiero centrarme en la l\u00f3gica que deber\u00eda seguir cada regla.<\/p>\n\n\n\n Copiar una expresi\u00f3n sin comprenderla suele ser peor que aprender qu\u00e9 queremos conseguir.<\/p>\n\n\n\n Podemos considerar varias estrategias:<\/p>\n\n\n\n No recomiendo bloquear indiscriminadamente el acceso a todo el mundo salvo que nuestro escenario permita hacerlo.<\/p>\n\n\n\n Por ejemplo, restringir por una \u00fanica IP puede ser muy efectivo para una instalaci\u00f3n administrada exclusivamente desde una oficina con IP fija.<\/p>\n\n\n\n Pero puede ser un desastre si los administradores trabajan desde conexiones m\u00f3viles o ubicaciones cambiantes.<\/p>\n\n\n\n La configuraci\u00f3n debe adaptarse al proyecto.<\/p>\n\n\n\n Podemos aplicar controles adicionales, aunque hay que recordar que WordPress y sus plugins pueden utilizar rutas relacionadas con el \u00e1rea administrativa para distintas funciones.<\/p>\n\n\n\n Por eso bloquear el directorio completo con una condici\u00f3n demasiado amplia puede romper funcionalidades.<\/p>\n\n\n\n Aqu\u00ed es especialmente importante probar.<\/p>\n\n\n\n Una regla aparentemente sencilla puede tener efectos secundarios que no son evidentes hasta que alguien intenta editar contenido, subir un archivo o utilizar determinada integraci\u00f3n.<\/p>\n\n\n\n \u00bfHay que bloquearlo siempre?<\/p>\n\n\n\n No necesariamente.<\/p>\n\n\n\n Primero tenemos que saber si nuestra web utiliza alguna funcionalidad que dependa de \u00e9l.<\/p>\n\n\n\n Si tenemos claro que no lo necesitamos, restringir el acceso puede reducir superficie innecesaria.<\/p>\n\n\n\n Si s\u00ed lo utilizamos, habr\u00e1 que plantear una protecci\u00f3n m\u00e1s selectiva.<\/p>\n\n\n\n La regla general aqu\u00ed vuelve a ser la misma: no bloquear por copiar una recomendaci\u00f3n; bloquear porque entendemos nuestro caso<\/strong>.<\/p>\n\n\n\n Esta es una de las \u00e1reas donde m\u00e1s valor tienen los logs.<\/p>\n\n\n\n Imaginemos que encontramos peticiones continuas contra:<\/p>\n\n\n\n Podemos estudiar si esas peticiones comparten caracter\u00edsticas \u00fatiles para construir una regla.<\/p>\n\n\n\n A veces ser\u00e1 la ruta.<\/p>\n\n\n\n Otras veces ser\u00e1 la frecuencia.<\/p>\n\n\n\n O el origen.<\/p>\n\n\n\n O varias se\u00f1ales combinadas.<\/p>\n\n\n\n Lo importante es evitar una condici\u00f3n tan gen\u00e9rica que termine bloqueando tr\u00e1fico leg\u00edtimo.<\/p>\n\n\n\n Esta es una de las aplicaciones que m\u00e1s me gustan de las reglas personalizadas.<\/p>\n\n\n\n Veo algo extra\u00f1o en los registros.<\/p>\n\n\n\n Lo analizo.<\/p>\n\n\n\n Compruebo si se repite.<\/p>\n\n\n\n Determino qu\u00e9 caracter\u00edstica permite distinguirlo.<\/p>\n\n\n\n Y entonces creo una protecci\u00f3n.<\/p>\n\n\n\n Ese flujo me parece mucho m\u00e1s \u00fatil que cargar una lista enorme de reglas preventivas sin saber si alguna se aplica realmente a nuestra web.<\/p>\n\n\n\n El WAF pasa as\u00ed de ser una configuraci\u00f3n est\u00e1tica a convertirse en una herramienta que podemos adaptar a medida que cambia el tr\u00e1fico.<\/p>\n\n\n\n No todas las solicitudes sospechosas tienen que terminar con un bloqueo.<\/p>\n\n\n\n Esta distinci\u00f3n es importante porque ayuda a reducir falsos positivos.<\/p>\n\n\n\n El bloqueo tiene sentido cuando estamos suficientemente seguros de que el tr\u00e1fico no deber\u00eda permitirse.<\/p>\n\n\n\n Por ejemplo, si detectamos una ruta que no existe en nuestra aplicaci\u00f3n y \u00fanicamente recibe tr\u00e1fico de explotaci\u00f3n automatizada, la decisi\u00f3n puede ser relativamente sencilla.<\/p>\n\n\n\n Lo mismo ocurre cuando hemos identificado con mucha precisi\u00f3n un patr\u00f3n malicioso.<\/p>\n\n\n\n Pero cuanto m\u00e1s gen\u00e9rica sea la condici\u00f3n, mayor precauci\u00f3n deber\u00edamos tener antes de aplicar un bloqueo definitivo.<\/p>\n\n\n\n Un desaf\u00edo puede resultar interesante cuando queremos elevar la dificultad para el tr\u00e1fico automatizado sin cerrar inmediatamente la puerta a cualquier usuario leg\u00edtimo que coincida con la condici\u00f3n.<\/p>\n\n\n\n Eso puede ser especialmente \u00fatil cuando trabajamos con se\u00f1ales que no son completamente deterministas.<\/p>\n\n\n\n Por ejemplo, determinado comportamiento puede ser habitual en bots, pero no exclusivo de ellos.<\/p>\n\n\n\n En lugar de bloquear directamente, podemos utilizar una acci\u00f3n menos definitiva y observar resultados.<\/p>\n\n\n\n Los falsos positivos no son un detalle menor.<\/p>\n\n\n\n Una regla que bloquea el 99 % del tr\u00e1fico malicioso pero tambi\u00e9n impide comprar al 2 % de nuestros clientes puede ser una mala regla.<\/p>\n\n\n\n Por eso prefiero aplicar cambios progresivos.<\/p>\n\n\n\n Primero observar.<\/p>\n\n\n\n Despu\u00e9s limitar.<\/p>\n\n\n\n Despu\u00e9s revisar.<\/p>\n\n\n\n Y finalmente endurecer, si los datos respaldan la decisi\u00f3n.<\/p>\n\n\n\n La seguridad debe proteger el negocio, no impedir que funcione.<\/p>\n\n\n\n Configurar el WAF es solo una parte del trabajo.<\/p>\n\n\n\n La otra consiste en comprobar qu\u00e9 est\u00e1 haciendo.<\/p>\n\n\n\n Los eventos de seguridad<\/a> nos permiten comprender qu\u00e9 solicitudes han activado determinadas protecciones.<\/p>\n\n\n\n Cuando una funci\u00f3n deja de responder despu\u00e9s de modificar el firewall, este deber\u00eda ser uno de los primeros lugares que revisemos.<\/p>\n\n\n\n Tenemos que buscar correlaciones:<\/p>\n\n\n\n Con esa informaci\u00f3n podemos ajustar mucho mejor.<\/p>\n\n\n\n Una buena pr\u00e1ctica consiste en evitar introducir muchas reglas agresivas simult\u00e1neamente.<\/p>\n\n\n\n Si hacemos diez cambios y algo deja de funcionar, tendremos que descubrir cu\u00e1l de los diez lo ha provocado.<\/p>\n\n\n\n Si trabajamos de forma progresiva, la causa es mucho m\u00e1s f\u00e1cil de identificar.<\/p>\n\n\n\n Yo prefiero:<\/p>\n\n\n\n Es menos espectacular que pegar veinte reglas de golpe, pero suele producir una configuraci\u00f3n bastante m\u00e1s fiable.<\/p>\n\n\n\n Lo primero es evitar convertir la excepci\u00f3n en un agujero enorme.<\/p>\n\n\n\n Si una regla bloquea una funcionalidad concreta, no deber\u00edamos solucionar el problema desactivando todo el WAF sin investigar.<\/p>\n\n\n\n Hay que identificar:<\/p>\n\n\n\n Las excepciones peque\u00f1as son preferibles a las excepciones globales.<\/p>\n\n\n\n Este es probablemente el punto m\u00e1s importante de toda la gu\u00eda.<\/p>\n\n\n\n Uno de los errores m\u00e1s f\u00e1ciles de cometer es pensar que activar Cloudflare WAF convierte autom\u00e1ticamente una web en segura.<\/p>\n\n\n\n No funciona as\u00ed.<\/p>\n\n\n\n Si aparece una actualizaci\u00f3n de seguridad<\/a>, hay que aplicarla de acuerdo con nuestra pol\u00edtica de mantenimiento y pruebas.<\/p>\n\n\n\n No tiene sentido dejar una vulnerabilidad conocida durante semanas pensando que el WAF bloquear\u00e1 cualquier forma posible de explotarla.<\/p>\n\n\n\n El firewall es una capa de apoyo.<\/p>\n\n\n\n La correcci\u00f3n del problema sigue siendo prioritaria.<\/p>\n\n\n\n Las cuentas con permisos elevados necesitan especial cuidado.<\/p>\n\n\n\n Algunas medidas b\u00e1sicas son:<\/p>\n\n\n\n Muchas intrusiones no necesitan una vulnerabilidad sofisticada si el atacante consigue credenciales v\u00e1lidas.<\/p>\n\n\n\n La autenticaci\u00f3n en dos pasos a\u00f1ade otra barrera importante.<\/p>\n\n\n\n Incluso si una contrase\u00f1a termina expuesta, disponer de un segundo factor puede impedir que esa credencial sea suficiente por s\u00ed sola.<\/p>\n\n\n\n Cloudflare puede ayudar a reducir intentos hostiles antes de que lleguen a WordPress, pero eso no elimina la necesidad de proteger correctamente las cuentas.<\/p>\n\n\n\n Hay otro punto que a veces se olvida.<\/p>\n\n\n\n Si colocamos Cloudflare delante pero nuestro servidor de origen sigue siendo f\u00e1cilmente accesible de forma directa, parte de la estrategia puede perder efectividad.<\/p>\n\n\n\n La configuraci\u00f3n de red, servidor web y servicios expuestos sigue importando.<\/p>\n\n\n\n Tambi\u00e9n importa mantener actualizado:<\/p>\n\n\n\n Cloudflare protege determinadas capas. No reemplaza toda la infraestructura.<\/p>\n\n\n\n Una estrategia de seguridad sin copias de seguridad me parece incompleta.<\/p>\n\n\n\n Las copias deben existir antes de necesitarlas.<\/p>\n\n\n\n Y, cuando el proyecto lo justifique, conviene comprobar tambi\u00e9n que pueden restaurarse.<\/p>\n\n\n\n Si algo termina saliendo mal \u2014una intrusi\u00f3n, un error humano, una actualizaci\u00f3n defectuosa o cualquier otro incidente\u2014 disponer de una recuperaci\u00f3n fiable puede marcar la diferencia.<\/p>\n\n\n\n \u00bfNecesita absolutamente cualquier WordPress una configuraci\u00f3n avanzada de WAF?<\/p>\n\n\n\n No necesariamente.<\/p>\n\n\n\n Pero hay escenarios donde su utilidad se vuelve mucho m\u00e1s evidente.<\/p>\n\n\n\n A medida que crece el tr\u00e1fico, tambi\u00e9n aumenta el impacto potencial del tr\u00e1fico basura.<\/p>\n\n\n\n Si podemos eliminar parte de ese volumen antes de alcanzar el origen, reducimos trabajo innecesario en nuestra infraestructura.<\/p>\n\n\n\n No todo se trata de seguridad pura.<\/p>\n\n\n\n Tambi\u00e9n estamos hablando de eficiencia.<\/p>\n\n\n\n Hay webs que aparecen constantemente en esc\u00e1neres autom\u00e1ticos.<\/p>\n\n\n\n Podemos ver intentos contra docenas de vulnerabilidades que ni siquiera afectan a nuestra instalaci\u00f3n.<\/p>\n\n\n\n Ese tr\u00e1fico consume recursos y ensucia los registros.<\/p>\n\n\n\n Tener una barrera delante puede ayudarnos a reducir una parte importante de ese ruido.<\/p>\n\n\n\n Si No deber\u00edamos esperar necesariamente a tener un incidente.<\/p>\n\n\n\n Si el patr\u00f3n ya es visible, podemos responder.<\/p>\n\n\n\n Cuanto mayor sea la importancia de la web, m\u00e1s sentido tiene trabajar con varias capas.<\/p>\n\n\n\n Una tienda online, una web que almacena datos importantes o un proyecto que depende econ\u00f3micamente de su disponibilidad tienen incentivos claros para reducir riesgos.<\/p>\n\n\n\n En sitios WordPress que reciben bastante tr\u00e1fico, sufren intentos constantes de acceso o empiezan a aparecer repetidamente en el radar de bots y esc\u00e1neres autom\u00e1ticos es donde, en mi experiencia, una capa como Cloudflare puede marcar una diferencia especialmente interesante.<\/p>\n\n\n\n Una configuraci\u00f3n de seguridad tambi\u00e9n puede fallar por exceso.<\/p>\n\n\n\n Estos son algunos errores que intentar\u00eda evitar.<\/p>\n\n\n\n No basta con configurar el firewall una vez y asumir que todo funciona perfectamente.<\/p>\n\n\n\n El tr\u00e1fico cambia.<\/p>\n\n\n\n WordPress cambia.<\/p>\n\n\n\n Los plugins cambian.<\/p>\n\n\n\n Nuestra propia web cambia.<\/p>\n\n\n\n Conviene revisar peri\u00f3dicamente qu\u00e9 est\u00e1 ocurriendo, especialmente despu\u00e9s de modificaciones importantes.<\/p>\n\n\n\n Internet est\u00e1 lleno de colecciones de \u201clas mejores reglas para Cloudflare\u201d.<\/p>\n\n\n\n Algunas pueden ser \u00fatiles.<\/p>\n\n\n\n Otras pueden no tener ning\u00fan sentido para nuestra instalaci\u00f3n.<\/p>\n\n\n\n Copiar una expresi\u00f3n sin saber qu\u00e9 condici\u00f3n est\u00e1 evaluando puede terminar bloqueando funcionalidades importantes.<\/p>\n\n\n\n Antes de aplicar una regla deber\u00edamos ser capaces de explicar con palabras sencillas:<\/p>\n\n\n\n \u201cQuiero bloquear este tr\u00e1fico porque\u2026\u201d<\/strong><\/p>\n\n\n\n Si no podemos terminar la frase, probablemente deber\u00edamos estudiar mejor la regla.<\/p>\n\n\n\n M\u00e1s bloqueo no significa autom\u00e1ticamente m\u00e1s seguridad.<\/p>\n\n\n\n Una pol\u00edtica demasiado agresiva puede generar:<\/p>\n\n\n\n Me parece mucho m\u00e1s sensato endurecer progresivamente.<\/p>\n\n\n\n Este es probablemente el error m\u00e1s peligroso.<\/p>\n\n\n\n El WAF puede ser capaz de impedir ciertos intentos de explotaci\u00f3n, pero no debemos utilizarlo como justificaci\u00f3n para mantener software vulnerable.<\/p>\n\n\n\n Una vulnerabilidad debe corregirse en su origen siempre que sea posible.<\/p>\n\n\n\n Cloudflare WAF me parece una de las herramientas m\u00e1s interesantes que podemos colocar delante de WordPress cuando queremos mejorar la seguridad sin convertir toda la protecci\u00f3n en una configuraci\u00f3n compleja dentro del servidor.<\/p>\n\n\n\n Su principal ventaja, desde mi punto de vista, es precisamente su posici\u00f3n.<\/p>\n\n\n\n Puede analizar parte del tr\u00e1fico antes de que llegue a Apache, Nginx, PHP, WordPress o la base de datos.<\/p>\n\n\n\n Adem\u00e1s, las reglas administradas ofrecen un punto de partida accesible incluso cuando no queremos construir toda nuestra protecci\u00f3n manualmente.<\/p>\n\n\n\n Pero donde veo realmente su potencial es en la combinaci\u00f3n:<\/p>\n\n\n\n Managed Rules + Custom Rules + observaci\u00f3n de logs.<\/strong><\/p>\n\n\n\n Las reglas administradas nos proporcionan una base.<\/p>\n\n\n\n Las personalizadas nos permiten adaptar la defensa a nuestra instalaci\u00f3n.<\/p>\n\n\n\n Y los registros nos dicen qu\u00e9 est\u00e1 ocurriendo realmente.<\/p>\n\n\n\n Aun as\u00ed, no confiar\u00eda nunca toda la seguridad de WordPress al WAF.<\/p>\n\n\n\nwp-login.php<\/code>, xmlrpc.php<\/code>, plugins que ni siquiera tenemos instalados o rutas utilizadas habitualmente por herramientas autom\u00e1ticas de reconocimiento.<\/p>\n\n\n\n
\n\n\n\nQu\u00e9 es Cloudflare WAF y por qu\u00e9 tiene sentido delante de WordPress<\/h2>\n\n\n\n
Qu\u00e9 ocurre con una petici\u00f3n antes de llegar a WordPress<\/h3>\n\n\n\n
Qu\u00e9 puede hacer un WAF y qu\u00e9 no puede hacer<\/h3>\n\n\n\n
admin123<\/code>, Cloudflare tampoco convierte esa contrase\u00f1a en segura.<\/p>\n\n\n\n\n
\n\n\n\nQu\u00e9 ataques puede ayudar a bloquear Cloudflare WAF en WordPress<\/h2>\n\n\n\n
Ataques de SQL injection<\/h3>\n\n\n\n
Cross-Site Scripting o XSS<\/h3>\n\n\n\n
Intentos de explotaci\u00f3n de plugins y temas vulnerables<\/h3>\n\n\n\n
Bots, esc\u00e1neres y tr\u00e1fico automatizado<\/h3>\n\n\n\n
Fuerza bruta y ataques contra el acceso de WordPress<\/h3>\n\n\n\n
wp-login.php<\/code> es uno de los objetivos m\u00e1s evidentes.<\/p>\n\n\n\n
\n\n\n\nC\u00f3mo empezar a proteger WordPress con Cloudflare WAF<\/h2>\n\n\n\n
Activa primero las reglas administradas<\/h3>\n\n\n\n
Cloudflare Managed Rules y reglas orientadas a amenazas web<\/h3>\n\n\n\n
Revisa los eventos antes de endurecer la configuraci\u00f3n<\/h3>\n\n\n\n
\n
\n\n\n\nManaged Rules vs Custom Rules: cu\u00e1ndo utilizar cada una<\/h2>\n\n\n\n
Qu\u00e9 solucionan las reglas administradas<\/h3>\n\n\n\n
Cu\u00e1ndo merece la pena crear una regla personalizada<\/h3>\n\n\n\n
Por qu\u00e9 combinar ambos tipos de reglas<\/h3>\n\n\n\n
\n\n\n\nReglas de Cloudflare \u00fatiles para proteger WordPress<\/h2>\n\n\n\n
C\u00f3mo proteger wp-login.php<\/h3>\n\n\n\n
wp-login.php<\/code> es un candidato evidente para aplicar controles adicionales.<\/p>\n\n\n\n\n
C\u00f3mo proteger wp-admin<\/h3>\n\n\n\n
\/wp-admin\/<\/code> merece un razonamiento parecido.<\/p>\n\n\n\nQu\u00e9 hacer con xmlrpc.php<\/h3>\n\n\n\n
xmlrpc.php<\/code> lleva a\u00f1os apareciendo en conversaciones sobre seguridad WordPress porque puede utilizarse para determinadas funciones remotas y tambi\u00e9n ha sido objetivo habitual de abuso automatizado.<\/p>\n\n\n\nC\u00f3mo filtrar bots y esc\u00e1neres agresivos<\/h3>\n\n\n\n
\n
C\u00f3mo reaccionar ante un patr\u00f3n de ataque detectado en los logs<\/h3>\n\n\n\n
\n\n\n\nBloquear, desafiar o permitir: qu\u00e9 acci\u00f3n elegir<\/h2>\n\n\n\n
Cu\u00e1ndo utilizar Block<\/h3>\n\n\n\n
Cu\u00e1ndo es mejor utilizar un Challenge<\/h3>\n\n\n\n
C\u00f3mo evitar bloquear visitantes leg\u00edtimos<\/h3>\n\n\n\n
\n\n\n\nC\u00f3mo detectar y corregir falsos positivos<\/h2>\n\n\n\n
Revisar eventos de seguridad<\/h3>\n\n\n\n
\n
Probar las reglas de forma progresiva<\/h3>\n\n\n\n
\n
Qu\u00e9 hacer cuando una regla rompe una funci\u00f3n de WordPress<\/h3>\n\n\n\n
\n
\n\n\n\nCloudflare WAF no sustituye la seguridad de WordPress<\/h2>\n\n\n\n
Mant\u00e9n WordPress, plugins y temas actualizados<\/h3>\n\n\n\n
Protege las cuentas administrativas<\/h3>\n\n\n\n
\n
A\u00f1ade 2FA y contrase\u00f1as seguras<\/h3>\n\n\n\n
Mant\u00e9n tambi\u00e9n protegido el servidor de origen<\/h3>\n\n\n\n
\n
Copias de seguridad como \u00faltima capa de defensa<\/h3>\n\n\n\n
\n\n\n\nCu\u00e1ndo merece especialmente la pena usar Cloudflare WAF<\/h2>\n\n\n\n
Sitios con mucho tr\u00e1fico<\/h3>\n\n\n\n
WordPress atacados constantemente por bots<\/h3>\n\n\n\n
Webs que reciben intentos de acceso repetidos<\/h3>\n\n\n\n
wp-login.php<\/code> est\u00e1 recibiendo intentos constantes, merece la pena estudiar qu\u00e9 controles podemos a\u00f1adir.<\/p>\n\n\n\nProyectos con mayor exposici\u00f3n p\u00fablica<\/h3>\n\n\n\n
\n\n\n\nErrores habituales al configurar Cloudflare WAF en WordPress<\/h2>\n\n\n\n
Activar reglas y olvidarse de revisar los eventos<\/h3>\n\n\n\n
Copiar reglas de otras webs sin entenderlas<\/h3>\n\n\n\n
Bloquear demasiado tr\u00e1fico desde el principio<\/h3>\n\n\n\n
\n
Pensar que el WAF hace innecesarias las actualizaciones<\/h3>\n\n\n\n
\n\n\n\nCloudflare como primera barrera, no como \u00fanica defensa<\/h2>\n\n\n\n