La historia de cómo evitar un ataque DDOS basado en el tiempo en Node.js

Prometo que cambiaré este título porque definitivamente es demasiado largo, pero pongamos una frase corta y llamativa. A veces tu peor enemigo es simplemente la lentitud. Ahora no me crees, pero al final de la charla realmente me creerás y te sorprenderás de cómo sucedió esto.

En primer lugar, permíteme presentarme nuevamente. Para las personas que me preguntan de dónde vengo, el pequeño punto allí en el centro de Italia del Sur y puedo decirte que el resto de Italia no reconoce nuestra existencia. Mi región está completamente olvidada. No me preguntes por qué, pero como también dije, soy un ingeniero Dx de Nearform y cofundador y arquitecto principal de Orama. ¿Qué son estas empresas? Nearform es una empresa de servicios profesionales completamente remota. Siempre estamos buscando nuevos talentos, así que si estás interesado, ven a saludarme después de esta charla. Somos 300 y contando, completamente remotos y desafortunadamente no puedes escapar de nosotros en NPM. Tenemos 1 billón de descargas mensuales en nuestros paquetes, 8%, así que desafortunadamente no puedes escapar. Sin Orama, solo planeamos hacer una cosa simple. Buscar en todas partes, donde sea que puedas ejecutar JavaScript. Estamos tratando de reinventar la industria de búsqueda de texto, solo utilizando JavaScript y manteniéndonos de código abierto. Una vez más, si estás interesado, ven a saludarme más tarde, a mí o a mi cofundador Michele y Angela, estamos afuera.

Vamos al grano. Hoy en día estamos utilizando cada vez más aplicaciones web y son muy importantes para todos nuestros usos. Pueden variar desde temas muy importantes como, no sé, la telemedicina, la banca en línea, la seguridad nacional, o lo que sea, hasta lo que se podría considerar como temas triviales como las redes sociales, la mensajería, y así sucesivamente.

Digo que podrían considerarse triviales porque si piensas en la accesibilidad y la inclusión, para algunas personas como los ancianos y demás, WhatsApp podría ser la única forma de hablar con su sobrino. Así que si WhatsApp no funciona, los estás privando de una parte muy importante de su comunicación. Estas aplicaciones simplemente nunca pueden dejar de funcionar. Eso no va a suceder.

Lo cual nos lleva a otro problema, que es que siempre somos vulnerables. No importa lo inteligente que creas que eres, no importa cuántas personas trabajen en seguridad en tu empresa, recuerda que siempre habrá 10 personas más afuera tratando de perder tu tiempo y molestar con tu aplicación y derribarla. Desafortunadamente, siempre superan en número.

Esto nos lleva a una categoría de ataques que generalmente son bien conocidos. Por favor, levanten la mano si conocen los ataques DDoS. Y levanten la mano si conocen los ataques DDoS distribuidos. Ok, prácticamente las mismas personas. En resumen, un ataque de denegación de servicio es un tipo de ataque en el que un recurso de red se vuelve maliciosamente inaccesible para el usuario previsto. La aplicación no es comprometida por el atacante, sino que se ve abrumada por las solicitudes. Existe la versión distribuida que es el ataque DDoS, en el que el tráfico malicioso proviene de varias fuentes en la web. Es mucho más difícil de combatir por las razones que veremos en un momento. Hasta hace unos años, se entendía comúnmente que para llevar a cabo un ataque DDoS, el atacante debía utilizar una gran cantidad de recursos de varias fuentes en todo el mundo. Por favor, levanten la mano si creen que esto sigue siendo cierto y que para ejecutar un ataque DDoS se necesitan muchos recursos. Ok, eso es en parte cierto y en parte no, y les mostraré por qué en un momento. Primero, déjenme presentarles a su verdadero enemigo de hoy. Este es el animal más horrible que he visto en TI. Este tipo. Este tipo es aterrador. Cuando les cuente por qué, dirán: `Ok, esto es increíble`. Este es el Zoloris y básicamente es un animal muy, muy, muy pequeño y lento. Por definición, se mueve muy lento.

Si conoces la película Zootrópolis, hay una escena del DMV. Si sabes a qué me refiero, piensa en algo así. Eso te matará. Eso es exactamente de lo que vamos a hablar ahora. Porque nos estamos centrando en un ataque que se llamó el ataque Zoloris. Es un ataque DDoS que utiliza, contrario a lo que podrías pensar, un ancho de banda mínimo, casi nada, lo cual es asombroso. Este ataque fue creado por Robert Tenzin en 2009. Y hay algo que acabo de encontrar en línea cuando buscaba este ataque.

Técnicamente hablando, no solo se aplica a HTTP. No sé por qué, si buscas en línea el ataque Zoloris, solo se menciona su implementación en HTTP, probablemente porque es el protocolo más utilizado. Pero en mi opinión, al analizar cómo funciona este ataque, este ataque se puede extender a cualquier protocolo que se ejecute sobre TCP y que no tenga un buen manejo de tiempo de espera. Si lo haces así, puedes derribar cualquier servidor. Y recuerda que solo se necesita un solo servidor para dejar todo inactivo.

Comencemos analizando cómo funcionan las cosas normalmente en HTTP. Cuando hablamos de un servidor HTTP, por lo general, lo que sucede es que hay un cliente que se conecta al servidor. Así que hay una línea negra sólida, luego envía una solicitud, que es la línea roja sólida en este caso, y recibe una respuesta, que es la línea verde sólida. Por lo general, ese es el flujo normal. Podemos asumir, para este ejemplo, que cada socket consume la misma cantidad de RAM y otros recursos del sistema del servidor. Por lo general, ese es el caso, pero dependiendo del medio que uses, es posible que no sea realmente así, pero asumamos que lo es.

Luego hay una segunda solicitud que hace lo mismo, pero para cuando llega esa segunda solicitud, podemos asumir que el primer cliente se ha desconectado. Veo tu objeción. Eso no es cierto para keepalive porque, por supuesto, un cliente puede permanecer conectado y eventualmente realizar múltiples solicitudes en el mismo socket. Pero solo por el bien del ejemplo, digamos que el primer cliente en algún momento se desconecta. Entonces, a lo largo del tiempo, segundo, tercer, cuarto, quinto cliente, podemos asumir que el número de recursos y sockets en el servidor, olvidando los picos temporales, suele ser constante. Esa es nuestra suposición, que generalmente también es cierta si observas tus gráficos en cualquier aplicación de registro, verás que el tráfico de red es relativamente estable. Así que eso realmente es cierto. La segunda cosa es que una cosa que probablemente nunca consideras es que retener un socket en el servidor es costoso porque primero obtienes un archivo. Quiero decir, primero obtienes una capa de manejo de red y sistema operativo, lo que significa que se utiliza una parte de la ROM de tu sistema solo para mantener esa aplicación abierta. Luego está el sistema de archivos. Si estás en Unix, enlazarás esos recursos de red a un descriptor de archivo porque en Unix, todo es un descriptor de archivo, ya sabes la regla.

Este descriptor de archivo que se crea afectará el número ULIMIT de tu proceso. Por favor, levanta la mano si sabes qué es ULIMIT. OK, ok, en resumen, ULIMIT es un número de archivos, un parámetro del sistema que especifica cuántos descriptores de archivo puede abrir tu proceso. Por lo general, el proceso comienza con un límite bastante bajo, que es 1024, y se puede aumentar por el usuario para que sea infinito.

El problema es ¿qué significa infinito? Infinito para el proceso individual, pero a nivel del sistema, el número sigue siendo finito, por lo que en algún momento tu proceso puede ocupar todos los descriptores de archivo posibles, pero en algún momento no habrá descriptores de archivo para nadie, incluido tu proceso, y eso es un problema.

Finalmente, cuando salimos de la capa del sistema operativo, llegamos a la capa de la aplicación. Por ejemplo, en Node, para mantener un socket, se necesitan muchos callbacks, streams y demás, relacionados con tu único socket. Una vez más, mucha RAM. En algún momento, esta RAM se agotará. Siempre hablamos de la RAM virtual, pero también hay RAM física que en algún momento simplemente se agotará. Ese es el problema. Y eso nos lleva al ataque slow-lorist. El ataque slow-lorist es bastante único porque cada cliente se conecta y nunca termina la respuesta. En este caso, como puedes ver, la línea roja es discontinua y eso significa una solicitud incompleta, por lo que nunca envía el último byte. Y como puedes ver, no hay línea verde porque el servidor nunca pudo recibir realmente la solicitud completa y la respuesta del servidor. Con el tiempo, cada vez más clientes siguen conectándose y nunca se desconectan, y esto provoca interrupciones del servicio porque en algún momento el servidor no podrá aceptar nuevas conexiones debido a la falta de descriptores de archivo, RAM o BOT.

¿Cuál es el problema aquí? Si miras tus registros en tu sistema de monitoreo, no verás ancho de banda. Probablemente solo verás una caída en el ancho de banda saliente porque el servidor no podrá responder más, pero el ancho de banda entrante será casi nulo, por lo que realmente no establecerás ninguna alarma. Porque es casi imposible distinguir si nadie se está conectando o si alguien se está conectando pero nunca envía los data que es un desastre horrible. Lo que nos lleva a otra pregunta muy simple. ¿Cómo lo detenemos? Y aquí es cuando las cosas se ponen horribles. Porque en resumen, en primer lugar, si estás utilizando Node u aplicaciones similares, por favor no los pongas directamente en contacto con el público. Siempre ten un proxy inverso o una puerta IPI o algo así al frente porque estos software son más adecuados para este trabajo de prevenir este tipo de ataques. Node u otras herramientas similares son herramientas de propósito general, por lo que no son adecuadas para esto. Así que no lo hagas. Pero si tienes que hacerlo, por cualquier motivo, desafortunadamente, puedo decirte que ninguna de las estrategias que puedas implementar será precisa. La razón es que hay dos formas principales de detener un ataque DDoS. La primera es una medida temporal que consiste en prohibir las IP ofensivas durante un tiempo. Por supuesto, no tiene sentido porque todos sabemos lo fácil que es crear una nueva instancia en cualquier cloud y obtener una nueva IP. Pero para un alivio temporal, esto podría funcionar.

A largo plazo, debes tener una aplicación de cumplimiento de velocidad o tiempo de espera muy buena, lo cual es generalmente lo más fácil y equivalente de implementar. La técnica de manejo de tiempo de espera plantea un problema en cuanto a la inclusión. Porque si, por ejemplo, consideras que todos los clientes que son más lentos de 5 segundos están atacando, estás excluyendo a las personas que tienen una conexión de red deficiente y son clientes legítimos. Por lo tanto, debes conocer a tus clientes, debes conocer el caso de uso de tu aplicación y en base a eso puedes elegir cuál es tu umbral de tiempo de espera que eventualmente puedes monitorear e incrementar. Esto básicamente llevará a un cierto umbral de usuarios legítimos que serán excluidos y debes conocer tu riesgo desafortunadamente. Pero nunca puedes ser 100% preciso.

Ahora, ¿qué hay de Node? ¿Cómo maneja Node este ataque de liberación lenta y cómo podemos hacerlo? En primer lugar, Node ha estado parcialmente desprotegido hasta 2018. Aunque la liberación lenta ha estado presente desde 2009 y también Node. Desde la primera versión, Node incluía un servidor HTTP pero no un manejo efectivo de tiempo de espera. El único manejo de tiempo de espera disponible antes de la versión 10.14 era net.socket.timeout, que es la cantidad de tiempo que un socket puede permanecer completamente inactivo, es decir, sin enviar ningún byte, antes de ser cerrado. Ese era el único tiempo de espera. En la versión 10.14 de Node se introdujo el tiempo de espera de encabezados del servidor HTTP, que básicamente establecía cuánto tiempo tiene cada cliente para enviar todos los encabezados de la solicitud.

