Hello, dear readers! My name is Hélder Pinto and I am sharing here some tips about how to leverage NSG Flow Logs and Traffic Analytics to improve your Azure network security hygiene and, at the end, simplify your NSG rules and, more importantly, uncover security vulnerabilities.
Traffic Analytics is an Azure-native service that allows you to get insights about the Azure Virtual Network flows originated by or targeted to your applications. For example, identifying network activity hot spots, security threats or network usage patterns is made very easy by navigating over the several ready-made Traffic Analytics dashboards. This service depends on the Flow Logs generated by the network activity evaluated by Network Security Group (NSG) rules. Whenever a network flow tries to go from A to B in your network, it generates a log for the NSG rule that allows/denies the flow. Traffic Analytics is not enabled by default and you must turn it on for each NSG. You can read more details about Traffic Analytics here.
Traffic Analytics dashboards are built on top of the logs that are collected at least every hour into a Log Analytics workspace. If you drill down some of its charts, you’ll notice that everything depends on the AzureNetworkAnalytics_CL custom log table. Of course, these flow logs can be used for other purposes besides feeding Traffic Analytics dashboards. In this article, I’ll demonstrate how to leverage Traffic Analytics logs to improve your Azure network security hygiene and, at the end, simplify your NSG rules and, more importantly, uncover security vulnerabilities.
When managing NSGs, inbound/outbound rules are added/updated as new services are onboarded into the Virtual Network. Sometimes, rules are changed temporarily to debug a failing flow. Meanwhile, services and network interfaces are decommissioned, temporary rules are not needed anymore, but too frequently NSG rules are not updated after those changes. As time goes by, it is not uncommon to find NSG rules for which we don’t know the justification at all or, in many cases, containing IP address-based sources/destinations that are not easy to identify. As a result, motivated by the fear of breaking something, we let those rules hanging around.
This negligence in network security hygiene sometimes originates vulnerabilities that have a dire impact in your Azure assets. Some examples:
An outbound allow rule for Azure SQL that is not needed anymore and that can be exploited for data exfiltration.
A deny rule that is never hit because someone inserted a permissive allow rule with higher priority.
An RDP allow rule for a specific source/destination that is never hit because, again, someone added a higher priority rule that suppresses its effect.
Even if some unneeded NSG rule is innoxious, it is a general best practice to keep your Azure resources as optimized and clean as possible – the cleaner your environment, the more manageable it is.
NSG Optimization Workbook
Based on Azure Resource Graph and on the AzureNetworkAnalytics_CL Log Analytics table generated by Traffic Analytics, I built an Azure Monitor workbook that helps you spot NSG rules that haven’t been used for a given period, i.e., good candidates for cleanup or maybe a symptom that something is wrong with your NSG setup.
The workbook starts by showing you:
which NSGs do not have Traffic Analytics enabled – this means no visibility over their flows.
which NSGs have been inactive, i.e., not generating any flow logs – maybe these NSGs were associated to subnets or network interfaces that were decommissioned.
Workbook tiles with a summary of Traffic Analytics state in all NSGs
Workbook tile listing NSGs that have not been generating flow logs (inactive)
If you scroll down a bit more, you’ll also get details about NSG rules that have been inactive for the period specified as parameter. These rules are not generating NSG Flow Logs and this may be a symptom of some misconfiguration or, at least, of some lack of security hygiene.
Workbook tile with a list of NSG rules that have not been used by network traffic
If you select a rule from the list, you get statistics about other rules in the same NSG that are generating flows, which may give you a hint for the reason why that rule has not generated any log lately.
Workbook tile with the statistics for all the NSG rules that have generating traffic for the NSG where the inactive rule sits in
Deploying the Workbook
The NSG Optimization workbook can be found at the address below:
For instructions on how to setup a workbook, check the Azure Monitor documentation. Once in Azure Monitor Workbooks, you must create a new Workbook and, in edit mode, click on the Advanced Editor button (see picture below) and replace the gallery template code by the one you find in the GitHub URL above. After applying the workbook code, you should see the dashboard described in this article. The workbook looks quite simple but the logic behind is somewhat complex and, depending on the volume of your NSG Flow Logs and on the NSG activity time range you chose, it may take a while to fully load each table. Don’t forget to save your workbook!
Screenshot of the Workbooks user interface for creating a new workbook from existing code
Screenshot of the Workbooks user interface for applying and saving a new workbook from existing code
As we saw in this article, keeping a good network security hygiene may save you from troubles. Some of these potential issues come out of unneeded or obsolete network security rules defined in your NSGs. The NSG Optimization Workbook here described will help you uncover NSGs or NSG rules that have not been used over a specific time range, based on Traffic Analytics logs. An NSG rule that has not generated flow logs is probably a symptom of some misconfiguration. So, go turn on Traffic Analytics, deploy the NSG Optimization Workbook and give a start to your NSG spring cleanup! :smiling_face_with_smiling_eyes: