Français - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Az - Azure Network

Support HackTricks

Basic Information

Les réseaux au sein d'Azure fonctionnent comme une partie intégrante de sa plateforme de cloud computing, permettant la connexion et la communication entre divers services et ressources Azure. L'architecture réseau dans Azure est conçue pour être hautement évolutive, sécurisée et personnalisable.

Au cœur d'Azure, il existe un réseau virtuel (VNet) qui permet aux utilisateurs de créer des réseaux isolés au sein du cloud Azure. Dans ces VNets, des ressources telles que des machines virtuelles, des applications et des bases de données peuvent être hébergées et gérées en toute sécurité. Le réseau dans Azure prend en charge à la fois la communication au sein du cloud (entre les services Azure) et la connexion à des réseaux externes et à Internet.

La sécurité est un aspect critique du réseau Azure, avec divers outils et services disponibles pour protéger les données, gérer l'accès et garantir la conformité. Ces mesures de sécurité incluent des pare-feu, des groupes de sécurité réseau et des capacités de chiffrement, permettant un haut niveau de contrôle sur le trafic et l'accès.

Dans l'ensemble, les capacités de mise en réseau d'Azure sont conçues pour offrir de la flexibilité, permettant aux utilisateurs de créer un environnement réseau qui répond à leurs besoins spécifiques en matière d'application et de charge de travail tout en maintenant un fort accent sur la sécurité et la fiabilité.

Virtual Network (VNET) & Subnets

Un VNet dans Azure est essentiellement une représentation de votre propre réseau dans le cloud. C'est une isolation logique du cloud Azure dédiée à votre abonnement. Un VNet vous permet de provisionner et de gérer des réseaux privés virtuels (VPN) dans Azure et peut être utilisé pour héberger et gérer plusieurs types de ressources Azure, telles que des machines virtuelles (VM), des bases de données et des services d'application.

Les VNets vous donnent un contrôle total sur vos paramètres réseau, y compris les plages d'adresses IP, la création de sous-réseaux, les tables de routage et les passerelles réseau.

Un sous-réseau est une plage d'adresses IP dans votre VNet. Vous pouvez diviser un VNet en plusieurs sous-réseaux pour l'organisation et la sécurité. Chaque sous-réseau dans un VNet peut être utilisé pour isoler et regrouper des ressources selon votre architecture réseau et application.

De plus, les sous-réseaux vous permettent de segmenter votre VNet en un ou plusieurs sous-réseaux, fournissant une plage d'adresses IP que les ressources peuvent utiliser.

Example

  • Supposons que vous ayez un VNet nommé MyVNet avec une plage d'adresses IP de 10.0.0.0/16. Vous pouvez créer un sous-réseau au sein de ce VNet, disons Subnet-1, avec une plage d'adresses IP de 10.0.0.0/24 pour héberger vos serveurs web. Un autre sous-réseau, Subnet-2 avec une plage de 10.0.1.0/24, pourrait être utilisé pour vos serveurs de base de données. Cette segmentation permet une gestion efficace et des contrôles de sécurité au sein du réseau.

Enumeration

Pour lister tous les VNets et sous-réseaux dans un compte Azure, vous pouvez utiliser l'interface de ligne de commande Azure (CLI). Voici les étapes :

# List VNets
az network vnet list --query "[].{name:name, location:location, addressSpace:addressSpace}" -o table

# List subnets of a VNet
az network vnet subnet list --resource-group <ResourceGroupName> --vnet-name <VNetName> --query "[].{name:name, addressPrefix:addressPrefix}" -o table

Groupes de Sécurité Réseau (NSG)

Dans Azure, un Groupe de Sécurité Réseau (NSG) a pour fonction principale de filtrer le trafic réseau tant vers que depuis les ressources Azure au sein d'un Réseau Virtuel Azure (VNet). Il contient un ensemble de règles de sécurité qui dictent minutieusement le flux du trafic réseau.