Ahora, ¿por qué solo los encabezados de la solicitud? Porque en Node nunca tratamos el tiempo de espera o lo que sea con el cuerpo. Esa fue una decisión inicial que delegamos el manejo del cuerpo a la capa de aplicación, que es Express, Fastify, lo que quieras. Ahora, levanta la mano si crees que estos frameworks implementaron correctamente la lógica de manejo de tiempo de espera. Has estado en TI por mucho tiempo... De acuerdo, aprecio eso. Desafortunadamente, eso fue un problema. Entonces, en Node 14.0, hubo una protección inicial, al menos en la parte de los encabezados, pero el cuerpo quedó excluido. Básicamente, no fue tan efectivo como protección. La situación empeoró aún más cuando lanzamos la versión 13.0.0 de Node un año después, donde deshabilitamos el tiempo de espera. Estaba eliminando todo el tiempo de espera de inactividad. Ese tiempo de espera se deshabilitó de forma predeterminada, en lugar de estar habilitado de forma predeterminada. La razón fue ser más amigable con el entorno sin servidor que necesita conexiones de larga duración. Por lo tanto, tienes conexiones inactivas. Deshabilitamos eso y una vez más confiamos en el framework para implementar correctamente el manejo de tiempo de espera. Una vez más, no te pediré que levantes la mano de nuevo, pero ya conoces la idea. Desafortunadamente, no hubo un manejo adecuado por parte de los frameworks. Fastify, Rastify implementaron una solución adecuada, CoA y Express no lo hicieron, lo cual en Abyss ya implementaron una solución adecuada, CoA y Express no lo hicieron, y eso fue un gran problema.

Luego, un año después en Node 14, obtuvimos una mejor protección, que fue el tiempo de espera de solicitud del servidor HTTP. Como su nombre lo indica, es una forma de imponer un tiempo de espera completo en toda la solicitud HTTP. Estaba disponible en todas las líneas activas, pero desafortunadamente, estaba desactivado de forma predeterminada. La razón fue que se introdujo como un cambio de versión semántica menor, por lo que no se pudo habilitar de forma predeterminada debido a que era un cambio incompatible hacia atrás. Eso fue un problema.

¿Estamos seguros? ¿Están levantando la mano? Sí. Bueno, eso es genial. Ya saben cómo funciona. Estábamos casi protegidos. Las contramedidas que teníamos en Node 14 eran débiles, porque se necesitaba una configuración personalizada para protegerse. Es decir, tenías que volver a habilitar todos los temporizadores que se habían desactivado de forma predeterminada, desafortunadamente. Hubo una priorización del rendimiento al implementar la verificación. Volveré en un minuto. Básicamente, el problema era que el tiempo de espera se verificaba después de recibir el siguiente byte. Entonces, ¿queremos adivinar por qué esta lógica podría ser defectuosa en caso de slow lorries? ¿Alguien? De acuerdo, ¿qué? Ese es el punto. Ese es el punto de partida. Entonces, para un ataque muy rápido, funciona, pero para un ataque lento, como los ataques de slow lorries, nunca recibes el siguiente byte. Esperar el siguiente byte para verificar si deberías haberlo recibido antes no tiene mucho sentido, ¿verdad? Pero era la forma más rápida de implementar una verificación de tiempo de espera adecuada. De todos modos, empecemos por algo pequeño.

Supongamos que estamos en Node 16 y versiones anteriores. Entonces, ¿cómo protegemos tu aplicación Node de la manera correcta? En primer lugar, asegúrate de que el socket no pueda estar inactivo, habilita HTTP.server.timeout. Limita el tiempo para cada solicitud, habilita HTTP.server.requestTimeout. Y también habilita addersTimeout con un valor más bajo. Esta es la forma de proteger las versiones 16, 14, 12, 15, por favor actualiza al menos a la versión 16. Haznos un favor.

Ambos están fuera de servicio. Y este es un ejemplo, por ejemplo. Puedes simplemente copiar esos valores. Así que dos minutos para que el socket esté inactivo, cinco minutos para recibir la solicitud completa, lo cual es mucho. Y addersTimeout, solo un minuto. De esta manera, si tu servidor puede resistir cinco minutos, resistirá el ataque. Esa es la idea.

