Pare-feu basé sur l’hôte et autorisation sélective des applications

Un pare-feu réseau se situe à la périphérie et filtre le trafic entre les segments réseau. Un pare-feu basé sur l’hôte s’exécute sur le point de terminaison individuel et filtre le trafic entrant et sortant de cette machine précise. Les pare-feu basés sur l’hôte fournissent une défense en profondeur : même si un attaquant contourne le pare-feu réseau (via un VPN, un initié compromis ou un déplacement latéral depuis un autre hôte infecté), le pare-feu de l’hôte applique les règles locales de trafic. Ils sont particulièrement importants pour les ordinateurs portables qui sortent du périmètre de l’entreprise et se connectent à des réseaux non fiables.

Windows Defender Firewall (WDF) est le pare-feu intégré basé sur l’hôte de toutes les versions modernes de Windows. Il prend en charge trois profils : Domain (connecté au domaine de l’entreprise — généralement plus permissif), Private (réseau domestique fiable) et Public (réseaux non fiables — le plus restrictif). Les règles WDF peuvent filtrer selon le port, le protocole, le chemin de l’application, l’IP distante et l’identité de l’utilisateur. Le composant logiciel enfichable MMC Windows Defender Firewall with Advanced Security (WFAS) et la stratégie de groupe permettent de gérer de manière centralisée les règles du pare-feu sur tous les ordinateurs joints au domaine.

Les pare-feu basés sur l’hôte sous Linux utilisent le framework du noyau Netfilter, configurable avec iptables (ancienne solution, toujours largement utilisée) ou avec le moderne nftables. Les règles sont organisées en chaînes (INPUT, OUTPUT, FORWARD) au sein de tables (filter, nat, mangle). La stratégie par défaut doit être DROP, avec des règles ACCEPT explicites pour le trafic nécessaire : c’est le principe du refus par défaut. Des outils de niveau supérieur comme ufw (Ubuntu) et firewalld (RHEL/CentOS) fournissent des interfaces plus conviviales tout en utilisant Netfilter en arrière-plan.

Les pare-feu basés sur l’hôte peuvent appliquer des règles au niveau applicatif : ils filtrent le trafic selon l’application qui l’a généré, et pas seulement selon le port. Windows Defender Firewall prend en charge les règles basées sur les applications : autoriser C:\Program Files\MyApp\app.exe à établir des connexions sortantes tout en bloquant tout le reste sur le même port. Cela empêche les logiciels malveillants de détourner des ports autorisés en se faisant passer pour une application fiable. Les règles au niveau applicatif sont nettement plus efficaces que les règles fondées uniquement sur les ports, qui peuvent être contournées en liant un logiciel malveillant à des ports courants comme 443.

L’Allowlisting des applications (anciennement appelé Whitelisting) est un contrôle de sécurité qui autorise uniquement l’exécution des applications explicitement approuvées sur un point de terminaison. Tout exécutable qui ne figure pas sur la liste d’autorisation est bloqué, qu’il s’agisse d’un logiciel malveillant ou simplement d’un logiciel non approuvé. Il s’agit d’une défense efficace contre les logiciels malveillants, car même les logiciels malveillants inédits de type zero-day sont bloqués s’ils ne figurent pas sur la liste approuvée. La difficulté est opérationnelle : gérer la liste d’autorisation dans des environnements vastes et dynamiques nécessite un processus mature de gestion des changements et génère de nombreux tickets d’assistance s’il est mal ajusté.

AppLocker est la fonctionnalité de contrôle des applications intégrée à Windows, disponible dans les éditions Enterprise et Education. Elle filtre l’exécution selon : le chemin (bloquer les exécutables provenant de %TEMP% ou de répertoires accessibles en écriture par les utilisateurs), le hachage du fichier (n’autoriser que les hachages connus comme fiables) ou le publisher (autoriser les logiciels signés par Microsoft ou Adobe). Les politiques AppLocker sont déployées via la stratégie de groupe et consignées dans le journal des événements Windows (ID d’événement 8003 = bloqué). Exécuter d’abord AppLocker en Audit Mode — en consignant les blocages sans les appliquer — permet aux équipes d’ajuster la liste d’autorisation avant de commencer l’application.

