Translated ['', 'src/pentesting-cloud/azure-security/az-services/vms/az-

This commit is contained in:
Translator
2026-01-21 21:44:01 +00:00
parent f151072e06
commit 1c9da53c65
@@ -4,25 +4,25 @@
## Podstawowe informacje
Azure zapewnia **wirtualne sieci (VNet)**, które pozwalają użytkownikom tworzyć **izolowane** **sieci** w chmurze Azure. W ramach tych VNet można bezpiecznie hostować i zarządzać zasobami takimi jak maszyny wirtualne, aplikacje, bazy danych... Sieci w Azure wspierają zarówno komunikację wewnątrz chmury (między usługami Azure), jak i połączenie z zewnętrznymi sieciami oraz internetem.\
Co więcej, możliwe jest **połączenie** VNet z innymi VNet oraz z sieciami lokalnymi.
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.
## Wirtualna sieć (VNET) i podsieci
## Virtual Network (VNET) i podsieci
Wirtualna sieć Azure (VNet) jest reprezentacją twojej własnej sieci w chmurze, zapewniając **logiczne izolowanie** w ramach środowiska Azure dedykowanego twojej subskrypcji. VNet pozwala na provisionowanie i zarządzanie wirtualnymi sieciami prywatnymi (VPN) w Azure, hostując zasoby takie jak maszyny wirtualne (VM), bazy danych i usługi aplikacyjne. Oferują **pełną kontrolę nad ustawieniami sieci**, w tym zakresami adresów IP, tworzeniem podsieci, tabelami routingu i bramami sieciowymi.
Azure Virtual Network (VNet) to odwzorowanie Twojej sieci w chmurze, zapewniające **logiczna izolację** w środowisku Azure przypisanym do Twojego subskrypcji. VNety pozwala 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.
**Podsieci** to podziały w ramach VNet, definiowane przez konkretne **zakresy adresów IP**. Dzieląc VNet na wiele podsieci, możesz organizować i zabezpieczać zasoby zgodnie z architekturą swojej sieci.\
Domyślnie wszystkie podsieci w tej samej Wirtualnej Sieci Azure (VNet) **mogą komunikować się ze sobą** bez żadnych ograniczeń.
**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:**
- `MyVNet` z zakresem adresów IP 10.0.0.0/16.
- **Podsieć-1:** 10.0.0.0/24 dla serwerów webowych.
- **Podsieć-2:** 10.0.1.0/24 dla serwerów baz danych.
- **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 wylistować wszystkie VNet i podsieci w koncie Azure, możesz użyć interfejsu wiersza poleceń Azure (CLI). Oto kroki:
Aby wypisać wszystkie VNety i podsieci w koncie Azure, możesz użyć Azure Command-Line Interface (CLI). Oto kroki:
{{#tabs }}
{{#tab name="az cli" }}
@@ -47,15 +47,15 @@ Select-Object Name, AddressPrefix
{{#endtab }}
{{#endtabs }}
## Grupy zabezpieczeń sieci (NSG)
## Grupy zabezpieczeń sieciowych (NSG)
**Grupa zabezpieczeń sieci (NSG)** filtruje ruch sieciowy zarówno do, jak i z zasobów Azure w ramach Wirtualnej Sieci Azure (VNet). Zawiera zestaw **reguł zabezpieczeń**, które mogą wskazyw**które porty otworzyć dla ruchu przychodzącego i wychodzącego** według portu źródłowego, adresu IP źródłowego, portu docelowego, a także możliwe jest przypisanie priorytetu (im niższy numer priorytetu, tym wyższy priorytet).
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śl**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ć przypisane do **podsieci i NIC.**
NSG mogą być powiązane z **subnetami i NIC.**
**Przykład reguł:**
**Przykłady reguł:**
- Reguła przychodząca zezwalająca na ruch HTTP (port 80) z dowolnego źródła do twoich serwerów webowych.
- 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
@@ -71,7 +71,7 @@ az network nsg show --name <nsg-name>
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 MyLowCostVM-nsg --resource-group Resource_Group_1 --query "{subnets: subnets, networkInterfaces: networkInterfaces}"
az network nsg show --name <NSGName> --resource-group <ResourceGroupName> --query "{subnets: subnets, networkInterfaces: networkInterfaces}"
```
{{#endtab }}
{{#tab name="PowerShell" }}
@@ -81,32 +81,35 @@ Get-AzNetworkSecurityGroup | Select-Object Name, Location
Get-AzNetworkSecurityGroup -Name <NSGName> -ResourceGroupName <ResourceGroupName>
# Get NSG rules
(Get-AzNetworkSecurityGroup -ResourceGroupName <NSGName> -Name <ResourceGroupName>).SecurityRules
Get-AzNetworkSecurityGroup -Name <NSGName> -ResourceGroupName <ResourceGroupName> |
Select-Object -ExpandProperty SecurityRules |
Select-Object Name, Priority, Direction, Access, Protocol, SourceAddressPrefix, DestinationAddressPrefix, SourcePortRange, DestinationPortRange
# Get NICs and subnets using this NSG
(Get-AzNetworkSecurityGroup -Name <NSGName> -ResourceGroupName <ResourceGroupName>).Subnets
(Get-AzNetworkSecurityGroup -Name <NSGName> -ResourceGroupName <ResourceGroupName>).NetworkInterfaces
```
{{#endtab }}
{{#endtabs }}
## Azure Firewall
Azure Firewall to **zarządzana usługa zabezpieczeń sieciowych** w Azure, która chroni zasoby chmurowe poprzez inspekcję i kontrolowanie ruchu. Jest to **stanowy firewall**, który filtruje ruch na podstawie reguł dla warstw 3 do 7, wspierając komunikację zarówno **w Azure** (ruch wschód-zachód), jak i **do/z sieci zewnętrznych** (ruch północ-południe). Wdrażany na poziomie **Wirtualnej Sieci (VNet)**, zapewnia centralną ochronę dla wszystkich podsieci w VNet. Azure Firewall automatycznie dostosowuje się do wymagań ruchu i zapewnia wysoką dostępność bez potrzeby ręcznej konfiguracji.
Azure Firewall to zarządzalny, stanowy firewall, który filtruje ruch (L3L7) dla przepływów eastwest i northsouth. Wdrażany na poziomie VNet, centralizuje inspekcję dla wszystkich podsieci i automatycznie skaluje się dla dostępności.
Jest dostępny w trzech SKU—**Podstawowy**, **Standardowy** i **Premium**, z których każdy jest dostosowany do specyficznych potrzeb klientów:
Dostępne SKU: **Basic**, **Standard** i **Premium**:
| Kryteria/Cechy | Opcja 1 | Opcja 2 | Opcja 3 |
| Kryterium/Funkcja | Opcja 1 | Opcja 2 | Opcja 3 |
| ------------------------------ | ------------------------------------------------- | ------------------------------------------- | --------------------------------------------------------- |
| **Zalecany przypadek użycia** | Małe/Średnie Przedsiębiorstwa (SMB) z ograniczonymi potrzebami | Ogólne zastosowanie w przedsiębiorstwie, filtracja warstw 37 | Wysoce 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 powiadomienia | Powiadomienia i blokowanie (złośliwe IP/domeny) | Powiadomienia i blokowanie (zaawansowana inteligencja zagrożeń) |
| **Filtracja L3L7** | Podstawowa filtracja | Stanowa filtracja w różnych protokołach | Stanowa filtracja z zaawansowaną inspekcją |
| **Zaawansowana ochrona przed zagrożeniami** | Niedostępna | Filtracja oparta na inteligencji zagrożeń | Zawiera system wykrywania i zapobiegania włamaniom (IDPS) |
| **Inspekcja TLS** | Niedostępna | Niedostępna | Wspiera zakończenie TLS przychodzącego/wychodzącego |
| **Dostępność** | Stałe zaplecze (2 VM) | Autoskalowanie | Autoskalowanie |
| **Łatwość zarządzania** | Podstawowe kontrole | Zarządzane przez Firewall Manager | Zarządzane przez Firewall Manager |
| **Zalecany przypadek użycia** | Małe/Średnie przedsiębiorstwa (SMB) o ograniczonych potrzebach | Ogólne użycie w przedsiębiorstwie, filtrowanie warstw 37 | 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 L3L7** | 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 |
### Enumeracja
### Enumeration
{{#tabs }}
{{#tab name="az cli" }}
@@ -141,11 +144,16 @@ Get-AzFirewall
{{#endtab }}
{{#endtabs }}
## Tabele trasowania Azure
## Azure Tablice tras
Tabele **trasowania Azure** są używane do kontrolowania trasowania ruchu sieciowego w obrębie podsieci. Definiują zasady, które określają, jak pakiety powinny być przesyłane, czy to do zasobów Azure, internetu, czy do konkretnego następnego skoku, takiego jak Wirtualne Urządzenie lub Zapora Azure. Możesz powiązać tabelę trasowania z **podsiecią**, a wszystkie zasoby w tej podsieci będą podążać za trasami w tabeli.
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).
**Przykład:** Jeśli podsieć hostuje zasoby, które muszą kierować ruch wychodzący przez Wirtualne Urządzenie Sieciowe (NVA) w celu inspekcji, możesz utworzyć **trasę** w tabeli trasowania, aby przekierować cały ruch (np. `0.0.0.0/0`) do prywatnego adresu IP NVA jako następnego skoku.
> 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/0` z **Internet** jako next hop.
- Aby przeanalizować ruch wychodzący, skieruj `0.0.0.0/0` do adresu IP Network Virtual Appliance (NVA).
### **Enumeracja**
@@ -155,8 +163,11 @@ Tabele **trasowania Azure** są używane do kontrolowania trasowania ruchu sieci
# List Route Tables
az network route-table list --query "[].{name:name, resourceGroup:resourceGroup, location:location}" -o table
# List routes 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
# 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>
```
{{#endtab }}
{{#tab name="PowerShell" }}
@@ -172,18 +183,18 @@ Get-AzRouteTable
## Azure Private Link
Azure Private Link to usługa w Azure, która **umożliwia prywatny dostęp do usług Azure**, zapewniając, że **ruch między twoją wirtualną siecią Azure (VNet) a usługą odbywa się całkowicie w ramach sieci backbone Microsoftu Azure**. Efektywnie wprowadza usługę do twojej VNet. Ta konfiguracja zwiększa bezpieczeństwo, nie narażając danych na publiczny internet.
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 i niestandardowymi usługami udostępnianymi za pośrednictwem Private Link. Zapewnia bezpieczny sposób korzystania z usług z poziomu własnej VNet lub nawet z różnych subskrypcji Azure.
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]
> NSG nie mają zastosowania do punktów końcowych prywatnych, co wyraźnie oznacza, że przypisanie NSG do podsieci zawierającej Private Link nie będzie miało żadnego efektu.
> 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 twojej VNet**. Zwykle może to wymagać przechodzenia przez publiczny internet. Dzięki Private Link możesz utworzyć **prywatny punkt końcowy w swojej VNet**, który łączy się bezpośrednio z usługą Azure SQL Database. Ten punkt końcowy sprawia, że baza danych wydaje się częścią twojej własnej VNet, dostępna za pośrednictwem prywatnego adresu IP, co zapewnia bezpieczny i prywatny dostęp.
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.
### **Enumeration**
### **Enumeracja**
{{#tabs }}
{{#tab name="az cli" }}
@@ -206,15 +217,62 @@ Get-AzPrivateEndpoint | Select-Object Name, Location, ResourceGroupName, Private
{{#endtab }}
{{#endtabs }}
## Punkty końcowe usługi Azure
### DNS OverDoS via service Private DNS zone links
Punkty końcowe usługi Azure rozszerzają prywatną przestrzeń adresową Twojej sieci wirtualnej i tożsamość Twojego VNet do usług Azure za pośrednictwem bezpośredniego połączenia. Włączając punkty końcowe usług, **zasoby w Twoim VNet mogą bezpiecznie łączyć się z usługami Azure**, takimi jak Azure Storage i Azure SQL Database, korzystając z sieci szkieletowej Azure. Zapewnia to, że **ruch z VNet do usługi Azure pozostaje w sieci Azure**, co zapewnia bardziej bezpieczną i niezawodną trasę.
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.
**Przykład:**
**Przebieg nadużycia (control-plane DoS):**
Na przykład, konto **Azure Storage** domyślnie jest dostępne przez publiczny internet. Włączając **punkt końcowy usługi dla Azure Storage w swoim VNet**, możesz zapewnić, że tylko ruch z Twojego VNet może uzyskać dostęp do konta magazynowego. Zapora konta magazynowego może być następnie skonfigurowana tak, aby akceptowała ruch tylko z Twojego VNet.
1. Uzyskaj RBAC pozwalające na tworzenie **Private Endpoints** lub modyfikowanie **Private DNS zone links**.
2. 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).
3. Powiąż tę **service Private DNS zone** z VNetem ofiary.
4. Ponieważ VNet ofiary teraz **wymusza rozwiązywanie przez Private DNS zone** i w tej strefie nie istnieje rekord `A` dla 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.).
### **Enumeracja**
**Odkrywanie na dużą skalę (Azure Resource Graph):**
- VNETs linked to the blob Private DNS zone (forced resolution for PL-registered blob endpoints):
```kusto
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):
```kusto
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**
{{#tabs }}
{{#tab name="az cli" }}
@@ -223,7 +281,10 @@ Na przykład, konto **Azure Storage** domyślnie jest dostępne przez publiczny
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
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"
```
{{#endtab }}
{{#tab name="PowerShell" }}
@@ -237,73 +298,87 @@ Get-AzVirtualNetwork
{{#endtab }}
{{#endtabs }}
### Różnice między punktami końcowymi usługi a prywatnymi łączami
### Różnice między Service Endpoints a Private Links
Microsoft zaleca korzystanie z prywatnych łączy w [**docs**](https://learn.microsoft.com/en-us/azure/virtual-network/vnet-integration-for-azure-services#compare-private-endpoints-and-service-endpoints):
Microsoft zaleca używanie Private Links w [**docs**](https://learn.microsoft.com/en-us/azure/virtual-network/vnet-integration-for-azure-services#compare-private-endpoints-and-service-endpoints):
<figure><img src="../../../../images/image (25).png" alt=""><figcaption></figcaption></figure>
**Punkty końcowe usługi:**
**Service Endpoints:**
- Ruch z Twojej VNet do usługi Azure podróżuje przez sieć backbone Microsoft Azure, omijając publiczny internet.
- Punkt końcowy to bezpośrednie połączenie z usługą Azure i nie zapewnia prywatnego adresu IP dla usługi w VNet.
- Sama usługa jest nadal dostępna za pośrednictwem swojego publicznego punktu końcowego z zewnątrz Twojej VNet, chyba że skonfigurujesz zaporę usługi, aby zablokować taki ruch.
- To relacja jeden do jednego między podsiecią a usługą Azure.
- Tańsze niż prywatne łącza.
- 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.
**Prywatne łącza:**
**Private Links:**
- Prywatne łącze mapuje usługi Azure do Twojej VNet za pośrednictwem prywatnego punktu końcowego, który jest interfejsem sieciowym z prywatnym adresem IP w Twojej VNet.
- Usługa Azure jest dostępna za pomocą tego prywatnego adresu IP, co sprawia, że wydaje się, iż jest częścią Twojej sieci.
- Usługi połączone za pośrednictwem prywatnego łącza mogą być dostępne tylko z Twojej VNet lub połączonych sieci; nie ma dostępu do usługi z publicznego internetu.
- Umożliwia bezpieczne połączenie z usługami Azure lub własnymi usługami hostowanymi w Azure, a także połączenie z usługami udostępnionymi przez innych.
- Zapewnia bardziej szczegółową kontrolę dostępu za pośrednictwem prywatnego punktu końcowego w Twojej VNet, w przeciwieństwie do szerszej kontroli dostępu na poziomie podsieci z punktami końcowymi usługi.
- 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, podczas gdy zarówno punkty końcowe usługi, jak i prywatne łącza zapewniają bezpieczne połączenie z usługami Azure, **prywatne łącza oferują wyższy poziom izolacji i bezpieczeństwa, zapewniając, że usługi są dostępne prywatnie, bez narażania ich na publiczny internet**. Punkty końcowe usługi, z drugiej strony, są łatwiejsze do skonfigurowania w ogólnych przypadkach, gdzie wymagany jest prosty, bezpieczny dostęp do usług Azure bez potrzeby posiadania prywatnego adresu IP w VNet.
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) i AFD WAF
## Azure Front Door (AFD) & AFD WAF
**Azure Front Door** to skalowalny i bezpieczny punkt wejścia do **szybkiej dostawy** Twoich globalnych aplikacji internetowych. **Łączy** różne usługi, takie jak globalne **równoważenie obciążenia, przyspieszanie witryn, odciążanie SSL i możliwości zapory aplikacji internetowej (WAF)** w jedną usługę. Azure Front Door zapewnia inteligentne routowanie w oparciu o **najbliższą lokalizację brzegową do użytkownika**, zapewniając optymalną wydajność i niezawodność. Dodatkowo oferuje routowanie oparte na URL, hosting wielu witryn, afinityzację sesji i bezpieczeństwo na poziomie aplikacji.
**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 WAF** jest zaprojektowany, aby **chronić aplikacje internetowe przed atakami opartymi na sieci** bez modyfikacji kodu zaplecza. Zawiera niestandardowe zasady i zarządzane zestawy zasad, aby chronić przed zagrożeniami takimi jak wstrzykiwanie SQL, skrypty międzywitrynowe i inne powszechne ataki.
> 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:**
Wyobraź sobie, że masz globalnie rozproszoną aplikację z użytkownikami na całym świecie. Możesz użyć Azure Front Door, aby **przekierować żądania użytkowników do najbliższego regionalnego centrum danych** hostującego Twoją aplikację, co zmniejsza opóźnienia, poprawia doświadczenia użytkowników i **broni jej przed atakami sieciowymi dzięki możliwościom WAF**. Jeśli w danym regionie wystąpi przestój, Azure Front Door może automatycznie przekierować ruch do następnej najlepszej lokalizacji, zapewniając wysoką dostępność.
- 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).
### Enumeracja
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**
{{#tabs }}
{{#tab name="az cli" }}
```bash
# List Azure Front Door Instances
# 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
# List Front Door WAF Policies
# Classic Azure Front Door WAF policies
az network front-door waf-policy list --query "[].{name:name, resourceGroup:resourceGroup, location:location}" -o table
```
{{#endtab }}
{{#tab name="PowerShell" }}
```bash
# List Azure Front Door Instances
# List Azure Front Door profiles
Get-AzFrontDoorCdnProfile | Select-Object Name, Location, ResourceGroupName
# List AFD endpoints
Get-AzFrontDoorCdnEndpoint -ProfileName <ProfileName> -ResourceGroupName <ResourceGroupName> | Select-Object Name, HostName, ResourceState
# Classic Azure Front Door (v1) profiles
Get-AzFrontDoor
# List Front Door WAF Policies
# Classic Azure Front Door WAF policies
Get-AzFrontDoorWafPolicy -Name <policyName> -ResourceGroupName <resourceGroupName>
```
{{#endtab }}
{{#endtabs }}
## Azure Application Gateway i Azure Application Gateway WAF
## Azure Application Gateway and Azure Application Gateway WAF
Azure Application Gateway to **load balancer ruchu sieciowego**, który umożliwia zarządzanie ruchem do Twoich **aplikacji** internetowych. Oferuje **równoważenie obciążenia na warstwie 7, zakończenie SSL oraz możliwości zapory aplikacji internetowej (WAF)** w ramach usługi Application Delivery Controller (ADC). Kluczowe funkcje obejmują routowanie oparte na URL, sesje oparte na ciasteczkach oraz odciążanie warstwy gniazd zabezpieczonych (SSL), które są niezbędne dla aplikacji wymagających złożonych możliwości równoważenia obciążenia, takich jak globalne routowanie i routowanie oparte na ścieżkach.
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ę internetową e-commerce, która zawiera wiele subdomen dla różnych funkcji, takich jak konta użytkowników i przetwarzanie płatności. Azure Application Gateway może **routować ruch do odpowiednich serwerów internetowych na podstawie ścieżki URL**. Na przykład ruch do `example.com/accounts` może być kierowany do usługi kont użytkowników, a ruch do `example.com/pay` może być kierowany do usługi przetwarzania płatności.\
I **chroń swoją stronę internetową przed atakami, korzystając z możliwości WAF.**
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.**
### **Enumeracja**
### **Enumeration**
{{#tabs }}
{{#tab name="az cli" }}
@@ -320,20 +395,20 @@ az network application-gateway waf-config list --gateway-name <AppGatewayName> -
{{#endtab }}
{{#endtabs }}
## Azure Hub, Spoke i Peering VNet
## VNet Peering & HUB and Spoke topologies
**Peering VNet** to funkcja sieciowa w Azure, która **pozwala na bezpośrednie i płynne łączenie różnych Wirtualnych Sieci (VNets)**. Dzięki peeringowi VNet zasoby w jednej VNet mogą komunikować się z zasobami w innej VNet, używając prywatnych adresów IP, **jakby znajdowały się w tej samej sieci**.\
**Peering VNet może być również używany z sieciami lokalnymi** poprzez skonfigurowanie VPN site-to-site lub Azure ExpressRoute.
### VNet Peering
**Azure Hub i Spoke** to topologia sieciowa używana w Azure do zarządzania i organizowania ruchu sieciowego. **"Hub" to centralny punkt, który kontroluje i kieruje ruchem między różnymi "spokes"**. Hub zazwyczaj zawiera usługi wspólne, takie jak wirtualne urządzenia sieciowe (NVA), Azure VPN Gateway, Azure Firewall lub Azure Bastion. **"Spokes" to VNety, które hostują obciążenia i łączą się z hubem za pomocą peeringu VNet**, co pozwala im korzystać z usług wspólnych w hubie. Ten model promuje czysty układ sieci, redukując złożoność poprzez centralizację wspólnych usług, z których mogą korzystać różne obciążenia w różnych VNetach.
**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.
> [!CAUTION] > **Peering VNET jest nietransytywny w Azure**, co oznacza, że jeśli spoke 1 jest połączony ze spoke 2, a spoke 2 jest połączony ze spoke 3, to spoke 1 nie może bezpośrednio komunikować się ze spoke 3.
**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ę.
**Przykład:**
**Example:**
Wyobraź sobie firmę z oddzielnymi działami, takimi jak Sprzedaż, HR i Rozwój, **każde z własną VNet (spokes)**. Te VNety **wymagają dostępu do wspólnych zasobów**, takich jak centralna baza danych, zapora ogniowa i brama internetowa, które znajdują się w **innej VNet (hub)**. Korzystając z modelu Hub i Spoke, każde z działów może **bezpiecznie łączyć się z wspólnymi zasobami przez VNet hub, nie narażając tych zasobów na publiczny internet** ani nie tworząc skomplikowanej struktury sieciowej z licznymi połączeniami.
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.
### Enumeracja
### **Enumeration**
{{#tabs }}
{{#tab name="az cli" }}
@@ -341,8 +416,8 @@ Wyobraź sobie firmę z oddzielnymi działami, takimi jak Sprzedaż, HR i Rozwó
# 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 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
@@ -353,8 +428,8 @@ az network firewall list --query "[].{name:name, location:location, resourceGrou
# List all VNets in your subscription
Get-AzVirtualNetwork
# List VNet peering connections for a given VNet
(Get-AzVirtualNetwork -ResourceGroupName <ResourceGroupName> -Name <VNetName>).VirtualNetworkPeerings
# List VNet Peerings
Get-AzVirtualNetworkPeering -ResourceGroupName <ResourceGroupName> -VirtualNetworkName <VNetName>
# List Shared Resources (e.g., Azure Firewall) in the Hub
Get-AzFirewall
@@ -362,13 +437,13 @@ Get-AzFirewall
{{#endtab }}
{{#endtabs }}
## VPN Site-to-Site
## Site-to-Site VPN
VPN Site-to-Site w Azure pozwala na **połączenie lokalnej sieci z Twoją Wirtualną Siecią Azure (VNet)**, umożliwiając zasobom takim jak VM w Azure, aby wydawały się, jakby były w Twojej lokalnej sieci. To połączenie jest ustanawiane przez **bramę VPN, która szyfruje ruch** między dwiema sieciami.
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, której główne biuro znajduje się w Nowym Jorku, ma lokalne centrum danych, które musi bezpiecznie połączyć się ze swo VNet w Azure, która hostuje jej wirtualizowane obciążenia. Poprzez skonfigurowanie **VPN Site-to-Site, firma może zapewnić szyfrowane połączenie między lokalnymi serwerami a VM w Azure**, umożliwiając bezpieczny dostęp do zasobów w obu środowiskach, jakby były w tej samej lokalnej sieci.
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**
@@ -395,11 +470,11 @@ Get-AzVirtualNetworkGatewayConnection -ResourceGroupName <ResourceGroupName>
## Azure ExpressRoute
Azure ExpressRoute to usługa, która zapewnia **prywatne, dedykowane, szybkie połączenie między Twoją infrastrukturą lokalną a centrami danych Azure**. To połączenie jest realizowane przez dostawcę łączności, omijając publiczny internet i oferując większą niezawodność, szybsze prędkości, niższe opóźnienia i wyższe bezpieczeństwo niż typowe połączenia internetowe.
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 z powodu dużej ilości danych** i potrzeby wysokiej przepustowości. Firma decyduje się na Azure ExpressRoute, aby bezpośrednio połączyć swoje lokalne centrum danych z Azure, ułatwiając transfery danych na dużą skalę, takie jak codzienne kopie zapasowe i analizy danych w czasie rzeczywistym, z poprawioną prywatnością i szybkością.
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**
@@ -418,4 +493,10 @@ Get-AzExpressRouteCircuit
{{#endtab }}
{{#endtabs }}
## Źródła
- [DNS OverDoS: Czy Private Endpoints są zbyt prywatne?](https://unit42.paloaltonetworks.com/dos-attacks-and-azure-private-endpoint/)
- [Konfiguracja Azure Private Endpoint DNS](https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns)
- [Private DNS — fallback do internetu](https://learn.microsoft.com/en-us/azure/dns/private-dns-fallback)
{{#include ../../../../banners/hacktricks-training.md}}