Internet Access Control

Module: Design and Implement Routing

Section: Azure Routing

Lesson: Internet Access Control

Introduction: The Criticality of Internet Access Control in Azure

When you deploy workloads into the cloud, the boundary between your private infrastructure and the public internet becomes one of the most critical security vectors. In Azure, a virtual network (VNet) is essentially a private space, but by default, resources within that network often have paths that could lead to the public internet. Managing how, when, and through what mechanisms your resources communicate with the outside world is the essence of Internet Access Control.

Why does this matter? Simply put, uncontrolled internet access is a recipe for data exfiltration and compromise. If a virtual machine is compromised by a malicious actor, the first thing that attacker will attempt is to reach out to a Command and Control (C2) server on the internet to download further payloads. If your egress traffic is not restricted or inspected, that attacker has a clear path to complete their objectives. Conversely, controlling ingress traffic is about protecting your services from unauthenticated access, DDoS attacks, and vulnerability exploits.

This lesson explores the mechanisms available in Azure to govern this traffic. We will move beyond basic firewall rules and look at the architecture of routing, the role of Network Security Groups (NSGs), the power of Azure Firewall, and the strategic implementation of forced tunneling. By the end of this module, you will understand how to design a "Zero Trust" approach to internet connectivity, ensuring that your Azure resources only talk to the internet when absolutely necessary, and only through the paths you explicitly authorize.

The Architecture of Egress: Understanding Default Routing

To control internet access, you must first understand how Azure handles traffic by default. When you create an Azure Virtual Network, Azure automatically creates system routes. These system routes allow all subnets within a VNet to communicate with each other, and they allow resources to reach the internet via the default Azure gateway.

This default behavior is convenient for development and initial prototyping, but it is dangerous for production environments. In a secure design, you should treat the internet as an untrusted zone. You want to move from an "allow-by-default" posture to a "deny-by-default" posture. This means blocking all outbound traffic and explicitly whitelisting only the specific destinations (FQDNs or IP ranges) that your applications require.

The Role of User-Defined Routes (UDRs)

User-Defined Routes, or UDRs, are the primary mechanism for overriding default Azure system routing. By creating a route table and associating it with a subnet, you can force traffic to flow through a specific virtual appliance (like an Azure Firewall or a Network Virtual Appliance) rather than going directly to the internet.

This is the foundation of "forced tunneling." When you configure a UDR with a next-hop type of "Virtual Appliance" and a destination prefix of "0.0.0.0/0," you are effectively telling every resource in that subnet: "If you need to reach the internet, do not go through the default gateway. Instead, send your traffic to this specific internal IP address."

Callout: The "0.0.0.0/0" Concept In networking, the "0.0.0.0/0" prefix represents the "default route" or the "gateway of last resort." It encompasses every possible destination on the internet. By creating a UDR for 0.0.0.0/0, you are capturing all outbound traffic that is not destined for your own internal VNet or peered networks. This is the most effective way to intercept and control internet-bound traffic.

Implementing Network Security Groups (NSGs) for Granular Control

Network Security Groups act as a distributed firewall for your Azure resources. They consist of security rules that allow or deny traffic based on source IP, destination IP, source port, destination port, and protocol. NSGs can be applied to individual network interfaces (NICs) or at the subnet level.

Best Practices for NSG Configuration

1. Deny All by Default: Always ensure that your final rule in any NSG is a "Deny All" rule. While Azure provides default rules, explicitly defining a deny rule makes your security posture clear and auditable.
2. Principle of Least Privilege: Only open the specific ports required for your application to function. For example, if a web server only needs to serve traffic on port 443, do not open port 80, and certainly do not open SSH (22) or RDP (3389) to the entire internet.
3. Use Service Tags: Instead of hardcoding IP ranges for Azure services, use Service Tags. For example, if your VM needs to talk to Azure Storage, use the Storage service tag instead of looking up and maintaining a list of Microsoft’s IP addresses.

Note: NSGs are stateful. This means if you allow an inbound request from an external source, the return traffic is automatically allowed regardless of your outbound rules. This simplifies rule management significantly.

Example: Restricting Outbound Traffic via NSG

Suppose you have a backend application that needs to connect to an external API at api.example.com. Instead of allowing all outbound traffic, you can restrict it.

{
  "name": "AllowOutboundToAPI",
  "properties": {
    "priority": 100,
    "direction": "Outbound",
    "access": "Allow",
    "protocol": "Tcp",
    "sourcePortRange": "*",
    "destinationPortRange": "443",
    "sourceAddressPrefix": "10.0.1.0/24",
    "destinationAddressPrefix": "203.0.113.5" 
  }
}

In this snippet, we only permit traffic on port 443 to a specific destination IP. By adding a subsequent rule with a higher priority number (e.g., 200) that denies all traffic to the Internet service tag, you effectively lock down the subnet.

