It’s been quite a ride, Server Message Block has been. That’s my own feeble attempt at channeling Yoda as he tries to explain what’s been happening with SMB support in Microsoft Windows over the years. SMB is the network file sharing protocol used by Windows Server, and it’s implemented as a client/server protocol that runs in the Application or Presentation layer of the OSI stack while relying on lower-level protocols as the transport mechanism for getting packets to go from here to there. What this basically means is that SMB is used by client computers to request file services from servers over a network. SMB is also used as a transport protocol for remote procedure calls (RPCs) because it supports the creation and use of named pipes. And the question I want to pose here is this: Whither SMB?
Quick history lesson
Over the years, SMB has aged much more gracefully than I have. Here’s a quick history lesson that should bring back some memories for those of you who have been in IT for a while:
1996 — Microsoft includes support for CIFS (Common Internet File System), an early precursor to SMB, in their Windows NT 4.0 file system. We won’t say anything more about this because who runs Windows NT nowadays anyway?
2000 — SMB version 1.0 makes its appearance in Windows 2000 Server and continues to hang around through the Windows Server 2003 and Windows Server 2003 R2 eras. Unfortunately SMB 1.0 was a rather “chatty” protocol as it generated a lot of network traffic, which was a problem especially when you tried to access file services over a slow WAN link. SMB also had some other limitations, for example concerning the number of open files and the total number of shares it could support. So it’s not surprising that its life expectancy was limited.
2008 — SMB 2.0 made its appearance in Windows Server 2008 and also in Windows Vista, which it’s best not to speak further about. Version 2.0 relaxed the limitations regarding file sharing and used packet compounding to reduce the amount of chattiness generated by the protocol, thus enabling faster communications with file servers. Of course Microsoft also maintained support for SMB 1.0 in Windows Server 2008, and that was a good thing (at the time) since backward compatibility is frequently a big concern for organizations (especially large enterprises) that are considering upgrading their operating system to a newer version. As we’ll see next, however, I sometimes wonder if things didn’t begin to fall apart at Microsoft at that time, since the years that followed also brought incremental upgrades to SMB, which makes me wonder whether they had started pushing new features out the door too fast around then.
2009 — This incremental improvement was called SMB 2.1 and it appeared only about a year after 2.0, when the R2 release of Windows Server 2008 was released together with the still much-loved-by-many Windows 7. SMB 2.1 included several enhancements that basically resulted in reduced bandwidth consumption, better response when accessing files over the network, and improved scalability for file servers. A key design goal for SMB 2.1 was to enable better performance over high-speed low-latency 10 GbE networks. Key to making these possible was increasing the maximum transmission unit (MTU) size from 46KB to 1MB, and the result could easily be seen when one tried to copy large files using 2.1 compared to 2.0.
2012 — SMB 3.0 jumped on the stage with the release of Windows Server 2012 and its client version Windows 8, the former of which was an unfinished milestone while the latter is something most of us prefer to forget (like Vista). I wrote at length about the new features of SMB 3.0 in my free ebook Introducing Windows Server 2012 and these improvements can be summarized as follows:
- SMB Direct, which enables using network adapters capable of Remote Direct Memory Access (RDMA) such as iWARP, Infiniband, or RoCE (RDMA over Converged Ethernet) that can function at full speed and low latency with very little processor overhead on the host.
- SMB Directory Leasing, which reduces round-trips from client to server because metadata is retrieved from a longer living directory cache.
- SMB Encryption, which enables end-to-end encryption of SMB data to protect network traffic from eavesdropping when travelling over untrusted networks. S
- SMB Multichannel, which allows aggregation of network bandwidth and network fault tolerance when multiple paths become available between the SMB client and the SMB server.
- SMB-specific Windows PowerShell cmdlets, which provide Windows PowerShell cmdlets and WMI objects to manage SMB file servers and SMB file shares.
- SMB Scale Out, which allows you to create file shares that provide simultaneous access to data files with direct I/O through all the nodes in your file server cluster.
- SMB3 Secure Dialect Negotiation, which helps protect against man-in-the-middle attacks, where eavesdroppers attempt to downgrade the initially negotiated dialect and capabilities between an SMB client and an SMB server.
- SMB Transparent Failover, which allows administrators to perform hardware or software maintenance of nodes in a clustered file server without interruption to server applications storing their data on file shares.
- VSS for SMB file shares, which allows SMB clients and SMB servers supporting SMB 3.0 to take advantage of the Volume Shadow Copy Service (VSS) for SMB file shares.
Now on the face of it, these improvements (and a bunch of others introduced a year later in 2013 with SMB 3.0.2 in Windows Server 2012 R2) sound like nothing short of a revolution. But it’s important to keep in mind that many of these improvements were introduced to bring the operation of SMB into the age of virtual servers running on Hyper-V host clusters, and to some extent, the idea of SMB as a protocol became somewhat blurred as a result. For example, one SMB 3.0.2 feature, Hyper-V Live Migration over SMB, allows you to perform a live migration of virtual machines by using SMB as a transport. Whether that’s a feature of SMB as a protocol of Live Migration as a feature of Hyper-V can be debatable, however.
SMB in Windows Server 2016
- SMB Encryption has been enhanced with additional support for AES-128-GCM, which is now the default encryption algorithm instead of AES-128-CCM, which is still supported but no longer the default.
- SHA-512 cryptographic hash is now used during the negotiate and session setup portions of an SMB conversation to provide extra protection against man-in-the-middle attacks.
- Some miscellaneous under-the-hood changes in how the SMB Client or SMB Server components of Windows functions.
These changes seem pretty minor compared to what was introduced for SMB in versions 3.0 and 3.0.2, and my own thinking is that with Windows Server 2016, Microsoft finally was able to implement most of what it had originally planned for Windows Server 2012. However, what’s really important is that up until now Microsoft has continued to support all earlier versions of SMB in each successive version of Windows it has released. This means in particular that SMB 1.0 is still enabled by default in Windows Server 2016.
And that’s a very bad thing. Why? Because most of the significant improvements made to SMB over the years have been in two areas: reliability and security. And security is probably the uppermost thing in the minds of most system administrators these days. Ned Pyle, a principal program manager in the Windows Server High Availability and Storage group at Microsoft, probably says it best when he points out that continuing to use SMB 1.0 means you are giving up message signing, guest authentication blocking, secure dialect negotiation, pre-authentication integrity, and encryption when you use SMB to access files over the network.
The solution, of course, is to disable SMB 1.0 on all your Windows Server systems, and this Knowledge Base article explains how you can do this and this post on Microsoft’s “Stay Safe” Cyber Security Blog has some further details you may want to look at. But there’s a catch, of course, because if any of your clients or applications are still using SMB 1.0, then disabling it will break things. Windows Server 2003 and Windows XP use SMB 1.0 but those platforms are now out of support so you shouldn’t be using them any longer on your network. There may also be a few other reasons why you’re still holding on to SMB 1.0 but to avoid leaving your network exposed to ransomware attacks like WannaCry, you’d best start planning on how to get rid of SMB 1.0 entirely and forever from your network.
Which brings me back to my original question of “Whither SMB?” From the looks of things, Microsoft has taken the foot off the gas pedal of improving core networking features like SMB and is focusing most of their energies now on enhancing the virtualization capabilities of Windows Server to make the platform more suitable as a foundation for building private, public, and hybrid cloud solutions. But based on past experience, Redmond usually doesn’t take their eye off the ball for very long, so it’s a good idea to get a handle on how SMB has evolved over the years and give some thought to how it might still be improved.
Photo credit: Shutterstock