Azure Network Watcher for Monitoring and Testing Network Security

Azure Monitor is designed to monitor Applications and Infrastructure. Today, we are going to focus on monitoring network security aspect of Azure VM connected to Private Virtual Network (vNET without public IP). You will get to learn how to configure Network Watcher and view logs at Traffic Analytics.

Microsoft is very good on documentation and you can find details at Microsoft site. Goal of this post is to walk you through minimum required configurations to turn on monitoring. Again, our focus is on network security of VM’s to allow traffic based on Network Security Group (NSG). RDP is allowed from vNET (vNET Gateway to be specific) to VM’s with network interface attached to Application Security Group (ASG). I am using PointToSite (w/address pool 172.27.1.0/24) VPN to connect to vNET Gateway. Anyone coming outside of vNET and vNET Gateway address pool would be denied RDP access. Attempt to RDP to VM from any other source would be denied and we will know about them at the Traffic Analytics!

Let’s look at the Effect Rules at the Security Group View and Network Topology of VM’s.

Figure: @Monitor>Network>Security group view

Figure: Topology of Virtual Network @ Virtual machines>VM>Networking>Topology.

Let’s navigate to Network Watcher (Monitor>Network) and Enable the Azure region(s) where your resources are provisioned. My resources are provisioned in South Central US and I enabled only this region. You can enable multiple regions by right clicking the context menu (…) next to the region.

Next, navigate to NSG Flow Logs under Network Watcher and configure Storage Account and Oms Workspace. Make sure your VM’s are running when you configure this step. I created a new Log Analytics workspace (laworkspace-aspnet4u) as opposed to using the default one but you can use any. It’s important that you configure the Log Analytics workspace to connect/enable data sources.

Navigate to Log Analytics workspace and configure workspace data sources. I have configured Virtual Machine, Azure Activity Log and few Azure Resources for the purpose of the demo. It takes few minutes before you starts to see the logs.

Let’s do some testing to see if our NSG rules are working as designed! Navigate to IP Flow Verify under Network Watcher (@Monitor>Network).

Test 1: Connect to vNET via VPN. RDP from internet (I am using IP of my internet provider, masked for privacy) to VM (appvm01). It should fail because NSG is configured to allow RDP from vNET only. IP Flow Verify shows the result along with the rule that allowed/denied the traffic.

Test 2: Connect to vNET via VPN. RDP from vNET Gateway(w/address pool 172.27.1.0/24) to VM (appvm01). It should succeed because NSG is configured to allow RDP from vNET only. IP Flow Verify shows the result along with the rule that allowed/denied the traffic.

Note that NSG sees the source IP of the vNET Gateway. In my case, it is 172.27.1.2 (assigned by Azure). This IP is part of vNET. I will do a netstat on my local machine to verify the DRP connection!

Test 3: Connect to vNET via VPN. RDP from an IP (outside of vNET ranges) to VM (appvm01). It should fail because NSG is configured to allow RDP from vNET only. IP Flow Verify shows the result along with the rule that allowed/denied the traffic.

Test 4: Connect to vNET via VPN. RDP from an IP (outside of vNET ranges and not in vNET Gateway) to VM (appvm01). It should fail because NSG is configured to allow RDP from vNET only. IP Flow Verify shows the result along with the rule that allowed/denied the traffic.

Okay, we are done with the testing and the exercise produced some logs. Now, it is time to see who are those bad actors attempted to RDP into our VM! Navigate to Traffic Analytics under Network Watcher and filter log analytic workspace and time interval. We can see there are some bad actors who are denied access to NSG!