Les aspects clés des NSG incluent :

  • Contrôle du Trafic : Chaque NSG contient des règles qui sont essentielles pour permettre ou bloquer le trafic réseau entrant et sortant associé à diverses ressources Azure.

  • Composants de Règle : Les règles au sein d'un NSG sont très spécifiques, filtrant le trafic en fonction de critères tels que l'adresse IP source/destination, le port et le protocole. Cette spécificité permet une gestion granulaire du trafic réseau.

  • Amélioration de la Sécurité : En veillant à ce que seul le trafic autorisé puisse entrer ou sortir de vos ressources Azure, les NSG jouent un rôle crucial dans le renforcement de la posture de sécurité de votre infrastructure réseau.

Exemple

  • Imaginez que vous ayez un NSG nommé MyNSG appliqué à un sous-réseau ou à une machine virtuelle spécifique au sein de votre VNet. Vous pouvez créer des règles comme :

  • Une règle entrante permettant le trafic HTTP (port 80) de n'importe quelle source vers vos serveurs web.

  • Une règle sortante permettant uniquement le trafic SQL (port 1433) vers une plage d'adresses IP de destination spécifique.

Énumération

# List NSGs
az network nsg list --query "[].{name:name, location:location}" -o table

# Get NSG rules
az network nsg rule list --nsg-name <NSGName> --resource-group <ResourceGroupName> --query "[].{name:name, priority:priority, direction:direction, access:access, protocol:protocol, sourceAddressPrefix:sourceAddressPrefix, destinationAddressPrefix:destinationAddressPrefix, sourcePortRange:sourcePortRange, destinationPortRange:destinationPortRange}" -o table

Azure Firewall

Azure Firewall est un service de sécurité réseau géré et basé sur le cloud qui protège vos ressources Azure Virtual Network. C'est un pare-feu entièrement stateful en tant que service avec des fonctionnalités intégrées de haute disponibilité et d'évolutivité.

Azure Firewall fournit des fonctionnalités plus avancées que les NSGs, y compris le filtrage au niveau des applications, le filtrage au niveau du réseau, le filtrage basé sur l'intelligence des menaces, et l'intégration avec Azure Monitor pour la journalisation et l'analyse. Il peut filtrer le trafic sortant, entrant, entre les spokes, VPN et ExpressRoute. Des règles de pare-feu peuvent être créées en fonction du FQDN (Nom de Domaine Entièrement Qualifié), des adresses IP et des ports.

Différences entre Azure Firewall et NSGs

  1. Portée :

  • NSG : Fonctionne au niveau du sous-réseau ou de l'interface réseau. Il est destiné à fournir un filtrage de base du trafic entrant et sortant des interfaces réseau (NIC), des VMs ou des sous-réseaux.

  • Azure Firewall : Opère au niveau du VNet, offrant une portée de protection plus large. Il est conçu pour sécuriser vos ressources de réseau virtuel et gérer le trafic entrant et sortant du VNet.

  1. Capacités :

  • NSG : Fournit des capacités de filtrage de base basées sur l'adresse IP, le port et le protocole. Il ne prend pas en charge des fonctionnalités avancées comme l'inspection au niveau des applications ou l'intelligence des menaces.

  • Azure Firewall : Offre des fonctionnalités avancées comme le filtrage du trafic au niveau des applications (couche 7), le filtrage basé sur l'intelligence des menaces, le filtrage du trafic réseau, et plus encore. Il prend également en charge plusieurs adresses IP publiques.

  1. Cas d'utilisation :

  • NSG : Idéal pour le filtrage de trafic de base au niveau du réseau.

  • Azure Firewall : Adapté à des scénarios de filtrage plus complexes où un contrôle au niveau des applications, la journalisation et l'intelligence des menaces sont nécessaires.

  1. Gestion et Surveillance :

  • NSG : Offre une journalisation de base et une intégration avec Azure Monitor.

  • Azure Firewall : Fournit des capacités avancées de journalisation et d'analyse via Azure Monitor, ce qui est essentiel pour comprendre la nature et le modèle du trafic.

Enumeration

# List Azure Firewalls
az network firewall list --query "[].{name:name, location:location, subnet:subnet, publicIp:publicIp}" -o table

# Get network rules of a firewall
az network firewall network-rule collection list --firewall-name <FirewallName> --resource-group <ResourceGroupName> --query "[].{name:name, rules:rules}" -o table

# Get application rules of a firewall
az network firewall application-rule collection list --firewall-name <FirewallName> --resource-group <ResourceGroupName> --query "[].{name:name, rules:rules}" -o table

# Get nat rules of a firewall
az network firewall nat-rule collection list --firewall-name <FirewallName> --resource-group <ResourceGroupName> --query "[].{name:name, rules:rules}" -o table

Appliance Virtuel Réseau (NVA)

Un Appliance Virtuel Réseau (NVA) dans Azure est un appliance virtuel qui effectue des fonctions réseau au sein d'un réseau virtuel. Les NVAs sont généralement utilisés pour des fonctions réseau qui ne sont pas disponibles nativement dans Azure ou lorsque plus de personnalisation est requise. Ils sont essentiellement des VMs qui exécutent des applications ou des services réseau, tels que des pare-feu, des optimiseurs WAN ou des équilibreurs de charge.

Les NVAs sont utilisés pour des tâches complexes de routage, de sécurité et de gestion du trafic réseau. Ils peuvent être déployés depuis le Marketplace Azure, où de nombreux fournisseurs tiers proposent leurs appliances prêtes à être intégrées dans des environnements Azure.

Exemple

  • Une organisation peut déployer un NVA dans Azure pour créer une solution de pare-feu personnalisée. Ce NVA pourrait exécuter un logiciel de pare-feu tiers, offrant des fonctionnalités avancées telles que la détection d'intrusions, l'inspection des paquets ou la connectivité VPN. Le NVA peut être configuré pour inspecter et filtrer le trafic qui le traverse, garantissant que des mesures de sécurité renforcées sont en place conformément aux politiques de l'organisation.

Énumération

# Usually NVAs are named or tagged in a way to distinguish them from other VMs
az vm list --query "[].{name:name, resourceGroup:resourceGroup, location:location}" -o table

# For a specific VM identified as an NVA, list its network interfaces
az vm nic list --vm-name <VMName> --resource-group <ResourceGroupName> --query "[].{id:id}" -o table

Tables de routage Azure & Routes définies par l'utilisateur (UDR)

Les tables de routage Azure sont une fonctionnalité de Microsoft Azure qui permet de contrôler le routage du trafic réseau au sein des réseaux virtuels Azure (VNets). Essentiellement, elles définissent comment les paquets sont transférés entre les sous-réseaux au sein des VNets, entre les VNets, ou vers des réseaux externes. Chaque table de routage contient un ensemble de règles, appelées routes, qui spécifient comment les paquets doivent être routés en fonction de leurs adresses IP de destination.

Les routes définies par l'utilisateur (UDR) dans Azure sont des routes personnalisées que vous créez au sein des tables de routage Azure pour contrôler le flux de trafic réseau au sein et entre les réseaux virtuels Azure (VNets), et vers des connexions externes. Les UDR vous offrent la flexibilité de diriger le trafic réseau selon vos besoins spécifiques, en remplaçant les décisions de routage par défaut d'Azure.

Ces routes sont particulièrement utiles pour des scénarios où vous devez router le trafic à travers un appareil virtuel, imposer un chemin spécifique pour la sécurité ou la conformité aux politiques, ou intégrer des réseaux sur site.

Exemple

  • Supposons que vous ayez déployé un appareil virtuel réseau (NVA) pour inspecter le trafic entre les sous-réseaux au sein d'un VNet. Vous pouvez créer une UDR qui dirige tout le trafic d'un sous-réseau à un autre sous-réseau à passer par le NVA. Cette UDR garantit que le NVA inspecte le trafic à des fins de sécurité avant qu'il n'atteigne sa destination.

Énumération

# List Route Tables
az network route-table list --query "[].{name:name, resourceGroup:resourceGroup, location:location}" -o table

# List UDRs for a table
az network route-table route list --route-table-name <RouteTableName> --resource-group <ResourceGroupName> --query "[].{name:name, addressPrefix:addressPrefix, nextHopType:nextHopType, nextHopIpAddress:nextHopIpAddress}" -o table

Azure Private Link

Azure Private Link est un service dans Azure qui permet un accès privé aux services Azure en garantissant que le trafic entre votre réseau virtuel Azure (VNet) et le service circule entièrement au sein du réseau backbone de Microsoft Azure. Cela intègre efficacement le service dans votre VNet. Cette configuration améliore la sécurité en ne rendant pas les données accessibles sur Internet public.

Private Link peut être utilisé avec divers services Azure, comme Azure Storage, Azure SQL Database, et des services personnalisés partagés via Private Link. Il fournit un moyen sécurisé de consommer des services depuis votre propre VNet ou même depuis différentes abonnements Azure.

Les NSG ne s'appliquent pas aux points de terminaison privés, ce qui signifie clairement qu'associer un NSG à un sous-réseau contenant le Private Link n'aura aucun effet.

Exemple

  • Considérez un scénario où vous avez une base de données Azure SQL à laquelle vous souhaitez accéder de manière sécurisée depuis votre VNet. Normalement, cela pourrait impliquer de traverser Internet public. Avec Private Link, vous pouvez créer un point de terminaison privé dans votre VNet qui se connecte directement au service de base de données Azure SQL. Ce point de terminaison fait apparaître la base de données comme si elle faisait partie de votre propre VNet, accessible via une adresse IP privée, garantissant ainsi un accès sécurisé et privé.

Énumération

# List Private Link Services
z network private-link-service list --query "[].{name:name, location:location, resourceGroup:resourceGroup}" -o table

# List Private Endpoints
az network private-endpoint list --query "[].{name:name, location:location, resourceGroup:resourceGroup, privateLinkServiceConnections:privateLinkServiceConnections}" -o table

Points de terminaison de service Azure

Les points de terminaison de service Azure étendent l'espace d'adresses privées de votre réseau virtuel et l'identité de votre VNet aux services Azure via une connexion directe. En activant les points de terminaison de service, les ressources de votre VNet peuvent se connecter en toute sécurité aux services Azure, comme Azure Storage et Azure SQL Database, en utilisant le réseau backbone d'Azure. Cela garantit que le trafic du VNet vers le service Azure reste au sein du réseau Azure, offrant un chemin plus sécurisé et fiable.

Exemple

  • Par exemple, un compte Azure Storage est par défaut accessible via Internet public. En activant un point de terminaison de service pour Azure Storage au sein de votre VNet, vous pouvez vous assurer que seul le trafic de votre VNet peut accéder au compte de stockage. Le pare-feu du compte de stockage peut alors être configuré pour accepter le trafic uniquement de votre VNet.

Énumération

# List Virtual Networks with Service Endpoints
az network vnet list --query "[].{name:name, location:location, serviceEndpoints:serviceEndpoints}" -o table

# List Subnets with Service Endpoints
az network vnet subnet list --resource-group <ResourceGroupName> --vnet-name <VNetName> --query "[].{name:name, serviceEndpoints:serviceEndpoints}" -o table

Différences entre les points de terminaison de service et les liens privés

Microsoft recommande d'utiliser les liens privés dans les docs:\

Points de terminaison de service :

  • Le trafic de votre VNet vers le service Azure circule sur le réseau backbone de Microsoft Azure, contournant l'internet public.

  • Le point de terminaison est une connexion directe au service Azure et ne fournit pas d'IP privée pour le service au sein du VNet.

  • Le service lui-même est toujours accessible via son point de terminaison public depuis l'extérieur de votre VNet, sauf si vous configurez le pare-feu du service pour bloquer ce type de trafic.

  • C'est une relation un à un entre le sous-réseau et le service Azure.

  • Moins coûteux que les liens privés.

Liens privés :

  • Le lien privé mappe les services Azure dans votre VNet via un point de terminaison privé, qui est une interface réseau avec une adresse IP privée au sein de votre VNet.

  • Le service Azure est accessible en utilisant cette adresse IP privée, ce qui le fait apparaître comme s'il faisait partie de votre réseau.

  • Les services connectés via le lien privé ne peuvent être accessibles que depuis votre VNet ou des réseaux connectés ; il n'y a pas d'accès à l'internet public pour le service.

  • Il permet une connexion sécurisée aux services Azure ou à vos propres services hébergés dans Azure, ainsi qu'une connexion aux services partagés par d'autres.

  • Il fournit un contrôle d'accès plus granulaire via un point de terminaison privé dans votre VNet, par opposition à un contrôle d'accès plus large au niveau du sous-réseau avec des points de terminaison de service.

En résumé, bien que les points de terminaison de service et les liens privés offrent une connectivité sécurisée aux services Azure, les liens privés offrent un niveau d'isolation et de sécurité supérieur en garantissant que les services sont accessibles de manière privée sans les exposer à l'internet public. Les points de terminaison de service, en revanche, sont plus faciles à configurer pour des cas généraux où un accès simple et sécurisé aux services Azure est requis sans avoir besoin d'une IP privée dans le VNet.

Azure Front Door (AFD) & AFD WAF

Azure Front Door est un point d'entrée évolutif et sécurisé pour la livraison rapide de vos applications web mondiales. Il combine divers services tels que l'équilibrage de charge mondial, l'accélération de site, le déchargement SSL et les capacités de pare-feu d'application web (WAF) en un seul service. Azure Front Door fournit un routage intelligent basé sur la localisation de bord la plus proche de l'utilisateur, garantissant des performances et une fiabilité optimales. De plus, il offre un routage basé sur l'URL, l'hébergement de plusieurs sites, l'affinité de session et la sécurité au niveau de l'application.

Azure Front Door WAF est conçu pour protéger les applications web contre les attaques basées sur le web sans modification du code de back-end. Il comprend des règles personnalisées et des ensembles de règles gérées pour se protéger contre des menaces telles que l'injection SQL, le cross-site scripting et d'autres attaques courantes.

Exemple

  • Imaginez que vous avez une application distribuée mondialement avec des utilisateurs partout dans le monde. Vous pouvez utiliser Azure Front Door pour diriger les demandes des utilisateurs vers le centre de données régional le plus proche hébergeant votre application, réduisant ainsi la latence, améliorant l'expérience utilisateur et la protégeant contre les attaques web avec les capacités WAF. Si une région particulière connaît une panne, Azure Front Door peut automatiquement rediriger le trafic vers le meilleur emplacement suivant, garantissant une haute disponibilité.

Énumération

# List Azure Front Door Instances
az network front-door list --query "[].{name:name, resourceGroup:resourceGroup, location:location}" -o table

# List Front Door WAF Policies
az network front-door waf-policy list --query "[].{name:name, resourceGroup:resourceGroup, location:location}" -o table

Passerelle d'application Azure et WAF de la passerelle d'application Azure

La passerelle d'application Azure est un équilibreur de charge de trafic web qui vous permet de gérer le trafic vers vos applications web. Elle offre des capacités d'équilibrage de charge de couche 7, de terminaison SSL et de pare-feu d'application web (WAF) dans le contrôleur de livraison d'application (ADC) en tant que service. Les fonctionnalités clés incluent le routage basé sur l'URL, l'affinité de session basée sur les cookies et le déchargement de la couche de sockets sécurisés (SSL), qui sont cruciaux pour les applications nécessitant des capacités d'équilibrage de charge complexes telles que le routage global et le routage basé sur le chemin.

Exemple

  • Considérez un scénario où vous avez un site web de commerce électronique qui comprend plusieurs sous-domaines pour différentes fonctions, telles que les comptes utilisateurs et le traitement des paiements. La passerelle d'application Azure peut router le trafic vers les serveurs web appropriés en fonction du chemin de l'URL. Par exemple, le trafic vers example.com/accounts pourrait être dirigé vers le service des comptes utilisateurs, et le trafic vers example.com/pay pourrait être dirigé vers le service de traitement des paiements. Et protégez votre site web contre les attaques en utilisant les capacités WAF.

Énumération

# List the Web Application Firewall configurations for your Application Gateways
az network application-gateway waf-config list --gateway-name <AppGatewayName> --resource-group <ResourceGroupName> --query "[].{name:name, firewallMode:firewallMode, ruleSetType:ruleSetType, ruleSetVersion:ruleSetVersion}" -o table

Azure Hub, Spoke & VNet Peering

Le Peering VNet est une fonctionnalité de mise en réseau dans Azure qui permet à différents Réseaux Virtuels (VNets) d'être connectés directement et de manière transparente. Grâce au peering VNet, les ressources dans un VNet peuvent communiquer avec des ressources dans un autre VNet en utilisant des adresses IP privées, comme si elles étaient dans le même réseau. Le Peering VNet peut également être utilisé avec des réseaux sur site en configurant un VPN site-à-site ou Azure ExpressRoute.

Azure Hub et Spoke est une topologie de réseau utilisée dans Azure pour gérer et organiser le trafic réseau. Le "hub" est un point central qui contrôle et dirige le trafic entre différents "spokes". Le hub contient généralement des services partagés tels que des appliances virtuelles réseau (NVA), Azure VPN Gateway, Azure Firewall ou Azure Bastion. Les "spokes" sont des VNets qui hébergent des charges de travail et se connectent au hub via le peering VNet, leur permettant de tirer parti des services partagés au sein du hub. Ce modèle favorise une disposition réseau claire, réduisant la complexité en centralisant les services communs que plusieurs charges de travail à travers différents VNets peuvent utiliser.

Le peering VNET est non transitif dans Azure, ce qui signifie que si le spoke 1 est connecté au spoke 2 et que le spoke 2 est connecté au spoke 3, alors le spoke 1 ne peut pas communiquer directement avec le spoke 3.

Exemples

  • Imaginez une entreprise avec des départements séparés comme Ventes, RH et Développement, chacun avec son propre VNet (les spokes). Ces VNets ont besoin d'accéder à des ressources partagées comme une base de données centrale, un pare-feu et une passerelle Internet, qui se trouvent tous dans un autre VNet (le hub). En utilisant le modèle Hub et Spoke, chaque département peut se connecter en toute sécurité aux ressources partagées via le VNet hub sans exposer ces ressources à Internet public ou créer une structure réseau complexe avec de nombreuses connexions.

Énumération

# List all VNets in your subscription
az network vnet list --query "[].{name:name, location:location, addressSpace:addressSpace}" -o table

# List VNet peering connections for a given VNet
az network vnet peering list --resource-group <ResourceGroupName> --vnet-name <VNetName> --query "[].{name:name, peeringState:peeringState, remoteVnetId:remoteVnetId}" -o table

# List Shared Resources (e.g., Azure Firewall) in the Hub
az network firewall list --query "[].{name:name, location:location, resourceGroup:resourceGroup}" -o table

VPN Site-à-Site

Un VPN Site-à-Site dans Azure vous permet de connecter votre réseau local à votre réseau virtuel Azure (VNet), permettant aux ressources telles que les VM dans Azure d'apparaître comme si elles étaient sur votre réseau local. Cette connexion est établie via une passerelle VPN qui crypte le trafic entre les deux réseaux.

Exemple

  • Une entreprise dont le bureau principal est situé à New York dispose d'un centre de données sur site qui doit se connecter de manière sécurisée à son VNet dans Azure, qui héberge ses charges de travail virtualisées. En configurant un VPN Site-à-Site, l'entreprise peut garantir une connectivité cryptée entre les serveurs sur site et les VM Azure, permettant un accès sécurisé aux ressources à travers les deux environnements comme si elles étaient sur le même réseau local.

Énumération

# List VPN Gateways
az network vnet-gateway list --query "[].{name:name, location:location, resourceGroup:resourceGroup}" -o table

# List VPN Connections
az network vpn-connection list --gateway-name <VpnGatewayName> --resource-group <ResourceGroupName> --query "[].{name:name, connectionType:connectionType, connectionStatus:connectionStatus}" -o table

Azure ExpressRoute

Azure ExpressRoute est un service qui fournit une connexion privée, dédiée et à haute vitesse entre votre infrastructure sur site et les centres de données Azure. Cette connexion est établie par l'intermédiaire d'un fournisseur de connectivité, contournant l'internet public et offrant plus de fiabilité, des vitesses plus rapides, des latences plus faibles et une sécurité accrue par rapport aux connexions internet typiques.

Exemple

  • Une multinationale nécessite une connexion cohérente et fiable à ses services Azure en raison du volume élevé de données et du besoin d'un débit élevé. L'entreprise opte pour Azure ExpressRoute pour connecter directement son centre de données sur site à Azure, facilitant les transferts de données à grande échelle, tels que les sauvegardes quotidiennes et l'analyse de données en temps réel, avec une confidentialité et une vitesse améliorées.

Énumération

# List ExpressRoute Circuits
az network express-route list --query "[].{name:name, location:location, resourceGroup:resourceGroup, serviceProviderName:serviceProviderName, peeringLocation:peeringLocation}" -o table
Soutenir HackTricks
PreviousAz - Virtual Machines & NetworkNextAz - Permissions for a Pentest

Last updated