What is Azure Web Application Firewall on Azure Application Gateway?

• 
  

The Azure Web Application Firewall (WAF) on Azure Application Gateway actively safeguards your web applications against common exploits and vulnerabilities. As web applications become more frequent targets for malicious attacks, these attacks often exploit well-known vulnerabilities such as SQL injection and cross-site scripting.

WAF on Application Gateway is based on the Core Rule Set (CRS) from the Open Web Application Security Project (OWASP).

All of the following WAF features exist inside of a WAF policy. You can create multiple policies, and they can be associated with an Application Gateway, to individual listeners, or to path-based routing rules on an Application Gateway. This way, you can have separate policies for each site behind your Application Gateway if needed. For more information on WAF policies, see Create a WAF Policy.

Application Gateway operates as an application delivery controller (ADC). It offers Transport Layer Security (TLS), previously known as Secure Sockets Layer (SSL), termination, cookie-based session affinity, round-robin load distribution, content-based routing, ability to host multiple websites, and security enhancements.

Application Gateway enhances security through TLS policy management and end-to-end TLS support. By integrating WAF into Application Gateway, it fortifies application security. This combination actively defends your web applications against common vulnerabilities and offers a centrally manageable, easy-to-configure location.

Benefits

This section describes the core benefits that WAF on Application Gateway provides.

Protection

• Protect your web applications from web vulnerabilities and attacks without modification to back-end code.

• Protect multiple web applications at the same time. An instance of Application Gateway can host up to 40 websites that are protected by a web application firewall.

• Create custom WAF policies for different sites behind the same WAF.

• Protect your web applications from malicious bots with the IP Reputation ruleset.

• Protect your application against DDoS attacks. For more information, see Application DDoS Protection.

Monitoring

• Monitor attacks against your web applications by using a real-time WAF log. The log is integrated with Azure Monitor to track WAF alerts and easily monitor trends.

• The Application Gateway WAF is integrated with Microsoft Defender for Cloud. Defender for Cloud provides a central view of the security state of all your Azure, hybrid, and multicloud resources.

Customization

• Customize WAF rules and rule groups to suit your application requirements and eliminate false positives.

• Associate a WAF Policy for each site behind your WAF to allow for site-specific configuration

• Create custom rules to suit the needs of your application

Features

• SQL injection protection.
• Cross-site scripting protection.
• Protection against other common web attacks, such as command injection, HTTP request smuggling, HTTP response splitting, and remote file inclusion.
• Protection against HTTP protocol violations.
• Protection against HTTP protocol anomalies, such as missing host user-agent and accept headers.
• Protection against crawlers and scanners.
• Detection of common application misconfigurations (for example, Apache and IIS).
• Configurable request size limits with lower and upper bounds.
• Exclusion lists let you omit certain request attributes from a WAF evaluation. A common example is Active Directory-inserted tokens that are used for authentication or password fields.
• Create custom rules to suit the specific needs of your applications.
• Geo-filter traffic to allow or block certain countries/regions from gaining access to your applications.
• Protect your applications from bots with the bot mitigation ruleset.
• Inspect JSON and XML in the request body

WAF policy and rules

To enable a Web Application Firewall on Application Gateway, you must create a WAF policy. This policy is where all of the managed rules, custom rules, exclusions, and other customizations such as file upload limit exist.

You can configure a WAF policy and associate that policy to one or more application gateways for protection. A WAF policy consists of two types of security rules:

• Custom rules that you create

• Managed rule sets that are a collection of Azure-managed preconfigured set of rules

When both are present, custom rules are processed before processing the rules in a managed rule set. A rule is made of a match condition, a priority, and an action. Action types supported are: ALLOW, BLOCK, and LOG. You can create a fully customized policy that meets your specific application protection requirements by combining managed and custom rules.

Rules within a policy are processed in a priority order. Priority is a unique integer that defines the order of rules to process. Smaller integer value denotes a higher priority and those rules are evaluated before rules with a higher integer value. Once a rule is matched, the corresponding action that was defined in the rule is applied to the request. Once such a match is processed, rules with lower priorities aren't processed further.

A web application delivered by Application Gateway can have a WAF policy associated to it at the global level, at a per-site level, or at a per-URI level.

Core rule sets

