This guide outlines a strategy for implementing zero-trust security for web apps. This type of security model verifies the trustworthiness of network packets that flow to applications. A multi-layered approach works best, where network security makes up one layer. In this layer, network appliances inspect packets to ensure that only legitimate traffic reaches applications.
Typically, different types of network appliances inspect different aspects of network packets :
Web application firewalls look for patterns that indicate an attack at the web application layer.
Next-generation firewalls can also look for generic threats.
In some situations, you can combine different types of network security appliances to increase protection. A separate guide, Firewall and Application Gateway for virtual networks, describes design patterns that you can use to arrange the various appliances. This document focuses on a common pattern for maximizing security, in which Azure Application Gateway acts before Azure Firewall Premium.
The following diagram illustrates this pattern:
This architecture uses the Transport Layer Security (TLS) protocol to encrypt traffic at every step.
A client sends packets to Application Gateway, a load balancer. It runs with the optional addition of Azure Web Application Firewall.
Application Gateway decrypts the packets and searches for threats to web applications. If it doesn't find any threats, it uses zero-trust principles to encrypt the packets. Then, it releases them.
Azure Firewall Premium runs security checks:
o Transport layer security (TLS) inspection decrypts and examines the packets.
o Intrusion detection and protection features check the packets for malicious intent.
If the packets pass the tests, Azure Firewall Premium takes these steps:
o Encrypts the packets
o Uses a Domain Name System (DNS) service to determine the application's virtual machine (VM)
o Forwards the packets to the application VM
Various inspection engines in this architecture ensure traffic integrity:
Web Application Firewall uses rules to prevent attacks at the web layer. Examples of attacks include SQL code injection and cross-site scripting. For more information on rules and the Open Web Application Security Project (OWASP) Core Rule Set, see Web Application Firewall CRS rule groups and rules.
Azure Firewall Premium uses generic intrusion detection and prevention rules. These rules help identify malicious files and other threats that target web applications.
This architecture supports different types of network design, which this article discusses:
Traditional hub and spoke networks
Networks that use Azure Virtual WAN as a platform
Networks that use Azure Route Server to simplify dynamic routing
Azure Firewall Premium and name resolution
When checking for malicious traffic, Azure Firewall Premium verifies that the HTTP Host header matches the packet IP address and TCP port. For example, suppose Application Gateway sends web packets to the IP address 172.16.1.4 and TCP port 443. The value of the HTTP Host header should resolve to that IP address.
HTTP Host headers usually don't contain IP addresses. Instead, the headers contain names that match the server's digital certificate. In this case, Azure Firewall Premium uses DNS to resolve the Host header name to an IP address. The network design determines which DNS solution works best, as later sections describe.
Digital certificates
The following diagram shows the common names (CNs) and certificate authorities (CAs) that the architecture's TLS sessions and certificates use:
TLS connections
This architecture contains three distinct TLS connections. Digital certificates validate each one:
From clients to Application Gateway
In Application Gateway, you deploy the digital certificate that clients see. A well-known CA such as DigiCert or Let's Encrypt typically issues such a certificate.
From Application Gateway to Azure Firewall Premium
To decrypt and inspect TLS traffic, Azure Firewall Premium dynamically generates certificates. Azure Firewall Premium also presents itself to Application Gateway as the web server. A private CA signs the certificates that Azure Firewall Premium generates. For more information. Application Gateway needs to validate those certificates. In the application's HTTP settings, you configure the root CA that Azure Firewall Premium uses.
From Azure Firewall Premium to the web server
Azure Firewall Premium establishes a TLS session with the destination web server. Azure Firewall Premium verifies that a well-known CA signs the web server TLS packets.
Component roles
Application Gateway and Azure Firewall Premium handle certificates differently from one another because their roles differ:
Application Gateway is a reverse web proxy. It protects web servers from malicious clients by intercepting HTTP and HTTPS requests. You declare each protected server that's in the back-end pool of Application Gateway with its IP address or fully qualified domain name. Legitimate clients should be able to access each application. So, you configure Application Gateway with a digital certificate that a public CA has signed. Use a CA that any TLS client will accept.
Azure Firewall Premium is a forward web proxy or, simply, a web proxy. It protects clients from malicious web servers by intercepting TLS calls from the protected clients. When a protected client makes an HTTP request, the forward proxy impersonates the target web server by generating digital certificates and presenting them to the client. Azure Firewall Premium uses a private CA, which signs the dynamically generated certificates. You configure the protected clients to trust that private CA. In this architecture, Azure Firewall Premium protects requests from the Application Gateway to the web server. Application Gateway trusts the private CA that Azure Firewall Premium uses.
Hub and spoke example
Typically, a hub and spoke design deploys shared network components in the hub virtual network and application-specific components in the spokes. In most systems, Azure Firewall Premium is a shared resource. However, a Web Application Firewall can be a shared network device or an application-specific component. For the following reasons, it's usually best to treat Application Gateway as an application component and deploy it in a spoke virtual network:
It can be difficult to troubleshoot Web Application Firewall alerts. You generally need in-depth application knowledge to decide whether the messages that trigger those alarms are legitimate.
If you treat Application Gateway as a shared resource, you might exceed Azure Application Gateway limits.
You might face role-based access control problems if you deploy Application Gateway in the hub. This situation can come up when teams manage different applications but use the same instance of Application Gateway. Each team then has access to the entire Application Gateway configuration.
With traditional hub and spoke architectures, DNS private zones provide an easy way to use DNS:
Configure a DNS private zone.
Link the zone to the virtual network that contains Azure Firewall Premium.
Make sure that an A record exists for the value that Application Gateway uses for traffic and health checks.
The following diagram shows the packet flow when the Application Gateway is in a spoke virtual network. In this case, a client connects from the public internet.
Traffic can also arrive from an on-premises network instead of the public internet. The traffic flows either through a site-to-site virtual private network (VPN) or through ExpressRoute. In this scenario, the traffic first reaches a virtual network gateway in the hub. The rest of the network flow is the same as in the previous case.
Virtual WAN example
You can also use the networking service Virtual WAN in this architecture. This component offers many benefits. For instance, it eliminates the need for user-maintained UDRs in spoke virtual networks. You can define static routes in virtual hub route tables instead. The programming of every virtual network that you connect to the hub then contains these routes.
The following diagram shows the packet flow in a Virtual WAN case. In this situation, access to Application Gateway is from an on-premises network. A site-to-site VPN or ExpressRoute connects that network to Virtual WAN. Access from the internet is similar.
Route Server example
Route Server offers another way to inject routes automatically in spokes. With this functionality, you avoid the administrative overhead of maintaining route tables. Route Server combines the Virtual WAN and hub and spoke variants:
With Route Server, customers manage hub virtual networks. As a result, you can link the hub virtual network to a DNS private zone.
Route Server has the same limitation that Virtual WAN has concerning IP address prefixes. You can only inject routes into a spoke if the prefix is shorter (less specific) than the virtual network prefix. Because of this limitation, the Application Gateway and the destination web server need to be in different virtual networks.
The following diagram shows the packet flow when the Route Server simplifies dynamic routing. Note these points:
Route Server currently requires the device that injects the routes to send them over Border Gateway Protocol (BGP). Since Azure Firewall Premium doesn't support BGP, use a third-party Network Virtual Appliance (NVA) instead.
The functionality of the NVA in the hub determines whether your implementation needs DNS.
As with Virtual WAN, you might need to modify the routing when you use Route Server. If you advertise the 0.0.0.0/0 route, it might propagate to the Application Gateway subnet. But Application Gateway doesn't support that route. In this case, configure a route table for the Application Gateway subnet. Include a route for 0.0.0.0/0 and a next hop type of Internet in that table.
Comments