Article corédigé par Amine Teffahi et Gilles Etien

 

Azure firewall est la solution Azure permettant la sécurisation de votre réseau sur les couches 3 et 4 principalement mais aussi sur la couche 7 du modèle OSI. L’objectif de cet article est de vous présenter plusieurs cas de figure de sécurisation d’un réseau Hub and Spoke à l’aide d’Azure Firewall.

 

Cas pratique de sécurisation d’une plateforme : le scénario

 

Nous devrons déployer et sécuriser une plateforme ayant :

• Une virtual machine d’administration dans le premier spoke (1^er réseau)
• Une virtual machine dans le spoke 2 (2^nd réseau)
• Une webapp avec un private endpoint dans le spoke 2 (non accessible depuis Internet)

 

Nous souhaitons que :

• La machine VMAdmin soit accessible uniquement en passant par le firewall en RDP (Pas d’IP public rattaché à notre VM) ;
• VMAdmin accède à VM2 en passant par le firewall (réseau privé ) ;
• La WebApp soit accessible uniquement depuis la VMAdmin en passant par le firewalls.

 

 

 

Qu’est-ce qu’une architecture hub-and-spoke ?

 

Schématiquement, une architecture hub-and-spoke se compose de trois espaces réseau :

• Hub: c’est le point central d’une architecture en étoile. Il se compose a minima d’un Vnet hébergeant les services centralisés (Azure Firewall, VPN Gateway, Bastion, monitoring).
• Spoke 1 et 2: ils représentent des Vnet connectés via un peering au Hub. Ils doivent pouvoir communiquer l’un et l’autre en passant par le Hub et potentiellement publier des services à l’extérieur via le hub.

 

« Tous les chemins mènent au Hub dans une architecture en étoile »

 

Avantages et points d’attention sur une architecture en Hub-and-Spoke

 

Une architecture en Hub-and-Spoke présente de nombreux avantages :

• Maitriser les coûts en centralisant les services les plus onéreux tout en évitant de les multiplier par environnement.
• Interconnecter plusieurs réseaux indépendants: le point de passage doit être le hub pour une communication entre Spokes (flux Est/Ouest), vers ou venant d’Internet (Nord/Sud).
• Il s’agit d’une architecture évolutive.
• Le management des flux est centralisé sur le hub, à l’inverse des Network Security Groups.
• Les caractéristiques d’une architecture en étoile font que le Hub devient le point le plus central de la plateforme et doit bénéficier d’un service de recovery clairement défini.
• Ce type d’architecture a fait ses preuves.

 

 

Quels sont les services Azure utilisés ?

 

Plusieurs services Azure peuvent être utilisés :

• Virtual Network (indispensable): Composant de base qui représente le hub et les Spokes. Chaque Vnet doit avoir sa propre liste d’adresse IP indépendante. Ces IP ne doivent en aucun cas se chevaucher au risque de causer l’instabilité de toute la plateforme.
• Peering (indispensable): c’est une configuration du Vnet (Virtual Networking) utilisé pour faire communiquer les Vnets entre eux via le réseau Azure.
• User Defined Route – UDR (indispensable): c’est un service pour créer et personnaliser des flux réseaux.
• Azure Firewall: il n’est pas obligatoire dans le fonctionnement basique d’un hub-and-spoke. Cependant, il est fortement conseillé de l’implémenter pour sécuriser les flux de communications.
• Log Analytics workspace (monitoring) : c’est un service azure responsable de collecter les métriques et les logs des ressources Azure.
• Bastion: ce service Azure permet de se connecter sur les machines Azure de façon sécurisée.
• VPN Gateway ou express route: pour établir la communication avec on-prem.

 

Ressources Azure

 

Architecture Réseau

 

Déploiement des Services Azure

 

Tout d’abord, on déploie les Vnets (Hub/Spoke1/Spoke2), les peerings, l’Azure firewall et les autres ressources via Azure Portal.

 

Déploiement des Vnets

Nous partons pour déployer les trois Vnets

 

Vnet Hub

Le Vnet Hub se situera dans la resource group Hub et se nommera hub dans la région West Europe.

 

On définit la plage d’adresse pour le Vnet et on ajoute un subnet /26 pour le firewall avec un nom imposé par Azure « AzureFirewallSubnet » (pour en savoir plus, nous vous invitons à consulter la documentation Microsoft)

 

 

