alexfray Azure

Azure Firewall

Microsoft’s Firewall as a Service offering, Azure Firewall, was released in 2018. A bit late in the day in my opinion as early adopters of Azure would have already procured Network Virtual Appliances such as Checkpoint or Palo Alto but if you haven’t adopted Azure yet or are re-evaluating your perimeter security then Azure Firewall might be the solution for you.

Azure Firewall is a Firewall as a Service which means you get built-in high availability, scalability and no requirement to maintain or upgrade appliances which is a real business benefit. What does it give you over a Network Security Group (NSG)? Well quite a lot, you get a dedicated public IP address so you appear as a consistent address on the Internet, you can also create inbound rules if you desire. The key benefits though are automation, FQDN based rules and Azure tags, which provides simplified management and scalability over an NSG’s 5 tuple approach.

Microsoft have baked in a raft of Azure tags so you don’t need to define rules/FQDNs for Azure AD, Azure Backup, Windows Updates, Azure Key Vault and other Azure services which makes deploying and securing Internet connectivity for Windows VMs very quick and easy. This also makes management overhead of your rulebase very low, even when compared to a Network Virtual Appliance (NVA).

If you haven’t already invested in an NVA or are re-evaluating your Azure perimeter security then Azure Firewall is a viable option,  however there are some drawbacks.

  • There is no SSL inspection which means the rules are based on the FQDN for HTTP sites or the Certificate CN for SSL based sites. This can make creating rules for SSL sites a bit tricky if SAN or wildcard certificates are used so be prepared to use Wireshark.
  • Logging. You will need to use a Log Analytics workspace to view logs which is ok and the workspace stats are quite snazzy for reporting. Bear in mind unless you use a free workspace which has limitations this will incur additional costs either per host or per GB. For live troubleshooting using log analytics just isn’t an NVA log viewer like Checkpoint Smart tracker or similar. This blog written by Thuan Soldier has some good info and log query samples https://thuansoldier.net/7805/
  • NGFW Capabilities. Limited layer 7 protection features commonly referred to as Next Generation Firewall protection such as IPS, Application Awareness, Anti-Virus etc. Currently the only NGFW feature is threat intelligence which dynamically blocks known malicious IPs/Domains (in preview). This means limited visibility of your traffic, considering 70% of websites are now SSL you want to ensure your environment is protected from advanced threats or malware where possible.
  • Cost. Its not cheap, over a year, an Azure Firewall will cost over £7k. which is equal to or more than most NVA’s (depending on your discount). So you are paying a lot for the ‘as a Service’ benefits (HA, scalability and minimal management overhead). Coming soon you will be able to de-allocate/allocate the Azure Firewall to pause the cost so for dev/test environments you could automate this to lower the cost for environments which are not 24/7.

We have deployed Azure Firewall for clients and it is very easy to deploy. The only prerequisites are that you need a dedicated subnet to deploy the Azure Firewall called AzureFirewallSubnet; and the subnet must have a /26 mask. Its also easy to script to repeat the process for multiple release process environments.

From a network design perspective, deploy the Azure Firewall in your hub or transit VNET so you can leverage it for all your VNETs. You can deploy the Azure Firewall without impact existing traffic flows as you need to create User Defined Routes to force traffic through the Azure Firewall so it is easy to integrate into an existing environment subnet-by-subnet to limit the impact and also provide rollback if your rules aren’t quite right.

No doubt Microsoft will continue to develop Azure Firewall and introduce more NGFW features so I am sure some of the technical limitations above will be addressed. Azure Firewall is a solid alternative to secure your Azure environment, especially if you have a small IT support team, but consider your current and future requirements as an NVA may be a better fit. One cloud benefit is that you don’t have to sweat assets, as there is no hardware or capital purchase involved, so you could always migrate to an NVA if your requirements change, environment scales or requires Next Generation Firewall capabilities.

Microsoft’s documentation is excellent for Azure components, for documentation on Azure Firewall see here.

