Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Que peut-on faire pour réactiver correctement le Pare-feu Windows sur un domaine ?

ayi

<h2><a name="p-33215-contexterecherche-1" class="anchor" href="#p-33215-contexterecherche-1" aria-label="Heading link"></a>CONTEXTE/RECHERCHE</h2>
Je crois sincèrement que des questions comme celle-ci : <a href="https://serverfault.com/questions/102395/using-gpo-in-active-directory-domain-to-force-workstations-windows-firewall-to-d" rel="noopener nofollow ugc">Using GPO in Active Directory domain to force workstations Windows Firewall to disabled - how?</a> existaient parce que les administrateurs Windows en général ont appris il y a longtemps que :
<blockquote></blockquote>
« la chose la plus simple à faire avec un ordinateur de domaine est simplement d’avoir une GPO sur le domaine pour désactiver le Pare-feu Windows… cela vous causera beaucoup moins de maux de tête au final. » - divers formateurs/mentors informatiques d’antan
Je peux aussi affirmer que dans LA PLUPART des entreprises pour lesquelles j’ai fait du travail en complément, c’était le cas, où une GPO au minimum désactivait le Pare-feu Windows pour le profil de domaine et au PIRE le désactivait aussi pour le profil public.
De plus, certains vont le désactiver pour les serveurs eux-mêmes : <a href="https://serverfault.com/questions/491771/disable-firewall-for-all-network-profiles-on-windows-server-2008-r2-through-gpo?rq=1" rel="noopener nofollow ugc">Disable firewall for all network profiles on Windows Server 2008 R2 through GPO</a>
Un <a href="http://technet.microsoft.com/en-us/library/cc766337%28v=ws.10%29.aspx" rel="noopener nofollow ugc">article Microsoft Technet sur le PARE-FEU WINDOWS</a> recommande de NE PAS désactiver le Pare-feu Windows :
<blockquote></blockquote>
Parce que le Pare-feu Windows avec sécurité avancée joue un rôle important pour aider à protéger votre ordinateur contre les menaces de sécurité, nous recommandons de ne pas le désactiver à moins que vous n’installiez un autre pare-feu d’un éditeur réputé qui fournit un niveau de protection équivalent.
Cette question ServerFault pose la vraie question : <a href="https://serverfault.com/questions/317166/is-it-alright-to-turn-off-firewall-in-a-lan-using-group-policy" rel="noopener nofollow ugc">Is it alright to turn off firewall in a LAN using Group Policy?</a> – et les experts ici sont même partagés dans leur avis.
Et comprenez bien que je ne parle pas de désactiver/activer le SERVICE : <a href="https://serverfault.com/questions/520509/how-can-i-back-up-my-recommendation-to-not-disable-the-windows-firewall-service" rel="noopener nofollow ugc">How can I back up my recommendation to NOT disable the Windows Firewall service?</a> – pour être clair, il s’agit de savoir si le service de pare-feu active ou désactive le pare-feu.
<h2><a name="p-33215-la-question-en-question-2" class="anchor" href="#p-33215-la-question-en-question-2" aria-label="Heading link"></a>LA QUESTION EN QUESTION</h2>
Je reviens donc au titre de cette question… que peut-on faire pour réactiver correctement le pare-feu Windows sur un domaine ? Plus précisément pour les stations de travail clientes et leur profil de domaine.
Avant de simplement basculer la GPO de Désactivé à Activé, quelles étapes de planification doivent être prises pour s’assurer que l’activation du commutateur ne provoque pas la défaillance soudaine d’applications client/serveur critiques, de trafic autorisé, etc. ? La plupart des environnements ne toléreront pas la mentalité « faites le changement et voyez qui appelle le support ».
Existe-t-il des listes de contrôle/utilitaires/procédures disponibles chez Microsoft pour gérer une telle situation ? Avez-vous déjà été dans cette situation vous-même et comment l’avez-vous gérée ?
<hr>
Source : <a href="https://serverfault.com/questions/102395/using-gpo-in-active-directory-domain-to-force-workstations-windows-firewall-to-d" rel="noopener nofollow ugc">Server Fault</a>