⚠️ Point de vigilance : Azure firewall exige au minimum un /26 pour le subnet (voir FAQ de Microsoft)

 

Cliquez sur Next et validez :

Vnet Spoke 1et Vnet spoke 2

Menons la même opération pour Spoke 1 & 2 avec les informations suivantes :

Après le déploiement des 3 Vnets, nous pouvons configurer le VNET peering.

 

Configuration de Vnet peering

 

Le peering permettra d’interconnecter les trois Vnets entre eux. Pour cela, nous commençons par le Vnet « Hub »

⚠️ Attention : le Vnet Peering n’est pas transitif par défaut. Il ne permet pas de faire communiquer Spoke 1 et Spoke 2 automatiquement. Le firewall le permet en prenant le rôle de routeur.

Le VPN Gateway peut aussi assurer ce rôle.

Allez dans le panneau de configuration du Vnet « Hub » et cliquez sur « peering » :

 

 

Peering entre Hub et Spoke 1 dans les deux sens

Cliquez sur Add.

Nommez le peering « HubToSpoke1 » et sélectionnez “Vnet1”.

On sélectionne “Allow”:

• “Traffic to remote virtual Network”

On sélectionne:

• “Block traffic that from outside this virtual network”

⚠️ (Traffic ne provenant pas de vnet1)

 

Pour « virtual network gateway or route server”, nous laissons l’option « none » parce que le rôle de routeur dans notre scénario sera pris en charge par le firewall.

Cliquez sur Add.

Nommez le peering « Spoke1To Hub ».

Sélectionnez “Vnet1”.

Autorisez : “Traffic to remote virtual Network”

Autorisez : “Traffic forwarded from remote virtual Network”

 

Pour « virtual network gateway or route server », nous laissons l’option « none » parce que le rôle de routeur dans notre scénario sera pris en charge par le firewall.

 

 

 

Peering entre Hub et Spoke 2 dans les deux sens

 

Cliquez sur Add.

Nommez le peering « HubToSpoke2 ».

On sélectionne “Allow”:

• “Traffic to remote virtual Network”

On sélectionne :

• “Block traffic that from outside this virtual network”

⚠️ (Traffic ne provenant pas de Vnet 2)

 

Pour « virtual network gateway or route server », nous laissons l’option « none » parce que le rôle de routeur dans notre scénario sera pris en charge par le firewall.

 

Cliquez à nouveau sur Add et nommez le peering « Spoke2ToHub »

Sélectionnez « Vnet2.»

Autorisez : « Traffic to remote virtual Network »

Autorisez : « Traffic forwarded from remote virtual Network »

 

Pour « virtual network gateway or route server », nous laissons l’option « none » parce que le rôle de routeur dans notre scénario sera pris en charge par le firewall.

 

 

Nous avons maintenant terminé la configuration du peering entre le Vnet du Hub et ceux de Spoke 1 et Spoke 2. Nous pouvons désormais déployer l’élément sécurité de notre architecture : le firewall.

 

Déploiement d’Azure firewall

 

Azure firewall sécurisera les flux Nord/Sud (flux extérieurs vers réseau privé) et les flux Est/Ouest (flux inter Vnet). En prérequis, l’installation a besoin d’un Vnet (hub) et d’un subnet appelé AzureFirewallSubnet.

 

Création d’Azure Firewall

Allez sur « Create a resource »,  tapez « Azure firewall » et cliquez sur « Create ».

 

Remplissez les champs ci-dessous :

• Resource Group : Hub
• Name : FirewallDemo
• Region: West Europe
• Firewall tier : Standard

 

Sur le champ « Firewall policy », cliquez sur « Add New » :

• Policy Name: Parent Policy
• Region: West Europe
• Policy Tier: Standard

Et cliquez sur  « OK » :

 

 

Nous allons créer une IP public pour le firewall, cette étape constituant un prérequis au déploiement.

• Name : FWPIP
• SKU: standard
• Assignment : Static

Cliquez sur « OK ».

 

 

 

Déploiement de Virtual Machines

 

Nous déployons deux machines virtuelles : VMadmin comme machine admin dans Vnet1 et VM2 dans Vnet 2. Toutes les machines tourneront sous Windows server 2022.

 

VmAdmin

 

Networking

