Cloudflare: desactivada «desafío habla no hispana» — retaba a todo el mundo salvo España y LatAm, con un 0,9 % de éxito #220

Open
opened 2026-08-28 08:59:23 +00:00 by inma · 1 comment
Collaborator

Qué pasaba

Una lectora de 83 años de Bonn (Alemania) llevaba semanas sin poder leer la carta. Contó que al abrir cualquier enlace le salía «una ruedita que gira», después la pantalla de «confirma que eres humano», y al superarla volvía a empezar, una y otra vez, sin llegar nunca al artículo. Llegó a escribir a Brevo pensando que el problema estaba en el envío, y le confirmaron que por su parte no había restricción.

No era Brevo. Era nuestro Cloudflare.

La regla

Custom rule «desafío habla no hispana», acción Managed Challenge, orden 5. Su expresión, traducida:

Reta a todo el que entre desde África, Antártida, Asia, Oceanía o Tor; desde Europa salvo España; y desde América del Norte salvo México, El Salvador, Guatemala, Cuba, Puerto Rico, Nicaragua, Costa Rica y Honduras.

Es decir: el mundo entero excepto España y la Latinoamérica hispanohablante.

El dato que la condena

Eventos acumulados 58.600
CSR (Challenge Solve Rate) 0,9 %

El CSR es el porcentaje de retados que consigue superar la prueba. Un 0,9 % significa que de cada 1.000 personas retadas, solo 9 lograban entrar; las otras 991 se quedaban fuera. Sobre 58.600 eventos, hablamos de unas 58.100 visitas que no llegaron a su destino.

Eso no es un filtro: es un muro. Y por volumen era la regla que más tráfico tocaba de las cinco (58,6k frente a los 25,8k de «bloquear bots 1»).

Y contradice de lleno el trabajo de traducción: se pagan y se producen cada semana traducciones y audios a EN/FR/IT/PT para un público —Europa no española, África, Asia, Brasil, Filipinas— al que la propia web le cerraba la puerta al llegar. Sin contar a los hispanohablantes que viven fuera, que son muchos.

Por qué se quedaba en bucle y no solo fallaba una vez

Un Managed Challenge se supera una vez y deja pasar, porque el navegador guarda la credencial (cf_clearance) que Cloudflare le entrega. En un iPad eso se rompe con facilidad por dos motivos:

  • Relay privado de iCloud: va cambiando la IP de salida y la credencial va atada a la IP, así que cada recarga la invalida.
  • Cookies bloqueadas en Safari: sin poder guardar la cookie, la prueba no se puede completar nunca.

De ahí el bucle infinito que describía ella. Con la regla quitada, el problema desaparece de raíz porque ya no hay reto que superar.

Qué se ha hecho (28/08/2026)

  • La regla queda desactivada, no borrada (tres puntos → Disable). Si aparece un ataque real, se reactiva con un clic y con datos en la mano.
  • Las otras cuatro reglas siguen activas: «Permitir bing, google, yahoo», «Permitir crawlers» (la que arreglamos en junio para Facebook), «bloquear bots 1» y «bloquear bots 2». Todas filtran por user agent, que sí distingue a un bot de una persona; el país no distingue nada.

Nota de navegación, que despista: en el panel nuevo de Cloudflare el WAF se llama ahora Security → Security rules.

Pendiente / a decidir

  1. Vigilar Security → Events unos días. Si no aparece tráfico malo real, la regla se borra definitivamente.
  2. Montar la regla de rate limiting sobre /wp-login.php y /xmlrpc.php, que es donde de verdad pegan los bots. Hay derecho a una en el plan y está sin estrenar (Rate limiting rules: 0/1). Quedó apuntado en junio, cuando lo de Facebook, y nunca se hizo.
  3. ¿Sabes por qué se creó esta regla? La puso un amigo programador de Inma hace tiempo, para frenar ataques. Si hubo un incidente concreto detrás, conviene conocerlo antes de borrarla del todo: quizá lo que hace falta es una versión mucho más estrecha (solo Tor, o solo sobre las rutas de login).

He omitido a propósito el nombre completo y el correo de la lectora.

