"En la actualidad, uno de los ataques con mayor impacto que se producen son los ataques distribuidos de denegación de servicio (DDoS). En esta entrada se repasan los motivos de su éxito y los problemas que existen en su detección, prevención y mitigación, incluyendo soluciones que minimizan su impacto, alguna de ellas basada en redes definidas por software (SDN)"
En una anterior entrada ("TRILL, SPB, VXLAN, NVGRE, EVI, OTV, EVB, VNTag: nuevas soluciones para antiguos problemas") se mostraron las tendencias que están apareciendo para solventar muchas de las problemáticas que aparecen en las actuales arquitecturas de red de los Data Centers.
Del mismo modo, ahora se presentan las soluciones que aparecen, y las que se impondrán en el futuro, a la hora de detectar y mitigar uno de los ataques más destructivos que se producen a día de hoy, los ataques de denegación de servicio (DoS), en particular los que son distribuidos (DDoS).
Antes de comenzar con los sistemas de detección y mitigación, se comenzará repasando qué es un ataque DoS y posteriormente se revisarán algunas de las técnicas de prevención más habituales.
Habitualmente esto se consigue mediante técnicas de envío masivo de paquetes o información, también nombrado como flooding, al cual la víctima no puede responder por su cantidad/tamaño, por lo que deja de dar servicio.
Otro modo de conseguir el efecto buscado es mediante vulnerabilidades de las aplicaciones (ataques de nivel 7).
En la actualidad, este tipo de ataques han ido mejorándose, desde los más sencillos, en los que un atacante con origen conocido realiza un flooding sobre la víctima, hasta ataques más complejos como puedan ser los ataques distribuidos amplificados y que se aprovechan de exploits de la aplicación.
El ataque de directo de origen localizado tiene una incidencia menor en la actualidad, ya que es más fácil de detectar y mitigar, así como porque los servidores y dispositivos de hoy en día soportan una carga, lo suficientemente alta, como para que el servicio no se vea afectado por un número reducido de atacantes, no obstante existen excepciones, que casi siempre vienen dadas por fallos en los aplicativos, los cuales pueden ser explotados por el/los atacantes y provocar la caída del servicio.
Un ataque más preocupante que el anterior es el ataque de denegación de servicio distribuido, o DDoS. En este caso el/los atacantes lanzan el ataque desde una multitud de orígenes diferentes, confundiéndose con los usuarios lícitos del servicio.
El ataque conjunto de varios atacantes desde múltiples localizaciones es posible, pero requiere un trabajo de coordinación, ya que todos los orígenes deben atacar la mismo objetivo a la vez. Para solucionar ese problema se han creado varios software que permiten la utilización de dispositivos de terceros, con o sin su conocimiento, para el envío de peticiones simultaneas desde ellos.
Muchas veces los atacantes hacen uso de botnets, que no son más que multitud de equipos que poseen este tipo de software (muchas veces instalados mediante la descarga no intencionada de malware) para generar un mayor número de peticiones y ocultar su origen.
Como se puede ver en la anterior figura, mediante esta técnica se genera un ataque con una multiplicación del número de peticiones.
En ocasiones, la víctima, dispone de una política de seguridad que solo permita el tráfico a un determinado servicio desde unas pocas IPs. Para "saltarse" esa securización, los atacantes pueden utilizar una técnica llamada ataque reflexivo que utiliza dispositivos de terceros, que si están permitidos, para poder encontrar un vector de ataque.
Esta técnica, además de saltarse la política de seguridad, permite al atacante ocultar su dirección IP. Para poder efectuarla se ha de realizar un IP spoofing para que las respuestas del dispositivo de terceros envíe las respusetas a la víctima, en lugar de al atacante. Esto se verá con más detalle a continuación, en los ataques amplificados, ya que en su gran mayoría utilizan la técnica de ataque reflexivo.
A parte de esta multiplicación en el número de peticiones que se ha visto con el ataque desde botnets, también se puede amplificar el tamaño de los paquetes, haciendo que a partir de pequeñas peticiones, se generen flujos de tráfico de mayor tamaño, que se destinan a la victima que está siendo atacada.
Los ataques DoS amplificados son muy efectivos para agotar los recursos de ancho de banda de la víctima, ya que por ejemplo, en el caso del ataque de DNS amplificado que se verá más adelante, con una petición de 60 bytes del atacante, se puede generar una respuesta, recibida por la víctima, de más de 3Mb, es decir, más de 50 veces el tráfico generado por un solo atacante, por lo que si este tiene, por ejemplo, un ADSL con únicamente 1 Mbps de subida, podría generar un caudal de 50 Mbps que recibiría la víctima.
Si a este tráfico amplificado se le suma el esquema distribuido DDoS, con 10 atacantes, la víctima necesitaría más de 500Mbps de conexión a Internet para poder recibir todo ese tráfico.
Por último, si se realiza una DDoS con una botnet, donde existen cientos y miles de zombis en muchas de ellas, y a la vez se utiliza esta técnica de amplificación, se podrían generar Gigas de tráfico que colapsarían cualquier conexión pública que pueda tener la víctima.
Existen varios tipos de ataques que pueden ser amplificados pero estos tienen en común el uso de protocolos no orientados a conexión en los cuales las respuestas sean mucho mayores que las peticiones, y el IP spoofing .
El primero que existió, el smurff attack, consistía en lanzar peticiones ICMP a la dirección broadcast de una red haciendose pasar por la víctima (con lo que recibía las respuestas de todos los elementos de la red). También se ha hablado de la amplificación DNS, que se cubrirá más adelante, pero el DNS no es el único utilizado para este tipo de ataques, otro susceptible, y facil de comprender, es el protocolo NTP, por el cual mediante el comando monlist, el cual devuelve una lista de las últimas 600 direcciones IP que han consultado el NTP, se puede reenviar más de 200 veces el tráfico generado por la propia petición.
Para mostrar un ataque amplificado algo más complejo, se revisará el DDoS DNS amplificado, que es uno de los más comunes de este tipo.
Ya que las respuestas DNS son, como ya se ha comentado antes, mucho mayores en tamaño que las peticiones, y si además a esto se añade que es posible utilizar multitud de DNS recursivos (cuyas respuestas DNS no descartará la víctima), al estar estos abiertos a las peticiones de cualquier IP, se tiene un resultado perfecto para la generación de ataques DoS amplificados.
Para ilustrar el ataque que aprovecha este tipo de amplificación se presenta el siguiente esquema (tomado de Security Affairs) donde se pueden ver los pasos de un ataque DDoS DNS amplificado utilizado a su vez una botnet:
Este tipo de ataque es, si cabe, mucho más efectivo si se provee del servicio DNSSEC, ya que se obtiene un mayor tamaño de las respuestas DNS en estos casos.
Del mismo modo, ahora se presentan las soluciones que aparecen, y las que se impondrán en el futuro, a la hora de detectar y mitigar uno de los ataques más destructivos que se producen a día de hoy, los ataques de denegación de servicio (DoS), en particular los que son distribuidos (DDoS).
Antes de comenzar con los sistemas de detección y mitigación, se comenzará repasando qué es un ataque DoS y posteriormente se revisarán algunas de las técnicas de prevención más habituales.
¿Qué es un ataque DoS?
Un ataque de denegación causa la interrupción de uno o varios servicios mediante el consumo excesivo de alguno de estos recursos en el servidor o elementos de red intermedios:- Ancho de banda
- Ciclos de CPU
- Memoria
- Espacio en disco, Bases de Datos, o tablas internas (de número de conexiones por ejemplo)
Otro modo de conseguir el efecto buscado es mediante vulnerabilidades de las aplicaciones (ataques de nivel 7).
En la actualidad, este tipo de ataques han ido mejorándose, desde los más sencillos, en los que un atacante con origen conocido realiza un flooding sobre la víctima, hasta ataques más complejos como puedan ser los ataques distribuidos amplificados y que se aprovechan de exploits de la aplicación.
Figura 1 - Tipos de ataque DoS más utilizados según RADWARE (info 2011)
El ataque de directo de origen localizado tiene una incidencia menor en la actualidad, ya que es más fácil de detectar y mitigar, así como porque los servidores y dispositivos de hoy en día soportan una carga, lo suficientemente alta, como para que el servicio no se vea afectado por un número reducido de atacantes, no obstante existen excepciones, que casi siempre vienen dadas por fallos en los aplicativos, los cuales pueden ser explotados por el/los atacantes y provocar la caída del servicio.
Figura 2 - Esquema de ataque DoS
El ataque conjunto de varios atacantes desde múltiples localizaciones es posible, pero requiere un trabajo de coordinación, ya que todos los orígenes deben atacar la mismo objetivo a la vez. Para solucionar ese problema se han creado varios software que permiten la utilización de dispositivos de terceros, con o sin su conocimiento, para el envío de peticiones simultaneas desde ellos.
Muchas veces los atacantes hacen uso de botnets, que no son más que multitud de equipos que poseen este tipo de software (muchas veces instalados mediante la descarga no intencionada de malware) para generar un mayor número de peticiones y ocultar su origen.
Figura 3 - Esquema de ataque DDoS mediante botnet
Como se puede ver en la anterior figura, mediante esta técnica se genera un ataque con una multiplicación del número de peticiones.
En ocasiones, la víctima, dispone de una política de seguridad que solo permita el tráfico a un determinado servicio desde unas pocas IPs. Para "saltarse" esa securización, los atacantes pueden utilizar una técnica llamada ataque reflexivo que utiliza dispositivos de terceros, que si están permitidos, para poder encontrar un vector de ataque.
Esta técnica, además de saltarse la política de seguridad, permite al atacante ocultar su dirección IP. Para poder efectuarla se ha de realizar un IP spoofing para que las respuestas del dispositivo de terceros envíe las respusetas a la víctima, en lugar de al atacante. Esto se verá con más detalle a continuación, en los ataques amplificados, ya que en su gran mayoría utilizan la técnica de ataque reflexivo.
A parte de esta multiplicación en el número de peticiones que se ha visto con el ataque desde botnets, también se puede amplificar el tamaño de los paquetes, haciendo que a partir de pequeñas peticiones, se generen flujos de tráfico de mayor tamaño, que se destinan a la victima que está siendo atacada.
Los ataques DoS amplificados son muy efectivos para agotar los recursos de ancho de banda de la víctima, ya que por ejemplo, en el caso del ataque de DNS amplificado que se verá más adelante, con una petición de 60 bytes del atacante, se puede generar una respuesta, recibida por la víctima, de más de 3Mb, es decir, más de 50 veces el tráfico generado por un solo atacante, por lo que si este tiene, por ejemplo, un ADSL con únicamente 1 Mbps de subida, podría generar un caudal de 50 Mbps que recibiría la víctima.
Si a este tráfico amplificado se le suma el esquema distribuido DDoS, con 10 atacantes, la víctima necesitaría más de 500Mbps de conexión a Internet para poder recibir todo ese tráfico.
Por último, si se realiza una DDoS con una botnet, donde existen cientos y miles de zombis en muchas de ellas, y a la vez se utiliza esta técnica de amplificación, se podrían generar Gigas de tráfico que colapsarían cualquier conexión pública que pueda tener la víctima.
Existen varios tipos de ataques que pueden ser amplificados pero estos tienen en común el uso de protocolos no orientados a conexión en los cuales las respuestas sean mucho mayores que las peticiones, y el IP spoofing .
El primero que existió, el smurff attack, consistía en lanzar peticiones ICMP a la dirección broadcast de una red haciendose pasar por la víctima (con lo que recibía las respuestas de todos los elementos de la red). También se ha hablado de la amplificación DNS, que se cubrirá más adelante, pero el DNS no es el único utilizado para este tipo de ataques, otro susceptible, y facil de comprender, es el protocolo NTP, por el cual mediante el comando monlist, el cual devuelve una lista de las últimas 600 direcciones IP que han consultado el NTP, se puede reenviar más de 200 veces el tráfico generado por la propia petición.
Figura 4 - Esquema de ataque DDoS NTP amplificado
El ataque amplificado por NTP es más sencillo, ya que no tiene tantos elementos intermedios como el ataque amplificado por DNS, pero no es tan común que los servidores NTP permitan el uso de monlist , por lo que es más fácil encontrar DNS recursivos abiertos que servidores NTP con esta "vulnerabilidad",
Para mostrar un ataque amplificado algo más complejo, se revisará el DDoS DNS amplificado, que es uno de los más comunes de este tipo.
Ya que las respuestas DNS son, como ya se ha comentado antes, mucho mayores en tamaño que las peticiones, y si además a esto se añade que es posible utilizar multitud de DNS recursivos (cuyas respuestas DNS no descartará la víctima), al estar estos abiertos a las peticiones de cualquier IP, se tiene un resultado perfecto para la generación de ataques DoS amplificados.
Para ilustrar el ataque que aprovecha este tipo de amplificación se presenta el siguiente esquema (tomado de Security Affairs) donde se pueden ver los pasos de un ataque DDoS DNS amplificado utilizado a su vez una botnet:
Figura 5 - Esquema de ataque DDoS DNS amplificado
Prevención de ataques DoS / DDoS
Los ataques de denegación de servicio, sobretodo los distribuidos en los que se utilizan botnets, son difíciles de detener, e incluso de detectar, pero su prevención se basa en los mismos principios que en los de cualquier otro ataque:1- Monitorización y conocimiento de la plataforma
Aunque pueda ser obvio, el conocimiento del servicio prestado es fundamental para poder abordar las tareas de prevención del ataque, y en muchos casos sucede que la información se tiene, pero de forma segmentada (habitualmente por "departamentos"), cuando la visión y conocimiento de la plataforma deben ser globales para poder sacarles el mayor provecho.
Se deberán contemplar aspectos como:
La mayor parte del anterior conocimiento se obtiene de una correcta monitorización de la plataforma, por lo que este sondeo tendría una doble función, por un lado recabar la información de los puntos descritos más arriba, y por otra recoger los datos que, una vez procesados, indiquen que se está bajo un ataque y, a la vez, servir para poder detenerlo, como se verá en el siguiente apartado de detección y mitigación.
El procesamiento de la información recogida por los sistemas de monitorización debería ir más allá de la revisión frente a un gran ataque, es recomendable realizar periódicamente búsquedas de fuentes de pequeños ataques, que incluso han podido pasar desapercibidos, o por comportamientos anómalos en el servicio que puedan ser el origen de problemas posteriores.
Para poder realizar una monitorización completa se ha de revisar también el tráfico encriptado, ya que cada vez más ataques DoS utilizan protocolos como SSL para hacer más "opacos" sus ataques, ya que en la mayoría de los casos este tráfico no se desencripta para su monitorización, debido a los problemas de rendimiento que esto plantea, a parte de las implicaciones legales asociadas a desvelar la información que transporta SSL.
Se deberán contemplar aspectos como:
- Comportamiento habitual del servicio a proteger, entre los que se encontrarían el número de peticiones nuevas según línea temporal, localización de los clientes que acceden al servicio, puertos y flujos de conexiones necesarios, ancho de banda utilizado, valores medios de CPU, memoria, etc de dispositivos, ... para poder comparar en caso de ataques o comportamientos anómalos.
- Valores máximos que todos los dispositivos implicados puede soportar, así como los rangos de funcionamiento teniendo en cuenta otros servicios si existen dispositivos compartidos (servidores, firewalls, balanceadores, routers, etc), de manera que se puedan conocer los posibles cuellos de botella del servicio de manera anticipada.
- Crecimiento esperado en el tiempo y nuevos servicios, que puedan impactar en los datos de los dos puntos anteriores
La mayor parte del anterior conocimiento se obtiene de una correcta monitorización de la plataforma, por lo que este sondeo tendría una doble función, por un lado recabar la información de los puntos descritos más arriba, y por otra recoger los datos que, una vez procesados, indiquen que se está bajo un ataque y, a la vez, servir para poder detenerlo, como se verá en el siguiente apartado de detección y mitigación.
El procesamiento de la información recogida por los sistemas de monitorización debería ir más allá de la revisión frente a un gran ataque, es recomendable realizar periódicamente búsquedas de fuentes de pequeños ataques, que incluso han podido pasar desapercibidos, o por comportamientos anómalos en el servicio que puedan ser el origen de problemas posteriores.
Para poder realizar una monitorización completa se ha de revisar también el tráfico encriptado, ya que cada vez más ataques DoS utilizan protocolos como SSL para hacer más "opacos" sus ataques, ya que en la mayoría de los casos este tráfico no se desencripta para su monitorización, debido a los problemas de rendimiento que esto plantea, a parte de las implicaciones legales asociadas a desvelar la información que transporta SSL.
2 - Correcto diseño de la plataforma y planificación de procedimientos
Es imposible crear un buen diseño de la arquitectura del servicio si no se dispone de la información relativa al anterior punto. Los datos del comportamiento "normal" del servicio, así como la previsión de crecimiento son fundamentales a la hora de un correcto dimensionamiento, determinación de la topología y la elección de los dispositivos implicados en la plataforma de servicio.
En alguna ocasión, en el dimensionamiento de equipos, se puede tener cuenta un cierto factor de corrección, para permitir que la arquitectura soporte un nivel de carga significativamente superior a los máximos habituales (y crecimiento esperado), de manera que sea menos vulnerable a los ataques.
Otra idea es la de instalar elementos que estén específicamente diseñados para realizar el caching de partes del servicio, de manera que la mayoría de las conexiones sean atendidas por estos elementos sin tener que llegar las peticiones al servidor backend.
Estas medidas, aunque efectivas, supone un costo adicional, sobretodo el sobre-dimensionamiento, en casi todos los casos es demasiado elevado para tenerlo en cuenta.
A modo de resumen, algunas ideas de configuración mencionadas a tener en cuenta son:
Una parte del diseño fundamental a la hora de prevenir los ataques DoS y DDoS es la arquitectura de seguridad. Esta deberá, al menos, Incluir políticas antispoofing (que también deberían habilitarse en los routers mediante la configuración de uRPF, sobretodo si se utiliza BGP) y restringir los accesos a las IPs de los clientes, en los casos en los que se pueda, por ejemplo, si se presta un servicio NTP, que solo las IPs autogestionadas puedan realizar peticiones de este tipo, en ningún caso hacer público para todo el mundo, ya que se da pié a que un atacante (con una IP que estaría fuera de nuestro control) explotase alguna vulnerabilidad conocida.
Un problema recurrente a la hora de prevenir los ataques DoS y DDoS es que, en muchos casos, las acciones tomadas para reducirlos no son útiles si el resto del mundo no los adopta. Por ejemplo, el que los servidores NTP propios no permitan el uso de monlist ,no impide que otro servidor NTP bajo otra administración si lo haga y por ello sea susceptible de ser utilizado para realizar un ataque sobre un servicio propio.
3 - Realización de auditorias y corrección de vulnerabilidades
Como último punto de prevención, se encontraría la realización periódica de auditorías para revelar y corregir las vulnerabilidades del servicio.
En estas auditorías se deberían volver a revisar la localización de los cuellos de botella (no únicamente de red) y fallos en las configuraciones. También se realizarán pruebas de carga para comprobar el comportamiento de la plataforma frente frente al estrés.
Del mismo modo, se deberá revisar si se está protegido frente a las últimas vulnerabilidades y ataques conocidos, actualizando aplicativos y Sistemas Operativos en los casos que sean necesarios.
Por ello se han de tener claros tres puntos principalmente:
Tanto la detección, como la mitigación de los ataques DDoS son bastante complejas, tal y como se verá a continuación, por lo que los fabricantes de equipamiento de red han desarrollado sus soluciones propietarias que proporcionan estos servicios anti-DoS. Por su parte, operadores y proveedores Cloud, aprovechando esta complejidad, también aportan la posibilidad de gestionar ellos el tráfico susceptible de ser un ataque DDoS y "limpiar" de esta manera las conexiones entrantes a un servicio específico.
Por tanto, en la mayoría de los casos, tanto la detección como la mitigación de los ataques DoS y DDoS recae sobre terceros, ya sea mediante la implementación de sus productos en la infraestructura propia, o mediante la utilización de servicios de "detección y limpieza" de diversos proveedores e ISPs (reenviando el tráfico). Esto no quiere decir que sea imposible realizar una solución propia de detección y mitigación, programando diversos scripts, instalando servidores y configurado integraciones con los dispositivos de red, aunque en ningún caso se podrá obtener el mismo resultado que con las soluciones propietarias.
Todas las anteriores afirmaciones se entenderán mejor en el siguiente desglose.
1 - Métodos de detección
Para poder contrarrestar un ataque hay que disponer de cierta información. En primer lugar se ha de detectar que se está bajo un ataque (esto no siempre es tan facil como parece), preferentemente antes de que los servicios se vean afectados, y más tarde, se ha de localizar el origen y el vector de ataque. Sin esa información será imposible mitigación alguna.
Para ello se requiere el estudio de los datos obtenidos mediante la monitorización de la plataforma. Esta monitorización puede venir dada por exportaciones de datos (por ejemplo Netflow, útil para obtener información sobre cantidades de tráfico así como número de conexiones e IPs origen/destino), obtención de valores SNMP o incluso, para las detecciones más avanzadas de algunos fabricantes, capturas de trazas (tcpdump) del tráfico.
Es importante volver a recalcar la necesidad de monitorizar el tráfico encriptado y tunelizado, ya que sin la visibilidad de este tipo de conexiones nunca se podrán evitar los ataques que utilicen esos medios para alcanzar a la víctima.
Las soluciones de detección/mitigación de los fabricantes utilizan una combinación de los anteriores métodos de monitorización (ya sea con dispositivos situados en línea o con la importación de los datos mediante SPAN de puertos u otro tipo de reenvío del tráfico), algunos incluso proporcionando los medios necesarios para romper ellos mismos los túneles SSL y de ese modo inspeccionar insitu el tráfico encriptado (otros en cambio necesita de un tercero para hacer este trabajo y reenviarle los datos "en claro").
Volviendo al principio, para detectar que la plataforma se encuentra bajo un ataque, basta con tener los datos "habituales" de funcionamiento y compararlos con los aportados por la monitorización. Para determinar si se está bajo un ataque se han de recoger que los datos de utilización de recursos como la CPU, memoria, red (latencias y ancho de banda utilizado), disco, etc, de los equipos implicados y compararlos con los valores "normales" que suele tener el servicio.
Con esta información se puede llegar a asegurar que un ataque se está produciendo, pero en muchos casos no se aporta suficiente información para determinar el origen (distinguiendolo de los usuarios lícitos) ni el tipo de ataque que se está produciendo.
Detectar los orígenes del ataque puede ser muy complicado ya que, como se vio en el primer apartado, los ataques reflexivos o la utilización de botnets complican la localización de las IPs desde las que se lanzan las peticiones de ataque, al estar estas enmascardas con el tráfico lícito de otros clientes.
Los diferentes fabricantes han desarrollado sus propios algoritmos de categorización de flujos de tráfico que, a la vez, informan del tipo de ataque producido, casi siempre basándose en esta información:
2 - Métodos de mitigación
Una vez conocidos los orígenes y el modo de ataque, se puede proceder a realizar las acciones necesarias para mitigar los efectos que este produce sobre el servicio.
La mitigación puede producirse en el mismo equipo/infraestructura que ha realizado la detección, o reenviando el tráfico "posiblemente malicioso" o otro dispositivo o plataforma que realice nuevos test y finalmente minimice o descarte el tráfico marcado como "ataque".
Ambas soluciones, se basan en dos modelos para mitigar el ataque:
En el primer diagrama, puede observarse la arquitectura más simple, en la que un equipo en línea sondea y reconoce el tráfico y a la vez minimiza el impacto de los ataques DoS/DDoS.
El dispositivo debe ser correctamente dimensionado, ya que un propio ataque DoS puede dejar inutilizado el equipo y cortar todas las conexiones. Para ello estos equipos se suelen conectar a un switch de bypass que puede "puentear" el tráfico para saltarse el equipo anti DoS, lo cual no haría otra cosa que dejar pasar el ataque directamente hasta donde esté alojado el servicio.
Otro de las posibilidades mencionadas es la contratación de servicios de "limpieza" de conexiones a los propios proveedores (lo que excluiría la necesidad de incluir equipamiento anti-DoS en todos los Data Centers). Este esquema funcionaría del siguiente modo, en condiciones normales las peticiones de los clientes se destinan directamente al servicio, mientras que si se detecta un ataque (mediante la interpretación de la información de monitorización) el tráfico sospechoso se envía a un "centro de depuración" el cual vuelve a sondear el tráfico, desecha los flujos de ataque, y reenvía el tráfico limpio al servicio.
Esta redirección puede hacerse de varias formas, incluso de manera automática modificando las rutas anunciadas por BGP dependiendo de las incidencias detectadas por un monitor al cual se envían los datos Netflow, como muestra el siguiente esquema tomado del proyecto opendaylight:
Como se puede imaginar, estas modificaciones sobre la marcha de los enrutamientos no son sencillas y puede que el ISP no permita hacerlas si el servicio de depuración de conexiones no lo está aportando el mismo. Si no se permiten estas redirecciones, se deberá enrutar todo el tráfico del servicio (sea o no posiblemente malicioso) al centro de depuración para que sea tratado en consecuencia.
Por otra parte, si el ISP realiza el procedimiento automático de modificar las rutas anunciadas por BGP, existe el problema adicional de la lentitud de respuesta ante el posible ataque, ya que los temporizadores de BGP suelen ser muy lentos.
Aunque este procedimiento de redirección de tráfico sospechoso se ha visto para el caso de "depuración en la nube", un esquema parecido se puede implementar en la arquitectura local, sustituyendo el "centro de depuración" por el appliance que realice ese mismo trabajo.
No obstante los problemas de configuración selectiva de la redirección siguen siendo los mismos, o incluso mayores porque normalmente a nivel local no se cuenta con la flexibilidad que aporta el protocolo BGP.
Es por ello que en las soluciones locales se hace difícil implementar esta arquitectura de diversificación de flujos, a no ser que se cuente con una infraestructura de red basada en Software o red SDN (en la anterior entrada "Ideas básicas sobre SDN" se introdujeron los conceptos clave sobre redes SDN).
En este caso, la utilidad viene dada en la versatilidad que aporta el Controller a la hora de destinar los flujos de conexiones atendiendo a cualquier parámetro que pueda imaginarse. En el caso que se aborda se tendrían las siguientes ventajas:
En el siguiente esquema, tomado de una solución de Radware, puede napreciarse los puntos comentados:
Como puede observarse, el despliegue de esta solución es mucho más simple, y solventa todos los problemas de tiempos de respuesta que se encuentran en las arquitecturas tradicionales, al contar con la facilidad de reconfiguración de los flujos de tráfico desde el controlador SDN, y la inteligencia que aporta el software que utiliza su API.
3 - Planificación de la contingencia
Como último punto a tratar dentro de este apartado está la designación de un plan de contingencia que marcará las pautas de actuación en caso de recibir un ataque y que este no pueda ser detenido.
Debido a la efectividad de los ataques DDoS es importante definir (con suficiente antelación) qué hacer en última instancia si un servicio es atacado y ni las medidas de prevención ni de detección/mitigación adoptadas son suficientes para detenerlo.
Aquí las posibilidades son infinitas aunque algunas de las acciones que en última instancia podrían tomarse son:
En alguna ocasión, en el dimensionamiento de equipos, se puede tener cuenta un cierto factor de corrección, para permitir que la arquitectura soporte un nivel de carga significativamente superior a los máximos habituales (y crecimiento esperado), de manera que sea menos vulnerable a los ataques.
Otra idea es la de instalar elementos que estén específicamente diseñados para realizar el caching de partes del servicio, de manera que la mayoría de las conexiones sean atendidas por estos elementos sin tener que llegar las peticiones al servidor backend.
Estas medidas, aunque efectivas, supone un costo adicional, sobretodo el sobre-dimensionamiento, en casi todos los casos es demasiado elevado para tenerlo en cuenta.
Otra parte del diseño que es importante a la hora de prevenir los ataques DoS es la deshabilitación de funcionalidades no utilizadas o que potencialmente puedan ser utilizadas como vector de ataque. En este caso podrían incluirse algunos de los ejemplos ya comentados anteriormente, como la desactivación del comando monlist en los servidores NTP, o la función de recursividad en los servidores DNS. Estas funcionalidades no se restringen a los servidores, sino que también a los elementos de red que pueden ser susceptibles a ser atacados, como por ejemplo, los routers (fragmentación IP, ICMP redirects, pings a direcciones broadcast, ataques de STP, etc).
En los routers también existen configuraciones que pueden prevenir los ataques DoS, como por ejemplo la desactivación de la fragmentación IP. Esta configuración, aunque muchas veces problemática si no se tienen bien configuradas las MTU, permite ser inmune a los ataques basados en fragmentación de paquetes, los cuales son utilizados o como medio para "saltarse los firwealls" y sus inspecciones anti-DoS, o directamente como vector de ataque, enviando múltiples paquetes que se deban segmentar, haciendo que el uso de la CPU del router se dispare (sobretodo si el tráfico saliente es por un túnel).
Del mismo modo, si los componentes del servicio lo permiten, es una buena idea limitar el número de conexiones totales y por usuario único (suele ser por IP origen), así como el número de nuevas conexiones por segundo (también a nivel general y por usuario único).
En ocasiones, del mismo modo, se podrán limitar los temporizadores de establecimiento de sesión y de sesiones establecidas (para evitar que se mantengan en la tabla de memoria, sesiones que no son utilizadas durante largos periodos), ya que varios ataques DoS se basan en agotar la memoria de los equipos lanzando muchas conexiones "half open" esto es, que no se abren completamente, lo que hace que el dispositivo que recibe la petición de apertura tenga que destinar memoria (durante el periodo del temporizador de establecimiento de conexión) para guardar el estado de la "medio conexión", a la espera de que se termine de completar.
Las configuraciones de los temporizadores son útiles a la hora de prevenir los efectos de los ataques pero es importante tener en cuenta que están muy condicionados a los servicios que hay por debajo, por ejemplo, hay servicios de bases de datos que deben mantener conexiones abiertas sin utilizar durante horas, por lo que si se restringe el temporizador de sesión puede que el servicio se vea interrumpido intermitentemente.
Por otro lado, a parte de las configuraciones de QoS que restrinjan la utilización de ancho de banda, las cuales también son de ayuda a la hora de minimizar el impacto de los ataques DoS, una buena idea, si es posible, es la de configurar valores máximos de recursos utilizados por los aplicativos, por ejemplo, si el servicio se encuentra en una máquina virtual, o si las conexiones transcurren por un firewall físico que ha sido subdividido en varios virtuales, limitar el máximo número de ciclos de CPU, memoria y conexiones (en el caso del firewall) que podrá consumir de la máquina host, de manera que el ataque a un determinado servicio, no afecte a otros que no están siendo atacados directamente.
En los routers también existen configuraciones que pueden prevenir los ataques DoS, como por ejemplo la desactivación de la fragmentación IP. Esta configuración, aunque muchas veces problemática si no se tienen bien configuradas las MTU, permite ser inmune a los ataques basados en fragmentación de paquetes, los cuales son utilizados o como medio para "saltarse los firwealls" y sus inspecciones anti-DoS, o directamente como vector de ataque, enviando múltiples paquetes que se deban segmentar, haciendo que el uso de la CPU del router se dispare (sobretodo si el tráfico saliente es por un túnel).
Del mismo modo, si los componentes del servicio lo permiten, es una buena idea limitar el número de conexiones totales y por usuario único (suele ser por IP origen), así como el número de nuevas conexiones por segundo (también a nivel general y por usuario único).
En ocasiones, del mismo modo, se podrán limitar los temporizadores de establecimiento de sesión y de sesiones establecidas (para evitar que se mantengan en la tabla de memoria, sesiones que no son utilizadas durante largos periodos), ya que varios ataques DoS se basan en agotar la memoria de los equipos lanzando muchas conexiones "half open" esto es, que no se abren completamente, lo que hace que el dispositivo que recibe la petición de apertura tenga que destinar memoria (durante el periodo del temporizador de establecimiento de conexión) para guardar el estado de la "medio conexión", a la espera de que se termine de completar.
Las configuraciones de los temporizadores son útiles a la hora de prevenir los efectos de los ataques pero es importante tener en cuenta que están muy condicionados a los servicios que hay por debajo, por ejemplo, hay servicios de bases de datos que deben mantener conexiones abiertas sin utilizar durante horas, por lo que si se restringe el temporizador de sesión puede que el servicio se vea interrumpido intermitentemente.
Por otro lado, a parte de las configuraciones de QoS que restrinjan la utilización de ancho de banda, las cuales también son de ayuda a la hora de minimizar el impacto de los ataques DoS, una buena idea, si es posible, es la de configurar valores máximos de recursos utilizados por los aplicativos, por ejemplo, si el servicio se encuentra en una máquina virtual, o si las conexiones transcurren por un firewall físico que ha sido subdividido en varios virtuales, limitar el máximo número de ciclos de CPU, memoria y conexiones (en el caso del firewall) que podrá consumir de la máquina host, de manera que el ataque a un determinado servicio, no afecte a otros que no están siendo atacados directamente.
A modo de resumen, algunas ideas de configuración mencionadas a tener en cuenta son:
- Limitar el número de conexiones totales y conexiones por usuario, así como el número de nuevas conexiones a nivel general y por usuario
- Aplicar políticas QoS a los flujos de tráfico
- Minimizar los temporizadores de sesiones establecidas y de espera en la apertura de nuevas conexiones
- Limitar la utilización de recursos (CPU, memoria, red y disco) cuando se utilicen sistemas compartidos o virtualizados.
Una parte del diseño fundamental a la hora de prevenir los ataques DoS y DDoS es la arquitectura de seguridad. Esta deberá, al menos, Incluir políticas antispoofing (que también deberían habilitarse en los routers mediante la configuración de uRPF, sobretodo si se utiliza BGP) y restringir los accesos a las IPs de los clientes, en los casos en los que se pueda, por ejemplo, si se presta un servicio NTP, que solo las IPs autogestionadas puedan realizar peticiones de este tipo, en ningún caso hacer público para todo el mundo, ya que se da pié a que un atacante (con una IP que estaría fuera de nuestro control) explotase alguna vulnerabilidad conocida.
Por otra parte, cada vez es más importante incluir elementos de control y seguridad de aplicación, como los firewalls de nivel 7 e IPS, para minimizar los ataques DoS basados en exploits o fallos software de los aplicativo, así como para eliminar directamente las conexiones "mal hechas".
Para finalizar con la parte de seguridad, tan solo añadir que, como es normal, será necesaria la utilización de software antivirus y antimalware, para que los servidores y PCs no puedan ser incluidos como parte de alguna botnet que ataque a terceros o a uno mismo.
Un problema recurrente a la hora de prevenir los ataques DoS y DDoS es que, en muchos casos, las acciones tomadas para reducirlos no son útiles si el resto del mundo no los adopta. Por ejemplo, el que los servidores NTP propios no permitan el uso de monlist ,no impide que otro servidor NTP bajo otra administración si lo haga y por ello sea susceptible de ser utilizado para realizar un ataque sobre un servicio propio.
Una vez vistas las indicaciones de diseño y seguridad, solo queda recalcar que muchas de las acciones de prevención (y mitigación como se verá más adelante) pueden ser efectuadas por terceros, o por incluso el propio ISP que proporciona conexión, por lo que es importante planificar con ellos la posibilidad de utilizar estos servicios añadidos en caso de contingencia o incluso de manera continuada.
La planificación de las acciones tomadas en caso de contingencia es un punto importante que podría tomarse como parte de la prevención, así como el estudio de la automatización de tareas en el caso de detección de ataque y puesta en marcha de contramedidas, de manera que se detecte y detenga el ataque antes de que este provoque daños al servicio.
La planificación de las acciones tomadas en caso de contingencia es un punto importante que podría tomarse como parte de la prevención, así como el estudio de la automatización de tareas en el caso de detección de ataque y puesta en marcha de contramedidas, de manera que se detecte y detenga el ataque antes de que este provoque daños al servicio.
3 - Realización de auditorias y corrección de vulnerabilidades
Como último punto de prevención, se encontraría la realización periódica de auditorías para revelar y corregir las vulnerabilidades del servicio.
En estas auditorías se deberían volver a revisar la localización de los cuellos de botella (no únicamente de red) y fallos en las configuraciones. También se realizarán pruebas de carga para comprobar el comportamiento de la plataforma frente frente al estrés.
Del mismo modo, se deberá revisar si se está protegido frente a las últimas vulnerabilidades y ataques conocidos, actualizando aplicativos y Sistemas Operativos en los casos que sean necesarios.
Detección y mitigación de ataques DoS / DDoS
Como se ha visto, es muy difícil prevenir completamente los ataques DoS, ya que en gran medida depende también de la configuración por parte de terceros (por ejemplo en los casos de ataques amplificados y reflexivos), por lo que es probable que si se publican servicios conocidos en Internet, antes o después estos sean atacados.Por ello se han de tener claros tres puntos principalmente:
- Métodos de detección
- Métodos de mitigación
- Planificación del procedimiento de contingencia
Tanto la detección, como la mitigación de los ataques DDoS son bastante complejas, tal y como se verá a continuación, por lo que los fabricantes de equipamiento de red han desarrollado sus soluciones propietarias que proporcionan estos servicios anti-DoS. Por su parte, operadores y proveedores Cloud, aprovechando esta complejidad, también aportan la posibilidad de gestionar ellos el tráfico susceptible de ser un ataque DDoS y "limpiar" de esta manera las conexiones entrantes a un servicio específico.
Por tanto, en la mayoría de los casos, tanto la detección como la mitigación de los ataques DoS y DDoS recae sobre terceros, ya sea mediante la implementación de sus productos en la infraestructura propia, o mediante la utilización de servicios de "detección y limpieza" de diversos proveedores e ISPs (reenviando el tráfico). Esto no quiere decir que sea imposible realizar una solución propia de detección y mitigación, programando diversos scripts, instalando servidores y configurado integraciones con los dispositivos de red, aunque en ningún caso se podrá obtener el mismo resultado que con las soluciones propietarias.
Todas las anteriores afirmaciones se entenderán mejor en el siguiente desglose.
1 - Métodos de detección
Para poder contrarrestar un ataque hay que disponer de cierta información. En primer lugar se ha de detectar que se está bajo un ataque (esto no siempre es tan facil como parece), preferentemente antes de que los servicios se vean afectados, y más tarde, se ha de localizar el origen y el vector de ataque. Sin esa información será imposible mitigación alguna.
Para ello se requiere el estudio de los datos obtenidos mediante la monitorización de la plataforma. Esta monitorización puede venir dada por exportaciones de datos (por ejemplo Netflow, útil para obtener información sobre cantidades de tráfico así como número de conexiones e IPs origen/destino), obtención de valores SNMP o incluso, para las detecciones más avanzadas de algunos fabricantes, capturas de trazas (tcpdump) del tráfico.
Es importante volver a recalcar la necesidad de monitorizar el tráfico encriptado y tunelizado, ya que sin la visibilidad de este tipo de conexiones nunca se podrán evitar los ataques que utilicen esos medios para alcanzar a la víctima.
Las soluciones de detección/mitigación de los fabricantes utilizan una combinación de los anteriores métodos de monitorización (ya sea con dispositivos situados en línea o con la importación de los datos mediante SPAN de puertos u otro tipo de reenvío del tráfico), algunos incluso proporcionando los medios necesarios para romper ellos mismos los túneles SSL y de ese modo inspeccionar insitu el tráfico encriptado (otros en cambio necesita de un tercero para hacer este trabajo y reenviarle los datos "en claro").
Volviendo al principio, para detectar que la plataforma se encuentra bajo un ataque, basta con tener los datos "habituales" de funcionamiento y compararlos con los aportados por la monitorización. Para determinar si se está bajo un ataque se han de recoger que los datos de utilización de recursos como la CPU, memoria, red (latencias y ancho de banda utilizado), disco, etc, de los equipos implicados y compararlos con los valores "normales" que suele tener el servicio.
Con esta información se puede llegar a asegurar que un ataque se está produciendo, pero en muchos casos no se aporta suficiente información para determinar el origen (distinguiendolo de los usuarios lícitos) ni el tipo de ataque que se está produciendo.
Detectar los orígenes del ataque puede ser muy complicado ya que, como se vio en el primer apartado, los ataques reflexivos o la utilización de botnets complican la localización de las IPs desde las que se lanzan las peticiones de ataque, al estar estas enmascardas con el tráfico lícito de otros clientes.
Los diferentes fabricantes han desarrollado sus propios algoritmos de categorización de flujos de tráfico que, a la vez, informan del tipo de ataque producido, casi siempre basándose en esta información:
- Medición de "rates", es decir, número de peticiones por cliente, tráfico generado, etc para descubrir los ataques basados en "volumen" (ataques por flooding)
- Clasificación de clientes, mediante puntuaciones que se realizan atendiendo al país de procedencia, rangos de IPs públicas, etc. Estas puntuaciones se modifican dinámicamente realimentándose de los datos obtenidos por los propios algoritmos.
- Análisis del comportamiento de cada cliente. Ya que las botnets no son peticiones realizadas por clientes reales, sino que son producidas por software, en ocasiones se repiten ciertos patrones que dan un indicio de que las peticiones de una cierta IP no son "reales". Si se tiene esta sospecha se podría directamente marcar a un cliente como atacante, o modificar los puntos de su clasificación (punto anterior). Por otra parte, también se puede utilizar el conocimiento adquirido sobre los comportamientos "normales" de los clientes, por ejemplo, si habitualmente los clientes que realizan una petición a un servicio web X, también abren conexiones sobre otro servicio web Y, y existen multitud de conexiones desde un cliente al servicio X pero ninguna desde él al servicio Y, puede hacer sospechar que no es un comportamiento "normal" y que es parte de un ataque DDoS.
Como se puede ver, es difícil generar por uno mismo un algoritmo parecido al ya desarrollado por los fabricantes de dispositivos y proveedores de servicio, por lo menos para aportar las funcionalidades de clasificación de clientes y análisis de comportamiento, no obstante es posible programar scripts propios que controlen los "rates" de tráfico, conexiones, CPU, etc para, tal vez, tener la oportunidad de determinar las IPs que están realizando ataques DoS por flooding.
Por último, una vez que se tienen acotados los posibles orígenes del ataque, se realiza un estudio más pormenorizado (revisando las capturas de paquetes o flujos de tráfico) para determinar el tipo de ataque que se está sufriendo. Estos procedimientos son parecidos a las que realizan otros elementos como IPS o firewalls de aplicación, incluso hay fabricantes que recogen la información de estos para poder deducir el tipo de ataque DoS que se está efectuando. Para ello utilizan una serie de firmas que verifican el vector de ataque.
Este último trabajo es difícil de ser implementado desde cero, por lo que nuevamente se ha de confiar en productos anti-DoS hechos a medida. Algunos ejemplos de despliegue de soluciones anti-DoS se darán en el siguiente punto, tras mostrar las técnicas de mitigación de los ataques.
Una vez conocidos los orígenes y el modo de ataque, se puede proceder a realizar las acciones necesarias para mitigar los efectos que este produce sobre el servicio.
La mitigación puede producirse en el mismo equipo/infraestructura que ha realizado la detección, o reenviando el tráfico "posiblemente malicioso" o otro dispositivo o plataforma que realice nuevos test y finalmente minimice o descarte el tráfico marcado como "ataque".
Ambas soluciones, se basan en dos modelos para mitigar el ataque:
- En la modificación de algunos de los parámetros de configuración, como los temporizadores, tamaños de ventana TCP, QoS, etc (los mismos que se modificaron para la prevención en un apartado anterior), restringiendo mucho más sus valores, por ejemplo reduciendo drásticamente los temporizadores de sesión, o el ancho de banda utilizado por cierto rango de IPs.
- Descartar directamente el tráfico susceptible de ser un ataque, en lugar restringir esos parámetros de configuración.
Se va a ilustrar lo comentado sobre la detección y la mitigación mostrando algunos esquemas de soluciones anti-DoS.
En el primer diagrama, puede observarse la arquitectura más simple, en la que un equipo en línea sondea y reconoce el tráfico y a la vez minimiza el impacto de los ataques DoS/DDoS.
Figura 6 - Esquema dispositivo anti-DDoS en línea
El dispositivo debe ser correctamente dimensionado, ya que un propio ataque DoS puede dejar inutilizado el equipo y cortar todas las conexiones. Para ello estos equipos se suelen conectar a un switch de bypass que puede "puentear" el tráfico para saltarse el equipo anti DoS, lo cual no haría otra cosa que dejar pasar el ataque directamente hasta donde esté alojado el servicio.
Otro de las posibilidades mencionadas es la contratación de servicios de "limpieza" de conexiones a los propios proveedores (lo que excluiría la necesidad de incluir equipamiento anti-DoS en todos los Data Centers). Este esquema funcionaría del siguiente modo, en condiciones normales las peticiones de los clientes se destinan directamente al servicio, mientras que si se detecta un ataque (mediante la interpretación de la información de monitorización) el tráfico sospechoso se envía a un "centro de depuración" el cual vuelve a sondear el tráfico, desecha los flujos de ataque, y reenvía el tráfico limpio al servicio.
Figura 7 - Esquema servicio Anti-DDoS "en la nube"
Esta redirección puede hacerse de varias formas, incluso de manera automática modificando las rutas anunciadas por BGP dependiendo de las incidencias detectadas por un monitor al cual se envían los datos Netflow, como muestra el siguiente esquema tomado del proyecto opendaylight:
Figura 8 - Problemática de la redirección del tráfico
Como se puede imaginar, estas modificaciones sobre la marcha de los enrutamientos no son sencillas y puede que el ISP no permita hacerlas si el servicio de depuración de conexiones no lo está aportando el mismo. Si no se permiten estas redirecciones, se deberá enrutar todo el tráfico del servicio (sea o no posiblemente malicioso) al centro de depuración para que sea tratado en consecuencia.
Por otra parte, si el ISP realiza el procedimiento automático de modificar las rutas anunciadas por BGP, existe el problema adicional de la lentitud de respuesta ante el posible ataque, ya que los temporizadores de BGP suelen ser muy lentos.
Aunque este procedimiento de redirección de tráfico sospechoso se ha visto para el caso de "depuración en la nube", un esquema parecido se puede implementar en la arquitectura local, sustituyendo el "centro de depuración" por el appliance que realice ese mismo trabajo.
No obstante los problemas de configuración selectiva de la redirección siguen siendo los mismos, o incluso mayores porque normalmente a nivel local no se cuenta con la flexibilidad que aporta el protocolo BGP.
Es por ello que en las soluciones locales se hace difícil implementar esta arquitectura de diversificación de flujos, a no ser que se cuente con una infraestructura de red basada en Software o red SDN (en la anterior entrada "Ideas básicas sobre SDN" se introdujeron los conceptos clave sobre redes SDN).
En este caso, la utilidad viene dada en la versatilidad que aporta el Controller a la hora de destinar los flujos de conexiones atendiendo a cualquier parámetro que pueda imaginarse. En el caso que se aborda se tendrían las siguientes ventajas:
- La recolección de estadísticas, información de las trazas, etc que de otra manera deberían ser exportadas o tomadas por equipos únicos situados en línea de las conexiones, son tomados directamente por todos y cada uno de los switches, por lo que no existe la necesidad de añadir equipamiento adicional.
- La información es tratada por el controlador y el software conectado a su API el cual realizaría las tareas de detección y mitigación de ataques DDoS, dando instrucciones al controlador para que desviase los flujos que desee hacia la herramienta de depuración.
En el siguiente esquema, tomado de una solución de Radware, puede napreciarse los puntos comentados:
Figura 9 - Esquema con equipo anti-DDoS y red SDN
Como puede observarse, el despliegue de esta solución es mucho más simple, y solventa todos los problemas de tiempos de respuesta que se encuentran en las arquitecturas tradicionales, al contar con la facilidad de reconfiguración de los flujos de tráfico desde el controlador SDN, y la inteligencia que aporta el software que utiliza su API.
3 - Planificación de la contingencia
Como último punto a tratar dentro de este apartado está la designación de un plan de contingencia que marcará las pautas de actuación en caso de recibir un ataque y que este no pueda ser detenido.
Debido a la efectividad de los ataques DDoS es importante definir (con suficiente antelación) qué hacer en última instancia si un servicio es atacado y ni las medidas de prevención ni de detección/mitigación adoptadas son suficientes para detenerlo.
Aquí las posibilidades son infinitas aunque algunas de las acciones que en última instancia podrían tomarse son:
- Realizar el bypass del equipo "cuello de botella", si el ataque está afectando primordialmente a equipos intermedios de conexión.
- Acordar con el ISP el descarte directo de cierto tráfico (black holes con BGP por ejemplo) para evitar que este llegue a la arquitectura propia. El tráfico seleccionado pueden ser redes completas (ya que seguramente no se tenga información precisa sobre los orígenes del ataque), de manera que se descarte tanto el tráfico de ataque como mucho del tráfico lícito de clientes.
- Deshabilitar totalmente el servicio que está siendo atacado. Esto puede ser útil si el servicio es atacado por un exploit (que incremente por ejemplo su uso de CPU hasta el 100%) y corre sobre una plataforma compartida y el ataque, aunque solo esté destinado a él, está afectando al resto de servicios que utilizan la misma infraestructura.
- Añadir más equipamiento para repartir la carga de manera balanceada, en el caso de que sea un servicio que esté soportado por varios servidores balanceados. En este caso se podrían incluir varios servidores adicionales en el pool, con lo que la carga/servidor sería menor. Esta solución es útil si los servidores pueden desplegarse rápidamente (por ejemplo por ser virtuales) y los equipos que balancean la carga soportan sin problema la carga del ataque. Existen incluso soluciones de fabricantes de balanceadores que pueden detectar una mayor demanda de recursos en los servidores y, mediante una integración con los productos de virtualización (vCenter de VMware, por ejemplo), crear nuevas máquinas virtuales, añadirlas al pool de servicio y comenzar automáticamente a repartir la carga entre esos nuevos servidores y los antiguos.
Estos son solo algunos ejemplos de las acciones últimas a tomar en casos límite, los cuales habría que sopesar si, atendiendo a las particularidades del servicio, podrán ponerse en uso en caso de contingencia.
Las consecuencia de algunas de ellas es una interrupción total o parcial (para algunos clientes) del servicio atacado, pero muchas veces esto es mejor que afectar a la totalidad de servicios proporcionados por un Data Center.
Las consecuencia de algunas de ellas es una interrupción total o parcial (para algunos clientes) del servicio atacado, pero muchas veces esto es mejor que afectar a la totalidad de servicios proporcionados por un Data Center.
