Un pare-feu se présente habituellement comme un appareil qui s’installe en rup-ture de flux entre plusieurs zones de sécurité : une situation courante est une sé-paration entre trois espaces que sont l’Internet (réseau dangereux par nature), une DMZ (qu’il est important de protéger mais qui peut être amenée à discuter avec l’Internet) et le réseau interne qui ne doit recevoir aucune connexion de l’extérieur
mais peut être amené à communiquer de façon contrôlée avec la DMZ et parfois même l’Internet.
La logique de conception d’une politique de sécurité repose dans ce cas sur la définition de règles de flux. Les connexions autorisées sont définies à partir de l’adresse IP source (éventuellement d’un numéro de port) et d’un protocole, cela à destination d’un service bien particulier (numéro de port) et peut-être même d’une plage restreinte d’adresses IP. Les produits classiques (dits « à états », oustateful) vérifieront la conformité du trafic au niveau du protocole de couche 4 (TCP ou UDP) alors que des produits plus évolués (et souvent plus coûteux) pourront en plus s’assurer d’une certaine conformité au protocole supposé être transporté.
En complément (ou parfois au titre de seule et unique protection pour un poste isolé) de ces produits de sécurité situés aux extrémités du réseau il est de plus en plus courant d’équiper ses micro-ordinateurs d’un logiciel pare-feu. L’utilisateur d’un système de typeLinux pourra faire cela à moindres frais :Netfilter lui per-mettra de protéger son poste de travail tout en concevant ses règles de sécurité de la même façon qu’il le ferait pour un pare-feu situé dans le réseau (cf. la sec-tion 130). L’utilisateur d’un système Windows récent n’est pas oublié non plus : que ce soit le pare-feu intégré au système d’exploitation Windows XPou bien un produit du commerce, comme le pare-feuSygateou l’un de ses nombreux dérivés, l’utilisateur peut mettre en œuvre des moyens de protection de son ordinateur.
La philosophie de fonctionnement et de gestion, voire de conception, des règles de sécurité est cependant très différente entre ces produits et les plus classiques pare-feu réseau : si ces outils permettent, avec plus ou moins de facilité, la défini-tion de règles réseau, leur intérêt principal est d’y associer des autorisadéfini-tions d’accès au réseau pour des programmes. Une règle de sécurité autorisant le courrier élec-tronique pourrait ainsi devenir « j’autorise le programmeThunderbird, et lui seul, à se connecter sur le port 25 (SMTP), afin d’envoyer du courrier électronique ».
Dans la pratique, les interfaces de gestion proposées ne sont pas aussi pratiques qu’on le souhaiterait : dans un souci de simplicité (car l’utilisateur n’est en général pas un expert de sécurité informatique), les autorisations d’accès au réseau que l’utilisateur peut être amené à donner restent assez larges.
Un mode de fonctionnement assez typique de ce genre de produit est le suivant :
• à l’installation un certain nombre de règles par défaut autorisent du trafic sur le réseau (certains programme du système) ;
• lorsqu’un nouveau programme souhaite accéder au réseau, le pare-feu personnel détecte cette action et va émettre une alerte auprès de l’utilisateur, lui laissant le choix : autoriser ou bloquer ce trafic (et éventuellement se souvenir de ce choix pour la prochaine fois) ;
• à moins d’utiliser des règles avancées, pas toujours faciles à configurer, l’autori-sation précédemment donnée vaut pour tout le trafic réseau que le programme pourrait être amené à traiter, qu’il soit pour le service ayant généré l’alerte ou bien pour un autre service - et c’est là qu’est le danger.
Le pare-feu du système d’exploitation Windows XP
Lorsque l’option pare-feu est activée dans Windows XP (cela se fait dans les pro-priétés avancées d’une carte réseau), elle permet de mettre l’ordinateur dans un mode de fonctionnement de type « diode » : tout le trafic sortant est autorisé, mais le trafic entrant est, lui, interdit, sauf exception. Ces exceptions peuvent se confi-gurer manuellement ou bien donner lieu à une alerte lorsqu’elles se présentent.
Illustrons par deux exemples.
• Situation no1 :connexion SSH vers une machine distante en utilisant le pro-grammePutty. Cette situation ne donnera lieu à aucune alerte puisque, s’agis-sant d’une connexion sortante, elle n’est pas bloquée par le pare-feu Windows XP.
• Situation no2 :l’utilisateur lance le programme VLC (Vidéolan) et y configure un serveur pour diffuser du contenu sur le port TCP no1234. Cette action sera interceptée par le pare-feu Windows XP dès que le programme VLC indique au système qu’il est prêt à recevoir les connexions TCP sur le port no1234. Le pare-feu ouvrira alors une alerte pour demander à l’utilisateur de décider (figure 6.9).
Cette alerte, simple à comprendre, laisse cependant l’utilisateur expert sur sa faim : elle ne donne aucune information quant à la nature du trafic réseau qu’il faut autoriser (ou interdire), probablement parce que la décision par défaut sera, en cas de déblocage, d’autoriser tout trafic entrant destiné au programme VLC, que ce soit sur le port no1234 ou bien pour un autre service.
Il est bien sûr possible de consulter à tout moment l’état des autorisations (via les propriétés avancées de la carte réseau), comme on le voit sur la figure 6.10.
Figure 6.9 Panneau d’alerte du pare-feu deWindows
Ce tableau est d’ailleurs l’occasion de voir l’existence de quelques exceptions « par défaut » qu’il n’est pas possible de supprimer (les quatre premières lignes de la copie d’écran ci-dessus).
C’est également depuis cet écran que l’utilisateur pourra modifier les règles, par exemple pour restreindre l’autorisation de base accordée par le pare-feu Windows et limiter les plages d’adresses IP ou les numéros de ports autorisés.
Un pare-feu personnel dérivé de la technologie Sygate
Lorsque le système n’intègre pas de pare-feu en standard (par exemple Windows 2000) ou que les fonctions du pare-feu Windows XP sont jugées insuffisantes, il existe une pléthore de produits qui pour quelques dizaines d’euros permettent de rendre des services de sécurité. Nous illustrons cette section avec des copies d’écran issues du produitNetscreen Remote Security Client(version datant de 2002), qui utilise la technologie Sygate.
Le principe de fonctionnement est similaire au produit précédent, mais il intègre quelques fonctions complémentaires qui peuvent être utiles, par exemple :
Figure 6.10 Panneau de configuration du pare-feu deWindows
• la détection de certaines attaques comme unport scan;
• la possibilité d’autoriser ou d’interdire les services réseau Microsoft (partage d’imprimante, de fichiers, ou utilisation de tels serveurs) ;
• des facilités pour mettre en œuvre des règles « réseau » comme avec un pare-feu classique.
Le système d’autorisation, programme par programme reste comparable à celui du pare-feu Windows XP, avec en plus un contrôle aussi bien en entrée qu’en sortie.
Reprenons l’un des exemples précédents pour illustrer les quelques différences : connexion SSH vers la machine lamachinede.mondomaineamoi.fren utili-sant le programmePutty. Le pare-feu émettra l’alerte illustrée par la figure 6.11
même pour cette connexion sortante, parce que ce programme n’a pas été autorisé lors d’une utilisation précédente.
Figure 6.11 Mire d’alerte du pare-feuSygate
Ici aussi, il faudra, lors d’une deuxième opération, utiliser les propriétés avancées dans la liste des programmes autorisés pour préciser le souhait de n’autoriser que les connexions sortantes TCP sur le port no22, comme indiqué sur la figure 6.12.
Si cette configuration avancée est relativement simple à faire pour un programme commeputty, qu’en est-il lorsqu’il s’agit d’indiquer au pare-feu des règles avan-cées pour un programme système, comme celui montré sur la figure 6.13 ? À moins d’être un expert du fonctionnement de Windows 2000, bien peu de personnes sont en mesure de dire quels sont les flux qui peuvent être autorisés pour le programmeinetinfo.exe, et dans ce cas on se contentera du choix par défaut, à savoir : tout trafic réseau de ce programme est autorisé, sans restrictions.