Application Gateway supports multiple rule sets, including CRS 3.2, CRS 3.1, and CRS 3.0. These rules protect your web applications from malicious activity.

For more information, see Web application firewall CRS rule groups and rules.

Custom rules

Application Gateway also supports custom rules. With custom rules, you can create your own rules, which are evaluated for each request that passes through WAF. These rules hold a higher priority than the rest of the rules in the managed rule sets. If a set of conditions is met, an action is taken to allow or block.

The geomatch operator is now available for custom rules. See geomatch custom rules for more information.

For more information on custom rules, see Custom Rules for Application Gateway.

Bot protection rule set

You can enable a managed bot protection rule set to take custom actions on requests from all bot categories.

Three bot categories are supported:

• Bad

  Bad bots include bots from malicious IP addresses and bots that falsify their identities. Bad bots with malicious IPs are sourced from the Microsoft Threat Intelligence feed’s high confidence IP Indicators of Compromise.

• Good

  Good bots include validated search engines such as Googlebot, bingbot, and other trusted user agents.

• Unknown

  Unknown bots are classified via published user agents without more validation. For example, market analyzer, feed fetchers, and data collection agents. Unknown bots also include malicious IP addresses that are sourced from Microsoft Threat Intelligence feed’s medium confidence IP Indicators of Compromise.

The WAF platform actively manages and dynamically updates bot signatures.

You can assign Microsoft_BotManagerRuleSet_1.0 by using the Assign option under Managed Rulesets:

When Bot protection is enabled, it blocks, allows, or logs incoming requests that match bot rules based on the action you've configured. It blocks malicious bots, allows verified search engine crawlers, blocks unknown search engine crawlers, and logs unknown bots by default. You have the option to set custom actions to block, allow, or log different types of bots.

You can access WAF logs from a storage account, event hub, log analytics, or send logs to a partner solution.

WAF modes

The Application Gateway WAF can be configured to run in the following two modes:

• Detection mode: Monitors and logs all threat alerts. You turn on logging diagnostics for Application Gateway in the Diagnostics section. You must also make sure that the WAF log is selected and turned on. Web application firewall doesn't block incoming requests when it's operating in Detection mode.
• Prevention mode: Blocks intrusions and attacks that the rules detect. The attacker receives a "403 unauthorized access" exception, and the connection is closed. Prevention mode records such attacks in the WAF logs.

WAF engines

The Azure web application firewall (WAF) engine is the component that inspects traffic and determines whether a request includes a signature that represents a potential attack. When you use CRS 3.2 or later, your WAF runs the new WAF engine, which gives you higher performance and an improved set of features. When you use earlier versions of the CRS, your WAF runs on an older engine. New features are only available on the new Azure WAF engine.

WAF actions

You can choose which action is run when a request matches a rule condition. The following actions are supported:

• Allow: Request passes through the WAF and is forwarded to back-end. No further lower priority rules can block this request. Allow actions are only applicable to the Bot Manager ruleset, and aren't applicable to the Core Rule Set.
• Block: The request is blocked and WAF sends a response to the client without forwarding the request to the back-end.
• Log: Request is logged in the WAF logs and WAF continues evaluating lower priority rules.
• Anomaly score: This is the default action for CRS ruleset where total anomaly score is incremented when a rule with this action is matched. Anomaly scoring isn't applicable for the Bot Manager ruleset.

Anomaly Scoring mode

OWASP has two modes for deciding whether to block traffic: Traditional mode and Anomaly Scoring mode.

In Traditional mode, traffic that matches any rule is considered independently of any other rule matches. This mode is easy to understand. But the lack of information about how many rules match a specific request is a limitation. So, Anomaly Scoring mode was introduced. It's the default for OWASP 3.x.

In Anomaly Scoring mode, traffic that matches any rule isn't immediately blocked when the firewall is in Prevention mode. Rules have a certain severity: Critical, Error, Warning, or Notice. That severity affects a numeric value for the request, which is called the Anomaly Score. For example, one Warning rule match contributes 3 to the score. One Critical rule match contributes 5.

Severity	Value
Critical	5
Error	4
Warning	3
Notice	2

There's a threshold of 5 for the Anomaly Score to block traffic. So, a single Critical rule match is enough for the Application Gateway WAF to block a request, even in Prevention mode. But one Warning rule match only increases the Anomaly Score by 3, which isn't enough by itself to block the traffic.

