Security Challenge on Azure
There are few common security related questions when we start planning migration to Azure:
- How can we restrict the ingress and egress traffic on Azure ?
- How can we route the traffic on Azure ?
- Can we have Firewall kit, Intrusion Prevention System (IPS), Network Access Control, Application Control and Anti – Malware on Azure DMZ ?
This blog post intention is to answer above questions using following Azure features combined with Security Virtual Appliance available on Azure Marketplace:
- Azure Virtual Network (VNET)
- Azure Network Security Groups (NSGs)
- Azure Network Security Rule
- Azure Forced Tunelling
- Azure Route Table
- Azure IP Forwarding
- Barracuda NG Firewall available on Azure Marketplace
One of the most common methods of attack is The Script Kiddie / Skiddie / Script Bunny / Script Kitty. Script Kiddies attacks frequency is one of the highest frequency and still is. However the attacks have been evolved into something more advanced, sophisticated and far more organized. The diagram below illustrates the evolution of attacks:
The main target of the attacks from the lowest sophistication level of the attacks to the most advanced one is our data. Data loss = financial loss. We are working together and sharing the responsibility with our cloud provider to secure our cloud environment. This blog post will focus on Azure environment.
Defense in Depth
Based on SANS Institute of Information Security. Defense in depth is the concept of protecting a computer network with a layer of defensive mechanisms. There are varies of defensive mechanisms and countermeasures to protect our Azure environment because there are many attack scenarios and attack methods available.
In this post we will use combination of Azure Network Security Groups to establish Security Zone discussed previously on my previous blog, deploy network firewall including Intrusion Prevention System on our Azure network to implement additional high security layer and route the traffic to our security kit. On Secure Azure Network blog we have learned on how to establish the simple Security Zone on our Azure VNET. The underlying concept behind the zone model is the increasing level of trust from outside into the center. On the outside is the Internet – Zero Trust which is where the Script Kiddies and other attackers reside.
The diagram below illustrates the simple scenario we will implement on this post:
There are four main configurations we need to do in order to establish solution as per diagram above:
- Azure VNET Configuration
- Azure NSG and Security Rules
- Azure User Defined Routes and IP Forwarding
- Barracuda NG Firewall Configuration
In this post we will focus on the last two items. This tutorial link will assist the readers on how to create Azure VNET and my previous blog post will assist the readers on how to establish Security Zone using Azure NSGs.
Barracuda NG Firewall
The Barracuda NG Firewall fills the functional gaps between cloud infrastructure security and Defense-In-Depth strategy by providing protection where our application and data reside on Azure rather than solely where the connection terminates.
The Barracuda NG Firewall can intercept all Layer 2 through 7 traffic and apply Policy – based controls, authentication, filtering and other capabilities. Just like its physical device, Barracuda NG Firewall running on Azure has traffic management capability and bandwidth optimizations.
The main features:
- PAYG – Pay as you go / BYOL – Bring your own license
- ExpressRoute Support
- Network Firewall
- Application Control
- IDS – IPS
- Network Access Control Management
- Advanced Threat Detection
- Centralized Management
Above features are necessary to establish a virtual DMZ in Azure to implement our Defense-In-Depth and Security Zoning strategy.
Choosing the right size of Barracuda NG Firewall will determine the level of support and throughput to our Azure environment. Details of the datasheet can be found here.
I wrote handy little script below to deploy Barracuda NG Firewall Azure VM with two Ethernets :
User Defined Routes in Azure
Azure allows us to re-defined the routing in our VNET which we will use in order to re-direct the routing through our Barracuda NG Firewall. We will enable IP forwarding for the Barracuda NG Firewall virtual appliance and then create and configure the routing table for the backend networks so all traffic is routed through the Barracuda NG Firewall.
There are some notes using Barracuda NG Firewall on Azure:
- User-defined routing at the time of writing cannot be used for two Barracuda NG Firewall units in a high availability cluster
- After the Azure routing table has been applied, the VMs in the backend networks are only reachable via the NG Firewall. This also means that existing Endpoints allowing direct access no longer work
Step 1: Enable IP Forwarding for Barracuda NG Firewall VM
In order to forward the traffic, we must enable IP forwarding on Primary network interface and other network interfaces (Ethernet 1 and Ethernet 2) on the Barracuda NG Firewall VM.
Enable IP Forwarding:
Enable IP Forwarding on Ethernet 1 and Ethernet 2:
On the Azure networking side, our Azure Barracuda NG Firewall VM is now allowed to forward IP packets.
Step 2: Create Azure Routing Table
By creating a routing table in Azure, we will be able to redirect all Internet outbound connectivity from Mid and Backend subnets of the VNET to the Barracuda NG Firewall VM.
Firstly, create the Azure Routing Table:
Next, we need to add the Route to the Azure Routing Table:
As we can see the next hop IP address for the default route is the IP address of the default network interface of the Barracuda NG Firewall (192.168.0.54). We have extra two network interfaces which can be used for other routing (192.168.0.55 and 192.168.0.55).
Lastly, we will need to assign the Azure Routing Table we created to our Mid or Backend subnet.
Step 3: Create Access Rules on the Barracuda NG Firewall
By default all outgoing traffic from the mid or backend is blocked by the NG Firewall. Create an access rule to allow access to the Internet.
Download the Barracuda NG Admin to manage our Barracuda NG Firewall running on Azure and login to our Barracuda NG Admin console:
Create a PASS access rule:
- Source – Enter our mid or backend subnet
- Service – Select Any
- Destination – Select Internet
- Connection – Select Dynamic SNAT
- Click OK and place the access rule higher than other rules blocking the same type of traffic
- Click Send Changes and Activate
Our VMs in the mid or backend subnet can now access the Internet via the Barracuda NG Firewall. RDP to my VM sitting on Mid subnet 192.168.1.4, browse to Google.com:
Let’s have a quick look at Barracuda NG Admin Logs 🙂
And we are good to go using same method configuring the rest to protect our Azure environment:
- Backend traffic to go pass our Barracuda NG Firewall before hitting the Mid traffic and Vice Versa
- Mid traffic to go pass our Barracuda NG Firewall before hitting the Frontend traffic and Vice Versa
I hope you’ve found this post useful – please leave any comments or questions below!