Azure Networking Security – Where to Start?

If you’ve read any of my blog posts regarding networking in Azure, you might have guessed it’s one of my favourite topics. For ITops, it’s one of the shifts in thinking required to make a change to cloud. As software-defined-networking is one of the core concepts required for a successful cloud implementation, it’s no surprise that the security of that networking is a close second.

Looking at it as simply as possible, good network security means allowing only required traffic and preventing everything else while logging what is useful for auditing. Azure offers several integrated services that can help achieve this.

With that in mind, there are three major scenarios to deal with when it comes to Azure networking:

  1. Azure Resource to Azure Resource
  2. Azure Resource to on-premises Resource
  3. Azure Resource to/from the Internet

I will reference each as we cover the different best practises available.

Access Control

Good network access control requires layering. In Azure, the most common networking concept is a vnet. A vnet does not, by default, get access to another vnet. However, within a vnet, every subnet, by default, has access to each other. So, the subnet layer is most likely where you will need to address access control. In Azure this can be done in two, free, simple ways. Custom Route Tables and/or Network Security Groups.

Custom Route Tables are exactly as they sound. They modify the system route table using routes you specify. If your route matches a system route, it will take preference, user defined routes always do. Similarly the lowest prefix match will always win. More on route tables here. CRTs are applied at subnet level and can quickly manipulate network traffic for your entire vnet. For example, preventing internet access by dropping traffic to 0.0.0.0/0.

Network Security Groups are a little bit more complex in application, but their concept is straight forward. They are an ACL for your network. They can be applied at subnet or network interface level. While NSGs allow you to create complex and granular rules quite simply, managing them at scale can be a challenge. More on them here.

Firewall

While the above allows for control of the network from a routing and access perspective, you may also need to control traffic by inspection and filtering. Within Azure, there are two main options for this; Azure Firewall or a 3rd party NVA.

Azure Firewall was released last year and is a stateful, firewall-as-a-service resource. It offers HA and scalability, however, it’s still a young product and therefore light on traditional network security options. More on it here.

Thankfully, Azure and network appliance vendors have been working better together recently. Most solutions you would expect are available in the Marketplace. The common gripe is that documentation can be light if not bad. However, if you need continuity with your local site, or a specific feature well then they are your best choice. My advice is to reach out to the Azure community if you are having issues, generally someone will have had the same issue and can help!

Perimeter

It’s best to start with some basic architecture decisions relative to your Azure perimeter.

  • Will Azure have a public perimeter?
  • Will it be inbound and outbound?
  • What requirements are there for a private perimeter?

Once the above are answered, you have a couple of well documented implementation options. They all operate on the same premise of layering. This allows for segregation of traffic most commonly with a firewall aspect. This combined with UDR can lead to a well designed and secure environment allowing only the network access required. Therefore layering everything that has been discussed already.

Monitoring

In Azure, there are two major tools to help you with this:

  • Azure Network Watcher
  • Azure Security Center

Network Watcher is one of my favourite tools in Azure. Within a couple of minutes, you can gain granular insights into your complex network issues with minimal effort. You can also integrate the output to other Azure services like Monitor and Functions to react to alerts and capture traffic automatically (*notes to self* must blog that).

Security Center, as it does for other infrastructure, offers insights into your network topology and can provide actionable recommendations at scale. Meaning you have a single pane to sanity check your network, regardless of how complex it may be.

If you take the time to understand and implement the above, you’re well on your way to having a secure networking environment. However, every single environment and workload should be treated as unique. The best network security is constantly auditing and reassessing itself. Be proactive to avoid having to be reactive!

As always, get in touch with any questions or to chat about your go-to network security steps.

Azure Firewall – Where to Start?

About a year ago, Microsoft introduced the first release of Azure Firewall. Since then, and since its general release the service has grown and the features have matured.

To begin, let’s understand what Azure Firewall is? At its core it’s a managed, network security service that protects your Azure Virtual Network resources. It functions as a stateful firewall-as-a-service and offers built-in high availability and scalability. This means you can centrally control, enforce and log all of your network traffic. It fully integrates with Azure Monitor too which means all of the usual logging and analytical goodness.

If the above sounds like something you’d like to use, or at least try, in your Azure environment, read on! To start, let’s break out what can be configured within Azure Firewall and which features could be useful for you.

When deploying an Azure Firewall, you need a couple of things in advance. It needs a dedicated subnet, specifically named “AzureFirewallSubnet” and the minimum size it can be is a /26. It also needs at least one Static Public IP. The Public IP must be on the Standard tier. My recommendation here is to look at creating a Public IP Prefix in advance of creating your Azure Firewall. That way, if you need to delete it and redeploy, you can continue to use the same Public IP again and again. If you want to use multiple Public IPs, it supports up to 100.

So, let’s look at what Azure Firewall (AFW) can do for you on your Virtual Network and then consider some deployment options.

Access

Using your single, or multiple Public IP addresses, AFW allows both source and destination NATing. Meaning it can support multiple inbound ports, such as HTTPS over 443 to different resources. Outbound SNAT helps greatly with services that require white-listing. If you are using multiple Public IPs, AFW randomly picks one for SNAT, so ensure you include all of them in your white-listing requirements.

Protection

AFW uses a Microsoft service called Threat Intelligence filtering. This allows Azure Firewall to alert and deny traffic to and from known malicious IPs and domains. You can turn this setting off, set it to just alert or to both alert and deny. All of the actions are logged.

Filtering

Finally, for filtering, AFW can use both Network Traffic and Application FQDN rules. This means that you can limit traffic to only those explicitly listed within the rule collections. For example, an application rule that only allows traffic to the FQDN – www.wedoazure.ie

A visual representation of the above features is below:

Firewall overview

Now that you understand AFW, let’s look at how to configure to your needs. Normally I would go into the deployment aspect, but it is excellently documented already and relatively easy to follow. However, there are some aspects of the configuration that warrant further detail.

Once deployed, you must create a Custom Route Table to force traffic to your AFW. In the tutorial, it shows you how to create a route for Internet traffic (0.0.0.0/0), however you may want the AFW to be your central control point for your vnet traffic too. Don’t forget, traffic between subnets is not filtered by default. Routing all traffic for each subnet to AFW could allow you to manage which subnet can route where centrally. For example, if we have three subnets, Web, App and DB. A single route table applied to each subnet can tunnel all traffic to AFW. On the AFW you can then allow Web to the Internet and the App subnet. The App subnet can access Web and DB but not Internet and finally the DB subnet can only access the App subnet. This would all be achieved with a single Network Rule collection.

Similarly you can allow/block specific FQDNs with an Application Rule collection. In the tutorial, a single FQDN is allowed. This means that all others are blocked as that is the default behaviour. This might not be practical for your environment and the good news is, you can implement the reverse. With the right priority order, you can allow all traffic except for blocked FQDNs.

A feature you may also want to consider trying is destination NATing. This thankfully has another well documented tutorial on Docs.

Finally, and in some cases most importantly, let’s look at price. You are charged in two ways for AFW. There is a price per-hour-per-instance. That means if you deploy and don’t use it for anything, you will pay approx. €770 per-month (PAYG Calculator). On top of that, you will pay for both data inbound and outbound that is filtered by AFW. You’re charged the same price either direction and that’s approx. €14 per-Tb-per-month. Depending on your environment and/or requirements this price could be OK or too steep. My main advice is to ensure you understand it before deploying!

As always, if there are any questions please get in touch!

Virtual Network Service Endpoints

When designing an application deployment to be hosted in Azure, a design consideration that is commonly enticing is to transform a layer of the application from traditional infrastructure to something more modern. Microsoft offer several Platform-as-a-service (PAAS) options that allow this to be achieved, for example, transforming SQL server installed on a VM to Azure SQL.

While this transformation might be straight forward from an SQL Database point of view and most likely when considering the cost of running your deployment, a concern that often arises is security. As Azure SQL is PAAS, it offers a public endpoint for SQL authentication and connectivity. This is by design and there are limited options to prefix this with a security layer. If your application runs somewhere outside Azure, this makes sense and might be an acceptable and noted weak spot. However, if the rest of your application layers are hosted within Azure, having to route out to a public endpoint is less secure than it could be and simply bad design.

Thankfully, Microsoft have been making updates to virtual network functionality that allow you to route directly from your virtual network resources to several PAAS offerings. To do this, you must make use of virtual network Service Endpoints.