Puedo decirte que con el lanzamiento de Node 18.0.0, finalmente estamos seguros por defecto. ¿Por qué es eso? Porque las solicitudes se verifican periódicamente. Hay una nueva API que verifica cada ciertos segundos. Por defecto son 30 segundos. Verifica todos los sockets. Por lo tanto, se implementó una nueva lista de conexiones. Porque antes en Node 18, Node no mantenía una lista de sockets conectados al servidor HTTP. Por lo tanto, no podía realizar este tipo de verificación. Lo implementamos en Node 18. Y cada 30 segundos verificamos todos los sockets, sin importar si hemos recibido nuevos data o no, y cortamos los expirados. Además, tenemos valores predeterminados más seguros. Huevo de Pascua. Estos eran los valores predeterminados en Node 18. Puedes usarlos en Node antes de la versión 18, pero estos también son los valores predeterminados en Node 18 finalmente, lo cual nos facilita las cosas. Y ahora Node 18 está protegido por defecto contra slow lorries. Así que finalmente lo logramos. Finalmente estamos seguros en eso.

Lecciones para llevar. Lo que podemos aprender de esto. En primer lugar, siempre piensa en la security. Los data van primero, antes que el performance. Puedes sacrificar el performance, y eventualmente si haces esto y básicamente cambias tu mentalidad, incluso podrías obtener una ganancia de performance de forma gratuita. Cuando implementé un intervalo de verificación de conexiones, obtuve una mejora del 2%, totalmente inesperada.

Ni siquiera estaba buscando eso. De alguna manera lo obtuve. No me preguntes cómo, nunca lo verifiqué. Simplemente estaba feliz con eso.

Además, valida regularmente lo que estás haciendo. Porque podrías encontrar código que otra persona ha escrito con muy buena intención pero que tiene fallas de implementación o simplemente estaba cansada, y así siempre puedes volver a verificar lo que estás haciendo cada vez.

Y finalmente, una cosa que siempre me gusta hacer en mis charlas es terminar con citas muy, muy inteligentes de otra persona. En mi caso, estoy citando a William Safar, quien dice que nunca asumas que lo obvio es cierto. En mis propias palabras, digo, por favor, por favor, por favor, usa el sentido común en todas partes. Esta cosa generalmente se olvida y tú lo sabes. Usa el sentido común en toda tu vida laboral y no laboral.

Preguntas en un momento y muchas gracias. Eso es todo. Así que, la gente piensa en la seguridad sin necesariamente tener el conocimiento sobre cómo implementarla. Has dado o implementado prácticas hacia eso. Has dado algunos puntos clave que son buenos puntos de partida para los procesos de pensamiento que debes establecer. Me pregunto si ves alguna mitigación común o creencia de los desarrolladores que pueda terminar haciendo más daño que bien. Me refiero a aquellos casos en los que no está realmente relacionado con la seguridad pero está presente en todas partes, que es el término de sobreingeniería. A veces, sobreingenierizan cosas y pueden causar daño o incluso matar completamente el rendimiento. Así que si comienzas a sobreingenierizar buscando solo la seguridad o el rendimiento, podrías matar al otro y eso es cuando estás matando tu aplicación porque si una aplicación es segura pero no es utilizable, como tener que iniciar sesión cada cinco minutos, por ejemplo, si cambiamos al frontend, nadie lo va a usar, por lo que ya no importa si es seguro o rápido porque haces, digamos, que la experiencia de usuario sea inutilizable. Siempre es importante recordar todos los aspectos de seguridad, rendimiento y usabilidad. Hay un triángulo en el que generalmente se trata de mantener uno o dos de los tres vértices, pero en este caso debemos intentar mantener todos ellos. Esa es la idea. Oh sí, fácil, fácil. Al menos luchamos. No digo que sea posible, pero luchemos por mantener los tres vértices del triángulo. Excelente.

Tenemos varias preguntas, así que las responderé rápidamente en el tiempo que tenemos. ¿Cómo protege NGINX tu servidor contra Slow Loris? Para ser honesto, no tengo idea, pero sé que lo hace. No, quiero decir, supongo que la única forma de protegerse contra Slow Loris es un manejo adecuado de los tiempos de espera. Así que supongo que NGINX tiene un mejor manejo de los tiempos de espera que es más adecuado para el trabajo. El mayor problema es que no puedes proporcionar un software completo, por lo que NGINX se enfoca únicamente en eso y supongo que incluso ahora o en el futuro, si no hay una protección adecuada, NGINX tendrá un proceso más rápido para obtener una protección adecuada, porque por ejemplo, en Node tenemos que preocuparnos por Http y criptografía al mismo tiempo, ¿verdad? NGINX se enfoca solo en Http, por lo que será más rápido si surgen nuevos ataques para protegerse inmediatamente de ellos. Esa es la idea. Sí, genial. Gracias.

¿Existe un método para mitigar los ataques Slow Loris en WebSockets? Para lo mismo, el tiempo de inactividad. En el caso de los WebSockets, es la misma técnica. Por supuesto, no se puede realmente imponer, probablemente debas aplicar tiempos de espera más largos porque puede ser que el WebSocket no se utilice durante un tiempo porque simplemente está inactivo, pero por ejemplo, cuando comienza un nuevo mensaje, se impone un tiempo de espera estricto. Entonces, el mensaje debe llegar al otro extremo eventualmente, solo a nivel del protocolo de carga. Y, por supuesto, se impone un tiempo de espera muy largo para un Socket inactivo. Digamos que después de una hora, se puede asumir que el cliente no está haciendo nada, se debe cerrar. Tal vez una hora sea demasiado. Pero una vez más, conocer tu aplicación es clave.

Hay varias preguntas sobre los números mágicos. Llegaremos a ellas en su debido momento, pero primero la siguiente pregunta, ¿hay vulnerabilidades importantes similares que aún nos afecten incluso con la última versión de Node? No que yo sepa. Podría ser, pero por el momento no tengo conocimiento de ello. Podría estar equivocado, así que no confíes en mí. Verifica nuevamente. No confío en mí mismo, Fox, así que verifica todo lo que veo. En cuanto a Slowloris, ¿sigue siendo el ataque DDoS más común en la actualidad o existen otras formas de ataques populares de los que las personas deben estar conscientes y mitigar? Básicamente, puedes intercambiar los ataques en dos lados. Slowloris es el que utiliza un ancho de banda mínimo y existen varios tipos de ataques que simplemente saturan tu servidor, ya sea con intentos de conexión o enviando tráfico excesivo, pero demasiado tráfico y así sucesivamente. Estas son las dos categorías principales. Pueden ser lentos o rápidos. Si eres promedio o simplemente una solicitud regular, no importa. Esa es probablemente la respuesta a eso.

Audiencia, pregunta. Dije Nginx. ¿Es Nginx o Ngin? Siempre he dicho NginX. Asentimientos. Asentimientos. Excelente. Muchas gracias, equipo.

Entonces, ¿deberíamos mantener las medidas de seguridad que recomiendas en Node, incluso cuando lo estamos ejecutando detrás de un Nginx, ya sabes, configuración, por ejemplo? Absolutamente, absolutamente. La razón es que, como te dije, no estoy seguro de si Nginx protege contra slowloris, así que ¿por qué eliminar una capa adicional de protección? La mayoría de las veces, estos tiempos de espera nunca se activarán, por lo que no tendrás ningún problema, así que está perfectamente bien. No causará ningún daño dejarlos abiertos, especialmente porque todos los tiempos de espera que mencioné anteriormente se implementaron con diferentes tiempos de espera y intervalos establecidos internamente en Node. Ahora todos se implementan con un tiempo de espera temporal regular. Antes de que se cumpla el tiempo de espera, el intervalo de verificación no se activará, por lo que obtienes eso de forma gratuita, así que no hay razón para desactivarlo ahora. En Node 18, si estás en Node 16, probablemente lo pienses dos veces, pero dado que estos tiempos de espera son tan altos, nunca se activarán, así que probablemente estés bien. Pero mi consejo es que Node 18 se lanzará como LTS en octubre, actualiza, ya sabes a lo que me refiero. Actualiza.

