Protect your application gateway with Azure DDoS Network Protection

• 
  

This article helps you create an Azure Application Gateway with a DDoS protected virtual network. Azure DDoS Network Protection enables enhanced DDoS mitigation capabilities such as adaptive tuning, attack alert notifications, and monitoring to protect your application gateways from large scale DDoS attacks.

 Important

Azure DDoS Protection incurs a cost when you use the Network Protection SKU. Overages charges only apply if more than 100 public IPs are protected in the tenant. Ensure you delete the resources in this tutorial if you aren't using the resources in the future. For information about pricing, see Azure DDoS Protection Pricing. For more information about Azure DDoS protection, see What is Azure DDoS Protection.

In this tutorial, you learn how to:

• Create a DDoS protection plan
• Create an application gateway
• Associate a DDoS Protection plan to the virtual network
• Add VMs to the backend of the application gateway
• Test the application gateway

Prerequisites

An Azure account with an active subscription is required. If you don't already have an account, you can create an account for free.

Create a DDoS protection plan

1. Sign in to the Azure portal.

2. In the search box at the top of the portal, enter DDoS protection. Select DDoS protection plans in the search results and then select + Create.

3. In the Basics tab of Create a DDoS protection plan page, enter or select the following information:

   

   Setting	Value
   Project details
   Subscription	Select your Azure subscription.
   Resource group	Select Create new. Enter myResourceGroupAG. Select OK.
   Instance details
   Name	Enter myDDoSProtectionPlan.
   Region	Select Central US.

4. Select Review + create and then select Create to deploy the DDoS protection plan.

Create an application gateway

You'll create the application gateway using the tabs on the Create application gateway page.

1. On the Azure portal menu or from the Home page, select Create a resource.
2. Under Categories, select Networking and then select Application Gateway in the Popular Azure services list.

Basics tab

1. On the Basics tab, enter these values for the following application gateway settings:

   • Resource group: Select myResourceGroupAG for the resource group. If it doesn't exist, select Create new to create it.

   • Application gateway name: Enter myAppGateway for the name of the application gateway.

     

2. For Azure to communicate between the resources that you create, a virtual network is needed. You can either create a new virtual network or use an existing one. In this example, you'll create a new virtual network at the same time that you create the application gateway. Application Gateway instances are created in separate subnets. You create two subnets in this example: One for the application gateway, and another for the backend servers.

   
   

   Under Configure virtual network, create a new virtual network by selecting Create new. In the Create virtual network window that opens, enter the following values to create the virtual network and two subnets:

   • Name: Enter myVNet for the name of the virtual network.

   • Subnet name (Application Gateway subnet): The Subnets grid will show a subnet named default. Change the name of this subnet to myAGSubnet.
     The application gateway subnet can contain only application gateways. No other resources are allowed.

   • Subnet name (backend server subnet): In the second row of the Subnets grid, enter myBackendSubnet in the Subnet name column.

   • Address range (backend server subnet): In the second row of the Subnets Grid, enter an address range that doesn't overlap with the address range of myAGSubnet. For example, if the address range of myAGSubnet is 10.0.0.0/24, enter 10.0.1.0/24 for the address range of myBackendSubnet.

   Select OK to close the Create virtual network window and save the virtual network settings.

   

3. On the Basics tab, accept the default values for the other settings and then select Next: Frontends.

Frontends tab

1. On the Frontends tab, verify Frontend IP address type is set to Public.
   You can configure the Frontend IP to be Public or Private as per your use case. In this example, you'll choose a Public Frontend IP.

    Note

   For the Application Gateway v2 SKU, there must be a Public frontend IP configuration. You can still have both a Public and a Private frontend IP configuration, but Private only frontend IP configuration (Only ILB mode) is currently not enabled for the v2 SKU.

2. Select Add new for the Public IP address and enter myAGPublicIPAddress for the public IP address name, and then select OK.

   

3. Select Next: Backends.

Backends tab

The backend pool is used to route requests to the backend servers that serve the request. Backend pools can be composed of NICs, Virtual Machine Scale Sets, public IP addresses, internal IP addresses, fully qualified domain names (FQDN), and multi-tenant backends like Azure App Service. In this example, you'll create an empty backend pool with your application gateway and then add backend targets to the backend pool.

1. On the Backends tab, select Add a backend pool.

2. In the Add a backend pool window that opens, enter the following values to create an empty backend pool:

   • Name: Enter myBackendPool for the name of the backend pool.
   • Add backend pool without targets: Select Yes to create a backend pool with no targets. You'll add backend targets after creating the application gateway.

3. In the Add a backend pool window, select Add to save the backend pool configuration and return to the Backends tab.

   

4. On the Backends tab, select Next: Configuration.

Configuration tab

On the Configuration tab, you'll connect the frontend and backend pool you created using a routing rule.

1. Select Add a routing rule in the Routing rules column.

