Controlling Data Egress in Azure
What Azure services allow data egress?
Virtual Network subnets or VMs without UDR or BGP Control – traffic can leave the default outbound access IP which is not controllable or managed by the customer.
Private VNETs will be available with secure by default enabled scheduled 2025 and will provide a means to disable this unmanaged Public egress pattern. – Azure Private Subnet
User Defined Route (UDR) – Routes added to UDRs can inject routes to VMs and services deployed to a subnet.
A UDR can have a route that directs traffic directly to the internet, but this traffic would go out as mentioned above via a customer unmanaged IP address.
If the Subnet has a NAT Gateway associated to it and has a route targeting traffic to next hop internet, it should reach the public internet via the NAT Gateway’s associated IP addresses.
If the Subnet has a route targeting traffic to next hop Azure Firewall or 3rd party NVA, the traffic will reach the internet via that devices route table or public IP address.
NAT Gateway – NAT Gateway plays a role in allowing a subnet to reach the internet from a specific IP address or prefix. This allows data to leave and reply to requests BUT does not allow an Ingress point for data.
A scenario here would be: I have an Azure VM that needs to reach out to our partner who whitelists IP addresses that can communicate with them. A NAT Gateway would allow that known public IP address to be provided to the partner without allowing unsecure access to your virtual machines. More information can be found here: NAT Gateway
VNET Gateway for Express Route or VPN (VNG) – Data can only leave Virtual Network Gateways if it is going through a Express Route or VPN (S2S or P2S). If traffic destined for the public internet is directed to the VNG, the traffic will drop. If you need traffic from subnets to leave a known IP address on your network, please leverage NAT Gateway. If Traffic is directed via a BGP or UDR entry to an on-prem IP address, the traffic can pass through the VNET Gateway over the secure connection to the on-prem IP address for egress.
Public IP Addresses – If an Azure VM or PaaS service has a public IP address, traffic will egress from that known published Public IP address.
For example, if a 3rd party network solution (Cisco or Palo Alto for example) is deployed on a VM in Azure with a public IP address associated to it, traffic on the internet would show that data’s source would be the public IP address assigned to the VM. Public IP Egress for VMs
External Load Balancer (ELB) – For example, if a 3rd party network solution (Cisco or Palo Alto for example) is deployed on a VM in Azure without a public IP address associated to it, but has a Public Standard Load Balancer attached, the traffic on the internet would show that data’s source would be the public IP address assigned to the ELB. Azure VM Outbound Connectivity Methods
For PaaS Services with Public IP addresses, it can reach the internet through its public IP Address. If the PaaS Service supports VNET integration, that traffic can be redirected to the appropriate network services to control/govern that data as needed. If VNET integration is enabled and the subnet connected to the PaaS service has a NAT Gateway or a UDR directing the applicable traffic, the traffic would come from that known IP address instead. Azure VNET Integration
Public IP Prefix – Public IP Prefixes allow a group of IP addresses to be used for data egress on services such as Virtual Machines, Standard Load Balancers, Azure Firewall, and VPN Gateway. The benefit of this service is to allow you to expand past the standard network limits for a single public IP address such as SNAT (Source NAT). Azure Public IP Prefix
Azure Firewall (AzFW) – Azure Firewall is a scalable Cloud-Native Firewall. AzFW can replace or supplement 3rd party network solutions in a number of secure network designs, but focusing on egress, traffic directed to the Azure Firewall can egress to the internet via a NAT Gateway or an associated public IP address. Azure Firewall Public IP Address
Azure Firewall has a huge number of security benefits which can be found: Azure Firewall Version Comparison
Now that we discussed what can egress, how can we monitor/secure it? What does this look like in practice?
Azure Network Security Group (NSG) – As mentioned in various documents, micro segmentation is a key component of ensuring zero trust and reducing attack surfaces for network attacks. When creating NSG rules – similar to ACLs (Access Control Lists) in other network solutions, ensure only approved traffic is allowed. NSGs
Example: If I have a web server running on a windows VM that doesn’t require egress, ensure the NSG rules specify:
Inbound:
Allow port 443 for https from its allowed sources at priority 100
RDP for management/access at priority 101
Implicit DENY for all inbound traffic at rule priority 4000.
Default rules at 65000, 65001, and 65500 should be ignored.
Outbound:
Allow outbound communication to authentication servers at priority 100
Allow outbound communication to DNS servers at priority 101
Allow outbound communication to management applications at priority 101
Implicit DENY for all outbound traffic at rule priority 4000.
Default rules at 65000, 65001, and 65500 should be ignored.
NSGs have default rules that allow certain traffic BEFORE the implicit deny. If you are advertising addresses through a Virtual Network Gateway from a Site-to-Site VPN or BGP configuration, the on-prem communication may be allowed as part of the ‘VNET communication’ default rule since it is a private address that announced to your Virtual Networks.
Flow Logs:
Only Option Until April 2024 – NSG Flow Logs – NSG Flow logs can help monitor what traffic is being allowed to reach the various sources including the public internet. This information can be sent to a SIEM solutions for central review of all traffic from Azure.
VNET Flow logs was released April 2024, can simplify the capturing of flow logs and be deployed per VNET instead of per subnet. – VNET Flow Logs
Azure UDR – User Defined Routes can control what routes are published to subnets in Azure and can control if routes from on-prem are published to Azure. Routes such as Communication to IP addresses, IP ranges, or Azure Services can be manipulated to direct traffic. For example, if an environment is using an Azure Firewall for Azure Native traffic, but all other traffic firewall should be going to a particular 3rd party solution to leave the environment:
Subnets will have a UDR that directs the applicable Service Tag will say next hop = Azure Firewall.
Azure Service Tags – A Service Tag is a Microsoft Managed logical grouping of public IP addresses in the Azure Backbone to provide access to services with or without region association. Examples can be found: Service Tags
Azure Policy
NSGs should be associated with all subnets
Flow Logs should be deployed to capture all data on networks in Azure.
Per Subnets – Flow logs should be configured for every network security group
Per Virtual Networks – Audit flow logs configuration for every virtual network
What can govern your Azure Data Egress requests?
Azure Firewall
Deploy Route Table to control traffic. Azure Firewall UDR Support
Network Rules on Azure Firewall to control traffic
3rd party NVAs (Palo, Cisco, Juniper, etc)
Deploy Route Table to control traffic. Azure Firewall UDR Support
Network Rules on NVAs to control traffic
Azure NSGs
Deployed per subnet as mentioned above.
In conclusion, the secure management of egress traffic is a critical component of our overall security posture. By adhering to the guidelines and principles outlined in this document, we fortify our defenses against potential threats and ensure the integrity of our data as it traverses beyond the confines of our internal network. Thank you for your commitment to upholding these standards and contributing to our collective security efforts.
Microsoft Tech Community – Latest Blogs –Read More