Polish - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Az - Azure Network

Support HackTricks

Podstawowe informacje

Sieci w Azure funkcjonują jako integralna część jego platformy chmurowej, umożliwiając połączenie i komunikację między różnymi usługami i zasobami Azure. Architektura sieci w Azure została zaprojektowana w sposób wysoce skalowalny, bezpieczny i dostosowywalny.

W swojej istocie Azure zapewnia wirtualną sieć (VNet), która pozwala użytkownikom tworzyć izolowane sieci w chmurze Azure. W ramach tych VNets zasoby, takie jak maszyny wirtualne, aplikacje i bazy danych, mogą być bezpiecznie hostowane i zarządzane. Sieci w Azure wspierają zarówno komunikację wewnątrz chmury (między usługami Azure), jak i połączenie z zewnętrznymi sieciami i internetem.

Bezpieczeństwo jest kluczowym aspektem sieciowania w Azure, z różnymi narzędziami i usługami dostępnymi do ochrony danych, zarządzania dostępem i zapewnienia zgodności. Te środki bezpieczeństwa obejmują zapory, grupy zabezpieczeń sieci oraz możliwości szyfrowania, co pozwala na wysoki poziom kontroli nad ruchem i dostępem.

Ogólnie rzecz biorąc, możliwości sieciowe Azure są zaprojektowane w celu oferowania elastyczności, pozwalając użytkownikom na stworzenie środowiska sieciowego, które odpowiada ich specyficznym potrzebom aplikacyjnym i obciążeniowym, jednocześnie kładąc silny nacisk na bezpieczeństwo i niezawodność.

Wirtualna sieć (VNET) i podsieci

VNet w Azure jest zasadniczo reprezentacją twojej własnej sieci w chmurze. Jest to logiczne odizolowanie chmury Azure dedykowane twojej subskrypcji. VNet pozwala na provisionowanie i zarządzanie wirtualnymi sieciami prywatnymi (VPN) w Azure i może być używane do hostowania i zarządzania wieloma typami zasobów Azure, takimi jak maszyny wirtualne (VM), bazy danych i usługi aplikacyjne.

VNets zapewniają pełną kontrolę nad ustawieniami sieci, w tym zakresami adresów IP, tworzeniem podsieci, tabelami routingu i bramami sieciowymi.

Podsieć to zakres adresów IP w twoim VNet. Możesz podzielić VNet na wiele podsieci w celu organizacji i bezpieczeństwa. Każda podsieć w VNet może być używana do izolowania i grupowania zasobów zgodnie z twoją architekturą sieciową i aplikacyjną.

Ponadto, podsieci pozwalają na segmentację twojego VNet na jedną lub więcej podsieci, zapewniając zakres adresów IP, które zasoby mogą wykorzystać.

Przykład

  • Załóżmy, że masz VNet o nazwie MyVNet z zakresem adresów IP 10.0.0.0/16. Możesz stworzyć podsieć w ramach tego VNet, powiedzmy Subnet-1, z zakresem adresów IP 10.0.0.0/24 do hostowania swoich serwerów webowych. Inna podsieć, Subnet-2 z zakresem 10.0.1.0/24, mogłaby być używana dla twoich serwerów baz danych. Ta segmentacja pozwala na efektywne zarządzanie i kontrolę bezpieczeństwa w sieci.

Enumeracja

Aby wylistować wszystkie VNety i podsieci w koncie Azure, możesz użyć interfejsu wiersza poleceń Azure (CLI). Oto kroki:

# 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

Grupy zabezpieczeń sieci (NSG)

W Azure, Grupa zabezpieczeń sieci (NSG) pełni podstawową funkcję filtrowania ruchu sieciowego zarówno do, jak i z zasobów Azure w ramach Wirtualnej Sieci Azure (VNet). Zawiera zestaw reguł zabezpieczeń, które skrupulatnie określają przepływ ruchu sieciowego.

Kluczowe aspekty NSG obejmują:

  • Kontrola ruchu: Każda NSG zawiera reguły, które są niezbędne do zezwolenia lub zablokowania przychodzącego i wychodzącego ruchu sieciowego związanego z różnymi zasobami Azure.

  • Składniki reguły: Reguły w NSG są bardzo szczegółowe, filtrując ruch na podstawie kryteriów takich jak adres IP źródłowy/docelowy, port i protokół. Ta szczegółowość pozwala na precyzyjne zarządzanie ruchem sieciowym.

  • Wzmocnienie zabezpieczeń: Zapewniając, że tylko autoryzowany ruch może wchodzić lub wychodzić z zasobów Azure, NSG odgrywają kluczową rolę w wzmacnianiu bezpieczeństwa infrastruktury sieciowej.

