German - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Az - Azure Network

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Unterstütze HackTricks

Grundlegende Informationen

Netzwerke innerhalb von Azure fungieren als integraler Bestandteil seiner Cloud-Computing-Plattform und ermöglichen die Verbindung und Kommunikation zwischen verschiedenen Azure-Diensten und -Ressourcen. Die Netzwerkarchitektur in Azure ist darauf ausgelegt, hoch skalierbar, sicher und anpassbar zu sein.

Im Kern bietet Azure ein virtuelles Netzwerk (VNet), das es Benutzern ermöglicht, isolierte Netzwerke innerhalb der Azure-Cloud zu erstellen. Innerhalb dieser VNets können Ressourcen wie virtuelle Maschinen, Anwendungen und Datenbanken sicher gehostet und verwaltet werden. Das Netzwerk in Azure unterstützt sowohl die Kommunikation innerhalb der Cloud (zwischen Azure-Diensten) als auch die Verbindung zu externen Netzwerken und dem Internet.

Sicherheit ist ein kritischer Aspekt des Azure-Netzwerks, mit verschiedenen Tools und Diensten zum Schutz von Daten, zur Verwaltung des Zugriffs und zur Gewährleistung der Compliance. Diese Sicherheitsmaßnahmen umfassen Firewalls, Netzwerksicherheitsgruppen und Verschlüsselungsfähigkeiten, die ein hohes Maß an Kontrolle über den Datenverkehr und den Zugriff ermöglichen.

Insgesamt sind die Netzwerkkapazitäten von Azure darauf ausgelegt, Flexibilität zu bieten, sodass Benutzer eine Netzwerkumgebung erstellen können, die ihren spezifischen Anwendungs- und Arbeitslastanforderungen entspricht, während gleichzeitig ein starker Fokus auf Sicherheit und Zuverlässigkeit gelegt wird.

Virtuelles Netzwerk (VNET) & Subnetze

Ein VNet in Azure ist im Wesentlichen eine Darstellung Ihres eigenen Netzwerks in der Cloud. Es ist eine logische Isolation der Azure-Cloud, die Ihrem Abonnement gewidmet ist. Ein VNet ermöglicht es Ihnen, virtuelle private Netzwerke (VPNs) in Azure bereitzustellen und zu verwalten und kann verwendet werden, um verschiedene Arten von Azure-Ressourcen zu hosten und zu verwalten, wie virtuelle Maschinen (VMs), Datenbanken und Anwendungsdienste.

VNets bieten Ihnen volle Kontrolle über Ihre Netzwerkeinstellungen, einschließlich IP-Adressbereiche, Subnetz-Erstellung, Routentabellen und Netzwerk-Gateways.

Ein Subnetz ist ein Bereich von IP-Adressen in Ihrem VNet. Sie können ein VNet in mehrere Subnetze unterteilen, um Organisation und Sicherheit zu gewährleisten. Jedes Subnetz in einem VNet kann verwendet werden, um Ressourcen gemäß Ihrer Netzwerk- und Anwendungsarchitektur zu isolieren und zu gruppieren.

Darüber hinaus ermöglichen Subnetze, Ihr VNet in ein oder mehrere Teilnetzwerke zu segmentieren, die einen Bereich von IP-Adressen bereitstellen, die Ressourcen verwenden können.

Beispiel

  • Angenommen, Sie haben ein VNet namens MyVNet mit einem IP-Adressbereich von 10.0.0.0/16. Sie können ein Subnetz innerhalb dieses VNets erstellen, sagen wir Subnet-1, mit einem IP-Adressbereich von 10.0.0.0/24 für das Hosting Ihrer Webserver. Ein weiteres Subnetz, Subnet-2 mit einem Bereich von 10.0.1.0/24, könnte für Ihre Datenbankserver verwendet werden. Diese Segmentierung ermöglicht eine effiziente Verwaltung und Sicherheitskontrollen innerhalb des Netzwerks.

Aufzählung

Um alle VNets und Subnetze in einem Azure-Konto aufzulisten, können Sie die Azure Command-Line Interface (CLI) verwenden. Hier sind die Schritte:

# 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

Network Security Groups (NSG)