Configuration

You can configure and deploy all WAF policies using the Azure portal, REST APIs, Azure Resource Manager templates, and Azure PowerShell. You can also configure and manage Azure WAF policies at scale using Firewall Manager integration (preview). For more information, see Use Azure Firewall Manager to manage Web Application Firewall policies (preview).

WAF monitoring

It's important to monitor the health of your application gateway. You can support this by integrating your WAF and the applications it protects with Microsoft Defender for Cloud, Azure Monitor, and Azure Monitor logs.

Azure Monitor

Application Gateway logs are integrated with Azure Monitor. This allows you to track diagnostic information, including WAF alerts and logs. You can access this capability on the Diagnostics tab in the Application Gateway resource in the portal or directly through Azure Monitor. To learn more about enabling logs, see Application Gateway diagnostics.

Microsoft Defender for Cloud

Defender for Cloud helps you prevent, detect, and respond to threats. It provides increased visibility into and control over the security of your Azure resources. Application Gateway is integrated with Defender for Cloud. Defender for Cloud scans your environment to detect unprotected web applications. It can recommend Application Gateway WAF to protect these vulnerable resources. You create the firewalls directly from Defender for Cloud. These WAF instances are integrated with Defender for Cloud. They send alerts and health information to Defender for Cloud for reporting.

Microsoft Sentinel

Microsoft Sentinel is a scalable, cloud-native, security information event management (SIEM) and security orchestration automated response (SOAR) solution. Microsoft Sentinel delivers intelligent security analytics and threat intelligence across the enterprise, providing a single solution for alert detection, threat visibility, proactive hunting, and threat response.

With the built-in Azure WAF firewall events workbook, you can get an overview of the security events on your WAF. This includes events, matched and blocked rules, and everything else that gets logged in the firewall logs. More information on logging follows.

Azure Monitor Workbook for WAF

This workbook enables custom visualization of security-relevant WAF events across several filterable panels. It works with all WAF types, including Application Gateway, Front Door, and CDN, and can be filtered based on WAF type or a specific WAF instance. Import via ARM Template or Gallery Template. To deploy this workbook, see WAF Workbook.

Logging

Application Gateway WAF provides detailed reporting on each threat that it detects. Logging is integrated with Azure Diagnostics logs. Alerts are recorded in the .json format. These logs can be integrated with Azure Monitor logs.

Azure Application Gateway

 

What is Azure Application Gateway?

Azure Application Gateway is a load balancing solution provided by Microsoft Azure. This web traffic load balancer works on Layer 7 of the OSI model and enables you to manage traffic for your web applications. Unlike traditional load balancers that operate at Layer 4 and route traffic based on source IP address and port, Azure Application Gateway makes routing decisions based on additional attributes of an HTTP request such as URI path or host headers.

Azure Application Gateway gives you application-level routing and load balancing services that let you build a scalable and highly-available web front end in Azure.

Azure Application Gateway is a helpful tool for web traffic managers, and it works similar to AWS Application Gateway wherein we can make routing decisions based on URI or host headers. For example, you can route traffic based on the incoming URL. If /Images or /Videos are in the URL, then you can route to the specific set of servers configured for Images or Videos. It can also be used for SSL or TLS termination as well.

The following is an example to help you understand the concept better:

You can route traffic based on the incoming URL. If you request an image and it has a corresponding image URL, you will be routed to a particular incoming URL. Similarly, if a video is the incoming URL, you will be routed to another set of servers, which is specifically optimized for videos.

If you are interested in learning Azure, take a look at our Azure tutorial to learn more!

Why is Azure Application Gateway Needed?

Many enterprises, merchants, and suppliers around the globe access their clients’ web applications to perform online credit card payments. The entire process includes processing, verification, and reporting of payment that must be done efficiently and securely.

The deployment setup and architecture of applications to accomplish such tasks was primarily developed using classic Active Server Pages (ASP). One of the biggest drawbacks of classic ASP was that it was hosted on a single instance Windows 2003 32-bit OS server and was not PCI compliant. This legacy system used a standard Microsoft SQL server 2005 database for storage and had no documentation pertaining to the DLLs. Apart from this, some of the other capabilities the system lacked were the inability to scale on-demand and control system downtime. As the system had not been upgraded for over 15 years, it lacked the ability to support the latest security and high-capacity infrastructure standards.

Considering all the above-mentioned drawbacks of the legacy system, clients aimed at shifting to Azure Application Gateway via the IaaS platform. The main notion behind this shift was to provide an advanced and secure payment platform having all the latest security features. What further strengthened the decision to switch to Azure was to reduce maintenance requirements and costs, increase performance, and achieve zero downtime and data loss.

Transitioning from legacy systems to IaaS migration via Azure was a win-win situation for enterprises and their customers. In some cases, unencrypted communication to servers is not acceptable because of security standards, compliance, etc. In those scenarios, AFW is helpful for end-to-end TLS/SSL encryption.

In order to further comprehend what makes Azure Payment Gateway an excellent service for enterprises and their customers, let us discuss some of its features in detail.

Prepare for the Azure Interview and crack like a pro with these Azure Interview Questions.

Benefits of Azure Application Gateway

Generally, Azure Application Gateway has a couple of exciting features, ranging from improving security and handling dynamic workload to performance optimization and much more. Let us discuss the features of Azure Application Gateway in detail:

Connection draining:

It is something that helps in gracefully removing the backend member from the pool. For example, if there is a set of five servers in a pool and one of them is reported as unhealthy by the health probe or it requires a periodic update, then the Application Gateway helps in the removal of that particular server.

All existing connections to that particular server are kept until all requests to that server are completed.

Secure Socket Layer (SSL) termination:

Azure Application Gateway helps in SSL termination at the gateway level itself, allowing communication between backend instances. This feature removes the encryption and decryption overhead from the backend server, and that makes the entire process a little faster and also decreases the response time. But this feature is sometimes not accessible to businesses. That is why, there is an end-to-end SSL feature that prevents data being read or secretly modified.

Web application firewall:

This is probably one of the most interesting features of Azure Application Gateway; it provides centralized protection of web applications from common security threats and vulnerabilities. It supports open web application security project (OWASP).

Multiple site hosting:

This feature of Azure Application Gateway allows a single application gateway to host multiple sites, upto 100+ websites, that point to the same application gateway. For example, if you have multiple websites, you can point all of them to the same application gateway. The application gateway can then send it to the respective URL based on the incoming URL.

Redirection:

One of the most important benefits of Azure Application Gateway is redirection. It is very useful in cases where an application gets the request over HTTP, but it has to be redirected to HTTPS. Through the gateway, redirection can be easily done to external websites as well.

Autoscaling:

It handles the dynamic workload by scaling up and down. This feature is useful in eliminating the problem of estimating the size instances needed to be deployed.

Session affinity:

In Application Gateway, session affinity is maintained by transferring the income request from the session to the same server. This is required when the session is maintained at the local server.

Static VIP:

This feature helps in providing static VIP to Application Gateway whenever needed. Static VIP feature ensures that its endpoint addresses will not change over its lifecycleHeader Rewrite, allowing it to perform operations, such as add, remove, or update HTTP request and response headers, on Application Gateway.

How does Azure Application Gateway Work?

In this section of the blog, you will learn how Application Gateway works. Let us first understand how it accepts request:

When a user sends a request to the Application Gateway, the domain name is resolved by a Domain Name System (DNS) server. The request can be from the public internet or over the intranet, depending on the configuration. Azure controls the DNS entry because all application gateways are in the azure.com domain. The Azure DNS then returns the IP address to the client, which is called the frontend IP address of the application gateway.

The application gateway accepts incoming traffic from one or more listeners. A listener is a logical entity that checks for connection requests sent on the public or private IP addresses and has a defined set of rules.

To establish connections from the client-side, the application gateway is configured with a frontend IP address, protocol, and port number. If a web application firewall (WAF) is in use, the application gateway checks the request headers and the body, if present, against WAF rules. This helps in determining whether a request is a valid request or a security threat. In the case of the former, the request is routed to the backend, but if it is the latter, the request is blocked as a security threat. If the request is in detection mode, it is evaluated and logged but still forwarded to the backend server.

Master the core concepts of Azure through this Azure Course for becoming a Certified Administrator.

Step-by-step Configuration of Azure Application Gateway

