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.

 

 

 

Azure VNET gateway: basic, standard and high performance

Originally posted @ Lucian.Blog. Follow Lucian on twitter @Lucianfrango.


I’ve been working a lot with Azure virtual network (VNET) virtual private network (VPN) gateways of late. The project I’m working on at the moment requires two sites to connect to a multi-site dynamic routing VPN gateway in Azure. This is for redundancy when connecting to the Azure cloud as there is a dedicated link between the two branch sites.

Setting up a multi-site VPN is a relatively streamlined process and Matt Davies has written a great article on how to run through that process via the Azure portal on the Kloud blog.

Read More

Connection Options When Building An Azure Hybrid Cloud Solution

If your business is migrating workloads to Azure the chances are at some point you will probably want to create a form of private interconnect with Azure. There is more than one way to achieve this, so in this post I’ll take a look at what options you have and the most appropriate scenarios for each.

We’ll work through the connection types from simplest (and quickest to provision) to more complex (where you’ll need IP networking expertise and hardware).

Hybrid Connection

This is your baseline interconnect option and is tied to the BizTalk Services offering within Azure. At time of writing the only Azure-based services that can leverage Hybrid Connections are Web Apps (formerly Websites) and Mobile Apps (formerly Mobile Services).

Hybrid Connections are a great way to quickly get access to on-premises resources without the complexity involved in firewall or VPN setups. If you look at the official documentation you’ll see there is no mention of firewall rules or VPN setup!

Your on-premises resources must be running on Server 2008 R2 or above in order to leverage this service offering which at its most restricted can work over standard HTTP(S) ports and nothing more.

  • Benefits:
    • Quick to setup (requires no changes on-prem)
    • Typically “just works” with most corporate network edge configurations
    • Doesn’t require a Virtual Network to be configured in Azure
    • Can be shared between multiple Web and Mobile Apps
    • Good for exposing single on-prem resources to consumers in Azure (i.e. DB on-prem / web in Azure).
  • Drawbacks:
    • Your security team may be unhappy with you 🙂
    • Performance may not meet your needs beyond simple use cases
    • TCP services requiring dynamic ports aren’t supported (think FTP)
    • Tied to BizTalk Services and utilises a range of other Azure services such as ACS and Azure SQL Database
    • In Preview (no SLA) and not available in all Azure Regions
    • Limited use cases in Azure (Web and Mobile Apps).

Point-to-Site VPN

The next step up from Hybrid Connections is Point-to-Site (P2S) VPN connections. These connections allow you to use a downloaded client to provide an SSTP VPN between a single on-premises (or Azure based) resource and a Virtual Network (VNet) in Azure.

This VPN setup is a good way to test out simple-to-medium complexity hybrid scenarios or proof-of-concepts without the need for dedicated VPN hardware in your corporate environment.

When setting up a P2S VPN you have a few items you need to succeed:

  • the IP address range that will be used for clients when they connect
  • a subnet defined on your VNet for the Azure Gateway that will host VPN connections
  • a running Gateway instance that will allow your VPN clients to connect
  • a valid x509 certificate that will be used by the VPN client.

As you can see, there are quite a few extra steps involved beyond the Hyrbid Connection! You can run up to 128 on-prem clients connected to an Azure VNet if needed.

  • Benefits:
    • Does not require dedicated on-premises networking hardware
    • SSTP can usually connect OK with most corporate network edge configurations
    • Can co-exist with Site-to-Site connections
    • Allows you expose services on a single on-prem resource to an entire Azure VNet.
  • Drawbacks:
    • You’ll need to understand IP networking to setup a VNet in Azure
    • Performance is still relatively limited due to the nature of SSTP
    • Isn’t an ‘always on’ proposition as requires an interactive user session on-prem to run the client
    • Only supports connection from a single on-prem resource running on Windows
    • You’ll need an x509 certificate for use with the VPN client.

Site-to-Site VPN

Now we start to get serious!

If you want to run a Site-to-Site (S2S) connection you will need to have dedicated VPN hardware or Windows Server 2012 (or above) running RRAS on-prem and some private IP address space for your Azure environment that doesn’t overlap with the on-premises network you’ll be connecting with.

This option is the first to really offer you a true hybrid environment where two networks can connect via the VPN. This is often the first step we see many enterprises take when adopting Azure as it is relatively quick to stand up and typically most customers have the necessary devices (or ones that meet Azure’s VPN requirements) available already.