Endpoints extend your virtual network private address space and the identity of your VNet to specific Azure services, over a direct connection. Endpoints allow you to secure your critical Azure service resources, such as Azure SQL, to only your virtual networks. Traffic from your VNet to the Azure service always remains on the Microsoft Azure backbone network and never takes a public route. They are currently available for three PAAS offerings:

  1. Azure SQL
  2. Azure Storage
  3. Azure Data Warehouse (Preview)

Introducing an Endpoint for Azure SQL (to stick with the initial example) allows improved security as it fully removes public Internet access and allows traffic only from the virtual network.

It also optimises routing as Endpoints always take service traffic directly from your virtual network to the service itself on the Microsoft Azure backbone network. Doing this means that if your environment uses forced-tunnelling this traffic will no longer be viewed as outbound, but intra-Azure and will flow direct.

There are some considerations to be aware of:

  • Location – the virtual network and the PAAS offering must be located in the same region.
  • Outbound Network Flow – if you control outbound network flow via NSG, you can make use of the “Azure Service” tags to allow this traffic via Endpoint.
  • Connections – If you enable a service endpoint, all current TCP connections from your virtual network will drop. This is to allow a change from Public IP access to Private.

Personally, I think Endpoints should be used as widely as possible. From a security and design perspective they allow greater ease of adoption when PAAS offerings are being considered and perhaps best of all, they are free!

User Defined Routing

How traffic is routed within and between Azure networks isn’t something that is immediately apparent to the average admin. Therefore trying to increase the complexity of this for security reasons or by adding a virtual appliance can offer several challenges. As more companies begin to adopt a cloud strategy these scenarios will become more common. I’m here to tell you that with a little patience, taking full control of traffic routing in your Azure environment only takes a couple of well planned steps.

This is something you should see repeated often when reading about Azure; everything starts with the Virtual Network. When you create a Virtual Network (vnet) you must define some simple parameters, we’ll focus on two of these for this blog post, Address Space and Subnets.

If you are planning on a cloud-only environment, you can choose whatever address space you like (well, almost… any range defined in RFC1918) but, I would always recommend you plan vnets with the possibility they will be linked to your LAN. It is much easier to plan for this now than trying to resolve it later, trust me.

Choosing how to divide your address space up into several subnets also requires careful consideration. To start with, not all of the addresses in a subnet are usable, Azure reserves the first, last and three other addresses for Azure services. So you need to ensure there are enough usable addresses in each subnet for its intended use.

Once the above steps are completed, Azure creates a system routing table. This defines how traffic will route both within and out of the vnet. It is a combination of your vnet address space and Azure defined address spaces. Below are the effective routes for a demo network interface sitting in a vnet with the address space 10.0.0.0/16

system_routing

As you can see, all of the source definitions are ‘Default’ indicating they are system generated. The entry noted with ‘next hop type’ of ‘Virtual Network’ is our vnet address space, this defines the traffic as local. The rest are added by default to cover system and internet routing, more on those here.

The above table applies to all subnets within the vnet, so if you had a requirement for an incredibly secure vnet that could not route to the internet, only local traffic, you could introduce a user defined route table to overwrite the system route.

Routing in Azure is done by longest prefix match (LPM) this means that if the system table defines a 0/16 and you define a 0/24 and traffic is bound for that address space, it will follow the 0/24 route. If the LPM is an exact match, the following order is adhered to:

  1. User defined route
  2. BGP route (when ExpressRoute is used)
  3. System route

So using our example above, we would create a UDR and define a route for traffic bound for 0.0.0.0/0 as having a ‘next hop’ of none. This will prevent any outbound traffic, with the exception of your vnet (remember, LPM) from being able to route entirely.

The below grab of my demo VM effective routes shows how the system route is now marked as invalid and my user route has precedence.

udr

There are many other scenarios where this can be useful, for example if you have a site-to-site VPN and would like all internet traffic to tunnel through on-premise appliances you can force tunnel traffic to the gateway.

Similarly if you have an appliance as part of your vnet within Azure, you can route all traffic to and from it as you see fit. Remember to always view the effective routes being applied to a network interface before pushing to a live production environment!

My final recommendation if using UDRs in your environment is to add a Network Watcher object. It greatly simplifies analysing and troubleshooting routing. There are multiple powershell and CLI commands you can also make use of for troubleshooting.

If you’ve any questions etc, get in touch!