Archives de la catégorie ‘IT Security’

 

Introduction

PSexec fait partie de la fameuse SysInternals Tools/PsTools Suite de Microsoft, créée par Mark Russinovich, qui n’est autre que le CTO actuel de la firme américaine.

PSexec vous permet d’exécuter des commandes/Processus sur des machines distantes, et ce sans avoir besoin d’installer de features/outils supplémentaires.

Il s’agit d’un outil très puissant d’Administration (à distance) et troubleshooting des plateformes Windows (Client & Server).

Télécharger la Suite SysInternals Tools

Télécharger l’outil PSexec.exe

Note : le guide d’utilisation de PSexec est détaillé depuis la même page de Download.

Tip : comme vous pouvez le constater, les tools de la Sysinternals peuvent être téléchargés séparément.

 

Bloquer l’exécution de PSexec ?!! Pourquoi ? Pour quelles raisons ?

Contrairement à la plupart des Softwares/Tools de Microsoft, le fonctionnement de PsExec.exe n’est pas un secret, il est assez simple. PsExec autorise les redirections des Input & Output d’un exécutable démarré à distance via l’utilisation de SMB et du partage (caché) $ADMIN sur le système distant. Avec ce partage, PsExec utilise l’API Windows Service Control Manager (WSCM) pour démarrer le service PsExecsvc sur le système distant, qui crée un canal nommé avec lequel PsExec communique. Ce canal nommé est ce qui permet la redirection des entrées / sorties vers le système qui a lancé PsExec.

PsExec peut être utilisé pour collecter des informations depuis des machines distantes (IPConfig, Net use, …) ou administrer un serveur Windows (Changer le password d’un compte Admin Loca, Patch management à partir d’un script…) ou encore lancer une instance Regedit.exe en tant que System Account pour pouvoir écrire/modifier certaines clés de Registre et bien plus encore !

La puissance de cet outil fait justement « peur » à certains RSSI/DSI, par conséquent, PsExec fait généralement partie des tools à Blacklister sur tout le parc Windows Client/Server.

A l’aide de PsExec, un Hacker ayant réussi à récupérer des crédentials depuis une machine vulnérable sur le réseau, peut les utiliser pour établir une connexion distante et tenter des collecter plus d’infos sensibles voire envisager une escalation de privilège.

 

Quelques Real-world scénarios
  • Exéuction d’un programme malveillant à distance (eg : Backdoor)

Figure 4: A malicious executable being launched remotely

  • Exécuter un programme/file à distance via l’utilisation d’un UserName et le Hash de son password !

Figure 5: Using a password hash to execute a file remotely

Exécution des outils /programmes en tant que Compte « System » : compte ayant le plus haut niveau de privilège sur les OS Windows

 

Vous aurez compris, l’utilisation de PsExec au sein d’un réseau Windows peut s’avérer dangereuse car permettrait à un Hacker ou toute personne malveillante d’accéder et récupérer à des informations sensibles (AD, comptes Admin…)

 

HowTo : Bloquer l’exécution du PSexec

Il existe différentes méthodes pour bloquer l’exécution de PsExec.exe :

  • Désactivation du partage (par défaut) ADMIN$
  • Déploiement d’une clé de registre (psexec.exe > Dubugger = svchost.exe)

 

Bloquer PsExec via la désactivation du Partage Windows ADMIN$

Pourquoi désactiver le partage ADMIN$ ?

Lorsque PsExec est utilisé pour exécuter une tâche/commande sur un système distant, il crée un nouvel exécutable/service appelé « psexesvc.exe ». Cet exe est copié dans le dossier Windows de la machine distante via le partage par défaut ADMIN$ (d’où la nécessité d’être un administrateur pour que psexec fonctionne à distance), désactiver ce partage bloque donc le fonctionnement de PsExec

Pour désactiver le partage ADMIN$, rien de plus simple, il faut lancer la console « Dossiers partagés » en exécutant l’outil « FsMgmt.msc » depuis le Menu Exécuter ou Démarré > Partages > ADMIN$ > Click-droit > Arrêter le Partage.

 

Bloquer PsExec via la clé de Registre

Pour bloquer l’exécution du PSexec via la clé de Registre, suivez les instructions suivantes :

  • Créer une clé de Registre nommée « psexec.exe » au niveau de : HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\
  • Créer ensuite une sous-clé au niveau de « psexec.exe », avec les informations suivantes :
    • Type : REG_SZ (Data String)
    • Nom clé : Debugger
    • Valeur : svchost.exe

 

Aucun reboot de la machine n’est requis :).

Testons maintenant l’exécution du PSexec. Dans l’exemple suivant, je reprend l’exemple précédent pour lancer un CMD.exe en tant que « System », comme montré ci-dessous, aucun résultat n’est retourné.

PSexec est bloqué au lancement, vous n’aurez aucune info ni message d’erreur :

 

Bloquer PsExec via GPO (GPP)

Si vous devez généraliser le déploiement de la clé Registre créée précédemment, le meilleur moyen de le faire, est de configurer une GPP (Group Policy Preference), voir paramètres suivants ;

 

Télécharger la clé de Registre

Vous pouvez télécharger la clé de Registre depuis l’URL suivante et l’importer directement sur les machines (Client et/ou Serveur) sur lesquelles vous souhaitez bloquer l’exécution de PSexec

https://gallery.technet.microsoft.com/Block-PsExec-Execution-4a86c023

 

Pensez à implémenter AppLocker 