When you setup your Gateway in Azure, the Azure platform will even handily provide you with a configuration script/template for whichever on-prem device you’ve selected.

  • Benefits:
    • Provides full network-to-network connectivity
    • Supports a growing number of standard VPN appliances
    • Foundation of support for multi-site connectivity
    • Can use Windows Server 2012 RRAS if you don’t have an appliance.
  • Drawbacks:
    • Maximum throughput of 100 Mbps
    • Doesn’t support redundant single site to single VNet connections.

Be aware: Forced Tunnelling

Before we move on to the next Azure connection type we do need to talk about Forced Tunelling. The current generation Azure VNet has a default route for all public Internet traffic which is out over Azure’s managed Internet infrastructure (it’s just there and you can’t manage it or turn it off). On some other public cloud platforms you can disable public internet traffic by not adding an Internet Gateway – on Azure that option isn’t currently available.

In order to mitigate some challenges around controlling the path public traffic takes from an Azure VNet, Microsoft introduced Forced Tunelling which can be used to force traffic bound for the Internet back over your VPN and into your on-prem environment.

You must plan your subnets appropriately and only apply Forced Tunelling to those where required. This is especially important if you will consume any of Azure’s PaaS offerings other than Web or Worker Roles which can be added to an Azure VNet.

Almost all of Azure’s PaaS services (even Blob Storage) are exposed as secured public Internet endpoints which means any call to these from a VNet configured for Forced Tunelling will result in that traffic heading back to your on-prem network and out your own Internet Gateway. Performance will take a hit and you will pay data egress charges on those calls as well as they will appear to originate from your on-prem Internet Gateway.

ExpressRoute

The grandpappy of all of them – and the one that requires the most planning and commitment. If you find yourself starting your hybrid journey here then either you have an existing investment in an MPLS WAN or you’re already co-located in an exchange that is providing ExpressRoute services.

The are two connection options for ExpressRoute:

  • Network Service Provider (NSP): utilises a new or existing MPLS WAN cross-connect into one or more Azure Region. Speeds 10 Mbps to 1 Gbps supported.
  • Exchange Provider (IXP): uses a new paired cross-connect in a data centre location when the IXP and Microsoft’s routers are co-located. Speeds 200 Mbps to 10 Gbps supported.

The officially support list of NSPs and IXPs is pretty small, but you can quite often work with your existing provider to get a connection into an IXP, or look to leverage offerings such as Equinix’s Cloud Exchange as a shortcut (for example, in Sydney 130+ network service providers provide services into Equinix).

Once you’re operating at this level you will definitely need the networking team in your organisation involved as you’ll be doing heavy lifting that requires solid knowledge of IP networking and specifically BGP.

  • Benefits:
    • A single ExpressRoute circuit can connect to multiple Azure VNets (up to 10) and across multiple Azure Subscriptions (also up to 10)
    • Redundant connection by default (a pair is provided when you connect)
    • Two peers provided: one for Azure public services and one for your private services. You can choose to not use either peer if you wish
    • Can support bursting to higher bandwidth levels (provider depending)
    • Offers an SLA for availability.
  • Drawbacks:
    • Requires that you have a relationship with an NSP or IXP in addition to Azure.
    • NSP bandwidth maximum is 1 Gbps
    • Maximum 4,000 route prefixes for BGP on all peers on a connection.

If you’re unsure how to get started here, but you have an existing WAN or co-location facility it may be worth talking to them about how to get a connection into Azure.

Be Aware: Default Routes and Public Peering

This topic falls under the same category as the earlier section on Forced Tunnelling for S2S VPNs.

When using ExpressRoute you can use BGP to advertise the default route for all your Azure VNets to be back over your ExpressRoute connection to your on-prem environment. Unlike the VPN connection scenario though, where all Azure PaaS services will route back over your on-prem Internet gateway, with ExpressRoute’s peering you can use the public peer as the shortcut back to Azure.

While this is a better option than you get with VPN it still means you are pushing Azure calls back to your ExpressRoute gateway so you will potentially see a performance hit and will see the data included if you are using an IXP connection.

Conclusion

So there we have it – a quick rundown of the techniques you have at your disposal when looking to create a private hybrid network environment that allows you to connect your existing locations with Azure.

HTH.

Highly Available SQL 2012 across Azure VNET (Part 1: VNET Peering)

Just over a year Microsoft announced the support of SQL Server AlwaysOn Availability Groups (AAG) on Microsoft Azure IaaS. Last month, Microsoft announced the support of SQL AAG between Azure Regions. This is a great news for great technology like SQL Server 2012 for highly available and disaster recovery scenario. SQL AAG released in SQL 2012 and enhanced in SQL 2014. AAG will detect anomaly which will impact SQL availability. When We will discuss how to do this in two blog posts:

  • Part1: Design SQL 2012 AAG across Azure VNET and How to create Microsoft Azure VNET to VNET peering
  • Part2: SQL, WSFC, Configure Quorum and Voting (SQL) and Configure AAG