In Azure dient eine Network Security Group (NSG) der Hauptfunktion, den Netzwerkverkehr sowohl zu als auch von Azure-Ressourcen innerhalb eines Azure Virtual Network (VNet) zu filtern. Sie enthält eine Reihe von Sicherheitsregeln, die den Netzwerkverkehr genau vorschreiben.

Wichtige Aspekte der NSG umfassen:

  • Verkehrskontrolle: Jede NSG enthält Regeln, die entscheidend sind, um eingehenden und ausgehenden Netzwerkverkehr, der mit verschiedenen Azure-Ressourcen verbunden ist, entweder zuzulassen oder zu blockieren.

  • Regelkomponenten: Die Regeln innerhalb einer NSG sind sehr spezifisch und filtern den Verkehr basierend auf Kriterien wie Quell-/Ziel-IP-Adresse, Port und Protokoll. Diese Spezifität ermöglicht eine granulare Verwaltung des Netzwerkverkehrs.

  • Sicherheitsverbesserung: Durch die Gewährleistung, dass nur autorisierter Verkehr Ihre Azure-Ressourcen betreten oder verlassen kann, spielen NSGs eine entscheidende Rolle bei der Stärkung der Sicherheitslage Ihrer Netzwerk-Infrastruktur.

Beispiel

  • Stellen Sie sich vor, Sie haben eine NSG namens MyNSG, die auf ein Subnetz oder eine bestimmte virtuelle Maschine innerhalb Ihres VNet angewendet wird. Sie können Regeln erstellen wie:

  • Eine eingehende Regel, die HTTP-Verkehr (Port 80) von jeder Quelle zu Ihren Webservern zulässt.

  • Eine ausgehende Regel, die nur SQL-Verkehr (Port 1433) zu einem bestimmten Ziel-IP-Adressbereich zulässt.

Enumeration

# 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 ist ein verwalteter, cloudbasierter Netzwerksicherheitsdienst, der Ihre Azure Virtual Network-Ressourcen schützt. Es ist eine vollständig zustandsbehaftete Firewall als Dienst mit integrierten Hochverfügbarkeits- und Skalierbarkeitsfunktionen.

Azure Firewall bietet fortschrittlichere Funktionen als NSGs, einschließlich Anwendungsfilterung, Netzwerkfilterung, Bedrohungsintelligenz-basierte Filterung und Integration mit Azure Monitor für Protokollierung und Analysen. Es kann ausgehenden, eingehenden, spoke-to-spoke, VPN- und ExpressRoute-Verkehr filtern. Firewall-Regeln können basierend auf FQDN (Fully Qualified Domain Name), IP-Adressen und Ports erstellt werden.

Unterschiede zwischen Azure Firewall und NSGs

  1. Umfang:

  • NSG: Arbeitet auf Subnetz- oder Netzwerkschnittstellenebene. Es soll eine grundlegende Filterung des eingehenden und ausgehenden Datenverkehrs von Netzwerkschnittstellen (NIC), VMs oder Subnetzen bieten.

  • Azure Firewall: Arbeitet auf VNet-Ebene und bietet einen breiteren Schutzumfang. Es ist darauf ausgelegt, Ihre virtuellen Netzwerkressourcen zu sichern und den Datenverkehr, der in und aus dem VNet fließt, zu verwalten.

  1. Fähigkeiten:

  • NSG: Bietet grundlegende Filterfunktionen basierend auf IP-Adresse, Port und Protokoll. Es unterstützt keine erweiterten Funktionen wie Anwendungsinspektion oder Bedrohungsintelligenz.

  • Azure Firewall: Bietet erweiterte Funktionen wie Anwendungsfilterung (Layer 7), Bedrohungsintelligenz-basierte Filterung, Netzwerkverkehrsfilterung und mehr. Es unterstützt auch mehrere öffentliche IP-Adressen.

  1. Anwendungsfälle:

  • NSG: Ideal für grundlegende Netzwerkverkehrsfilterung.

  • Azure Firewall: Geeignet für komplexere Filterungsszenarien, bei denen Anwendungssteuerung, Protokollierung und Bedrohungsintelligenz erforderlich sind.

  1. Verwaltung und Überwachung:

  • NSG: Bietet grundlegende Protokollierung und Integration mit Azure Monitor.

  • Azure Firewall: Bietet erweiterte Protokollierungs- und Analysefunktionen über Azure Monitor, was für das Verständnis der Art und des Musters des Datenverkehrs unerlässlich ist.

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

