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

RECHERCHE EN ARRIÈRE PLAN

Je crois honnêtement que des questions comme celle-ci: Utilisation de GPO dans le domaine Active Directory pour forcer les postes de travail Pare-feu Windows à désactiver - comment? existe parce que les administrateurs Windows en général ont appris depuis longtemps que:

"la chose la plus simple à faire lorsque vous traitez avec un ordinateur de domaine est d'avoir juste un GPO sur le domaine pour désactiver le pare-feu Windows ... cela vous causera beaucoup moins de chagrin à la fin." - des instructeurs / mentors en TI choisis au hasard depuis des années

Je peux également dire que dans la plupart des entreprises, j'ai effectué un travail parallèle pour cela, où un objet de stratégie de groupe a au minimum désactivé le pare-feu Windows pour le profil de domaine et, au pire, l'a désactivé également pour le profil public.

Encore plus, certains le désactiveront pour les serveurs eux-mêmes: désactivez le pare-feu pour tous les profils réseau sur Windows Server 2008 R2 via GPO

Un article Microsoft Technet sur le PARE-FEU WINDOWS vous recommande de NE PAS désactiver le pare-feu Windows:

Étant donné que le pare-feu Windows avec sécurité avancée joue un rôle important dans la protection de votre ordinateur contre les menaces de sécurité, nous vous recommandons de ne pas le désactiver, sauf si vous installez un autre pare-feu d'un fournisseur réputé qui offre un niveau de protection équivalent.

Cette question ServerFault pose la vraie question: est-il correct de désactiver le pare-feu dans un réseau local à l'aide de la stratégie de groupe? - et les experts ici sont même mitigés dans leur avis.

Et comprenez que je ne parle pas de désactiver / activer le SERVICE: Comment puis-je sauvegarder ma recommandation de ne PAS désactiver le service Pare-feu Windows? - afin de préciser qu'il s'agit de savoir si le service de pare-feu active ou non le pare-feu.

LA QUESTION À LA MAIN

Je reviens donc au titre de cette question ... que peut-on faire pour réactiver correctement le pare-feu Windows sur un domaine? Spécifiquement pour les postes de travail clients et leur profil de domaine.

Avant de simplement passer l'objet de stratégie de groupe de Désactivé à Activé, quelles étapes de planification devez-vous prendre pour vous assurer que le basculement du commutateur n'entraîne pas l'échec soudain des applications client / serveur critiques, du trafic autorisé, etc. La plupart des endroits ne toléreront pas l'état d'esprit "changez-le et voyez qui appelle le Helpdesk" ici.

Existe-t-il des listes de contrôle / utilitaires / procédures disponibles auprès de Microsoft pour gérer une telle situation? Avez-vous été vous-même dans cette situation et comment l'avez-vous gérée?

What can be done to properly re-enable the Windows firewall on a domain?

Eh bien, la réponse courte est que ça va être beaucoup de travail si vous décidez d'aller de l'avant, et pour le compte rendu, je ne suis pas sûr que je le ferais.

Dans le cas général, les pare-feu clients n'offrent pas beaucoup de sécurité dans un réseau d'entreprise (qui a généralement des pare-feu matériels et contrôle ce type de chose à la périphérie), et les auteurs de logiciels malveillants de nos jours sont assez intelligents pour utiliser le port 80 pour leur trafic, parce que pratiquement personne ne bloque ce port, vous obtenez donc beaucoup d'efforts pour mettre quelque chose en place pour une sécurité limitée.

Cela dit, la longue réponse est:

1. Inventoriez les applications et leurs besoins de connectivité du mieux que vous le pouvez.
   • Si vous pouvez activer en toute sécurité le pare-feu Windows avec une allow allrègle et définir la journalisation, ce sera un trésor de données pour déterminer les applications dont vous disposez qui nécessitent des excusions de pare-feu.
   • Si vous ne pouvez pas collecter les données de journalisation de manière non intrusive, vous devrez vous contenter d'un simple inventaire ou vous connecter aux utilisateurs qui peuvent gérer les perturbations et les activités informatiques intrusives (comme vous et d'autres techniciens, par exemple).
2. Pensez à vos besoins de dépannage.
   • Il y a des choses qui ne se présenteront probablement pas dans un audit logiciel auxquelles vous devez penser. Par exemple:
     • Vous souhaiterez peut-être autoriser ICMP (ou ICMP à partir d'espaces d'adressage approuvés) pour que le dépannage et la gestion des adresses IP ne soient pas horribles.
     • De même, des exclusions pour toutes les applications de gestion à distance que vous utilisez.
     • Vous souhaiterez également probablement définir la journalisation du pare-feu par stratégie
3. Créez un GPO de base et déployez-le dans un groupe de test ou plusieurs groupes de test.
   • Bien que vous ne puissiez pas simplement le faire et laisser le helpdesk le régler pour tout le monde, la direction sera beaucoup plus disposée à piloter les changements avec un groupe sélectionné d'employés triés sur le volet, surtout s'ils pensent qu'il existe un problème de sécurité valide. .
   • Choisissez soigneusement votre groupe de test. Il serait peut-être judicieux d'utiliser d'abord l'informatique, puis d'élargir le groupe pour inclure des personnes d'autres départements.
   • De toute évidence, surveillez votre groupe de test et restez en communication constante avec lui pour résoudre rapidement les problèmes que vous n'avez pas détectés la première fois.
4. Déployez le changement lentement et par étapes.
   • Une fois que vous l'avez testé à votre satisfaction, vous devez toujours faire preuve de prudence et ne pas simplement le diffuser à l'ensemble du domaine à la fois. Déployez-le en petits groupes, que vous devrez définir en fonction de la structure et des besoins de votre organisation.
5. Assurez-vous que vous avez quelque chose en place pour gérer les changements futurs.
   • Le faire fonctionner pour ce que vous avez dans votre environnement ne suffira pas maintenant, car vous vous retrouverez avec de nouvelles applications sur votre domaine et vous devrez vous assurer que la politique de pare-feu est mise à jour pour les accueillir, ou quelqu'un au-dessus de vous décidera que le pare-feu est plus problématique que cela en vaut la peine et que la politique sera supprimée, éliminée et le travail que vous y avez investi jusqu'à présent.

Edit: Je voudrais juste dire qu'il n'y a rien de mal en soi avec le pare-feu Windows. Il s'agit d'un élément parfaitement acceptable d'une stratégie globale de défense en profondeur. Le fait est que la plupart des magasins sont trop incompétents ou trop paresseux pour être dérangés pour déterminer quelles règles de pare-feu sont nécessaires pour les applications qu'ils exécutent, et donc ils le forcent de manière omniprésente.

Si le pare-feu Windows, par exemple, empêche vos contrôleurs de domaine de faire leur travail, c'est parce que vous ne saviez pas quels ports Active Directory avait besoin avant d'activer le pare-feu ou parce que vous avez mal configuré la stratégie.

Voilà l'essentiel.

Tout d'abord, communiquez avec vos chefs de projet, vos patrons, vos parties prenantes, votre cabinet de conseil en changement, quel que soit le processus dans votre entreprise, et informez-les tous que vous allez subir une correction progressive impliquant le pare-feu Windows afin d'augmenter le total posture de sécurité de votre environnement.

Assurez-vous qu'ils comprennent qu'il y a des risques. Oui, bien sûr, nous ferons tout ce que nous pouvons, toute la planification que nous pouvons, pour nous assurer qu'il n'y aura pas d'interruptions, mais ne faisons aucune promesse. Essayer de mettre un ancien domaine en forme est un travail difficile.

Ensuite, vous devez répertorier les applications utilisées dans votre environnement et les ports dont elles ont besoin. Selon l'environnement, cela peut être très difficile. Mais cela doit être fait. Agents de surveillance? Agents SCCM? Agents antivirus? La liste continue.

Développez un objet de stratégie de groupe Windows Firewall qui inclut des règles personnalisées pour vos applications d'entreprise. Vous pouvez avoir besoin de plusieurs stratégies avec des étendues différentes qui s'appliquent à différents serveurs. Par exemple, une politique distincte qui s'applique uniquement aux serveurs Web pour les ports 80, 443, etc.

