Microsoft Azure

Implementing a DMZ for Microsoft Azure Virtual Machines

tiny-people-working-on-computer-hero-img

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.
An Azure DMZ made from user-defined routes, a virtual appliance firewall and NSGs (Image Credit: Microsoft)
An Azure DMZ made from user-defined routes, a virtual appliance firewall and NSGs (Image Credit: Microsoft)

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.

Sponsored Content

What is “Inside Microsoft Teams”?

“Inside Microsoft Teams” is a webcast series, now in Season 4 for IT pros hosted by Microsoft Product Manager, Stephen Rose. Stephen & his guests comprised of customers, partners, and real-world experts share best practices of planning, deploying, adopting, managing, and securing Teams. You can watch any episode at your convenience, find resources, blogs, reviews of accessories certified for Teams, bonus clips, and information regarding upcoming live broadcasts. Our next episode, “Polaris Inc., and Microsoft Teams- Reinventing how we work and play” will be airing on Oct. 28th from 10-11am PST.

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.
The Azure virtual network subnets (Image Credit: Aidan Finn)
The Azure virtual network subnets (Image Credit: Aidan Finn)

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.

The user defined routes for a DMZ in Azure (Image Credit: Aidan Finn)
The user defined routes for a DMZ in Azure (Image Credit: Aidan Finn)

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.

Associate a routing table with a subnet (Image Credit: Aidan Finn)
Associate a routing table with a subnet (Image Credit: Aidan Finn)

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.

Creating a NSG rule (Image Credit: Aidan Finn)
Creating a NSG rule (Image Credit: Aidan Finn)

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.

Related Topics:

BECOME A PETRI MEMBER:

Don't have a login but want to join the conversation? Sign up for a Petri Account

Register
Comments (1)

One response to “Implementing a DMZ for Microsoft Azure Virtual Machines”

  1. <p>I'm a little confused on how to create firewall rules when there are no "zone". When i create a rule I use the interfaces as the zone with my on-prim fortinet, but when I want a webserver in the DMZ to talk to my application server in the data subnet how would i create the rule. The interface for incoming and outgoing would be the same interface. </p>

Leave a Reply

Aidan Finn, Microsoft Most Valuable Professional (MVP), has been working in IT since 1996. He has worked as a consultant and administrator for the likes of Innofactor Norway, Amdahl DMR, Fujitsu, Barclays and Hypo Real Estate Bank International where he dealt with large and complex IT infrastructures and MicroWarehouse Ltd. where he worked with Microsoft partners in the small/medium business space.
External Sharing and Guest User Access in Microsoft 365 and Teams

This eBook will dive into policy considerations you need to make when creating and managing guest user access to your Teams network, as well as the different layers of guest access and the common challenges that accompany a more complicated Microsoft 365 infrastructure.

You will learn:

  • Who should be allowed to be invited as a guest?
  • What type of guests should be able to access files in SharePoint and OneDrive?
  • How should guests be offboarded?
  • How should you determine who has access to sensitive information in your environment?

Sponsored by:

 
Live Webinar: Active Directory Security: What Needs Immediate Priority!Live on Tuesday, October 12th at 1 PM ET

Attacks on Active Directory are at an all-time high. Companies that are not taking heed are being punished, both monetarily and with loss of production.

In this webinar, you will learn:

  • How to prioritize vulnerability management
  • What attackers are leveraging to breach organizations
  • Where Active Directory security needs immediate attention
  • Overall strategy to secure your environment and keep it secured

Sponsored by: