Principe de fonctionnement de Windows Firewall

XP et si je tape
www.cnn.com
dans la barre Address, IE amène le
système à  envoyer une requête à 
CNN pour demander sa home page.
Windows Firewall ne bloque pas le
trafic sortant mais il note où il va.
Quelques instants plus tard, le serveur
Web de CNN essaie d’envoyer à 
IE les données qu’il a demandées.
Windows Firewall voit le trafic entrant,
détermine qu’il provient de
www.cnn.com – un site auquel mon
système a envoyé une requête – et laisse passer le trafic. On a compris le principe de base :
Windows Firewall permet de communiquer avec le reste
d’Internet et avec l’intranet pourvu que votre système
amorce la conversation.
A l’inverse, supposons qu’un système extérieur – peutêtre
bien infecté du ver Blaster – essaie d’entamer une
conversation avec mon système XP. Le système externe essaie
d’envoyer un paquet à  mon port 135, en profitant de
l’occasion pour infecter mon système avec Blaster. Comme
Windows Firewall ne reconnaît pas cette communication
comme une réponse à  une conversation que mon système a
entamée, le pare-feu ignore le paquet. En quelque sorte,
Windows Firewall dit au réseau : « Ne me parle que quand je
parle le premier ».
Que se passerait-il si vous activiez Windows Firewall sur
un système à  l’intérieur de votre intranet – un intranet
connecté à  un domaine ? Au premier abord, vous pourriez
considérer que le fait de rejeter toutes les communications,
sauf celles qui sont déclenchées par un client, freinerait
d’une certaine manière la participation habituelle d’une station
de travail dans un domaine – ce fut en tout cas ma première
conclusion un peu hâtive. Mais, en y réfléchissant
bien, il m’est apparu que toute la communication d’un domaine
est amorcée par un client : le client demande à  se
connecter, le client demande les rafraîchissements des stratégies
de groupe, le client demande les profils itinérants, et
ainsi de suite. Pour tester cette théorie, en septembre 2003,
j’ai activé Windows Firewall sur plusieurs stations de travail
XP dans mon domaine basé sur AD (Active Directory).
Depuis lors, je n’ai constaté aucune perte de fonctionnalités
du domaine. Mais, comme je l’ai dit précédemment, mes outils
d’administration à  distance ne fonctionnent que si je
désactive ou modifie Windows Firewall.
Votre réseau connaîtra peut-être des problèmes, ce ne fut pas le cas du mien. Par exemple, je connais quelqu’un qui,
après avoir activé le pare-feu pré-SP2, a perdu la possibilité
de consulter Network Neighborhood et de s’associer aux
shares. Sachez que chaque segment de réseau a besoin d’un
« browse master » : une machine qui recense les serveurs sur
son segment. N’importe quel serveur peut jouer le rôle de
browse master et, dans la plupart des réseaux, chaque station
de travail est un serveur. Sur un segment qui n’a pas de serveur
réel, comme un serveur de fichiers ou un serveur d’impression,
une station de travail quelconque assume la fonction
de browse master. Mais, dans un segment uniquement
peuplé de stations de travail dotées de leurs propres parefeu,
aucun système ne sera volontaire pour assumer le rôle
de browse master et la navigation dans Network Neighborhood
échouera. On verrait aussi ce comportement sur un
segment peuplé uniquement de systèmes XP équipés en
SP2, sauf si l’on a modifié le pare-feu sur au moins un
système sur le segment pour ouvrir le port et permettre à  ce
système de fonctionner comme un serveur de fichiers et
d’impression.
Commençons par l’aspect le plus fondamental du
contrôle de Windows Firewall : le mettre en marche et l’arrêter.
Vous pouvez désactiver et activer Windows Firewall sous
SP2 de trois manières : au moyen de la GUI, à  partir de la
ligne de commande, et par le biais des stratégies de groupe.