Step 1: Visit the Azure portal and search for “Application gateways” and then click “Add”.

Step 2: After this, fill in all the basic details such as the resource group, autoscaling details, and virtual network. Also create a new VNet, if it does not exist before, and then click on “Frontends”.

Step 3: After you have clicked on “Frontend” in the previous step, choose “Frontend IP address type”, create a new Public IP address, and then click on “Backends”.

Step 4: Now, select the required backend pool for the application gateway and then click on “Configuration”.

Step 5: Under “Configuration”, add a routing rule; enter the “Rule name” and then specify the routing rules here along with the backend targets. Turn “Error page url” to Yes to add a link for the static web page to a storage account.

Step 6: For each backend target, create a specific HTTP setting; click on “Create new” under “HTTP setting”, and specify the backend protocol and port.

Step 7: To add a routing rule, specify the target type, path, and HTTP setting for that backend target. After that, click on “Save changes” and go back to routing rules.

Step 8: The default route and multiple path-based rule targets will appear under Backend targets; here, click on “Add” after filling in the details.

Step 9: You will be able to view Frontends, Routing rules, and Backend pools for the application gateway; click on “Review + create” to deploy the application gateway.

Step 10: Click on “Go to resource” to access the application gateway, and copy the Frontend public IP address of the application gateway to test it.

Step 11: As the last step of the configuration, paste the IP address, along with the specific path-based routing, to check if the application gateway is running.

Check out our Microsoft Azure Training Bangalore, to help you master its core concepts.

Azure Application Gateway Pricing

Microsoft offers its Application Gateway with different pricing tiers. The cost of the service varies from company to company depending on the total usage and the gateway type. As the Application Gateway is offered as a SaaS platform, there are no upfront fees and nothing is charged in the name of contract termination fees. Microsoft’s terms and conditions offer standard clauses for a pay-as-you-go contract.

The following image mentions how the basic pricing for the Azure Application Gateway will work for an organization operating from central USA:

 

Operator sign up and service onboarding for Microsoft Connected Cache

Prerequisites

Before you begin sign up, ensure you have the following components:

1. Azure Pay-As-You-Go subscription: Microsoft Connected Cache is a completely free-of-charge service hosted in Azure. You'll need to have a Pay-As-You-Go subscription in order to onboard to our service. To create a subscription, go to the Pay-As-You-Go subscription page.

    Note

   Microsoft Connected Cache is a completely free service for operators. None of the resources created in Azure will incur any charges. However, be aware that any additional services that might be selected as part of the Azure sign-up process might incur charges.

2. Access to Azure portal: Ensure you have the credentials needed to access your organization's Azure portal.

3. Peering DB: Ensure your organization's Peering DB page is up-to-date and active. Check that the NOC email listed is accurate, and that you have access to this email.

4. Server: Ensure the server you wish to install Microsoft Connected Cache on is ready, and that the server is installed on Ubuntu 20.04 LTS.

5. Configure cache drive: Make sure that you have a data drive configured with full permissions on your server. You'll need to specify the location for this cache drive during the cache node configuration process. The minimum size for the data drive is 100 GB. For instructions to mount a disk on a Linux VM, see Attach a data disk to a Linux VM.

Resource creation and sign up process

1. Navigate to the Azure portal. Select Create a Resource. Then, search for Microsoft Connected Cache.

   

2. Select Create to create a Microsoft Connected Cache. When prompted, choose the subscription, resource group, and location of your cache node. Also, enter a name for your cache node.

   

   After a few moments, you'll see a "Validation successful" message, indicating you can move onto the next step and select Create.

   

3. The creation of the cache node may take a few minutes. After a successful creation, you'll see a Deployment complete page as below. Select Go to resource.

   

4. Navigate to Settings > Sign up. Enter your organization ASN. Indicate whether you're a transit provider. If so, additionally, include any ASN(s) for downstream network operators that you may transit traffic for.

   

5. Once we verify the information entered, a verification code will be sent to the NOC email address provided on Peering DB. Once you receive the email, navigate to your Azure portal > Microsoft Connected Cache > Settings > Verify operator, and enter the verification code sent to the NOC email address.

   
   

   

   
   

6. Once verified, follow the instructions in Create, provision, and deploy cache node to create your cache node.