Tenemos un par de preguntas que se enviaron. Voy a combinarlas en aras del tiempo, así que las leeré completas. ¿Cuán grandes son los impactos en el performance de verificar todas las solicitudes en Node 18+? ¿Existe un valor óptimo para el intervalo de verificación? Y una pregunta similar. Un minuto parece un tiempo muy largo para un tiempo de espera de encabezado. En tu experiencia, ¿cuáles podrían ser buenos números para ejemplos del mundo real? Sí, de hecho es un tiempo de espera enorme, y eso es por design. Recuerda que Node es una herramienta de propósito general, así que no tenemos idea de lo que estás haciendo en tu aplicación. Debes establecer un valor predeterminado que probablemente no afecte a las personas y las mantenga seguras, pero si sabes que tus clientes son muy rápidos, puedes reducirlo incluso a 10 segundos. Una cosa adicional que tendrás que tener en cuenta es conocer tu aplicación y conocer a tus clientes. En este caso, no estoy hablando de conocer a tus clientes para hacerles marketing. Es en el lado técnico. Si sabes que tus clientes son solo de escritorio, puedes asumir que tienen una conexión rápida, por ejemplo. Aquellos que son solo móviles deben tener tiempos de espera más largos porque su conexión puede ser lenta a veces. Por supuesto, nuestros tiempos de espera son muy generosos y probablemente no afectarán a nadie, pero nunca debes reducirlos. Gracias. Un par más.

¿Cómo funciona esto, esto es ambiguo, podría ser el ataque o la defensa, pero cómo funciona esto con el manejo de cargas de archivos y datos multiplataforma? Oh... No, tu aplicación. Si sabes que estás cargando 5 gigabytes, permite una hora para el tiempo de espera. Una vez más, eso depende de la aplicación. Quiero decir, este tiempo de espera, por supuesto, no funcionará si tienes que cargar un archivo de 10 gigabytes a través de una red 3G. Nunca funcionará. Si sabes que tu usuario debe hacer eso, permitámosles tener tiempos de espera más largos. Por ejemplo, no sé cómo funciona S3, pero estoy bastante seguro de que el punto de carga de S3 tiene tiempos de espera más largos que el de descarga, seguro. De lo contrario, nunca funcionará. Es solo un sentido común. Una vez más, usa el sentido común, amigos.

Eso es lo mejor que puedo darte. Última pregunta, Ian. Por lo general, hay un límite en el número de conexiones simultáneas permitidas a un servidor en general. Entonces, ¿el ataque Slow Loris todavía requiere una red distribuida para funcionar? Sí. Pero la cosa es que, bueno, no estrictamente. Digámoslo de esta manera. Si tu cliente es más potente que el servidor objetivo, es posible que solo necesites un solo cliente.

Entonces, si el servidor se queda sin RAM y sockets antes de que tu cliente se quede sin sockets, de los que estamos hablando de posiblemente el mismo IPS como 65K. Si el servidor se cae debido a la falta de RAM o descriptores de archivo antes de que termines los sockets en tu cliente, solo necesitas un solo cliente. Depende de con qué estás atacando y a qué estás atacando el objetivo. Sí, pero por naturaleza es quien se queda sin recursos primero. En teoría, sí. Tendrías más nodos para... Pero es bastante fácil porque si el servidor es solo un servidor normal, con el nuevo como ese, por ejemplo, en el servidor tenemos los CPUs AMD. En el cliente, tenemos los M.2 que son muy potentes. Si tienes una buena red, tal vez dos MacBook M.2 puedan derribar una máquina AMD. Depende de cómo esté configurada la máquina. Depende del entorno. No hay una regla de oro. Por lo general, requiere muchos recursos. Pero considera que la red no es uno de estos recursos. Por lo tanto, simplemente puedes poner máquinas EC2, dejar que inicien los sockets y no hacer nada. Eso es todo. Quiero decir, eventualmente espero que Amazon se dé cuenta de que estás creando sockets sin hacer nada. Pero eso es otro tema. Eso probablemente es otro tema.

Podemos dar un gran aplauso a Paolo. Fue absolutamente fascinante. Muchas gracias. Muchas gracias.