Le meilleur moyen de bloquer l’exécution des PsTools (PsExec, PsShutdown…) est d’implémenter des règles (Blacklisting) AppLocker à base de Hash, c’est le moyen le plus fiable en terme de software blacklisting dans les environnements Windows.

 

Note : un eBook sur AppLocker 2012 R2 et 2016 est disponible sur BecomeITExpert.com. Si le sujet vous intéresse, cliquez sur une des images ci-dessous pour en savoir plus.

 

A bientôt :).

Résultat de recherche d'images pour "azure private link"
Introduction

Les clients Azure ont de plus en plus besoin d’accéder à leurs données et services Cloud de manière privée et sécurisée.

Plusieurs Services Azure (offres PaaS et SaaS principalement) sont (par défaut) déployés avec des interfaces Publics. Eg Database Azure SQL ou Compte de Stockage Azure déployés avec des URL Publics/DNS Name routable sur Internet.

Microsoft avait introduit un service appelé « VNET Service Endpoint » (Points de terminaison) permettant d’associer un service Azure partagé (Shared) à un VNET privé.

Vous pouvez en effet sécuriser la connexion à un service Partagé tel qu’une base Azure SQL PaaS en utilisant les points de terminaison VNET, ces derniers maintiennent le trafic sur le réseau interne Microsoft et permettent de « Lock-down » la ressource PaaS sur votre réseau virtuel uniquement.

En revanche, les points de terminaison PaaS restent accessibles via une adresse IP publique et ne peuvent donc pas être atteints depuis votre réseau local/onPrem via un Peering privé ExpressRoute ou une Passerelle VPN Azure.

Pour rendre ses services PaaS et SaaS Publics accessibles de manière privée et sécurisée, Microsoft a introduit un nouveau service appelé « Azure Private Link » !

 

Azure Private Link : qu’est-ce que c’est ? 

Tant attendu, Azure Private Link (APL) est un service qui va vous permettre d’accéder à des services Azure tels que Azure Storage, SQL (Offres PaaS), des Services tiers (Marketplace Azure) ou encore des ressources Buildées par vous via une liaison privée/sécurisée et complètement déconnectée d’Internet.

Une fois configuré et intégré à votre VNET, Azure Private Link établit un lien privé via des Private Endpoints avec tous les services Azure partagés pris en charge (Azure SQL, Azure Storage…), ces derniers deviennent accessibles via une Adresse IP Privée/Locale faisant parti de votre Range IP, comme n’importe quelle ressource déployée et associée à un de vos VNET Azure.

Notez qu’Azure Private Link s’intègre également avec les Zones DNS Privées d’Azure.

Prenons l’exemple suivant : Architecture Hybride Azure avec liaison ER (Private Peering)

Azure présente une extension de votre Datacenter (OnPrem), ce dernier est interconnecté avec Azure via une liaison « ExpressRoute » en Private Peering.

Vous déployez une base de données Azure SQL, par défaut, ce service est accessible via une URL publique (Routable sur Internet). Azure Private Link permet de rendre cette ressource Publique (DB Azure SQL), privée en l’associant à votre VNET et en lui attribuant une adresse IP locale. Les utilisateurs OnPrem peuvent donc (via le lien Private Peering ExpressRoute) accéder à cette DB Azure SQL via son adresse IP Privée/Locale, la ressource sera visible et accessible comme n’importe quelle ressource déployée dans vos environnements locaux ou Cloud.

Cela réduit considérablement le risque lié à l’exposition des ressources Azure sur Internet, car tout le trafic passe à travers le réseau Interne de MS Azure (Azure Backbone Network).

Le Schéma suivant illustre le fonctionnement du service Azure Private Link :

Diagram showing the Private Link topology. Starting from services attached to Private Link, then linked and made available in the customer VNet through a Private Endpoint.

 

Vous pouvez aussi regarder la vidéo ci-dessous pour en savoir plus sur APL :

[Cliquez sur l’image pour visionner la vidéo]

 

Pourquoi utiliser Azure Private Link : Quels avantages ? Quels Use-Cases ?

L’utilisation d’Azure Private Link présente plusieurs avantages :

  • Configuration réseau simplifiée : la configuration et gestion des règles de filtrage réseau reste la même car tous les services Publics partagés (eg : Azure SQL Database) deviennent privés et sont accédées via leurs interfaces IP privées comme n’importe quelle ressource associée à votre VNET (même accès et connectivité que les VM Azure par exemple).

Vous pouvez utiliser Azure Private Link dans les scénarios suivants :

  • Si vous voulez établir une connexion privée avec les services PaaS Azure : comme mentionné précédemment, grâce à Azure Private Link, vous pouvez désormais accéder à des services partagés Multi-tenant tels que le Stockage Azure, Azure SQL de manière privée et sécurisée. Vous pouvez simplement créer un Private Endpoint dans votre VNET et le mapper sur votre ressource PaaS (votre compte de stockage Azure ou base de données SQL), APL attribue ensuite des adresses IP locales/privées à ces services PaaS et les rendent accessibles depuis votre réseau Azure (VNET) ou Local (OnPrem).
  • Si vous voulez Établir une connexion privée avec les services SaaS Azure : Plusieurs Partenaires de Microsoft offrent aujourd’hui leurs solutions sous forme de SaaS (Software-as-a-Service) à travers la Marketplace Azure. Ces solutions SaaS sont souvent accessibles que depuis Internet. Certains clients Azure souhaitent utiliser ces SaaS au sein de leurs réseaux privés comme s’elles étaient déployées au sein de leurs Datacenters. La possibilité de consommer les solutions SaaS à titre privé au sein du réseau du client est une demande courante. Avec Azure Private Link, la connectivité privée est aussi étendue aux partenaires Microsoft. Quand APL sera en GA, vous allez surement constater la disponibilité de plusieurs offres/solutions SaaS du Marketplace via un Azure Private Link : nous allons donc parler plutôt de Private SaaS.
  • Si vous voulez  établir une connexion privée avec vos services Azure (autres que PaaS et SaaS) : Le scope d’Azure Private Link ne se limite pas aux services/offres PaaS et SaaS d’Azure, vous pouvez en effet étendre APL aux autres Workloads comme par exemple des VMs Azure (faisant office de Web Server) ou des Azure WebApps placés derrière un Équilibreur de charge (Load Balancer) Standard. Le diagram suivant illustre une architecture avec et sans APL :

 

Before and after diagram, showing services traditionally exposed through public IPs vs exposed privately in the VNet through Private Link

 

Comme montré dans le schéma ci-dessus, avec Azure Private Link, vous pouvez déployer et placer des ressources Azure derrière un Load Balancer Standard, et configurer ce dernier pour permettre à vos utilisateurs faisant parti d’autres tenant AAD (ou abonnements) de donc depuis d’autres VNET d’atteindre sans avoir besoin d’exposer vos ressources sur Internet.

La création d’un Azure Private Link Service est nécessaire.

 

Composants d’Azure Private Link

Il faut bien noter qu’Azure Private Link fonctionne de la manière suivante :

  • Les Azure Private Endpoints sont utilisés pour rendre la communication privée avec les services PaaS/SaaS
  • Les Azure Private Link Services sont utilisés pour faire référence à vos ressources (VMs) placées derrière un Load Balancer Standard.

 

Services Azure pris en charge par Azure Private Link
Services Azure PaaS pris en charge 

Encore en Public Preview au moment de la rédaction de ce post, Azure Private Link prend uniquement en charge les services PaaS suivants :

  • Azure Storage
  • Azure SQL Database
  • Azure SQL Data Warehouse
  • Azure Data Lake Storage (Gen2)

 

Autres Services Azure pris en charge 
  • Services Azure placés derrière un Load Balancer Standard

 

Régions prenant en charge Azure Private Link

La Public Preview d’Azure Private Link prend uniquement en charge les régions Azure suivantes :

Type de service (Scénario) Services pris en charge Régions disponibles
Private Link pour vos services Azure Services derrière un Load Balancer Standard
  • West Central US
  • WestUS
  • South Central US
  • East US
  • North US
Private Link pour les services Azure PaaS Azure Storage
  • East US
  • West US
  • West Central US
Azure SQL Database
  • East US
  • West US
  • West Central US
Azure SQL Data Warehouse
  • West Central US
  • WestUS
  • South Central US
  • East US
  • North US
Azure Data Lake Storage Gen2
  • West Central US
  • WestUS
  • South Central US
  • East US
  • North US

Note importante : si des règles de sécurité/Compliance vous obligent à déployer des services Azure uniquement en France (Central /Sud) ou en Europe (Nord & Ouest), vous ne pouvez malheureusement activer/configurer/tester Azure Private Link. Eg : une Azure Policy qui force le déploiement des services Azure dans les Régions France et Europe uniquement vous empêchera de déployer APL. Voir avec les Cloud SecAdmin pour faire une exclusion sur un RG de test ou réaliser vos tests sur un Abonnement dédié au Sandbox/Dev/Test.

 

Limitations

Au moment de la rédaction du présent article, Azure Private Link (encore en Public Preview) présente les limitations suivantes :

Ressource/Object Limitation
Nombre de « Private Endpoints » par VNET 1000
Nombre de « Private Endpoints » par Abonnement 64000
Nombre de Service « Private Link » par Abonnement 32
Nombre de Configurations IP pour un Service « Private Link » 8 (Adresses IP NAT IP utilisées par PLS)
Nombre de « Private Endpoints » pour le même Service « Private Link » 1000

 

Pricing

Au moment de la rédaction de ce post, Azure Private Link est facturé de la manière suivante :

Service Liaison privée Le service Liaison privée n’est pas facturé
Point de terminaison privé 0,005 € par heure
Données entrantes (IN) traitées 0,005 € par Go
Données sortantes (OUT) traitées 0,005 € par Go

Notez que pendant toute la période « Public Preview » du service Azure Private Link, vous bénéficiez d’une remise de 50% sur les tarifs indiqués dans le tableau ci-dessus.

 

HowTo : créer un service Azure Private Link

Pour pouvoir créer un Private Link Azure, vous devez d’abord créer un Private endpoint. Azure Private Link s’appuie en effet sur le Private endpoint pour établir les différents canaux privés entre le VNET et les services Azure cibles (PaaS, SaaS, Ressources propriétaires).

Nous allons découvrir durant cette partie comment activer et configurer Azure Private Link.

Dans l’exemple suivant, le but est de sécuriser la communication entre une DB Azure SQL (PaaS) et une VM Azure (IaaS) depuis le réseau privé (VNET) Azure.

Notre service cible (DB Azure SQL) sera accessible de manière privée via son @IP privée/locale et ne sera donc plus visible depuis Internet.

Prérequis

Si vous ne disposez pas encore de compte Azure, vous pouvez en créer un gratuitement en cliquant ici.

 