WDAC est le successeur plus puissant d’AppLocker, appliqué au niveau du noyau plutôt que dans l’espace utilisateur. Contrairement à AppLocker, WDAC ne peut pas être contourné par des attaquants disposant de droits d’administrateur local, ce qui en fait le contrôle privilégié dans les environnements hautement sécurisés. Les politiques WDAC sont écrites en XML, puis converties en fichiers de politique binaires déployés via MDM (Intune) ou la stratégie de groupe. WDAC permet également l’intégration à Intelligent Security Graph (ISG), qui utilise le service de réputation cloud de Microsoft pour autoriser automatiquement les logiciels dont la réputation est fiable, réduisant ainsi la charge opérationnelle liée à la sélection manuelle des éléments de la liste d’autorisation.

L’Allowlisting est efficace, mais exigeant sur le plan opérationnel. Difficultés courantes : les LOLBins (binaires Living-Off-the-Land) — les attaquants utilisent des outils système Windows comme PowerShell, wscript.exe et mshta.exe, qui figurent généralement sur toutes les listes d’autorisation ; l’Allowlisting doit donc restreindre la manière dont ces outils sont invoqués, et pas seulement déterminer s’ils peuvent s’exécuter. Les langages de script (PowerShell, Python) sont souvent autorisés, mais peuvent exécuter du code malveillant. Les faux positifs — des logiciels légitimes bloqués par la liste d’autorisation — génèrent des tickets au support et une pression visant à affaiblir les contrôles. Les programmes d’Allowlisting matures traitent les LOLBins au moyen de politiques supplémentaires de mode de langage restreint.

L’Allowlisting autorise uniquement les éléments explicitement approuvés et bloque tout le reste : la posture de sécurité est plus forte. Le Denylisting (blacklisting) bloque les éléments explicitement identifiés comme malveillants et autorise tout le reste : c’est le modèle antivirus traditionnel. Le Denylisting échoue face aux menaces inconnues ; l’Allowlisting échoue face aux LOLBins et aux entrées d’autorisation trop larges. La plupart des programmes de sécurité matures utilisent l’Allowlisting comme contrôle principal pour les systèmes critiques, tout en utilisant la détection comportementale (EDR) pour repérer l’utilisation abusive d’applications autorisées. Pour les systèmes moins critiques, une liste de refus bien ajustée avec une surveillance comportementale peut être acceptable.

Les pare-feu basés sur l’hôte et l’Allowlisting des applications sont des contrôles complémentaires et en couches. La liste d’autorisation empêche l’exécution de code non autorisé ; le pare-feu empêche les connexions réseau non autorisées établies par du code autorisé, mais compromis. Ensemble, ils mettent en œuvre les principes du moindre privilège aux niveaux applicatif et réseau du point de terminaison. Ajouter EDR comme troisième couche crée une architecture de défense en profondeur dans laquelle chaque contrôle détecte ce que les autres pourraient manquer, augmentant considérablement le coût et la complexité des attaques réussies contre les points de terminaison.

La valeur des pare-feu basés sur l’hôte dépend de la qualité des journaux qu’ils génèrent. Activez la journalisation des connexions bloquées afin de capturer les tentatives d’attaque et les violations de politique. Activez la journalisation des connexions autorisées pour les règles sensibles (par exemple celles qui autorisent les outils d’administration) afin de conserver une piste d’audit. Transférez les journaux du pare-feu vers le SIEM pour permettre la corrélation : une série de connexions sortantes bloquées depuis un même hôte peut indiquer qu’un logiciel malveillant tente d’établir des rappels C2. Sous Windows, les journaux du pare-feu sont écrits par défaut dans %systemroot%\System32\LogFiles\Firewall\pfirewall.log et doivent être transférés via Windows Event Forwarding (WEF) ou un agent de journaux.

Vérifiez votre compréhension des concepts de CompTIA Security+ (SY0-701) présentés dans cette leçon.

Dans cette leçon, vous avez appris que les pare-feu basés sur l’hôte (Windows Defender Firewall, iptables) filtrent le trafic pour chaque point de terminaison avec une stratégie de refus par défaut et des règles limitées aux applications ; que l’Allowlisting des applications (AppLocker, WDAC) bloque l’exécution des exécutables non autorisés, y compris les logiciels malveillants ; et que la combinaison du pare-feu, de l’Allowlisting et d’EDR crée une défense en profondeur qui augmente considérablement le coût d’une attaque. Nous allons maintenant découvrir l’authentification des e-mails : SPF, DKIM et DMARC.