Az - Azure Netwerk

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Basiese Inligting

Azure provides virtual networks (VNet) wat gebruikers toelaat om geïsoleerde netwerke binne die Azure cloud te skep. Binne hierdie VNets kan hulpbronne soos Virtual Machines (VMs), toepassings, databasisse
 veilig gehuisves en bestuur word. Die netwerkinfrastruktuur in Azure ondersteun beide kommunikasie binne die cloud (tussen Azure services) en die verbinding na eksterne netwerke en die internet.
Verder is dit moontlik om VNets met ander VNets en met on-premise netwerke te verbind.

Virtual Network (VNET) & Subnets

An Azure Virtual Network (VNet) is ’n voorstelling van jou eie netwerk in die cloud, wat logiese isolasie binne die Azure-omgewing bied wat aan jou subskripsie gewy is. VNets laat jou toe om virtual private networks (VPNs) in Azure te voorsien en te bestuur, en hulpbronne soos Virtual Machines (VMs), databasisse en toepassingsdienste te huisves. Hulle bied volle beheer oor netwerkinstellings, insluitend IP address ranges, subnet creation, route tables, en network gateways.

Subnets is onderverdelings binne ’n VNet, gedefinieer deur spesifieke IP address ranges. Deur ’n VNet in verskeie subnets te segmenteer, kan jy hulpbronne organiseer en beveilig volgens jou netwerkargitektuur.
By verstek kan alle subnets binne dieselfde Azure Virtual Network (VNet) met mekaar kommunikeer sonder enige beperkings.

Voorbeeld:

  • MyVNet with an IP address range of 10.0.0.0/16.
  • Subnet-1: 10.0.0.0/24 for web servers.
  • Subnet-2: 10.0.1.0/24 for database servers.

Enumeration

To list all the VNets and subnets in an Azure account, you can use the Azure Command-Line Interface (CLI). Here are the steps:

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

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

Netwerksekuriteitsgroepe (NSG)

’n Network Security Group (NSG) filtreer netwerkverkeer beide na en van Azure-hulpbronne binne ’n Azure Virtual Network (VNet). Dit bevat ’n stel sekuriteitsreĂ«ls wat kan aandui watter poorte oopgemaak moet word vir inkomende en uitgaande verkeer volgens bronpoort, bron-IP, bestemmingspoort en dit is moontlik om ’n prioriteit toe te ken (hoe laer die prioriteitsnommer, hoe hoĂ«r die prioriteit).

NSGs can be associated to subnets and NICs.

Voorbeelde van reëls:

  • ’n Inkomende reĂ«l wat HTTP-verkeer (poort 80) van enige bron na jou webbedieners toelaat.
  • ’n Uitgaande reĂ«l wat slegs SQL-verkeer (poort 1433) na ’n spesifieke bestemmings-IP-adresreeks toelaat.

Enumeration

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

# 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

# Get NICs and subnets using this NSG
az network nsg show --name <NSGName> --resource-group <ResourceGroupName> --query "{subnets: subnets, networkInterfaces: networkInterfaces}"

Azure Firewall

Azure Firewall is a beheerde, staatgebaseerde firewall wat verkeer filtreer (L3–L7) vir oos-wes en noord-suid vloei. Ingeplant op die VNet level, sentraliseer dit inspeksie vir alle subnets en skaal dit outomaties vir beskikbaarheid.

Beskikbare SKUs: Basic, Standard, en Premium:

Criteria/FeatureOption 1Option 2Option 3
Recommended Use CaseKlein/Middelgroot Besighede (SMBs) met beperkte behoeftesAlgemene ondernemingsgebruik, Laag 3–7 filtereringBaie sensitiewe omgewings (bv. betalingverwerking)
PerformanceTot 250 Mbps deursyferTot 30 Gbps deursyferTot 100 Gbps deursyfer
Threat IntelligenceSlegs waarskuwingsWaarskuwings en blokkering (kwaadwillige IP’s/domeine)Waarskuwings en blokkering (gevorderde dreigintelligensie)
L3–L7 FilteringBasiese filtereringStaatgebaseerde filterering oor protokolleStaatgebaseerde filterering met gevorderde inspeksie
Advanced Threat ProtectionNie beskikbaar nieDreigintelligensie-gebaseerde filtereringSluit Intrusion Detection and Prevention System (IDPS) in
TLS InspectionNie beskikbaar nieNie beskikbaar nieOndersteun inkomende/uitgaande TLS-terminasie
AvailabilityVaste backend (2 VMs)AutoskaalAutoskaal
Ease of ManagementBasiese beheerBeheer via Firewall ManagerBeheer via Firewall Manager

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