2. In the Add a routing rule window that opens, enter the following values for Rule name and Priority:

   • Rule name: Enter myRoutingRule for the name of the rule.
   • Priority: The priority value should be between 1 and 20000 (where 1 represents highest priority and 20000 represents lowest) - for the purposes of this quickstart, enter 100 for the priority.

3. A routing rule requires a listener. On the Listener tab within the Add a routing rule window, enter the following values for the listener:

   • Listener name: Enter myListener for the name of the listener.

   • Frontend IP: Select Public to choose the public IP you created for the frontend.

     Accept the default values for the other settings on the Listener tab, then select the Backend targets tab to configure the rest of the routing rule.

   

4. On the Backend targets tab, select myBackendPool for the Backend target.

5. For the Backend setting, select Add new to add a new Backend setting. The Backend setting will determine the behavior of the routing rule. In the Add Backend setting window that opens, enter myBackendSetting for the Backend settings name and 80 for the Backend port. Accept the default values for the other settings in the Add Backend setting window, then select Add to return to the Add a routing rule window.

   

6. On the Add a routing rule window, select Add to save the routing rule and return to the Configuration tab.

   

7. Select Next: Tags and then Next: Review + create.

Review + create tab

Review the settings on the Review + create tab, and then select Create to create the virtual network, the public IP address, and the application gateway. It may take several minutes for Azure to create the application gateway. Wait until the deployment finishes successfully before moving on to the next section.

Enable DDoS protection

Azure DDoS Network Protection is enabled at the virtual network where the resource you want to protect reside.

1. In the search box at the top of the portal, enter Virtual network. Select Virtual networks in the search results.

2. Select myVNet.

3. Select DDoS protection in Settings.

4. Select Enable.

5. In the pull-down box in DDoS protection plan, select myDDoSProtectionPlan.

   

6. Select Save.

Add backend targets

In this example, you'll use virtual machines as the target backend. You can either use existing virtual machines or create new ones. You'll create two virtual machines as backend servers for the application gateway.

To do this, you'll:

1. Create two new VMs, myVM and myVM2, to be used as backend servers.
2. Install IIS on the virtual machines to verify that the application gateway was created successfully.
3. Add the backend servers to the backend pool.

Create a virtual machine

1. On the Azure portal menu or from the Home page, select Create a resource. The New window appears.

2. Select Windows Server 2016 Datacenter in the Popular list. The Create a virtual machine page appears.
   Application Gateway can route traffic to any type of virtual machine used in its backend pool. In this example, you use a Windows Server 2016 Datacenter virtual machine.

3. Enter these values in the Basics tab for the following virtual machine settings:

   • Resource group: Select myResourceGroupAG for the resource group name.
   • Virtual machine name: Enter myVM for the name of the virtual machine.
   • Region: Select the same region where you created the application gateway.
   • Username: Type a name for the administrator user name.
   • Password: Type a password.
   • Public inbound ports: None.

4. Accept the other defaults and then select Next: Disks.

5. Accept the Disks tab defaults and then select Next: Networking.

6. On the Networking tab, verify that myVNet is selected for the Virtual network and the Subnet is set to myBackendSubnet. Accept the other defaults and then select Next: Management.
   Application Gateway can communicate with instances outside of the virtual network that it is in, but you need to ensure there's IP connectivity.

7. On the Management tab, set Boot diagnostics to Disable. Accept the other defaults and then select Review + create.

8. On the Review + create tab, review the settings, correct any validation errors, and then select Create.

9. Wait for the virtual machine creation to complete before continuing.

Install IIS for testing

In this example, you install IIS on the virtual machines to verify Azure created the application gateway successfully.

1. Open Azure PowerShell.

   Select Cloud Shell from the top navigation bar of the Azure portal and then select PowerShell from the drop-down list.

   

2. Run the following command to install IIS on the virtual machine. Change the Location parameter if necessary:

3. Create a second virtual machine and install IIS by using the steps that you previously completed. Use myVM2 for the virtual machine name and for the VMName setting of the Set-AzVMExtension cmdlet.

Add backend servers to backend pool

1. On the Azure portal menu, select All resources or search for and select All resources. Then select myAppGateway.

2. Select Backend pools from the left menu.

3. Select myBackendPool.

4. Under Backend targets, Target type, select Virtual machine from the drop-down list.

5. Under Target, select the myVM and myVM2 virtual machines and their associated network interfaces from the drop-down lists.

   

6. Select Save.

7. Wait for the deployment to complete before proceeding to the next step.

Test the application gateway

Although IIS isn't required to create the application gateway, you installed it in this quickstart to verify if Azure successfully created the application gateway.

Use IIS to test the application gateway:

1. Find the public IP address for the application gateway on its Overview page. Or, you can select All resources, enter myAGPublicIPAddress in the search box, and then select it in the search results. Azure displays the public IP address on the Overview page.

2. Copy the public IP address, and then paste it into the address bar of your browser to browse that IP address.

3. Check the response. A valid response verifies that the application gateway was successfully created and can successfully connect with the backend.

   

 

How to Protect your Azure resources from Distributed Denial of Service attacks

 