ayi_2

<code>Que peut-on faire pour réactiver correctement le pare-feu Windows sur un domaine ?</code>
Eh bien, la réponse courte est que cela va représenter beaucoup de travail si vous décidez d’aller de l’avant, et pour mémoire, je ne suis pas sûr que je le ferais.
Dans le cas général, les pare-feu clients ne fournissent pas beaucoup de sécurité dans un réseau d’entreprise (qui a typiquement des pare-feu matériels et contrôle ce type de choses à la périphérie), et les auteurs de malwares de nos jours sont assez malins pour utiliser le port 80 pour leur trafic, car pratiquement personne ne bloque ce port, donc vous investissez beaucoup d’efforts pour mettre en place quelque chose qui fournit un bénéfice de sécurité limité.
Cela dit, la réponse longue est :
<ul>
<li>
Inventoriez les applications et leurs besoins de connectivité aussi bien que possible.
</li>
<li>
Si vous pouvez activer le Pare-feu Windows en toute sécurité avec une règle <code>autoriser tout</code> et activer la journalisation, ce sera un trésor de données pour déterminer quelles applications nécessitent des exceptions de pare-feu.
</li>
<li>
Si vous ne pouvez pas collecter les données de journalisation de manière non intrusive, vous devrez vous contenter d’un inventaire simple, ou effectuer votre journalisation sur des utilisateurs qui peuvent supporter les perturbations et l’activité informatique intrusive (comme vous-même et d’autres techniciens, par exemple).
</li>
<li>
Réfléchissez à vos besoins de dépannage.
</li>
<li>
Il y a des choses qui ne ressortiront probablement pas lors d’un audit logiciel auxquelles vous devez penser. Par exemple :
</li>
<li>
Vous voudrez peut-être autoriser l’ICMP (ou l’ICMP depuis des espaces d’adresses approuvés) pour que le dépannage et la gestion des adresses IP ne soient pas horribles.
</li>
<li>
De même, des exceptions pour les applications de gestion à distance que vous utilisez.
</li>
<li>
Vous voudrez aussi probablement configurer la journalisation du pare-feu par stratégie
</li>
<li>
Créez une GPO de référence et déployez-la sur un groupe de test, ou plusieurs groupes de test.
</li>
<li>
Bien que vous ne puissiez pas simplement le faire et laisser le support technique gérer pour tout le monde, la direction sera beaucoup plus ouverte à un pilotage des changements avec un groupe restreint d’employés triés sur le volet, surtout s’ils pensent qu’il y a une préoccupation de sécurité valide.
</li>
<li>
Choisissez soigneusement votre groupe de test. Il pourrait être judicieux d’utiliser d’abord le personnel informatique, puis d’élargir le groupe pour inclure des personnes d’autres départements.
</li>
<li>
Évidemment, surveillez votre groupe de test et restez en communication constante avec eux pour résoudre rapidement les problèmes que vous n’avez pas détectés au premier passage.
</li>
<li>
Déployez le changement lentement et par étapes.
</li>
<li>
Une fois que vous l’avez testé à votre satisfaction, vous devriez toujours faire preuve de prudence et ne pas le déployer à tout le domaine en une seule fois. Déployez-le à des groupes plus petits, que vous devrez définir en fonction de la structure et des besoins de votre organisation.
</li>
<li>
Assurez-vous d’avoir quelque chose en place pour gérer les changements futurs.
</li>
<li>
Faire en sorte que cela fonctionne pour ce que vous avez dans votre environnement actuellement ne sera pas suffisant, car vous aurez de nouvelles applications sur votre domaine, et vous devrez vous assurer que la stratégie de pare-feu est mise à jour pour les accommoder, sinon quelqu’un au-dessus de vous décidera que le pare-feu est plus de problèmes qu’il n’en vaut la peine et fera retirer la stratégie, éliminant tout le travail que vous avez investi jusqu’à présent.
</li>
</ul>