Sandbox : Informations de configuration

Voici la configuration de notre LAB Azure :

  • 1 VNET :
    • Espace Adressage 10.10.0.0/16
    • Subnet 10.10.0.0/24
  • 1 VM Azure :
    • WS Server 2016 (Datacenter Edition)
    • Avec SSMS (SQL Server Management Studio) installé
    • IP : 10.10.0.4
  • [PaaS] Azure SQL Database :
    • Nom SQL Server : hklabdbserver.database.windows.net
    • Nom Database SQL : hklabdatabase
    • Zone DNS Privée Azure
      • Nom de la zone : hklabprivatelink.windows.database.net
      • Record A pour la base PaaS :
        • Hostname : hklabdbserver.hklabprivatelink.windows.database.net
        • IP Address (privée) : 10.10.0.5

 

Outils de déploiement

L’activation et configuration d’Azure Private Link peuvent être réalisées via différents tools (Azure Portal, Az PowerShell Module, Az CLI…).

Pour notre LAB, Azure CLI sera utilisé car c’est mon tool préféré (:D) mais aussi parce que je trouve que l’interaction avec Azure est 2 à 3 fois plus rapide par rapport à WS PS.

 

HowTo : créer un service Azure Private Link

Pour pouvoir créer et tester Azure Private Link, nous allons d’abord déployer notre infra de test, comprenant :

  • 1 VNET + 1 Subnet
  • 1 VM
  • 1 SQL Server-as-a-Service
  • 1 Database SQL Azure
  • 1 Zone DNS Privée Azure + 1 Record pour notre Azure DB Server
  • Le tout placé dans un Resource Group 

 

Pour ce faire, connectez-vous sur le Cloud Shell Azure et exécutez les commandes suivantes :

  • Note : vous pouvez changer les noms des objets et renseigner ceux qui vous conviennent le plus (eg : respecter une convention de nommage d’un env LAB Azure de votre société ou client).

 

#1 : Création du Ressource Groupe

Exécutez la commande suivante pour créer un groupe de ressource nommé « hk-lab-rg » au niveau de la région France Central :

#2 : Création du VNET et Subnet

Exécutez les commandes suivantes pour créer un nouveau VNET nommé « hk-lab-vnet » avec un subnet de /24 nommé « hk-lab-subnet » :

#3 : Création de la VM

Exécutez les commandes suivantes pour créer une nouvelle VM WS2019Datacenter nommé « hk-lab-vm« :

 

#4 : Création d’un nouveau Server Azure SQL (hklabdbserver) et une base de données de test (hklabdatabase)

Exécutez les commandes suivantes pour créer une nouveau Server Azure SQL :

az sql server create \
–name « hklabdbserver » \
–resource-group « hk-lab-rg » \
–location francecentral \
–admin-user « hksqladmin » \
–admin-password P@$$w0rd_2019!

Exécutez ensuite les commandes suivantes pour créer une nouvelle DB Azure SQL :

az sql db create \
–resource-group hk-lab-rg \
–server hklabdbserver \
–name hklabdatabase \
–edition GeneralPurpose \
–family Gen5 \
–capacity 1

 

#5  : Mettez à jour les stratégies Réseaux au niveau du Subnet « hk-lab-subnet »

Les stratégies réseaux et règles de filtrage (eg : règles NSG) ne prennent pas en charge les Private endpoints.

Le sous-réseau auquel nous allons associer les Ressources Private Link (via les Private endpoints) doit être configuré/mis à jour pour exclure les Privates Endpoints de toute règle réseau/filtrage définie.

Pour désactiver ces stratégies réseaux du subnet sur lequel vous allez créer et associer des Private endpoints, il suffit d’exécuter les commandes suivantes :

az network vnet subnet update \
–name hk-lab-subnet \
–resource-group hk-lab-rg \
–vnet-name hk-lab-vnet \
–disable-private-endpoint-network-policies true

 

Note importante : si vous créez votre Private endpoint via le Portail Azure (GUI mode), cette mise à jour des network policies est faite de manière automatique par l’assistant. Elle doit être réalisée à la main seulement quand vous déployer des private Endpoints via Windows PowerShell (Az Module) ou Azure CLI.

 

#6 : Création du Private Endpoint

Maintenant que les ressources requises pour notre LAB ont été créées et les stratégies réseaux ont été désactivées, nous allons créer et configurer Azure Private Link.

Pour ce faire, vous devez simplement créer un Private Endpoint car APL s’appuie en effet ce dernier pour faire communiquer des ressources comme les VMs Azure avec les ressources Private Link (de type Base PaaS Azure SQL ou Compte de stockage Azure).

Commencez donc par créer un Private endpoint en exécutant la commande Az CLI suivante

az network private-endpoint create \
–name hktestprivateendpoint \
–resource-group hk-lab-rg \
–vnet-name hk-lab-vnet \
–subnet hk-lab-subnet \
–private-connection-resource-id « /subscriptions/id/resourceGroups/hk-lab-rg/providers/Microsoft.Sql/servers/hklabdbserver »/ \
–group-ids hklabdbserver \
–connection-name hklabprivateendpointconnection

 

Tip : vous devez avoir l’ID de votre Az SQL Server (paramètre –private-connection-resource-id), pour l’obtenir, vous pouvez exécuter la commande suivante :

az sql server show -n hklabdbserver -g hk-lab-rg

 

#7 : Création de la Zone DNS privé Azure ainsi que le record pour la PaaS SQL Azure