Network Virtual Appliance (NVA)

Ein Network Virtual Appliance (NVA) in Azure ist ein virtuelles Gerät, das Netzwerkfunktionen innerhalb eines virtuellen Netzwerks ausführt. NVAs werden typischerweise für Netzwerkfunktionen verwendet, die nicht nativ in Azure verfügbar sind oder wenn mehr Anpassung erforderlich ist. Sie sind im Wesentlichen VMs, die Netzwerk-Anwendungen oder -Dienste ausführen, wie Firewalls, WAN-Optimierer oder Load Balancer.

NVAs werden für komplexe Routing-, Sicherheits- und Netzwerkverkehrsmanagement-Aufgaben verwendet. Sie können aus dem Azure Marketplace bereitgestellt werden, wo viele Drittanbieter ihre Appliances zur Integration in Azure-Umgebungen anbieten.

Beispiel

  • Eine Organisation kann ein NVA in Azure bereitstellen, um eine benutzerdefinierte Firewall-Lösung zu erstellen. Dieses NVA könnte eine Drittanbieter-Firewall-Software ausführen, die erweiterte Funktionen wie Intrusion Detection, Paketinspektion oder VPN-Konnektivität bietet. Das NVA kann so konfiguriert werden, dass es den durchlaufenden Datenverkehr inspiziert und filtert, um sicherzustellen, dass erweiterte Sicherheitsmaßnahmen gemäß den Richtlinien der Organisation vorhanden sind.

Enumeration

# 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

Azure Route Tables & User Defined Routes (UDR)

Azure Route Tables sind eine Funktion innerhalb von Microsoft Azure, die die Kontrolle des Netzwerkverkehrs innerhalb von Azure Virtual Networks (VNets) ermöglicht. Im Wesentlichen definieren sie, wie Pakete zwischen Subnetzen innerhalb von VNets, zwischen VNets oder zu externen Netzwerken weitergeleitet werden. Jede Routentabelle enthält eine Reihe von Regeln, die als Routen bekannt sind und festlegen, wie Pakete basierend auf ihren Ziel-IP-Adressen weitergeleitet werden sollen.

User Defined Routes (UDR) in Azure sind benutzerdefinierte Routen, die Sie innerhalb von Azure Route Tables erstellen, um den Fluss des Netzwerkverkehrs innerhalb und zwischen Azure Virtual Networks (VNets) und zu externen Verbindungen zu steuern. UDRs bieten Ihnen die Flexibilität, den Netzwerkverkehr gemäß Ihren spezifischen Anforderungen zu lenken und die standardmäßigen Routing-Entscheidungen von Azure zu überschreiben.

Diese Routen sind besonders nützlich in Szenarien, in denen Sie den Verkehr durch ein virtuelles Gerät leiten, einen bestimmten Pfad aus Sicherheits- oder Richtliniengründen erzwingen oder mit lokalen Netzwerken integrieren müssen.

Beispiel

  • Angenommen, Sie haben ein Network Virtual Appliance (NVA) bereitgestellt, um den Verkehr zwischen Subnetzen innerhalb eines VNet zu inspizieren. Sie können eine UDR erstellen, die den gesamten Verkehr von einem Subnetz zu einem anderen Subnetz durch das NVA leitet. Diese UDR stellt sicher, dass das NVA den Verkehr aus Sicherheitsgründen inspiziert, bevor er sein Ziel erreicht.

Enumeration

# 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 ist ein Dienst in Azure, der privaten Zugriff auf Azure-Dienste ermöglicht, indem er sicherstellt, dass der Datenverkehr zwischen Ihrem Azure Virtual Network (VNet) und dem Dienst vollständig innerhalb des Azure-Backbone-Netzwerks von Microsoft bleibt. Es bringt den Dienst effektiv in Ihr VNet. Diese Konfiguration erhöht die Sicherheit, indem die Daten nicht dem öffentlichen Internet ausgesetzt werden.

Private Link kann mit verschiedenen Azure-Diensten verwendet werden, wie Azure Storage, Azure SQL Database und benutzerdefinierten Diensten, die über Private Link geteilt werden. Es bietet eine sichere Möglichkeit, Dienste innerhalb Ihres eigenen VNets oder sogar aus verschiedenen Azure-Abonnements zu nutzen.

