Principe de fonctionnement

PacketHound modifie la règle par défaut du pare‑feu Windows pour bloquer toutes les connexions sortantes. La première fois qu’une application tente d’accéder à Internet, une fenêtre s’affiche avec le nom de l’application, son éditeur, l’adresse cible et le port. L’utilisateur choisit Autoriser ou Bloquer et la décision est enregistrée sous forme de règle du pare‑feu Windows, valable tant que l’application reste active ou de façon permanente.

Les décisions sont mémorisées dans le même format que les règles classiques, visibles dans wf.msc. Un commutateur unique permet de basculer rapidement une règle entre autorisation et blocage, et un journal répertorie chaque tentative bloquée avec son nom d’hôte et son port.

Architecture et intégration Windows

Le logiciel n’installe aucun pilote noyau et ne crée aucun service d’arrière‑plan dédié. Il s’appuie exclusivement sur l’API du pare‑feu Windows et sur le journal des événements de sécurité (Security event log) pour détecter les tentatives de connexion. Lorsqu’une entrée du journal indique une connexion sortante, PacketHound vérifie si le processus provient d’un répertoire Windows, possède le propriétaire « SYSTEM » et une signature Microsoft valide ; dans ce cas il autorise silencieusement la connexion.

Les processus non reconnus – y compris les outils souvent détournés par les malwares (PowerShell, curl, certutil, mshta, rundll32) – déclenchent le prompt. Le logiciel effectue une résolution DNS standard pour afficher le nom de domaine au lieu d’une adresse IP brute. Une requête hebdomadaire vérifie la disponibilité d’une version plus récente, sans transmettre d’informations d’identification.

Le code source est publié sur GitHub sous licence GPL‑v3, permettant à tout analyste de vérifier le comportement ou de compiler une version autonome.

Analyse de sécurité et limites

En bloquant par défaut les flux sortants, PacketHound empêche les programmes malveillants d’exfiltrer des données ou de télécharger des charges utiles, même si ces programmes utilisent des composants natifs de Windows. L’absence de pilote noyau réduit la surface d’attaque du logiciel lui‑même, et chaque règle créée reste gérable via les outils natifs de Windows.

Le principal point de dépendance est le pare‑feu Windows. Si un antivirus tiers désactive ou remplace ce pare‑feu, PacketHound ne peut plus appliquer ses règles. De plus, la première connexion d’un installateur peut être bloquée avant que l’utilisateur n’ait la possibilité de répondre, ce qui nécessite parfois de relancer l’installation après avoir temporairement désactivé la protection.

Le modèle « ask‑first » repose sur l’intervention de l’utilisateur ; des décisions erronées (autoriser un processus inconnu) peuvent rétablir un vecteur d’attaque. Le logiciel ne fournit pas de mécanisme de classification automatisée des processus, ce qui place la charge de décision entièrement sur l’opérateur.