Les stratégies de pare-feu Windows intégrées vous seront très utiles, car elles sont parfaitement adaptées à la plupart des activités Windows courantes. Ces règles intégrées sont meilleures car elles ne se contentent pas d'ouvrir ou de fermer un port à l'ensemble du système - elles sont limitées à des processus et des activités de protocole très spécifiques se déroulant sur la machine, etc. Mais ils ne couvrent pas vos applications personnalisées. , ajoutez donc ces règles aux stratégies en tant qu'ACE auxiliaires.

Déployez d'abord dans un environnement de test si possible, et lors du déploiement en production, faites-le d'abord en morceaux limités. Ne vous contentez pas de déployer le GPO sur l'ensemble du domaine lors de votre première utilisation.

Cette dernière déclaration est probablement le meilleur conseil que je puisse vous donner - déployez vos modifications dans de très petites étendues contrôlées.

D'accord, je suis sur le point de suggérer quelque chose qui peut ou non vous causer des ennuis, mais c'est ce que j'utilise lorsque j'allume le pare-feu.

Nmap. (N'importe quel scanner de port ferait l'affaire.) Je crains de ne pas faire confiance à la documentation des ports utilisés. Je veux voir par moi-même.

Contexte: Je viens d'un environnement universitaire où les ordinateurs portables des étudiants se frottaient les coudes avec nos serveurs (Ugh!). Quand j'ai commencé à utiliser nmap sur mes propres serveurs, nous n'avions pas non plus d'IDS, donc je pouvais nmap à volonté et personne ne le remarquerait. Ensuite, ils ont implémenté IDS et je recevrais des courriels qui m'indiquaient essentiellement: "ATTAQUE DE NUMÉRISATION DE PORT DE RÉSEAU SUR VOTRE SERVEUR DEPUIS VOTRE POSTE DE TRAVAIL !!!!!" et je répondais et disais: "Oui, c'est moi." Il h. Après un certain temps, ils ont développé un sens de l'humour à ce sujet. ;)

J'ai également utilisé nmap sur les postes de travail, par exemple, pour rechercher conficker . Nmap augmenterait probablement les ports de gestion AV, tous les autres ports de logiciel de gestion, etc. (Le bureau sera très difficile si vous cassez leur logiciel de gestion.) Il pourrait également révéler des logiciels non autorisés, selon votre environnement.

En tous cas. Certains environnements vont paniquer à propos de nmap et certains ne le remarqueront même pas. En règle générale, je ne mappe mes propres serveurs ou postes de travail qu'à des fins spécifiques, ce qui est utile. Mais oui, vous voulez probablement préciser que vous allez exécuter une analyse de port avec toute personne qui pourrait vous faire peur.

Alors tu sais. Ce que Ryan Ries a dit. Gestion / gestion du changement / politique de groupe / etc.

Je ne pense pas qu'il existe d'utilitaires disponibles à ce sujet auprès de Microsoft, mais si je devais utiliser le pare-feu Windows sur notre domaine (il est activé là où je travaille), je garantirais ce qui suit:

1. Il existe des exceptions pour tous les outils d'administration à distance (WMI, etc., etc.)
2. Créez des exceptions de plage IP sur les postes de travail de domaine pour autoriser les serveurs administratifs (tels que SCCM / SCOM, si vous en avez) à autoriser tout le trafic.
3. Autorisez les utilisateurs finaux à ajouter des exceptions au profil de domaine uniquement pour les logiciels au cas où vous manqueriez certaines choses (et vous le ferez).

Les serveurs sont un peu une bête différente. J'ai actuellement le pare-feu désactivé pour nos serveurs, car l'activer a causé de nombreux problèmes, même avec des exceptions en place. Vous devez fondamentalement appliquer une politique de "squelette" de couverture pour tous les serveurs (interdire les ports dangereux, par exemple), puis aller sur chaque serveur et personnaliser individuellement les paramètres. Pour cette raison, je peux voir la raison pour laquelle beaucoup de gens de l'informatique désactivent simplement le pare-feu. Votre pare-feu de périmètre doit protéger suffisamment ces machines sans leurs propres pare-feu. Cependant, il vaut parfois la peine de configurer individuellement les serveurs pour les environnements à haute sécurité.

En guise de remarque, le pare-feu Windows régit également l'utilisation d'IPsec, donc si vous l'utilisez, vous avez quand même besoin du pare-feu.