L'ActiveArmor, le Firewall 2.0

nVidia a mis beaucoup d’effort dans cette fonctionnalité, qui consiste en fait en l’association d’un firewall et d’un moteur réseau matériel.

L’ActiveArmor

Premièrement, l’ActiveArmor consiste à décharger le CPU des tâches de filtrage des trames réseau, et de les effectuer sur le moteur réseau afin de permettre la réalisation d’un filtrage efficace sans trop alourdir la charge CPU. Sans revenir sur le modèle en couches OSI, ce moteur réseau intervient entre le moment où la carte réseau reçoit les trames, et le moment où la trame parvient à la dernière couche, Application.

En zoomant sur cette boîte, on obtient l’organigramme suivant :

Le cœur du système repose sur le Firewall qui réalise un premier tri entre les mauvais paquets, les bon paquets, et les paquets non reconnus qui sont alors transférés à un vérificateur qui lui est pris en charge par le CPU, au contraire des tâches précédentes prises en charge par le moteur réseau. L’ActiveArmor récupère donc directement les trames du contrôleur réseau et ne les transmet en mémoire centrale que si elles sont validées, alors que dans le schéma classique celles-ci sont d’abord inscrites dans le noyau du système, avant d’être vérifiées par le CPU pour enfin être transmises aux applications.

Le Firewall

Nous en arrivons au Firewall à proprement parler. La compréhension du fonctionnement du Firewall nous oblige à un rapide rappel sur le fonctionnement d’un réseau. Lorsqu’un PC veut envoyer des informations à un autre PC, ses informations sont progressivement segmentées en trames. Outre la portion d’information à transmettre et le code CRC, chaque trame possède obligatoirement l’adresse IP de l’ordinateur source, et l’adresse IP de l’ordinateur de destination.

Un Firewall est un élément qui va réaliser le filtrage des paquets à partir des éléments de l’entête IP, et de certains éléments de l’entête UDP/TCP. Une fois avoir défini au Firewall les critères de filtrage, celui-ci fonctionne de la manière suivante. Dès qu’un paquet arrive sur le port désigné par une des règles, ses entêtes IP, TCP et UDP sont analysées. Chaque règle est alors appliquée au paquet. Il est important de signaler ici que les règles sont stockées dans un ordre précis, et appliquées dans le même ordre. Si une règle bloque, le paquet est rejeté. Si une règle accepte, le paquet passe. Si le paquet ne satisfait à aucune règle, il est bloqué.

Ainsi, il est possible d’interdire l’accès de trames provenant ou à destination d’une certaine plage d’adresse IP. Il est également possible de bloquer directement certains ports, par exemple le port 21 (ftp). Pour bien comprendre, considérons un exemple de règles permettant de bloquer les applications de type FTP mais acceptant le HTTP sur une interface I1, et acceptant les paquets FTP sortant uniquement pour un PC muni de l’adresse IP 200.100.63.42, sur une interface I2 :

Exemple de règles d'un Firewall
N° règle	IP source	Port source	IPdestinataire	Port destinataire	Décision	Interface
#1	*	*	*	21	Bloquer	I1
#2	*	*	*	80	Accepter	I1
#3	200.100.63.42	*	*	21	Accepter	I2

Voilà pour le principe de base des Firewalls. Parlons du point de vue performances maintenant. Ce type de Firewall, « Stateless », présente l’inconvénient de devoir confronter chaque paquet à chaque règle définie. Plus il y a de règles et surtout de débit réseau permis par les interfaces, et plus l’occupation CPU devient importante pour la réalisation de ces tâches.

Une optimisation à ce type de Firewall, également supportée par le Firewall de nVidia est le « Statefull » Firewall. L’optimisation consiste à ne confronter les paquets aux règles du Firewall que lorsqu’une connexion s’établit. Si celle-ci est acceptée, une entrée est ajoutée à une table de suivi du statut de connexion. Ainsi, les prochains paquets qui correspondront à cette table pourront être vérifiés via la table des connexions acceptées, au lieu d’être confrontés à chaque règle du Firewall. Au final, le même niveau de sécurité qu’avec les Firewall « Stateless » est atteint, mais beaucoup de cycles CPU sont économisés.

Au niveau pratique, ce firewall se paramètre comme toujours avec le navigateur Internet, via une interface qui semble très claire et ergonomique.

L’Intelligent Application Manager

Cette fonctionnalité du Firewall permet simplement d’effectuer un filtrage basé sur les applications, qu’elles soient serveur ou client. Ainsi, lorsqu’une application inconnue tente d’accéder au réseau, une fenêtre s’ouvre demandant à l’utilisateur d’accepter ou non la connexion. Il est alors possible d’accepter une fois pour toute les connections de ce programme au réseau, sans avoir à paramétrer le Firewall à la main.

Enfin, le gros avantage de cette association Firewall/SNE réside dans l’occupation CPU. Nous le verrons plus loin, ce Firewall sera adapté sur les chipsets nForce précédent, mais évidemment il ne sera pas pris en charge par le chipset. nVidia utilise une démonstration utilisant NTttcp entre deux PC connectés via Ethernet Gigabit, afin de mesurer l’écart d’occupation CPU entre une prise en charge matérielle du Firewall de nVidia, et une prise en charge software du Firewall de Norton. Dans ces conditions, l’occupation CPU atteint 75 % sur Norton contre 15 % sur le Firewall nVidia. Si ce chiffre est intéressant, il ne représente pas moins une situation extrême qui masque le vrai problème de cette fonctionnalité : son manque de réalisme.

Cet ensemble s’annonce en effet très puissant, mais nous avouons avoir quelques doutes sur son intérêt pour le commun des mortels. Certes, le SNE permet de réduire l’utilisation processeur en cas d’utilisation des débits permis par l’Ethernet Gigabit. Mais nous doutons de l’utilisation en continue de tels débits sur un réseau local entre papa et le petit frère, d’autant qu’un tel réseau n’a pas besoin d’autant de sécurités. Par ailleurs, vu les débits permis par l’ADSL actuellement, le firewall intégré à Windows XP SP2 paraît largement suffisant et n’entraîne pas vraiment de hausse significative de l’utilisation CPU. En outre, si un Firewall est effectivement une protection efficace pour se protéger des attaques sur des failles non corrigées, son intérêt est plus relatif avec un système d’exploitation à jour au niveau failles de sécurité/noyau. Il aurait peut-être été intéressant d’allouer ces ressources à d’autres développement, même si techniquement la solution semble solide et conviendra certainement à plusieurs utilisateurs.

Envoyer le lien de cette page par email :

Votre adresse *

Votre nom *

Adresse du destinataire *

Envoyer

* Les adresses email récoltées via ce formulaire ne sont pas enregistrées sur notre serveur et ne servent qu'à l'envoi demandé