Utilisation de Azure Firewall pour protéger votre infrastructure Cloud

Aujourd’hui, je vous propose un exercice simple en mode pas-à-pas afin de découvrir Azure Firewall. Je ne vais pas tout redétailler et nous allons prendre pour hypothèse que vous sachez ce qu’est un firewall ainsi que les autres alternatives qui peuvent être disponibles dans Azure (NSG, Azure Load Balancer, etc.). 🙂

Etape 1 : Création d’une VM et d’un VNet de test

Nous allons rester très simple afin de pouvoir monter en compétences simplement sur ce composant. Une fois que vous serez à l’aise vous pourrez bien évidemment l’utiliser dans des infrastructures plus complexes.

Commencez par créer une machine virtuelle (j’ai pris une Windows Server mais Linux c’est OK aussi) en gardant une majorité des options par défaut. Je vais attirer votre attention sur ce qui est important. J’ai pris une B2ms ainsi qu’une VM Smalldisk afin d’optimiser les coûts étant donné qu’il s’agit d’une petite infra de test.

Ce qui est important c’est la partie réseau. Par défaut, lorsque vous créez une machine virtuelle vous allez avoir un VNet par défaut composé d’un subnet ainsi que d’un NSG (Network Security Group) pour contrôler les flux sur votre VM. Pour autant, dans notre cas de figure, nous souhaitons tout déléguer à notre Azure Firewall. Vous allez donc veiller à créer une machine virtuelle qui ne dispose d’aucun flux ouvert mais aussi et surtout sans NSG.

• MyVNet : 10.1.0.0./16
• Subnet : default 10.1.0.0/24
• Public IP : none
• NSG : none

Vous pouvez adapter ces réglages de votre côté.

Pour l’instant, vous disposez d’une VM mais qui n’est pas accessible depuis Internet puisqu’elle n’a qu’une adresse IP interne (pas d’IP publique et pas non plus de redirections avec un Load Balancer ou n’importe quoi d’autre). Impossible donc de s’y connecter.

Etape 2 : Création de notre Azure Firewall pour gérer les flux entrants

Avant de créer votre Azure Firewall, nous allons devoir créer un Subnet bien précis au sein de notre VNet. C’est un prérequis spécifique que l’on retrouve pour beaucoup de produits SaaS (comme Azure Bastion par exemple que j’avais déjà présenté dans un ancien article).

Dans notre cas, allez dans votre VNet puis dans l’option Subnets, créez un nouveau Subnet en utilisant le menu déroulant pour choisir : AzureFirewallManagementSubnet. Le portail Azure étant bien fait cela va se déployer tout seul avec une configuration IP satisfaisante mais vous pouvez également personnaliser le plan d’adressage.

Renouvelez l’opération pour créer un autre Subnet AzureFirwallSubnet. Le fait de vous faire créer tout ça maintenant va nous éviter des messages d’erreurs plus tard. A la fin, vous devez avoir quelque-chose comme ça le screenshot ci-dessous :

Vous pouvez conserver toutes les autres options avec leurs valeurs par défaut pour notre test.

Maintenant, créons notre Azure Firewall. Cherchez le composant dans le portail Azure et configurez comme indiqué ci-dessous :

Dans mon exemple je suis parti sur une Azure FW de type « Standard » afin que nous ayons un peu plus de choses à configurer que simplement en mode Basic. Créez un nouvel objet Policy (c’est là que nous allons mettre les règles de notre FW), choisissez le VNet que nous avons précédemment créé puis créez également les 2 nouvelles adresses IP publiques qui sont nécessaires pour notre Azure Firewall.

La création d’un Azure FW prend un peu de temps c’est tout à fait normal. 😀

Etape 3 : Création d’une nouvelle règle dans notre Azure Firewall Policy

Un Azure Firewall propose de nombreuses options de gestion des flux mais aussi de sécurité. D’un point de vue modèle OSI, il est capable d’intervenir sur plusieurs couches / niveaux selon le niveau de Azure Firewall que vous avez choisi d’utiliser : Basic, Standard, Premium.

Au point où nous en sommes vous devriez avoir les objets suivants dans votre Resource Group de test (à part le Runbook tout en haut qui n’a rien à voir avec notre test).

Pour l’instant, notre VM n’est pas accessible car elle dispose que d’une adresse IP privée : 10.1.0.4 mais ne possède ni d’adresse IP publique ni NSG. Nous allons donc faire en sorte d’ouvrir pour commencer le port 3389 afin de pouvoir nous connecter en RDP.

