Remember the nasty ransomware attacks Petya & WannaCry which spread almost like a zombie apocalypse earlier this year? Millions of devices arround the world were affected with these attacks which were designed to exploit the loopholes in the good old Server Message Block version 1 (SMB v1) protocol. A lot of security experts have argued that having SMB v1 enabled in servers/PCs by default will leave the consumers vulnerable for any future attacks of this nature.
Starting this month, Azure Security Team has closed the doors for SMB v1 protocol for Windows OS images available in Azure marketplace. This means that when you deploy a VM with any of the below operating systems using an Azure marketplace image, the SMV v1 protocol is disabled by default.
- HPC Pack 2012 R2 Compute Node with Excel on Windows Server 2012 R2
- HPC Pack 2012 R2 on Windows Server 2012 R2
- Windows Server 2008 R2 SP1
- Windows Server 2012 Datacenter
- Windows Server 2012 R2 Datacenter
- Windows Server 2016 – Nano Server
- Windows Server 2016 Datacenter
- Windows Server 2016 Datacenter – with Containers
- [HUB] Windows Server 2008 R2 SP1
- [HUB] Windows Server 2012 Datacenter
- [HUB] Windows Server 2012 R2 Datacenter
- [HUB] Windows Server 2016 Datacenter
- [smalldisk] Windows Server 2008 R2 SP1
- [smalldisk] Windows Server 2012 Datacenter
- [smalldisk] Windows Server 2012 R2 Datacenter
- [smalldisk] Windows Server 2016 Datacenter
This doesn’t mean that you can turn a blind eye to your existing Windows VMs in Azure. If you haven’t already disabled SMB v1 in those, you can refer this TechNet article to learn how to do so. Regardless of where your servers and PCs are deployed (cloud or on-premises) Microsoft strongly recommend you to disable SMB v1 protocol.
OK what about Linux ?
The Samba service which enables the SMB protocol in Linux VMs is not installed by default in any Azure Linux gallery image. If you install this service later on once you have provisioned a VM vulnerability report CVE-2017-7494 need to be taken into consideration to there are any threats that you should be alarmed of. This explains the vulnerabilities in Samba 3.5 and onward where as the current version is 4.6.7. However it is always recommend to update to the latest version as soon as possible.
Do I need to use SMB v1 ever ?
SMB v1 has been superseded by SMB v2 & V3 a long back. These versions are inherently more secure than the v1 of SMB protocol. However there are dozens of products out there which still leverages the SMB v1 protocol. This TechNet article lists out most of the products that still leverage SMB v1 at some point of their current life cycle.
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.
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.