Servicio Avanzado de Protección DDoS
Los ataques de Denegación de Servicio (DoS) están en aumento y se han convertido en desafíos de seguridad complejos y abrumadores para las organizaciones grandes y pequeñas. A pesar de que los ataques DoS no son un fenómeno reciente, los métodos y los recursos disponibles para llevarlos a cabo y las técnicas para enmascarar los han evolucionado dramáticamente para incluir distribuidos (DDoS) y, más recientemente, ataques de reflector distribuido (DRDoS). Ataques que simplemente no pueden ser abordados por las soluciones tradicionales on-premise.
La protección avanzada DDoS de Cloudflare, aprovisionado como un servicio en el borde de la red, acorde con la sofisticación y la escala de este tipo de amenazas, y se puede utilizar para mitigar ataques DDoS de todas las formas y tamaños, incluyendo aquellos que se dirigen a los protocolos UDP,ICMP, así como SYN/ACK, amplificación DNS y ataques de Capa 7.
Cloudflare es una de las mayores redes de protección DDoS del mundo. Ofrecemos protección DDoS con una tarifa plana basada en la tecnología Anycast y hemos mitigado con éxito ataques más grandes que 400Gbps.
Mapa de redes
Tarifa Plana de Precios
Cloudflare ofrece protección contra ataques DDoS sin límite de nivel empresarial a una tasa fija mensual. Creemos que no debe ser penalizado por un pico de tráfico de red asociado con un ataque DDoS. Con la protección de Cloudflare de DDoS, puede estar seguro de que su sitio permanecerá en línea y de que tendrá una factura mensual predecible.
Capacidad de Red de 15 Tbps
Protección DDoS de Cloudflare de más de 15 Tbps. La red Anycast puede bloquear cualquier ataque DDoS lanzado contra ella. Nuestra capacidad total es mucho más grande que el típico ataque DDoS y es 10 veces mayor que el mayor ataque DDoS jamás registrado.
Mitigación de Ataques DDoS Históricos
Si su red o su sitio web está conectado a Internet, la prevención de ataques DDoS no es algo que se pueda hacer, pero la protección siempre es posible, sea cual sea el tamaño. En Cloudflare, nuestros ingenieros han compartido de algunos de los mayores ataques DDoS de la historia. Descubra cómo les hicimos frente en nuestro Blog de desarrolladores.
400Gbps: Invierno de los Enormes Ataques DDoS de Capa 3
En el invierno de 2016, mitigamos el mayor ataque DDoS de Capa 3 registrado hasta la fecha. No solo fuimos capaces de mitigarlo, sino también de medirlo y analizarlo con precisión. Aprenda más
Detalles Detrás de un Ataque de Amplificación NTP de 400Gbps
Los ataques DDoS toman todas las formas y aspectos. En este ataque de amplificación de 400Gbps, un atacante utilizó 4.529 servidores NTP para amplificar un ataque de un simple servidor de origen de 87Mbps. Aprenda más
El Ataque DDoS que Casi daño el Internet
Cloudflare ha estado luchando contra ataques históricos de DDoS durante más de 5 años. En el 2013, los 120Gbps de Spamhaus eran un "gran" ataque, y fuimos capaces de mantener su sitio web en línea. Aprenda más
Configurar Cloudflare es Fácil
Tarifas de Cloudflare
Los sitios web de todo el mundo se pueden beneficiar de usar Cloudflare.
Escoja el plan que encaje con sus necesidades.
Gratis
Pro
Business
Enterprise
Los mejores confían en nosotros
Mitigación de Ataques DDoS Históricos
Desde que Cloudflare actúa como un proxy para todo el tráfico de su red, podemos protegerle de cualquier tipo de ataque distribuido de denegación de servicio, incluyendo:
Ataques de Capa 3/4
La mayoría de los ataques DDoS se dirigen a las capas de transporte y red de un sistema de comunicaciones. Estas capas se representan como capas 3 y 4 del modelo OSI. La llamada capa de "transporte" de la pila de la red especifica el protocolo (por ejemplo, TCP o UDP) por el cual dos hosts en una red se comunican entre sí. Los ataques dirigidos a las capas 3 y 4 están diseñados para inundar una interfaz de red con tráfico de ataque con el fin de abrumar sus recursos y de negarle la capacidad de responder al tráfico legítimo. Más específicamente, los ataques de esta naturaleza tienen como objetivo saturar la capacidad de un switch de red, o abrumar la tarjeta de red de un servidor o la capacidad de su CPU para manejar el tráfico de ataque.
Los ataques de capas 3 y 4 son difíciles, si no imposibles, de mitigar con una solución local basada en hardware. Si un atacante puede enviar más tráfico que el que un enlace de red puede manejar, ninguna cantidad de hardware adicional ayudará a mitigar este tipo de ataque. Por ejemplo, si usted tiene un router con un puerto de 10 Gbps y un atacante le envía 11Gbps de tráfico de ataque, ninguna cantidad de software o hardware inteligente le permitirá detener el ataque si el enlace de la red está completamente saturado.
Los ataques muy grandes de capa 3/4 casi siempre proceden de varias fuentes. Cada una de esas fuentes envía tráfico de ataque a una sola ubicación de Internet creando una avalancha que supera los recursos de un objetivo. En este sentido, el ataque se distribuye. Las fuentes del tráfico de ataque pueden ser un grupo de individuos que trabajan juntos, una red de bots de PC’s comprometidos, una red de bots de servidores comprometidos, resoluciones DNS mal configuradas o incluso routers caseros de Internet con contraseñas débiles.
Como a un atacante que lanza un ataque de capa de 3/4 no le importa recibir una respuesta a las peticiones que manda, los paquetes que componen el ataque no tienen que ser exactos ni formateados correctamente. Los atacantes suelen falsificar toda la información de los paquetes de ataque, incluyendo la IP de origen, lo que hace que parezca como si el ataque viniese de un número prácticamente infinito de fuentes. Como los datos de los paquetes pueden ser totalmente aleatorios, incluso técnicas como el filtrado de IP inmediatas se vuelven prácticamente inútiles.
Con Cloudflare, todo el tráfico de ataque que de lo contrario afectaría directamente a su infraestructura de servidores, se envía automáticamente a la red Anycast global y centros de datos de Cloudflare. Una vez que se cambia el tráfico de ataque, somos capaces de aprovechar la capacidad global significativa de nuestra red, así como de la gran cantidad de racks de servidores para absorber las inundaciones del tráfico de ataque al nivel de nuestra red. Esto significa que Cloudflare es capaz de evitar que incluso un solo paquete de tráfico de ataque de un ataque tradicional de capa 3/4 alcance un sitio protegido por Cloudflare.
Ataques de amplificación DNS
Los ataques de amplificación DNS, una forma de DRDoS, están en aumento y se han convertido en la mayor fuente de ataques DDoS de Capa 3/4. Cloudflare mitiga rutinariamente ataques que exceden los 100Gpbs y recientemente ha protegido a un cliente de un ataque que superó los 300Gbps, un ataque que el "mayor ataque DDoS de la historia de Internet anunciado públicamente."
En un ataque de reflexión DNS, el atacante envía una petición para una zona grande de DNS, con la dirección IP de origen pirateada como la dirección IP de la víctima potencial a un gran número de DNS open resolvers. Luego los resolvers responden a las peticiones enviándole respuestas grandes de DNS a la dirección IP de la víctima. Las mismas peticiones de los atacantes son solo una fracción del tamaño de las respuestas, lo que permite al atacante amplificar su ataque a muchas veces el tamaño de los recursos del ancho de banda que controlan ellos mismos.
Ataque de Reflexión DNS Sin Cloudflare
Un atacante reúne recursos, como redes de bots o recursos abiertos de DNS, e imita la dirección IP del objetivo. A continuación, los recursos envían una avalancha de respuestas al objetivo, haciendo que pierda la conexión.
Ataque de Reflexión DNS Con Cloudflare
Un atacante reúne recursos, como redes de bots o recursos abiertos de DNS, e imita la dirección IP del objetivo. A continuación, los recursos envían una avalancha de respuestas al objetivo, pero son bloqueadas regionalmente por los centros de datos de Cloudflare. El tráfico legítimo aún puede acceder a la propiedad de la web.
Hay dos criterios para un ataque de amplificación: 1.) una consulta puede ser enviada con una dirección de origen falsificada (por ejemplo, a través de un protocolo como ICMP o UDP que no requiere handshake); y 2.) la respuesta a la consulta es significativamente más grande que la propia consulta. DNS es una base, una plataforma ubicua de Internet que cumple con estos criterios, y por lo tanto se ha convertido en la mayor fuente de ataques de amplificación.
Las consultas DNS se transmiten normalmente a través de UDP, lo que significa que, al igual que las consultas ICMP usadas en un ataque SMURF (descrito más adelante), son enviadas sin confirmación. Como resultado, el atributo de origen de una consulta DNS se puede suplantar y el receptor no tiene manera de determinar su veracidad antes de responder. El DNS también es capaz de generar una respuesta mucho más grande que la consulta. Por ejemplo, puede enviar la siguiente (pequeña) consulta (donde xxxx es la dirección IP de una resolución DNS abierta):
dig ANY isc.org @x.x.x.x +edns=0
Y recibir la siguiente respuesta gigantesca:
; <<>> DiG 9.7.3 <<>> ANY isc.org @x.x.x.x
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5147
;; flags: qr rd ra; QUERY: 1, ANSWER: 27, AUTHORITY: 4, ADDITIONAL: 5
;; QUESTION SECTION:
;isc.org. IN ANY
;; ANSWER SECTION:
isc.org. 4084 IN SOA ns-int.isc.org. hostmaster.isc.org. 2012102700 7200 3600 24796800 3600
isc.org. 4084 IN A 149.20.64.42
isc.org. 4084 IN MX 10 mx.pao1.isc.org.
isc.org. 4084 IN MX 10 mx.ams1.isc.org.
isc.org. 4084 IN TXT "v=spf1 a mx ip4:204.152.184.0/21 ip4:149.20.0.0/16 ip6:2001:04F8::0/32 ip6:2001:500:60::65/128 ~all"
isc.org. 4084 IN TXT "$Id: isc.org,v 1.1724 2012-10-23 00:36:09 bind Exp $"
isc.org. 4084 IN AAAA 2001:4f8:0:2::d
isc.org. 4084 IN NAPTR 20 0 "S" "SIP+D2U" "" _sip._udp.isc.org.
isc.org. 484 IN NSEC _kerberos.isc.org. A NS SOA MX TXT AAAA NAPTR RRSIG NSEC DNSKEY SPF
isc.org. 4084 IN DNSKEY 256 3 5 BQEAAAAB2F1v2HWzCCE9vNsKfk0K8vd4EBwizNT9KO6WYXj0oxEL4eOJ aXbax/BzPFx+3qO8B8pu8E/JjkWH0oaYz4guUyTVmT5Eelg44Vb1kssy q8W27oQ+9qNiP8Jv6zdOj0uCB/N0fxfVL3371xbednFqoECfSFDZa6Hw jU1qzveSsW0=
isc.org. 4084 IN DNSKEY 257 3 5 BEAAAAOhHQDBrhQbtphgq2wQUpEQ5t4DtUHxoMVFu2hWLDMvoOMRXjGr hhCeFvAZih7yJHf8ZGfW6hd38hXG/xylYCO6Krpbdojwx8YMXLA5/kA+ u50WIL8ZR1R6KTbsYVMf/Qx5RiNbPClw+vT+U8eXEJmO20jIS1ULgqy3 47cBB1zMnnz/4LJpA0da9CbKj3A254T515sNIMcwsB8/2+2E63/zZrQz Bkj0BrN/9Bexjpiks3jRhZatEsXn3dTy47R09Uix5WcJt+xzqZ7+ysyL KOOedS39Z7SDmsn2eA0FKtQpwA6LXeG2w+jxmw3oA8lVUgEf/rzeC/bB yBNsO70aEFTd
isc.org. 4084 IN SPF "v=spf1 a mx ip4:204.152.184.0/21 ip4:149.20.0.0/16 ip6:2001:04F8::0/32 ip6:2001:500:60::65/128 ~all"
isc.org. 484 IN RRSIG NS 5 2 7200 20121125230752 20121026230752 4442 isc.org. oFeNy69Pn+/JnnltGPUZQnYzo1YGglMhS/SZKnlgyMbz+tT2r/2v+X1j AkUl9GRW9JAZU+x0oEj5oNAkRiQqK+D6DC+PGdM2/JHa0X41LnMIE2NX UHDAKMmbqk529fUy3MvA/ZwR9FXurcfYQ5fnpEEaawNS0bKxomw48dcp Aco=
isc.org. 484 IN RRSIG SOA 5 2 7200 20121125230752 20121026230752 4442 isc.org. S+DLHzE/8WQbnSl70geMYoKvGlIuKARVlxmssce+MX6DO/J1xdK9xGac XCuAhRpTMKElKq2dIhKp8vnS2e+JTZLrGl4q/bnrrmhQ9eBS7IFmrQ6s 0cKEEyuijumOPlKCCN9QX7ds4siiTIrEOGhCaamEgRJqVxqCsg1dBUrR hKk=
isc.org. 484 IN RRSIG MX 5 2 7200 20121125230752 20121026230752 4442 isc.org. VFqFWRPyulIT8VsIdXKMpMRJTYpdggoGgOjKJzKJs/6ZrxmbJtmAxgEu /rkwD6Q9JwsUCepNC74EYxzXFvDaNnKp/Qdmt2139h/xoZsw0JVA4Z+b zNQ3kNiDjdV6zl6ELtCVDqj3SiWDZhYB/CR9pNno1FAF2joIjYSwiwbS Lcw=
isc.org. 484 IN RRSIG TXT 5 2 7200 20121125230752 20121026230752 4442 isc.org. Ojj8YCZf3jYL9eO8w4Tl9HjWKP3CKXQRFed8s9xeh5TR3KI3tQTKsSeI JRQaCXkADiRwHt0j7VaJ3xUHa5LCkzetcVgJNPmhovVa1w87Hz4DU6q9 k9bbshvbYtxOF8xny/FCiR5c6NVeLmvvu4xeOqSwIpoo2zvIEfFP9deR UhA=
isc.org. 484 IN RRSIG AAAA 5 2 7200 20121125230752 20121026230752 4442 isc.org. hutAcro0NBMvKU/m+2lF8sgIYyIVWORTp/utIn8KsF1WOwwM2QMGa5C9 /rH/ZQBQgN46ZMmiEm4LxH6mtaKxMsBGZwgzUEdfsvVtr+fS5NUoA1rF wg92eBbInNdCvT0if8m1Sldx5/hSqKn8EAscKfg5BMQp5YDFsllsTauA 8Y4=
isc.org. 484 IN RRSIG NAPTR 5 2 7200 20121125230752 20121026230752 4442 isc.org. ZD14qEHR7jVXn5uJUn6XR9Lvt5Pa7YTEW94hNAn9Lm3Tlnkg11AeZiOU 3woQ1pg+esCQepKCiBlplPLcag3LHlQ19OdACrHGUzzM+rnHY50Rn/H4 XQTqUWHBF2Cs0CvfqRxLvAl5AY6P2bb/iUQ6hV8Go0OFvmMEkJOnxPPw 5i4=
isc.org. 484 IN RRSIG NSEC 5 2 3600 20121125230752 20121026230752 4442 isc.org. rY1hqZAryM045vv3bMY0wgJhxHJQofkXLeRLk20LaU1mVTyu7uair7jb MwDVCVhxF7gfRdgu8x7LPSvJKUl6sn731Y80CnGwszXBp6tVpgw6oOcr Pi0rsnzC6lIarXLwNBFmLZg2Aza6SSirzOPObnmK6PLQCdmaVAPrVJQs FHY=
isc.org. 484 IN RRSIG DNSKEY 5 2 7200 20121125230126 20121026230126 4442 isc.org. i0S2MFqvHB3wOhv2IPozE/IQABM/eDDCV2D7dJ3AuOwi1A3sbYQ29XUd BK82+mxxsET2U6hv64crpbGTNJP3OsMxNOAFA0QYphoMnt0jg3OYg+AC L2j92kx8ZdEhxKiE6pm+cFVBHLLLmXGKLDaVnffLv1GQIl5YrIyy4jiw h0A=
isc.org. 484 IN RRSIG DNSKEY 5 2 7200 20121125230126 20121026230126 12892 isc.org. j1kgWw+wFFw01E2z2kXq+biTG1rrnG1XoP17pIOToZHElgpy7F6kEgyj fN6e2C+gvXxOAABQ+qr76o+P+ZUHrLUEI0ewtC3v4HziMEl0Z2/NE0MH qAEdmEemezKn9O1EAOC7gZ4nU5psmuYlqxcCkUDbW0qhLd+u/8+d6L1S nlrD/vEi4R1SLl2bD5VBtaxczOz+2BEQLveUt/UusS1qhYcFjdCYbHqF JGQziTJv9ssbEDHT7COc05gG+A1Av5tNN5ag7QHWa0VE+Ux0nH7JUy0N ch1kVecPbXJVHRF97CEH5wCDEgcFKAyyhaXXh02fqBGfON8R5mIcgO/F DRdXjA==
isc.org. 484 IN RRSIG SPF 5 2 7200 20121125230752 20121026230752 4442 isc.org. IB/bo9HPjr6aZqPRkzf9bXyK8TpBFj3HNQloqhrguMSBfcMfmJqHxKyD ZoLKZkQk9kPeztau6hj2YnyBoTd0zIVJ5fVSqJPuNqxwm2h9HMs140r3 9HmbnkO7Fe+Lu5AD0s6+E9qayi3wOOwunBgUkkFsC8BjiiGrRKcY8GhC kak=
isc.org. 484 IN RRSIG A 5 2 7200 20121125230752 20121026230752 4442 isc.org. ViS+qg95DibkkZ5kbL8vCBpRUqI2/M9UwthPVCXl8ciglLftiMC9WUzq Ul3FBbri5CKD/YNXqyvjxyvmZfkQLDUmffjDB+ZGqBxSpG8j1fDwK6n1 hWbKf7QSe4LuJZyEgXFEkP16CmVyZCTITUh2TNDmRgsoxrvrOqOePWhp 8+E=
isc.org. 4084 IN NS ns.isc.afilias-nst.info.
isc.org. 4084 IN NS ams.sns-pb.isc.org.
isc.org. 4084 IN NS ord.sns-pb.isc.org.
isc.org. 4084 IN NS sfba.sns-pb.isc.org.
;; AUTHORITY SECTION:
isc.org. 4084 IN NS ns.isc.afilias-nst.info.
isc.org. 4084 IN NS ams.sns-pb.isc.org.
isc.org. 4084 IN NS ord.sns-pb.isc.org.
isc.org. 4084 IN NS sfba.sns-pb.isc.org.
;; ADDITIONAL SECTION:
mx.ams1.isc.org. 484 IN A 199.6.1.65
mx.ams1.isc.org. 484 IN AAAA 2001:500:60::65
mx.pao1.isc.org. 484 IN A 149.20.64.53
mx.pao1.isc.org. 484 IN AAAA 2001:4f8:0:2::2b
_sip._udp.isc.org. 4084 IN SRV 0 1 5060 asterisk.isc.org.
;; Query time: 176 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Tue Oct 30 01:14:32 2012
;; MSG SIZE rcvd: 3223
Eso es una consulta de 64 bytes que dio lugar a una respuesta de 3.223 bytes. En otras palabras, un atacante es capaz de lograr una amplificación 50 veces mayor sobre cualquier tráfico que pueda iniciar una resolución DNS abierta.
La red "Anycast" de Cloudflare fue diseñada específicamente para detener los ataques masivos de capa 3/4. Mediante el uso de Anycast, estamos en condiciones de anunciar las mismas direcciones IP de cada uno de nuestros 151 centros de datos en todo el mundo. La propia red balancea la carga al punto de presencia más cercano. En circunstancias normales, esto nos ayuda a asegurar que los visitantes de su sitio se enrutan automáticamente al centro de datos más cercano de nuestra red para garantizar el mejor rendimiento. Cuando se produce un ataque, Anycast sirve para dispersar y diluir el tráfico de ataques con eficacia a través de toda nuestra red de centros de datos. Debido a que cada centro de datos anuncia la misma dirección IP para cualquier cliente de Cloudflare, el tráfico no puede ser dirigido a un lugar determinado. En lugar de que el ataque sea de muchos-para-uno, se convierte en muchos-para-muchos sin un solo punto en la red con un punto de fallo.
Ataques SMURF
Uno de los primeros ataques de amplificación se conoció como un ataque SMURF. En un ataque SMURF, un atacante envía peticiones ICMP (es decir, peticiones ping) a la dirección broadcast de una red (es decir, X.X.X.255) anunciada desde un router configurado para retransmitir ICMP a todos los dispositivos que están detrás del router. Después, el atacante suplanta la identidad de la fuente de la petición ICMP para convertirse en la dirección IP de la víctima. Como el ICMP no incluye un protocolo de intercambio, el destino no tiene ninguna forma de verificar si la IP de origen es legítima. El router recibe la petición y la pasa a todos los dispositivos que están detrás de él. Después, cada uno de estos dispositivos responde al ping. El atacante es capaz de amplificar el ataque a un igual múltiple que el número de dispositivos que se encuentran detrás del router (es decir, si tiene 5 dispositivos detrás del router entonces el atacante es capaz de amplificar 5 veces el ataque, véase el siguiente diagrama).
Los ataques SMURF suelen ser cosa del pasado. En su mayor parte, los operadores de redes han configurado sus routers para desactivar el ICMP Relay enviadas a la dirección broadcast de una red.
Ataques ACK
Para entender un ataque ACK, hay que profundizar en el mundo de TCP. Cuando se establece una conexión TCP existe un protocolo de intercambio. El servidor que inicia la sesión de TCP envía primero una petición SYN (para sincronización) para el servidor de recepción. El servidor de recepción responde con un ACK (para confirmar). Después de que este protocolo de intercambio, se pueden intercambiar datos.
En un ataque de reflexión ACK, el atacante envía una gran cantidad de paquetes SYN a los servidores con una dirección IP de origen suplantada que apunta a la posible víctima. Los servidores responden a continuación al IP de la víctima con un ACK que crea el ataque.
Al igual que los ataques de reflexión DNS, los ataques ACK disfrazan el origen del ataque haciendo que parezca provenir de servidores legítimos. Sin embargo, a diferencia de un ataque de reflexión DNS, no hay factor de amplificación: el ancho de banda del ACK es simétrico al ancho de banda que el atacante tiene para generar los SYN. La red de Cloudflare está configurada para eliminar los ACK sin respuestas, lo que mitiga este tipo de ataques.
Ataques de Capa 7
Una nueva generación de ataques tiene como objetivo la capa 7 del modelo OSI, la capa de "aplicación". Estos ataques se centran en características específicas de las aplicaciones web que crean cuellos de botella. Por ejemplo, el llamado ataque Slow Read envía paquetes lentamente a través de múltiples conexiones. Debido a que Apache abre un nuevo subproceso para cada conexión y dado que las conexiones se mantienen siempre y cuando el tráfico se envíe, un atacante puede abrumar un servidor web mediante el agotamiento de su grupo de subprocesos de forma relativamente rápida.
Cloudflare tiene protecciones habilitadas contra muchos de estos ataques y en experiencias del mundo real, por lo general reduce los ataques al tráfico HTTP en un 90%. Para la mayoría de los ataques y para la mayoría de nuestros clientes, esto es suficiente para mantenerlos en línea. Sin embargo, el 10% del tráfico que llega a su destino a través de protecciones tradicionales, puede resultar abrumador para clientes con recursos limitados o que hacen frente a grandes ataques. En este caso, Cloudflare ofrece un entorno de seguridad denominado modo "Estoy sufriendo un ataque" (I’m Under Attack Mode” IUAM).
El IUAM es un nivel de seguridad que puede establecer para su sitio cuando reciba un ataque. Cuando IUAM está encendido, Cloudflare añadirá una capa adicional de protección para detener el tráfico HTTP malicioso que se transmita a su servidor. Mientras que un número de controles adicionales se llevan a cabo en segundo plano, una página intersticial se presenta a los visitantes de su sitio durante 5 segundos, mientras que los controles se completan. Piense en ello como en un reto en el que las pruebas son automáticas y los visitantes nunca tienen que rellenar un CAPTCHA.
Después de haber sido verificado como legítimo por las pruebas automatizadas, los visitantes pueden navegar por su sitio sin problemas. Las cookies y el JavaScript son necesarios para las pruebas y para registrar el hecho de que las mismas se pasan correctamente. La página que ven sus visitantes cuando está en IUAM puede personalizarse completamente para reflejar su imagen de marca. El modo de Estoy Sufriendo un Ataque no bloquea los indexadores de motores de búsqueda ni la lista blanca de Cloudflare existente.