Przykład

  • Wyobraź sobie, że masz NSG o nazwie MyNSG zastosowaną do podsieci lub konkretnej maszyny wirtualnej w swojej VNet. Możesz stworzyć reguły takie jak:

  • Reguła przychodząca zezwalająca na ruch HTTP (port 80) z dowolnego źródła do twoich serwerów webowych.

  • 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

# 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 to zarządzana, oparta na chmurze usługa zabezpieczeń sieciowych, która chroni zasoby Twojej sieci wirtualnej Azure. Jest to w pełni stanowy firewall jako usługa z wbudowanymi funkcjami wysokiej dostępności i skalowalności.

Azure Firewall oferuje bardziej zaawansowane funkcje niż NSG, w tym filtrowanie na poziomie aplikacji, filtrowanie na poziomie sieci, filtrowanie oparte na inteligencji zagrożeń oraz integrację z Azure Monitor w celu logowania i analizy. Może filtrować ruch wychodzący, przychodzący, między węzłami, VPN i ExpressRoute. Reguły zapory mogą być tworzone na podstawie FQDN (Fully Qualified Domain Name), adresów IP i portów.

Różnice między Azure Firewall a NSG

  1. Zakres:

  • NSG: Działa na poziomie podsieci lub interfejsu sieciowego. Ma na celu zapewnienie podstawowego filtrowania ruchu przychodzącego i wychodzącego z interfejsów sieciowych (NIC), VM lub podsieci.

  • Azure Firewall: Działa na poziomie VNet, zapewniając szerszy zakres ochrony. Jest zaprojektowany w celu zabezpieczenia zasobów sieci wirtualnej i zarządzania ruchem wpływającym i wypływającym z VNet.

  1. Możliwości:

  • NSG: Oferuje podstawowe możliwości filtrowania oparte na adresie IP, porcie i protokole. Nie obsługuje zaawansowanych funkcji, takich jak inspekcja na poziomie aplikacji czy inteligencja zagrożeń.

  • Azure Firewall: Oferuje zaawansowane funkcje, takie jak filtrowanie ruchu na poziomie aplikacji (warstwa 7), filtrowanie oparte na inteligencji zagrożeń, filtrowanie ruchu sieciowego i inne. Obsługuje również wiele publicznych adresów IP.

  1. Przypadki użycia:

  • NSG: Idealne do podstawowego filtrowania ruchu na poziomie sieci.

  • Azure Firewall: Odpowiednie do bardziej złożonych scenariuszy filtrowania, gdzie potrzebna jest kontrola na poziomie aplikacji, logowanie i inteligencja zagrożeń.

  1. Zarządzanie i monitorowanie:

  • NSG: Oferuje podstawowe logowanie i integrację z Azure Monitor.

  • Azure Firewall: Zapewnia zaawansowane możliwości logowania i analizy poprzez Azure Monitor, co jest niezbędne do zrozumienia charakteru i wzorców ruchu.

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)

A Network Virtual Appliance (NVA) w Azure to wirtualne urządzenie, które wykonuje funkcje sieciowe w ramach wirtualnej sieci. NVAs są zazwyczaj używane do funkcji sieciowych, które nie są dostępne natywnie w Azure lub gdy wymagana jest większa personalizacja. Są to zasadniczo VM-y, które uruchamiają aplikacje lub usługi sieciowe, takie jak zapory, optymalizatory WAN lub równoważniki obciążenia.

NVAs są używane do złożonego routingu, bezpieczeństwa i zarządzania ruchem sieciowym. Mogą być wdrażane z Azure Marketplace, gdzie wielu dostawców zewnętrznych oferuje swoje urządzenia gotowe do integracji z środowiskami Azure.

Przykład

  • Organizacja może wdrożyć NVA w Azure, aby stworzyć niestandardowe rozwiązanie zapory. Ta NVA mogłaby uruchamiać oprogramowanie zapory od strony trzeciej, oferując zaawansowane funkcje, takie jak wykrywanie włamań, inspekcja pakietów lub łączność VPN. NVA może być skonfigurowana do inspekcji i filtrowania ruchu przechodzącego przez nią, zapewniając, że wprowadzone są zaawansowane środki bezpieczeństwa zgodnie z politykami organizacji.

Enumeracja

# 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

Tabele trasowania Azure i zdefiniowane przez użytkownika trasy (UDR)