Advanced Egress Control: Azure Firewall

While NSGs are excellent for simple filtering, they operate at Layer 3 and Layer 4 of the OSI model. They do not understand application-level protocols or domain names (FQDNs). This is where Azure Firewall becomes indispensable.

Azure Firewall is a managed, cloud-native network security service. It provides FQDN filtering, which allows you to permit traffic based on domain names rather than volatile IP addresses. For instance, you can allow your servers to talk to github.com without needing to know every IP address GitHub uses.

Implementing FQDN Filtering with Azure Firewall

1. Deploy the Firewall: Create an Azure Firewall resource in a dedicated subnet named AzureFirewallSubnet.
2. Create a Firewall Policy: Define a collection of rules.
3. Configure Application Rules: Specify the FQDNs you wish to allow.

Example of an Application Rule collection in Azure CLI:

az network firewall policy rule-collection create \
    --resource-group MyRG \
    --policy-name MyFirewallPolicy \
    --name AllowGithub \
    --rule-collection-type FirewallPolicyRuleCollection \
    --action Allow \
    --rule-name AllowGithubRule \
    --rule-type ApplicationRule \
    --protocols Http=80 Https=443 \
    --target-fqdns "github.com" "*.github.com"

This configuration ensures that only traffic destined for GitHub is permitted, and any attempt to reach other domains is silently dropped or logged. This is far more secure than allowing traffic based on an IP address range, which could be shared by multiple services or change frequently.

Forced Tunneling and Hybrid Connectivity

In enterprise environments, you often have a requirement to route all internet traffic through an on-premises security stack. This is known as "Forced Tunneling." By using UDRs to send all 0.0.0.0/0 traffic to your VPN Gateway or ExpressRoute circuit, you ensure that every packet leaving your Azure VNet is inspected by your corporate firewall or proxy.

Steps to Implement Forced Tunneling

1. Create a Route Table: Define a new route table in your VNet.
2. Add a Default Route: Create a rule with address prefix 0.0.0.0/0 and next-hop type Virtual Network Gateway (for VPN/ExpressRoute) or Virtual Appliance (for NVA/Firewall).
3. Associate the Subnet: Link the route table to the specific subnet containing your workloads.
4. Verify Propagation: Ensure that the BGP or static routes from your on-premises environment are correctly advertising the return path, otherwise, traffic will be "black-holed."

Warning: Be careful when implementing forced tunneling. If you inadvertently cut off the path for Azure services to reach their own management endpoints (like the Azure fabric controller), you may lose the ability to manage your VMs. Always ensure that you have specific routes for Azure management services if necessary.

Managing Ingress: Controlling Access to Your Services

While egress control focuses on what your resources can reach, ingress control focuses on who can reach your resources. The primary tools here are Public IP addresses, Load Balancers, and Application Gateways.

Public IP vs. Private Endpoints

The most common mistake in Azure is assigning a Public IP address directly to a Virtual Machine. This exposes the VM directly to the internet, making it a target for brute force attacks.

Best Practice: Use a "Hub and Spoke" architecture. Place your public-facing entry points (like an Azure Application Gateway or Azure Front Door) in a central Hub VNet. These services provide Web Application Firewall (WAF) capabilities, which protect against SQL injection and Cross-Site Scripting (XSS). Your backend services should reside in spoke VNets, accessible only via Private Endpoints or internal load balancers.

The Power of Private Link

Private Link allows you to access Azure PaaS services (like Azure SQL or Azure Storage) over a private IP address within your VNet. By using Private Link, you can disable the public internet access for these services entirely.

1. Disable Public Network Access: In the configuration of your Azure SQL instance, set Public network access to Disabled.
2. Create a Private Endpoint: Create a Private Endpoint in your VNet that maps to your SQL resource.
3. Update DNS: Ensure your VNet can resolve the private IP address of the service.

This approach effectively removes the internet from the equation for your data access layer, drastically reducing your attack surface.

Comparison: NSG vs. Azure Firewall vs. Application Gateway

Choosing the right tool is essential for both performance and security. Use the following table to guide your architectural decisions.

Common Pitfalls and How to Avoid Them

1. Over-reliance on Default Routes

Many teams assume that because they haven't added a Public IP to a VM, it is "safe." However, if that VM is in a VNet with a default route to the internet, it can still initiate outbound connections. Always assume that outbound traffic is possible unless you have explicitly blocked it.

2. Misconfiguration of UDRs

A common mistake is creating a UDR that conflicts with existing system routes, causing traffic to get stuck in a loop. Always use the "Effective Routes" view in the Azure portal for a specific network interface to see exactly which path Azure is choosing for a packet. If you see a route you don't recognize, investigate the route table association immediately.

3. Ignoring Logging and Monitoring

