Implementing a DMZ for Microsoft Azure Virtual Machines

In this post I’ll show you how you can create a DMZ for hosting an n-tier application based on Azure virtual machines, using a combination of Azure features: a multiple subnet virtual network, a firewall appliance from the Azure Marketplace, network security groups, and user-defined routing.

Design

In this article I’ll be using a design that was discussed in “Designing a DMZ for Azure Virtual Machines.” The specific design in question uses:

• Virtual network: The network is split into three subnets, one for security, one for web servers, and the third for backend servers.
• Virtual firewall appliance: This is a third-party firewall that runs in a special Azure virtual machine that can be deployed from the Azure Marketplace — check with the original vendor on how they license or bill for the appliance in addition to the virtual machine charges. The firewall appliance provides application-layer security between the Internet and the service, and between the networks and machines within the service.
• Network security groups (NSGs): NSGs are used to create protocol and port rules to enforce routing via the firewall appliance so that firewall rules and inspection are always used.
• User defined routing (UDR): We need to override default routing between the virtual network subnets and route via the virtual firewall appliance.

Resource Group

Normally, I like to wrap up all components of a service in a single resource group and then create a resource group for the online service. I’ve created one called PetriDMZ.

Virtual Network

A single virtual network is created in the resource group. There are three subnets:

• Security: This subnet is the public face of the service and is where the firewall virtual appliance will be located.
• FrontEnd: The web servers of the service run in this subnet.
• BackEnd: Application and database servers run in this completely isolated subnet.

User Defined Routing

Our goal is that all traffic must route via the firewall in the security subnet. This requires one routing table for the back-end subnet and another for the front-end subnet with at least two rules:

• Override internal routing: We must override the default routes between the front end (10.0.1.0/14) and the back end (10.0.2.0/24) subnets with a rule for the virtual network 10.
• Override global routing: All traffic to all other destinations (0.0.0.0/0) must be routed via the firewall, too.

Note that the firewall will be deployed with a reserved private IP address of 10.0.0.4.

With the above configuration, no machine can talk directly to a machine in a different subnet. Even machines in the same subnet will communicate via the firewall, which is probably desirable, but you can override this behavior with an additional rule to allow intra-subnet traffic to route directly within the subnet.
Here are the rules for the front-end subnet, including the optional third rule called FrontEnd:

Route Name	Address Prefix	Next Hop Type	Next Hop Address
Network	10.0.0.0/16	Virtual appliance	10.0.0.4
Everywhere	0.0.0.0/0	Virtual appliance	10.0.0.4
FrontEnd	10.0.1.0/24	Virtual network	N/A

And here are the rules for the back-end subnet, including the optional third rule called BackEnd:

Route Name	Address Prefix	Next Hop Type	Next Hop Address
Network	10.0.0.0/16	Virtual appliance	10.0.0.4
Everywhere	0.0.0.0/0	Virtual appliance	10.0.0.4
BackEnd	10.0.2.0/24	Virtual network	N/A

Associate the front-end routing table with the front-end subnet and the back-end routing table with the back-end subnet.

Network Security Groups

Next, we will create simple network security groups (NSGs), each with a single rule, whose purpose is to protect against manual error. Security is actually being provided by the firewall. The NSG rule puts in a simple filter to prevent any traffic from the Internet-reaching machines in either the front-end or back-end subnets; everything must route vie the security subnet.
Create two NSGs, one called FrontEnd and one called BackEnd. Each will be configured with an identical single inbound security rule, as shown below.

Associate the front-end NSG with the front-end subnet and the back-end NSG with the back-end subnet.
There is a chance that you’ll decide to extend the rules in the NSGs to provide an extra level of protection between the front-end and back-end subnets, beyond what the firewall appliance offers. If so, you can:

• Override the default rule to block all VNet-internal traffic, which is allowed by default.
• Create additional rules that allow each acceptable application protocol.

Firewall Appliance

The exact instructions for deploying and configuring your virtual firewall is provided by the vendor of the virtual appliance.
There are three considerations in this design:

• The virtual appliance is deployed into the security subnet.
• You will reserve the IP address of 10.0.0.4 for the virtual appliance.
• You must enable IP forwarding for the virtual NIC of this virtual appliance to allow it to route and redirect traffic.

In my example, I’ve used Azure V2 or Azure Resource Manager (ARM). The following piece of PowerShell will be used to enable IP forwarding for a virtual machine called PetriDMZFW in the PetriDMZ resource group:

$RgName = “PetriDMZ”
$VMName = “PetriDMZFW”
$NicName = ((Get-AzureRmVM -ResourceGroupName $RgName -Name $VmName).NetworkInterfaceIDs).Split("/")[-1] | Out-GridView -Title "Select a NIC to configure forwarding ..." –PassThru

Next, you’ll get the configuration of that NIC using the following line:

$NicConfig = Get-AzureRmNetworkInterface -ResourceGroupName $RgName -Name $NicName

And finally, enable IP forwarding:

$NicConfig.EnableIPForwarding = $true
$NicConfig | Set-AzureRmNetworkInterface

There are two remaining steps:

• Create and edit the NSG of the security subnet to allow your desired inbound traffic from the Internet.
• Use the administration tool of the virtual firewall appliance to create all of the external and internal firewall rules that your n-tier application requires.