Pour créer la zone DNS privée « hklabprivatelink.database.windows.net« , exécutez la commande suivante :

az network private-dns zone create –resource-group hk-lab-rg \
–name « hklabprivatelink.database.windows.net »

Créez ensuite le lien DNS privé, en exécutant la commande suivante :

az network private-dns link vnet create –resource-group hk-lab-rg \
–zone-name « hklabprivatelink.database.windows.net »\
–name hklabdnslink \
–virtual-network hk-lab-vnet \
–registration-enabled false

Nous allons maintenant déclarer/ajouter un record (A) et l’associer à notre serveur SQL Azure (hklabdbserver <> IP locale/privée : 10.10.0.5 car le 10.10.0.4 est attribuée à notre VM WS2016) en exécutant les deux commandes suivantes :

az network private-dns record-set a create –name hklabdbserver –zone-name hklabprivatelink.database.windows.net –resource-group hk-lab-rg

az network private-dns record-set a add-record –record-set-name hklabdbserver –zone-name hklabprivatelink.database.windows.net –resource-group hk-lab-rg -a 10.10.0.5

Et voilà le tour est joué :).

HowTo : Créer /Configurer Azure Private Link via PowerShell & Azure Portal

Pour créer et configurer Azure Private Link via PowerShell (Az Moduel), consultez cet article.

Pour créer et configurer Azure Private Link via le Portail Azure, consultez cet article.

 

Tester l’accès à votre service PaaS (SQL Server Azure) via son @IP locale

Nous allons maintenant tester la connectivité (privée) entre notre VM Azure (10.10.0.4) et notre Azure SQL Server (10.10.0.5), pour ce faire :

  • Connectez-vous via RDP sur la VM Azure (Click Connect pour récupérer le RDP File). Si vous n’avez pas attachée une Public IP à votre VM, vous pouvez toujours vous connecter en RDP via le service Azure Bastion. Pensez à utiliser l’URL « Preview » pour avoir l’option « Bastion : RDP|SSH » sur votre VM.
  • Une fois la session Windows ouverte, lancez l’invite de commande (CMD.exe) et faites un test nslookup avec le DNS name du serveur SQL Azure en exécutant la commande suivante : nslookup hklabdbserver.hklabprivatelink.database.windows.net
  • Comme montré dans la capture d’écran suivante, L’@IP retournée est 10.10.0.5 (IP locale)

  • Nous allons maintenant tester la communication via le port 1433 (SQL) sur l’@IP 10.10.0.5. Pour ce faire, lancez Windows PowerShell (en tant qu’Admin) et saisissez la commande suivante : Test-NetConnection -ComputerName 10.10.0.5 -Port 1433, le résultat retourné doit indiquer ‘True’, c’est qui veut dire que la communication entre votre VM et le service PaaS Azure SQL sur le port 1433 est OK via l’@IP locale (10.10.0.5)

  • Enfin, installez SQL Server Management Studio sur la VM Azure (10.10.0.4) et connectez-vous sur le serveur Azure SQL (hklabdbserver <> 10.10.0.5) à l’aide des credentials Admin SQL renseignés lors de la création du service Azure SQL

  • Comme montré dans la screenshot ci-dessous, la connexion sur le serveur Azure SQL a été réalisée avec succès, nous sommes bien connectés sur notre instance hklabdbserver via l’IP locale 10.10.0.5 :

 

S(ervice) L(evel) A(greement)

Une fois en GA (General Availability), Microsoft annonce une disponibilité trois 9 (99,9) du service Azure Private Link.

Source : https://azure.microsoft.com/fr-fr/pricing/details/private-link/

 

Azure Private Link : La Roadmap ?

L’équipe Azure Networking Corp annonce plusieurs New Features dans la Roadmap Azure Private Link, à savoir :

  • Disponibilité d’Azure Private Link dans de nouvelles Régions : Les régions France Central/Sud et Europe Nord/Ouest seront donc bientôt prises en charge (selon le PM Azure Networking)
  • Pris en charge de plusieurs nouveaux services PaaS : Azure Cosmos DB | Azure MySQL | Azure PostgreSQL | Azure MariaDB | Azure Application Service | Azure Key Vaul
  • Pris en charge de Nouveaux Services Partner (Service Tiers du Marketplace)

Quand il sera en GA, Azure Private Link prendra en charge une liste de services nettement plus importante.

Stay connected on : https://azure.microsoft.com/fr-fr/updates/?product=virtual-network

 

Lien Utile /Documenttion « Azure Private Link » 

La documentation officielle sur Azure Private Link est disponible depuis l’URL ci-dessous :

https://docs.microsoft.com/en-us/azure/private-link/

 

That’s All :).

A bientôt, #HK

 

La configuration de la solution LAPS est réalisée via PowerShell (PowerShell V2 minimum), cette solution possède un module dédié nommé « AdmPwd.PS ». Ce module s’installe avec LAPS en sélectionnant l’option « PowerShell Module ». Avant l’installation et le déploiement de la solution il est préférable de se familiariser avec ce module.

Avant chaque opération LAPS via PowerShell, vous devez d’abord importer le module PowerShell « AdmPwd.PS » en exécutant l’une des deux commandes suivantes :

Ci-dessous vous trouverez la liste des Cmd-Lets inclus dans le module PowerShell.

Import-Module AdmPwd.PS

IpMo AdmPwd.PS

Vous pouvez ensuite exécuter la commande suivante pour obtenir la liste complète des Cmd-lets fournis avec le module LAPS PS « AdmPwd.PS » :

Get-Command -Module AdmPwd.PS

Comme illustré dans la capture d’écran ci-dessous, le module « AdmPwd.PS » dispose de plusieurs Cmd-lets, celles-ci sont détaillées dans le tableau ci-dessous :

Cmd-Let /Explication
Find-AdmPwdExtendedRights

Permet d’obtenir les groupes /comptes par OU ayant la permission de consulter les mots de passe.

Get-AdmPwdPassword

Permet d’obtenir le mot de passe d’une machine.

Reset-AdmPwdPassword

Permet de modifier la date d’expiration du mot de passe.

Set-AdmPwdAuditing

Permet d’activer l’audit d’accès au mot de passe d’une machine. Créer l’événement 4662 sera consigné dans le journal des événements de sécurité des contrôleurs de domaine.

Set-AdmPwdComputerSelfPermission

Permet de créer sur les OU dans Active Directory les délégations de contrôles pour les comptes ordinateurs. Ceux-ci peuvent modifier les attributs LAPS afin de renseigner le mot de passe.

Set-AdmPwdReadPasswordPermission

Permet de créer sur les OU dans Active Directory les délégations de contrôles pour les groupes/utilisateurs. Ceux-ci peuvent afficher le mot de passe.

Set-AdmPwdResetPasswordPermission

Permet de créer sur les OU dans Active Directory les délégations de contrôles pour les groupes /utilisateurs. Ceux-ci peuvent modifier la date d’expiration afin d forcer le changement du mot de passe.

Update-AdmPwdADSchema

Permet de modifier le schéma AD en ajoutant les objets de type ordinateur les attributs suivants :

ms-MCS-AdmPwd

ms-Mcs-AdmPwdExpirationTime

 

Ceci est un extrait de l’eBook « Microsoft LAPS – Déploiement et Configuration en Entreprise« .

L’eBook est disponible ici.

N’hésitez pas à consulter la table des matières pour en savoir plus.

 

#HK

Introduction

Le produit LAPS (Local Administrator Password Solution) est un outil gratuit édité par Microsoft permettant de gérer automatiquement le mot de passe du compte administrateur local des systèmes d’exploitation Windows.

La solution se base par défaut sur le SID du compte administrateur local (S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-500).

L’utilisation du SID plutôt que le « SamAccountName » du compte BUILTING\administrateur (administrateur local de la machine) supprime l’adhérence à la langue du système installé, il est donc possible de déployer sur des environnements en français dont le compte se nomme « Administrateur » que des environnements en anglais où ce même compte se nomme « Administrator ».

La solution fonctionne aussi si vous avez renommé le compte Administrateur via GPO avec l’option :

Configuration ordinateur‘>’Paramètres Windows’> ‘Paramètres de sécurité’ > ‘Stratégies locales‘ > ‘Options de sécurité‘ > ‘Comptes : renommer le compte Administrateur‘ :

Note : vous pouvez trouver la liste des SID remarquables dans les KB Microsoft ci-dessous :

https://support.microsoft.com/fr-fr/help/243330/well-known-security-identifiers-in-windows-operating-systems

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc978401(v=technet.10)

 

Le mot de passe est généré de manière aléatoire et automatique avec une politique de complexité définie à l’avance et configurable. Ce même mot de passe est ensuite stocké au sein d’Active Directory dans un attribut du compte ordinateur « ms-MCS-AdmPwd ». Le mot de passe est donc unique à chaque machine.

Avant l’arrivée du produit LAPS, il était possible de configurer le mot de passe du compte Administrateur via GPO, plus précisément les GPP. Cette solution a été retirée par Microsoft car non sécure. De plus le mot de passe était global sur l’ensemble des ordinateurs recevant la GPO et en cas de changement il n’était pas possible de s’assurer que l’ensemble des machines aient été mise à jour. Il existe d’autre méthode via script PowerShell par exemple.

Avec LAPS lorsqu’il arrive qu’une machine soit corrompu ou que le mot de passe administrateur soit communiqué à un utilisateur, l’ensemble du parc machine n’est pas remis en cause.

Vous trouverez dans le lien ci-dessous le détail sur les failles de sécurité des GPO :

https://support.microsoft.com/en-us/help/2962486/ms14-025-vulnerability-in-group-policy-preferences-could-allow-elevati

La solution LAPS apporte les avantages suivants :

  • Sécurité :
    • Mot de passe généré aléatoirement.
    • Mot de passe unique.
    • Mot de passe changé régulièrement.
    • Possibilité d’ajuster la complexité du mot de passe
    • Possibilité de forcer le changement de mot de passe.
    • Mot de passe stocké dans AD et protégé par des ACL.
    • Echange entre client et AD chiffrés par Kerberos.
  • Management :
    • Configuration via GPO.
    • Module PowerShell pour l’installation, la configuration et gestion.
    • Disponibilité d’un client Lourd Graphique (GUI).

 

Lien de téléchargement

Microsoft LAPS est disponible en téléchargement gratuit depuis l’URL suivante :

https://www.microsoft.com/en-us/download/details.aspx?id=46899

 

Ceci est un extrait de l’eBook « Microsoft LAPS – Déploiement et Configuration en Entreprise« .

Pour en savoir plus, cliquez sur l’image suivante :

Hi Folks,

Microsoft a récemment annoncé la disponibilité générale (GA : General Availability) d’Azure AD Password Protection.

Je vous recommande vivement de le configurer désormais sur vos Directories Azure AD.

Lien utile

J’avais déjà rédigé dans le passé un post détaillant le sujet (Azure AD Password Protection) ainsi que l’option « Smart Lockout ».

Je vous invite à consulter cet article pour en savoir plus : https://hichamkadiri.wordpress.com/2018/07/21/azure-security-introduction-a-azure-ad-password-protection-et-smart-lockout-desormais-disponibles-en-public-preview/

 

Introduction

RDP (Remote Desktop Protocol) est (par défaut) considéré comme un protocole vulnérable qui peut exposer votre infrastructure (voire tout votre S.I) à des risques assez importants, notamment :

  • Brute-Force Attack
  • DoS (Denial-of-Service) Attack
  • Encryption Attack
  • Man-in-The-Middle (MiTM) Attack

 

Vous exposerez également votre S.I à un risque de sécurité si vous êtes consommateur (Cloud Consumer) d’une solution/Application Cloud hébergée sur une infrastructure RDS distante : Multi-tenancy Risk.

Plusieurs Cloud Providers proposant des applications SaaS (Software-as-a-Service) virtualisées et distribuées (RemoteApp) via des Portail RD Web Access personnalisés. Ces Apps sont souvent hébergées sur des infrastructures RDS « Partagées /Shared », cela veut dire que plusieurs clients, se connectent et consomment les mêmes Apps Cloud RDS depuis le même environnement. Pour des raisons de réduction de coût, plusieurs Cloud Providers déploient des RD Session Host en mode « Shared », et proposent rarement des infrastructures RDS dédiées (Collections de Session RDS dédiées par client/app).

Malheureusement la plupart des clients ne pensent pas à poser la question et se contentent de signer un contrat désignant les responsabilités de chacun (SLA) : en mode SaaS vous êtes uniquement responsable de vos données, les couches infra/storage/middleware sont gérées par le CP, seul ce dernier est responsable de la gestion, maintenance, patching… de l’environnement Cloud.

En revanche, vous avez la responsabilité de s’assurer du niveau de sécurité offert à travers ces applis Cloud qui souvent font parties de votre IT globale car les devices clients depuis lesquels vos users se connectent sont souvent intégrés dans votre AD local et connectés au niveau de votre Coporate Network.

 

Guide de Sécurité RDS : Liste des Risques, Menaces et Bonnes Pratiques que vous connaître 

Je viens de publier sur Slideshare un Guide de sécurité RDS assez complet (en Anglais) traitant ce sujet.

Il décrit et détaille toutes les Security Risks, menaces ainsi que les bonnes pratiques que vous devez prendre en considération lors de la phase « Design » de tout projet RDS (de 2008 R2 à 2019).

Il vous liste également les Risks/Menaces liées à des infrastructures RDS Offsites (hébergées chez un Cloud Provider), si vous êtes Cloud Customer d’une ou plusieurs Apps Cloud, vous pouvez toujours challenger l’éditeur/Cloud Provider en posant les questions listées dans ce Slide.

Le document est disponible sur SlideShare, à cet URL.

Vous pouvez aussi le visualiser directement depuis ce post, voir Slide ci-dessous :

Si vous souhaitez être accompagné, n’hésitez pas à me Ping via MP pour planifier un call et discuter plus en détail de votre projet.

Bonne lecture à tous,

#HK

Image associée

BitLocker : Introduction

BitLocker est une fonctionnalité native dans les OS Windows Client et Server.

Cette Built-in Feature vous permet de chiffrer vos Disks Systèmes et DATA mais aussi vos Disks Amovibles (Removable Devices > eg : USB Key) à l’aide de la fonctionnalité BitLocker ToGo.

Avec BitLocker, vous pouvez donc protéger vos données et vous protéger contre les menaces liées au vol/perte de Laptop.

BitLocker a d’abord été introduit avec le couple Windows Vista/Windows Server 2008. Cette fonctionnalité de sécurité Windows a évoluée dans le temps et a été améliorée avec la sortie de chaque nouvelle version d’OS Windows.

Pour en savoir plus sur BitLocker, je vous invite à consulter cet article.

 

Suis-je Obligé d’utiliser un Module TPM (ou pas) ?

Pour pouvoir chiffrer vos Disks (OS & DATA) à l’aide de BitLocker, Microsoft recommande l’utilisation de ce qu’on appelle un TPM (Trusted Platform Module : Module de Plateforme Sécurisée).

Une puce TPM est un petit contrôleur de sécurité gravé (dès la conception/fabrication de votre Laptop) sur la carte mère, il s’agit d’un mini « HSM (Hardware Security Manager) qui servira de coffre-fort (Key Vault) pour stocker la clé de chiffrement utilisée par BitLocker.

Cette clé de chiffrement utilisée par BitLocker sert à chiffrer (et dé-chiffrer) vos données, elle est ensuite communiquée au lanceur du système seulement si les principaux fichiers de démarrage ne semblent pas avoir été modifiés. L’utilisateur doit ensuite s’authentifier pour démarrer l’OS.

Modes d’Authentification 

Deux modes d’authentifications sont possibles : par code PIN ou par une clé USB contenant une clé valide, ce mode ne nécessite donc pas de puce TPM mais une simple clé USB qui sera nécessaire pour le Boot de la machine.

Il n’est pas recommandé d’utiliser une clé USB (risque de perte/vol de celle-ci !!) pour stocker la clé de chiffrement utilisée par BitLocker. C’est la raison pour laquelle nous allons voir à travers cet article comment Activer BitLocker pour chiffrer vos Disks à l’aide d’un code PIN.

Stay Connected :).

 

Comment puis-je vérifier la présence (ou absence) du module TPM sur mon Laptop ?

Windows 10 est fourni avec un Buil-in Snap-in appelé « TPM Manager /Gestionnaire TPM ».

Cet outil vous permet de configurer et gérer vos modules TPM localement ou à distance.

Il s’agit du Snap-in TPM.msc, accessible depuis une console MMC ou directement depuis le Menu « Démarrer » ou « Exécuté ».

Une fois lancé, TPM Manager vous indique si un module TPM est présent (ou pas) sur votre machine Windows. Dans l’exemple suivant, il est indiqué que le module TPM est prêt à être utilisé, cela veut simplement dire que ma machine est bien équipée d’une puce TPM.

 

HowTo : Activez Bitlocker et sécurisez l’accès à vos OS Disk sans module TPM :).

Suivez les instructions suivantes pour activer BitLocker (avec PIN code) sur votre Laptop Windows 10

Lancez l’outil GPEdit.msc depuis le Menu « Exécuter » (ou Démarrer) :

Développez : Configuration Ordinateur \ Modèles d’Administration \ Composants Windows \ Chiffrement de lecteur BitLocker \ Lecteurs du système d’exploitation

Double-cliquez sur le paramètre « Exiger une authentification supplémentaire au démarrage »

Cliquez sur « Activé » et cochez l’option « Autoriser BitLocker sans un module de plateforme sécurisée compatible (requiert un mot de passe ou une clé de démarrage……USB). Enfin, cliquez sur « Ok » pour valider :

Saisissez un GpUpdate depuis une Invite de Commande (CMD.exe) ou le Menu « Démarré » pour Refresh le moteur des stratégies de groupe local.

Maintenant, rendez-vous dans Panneau de configuration > Chiffrement de lecteur BitLocker :

Au niveau de votre partition système (C:), cliquez sur « Activer BitLocker »

L’assistant suivant apparaît, cliquez sur « Entrer un code confidentiel (recommandé) »

Saisissez votre PIN Code (Je vous recommande l’utilisation d’un code avec 14 et 16 caractères minimum) :

Si toutefois vous oubliez votre code PIN (parce que vous partez en vacances ce soir et que vous revenez que dans un mois :-D), la clé de récupération que vous êtes invité à sauvegarder lors de cette étape vous permettra la récupération/accès à votre PC. Vous aurez compris, il faut l’enregistrer/sauvegarder dans un endroit sûr !

L’assistant vous propose plusieurs options :

  • Enregistrement dans le Cloud (Microsoft bien évidement) : OneDrive doit être configuré au préalable sur votre machine
  • Enregistrement dans un fichier (Texte) : l’assistant refusera l’enregistrement du fichier (clé de récup) sur le même disque à chiffrer, vous devez donc disposez d’au moins deux disques locaux (physiques) attachés à votre machine, un disque dur externe ou une clé USB.
  • Impression de la clé de récupération : WTF !!! à éviter bien évidemment

 

Dans l’exemple suivant, ma clé de récupération sera sauvegardée dans le Cloud (sur mon Onedrive qui est déjà sécurisé et chiffré : Data-in-Transit et At-Rest)

Si vous choisissez l’option « Enregistrement dans un fichier », vous devez simplement sélectionnez un emplacement (externe > ExHDD ou USB Key) et cliquez sur « Enregistrer » :

BitLocker peut chiffrer tout le disque ou uniquement l’espace disque utilisé, le chiffrement de tout le disque risque de prendre plusieurs heures voire des jours s’il s’agit de plusieurs centaines de GigaB ou plusieurs TeraB. Je vous recommande de chiffrer que l’espace disque utilisé :

Comme mentionné dans l’assistant, depuis la v1511 de Windows 10, BitLocker prend en charge un nouveau mode de chiffrement de disque (basé sur du chiffrement par bloc : XTS-AES). Si votre Windows 10 est compatible XTS-AES, je vous recommande l’utilisation de ce mode de chiffrement :

Are You Ready 🙂 ? Si oui, laissez l’option « Exécuter la vérification du système BitLocker » cochée et cliquez sur « Continuer » :

La notification suivante apparaît dans le coin inférieur gauche de votre écran, et vous indiquant que le chiffrement de votre disque démarrera après le reboot de la machine :

Redémarrez votre machine (assurez-vous que tous vos travaux soient enregistrés et fermés 🙂 : document Word ouvert, Mail écrit mais non enregistré/non envoyé…etc) :

Après redémarrage, la fenêtre suivante apparaît, vous pouvez continuer à travailler sur votre machine le temps que BitLocker encrypte votre(vos) Disk(s). Cliquez simplement sur le bouton « Fermer » pour cacher la petite fenêtre « Chiffrement de lecteur BitLocker » :

 

Une fois le disque chiffré, BitLocker retourne le statut suivant :

Enfin, redémarrez votre Ordinateur et notez l’apparition de l’assistant BitLocker au démarrage, vous devez saisir votre PIN Code (configuré précédemment) pour pouvoir démarrer votre OS :).

That’s All :).

J’espère que cette astuce pourra vous être utile. N’attendez plus, commencez à sécuriser vos Laptops/PC de Bureau dès aujourd’hui.

A bientôt,

#HK