Az - Azure Network
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Azure provides virtual networks (VNet) that allows users to create isolated networks within the Azure cloud. Within these VNets, resources such as virtual machines, applications, databases... can be securely hosted and managed. The networking in Azure supports both the communication within the cloud (between Azure services) and the connection to external networks and the internet. Moreover, it's possible to connect VNets with other VNets and with on-premise networks.
An Azure Virtual Network (VNet) is a representation of your own network in the cloud, providing logical isolation within the Azure environment dedicated to your subscription. VNets allow you to provision and manage virtual private networks (VPNs) in Azure, hosting resources like Virtual Machines (VMs), databases, and application services. They offer full control over network settings, including IP address ranges, subnet creation, route tables, and network gateways.
Subnets are subdivisions within a VNet, defined by specific IP address ranges. By segmenting a VNet into multiple subnets, you can organize and secure resources according to your network architecture. By default all subnets within the same Azure Virtual Network (VNet) can communicate with each other without any restrictions.
Example:
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.
To list all the VNets and subnets in an Azure account, you can use the Azure Command-Line Interface (CLI). Here are the steps:
A Network Security Group (NSG) filters network traffic both to and from Azure resources within an Azure Virtual Network (VNet). It houses a set of security rules that can indicate which ports to open for inbound and outbound traffic by source port, source IP, port destination and it's possible to assign a priority (the lower the priority number, the higher the priority).
NSGs can be associated to subnets and NICs.
Rules example:
An inbound rule allowing HTTP traffic (port 80) from any source to your web servers.
An outbound rule allowing only SQL traffic (port 1433) to a specific destination IP address range.
Azure Firewall is a managed network security service in Azure that protects cloud resources by inspecting and controlling traffic. It is a stateful firewall that filters traffic based on rules for Layers 3 to 7, supporting communication both within Azure (east-west traffic) and to/from external networks (north-south traffic). Deployed at the Virtual Network (VNet) level, it provides centralized protection for all subnets in the VNet. Azure Firewall automatically scales to handle traffic demands and ensures high availability without requiring manual setup.
It is available in three SKUs—Basic, Standard, and Premium, each tailored for specific customer needs:
Recommended Use Case
Small/Medium Businesses (SMBs) with limited needs
General enterprise use, Layer 3–7 filtering
Highly sensitive environments (e.g., payment processing)
Performance
Up to 250 Mbps throughput
Up to 30 Gbps throughput
Up to 100 Gbps throughput
Threat Intelligence
Alerts only
Alerts and blocking (malicious IPs/domains)
Alerts and blocking (advanced threat intelligence)
L3–L7 Filtering
Basic filtering
Stateful filtering across protocols
Stateful filtering with advanced inspection
Advanced Threat Protection
Not available
Threat intelligence-based filtering
Includes Intrusion Detection and Prevention System (IDPS)
TLS Inspection
Not available
Not available
Supports inbound/outbound TLS termination
Availability
Fixed backend (2 VMs)
Autoscaling
Autoscaling
Ease of Management
Basic controls
Managed via Firewall Manager
Managed via Firewall Manager
Azure Route Tables are used to control the routing of network traffic within a subnet. They define rules that specify how packets should be forwarded, either to Azure resources, the internet, or a specific next hop like a Virtual Appliance or Azure Firewall. You can associate a route table with a subnet, and all resources within that subnet will follow the routes in the table.
Example: If a subnet hosts resources that need to route outbound traffic through a Network Virtual Appliance (NVA) for inspection, you can create a route in a route table to redirect all traffic (e.g., 0.0.0.0/0) to the NVA's private IP address as the next hop.
Azure Private Link is a service in Azure that enables private access to Azure services by ensuring that traffic between your Azure virtual network (VNet) and the service travels entirely within Microsoft's Azure backbone network. It effectively brings the service into your VNet. This setup enhances security by not exposing the data to the public internet.
Private Link can be used with various Azure services, like Azure Storage, Azure SQL Database, and custom services shared via Private Link. It provides a secure way to consume services from within your own VNet or even from different Azure subscriptions.
NSGs do not apply to private endpoints, which clearly means that associating an NSG with a subnet that contains the Private Link will have no effect.
Example:
Consider a scenario where you have an Azure SQL Database that you want to access securely from your VNet. Normally, this might involve traversing the public internet. With Private Link, you can create a private endpoint in your VNet that connects directly to the Azure SQL Database service. This endpoint makes the database appear as though it's part of your own VNet, accessible via a private IP address, thus ensuring secure and private access.
Azure Service Endpoints extend your virtual network private address space and the identity of your VNet to Azure services over a direct connection. By enabling service endpoints, resources in your VNet can securely connect to Azure services, like Azure Storage and Azure SQL Database, using Azure's backbone network. This ensures that the traffic from the VNet to the Azure service stays within the Azure network, providing a more secure and reliable path.
Example:
For instance, an Azure Storage account by default is accessible over the public internet. By enabling a service endpoint for Azure Storage within your VNet, you can ensure that only traffic from your VNet can access the storage account. The storage account firewall can then be configured to accept traffic only from your VNet.
Microsoft recommends using Private Links in the docs:
Service Endpoints:
Traffic from your VNet to the Azure service travels over the Microsoft Azure backbone network, bypassing the public internet.
The endpoint is a direct connection to the Azure service and does not provide a private IP for the service within the VNet.
The service itself is still accessible via its public endpoint from outside your VNet unless you configure the service firewall to block such traffic.
It's a one-to-one relationship between the subnet and the Azure service.
Less expensive than Private Links.
Private Links:
Private Link maps Azure services into your VNet via a private endpoint, which is a network interface with a private IP address within your VNet.
The Azure service is accessed using this private IP address, making it appear as if it's part of your network.
Services connected via Private Link can be accessed only from your VNet or connected networks; there's no public internet access to the service.
It enables a secure connection to Azure services or your own services hosted in Azure, as well as a connection to services shared by others.
It provides more granular access control via a private endpoint in your VNet, as opposed to broader access control at the subnet level with service endpoints.
In summary, while both Service Endpoints and Private Links provide secure connectivity to Azure services, Private Links offer a higher level of isolation and security by ensuring that services are accessed privately without exposing them to the public internet. Service Endpoints, on the other hand, are easier to set up for general cases where simple, secure access to Azure services is required without the need for a private IP in the VNet.
Azure Front Door is a scalable and secure entry point for fast delivery of your global web applications. It combines various services like global load balancing, site acceleration, SSL offloading, and Web Application Firewall (WAF) capabilities into a single service. Azure Front Door provides intelligent routing based on the closest edge location to the user, ensuring optimal performance and reliability. Additionally, it offers URL-based routing, multiple-site hosting, session affinity, and application layer security.
Azure Front Door WAF is designed to protect web applications from web-based attacks without modification to back-end code. It includes custom rules and managed rule sets to protect against threats such as SQL injection, cross-site scripting, and other common attacks.
Example:
Imagine you have a globally distributed application with users all around the world. You can use Azure Front Door to route user requests to the nearest regional data center hosting your application, thus reducing latency, improving user experience and defending it from web attacks with the WAF capabilities. If a particular region experiences downtime, Azure Front Door can automatically reroute traffic to the next best location, ensuring high availability.
Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web applications. It offers Layer 7 load balancing, SSL termination, and web application firewall (WAF) capabilities in the Application Delivery Controller (ADC) as a service. Key features include URL-based routing, cookie-based session affinity, and secure sockets layer (SSL) offloading, which are crucial for applications that require complex load-balancing capabilities like global routing and path-based routing.
Example:
Consider a scenario where you have an e-commerce website that includes multiple subdomains for different functions, such as user accounts and payment processing. Azure Application Gateway can route traffic to the appropriate web servers based on the URL path. For example, traffic to example.com/accounts could be directed to the user accounts service, and traffic to example.com/pay could be directed to the payment processing service.
And protect your website from attacks using the WAF capabilities.
VNet Peering is a networking feature in Azure that allows different Virtual Networks (VNets) to be connected directly and seamlessly. Through VNet peering, resources in one VNet can communicate with resources in another VNet using private IP addresses, as if they were in the same network. VNet Peering can also used with a on-prem networks by setting up a site-to-site VPN or Azure ExpressRoute.
Azure Hub and Spoke is a network topology used in Azure to manage and organize network traffic. The "hub" is a central point that controls and routes traffic between different "spokes". The hub typically contains shared services such as network virtual appliances (NVAs), Azure VPN Gateway, Azure Firewall, or Azure Bastion. The "spokes" are VNets that host workloads and connect to the hub using VNet peering, allowing them to leverage the shared services within the hub. This model promotes clean network layout, reducing complexity by centralizing common services that multiple workloads across different VNets can use.
VNET pairing is non-transitive in Azure, which means that if spoke 1 is connected to spoke 2 and spoke 2 is connected to spoke 3 then spoke 1 cannot talk directly to spoke 3.
Example:
Imagine a company with separate departments like Sales, HR, and Development, each with its own VNet (the spokes). These VNets require access to shared resources like a central database, a firewall, and an internet gateway, which are all located in another VNet (the hub). By using the Hub and Spoke model, each department can securely connect to the shared resources through the hub VNet without exposing those resources to the public internet or creating a complex network structure with numerous connections.
A Site-to-Site VPN in Azure allows you to connect your on-premises network to your Azure Virtual Network (VNet), enabling resources such as VMs within Azure to appear as if they are on your local network. This connection is established through a VPN gateway that encrypts traffic between the two networks.
Example:
A business with its main office located in New York has an on-premises data center that needs to connect securely to its VNet in Azure, which hosts its virtualized workloads. By setting up a Site-to-Site VPN, the company can ensure encrypted connectivity between the on-premises servers and the Azure VMs, allowing for resources to be accessed securely across both environments as if they were in the same local network.
Azure ExpressRoute is a service that provides a private, dedicated, high-speed connection between your on-premises infrastructure and Azure data centers. This connection is made through a connectivity provider, bypassing the public internet and offering more reliability, faster speeds, lower latencies, and higher security than typical internet connections.
Example:
A multinational corporation requires a consistent and reliable connection to its Azure services due to the high volume of data and the need for high throughput. The company opts for Azure ExpressRoute to directly connect its on-premises data center to Azure, facilitating large-scale data transfers, such as daily backups and real-time data analytics, with enhanced privacy and speed.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