NSGs gelten nicht für private Endpunkte, was eindeutig bedeutet, dass die Zuordnung eines NSG zu einem Subnetz, das den Private Link enthält, keine Wirkung hat.

Beispiel

  • Betrachten Sie ein Szenario, in dem Sie eine Azure SQL Database sicher von Ihrem VNet aus zugreifen möchten. Normalerweise könnte dies den öffentlichen Internetverkehr umfassen. Mit Private Link können Sie einen privaten Endpunkt in Ihrem VNet erstellen, der direkt mit dem Azure SQL Database-Dienst verbunden ist. Dieser Endpunkt lässt die Datenbank so erscheinen, als wäre sie Teil Ihres eigenen VNets, zugänglich über eine private IP-Adresse, und gewährleistet so einen sicheren und privaten Zugriff.

Enumeration

# 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

Azure Service Endpoints

Azure Service Endpoints erweitern den privaten Adressraum Ihres virtuellen Netzwerks und die Identität Ihres VNet zu Azure-Diensten über eine direkte Verbindung. Durch das Aktivieren von Service-Endpunkten können Ressourcen in Ihrem VNet sicher mit Azure-Diensten wie Azure Storage und Azure SQL Database über das Backbone-Netzwerk von Azure verbinden. Dies stellt sicher, dass der Datenverkehr vom VNet zum Azure-Dienst innerhalb des Azure-Netzwerks bleibt, was einen sichereren und zuverlässigeren Pfad bietet.

Beispiel

  • Zum Beispiel ist ein Azure Storage-Konto standardmäßig über das öffentliche Internet zugänglich. Durch das Aktivieren eines Service-Endpunkts für Azure Storage innerhalb Ihres VNet können Sie sicherstellen, dass nur Datenverkehr von Ihrem VNet auf das Speicherkonto zugreifen kann. Die Firewall des Speicherkontos kann dann so konfiguriert werden, dass sie nur Datenverkehr von Ihrem VNet akzeptiert.

Enumeration

# 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

Unterschiede zwischen Service Endpoints und Private Links

Microsoft empfiehlt die Verwendung von Private Links in den Dokumentationen:\

Service Endpoints:

  • Der Datenverkehr von Ihrem VNet zum Azure-Dienst erfolgt über das Microsoft Azure-Backbone-Netzwerk und umgeht das öffentliche Internet.

  • Der Endpoint ist eine direkte Verbindung zum Azure-Dienst und stellt keine private IP für den Dienst innerhalb des VNet bereit.

  • Der Dienst selbst ist weiterhin über seinen öffentlichen Endpoint von außerhalb Ihres VNet zugänglich, es sei denn, Sie konfigurieren die Dienst-Firewall so, dass solcher Datenverkehr blockiert wird.

  • Es besteht eine Eins-zu-Eins-Beziehung zwischen dem Subnetz und dem Azure-Dienst.

  • Günstiger als Private Links.

Private Links:

  • Private Link ordnet Azure-Dienste über einen privaten Endpoint, der eine Netzwerkschnittstelle mit einer privaten IP-Adresse innerhalb Ihres VNet ist, Ihrem VNet zu.

  • Der Azure-Dienst wird über diese private IP-Adresse aufgerufen, wodurch er so erscheint, als wäre er Teil Ihres Netzwerks.

  • Dienste, die über Private Link verbunden sind, können nur von Ihrem VNet oder verbundenen Netzwerken aus aufgerufen werden; es gibt keinen öffentlichen Internetzugang zum Dienst.

  • Es ermöglicht eine sichere Verbindung zu Azure-Diensten oder Ihren eigenen in Azure gehosteten Diensten sowie eine Verbindung zu von anderen geteilten Diensten.

  • Es bietet eine granularere Zugriffskontrolle über einen privaten Endpoint in Ihrem VNet im Gegensatz zu einer breiteren Zugriffskontrolle auf Subnetzebene mit Service Endpoints.

