This post begins with a warning about disabling SMBv1, a scary warning that should cause cold, bone-chilled sweats and nightmares of a post-apocalyptic future fit for neither man nor beast; and you should read this dire warning right after reading this sentence you are now reading.
Warning
Disabling SMBv1 without thoroughly testing for SMBv1 traffic in your environment can have unintended consequences, up to and including a complete suspension of all network services, denied access to all resources, and remote authentication failures (like LDAP).
We simply cannot stress enough, even when using BOLD UNDERLINE ALL-CAPS WARNINGS that disabling SMBv1 in certain scenarios can lead to an almost biblical level of devastation and probably an exercise in résumé writing. Recovery will most likely require a physical visit to each machine in your organization, remote or local. There is no “undo” switch, no command in which to recover from a loss of authentication due to SMBv1 disablement (except maybe something like setting up a scheduled task to undo the change locally should things go terribly awry).
What could possibly go wrong with disabling a communication protocol that’s been around for 30 years? Here’s an incomplete list (note: some vendors are actively working on resolutions to this, so if you see this in the list, confirm with the vendor and update your application/appliance as appropriate). But first, another warning from Ned Pyle, master of the SMB over at Microsoft. He had this to add after someone asked him why he didn’t provide a script to remove SMBv1 after he authored a scathing article about how SMB1 was evil.
“Because if I gave out a widespread removal script, it would be like throwing a bomb over my shoulder. People would simply run it without thought because it came from MS. You must always approach protocol removal with caution when you are responsible for 2 billion computers. That’s why I provided all the necessary info on how in 2696547 and leave it to IT pros to decide how they want to do it with their umpteen hundred methodologies and 3rd parties. 12% of all SMB communication worldwide is still SMB1. [emphasis ours]” -Ned Pyle Quote
Products, services, and infrastructure elements that continue to use SMBv1
This is not a comprehensive list, by any means.
Currently requires SMBv1 as of this writing*:
Windows XP and Server 2003/R2 (verified) Sophos UTM and Others. They do have some Suggested Workarounds (verified)
Konica BizHubs, Xerox printers, certain Ricoh printers, Toshiba printers and so many others. In many cases, you can move from scan to a folder to scan to email and bypass the SMBv1 (not verified).
Certain EMC SANs, such as certain/some/all of the VNX storage systems (verified).
ManageEngine ServiceDesk’s SSO/AD Authentication will not work if SMBv1 is disabled (verified).
A shared MS Access database (not verified).
File system explorers for Android (not verified).
A multitude of manufacturing and fabrication technologies and equipment, such as CNC machines and SCADA systems (not verified).
McAfee Web Gateway (not verified).
McAfee Appliances that run Linux using older AD auth (not verified).
MalwareBytes definitions (not verified).
Buffalo Appliances (some known, but not verified).
Certain Synology NAS products (verified).
Cisco WAAS – (verified).
Xen for Linux >> Windows (verified).
Backup software (Barracuda, Veeam, etc.) that uses authentication (not verified).
Some firewalls and switches -you will need to check your firewalls/switches (verified).
Active Directory operating in Forest Functional Level of 2008 or lower -please check (verified).
SQL server. This will depend on a lot, such as mixed mode authentication, SQL server build, AD functional level, etc. Test, test, test (not verified).
SMBv1 enabled by default, but can (read: should) be changed to SMBv2+*:
vCenter Server Appliance (VCSA) < 6.5 (6.5+ uses SMBv2 by default -thanks to RR for the update). For version < 6.5 you can get around SMBv1 by Enabling SMBv2 (verified).
Certain Synology NAS products (verified).
Buffalo Appliances (not verified).
Quantum DXi appliances (not verified).
QNAP NAS -SMBv1 (verified).
Harmonic Mediagrid (not verified).
Some firewalls and switches (verified).
*Some items exist in both lists, as some versions of the application/appliance are SMBv1 only and other versions are SMBv1 by default but can be modified to use SMBv2+.
Testing for SMBv1 in Your Environment:
In this, our cautionary tale, we use Wireshark to look at SMB traffic to determine what is using which SMB protocol, including SMBv1. Install Wireshark if it’s not already installed. Ideally, you will install Wireshark on a laptop so you can migrate around your site testing different VLANs or networks as necessary. Keep in mind you’re going to want to mimic what users do (authenticate with AD, print, scan to a folder, etc.) and capture how your applications communicate across the network.
NOTES:
The reason we recommend a display filter rather than a capture filter is so that we capture all data and run a dynamic filter on the collected data. Capture filters, if malformed, can provide bad data.
In cases where you will be capturing large amounts of data, use a capture filter instead. This will limit the size of PCAP files as it will discard anything that doesn’t match. For example, capturing on a DNS server or file server will result in massive PCAP files. Massive.
For the best results, mirror a switch port, use a hub (yes, they are still exceptionally useful in networks), buy or make a Tap, or run Wireshark from many users’ machines -ideally users that access different resources on the network.
First, fire up Wireshark and select the interface to capture:
At this point, you will be capturing all traffic the interface sees. This can get overwhelming very quickly, but we’ll be filtering this out, so no need to worry about the large amount of information you are collecting (see notes above).
When you are done testing stop your capture, throw in the filter so we only see relevant traffic, and then sort by protocol.
Wireshark Display Filter for SMB:
tcp.port eq 445 or tcp.port eq 139This will show you all SMB and NetBIOS traffic:
After you have applied this filter, look for the protocols. Here is an example of what SMB2 looks like:
Here is an SMB negotiation packet:
IMPORTANT: The view from the capture page can be confusing, as the protocol looks at only the protocol, SMB, and not necessarily the version.
Other packets you may see in this filter include DCERPC. When you open a DCERPC packet, you can view the SMB protocol associated with it:
You may also see the SAMR protocol.
And finally, here’s what SMBv1 looks like:
Disable SMBv1
You’ve read the warnings, performed the testing, and are now ready to disable SMBv1.
If the warnings above were not ample enough, here’s one more. PDQ.com provides these instructions as-is, without support, or any warranty of any kind, implied or otherwise. There is absolutely no guarantee of fitness or that these instructions are in any way suitable for your, or any, environment at any time. You accept all responsibility for the use or misuse of this package, and accept any and all consequences.
Okay, that’s done. You have been warned, let us go where angels fear to tread:
1. First, open PDQ Deploy and create a new package. Call this something meaningful. Include all relevant options, including a WARNING OF TERROR for your peers.
2. Next, create a PowerShell script called CheckServerCompatibility.ps1 and place it in your PDQ Deploy Repository using the following path ($(Repository)\Disable SMBv1\CheckServerCompatibility.ps1). This script will check to make sure you do not accidentally run the package against a Domain Controller or Exchange server.
$DomainRole = (Get-WmiObject Win32_ComputerSystem).DomainRole
$ExchangeSvc = Get-Service -Name MSExchangeServiceHost -ErrorAction SilentlyContinue
#### Check if this is running on a domain controller and exit to avoid causing any problems on the domain
if ($DomainRole -eq 4 -or $DomainRole -eq 5) {
Write-Output "This machine has the Active Directory Role installed. Quitting to avoid any potential damage on this domain"
exit 1
}
else {
Write-Output "Not running on a domain controller. Continuing..."
}
#### Check if this is running on an Exchange server and exit to avoid angering Exchange
if ($ExchangeSvc -ne $null) {
Write-Output "This machine is running an Exchange server. Exiting to avoid angering Exchange"
exit 1
}
else {
Write-Output "Not running on an Exchange server. Continuing..."
}3. Now create a PowerShell step that calls this script from the Repository. The PowerShell you will use in the PowerShell step is
& '.\CheckServerCompatibility.ps1'
And you’ll want to add the path to that file in the Files section (make sure the Options Tab, Error Mode is set to “Stop Deployment With Error”):
4. Next, add a Command Step to add the registry key that will disable SMBv1. The command is this:
%SystemRoot%\System32\Reg.exe ADD "HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" /v SMB1 /t REG_DWORD /d 0 /f
And set the following conditions in the Conditions Tab for this step:
5. Next, add another Command Step to prevent SMBv1 from starting (pre-Windows 8.1):
sc.exe config lanmanworkstation depend= bowser/mrxsmb20/nsi
sc.exe config mrxsmb10 start= disabled
And set the following conditions in the Conditions Tab for this step:
6. And now add another PowerShell step to disable the SMBv1 server:
Set-SmbServerConfiguration -EnableSMB1Protocol $false -force
And set the following conditions in the Conditions Tab for this step:
7. Next, add another PowerShell step to remove the Windows Feature, should it exist.
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart
And set the following conditions in the Conditions Tab for this step:
8. Lastly, reboot all machines where you have deployed the SMBv1 disablement. Good luck and Godspeed.
Special thanks to Katie, Kris, Josh, and Colby for their significant contributions to this blog article.
