Azure : What do I put in front of my (web) application?

Introduction

In almost every design session, the following question pops up…

“What do I put in front of my web application to secure it?”

Today we will take a look at the different options at hand. Or better said … What is the difference between the following services?

Azure CDN vs Azure Front Door versus Azure Application Gateway (WAF) vs Azure Traffic Manager

 

TL;DR

If you do not want to go through the entire post, here is a brief summary of the different options ;

My gut feeling tells me this will already help out like a lot! 😉

 

Web Application Firewall (WAF) : Azure Front Door vs Azure Application Gateway

Both Azure Front Door and Azure Application Gateway state that they can be configured to act as a Web Application Firewall. They key difference here is that the Azure Application Gateway can do a “detection only”-mode and that it supports CRS 2.2.9, 3.0, and 3.1. This means that there are out-of-the-box rules that provide a baseline security against most of the top-10 vulnerabilities that Open Web Application Security Project (OWASP) identifies. With Azure Front Door, you need to configure the rules yourself to your liking.

In terms of networking, there also is a very important difference between both. An Azure Application Gateway can be deployed (injected) in(to) an Azure VNET (Virtual Network). By doing so, the traffic between this gateway and your internal backend will flow through a private network. With Azure Front Door, your backend is always based on a public endpoint. Though you can harden / lock down the connectivity between Azure Front Door and your application by restricting the ingress of the traffic.

 

Geographic Redundancy : Azure Front Door vs Azure Traffic Manager

If you want to publish your webapp across regions, then you can leverage Azure Front Door or Azure Traffic Manager to do so. The most important thing to know is that Azure Traffic Manager is DNS based and serves as a redirection mechanism. Azure Front Door will serve as an entrypoint (think reverse proxy). So when using Traffic Manager, you will typically look at another reverse proxy / WAF (like Azure Application Gateway) to cover the need for the secure entrypoint for your application. Next to that, the Azure Traffic Manager is more feature rich in terms of the routing mechanisms, though Azure Front Door (just like Azure Application Gateway) have the advantage of working at layer 7 (Reference : OSI Model), thus also do header/path based routing.

 

Caching Content : Azure CDN vs Azure FrontDoor

The first thing to realize is what the intent was of both solutions?

• Azure CDN is a Content Delivery Network and was designed to delivery content. Think in terms of media files (“video”) for instance.
• Azure Front Door was built as a scalable entry point for applications (like Office 365)

Both will do caching (check the links above), though they differ in the sweet spots. Azure Front Door will cache files up to 8MB (as a side trait), where you should think that this is mainly done to optimize the delivery of your “web app”. Azure CDN its core function is caching… It was built to ensure that your files would be distributed world wide and delivered from a local pop.

The funky thing here, is that (if you ignore the Verizon and Akamai flavors of Azure CDN) both Azure CDN and Azure Front Door share the same POPs! Though the caching mechanics of both work differently.

 

DDOS

All services will have DDOS protection (“Basic”), as this is native to any Azure service! It is a key component of the Microsoft backbone actually. Though you can augment the services that reside in your VNET with the “Standard” protection. That being said, do know that the Azure Application Gateway does not scale as dynamic as the other services mentioned here (Azure Front Door and Azure Traffic Manager). So this could become a bottleneck for your design.

 

Closing Thoughts

With more than 100 services in Azure, you are bound to have services that overlap in terms of capabilities. I do hope this post provides you with some guidance towards a the external facing endpoints of your application! The above things are the recurring patterns I see in discussions with the organizations I talk to when deploying web applications on Azure.

Trying out the Azure Firewall in a Hub & Spoke deployment model

Introduction

A few weeks ago the Azure Firewall went into public preview. Today’s post will be around taking it for a spin in a hub & spoke deployment.

 

Architecture

First off, what will the architecture of our deployment look like?

• A central hub, where we’ll deploy the Azure Firewall. This will consist of the address space 172.16.0.0/12.
• Two spokes, each with their own address space (10.[1/2].0.0/16) where a UDR will send all traffic to the Azure Firewall (172.16.254.4).
• In each VNET, we’ll deploy a “SUBNET000” in which we’ll setup a vm to do our basic connectivity testing.
• Each spoke is connected with a bidirectional VNET peering with the spokes. Both spokes can only talk to each other over the HUB.
• The Azure firewall will be configured to allow traffic within the 10.0.0.0/8 range.

 

