[Guille]

Buenos días:

Se me ha hecho muchas veces la pregunta sobre el funcionamiento de la protección anti-DDOS L7 que desarrollamos y por qué el VAC no es suficiente.
Antes es necesario comprender el funcionamiento de una solución de protección uni-direccional o asimétrica como el VAC.
Luego nos interesaremos en las protecciones bidireccionales alias “simétricas”.

El VAC se ocupa únicamente de paquetes entrantes. No hacia fuera. Es decir que todos los paquetes IP provenientes de Internet pasan por el VAC y el VAC mira si el paquete es OK o no. Y deja pasar pasar el paquete legítimo y bloquea el paquete no legítimo. Pero las respuestas del servidor se hacen directamente sin pasar por el VAC. Es como funciona la red de cortafuegos Tilera y Arbor.

Es un modo de funcionar que permite activar la protección “al vuelo” sin ninguna modificación de la infraestructura del cliente. Por lo tanto muy suave. Y puede hacer muchas cosas basándose sólo en la entrada de un servidor. Eso requiere utilizar la astucia para descubrir si un paquete es legítimo o no, pero globalmente hay pocos falsos positivos a condición de tratar los ataques L3/L4.

Si se quiere tratar los ataques L7 en uni-direccional eso quiere decir forzosamente que el VAC (cortafuegos, Tilera, Arbor) debe dejar el paquete llegar al servidor, dejar abrir la conexión sólo después de que el VAC mire lo que ocurre con la conexión y decida si la corta o la deja.
En efecto el VAC no modifica los paquetes, no hace de proxy, sólo decide dos cosas: dejar pasar o cortar. Y en los casos de los ataques L7 no pueden decidir sin saber lo que hay en la petición y por lo tanto dejan iniciar la petición en el servidor.

Tomando el ejemplo del Slowloris, eso quiere decir que el ataque llega justo al servidor, la conexión TCP está abierta sobre el servidor web y luego solamente el VAC (más concretamente Arbor) va a cortar la conexión al cabo de 4 o 5 segundos en los que va a descubrir que es el Slowloris.
Consecuencia: el servidor debe aceptar todas las conexiones incluyendo el ataque. Solo después se alivia de conexiones no legítimas.

Y es lo mismo para los scans, robots, ataques de gran número de conexiones por segundo o el número de conexiones simultáneas.
En resumen, el servidor asume el ataque y sólo podemos esperar que
Arbor cortará lo suficiente para que el servidor no cuelgue.
Por lo tanto, debe ser un servidor bien fuerte para que llegue a soportar cualquier ataque.

Aquí interviene la protección bidireccional alias simétrica, sobre la cual trabajamos.
El objetivo de esta protección es tomar cualquier ataque en lugar del servidor, aceptar todas las conexiones, abrirlas y mirar si lo que llega es legítimo o no.
Y solamente si es legítimo, la infraestructura va a crear una conexión hacia el servidor y va a reenviar la petición legítima. Luego mirará la respuesta y la reenviará al verdadero usuario.
Si no es legítima cortará la conexión y no molestará al servidor con ella.
Y en el caso de el anti-DDOS l7 bidireccional el servidor no ve nada más que tráfico legítimo, al contrario que el anti-DDOS l7 unidirecciona en donde recibe todos los ataques.

Para hacer Anti-DDOS l7 bidireccional se necesitan cajas realmente fuertes que sepan manejar todos los ataques . El synflood, el ackflood y todos los ataques L3/L4 de base y luego todos los ataques de aplicaciones. Es por lo tanto hard con ASIC que tratan todo en hardware. Por ejemplo la infraestructura de test es capaz de generar 60 M de paquetes syn por segundo!! (un Arbor que es 20x mas caro es capaz de generar 40 M)

En resumen las protecciones unidireccionados están hechas para L3/L4 y no del todo para L7 por cuestiones de eficacia y de coste.
El principal de problema de la protección anti-DDOS l7 bidirecional es que no se puede activar “al vuelo” . Funciona un poco como un CDN o un proxy. Es necesario tomar las peticiones del web y luego reenviarlas al servidor. Y por lo tanto es necesario cambiar la IP del sitio a proteger.
Ssólo salvo que ahí haya una solución colocada que permita activar esa protección L7 bidireccional al vuelo. Es un poco complejo explicar como hemos llegado a activar la protección de una IP y protegerla de todas las peticiones web contra … esa misma IP!!

El cliente no tiene nada que cambiar. Como en las uni-direccionales.

