Intune : configurer le pare-feu Windows Defender via Endpoint Security

Le pare-feu Windows Defender est la première ligne de défense de chaque poste Windows contre les connexions réseau non autorisées, les mouvements latéraux et les communications malveillantes sortantes. Pourtant, dans de nombreuses entreprises, sa configuration reste incohérente d'un poste à l'autre : règles héritées jamais nettoyées, profils Public et Private confondus, journaux de flux désactivés. Microsoft Intune, via son module Endpoint Security, offre une approche radicalement différente : déployer des politiques de pare-feu centralisées dans le cloud, sans GPO Active Directory, avec une visibilité en temps réel sur la conformité de chaque appareil. Ce tutoriel complet vous guide depuis la création d'un profil pare-feu dans Intune jusqu'au monitoring avancé, en passant par la configuration des règles entrantes et sortantes, la gestion des exceptions pour vos applications métier et l'intégration avec Microsoft Defender for Endpoint pour une défense en profondeur. Que votre parc soit totalement cloud-native ou hybride, vous disposerez à l'issue de ce guide d'une stratégie de pare-feu cohérente, auditée et alignée avec les bonnes pratiques Zero Trust 2026.

Comprendre l'architecture du pare-feu Windows Defender en entreprise

Avant de configurer quoi que ce soit dans Intune, il est utile de rappeler comment le pare-feu Windows Defender fonctionne en profondeur, et pourquoi il reste pertinent même dans des environnements disposant d'un firewall réseau périmétrique.

Pare-feu distribué vs pare-feu périmétrique

Un firewall réseau (Fortinet, Palo Alto, Cisco ASA) protège le périmètre de l'entreprise. Mais il est aveugle au trafic interne : un poste compromis qui communique avec un autre poste sur le même segment réseau ne passe pas par le firewall périmétrique. Le pare-feu Windows Defender, déployé sur chaque endpoint, crée un firewall distribué qui protège chaque machine individuellement, y compris contre les mouvements latéraux internes — une menace centrale dans les attaques ransomware modernes.

Intégration avec Windows Filtering Platform (WFP)

Le pare-feu Windows Defender s'appuie sur la Windows Filtering Platform (WFP), un framework kernel qui inspecte et filtre le trafic réseau à très bas niveau. Cette architecture permet au pare-feu de fonctionner indépendamment des applications et d'être pratiquement impossible à contourner par un malware s'exécutant en espace utilisateur (sans droits kernel). Les solutions tierces (Defender for Endpoint, antivirus EDR) utilisent également WFP pour leurs propres règles de filtrage réseau.

Règles intégrées Windows et règles administrateur

Windows inclut des centaines de règles de pare-feu prédéfinies pour les services système (DHCP, DNS, NTP, Windows Update, RPC). Vos règles Intune s'ajoutent à ces règles intégrées — elles ne les remplacent pas. La politique Intune peut cependant bloquer toutes les règles locales (règles créées par les utilisateurs ou les logiciels installés localement) en activant le paramètre "Apply local firewall rules" sur Disabled. Dans les environnements à haute sécurité, cette option garantit que seules les règles définies centralement par l'équipe IT sont appliquées.

Préparation et audit du pare-feu existant avant migration vers Intune

Avant de déployer vos politiques Intune pare-feu, un audit de l'état actuel des règles sur les postes existants évite les mauvaises surprises. Voici comment inventorier l'existant rapidement.

Exporter les règles pare-feu locales via PowerShell

Sur un poste représentatif, exportez toutes les règles actives :

# Exporter toutes les règles activées dans un CSV pour analyse
Get-NetFirewallRule | Where-Object {$_.Enabled -eq "True"} |
  Select-Object DisplayName, Direction, Action, Profile, @{
    Name='Protocol';Expression={(Get-NetFirewallPortFilter -AssociatedNetFirewallRule $_).Protocol}
  }, @{
    Name='LocalPort';Expression={(Get-NetFirewallPortFilter -AssociatedNetFirewallRule $_).LocalPort}
  } |
  Export-Csv C:\temp\firewall-rules-audit.csv -Encoding UTF8 -NoTypeInformation

Identifier les règles créées par les applications

Filtrez les règles dont le propriétaire est une application tierce (non-Windows) :

