Configurer et déployer un pare-feu Azure

Récemment, Microsoft a annoncé deux nouvelles fonctionnalités réseaux sur Azure, longtemps attendues et qui sont maintenant en prévisualisation publique (public preview). L’une d’entre elles est Azure Firewall, qui offre des fonctionnalités de pare-feu natif entièrement dynamiques pour les ressources de réseau virtuel, avec une haute disponibilité intégrée et la possibilité de mettre automatiquement à l’échelle. Il est possible de créer et d’appliquer des stratégies de connectivité à l’aide de règles de filtrage au niveau de l’application et du réseau. Les stratégies de connectivité peuvent être appliquées sur plusieurs abonnements et réseaux virtuels. Le service Azure Firewall est entièrement intégré à la plateforme Azure, à l’interface utilisateur et aux services du portail.

Azure Firewall intègre les fonctionnalités suivantes :

 

Dans l’exemple suivant, les opérations suivantes vont être effectuées :

  • Activer le service Azure Firewall
  • Configurer et déployer un pare-feu avec un environnement réseau de test
  • Créer un itinéraire par défaut
  • Configurer des règles d’application et de réseau
  • Tester le pare-feu

 

Il est important de noter qu’Azure Firewall est toujours en version de prévisualisation publique (Public preview) et que des fonctionnalités supplémentaires peuvent être ajoutées et/ou que les fonctionnalités existantes peuvent changer et évoluer. Cette préversion publique est fournie sans contrat de niveau de service et ne doit pas être utilisée pour les charges de travail en production.

Afin de faciliter les prochaines commandes, J’ai utilisé Azure Cloud Shell qui permet d’executer les commandes directement sur Azure sans passer par une fenêtre de commande PowerShell locale. Cela est pratique lorsque l’on utilise un environnement de travail qui n’exécute pas Windows. (MacOS par exemple)

Activer Azure Firewall

Comme cette fonctionnalité est toujours en prévisualisation, il est nécessaire de l’activer dans la souscription, en utilisant la commande PowerShell Register-AzureRmProviderFeature :

Register-AzureRmProviderFeature -FeatureName AllowRegionalGatewayManagerForSecureGateway -ProviderNamespace Microsoft.Network
Register-AzureRmProviderFeature -FeatureName AllowAzureFirewall -ProviderNamespace Microsoft.Network

Il faut compter plusieurs minutes pour l’inscription de la fonctionnalité. Vous pouvez vérifier votre statut d’enregistrement en exécutant les commandes Azure PowerShell suivantes :

Get-AzureRmProviderFeature -FeatureName AllowRegionalGatewayManagerForSecureGateway -ProviderNamespace Microsoft.Network
Get-AzureRmProviderFeature -FeatureName AllowAzureFirewall -ProviderNamespace Microsoft.Network

Il faut créer un seul réseau virtuel avec trois sous-réseaux :

  • FW-SN : le pare-feu est dans ce sous-réseau
  • Workload-SN : le serveur de la charge de travail est dans ce sous-réseau. Le trafic réseau de ce sous-réseau traverse le pare-feu
  • Jump-SN : le serveur « jump » est dans ce sous-réseau. Le serveur de rebond possède une adresse IP publique à laquelle vous pouvez vous connecter à l’aide du Bureau à distance. De là, vous pouvez alors vous connecter (à l’aide d’un autre Bureau à distance) au serveur de la charge de travail

Je pars d’une souscription vide, sans aucune ressources. Il va donc falloir créer :

  • Un groupe de ressources
  • Un réseau virtuel
  • Des sous-réseaux supplémentaires
  • Des machines virtuelles

Configurer Azure Firewall

Je commence par créer le service Firewall qui me propose de créer les 2 premieres ressources

Il faut ensuite :

  1. Créer un groupe de ressources : Test-FW-RG
  2. Créer un réseau virtuel : Test-FW-VN avec l’espace d’adresse 10.0.0.0/16. Sous Subnet, le nom AzureFirewallSubnet s’affiche par défaut
  3. Pour Subnet address space, entrez 10.0.1.0/24
  4. Créer une adresse IP publique, par défaut azureFirewalls-ip est proposé avec un nom DNS en .cloudapp.azure.com
  5. Cliquer sur Review + create puis Create

Lors de la création du pare-feu, si vous n’avez pas activer Azure Firewall sur la souscription, un message d’erreur vous rappellera de faire l’enregistrement :

L’étape suivante consiste à créer des sous-réseaux supplémentaires pour le serveur de rebond et un sous-réseau pour les serveurs de la charge de travail.

  1. Dans la page d’accueil du portail Azure, cliquez sur Resource groups, puis cliquez sur Test-FW-RG
  2. Cliquez sur le réseau virtuel Test-FW-VN
  3. Sélectionnez Subnets, puis ajouter en un via l’onglet Subnet
  4. Entrez Workload-SN
  5. Pour Address range, entrez 10.0.2.0/24
  6. Cliquez sur OK.

Créez un autre sous-réseau nommé Jump-SN, avec la plage d’adresses 10.0.3.0/24

Créer des machines virtuelles

Maintenant, créez les machines virtuelles de rebond et de charge de travail, et placez-les dans les sous-réseaux appropriés.

Basics

  1. À partir de la page d’accueil du portail Azure, cliquez sur All services
  2. Sous Compute, cliquez sur Virtual machines
  3. Cliquez sur Add, puis sur Windows Server. Sélectionnez Windows Server 2016 Datacenter, puis cliquez sur Create
  4. Pour Name, entrez Srv-Jump. Je choisis SSD comme type de disque
  5. Entrez un nom d’utilisateur et un mot de passe
  6. Pour Resource group, cliquez sur Use existing puis sur Test-FW-RG
  7. Pour Location, sélectionnez le même emplacement que celui utilisé précédemment
  8. Cliquez sur OK