Azure Route Tables

Azure Route Tables (UDR) laat jou toe om standaardroetering te oorskryf deur bestemmingsvoorvoegsels te definieer (bv. 10.0.0.0/16 of 0.0.0.0/0) en ’n volgende hop (Virtual Network, Internet, Virtual Network Gateway, of Virtual Appliance).

Roetes geld op subnet-vlak; alle VMs in daardie subnet volg die tabel.

Voorbeeld:

  • Vir internetbestemde verkeer, gebruik die standaard 0.0.0.0/0 met Internet as volgende hop.
  • Om uitgaande verkeer te inspekteer, lei 0.0.0.0/0 na ’n Network Virtual Appliance (NVA) IP.

Enumerasie

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

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

# List routes for a table (full)
az network route-table route list --resource-group <ResourceGroupName> --route-table-name <RouteTableName>

Azure Private Link is a service in Azure that enableer privaat toegang tot Azure-dienste deur te verseker dat verkeer tussen jou Azure virtuele netwerk (VNet) en die diens heeltemal binne Microsoft se Azure-ruggraatnetwerk reis. Dit bring die diens effektief in jou VNet. Hierdie opstelling verbeter sekuriteit deur die data nie aan die openbare internet bloot te stel nie.

Private Link kan gebruik word met verskeie Azure-dienste, soos Azure Storage, Azure SQL Database, en pasgemaakte dienste wat via Private Link gedeel word. Dit bied ’n veilige manier om dienste vanaf jou eie VNet of selfs vanaf verskillende Azure-subskripsies te verbruik.

Caution

NSGs is nie van toepassing op private endpoints nie, wat duidelik beteken dat die assosiasie van ’n NSG met ’n subnet wat die Private Link bevat, geen effek sal hĂȘ nie.

Voorbeeld:

Oorweeg ’n scenario waar jy ’n Azure SQL Database het wat jy veilig vanaf jou VNet wil toegang kry. Normaalweg sou dit dalk die openbare internet vereis. Met Private Link kan jy ’n private endpoint in jou VNet skep wat direk aan die Azure SQL Database-diens koppel. Hierdie endpoint laat die databasis voorkom asof dit deel is van jou eie VNet, toeganklik via ’n private IP-adres, en verseker dus veilige en privaat toegang.

Enumeration

# List Private Link Services
az 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

Wanneer ’n VNet ’n Virtual Network Link na ’n service Private DNS zone het (bv. privatelink.blob.core.windows.net), dwing Azure dat hostname resolution vir Private Link‑geregistreerde hulpbronne van daardie dienstoort deur die zone plaasvind. As die zone nie die vereiste A record vir ’n hulpbron bevat wat werkladinge steeds via sy publieke endpoint bereik nie, gee DNS‑resolusie NXDOMAIN terug en bereik kliĂ«nte nooit die publieke IP nie, wat ’n availability DoS veroorsaak sonder om die hulpbron self aan te raak.

Abuse flow (control-plane DoS):

  1. Verkry RBAC wat toelaat om Private Endpoints te skep of Private DNS zone links te wysig.
  2. Skep ’n Private Endpoint vir dieselfde dienstoort in ’n ander VNet (Azure skep outomaties die service Private DNS zone en koppel dit aan daardie VNet).
  3. Koppel daardie service Private DNS zone aan die slagoffer‑VNet.
  4. Omdat die slagoffer‑VNet nou dwing resolusie via die Private DNS zone en daar geen A record vir die teikenhulpbron in daardie zone bestaan nie, misluk naamresolusie en kan die werklading nie die (nog publieke) endpoint bereik nie. Dit geld vir enige Private Link–ondersteunde diens (storage, Key Vault, ACR, Cosmos DB, Function Apps, OpenAI, ens.).