Zusammenfassend lässt sich sagen, dass sowohl Service Endpoints als auch Private Links eine sichere Konnektivität zu Azure-Diensten bieten, Private Links jedoch ein höheres Maß an Isolation und Sicherheit bieten, indem sie sicherstellen, dass Dienste privat aufgerufen werden, ohne sie dem öffentlichen Internet auszusetzen. Service Endpoints hingegen sind einfacher einzurichten für allgemeine Fälle, in denen ein einfacher, sicherer Zugriff auf Azure-Dienste erforderlich ist, ohne dass eine private IP im VNet benötigt wird.

Azure Front Door (AFD) & AFD WAF

Azure Front Door ist ein skalierbarer und sicherer Einstiegspunkt für die schnelle Bereitstellung Ihrer globalen Webanwendungen. Es kombiniert verschiedene Dienste wie globales Load Balancing, Site-Beschleunigung, SSL-Offloading und Web Application Firewall (WAF)-Funktionen in einem einzigen Dienst. Azure Front Door bietet intelligentes Routing basierend auf dem nächstgelegenen Edge-Standort zum Benutzer, um optimale Leistung und Zuverlässigkeit zu gewährleisten. Darüber hinaus bietet es URL-basiertes Routing, Hosting mehrerer Sites, Sitzungsaffinität und Sicherheit auf Anwendungsebene.

Azure Front Door WAF ist darauf ausgelegt, Webanwendungen vor web-basierten Angriffen zu schützen, ohne den Backend-Code zu ändern. Es umfasst benutzerdefinierte Regeln und verwaltete Regelsets, um Bedrohungen wie SQL-Injection, Cross-Site-Scripting und andere häufige Angriffe abzuwehren.

Beispiel

  • Stellen Sie sich vor, Sie haben eine global verteilte Anwendung mit Benutzern auf der ganzen Welt. Sie können Azure Front Door verwenden, um Benutzeranfragen zum nächstgelegenen regionalen Rechenzentrum zu leiten, das Ihre Anwendung hostet, wodurch die Latenz verringert, die Benutzererfahrung verbessert und die Anwendung mit den WAF-Funktionen vor Webangriffen geschützt wird. Wenn eine bestimmte Region einen Ausfall erlebt, kann Azure Front Door den Datenverkehr automatisch zum nächstbesten Standort umleiten, um eine hohe Verfügbarkeit sicherzustellen.

Enumeration

# 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

Azure Application Gateway und Azure Application Gateway WAF

Azure Application Gateway ist ein Web-Traffic-Load-Balancer, der es Ihnen ermöglicht, den Traffic zu Ihren Web-Anwendungen zu verwalten. Es bietet Layer-7-Load-Balancing, SSL-Termination und Web Application Firewall (WAF) Fähigkeiten im Application Delivery Controller (ADC) als Service. Wichtige Funktionen umfassen URL-basiertes Routing, Cookie-basierte Sitzungsaffinität und Secure Sockets Layer (SSL) Offloading, die für Anwendungen, die komplexe Load-Balancing-Fähigkeiten wie globales Routing und pfadbasiertes Routing erfordern, entscheidend sind.

Beispiel

  • Betrachten Sie ein Szenario, in dem Sie eine E-Commerce-Website haben, die mehrere Subdomains für verschiedene Funktionen umfasst, wie Benutzerkonten und Zahlungsabwicklung. Azure Application Gateway kann Traffic basierend auf dem URL-Pfad zu den entsprechenden Webservern routen. Zum Beispiel könnte Traffic zu example.com/accounts zum Benutzerkonten-Service geleitet werden, und Traffic zu example.com/pay könnte zum Zahlungsabwicklungs-Service geleitet werden. Und schützen Sie Ihre Website vor Angriffen mit den WAF-Fähigkeiten.

Enumeration

# 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

VNet Peering ist eine Netzwerkfunktion in Azure, die es ermöglicht, verschiedene Virtual Networks (VNets) direkt und nahtlos zu verbinden. Durch VNet Peering können Ressourcen in einem VNet mit Ressourcen in einem anderen VNet unter Verwendung privater IP-Adressen kommunizieren, als ob sie sich im selben Netzwerk befänden. VNet Peering kann auch mit On-Prem-Netzwerken verwendet werden, indem ein Site-to-Site-VPN oder Azure ExpressRoute eingerichtet wird.