Part1 SQL 2012 AAG across Azure VNET SQL 2012 AAG is designed to provide high availability for SQL database and Azure IaaS is great place where this technology can live. There are few benefits using Azure IaaS for this scenario:

  • Security features  from Azure as Cloud Provider. The security whitepaper can be found here
  • Azure VM Security Extensions which means we can rest assure when VM is deployed, it is protected from day 1. Details can be found here
  • Azure ILB to provide load balancing solution
  •  99.90% SLA for VNET connectivity (VPN). This feature is backed up by two “hidden” Azure VMs in active-passive configuration
  • Express Route (MPLS) for higher bandwidth requirement – we won’t discuss and use this feature in this blog posts

The architecture components for this scenario: 2 VNET on two different regions to avoid single point of region failure. We will call this VNET: SEVNET (Southeast Asia Region) and USVNET (US West Region). These VNETs will be peered. DC on each VNET to provide AD and DNS service. First DC on Southeast Asia region will be used as File Share Witness. 3 SQL Servers in AAG which 2 SQL will be at SEVNET on Azure Availability Set and 1 SQL will be at USVNET. The constraints for this scenario:

  • Cloud Service cannot span across Azure VNET. For this scenario two Cloud Service will be used for SQL VMs
  • Azure Availability Set (AS) cannot span across VNET and Cloud Service. Two SQL AS will be deployed
  • Azure ILB cannot span across VNET. Only Primary and Secondary SQL will be load balanced on SEVNET

Diagram below illustrates the architecture:

SQLAAGacrossVNET

Diagram above shows SQL AAG is configured across two Azure VNET. This configuration will give resiliency from full Azure region failure. AAG will be configured with 2 replicas (Primary at SEVNET, one replica at SEVNET for automatic failover and the other replica across region at USVNET configured for manual failover and disaster recovery in case of region failure at SEVNET). The listener will be configured o SEVNET which configured to route connections to primary replica. The scenario above also allows offloading read workloads from the Primary replica to readable secondary replicas in Azure region that are closer to the source of the read workloads (For example: reporting/ BI / backup purpose) Microsoft Azure VNET to VNET Peering Now let’s create 2 VNET on Southeast Asia region and US West region. Below is the configuration:

  • SEVNET | Southeast Asia Region | Storage: sevnetstor | Address Space: 10.0.0.0/20 | DNS:  10.0.0.4
  • USVNET | US West Region | Storage: usvnetstor | Address Space: 192.168.0.0/20 | DNS: 10.0.0.4

We will use Regional Virtual Network instead of using Affinity Group for this scenario which will enable us to use ILB for the future use. My colleague Scott Scovell wrote a blog about this a while ago. Create 2 Storage Accounts:

2 storage

Create DNS Server 10.0.0.4 – I registered with DC name AZSEDC001 Create VNET Peering We will use Azure GUI to create VNET-VNET peering Create first VNET at SE Asia Region: Go to NEW>Network Services>Virtual Network>Custom Create> Enter VNET name: SEVNET and select Region Southeast Asia > Next > select DNS Servers: AZSEDC001 > check Configure a site-to-site VPN > On Local Network choose Specify a new Local Network > Next

sevnet1

 

Enter the name of local network as USVNET and specify the address space. On VPN Device IP Address just use temporary one and we will replace that with the actual Public IP Address of the Gateway.

sevnet2

Next – we will configure the IP range of SEVNET . The important bit: Click on Add Gateway Subnet

sevnet3

Next We need to configure the USVNET with the same way. Configure site-to-site connectivity with the local as SEVNET using its address space. Both VNET will be like below:

vnet4

Next: We will need to create Dynamic Routing VPN Gateways for both VNET. Static Routing is not supported.

vnet5

Once completed, get the Gateway IP address for both VNET and replace the temporary VPN IP Address on Local Networks with the actual Gateway IP address we just obtained.

 

vnet6

The last step: Set the IPsec/IKE pre-shared keys for both VNET. We will use Azure PowerShell for this configuration. Firstly we will get the Pre-Shared keys to be used on our PowerShell script.

vnet7

Please ensure You are on the right subscription. Always good habit to use select-azuresubscription -default cmdlet before executing Azure PowerShell script.

vnet8

And That’s it! We should see the successful VNET to VNET Peering :

vnet9

Part 2 we will deep dive on how to configure the SQL AAG on across both VNET

Follow Us!

Kloud Solutions Blog - Follow Us!