Firewall Windows : Pourquoi se priver du pare feu natif ?

Suite à l’article de l’ami Denis sur l’intérêt d’un firewall permettant la création de règle basée en autre sur un processus, j’ai voulu suivre ses recommandations sur l’utilisation du Pare Feu Windows livré nativement depuis Windows 7 (et aussi avant mais d’une qualité nettement moins bonne) et dont les fonctionnalités n’ont rien à envier aux concurrents payants.

Dans cet article, je passe en revue le cycle de vie de l’utilisation de ce firewall.

Installation

Pour l’installation, rien de plus simple : il n’y a rien à faire. Le firewall est livré par défaut sous Windows, il est accessible depuis le panneau de configuration, en pensant à utiliser les « Paramètres avancés » afin de pouvoir configurer finement la bête.

Autre manière tout aussi rapide d’y accéder : Démarrer / Exécuter et saisir « wf.msc »

La première des choses à faire est d’exporter la stratégie (au cas où on ne sait jamais) puis dans les propriété du Firewall sur les 3 profiles (domaine / privé et public) d’activer le firewall avec un blocage des connexions entrantes et sortantes

FWActivation

Ensuite, toujours pour chacun des profils, personnaliser l’enregistrement des logs afin de logger les paquets rejetés :

FWLog

Et enfin supprimer toutes les règles pour le trafic entrant et sortant.

A ce stade plus rien ne communique sur la station de travail.

Création des règles

Commencer par créer des règles en utilisant systématiquement le type « Personnalisée »

FWRegle

Denis Szalkowski nous a fait un billet sur son blog où il détaille les règles entrantes et sortantes de bases à mettre (looopback, dns, dhcp etc.). Je vous invite à lire son article à ce sujet pour créer vos règles.

Consulter les Logs

Que faire lorsque vous avez une application qui ne communique pas ? Et bien le mieux est de consulter les logs afin d’obtenir le plus de détails possible (protocole, port et adresse distante utilisée) dans le but de régler le plus finement possible votre firewall.

Journal des évènements

Pour activer la visualisation des logs du Pare Feu Windows, il faudra activer dans les stratégies l’audit sur l’accès aux objets :

Lancer « gpedit.msc » puis aller dans : Configuration ordinateur / Paramètres Windows / Paramètres de sécurité / Stratégie d’audit / Auditer l’accès aux objets (cocher Réussite et Echec)

FWgpedit

Cette fonctionnalité est activable en ligne de commande :


Contrôler grâce à l’attribut « get » la prise en compte :

FWauditpolGet

 

Ensuite il faut mettre à jour sur le poste la stratégie configurée (que vous ayez opté pour l’activation graphique ou en ligne de commande) :


Désormais les trames sont loggées et visibles dans l’observateur d’événements / Journaux Windows / Sécurité :

FWOrservateurEvenement01

Vous noterez au passage que le protocole n’est pas mentionné en toute lettre mais par son numéro (ici le numéro 6). L’association numéro / protocole est disponible ici : http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

Il vous suffira ensuite de créer une vue personnalisée sur la source « Microsoft Windows security auditing » dans la catégorie « Rejet de paquet par la plateforme de filtrage » de cette manière :

FWOrservateurEvenement

Ainsi vous avez une vue filtrée uniquement pour les trames rejetées. Grace au « CTRL + F » on peut rechercher un terme (« firefox.exe » par exemple) pour voir les détails du blocage et ainsi créer une règle d’autorisation en conséquence.

Voici le requête XML de mon filtrage :

 

Netstat

Autre technique de sioux, tapez successivement les 2 commandes suivantes dans une invite de commande :

  • Consultez ensuite le fichier tasks.txt puis relever le PID du processus qui vous intéresse (« firefox » par exemple)
  • Consultez ensuite le fichier portlog.txt puis consulter les logs correspondant au PID relevé précédemment afin de connaitre le port et adresse de destination utilisée.

Moniteur de ressources

Enfin dernière technique, allez dans le gestionnaire des tâches Windows (taskmgr.exe), puis dans l’onglet Performance cliquer sur le bouton « Moniteur de ressources … »

Dans l’onglet « Réseau », choisissez (cochez la case) le processus qui vous intéresse puis consulter les connexion TCP associées à ce processus. Exemple ci dessous avec le processus « Onedrive.exe ».

Attention cette technique ne marche que SI et seulement SI le processus est autorisé à communiquer sur le réseau. Autrement dit il vous faudra soit arrêter le firewall, soit créer une règle ultra permissive sur ce processus (autoriser le programme quelque soit son protocole, son port et son adresse de destination). C’est la technique qu’utilise Denis

FWOneDrive03

 

Cas Pratique « One Drive »

Maintenant que l’on connait les rudiments, voici un cas pratique avec le « déblocage » de One Drive.

Consulter les logs afin de relever les informations permettant de créer une règle la plus fine possible :

FWOneDrive05

Ensuite créer une règle en allant chercher le programme « OneDrive.exe » :

FWOneDrive01

Alors attention, en cliquant sur « Parcourir » pour aller chercher le programme « OneDrive » (qui se trouve être dans C:\Users\VOTRE LOGIN\AppData\Local\Microsoft\OneDrive\) automatiquement le firewall vous écrira le chemin suivant :


Remplacer de suite le %userprofile% par le chemin réel :


En effet, Microsoft  stipule dans cet article qu’il ne faut surtout pas utiliser les variables d’environnement liées au contexte utilisateur. Le Firewall ne s’exécutant pas dans votre contexte utilisateur n’a aucunement connaissance du contenu de la variable %userprofile%

 

Continuez à créer la règle on spécifiant le protocole + port utilisé :

FWOneDrive02

 

Puis enfin spécifiez les adresses de destination :

FWOneDrive04

Voilà désormais One Drive communique correctement

Conclusion

Pour conclure je dois admettre l’efficacité de ce FireWall d’autant qu’il est livré nativement et permet de sauter la case « Logiciel Tiers qui est compatible aujourd’hui mais qui risque bien de faire un plantage demain »

Cependant son gros défaut (et je ne suis pas le seul à le penser) est l’absence d’un mode « Interactif« . Vu chez les concurrent, ce mode ouvre une notification pour chaque entrée ou sortie détectée sur le PC. Voici une illustration avec Eset Smart Security :

FWInteractif

Ce mode très pratique permet de simplifier grandement l’utilisation d’un Firewall. Certains (comme Eset) propose même de Mémoriser temporairement une règle (le temps d’exécution du processus) ce qui s’avère extrêmement pratique lorsque actuellement de plus en plus de logiciels s’installe en utilisant des sources depuis l’internet je pense à :

  • Flash Player
  • Google Chrome
  • Adobe Creative Cloud
  • etc.

Même si la liste citée n’est pas forcément la plus représentative mais dans l’idée actuellement on télécharge un installeur léger de quelques kilo-octets qui va en réalité chercher les sources d’installation sur le net. Et créer une règle autorisant la communication pour la retirer ensuite peut s’avérer lourd à l’utilisation.

 

A propos de l'auteur :  Fabien Lierville

Chef de projet en Ingénierie Informatique Industrielle avec une expérience significative de 17 années. Gestion de projet à dominante pharmaceutique avec le respect de méthode qualité (GAMP V5). Véritable passionné d'informatique depuis l'Amstrad cpc 6128 ;)

Laisser un commentaire

Une réponse à “Firewall Windows : Pourquoi se priver du pare feu natif ?