Distributed denial of service (DDoS) attacks are some of the largest availability and security concerns facing customers that are moving their applications to the cloud. A DDoS attack attempts to exhaust an application's resources, making the application unavailable to legitimate users. DDoS attacks can be targeted at any endpoint that is publicly reachable through the internet.

What is DDoS Protection? Protecting applications from DDoS attacks has been one of the top security concerns for Azure customers. Azure DDoS protection service is an Azure Networking offering aimed at protecting publicly accessible endpoints from DDoS attacks. The offering gives customers access to the same protection that is used to protect Microsoft's online assets, such as Xbox Live and Office 365. Azure DDoS protection service provides constant network flow monitoring of the protected endpoints, and when detecting a DDoS attack, automatically applies traffic scrubbing to make sure only legitimate requests are forwarded to the application.

Azure DDoS protection, combined with application design best practices, provide defense against DDoS attacks. Azure DDoS protection provides the following service tiers:

• Basic: Automatically enabled as part of the Azure platform. Always-on traffic monitoring, and real-time mitigation of common network-level attacks, provide the same defenses utilized by Microsoft's online services. The entire scale of Azure's global network can be used to distribute and mitigate attack traffic across regions. Protection is provided for IPv4 and IPv6 Azure public IP addresses.
• Standard: Provides additional mitigation capabilities over the Basic service tier that are tuned specifically to Azure Virtual Network resources. DDoS Protection Standard is simple to enable, and requires no application changes. Protection policies are tuned through dedicated traffic monitoring and machine learning algorithms. Policies are applied to public IP addresses associated to resources deployed in virtual networks, such as Azure Load Balancer, Azure Application Gateway, and Azure Service Fabric instances, but this protection does not apply to App Service Environments. Real-time telemetry is available through Azure Monitor views during an attack, and for history. Rich attack mitigation analytics are available via diagnostic settings. Application layer protection can be added through the Azure Application Gateway Web Application Firewall or by installing a 3rd party firewall from Azure Marketplace. Protection is provided for IPv4 Azure public IP addresses.

So how to start with DDoS in Azure.

First go to the Virtual Networks.

Next selecting the Network and in the left pane there is a section DDoS Protection.

Selecting the DDoS Protection there is the Basic and the Standard Setting

Pricing Details

There the Basic is the default and comes with free pricing.

The Standard is a different option and Cost you some real money! and these are monthly costs. For a demo I turned it on and forget to turned it of and spend 10K in 4 months so keep a track on your Azure costs.

The DDoS Protection service will have a fixed monthly charge, as well as a charge for data processed. The fixed monthly charge includes protection for 100 resources. Protection for additional resources will be charged on a monthly per-resource basis.

Monthly price for DDoS Protection (includes protection for 100 resources): €2,483/month

Overage charges (more than 100 resources): €25 per resource per month

 

When Enabling the DDoS Standard we need to create a DDoS protection plan first, if you have already one you can add the ID.

Check the create DDoS protection Plan

Now that we created a plan witch is more a resource place holder, we can add this to the DDoS protection plan

Now that the DDoS and the plan is in place we can create an alert rule in case we have a DDoS attack.

In the Azure Monitor we can create the alert rule and we can see the logging.

To see telemetry for a DDoS attack, log into the Azure Portal and navigate to the “Monitor” blade.

Within the monitor blade, click on “Metrics”, select the appropriate subscription, resource group, resource type of “Public IP” and the Public IP that was the target of the attack. After selecting the resource, a series of Available Metrics will appear on the left side. These metrics are selected and then will be graphed.

The metric names are relatively self-explanatory and the basic construct is that there are tag names on each metric as follows: • Dropped tag name (e.g. Inbound Packets Dropped DDoS): The number of packets dropped/scrubbed by the DDoS system

• Forwarded tag name (e.g: Inbound Packets Forwarded DDoS): The number of packets forwarded by the DDoS system to the destination VIP – traffic that was not filtered • No tag name (e.g: Inbound Packets DDoS): The total number of packets that came into the scrubbing system – representing the sum of the packets dropped and forwarded

The traffic shown in the Monitor dashboard.

Email Alerting To configure an email alert for a metric, click on the “Click to add an alert” text. An email alert can be created on any metric, but the most obvious metric to create an alert on is “Under DDoS attack or not”. This is a boolean value 1 or 0. “1” means you are under attack. “0” means you are not under attack. To be emailed when under attack, set the Metric for “Under DDoS attack or not” and “Condition” to “Greater than” zero (0) over the last 5 minutes. Similar alerts can be set up for other metrics. An example screenshot is provided below.

 

 

To divine the Severity I keep this as this is also be used in SCOM

Azure Monitor Alert Severity Levels

Sev 0 = Critical
Sev 1 = Error
Sev 2 = Warning
Sev 3 = Informational
Sev 4 = Verbose

Last part in selecting the email for this alert.

With this setup you got a good protection against DDoS attacks. below is the workflow how DDoS protection works.