Size

  1.  Choisir une taille suffisante, ici B2ms (8 Go de RAM, 16 Go de stockage)
  2. Cliquez sur Sélectionner

Settings

  1. Sous Network, sélectionnez Test-FW-VN pour Virtual network
  2. Pour Subnets, sélectionnez Jump-SN
  3. Pour Select public inbound ports, sélectionnez RDP (3389)
  4. Laissez les autres paramètres par défaut et cliquez sur OK

Summary

Consultez le résumé, puis cliquez sur Créer. L’exécution du déploiement nécessite quelques minutes.

Répétez ce processus pour créer une autre machine virtuelle nommée Srv-Work avec les paramètres suivants :

  1. Pour Subnets, sélectionnez Workload-SN
  2. Pour Public IP address, sélectionnez None
  3. Pour Select public inbound ports, sélectionnez No public inbound ports

Le reste de la configuration est identique à celle de la machine virtuelle Srv-Jump.

Créer un itinéraire par défaut

Pour le sous-réseau Workload-SN, vous devez configurer l’itinéraire sortant par défaut pour qu’il traverse le pare-feu.

  1. À partir de la page d’accueil du portail Azure, cliquez sur Tous les services
  2. Sous Networking, cliquez sur Route tables
  3. Cliquez sur Add
  4. Pour Name, entrez Firewall-route
  5. Pour Resource group, sélectionnez Use existing puis Test-FW-RG
  6. Pour Location, sélectionnez le même emplacement que celui utilisé précédemment
  7. Cliquez sur Create
  8. Actualiser la page Route tables, puis cliquer sur la table de routage Firewall-route
  9. Cliquez sur Subnets, puis sur Associate
  10. Cliquez sur Virtual network, puis sélectionnez Test-FW-VN
  11. Pour Sous-réseau, cliquez sur Workload-SN
  12. Cliquez sur OK
  13. Cliquez sur Routes, puis sur Add
  14. Pour Route name, entrez FW-DG
  15. Pour Address prefix, entrez 0.0.0.0/0
  16. Pour Next hope type, sélectionnez Virtual Appliance
  17. Pour Next hope address, entrez l’adresse IP privée du pare-feu (disponible en cliquant sur la ressource Test-FW01)
  18. Cliquez sur OK.

Configurer des règles d’application

  1. Sur la page de la ressource Test-FW01, sous Settings, cliquez sur Rules
  2. Cliquez sur Add application rule collection
  3. Pour Name, entrez App-Coll01
  4. Pour Priority, entrez 200
  5. Pour Action, sélectionnez Allow
  6. Sous Rules,
    1. Pour Name, entrez AllowGH
    2. Pour Source addresses, entrez 10.0.2.0/24
    3. Pour Protocol:port, entrez http, https
    4. Pour Target FQDNS, entrez github.com
  7. Cliquez sur Add
  8. J’ai ajouté une autre règle : AllowMS avec comme Target FQDNS la valeur *.microsoft.com

Configurer des règles de réseau

  1. Cliquez sur Add network rule collection
  2. Pour Name, entrez Net-Coll01
  3. Pour Priority, entrez 200
  4. Pour Action, sélectionnez Allow
  5. Sous Rules,
    1. Pour Name, entrez AllowDNS
    2. Pour Protocol, sélectionnez UDP
    3. Pour Source addresses, entrez 10.0.2.0/24
    4. Pour Destination addresses, entrez 209.244.0.3, 209.244.0.4
    5. Pour Destination ports, entrez 53
    6. Cliquez sur Add

 

Afin de pouvoir résoudre les noms DNS configurés dans les règles d’application,  il faut ajouter des adresses DNS principales et secondaires sur l’interface réseau Srv-Work.

  1. Ouvrez le groupe de ressources Test-FW-RG

  2. Cliquez sur l’interface réseau de la machine virtuelle Srv-Work

  3. Sous Settings, cliquez sur DNS servers

  4. Sous DNS servers, cliquez sur Custom

  5. Entrez 209.244.0.3 et 209.244.0.4 dans chacune des zones de texte

  6. Cliquez sur Enregistrer

  7. Redémarrez la machine virtuelle Srv-Work.

Architecture finale

Tester le pare-feu

  1. Connectez un bureau à distance à la machine virtuelle Srv-Jump, et à partir de là, ouvrez une connexion Bureau à distance à l’adresse IP privée Srv-Work
  2. Ouvrez Internet Explorer et accédez à github.commicrosoft.com ou azure.microsoft.con. Les 3 pages doivent s’afficher. (IE n’étant plus supporté, l’affichage risque d’être altéré)
  3. Essayer d’accéder à d’autres sites, vous devriez être bloqués par le pare-feu et avoir le message suivant qui s’affiche : 

HTTP request from xx.x.x.x:xxxxx to xxxxxxxx:xx. Action: Deny. No rule matched. Proceeding with default action

 

Tarification Azure Firewall

Le coût Azure Firewall est disponible ici. Celui ci est mesuré en fonction du transfert des données entrantes et sortantes par Go et par unité logique (nombre de pare-feu),

Un modèle ARM est également disponible sur Github afin de déployer automatiquement un environnement de test.

La documentation sur Azure Firewall est également disponible sur https://docs.microsoft.com

Laisser un commentaire

Votre adresse courriel ne sera pas publiée. Les champs obligatoires sont indiqués avec *