Discovery at scale (Azure Resource Graph):

  • VNETs wat gekoppel is aan die blob Private DNS zone (gedwonge resolusie vir PL‑registered blob endpunte):
resources
| where type == "microsoft.network/privatednszones/virtualnetworklinks"
| extend
zone = tostring(split(id, "/virtualNetworkLinks")[0]),
vnetId = tostring(properties.virtualNetwork.id)
| join kind=inner (
resources
| where type == "microsoft.network/privatednszones"
| where name == "privatelink.blob.core.windows.net"
| project zoneId = id
) on $left.zone == $right.zoneId
| project vnetId
  • Stoorrekeninge wat via ’n publieke endpoint bereikbaar is, maar sonder Private Endpoint-verbindinge (sal waarskynlik breek as bogenoemde skakel bygevoeg word):
Resources
| where type == "microsoft.storage/storageaccounts"
| extend publicNetworkAccess = properties.publicNetworkAccess
| extend defaultAction = properties.networkAcls.defaultAction
| extend vnetRules = properties.networkAcls.virtualNetworkRules
| extend ipRules = properties.networkAcls.ipRules
| extend privateEndpoints = properties.privateEndpointConnections
| where publicNetworkAccess == "Enabled"
| where defaultAction == "Deny"
| where (isnull(privateEndpoints) or array_length(privateEndpoints) == 0)
| extend allowedVnets = iif(isnull(vnetRules), 0, array_length(vnetRules))
| extend allowedIps = iif(isnull(ipRules), 0, array_length(ipRules))
| where allowedVnets > 0 or allowedIps > 0
| project id, name, vnetRules, ipRules

Azure Service Endpoints

Azure Service Endpoints brei jou virtuele netwerk se privaat adresruimte en die identiteit van jou VNet uit na Azure-dienste oor ’n direkte verbinding. Deur Service Endpoints te aktiveer, kan hulpbronne in jou VNet veilig met Azure-dienste verbind, soos Azure Storage en Azure SQL Database, oor die Azure backbone-netwerk. Dit is besonder nuttig wanneer dit saam met Network Security Groups (NSGs) gebruik word vir gedetailleerde verkeersbeheer.

Voorbeeld:

  • Met ’n Storage Account en Service Endpoint geaktiveer in ’n VNET, is dit moontlik om inkomende verkeer slegs vanaf ’n VNET in die storage account firewall toe te laat, wat ’n veilige verbinding afdwing sonder dat publieke IP-toegang tot die storage-diens nodig is.

Service Endpoints vereis nie private IP-adresse vir die dienste nie en vertrou in plaas daarvan op die Azure backbone vir veilige konneksie. Hulle is makliker om op te stel in vergelyking met Private Links maar bied nie dieselfde vlak van isolasie en granulariteit as Private Links nie.

Enumerasie

# 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}"

# List Service Endpoints for a Subnet
az network vnet subnet show --resource-group <ResourceGroupName> --vnet-name <VNetName> --name <SubnetName> --query "serviceEndpoints"

Microsoft beveel aan om Private Links te gebruik in die docs:

Service Endpoints:

  • Verkeer van jou VNet na die Azure service reis oor die Microsoft Azure backbone-netwerk en omseil die openbare internet.
  • Die endpoint is ’n direkte verbinding na die Azure service en verskaf nie ’n private IP vir die service binne die VNet nie.
  • Die service self is steeds toeganklik via sy openbare endpoint van buite jou VNet, tensy jy die service se firewall konfigureer om so ’n verkeer te blokkeer.
  • Dit is ’n een-tot-een verhouding tussen die subnet en die Azure service.
  • Minder duur as Private Links.