Get-NetFirewallRule | Where-Object {
  $_.Enabled -eq "True" -and
  $_.PolicyStoreSourceType -eq "Local" -and
  $_.DisplayGroup -notlike "Windows*" -and
  $_.DisplayGroup -notlike "Core*"
} | Select-Object DisplayName, DisplayGroup, Action | Sort-Object DisplayGroup

Ces règles locales créées par les applications sont celles que vous devrez soit recreer dans Intune (si elles sont légitimes), soit laisser gérer par l'application elle-même (si vous autorisez les règles locales d'application dans votre politique Intune).

Utiliser Group Policy Analytics pour la migration

Si vous migrez depuis des GPO existantes, le module Group Policy Analytics dans Intune (Devices → Group Policy Analytics) analyse vos GPO exportées et identifie les paramètres pare-feu qui peuvent être convertis directement en politiques MDM. L'outil génère un rapport de compatibilité indiquant le pourcentage de paramètres GPO migrables vers Intune — en général 80 à 90% pour les paramètres pare-feu standard.

Sécuriser le profil Public — Bonnes pratiques pour les postes nomades

Les postes nomades (commerciaux, dirigeants, télétravailleurs) sont régulièrement connectés à des réseaux publics non maîtrisés. Le profil Public du pare-feu Windows Defender est la dernière ligne de défense dans ces situations.

Paramètres recommandés pour le profil Public

En complément des paramètres mentionnés précédemment, voici les configurations avancées à activer via Intune pour le profil Public :

• Block all incoming connections : True — aucune exception, même pour les services normalement autorisés en profil Domain
• Disable unicast response to multicast broadcasts : True — empêche la découverte de la machine sur le réseau local
• Auth apps allow : None — ne pas permettre aux applications de s'auto-autoriser en profil Public
• Global ports allow merge : Disabled — ne pas fusionner les règles locales avec les règles de politique en Public

Combinaison avec Always On VPN

Pour les organisations utilisant Always On VPN (via Intune + RRAS ou une solution tierce), les postes mobiles se connectent automatiquement au VPN d'entreprise dès détection d'un réseau non-Domain. En combinant Always On VPN avec un profil Public très restrictif, les postes bénéficient d'une protection maximale hors réseau d'entreprise : le VPN chiffre le trafic, le pare-feu Public bloque les connexions entrantes, et Network Protection de Defender bloque les destinations malveillantes sortantes.

Intune Endpoint Security vs GPO — avantages et différences fondamentales

Avant Microsoft Intune, la gestion centralisée du pare-feu Windows reposait exclusivement sur les stratégies de groupe (GPO) déployées via Active Directory. Cette approche reste valide dans des environnements 100% on-premise, mais elle présente des limites structurelles dans le contexte actuel.

Limites des GPO pour le pare-feu

• Dépendance réseau : les GPO ne s'appliquent que lorsque l'appareil est sur le réseau d'entreprise ou connecté via VPN. Un poste en télétravail sans VPN ne reçoit pas les nouvelles règles.
• Latence de déploiement : les mises à jour de GPO peuvent prendre jusqu'à 90 minutes + intervalle aléatoire pour se propager sur tous les postes.
• Visibilité limitée : impossible de savoir en temps réel depuis la console AD combien de postes ont appliqué une règle pare-feu spécifique.
• Complexité de gestion : les GPO héritées s'accumulent, créant des conflits de règles difficiles à diagnostiquer.

Avantages d'Intune Endpoint Security Firewall

• Déploiement cloud-first : les règles atteignent les postes via le canal MDM dès que l'appareil est connecté à internet, sans VPN.
• Convergence des politiques : toutes les règles pare-feu sont visibles dans une console unique, avec un historique de version.
• Ciblage par groupe dynamique Entra ID : appliquez des règles différentes selon le département, le rôle, la localisation — les groupes dynamiques Entra ID se mettent à jour automatiquement.
• Rapports de conformité intégrés : tableau de bord indiquant quels appareils ont appliqué les règles avec succès.
• Intégration Defender for Endpoint : les événements pare-feu remontent dans le portail Defender pour une analyse corrélée avec d'autres signaux de menace.

Créer un profil Endpoint Security Firewall dans Intune

Connectez-vous sur intune.microsoft.com avec un compte Global Administrator ou Security Administrator.

