Server Message Block (SMB) is a critical component for any Microsoft-oriented networking environment. That’s why hardening SMB is one of the critical steps in securing Active Directory Domain Controllers.
In the first part of this series, I’ve shown you how to report on incoming SMB connections on your Active Directory Domain Controllers. Now, let’s put the data to work. Let’s disable SMB versions that are no longer used or shouldn’t be used anymore throughout your networking environment.
The trouble with old versions of SMB
The original Server Message Block (SMB) protocol, known as version 1, is over 30 years old. It was conceived in a world before the Internet and was designed for safe networks. Because of its legacy, it’s underperforming, it doesn’t offer encryption and uses signing based on weak hashing methods. Yet, it was the default version of SMB shipping with Windows until Windows Server 2003. Today, Microsoft urges you to stop using SMBv1.
When comparing to SMBv1, SMB version 2 introduced performance improvements, symbolic links and SHA-256 message signing in 2006 with Windows Vista.
SMBv2 offers a much better alternative than SMBv1, but still SMBv3 is the version you’d want to see negotiated. Especially since SMBv3 offers end-to-end encryption. Yet, this version wasn’t released until Windows 8.1 and Windows Server 2012 R2.
SMBv2 is currently not as problematic as SMBv1 and thus as urgent as disabling SMBv1. In time, though, SMBv2 will also prove to be too insecure to leave around.
Why SMBv1 is still around
You’d think that when all devices and servers on the network run supported Operating Systems (OSs), you wouldn’t see any SMBv1 or SMBv2 around. Reality, however, is stubborn. Your networking infrastructure doesn’t merely run Windows. It also features printers that are capable of storing scanned documents onto a file share, virtualization products from different vendors, management solutions, backup solutions, etc.
The SMB1 Product Clearinghouse offers an overview of solutions, services, applications, products and devices still actively requiring SMBv1.
Getting rid of SMBv1
When we disable SMBv1, we might break the functionality these other solutions offer to our infrastructure. This is undesirable. Therefore, we report on SMBv1, SMBv2 and SMB null sessions, before we disable any of them.
When you have found SMBv1 connections this way, you have three approaches to get rid of them:
- Check the SMB1 Product Clearinghouse for the solution, service, application, product and/or device that still uses SMBv1. If the vendor provides an upgrade path to a version of the solution, service, application, product and/or firmware for the device, apply it.
- If the solution, service, application, product and/or device is not listed in the SMB1 Product Clearinghouse, contact a sales representative for the product and ask for a solution. Then, send an email to StillNeedsSMB1@microsoft.com to get the product added to the clearinghouse page.
- If the solution, service, application, product and/or device that still uses SMBv1 is older than fifteen years, chuck it. Don’t expect any help. Replace it with a product, service, application and/or device that is not listed in the SMB1 Product Clearinghouse.
Disabling SMBv1 is actually straightforward. For Domain Controllers running Windows Server 2016, run the following three lines in an elevated Windows PowerShell session:
$P = "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters"
New-ItemProperty -Path $P -Name SMB1 –PropertyType DWORD –Value 0 –Force
Disabling SMBv1 on Active Directory Domain Controllers improves the security posture of your Microsoft-oriented networking environment.