Sécuriser votre architecture

1. Déroulement d’une attaque type

En règle générale, de nombreuses attaques utilisent le phishing comme vecteur de compromission. Le social engineering (capacité de convaincre une personne à faire ce que l’on attend d’elle) est une arme redoutable. Vous aurez beau avoir mis à jour votre système d’exploitation et vos plugins, si un utilisateur se laisser berner par un mail malicieux et qu’il ouvre une pièce jointe malveillante, alors les jeux sont faits.

Généralement, une attaque se déroule ainsi :

1. Approche par tiers de confiance

Du poste utilisateur vers un compte admin du domaine

À la lecture des différents éléments évoqués plus haut, vous devinez sans doute qu’il peut être très compliqué de protéger un Active Directory.

Prenons l’exemple d’un utilisateur du support de proximité. Son compte est membre d’un groupe de domaine qui lui-même est membre du groupe Administrateur local de tous les postes de travail. Il est normal, de par la nature de ses fonctions, qu’un tel utilisateur puisse accéder en tant qu’administrateur aux postes de travail.

Cela signifie donc qu’au fil de ses différentes interventions, le hash de son compte va se retrouver sur un nombre important d’ordinateurs. Il suffira alors que juste un de ces postes soient sous le contrôle d’un utilisateur de l’outil mimikatz (ou équivalent) pour que le mot de passe de cet utilisateur soit affiché et que l’utilisateur malintentionné puisse réutiliser ce compte pour se connecter en tant qu’administrateur à n’importe quel autre poste de travail.

Si parmi ces postes de travail se trouvent des postes de comptes d’administrateurs qui se chargent d’administrer les serveurs (ou pire, l’Active Directory), alors l’attaquant pourra rejouer mimikatz sur les postes en question et ainsi récupérer le mot de passe d’un administrateur de serveurs ou de domaine.

Une fois administrateur du domaine, l’attaquant peut générer un « Golden Ticket » et alors avoir un accès quasi à vie et indétectable en tant qu’administrateur du domaine.

Certains seront tentés de répondre : « Pas de souci, j’ai un antivirus sur tous mes postes et serveurs, mimikatz ou n’importe quel autre outil ne sera jamais capable de s’exécuter. »

