Okay, so ‘The End Is Nigh’ may be a little strong when referring to SMB, but one of the lesser-known changes that comes with the latest release of Windows 10 is an adjustment to the default installation of SMB. Version 1 of the SMB protocol will not be installed by default*
*- in most cases
What is SMB?
SMB stands for Server Message Block - a protocol used to provide shared access to files, printers and miscellaneous other communications between nodes on a network.
For those old enough to remember RM NetLM, which was RM’s flagship network solution for schools based on Microsoft LAN Manager running on OS/2, a modified version of SMBv1 was utilised by LAN Manager, over NetBEUI. Now, that sentence contains references to a number of technologies I never thought I’d talk about again, but it is an illustration of how venerable SMBv1 is; it’s getting on for 30 years old.
SMBv1 – A Brief History
After various implementations of SMBv1, the next major version of SMB to appear was v2 in Windows Vista. I’ll just let that sink in. Vista. In 2007. That means SMBv1 was still the default file sharing protocol in Windows XP and Windows Server 2003.
Windows 7 and Windows Server 2008 R2 introduced SMBv2.1, and the current major version, v3, came along with Windows 8 and Windows Server 2012.
SMB continues to be improved, bringing us to the latest version – 3.1.1 – introduced with Windows 10 and Windows Server 2016. V3.1.1 is a very long way from those early days of SMBv1.
So why does SMBv1 warrant a blog?
Well, we’ve established that SMBv1 has been ever-present in every major Windows operating system, right up to the very latest release of Windows 10 and Windows Server ‘as a Service’. V1 was superseded in 2007 and deprecated by Microsoft in 2014.
When you add to that the knowledge that the EternalBlue vulnerability in SMBv1 was leveraged by ransomware at least twice in 2017 – by Petya and WannaCry – you start to build the picture of why this is a subtle, but important change.
Hypothetically speaking, patching these vulnerabilities means there’s nothing to worry about, right? Asking for a friend….
If you still have SMBv1 on a network, or client, you look after, staying up to date with available security patches is the first step. Surely though, it’s better not to have a potentially vulnerable component on your network in the first place, which brings us to:
Do you still need SMBv1?
As we’ve already established, SMBv1 is getting on for 30 years old and was deprecated by Microsoft in 2014, but it’s still present in the OS. So what might still need it? The obvious dependency to point out would be on Windows Server 2003, and Windows XP, if there are any such devices still in the network. After that, the most likely areas to find it would be in devices such as printers (particularly older MFDs), older network-aware applications and third-party systems (e.g. CCTV, print management, access control). Lastly, older Linux / Unix systems might also be using SMBv1.
There’s a list in this blog from Ned Pyle at Microsoft to get you started.
Clearly this isn’t an extensive and all-inclusive list. If in doubt, do some research and talk to your third-party vendors. If you’re not already prepared, it’s a good time to be preparing for life after SMBv1, and to take action to retire it from your network.
How you can find out if SMBv1 is still in use
As you might expect, it’s not necessarily obvious that SMBv1 is still in use on a network. There are monitoring and packet inspection tools available that can be used to detect it. For the slightly less geeky, there are facilities built into Windows 10 and Windows Server 2016, and available from the June 2017 rollup for Windows 8.1 and Windows Server 2012 R2, that when enabled will log usage to the SMBServer\Audit event log on the enabled system.
This PowerShell command will configure the SMB Server subcomponent to log events:
Set-SmbServerConfiguration –AuditSmb1Access $true
Back to the Future
Much like the license (registration) plate on the DeLorean in Back to the Future, it seems that with the latest iteration of Windows 10, SMBv1 is ‘OUTATIME’.
As I mentioned at the very beginning, SMBv1 will not be installed on most deployments of Windows 10 v1709. The following table illustrates where it will, and won’t, be installed by default:
- Remember that in this table a cross () is a good thing; it means SMBv1 won’t be installed.
- The red ticks () against upgraded Education and Enterprise editions mean that the SMBv1 Client and Server components will still be present after a Feature update to v1709, and that the administrator will need to take action to remove them, if desired.
- The green ticks () mean that if the relevant subcomponent (Client or Server) is not used for 15 days, excluding any time the computer is switched off, it will automatically uninstall itself.
For Community Connect, our intention is to introduce support for Feature updates with the v1709 release. That means we’ll be establishing a preferred approach for how we handle SMBv1 components installed when v1607 was deployed. The Dev team are looking into this as part of the v1709 introduction project.
Conclusion
SMBv1 is venerable and vulnerable, and in a modern network should not be required any more. It’s a good thing that new installations of the latest release of Windows 10 won’t install it.
With the introduction of v1709 clients, those clients will not be able to communicate with other network components, or servers, dependent on SMBv1. It’s a good time to take action to retire any remaining dependencies on it.
Key Takeaways
- SMBv1 was deprecated in 2014. In a lot of cases it shouldn’t be needed any more.
- Identify any dependencies on SMBv1, plan and take action to remove them, and then SMBv1 itself.
- If there’s a need to retain SMBv1 support for now, limit it to the devices that need it and ensure that patching on those devices is kept up to date.
- Starting with Windows 10 v1709, SMBv1 will not be installed by default in the Education edition.
- Devices running Windows 10 Education edition that were Feature-upgraded to v1709 will still have SMBv1 Client and Server installed, unless explicit action has been taken to remove them.