Podemos activar también el SSL con el tratamiento por los ASIC de cifrado y el cache de ficheros estáticos de máximo 4 Mb por IP sobre SSD local en una caja. Eso permite descargar el servidor como un CDN y evitar las sobrecargas del servidor debido al cifrado SSL y los ficheros estáticos.
¿Es una solución perfecta?
Hay un pero: podemos proteger en anti-DDOS l7 bidireccional únicamente las IP sin tráfico saliente. En efecto si protegemos la IP principal del servidor y el servidor quiere crear un petición web hacia una IP en la red, va a enviar un SYN y la respuesta ACK va a llegar en la infraestructura anti-DDOS l7 y será eliminada por no conocida/iniciada por la infraestructura.
Es necesario utilizar la IP FO y sin tráfico saliente. A menudo este es el caso por ejemplo la IP de nuestros servidores compartidos son IP que no tienen más que tráfico entrante. El tráfico saliente sale por otras IP. Si tienes un sitio importante o ataques en la web es necesario proporcionar una IP FO para la web. Por lo tanto los KS2013 no puede aprovechar verdaderamente esta protección, porque no tienen IP FO.

Ayer hemos testeado las protecciones anti-DDOS l7 bidireccionales con un cliente que tenía un pequeño ataque L7 contra las URL aleatorias a partir de 200 botnet. Eso generaba 250 peticiones/ segundo, 1500 conexiones a medio abrir y 100 conexiones simultáneas en nuestra infraestructura. La infraestructura finalmente filtró todas las peticiones web de verdaderos visitantes. Por lo tanto el cliente no ha visto ninguna conexión de botnet en su servidor.
Con una protección unidireccional habría debido aceptar todas las peticiones sobre el servidor y sólo después la conexión se hubiera cortado por no legítima. Pero con un KS eso funcionaría sin problemas, salvo por las conexiones salientes.

Podemos comparar los dos tipos de protección a un portero a la entrada de una discoteca. Deja entrar a todo el mundo y luego hace salir a los que causan desorden. Y la otra no deja entrar más que a los clientes que vienen a divertirse.

Y esto es por lo que desarrollamos esta tecnología exclusiva que podremos proponer a partir de algunos euros / mes… Sólamente.

[fuegox]

Hola necesito que alguien me pueda traducir este mensaje de oles, que no lo ha puesto todavia por aquí (quizás se le haya olvidado) pero no de google traductor ni nada.. Alguien que sepa "francés" y sea amable, ya que al traducirlo con google y tal no se entiende un carajo.. A lo que se refiere:

Bonjour,
On m'a posé plusieurs fois la question sur le fonctionnement de
protection anti-DDoS L7 qu'on développe et pourquoi le VAC
actuel ne suffit pas.

Avant il faut comprendre le fonctionnement d'une solution de
protection "uni-directionelle" ou "asymétrique" comme le VAC.
Puis intéressons nous aux protections "bi-directionnelles" alias
"symétriques".

Le VAC s'occupe uniquement de packets entrant. Pas sortant.
C'est à dire que tous les packets IP venant de l'Internet passent
par le VAC, et le VAC regarde si le packet est okey ou pas et donc laisse
passer le packet légitime et droppe le packet non légitime. Mais
les réponses du serveur se font en direct sans passer par le VAC.
C'est comme ça que fonctionne le Firewall Network, Tilera et Arbor.

C'est un mode de fonctionne qui permet d'activer la protection
"on the fly" sans aucune modification de l'infra du client. Donc
très souple. Et on peut faire déjà pas mal de choses en se
basant juste sur le input d'un serveur. Ca demande d'utiliser
les astuces pour découvrir si un packet est légitime ou pas
mais globalement il y a peu de faux positive à condition de
traiter les attaques L3/L4.

Si on veut traiter les attaques L7 en uni-directionel cela veut
forcement dire que le VAC (Firewall, Tilera, Arbor) doit laisser
le packet arriver sur le serveur, laisser ouvrir la connexion puis
seulement après le VAC regarde ce qu'il se passe lors de la
connexion et en suite décide si on coupe la connexion ou on la
laisse. En effet, le VAC ne modifie pas les packets, ne fait pas
de proxy mais uniquement décide 2 choses: je laisse passer
ou je coupe. Et dans le cas des attaques L7, il ne peut rien
decider sans savoir ce qu'il y a dans la requête et donc il laisse
s'initier la requête .. sur le serveur.

Prenant l'exemple de slowloris, cela veut dire que l'attaque
arrive jusqu'au serveur, la connexion TCP est ouverte sur le
serveur web et en suite seulement le VAC (plus précisément
Arbor) va couper la connexion au bout de 4 ou 5 secondes
car il va découvrir que c'est du slowloris.

Consequence: le serveur doit accepter toutes les connexions
y compris l'attaque puis seulement il est soulagé des connexions
non legitime.

Et c'est la même chose pour les scans, les robots, les attaques
en nombre de nouvelles connexions par seconde ou le nombre
de connexions simultanées.

