Azure AppGW with WAF: A Comprehensive Guide

Azure Application Gateway (AppGW) with Web Application Firewall (WAF) is a powerful solution to protect web applications from common web exploits, including SQL injection, cross-site scripting (XSS), and other attacks. It offers a scalable and highly available solution to manage and secure web traffic to your web applications. In this article, we will discuss how to use Azure AppGW with WAF to protect web applications.

What is Azure Application Gateway (AppGW) with Web Application Firewall (WAF)?

Azure Application Gateway is a layer 7 load balancer that provides traffic management and secure web application delivery. It is designed to provide scalable and highly available web traffic management and protection for your web applications. It supports multiple protocols, including HTTP, HTTPS, and WebSocket, and can be used to route traffic to different backend servers based on URL path or host headers.

Web Application Firewall (WAF) is a security feature that helps protect web applications from common web exploits by filtering and monitoring traffic between the web application and the Internet. WAF can be used to prevent attacks such as SQL injection, cross-site scripting (XSS), and other attacks by inspecting traffic and blocking malicious requests.

Using Azure Application Gateway with WAF provides additional security features such as bot protection, threat intelligence, and managed rulesets to protect your web applications from the latest threats.

Azure Application Gateway is a Layer 7 load balancer that works as a reverse proxy to manage and secure web traffic to your web applications. It can accept HTTP, HTTPS, and WebSocket requests and route them to different backend servers based on URL path or host headers.

When a client sends a request to the Application Gateway, the following steps take place:

1. The client sends a request to the Application Gateway’s public IP address using HTTP or HTTPS protocol.

2. The DNS resolution system resolves the hostname to the public IP address of the Application Gateway.

3. The Application Gateway receives the request on the listener, which is configured to accept requests on specific ports and protocols.

4. The Application Gateway inspects the request to determine the routing rules that apply to the request.

5. If SSL termination is enabled, the Application Gateway decrypts the SSL traffic and forwards the request to the backend servers as HTTP traffic. Otherwise, the request is forwarded to the backend servers as SSL traffic.

6. The Application Gateway uses the routing rules to determine the backend pool to which the request should be forwarded.

7. The Application Gateway sends the request to one of the backend servers in the backend pool.

8. The backend server processes the request and sends the response back to the Application Gateway.

9. The Application Gateway inspects the response to determine whether any processing is needed, such as content-based routing or caching.

10. The Application Gateway sends the response back to the client.

There are a number of components that make up an application gateway. These components include:

• Frontend IP addresses: Frontend IP addresses are the public IP addresses that clients use to connect to the application gateway.
• Listeners: Listeners are resources that define how the application gateway should listen for and accept traffic.
• Request routing rules: Request routing rules are used to determine which backend pool to route a request to.
• HTTP settings: HTTP settings are used to configure the behavior of the application gateway for HTTP traffic.
• Backend pools: Backend pools are groups of servers that are responsible for handling requests for a particular application.
• Health probes: Health probes are used to monitor the health of the servers in a backend pool.
• SSL certificates: SSL certificates are used to secure connections between the application gateway and clients.
• Web application firewall (WAF): The WAF is a feature of the application gateway that can be used to protect your web applications from common web application attacks.

Application Gateway components and routing flow

Web application firewall (WAF) is an optional component that can be added to an application gateway. It helps to protect your web applications from a variety of attacks, such as SQL injection, cross-site scripting, and denial-of-service attacks.

The WAF works by inspecting all incoming requests and blocking any that match known attack patterns. It also has a number of other features that can help to improve the security of your web applications, such as:

• Request rate limiting: This feature can be used to prevent attackers from sending too many requests to your web application.
• Bot detection: This feature can be used to identify and block automated bots, such as scrapers and crawlers.
• Content filtering: This feature can be used to block malicious content, such as malware and phishing attacks.

The WAF is a powerful tool that can help to protect your web applications from a variety of attacks. It is easy to configure and manage, and it can be a valuable addition to any web application security strategy.

Here are some additional information about WAF:

• WAF rule sets: The WAF uses a set of rules to identify and block malicious requests. These rules are called rule sets. There are two rule sets available for the WAF: CRS 2.2.9 and CRS 3.0. CRS 3.0 is the default and more recent of these rule sets.
• WAF rule conditions: The WAF can be configured to only block requests that match certain conditions. For example, you can configure the WAF to only block requests that come from a specific IP address or that contain a specific string.
• WAF rule actions: The WAF can be configured to take different actions when it blocks a request. For example, you can configure the WAF to log the request, block the request, or challenge the user for authentication.

It is important to implement other security measures, such as firewalls and intrusion detection systems, to protect your web applications from attack.

Note: WAF can be deployed with Azure Application Gateway, Azure Front Door, and Azure Content Delivery Network (CDN) service from Microsoft.

There are 100 rules in AppGW with WAF. When a request comes in, AppGW will evaluate these rules in the following order:

1. Rule priority: WAF rules can be assigned a priority, with higher-priority rules being evaluated before lower-priority rules. This allows you to control the order in which rules are evaluated and to ensure that the most important rules are evaluated first.
2. Rule conditions: WAF rules can be configured with conditions that must be met in order for the rule to be evaluated. This allows you to fine-tune the behavior of the WAF and to ensure that rules are only evaluated for requests that match the specified conditions.
3. Rule actions: WAF rules can be configured to take a variety of actions, including blocking requests, logging requests, and challenging clients for authentication. This allows you to customize the behavior of the WAF and to respond to a variety of threats.

If a rule matches a request, AppGW will take the action that is specified for that rule. If no rule matches a request, AppGW will allow the request to continue. Let’s go deaper into the evaluation process of WAF rules.

The evaluation process of WAF rules for each incoming request is documented in the following sequence:

1. The network traffic is directed to the Azure Application Gateway, and the corresponding listener receives the traffic.
2. The Application Gateway examines the request against the configured “WAF Policy”.
3. The “Custom Rules” are given priority. The WAF selects the rule with the lowest number in priority, and the rule with the lowest cost is assessed first.
4. The WAF evaluates the “Custom Rule #01”. If it is true, the WAF applies it and disregards the other rules. If it is not applicable (false), the WAF identifies the rule with the next highest priority/cost.
5. The WAF evaluates the “Custom Rule #02”. If it is true, the WAF applies it and disregards the other rules. If it is not applicable (false), the WAF identifies the rule with the next highest priority/cost.
6. If none of the “Custom Rules” are applicable (all = false), the “Managed Rules” are utilized. All rules have an associated action that is executed when the rule is true, either granting or denying network traffic.
7. If the action permits network traffic (allow traffic), the WAF policy reports this to the Azure Application Gateway, which grants access to the backend pool as requested.
8. If the action denies network traffic (deny traffic), the requested access is blocked by the Application Gateway.

Request routing and WAF rule evaluation

In summary:

To use WAF on AppGW, you must first create a WAF policy. A WAF policy is a collection of rules that define how WAF will inspect traffic. You can create a new WAF policy from scratch, or you can use one of the pre-defined policies that are provided by Azure.

Once you have created a WAF policy, you must assign it to an AppGW listener. A listener is a resource that defines how AppGW will listen for and accept traffic. When you assign a WAF policy to a listener, AppGW will inspect all traffic that is received on that listener and block any requests that match a rule in the WAF policy.

Please let me know if need to go deeper into configuring WAF rules and explain each use cases of them and to identify how to test it out.

#Azure #AppGW #WAF #Firewall