Many IT pros probably take for granted sharing files on their predominantly Windows environments and local area networks. Although several protocols are available, Server Message Block (SMB) is clearly the most prevalent. This article examines how Windows file sharing works over ports 445, 139, 138, and 137.
SMB is a network file-sharing protocol that allows applications on networked computers to read and write files and request services from ‘server’ programs. The SMB protocol can be used on top of the TCP/IP protocol along with other network protocols.
CIFS and SMB (v1) are essentially the same and are not recommended for usage, especially on the Internet. They contain severe security vulnerabilities and are not installed by default in Windows. In fact, Microsoft is (slowly) phasing this functionality out of Windows – as soon as we IT pros remove it completely from our environments!
The bulk of this post will be describing the various SMB dialects in use throughout enterprises. As Microsoft developed newer versions of Windows over time, they, in tandem, introduced more robust, secure, and performant versions of SMB. Let’s go through each of these one by one.
The original Server Message Block (SMB 1.0) protocol is over 30 years old! In the OSI (Open Systems Interconnection) networking model, Microsoft’s SMB Protocol is often used as an application layer or a presentation layer protocol; it relies on lower-level protocols for transport across your network’s physical mediums.
This first iteration of what would become a standard was incredibly chatty on the network. It slowed down Wide Area Network (WAN) links due to its inherent overhead. As I already stated, perhaps most importantly, it was very insecure.
Samba is a free and open-source re-implementation of SMB, originally developed and written by Andrew Tridgell. It is often referred to as a Samba server – a server-based product that implements the SMB protocol and Microsoft extensions by providing samba shares on your network seamlessly.
This dialect is highly popular in the Apple/Mac and Linux/Unix camps and runs on Linux, Solaris, BSD, and AIX variants. It is standard on almost every Linux distribution and is used as a basic system service on various Unix-based operating systems.
As I stated above, Common Internet File System (CIFS) can be interchanged with SMBv1. It is a cross-platform, transport-independent protocol that provides a mechanism for clients to use low-level Windows file and print services.
Interestingly, the meaning of ‘CIFS’ has changed since its inception. It was originally designed and intended as a proposed standard version of SMB based on Windows NT 4.0 and Windows 2000. However, in the past 10-15 years, it is commonly referred to as the de facto standard/protocol for sharing files off of NAS (Network Attached Storage) devices.
NQ is another SMB implementation developed primarily by Visuality Systems. It is a family of portable client/server systems that are compromised of an embedded SMB stack (written in the C language), a pure Java SMB client, and a storage server implementation. It even supports the most recent SMB 3.1.1 developed by Microsoft in Windows Server 2016 and Windows 10.
SMB 2.0 improved on CIFS and reduced the very chatty nature of SMB 1.0. It did this by reducing the number of protocol commands from hundreds down to under 20.
It also added support for symbolic links, allowing you to leave a placeholder of sorts for a file link across the network. Many security issues were also addressed.
Introduced with Windows Vista and Windows Server 2008 in 2006, it also provided support for the pipelining mechanism. Major performance and efficiency gains were made by increasing packet sizes to 32-bit (and 128-bit for file handles). Caching and durable connections were added in another bid to boost performance.
Fusion File Share by Tuxera is one of the proprietary SMB server implementations that can be run in either kernel or user space, a great boost for interoperability. It also supports SMB 3.1.1 including previous versions.
Besides the raw features inherent to SMB, it also includes advanced SMB features like RDMA (SMB Direct), SMB multichannel, continuous availability scale-out, and transparent compression.
In 2009, Likewise developed a new CIFS/SMB implementation. The key aspects of this dialect were a multiprotocol, identity-aware platform for network access to files used in OEM storage products built on Unix/Linux devices. Use cases included NAS, cloud gateway, and even cloud caching devices. EMC Isilon took over this dialect when they purchased Likewise in 2012.
Let’s round out the discussion on SMB dialects by providing the most recent history of SMB in Microsoft Windows.
Opportunistic locking is a mechanism designed to offer more performance by controlling the caching of network files by the client.
In addition, security was boosted, as expected including a new AES-based signing algorithm.
SMB 3.1.1 was released with Windows 10 and Windows Server 2016 – this would put it around the 2016 timeframe. This version is current and supports AES-128 encryption in addition to AES-128 CCM encryption. The biggest security boost however comes from SMB 3.1.1 requiring secure negotiation when connecting with clients using SMB 2.x and up.
I will round out this post by explaining what ports SMB has traditionally used and uses today. Let’s start with the most common – 445.
In modern and supported versions of Windows, File and Printer Sharing services use TCP port 445. When you need to make adjustments (carefully) to firewall setups, either on the client or a router, TCP port 445 needs to be open in order to be able to accept incoming file share requests from an SMB client. When you enable this feature in Windows, it will automatically allow this port in the local Windows (Defender) firewall software.
In the earliest versions of SMB 1.0, there were three ports used in tandem to allow client/server SMB file-sharing activity using NetBIOS over TCP/IP (NBT). Port 139 was used for session services.
As a part of the original SMB 1.0, UDP port 138 was used for datagram services.
And finally, with the initial implementation of SMB 1.0, TCP/UPD port 137 was used for name services.
It’s now time to put some of our learned knowledge to practical use. Let me show you how you can check what versions of SMB are enabled on a Windows device, and how to enable or disable them. Let’s first start with the Windows GUI.
We can use the Windows Defender Firewall in Windows 10 to enable File and Printer Sharing TCP/UDP ports (incidentally, this is what ‘Network Discovery’ enables). You can open Control Panel or click the Start button, type in ‘firewall’, and choose Windows Defender Firewall.
On the left, click the Advanced settings link.
Now, click the Inbound Rules link in the tree on the left.
Scroll down to the File and Printer Sharing items. The specific ones we want are File and Printer Sharing (NB-Session-In) & ‘File and Printer Sharing (SMB-In). Right-click on each of them on the Domain Profile and choose Enable Rule.
Thankfully, Microsoft added some PowerShell commands in Windows 8 to assist us ‘command-line’ IT Pros. Run the following command to disable SMB 1.0 and enable SMB 2.0 running on your Windows computer.
Set-SmbServerConfiguration -EnableSMB1Protocol $false Set-SmbServerConfiguration -EnableSMB2Protocol $true
No news = good news! You’re good.
We can also use PowerShell to quickly check the status of SMB 1.0 and SMB 2.0 running on a computer. Run this single command to check the status.
Get-SmbServerConfiguration | Select *protocol*
We are in a good state – again, this is how Windows 10/11 is configured by default: SMB 1.0 is disabled while SMB 2.0 and 3.0 are enabled.
The best course of action here is to make sure that SMB 1.0 is NOT enabled. This is absolutely imperative. You can run the PowerShell command above to disable SMB 1.0. In fact, I would highly recommend you verify that a Group Policy object is set to blanket ALL of your Windows domain-joined devices. If you have any requirements for SMB 1.0, you should definitely re-evaluate them.
Remember what I wrote when starting this post? That part about taking for granted sharing files in Windows? Yes, that part. Well, if I were to pick the most important reason for stating that, it would be security.
I will admit that once you have a secure environment, maybe only using SMB 2.0/3.0 on your network, an odd technical issue may arise. All of a sudden, your brand new laptops running Windows 11 may not be able to access your file servers.
You’ll eventually pinpoint it to some type of access or permission/security issue. At this point, it is fairly straightforward to make changes to your client registries to make the clients work, especially if it is your CEO! Anyway, please plan the time to dig into the details and implement changes to re-secure your enterprise. I am sure Microsoft Support would be glad to help!
Thank you for reading my article. If you have any comments or questions, please leave me a comment below.