Will it break anything?
The answer here is 'it depends'. Carefully consider your own environment and how SMB/file & printer sharing is being used. What systems need to interact with one another and what versions of SMB do those systems support?
- Windows XP and Server 2003 need SMB1 for file sharing but newer Windows operating systems do not.
- Some Linux operating systems may need SMB1 as well, but that can be disabled for Samba starting with version 3.6.
- Multi-function devices should be checked to verify that the firmware supports SMB2 or 3 as there are reports of some older devices that do not. If you do not use scan-to-network capability, this may be irrelevant.
- Network/security devices that interact with your Active Directory domain may be an unexpected source of SMB1 reliance. For example, Sophos UTM appliances with current firmware require SMB1 in order to use AD Single-Sign On.
I think the best guidance here is simply to be careful, plan the change, and test thoroughly. It never hurts to have a roll-back plan too.
How do I disable it?
Microsoft has specific guidance available for toggling the SMB protocols in Windows in this article. Bear in mind that we're only interested in disabling SMB1 for now. SMB2/3 are still needed for Windows file sharing in current operating systems, and they do not have the vulnerability that's being exploited by WannaCry. For a handful of machines you can easily hand jam these changes and be done with it. For larger environments, scripting out the change and creating a Group Policy for your Windows machines will certainly be the most efficient method of delivery. There are already dozens of scripts in the wild for disabling the SMB1 protocol on Windows machines. You need look no further than the WannaCry Megathread on Reddit for numerous options.
I'm a roll-my-own kind of guy, because I like to keep things as simple as possible and ideally learn something from the process. It also helps me to validate that the results of a script are predictable within my specific environment, and that there's no superfluous functionality that's going to cause problems, so I wrote a simple PowerShell script for deployment through AD Group Policy. All it does is query the Win32_OperatingSystem WMI object and then apply the proper fix from Microsoft's article depending on the OS version detected. It works on Windows 7/Server 2008 through Windows 10 / Server 2016. If you're deploying these changes differently in your environment, I'd love to hear about it.
Get the script: Here
No comments:
Post a Comment