Security is useless if you don't know when it's being tested. You should always enable NSG Flow Logs and Azure Firewall logs, and stream them to a Log Analytics workspace. Without these logs, you are "flying blind." If an incident occurs, you will have no way of knowing which traffic was allowed or denied, or where it originated.

4. Hardcoding IP Addresses

Infrastructure is dynamic. Using static IP addresses in your routing tables or firewall rules creates a maintenance nightmare. Whenever possible, use Service Tags, FQDNs, or Application Security Groups (ASGs). ASGs allow you to group VMs by their function (e.g., "WebServers") and apply rules to the group rather than individual IPs.

Step-by-Step Implementation Strategy

If you are tasked with securing a new VNet, follow this structured approach:

1. Define the Network Perimeter: Create a Hub VNet for shared services and Spoke VNets for your applications.
2. Implement NSGs with a "Deny All" baseline: Create an NSG that denies all outbound traffic, then add explicit "Allow" rules for only the necessary traffic flows.
3. Deploy Azure Firewall for Egress: If your compliance requirements mandate FQDN filtering, deploy an Azure Firewall in the Hub and route all Spoke 0.0.0.0/0 traffic through it.
4. Use Private Endpoints: Move all PaaS service access to Private Endpoints and disable their public internet access.
5. Enable Diagnostics: Configure diagnostic settings to send all network logs to a central Log Analytics workspace.
6. Audit Regularly: Use Azure Policy to enforce the presence of NSGs and to prevent the creation of public IP addresses on unauthorized resources.

Deep Dive: The Role of Application Security Groups (ASGs)

Application Security Groups are a powerful, yet often underutilized, feature for managing network security at scale. Instead of managing firewall rules based on IP addresses, ASGs allow you to group virtual machines based on their role or application.

For example, you can create an ASG called AppTier and an ASG called DatabaseTier. In your NSG, you can create a rule that says: "Allow traffic from AppTier to DatabaseTier on port 1433." If you add 10 more VMs to the AppTier later, they automatically inherit the ability to talk to the database without you having to touch the NSG rules.

This reduces the risk of human error when updating rules and makes your security policy much easier to read and understand. It turns your network configuration into a document that describes the intent of the system rather than just a list of arbitrary IP addresses.

Tip: Use descriptive names for your ASGs and NSG rules. Instead of Rule1, use Allow-AppTier-To-DBTier-SQL. This makes auditing and troubleshooting significantly faster.

Handling Hybrid Scenarios: ExpressRoute and Internet Access

When you connect your Azure VNet to an on-premises network via ExpressRoute, you need to consider how internet traffic is handled. By default, an ExpressRoute circuit does not provide internet access; it only provides private connectivity to your on-premises environment.

If you have a requirement for your Azure VMs to reach the internet, you have two primary choices:

1. Direct Internet Access: Allow the VMs to go directly out to the internet via the Azure default gateway. This is the simplest but least secure method, as it bypasses your on-premises security stack.
2. Forced Tunneling via ExpressRoute: Configure your Azure UDRs to send all 0.0.0.0/0 traffic back to your on-premises environment. Your on-premises firewall then inspects the traffic and routes it out to the internet. This provides maximum visibility and control but adds significant latency to internet-bound traffic.

Choose the second option if your organization has strict compliance requirements for data egress. Be aware, however, that this places a significant load on your on-premises bandwidth and firewall capacity.

Summary of Key Takeaways

To effectively design and implement internet access control in Azure, keep the following principles in mind:

• Adopt a Zero Trust Mentality: Never assume that a connection is safe. Default to denying all traffic and only permit what is strictly necessary for your application to function.
• Layer Your Defenses: Use a combination of NSGs for basic filtering, Azure Firewall for FQDN-based egress control, and WAFs for application-layer ingress protection.
• Favor FQDNs over IP Addresses: IP addresses change and are often shared. FQDNs provide a more stable and readable way to define your security boundaries.
• Use Private Endpoints: Whenever you use Azure PaaS services, prioritize Private Endpoints over public internet access to keep your data traffic off the public web.
• Monitor and Audit: Implement comprehensive logging for all network traffic. Without logs, you cannot verify that your security policies are actually working as intended.
• Centralize with Hub and Spoke: Centralize your security appliances (Firewalls, WAFs) in a Hub VNet to ensure consistent policy application across all your Spoke VNets.
• Automate with Infrastructure as Code (IaC): Use tools like Terraform or Bicep to define your network security. This ensures that your configuration is version-controlled, repeatable, and less prone to manual configuration errors.

By following these practices, you transform your Azure network from a collection of loosely connected resources into a hardened, defensible infrastructure. Internet access control is not a one-time configuration task; it is an ongoing process of monitoring, refining, and adapting to the evolving threat landscape. Always prioritize the simplicity of your policy, as complex rules are the ones most likely to be misconfigured or bypassed.