HackTricks Cloud
HackTricks Training Twitter Linkedin Sponsor

Az - Azure Network

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!

Other ways to support HackTricks:

Basic Information

Networks within Azure function as an integral part of its cloud computing platform, enabling the connection and communication between various Azure services and resources. The network architecture in Azure is designed to be highly scalable, secure, and customizable.

At its core, Azure provides a virtual network (VNet) that allows users to create isolated networks within the Azure cloud. Within these VNets, resources such as virtual machines, applications, and 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.

Security is a critical aspect of Azure networking, with various tools and services available for protecting data, managing access, and ensuring compliance. These security measures include firewalls, network security groups, and encryption capabilities, allowing for a high level of control over traffic and access.

Overall, Azure's networking capabilities are designed to offer flexibility, allowing users to create a network environment that suits their specific application and workload needs while maintaining a strong emphasis on security and reliability.

Virtual Network (VNET) & Subnets

A VNet in Azure is essentially a representation of your own network in the cloud. It is a logical isolation of the Azure cloud dedicated to your subscription. A VNet allows you to provision and manage virtual private networks (VPNs) in Azure and can be used to host and manage multiple types of Azure resources, such as Virtual Machines (VMs), databases, and application services.

VNets provide you with full control over your network settings, including IP address ranges, subnet creation, route tables, and network gateways.

A subnet is a range of IP addresses in your VNet. You can divide a VNet into multiple subnets for organization and security. Each subnet in a VNet can be used to isolate and group resources according to your network and application architecture.

Moreover, subnets allow you to segment your VNet into one or more sub-networks, providing a range of IP addresses that resources can use.

Example

  • Suppose you have a VNet named MyVNet with an IP address range of 10.0.0.0/16. You can create a subnet within this VNet, let's say Subnet-1, with an IP address range of 10.0.0.0/24 for hosting your web servers. Another subnet, Subnet-2 with a range of 10.0.1.0/24, could be used for your database servers. This segmentation allows for efficient management and security controls within the network.

Enumeration

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

# List VNets
az network vnet list --query "[].{name:name, location:location, addressSpace:addressSpace}" -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

Network Security Groups (NSG)

In Azure, a Network Security Group (NSG) serves the primary function of filtering network traffic both to and from Azure resources within an Azure Virtual Network (VNet). It houses a set of security rules that meticulously dictate the flow of network traffic.

Key aspects of NSG include:

  • Traffic Control: Each NSG contains rules that are instrumental in either permitting or obstructing inbound and outbound network traffic associated with various Azure resources.

  • Rule Components: The rules within an NSG are highly specific, filtering traffic based on criteria like source/destination IP address, port, and protocol. This specificity allows for granular management of network traffic.

  • Security Enhancement: By ensuring that only authorized traffic can enter or exit your Azure resources, NSGs play a crucial role in fortifying the security posture of your network infrastructure.

Example

  • Imagine you have an NSG named MyNSG applied to a subnet or a specific virtual machine within your VNet. You can create rules like:

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

Enumeration

# 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 is a managed, cloud-based network security service that protects your Azure Virtual Network resources. It is a fully stateful firewall as a service with built-in high availability and scalability features.

Azure Firewall provides more advanced features than NSGs, including application-level filtering, network-level filtering, threat intelligence-based filtering, and integration with Azure Monitor for logging and analytics. It can filter outbound, inbound, spoke-to-spoke, VPN, and ExpressRoute traffic. Firewall rules can be created based on FQDN (Fully Qualified Domain Name), IP addresses, and ports.

Differences between Azure Firewall and NSGs

  1. Scope:

    • NSG: Works at the subnet or network interface level. It's meant to provide basic filtering of inbound and outbound traffic from network interfaces (NIC), VMs, or subnets.

    • Azure Firewall: Operates at the VNet level, providing a broader scope of protection. It's designed to secure your virtual network resources and manage traffic flowing in and out of the VNet.

  2. Capabilities:

    • NSG: Provides basic filtering capabilities based on IP address, port, and protocol. It does not support advanced features like application-level inspection or threat intelligence.

    • Azure Firewall: Offers advanced features like application-level (Layer 7) traffic filtering, threat intelligence-based filtering, network traffic filtering, and more. It also supports multiple public IP addresses.

  3. Use Cases:

    • NSG: Ideal for basic network level traffic filtering.

    • Azure Firewall: Suited for more complex filtering scenarios where application-level control, logging, and threat intelligence are needed.

  4. Management and Monitoring:

    • NSG: Offers basic logging and integration with Azure Monitor.

    • Azure Firewall: Provides advanced logging and analytics capabilities through Azure Monitor, which is essential for understanding the nature and pattern of the traffic.

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) in Azure is a virtual appliance that performs network functions within a virtual network. NVAs are typically used for network functions that aren't natively available in Azure or when more customization is required. They are essentially VMs that run network applications or services, such as firewalls, WAN optimizers, or load balancers.

NVAs are used for complex routing, security, and network traffic management tasks. They can be deployed from Azure Marketplace, where many third-party vendors offer their appliances ready for integration into Azure environments.

Example

  • An organization can deploy an NVA in Azure to create a custom firewall solution. This NVA could run a third-party firewall software, providing advanced features like intrusion detection, packet inspection, or VPN connectivity. The NVA can be configured to inspect and filter traffic passing through it, ensuring enhanced security measures are in place as per the organization's policies.

Enumeration

# 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

Azure Route Tables & User Defined Routes (UDR)

Azure Route Tables are a feature within Microsoft Azure that allow for the control of network traffic routing within Azure Virtual Networks (VNets). Essentially, they define how packets are forwarded between subnets within VNets, between VNets, or to external networks. Each route table contains a set of rules, known as routes, that specify how packets should be routed based on their destination IP addresses.

User Defined Routes (UDR) in Azure are custom routes that you create within Azure Route Tables to control the flow of network traffic within and between Azure Virtual Networks (VNets), and to external connections. UDRs give you the flexibility to direct network traffic as per your specific requirements, overriding Azure's default routing decisions.

These routes are particularly useful for scenarios where you need to route traffic through a virtual appliance, enforce a specific pathway for security or policy compliance, or integrate with on-premises networks.

Example

  • Suppose you have deployed a Network Virtual Appliance (NVA) for inspecting traffic between subnets within a VNet. You can create a UDR that directs all traffic from one subnet to another subnet to go through the NVA. This UDR ensures that the NVA inspects the traffic for security purposes before it reaches its destination.

Enumeration

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

Enumeration

# 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

Azure Service Endpoints

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.

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}" -o table

Differences Between Service Endpoints and Private Links

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 (AFD) & AFD WAF

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.

Enumeration

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

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.

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

Azure Hub, Spoke & VNet Peering

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.

Examples

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

Enumeration

# 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

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.

Enumeration

# List VPN Gateways
az network vnet-gateway list --query "[].{name:name, location:location, resourceGroup:resourceGroup}" -o table

# List VPN Connections
az network vpn-connection list --gateway-name <VpnGatewayName> --resource-group <ResourceGroupName> --query "[].{name:name, connectionType:connectionType, connectionStatus:connectionStatus}" -o table

Azure ExpressRoute

Azure ExpressRoute is 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.

Enumeration

# List ExpressRoute Circuits
az network express-route list --query "[].{name:name, location:location, resourceGroup:resourceGroup, serviceProviderName:serviceProviderName, peeringLocation:peeringLocation}" -o table
Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!

Other ways to support HackTricks:

PreviousAz - Virtual Machines & NetworkNextAz - Permissions for a Pentest

Last updated