Primera publicación | ¿Cómo previene un navegador blockchain los ataques DoS?

Cuando se trata de navegadores, lo que salta a la mente de todos debe ser "Baidu, lo sabrás", "Internet comienza desde Sogou"... Estos navegadores que son muy conocidos e incluso mencionados por el tío son los portavoces de Internet. ., es la entrada a Internet. Pero si hay alguien que tiene una estrecha relación con Internet es la tecnología blockchain que hoy en día está en pleno apogeo. Internet cambia la vida y la tecnología blockchain cambia Internet. Entonces no cabe duda de que, como puerta de entrada a Internet, el navegador también debe ser inseparable de la tecnología blockchain. El navegador de cadena de bloques que nació de esto, como un producto de aterrizaje muy conocido, ha brindado un grado considerable de comodidad a los usuarios de cadena de bloques. El navegador de la cadena de bloques es un motor de búsqueda de la cadena de bloques y los usuarios pueden utilizar esta herramienta para buscar información específica sobre la cadena de bloques. Por ejemplo, Etherscan es un navegador de cadena de bloques para Ethereum. A través de Etherscan, los usuarios pueden obtener fácilmente información sobre bloques, direcciones, transacciones y otras actividades en Ethereum. En otras palabras, el navegador de blockchain se parece más a un sitio web oficial de consulta de blockchain. Entonces, ¿qué pasa con la seguridad del navegador blockchain en el escenario donde la mayoría de las aplicaciones blockchain enfrentan amenazas de seguridad? Hay relativamente pocos puntos de ataque para las aplicaciones de exploración de blockchain. Las razones son las siguientes: no se requiere autenticación ni autorización, por lo que no se filtra información privada; el uso generalizado de marcos web como Vue y React hace que sea menos probable que ocurra XSS (cross-site scripting); ¿no será atacado el dispositivo? ? ¿O está bien ser atacado? La respuesta es: No. Veamos primero a qué tipos de ataques pueden estar sujetos los navegadores de blockchain. Porque la mayoría de las funciones en el explorador de blockchain involucran la búsqueda de datos de la base de datos back-end o la consulta de datos directamente desde los nodos de blockchain. Cuando se trata de funciones de búsqueda y consulta, las personas generalmente piensan en dos posibles vulnerabilidades: inyección de SQL; DoS (ataque de denegación de servicio de denegación de servicio); sin embargo, al examinar diferentes navegadores, el equipo técnico de CertiK solo encontró un caso. de inyección SQL, y más del 50 % de los navegadores de cadena de bloques corren el riesgo de ser atacados por DoS. Por poner un ejemplo fácil de entender, un abuelo de barba blanca ve que el pollo frito de la tienda de cierto tío payaso se vende cada vez mejor, por lo que busca unos cuantos mafiosos para armar lío. Se pararon frente al mostrador de pedidos, hablaron con él de izquierda a derecha y plantearon varias preguntas y necesidades. El empleado estaba abrumado y no sabía qué quería el gángster después de ordenar durante dos horas. Los clientes hambrientos no podían. No esperé más y me fui. Esto no es suficiente, si los empleados de la tienda del Tío Payaso tienen mal genio, una vez que se intensifiquen por conflictos externos, todas las artes marciales se escenificarán directamente, y la tienda será un desastre... DoS: Negación La abreviatura de de Servicio significa denegación de servicio, y el comportamiento de ataque que causa DoS se denomina ataque DoS, que a menudo se usa para evitar que el sistema brinde servicios a usuarios legítimos. En el servidor, existe el hecho de que el cliente puede enviar solicitudes HTTP sin ningún esfuerzo, pero es posible que el servidor necesite consumir muchos recursos para procesar y responder a la solicitud. La capa de aplicación DoS utiliza tales características para atacar. En términos generales, el ataque y la defensa DoS son similares a este proceso, y el resultado final depende de quién tenga más recursos. Sin embargo, si la implementación del código de back-end tiene errores, una sola solicitud puede ser suficiente para bloquear el servidor. Este artículo compartirá con usted: algunos ejemplos de ataques DoS, el impacto de los ataques DoS y recomendaciones relacionadas para proteger aplicaciones. Hay varias formas de atacar DoS a un servidor. En términos generales, el objetivo elegirá: Consumir todos los recursos de CPU y memoria; Ocupar todos los enlaces de red; El siguiente es un análisis de caso de algunos servidores que pueden ser atacados por DoS, algunos de los cuales son causados ​​por errores de implementación de código, mientras que otros son causados por Causado por errores de configuración: 1. La API de acceso a recursos carece del límite de número https://fake.sample.com/api/v1/blocks?limit=10 La solicitud anterior obtiene información de bloque con el número indicado en el "límite" parámetro. Cuando el límite se establece en 10, devolverá información de los últimos 10 bloques. Cuando el número es pequeño, la solicitud funciona bien. Sin embargo, es posible que el backend no haya establecido un límite superior en el parámetro "límite". Cuando el equipo técnico de CertiK estableció el parámetro "límite" en 9999999 y envió la solicitud, la solicitud respondió con un error de "tiempo de espera de puerta de enlace 504" mucho después de ser procesada. Mientras el servidor procesa las solicitudes anteriores, el tiempo de respuesta de otras API aumenta significativamente. 9999999 también supera el número total de bloques en la cadena. La suposición es que el backend intenta obtener datos para cada bloque en la cadena de bloques. Si un atacante envía una gran cantidad de solicitudes con un parámetro de "límite" alto, el servidor no podrá responder a las solicitudes normales e incluso puede bloquearse directamente. 2. Consultas GraphQL anidadas Durante la investigación, el equipo técnico de CertiK encontró algunos recursos de blockchain que utilizan GraphQL. GraphQL es un lenguaje de consulta para API. En comparación con una API REST típica que usa múltiples solicitudes para solicitar múltiples recursos, GraphQL puede obtener todos los datos que necesita la aplicación con una sola solicitud. GraphQL tiene una alta tasa de uso, pero si no se implementan las medidas de protección correspondientes durante el uso, puede haber riesgos de seguridad. Al probar los navegadores de cadena de bloques, el equipo técnico de CertiK descubrió que uno de los navegadores usa la interfaz GraphQL, y los dos tipos definidos por él tienen una relación de inclusión mutua, lo que permite a los usuarios construir una consulta anidada muy compleja. El envío de consultas anidadas de este tipo puede causar un gran aumento en el uso de la CPU en el servidor. En circunstancias normales, algunas de estas solicitudes pueden aumentar el uso de la CPU a más del 100 %, lo que hace que el servidor no responda a las solicitudes normales de los usuarios. El "dos_query" en la figura a continuación muestra un ejemplo de graphql anidado: El impacto de una solicitud de GraphQL tan maliciosa en el servidor depende de la complejidad de la consulta y el rendimiento del servidor. El servidor puede estar en Se necesita mucho tiempo tiempo para finalmente responder a la consulta con éxito, pero también es posible que el servidor se bloquee directamente debido al alto uso de la CPU. Si desea obtener más información sobre la seguridad de GraphQL, puede visitar el enlace de referencia 1 al final del artículo 3. API RPC de Cosmos expuesta directamente https://fake.cosmos.api.com/txs?message.action=send& ;limit =100&tx.minheight=1 La API de Cosmos anterior busca 100 transacciones enviadas a partir del bloque 1. A partir de ahora, hay 2.712.445 bloques en la red principal de Cosmos. Entre los nodos de la API de RPC expuestos en CosmosHub, no pudimos encontrar ningún nodo que pudiera manejar la solicitud. Después de recibir esta solicitud, el servidor devolverá un error "502 Bad Gateway" después de un período de tiempo, lo que indica que la solicitud falló. Si el servidor RPC del nodo recibe cientos de solicitudes de búsqueda descritas anteriormente en unos pocos segundos, devolverá el siguiente error para todas las solicitudes de API. Algunos servidores de nodos pueden recuperarse de los errores, mientras que otros deben reiniciarse. Para que los lectores comprendan mejor el problema anterior y demuestren su efecto, el equipo técnico de CertiK configuró un nodo completo de Cosmos completamente sincronizado y utilizó la consulta mencionada anteriormente para atacar el nodo: "https://fake.cosmos.api. com /txs?message.action=send&limit=100&tx.minheight=1". Panel de uso de la CPU de Grafana El gráfico se puede dividir en tres etapas: El nodo está en funcionamiento, el uso de la CPU del sistema es del 35 % El nodo se enfrenta a un ataque DoS, el uso de la CPU del sistema alcanza el 97 % El nodo falla y no puede proporcionar nuevos datos a El gráfico de Grafana muestra que bajo un ataque DoS, el servidor colapsó en solo unos minutos. El operador tuvo que reiniciar el servidor porque no pudo conectarse al servidor usando SSH después de que el servidor fallara. 4. El controlador de solicitudes tiene fallas https://fake.sample.com/api/v1?feature=Always_time_out El equipo técnico de CertiK encontró una API que seguía cargándose y mostrando el tiempo de espera después de un tiempo, pero envió varias solicitudes al servidor No lo hará afectar el tiempo de respuesta de otras API. Una conjetura inicial es que los métodos de procesamiento para esa API en particular no requieren mucha CPU o memoria. Dado que este navegador de cadena de bloques no es de código abierto, es imposible obtener información relevante sobre la implementación del código API, y también es imposible determinar el propósito del punto final de la API en función de su nombre. Si bien es poco probable que el ataque a esta API bloquee el servidor, un atacante podría impedir que otros usuarios accedan a la API en este servidor enviando este tipo de solicitudes "Always hang and time out" para bloquear todas las conexiones de red. Como ejemplo, la función "sleep_to_handle_request" demuestra que una solicitud puede consumir poca CPU y memoria, pero demora mucho en cargarse y vincularse a la conexión de red. A diferencia de los otros tres casos en los que el servidor colapsó por completo o tardó mucho tiempo en recuperarse, en este caso el servidor se recuperó inmediatamente después de que se detuvo el ataque. Al encontrarse con un ataque DoS, el servidor vulnerable no podrá responder a las solicitudes normales de los usuarios. Algunos servidores pueden volver al estado normal inmediatamente o después de un período de tiempo después de que se detenga el ataque, mientras que otros se bloquearán por completo y deberán reiniciarse. No poder usar un explorador de blockchain puede causar una gran angustia a los usuarios. Porque los usuarios no pueden obtener fácilmente información sobre las actividades en cadena. Además, en una cadena basada en Cosmos, si un nodo sufre un ataque DoS, no solo el navegador de cadena de bloques conectado no puede obtener datos del nodo, sino que los usuarios no pueden usar la API para realizar operaciones como enviar tokens o delegar tokens a validadores. Cualquier aplicación tiene la amenaza de ser atacada por DoS, y no existe una solución en el mundo que pueda prevenir perfectamente los ataques DoS. Sin embargo, se pueden usar algunos métodos para aumentar el costo del ataque para dificultar que los atacantes potenciales realicen operaciones de ataque y reducir la probabilidad de vulnerabilidades en las aplicaciones de navegador de blockchain. Aquí, el equipo técnico de CertiK enumera algunas sugerencias para minimizar las posibilidades de que la aplicación sea atacada: 1. Limitación de velocidad Incluso si la API de backend es lo suficientemente segura en la implementación, un atacante también puede enviar una gran cantidad de solicitudes al servidor. Por lo tanto, las API deben, en cualquier caso, tener una tasa limitada para bloquear de forma temporal o permanente las IP maliciosas. Aunque la limitación de velocidad no puede resolver completamente el problema, es relativamente conveniente de operar y puede constituir la primera línea de defensa contra los ataques DoS. 2. Diseño e implementación mejorados El buen diseño del programa y la implementación del código pueden mostrar un mejor rendimiento bajo las mismas condiciones de hardware, y este efecto es más prominente en las funciones relacionadas con la búsqueda de bases de datos y el procesamiento de datos. Pero antes de pensar en el rendimiento, primero asegúrese de que su código esté libre de errores. Por lo tanto, vale la pena invertir mucho tiempo en escribir pruebas unitarias para su API antes de implementarla en producción para asegurarse de que funcionen como se espera. 3. Validación de entrada y restricciones de parámetros Si las variables proporcionadas por el usuario no se verifican y restringen, entonces el atacante puede abusar de la API. Después de determinar que el código funciona como se esperaba, el siguiente paso es asegurarse de que un atacante no pueda abusar de la API con entradas no convencionales. No se deben permitir solicitudes como consultas GraphQL para obtener datos para el bloque 9999999 o procesar bucles de nivel 1000. Por lo tanto, todas las entradas del usuario deben considerarse no confiables y el servidor debe validar la entrada del usuario antes de procesarla. En el caso mencionado anteriormente, la API de GraphQL puede establecer la cantidad máxima de capas para prevenir de manera efectiva el ataque DoS de consulta circular, mientras que la API de adquisición de datos de bloques puede limitar la cantidad máxima de bloques a un valor razonable como 50. Los desarrolladores pueden resumir los esquemas de restricción y verificación de entrada más adecuados para el programa actual de acuerdo con la implementación del código y el diseño del programa. 4. No exponga el RPC del nodo No todas las implementaciones del código API están bajo el control del desarrollador. Por ejemplo, los desarrolladores no recomiendan cambiar el código de la API RPC de Cosmos. El rendimiento de algunas consultas de búsqueda en Cosmos SDK no es muy bueno, entonces, ¿qué hacer? Una de las soluciones: crear una API contenedora alrededor de la API RPC de Cosmos y crear una base de datos que almacene datos de blockchain, que sincroniza los datos de blockchain de los nodos. La API de envoltura externa está expuesta al público y recibe y procesa las solicitudes de los usuarios antes de pasarlas a Cosmos RPC o buscar datos en la base de datos de back-end. Agregar una API externa evita que los usuarios interactúen directamente con la API de RPC del nodo. La base de datos evita que los nodos se vean abrumados por las consultas de búsqueda y los desarrolladores pueden optimizar la base de datos de la forma que deseen. En el foro de Cosmos, el usuario "kwunyeung" también propuso una solución: usar un proxy HTTP (como Nginx o Caddy) para proteger el puerto RPC. En términos generales, el punto de vista es el mismo: el puerto RPC no se puede divulgar directamente al público y, al mismo tiempo, se deben tomar medidas de protección. 5. Cumpla con los requisitos de hardware recomendados Incluso si se implementan todos los mecanismos de defensa anteriores, los usuarios aún deben prestar atención a los requisitos mínimos de hardware para ejecutar servidores API o nodos estables como Tendermint (consulte el enlace de referencia 2 para obtener más detalles). Si el servidor tiene dificultades para manejar las solicitudes de los usuarios comunes que visitan el sitio web, entonces el administrador debe considerar actualizar el hardware. Los ataques DoS pueden bloquear aplicaciones como los navegadores de cadena de bloques, lo que puede considerarse una amenaza fatal para la mayoría de las empresas. El equipo técnico de seguridad profesional de CertiK cuenta con amplia experiencia y conocimientos de seguridad profesional en evaluación de vulnerabilidad de aplicaciones, auditoría de código para diferentes lenguajes como Solidity, RUST y Go, y mantenimiento de seguridad de plataformas como Ethereum, Cosmos y Substrate.

Tags：

LTC