This article is contributed. See the original author and article here.
Azure Firewall Premium is now in Public Preview and offers many new and powerful capabilities that can be used in your Windows Virtual Desktop environment. Several of these capabilities are Intrusion Detection and Prevention System (IDPS) and Web Categories. You can learn more about these capabilities and how they protect Windows Virtual Desktop environments plus some sample application and network rules and their anatomy in this post.
Assets created in this article can be found here:
If you would like to test along check out the instructions on how to deploy Azure Firewall premium. Be sure to take in consideration the WVD Virtual network and that there is dedicated subnet for Azure Firewall. The minimum IP address space in CIDR notation needed is /26 for the dedicated Azure Firewall subnet. The subnet must also be named AzureFirewallSubnet .Below is a sample template I use in pilots using a single Virtual Network with multiple subnets and segmentation for Windows Virtual Desktop.
After Azure Firewall Premium is deployed be sure to create a User Defined Route by creating a Route Table in Azure
Once created go to the route table and add a route.
When adding the route you can in testing add a quad zero route of 0.0.0.0/0 which will steer all public traffic public to a next hop address of the Azure Firewall Premium private IP address.
If you have additional VNETs or Subnets for testing, add more granular routes xx.xx.xx.xx/yy to each Azure private IP address space that needs to pass to the Azure Firewall, be sure to include next hop address of the Azure Firewall Premium private IP address.
Once added we can associate the route to the Windows Virtual Desktop subnet. Once associated the traffic will flow to Azure Firewall Premium as next hop.
Intrusion Detection and Prevention System (IDPS)
Azure Firewall Premium now brings Intrusion Detection and Prevention System (IDPS) to your virtual network and Windows Virtual Desktop Host Pool internet bound communications. Under the hood is an abstracted Suricata engine and the signatures fed by powerful third party watchlists. IDPS is a great feature to use as you may allow some openness to your Internet bound traffic within Windows Virtual Desktop. As employees surf the web or execute programs, IDPS can scan each network connection against its rules and then Audit or Audit and Deny traffic based on signature matches.
To turn on this feature with Azure Firewall policy applied to it, you will find a new blade for IDPS (preview). Please note this will only work for Azure Firewall premium. In addition, be sure to review configuring your Azure Firewall policies to use KeyVault and certificates to do TLS inspection, this will greatly enhance IDPS.
Once turned on you will want to send the Azure Firewall Diagnostic traffic to Log Analytics or your SIEM of choice. This is because it will help record the Signatures discovered that were audited or denied in IDPS so you can use Signature Rules.
You can set this up by going to the Azure Firewall resource and to the Diagnostic Settings blade and Add Diagnostic Settings.
Then define and send the logs to Log Analytics workspace
Within Log Analytics you can use the following Query to look at the traffic that was alerted or alerted and denied on with IDPS, including the signature in the event you need to tweak the Signature to allow or deny.
AzureDiagnostics
| where TimeGenerated >= ago(90d)
| where Category == "AzureFirewallNetworkRule"
| where OperationName == "AzureFirewallIDSLog"
| parse msg_s with * "TCP request from " Source " to " Destination ". Action: " ActionTaken ". Rule: " IDPSSig ". IDS: " IDSMessage ". Priority: " Priority ". Classification: " Classification
| project TimeGenerated, Source, Destination, ActionTaken, IDPSSig, IDSMessage, Priority, Classification
Once you have a signature, you can use this in Azure Firewall polies and IDPS (Preview) blade further to help with over riding the default mode you set IDPS on earlier via the signatures. This can help with false positives if Deny is default for IDPS mode or for adding to blocklists you generate in a permissive Alert Only IDPS mode
Finally if you need certain WVD Host Pool Members or other Components of the architecture to bypass IDPS all together you can set this within the Bypass list. You may have a WVD Host Pool that includes a legacy application that does not have methods of supporting certificates from the Azure Firewall. Most modern applications and web browsers support this but if you do encounter one you can use this bypass list. The Bypass list allows a 5 tuple network rule configuration. Once configured the servers originating traffic will no longer pass through IDPS.
Web Categories
Another approach is to use web categories to deny or allow traffic based on website characteristics like social media sites or gambling websites as an example. There are 64 web categories across differing classifications for selection. This is certainly appealing to block or allow web content to your employees utilizing their Windows 10 interface to the Internet through Windows Virtual Desktop. Below is an example of creating a rule collection and using web categories to deny traffic from Windows Virtual Desktop host pools. An even interesting feature is if you were to block News for instance under Azure Firewall premium a URL like www.google.com/news would be blocked under the web category so it extends beyond the FQDN and into the URL path.
{
"ruleType": "ApplicationRule",
"name": "AllowNews",
"protocols": [
{
"protocolType": "Https",
"port": 443
}
],
"webCategories": [
"business",
"webbasedemail"
],
"sourceAddresses": [
"*"
],
"terminateTLS": true
}
Anatomy of a Firewall Rule Collection
When using Azure Firewall to protect your Windows Virtual Desktop host pools, there are special rules that have to be implemented beyond the Windows Virtual Desktop tag to allow for the host pools to communicate properly with the Host Traffic. The needed WVD rules are outlined here but you can use the rules as an example to walkthrough the anatomy of Azure Firewall rule as code.
One of the capabilities of Azure Firewall is configuration as code, in particular ARM Template code in Declarative JSON. As an example you will walk through the firewall rule as code.
You will need a couple rule collections to allow traffic for the Windows Virtual Desktop host pools to communicate outbound to the management plane. A rule collection code is very simple, it allows you to define a collection of rules for the Azure Firewall, the priority they will take, the action of allowing or denying traffic in those rules and the rules themselves. An example below.
{
"name": "AllowAdditionalWVDApp",
"priority": 203,
"ruleCollectionType": "FirewallPolicyFilterRuleCollection",
"action": {
"type": "Allow"
},
"rules": []
}
In the next section you will want to define those rules that fit within the collection.
According to the Azure documentation you will use an Application rule and a FQDN tag. The following rule code fits into the rule collection code “rules”: […]
{
"ruleType": "ApplicationRule",
"name": "AllowWVDTag",
"protocols":[
{
"protocolType":"Https",
"port":443
},
],
"fqdnTags": [
"WindowsVirtualDesktop"
],
"targetFqdns": [],
"sourceAddresses":[
"XX.XX.XX.XX/YY"
],
"sourceIpGroups": [],
"terminateTLS":false
},
“sourceAddress”: [ xx.xx.xx.xx/yy ] is the Network CIDR range of the subnet where your Azure Virtual Desktop host pools are located in.
This rule will allow HTTPS traffic from the Windows Virtual Desktop host pool VMs to communicate with the management plane of WVD via the Tag.
You need to add some additional rules as well into the rule collection set, these allow the Windows Virtual Desktop host pool VMs to communicate with the data plane of WVD.
According to the documentation, the data plane of the WVD can be unique per instance. The first example may be a bit too wide open for your security posture and risk. In order to have more restrictive rules that are granular to only allow specific access to the data plane of WVD; the documentation provides you with a KQL query you can run against the Azure Firewall’s diagnostic logs.
AzureDiagnostics
| where Category == "AzureFirewallApplicationRule"
| search "Deny"
| search "gsm*eh.servicebus.windows.net" or "gsm*xt.blob.core.windows.net" or "gsm*xt.table.core.windows.net"
| parse msg_s with Protocol " request from " SourceIP ":" SourcePort:int " to " FQDN ":" *
| project TimeGenerated,Protocol,FQDN
Another method to find these specific FQDNs of the WVD data layer can also be found on the Host Pool VM themselves in the Event Viewer. Many thanks to Eric Moore who discovered this technique. This can be useful if you are putting in an Azure Firewall into an existing WVD host pool to prevent interruption.
On the WVD Host Pool VM Open Event Viewer, go to Windows Logs and Application
Filter on Source: WVD-Agent and Event ID: 3701
Scroll through the events until you come across one that exposes a larger list more then 4 FQDNs
Now that you have obtained the FQDNs unique to your WVD instances you can create additional Application Rules to allow the Windows Virtual Desktop host pools to communicate on the data access layer. The WVD Data access layer consists of unique Azure Service Bus, Storage Accounts blobs, tables, and queues.
{
"ruleType": "ApplicationRule",
"name": "AllowWVDServicebus",
"protocols":[
{
"protocolType":"Https",
"port":443
}
],
"targetUrls":[
"gsm1860291218eh.servicebus.windows.net/*",
"gsm1402610616eh.servicebus.windows.net/*",
"gsm2121010078eh.servicebus.windows.net/*",
"gsm2076831083eh.servicebus.windows.net/*"
],
"sourceAddresses":[
"XX.XX.XX.XX/YY"
],
"terminateTLS":true
},
{
"ruleType": "ApplicationRule",
"name": "AllowWVDBlob",
"protocols":[
{
"protocolType":"Https",
"port":443
}
],
"targetUrls":[
"gsm1860291218xt.blob.core.windows.net/*",
"gsm1402610616xt.blob.core.windows.net/*,",
"gsm2121010078xt.blob.core.windows.net/*",
"gsm2076831083xt.blob.core.windows.net/*"
],
"sourceAddresses":[
"XX.XX.XX.XX/YY"
],
"terminateTLS":true
},
{
"ruleType": "ApplicationRule",
"name": "AllowWVDTable",
"protocols":[
{
"protocolType":"Https",
"port":443
}
],
"targetUrls":[
"gsm1860291218xt.table.core.windows.net/*",
"gsm1402610616xt.table.core.windows.net/*",
"gsm2121010078xt.table.core.windows.net/*",
"gsm2076831083xt.table.core.windows.net/*"
],
"sourceAddresses":[
"XX.XX.XX.XX/YY"
],
"terminateTLS":true
},
{
"ruleType": "ApplicationRule",
"name": "AllowWVDQueue",
"protocols":[
{
"protocolType":"Https",
"port":443
}
],
"targetUrls":[
"gsm1860291218xt.queue.core.windows.net/*",
"gsm1402610616xt.queue.core.windows.net/*",
"gsm2121010078xt.queue.core.windows.net/*",
"gsm2076831083xt.queue.core.windows.net/*"
],
"sourceAddresses":[
"XX.XX.XX.XX/YY"
],
"terminateTLS":true
},
“sourceAddress”: [ xx.xx.xx.xx/yy ] is the Network CIDR rage of the subnet where your Azure Virtual Desktop host pools are located in.
This rule will allow HTTPS traffic from the Windows Virtual Desktop host pool VMs to communicate with the unique data plane of WVD.
Be sure to review configuring your Azure Firewall policies to use KeyVault and certificates to do TLS inspection, this will allow the use of the URL / within the application rules.
The rules above are reflected in the Azure Portal within the Firewall Policy under Application Rules
You will now create a new rule collection set for the Network based rules to allow certain traffic from the Windows Virtual Desktop host pools.
{
"name": "AllowAdditionalWVDNetwork",
"priority": 103,
"ruleCollectionType": "FirewallPolicyFilterRuleCollection",
"action": {
"type": "Allow"
},
"rules": [...]
}
Azure documentation states the following for Network based rules
Those rules will look like the following in code between the rule collection code “rules”: […]
{
"ruleType": "NetworkRule",
"name": "AllowADDNS",
"ipProtocols": [
"TCP",
"UDP"
],
"sourceAddresses": [
"XX.XX.XX.XX/YY"
],
"destinationAddresses": [
"ZZ.ZZ.ZZ.ZZ"
],
"sourceIpGroups": [],
"destinationIpGroups": [],
"destinationFqdns": [],
"destinationPorts": [
"53"
]
},
“sourceAddress”: [ xx.xx.xx.xx/yy ] is the Network CIDR range of the subnet where your Azure Virtual Desktop host pools are located in.
This first network rule in the ruleset Allows the WVD Host Pools to communicate TCP 53 with Local AD DNS servers. ZZ.ZZ.ZZ.ZZ is the AD DNS Server(s). Note if you are restrictive in the communication between Host Pool and Active Directory Domain Services subnet, you may want to also open additional ports outlined here for Active Directory.
An example of the next rule is below
{
"ruleType": "NetworkRule",
"name": "AllowAzureKMS",
"ipProtocols": [
"TCP"
],
"sourceAddresses": [
"XX.XX.XX.XX/YY"
],
"destinationAddresses": [],
"sourceIpGroups": [],
"destinationIpGroups": [],
"destinationFqdns": [
"kms.core.windows.net"
],
"destinationPorts": [
"1688"
]
},
The second network rule is allowing the WVD Host Pools to communicate with the Azure KMS service. What is interesting here is the use of a FQDN in a Network Rule rather than an IP address for destination. A couple months back Azure Firewall introduced this capability which allows the Azure Firewall to Leverage Azure DNS or a Custom DNS to lookup answers for the network rule. This can simplify a lot of rules now since many Azure services or Microsoft Services or 3rd party cloud services have a FQDN service that’s IP addresses can change from time to time.
If you are using a Network rule like this with FQDN, please take note you need to update the Azure Firewall to utilize FQDNs in network rules, the following article goes into more detail.
The ARM template and Infrastructure as code looks like this under the resource Microsoft.Network/firewallPolicies
"properties": {
"threatIntelMode": "Alert",
"dnsSettings": {
"servers": []
},
"transportSecurity": {
"certificateAuthority": {
"name": "cacert"
}
}
}
In the Azure portal if you go to the Azure Firewall policy and under Setting > DNS the equivalent configuration.
A final network rule will allow the WVD host pool communicate with NTP servers using the FQDN as a destination.
{
"ruleType": "NetworkRule",
"name": "AllowWindowsNTP",
"ipProtocols": [
"UDP"
],
"sourceAddresses": [
"*"
],
"destinationAddresses": [],
"sourceIpGroups": [],
"destinationIpGroups": [],
"destinationFqdns": [
"time.windows.com"
],
"destinationPorts": [
"123"
]
}
The rules above are reflected in the Azure Portal within the Firewall Policy under Network Rules
All of the rule collections and application and network rules discussed here can also be found on Azure Network Security GitHub repo as a deployable Azure Fw Policy. There will be continuing improvement on the WVD Azure Firewall Policy sample to include the Active Directory, Azure NetApp, and Office 365 Allow Rules. For now the deployable sample will include the items discussed in the Azure documentation.
In this post you learned how to use the new features of Azure Firewall premium with Windows Virtual Desktop. Features like IDPS and Web Categories which enhance your security posture for Windows Virtual Desktop. You also learned some examples of Application and Network rules for Windows Virtual Desktop.
Be sure to check out other examples at Azure Network Security GitHub and if interested please upload your Azure Firewall Sample patterns here as well via a pull request.
Special thanks to:
@Nyler Gaskins for GitHub assets and testing and reviewing this post
@Ashish Kapila for testing and reviewing the post
@Eric Moore for how to find the WVD data plane communication technique
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.
Recent Comments