• Virtual network : VNET1
• Subnet : 192.168.16.0/24
• Pour utiliser le RDP, nous devons ouvrir le port 3389 dans le NSG.

 

Vm2

• Resource Group : Spoke2
• Région : Europe West Europe

 

Networking

• Virtual network : VNET2
• Subnet : 192.168.32.0/24
• Pour utiliser le RDP, nous devons ouvrir le port 3389 dans le NSG.

Nous avons déployé les machines virtuelles sur le réseau privé mais elles ne sont pas accessibles et ne peuvent pas communiquer entre elles. Nous devons router les flux réseaux à l’aide du service UDR (User Define Route).

 

UDR (User Define Route)

 

UDR est un service network essentiel pour la maitrise des flux réseau. Il nous permet de rediriger tous les flux vers le firewall.

 

Création du User Define Route

Allez sur Create => Network => Route Table

 

Donnez les informations suivantes :

• Resource Group : Hub
• Region : West Europe
• Name : DefaultRT

 

Association UDR avec Subnet :

Après la création de l’UDR, nous allons associer notre default UDR avec les subnets où sont localisées les machines virtuelles, afin que l’UDR route les flux provenant des machines.

Pour cela :

• Cliquez sur « Subnet » et « Association »
• Sélectionnez les deux subnets crées précédemment
• Après ces actions, vous devez avoir les deux subnets listés (AdminSubnet et VM subnet)

 

 

Configuration UDR

 

Pour la configuration, Cliquez sur « route » puis sur « Add ».

Définissez le nom de votre route dans le champ « Route Name » (ToFirewall)

Addresse prefix : 0.0.0.0/0

Next Hop : Virtual Appliance

Next Hop address : 192.168.0.4 (adresse IP privée du Firewall)

Cliquez sur “Add”.

 

Nous venons de configurer l’UDR pour que les IP appartenant à la plage d’adresse 0.0.0.0/0 soient redirigées vers l’adresse IP privée du Virtual Appliance (Firewall).

 

Pour en savoir plus, nous vous invitons à consulter la documentation Microsoft expliquant en détail le concept de routing dans Azure :

• Default route
• User Defined

 

A présent, nous attaquons le service Azure Private DNS qui sera utilisé par notre web avec son private end point.

 

 

Azure Private DNS

 

Cette étape consiste à déployer le Azure Private Dns et à l’attacher à chaque Vnet pour que le nom de domaine soit connu par les machines virtuelles (VM).

 

Création de l’Azure Private DNS

• Cliquez sur « Create a resource »
• Tapez « Private DNS Zone »
• Cliquez sur « Create »

 

• Dans le champ « resource group » : Hub
• Name : privatelink.azurewebsite.net

⚠️ Attention : nom domaine par défaut pour les ressources webapp.

Pour plus d’information sur voir le lien

 

• Cliquez sur « review+create »

 

Association Azure private DNS Vnet

• Cliquez sur “Virtual Network Links”
• Ensuite sur “Add”

 

 

Tapez le nom d’un des trois Vnets créés dans le chapitre VNET :

 

Répétez cette action pour les autres Vnets (hub & Vnet2).

A la fin, nous aurons la liste de tous les Vnets :

 

 

Installation du service Web App

 

Le service Web App (webbAppSpoke2) est le dernier élément à installer. Il sera dans le Spoke 2 et doit être accessible uniquement à partir d’un Private ndpoint.

 

Création du Web App

Commençons par créer une nouvelle ressource : cliquez sur « Create Resource » et « Web App » :

Remplissez les champs ci-dessous :

• Resource group : Spoke2
• NameWebApp : Spoke2
• Publish : Config Par Default
• Runtime starck : .NET 6
• Region : West Europe
• Operating System: Window/Linux (à votre convenance)

Ensuite, cliquez sur «Review et Create ».

 

Et sur « Create » :

 

Après le déploiement, on peut utiliser l’URL public de la WebApp https://webappspoke2.azurewebsites.net pour avoir l’image ci-dessous.

 

Cependant, nous voulons que la WebApp ne soit pas ouverte sur Internet. Les paramètres réseaux de la WebApp doivent changer pour ne fonctionner qu’avec une private endpoint dans notre réseau.

 

Private Endpoint

 

Cliquez sur « Networking » et sur « Private Endpoint » pour en créer un point d’accès à notre WebApp.

Cliquez sur « Add » :

