Comment configurer Azure Firewall pour sécuriser les flux dans un Hub-and-Spoke

Article corédigé par Gilles Etien et Amine Teffahi

Dans notre précédent article sur « Comment déployer une architecture Hub-and-Spoke avec Azure Firewall », nous avons présenté les étapes à suivre pour l’installation d’une architecture Hub-and-Spoke ainsi qu’un test de connexion à distance sur une machine de rebond (VM Admin) à partir d’une IP publique sécurisée par le Firewall. Nous avons également observé la particularité des rules DNAT sur les flux Inbound. A présent, nous vous proposons de tester les deux autres types de règles (Network/Application) sur Azure Firewall.

Scénario 2 : connexion sur VM2 à partir de VMadmin en RDP

Dans ce deuxième scénario, il est question de se connecter sur VM2 à partir de VMadmin en RDP. Bien sûr, le flux doit être filtré par le Firewall.

Configuration du Network

Allez sur « resource Firewal Policy »=> « Network rules » puis cliquez sur « Add rule collection » :

Configurez la rule collection comme indiqué ci-dessous :

• Name : NetworkRuleCollection
• Rule Collection Type : Network
• Priority : 500
• Rule Collection action : Allow
• Rule Collection Group : DefualtNetworkRuleCollectionGroup

Rules

Rule :

• Name : VmAdminToVm2
• SourceType : IP Adress
• Source : IP privee de la VM Admin (192.16.16.4)
• Protocole : Any
• Destination port : 3389 (Port RDP)
• Destination Type : IP address
• Destination : IP privée de VM2 192.168.32.4

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

Pour vérifier que AdminVM et VM2 communiquent, nous pouvons utiliser Network watcher avec Next Hop.

On donne :

• Virtual Machine: AdminVM
• Network interface: choisissez dans la liste déroulante la carte réseau de AdminVM (adminvm99)
• Source IP Adress : adresse IP de AdminVM (192.168.16.4)
• Destination : addresse IP de VM 2 192.168.32.4

Cliquez sur « Next Hop » et voici le résultat :

• Next Hop type : VirtualAppliance
• IPaddress : 192.168.0.4

Ce résultat nous confirme que le « peering » et la « route table » fonctionnent en redirigeant le flux vers le firewall ( 192.168.0.4 l’adresse IP privé du firewall)

Le second test consiste à se connecter sur AdminVM et lancer l’interface « command » pour utiliser un classique « Tracert » vers l’IP de VM2 (192.168.32.4). On voir sur l’image ci-dessous que le test est concluant*.

*Par défaut, les VM sur Azure ont le firewall Windows activé bloquant le protocole ICMP. Dans le cadre du test, nous avons autorisé le protocole ICMP sur le flux inbound en lançant la commande sur VM2 : New-NetFirewallRule –DisplayName “Allow ICMPv4-In” –Protocol ICMPv4

Scénario 3 : accès à une WebApp avec un private endpoint via le firewall

Le dernier scénario consiste à permettre à VMadmin d’accéder à une WebApp ayant un private endpoint en passant par le firewall. L’idée est de montrer qu’on utilise VMadmin comme machine de rebond pour accéder à une WebApp en interne tout en ayant l’intégralité des flux filtrés par le firewall.

Configuration du Application Rules

Sur “resource Firewal Policy”, allez sur “Application Rules” et cliquez sur “Add rule collection” :

Configurez la « rule collection » comme ci-dessous :

• Name : ApplicationRuleCollection
• Rule Collection Type : Network
• Priority : 300
• Rule Collection action : Allow
• Rule Collection Group : DefualtNetworkRuleCollectionGroup

Rules

Rule :

• Name : ToWebApp
• SourceType : ip Adress
• Source : subnet de AdminVm (192.16.16.0/24)
• Protocole : HTTPS
• Destination Type : fqdn
• Destination : webappspoke2.azurewebsite.net

Validez et laissez la nouvelle configuration de l’application rule se déployer.

Pour vérifier, connectez-vous sur VMadmin en RDP depuis Internet comme dans le scénario n°2. Une fois que vous êtes connecté, lancez le browser pour utiliser l’URL https://webappspoke2.azurewebsite.net.

Le test est OK ! Vous pouvez donc vous connecter sur une machine de rebond pour accéder à une WebApp publiée au sein d’un réseau privé.

Dans cette capture, on voit bien que le Remote Address est bien l’IP privée de notre WebApp (son private endpoint ) 192.168.33.4

L’essentiel à retenir sur la configuration d’Azure Firewall pour sécuriser les flux dans un Hub-and-Spoke

Par ces deux scénarios, nous avons démontré étape par étape qu’en s’appuyant sur une architecture réseau Hub-and-Spoke, et en s’assurant que tous les flux sont redirigés et filtrés par le firewall, on était en mesure de sécuriser des flux Est/Ouest (Vnet1/Vnet 2) avec Network rules mais aussi d’accéder à une WebApp à partir de son URL. Ces exemples ne sont qu’une partie des options fournies par Azure Firewall permettant de sécuriser les flux réseau (DNAT / TCP / UDP / HTTPS / Etc.).

Vous souhaitez en savoir plus ? Vous avez des questions ? Vous avez envie de nous faire part de vos retours sur cet article ? N’hésitez pas à nous laisser un message en commentaires !