Azure Star / Any Load Balancer or … like we would like to call it “HA Ports”

Introduction

A few weeks ago the “HA Ports” (finally) saw the light (in public preview)! I’m truly excited about this one, as it had become a “unicorn” for me over the last years.

Why am I so excited about this one? This unlocks of advanced networking patterns, starting with a truly HA setup for the Network Virtual Appliances (NVAs). In the past, we needed to rely on “workarounds” that would switch the UDR to point to the surviving node. That was great for the time, but let’s be honest… It shouldn’t have been like that.

Another use case is the scenario where an application needs to connect to a certain dynamic port ranges (like with SQL). I’ve seen several deployments annoyed by this requirement, which then forced people to create a lot of rules. This can now be avoided by allowing the entire port range, and just hardening it with a “Network Security Group” or Firewall rule base.

Azure Networking : Blueprint patterns for enterprises

Introduction

When moving to the cloud, one cannot imagine this without some kind of network integration. Taking a look at “Infrastructure-as-a-Service”, there are several common patterns that are utilized by enterprises. Today we’ll discuss these patterns…

 

Update – June 2018

Despite that this post isn’t even a year old, I’ll be updating it with the new guidance that come from the introduction of the standard LB. Here we advise to use a single legged deployment.

 

Typical Network Maturity Models

Embarking on a cloud journey? You’ll typically go through the following patterns depending on your “maturity level” in working with the cloud ;

1. “Island” : The first approach is typically “the island”. The VMs reside in a VNET that is not connected/integrated with any other networks, except for (maybe) the internet.
2. “Hybrid Connection” : The first step towards integration is creating a hybrid connection. Here you want to access “On Premises” resources, though the mass of the resources on Azure do not justify the investment into a “Network Virtual Appliance” (AKA Firewall). Two flavours typically arise here;
   1. “Forced Tunneling” : Here you set up a “UDR” (User Defined Route, AKA Static Route), where you force all traffic to go back to the “On Premises” network.
   2. “Azure = Internet Zone” : Here you assume that the Azure zone is does what it needs to do to protect its resources Though you’ll protect your “On Prem” zone by considering the Azure VNET as being “the bad internet”.
3. “Single VNET with DMZ” : One step beyond “forced tunneling”, is moving towards the typical DMZ-alike pattern, where you setup a HA-pair of “Network Virtual Appliances” and segregate network zones.
4. “Hub & Spoke”-model : Growing even further, you’ll have multiple subscriptions. Setting up “NVAs” on all of those can be quite expensive. In terms of governance, this also a nice model, where you can consolidate all network integration into a segregated subscription/vnet.

The advantage of these patterns is that you can evolve into another pattern without breaking anything in terms of design.

Azure : Basic Network Hardening between a Webapp & the SQL Database

A quick tip on hardening your SQL database in combination with an Azure Webapp. Browse to the properties of your webapp. Copy the “outbound ip addresses” to your text editor.

Now browse to the “SQL Server” you have provisioned in Azure. Click on “Show firewall settings” and enter the IP addresses you just noted down.

A small pointer ; You have to enter this an address at the time and save after each entry… Annoying as hell, though this is how the UI works.

Anyhow, let’s see how our webapp behaves…

As you probably do not believe my right off the bat. So let’s clear up the firewall rules…

and test again!

Now we notice that the access to the database was denied. The address listed there is the one that was present in the outbound ip addresses listing from earlier on.

Have fun hardening!

Azure Networking : Do not forget the impact of Network Security Groups!

Introduction

In my last post I mentioned that the NSGs (Network Security Groups) had a serious impact on your deployment. So today I’ll be doing a quick demo a possible annoyance you might encounter.

The demo environment

About the same setup as the last time… One VNET, three subnets ; firewall in subnet 10.0.0.0/24, one server in 10.0.1.0/24 and another server in 10.0.2.0/24.

Azure Networking : Building a DMZ and adding Packet Inspection to all Traffic

Introduction

The last week I’ve been putting down a sweat on getting the following “basic” design working.