• Name : webappPE
• Virtual Network : VNET2
• Subnet : PrivateEndpointSubnet

 

Et validez le Private endpoint.

 

Après cette opération, la WebApp ne doit plus être accessible par Internet. Si on utilise l’URL pour y accéder, voici ce qui s’affiche :

 

Notre WebApp est désormais accessible uniquement à partir du réseau privé, mais pour finir la configuration il faut lier notre WebApp avec notre private DNS zone.

 

Enregistrement DNS

 

Nous avons terminé l’installation de notre infrastructure Hub and Spoke. Portez une attention particulière sur les étapes Vnet, peering, UDR pour le succès de l’installation. Nous pouvons à présent commencer le scénario 1.

 

 

Scénario 1 : accéder à VMadmin en rdp via l’IP publique du firewall

 

L’objectif de ce premier scénario est de permettre un accès sur VMadmin en rdp en passant par l’IP publique du Firewall.

Pour cela, nous allons configurer le DNAT du firewall et tester une connexion à distance avec l’adresse IP publique du firewall pour se connecter.

 

Concepts de base sur Azure Firewall

 

Nous vous invitons à lire ces articles qui expliquent la structure logique du Firewall Policy et l’ordonnancement des rules du Firewall.

• Azure Firewall policy rule sets | Microsoft Docs
• Azure Firewall rule processing logic | Microsoft Docs
• https://docs.microsoft.com/en-us/azure/firewall/rule-processing#dnat-rules-and-network-rules

 

Structure logique Azure policy / Source

 

Configuration du Firewall

 

Allez sur le Firewall Policy (ressource Azure qui porte les règles du firewall).

Cliquez sur « DNAT Rule » et « Add a rule Collection » :

 

On souhaite que n’importe quelle IP puisse se connecter en RDP sur la machine VMadmin à partir de l’extérieur en utilisant uniquement l’IP publique du firewall. Ce dernier doit être en mesure de rediriger le flux directement sur l’IP privée de la VMadmin.

Pour cela, on va suivre la configuration suivante :

 

Rule Collection :

• Name : DNATRuleCollection
• Rule collection Type : Dnat
• Priority : 500
• Rule Collection Group: DefaultDnatRuleCollectionGroup

 

Rule :

• Name : To VmAdminVM
• SourceType : Ap Adress
• Source : *
• Protocole : TCP
• Destination port : 3389 (Port RDP)
• Destination Type: IP address
• Destination : (IP publique du firewall)
• Translated adress : IP privée de VMadmin, dans notre exemple c’est 192.168.16.4.

 

 

Validez la configuration et laissez la nouvelle configuration du DNAT se déployer.

Même si ce n’est pas expliqué ici, nous vous invitons à activer les logs pour suivre les flux qui passent par le firewall.

 

Test Connexion

 

Après, le déploiement de la règle, nous allons nous connecter sur VMadmin à partir de l’adresse IP du firewall.

Tapez la commande mstsc.exe à partir de l’exécutable de votre poste et remplissez :

• Ordinateur : donnez l’IP publique du firewall, dans notre cas c’est 20.224.1.212
• Nom de l’utilisateur : AdminVm (compte local admin)
• Connexion

 

 

Cliquez sur « autres choix » :

 

Sélectionnez « Utiliser un autre compte » : 

 

Tapez le mot passe du compte admin local de la VM admin :

Cliquez sur « oui » :

 

Vous êtes connecté !!!

 

La console du remote Desktop indique l’adresse IP du Firewall. Cependant, si vous vérifiez la configuration réseau de la machine (ipconfig /all), vous pouvez voir l’adresse privée de la machine.

 

Pour aller plus loin sur Azure Firewall

 

Nous avons réussi à accéder sur VMAdmin à partir d’Internet en utilisant l’adresse IP publique. Par cet exemple, nous avons mis en évidence le rôle de sécurisation du Firewall pour les flux Nord/sud (depuis Internet vers notre réseau sécurisé) grâce à « DNAT rule ». Par la même occasion, nous avons vérifié que notre peering était bien configuré en permettant la communication réseau entre les Vnets.

Nous vous invitons à découvrir la suite de cet article, dans laquelle nous continuerons à tester Azure Firewall avec les rules networks et les rules applications dans différents scenarios, dans le but de montrer comment Azure Firewall peut sécuriser votre plateforme.