Secure Azure Virtual Network Defense In Depth using Network Security Groups, User Defined Routes and Barracuda NG Firewall

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:

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:

Barracuda01

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
  • VPN
  • Application Control
  • IDS – IPS
  • Anti-Malware
  • 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:

barra01

 

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

barra02

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:

barra03

Let’s have a quick look at Barracuda NG Admin Logs 🙂

barra04

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!

Read more from me on the Kloud Blog or on my own blog at www.wasita.net.

 

 

 

Secure Azure Virtual Network and create DMZ on Azure VNET using Network Security Groups (NSG)

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:
    • Name
    • Type: Inbound/Outbound
    • 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
    • Access: Allow/Deny
    • 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 :

Azure VNET: SEVNET
Address Space: 10.0.0.0/20
Subnets:
Azure-DMZ – 10.0.2.0/25
Azure-App – 10.0.0.0/25
Azure-DB – 10.0.1.0/25

Multi Site Connectivity to: EUVNET (172.16.0.0/16) and USVNET (192.168.0.0/20).

The diagram below illustrates above scenario:

Security Zone 1

Lock ‘Em Down

After we decided our simple Security Zone model it’s time to lock them down and secure the zones.

The diagram below illustrates how the traffic flow will be configured:

Security Zone 2

In High Level the Traffic flow as follow:

  • Allow Internet ingress and egress on DMZ
  • Allow DMZ – App ingress and egress
  • Allow App – DB ingress and egress
  • Deny DMZ-DB ingress and egress
  • Deny App-Internet ingress and egress
  • Deny DB-Internet ingress and egress
  • Deny EUVNET-DB on SEVNET ingress and egress
  • Deny USVNET-DB on SEVNET ingress and egress

Section below will show the examples of Azure NSG rules table will look like.

NSG Rules Table

Azure DMZ NSG Rules Table

NameSource IPSource PortDestination IPDestination PortPortTypeActionPriority
RDPInternet-DMZ*6338910.0.2.0/2563389TCPInboundAllow347
Internet-DMZSSL*44310.0.2.0/25443TCPInboundAllow348
Internet-DMZDRS*4944310.0.2.0/2549443TCPInboundAllow349
USVNET-DMZ192.168.0.0/20*10.0.2.0/25**InboundAllow400
EUVNET-DMZ172.16.0.0/16*10.0.2.0/25**InboundAllow401
DMZ-App10.0.2.0/25*10.0.0.0/25**OutboundAllow500
DMZ-DB10.0.2.0/25*10.0.1.0/25**OutboundDeny600
Allow VNET InboundVirtual_Network*Virtual_Network**InboundAllow65000
Allow Azure Internal Load Balancer InboundAzure_LoadBalancer****InboundAllow65001
Deny All Inbound*****InboundDeny65500
Allow VNET OutboundVirtual_Network*Virtual_Network**OutboundAllow65000
Allow Internet Outbound**INTERNET**OutboundAllow65001
Deny All Outbound*****OutboundDeny65500

Azure App NSG Rules Table

NameSource IPSource PortDestination IPDestination PortProtTypeActionPriority
DMZ-App10.0.2.0/25*10.0.0.0/25**InboundAllow348
USVNET-App192.168.0.0/20*10.0.0.0/25**InboundAllow400
EUVNET-App172.16.0.0/16*10.0.0.0/25**InboundAllow401
App-DMZ10.0.0.0/25*10.0.2.0/25**OutboundAllow500
App-DB10.0.0.0/25*10.0.1.0/25**OutboundAllow600
App-Internet10.0.0.0/25*INTERNET**OutboundDeny601
Allow VNET InboundVirtual_Network*Virtual_Network**InboundAllow65000
Allow Azure Internal Load Balancer InboundAzure_LoadBalancer****InboundAllow65001
Deny All Inbound*****InboundDeny65500
Allow VNET OutboundVirtual_Network*Virtual_Network**OutboundAllow65000
Allow Internet Outbound**INTERNET**OutboundAllow65001
Deny All Outbound*****OutboundDeny65500

Azure DB NSG Rules Table

NameSource IPSource PortDestination IPDestination PortProtTypeActionPriority
App-DB10.0.0.0/25*10.0.1.0/25**InboundAllow348
USVNET-App192.168.0.0/20*10.0.1.0/25**InboundDeny400
EUVNET-App172.16.0.0/16*10.0.1.0/25**InboundDeny401
DB-DMZ10.0.1.0/25*10.0.2.0/25**OutboundDeny500
DB-App10.0.1.0/25*10.0.0.0/25**OutboundAllow600
DB-Internet10.0.0.0/25*INTERNET**OutboundDeny601
Allow VNET InboundVirtual_Network*Virtual_Network**InboundAllow65000
Allow Azure Internal Load Balancer InboundAzure_LoadBalancer****InboundAllow65001
Deny All Inbound*****InboundDeny65500
Allow VNET OutboundVirtual_Network*Virtual_Network**OutboundAllow65000
Allow Internet Outbound**INTERNET**OutboundAllow65001
Deny All Outbound*****OutboundDeny65500

Tables above will give us some ideas how to plan our Azure NSGs in order to establish our Security Zones.

Get Started using NSGs!

At the time this post was written, NSG is exposed only through PowerShell and REST API. To use PowerShell, we need version 0.8.10 of the Azure PowerShell module.

The commands are as follow:

  • Get-AzureNetworkSecurityGroup
  • Get-AzureNetworkSecurityGroupConfig
  • Get-AzureNetworkSecurityGroupForSubnet
  • New-AzureNetworkSecurityGroup
  • Remove-AzureNetworkSecurityGroup
  • Remove-AzureNetworkSecurityGroupConfig
  • Remove-AzureNetworkSecurityGroupFromSubnet
  • Remove-AzureNetworkSecurityRule
  • Set-AzureNetworkSecurityGroupConfig
  • Set-AzureNetworkSecurityGroupToSubnet
  • Set-AzureNetworkSecurityRule

Here are some examples:

Personally I will be recommending Azure NSG for every Azure Production deployment I perform in future!

Leave a comment below or contact us if you have any questions regarding Azure especially in more complex Enterprise scenarios.

www.wasita.net

Follow Us!

Kloud Solutions Blog - Follow Us!