Archives de la catégorie ‘Azure Networking’

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

Note : cette Big-Picture est disponible en téléchargement ici.

Introduction

Si vous êtes amenés à déployer et administrer des VM IaaS dans Azure, il est fortement déconseillé d’établir des connexions Directes RDP & SSH (à travers Internet) sur celles-ci : il s’agit d’une « Bad Practice » /cas courant dans les entreprises !

Les VMs Azure disposant d’une interface Public (@IP Public) sont exposées à Internet et donc à plusieurs Security Risks liés aux protocoles RDP et SSH.

Quels « Best Practices » ?

La « Best Practice » consiste à utiliser une connexion VPN Site-to-Site (entre le VNET Azure et votre réseau local : canal sécurisé IPSec /IKEv2) ou Point-to-Site (entre le VNET Azure et votre Machine d’Administration : canal sécurisé SSTP/IKEv2).

Avec cette architecture, vous réduisez la surface d’attaque en supprimant l’interface Publique de vos VMs (utilisation d’une Private NIC Only).

L’objectif du présent post est de vous détailler (step-by-step) la procédure à suivre pour SetuPé et configurer une connexion VPN Point-to-Site entre votre environnement Azure et votre ou vos machines d’administration distantes.

Let’s do it 🙂

 

# OS Client supporté pour la connexion VPN Point-to-Site

Les Operating System (OS) suivants sont pris en charge pour la connexion VPN Point-to-Site :

  • Windows :
    • Windows Client : Windows 7, 8, 8.1 et 10
    • Windows Server : Windows Server 2008, 2008 R2, 2012, 2012 R2 et 2016
  • Mac OS X

 

#[Prérequis] Créez votre compte Azure

Pour mettre en pratique les différentes techniques expliquées dans le présent article, vous devez disposer d’un compte Azure. Vous pouvez en créer un gratuitement via ce lien.

Useful info : MS vous offre 200$ de crédit Azure pour tout nouveau compte créé. Cette offre est valable pendant 30 jours (Trial Mode).

 

#Utilisation de l’interface Azure CLI 2.0 vs Ouverture de Session Azure Cloud Shell

Les scripts/lignes de codes listées ci-dessous peuvent être exécutées depuis :

  • Interface Azure CLI 2.0 (mode local)
  • Azure Cloud Shell  (mode web)

Si vous souhaitez exécuter les lignes de codes ci-dessous localement depuis votre machine d’administration, je vous invite à installer l’interface Azure CLI 2.0 en suivant les instructions détaillées dans cet article.

Sinon, vous pouvez simplement vous connecter sur le site shell.azure.com, ouvrir directement une session Azure Cloud Shell exécutez les scripts décrits ci-dessous.

Console Azure Cloud Shell Web

Note : Azure Cloud Shell représente votre machine d’administration hébergée dans le Cloud Azure. Elle est accessible depuis n’importe ou et via n’importe quel device. Le Cloud Shell Azure est accessible depuis le Portail Azure (portal.azure.com), il peut également être accédé directement depuis l’URL shell.azure.com

 

#Créez votre connexion VPN Azure Point-to-Site

Pour créer une connexion VPN Point-to-Site (P2S), vous devez créer et configurer plusieurs objets/services Azure : Passerelle VPN Azure, Public @IP de la Gateway, Certificat pour l’authentification de vos clients VPN distants

Voici les étapes à suivre pour créer et configurer correctement votre connexion VPN P2S.

  1. Créer un nouveau groupe de ressource qui regroupera toutes les ressources Azure qui seront créées
  2. Créer un nouveau VNET Azure
  3. Créer/Déclarer le Gateway Subnet du VNET Azure créé
  4. Créer une Nouvelle Passerelle VPN P2S (Point-to-Site)
  5. Créer une nouvelle @IP Public pour la nouvelle Passerelle VPN
  6. Créer/Générer un nouveau certificat Self-Signed (Auto-signé) pour authentifier les clients VPN Distants
  7. Déclarer le contenu de la clé Public du Certificat Root sur la configuration VPN Point-to-Site

 

