-
-
-
Auto-create Default Outbound NSG for Servers in Azure
Overview
In Azure, Network Security Group (NSG) is a basic firewall containing a list of security rules.
NSG can be associated to subnets, individual NICs or both.
By default the outbound NSG for a subnet allows all outbound traffic, which is not secure for servers.
There are discussions [1] [2] on how to limit the outbound traffic while allowing traffic to Azure infrastructures required by different services like Windows updates.
I found that existing methods created hundreds of rules which are difficult to maintain. This post introduces a method to create a single rule the allows the outbound traffic to all Azure IP ranges.
Implementation
Code – new
The following script uses Azure Powershell az.
As it doesn’t support GUI yet so there are more parameters to set before running it.
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859# JZ 20190712# This script creates a rule to allow outbound traffic to all Azure IPs# Note: before running, delete the existing NSG rule named $nsgName at priority $priorityNumber# Parameters$subscriptionID = "00000000-aaaa-bbbb-cccc-0000000000"$selectedRegions = "australiaeast","australiasoutheast","australiac","australiac2"$rgName = "Resource-group-name"$nsgName = "network-security-group-name"$ruleName = "Allow_Outbound_to_Azure_IPs"$priorityNumber = 200# Sign-in with Azure account credentialsConnect-AzAccount# Select Azure SubscriptionSelect-AzSubscription -SubscriptionId $subscriptionID# Download current list of Azure Public IP ranges# See https://www.microsoft.com/en-in/download/confirmation.aspx?id=41653 for latest list$downloadUri = "https://www.microsoft.com/en-in/download/confirmation.aspx?id=41653"$downloadPage = Invoke-WebRequest -Uri $downloadUri$xmlFileUri = ($downloadPage.RawContent.Split('"') -like "https://*PublicIps*")[0]$response = Invoke-WebRequest -Uri $xmlFileUri# Get list of regions & public IP ranges[xml]$xmlResponse = [System.Text.Encoding]::UTF8.GetString($response.Content)$regions = $xmlResponse.AzurePublicIpAddresses.Region$ipRange = ( $regions | where-object Name -In $selectedRegions ).IpRange# combine all IPs# They need to be in an array format to use NSG augmented security rules$all_subnets=""ForEach ($subnet in $ipRange.Subnet) {$all_subnets+=$subnet$all_subnets+=","}$all_subnets=$all_subnets.trimend(",")$test=$all_subnets.split(",")# Add the NSG rules$nsg = Get-AzNetworkSecurityGroup -Name $nsgName -ResourceGroupName $rgNameAdd-AzNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg -Name $ruleName `-Access Allow -Protocol * -Direction Outbound -Priority $priorityNumber `-SourceAddressPrefix * -SourcePortRange * `-DestinationAddressPrefix $test -DestinationPortRange *Set-AzNetworkSecurityGroup -NetworkSecurityGroup $nsgCode – old
The following script uses Azure Powershell.
Adjust the 3 parameters before running it.
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778# JZ 20180810# This script creates a rule to allow outbound traffic to all Azure IPs# Note: before running, delete the existing NSG rule named $nsgName at priority $priorityNumber# Parameters$nsgName = "VLAN-webDMZ-Security-Group"$ruleName = "Allow_Outbound_to_Azure_IPs"$priorityNumber = 200# Sign-in with Azure account credentialsLogin-AzureRmAccount# Select Azure Subscription$subscriptionId =(Get-AzureRmSubscription |Out-GridView `-Title "Select an Azure Subscription ..." `-PassThru).SubscriptionIdSelect-AzureRmSubscription -SubscriptionId $subscriptionId# Select Azure Resource Group$rgName =(Get-AzureRmResourceGroup |Out-GridView `-Title "Select an Azure Resource Group ..." `-PassThru).ResourceGroupName# Download current list of Azure Public IP ranges# See https://www.microsoft.com/en-in/download/confirmation.aspx?id=41653 for latest list$downloadUri = "https://www.microsoft.com/en-in/download/confirmation.aspx?id=41653"$downloadPage = Invoke-WebRequest -Uri $downloadUri$xmlFileUri = ($downloadPage.RawContent.Split('"') -like "https://*PublicIps*")[0]$response = Invoke-WebRequest -Uri $xmlFileUri# Get list of regions & public IP ranges[xml]$xmlResponse = [System.Text.Encoding]::UTF8.GetString($response.Content)$regions = $xmlResponse.AzurePublicIpAddresses.Region# Select Azure regions for which to define NSG rules$selectedRegions =$regions.Name |Out-GridView `-Title "Select Azure Datacenter Regions ..." `-PassThru$ipRange = ( $regions | where-object Name -In $selectedRegions ).IpRange# combine all IPs# They need to be in an array format to use NSG augmented security rules$all_subnets=""ForEach ($subnet in $ipRange.Subnet) {$all_subnets+=$subnet$all_subnets+=","}$all_subnets=$all_subnets.trimend(",")$test=$all_subnets.split(",")# Add the NSG rules$nsg = Get-AzureRmNetworkSecurityGroup -Name $nsgName -ResourceGroupName $rgNameAdd-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg -Name $ruleName `-Access Allow -Protocol * -Direction Outbound -Priority $priorityNumber `-SourceAddressPrefix * -SourcePortRange * `-DestinationAddressPrefix $test -DestinationPortRange *Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $nsgAfter running the code
After defining these Azure-related outbound rules, you may need to add some additional rules to permit outbound access to other legitimate non-Azure services, such as
- public DNS servers
- email services
- kms.core.windows.net:1688
- APIs,
- etc, that your applications may also need to access
Then, you can create a rule at the end of the NSG to block all outbound traffic.
Reference
[1] https://blogs.technet.microsoft.com/keithmayer/2016/01/12/step-by-step-automate-building-outbound-network-security-groups-rules-via-azure-resource-manager-arm-and-powershell/
[2] https://serverfault.com/questions/888645/nsg-block-all-outbount-internet-traffic
-
AirPlay in Enterprise Networks
Apple TV and AirPlay become increasingly popular in enterprise and schools recently. However, it can be much more complicated to make AirPlay work smoothly in enterprise environment than a home network. This article discusses both two parts of AirPlay: Discovery and Streaming.
AirPlay Devices Discovery
Before iOS 7.1, AirPlay Devices rely on Bonjour (which uses mDNS and DNS Service Discovery) to discover AirPlay enabled devices. However, VLAN separation and broadcast/multicast filters, which are commonly used in enterprise networks, prevents AirPlay devices discovery.
Following is a packet capture of the AirPlay mDNS query and response. I allowed mDNS so AirPlay devices in the same VLAN can see each other.
Figure 1 Now, after iOS7.1, AirPlay devices can discovery each other using Bluetooth Low Energy (BTLE) [1]. This is a good for enterprise environment because we can block mDNS and allow Apple TVs to be discovered by Bluetooth, so that a user can only see nearby AirPlay devices.
AirPlay Streaming
Previously, AirPlay devices need to be in the same network stream contents.
Now, using peer-to-peer AirPlay, we can stream contents from an iOS device or Mac to Apple TV even if the devices are on different networks or there’s no network available.
To support peer-to-peer AirPlay, you need to meet the following requirements:
1. Client needs to be at least iOS8 and MacOS 10.10
2. Apple TV needs to be at least 2nd generation (model A1469 above) and tvOS 7.0I tried a 1st generation Apple TV with tvOS 8.4.2 but it still requires same VLAN for AirPlay streaming (though it can be discovered by Bluetooth).
According to Apple [1], peer-to-peer AirPlay causes the devices to visit Wi-Fi channel 149(80MHz) or 44 in the 5 GHz band and Wi-Fi channel 6 in the 2.4 GHz band, where the discovery process continues.
Once the user selects an Apple TV and AirPlay starts, the Wi-Fi radios timeshare between channel 149 and whichever infrastructure channel each device is currently using. If possible, the AirPlay sender roams to the same infrastructure channel the Apple TV is using. If neither device is currently using an infrastructure network, the devices will utilize Wi-Fi channel 149 only for AirPlay. Peer-to-peer mirroring adheres to 802.11 standards, sharing Wi-Fi bandwidth with other Wi-Fi devices. [1]
This is where it becomes interesting. In an enterprise environment using VLAN separation, peer-to-peer AirPlay allows client devices (maybe on staff or guest VLAN) stream to Apple TVs (maybe on AV VLAN or even no network). However, client device’s airtime is reduced because it needs to jump to channel 149 to send data to Apple TV. A bigger problem is interference with all nearby WiFi devices if your WiFi infrastructure uses DFS channels 149, 153, 157 or 161.
I am lucky to have several Apple TVs to perform some tests. My laptop is on a staff VLAN and all the Apple TVs are patched through Ethernet on a dedicated AV VLAN.
As can be seen in the following 3 figures, AirPlay uses a 80MHz channel spanning 149, 153, 157 and 161. In Figure 2, where my MacBook is using channel 153, AirPlay definitely causes co-channel interference.
More interestingly, I found in several cases, as shown in Figure 4, Apple TV uses an additional 80MHz channel spanning 36, 40, 44 and 48. As can be seen in the waterfall plot in Figure 4, I tried stop-start AirPlay several times to confirm it is indeed AirPlay using these channels. In addition, I also did a packet capture over the 80MHz channel spanning 36, 40, 44 and 48, showing data transmission from my MacBook to Apple TV, as shown in Figure 5.
Figure 2 
Figure 3 
Figure 4 
Figure 5 Conclusion
In an enterprise environment, we can keep using VLAN separation and mDNS filtering. Apple TVs can be discovered by Bluetooth and streamed using peer-to-peer AirPlay.
The advantages are obviously that we keep network securely segmented, allow users to see only nearby Apple TVs and allow AirPlay between devices on different VLANs.
The disadvantage is WiFi channel interference.
The suggestions for deploying Apple TVs on a large enterprise Wi-Fi network:
- Patch Apple TV in with ethernet cable, allow traffic between user vlans and Apple TV vlan, if you cannot do this, see following suggestions
- Don’t use WiFi channel 149, 153, 157 and 161 for your infrastructure network nearby Apple TVs (also avoid WiFi channels 36, 40, 44 and 48 if possible)
- Don’t place or mount the Apple TV behind objects that could disrupt the Bluetooth Low Energy and Wi-Fi signals
- Don’t use 2.4G channel 6 (actually don’t use 2.4G at all as there are many interference sources)
[1] iOS Deployment Reference
[2] Apple TV Peer-to-Peer using WiFi channels 6 and 149
[3] Enterprise Best Practices for iOS devices and Mac computers on Cisco Wireless LAN
[4] Apple TV and iOS Client instability issues
[5] Apple TV discovery over Bluetooth
[6] Apple AirPlay Capture