Alex

alexfray Azure

Azure VPN Gateway

More and more we are asked by clients to configure site-to-site VPN tunnels from on-premise VPN gateways such as Checkpoint and Cisco to Azure using the native Microsoft Azure VPN Gateway.

The Azure VPN Gateway is a very compelling alternative to procuring a dedicate Network Virtual Appliance (NVA) in Azure, High Availability is built in, it scales, you don’t have to upgrade or maintain the appliance so for most clients it will do the job. However, a few things to consider:

  • Authentication, you can only use pre-shared keys (PSK), this may not be an issue but if you are required to use certificate-based authentication then you will need an NVA.
  • Troubleshooting, this is not particularly easy with the Azure VPN Gateway in comparison to an NVA which provides all information regarding tunnel negotiation. In my experience you are in the hands of the person or 3rd party configuring the on-premise end of the VPN to get it correct and troubleshoot. Now if that person is yourself or a competent engineer then this may not be an issue, however I have spent many an hour troubleshooting with inexperienced engineers configure VPNs.
  • No ACLs, you cannot apply rules to VPN tunnels or the Gateway subnet to limit what traffic or protocols can access services in your VNET/subnet(s). You can do this further up the stack on your destination servers or subnets but ideally you want to do this as close to the source as possible (best practice).

I think the Azure VPN Gateway is a decent offering but does lack the granularity of a Network Virtual Appliance. The choice will depend on your requirements, in-house network skills and budget.

Below is the powershell commands to create an object representing the on-premise VPN gateway and how to create and modify the VPN tunnel parameters. A prerequisite to this is downloading the Azure Powershell Module (i’m using AZ which replaced AzureRM)

logon to your Azure subscription (handy if you have multiple subscriptions)

#login to azure account
Login-AzAccount

#lists all the subscriptions in a form to choose from
$subscriptionId = 
(Get-AzSubscription |
Out-GridView `
-Title "Select an Azure Subscription …" `
-PassThru).SubscriptionId

Select-AzSubscription -SubscriptionId $subscriptionId 

# if error occurs opening subscriptions try
Set-ExecutionPolicy Unrestricted

Create the on-premise VPN gateway, referred to as a local gateway

#VPN variables
$RG1 = "existing-rg"
$Location1 = "uksouth"
$GWName1 = "Azure-VPN-GW"
$LNGName6 = "Onpremise-GW1"
$LNGIP1 = "1.1.1.1"
$LNGprefix1 = "192.168.1.0/24"
$connection16 = "3rd-Party-VPN"

#Create remote VPN Gateway object
New-AzLocalNetworkGateway -Name $LNGName6 -ResourceGroupName $RG1 `
-Location $Location1 -GatewayIpAddress $LNGIP1 -AddressPrefix $LNGprefix1

Create a VPN policy with your desired encryption, hashing algorithms and SA timeouts. Note the Phase 1 SA timeout cannot be changed from 28800 seconds.

#vpn parameters. Note phase 1 SA timeout cant be changed from 28800 seconds
$VPNPolicy-3rdParty = New-AZIpsecPolicy -IkeEncryption AES256 -IkeIntegrity SHA256 -DhGroup DHGroup14 -IpsecEncryption AES256 -IpsecIntegrity SHA256 -PfsGroup None -SALifeTimeSeconds 14400

Create the VPN Tunnel and bind to your gateways

#create vpn connection
$vnet1gw = Get-AZVirtualNetworkGateway -Name $GWName1 -ResourceGroupName $RG1
$lng6 = Get-AZlocalnetworkgateway -Name $LNGName6 -ResourceGroupName $RG1
New-AZVirtualNetworkGatewayConnection -Name $connection16 -ResourceGroupName $RG1 -VirtualNetworkGateway1 $vnet1gw -LocalNetworkGateway2 $lng6 -location $Location1 -ConnectionType IPsec -IpsecPolicies $VPNPolicy-3rdParty -SharedKey 'thisisyourpresharedkey'

Show your VPN policy settings

#show ipsec parameters for a policy
$connection6 = get-AZvirtualnetworkgatewayconnection -name $connection16 -ResourceGroupName $RG1 
$connection6.ipsecpolicies

Show your local and Azure VPN Gateway settings

#show vpn gateway local gateways defined
Get-AZvirtualnetworkgateway -resourcegroupname existing-rg
Get-AZlocalnetworkgateway -resourcegroupname existing-rg

When you create a VPN tunnel with a remote encryption domain, for example 192.168.1.0/24, this is automatically added to your system routing table so you don’t need to create User Defined Routes which is pretty neat.

Alex

 

alexfray ADFS, Authentication, AzureAD, Zscaler

Zscaler – Authentication Choices

Zscaler is the market leading cloud proxy service. I have implemented Zscaler for a number of customers in the Transport and Government sector over the last 3 years and its adoption is rapidly increasing as customers look to migrate services to the cloud, increased workforce mobility, a move to OPEX based services and away from traditional on-premise CAPEX heavy forward proxy solutions like Bluecoat. Note. Bluecoat do offer a cloud service but it is doesn’t have the maturity and cloud scale that Zscaler has built up as a pure cloud player over the last 10 years.

There are many ways to authenticate users of the Zscaler service, locally defined database, LDAP and SAML to name the main ones. However the problem comes in populating the user database. If you had a small organisation (sub 50 users) then a locally defined user database might work for you, however most organisation are way above this figure and want to leverage their existing Identity management system such as Active Directory or Azure AD. Now this is fine as we can integrate Zscaler into both of these IDPs using SAML. However populating the user database depends on your requirements. We can auto-populate (preferred) the Zscaler user database using the data from the SAML tokens, which is great as each time the user authenticates to Zscaler their information is updated! This works great when using Active Directory (ADFS) or Azure AD (see my other articles on how to integrate these). However when using AzureAD the user’s group membership cannot be added to the SAML token. You could define local groups in Zscaler if that meets your requirements however if like most organisations you are migrating from an on-premise forward proxy solution to Zscaler then chances are you will want to ease the pain by using the existing AD groups which are used to define your proxy policy. With ADFS we can insert the AD Groups that the user belongs to in the SAML token, it just puts a dependency on having an ADFS infrastructure in place or building one.

The other options are LDAP or Zscaler Authentication Bridge (ZAB). Where you could still carry out user authentication via SAML but populate the Zscaler user database using LDAP or the ZAB. I don’t like either of these solutions. Exposing your domain controllers to the Internet, albeit source IP restricted doesn’t feel right to me, it also puts a dependency on LDAPS being in place which a lot of organisations still don’t use. I guess you could use LDAP but i’m not even going to suggest exposing your IDP data unencrypted over the Internet. and the ZAB, what’s the point of a pure cloud proxy solution if you have to put a VM in your on-premise data centre to sync your user data. (Also Bluecoat’s and Cisco Umbrella’s solution) Also the ZAB is currently only supported on VMware so you couldn’t even host this is Azure or AWS!

I like the elegant solution of authentication and auto-populating the user database using SAML. I’ve spoken to Microsoft about being able to include Groups in the SAML token when using Azure AD as the IDP and it doesn’t seem to be supported for Zscaler. Note. You can modify app manifest files to populate User Groups in the SAML token for other apps so you maybe able to do this for Zscaler. Off topic, I don’t understand why Azure has App registrations and Enterprise Apps, this should be merged! Zscaler is deployed as an Enterprise App as such there is no Manifest file to modify, So you would have to manually register the app if this is even possible. I would hope, as this is not the only use case, that Groups will be possible using Azure AD at some point, Microsoft have got pretty good at listening to the community now that they have other options.

Links

https://support.zscaler.com/hc/en-us/articles/204455339-Choosing-Provisioning-and-Authentication-Methods