Denegación de servicio por consultas de SQL: ¿son las consultas selectivas mejores que las consultas que devuelven mucho?

Question

Denegación de servicio por consultas de SQL: ¿son las consultas selectivas mejores que las consultas que devuelven mucho?

#1 de phyrfox (2 votos)
#2 de Woody Payne (1 votos)
#3 de munkeyoto (0 votos)

1

Digamos que tengo un formulario de búsqueda para un blog (o cualquier otro sistema que usaría SQL para ejecutar consultas) y quiero protegerlo de la denegación de servicio. Un atacante quiere atacar mi sitio inundando la función de búsqueda, lo que causaría muchas consultas SQL y podría resultar en DoS.

Esto es teórico, así que no se trata de un solo tipo de lenguaje o sistema de administración de base de datos, pero si lo desea, puede imaginar que es PHP y MySQL (aunque me pregunto por los efectos en general más que por una plataforma específica) .

Una solicitud como GET /search.php?s=[SEARCH] busca en la base de datos todos los artículos que contienen [SEARCH] y los devuelve. Digamos que la longitud máxima de caracteres para [SEARCH] es 128.

Me pregunto en términos de "pérdida de rendimiento", que sería la peor forma de ataque entre estos dos escenarios:

El atacante busca una cadena aleatoria de 128 caracteres (por ejemplo, aisoizeuf[...]deuedujed ).
El atacante busca un solo carácter cada vez (por ejemplo, e ).

Al principio pensé que el ataque # 1 sería más efectivo, legitimando así un límite estricto en la longitud del carácter de la consulta de búsqueda. Pero luego pensé, ya que en mi ejemplo estamos hablando de un blog, que las búsquedas múltiples en un solo personaje pueden devolver muchos más artículos porque casi todo lo que escriba contendrá al menos una vocal. Entonces me di cuenta de que tal vez no es una respuesta tan clara.

El ataque # 1 requerirá más recursos para enviar la consulta y escanear todas las entradas en la base de datos, pero no devolverá nada, mientras que el ataque # 2 hará lo contrario: no ocupará muchos recursos para escanear la base de datos, pero dado que casi todas las entradas contendrán una aparición de la consulta de búsqueda, devolverá casi todas las entradas en la base de datos

¿Qué ataque crees que será más peligroso y usará más recursos?

denial-of-service databases

pregunta Sewer 27.04.2016 - 18:33

fuente

3 respuestas

Lea otras preguntas en las etiquetas denial-of-service databases

keytool -genseckey -alias TDES -keyalg DESede -keysize 128 funciona dentro de la carpeta jre / bin pero no cuando keytool.exe está en otra ubicación Si un pirata informático obtuviera un número de seguimiento de envío, ¿qué podría verse comprometido?

score 2 · Answer 1

Puede mitigar estos dos problemas creando un índice FULLTEXT. En otras palabras, en lugar de hacer que el sistema de la base de datos lea la tabla completa y escanee cada carácter en cada campo, el sistema crea un índice que se puede buscar rápidamente y descartar palabras o letras comunes. Su atacante puede buscar "e" tan rápido como lo desee, y el índice responderá sin resultados devueltos en una fracción muy pequeña de un segundo (y con el almacenamiento en caché apropiado, las búsquedas futuras costarán incluso menos). Esto puede reducir la cantidad de búsquedas necesarias de millones de bytes a unos pocos cientos de bytes, lo que es una operación trivial para una computadora.

La mayoría de los índices FULLTEXT tienden a usar una implementación de "b-tree" (o, binary tree). Esto significa que incluso si su atacante envía 128 caracteres aleatorios, a diferencia de un solo carácter, la base de datos solo tiene que ir hasta que pueda demostrar que no hay valores coincidentes, lo que significa que no buscará los 128 caracteres, suponiendo que estemos hablando. sobre los valores aleatorios reales. La búsqueda más exhaustiva que podría realizar el atacante sería utilizar palabras reales de un diccionario que también se encuentran en su blog. También puede restringir las búsquedas a una longitud mínima descartando las palabras con menos de, por ejemplo, tres caracteres de longitud. Esto haría que su índice sea más efectivo y reduciría las capacidades para realizar búsquedas pequeñas de spam.

En lo que se refiere a "peligroso", es poco probable que un ataque cueste mucho en términos de costo, suponiendo que fuera un blog personal: toda la base de datos puede caber en la memoria y por lo tanto no contribuiría mucho a la carga del servidor incluso si fuera golpeado cientos de veces por segundo. Es más probable que ocurra una DDoS simplemente porque el sistema operativo de su servidor no puede manejar más conexiones pendientes en lugar de la limitación de la base de datos en sí. La mayoría de las bases de datos pueden manejar cientos de consultas de índice simples por segundo, incluso en una computadora doméstica.

