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

Rate this content
Bookmark

Las aplicaciones web son comúnmente vulnerables a varios ataques de Denegación de Servicio Distribuido, a veces de formas inesperadas. Un ejemplo es el ataque SlowLoris, una explotación que provoca interrupción del servicio simplemente enviando los datos al servidor lo más lento posible. En esta charla contaré la historia de cómo tomó casi 13 años proteger por completo a Node del ataque SlowLoris. También mostraré que a veces, priorizar el rendimiento puede llevar a soluciones incorrectas que resultan en una falsa sensación de protección.

29 min
14 Apr, 2023

Video Summary and Transcription

Las aplicaciones web enfrentan constantes amenazas de ataques DDoS, incluido el nuevo ataque Zoloris que puede derribar un servidor con un ancho de banda mínimo. Node.js ha tenido vulnerabilidades en su manejo de tiempo de espera, pero las versiones recientes como Node 18 brindan una mejor protección. Se recomienda NGINX para protección contra ataques slow loris debido a su manejo superior de tiempo de espera. Mitigar los ataques slow loris en WebSockets implica imponer tiempos de espera más largos y cerrar clientes inactivos. Es importante priorizar la seguridad sobre el rendimiento y utilizar el sentido común en el desarrollo de software.

Available in English

1. Introducción y Antecedentes

Short description:

A veces tu peor enemigo es simplemente la lentitud. Al final de la charla, te sorprenderás de lo que sucedió. Soy un ingeniero Dx de Nearform y cofundador y arquitecto principal de Orama. Nearform es una empresa de servicios profesionales completamente remota. Somos 300 y contando, completamente remotos y desafortunadamente no puedes escapar de nosotros en NPM. Sin Orama, planeamos reinventar la industria de búsqueda de texto utilizando JavaScript y manteniéndonos de código abierto.

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.

2. DDoS Attacks and the Zoloris

Short description:

Hoy en día, las aplicaciones web son cruciales, sirviendo funciones importantes como la telemedicina, la banca en línea y la seguridad nacional, así como propósitos más triviales como las redes sociales y la mensajería. Sin embargo, incluso estas aplicaciones aparentemente triviales son vitales para ciertas personas, como los ancianos que dependen de las aplicaciones de mensajería para comunicarse. La amenaza constante de los ataques DDoS se cierne sobre todas las aplicaciones, ya que los atacantes siempre superan en número a los defensores. Los ataques DDoS implican abrumar un recurso de red con solicitudes maliciosas, y la variante distribuida, donde el tráfico malicioso proviene de múltiples fuentes, es particularmente difícil de combatir. Si bien alguna vez se creyó que los ataques DDoS requerían una cantidad significativa de recursos, una nueva amenaza llamada Zoloris demuestra lo contrario.

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.

3. Zoloris Attack and Server Resources

Short description:

El ataque Zoloris es un ataque DDoS que utiliza un ancho de banda mínimo y puede extenderse a cualquier protocolo que se ejecute sobre TCP. Fue creado por Robert Tenzin en 2009. Al analizar cómo funciona este ataque, podemos derribar cualquier servidor, ya que solo se necesita un solo servidor para dejar todo inactivo. En HTTP, el flujo normal implica que un cliente se conecte al servidor, envíe una solicitud y reciba una respuesta. Cada socket consume la misma cantidad de recursos en el servidor. Mantener los sockets en el servidor es costoso, ya que utiliza recursos del sistema y enlaza los recursos de red a un descriptor de archivo.

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.

4. Slow-lorist Attack and Defense Strategies

Short description:

Este descriptor de archivo que se crea afectará el número ULIMIT de tu proceso. ULIMIT es un número de archivos, un parámetro del sistema que especifica cuántos descriptores de archivo puede abrir tu proceso. El ataque slow-lorist es bastante único porque cada cliente se conecta y nunca termina la respuesta. Con el tiempo, cada vez más clientes siguen conectándose y nunca se desconectan, lo que provoca interrupciones del servicio. ¿Cómo lo detenemos? 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. Ninguna de las estrategias que puedas implementar será precisa. La primera es una medida temporal que consiste en prohibir las IP ofensivas durante un tiempo.

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.

5. Manejo de tiempo de espera de Node

Short description:

A largo plazo, debes tener una aplicación de cumplimiento de velocidad o tiempo de espera muy buena. Node ha estado parcialmente desprotegido hasta 2018. Desde la primera versión, Node incluía un servidor HTTP pero no un manejo efectivo de tiempo de espera. En la versión 10.14 de Node se introdujo el tiempo de espera de encabezados del servidor HTTP. 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 fue un gran problema.

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.

6. Protección en Node 14 y versiones anteriores

Short description:

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. ¿Estamos seguros? Estábamos casi protegidos. Las contramedidas que teníamos en Node 14 eran débiles, porque se necesitaba una configuración personalizada para protegerse. Básicamente, el problema era que el tiempo de espera se verificaba después de recibir el siguiente byte. Entonces, para un ataque muy rápido, funciona, pero para un ataque lento, como los ataques de slow loris. Digamos 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.

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.

7. Mejoras de seguridad en Node 18

Short description:

Con el lanzamiento de Node 18.0.0, finalmente estamos seguros por defecto. Node ahora verifica las solicitudes periódicamente, mantiene una lista de sockets conectados al servidor HTTP y corta las conexiones expiradas. Node 18 está protegido contra slow lorries. Siempre prioriza la seguridad sobre el rendimiento. Sacrificar el rendimiento por seguridad incluso puede llevar a ganancias de rendimiento inesperadas.

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.

8. Validación, Comillas Inteligentes y Sentido Común

Short description:

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.

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.

QnA

Protección de NGINX contra ataques Slow Loris

Short description:

La única forma de protegerse contra los ataques Slow Loris es un manejo adecuado de los tiempos de espera. NGINX tiene un mejor manejo de los tiempos de espera, lo que lo hace más adecuado para el trabajo. NGINX se enfoca únicamente en HTTP, lo que permite una protección más rápida contra nuevos ataques.

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.

Mitigación de ataques Slow Loris para WebSockets

Short description:

Para mitigar los ataques Slow Loris en WebSockets, se deben aplicar tiempos de espera más largos y un tiempo de espera muy largo para los Sockets inactivos. Cerrar los clientes inactivos después de un cierto período de tiempo, dependiendo de tu aplicación.

¿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.

Números mágicos y ataques DDoS

Short description:

No hay vulnerabilidades importantes similares que nos afecten con la última versión de Node. Slowloris sigue siendo el ataque DDoS más común, pero existen otras formas de ataques populares de los que las personas deben estar conscientes y mitigar. Estos ataques pueden clasificarse como lentos o rápidos, según la cantidad de tráfico que generen.

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.

Medidas de seguridad de Node y valores de tiempo de espera

Short description:

¿Deberíamos mantener las medidas de seguridad que recomiendas en Node, incluso cuando lo estamos ejecutando detrás de una configuración de Nginx? Absolutamente. La mayoría de las veces, estos tiempos de espera nunca se activarán, por lo que no causarán ningún daño dejarlos abiertos. En Node 18, si estás en Node 16, es posible que lo pienses dos veces, pero dado que estos tiempos de espera son tan altos, nunca se activarán. Node 18 se lanzará como LTS en octubre, así que actualiza. El impacto en el rendimiento de verificar todas las solicitudes en Node 18+ puede variar, y no hay un valor óptimo para el intervalo de verificación. El tiempo de espera del encabezado en Node 18+ está configurado en un minuto de forma predeterminada, pero puedes ajustarlo según tu aplicación y clientes. Conoce tu aplicación y tus clientes para determinar los valores de tiempo de espera adecuados.

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.

Manejo de Cargas de Archivos y Tiempos de Espera

Short description:

Si estás manejando cargas de archivos y datos multiplataforma, considera el tamaño y las condiciones de la red. Permite tiempos de espera más largos para cargas grandes y usa el sentido común. Los puntos de carga de S3 pueden tener tiempos de espera más largos que los puntos de descarga.

¿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.

Ataque Slow Loris y Agotamiento de Recursos

Short description:

El ataque Slow Loris todavía requiere una red distribuida para funcionar, pero no es estrictamente necesario. Si el cliente es más potente que el servidor objetivo, un solo cliente puede ser suficiente. Los recursos del servidor, como la RAM y los sockets, determinan cuál se agota primero. No hay una regla de oro, ya que depende de varios factores como la configuración de la máquina y el entorno. La red no es un recurso significativo, por lo que se pueden utilizar máquinas EC2 para iniciar sockets sin hacer nada.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Top Content
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.
Node Congress 2022Node Congress 2022
34 min
Out of the Box Node.js Diagnostics
In the early years of Node.js, diagnostics and debugging were considerable pain points. Modern versions of Node have improved considerably in these areas. Features like async stack traces, heap snapshots, and CPU profiling no longer require third party modules or modifications to application source code. This talk explores the various diagnostic features that have recently been built into Node.
You can check the slides for Colin's talk here. 
JSNation 2023JSNation 2023
22 min
ESM Loaders: Enhancing Module Loading in Node.js
Native ESM support for Node.js was a chance for the Node.js project to release official support for enhancing the module loading experience, to enable use cases such as on the fly transpilation, module stubbing, support for loading modules from HTTP, and monitoring.
While CommonJS has support for all this, it was never officially supported and was done by hacking into the Node.js runtime code. ESM has fixed all this. We will look at the architecture of ESM loading in Node.js, and discuss the loader API that supports enhancing it. We will also look into advanced features such as loader chaining and off thread execution.
JSNation 2023JSNation 2023
30 min
The State of Passwordless Auth on the Web
Can we get rid of passwords yet? They make for a poor user experience and users are notoriously bad with them. The advent of WebAuthn has brought a passwordless world closer, but where do we really stand?
In this talk we'll explore the current user experience of WebAuthn and the requirements a user has to fulfill for them to authenticate without a password. We'll also explore the fallbacks and safeguards we can use to make the password experience better and more secure. By the end of the session you'll have a vision for how authentication could look in the future and a blueprint for how to build the best auth experience today.

Workshops on related topic

Node Congress 2023Node Congress 2023
109 min
Node.js Masterclass
Workshop
Have you ever struggled with designing and structuring your Node.js applications? Building applications that are well organised, testable and extendable is not always easy. It can often turn out to be a lot more complicated than you expect it to be. In this live event Matteo will show you how he builds Node.js applications from scratch. You’ll learn how he approaches application design, and the philosophies that he applies to create modular, maintainable and effective applications.

Level: intermediate
React Summit 2023React Summit 2023
56 min
0 to Auth in an hour with ReactJS
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool. There are multiple alternatives that are much better than passwords to identify and authenticate your users - including SSO, SAML, OAuth, Magic Links, One-Time Passwords, and Authenticator Apps.
While addressing security aspects and avoiding common pitfalls, we will enhance a full-stack JS application (Node.js backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session securely for subsequent client requests, validating / refreshing sessions- Basic Authorization - extracting and validating claims from the session token JWT and handling authorization in backend flows
At the end of the workshop, we will also touch other approaches of authentication implementation with Descope - using frontend or backend SDKs.
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
JSNation 2023JSNation 2023
104 min
Build and Deploy a Backend With Fastify & Platformatic
WorkshopFree
Platformatic allows you to rapidly develop GraphQL and REST APIs with minimal effort. The best part is that it also allows you to unleash the full potential of Node.js and Fastify whenever you need to. You can fully customise a Platformatic application by writing your own additional features and plugins. In the workshop, we’ll cover both our Open Source modules and our Cloud offering:- Platformatic OSS (open-source software) — Tools and libraries for rapidly building robust applications with Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (currently in beta) — Our hosting platform that includes features such as preview apps, built-in metrics and integration with your Git flow (https://platformatic.dev/). 
In this workshop you'll learn how to develop APIs with Fastify and deploy them to the Platformatic Cloud.
JSNation Live 2021JSNation Live 2021
156 min
Building a Hyper Fast Web Server with Deno
WorkshopFree
Deno 1.9 introduced a new web server API that takes advantage of Hyper, a fast and correct HTTP implementation for Rust. Using this API instead of the std/http implementation increases performance and provides support for HTTP2. In this workshop, learn how to create a web server utilizing Hyper under the hood and boost the performance for your web apps.
React Summit 2022React Summit 2022
164 min
GraphQL - From Zero to Hero in 3 hours
Workshop
How to build a fullstack GraphQL application (Postgres + NestJs + React) in the shortest time possible.
All beginnings are hard. Even harder than choosing the technology is often developing a suitable architecture. Especially when it comes to GraphQL.
In this workshop, you will get a variety of best practices that you would normally have to work through over a number of projects - all in just three hours.
If you've always wanted to participate in a hackathon to get something up and running in the shortest amount of time - then take an active part in this workshop, and participate in the thought processes of the trainer.