Tabele trasowania Azure to funkcja w Microsoft Azure, która pozwala na kontrolowanie trasowania ruchu sieciowego w ramach Wirtualnych Sieci Azure (VNets). Zasadniczo definiują one, jak pakiety są przekazywane między podsieciami w VNets, między VNets lub do sieci zewnętrznych. Każda tabela trasowania zawiera zestaw reguł, znanych jako trasy, które określają, jak pakiety powinny być trasowane na podstawie ich adresów IP docelowych.

Zdefiniowane przez użytkownika trasy (UDR) w Azure to niestandardowe trasy, które tworzysz w ramach Tabel Trasowania Azure, aby kontrolować przepływ ruchu sieciowego w obrębie i między Wirtualnymi Sieciami Azure (VNets) oraz do połączeń zewnętrznych. UDR-y dają Ci elastyczność w kierowaniu ruchem sieciowym zgodnie z Twoimi specyficznymi wymaganiami, nadpisując domyślne decyzje trasowania Azure.

Te trasy są szczególnie przydatne w scenariuszach, w których musisz trasować ruch przez wirtualne urządzenie, wymusić określoną ścieżkę dla bezpieczeństwa lub zgodności z polityką, lub zintegrować się z sieciami lokalnymi.

Przykład

  • Załóżmy, że wdrożyłeś Wirtualne Urządzenie Sieciowe (NVA) do inspekcji ruchu między podsieciami w VNet. Możesz utworzyć UDR, który kieruje cały ruch z jednej podsieci do drugiej podsieci przez NVA. Ten UDR zapewnia, że NVA inspekcjonuje ruch w celach bezpieczeństwa, zanim dotrze do swojego celu.

Enumeracja

# 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 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 szkieletowej Microsoftu Azure. Efektywnie wprowadza usługę do twojej VNet. Ta konfiguracja zwiększa bezpieczeństwo, nie narażają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 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.

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.

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 wiązać się z przechodzeniem 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ę być częścią twojej własnej VNet, dostępna za pośrednictwem prywatnego adresu IP, co zapewnia bezpieczny i prywatny dostęp.

Enumeracja

# 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

Punkty końcowe usługi Azure

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ę.

Przykład

  • 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ć ruch tylko z twojego VNet.

Enumeracja

# 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

Różnice między punktami końcowymi usługi a prywatnymi łączami

Microsoft zaleca korzystanie z prywatnych łączy w docs:\

Punkty końcowe usługi:

  • Ruch z Twojej VNet do usługi Azure podróżuje przez sieć szkieletową 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.

Prywatne łącza:

  • 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.

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.

Azure Front Door (AFD) i 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 na podstawie najbliższej lokalizacji brzegowej do użytkownika, zapewniając optymalną wydajność i niezawodność. Dodatkowo oferuje routowanie oparte na URL, hosting wielu witryn, afinitywność sesji i bezpieczeństwo na poziomie aplikacji.

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.

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 chroni ją przed atakami internetowymi 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ść.

Enumeracja

# 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 i Azure Application Gateway WAF

Azure Application Gateway to balanser obciążenia ruchu sieciowego, który umożliwia zarządzanie ruchem do Twoich aplikacji internetowych. Oferuje balansowanie 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ą kluczowe dla aplikacji wymagających złożonych możliwości balansowania obciążenia, takich jak globalne routowanie i routowanie oparte na ścieżkach.

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 mógłby być kierowany do usługi kont użytkowników, a ruch do example.com/pay mógłby być kierowany do usługi przetwarzania płatności. I chroń swoją stronę internetową przed atakami, korzystając z możliwości WAF.

Enumeracja

# 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 i Peering VNet

Peering VNet to funkcja sieciowa w Azure, która pozwala na bezpośrednie i płynne połą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.

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.

Parowanie VNET jest nieprzechodnie 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 rozmawiać bezpośrednio ze spoke 3.

Przykłady

  • Wyobraź sobie firmę z oddzielnymi działami, takimi jak Sprzedaż, HR i Rozwój, każdy 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żdy dział może bezpiecznie połączyć się z wspólnymi zasobami przez VNet hub, nie narażając tych zasobów na publiczny internet ani nie tworząc złożonej struktury sieciowej z licznymi połączeniami.

Enumeracja

# 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

Site-to-Site VPN 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.

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 swoją VNet w Azure, która hostuje jej wirtualizowane obciążenia. Poprzez skonfigurowanie Site-to-Site VPN, 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 znajdowały się w tej samej lokalnej sieci.

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, szybkie połączenie między twoją infrastrukturą lokalną a centrami danych Azure. To połączenie realizowane jest przez dostawcę łączności, omijając publiczny internet i oferując większą niezawodność, szybsze 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 oraz 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ą.

Enumeracja

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

Last updated