Outrepasser la protection par signature d’un antivirus est extrêmement facile, surtout avec un outil comme mimikatz pour lequel les sources sont libres et que des portages PowerShell existent ! Pour vous en convaincre, vous pouvez appliquer les recommandations de cet article (http://www.blackhillsinfosec.com/?p=5555) qui explique comment...

1. Principe de moindre privilège et JEA

Le principe de moindre privilège est, comme son nom l’indique, un principe qui consiste à lancer chaque tâche avec un compte utilisateur qui a exactement les permissions nécessaires à l’accomplissement de cette tâche.

Dans la pratique, cela n’est bien sûr pas toujours réalisable mais il convient de toujours faire au mieux afin d’être le plus proche du besoin tout en laissant exposée une surface d’attaque la plus réduite possible.

La surface d’attaque sera d’autant plus réduite si vous patchez régulièrement votre parc aussi bien au niveau du système d’exploitation, que des outils tiers et sans oublier les équipements réseau. Le chapitre Cycle de vie de votre infrastructure traite notamment de l’utilisation de WSUS (Windows Server Update Services) pour déployer des patchs sur vos systèmes Windows.

Une nouvelle technologie nommée JEA pour Just Enough Administration permet, comme son nom l’indique, de donner « juste les droits nécessaires à l’administration » de n’importe quel composant qui peut être administré via PowerShell.

Il est même possible d’accéder à des ressources du réseau via cette solution (contrairement à d’autres solutions qui utilisent le compte SYSTEM de l’ordinateur local, limitant ainsi les interactions avec les ressources sur le réseau puisque dans ce cas, c’est le compte de l’ordinateur qui est utilisé).

JEA est disponible à partir de PowerShell 5.0 et donc Windows Server 2008 R2 et Windows 7 (mais partiellement compatible pour cet OS car il n’est alors pas possible de configurer JEA pour utiliser des comptes virtuels).

Un peu plus concrètement, voici le concept dans ses grandes lignes :

1. AppLocker ou le contrôle de l’application

AppLocker est une fonctionnalité qui a fait son apparition sous Windows 7 (en version Enterprise et Ultimate) et Windows Server 2008 R2 afin de remplacer les stratégies de restriction logicielle des versions précédentes de Windows.

Tout comme les stratégies de restriction logicielle, AppLocker permet de définir les applications autorisées à être exécutées par vos utilisateurs standards au sein de votre domaine en déployant vos paramètres via des stratégies de groupe.

L’intérêt principal est donc de limiter l’installation de malwares sur les postes de travail mais également d’empêcher l’installation de logiciels non normés ou nécessitant une licence que vous ne possédez pas, etc. Sur les postes et serveurs les plus sensibles (par exemple les contrôleurs de domaine), il peut servir à n’autoriser qu’une liste blanche d’exécutables, bloquant tous les autres.

Cette fonctionnalité concerne donc principalement les postes clients sous Windows 7/8/8.1 Enterprise mais il peut également être intéressant d’auditer et de limiter les exécutables lancés sur Windows Server 2008 R2 et Windows Server 2012/2012 R2.

AppLocker présente plusieurs avantages comparés aux stratégies de restriction logicielle :

Sachez également que si une stratégie...

1. Approche de la délégation d’administration

Les politiques de sécurité étant généralement différentes au sein des divisions et les équipes IT n’étant pas les mêmes, il convient de trouver une solution afin de déléguer les tâches nécessaires au travail de chacun sans pour autant compromettre la sécurité de la totalité du domaine Active Directory.

Il y a différentes façons de déléguer des droits à des utilisateurs. Certaines autorisations peuvent facilement être fournies au travers de groupes de sécurité déjà existants. C’est le cas par exemple si vous souhaitez déléguer l’administration de service comme le DHCP (avec le groupe DHCPAdmins) ou DNS (avec le groupe DNSAdmins), ou bien encore la possibilité de consulter les journaux d’événements (avec le groupe Event Log readers), etc.

Une délégation au sein de l’annuaire Active Directory est aussi réalisable de façon plus granulaire directement au niveau des objets.

La structure d’un domaine Active Directory est organisée par défaut de façon hiérarchique. Il est en effet possible de déléguer des tâches au niveau d’une forêt, d’un site, d’un domaine ou bien même d’une unité d’organisation. De plus, chaque objet possédant des attributs avec des DACL (Discretionary Access Control List) associées à ces derniers, il est également possible de déléguer des options de façon assez fine (réinitialiser le mot d’un utilisateur, autoriser la désactivation d’un compte utilisateur, etc.). Nous passerons à la pratique un peu plus loin dans ce chapitre.

Avant de vous lancer dans la configuration de la délégation de votre...

1. Le Pare-feu Windows

Windows Server 2016 met à disposition un pare-feu capable d’analyser à la fois le trafic entrant et le trafic sortant grâce à son nouveau module pare-feu à sécurité avancée accessible via la console MMC du même nom.

Ce module de pare-feu n’est pas à confondre avec le pare-feu « basique » bien connu des environnements XP et accessible via la commande firewall.cpl. Le pare-feu basique ne permet pas de définir des règles pour le trafic sortant mais uniquement des exceptions pour le trafic entrant.

Depuis Windows Server 2008 R2, la console du pare-feu basique a évolué et permet l’activation de la protection suivant le type de réseau auquel est connectée la carte, à savoir « Domaine », « Privé », ou « Public » (cf. plus loin pour davantage d’informations sur ces types de réseau). Chaque interface réseau se verra attribuer un profil suivant les caractéristiques définies par le service Connaissance des emplacements réseau.

Vous choisissez alors les applications pour lesquelles vous souhaitez autoriser le trafic entrant. Cela présente un avantage comparé à l’ouverture d’un port car une application autorisée ouvre une « brèche » uniquement le temps du lancement de l’application tandis qu’une règle sur un port reste ouverte tout le temps et rien ne peut garantir que l’application écoutant sur ce port n’est pas en réalité un malware.

Il est également possible de configurer les règles de pare-feu depuis une console MMC permettant de paramétrer de façon très précise et granulaire les flux aussi bien entrants que sortants. Cela permet de coller au mieux avec la réalité des besoins...