Azure Architecture Best Practice for securing Azure Virtual Networks

While desiging the azure landing zone we need to ensure that our network is secured.VNet protects inbound flow (from users) and outbound traffic flow (to Internet). Now the question arises how do we secure this traffic? Azure provides services like Azure firewall and Azure Application Gateway. It is very confusing on when to use Azure firewall vs. Azure Application Gateway? There can be other combinations which can make the design more and more complex. This article provides the definitive guidance and scnearios based approach to help what design should be used? When it should be used? How it should be used?

Traffic Types

Before designing the solution we need to ensure what types of traffic we need to protect. Essentially there are two types of traffic:

  1. Https Traffic: Web application Traffic when user browse the internet or hit the web application hosted on VM.
  2. Non-Http Traffic: Non web application traffic for example TCP traffic to connect to SQL server on port 1433.DNS server listening on port 53 is also non-Http traffic.

Address Translation

The most important part of security is to protect the devices by hiding their IP address.This way sender will not be able to attack the IP address from where the traffic is emenating. This is done by Netowrk address translation. There are two types of Network address translation:

Source Network Address Translation: SNAT is used when you want to hide the IP address of internal/private host trying to initiate a connection to an external/public host. The device performing NAT (Azure Firewall) changes the private IP address of the source host to public IP address. In this process It may also change the source port in the TCP/UDP headers. An example of SNAT is when we need to change the private address or port into a public address or port when the packets are leaving the network.

Destination Network Address Translation: DNAT is used to redirect incoming packets with a destination of a public address/port to a private IP address/port inside your network. Destination NAT is performed on incoming packets, where the firewall translates a public destination address to a private address. DNAT performs translation with the option to perform port forwarding or port translation.One example of DNAT would be that a users trying to accessing a web Server hosted in a Data Center where DNAT is used to hide the private address of web Server and NAT device (for example Azure Firewall) translates the public destination IP reachable to Internet users to Private IP address of Web Server.

What is Azure Application Gateway?

Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to the web applications. Azure Application Gateway operates at the transport layer (OSI layer 4 – TCP and UDP) and route traffic based on source IP address and port, to a destination IP address and port.

Application Gateway can make routing decisions based on additional attributes of an HTTP request, for example URI path or host headers. This means you can route traffic based on the incoming URL. for example if if /images is in the incoming URL, you can route traffic to a specific set of servers (known as a pool) configured for images. If /video is in the URL, that traffic is routed to another pool that’s optimized for videos.

What is Web Application Firewall?

Web Application Firewall (WAF) provides centralized protection of theweb applications from common exploits and vulnerabilities. Web applications are increasingly targeted by malicious attacks (SQL injection, Cross Site scripting etc.) that exploit commonly known vulnerabilities. SQL injection and cross-site scripting are among the most common attacks.

Preventing such attacks in application code is a herculean task. It can require rigorous maintenance, patching, and monitoring at multiple layers of the application topology. A centralized web application firewall helps make security management much simpler. A WAF also gives application administrators better assurance of protection against threats and intrusions.

What is Azure Firewall?

Azure Firewall is a managed, cloud-based network security service that protects your Azure Virtual Network resources. It’s a fully stateful firewall-as-a-service with built-in high availability and unrestricted cloud scalability. By default, Azure Firewall blocks traffic.

SNAT, DNAT and Network packet filtering, Application FQDN filtering rules are main features of Azure firewall.

Traffic filtering choice between Azure firewall vs WAF?

Http(s) and Non-Http(s) traffic from/to azure can be filtered by Azure firewall but WAF can only filter inbound traffic from onpremise /internet to Azure.

When to use standalone Azure firewall?

If there are no web-based workloads in the virtual network that can benefit from WAF, you can use Azure Firewall only.

Azure Firewall Only

When to use standalone Application Gateway?

Use Application Gateway where only web applications exist in the virtual network, and inspecting outbound traffic with NSGs is sufficient to protect outbound flows to the internet.

Azure Application Gateway

When to use Azure Firewall and Application Gateway in parallel?

if there’s a mix of web and non-web workloads in the virtual network. Azure WAF protects inbound traffic to the web workloads, and the Azure Firewall inspects inbound traffic for the other applications. The Azure Firewall will cover outbound flows from both workload types.

Inbound connection from outside client:

Inbound connection is self explanatory on how traffic is flowing.

Outbound connection from network VM to internet:

outbound connection is self explanatory on how traffic is flowing.

Application Gateway before firewall

When to use: Inbound web traffic goes through both Azure Firewall and WAF. The WAF provides protection at the web application layer. Azure Firewall acts as a central logging and control point, and it inspects traffic between the Application Gateway and the backend servers. The important point to consider here is that the Azure Firewall applies TLS inspection to do IDPS on the encrypted traffic between the Application Gateway and the web backend. This design is suitable for scenarios where application need to know incoming client source IP addresses. Let’s take an example application server serves the location specific contents so users coming from EU location will be served different content vs. users coming from AP region.

Application Gateway in front of Azure Firewall captures the incoming packet’s source IP address in the X-forwarded-for header, so the web server can see the original IP address in this header.

Non-Http(s) traffic will be hitting thru Azure Firewall’s private or public interface depending upon where the traffic is coming from?Private traffic will be coming from private interface and internet traffic will be coming from public interface.

Application Gateway after Firewall

When to use This design lets Azure Firewall filter and discard malicious traffic before it reaches the Application Gateway. Azure firewall can apply features like threat intelligence-based filtering. Another main benefit is that the application gets the same public IP address for both inbound and outbound traffic.

Limited benefit of this design because Azure firewall always see the encrypted traffic with which it can not do much. This scenario is only useful when you want to use WAF before firewall or you want to use multiple public IP addresses and you want to direct all the traffic via one firewall for central logging and monitoring mechanism.

On premise client connectivity

There are some caveats when you use this design from onpremise clients:

Hub and spoke considerations

When you implement Hub and spoke topology you need to carefully design the UDR to avoid asymmetric routing

Asymetric Routing: In the below routing diagram traffic coming from instance 1 of the firewall goes back to Instance 0 of the firewall causing Asymetric routing. To avoid it in the routing table dnext hop should not contain the whole Vnet address space where Azure Firewall is kept instead it should contain the specific subnet like common services subnet. That is why in the routing table it is depicted in red.

Asymmetric routing in hub and spoke

I hope this post heps to understand the Architecture best practices.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.