If you have been working with Azure Infrastructure services, then you would have come across Core Network offerings such as Azure Traffic manager, Azure Load balancers & Application Gateways. These network services provide solutions for applications that require high availability, security & scalability, but they also come with their own limitations. One such limitation is that they primarily exist in single regions (regional services). Azure Traffic manager for instance, which works at the DNS level for cross region support, cannot perform path-based routing and the failover time is based on TTL of the DNS record.
To overcome the regional limitation and make these services available globally, Microsoft introduced the Azure Front Door service. I will try to summarise this new offering and how it works when integrated with an Azure Web Application Firewall, the workflow and the security settings.
Azure Front Door Service enables us to define, manage, and monitor the global routing of web traffic by optimizing for best performance with instant global failover and high availability. It works at the layer 7 of the OSI model (Application layer or HTTP/HTTPS layer) and uses the Anycast protocol with split TCP and Microsoft’s global network for improving global connectivity. One of the primary benefits of using Azure Front Door is that utilizes Microsoft’s vast global network.
The table below describes a breakdown of the current capabilities of Azure Front door:
|Capability||Azure Front door|
|Dynamic Site acceleration (DSA) – application performance||√|
|Global load balancing||√|
|Multiple Site Hosting||√|
|Secure Sockets Layer (SSL) offloading||√|
|Custom domains and certificate management||√|
|URL rewrite / re-direct||√|
|Increase application availability with smart health probes||√|
|Alerts / Monitoring||√|
|Application layer security||√|
|HTTP -> HTTPs Redirect||√|
Note: The backend pools or Azure resource must have a public IP address or a publicly resolvable DNS hostname.
Azure WAF with Azure Front Door
Azure Web Application Firewall (WAF) is designed to protect web applications from multiple attack vectors such as injection type and volumetric DoS attacks. Azure WAF, when integrated with Front Door, stops denial-of-service and targeted application attacks at the Azure network edge, close to the attack sources before they enter your virtual network, offering protection without sacrificing performance.
Azure WAF provides centralized protection for web applications that are globally delivered using Azure Front Door. It is designed to defend web services against common exploits and vulnerabilities and keep these services highly available for your users in addition to meeting compliance requirements.
WAF policy can be configured in two modes:
- Detection: This mode does not take any actions based on rules, it simply monitors and logs the request.
- Prevention: This mode takes specific action based on rules defined and if a match is found, no other rules are evaluated.
The table below describes a breakdown of the capabilities of Azure Front door with WAF:
|Capability||Azure Front door|
|Custom response code||√|
|Managed Bot Protection rules – Preview||√|
|Geographic based access control||√|
|Azure Managed Rule sets||√|
Azure Frond door with WAF Policies- Workflow
The diagram below shows the process/workflow of Azure front door with WAF.
- When a client wants to access a web application, the request reaches the Front door environment where pre-defined vulnerabilities or threats are validated at the WAF.
- Front door evaluates the rules based on the incoming request and forwards or denies the request to backend resource. Additionally, it also checks the health probe of the backend resource.
- The user request is then serviced by the backend resource / pool.
Azure Frond door with WAF Policies
To defend Azure resources, Front door offers rules and actions. Let’s talk about rules first.
Custom rules: These rules are always processed first and is written with the specific need of the client. Custom Rules has different options:
- IP allow and block list – this is configured to allow or deny requests based on source IP address to match the list in rules.
- Geographic – This controls the access of web application based on country code associated with source IP address.
- Request Method based – This controls the access based on the request method such as GET & PUT.
- Rate limit – This rule configures the threshold on the number of requests allowed from the source IP address at specific interval times.
Managed Rule sets: These are pre-configured set of rules provided by Azure.
An IP address–based access control rule is a custom WAF rule that controls access to web applications. We can limit access from clients to a list of known IP addresses or address ranges by creating an IP matching rule that contains the list of IP addresses as matching values and set the logical operator to “NOT” (to negate is true) and the action set to “Block”.
After an IP restriction rule is applied, any request originating from addresses outside this allowed list, will receive a 403 Forbidden response.
Actions – Azure front door provides the following actions:
- Allow: The user request is validated and sent through to be processed by the backend.
- Block: The user request is blocked, and a response is sent to the client. The request is not forwarded to the backend.
- Log: The user request is logged, and validation of rules continues with lower priorities.
- Re-direct: WAF with front door will redirect all requests that matches the specific URI.
Azure Frond door – Security
To lock down backend resources to accept traffic only via the Front Door, we need to setup the actions below:
- configure IP ACLs for the backend resource/pool to accept traffic only from Azure Front Door’s backend IP address spaces. Additionally, Azure Front Door supports Service tags for NSGs and list of IP addresses for PaaS Services. (https://www.microsoft.com/en-us/download/details.aspx?id=56519)
- Restrict the set of accepted values for the header “X-Frowarded -host” sent by front door. This needs a few lines of codes on your backend application. If this is not set and it could lead the backend resources accessible via another front door, since IP ACL has range of ip address and not a specific ip address of Front door. This section decides the usage of Front door with your resources.