This article is contributed. See the original author and article here.
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.
Introduction
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.
The problem
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.
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.
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.
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!
Conclusion
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:
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.
Recent Comments