Private Links:

  • Private Link karteer Azure services in jou VNet deur ’n private endpoint, wat ’n netwerk-koppelvlak met ’n private IP-adres binne jou VNet is.
  • Die Azure service word via hierdie private IP-adres bereik, wat dit laat voorkom asof dit deel is van jou netwerk.
  • Services wat via Private Link gekoppel is, kan slegs vanaf jou VNet of gekoppelde netwerke bereik word; daar is geen openbare internettoegang na die service nie.
  • Dit maak ’n veilige verbinding na Azure services of jou eie services wat in Azure gehost word moontlik, sowel as ’n verbinding na services wat deur ander gedeel word.
  • Dit verskaf meer fynkorrelige toegangsbeheer via ’n private endpoint in jou VNet, teenoor wyer toegangsbeheer op subnet-vlak met service endpoints.

In opsomming: alhoewel beide Service Endpoints en Private Links veilige konnektiwiteit na Azure services bied, bied Private Links ’n hoĂ«r vlak van isolasie en sekuriteit deur te verseker dat services privaat bereik word sonder om hulle aan die openbare internet bloot te stel. Service Endpoints is daarenteen makliker om op te stel vir algemene gevalle waar eenvoudige, veilige toegang tot Azure services benodig word sonder die behoefte aan ’n private IP in die VNet.

Azure Front Door (AFD) & AFD WAF

Azure Front Door is ’n skaalbare en veilige toegangspunt vir die vinnige lewering van jou wĂȘreldwye webtoepassings. Dit kombineer verskeie dienste soos application acceleration, SSL offloading, en application layer security (deur Web Application Firewall - WAF). Dit is gebou op die konsep van edge POP (Point of Presence)-lokasies regoor die wĂȘreld om jou toepassings nader aan jou gebruikers te bring.

Azure Front Door voorsien ’n wĂȘreldwyd verspreide netwerk van edge-lokasies om inkomende verkeer na jou webtoepassings (in Azure of elders) te lei en te versnel, prestasie te verbeter, en sekuriteit te versterk.

Voorbeeld:

  • Vir ’n wĂȘreldwye e-handelsplatform met gebruikers regoor die wĂȘreld, kan Azure Front Door statiese inhoud by edge-lokasies cache en SSL offloading bied, wat latensie verminder en ’n meer reageerende gebruikerservaring gee. Dit verskaf ook WAF om jou toepassings te beskerm teen algemene web-kwesbaarhede (soos SQL injection of XSS).

Azure Front Door bied ook smart load balancing deur verkeer na die naaste beskikbare backend te route op grond van health probes en latensie, wat konsekwente prestasie en beskikbaarheid verseker. Deur WAF te integreer, help dit om te beskerm teen algemene webbedreigings.

Enumeration

# List Azure Front Door profiles
az afd profile list --query "[].{name:name, location:location, resourceGroup:resourceGroup}" -o table

# List AFD endpoints
az afd endpoint list --profile-name <ProfileName> --resource-group <ResourceGroupName> --query "[].{name:name, hostName:hostName, state:resourceState}" -o table

# Classic Azure Front Door (v1) profiles
az network front-door list --query "[].{name:name, resourceGroup:resourceGroup, location:location}" -o table

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

Azure Application Gateway and Azure Application Gateway WAF

Azure Application Gateway is ’n belastingbalanserer vir webverkeer wat jou in staat stel om verkeer na jou web toepassings te bestuur. Dit bied Layer 7 load balancing, SSL-terminering, en webtoepassing-firewall (WAF)-vermoĂ«ns in die Application Delivery Controller (ADC) as ’n diens. Belangrike kenmerke sluit URL-gebaseerde routering, koekie-gebaseerde sessie-affiniteit, en Secure Sockets Layer (SSL)-offloading in, wat noodsaaklik is vir toepassings wat komplekse load-balancing vermoĂ«ns benodig soos globale routering en padgebaseerde routering.

Example:

Oorweeg ’n scenario waar jy ’n e-handelswebwerf het wat verskeie subdomeine vir verskillende funksies insluit, soos gebruikersrekeninge en betalingsverwerking. Azure Application Gateway kan verkeer na die toepaslike webbedieners router op grond van die URL-pad. Byvoorbeeld, verkeer na example.com/accounts kan na die gebruikersrekeninge-diens gestuur word, en verkeer na example.com/pay kan na die betalingsverwerkingsdiens gestuur word.
En beskerm jou webwerf teen aanvalle deur die WAF-vermoëns te gebruik.

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

VNet Peering & HUB and Spoke topologieë

VNet Peering

VNet Peering is ’n funksie in Azure wat toelaat dat verskillende Virtual Networks (VNets) direk en naatloos verbind word. Deur VNet peering kan hulpbronne in een VNet kommunikeer met hulpbronne in ’n ander VNet met privaat IP-adresse, asof hulle in dieselfde netwerk is.\
VNet Peering kan ook met on-prem netwerke gebruik word deur ’n site-to-site VPN of Azure ExpressRoute op te stel.

Azure Hub and Spoke is ’n netwerkargitektuur wat VNet peering gebruik om ’n sentrale Hub VNet te skep wat aan veelvuldige Spoke VNets koppel. Die hub bevat tipies gedeelde dienste (soos firewalls, DNS of Active Directory), terwyl spokes toepassingswerkladinge huisves. Hierdie ontwerp vereenvoudig bestuur, verbeter sekuriteit deur gesentraliseerde kontroles, en verminder redundansie.

Voorbeeld:

’n Groot onderneming met verskeie departemente (Finance, HR, IT) kan ’n Hub VNet met gedeelde dienste skep soos firewalls en DNS-bedieners. Elke departement kan sy eie Spoke VNet hĂȘ wat via peering aan die Hub koppel. Dit laat departemente toe om veilig te kommunikeer en gedeelde dienste te gebruik sonder om hul hulpbronne aan die openbare internet bloot te stel.

Enumeration

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

# List VNet Peerings
az network vnet peering list --resource-group <ResourceGroupName> --vnet-name <VNetName> --query "[].{name:name, remoteVnetId:remoteVirtualNetwork.id, allowForwardedTraffic:allowForwardedTraffic, allowGatewayTransit:allowGatewayTransit}"

# 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

’n Site-to-Site VPN in Azure skep ’n veilige en bestande verbinding vanaf jou on-premises netwerk na jou Azure Virtual Network (VNet), wat hulpbronne soos VMs binne Azure laat voorkom asof hulle op jou plaaslike netwerk is. Hierdie verbinding word gevestig deur ’n VPN gateway wat verkeer enkripteer tussen die twee netwerke.

Voorbeeld:

’n Besigheid met sy hoofkantoor in New York het ’n on-premises datacentrum wat veilig aan sy VNet in Azure moet koppel, wat sy gevirtualiseerde werksladinge aanbied. Deur ’n Site-to-Site VPN op te stel, kan die maatskappy versleutelde konnektiwiteit verseker tussen die on-premises bedieners en die Azure VMs, wat toelaat dat hulpbronne veilig oor beide omgewings toeganglik is asof dit in dieselfde plaaslike netwerk is.

Enumerasie

# 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 is ’n diens wat ’n private, toegewyde, hoĂ«spoed-verbinding tussen jou plaaslike infrastruktuur en Azure datacenters bied. Hierdie verbinding word deur ’n verbindingsverskaffer gerealiseer, wat die openbare internet omseil en meer betroubaarheid, vinniger snelhede, laer latensies en hoĂ«r sekuriteit as tipiese internetverbindinge bied.

Voorbeeld:

’n Multinasionale korporasie benodig ’n konsekwente en betroubare verbinding na sy Azure-dienste as gevolg van die hoĂ« datavolume en die behoefte aan hoĂ« deurset. Die maatskappy kies Azure ExpressRoute om sy plaaslike datacenter direk met Azure te verbind, wat grootskaalse data-oordragte vergemaklik, soos daaglikse rugsteun en real-time data-analise, met verbeterde privaatheid en spoed.

Enumeration

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

Verwysings

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks