Blog ENI : Toute la veille numérique !
🐠 -25€ dès 75€ 
+ 7 jours d'accès à la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Cybersécurité et PowerShell
  3. Défendre son SI avec PowerShell
Extrait - Cybersécurité et PowerShell De l'attaque à la défense du système d'information
Extraits du livre
Cybersécurité et PowerShell De l'attaque à la défense du système d'information
2 avis
Revenir à la page d'achat du livre

Défendre son SI avec PowerShell

Introduction

Les chapitres précédents ont montré qu’il est possible d’utiliser PowerShell à des fins malveillantes, mais également que sécuriser PowerShell contre ce genre d’attaques est possible. En revanche, nous n’avons pas abordé ce que PowerShell peut offrir pour renforcer la sécurité d’un système d’information. Si pour les administrateurs la maîtrise des usages de PowerShell au sein de son système d’information est indispensable, maîtriser son système d’information l’est tout autant. On notera enfin qu’avec l’arrivée des installations serveur en mode "Core" (à partir de Server 2008), la maîtrise de PowerShell pour l’administration et la sécurisation de ses serveurs n’est plus optionnelle.

Ce chapitre va donc s’attarder sur quelques opérations de durcissement triées sur le volet et que l’on peut réaliser avec l’aide de PowerShell. Comme pour les autres chapitres, l’objectif ici n’est pas de donner une vision exhaustive de la sécurisation d’un SI, mais bien de pointer certains éléments clés ou certaines méthodes pour permettre au lecteur d’entamer ce travail par lui-même dans son propre contexte.

Durcissement

1. RDP : Remote Desktop Protocol

a. Authentification, NLA et gestion des accès

"Utilisez un mot de passe fort". Si cette recommandation peut donner l’impression d’enfoncer une porte ouverte à ce stade de l’ouvrage, elle a pourtant toute sa place ici. Le bruteforce des mots de passe reste une méthode très simple pour accéder de façon illégitime à un serveur RDP.

Partant de ce postulat, mettre en place une authentification forte sur RDP est la suite logique. Le protocole RDP supporte les tokens de type Yubikey (U2F) ou RSA, même si leur mise en œuvre ne nécessite à aucun moment PowerShell. Pour cette raison, cette mise en œuvre ne sera pas détaillée dans cet ouvrage.

En complément d’un bon mot de passe, d’autres configurations permettent de renforcer la sécurité du protocole RDP. Il est par exemple recommandé d’activer NLA (Network Level Authentication) disponible depuis Windows XP SP3. Cette fonction de sécurité de RDP permet d’autoriser la connexion uniquement lorsque le client est déjà authentifié. Avant cette option, la session RDP était établie avant et affichait l’écran de connexion, ce qui permettait d’exploiter d’éventuelles vulnérabilités au niveau du protocole, comme pour la faille « BlueKeep ».

BlueKeep est une faille sur RDP découverte en 2019. Celle-ci a touché tous les systèmes Microsoft depuis Windows 2000. L’attaque utilise de manière anormale les canaux du protocole RDP pour modifier la mémoire de la machine distante et exécuter du code sur la machine de la victime. L’utilisation de NLA permet de complexifier l’exploitation de la vulnérabilité.

 Vérifiez que NLA est bien activé sur DC19 :

