PARE-FEU SORTANT

Bloquer l’accès Internet de n’importe quelle application sous Windows

Windows embarque un pare-feu compétent, mais par défaut il ne filtre que ce qui entre. WinSight vous donne un contrôle par application sur ce qui sort, gratuitement et en open source.

Pourquoi le contrôle sortant est une vraie lacune

La documentation de Microsoft indique que le pare-feu Windows bloque par défaut le trafic entrant non sollicité mais autorise le trafic sortant sauf si une règle le bloque. Ce comportement par défaut est raisonnable pour la plupart des gens, mais il signifie que n’importe quel programme de votre machine (un utilitaire de mise à jour, un traqueur livré avec un gratuiciel, ou un logiciel malveillant) peut appeler ses serveurs tant que vous n’écrivez pas vous-même une règle de blocage. Créer et maintenir ces règles dans le pare-feu Windows Defender avec fonctions avancées de sécurité est manuel : une règle par chemin d’exécutable, aucune vue des connexions en cours attribuées aux processus, et aucune trace de ce qu’une règle bloquerait avant que vous ne l’activiez.

Ce que fait WinSight à la place

Le pare-feu sortant de WinSight applique des décisions de blocage/autorisation par application via la plateforme de filtrage Windows (WFP) (la même couche noyau qu’utilise le pare-feu Windows lui-même) grâce à un service LocalSystem facultatif. Le déroulé est délibérément prudent :

  • Installez le service explicitement. Le programme d’installation ne le fait jamais pour vous ; enregistrer un service LocalSystem qui modifie WFP doit être une décision, pas un effet de bord.
  • Démarrez en mode audit. Le service observe et enregistre ce que vos règles bloqueraient. Rien n’est encore filtré : une règle erronée ne peut donc pas couper un programme.
  • Armez l’application depuis le tableau de bord. Seul un opérateur élevé peut l’armer, via un canal IPC authentifié. Il n’existe délibérément aucun chemin en ligne de commande pour armer.
  • Fiez-vous à l’état rapporté. WinSight distingue le mode que vous avez demandé de l’état qu’il peut prouver auprès du moteur de filtrage actif. S’il ne peut pas vérifier l’application exactement, il rapporte Degraded, jamais Active.

Un cas d’usage concret

Imaginons qu’un enregistreur d’écran testé récemment contacte sans cesse un hôte que vous ne reconnaissez pas. Dans WinSight, vous ouvrez Connexions et DNS pour confirmer quel processus possède la connexion, vous ajoutez une règle de blocage pour cet exécutable dans la vue pare-feu, vous laissez le mode audit confirmer que la règle ne vise que ce programme, puis vous armez l’application. Le blocage survit aux redémarrages, et son état effectif est revérifié à chaque lecture d’état.

Prérequis et limites

  • Windows 11 ou Windows 10 22H2 (x64 ; l’exécution privilégiée Arm64 n’est pas encore qualifiée. C’est dit, pas caché).
  • Installer et armer le service de pare-feu exige une console élevée et un opérateur élevé. Tout le reste de WinSight fonctionne par utilisateur, sans droits administrateur.
  • La règle est définie par application. WinSight ne propose pas aujourd’hui d’invites interactives par connexion comme le fait Little Snitch sur macOS.
  • Il complète le pare-feu Windows au lieu de le remplacer : la protection entrante reste l’affaire de Windows, et la vue en lecture seule des règles de WinSight renvoie vers la console du pare-feu Windows pour le trafic entrant.

Sources : learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/ · docs/WFP_DESIGN.md · README.md#install · README.md#security-posture, vérifié le 2026-07-24