## Qué pasaba Una **lectora de 83 años de Bonn (Alemania)** llevaba semanas sin poder leer la carta. Contó que al abrir cualquier enlace le salía «una ruedita que gira», después la pantalla de «confirma que eres humano», y al superarla **volvía a empezar, una y otra vez, sin llegar nunca al artículo**. Llegó a escribir a Brevo pensando que el problema estaba en el envío, y le confirmaron que por su parte no había restricción. No era Brevo. Era nuestro Cloudflare. ## La regla Custom rule **«desafío habla no hispana»**, acción **Managed Challenge**, orden 5. Su expresión, traducida: > Reta a todo el que entre desde **África, Antártida, Asia, Oceanía o Tor**; desde **Europa salvo España**; y desde **América del Norte salvo México, El Salvador, Guatemala, Cuba, Puerto Rico, Nicaragua, Costa Rica y Honduras**. Es decir: **el mundo entero excepto España y la Latinoamérica hispanohablante**. ## El dato que la condena | | | |---|---:| | Eventos acumulados | **58.600** | | CSR (Challenge Solve Rate) | **0,9 %** | El CSR es el porcentaje de retados que consigue superar la prueba. **Un 0,9 % significa que de cada 1.000 personas retadas, solo 9 lograban entrar; las otras 991 se quedaban fuera.** Sobre 58.600 eventos, hablamos de unas 58.100 visitas que no llegaron a su destino. Eso no es un filtro: es un muro. Y por volumen era la regla que más tráfico tocaba de las cinco (58,6k frente a los 25,8k de «bloquear bots 1»). **Y contradice de lleno el trabajo de traducción**: se pagan y se producen cada semana traducciones y audios a EN/FR/IT/PT para un público —Europa no española, África, Asia, Brasil, Filipinas— al que la propia web le cerraba la puerta al llegar. Sin contar a los hispanohablantes que viven fuera, que son muchos. ## Por qué se quedaba en bucle y no solo fallaba una vez Un Managed Challenge se supera una vez y deja pasar, porque el navegador guarda la credencial (`cf_clearance`) que Cloudflare le entrega. En un iPad eso se rompe con facilidad por dos motivos: - **Relay privado de iCloud**: va cambiando la IP de salida y la credencial va atada a la IP, así que cada recarga la invalida. - **Cookies bloqueadas** en Safari: sin poder guardar la cookie, la prueba no se puede completar nunca. De ahí el bucle infinito que describía ella. Con la regla quitada, el problema desaparece de raíz porque ya no hay reto que superar. ## Qué se ha hecho (28/08/2026) - La regla queda **desactivada, no borrada** (tres puntos → Disable). Si aparece un ataque real, se reactiva con un clic y con datos en la mano. - **Las otras cuatro reglas siguen activas**: «Permitir bing, google, yahoo», «Permitir crawlers» (la que arreglamos en junio para Facebook), «bloquear bots 1» y «bloquear bots 2». Todas filtran por *user agent*, que sí distingue a un bot de una persona; el país no distingue nada. Nota de navegación, que despista: en el panel nuevo de Cloudflare el WAF se llama ahora **Security → Security rules**. ## Pendiente / a decidir 1. **Vigilar Security → Events** unos días. Si no aparece tráfico malo real, la regla se borra definitivamente. 2. **Montar la regla de rate limiting sobre `/wp-login.php` y `/xmlrpc.php`**, que es donde de verdad pegan los bots. Hay derecho a una en el plan y está sin estrenar (**Rate limiting rules: 0/1**). Quedó apuntado en junio, cuando lo de Facebook, y nunca se hizo. 3. **¿Sabes por qué se creó esta regla?** La puso un amigo programador de Inma hace tiempo, para frenar ataques. Si hubo un incidente concreto detrás, conviene conocerlo antes de borrarla del todo: quizá lo que hace falta es una versión mucho más estrecha (solo Tor, o solo sobre las rutas de login). He omitido a propósito el nombre completo y el correo de la lectora.
Author
Collaborator

De dónde venía la regla (respuesta a la pregunta 3)

Lo aclara Inma: la creó Antonio González después de un ataque, en un momento en el que el sitio no tenía Cloudflare ni ninguna protección anti-DDoS. Fue un parche de emergencia con lo único que había a mano: cerrar el grifo por geografía.

Con ese contexto, la regla se entiende perfectamente. Y también se entiende por qué hoy sobra:

  • La mitigación de DDoS de Cloudflare está siempre activa y es automática, en todos los planes, incluido el gratuito. No hay que configurarla ni pagarla: los ataques volumétricos y de capa 7 los absorbe la red antes de llegar al origen. Es exactamente el trabajo que la regla de continentes intentaba hacer a mano.
  • Encima de eso están las cuatro reglas por user agent que siguen activas, y el Bot Fight Mode.

Dicho de otro modo: el problema que justificaba la regla lo resuelve hoy la propia plataforma, y mucho mejor, porque distingue por comportamiento y no por pasaporte.

Queda por decidir si se borra del todo o se sustituye por algo estrecho. Nuestra propuesta sigue siendo la del mensaje anterior: en vez de un muro geográfico, una regla de rate limiting sobre /wp-login.php y /xmlrpc.php, que es donde de verdad pegan los bots y donde un ataque hace daño. Sigue sin usarse (Rate limiting rules: 0/1).

## De dónde venía la regla (respuesta a la pregunta 3) Lo aclara Inma: **la creó Antonio González después de un ataque**, en un momento en el que **el sitio no tenía Cloudflare ni ninguna protección anti-DDoS**. Fue un parche de emergencia con lo único que había a mano: cerrar el grifo por geografía. Con ese contexto, la regla se entiende perfectamente. Y también se entiende por qué hoy sobra: - **La mitigación de DDoS de Cloudflare está siempre activa y es automática**, en todos los planes, incluido el gratuito. No hay que configurarla ni pagarla: los ataques volumétricos y de capa 7 los absorbe la red antes de llegar al origen. Es exactamente el trabajo que la regla de continentes intentaba hacer a mano. - Encima de eso están las cuatro reglas por *user agent* que siguen activas, y el Bot Fight Mode. Dicho de otro modo: **el problema que justificaba la regla lo resuelve hoy la propia plataforma**, y mucho mejor, porque distingue por comportamiento y no por pasaporte. Queda por decidir si se borra del todo o se sustituye por algo estrecho. Nuestra propuesta sigue siendo la del mensaje anterior: en vez de un muro geográfico, una **regla de rate limiting sobre `/wp-login.php` y `/xmlrpc.php`**, que es donde de verdad pegan los bots y donde un ataque hace daño. Sigue sin usarse (Rate limiting rules: 0/1).
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: rafa/feadulta#220