Azure Hub and Spoke ist eine Netzwerktopologie, die in Azure verwendet wird, um den Netzwerkverkehr zu verwalten und zu organisieren. Der "Hub" ist ein zentraler Punkt, der den Verkehr zwischen verschiedenen "Spokes" steuert und routet. Der Hub enthält typischerweise gemeinsame Dienste wie Network Virtual Appliances (NVAs), Azure VPN Gateway, Azure Firewall oder Azure Bastion. Die "Spokes" sind VNets, die Workloads hosten und sich über VNet Peering mit dem Hub verbinden, wodurch sie die gemeinsamen Dienste im Hub nutzen können. Dieses Modell fördert eine saubere Netzwerkstruktur und reduziert die Komplexität, indem gemeinsame Dienste zentralisiert werden, die von mehreren Workloads in verschiedenen VNets genutzt werden können.

VNET Peering ist in Azure nicht transitiv, was bedeutet, dass wenn Spoke 1 mit Spoke 2 verbunden ist und Spoke 2 mit Spoke 3 verbunden ist, Spoke 1 nicht direkt mit Spoke 3 kommunizieren kann.

Beispiele

  • Stellen Sie sich ein Unternehmen mit separaten Abteilungen wie Vertrieb, Personalwesen und Entwicklung vor, jede mit ihrem eigenen VNet (den Spokes). Diese VNets benötigen Zugriff auf gemeinsame Ressourcen wie eine zentrale Datenbank, eine Firewall und ein Internet-Gateway, die sich alle in einem anderen VNet (dem Hub) befinden. Durch die Verwendung des Hub-and-Spoke-Modells kann jede Abteilung sicher auf die gemeinsamen Ressourcen über das Hub-VNet zugreifen, ohne diese Ressourcen dem öffentlichen Internet auszusetzen oder eine komplexe Netzwerkstruktur mit zahlreichen Verbindungen zu erstellen.

Enumeration

# 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

Site-to-Site VPN

Ein Site-to-Site VPN in Azure ermöglicht es Ihnen, Ihr lokales Netzwerk mit Ihrem Azure Virtual Network (VNet) zu verbinden, sodass Ressourcen wie VMs in Azure erscheinen, als wären sie in Ihrem lokalen Netzwerk. Diese Verbindung wird durch ein VPN-Gateway hergestellt, das den Datenverkehr zwischen den beiden Netzwerken verschlüsselt.

Beispiel

  • Ein Unternehmen mit Hauptsitz in New York hat ein lokales Rechenzentrum, das sicher mit seinem VNet in Azure verbunden werden muss, das seine virtualisierten Workloads hostet. Durch die Einrichtung eines Site-to-Site VPN kann das Unternehmen eine verschlüsselte Verbindung zwischen den lokalen Servern und den Azure VMs sicherstellen, sodass Ressourcen sicher in beiden Umgebungen zugegriffen werden können, als wären sie im selben lokalen Netzwerk.

Enumeration

# 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 ist ein Dienst, der eine private, dedizierte, hochgeschwindigkeits Verbindung zwischen Ihrer lokalen Infrastruktur und Azure-Rechenzentren bietet. Diese Verbindung wird über einen Konnektivitätsanbieter hergestellt, der das öffentliche Internet umgeht und mehr Zuverlässigkeit, höhere Geschwindigkeiten, geringere Latenzen und höhere Sicherheit als typische Internetverbindungen bietet.

Beispiel

  • Ein multinationales Unternehmen benötigt eine konsistente und zuverlässige Verbindung zu seinen Azure-Diensten aufgrund des hohen Datenvolumens und des Bedarfs an hoher Durchsatzrate. Das Unternehmen entscheidet sich für Azure ExpressRoute, um sein lokales Rechenzentrum direkt mit Azure zu verbinden, was groß angelegte Datenübertragungen wie tägliche Backups und Echtzeit-Datenanalysen mit erhöhter Privatsphäre und Geschwindigkeit erleichtert.

Enumeration

# List ExpressRoute Circuits
az network express-route list --query "[].{name:name, location:location, resourceGroup:resourceGroup, serviceProviderName:serviceProviderName, peeringLocation:peeringLocation}" -o table

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Unterstütze HackTricks
PreviousAz - Virtual Machines & NetworkNextAz - Permissions for a Pentest

Last updated