Note #1 : les étapes 1, 2 et 3 peuvent être by-passées si vous souhaitez configurer une connexion VPN P2S sur un VNET existant. Vous devriez dans ce cas changer les valeurs décrites ci-dessous par celles correspondant aux objets Azure existants (nom groupe de ressource, nom VNET, IP Address Prefix/CIDR…Etc)

Note #2 : si vous disposez d’une PKI sur le réseau local ou dans le Cloud, vous pouvez générer un certificat SSL signé/validé par votre CA et l’importer dans Azure. Dans notre cas, nous allons simplement utiliser un certificat Auto-Signé :).

 

Pour créer votre connexion VPN Azure P2S, exécutez les lignes de codes listées ci-dessous.

Notez que chaque bloc de code correspond à une des étapes décrite ci-haut.

||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

#Etape1 :  Creation du ressource groupe
az group create -n hkdemorg -l WestEurope

#Etape2 : Creation du VNET
az network vnet create –name hkdemovnet –resource-group hkdemorg -l WestEurope –address-prefixes 10.110.0.0/16 –subnet-name hkdemosubbe –subnet-prefix 10.110.1.0/24 –ddos-protection false

#Etape3 : Creation du sous-reseau de la Passerell ‘Subnet Gateway’
az network vnet subnet create –address-prefix 10.110.254.0/24 –name GatewaySubnet –resource-group hkdemorg –vnet-name hkdemovnet

#Etape4 : Creation de l’adresse IP Public de la Gateway VPN
az network public-ip create –name hkdemovpngtwpip –allocation-method Dynamic –location westeurope –resource-group hkdemorg –sku Basic

#Etape5 : Creation de la Gateway VPN P2S
az network vnet-gateway create –name hkdemovpngtw -g hkdemorg –vnet hkdemovnet –public-ip-addresses hkdemovpngtwpip –location westeurope –gateway-type Vpn –sku VpnGw1 –vpn-type RouteBased –address-prefixes 172.116.1.0/24 –client-protocol SSTP

||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

Plusieurs résultats vous sont retournés à la fin de l’exécution de chaque commande, cela vous permet de vérifier si les services Azure ont été créés correctement (ou pas : retour d’un ou plusieurs Error Messages).

Nous allons maintenant vérifier si tous les services Azure créés précédemment apparaissent depuis le Portail Azure.

Pour ce faire, connectez-vous sur Portal.azure.com et cliquez sur « Groupes de Ressources » ou « Resource Groups » si votre interface Web est en « Anglais ».

Notre Groupe de Ressource (hkdemorg) créé en « Etape 1 » doit apparaître sous « Groupe de ressources » :

Cliquez cette fois-ci sur le Groupe de Ressource hkdemorg pour visualiser toutes les ressources créées (VNET,  Passerelle VPN et son Adresse IP Publique associée) :

 

#Création du certificat Auto-Signé pour l’authentification des clients distants

Les Certificats sont utilisés par Azure pour authentifier les clients distants se connectant sur votre VNET Azure à travers la connexion VPN Point à Site.

Dès que vous aurez obtenu votre certificat (obtenu via votre PKI Enterprise ou un auto-signé), vous devez renseigner les informations relatives à sa clé Public au niveau de la configuration Point-to-Site Azure. Ce Certificat sera donc considéré comme étant « Trusted » pour toute connexion VPN P2S à votre VNET.

En outre, vous devez générer le certificat client à partir du Certificat Root de Confiance, vous l’installez ensuite sur chaque poste client devant s’authentifier/se connecter à travers le canal VPN P2S.

Maintenant que nous avons découvert à quoi servent les certificats dans une configuration VPN Azure, nous passerons à l’étape 6 qui consiste à créer/générer un certificat auto-signé Root pour l’authentification de nos postes clients VPN.

Pour générer ce certificat Auto-Signé, deux options s’offrent à vous :

  • Utilisation de l’outil MakeCert.exe
  • Utilisation de la Cmd-Let New-SelfSignedCertificate 

 

Note importante : l’outil MakeCert est considéré comme « Obsolète » et n’est plus recommandé par l’éditeur. Voir cet article pour en savoir plus

