Tag Archives: Azure Security

VM extensions installed in Azure VMs | Where do they all come from?

I have noticed that no matter what deployment method I use (Portal or ARM template) to deploy an Azure VM in my Azure subscription, I always get two additional VM installed by default. I have no intention of using OMS or Security Center for certain workloads I run on Azure but having these two extensions hanging in a VM looked weird to me. The reason is I never installed them in the first place.

As you can see in the below image MicrosoftMonitoringAgent & Monitoring VM extensions are installed after a VM has been provisioned.

Security Center Data Collection from Azure VMs

When you enable the Azure Security Center for your sbscriptions in Azure, by default data collection is turned on. This setting provisions the Microsoft Monitoring Agent (which explains the auto installed extension) on all Azure VMs in the subscription/s and any new VMs that you create.  The Microsoft Monitoring agent scans for security related configurations and posts them into Event Tracing for Windows (ETW) traces.  Also any event logs raised by the guest OS will be read by the the Microsoft Monitoring Agent and will be posted back to OMS.

In case if you are using the free tier of the Microsoft Azure Security Center, data collection can be disabled in the Security Policy as below. Enabling data collection is required for any subscription that uses the Azure Security Center Standard tier.

Once I disabled the data collection I got rid of the OMS agent being that has been auto provisioned in my Azure VMs. Also note that event though the data collection has been turned off, VM disk snapshots and artifact collection will still be enabled. However Microsoft do recommend to enable the data collection regardless of the security center tier your subscription is on.

 

Locking Resources with ARM

Sometimes you need to restrict access to an Azure subscription, resource group or a resource in order to prevent accidental deletion or modification of same by other users. With Azure resource Manager you can lock your resources in two levels.

  • CanNotDelete Authorized users can read and modify a resource, but they can’t delete it.
  • ReadOnly Authorized users can read from a resource, but they can’t delete it or perform any actions on it. The permission on the resource is restricted to the Reader role.

The ReadOnly lock be trick in certain situations. For an example a ReadOnly lock placed in a storage account  prevents all users from listing the keys as the list keys operation is handled through a POST request since the  returned keys are available for write operations. When you apply a lock at a parent, all child resources inherit the same lock. For an example if you apply a lock in a resource group all the resources in it will inherit same and even resources you add later will inherit same.

Locking with PowerShell

Following snippet demonstrates how you can apply a resource lock using PowerShell.

New-AzureRmResourceLock –LockLevel <either CanNotDelete or ReadOnly> –LockName <Lock Name> –ResourceName <resource name> –ResourceType <resource type> –ResourceGroupName <resource group name>

Here you should provide the exact resource type. For a complete list for available Azure resource providers please refer this article.