Problèmes de surcharge des garde-barrières sur les interfaces sécurisées

Ce mois-ci, plusieurs cas de blocages de gardes barrières (attaques par déni de service) ont été abordés dans les forums sécurité. Il s'agit à chaque fois de problèmes de saturation du garde barrière induits par un trafic "sortant" (i.e. depuis le réseau interne de l'entreprise) trop important. Nous vous en présentons ici une synthèse.

NetScreen :

Le premier produit a être mis sur le devant de la scène fut la gamme standard du garde-barrière Netscreen ( Netscreen-200 Series, Netscreen-100 (2), Netscreen-50, Netscreen-25 et Netscreen-5XP -http://www.netscreen.com/ ). Cette gamme se présente sous la forme d'une boite noire comportant typiquement 3 ports : 1 pour la connexion Internet , 1 pour la connexion vers la DMZ (Zone Démilitarisée) et le dernier vers le réseau interne de l'entreprise.

On a remarqué que les versions 2.6.1 du système d'exploitation ScreenOS de cette gamme supportent mal une charge conséquente sur son interface "Réseau interne". Par exemple, la série 5XP de Netscreen n'est pas capable de supporter plus de 2048 sessions IP concurrentes.

Un utilisateur sur le réseau interne de l'entreprise est donc capable de créer un déni de service du garde barrière, en saturant ce dernier de connexions.

Une parade a été introduite avec la version ScreenOS 2.6.1r2 (septembre 2001) par le biais d'une commande (Source IP Session Thresholding) permettant de fixer un nombre maximum de sessions IP autorisées pour un même utilisateur. Cette commande permet donc de pallier à ce problème.

set firewall session-threshold source-ip-based [nb]

où [nb] représente le nombre de sessions IP maximum

PIX de Cisco :

Le garde-barrière de Cisco, PIX présente également le même comportement sur ses interfaces "internes" avec la fonctionnalité de translation d'adresse (NAT) activée.

Ainsi, il est possible à des utilisateurs du réseau interne de créer un déni de service du garde-barrière en saturant la table NAT. La mise en œuvre de ce type d'attaque nécessite cependant que l'attaquant émette vers le garde barrière un grand nombre de connexions semblant provenir d'adresses sources distinctes, ce qui implique en général qu'il génère des adresses sources "spoofées" (i.e. usrpées).

Cisco recommande alors d'utiliser entre autre la fonctionnalité "reverse-path" permettant d'empêcher les attaques par "spoofing".

Une autre méthode est de restreindre l'utilisation de la translation d'adresse à un sous ensemble d'adresses autorisées :

Par exemple si le réseau interne utilise les adresses 192.168.0.0/24 et 192.168.5.0/24, alors on peut utiliser la commande suivante :

nat (inside) 1 192.168.0.0 255.255.255.0 0 0

nat (inside) 1 192.168.5.0 255.255.255.0 0 0

Document de Cisco sur "reverse-path" sous PIX: http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_v44/relnotes/pixrn445.htm#xtocid2419610

Recommandations de Netscreen à propos de la vulnérabilité décrite : http://online.securityfocus.com/archive/1/254268