Pour ce faire, vous allez vous rendre directement dans l’objet Firewall Policy qui s’appelle dans mon cas : NewAzureFWPolicy.

Dans mon cas, je cherche juste à mettre en évidence la possibilité d’accéder à ma VM Windows Server en RDP et donc sur le port 3389 tout en gérant ce flux via mon Azure Firewall. Dans votre Policy, allez dans la partie DNAT rules. Ajoutez une nouvelle règle avec la configuration suivante :

• Name: RDP
• Source type: IP
• Source IP: * (ou votre adresse IP personnelle de provenance)
• Destination IP: l’adresse IP publique de votre FW (son IP n°1)
• Protocol: TCP
• Destination Ports: 3389
• Translated Type: IP
• Translated Address: l’adresse IP privée de votre VM – dans mon cas, 10.1.0.4

L’application d’une ou plusieurs nouvelles règles peut prendre un moment donc soyez patients dans vos tests. Après quelques instants, il ne vous reste plus qu’à tenter une connexion RDP depuis votre logiciel favori en mettant l’adresse IP publique de votre Azure Firewall et le port 3389… et si tout se passe bien vous aller arriver sur votre machine Windows Server. 😉

Vous êtes parvenus à créer un Azure Firewall (SKU Standard) pour vous permettre d’accéder à une VM en RDP. Pour info, si vous aviez installé sur ce serveur un serveur web IIS sur le port TCP/80, vous pouvez faire une règle tout à fait similaire en remplaçant le port 3389 par le port 80 pour permettre l’accès à ce serveur web.

Autre point également, dans mon cas d’utilisation 1 port ne peut être utilié que pour 1 objet / VM puisque je dispose que d’1 seule adresse IP dans mon Azure Firewall. Mais sachez que vous pouvez ajouter plusieurs adresses IP publiques dans 1 seul et même Azure Firewall. Si vous voulez disposer de plusieurs adresses IP, il vous suffit d’aller dans l’option Public IP configuration et d’ajouter une nouvelle adresse IP publique.

Dans l’étape suivante, je cherche à aller plus loin pour faire en sorte que mon Azure Firewall contrôle aussi les flux sortants (c’est une partie optionnelle).

Etape 4 – Contrôler les flux sortants de la VM (et plus largement de notre VNet)

Par défaut, si vous testez sur votre VM vous verrez que vous pouvez « sortir » librement sur Internet et donc surfer avec Microsoft Edge – et pourtant nous n’avons rien fait pour l’autoriser. Pour vérifier par vous-même, lancez Microsoft Edge sur votre VM de test.

Nous allons donc pousser encore un peu plus loin notre scénario d’utilisation d’Azure Firewall en contrôlant également les flux sortants. Et pour cela, nous allons continuer d’utiliser notre VM pour tester et voir concrètement comment ça se comporte.

Pour empêcher ce comportement, nous devons créer une nouvelle Route et rediriger les flux vers notre Azure Firewall. Dans Azure, cherchez l’objet Route tables et créez une nouvelle Route.

Une fois que l’objet est créé, rendez-vous dans l’option Routes et créez une nouvelle Route avec la configuration ci-dessous :

• Address prefix = 0.0.0.0/0 → Tout le trafic sortant
• Next hop type = Virtual Appliance → On envoie le trafic vers le Firewall
• Next hop IP address = 10.1.1.68 → l’adresse IP privée de mon Azure Firewall

Et enfin, associez là au Subnet qui contient notre machine virtuelle. Dans mon cas, il s’agit de Default.

Désormais, il nous reste à créer une nouvelle règle pour bloquer le surf sur Internet dans notre Azure Firewall.

Désormais, si vous essayez de surfer sur Internet depuis le navigateur Internet de votre VM, vous verrez que le trafic sortant est désormais bloqué !

Conclusion

J’espère qu’au travers de cet article vous aurez une meilleure compréhension de Azure Firewall. Evidemment, pour notre cas d’usage c’est clairement « overkill » à la fois techniquement (juste pour accéder à une VM) mais c’est également aussi très discutable d’un point de vue financier.

En effet, la raison est simple un NSG est presque gratuit et sera capable de faire ce que nous avons vu précédemment (en tout cas la partie DNAT) alors qu’un Azure Firewall en mode Premium peut monter jusqu’à 800 € / mois. Ce composant permet toutefois aller plus loin en proposant par exemple du TLS Inspection.