Bref, le serveur se prend toute l'attaque et on peut juste espérer
que ce qu'Arbor coupera suffira pour que le serveur ne coule pas.
Il faut donc le serveur bien bien fort pour qu'il arrive à se prendre
toute attaque.

C'est là qu'intervient la protection bi-directionelle alias symétrique
sur laquelle on travaille. Le but de cette protection est de se
prend toute l'attaque à la place du serveur, d'accepter toutes les
connexions, de les ouvrir et voir si ce qui arrive est légitime ou pas.
Et seulement si c'est légitime, l'infra va créer une connexion vers le
serveur et va rejouer la requête légitime. Puis regarde la réponse puis
renvoyer la réponse au vrai visiteur. Et si ce n'est pas légitime, couper
la connexion et ne pas embêter le serveur avec.

Et donc dans le cas de anti-DDoS L7 bi-directionel le serveur ne
voit rien d'autre que le trafic légitime, à l'opposé de l'anti-DDoS L7
unidirectionnel où il se prend toute l'attaque.

Pour faire du anti-DDoS L7 bi-directionel il faut donc de boitiers
vraiment fort qui savent se prend toute l'attaque et quelque soit
l'attaque. le synflood, l'ackflood et toutes les attaques L3/L4 de
base puis toutes les attaques applicatifs. C'est donc du hard avec
des ASICs qui traitent tout en hardware. Par exemple l'infra de
tests est capable de gérer 60M de packets syn par seconde (!!).
(le boitier d'Arbor qui est 20x + cher est capable de gérer 40M).

Bref, les protections uni-directionel c'est fait pour L3/L4 et pas
du tout pour L7, pour de questions d'efficacité et de cout.

Le principal problème de protection anti-DDoS L7 bi-directionelle
est qu'on ne peut pas les activer "on the fly". ça fonctionne un peu
comme un CDN ou un proxy, il faut prendre les requêtes web puis
les rejouer sur le serveur. Et donc il faut changer l'IP du site à protéger

Sauf que là on a mis justement une solution en place qui permet
d'activer cette protection L7 bi-directionel "on the fly". C'est un peu
complexe à expliquer mais on est arrivé à activer la protection d'une
IP et la protéger tout en rejouant les requêtes web vers .. cette même
IP (!!). Le client n'a rien à changer. Comme dans les uni-directionnelle.

On peut activer aussi le SSL avec le traitement par les ASIC de
chiffrement et le cache de fichiers statiques de max 4Mo par IP
sur un SSD local au boitier. Ca permet de décharger le serveur comme
un CDN et éviter les surcharges du serveur dû au chiffrement SSL et
aux fichiers statiques.

C'est donc une solution parfaite ?

Il y a un mais: on peut protéger en anti-DDoS L7 bi-directionel
uniquement les IP sans trafic sortant. En effet, si on protège
l'IP principal du serveur, et si le serveur veut créer une requête
web vers une IP sur le Net, il va envoyer un SYN et la réponse
ACK va arriver sur l'infra anti-DDoS L7 et sera droppé puisque
non connu/initiée par l'infra. Il faut donc utiliser les IP FO et sans
trafic sortant. Souvent c'est le cas, par exemple les IP de nos
MUTU sont des IP qui n'ont que du trafic entrant. Le trafic sortant
sort par d'autres IP. Si vous avez un site important ou des attaques
sur le web, il faut donc prévoit une IP FO que pour le web.
Et donc les KS2013 ne peuvent pas vraiment profiter de cette
protection puisqu'ils n'ont pas de IP FO.

Hier, nous avons testé les protections anti-DDoS L7 bi-directionelles
avec un client qui s'est pris une petite attaque L7 vers les URLs
random à partir de 200 botnet. Cela gênerait 250 req/sec, 1500
half openned connexions et 100 connexions simu sur notre infra.
L'infra filtrait toutes ces requêtes puis gênerait sur le serveur du
client uniquement les requêtes web de vraies visiteurs. Donc le
client n'a vu aucune connexion de botnet sur son serveur. Avec
une protection uni-directionnelle, il aurait dû accepter toutes ces
requêtes sur le serveur puis seulement après la connexion
aurait été coupée car non légitime. Mais avec un KS ça marchait
sans problème .. sauf pour les connexions sortantes.

On peut comparer les 2 types de protections à un videur à l'entrée
d'une boite de nuit. L'un laisse entrer tout le monde puis fait sortir
ceux qui foutent le bordel. Et l'autre ne laisse entrer que les clients
qui sont venus uniquement pour s'amuser. C'est pas rien et c'est
pourquoi on développe cette technologie exclusive qu'on pourra
vous proposer pour quelques Euro / mois .. seulement. et oui ..

Amicalement
Octave

Gracias