This article is contributed. See the original author and article here.

Hi, all! Rod Trent here. I am a Cybersecurity CE/Consultant at Microsoft and work with Azure Sentinel literally every waking hour, so I see and hear a lot of unique and interesting things in relation to this fantastic product. I also blog for our Secure Infrastructure Blog and have quite a few Azure Sentinel articles posted there already.

 

Did you know that the Log Analytics agent requires an Internet connection no matter if it’s installed on an on-premises system or as an extension on a virtual machine stored in Azure? It may seem a bit quirky, but it’s true. Yes, even though an Azure VM has been spun up in the same cloud that the Log Analytics Workspace resides in, the agent still checks to see if there’s a valid Internet connection – well, actually it checks for a specific port (443) to be accessible, but the return error message is that an Internet connection is required.

 

As a security precaution, some customers spin up VMs in Azure and disable all outbound Internet access. This is done through an Outbound rule (VM => Networking => Outbound port rules => Deny Internet) similar to what is shown in the following image:

 

VM => Networking => Outbound port rules => Deny InternetVM => Networking => Outbound port rules => Deny Internet

 

However, the same customer may also want to monitor potential threats against these VMs using Azure Sentinel. Azure Sentinel, of course, requires a Log Analytics workspace which requires the Log Analytics agent extension to be installed which, yeah…you guessed it…requires the outbound Internet connection already discussed.

 

Even more interesting is that the Log Analytics agent extension will deploy perfectly. And, unless it’s monitored obsessively, all seems just fine. Well, that is, until it’s realized that the newly installed agent isn’t sending its data to Azure Sentinel’s Log Analytics Workspace.

 

Log Analytics Agent cannot connect due to a blocked portLog Analytics Agent cannot connect due to a blocked port

 

If it’s required that the Azure VM remains Internet disconnected, the solution is to create a new Outbound rule for the VM to provide the necessary port to trick the agent into thinking it has the required Internet connection. The new Outbound rule also needs to have a higher priority than the blocker, otherwise the port will never be exposed.

 

The new Outbound rule should look like the following:

 

Enable a new Outbound Rule specifically for AzureMonitorEnable a new Outbound Rule specifically for AzureMonitor

 

The details:

 

Create a new Outbound rule with a higher priority than the Deny Internet rule with the following information:

 

  • Source: VirtualNetwork
  • Secure port ranges: *
  • Destination: ServiceTag
  • Destination service tag: AzureMonitor
  • Destination port ranges: 443
  • Protocol: Any
  • Action: Allow
  • Priority: (set it higher than the Deny Internet rule)
  • Description: (I always recommend being very verbose when describing something you create – just in case you have a tendency to forget later on

 

 

Summary

This technique ensures that the Virtual Machine doesn’t have Internet access according to policy, and that security can still be managed and monitored through Azure Sentinel. Disabling full Internet access for each Virtual Machine may seem a rare occurrence, but as I noted in my opening statement, I regularly work with scenarios that are sometimes uncommon. And, if I see it once, it’s most likely going to happen again. Sharing makes us all smarter.

 

A use case example where this makes perfect sense is for Windows Virtual Desktops (WVD). Disabling the Internet completely for a compromised WVD, ensures that the device is effectively quarantined from the other VMs in the WVD pool while still maintaining the ability to kick-off a malware scan through an Azure Sentinel Playbook because the Azure Monitor port is still open.

 

NOTE: In the future, you can Use Azure Private Link to securely connect networks to Azure Monitor.

 

For additional knowledge in relation to Azure Sentinel-specific role access components, see the following:

 

Granting Access to Specific Azure Sentinel Playbooks for Specific Analysts: https://secureinfra.blog/2020/06/19/granting-access-to-specific-azure-sentinel-playbooks-for-specific-analysts/

 

Controlling access to Azure Sentinel Data: Resource RBAC:  https://techcommunity.microsoft.com/t5/azure-sentinel/controlling-access-to-azure-sentinel-data-resource-rbac/ba-p/1301463  

 

Table Level RBAC In Azure Sentinel: https://techcommunity.microsoft.com/t5/azure-sentinel/table-level-rbac-in-azure-sentinel/ba-p/965043 

 

Permissions in Azure Sentinel: https://docs.microsoft.com/en-us/azure/sentinel/roles

 

* Check out my other blog for more Azure Sentinel content: Rod Trent at the Secure Infrastructure Blog

 

* Follow me on Twitter: https://twitter.com/rodtrent

Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.