Azure Networking – Identifying Flows Blocked By NSGs Using Traffic ...

When working on identifying flows that should be allowed by your Network Security Groups in Azure, a great tool you can leverage is Azure Traffic Analytics data stored in Log Analytics. In supported regions, you can send NSG flow logs into Azure Log Analytics where you can run queries to help you identify legitimate flows you might be blocking in your network.

Here are the high level steps to get this going in your environment:

1. Enable Network Watcher
2. Enable flow logging and Traffic Analytics for your Network Security Groups
   1. Store flow logs in a storage account AND Azure Log Analytics
3. Query Flow Logs in Azure Log Analytics (…and complement with flow logs stored in Azure blob storage)

Enable Network Watcher

I highly recommend you enable Network Watcher in each region. Like everything in Azure, there’s multiple ways of achieving this. You can do this via an Azure Resource Manager template, PowerShell, Azure Portal, etc. I personally do this in the the ARM template responsible for deploying core network resources (VNET, subnet NSGs), that way I’m making sure it’s there in every new region I’m setting up. Here’s what the ARM template piece to do this looks like:

{ "type": "Microsoft.Network/networkWatchers", "name": "[concat('net-watcher-',parameters('environmentCode'),'-',variables('regionFullCode'))]", "apiVersion": "2018-07-01", "location": "[parameters('vnetLocation')]", "tags": { "environmentCode": "[parameters('environmentCode')]", "serviceCode": "net", "deploymentARMTemplateVersion": "[parameters('deploymentARMTemplateVersion')]", "deploymentARMTemplateParameterFileVersion": "[parameters('deploymentARMTemplateParameterFileVersion')]", "deploymentDateTime": "[parameters('deploymentDateTime')]" }, "properties": {}, "dependsOn": [] }

If you remove the resource tags portion, you can see it’s pretty straightforward to enable Network Watcher!

Enable flow logging for your Network Security Groups

I’ve tried to enable Flow Logging and Traffic Analytics directly via Azure Resource Manager but initially but it didn’t work. I’ve engaged with the Azure Networking folks who kindly explained that enabling flow logging and traffic analytics is done post-process, something that’s not supported by ARM template as that would make the template not idempotent anymore.

For the time being, I’m using PowerShell to do this. Here’s what the code looks like to enable flow logging and Traffic Analytics on the NSGs in a specific region (Inspired by this post from Alexandre Verkinderen and adapted/enhanced for my environment):

Function Set-GEMAzureNSGFlowLogging([string]$companyCode="ge", [string]$businessUnitCode, [string]$tenantEnvironmentCode, [string]$countryCode, [string]$regionCode, [string]$regionId, [string]$environmentCode, [string] $logAnalyticsCountryCode, [string]$logAnalyticsRegionCode, [string]$logAnalyticsRegionId) { Import-Module AzureRM.Resources Import-Module -Force .\libAzureResourceManager.psm1 #Login the the proper subscription Set-GEMAzureRMLogin -companyCode $companyCode ` -businessUnitCode $businessUnitCode ` -tenantEnvironmentCode $tenantEnvironmentCode ` -environmentCode $environmentCode ` -countryCode $countryCode ` -regionCode $regionCode ` -regionId $regionId #Initialize variables for storage accounts and log analytics workspace name to use $storageAccountResourceGroup = "rg-$environmentCode`-mon-diag" $StorageAccountLogs = "$companyCode$businessUnitCode$tenantEnvironmentCode$environmentCode`mondiag$countryCode$regionCode$regionId" $retentionperiod = 7 $logAnalyticsWorkspaceName="$companyCode$businessUnitCode$tenantEnvironmentCode`-log-law-$environmentCode`-$logAnalyticsCountryCode`-$logAnalyticsRegionCode$logAnalyticsRegionId`-1" $logAnalyticsWorkspaceResourceGroup="rg-$environmentCode`-log-law" $logAnalyticsWorkspace = Get-AzureRmOperationalInsightsWorkspace -Name $logAnalyticsWorkspaceName -ResourceGroupName $logAnalyticsWorkspaceResourceGroup Register-AzureRmResourceProvider -ProviderNamespace Microsoft.Insights #Get proper storage account and Network Watcher references $storageAccount = Get-AzureRmStorageAccount -ResourceGroupName $storageAccountResourceGroup -Name $StorageAccountLogs $NWs = Get-AzurermNetworkWatcher -ResourceGroupName "rg-$environmentCode`-net-generic" -Name "net-watcher-$environmentCode`-$countryCode`-$regionCode$regionId" #endregion Foreach($NW in $NWs){ $NWlocation = $NW.location write-host "Looping trough $NWlocation" -ForegroundColor Yellow #region Enable NSG Flow Logs $nsgs = Get-AzureRmNetworkSecurityGroup | Where-Object {$_.Location -eq $NWlocation} Foreach($nsg in $nsgs) { #Get-AzureRmNetworkWatcherFlowLogStatus -NetworkWatcher $NW -TargetResourceId $nsg.Id #Flow analytics not supported in Canada East if($countryCode -eq "ca" -and $regionCode -eq "ea" -and $regionId -eq "1") { Write-Host "Enabling Flow Logging only for"$nsg.Name Set-AzureRmNetworkWatcherConfigFlowLog -NetworkWatcher $NW -TargetResourceId $nsg.Id -StorageAccountId $storageAccount.Id -EnableFlowLog $true -EnableRetention $true -RetentionInDays $retentionperiod } else { Write-Host "Enabling Flow Logging and Traffic analytics for"$nsg.Name Set-AzureRmNetworkWatcherConfigFlowLog -NetworkWatcher $NW -TargetResourceId $nsg.Id -StorageAccountId $storageAccount.Id -EnableFlowLog $true -EnableRetention $true -RetentionInDays $retentionperiod -EnableTrafficAnalytics -Workspace $logAnalyticsWorkspace } write-host "Diagnostics enabled for $nsg.Name " -BackgroundColor Green } #endregion } }

You can verify that flow logging and Traffic Analytics is correctly enabled in the Azure Portal by going to the Flow Logs section in Network Watcher.

Query Flow Logs in Azure Log Analytics

It may take a little while before the flow logs start showing up in the specified Azure Log Analytics workspace but once it’s there, you can can issue a query like to following to help you identify at a high level which flow are getting blocked.

AzureNetworkAnalytics_CL| extend NSGRuleAction=split(NSGRules_s,'|',3)[0]| extend NSGRuleName=tostring(split(NSGRules_s,'|',1)[0])| where NSGRuleAction == "D" and VMIP_s contains "192.168" | summarize count() by VM_s,VMIP_s,SrcIP_s,DestIP_s,DestPort_d,

In the screenshot above, a couple of computers required port 135 to communicate, which was blocked by a core/deny all NSG rule.

You may discover some chatty computers that shouldn’t be communicating with each other due to misconfiguration or actual legitimate flows that should not be blocked and are probably causing issues in your environment.

One thing that’s worth mentionning, I noticed in our environment that some of the flow records don’t always have the destination IP included (I’m talking with the Azure Networking folks about this as well). In that situation, I have to resort to look at the flow log files stored in Azure Storage to determine what’s actual the targeted IP being blocked. At the moment, I only noticed this for outbound flows. Source IPs of inbound flows seem to show up correctly.

Should you have any questions about the blog post, feel free to ask questions via the comments section.

Thanks for reading!

Share this:

• Facebook
• Twitter
• Reddit
• Email
• LinkedIn
• Tumblr
• Pocket
• Pinterest

Like Loading...

Related