What do we see here? A virtual network with three subnets. The subnet “SUBNET000” will act as our “External DMZ”. We’ll put the Firewall (and other security related appliances) in here. The other subnets can fulfil different roles, as you want… Let’s imagine that the “SUBNET001” is our “Internal DMZ” and the “SUBNET002” is our “Server Network”.

And what do I want to achieve today? I want all traffic to flow through the firewall. This so I can control / inspect all flows and act accordingly. As a basic test, I want to be able to ping from 10.0.1.4 (subnet001) to 10.0.2.4 (subnet002) and I want to be able to browse to “www.kvaes.be” (internet) from 10.0.1.4 (subnet001). Both tests need to be performed with the firewall als virtual network appliance routing all traffic. This is needed, as otherwise the whole test is useless from a security perspective. 🙂 If I can do those two things, then I can prove that the you can control / inspect all traffic from your Azure network.

Setting up a DMZ in Azure? Firewall or Network Security Groups?

A question that often pops up is ; “How can I configure secure network zones in Azure?”

There are two ways towards tackling that question ;

• Traditional implementation with Firewall appliances
• Azure’s “Network Security Groups”

Both deployment models have their advantages and disadvantages…

Traditional Firewall
A traditional firewall deployment will act as central gateway through which all traffic needs to flow. This implies that the firewall is directly connected to all network zones. In the drawing below, we can see that the firewall is connected to three network zones; “Internet”, “Web Servers” & “Database Servers”. So from a physical networking point-of-view, the firewall has a seperate network connection to each of the three network zones.

When we would translate this model to Azure, then we would need to have a virtual machine with three network interfaces, where each network interface would provide a link to a seperate virtual network. In addition, the default gateway for each virtual network would need to be overriden to point to the firewall.

So far so good? Now be aware that the amount of network interfaces is limited by the size of your virtual machine. By default you will only get one network connection. The cheapest virtual machine to get two network connections is the “A3” (200€/month), four interfaces will need at lest the “A4” (400€/month), where for eight interfaces you will need to look towards the “D4” (811€/month) and for the maximum of sixteen you will need a “D14” (1,512€/month). So this isn’t cheap…

Now bear in mind, that you will only have paid for the machine itself… When we look towards the marketplace in the new portal, then we see appliances that can be purchased in a “pay-as-you-go”-manner. If we pick CheckPoint here, we can see that the list price here varies from ;

• A3 : 1665,10€ => 2 NICs
• A4 : 2892,45€ => 4 NICs
• D4 : 3003,26€ => 8 NICs
• D14 : 5489,08€ => 16 NICs

When looking towards such an outcome, most customers will say “Thank you very much, but no thank you!” in those sessions. And in all honesty, I fully comprehend the reaction, where I would say the same thing in their situation. Though, that does not solve their initial puzzle…

Network Security Groups
The alternative is setting up NSGs (Network Security Groups). Consider these a basic firewall implementation like the Windows Firewall or IPTables in *nix. How is it positioned by Azure?

A Network Security Group consists of a set of access control rules that describe traffic filters. These can be associated with a virtual machine or a subnet in the same region. The rules defined in the Network Security Group act as filters. On the ingress path they are applied before traffic enters the VM. On the egress path, they are applied after traffic leaves the VM. In short these rules are applied at the infrastructure level which can’t be altered by user processes or even the OS running in the VM. When the Network Security Group is associated with a subnet it applies to all the VMs in the subnet. Any change made on the Network Security Group is immediately is applied to all VMs in the subnet. Source

So with NSGs, you are capable of configuring a DMZ alike situation… What are the limitations?

• Maximum 100 NSGs per subscription. Maximum 200 rules per NSG.
• It only covers VM in a virtual network. So when you select “West Europe” instead of “MyPrivateVirtualNetwork”, then you cannot apply them.
• The configuration can only be done via PowerShell at the moment. But as we all know, the pace of Azure travels at Warp9, so a UI will come…)

So what Can I configure?

Some important aspects of the Network Security groups include:

• The rules contain a 5 tuple (Source IP, Source port, Destination IP, Destination port, protocol).
• The rules are stateful. This means if there is an inbound rule that allow traffic on a port (e.g. port 80), a matching rule on the outbound side is not required for the packets to flow on the same port.
• Every Network Security Group contains default rules that allow connectivity within the Virtual Network and Outbound access to Internet . These default rules can be overridden by the user rules.
• The rules are processed based on priority. Rules with small (meaning higher priority) values are processed before rules with larger (meaning lower priority) values.
• Azure provides defaults tags such as INTERNET and VIRTUAL_NETWORK that refers to the Public IP Address space outside the Virtual Network and customer’s entire network address space respectively. The tags can be used as part of an access control rule.