Navigation vers le module pare-feu

1. Dans le menu gauche : Endpoint Security
2. Sélectionnez Firewall
3. Cliquez sur + Create Policy
4. Choisissez Platform : Windows 10, Windows 11, and Windows Server
5. Choisissez Profile : Microsoft Defender Firewall
6. Nommez la politique : ex. Firewall-Baseline-AllDevices

Deux types de profils disponibles

• Microsoft Defender Firewall : configure les paramètres globaux du pare-feu (activation par profil, logging, comportement par défaut).
• Microsoft Defender Firewall Rules : définit des règles individuelles entrantes/sortantes. Ce profil peut être créé séparément et combiné avec le premier.

Configurer les paramètres généraux — Profils Domain, Private et Public

Windows Defender Firewall distingue trois profils réseau, chacun activable indépendamment :

Profil Domain (Domaine)

S'applique quand l'appareil est connecté à un réseau où un contrôleur de domaine Active Directory est détecté. Sur les postes Entra ID-only (sans AD), ce profil peut ne jamais s'activer. Paramètres recommandés :

• Firewall enabled : True
• Inbound connections default action : Block (bloquer toutes les connexions entrantes non explicitement autorisées)
• Outbound connections default action : Allow (permissif par défaut, affiner avec des règles sortantes spécifiques)
• Stealth mode : Enabled (ne pas répondre aux requêtes ICMP non sollicitées)

Profil Private (Privé)

