Az - Azure Network
Tip
Ucz się & ćwicz AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
Wspieraj HackTricks
- Sprawdź subscription plans!
- Dołącz do 💬 Discord group lub telegram group lub śledź nas na Twitterze 🐦 @hacktricks_live.
- Podziel się hacking tricks, zgłaszając PRy do HackTricks i HackTricks Cloud github repos.
Podstawowe informacje
Azure zapewnia virtual networks (VNet), które pozwalają użytkownikom tworzyć izolowane sieci w chmurze Azure. W obrębie tych VNetów zasoby takie jak maszyny wirtualne, aplikacje, bazy danych… mogą być bezpiecznie hostowane i zarządzane. Sieciowanie w Azure obsługuje zarówno komunikację wewnątrz chmury (między usługami Azure), jak i połączenia z sieciami zewnętrznymi oraz internetem.
Dodatkowo możliwe jest łączenie VNetów z innymi VNetami oraz z sieciami on-premise.
Virtual Network (VNET) i podsieci
Azure Virtual Network (VNet) to odwzorowanie Twojej sieci w chmurze, zapewniające logiczna izolację w środowisku Azure przypisanym do Twojego subskrypcji. VNety pozwalają na provision i zarządzanie wirtualnymi sieciami prywatnymi (VPN) w Azure, hostując zasoby takie jak Virtual Machines (VMs), bazy danych i usługi aplikacyjne. Dają one pełną kontrolę nad ustawieniami sieci, włączając zakresy adresów IP, tworzenie podsieci, tabele routingu oraz bramy sieciowe.
Subnets to podziały w obrębie VNetu, zdefiniowane przez konkretne zakresy adresów IP. Segmentując VNet na wiele podsieci, możesz organizować i zabezpieczać zasoby zgodnie z architekturą sieci.
Domyślnie wszystkie podsieci w ramach tej samej Azure Virtual Network (VNet) mogą się ze sobą komunikować bez żadnych ograniczeń.
Przykład:
MyVNetz zakresem adresów IP 10.0.0.0/16.- Subnet-1: 10.0.0.0/24 dla serwerów WWW.
- Subnet-2: 10.0.1.0/24 dla serwerów baz danych.
Enumeracja
Aby wypisać wszystkie VNety i podsieci w koncie Azure, możesz użyć Azure Command-Line Interface (CLI). Oto kroki:
# 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
Grupy zabezpieczeń sieciowych (NSG)
A Grupa zabezpieczeń sieciowych (NSG) filtruje ruch sieciowy zarówno do, jak i z zasobów Azure w ramach Azure Virtual Network (VNet). Zawiera zestaw reguł bezpieczeństwa, które mogą określać które porty otworzyć dla ruchu przychodzącego i wychodzącego według portu źródłowego, IP źródłowego, portu docelowego oraz umożliwia przypisanie priorytetu (niższy numer priorytetu = wyższy priorytet).
NSG mogą być powiązane z subnetami i NIC.
Przykłady reguł:
- Reguła przychodząca zezwalająca na ruch HTTP (port 80) z dowolnego źródła do Twoich serwerów WWW.
- Reguła wychodząca zezwalająca tylko na ruch SQL (port 1433) do określonego zakresu adresów IP docelowych.
Enumeracja
# 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 to zarządzalny, stanowy firewall, który filtruje ruch (L3–L7) dla przepływów east–west i north–south. Wdrażany na poziomie VNet, centralizuje inspekcję dla wszystkich podsieci i automatycznie skaluje się dla dostępności.
Dostępne SKU: Basic, Standard i Premium:
| Kryterium/Funkcja | Opcja 1 | Opcja 2 | Opcja 3 |
|---|---|---|---|
| Zalecany przypadek użycia | Małe/Średnie przedsiębiorstwa (SMB) o ograniczonych potrzebach | Ogólne użycie w przedsiębiorstwie, filtrowanie warstw 3–7 | Bardzo wrażliwe środowiska (np. przetwarzanie płatności) |
| Wydajność | Do 250 Mbps przepustowości | Do 30 Gbps przepustowości | Do 100 Gbps przepustowości |
| Inteligencja zagrożeń | Tylko alerty | Alerty i blokowanie (złośliwe IP/domeny) | Alerty i blokowanie (zaawansowana inteligencja zagrożeń) |
| Filtrowanie L3–L7 | Podstawowe filtrowanie | Stanowe filtrowanie między protokołami | Stanowe filtrowanie z zaawansowaną inspekcją |
| Zaawansowana ochrona | Niedostępne | Filtrowanie oparte na inteligencji zagrożeń | Zawiera System wykrywania i zapobiegania włamaniom (IDPS) |
| Inspekcja TLS | Niedostępne | Niedostępne | Obsługuje terminację TLS przychodzącą/wychodzącą |
| Dostępność | Stały backend (2 VM) | Autoskalowanie | Autoskalowanie |
| Łatwość zarządzania | Podstawowe sterowanie | Zarządzane przez Firewall Manager | Zarządzane przez 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 Tablice tras
Azure Route Tables (UDR) pozwalają nadpisać domyślne trasowanie przez zdefiniowanie prefiksów docelowych (np. 10.0.0.0/16 lub 0.0.0.0/0) oraz next hop (Virtual Network, Internet, Virtual Network Gateway, or Virtual Appliance).
Trasy obowiązują na poziomie subnetu; wszystkie VMs w tym subnecie stosują się do tabeli.
Przykład:
- Dla ruchu wychodzącego do internetu użyj domyślnego
0.0.0.0/0z Internet jako next hop. - Aby przeanalizować ruch wychodzący, skieruj
0.0.0.0/0do adresu IP Network Virtual Appliance (NVA).
Enumeracja
# 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
Azure Private Link to usługa w Azure, która umożliwia prywatny dostęp do usług Azure poprzez zapewnienie, że ruch między Twoją Azure virtual network (VNet) a usługą przebiega w całości w ramach szkieletowej sieci Azure firmy Microsoft. W praktyce przenosi usługę do Twojego VNet. Takie rozwiązanie zwiększa bezpieczeństwo, nie wystawiając danych na publiczny internet.
Private Link może być używany z różnymi usługami Azure, takimi jak Azure Storage, Azure SQL Database oraz usługami niestandardowymi udostępnianymi przez Private Link. Zapewnia bezpieczny sposób korzystania z usług z poziomu własnego VNet lub nawet z różnych subskrypcji Azure.
Caution
NSGs nie dotyczą private endpoints, co wyraźnie oznacza, że powiązanie NSG z podsiecią, która zawiera Private Link, nie będzie miało żadnego efektu.
Przykład:
Rozważ scenariusz, w którym masz Azure SQL Database, do której chcesz uzyskać bezpieczny dostęp z poziomu swojego VNet. Zwykle mogłoby to wymagać przejścia przez publiczny internet. Dzięki Private Link możesz utworzyć private endpoint w swoim VNet, który łączy się bezpośrednio z usługą Azure SQL Database. Ten endpoint sprawia, że baza danych wygląda tak, jakby była częścią Twojego VNet, dostępna przez prywatny adres IP, zapewniając tym samym bezpieczny i prywatny dostęp.
Enumeracja
# 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
DNS OverDoS via service Private DNS zone links
When a VNet has a Virtual Network Link to a service Private DNS zone (e.g., privatelink.blob.core.windows.net), Azure forces hostname resolution for Private Link registered resources of that service type through the zone. If the zone lacks the required A record for a resource that workloads still access via its public endpoint, DNS resolution returns NXDOMAIN and clients never reach the public IP, causing an availability DoS without touching the resource itself.
Przebieg nadużycia (control-plane DoS):
- Uzyskaj RBAC pozwalające na tworzenie Private Endpoints lub modyfikowanie Private DNS zone links.
- Utwórz Private Endpoint dla tego samego typu usługi w innym VNet (Azure automatycznie tworzy the service Private DNS zone i powiązuje ją z tym VNet).
- Powiąż tę service Private DNS zone z VNetem ofiary.
- Ponieważ VNet ofiary teraz wymusza rozwiązywanie przez Private DNS zone i w tej strefie nie istnieje rekord
Adla docelowego zasobu, rozwiązywanie nazw zawodzi i workload nie może osiągnąć (wciąż publicznego) endpointu. Dotyczy to każdej usługi obsługiwanej przez Private Link (storage, Key Vault, ACR, Cosmos DB, Function Apps, OpenAI, itp.).
Odkrywanie na dużą skalę (Azure Resource Graph):
- VNETs linked to the blob Private DNS zone (forced resolution for PL-registered blob endpoints):
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
- Storage accounts osiągalne przez public endpoint, ale bez połączeń Private Endpoint (prawdopodobnie przestanie działać, jeśli powyższy link zostanie dodany):
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 rozszerzają prywatną przestrzeń adresową twojej wirtualnej sieci oraz tożsamość twojego VNet na usługi Azure za pomocą bezpośredniego połączenia. Po włączeniu Service Endpoints, zasoby w twoim VNet mogą bezpiecznie łączyć się z usługami Azure, takimi jak Azure Storage i Azure SQL Database, przez sieć szkieletową Azure. Jest to szczególnie przydatne w połączeniu z Network Security Groups (NSGs) dla szczegółowej kontroli ruchu.
Example:
- Gdy Storage Account i Service Endpoint są włączone w VNET, można zezwolić na ruch przychodzący tylko z VNET określonego w storage account firewall, wymuszając bezpieczne połączenie bez potrzeby dostępu do usługi storage przez publiczny adres IP.
Service Endpoints nie wymagają prywatnych adresów IP dla usług i zamiast tego opierają się na sieci szkieletowej Azure dla bezpiecznej łączności. Są łatwiejsze w konfiguracji niż Private Links, ale nie zapewniają tego samego poziomu izolacji i granularności co Private Links.
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}"
# List Service Endpoints for a Subnet
az network vnet subnet show --resource-group <ResourceGroupName> --vnet-name <VNetName> --name <SubnetName> --query "serviceEndpoints"
Różnice między Service Endpoints a Private Links
Microsoft zaleca używanie Private Links w docs:
.png)
Service Endpoints:
- Ruch z twojego VNet do usługi Azure przechodzi przez szkieletową sieć Microsoft Azure, omijając publiczny Internet.
- Endpoint jest bezpośrednim połączeniem z usługą Azure i nie zapewnia prywatnego adresu IP dla usługi wewnątrz VNet.
- Sama usługa nadal jest dostępna poprzez swój publiczny endpoint spoza twojego VNet, chyba że skonfigurujesz firewall usługi, aby blokował taki ruch.
- To relacja jeden-do-jednego między subnetem a usługą Azure.
- Tańsze niż Private Links.
Private Links:
- Private Link mapuje usługi Azure do twojego VNet za pomocą private endpoint, który jest interfejsem sieciowym z prywatnym adresem IP w ramach twojego VNet.
- Do usługi Azure uzyskuje się dostęp przy użyciu tego prywatnego adresu IP, co sprawia, że wygląda, jakby była częścią twojej sieci.
- Usługi podłączone przez Private Link można uzyskiwać tylko z twojego VNet lub sieci połączonych; nie ma publicznego dostępu z Internetu do tej usługi.
- Umożliwia bezpieczne połączenie z usługami Azure lub twoimi usługami hostowanymi w Azure, jak również połączenie z usługami udostępnionymi przez innych.
- Zapewnia bardziej szczegółową kontrolę dostępu za pomocą private endpoint w twoim VNet, w przeciwieństwie do szerszej kontroli dostępu na poziomie subnetu w przypadku Service Endpoints.
Podsumowując, chociaż zarówno Service Endpoints, jak i Private Links zapewniają bezpieczne łącze do usług Azure, Private Links oferują wyższy poziom izolacji i bezpieczeństwa, zapewniając prywatny dostęp do usług bez ich wystawiania na publiczny Internet. Service Endpoints z kolei są prostsze do skonfigurowania w przypadkach, gdy potrzebny jest ogólny, bezpieczny dostęp do usług Azure bez konieczności posiadania prywatnego adresu IP w VNet.
Azure Front Door (AFD) & AFD WAF
Azure Front Door to skalowalny i bezpieczny punkt wejścia dla szybkiego dostarczania twoich globalnych aplikacji webowych. Łączy różne usługi, takie jak application acceleration, SSL offloading i application layer security (poprzez Web Application Firewall - WAF). Jest zbudowany na koncepcji edge POP (Point of Presence) — lokalizacji na całym świecie — aby przybliżyć aplikacje do użytkowników.
Azure Front Door zapewnia globalnie rozproszoną sieć lokalizacji edge, aby kierować i przyspieszać przychodzący ruch do twoich aplikacji webowych (w Azure lub gdzie indziej), poprawiać wydajność i zwiększać bezpieczeństwo.
Przykład:
- Dla globalnej platformy e-commerce z użytkownikami na całym świecie, Azure Front Door może przechowywać statyczne treści w pamięci podręcznej na lokalizacjach edge i oferować SSL offloading, redukując opóźnienia i zapewniając bardziej responsywne doświadczenie użytkownika. Dodatkowo zapewnia WAF, aby chronić aplikacje przed typowymi podatnościami webowymi (takimi jak SQL injection czy XSS).
Azure Front Door oferuje również smart load balancing poprzez kierowanie ruchu do najbliższego dostępnego backendu na podstawie health probes i opóźnień, zapewniając spójną wydajność i dostępność. Integrując WAF, pomaga chronić przed typowymi zagrożeniami webowymi.
Enumeracja
# 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 to load balancer ruchu webowego, który umożliwia zarządzanie ruchem do Twoich web aplikacji. Oferuje Layer 7 load balancing, SSL termination oraz funkcje web application firewall (WAF) jako Application Delivery Controller (ADC) w modelu usługi. Kluczowe funkcje obejmują routowanie oparte na URL, utrzymanie sesji oparte na cookie oraz odciążanie SSL, co jest istotne dla aplikacji wymagających złożonych możliwości równoważenia obciążenia, takich jak globalne routowanie i routowanie oparte na ścieżce.
Przykład:
Rozważ scenariusz, w którym masz stronę e-commerce zawierającą wiele subdomen dla różnych funkcji, takich jak konta użytkowników i przetwarzanie płatności. Azure Application Gateway może kierować ruch do odpowiednich serwerów webowych na podstawie ścieżki URL. Na przykład ruch do example.com/accounts może być skierowany do usługi kont użytkowników, a ruch do example.com/pay do usługi przetwarzania płatności.
I chronić Twoją stronę przed atakami, wykorzystując możliwości WAF.
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 topologies
VNet Peering
VNet Peering to funkcja w Azure, która umożliwia bezpośrednie i bezproblemowe połączenie różnych Virtual Networks (VNets). Dzięki VNet Peering zasoby w jednym VNet mogą komunikować się z zasobami w innym VNet przy użyciu prywatnych adresów IP, jakby znajdowały się w tej samej sieci.
VNet Peering może być również używany z sieciami on-prem poprzez skonfigurowanie site-to-site VPN lub Azure ExpressRoute.
Azure Hub and Spoke to architektura sieciowa, która wykorzystuje VNet peering do utworzenia centralnego Hub VNet, który łączy się z wieloma Spoke VNets. Hub zazwyczaj zawiera usługi współdzielone (takie jak firewalls, DNS, lub Active Directory), podczas gdy spokes hostują obciążenia aplikacyjne. Ten projekt upraszcza zarządzanie, zwiększa bezpieczeństwo dzięki scentralizowanym kontrolom i zmniejsza redundancję.
Example:
Duże przedsiębiorstwo z wieloma działami (Finance, HR, IT) może utworzyć Hub VNet z usługami współdzielonymi takimi jak firewalls i serwery DNS. Każdy dział może mieć własny Spoke VNet, który łączy się z Hub przez peering. Pozwala to działom na bezpieczną komunikację i korzystanie z usług współdzielonych bez narażania swoich zasobów na dostęp z publicznego internetu.
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
A Site-to-Site VPN w Azure nawiązuje bezpieczne i trwałe połączenie z Twoją siecią on-premises do Azure Virtual Network (VNet), umożliwiając zasobom takim jak VMs w Azure pojawianie się, jakby znajdowały się w Twojej sieci lokalnej. To połączenie jest realizowane przez VPN gateway, które szyfruje ruch między obiema sieciami.
Przykład:
Firma z siedzibą główną w Nowym Jorku ma centrum danych on-premises, które musi bezpiecznie połączyć się ze swoim VNet w Azure, gdzie hostowane są jej zwirtualizowane obciążenia. Konfigurując Site-to-Site VPN, firma może zapewnić zaszyfrowane połączenie między serwerami on-premises a Azure VMs, co umożliwia bezpieczny dostęp do zasobów w obu środowiskach, tak jakby znajdowały się w tej samej sieci lokalnej.
Enumeracja
# 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 to usługa, która zapewnia prywatne, dedykowane połączenie o dużej przepustowości między Twoją infrastrukturą on-premises a centrami danych Azure. To połączenie realizowane jest przez dostawcę łączności, omijając publiczny internet i oferując większą niezawodność, wyższe prędkości, niższe opóźnienia oraz wyższe bezpieczeństwo niż typowe połączenia internetowe.
Przykład:
Międzynarodowa korporacja wymaga spójnego i niezawodnego połączenia z usługami Azure ze względu na duży wolumen danych oraz potrzebę dużej przepustowości. Firma wybiera Azure ExpressRoute, aby bezpośrednio połączyć swoje lokalne centrum danych z Azure, ułatwiając przesyłanie dużych ilości danych, takich jak codzienne kopie zapasowe i analizy danych w czasie rzeczywistym, z większą prywatnością i szybkością.
Enumeration
# List ExpressRoute Circuits
az network express-route list --query "[].{name:name, location:location, resourceGroup:resourceGroup, serviceProviderName:serviceProviderName, peeringLocation:peeringLocation}" -o table
Źródła
- DNS OverDoS: Czy Private Endpoints są zbyt prywatne?
- Konfiguracja Azure Private Endpoint DNS
- Private DNS — fallback do internetu
Tip
Ucz się & ćwicz AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
Wspieraj HackTricks
- Sprawdź subscription plans!
- Dołącz do 💬 Discord group lub telegram group lub śledź nas na Twitterze 🐦 @hacktricks_live.
- Podziel się hacking tricks, zgłaszając PRy do HackTricks i HackTricks Cloud github repos.
HackTricks Cloud