Nous allons donc utiliser la Cmd-let New-SelfSignedCertificate pour générer notre certificat

Commencez par ouvrir une Session Windows sur un Poste Windows 10, lancez ensuite PowerShell ISE en tant qu’Administrateur et exécutez les commandes suivantes :

#Etape6-Part1 : Creation du Certificat Auto-signe « Root »
$hkcert = New-SelfSignedCertificate -Type Custom -KeySpec Signature -Subject "CN=HKP2SRootCert" -KeyExportPolicy Exportable
-HashAlgorithm sha256 -KeyLength 2048 `
-CertStoreLocation « Cert:\CurrentUser\My » -KeyUsageProperty Sign -KeyUsage CertSign

#Etape6-Part2 :  Generation du certificat client
New-SelfSignedCertificate -Type Custom -DnsName P2SChildCert -KeySpec Signature -Subject "CN=HKP2SChildCert" -KeyExportPolicy Exportable
-HashAlgorithm sha256 -KeyLength 2048 -CertStoreLocation "Cert:\CurrentUser\My"
-Signer $hkcert -TextExtension @(« 2.5.29.37={text}1.3.6.1.5.5.7.3.2 »)

Après exécution des commandes PowerShell ci-dessus, deux certificats sont générés au et stockés dans votre Magasin de certificats local (Certificats – Utilisateur Local):

  • HKP2SRootCert : certificat Root (dont la clé Public doit être déclarée sur Azure)
  • HKP2SChilfCert : certificat client (à installer sur chaque poste/client VPN).

Suivez les instructions suivantes pour exporter les deux certificats (Root & Child).

Export du Certificat Root, Pourquoi ?

Cette opération est importante car elle nous permettra de récupérer les informations sur la clé Public du Certificat Root pour les déclarer au niveau d’Azure (Config P2S) :

  1. Saisissez CertMgr.msc depuis le Menu Démarrer et lancez l’outil retourné dans les résultats de recherche
  2. La console « Certificats » apparaît. Développez « Personnel » > « Certificats« 
  3. Faites un Clic-droit sur HKP2SRootCert > Toutes les Tâches > Exporter…
  4. L’assistant suivant apparaît, cochez « Non, ne pas exporter la clé privée » et cliquez sur « Suivant » :

  1. Cochez « X.509 encodé en base 64 (*.cer) » et cliquez sur « Suivant » pour continuer :

  1. Cliquez sur « Parcourir… » et sélectionnez un emplacement dans lequel le certificat (.cer) sera placé (D:) dans l’exemple suivant) :

  1. Enfin, cliquez sur « Terminer » pour fermer l’assistant:

 

Export du Certifica Child (Client), Pourquoi ?

Le certificat client doit être installé sur chaque machine cliente devant se connecter (via le VPN P2S) sur votre VNET Azure. La procédure décrite ci-dessous vous permettra de générer un fichier PFX (avec son mot de passe associé).

  1. Saisissez CertMgr.msc depuis le Menu Démarrer et lancez l’outil retourné dans les résultats de recherche
  2. La console « Certificats » apparaît. Développez « Personnel » > « Certificats« 
  3. Faites un Clic-droit sur HKP2SChildCert > Toutes les Tâches > Exporter…
  4. L’assistant suivant apparaît, cochez « Oui, exporter la clé privée » et cliquez sur « Suivant » :

  1. Cochez « Echange d’informations personnelles – PKCS #12 (.PFX) » et cliquez sur « Suivant » pour continuer :

  1. Cochez « Mot de passe« , spécifiez un mot de passe, sélectionnez AES256 comme algorithme de chiffrement et cliquez sur « Suivant » :

  1. Choisissez un emplacement pour stocker votre fichier .Pfx et cliquez sur « Suivant » :

  1. Enfin, cliquez sur « Terminer » pour fermer l’assistant :

Le fichier PFX doit être installé sur toutes les machines d’administration depuis lesquelles vous pouvez être amenés à vous connecter pour établir la connexion VPN P2S Azure.

 

#Déclarer le contenu de votre certificat Root sur Azure (Configuration Point-to-Site)

A l’aide de Notepad ou Notepad++, éditez le fichier .Cer (Certificat Root Exporté précédemment) et copiez le contenu de sa clé Public comme montré ci-dessous :

Ces informations doivent être déclarées côté Azure (Configuration Point-to-Site).

Pour ce faire, exécutez la commande Az CLI suivante :

Note importante : remplacez la valeur du paramètre « –public-cert-data » par le contenu du Cert Root que vous avez copié précédemment.

#Etape7 Declaration du Cert Root au niveau de la configuration Point-to-Site Azure
az network vnet-gateway root-cert create –resource-group hkdemorg –gateway-name hkdemovpngtw –name hkvpnp2scert –public-cert-data « MIIC6zCCAdOgAwIBAgIQN9CJJEC3KopF32cKXpvOLTANBgkqhkiG9w0BAQsFADAY
MRYwFAYDVQQDDA1IS1AyU1Jvb3RDZXJ0MB4XDTE4MDcyNzIwNDQyMFoXDTE5MDcy
NzIxMDQyMFowGDEWMBQGA1UEAwwNSEtQMlNSb290Q2VydDCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMHLP5DxRhA9nem2F2/nELeHLyjD+NSLl9NWjikO
I6fTF2gnl6+cmRfoFbuZmjl6ocS7h9g9bNatTDeN/AFQx1xyf7ZKp9nZryEM9VdC
HoaTGkMlmdiqmXmyHzxBH457s4spEvM4udCIrnCkczn8ocWX11ea96BF1ZaUJ6x7
t3o8V8FzvcVh/7zeoK8x+sQU/j8f6Qs20/prjFrrcZ7olI1C2R8eBZkBw1mEe1Nt
0txmd8lmkjWZJNi17V5C+SOxpWwuyZml/Hw186jNi4wvNXCg9nK3Wn0NLCfOkILN
oQIbvraz7yYWNBZLq/xKqSumGtF4aV0t9yL/0dRfENpkQD0CAwEAAaMxMC8wDgYD
VR0PAQH/BAQDAgIEMB0GA1UdDgQWBBQCR1tl1iycoP6oJDjKrWcRAh6+hTANBgkq
hkiG9w0BAQsFAAOCAQEABRpmIzysxcKEBrCm/EtgjOYoPaj5SlKD8wJhTk1BGXG0
OE9yLTeuIscmZygT1Wt20lAaWlJAqbRmuTkhXbbinttc+WOyWbqvWrAnsIbydVAP
DYqz0vOEfTIxROeAw+keorAc/jhmszBgLbkRAhJ9CDamutKtPGxNYq0lI9BAs46e
l109pxxz/6hDLGOJFNPXdZDWqceoxjtFhWnFNBMXj6Z/2NEIA3u474eI2hDoguRE
rz3NJ9qJyINrjf9ncg4Yc0/RlM3LaVhLjcLpCp31dkbfPXx1/3IqSusiiUUSFLHG
64XQ9jVxvozhkuUXqBbmKekCnOTfHPbIeHA5mcv9RA== »

#Téléchargez le Package « VPN Client »

Avant de télécharger le client VPN (Fichier .Exe), commencez par vérifier que la clé Public de votre certificat Root a bien été déclarée au niveau de la configuration Point-à-Site Azure.

Enfin, cliquez sur « Télécharger le client VPN » pour générer le client VPN à installer sur votre machine d’administration : il s’agit d’un .Exe qui configure automatiquement la connexion VPN avec toutes les informations que vous avez configurées tout au long de ce post.

Une fois téléchargé, Dé-zippez le fichier et exécutez le Setup File correspondant à la version de votre OS Client.
Dans mon cas, j’utilise une machine Windows 10 64-bit. Le fichier WIndowsAmd64\VpnClientSetupAmd64.exe a donc été exécuté :

Le Setup VPN Client installe et configure automatiquement la connexion VPN Suivante :

Cliquez sur le nom de la connexion (hkdemovnet) pour faire apparaître la boite de dialogue suivante :

Cliquez sur « Se connecter« , et ensuite sur « Connecter » pour établir la connexion VPN P2S :

Une fois connecté, le statut de la connexion passe à « Connecté« , vous pouvez également vérifier l’adresse IP qui vous a été attribuée depuis l’invite de commande > IPConfig /All et la comparer à celle qui apparaît depuis le volet « Configuration Point-à-Site »  :

Et voilà le tour est joué :).

N’hésitez pas à me laisser un commentaire si vous avez des questions.
A bientôt Dear Readers.

#HK

 

Useful Info : Si vous n’avez pas encore consulté les 6 premiers HowTo Azure CLI 2.0, ceux-ci sont disponibles aux URLs ci-après:

HowTo #N°1 : Connecter l’interface Azure CLI 2.0 à votre abonnement Azure

HowTo #N°2 : Créer et gérer les groupes de ressources Azure

HowTo #N°3 Créer et gérer les réseaux virtuels Azure (VNET : Virtual Network)

HowTo #N°4 Créer et gérer les Machines Virtuelles Azure (Azure VM)

HowTo #N°5 : Gérer la facturation Azure (Azure Billing)

HowTo #N°6 Créer et gérer vos comptes de Stockage Azure

 

Introduction

Azure NSG (Network Security Groups) ou Groupes de Sécurité Réseau vous permettent de contrôler (autoriser ou refuser) le trafic entrant et sortant depuis et vers vos ressources Azure.

Les NSG sont basées sur des listes de règles de sécurité que vous créez/définissez manuellement. Notez que lors de la création d’un NGS, des règles par défaut sont générées automatiquement pour sécuriser certains trafics réseaux. Ces règles peuvent être bypassées en mettant en place des règles personnalisées.

Tip : Je vous invite à consulter cet article pour en savoir plus sur les NSG, leur fonctionnement et leur limitation.

 

La création d’un Groupe de Sécurité Réseau (NSG) peut se faire via :

Le nouveau portail Azure : portal.azure.com

Windows PowerShell : utilisation du module PS Azure

Azure CLI 2.0 : via l’utilisation de la commande az network nsg

 

Nous allons découvrir à travers cet article la troisième méthode qu’est l’utilisation de l’interface Azure CLI 2.0

Now let’s create & manage our Azure NSG via Azure CLI 2.0__O

 

HowTo : créer et gérer vos Groupes de Sécurité Réseau Azure (NGS)

Tout d’abord, je vous invite à saisir az network nsg -h pour en savoir plus sur les sous-commandes disponibles :

Pour lister tous les NSG existants, saisissez la commande suivante : az network nsg list 

Tip : pour une meilleure visibilité de la commande output, saisissez az network nsg list –out table

Commencez par créer un groupe de Ressource 

Azure ARM (Azure Resource Manager) introduit le concept des Groupes de ressources (RG : Resource Group). Ces derniers font office de « Conteneur » pour grouper et gérer les ressources Azure de manière centralisée.

Dans notre cas, nous allons créer un groupe de ressource pour regrouper les différents NSG Azure que nous allons créer par la suite.

Exécutez donc la commande suivante pour créer un nouveau groupe de ressource (nommé hk-demo-howto7) au niveau de la région Europe de l’Ouest (WestEurope)

az group create -n hk-demo-howto7 -l WestEurope

Maintenant que notre Groupe de Ressource est créé, nous allons créer notre premier Groupe de Sécurité Réseau Azure. Pour ce faire, exécutez la commande suivante (NSG nommé hk-demo-nsg dans l’exemple suivant) :

az network nsg create -n hk-demo-nsg -l WestEurope -g hk-demo-howto7

Vous pouvez également ajouter des « Tags » à vos NSG lors de leur création, dans l’exemple suivant nous allons créer un nouveau NSG Taggé « very_secure_network » :

az network nsg create -n hk-demo-nsg-vsecure -l WestEurope -g hk-demo-howto7 –tags very_secure_perimeter no_80 no_22 no_21

Pour afficher des informations détaillées sur un NSG spécifique, la commande suivante est à exécuter (hk-demo-nsg-vsecure dans l’exemple suivant) :

az network nsg show -n hk-demo-nsg-vsecure -g hk-demo-howto7

Enfin, si vous souhaitez supprimer un NSG, exécutez la commande suivante (hk-demo-nsg-vsecure dans l’exemple suivant) :

az network nsg delete -n hk-demo-nsg-vsecure -g hk-demo-howto7

Plusieurs HowTo Azure CLI (N°8/9 et 10) arrivent bientôt, so let’s keep in touch :).

A bientôt

#HK

Dans le cadre d’un projet de migration de Datacenters d’un de mes clients vers Azure, j’avais en charge l’étude, design et l’implémentation de plusieurs canaux VPN entre les Datacenters Azure et ceux OnPremise.

Compte-tenu du nombre de Gateway VPN Azure à monter, j’ai créé le script P(ower)S(hell) suivant pour automatiser et accélérer le processus de création des services Cloud réseaux nécessaires pour interconnexion.

Le code est détaillé ci-après, j’ai utilisé des noms & subnets de tests, vous aurez donc juste à remplacer les valeurs des variables par celles correspondant à votre environnement.

Mon architecture réseau Azure « cible » est la suivante :

  • 1 VNET nommé : hk-demo-vnet »
  • 1 Espace d’adressage : 10.0.52.0/24
  • 5 Subnets :
    • Subnet « Front-end » : 10.0.52.0/25
    • Subnet « Back-end » :  10.0.52.128/26
    • Subnet « Management« : 10.0.52.192/27
    • Subnet « DMZ » :  10.0.52.224/28
    • Subnet dédiée à la « Passerelle Az » : 10.0.52.240/28

 

Note : la seule étape qui nécessite un peu d’attente (~45 minutes environ) est la création de la Gateway VPN Az [Step #8]. Le reste des opérations est quasi immédiat :).

Note importante : le présent script concerne uniquement la configuration côté « Azure »; une configuration spécifique côté « Réseau OnPrem » est à faire, cela dépendra du type d’équipement déjà présent sur votre S.I (e.g : Fortigate, Cisco ASA, F5 BIG-IP, A10 Network…Etc). N’hésitez pas à consulter cette page pour vérifier la comptabilité /prise en charge de votre équipement réseau pour la connexion VPN avec Azure.


#1 Connecter votre compte Azure
Login-AzureRmAccount

#2 Selectionner votre Abonnement Azure (si vous en avez qu’un seul, vous pouvez bypasser cette etape). Dans l’exemple suivant, la subscription « HKDemoSubsription » sera selectionnee
Select-AzureRmSubscription -SubscriptionName « HKDemoSubscription »

#3 Crerr votre groupe de Ressource Azure au niveau de la Region Europe de l’Ouest
New-AzureRmResourceGroup -Name « hk-demo-rg » -Location ‘West Europe’

#4 Creer  du VNET ‘HK-Demo-vnet » et ses Subnets associés
$hkdemosubfe = New-AzureRmVirtualNetworkSubnetConfig -Name ‘hk-demo-sub-fe’ -AddressPrefix 10.0.52.0/25

$hkdemosubbe = New-AzureRmVirtualNetworkSubnetConfig -Name ‘hk-demo-sub-be’ -AddressPrefix 10.0.52.128/26

$hkdemosubmgmt = New-AzureRmVirtualNetworkSubnetConfig -Name ‘hk-demo-sub-mgmt’ -AddressPrefix 10.0.52.192/27

$SecuritySubnet = New-AzureRmVirtualNetworkSubnetConfig -Name ‘SecuritySubnet’ -AddressPrefix 10.0.52.224/28

$GatewaySubnet = New-AzureRmVirtualNetworkSubnetConfig -Name ‘GatewaySubnet’ -AddressPrefix 10.0.52.240/28

New-AzureRmVirtualNetwork -Name hk-demo-vnet -ResourceGroupName hk-demo-rg `
-Location ‘West Europe’ -AddressPrefix 10.0.52.0/24 -Subnet $hkdemosubfe, $hkdemosubbe, $hkdemosubmgmt, $SecuritySubnet, $GatewaySubnet

#5 Declarer La Passerelle /Device VPN Local ainsi que les Subnets de votre reseau Corporate (192.168.x.0 dans l’exemple suivant)
New-AzureRmLocalNetworkGateway -Name hk-demo-localgtw -ResourceGroupName hk-demo-rg `
-Location ‘West Europe’ -GatewayIpAddress ‘10.112.11.33’ -AddressPrefix ‘192.168.1.0/24’, ‘192.168.2.0/24’, ‘192.168.3.0/24’

#6 Creation d’une nouvelle adresse IP public pour la Gateway VPN Azure
$azuregtwpip = New-AzureRmPublicIpAddress -Name hk-demo-azgtwpip -ResourceGroupName hk-demo-rg -Location ‘West Europe’ -AllocationMethod Dynamic

#7 Declarer /Creer la configuration de la Gateway VPN Azure
$vnet = Get-AzureRmVirtualNetwork -Name hk-demo-vnet -ResourceGroupName hk-demo-rg
$subnet = Get-AzureRmVirtualNetworkSubnetConfig -Name ‘GatewaySubnet’ -VirtualNetwork $vnet
$azgtwipconfig = New-AzureRmVirtualNetworkGatewayIpConfig -Name hk-demo-azgtwconfig -SubnetId $subnet.Id -PublicIpAddressId $azuregtwpip.Id

#8 Creer votre nouvelle Gateway Azure
New-AzureRmVirtualNetworkGateway -Name hk-demo-azgtw -ResourceGroupName hk-demo-rg -Location 'West Europe' -IpConfigurations $azgtwipconfig -GatewayType Vpn
-VpnType RouteBased -GatewaySku Standard

#9 Obtenir l’@IP Public de la Gateway Azure (verifier que l’IP Public de votre Gateway Azure est bien générée)
Get-AzureRmPublicIpAddress -Name hk-demo-azgtwpip -ResourceGroupName hk-demo-rg

#10 Creer la connexion VPN entre le Device OnPrem et Azure
$azuregtw = Get-AzureRmVirtualNetworkGateway -Name hk-demo-azgtw -ResourceGroupName hk-demo-rg
$localgtw = Get-AzureRmLocalNetworkGateway -Name hk-demo-localgtw -ResourceGroupName hk-demo-rg

New-AzureRmVirtualNetworkGatewayConnection -Name hk-demo-azgtwcon -ResourceGroupName hk-demo-rg -Location 'West Europe' -VirtualNetworkGateway1 $azuregtw -LocalNetworkGateway2 $localgtw
-ConnectionType IPsec -RoutingWeight 10 -SharedKey ‘$HKD€m0@2017$’


Run & Enjoy the script :).

Une fois l’interconnexion établie entre le Device VPN Azure et celui d’OnPrem, le statut de l’objet de connexion passe à « Connected« , checkez les « Data in » et « Data out » pour s’assurer que le traffic passe bien entre vos ressources locales (OnPrem) et celles hébergées dans le Cloud Az.

Restez connectés, de nouveaux posts autour de l’Azure (step-by-step guides, HowTo..Etc) sont en cours de finalisation :).

 

Malgré l’ajout des ~2300 nouvelles Cmd-lets PowerShell sur Windows Server 2012 R2 et 2016, le meilleur outil de gestion du Networking & Firewalling Windows reste (pour moi :D) le super Command-Line Tool Netsh.exe (Windows Network Shell).

En effet, Windows PowerShell fonctionne aujourd’hui qu’avec un sous-ensemble de fonctionnalités de management Windows Server, n’incluant pas la possibilité de configurer et gérer le Pare-feu Windows et ses fonctions avancées.

J’ai donc décidé de vous regrouper dans le présent post les « Top 10″ des Commandes Netsh que vous devez connaître pour créer, configurer et gérer vos Pare-feu Windows (Client & Server).

Les commandes détaillées ci-dessous peuvent aussi vous être utile lors de la configuration du Firewall Windows IaaS (E.g : VM Azure ou AWS)

 

1.Afficher /Lister une règle spécifique ou toutes les règles du Pare-feu Windows
  • Afficher toutes les règles : netsh advfirewall firewall show rule name=all
  • Afficher une règle spécifique (« SQL » dans l’exemple suivant) : netsh advfirewall firewall show rule name=SQL


2.Activer /Désactiver un ou plusieurs profils du Pare-feu Windows
  • Activer tous les profils du Pare-feu Windows : Netsh advfirewall set allprofiles state on
  • Désactiver tous les profils du Pare-feu Windows : Netsh advfirewall set allprofiles state off
  • Activer le profil « Public » du Pare-feu Windows : Netsh advfirewall set publicprofile state on
  • Désactiver le profil « Privé » du Pare-feu Windows : Netsh advfirewall set privateprofile state off
  • Activer le profil « Domaine » du Pare-feu Windows : Netsh advfirewall set domainprofile state on

3.Réinitialiser les stratégies (par défaut) du Pare-feu Windows
  • netsh advfirewall reset

4.Afficher et Configurer les fichiers Logs du Pare-feu Windows

Notez que le chemin par défaut des fichiers « Logs » liés au Pare-feu Windows est le suivant : C:\Windows\system32\LogFiles\Firewall\pfirewall.log

Vous pouvez visualiser ce chemin par défaut (pour tous les profils du Pare-feu) en exécutant la commande suivante :

  • netsh advfirewall show allprofiles logging

Nous allons définir dans l’exemple suivant le chemin « D:\WSFirewall\Logs\pfirewall.log », pour tous les profils du Pare-feu Windows (Domaine – Privé – Public)

  • netsh advfirewall set allprofiles logging filename « D:\WSFirewall\Logs\pfirewall.log« 

Note : après configuration d’un nouvel emplacement du fichier log pfirewall.log, l’ancien fichier log placé dans le chemin par défaut est automatiquement déplacé et renommé en .old


5.Autoriser ou Refuser le « Ping »
  • Autoriser le « Ping »: netsh advfirewall firewall add rule name= »All ICMP V4″ dir=in action=allow protocol=icmpv4
  • Refuser le « Ping » : netsh advfirewall firewall add rule name= »All ICMP V4″ dir=in action=block protocol=icmpv4

6.Ajouter (Autoriser) ou Supprimer un Port spécifique
  • Ajouter une nouvelle règle autorisant le port 1433 (port par défaut utilisé par SQL Server) : netsh advfirewall firewall add rule name= »Autoriser_Port_SQL Server » dir=in action=allow protocol=TCP localport=1433
  • Supprimer la règle précédente autorisant le port 1433 (port par défaut utilisé par SQL Server) : netsh advfirewall firewall delete rule name= »Autoriser_Port_SQL Server » protocol=tcp localport=1433

7.Autoriser un Programme
  • Dans l’exemple suivant, le Programme « IPScan » placé dans C:\Program Files\IPScan\IPScan.exe » sera autorisé : netsh advfirewall firewall add rule name= »Autoriser_IPScan » dir=in action=allow program= »%ProgramFiles%\IPScan\IPScan.exe »

8.Activer la gestion à distance
  • netsh advfirewall firewall set rule group= »Gestion à distance de Windows » new enable=yes


9. Activer /autoriser Les Connexions Bureau à distance
  • netsh advfirewall firewall set rule group= »Bureau à distance » new enable=Yes


10.Exporter ou importer la configuration & paramètres du Pare-feu Windows
  • Pour exporter toute la configuration du Pare-feu Windows vers D:\WSFirewall : netsh advfirewall export « D:\WSFirewall\WFconfiguration.wfw »

  • Pour exporter toute la configuration du Pare-feu Windows vers D:\WSFirewall : netsh advfirewall export « D:\WSFirewall\WFconfiguration.wfw »

Je vous laisse Run > Netsh Advfirewall /? et découvrir le reste des commandes.

Enfin, toujours gardez à l’esprit que le CLI Netsh.exe fait parti des outils en ligne de commande Windows les plus puissants (et compliqué aussi). Toujours PoC(er), Tester et Valider l’opération sur un LaB /Environnement d’Intégration /PréProd …Etc avant toute application sur les serveurs de Production.

A bientôt