Comparing both
So when do I choose one over the other? It basically comes down to this…

• When you only need basic features, want to restrict your budget and you are not afraid of powershell… Go for Network Security Groups.
• When you need a lot of Enterprise features (deep packet inspection, central management, …) or pass beyond the basic featurs towards the things a “Next Generation Firewall” offers, then you need to go for a full blown firewall implementation.

Microsoft Azure : How to create a virtual machine with multiple network interfaces

When you are designing a network, the ability to have a secure gateway between subnets is vital. Therefor we’ll be looking into the possibility to create a virtual machine with multiple network interfaces.

What is possible?

Be aware that the size of your virtual machine will influence the amount of NICs you can create / configure ;

It was also a surprise for me that it is (currently) not possible to add/remove NICs after the creation of the virtual machine. Trust me, I’ve tried and a nice warning tells me that this is not supported.

More details can be found on the Azure documentation page “Create a VM with Multiple NICs“.

 Let’s try this one out!

 

Our Test Environment

We’ll have a virtual network with three subnet and we’ll create a machine that is linked to two of them.

Possible use cases?

• Firewall
• Load Balancer
• Back-Up System
• Management System
• …

 

Step One ; Configure your Azure PowerShell to use your Azure Account

• Open an Azure PowerShell.
• To download your publishsettingsfile, enter:

  Get-AzurePublishSettingsFile

• The download pop-up of your browser opens. Save the file.
• Import the publishsettingsfile by entering:

  Import-AzurePublishSettingsFile PATH_TO_FILE

 

Step Two ; Setup the basics

• Via the portal, create a virtual network “MULTIPLENICS” with three subnets ;
  
• Configure a storage account “multiplenicskvaes” ;
• Link the storage account to your subscription in Azure Powershell ;

  PS C:\> Get-AzureStorageAccount "multiplenicskvaes"
PS C:\> Set-AzureSubscription -SubscriptionName "Gratis proefversie" -CurrentStorageAccount multiplenicskvaes
PS C:\> Get-AzureSubscription

  

• Get the image we want to use for our deployment. In this example, we’ll take the most recent Windows image ;

  PS C:\> $image = Get-AzureVMImage | where { $_.ImageFamily -Match "Windows*"} | sort PublishedDate -Descending | select -ExpandProperty ImageName -First 1

  

 

Step 3 ; Let’s create some VMs!

• Create a basic configuration (plus account to login)
  PS C:\> $vm01 = New-AzureVMConfig -Name "KVAES01" -InstanceSize ExtraLarge -Image $image -AvailabilitySetName "KVAESNICSCLUSTER"
PS C:\> Add-AzureProvisioningConfig -Windows -AdminUsername "demouser" -Password "Demo1234?" -VM $vm01

• Let’s add the machine to a given subnet

  PS C:\> Set-AzureSubnet -SubnetName "TIER000" -VM $vm01

  

• Now let’s add an additional NIC from another subnet

  PS C:\> Add-AzureNetworkInterfaceConfig -Name "NIC1" -SubnetName "TIER001" -StaticVNetIPAddress "192.168.1.100" -VM $vm01

  

• And finally, let’s press “create” 🙂

  PS C:\> New-AzureVM -ServiceName "KVAES01" -VM $vm01 -Location "West Europe" -VNetName "MULTIPLENICS"

  
  

Step 4 ; Verify that everything went according to plan!

• Wait for the machine to leave the “Provisioning” state
  (good time to get some coffee/tea/… whatever)
• Let’s note down the public ip & port which we’ll need to use for the “Remote Desktop Connection” .
  
• And let’s connect to it…
  
• Startup the console and type “ipconfig” to see what network interfaces are available
  

Import things to remember

• (Currently) you can only add/remove network interfaces upon creation.
• Despite that the feature is not visible via the GUI, you are able to use multiple NICs in different subnets.
• The limitation in regards to the number of NICs is related to the machine type.