miércoles, 5 de junio de 2013

Denegación de servicio en las Base de Datos

A medida que han ido haciéndose los servidores más y más potentes las bases de datos han ido desarrollando modelas mas conceptuales y las capas de abstracción cada vez son más profundas. La consecuencia inmediata de ello es que cada vez menos programadores realmente conocen como son las sentencias SQL que hay detrás de esos conceptos y la consencuencia de ello es un descuido total hace las cuestiones de rendimiento.
El hecho de que los sistemas se hayan hecho más resistentes a los ataques DoS clásicos ha forzado a que las organizaciones que están detrás de estos ataques suban un escalon en los niveles OSI y dirijan sus esfuerzos en diseñar ataques a nivel de Aplicación.



La idea básica es construir ataques basados en consultas que sean veroces consumidoras de recursos en los servidores: ejecutar pesadas select desde diversos sitios (ataque distribuido), generar carritos de compra con varios cientos (o miles de productos) y realizar pequeñas variaciones en ellos para obligar a recalcular todo.
También puede aprovecharse las limitaciones de los sistemas de bases de datos que dan servicio a la aplicación. Incluso se puede llegar a realizar ataques de SQL Injection que no tienen porque ser demasiado elaborados porque el objetivo de un ataque DoS no es comprometer al equipo, si no colapsarlo. Un sencillo ataque de SQL Injection  que cause un inesperado consumo excesivo de recursos es suficiente.

La cosa se puede agravar más porque gran parte de estas aplicaciones se construyen con herramientas ya conocidas y siempre es posible realizar simulaciones offline para analizar el rendimiento de las consultas generadas y seleccionar las más pesadas.


Evitar estos ataques se hace difícil para los sistemas tradicionales. Pueden no ser necesarias tantas peticiones para bloquear una base de datos por lo que los sistemas de detección basados en volumen no garantizan que puedan detectarlos.
Por otro lado la detección de SQL Injection se basa en la comparación de patrones para detectar ataques y en este caso se va a trabajar en su mayor con peticiones legítimas. Basarnos en estos sistemas necesitarán un ajuste muy fino o nos podemos estar bloqueando peticiones legítimas.

Se pueden hacer sistemas mixtos que  ciertos tipos de consultas con incrementos en peticiones, pero todo es encaje fino y sin garantías.

La solución pasa por una vuelta atrás y volver a hacer énfasis en el rendimiento. Antes era obligado porque las máquinas eran menos potentes y ahora porque las pueden sobrecargar. Diseñar la basa de datos muy ajustada al tipo de consultas que se espera. Optimizar la consultas para que funcionen de la manera mas eficiente. Olvidar un poco los modelos generalistas y centrarse en entornos específicos. Mas caro, más lento de desarrollar pero que a la larga puede ahorrar más de un quebradero de cabeza.

No hay comentarios:

Publicar un comentario