score 1 · Answer 2

Luego de que el sitio de un cliente se descompuso debido a este problema exacto, introdujimos una solución un tanto simplista que ayudó a minimizar dramáticamente el efecto de tales ataques. Como dijo Phyrfox en su respuesta, un índice FULLTEXT es una herramienta muy efectiva tanto para el rendimiento como para el contador DoS.

Como ya estábamos rastreando a los visitantes para obtener información estadística, dimos un paso más y comenzamos a rastrear el comportamiento de sus formularios. A cada usuario se le asignó una pequeña columna en sus estadísticas que rastrearon cuántas veces enviaron un formulario (o llenaron un formulario en el caso de solicitudes de ajax, pero que se registraron solo en usuarios). Cuando el total del usuario llegó a 32 ( un cuarto del valor máximo de un minúsculo) todas las solicitudes para utilizar el formulario se retrasaron un segundo. Cuando el total llegó a 48, dos segundos, 64, tres segundos, etc. En el momento de llegar a 128, se prohibió al usuario cualquier intento de usar los formularios pero no se le informó de esto . La probabilidad de que un atacante cambie las direcciones IP constantemente es bastante baja en tan poco tiempo y asumirán que la desaceleración se debe al éxito de su ataque DoS y no a la estrategia DoS contraria. El método funciona bastante similar a cómo funciona el algoritmo bcrypt para las contraseñas. Cuanto más alguien intenta procesarlo, más lento se vuelve. En lugar de procesar cualquier consulta SQL en 128, se les dio "No se encontraron resultados" o páginas de resultados en caché. Desde su punto de vista, todavía están implementando un ataque, pero detrás de escena solo están haciendo otra solicitud HTTP. Es posible, por supuesto, llevar esto más lejos y prohibirles el acceso de alguna manera, pero recuerde que prohibirlos por completo no tiene sentido si están totalmente empeñados en hacerte daño: simplemente cambiarán su proxy y se irán de nuevo. Esta es la razón por la que todos nuestros esfuerzos para reducir la eficacia del ataque fueron invisibles.

El beneficio real de este enfoque es la poca sobrecarga que produce. En el gran esquema de un gran sitio web que recibe muchos visitantes de spam, un diminuto adicional por usuario no contribuirá a ninguna ganancia sustancial en la base de datos. Esto, combinado con un índice FULLTEXT, debería evitar que la mayoría de los ataques DoS causen daños graves sin mucho esfuerzo de su parte.

score 0 · Answer 3

Hay algunas cosas que vienen a la mente con respecto a DoS a través de lo que describió. El primero se basa en la red, el segundo se basa en la consulta (cuál es el corte máximo). La primera red basada: esto dependerá del diseño o su red. Por ejemplo, ¿hay un equilibrio de carga configurado en algún lugar, tiene varios proveedores, tiene filtrado en su lugar, por ejemplo? Si la consulta excede N entonces bloquee al infractor. El segundo es lo que parece más preocupado.

Cosas a considerar:

Sistema : ¿tiene suficiente memoria para procesar grandes volúmenes de consultas
Configuración : ¿cuál es el conjunto máximo de consultas a (MySQL, Apache / etc)
Filtrado : hay un filtro para bloquear a los infractores
Búfer / Cuotas : si establece una longitud máxima de 10 caracteres, ¿qué está haciendo si alguien supera este límite?

1) Su sistema debe estar diseñado correctamente para garantizar que esto no ocurra. Su diseño debe incluir buffers para N cantidad de procesamiento, consultas, conexiones.

2) La mayoría de las congifuraciones le permiten establecer un límite codificado en la cantidad de conexiones que se producen.

3) El filtrado (especialmente con mod_ratelimit, etc.) puede garantizar que esto no ocurra.

4) Buffer / cuotas. Igual que el # 3

Entonces, ¿cuál es tu objetivo final? Un DoS tradicional te abrumará porque no estabas preparado. En una DoS basada en la red, es poco lo que puede hacer para evitar que 40Gbps lleguen a su sistema de 1Gbps sin ayuda de terceros (servidores en la nube, almacenamiento en caché (Akamai), etc.). Desde la perspectiva de un sistema / proceso, hay muchas formas de mitigar esto. ¿Cuál sería tu final aquí?