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 :
- Pare-feu avec état en tant que service
- Haute disponibilité avec extensibilité du cloud illimitée intégrées
- Stratégies de connectivité au niveau de l’application et du réseau
- Prise en charge de la traduction d’adresses réseau sources (SNAT)
- Intégration totale avec Azure Monitor pour la journalisation et l’analytique
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
À l’issue de l’installation, exécutez la commande suivante :
Register-AzureRmResourceProvider -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 :
- Créer un groupe de ressources : Test-FW-RG
- 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
- Pour Subnet address space, entrez 10.0.1.0/24
- Créer une adresse IP publique, par défaut azureFirewalls-ip est proposé avec un nom DNS en .cloudapp.azure.com
- 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.
- Dans la page d’accueil du portail Azure, cliquez sur Resource groups, puis cliquez sur Test-FW-RG
- Cliquez sur le réseau virtuel Test-FW-VN
- Sélectionnez Subnets, puis ajouter en un via l’onglet Subnet
- Entrez Workload-SN
- Pour Address range, entrez 10.0.2.0/24
- 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
- À partir de la page d’accueil du portail Azure, cliquez sur All services
- Sous Compute, cliquez sur Virtual machines
- Cliquez sur Add, puis sur Windows Server. Sélectionnez Windows Server 2016 Datacenter, puis cliquez sur Create
- Pour Name, entrez Srv-Jump. Je choisis SSD comme type de disque
- Entrez un nom d’utilisateur et un mot de passe
- Pour Resource group, cliquez sur Use existing puis sur Test-FW-RG
- Pour Location, sélectionnez le même emplacement que celui utilisé précédemment
- Cliquez sur OK
Size
- Choisir une taille suffisante, ici B2ms (8 Go de RAM, 16 Go de stockage)
- Cliquez sur Sélectionner
Settings
- Sous Network, sélectionnez Test-FW-VN pour Virtual network
- Pour Subnets, sélectionnez Jump-SN
- Pour Select public inbound ports, sélectionnez RDP (3389)
- 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 :
- Pour Subnets, sélectionnez Workload-SN
- Pour Public IP address, sélectionnez None
- 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.
- À partir de la page d’accueil du portail Azure, cliquez sur Tous les services
- Sous Networking, cliquez sur Route tables
- Cliquez sur Add
- Pour Name, entrez Firewall-route
- Pour Resource group, sélectionnez Use existing puis Test-FW-RG
- Pour Location, sélectionnez le même emplacement que celui utilisé précédemment
- Cliquez sur Create
- Actualiser la page Route tables, puis cliquer sur la table de routage Firewall-route
- Cliquez sur Subnets, puis sur Associate
- Cliquez sur Virtual network, puis sélectionnez Test-FW-VN
- Pour Sous-réseau, cliquez sur Workload-SN
- Cliquez sur OK
- Cliquez sur Routes, puis sur Add
- Pour Route name, entrez FW-DG
- Pour Address prefix, entrez 0.0.0.0/0
- Pour Next hope type, sélectionnez Virtual Appliance
- Pour Next hope address, entrez l’adresse IP privée du pare-feu (disponible en cliquant sur la ressource Test-FW01)
- Cliquez sur OK.
Configurer des règles d’application
- Sur la page de la ressource Test-FW01, sous Settings, cliquez sur Rules
- Cliquez sur Add application rule collection
- Pour Name, entrez App-Coll01
- Pour Priority, entrez 200
- Pour Action, sélectionnez Allow
- Sous Rules,
- Pour Name, entrez AllowGH
- Pour Source addresses, entrez 10.0.2.0/24
- Pour Protocol:port, entrez http, https
- Pour Target FQDNS, entrez github.com
- Cliquez sur Add
- J’ai ajouté une autre règle : AllowMS avec comme Target FQDNS la valeur *.microsoft.com
Configurer des règles de réseau
- Cliquez sur Add network rule collection
- Pour Name, entrez Net-Coll01
- Pour Priority, entrez 200
- Pour Action, sélectionnez Allow
- Sous Rules,
- Pour Name, entrez AllowDNS
- Pour Protocol, sélectionnez UDP
- Pour Source addresses, entrez 10.0.2.0/24
- Pour Destination addresses, entrez 209.244.0.3, 209.244.0.4
- Pour Destination ports, entrez 53
- 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.
-
Ouvrez le groupe de ressources Test-FW-RG
-
Cliquez sur l’interface réseau de la machine virtuelle Srv-Work
-
Sous Settings, cliquez sur DNS servers
-
Sous DNS servers, cliquez sur Custom
-
Entrez 209.244.0.3 et 209.244.0.4 dans chacune des zones de texte
-
Cliquez sur Enregistrer
-
Redémarrez la machine virtuelle Srv-Work.
Architecture finale
Tester le pare-feu
- 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
- Ouvrez Internet Explorer et accédez à github.com, microsoft.com ou azure.microsoft.con. Les 3 pages doivent s’afficher. (IE n’étant plus supporté, l’affichage risque d’être altéré)
- 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