Recently I’ve migrated a bunch of Virtual Box Virtual Machines to Azure as detailed here. These VM’s are in Resource Groups with a Network Security Group associated that restricts access to them for RDP based on a source TCPIP address. All good practice. However from a usability perspective, when I want to use these VM’s, I’m not always in the same location, and rarely on a connection with a static IP address. This post details a simple little script that;
Has a couple of variables associated with a Resource Group, Network Security Group, Virtual Machine Name and an RDP Configuration File associated with the VM
Gets the public IP Address of the machine I’m running the script from
Prompts for Authentication to Azure, and retrieves the NSG associated with the Resource Group
Compares the Source IP Address in the ‘RDP’ Inbound Rule to my current IP Address. If they aren’t a match it updates the Source IP Address to be my current public IP Address
Starts the Virtual Machine configured at the start of the script
Launches Remote Desktop using the RDP Configuration file
Here’s the raw script. Update lines 2-8 for your environment and away you go. Simple but useful as is often the way.
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
IDS – IPS
Network Access Control Management
Advanced Threat Detection
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!
At TechEd Europe 2014, Microsoft announced the General Availability of Network Security Groups (NSGs) which add security feature to Azure’s Virtual Networking capability. Network Security Groups provides Access Control on Azure Virtual Network and the feature that is very compelling from security point of view. NSG is one of the feature Enterprise customers have been waiting for.
What are Network Security Groups and how to use them?
Network Security Groups allow us to control traffic (ingress and egress) on our Azure VNET using rules we define and provide segmentation within VNET by applying Network Security Groups to our subnet as well as Access Control to VMs.
What’s the difference between Network Security Groups and Azure endpoint-based ACLs? Azure endpoint-based ACLs work only on VM public port endpoint. NSGs are able to work on one or more VMs and controls all ingress and egress traffic on the VM. In addition NSG can be associated with a subnet and to all VMs in that subnet.
NSG Features and Constraints
NSG features and constraints are as follow:
100 NSGs per Azure subscription
One VM / Subnet can only be associated with One NSG
One NSG can contain up to 200 Rules
A Rule has characteristics as follow:
Priority: Integer between 100 and 4096
Source IP Address: CIDR of Source IP Range
Source Port Range: Range between 0 and 65000
Destination IP Range: CIDR of Destination IP Range
Destination Port Range: Integer or Range between 0 and 65000
Protocol: TCP, UDP or use * for Both
Rules processed in the order of priority. Rule with lower priority is processed before rules with higher priority numbers.
Security Zone Model
Designing isolated Security Zones within an Enterprise network is an effective strategy for reducing many types of risk, and this applies in Azure also. We need to work together with Microsoft as our Cloud Vendor to secure our Azure environment. Our On-Premises knowledge to create Security Zones model can be applied to our Azure environment.
As a demonstration I will pick the simplest Security Zone model which I will apply on my test Azure enviroment just to get some ideas how NSG will work. I will create 3 layers of Security Zone model for my test Azure environment. This simple security zone is only for the demo purpose and might not be suitable for your Enterprise environment.
Internet = Attack Vectors / Un-trusted
Front-End = DMZ
App / Mid-Tier = Trusted Zone
DB / Back-end = Restricted Zone
Based on Security Zone model above, I created my test Azure VNET :