Azure Application Security Groups (ASG) are a new feature, currently in Preview, that allows for configuring network security using an application-centric approach within Network Security Groups (NSG). This approach allows for the grouping of Virtual Machines logicaly, irrespective of their IP address or subnet assignment within a VNet.
They work by assigning the network interfaces of virtual machines, as members of the ASG. ASGs are then used within NSGs as either a source or destination of a rule, and this provides additional options and flexibility for controlling network flows of resources within a subnet.
The following requirements apply to the creation and use of ASGs:
All network interfaces used in an ASG must be within the same VNet
If ASGs are used in the source and destination, they must be within the same VNet
The following scenario demonstrates a use case where ASGs may be useful. In the below diagram, there are 2 sets of VMs within a single subnet. The blue set of VMs require outbound connectivity on TCP port 443, while the green set of VMs require outbound connectivity on TCP port 1433.
As each VM is within the same subnet, to achieve this with traditional NSG rules would require that each IP address be added to a relevant rule that allows the required connectivity. For example:
As virtual machines are added, removed or updated the management overhead that is required to maintain the NSG may become quite considerable. This is where ASGs come in to play to simplify the NSG rule creation, and continued maintenance of the rule. Instead of defining IP prefixes, you create an ASG and use the it within the NSG rule. The Azure platform takes care of the rest by determining the IPs that are covered within the ASG.
As network interfaces of VMs are added to the ASG, the effective network security rules are applied without the need to update the NSG rule itself.
The following steps will demonstrate this process using 2 virtual machines.
Enable Preview Feature
ASGs are currently in preview and the feature must be enabled. At present these are only available within US West Central.
Check the status of the registration, and wait for the RegistrationState to change to Registered.
Create Application Security Groups
We will create 2 application security groups
Create security rules
In this example, we create rules that use the source as the application security group created in the previous step.
Create Network Security Group
Now that the ASGs are created and the relevant rules scoped to use the ASG as the source, we can create an NSG that uses these rules.
You can verify the rule from PowerShell, using Get-AzureRmNetworkSecurityGroup, and view the SecurityRules section. In there we can see that the reference to the ASG exists in SourceApplicationSecurityGroups:
Assign the NSG to a subnet:
Add network interfaces to ASG
The final step is to add the network interfaces of the VMs to the Application Security Group. The following example updates existing network interfaces to belong to the application security group. As network interfaces are added and removed the traffic flows will be controlled by the security rules applied to the NSG through the use of the ASGs, without further requirement to update the NSG.
You can verify this by viewing the network interface with Get-AzureRmNetworkInterface and checking the IpConfigurations properties. In there we can see the reference to the ASG memberships in ApplicationSecurityGroups.
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!
Microsoft Azure ExpressRoute provides dedicated, private circuits between your WAN or datacentre and private networks you build in the Microsoft Azure public cloud. There are two types of ExpressRoute connections – Network (NSP) based and Exchange (IXP) based with each allowing us to extend our infrastructure by providing connectivity that is:
Private: the circuit is isolated using industry-standard VLANs – the traffic never traverses the public Internet when connecting to Azure VNETs and, when using the public peer, even Azure services with public endpoints such as Storage and Azure SQL Database.
Reliable: Microsoft’s portion of ExpressRoute is covered by an SLA of 99.9%. Equinix Cloud Exchange (ECX) provides an SLA of 99.999% when redundancy is configured using an active – active router configuration.
High Speed speeds differ between NSP and IXP connections – but go from 10Mbps up to 10Gbps. ECX provides three choices of virtual circuit speeds in Australia: 200Mbps, 500Mbps and 1Gbps.
Microsoft provided a handy table comparison between all different types of Azure connectivity on this blog post.
ExpressRoute with Equinix Cloud Exchange
Equinix Cloud Exchange is a Layer 2 networking service providing connectivity to multiple Cloud Service Providers which includes Microsoft Azure. ECX’s main features are:
On Demand (once you’re signed up)
One physical port supports many Virtual Circuits (VCs)
Support 1Gbps and 10Gbps fibre-based Ethernet ports. Azure supports virtual circuits of 200Mbps, 500Mbps and 1Gbps
Orchestration using API for automation of provisioning which provides almost instant provisioning of a virtual circuit.
We can share an ECX physical port so that we can connect to both Azure ExpressRoute and AWS DirectConnect. This is supported as long as we use the same tagging mechanism based on either 802.1Q (Dot1Q) or 802.1ad (QinQ). Microsoft Azure uses 802.1ad on the Sell side (Z-side) to connect to ECX.
ECX pre-requisites for Azure ExpressRoute
The pre-requisites for connecting to Azure regardless the tagging mechanism are:
Two Physical ports on two separate ECX chassis for redundancy.
A primary and secondary virtual circuit per Azure peer (public or private).
Buy-side (A-side) Dot1Q and Azure ExpressRoute
The following diagram illustrates the network setup required for ExpressRoute using Dot1Q ports on ECX:
Tags on the Primary and Secondary virtual circuits are the same when the A-side is Dot1Q. When provisioning virtual circuits using Dot1Q on the A-Side use one VLAN tag per circuit request. This VLAN tag should be the same VLAN tag used when setting up the Private or Public BGP sessions on Azure using Azure PowerShell.
There are few things that need to be noted when using Dot1Q in this context:
The same Service Key can be used to order separate VCs for private or public peerings on ECX.
Get-AzureDedicatedCircuit returns the following output.
As we can see the status of ServiceProviderProvisioningState is NotProvisioned.
Note: ensure the physical ports have been provisioned at Equinix before we use this Cmdlet. Microsoft will start charging as soon as we create the ExpressRoute circuit even if we don’t connect it to the service provider.
Two physical ports need to be provisioned for redundancy on ECX – you will get the notification from Equinix NOC engineers once the physical ports have been provisioned.
Submit one virtual circuit request for each of the private and public peers on the ECX Portal. Each request needs a separate VLAN ID along with the Service Key. Go to the ECX Portal and submit one request for private peering (2 VCs – Primary and Secondary) and One Request for public peering (2VCs – Primary and Secondary).Once the ECX VCs have been provisioned check the Azure Circuit status which will now show Provisioned.
Next we need to configure BGP for exchanging routes between our on-premises network and Azure as a next step, but we will come back to this after we have a quick look at using QinQ with Azure ExpressRoute.
Buy-side (A-side) QinQ Azure ExpressRoute
The following diagram illustrates the network setup required for ExpressRoute using QinQ ports on ECX:
C-TAGs identify private or public peering traffic on Azure and the primary and secondary virtual circuits are setup across separate ECX chassis identified by unique S-TAGs. The A-Side buyer (us) can choose to either use the same or different VLAN IDs to identify the primary and secondary VCs. The same pair of primary and secondary VCs can be used for both private and public peering towards Azure. The inner tags identify if the session is Private or Public.
The process for provisioning a QinQ connection is the same as Dot1Q apart from the following change:
Submit only one request on the ECX Portal for both private and public peers. The same pair of primary and secondary virtual circuits can be used for both private and public peering in this setup.
ExpressRoute uses BGP for routing and you require four /30 subnets for both the primary and secondary routes for both private and public peering. The IP prefixes for BGP cannot overlap with IP prefixes in either your on-prem or cloud environments. Example Routing subnets and VLAN IDs:
Primary Private: 192.168.1.0/30 (VLAN 100)
Secondary Private: 192.168.2.0/30 (VLAN 100)
Primary Public: 192.168.1.4/30 (VLAN 101)
Secondary Public: 192.168.2.4/30 (VLAN 101)
The first available IP address of each subnet will be assigned to the local router and the second will be automatically assigned to the router on the Azure side.
To configure BGP sessions for both private and public peering on Azure use the Azure PowerShell Cmdlets as shown below.
Once we have configured the above we will need to configure the BGP sessions on our on-premises routers and ensure any firewall rules are modified so that traffic can be routed correctly.
I hope you’ve found this post useful – please leave any comments or questions below!