{"id":31924,"date":"2019-10-31T21:44:01","date_gmt":"2019-10-31T18:44:01","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy\/"},"modified":"2019-10-31T21:44:01","modified_gmt":"2019-10-31T18:44:01","slug":"ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy","title":{"rendered":"DDoS como ayuda: c\u00f3mo realizamos pruebas de estr\u00e9s y carga","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"DDoS
\n
\nLa empresa Variti desarrolla protecci\u00f3n contra bots y ataques DDoS, as\u00ed como realiza pruebas de estr\u00e9s y carga. En la conferencia HighLoad++ 2018, hablamos sobre c\u00f3mo proteger los recursos de diversos tipos de ataques. En resumen: a\u00edsle partes del sistema, utilice servicios en la nube y CDN, y mant\u00e9ngase actualizado regularmente. Pero sin empresas especializadas en protecci\u00f3n, usted a\u00fan no podr\u00e1 manejarlo \ud83d\ude42<\/i>
\n<\/a><\/noindex>
\nAntes de leer el texto, puede consultar un resumen breve en el sitio web de la conferencia<\/a><\/noindex>.
\nY si no le gusta leer o simplemente quiere ver el video, la grabaci\u00f3n de nuestra presentaci\u00f3n est\u00e1 a continuaci\u00f3n bajo el spoiler.<\/p>\n

Grabaci\u00f3n del informe<\/b>

\r\n \"Reproducir\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Muchas empresas ya saben c\u00f3mo realizar pruebas de carga, pero no todas hacen pruebas de estr\u00e9s. Algunos de nuestros clientes piensan que su sitio es invulnerable porque tienen un sistema de alta carga, y este protege bien contra ataques. Sin embargo, nosotros mostramos que esto no es del todo cierto.
\nPor supuesto, antes de realizar las pruebas, obtenemos permiso del cliente, con firma y sello, y con nuestra ayuda, no se puede realizar un ataque DDoS a nadie. La prueba se lleva a cabo en el momento elegido por el cliente, cuando la asistencia a su recurso es m\u00ednima, y los problemas de acceso no afectar\u00e1n a los clientes. Adem\u00e1s, dado que en el proceso de prueba siempre puede salir algo mal, mantenemos contacto constante con el cliente. Esto permite no solo informar sobre los resultados alcanzados, sino tambi\u00e9n hacer ajustes durante la prueba. Al finalizar la prueba, siempre elaboramos un informe en el que se\u00f1alamos las deficiencias encontradas y damos recomendaciones para corregir los puntos d\u00e9biles del sitio. <\/p>\n

C\u00f3mo trabajamos<\/h3>\n

\nAl realizar las pruebas, emulamos una botnet. Dado que trabajamos con clientes que no se encuentran en nuestras redes, para que la prueba no finalice en el primer minuto debido a l\u00edmites o protecciones activadas, generamos carga no desde una IP, sino desde nuestra propia subred. Adem\u00e1s, para crear una carga considerable, contamos con nuestro propio servidor de pruebas bastante potente.<\/p>\n

Postulados<\/h3>\n

<\/p>\n

Mucho no significa bien<\/b>
\nCuanto menor sea la carga que podamos llevar al recurso hasta el fallo, mejor. Si logramos que el sitio deje de funcionar con una solicitud por segundo, o incluso con una solicitud por minuto, ser\u00eda excelente. Porque, por ley de Murphy, los usuarios o delincuentes acabar\u00e1n cayendo en esa vulnerabilidad. <\/p><\/blockquote>\n

Un fallo parcial es mejor que un fallo total.<\/b>
\nSiempre aconsejamos que los sistemas sean heterog\u00e9neos. Adem\u00e1s, deben separarse a nivel f\u00edsico, no solo a trav\u00e9s de la contenedorizaci\u00f3n. En caso de separaci\u00f3n f\u00edsica, incluso si algo falla en el sitio, es probable que no deje de funcionar por completo, y los usuarios mantendr\u00e1n al menos un acceso parcial a la funcionalidad.<\/p><\/blockquote>\n

La arquitectura correcta es la base de la resiliencia.<\/b>
\nLa resiliencia del recurso y su capacidad para soportar ataques y cargas deben incorporarse desde la fase de dise\u00f1o, de hecho, desde el momento en que se dibujan los primeros diagramas de bloques en un cuaderno. Porque si se cometen errores fatales, se pueden corregir m\u00e1s adelante, pero ser\u00e1 muy dif\u00edcil.<\/p><\/blockquote>\n

No solo el c\u00f3digo debe ser bueno, tambi\u00e9n la configuraci\u00f3n.<\/b>
\nMuchos piensan que un buen equipo de desarrollo garantiza la resiliencia del servicio. Un buen equipo de desarrollo es realmente necesario, pero tambi\u00e9n debe haber una buena operaci\u00f3n, un buen DevOps. Es decir, se necesitan especialistas que configuren Linux y la red correctamente, que redacten las configuraciones en nginx de manera adecuada, que configuren los l\u00edmites, etc. De lo contrario, el recurso solo funcionar\u00e1 bien en pruebas, pero en producci\u00f3n, en alg\u00fan momento, todo fallar\u00e1.<\/p><\/blockquote>\n

Diferencias entre pruebas de carga y pruebas de estr\u00e9s.<\/b>
\nLas pruebas de carga permiten identificar los l\u00edmites de funcionamiento del sistema. Las pruebas de estr\u00e9s se centran en encontrar los puntos d\u00e9biles del sistema y se utilizan para romper ese sistema y observar c\u00f3mo se comporta durante la falla de ciertas partes. Sin embargo, la naturaleza de la carga suele ser desconocida para el cliente antes de comenzar las pruebas de estr\u00e9s.<\/p><\/blockquote>\n

<\/p>\n

Caracter\u00edsticas distintivas de los ataques L7.<\/h3>\n

\nLos tipos de carga los dividimos normalmente en cargas de nivel L7 y L3&4. L7 es carga a nivel de aplicaci\u00f3n, y con frecuencia se entiende solo HTTP, pero nosotros consideramos cualquier carga a nivel del protocolo TCP.
\nLos ataques L7 tienen ciertas caracter\u00edsticas distintivas. En primer lugar, se dirigen directamente a la aplicaci\u00f3n, lo que significa que es poco probable que se puedan mitigar mediante medios de red. Estos ataques utilizan l\u00f3gica y, gracias a eso, consumen de manera muy efectiva y con poco tr\u00e1fico, CPU, memoria, disco, base de datos y otros recursos.<\/p>\n

Inundaci\u00f3n HTTP<\/h3>\n

\nEn el caso de cualquier ataque, es m\u00e1s f\u00e1cil generar la carga que manejarla, y esto tambi\u00e9n es cierto para L7. El tr\u00e1fico de ataque no siempre es f\u00e1cil de distinguir del leg\u00edtimo, y a menudo esto se logra por la frecuencia, pero si todo est\u00e1 bien planificado, es imposible determinar a partir de los registros d\u00f3nde est\u00e1 el ataque y d\u00f3nde est\u00e1n las solicitudes leg\u00edtimas.
\nComo primer ejemplo, consideremos el ataque de Inundaci\u00f3n HTTP. En el gr\u00e1fico se puede ver que, por lo general, estos ataques son muy potentes; en el ejemplo a continuaci\u00f3n, el n\u00famero m\u00e1ximo de solicitudes super\u00f3 los 600 mil por minuto.<\/p>\n

\"DDoS
\n
\nLa Inundaci\u00f3n HTTP es la forma m\u00e1s simple de generar carga. Generalmente, se utiliza alguna herramienta de prueba de carga, como ApacheBench, y se establecen la solicitud y el objetivo. Con este enfoque sencillo, hay una alta probabilidad de encontrarse con el almacenamiento en cach\u00e9 del servidor, pero es f\u00e1cil de eludir. Por ejemplo, agregando cadenas aleatorias a la solicitud, lo que obligar\u00e1 al servidor a entregar una p\u00e1gina nueva constantemente.
\nTampoco hay que olvidar el user-agent al generar carga. Muchos user-agents de herramientas de prueba populares son filtrados por administradores de sistemas, y en tal caso, la carga puede simplemente no llegar al backend. Se puede mejorar significativamente el resultado al insertar en la solicitud un encabezado m\u00e1s o menos v\u00e1lido de un navegador.
\nA pesar de la simplicidad del ataque, la Inundaci\u00f3n HTTP tambi\u00e9n tiene sus desventajas. En primer lugar, se requieren grandes recursos para generar carga. En segundo lugar, estos ataques son muy f\u00e1ciles de detectar, especialmente si provienen de una sola direcci\u00f3n. Como resultado, las solicitudes comienzan a ser filtradas por administradores de sistemas o incluso a nivel del proveedor. <\/p>\n

Qu\u00e9 buscar<\/h3>\n

\nPara reducir la cantidad de solicitudes por segundo sin perder eficiencia, es necesario ser un poco creativo e investigar el sitio web. As\u00ed, se puede cargar no solo el canal o el servidor, sino tambi\u00e9n partes espec\u00edficas de la aplicaci\u00f3n, como bases de datos o sistemas de archivos. Tambi\u00e9n se pueden buscar \u00e1reas en el sitio que realicen grandes c\u00e1lculos: calculadoras, p\u00e1ginas de selecci\u00f3n de productos, entre otros. Finalmente, a menudo hay alg\u00fan script php en el sitio que genera una p\u00e1gina a partir de cientos de miles de l\u00edneas. Este script tambi\u00e9n carga significativamente al servidor y puede convertirse en un objetivo de ataque.<\/p>\n

D\u00f3nde buscar<\/h3>\n

\nCuando escaneamos un recurso antes de realizar pruebas, lo primero que miramos, por supuesto, es el propio sitio. Buscamos todo tipo de campos de entrada, archivos pesados, en resumen, todo lo que pueda causar problemas al recurso y ralentizar su funcionamiento. Aqu\u00ed ayudan las herramientas de desarrollo en Google Chrome y Firefox, que muestran los tiempos de respuesta de la p\u00e1gina.
\nTambi\u00e9n escaneamos subdominios. Por ejemplo, hay una tienda en l\u00ednea, abc.com, y tiene un subdominio admin.abc.com. Probablemente sea un panel de administraci\u00f3n con autenticaci\u00f3n, pero si se le aplica carga, puede causar problemas al recurso principal.
\nEl sitio puede tener un subdominio api.abc.com. Lo m\u00e1s probable es que sea un recurso para aplicaciones m\u00f3viles. Se puede encontrar la aplicaci\u00f3n en App Store o Google Play, establecer un punto de acceso especial, explorar la API y registrar cuentas de prueba. El problema es que a menudo las personas piensan que todo lo que est\u00e1 protegido por autenticaci\u00f3n es invulnerable a los ataques de denegaci\u00f3n de servicio. Supuestamente, la autenticaci\u00f3n es la mejor CAPTCHA, pero eso no es cierto. Crear 10-20 cuentas de prueba es sencillo, y al hacerlo, obtenemos acceso a funcionalidad compleja y sin proteger.
\nPor supuesto, miramos el historial, el robots.txt y WebArchive, ViewDNS, y buscamos versiones antiguas del recurso. A veces, ocurre que los desarrolladores lanzaron, digamos, mail2.yandex.net, y una versi\u00f3n antigua, mail.yandex.net, qued\u00f3. Este mail.yandex.net deja de ser mantenido, no se asignan recursos para su desarrollo, pero sigue consumiendo la base de datos. Por lo tanto, con la versi\u00f3n antigua se pueden utilizar eficazmente los recursos del backend y todo lo que est\u00e1 detr\u00e1s del dise\u00f1o. Claro, esto no sucede siempre, pero nos encontramos con algo similar con bastante frecuencia.
\nPor supuesto, analizamos todos los par\u00e1metros de la solicitud, la estructura de las cookies. Se podr\u00eda, por ejemplo, inyectar un valor en un array JSON dentro de una cookie, crear una gran anidaci\u00f3n y hacer que el recurso funcione de manera ineficaz durante mucho tiempo.<\/p>\n

Carga en la b\u00fasqueda<\/h3>\n

\nLo primero que se me ocurre al investigar un sitio web es cargar la base de datos, ya que casi todos tienen una funci\u00f3n de b\u00fasqueda, y desafortunadamente, en muchos casos est\u00e1 mal protegida. Por alguna raz\u00f3n, los desarrolladores no prestan suficiente atenci\u00f3n a la b\u00fasqueda. Pero hay una recomendaci\u00f3n: no se deben hacer consultas homog\u00e9neas, porque se puede encontrar con problemas de almacenamiento en cach\u00e9, como en el caso de un ataque por inundaci\u00f3n HTTP.
\nHacer consultas aleatorias en la base de datos tampoco siempre es efectivo. Es mucho mejor crear una lista de palabras clave relacionadas con la b\u00fasqueda. Volviendo al ejemplo de una tienda en l\u00ednea: supongamos que el sitio vende neum\u00e1ticos para autom\u00f3viles y permite ajustar el radio de las llantas, el tipo de coche y otros par\u00e1metros. Por lo tanto, las combinaciones de palabras relevantes har\u00e1n que la base de datos funcione en condiciones mucho m\u00e1s complejas.
\nAdem\u00e1s, vale la pena utilizar paginaci\u00f3n: es mucho m\u00e1s complicado para una b\u00fasqueda devolver la pen\u00faltima p\u00e1gina de resultados que la primera. Es decir, mediante la paginaci\u00f3n se puede diversificar un poco la carga.
\nEn el ejemplo a continuaci\u00f3n mostramos la carga en la b\u00fasqueda. Se puede ver que desde el primer segundo de la prueba, a diez solicitudes por segundo, el sitio colaps\u00f3 y no respondi\u00f3.<\/p>\n

\"DDoS
\n<\/p>\n

\u00bfY si no hay b\u00fasqueda?<\/h3>\n

\nSi no hay b\u00fasqueda, no significa que el sitio no contenga otros campos de entrada vulnerables. Un campo de este tipo puede ser la autenticaci\u00f3n. Hoy en d\u00eda a los desarrolladores les gusta crear hashes complejos para proteger la base de datos de nombres de usuario de ataques de tablas arco\u00edris. Esto es bueno, pero tales hashes consumen muchos recursos de CPU. Un gran flujo de intentos de autenticaci\u00f3n falsos puede llevar a la sobrecarga del procesador, lo que resulta en que el sitio deje de funcionar.
\nLa presencia en el sitio de todo tipo de formularios para comentarios y retroalimentaci\u00f3n es una raz\u00f3n para enviar textos muy grandes o simplemente crear un gran spam. A veces, los sitios aceptan archivos adjuntos, incluidos aquellos en formato gzip. En tal caso, tomamos un archivo de 1TB, lo comprimimos a trav\u00e9s de gzip a unos pocos bytes o kilobytes y lo enviamos al sitio. Luego se descomprime y se obtiene un efecto muy interesante. <\/p>\n

Rest API<\/h3>\n

\nMe gustar\u00eda dedicar un poco de atenci\u00f3n a servicios tan populares hoy en d\u00eda como el Rest API. Proteger un Rest API es mucho m\u00e1s complicado que proteger un sitio web ordinario. Incluso los m\u00e9todos b\u00e1sicos de protecci\u00f3n contra ataques de fuerza bruta y otras actividades ileg\u00edtimas no funcionan para un Rest API.
\nEs muy f\u00e1cil romper un Rest API porque se conecta directamente a la base de datos. Adem\u00e1s, la interrupci\u00f3n de este servicio puede tener consecuencias bastante graves para el negocio. Esto se debe a que el Rest API no solo est\u00e1 vinculado al sitio principal, sino tambi\u00e9n a aplicaciones m\u00f3viles y a ciertos recursos internos del negocio. Si todo esto falla, el efecto es mucho m\u00e1s fuerte que en el caso de un simple sitio web que deja de funcionar. <\/p>\n

Carga de contenido pesado<\/h3>\n

\nSi nos proponen probar una aplicaci\u00f3n de una sola p\u00e1gina, una p\u00e1gina de aterrizaje o una tarjeta de visita con funcionalidad sencilla, buscamos contenido pesado. Por ejemplo, grandes im\u00e1genes que proporciona el servidor, archivos binarios, documentaci\u00f3n en PDF; intentamos descargar todo esto. Estas pruebas sobrecargan bien el sistema de archivos y saturan los canales, por lo que son efectivas. Es decir, incluso si no haces caer el servidor al descargar un archivo grande a velocidades bajas, simplemente saturar\u00e1s el canal del servidor objetivo y entonces ocurrir\u00e1 una denegaci\u00f3n de servicio.
\nEn el ejemplo de esta prueba, se puede ver que a una velocidad de 30 RPS el sitio dej\u00f3 de responder o dio errores de servidor 500.<\/p>\n

\"DDoS
\n
\nNo debemos olvidar la configuraci\u00f3n de los servidores. A menudo se puede ver que una persona compr\u00f3 una m\u00e1quina virtual, instal\u00f3 Apache, lo configur\u00f3 todo por defecto, coloc\u00f3 una aplicaci\u00f3n PHP y abajo se puede ver el resultado. <\/p>\n

\"DDoS
\n
\nAqu\u00ed la carga fue al ra\u00edz y alcanz\u00f3 solo 10 RPS. Esperamos 5 minutos y el servidor fall\u00f3. Aunque no se sabe con certeza por qu\u00e9 fall\u00f3, se sospecha que simplemente se qued\u00f3 sin memoria y por eso dej\u00f3 de responder.<\/p>\n

Basado en ondas<\/h3>\n

\nEn los \u00faltimos uno o dos a\u00f1os, los ataques basados en ondas se han vuelto bastante populares. Esto se debe a que muchas organizaciones compran ciertos equipos para protegerse contra DDoS, los cuales requieren un tiempo espec\u00edfico para acumular estad\u00edsticas antes de empezar a filtrar el ataque. Es decir, no filtran el ataque en los primeros 30-40 segundos, ya que est\u00e1n acumulando datos y aprendiendo. Por lo tanto, durante esos 30-40 segundos se puede lanzar tal cantidad de tr\u00e1fico al sitio que el recurso estar\u00e1 ca\u00eddo durante un tiempo prolongado, hasta que se procesen todas las solicitudes.
\nEn el caso del ataque a continuaci\u00f3n, hubo un intervalo de 10 minutos, despu\u00e9s del cual lleg\u00f3 una nueva porci\u00f3n de ataque, modificada.<\/p>\n

\"DDoS
\n
\nEs decir, la protecci\u00f3n aprendi\u00f3, activ\u00f3 la filtraci\u00f3n, pero lleg\u00f3 una nueva porci\u00f3n de ataque completamente diferente, y la protecci\u00f3n comenz\u00f3 a aprender de nuevo. De hecho, la filtraci\u00f3n deja de funcionar, la protecci\u00f3n se vuelve ineficaz y el sitio no est\u00e1 disponible.
\nLos ataques basados en ondas se caracterizan por valores muy altos en el pico; pueden alcanzar hasta cien mil o un mill\u00f3n de solicitudes por segundo en el caso de L7. Si hablamos de L3&4, puede haber cientos de gigabits de tr\u00e1fico, o, en consecuencia, cientos de mpps, si los contamos en paquetes.
\nEl problema de estos ataques est\u00e1 en la sincronizaci\u00f3n. Los ataques provienen de un botnet, y para crear un pico muy grande en un solo momento, se requiere un alto grado de sincronizaci\u00f3n. Y esta coordinaci\u00f3n no siempre se logra: a veces, el resultado es un pico parab\u00f3lico que se ve bastante pobre.<\/p>\n

No solo HTTP<\/h3>\n

\nAdem\u00e1s de HTTP en el nivel L7, nos gusta explotar otros protocolos. Por lo general, un sitio web com\u00fan, especialmente en un hosting est\u00e1ndar, expone protocolos de correo y MySQL. Los protocolos de correo son menos susceptibles a la carga que las bases de datos, pero tambi\u00e9n se pueden sobrecargar de manera bastante efectiva, resultando en un CPU sobrecargado en el servidor.
\nLogramos tener \u00e9xito utilizando la vulnerabilidad SSH de 2016. Ahora esta vulnerabilidad ha sido pr\u00e1cticamente corregida por todos, pero eso no significa que no se pueda cargar SSH. Se puede. Simplemente se genera una carga enorme de autorizaciones, SSH consume casi toda la CPU del servidor y el sitio web comienza a fallar con solo una o dos solicitudes por segundo. Por lo tanto, estas una o dos solicitudes no se pueden distinguir de la carga leg\u00edtima en los registros.
\nSiguen siendo relevantes muchas conexiones que abrimos en los servidores. Antes, esto era un problema en Apache, y ahora tambi\u00e9n lo es en nginx, ya que a menudo se configura por defecto. El n\u00famero de conexiones que nginx puede mantener abiertas est\u00e1 limitado, por lo que si alcanzamos este n\u00famero de conexiones, nginx no aceptar\u00e1 una nueva conexi\u00f3n y, como resultado, el sitio web deja de funcionar.
\nNuestro cl\u00faster de prueba tiene suficiente CPU para atacar el SSL handshake. En principio, como muestra la pr\u00e1ctica, los botnets tambi\u00e9n a veces les gusta hacer esto. Por un lado, est\u00e1 claro que sin SSL no se puede evitar, debido a la presentaci\u00f3n en Google, el ranking y la seguridad. Por otro lado, el SSL, lamentablemente, tiene un problema con la CPU. <\/p>\n

L3&4<\/h3>\n

\nCuando hablamos de un ataque en niveles L3&4, generalmente nos referimos a un ataque a nivel de canal. Esta carga es casi siempre distinguible de la carga leg\u00edtima, a menos que se trate de un ataque SYN-flood. El problema de los ataques SYN-flood para los medios de protecci\u00f3n radica en su gran volumen. El m\u00e1ximo registrado en L3&4 fue de 1.5-2 Tbps. Este tipo de tr\u00e1fico es muy dif\u00edcil de manejar incluso para grandes empresas, incluyendo Oracle y Google.
\nSYN y SYN-ACK son paquetes que se utilizan para establecer una conexi\u00f3n. Por lo tanto, es dif\u00edcil distinguir un SYN-flood de una carga leg\u00edtima: no est\u00e1 claro si es un SYN que lleg\u00f3 para establecer una conexi\u00f3n o parte de un flood.<\/p>\n

UDP-flood<\/h3>\n

\nNormalmente, los atacantes no tienen la capacidad que tenemos nosotros, por lo que pueden usar amplificaci\u00f3n para llevar a cabo ataques. Es decir, el atacante escanea internet y encuentra servidores vulnerables o mal configurados que, por ejemplo, responden con tres SYN-ACK a un solo paquete SYN. Al falsificar la direcci\u00f3n de origen desde la direcci\u00f3n del servidor objetivo, se puede aumentar la capacidad, digamos, hasta tres veces, redirigiendo el tr\u00e1fico hacia la v\u00edctima.<\/p>\n

\"DDoS
\n
\nEl problema de las amplificaciones radica en su dif\u00edcil detecci\u00f3n. Un ejemplo reciente es el conocido caso con memcached vulnerable. Adem\u00e1s, ahora hay muchos dispositivos IoT y c\u00e1maras IP, que a menudo est\u00e1n configurados por defecto y, en su mayor\u00eda, de manera incorrecta, por lo que los atacantes utilizan estos dispositivos para realizar ataques con mayor frecuencia. <\/p>\n

\"DDoS
\n<\/p>\n

SYN-flood complicado<\/h3>\n

\nEl SYN-flood es probablemente el tipo de ataque m\u00e1s interesante para los desarrolladores. El problema es que a menudo los administradores de sistemas utilizan el bloqueo por IP como medida de protecci\u00f3n. De hecho, no solo los administradores que act\u00faan siguiendo gu\u00edas se ven afectados por el bloqueo por IP, sino que, lamentablemente, tambi\u00e9n ciertas soluciones de seguridad que se compran a un alto costo.
\nEste m\u00e9todo puede resultar en un desastre, ya que si los atacantes suplantan IP<\/a>, la empresa bloquear\u00e1 su propia subred. Cuando el firewall bloquea su propio cl\u00faster, las interacciones externas colapsar\u00e1n y el recurso fallar\u00e1.
\nAdem\u00e1s, lograr bloquear la propia red no es complicado. Si en la oficina del cliente hay una red Wi-Fi, o si el rendimiento de los recursos se mide mediante diversos monitoreos, tomamos la direcci\u00f3n IP de ese sistema de monitoreo o del cliente de Wi-Fi de la oficina y la utilizamos como fuente. Aparentemente, el recurso est\u00e1 disponible, pero las direcciones IP dirigidas est\u00e1n bloqueadas. As\u00ed, una red Wi-Fi de una conferencia como HighLoad, donde se presenta un nuevo producto de la empresa, puede quedar bloqueada, lo que implica ciertos costos empresariales y econ\u00f3micos.
\nDurante la prueba, no podemos utilizar amplificaci\u00f3n a trav\u00e9s de memcached con recursos externos, porque hay acuerdos para enviar tr\u00e1fico solo a direcciones IP permitidas. Por lo tanto, utilizamos amplificaci\u00f3n a trav\u00e9s de SYN y SYN-ACK, cuando al enviar un SYN, el sistema responde con dos o tres SYN-ACK, multiplicando as\u00ed el ataque por dos o tres. <\/p>\n

Herramientas<\/h3>\n

\nUna de las principales herramientas que utilizamos para carga en el nivel L7 es Yandex-tank. En particular, se utiliza un fantasma como ca\u00f1\u00f3n, adem\u00e1s de varios scripts para generar municiones y analizar resultados.
\nPara analizar el tr\u00e1fico de red se utiliza Tcpdump y para el an\u00e1lisis del servidor Nmap. Para crear carga en los niveles L3&4 se utilizan OpenSSL y un poco de magia propia con la biblioteca DPDK. DPDK es una biblioteca de Intel que permite trabajar con la interfaz de red, omitiendo el stack de Linux, aumentando as\u00ed la eficiencia. Por supuesto, no usamos DPDK solo en los niveles L3&4, sino tambi\u00e9n en el nivel L7, ya que permite generar un flujo de carga muy alto, de varios millones de solicitudes por segundo desde una sola m\u00e1quina.
\nTambi\u00e9n utilizamos ciertos generadores de tr\u00e1fico y herramientas especiales que desarrollamos para pruebas espec\u00edficas. Si recordamos la vulnerabilidad bajo SSH, el conjunto mencionado anteriormente no puede ser explotado. Si atacamos un protocolo de correo, utilizamos utilidades de correo o simplemente escribimos scripts para ellas.<\/p>\n

\n

Conclusiones<\/h3>\n

\nComo conclusi\u00f3n, me gustar\u00eda decir:<\/p>\n