Table des matières Page précédente Page suivante Version mono-page

III-11 Firewall applicatif

Jusqu'à présent, les utilisateurs de Windows® ont pu comparer le fonctionnement des techniques de Firewall de Linux avec ce qu'ils trouvent sur leur OS. Et bien que les fonctionnalités de Netfilter soient au moins équivalentes à ce que l'on trouve dans les outils de firewall sous Windows®, il reste une fonctionnalité qui manque à Linux : c'est le firewall applicatif.

On appelle "firewall applicatif" la capacité d'un logiciel à contrôler à la fois les flux de données entrantes et sortantes en fonction de certains critères (adresse IP, port, type de connexion, etc...), mais aussi des applications qui exploitent ces connexions. En gros, un firewall applicatif va permettre de contrôler quelles sont les connexions réseau que fait tel ou tel logiciel.

C'est typiquement ce que font des applications fonctionnant sous Windows®, tel que par exemple ZoneAlarm®, TinyFirewall®, Lock 'n' Stop®, etc... A chaque connexion que tente une application, ces firewall applicatifs vérifient que la connexion est autorisée, ou alertent l'utilisateur.

Mais à quoi sert exactement ce type d'application ? En fait, il permet à l'utilisateur de surveiller si telle ou telle application tente une connexion non autorisée, quasiment dans le dos de l'utilisateur. Par exemple lorsque Word® ou Excel® font une connexion Internet sans raison apparente, que le MediaPlayer® envoie une requête alors qu'il est en pleine lecture de vidéo, ou qu'une dll/ActiveX/autre utilise Internet Explorer® pour accéder à Internet. L'utilisateur de Windows® n'aurait donc pas confiance en les applications qu'il utilise ? Oui, c'est du moins ce qui ressort des discussions des utilisateurs de Windows® et de firewall applicatifs. Et pourquoi ne passent ils pas sous Linux alors ? Smiley Parce que ce les firewall applicatifs n'existent pas peut-être ? Que nenni, le firewall applicatif sous Linux, c'est faisable !

La mise en place d'un système de firewall applicatif se fait en fait en 2 temps :
  • Premièrement, il faut charger le module du kernel appelé "ip_queue"
    [root@phoenix /]# modprobe ip_queue
    
  • Puis dans les règles de Netfilter, par exemple au niveau des chaînes INPUT et OUTPUT de la table "Filter", il faut créer une règle qui envoie tout les paquets suspects vers la cible "QUEUE" (nous ne l'avons pas encore vue jusqu'ici). L'idéal est de la mettre en tant que dernière règle de la chaîne, afin que les autres règles aient déjà filtré les paquets :
    [root@phoenix /]# iptable -t filter -A OUTPUT -j QUEUE
    [root@phoenix /]# iptable -t filter -A INPUT -j QUEUE
    
    Dans le jargon du kernel, on dit que l'on envoie le paquet dans le "user space" ("espace utilisateur" en français)
  • Enfin, il faut avoir un applicatif qui va recevoir ces paquets, les analyser en fonction par exemple du programme qui a fait la connexion ou à qui elle est destinée, et refuser ou non le paquet. Une interface graphique peut par exemple montrer à l'utilisateur ce qui se passe, libre à ce dernier d'accepter ou non le paquet.
Pour l'instant, il n'existe que peu d'applications sous Linux qui fournissent de telles fonctionnalités "toutes faites". L'un d'entre eux est FireFlier. Comme le montrent les captures d'écran ci-dessous, ce logiciel gère à la fois les règles Netfilter classiques, ainsi que les règles spécifiques aux applications :
Règles iptables
Règles Netfilter
Règles de l'espace utilisateur
Règles de l'espace utilisateur
Vous pouvez évidement développer votre propre firewall applicatif. Pour cela, vous aurez besoin :
  • de la LIBIPQ, sur laquelle vous trouverez des informations ici.
  • éventuellement de ipqmpd qui permet de récolter les paquets IP venant de Netfilter. Vous pourrez le trouver ici
  • de quelques neurones, afin de créer votre programme de gestion des paquets, et des règles d'entrée / sorties.

Table des matières Page précédente Page suivante Version mono-page
Valid XHTML 1.0! Valid CSS!
Site de référence : http://olivieraj.free.fr/ Last modified: Sun Jun 19 19:15:09 CEST 2005