S'applique sur les réseaux marqués comme "privés" par l'utilisateur ou la politique (réseau domicile, réseau d'entreprise sans contrôleur de domaine). Mêmes paramètres que Domain, avec une politique entrante bloquante.

Profil Public

Le profil le plus restrictif, appliqué sur les réseaux inconnus (Wi-Fi hôtel, borne publique). Configuration recommandée :

• Firewall enabled : True
• Inbound connections : Block all (zéro exception)
• Outbound connections : Allow (nécessaire pour la navigation web et les mises à jour)
• Disable notifications : False (notifier l'utilisateur si une application est bloquée)

Configuration du logging

Activez le logging pour faciliter le dépannage et l'audit :

• Log file path : %systemroot%\system32\LogFiles\Firewall\pfirewall.log
• Log file size limit : 4096 KB (augmentez à 32768 KB en environnement haute sécurité)
• Log dropped packets : Yes
• Log successful connections : Yes (optionnel, génère du volume)

Créer des règles de pare-feu entrantes et sortantes

Les règles individuelles se créent via le profil Microsoft Defender Firewall Rules. Chaque règle peut cibler un port, un protocole, un programme ou une combinaison.

Créer un profil de règles

1. Endpoint Security → Firewall → + Create Policy
2. Platform : Windows 10, Windows 11, and Windows Server
3. Profile : Microsoft Defender Firewall Rules
4. Dans Configuration settings → + Add, ajoutez vos règles

Structure d'une règle

Chaque règle est définie par :

• Name : nom descriptif (ex. "Allow-RDP-Internal-Only")
• Direction : Inbound ou Outbound
• Action : Allow ou Block
• Protocol : TCP, UDP, ICMPv4, ICMPv6, Any
• Local ports : numéros de ports (ex. "3389", "443,80", "1024-65535")
• Remote address ranges : plages IP sources/destinations (ex. "192.168.1.0/24")
• Application : chemin vers l'exécutable (ex. %ProgramFiles%\MonApp\monapp.exe)
• Profile : Domain, Private, Public (ou une combinaison)
• Enabled : True/False

Exemples de règles communes

Bloquer SMBv1 (port 445 entrant depuis internet) :

• Direction : Inbound, Action : Block, Protocol : TCP, Local port : 445, Profile : Public

Autoriser le bureau à distance uniquement depuis le réseau interne :

• Direction : Inbound, Action : Allow, Protocol : TCP, Local port : 3389, Remote address : 192.168.0.0/16 (adaptez à votre plage), Profile : Domain, Private

Bloquer DNS sortant sauf vers vos serveurs DNS :

• Direction : Outbound, Action : Block, Protocol : UDP, Remote port : 53, Remote address : Any sauf votre IP DNS
• Direction : Outbound, Action : Allow, Protocol : UDP, Remote port : 53, Remote address : 8.8.8.8, 1.1.1.1 (ou vos DNS internes)

Déployer sur des groupes de périphériques via Entra ID

L'affectation des politiques pare-feu à des groupes Entra ID est l'étape cruciale pour un déploiement ciblé et progressif.

Créer des groupes dynamiques Entra ID

Dans le portail Entra ID (entra.microsoft.com) → Groups → + New group :

• Group type : Security
• Membership type : Dynamic Device
• Dynamic query : par exemple (device.operatingSystem -eq "Windows") and (device.deviceOwnership -eq "Company") pour cibler tous les postes Windows d'entreprise.

D'autres exemples de requêtes dynamiques utiles :

• Postes Windows 11 uniquement : device.operatingSystemVersion -startsWith "10.0.22"
• Par département (si l'attribut extensionAttribute1 est renseigné) : device.extensionAttribute1 -eq "Finance"
• Par tag Intune (scope tag) : utilisez les groupes d'affectation Intune directement

Stratégie de déploiement progressif

1. Phase pilote (J1-J7) : déployez sur un groupe de 20-50 machines avec des utilisateurs volontaires ou l'équipe IT.
2. Phase élargie (J8-J21) : étendez à 20% du parc, surveillez les tickets helpdesk liés au pare-feu.
3. Déploiement complet (J22+) : affectez au groupe All Devices ou à votre groupe principal.

Exceptions et règles pour les applications d'entreprise

Les applications métier (ERP, outils IT, agents de monitoring) nécessitent souvent des exceptions pare-feu spécifiques. Voici comment les gérer proprement via Intune.

Exceptions par programme (chemin d'exécutable)

Pour un agent de monitoring comme Zabbix Agent, créez une règle :

• Name : "Allow-ZabbixAgent-Inbound"
• Direction : Inbound
• Action : Allow
• Application : %ProgramFiles%\Zabbix Agent 2\zabbix_agent2.exe
• Protocol : TCP
• Local port : 10050
• Remote address : IP de votre serveur Zabbix

Exceptions pour les applications Microsoft 365

Microsoft publie et maintient la liste des ports et URL nécessaires pour Microsoft 365. Pour les applications Teams, SharePoint, Exchange Online, créez des règles sortantes autorisant les plages IP Microsoft (publiées via endpoints.office.com). En pratique, comme la politique par défaut sortante est "Allow", les règles sortantes Microsoft 365 ne sont nécessaires que si vous avez durci la politique sortante en mode "Block by default".

Gestion des conflits de règles

Quand plusieurs politiques Intune définissent des règles pare-feu sur le même appareil, les règles s'accumulent (les règles d'autorisation de toutes les politiques s'appliquent). En cas de conflit entre une règle "Allow" d'une politique et une règle "Block" d'une autre sur le même trafic, la règle "Block" l'emporte. Documentez soigneusement vos règles et auditez régulièrement les appareils avec netsh advfirewall show allprofiles.

Monitoring et rapports — Surveiller la conformité pare-feu

Une politique sans monitoring est une politique sans garantie. Intune fournit plusieurs vues pour suivre l'état de votre pare-feu.

Device status dans Intune

Pour chaque politique Endpoint Security Firewall :

1. Naviguez vers Endpoint Security → Firewall → votre politique
2. Onglet Device status : liste tous les appareils avec statut (Succeeded / Error / Conflict / Not applicable)
3. Cliquez sur un appareil en erreur → Per-setting status pour voir quel paramètre spécifique pose problème

Rapports de conformité

Dans Intune → Reports → Endpoint Security → Firewall status, vous obtenez un rapport agrégé indiquant le pourcentage d'appareils avec pare-feu actif sur chaque profil réseau. Ce rapport est exportable en CSV pour vos audits.

Integration avec Azure Monitor

Pour une rétention longue durée et une analyse avancée, activez l'export des logs Intune vers Azure Monitor :

1. Intune → Tenant administration → Diagnostic settings
2. Activez les catégories : DeviceComplianceOrg, Audit
3. Destination : Log Analytics workspace ou Event Hub vers votre SIEM

Combiner Intune Firewall avec Defender for Endpoint pour une défense en profondeur

Le pare-feu Windows géré par Intune et Microsoft Defender for Endpoint (MDE) sont complémentaires et s'intègrent naturellement dans Microsoft 365 Defender.

Attack Surface Reduction (ASR) Rules

MDE inclut des règles de réduction de la surface d'attaque qui complètent le pare-feu : blocage des macros Office malveillantes, protection des processus système, blocage des exécutables non signés depuis des dossiers temporaires. Ces règles s'activent également via Intune Endpoint Security → Attack surface reduction.

Network Protection

La fonctionnalité Network Protection de Defender for Endpoint étend la protection pare-feu en bloquant les connexions sortantes vers des domaines et IP malveillants connus (phishing, C2 de malwares, exploits connus). Activez-la via Intune → Endpoint Security → Attack surface reduction → Network protection : Enable.

Corrélation des événements dans Microsoft 365 Defender

Quand un poste tente de se connecter à un C2 connu et que le pare-feu bloque la connexion, l'événement remonte dans le portail security.microsoft.com et peut déclencher une alerte corrélée avec d'autres indicateurs (processus suspect ayant initié la connexion, hash de fichier malveillant). Cette corrélation n'est possible que si MDE est déployé sur les postes — ce qui est recommandé pour tout environnement Microsoft 365 E3 ou E5.

Pour une protection complémentaire des identités, combinez avec notre guide sur l'activation de BitLocker via Intune et consultez nos services de pentest Active Directory pour valider l'efficacité de votre défense en profondeur.

FAQ — Intune et le pare-feu Windows Defender

Peut-on migrer les règles pare-feu existantes des GPO vers Intune sans tout reconfigurer manuellement ?

Oui, partiellement. Microsoft a publié des outils de migration GPO vers Intune (Group Policy Analytics dans le portail Intune). Naviguez vers Devices → Group Policy Analytics → Analyze et importez vos fichiers GPO exportés. L'outil analyse les paramètres et indique ceux qui peuvent être migrés directement vers une politique MDM. Pour les règles pare-feu complexes, un export PowerShell des règles locales (Get-NetFirewallRule | Export-CliXml) peut aider à inventorier l'existant avant la migration.

Comment gérer les appareils qui utilisent à la fois des GPO et Intune pour le pare-feu ?

Sur les appareils hybrides joints à la fois à AD et Entra ID, les GPO et les politiques MDM coexistent. Pour le pare-feu, les règles des deux sources s'additionnent. En cas de conflit sur un paramètre global (activation du pare-feu, comportement par défaut), les GPO ont historiquement la priorité sur MDM. Pour éviter les conflits, configurez les GPO existantes en mode "Not configured" pour les paramètres gérés par Intune, ou utilisez MDMWinsOverGP (une clé de registre Microsoft qui donne la priorité à MDM sur GPO).

Les règles pare-feu Intune s'appliquent-elles pendant le démarrage avant la connexion utilisateur ?

Oui. Les règles pare-feu configurées via MDM/Intune sont appliquées au niveau système et actives dès le démarrage de Windows, avant l'ouverture de session utilisateur. C'est un avantage clé par rapport aux scripts de logon qui n'agissent qu'après authentification.

Comment savoir si le pare-feu Windows bloque une application sans désactiver le pare-feu ?

Activez le logging du pare-feu (paramètre Log dropped packets) et consultez le fichier log dans %systemroot%\system32\LogFiles\Firewall\pfirewall.log. Recherchez les entrées "DROP" avec l'adresse IP et le port de destination de l'application bloquée. Vous pouvez également utiliser la commande PowerShell Get-NetFirewallProfile | Select-Object Name,LogFileName,LogBlocked pour vérifier la configuration de logging active.

Est-il possible de bloquer complètement toutes les connexions sortantes sauf une liste blanche via Intune ?

Oui, mais c'est une approche qui demande une planification rigoureuse. Changez la politique sortante par défaut à "Block" pour les profils Public et Private, puis créez des règles "Allow" explicites pour chaque application et destination nécessaire. Commencez par mapper tous les flux sortants légitimes (HTTPS 443, DNS 53, Windows Update, Microsoft 365, votre VPN) avant d'activer le blocage par défaut. Une approche progressive par groupe d'appareils pilotes est indispensable pour éviter de bloquer les opérations critiques.