Firewall Options for an Azure Virtual Network

In this post, I will explain several techniques that you can use to secure and protect Azure virtual networks.
 

 

The Importance of Virtual Network Security

If you’re reading this, then you’re not stupid and I don’t need to explain the importance of a firewall to you. We take it for granted that virtual machines in the cloud should have some level of firewall security. Azure offers us several ways that we can do this, which I will cover in this article. These same techniques are also important to the developer side of Azure, Platform-as-a-Service or PaaS, because many platforms use virtual networks for privacy or communications, such as Service Fabric or Azure Service Environment (ASE, where the Isolated App Service Tier is hosted).

Network Security Groups

Azure offers free Layer-4 security in the form of Network Security Groups or NSGs. Using an NSG, you can allow or deny TCP, UDP, or wildcard protocols into or out of a virtual network. An NSG contains default inbound rules and outbound rules, which block everything from outside the virtual network from coming in and allow everything outbound. You can create additional prioritized (or stacked) rules to take more control over network security.

 
An NSG object can be associated with either a virtual machine NIC or a subnet (a better practice) in a virtual network and filters traffic at that resource level. For example, a deny outbound rule associated with a NIC will prevent a packet leaving a virtual machine.
NSGs are the foundation of security but they have no comprehension of application layer security. For example, HTTP traffic might be allowed into a web server but the NSG has no idea if there are bad requests or SQL injection attacks going on. That’s all TCP traffic and anything at the application layer is higher up in the networking stack, above the NSGs pay grade, so to speak.

DDoS Protection

Azure provides DDoS protection at the virtual network layer. By default, every virtual network gets Basic tier protection. Recently, Microsoft made Standard tier DDoS protection generally available, extending protection with:

• Machine learning based scanning/blocking
• Payment protection in case an attack causes resource scale-out and additional costs

Web Application Firewall

If you deploy a web service, such as an Azure App Service or some HTTP/HTTPS service on a virtual network (virtual machines, Service Fabric, App Service Environment), then you can place the Web Application Gateway (WAG) in front of the web application. The WAG offers Layer-7 load balancing, with application-aware scale-out and high-availability. If you deploy the Medium or higher sizes of the WAG, then you have the option, at additional cost, of enabling the Web Application Firewall (WAF). The WAF adds Layer-7 security based on the open source OWASP rule set. With this extra layer of security, you get protection against things, such as SQL Injections or malformed HTTP requests.

Third-Party Firewalls

Microsoft has a pretty good pitch on things like load balancing and firewalls. Its line is that the built-in solutions will be good for a certain percentage of customers/services. However, specialized partners will always offer more and should be considered when you need more than Microsoft can offer.
Several third-party network security solutions can be found in the Azure Marketplace. These solutions deploy as Linux virtual machines with an additional software cost. In some Azure offers (ways of purchasing Azure) you can pay-per-minute for the additional software. However, if you plan to use the firewalls 24*7*365, a bring-your-own-license (BYOL) option might be more cost-effective in the long run. You pay for the virtual machine on a per-minute basis but you buy the software up front. Some names you’ll find in the Marketplace include Check Point, Barracuda, Sophos, Watchguard, Sonicwall, and more.

 
There are many ways that a firewall appliance can be deployed into a virtual network. One can put it on an edge subnet in the virtual network, protecting the edge. If you want in-depth security, a micro-segmentation approach might be better:

1. Create a dedicated subnet for the third-party firewall.
2. Deploy web, application, and data services in other subnets.
3. Enable forwarding on the NICs of the virtual appliances.
4. Deploy routing tables to the subnets to force all traffic through the inspection of the virtual appliances.

Micro-segmentation allows the firewall to inspect all packets both at Layer-4 and Layer-7 (in the case of application-aware appliances).
Typically, if one has the budget and need for a third-party firewall, then there will also be a budget and need for high-availability. Instead of deploying just a single appliance, one will deploy a cluster of them for scale-out and high-availability.
A cluster of firewall appliances will be presented through shared IP addresses:

• One for external traffic coming in
• A second for internal traffic inspection, if required

This can be accomplished by using Azure load balancers:

• An Azure load balancer or WAG with a public IP address for incoming traffic inspection.
• An Azure load balancer with an internal IP address for internal traffic inspection, if required.

Note: Always check with the vendor of the firewall appliance for recommended Azure architectures.

There are two tiers of load balancer and your choice will impact how the cluster can function:

• Basic tier: The free load balancer supports active/passive firewall appliances. You will get high-availability but you won’t get scale-out.
• Standard tier: The complex pricing of the Standard tier adds HA ports, enabling active/active firewalls to be deployed in a simpler manner. You will get both high-availability and scale-out.

The Guest OS

The last line of defense is the firewall of the guest OS, which many people forget is there. One gotcha is when you deploy a Windows Server + SQL Server image from the Azure Marketplace and it blocks inbound TCP 1433 traffic (SQL Server client-server communications) by default. The guest OS firewall provides depth in defense and should be left enabled and managed.