> (Get-WmiObject -class "Win32_TSGeneralSetting" -Namespace  
root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'").
UserAuthenticationRequired 

Si nécessaire, il est possible d’activer NLA avec la cmdlet suivante :

(Get-WmiObject -class "Win32_TSGeneralSetting" -Namespace 
root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'")....

Windows Firewall

1. Qu’est-ce qu’un pare-feu déjà ?

Depuis le début de l’ouvrage, la notion de pare-feu est apparue à de nombreuses reprises, sans que sa définition et son administration soient abordées. Un firewall peut être de type "système", comme sur les Windows du Lab, ou encore "périmétrique" (dit parfois "barrière" ou "interzone"), comme sur la machine pfSense.

Un pare-feu a pour rôle d’imposer une politique réseau, en maîtrisant les communications autorisées (ou non) à partir de critères comme ceux-ci :

  • Les IP sources et destination.

  • Le protocole : TCP, UDP, ICMP, etc.

  • Le port source ou destination.

  • Certaines options : fragmentation, suivi du statut de la connexion TCP, nombre de connexions par seconde, etc.

Il existe aujourd’hui de très nombreux pare-feu. On citera par exemple iptables/netfilter pour Linux, les pare-feu intégrés à l’antivirus comme dans Symantec Endpoint Protection, ou des produits d’éditeurs comme Fortinet ou Palo Alto. Il est intéressant dans cet ouvrage de se pencher rapidement sur le fonctionnement d’un firewall Windows et sa configuration avec PowerShell.

Le firewall des clients Windows a la particularité d’intégrer trois profils de fonctionnement différents :

  • Réseaux avec domaine (les réseaux d’entreprises avec un AD).

  • Réseaux privés (les réseaux personnels ou de petites entreprises).

  • Réseaux publics ou invités (les réseaux publics non maîtrisés).

Ces localisations sont sélectionnées par l’utilisateur lors de la première connexion à un nouveau réseau, et associées à un jeu de règles dédié au profil. Le choix se fait entre le mode privé et le mode public, le mode "avec domaine" étant appliqué automatiquement dès que la machine rejoint le domaine. Le choix étant laissé à l’utilisateur, il est sujet aux erreurs que cet utilisateur pourrait faire face à un mécanisme qu’il ne comprend pas forcément…

 Contrôlez le mode de la connexion sur la machine Windows 10 :...

Défendre et contrôler son AD

Une première recommandation, à la fois très simple en apparence et facilement implémentable dans de petits environnements, est le suivi des comptes informatiques. Dans une entreprise, c’est un exercice obligatoire, que ce soit à des fins réglementaires, de conformité organisationnelle ou simplement de bonnes pratiques de sécurité.

Dans les grands SI, l’exercice s’avère beaucoup plus compliqué, au regard des ordres de grandeurs en jeu. Le renforcement et l’automatisation de ses processus sont un premier pas dans cette direction. La mise en œuvre de ces techniques de surveillance et d’automatisation n’a rien à voir avec de la sécurité à strictement parler, et se rapproche plus des bonnes pratiques d’administration.

1. Les comptes de service managés

Certains comptes sont beaucoup plus intéressants que les autres pour un attaquant : les comptes privilégiés et les comptes de service. Les premiers permettent de prendre rapidement le contrôle de l’infrastructure. Les seconds sont des comptes non nominatifs, souvent laissés sans attention particulière et parfois avec des mots de passe datant de politiques de sécurité identiques à l’âge du compte. Contraignants et chronophages, le suivi et le renouvellement des secrets de ces comptes sont souvent négligés. Pourtant, ces derniers disposent régulièrement de privilèges importants sur le domaine ou le SI.

L’attaque par Kerberoasting, présentée au chapitre Les attaquants et PowerShell, cible spécifiquement ce genre de compte. Pour celle-ci, la vulnérabilité exploitée revient à un mot de passe trop faible et donc réversible pour un compte. Microsoft propose une solution pour résoudre ce genre de problème : les comptes de service managés de groupe (gMSA).

Les comptes de service managés sont étonnamment peu connus des administrateurs Windows et éditeurs de solutions logicielles. Pourtant, les gMSA devraient remplacer dès que possible les comptes utilisateurs traditionnellement utilisés pour ces besoins de comptes techniques.

Ces gMSA sont les successeurs des comptes de service...

Live-forensics et PowerShell

1. WinRM et le live-forensics

Pour commencer, qu’est-ce que le live-forensics ? Il s’agit d’une méthode d’investigation numérique qui complète l’analyse forensique traditionnelle, qui est une analyse réalisée sur l’image disque d’une machine éteinte. "L’analyse forensique des systèmes vivants", en français, s’utilise, comme son nom l’indique, sur des machines actives et accessibles en ligne.

Cette technique est nécessaire pour tous les exemples d’attaques "en mémoire uniquement", qui ont été abordés au cours des premiers chapitres (voir chapitre Malware maison - Étape 1 : le dropper Memory Only). Par rapport à une analyse à froid, elle va permettre en particulier la collecte d’une image de la mémoire RAM qui serait impossible sur une machine éteinte.

Dans les grands SI, cette fonction est aujourd’hui portée par les EDR (Endpoint Detection and Response) qui, à l’aide d’un agent sur les postes et serveurs, va fournir ces fonctionnalités. Lorsque l’environnement ou le contexte ne permettent pas l’installation d’un tel produit, les fonctions de contrôle à distance de PowerShell comme WinRM, surtout s’il est couplé avec JEA, peuvent fournir des fonctionnalités similaires et intéressantes aux administrateurs.

Dans les sections suivantes, nous n’allons pas revenir sur le fonctionnement des accès distants de PowerShell, mais plutôt regarder ce qu’il est possible de surveiller sur un système avec PowerShell dans une optique de contrôle, ou de levée de doutes.

2. WMI : abonnements aux événements système

Très utilisés par les malwares comme mécanisme de persistance ou de propagation, les événements WMI peuvent également être utilisés dans une optique de surveillance du système d’information. WMI fournit en effet une fonctionnalité de gestion des événements.

Par exemple, lors de la création d’un nouveau processus, une nouvelle instance de l’objet WIN32_Process est créée dans la base WMI...

Conclusion

Au cours de ce chapitre, nous avons donné différents exemples de mécanismes défensifs qu’un administrateur peut mettre en place pour renforcer la sécurité de son SI : firewall, gestion des protocoles réseau, protection de l’annuaire et étude des mécanismes de surveillance, mais aussi des mécanismes de persistance des attaquants, avec souscription aux événements WMI. Ces exemples n’ont pas été choisis au hasard et font partie soit des quick win faciles à mettre en place sur un SI (mise en place des comptes de service managés par exemple), soit des éléments souvent mal compris par les administrateurs (la persistance WMI en tête).

En revanche, au travers de ces quelques exemples, nous n’avons ici fait qu’égratigner la surface de l’iceberg qu’est la défense d’un système d’information avec Windows. Il y aurait suffisamment de matière pour écrire un ouvrage rien que sur les mécanismes d’attaque et de défense d’Active Directory.

Plutôt qu’espérer un jour compléter une ultime checklist de suivi projet qui puisse vous assurer que votre SI est sécurisé, et d’implémenter les techniques ci-dessus sans prendre de recul, nous vous invitons à continuer cette démarche...