The SMB protocol is a client–server communication protocol that has been used by Windows since the beginning for sharing files, printers, named pipes, and other network resources. SMB stands for "server message block." Apart from regular resource sharing, SMB is also useful for inter-process communication (IPC), such as in mailslots.
Latest posts by Surender Kumar (see all)

SMB protocol dialects ^

The SMB protocol has evolved over time, and its various versions are commonly referred to as dialects. Microsoft continues to work hard to improve SMB with each new version of Windows. The following table shows the SMB dialects used in various Windows versions:

SMB DialectYearOperating SystemKey Points
SMB 1.01984Windows XP, 2003 and earlierExtremely chatty, No encryption, Insecure
CIFS1996Windows 95, Windows NT 4.0Supports larger files, direct transport over TCP/IP
Supports symlinks and hardlinks
SMB 2.02006Windows Vista, Server 2008Reduced protocol chattiness, Supports the pipelining mechanism
SMB 2.12010Windows 7, Server 2008 R2Minor performance improvements, Opportunistic locking, Significant MTU support
SMB 3.02012Windows 8, Server 2012End-to-end encryption, SMB transparent failover, SMB direct, SMB multichannel, SMB scale out
SMB 3.022014Windows 8.1, Server 2012 R2Performance improvements, ability to disable CIFS/SMB 1.0 for increased security
SMB 3.1.12015Windows 10, Server 2016, Server 2019Supports AES-128-GCM and AES-128-CCM encryption, supports directory caching, supports pre-authentication integrity checks to mitigate MITM attacks
SMB 3.1.1*2021Windows 11, Server 2022Supports AES-256-GCM and AES-256-CCM encryption, SMB direct with encryption, Supports SMB over QUIC

As you can see in the table, Windows 11 and Windows Server 2022 still use the SMB 3.1.1 dialect which has few new features and security enhancements.

Understanding SMB protocol services ^

As a client–server protocol, SMB requires a server service (LanmanServer) and a client service (LanmanWorkstation). Every Windows computer, whether it is running a server OS (like Server 2016 or Server 2019) or a client OS (like Windows 10 or Windows 11), has both the LanmanServer and LanmanWorkstation services. You can check the status of both services using the Get-Service Lanman* PowerShell command.

Viewing the status of Server and Workstation services using PowerShell

Viewing the status of Server and Workstation services using PowerShell

After the infamous WannaCry, Petya, or similar attacks, people were told to disable these services. Let's first understand these services.

Lanman server service

Remember, even if your computer is running a client OS, the LanmanServer service makes sure that your computer can act as a server for hosting SMB shares. Even if you aren't sharing any folders on your own, there are default shares (such as admin$, C$, IPC$, etc.) that are important for administrative purposes. All these shares depend on the LanmanServer service. You can use the Get-SmbShare PowerShell command to view all the shares on your computer.

Viewing all the shares on your computer using PowerShell

Viewing all the shares on your computer using PowerShell

The information about the LanmanServer service is stored in the following registry location:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer

Is it safe to disable the Lanman server service?

As discussed above, the LanmanServer service is important for your computer to be able to host SMB shares. If you stop this service, all the sharing will stop working, and other computers will not be able to access the resources you are sharing on your computer (including folders, printers, and default admin shares). This should give you an idea of how important the LanmanServer service really is, particularly for a file server or a domain controller in Active Directory (due to the sysvol and netlogon shares).

For home users, if you're not using any file or printer sharing services, the service can be safely disabled. Before actually disabling it, use the following command to check whether there is any service dependent on it:

Get-Service LanmanServer -DependentServices
Viewing dependent services on LanmanServer using PowerShell

Viewing dependent services on LanmanServer using PowerShell

You can see my computer docker desktop service depends on the LanmanServer service. If I disable LanmanServer, the Docker service will not be able to start. If you do not see any important dependent service on your computer, you can go ahead and safely disable the LanmanServer service using the following PowerShell command:

Set-Service LanmanServer -StartupType Disabled -PassThru | Stop-Service -Force
Disabling and stopping the LanmanServer service using PowerShell

Disabling and stopping the LanmanServer service using PowerShell

Restart your computer after running this command, and you will notice that port 445 is no longer listening. Disabling this service will not affect your ability to use the Internet.

Lanman Workstation Service

Similarly, the LanmanWorkstation service on your computer makes sure that it can utilize SMB shares and shared printers from remote computers or servers. The information about this service is stored in the following registry location:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation

Is it safe to disable the Lanman workstation service?

Stopping the LanmanWorkstation service means you're essentially stopping the computer's ability to use remote SMB shares. If you run the Get-Service LanmanWorkstation -DependentServices command, you will notice two services (Netlogon and Remote Desktop Configuration) that depend on the LanmanWorkstation service. As the name suggests, netlogon is an important service for network logon and authentication. If you disable it, your computer will not be able to communicate properly with other network devices.

Viewing dependent services on LanmanWorkstation using PowerShell

Viewing dependent services on LanmanWorkstation using PowerShell

Again, home users who do not use any kind of network service may disable this service. Disabling it will not impact your ability to use the Internet, local printer (connected via USB), or even the network printer (having built-in TCP/IP support). Remember, your computer will not be able to access the shared resources on remote computers, and other computers will not be able to access your computer. For a normal home computer, disabling this service could be a good thing in terms of security. To disable the LanmanWorkstation service, use the following command:

Set-Service LanmanWorkstation -StartupType Disabled -PassThru | Stop-Service -Force
Disabling and stopping the LanmanWorkstation service using PowerShell

Disabling and stopping the LanmanWorkstation service using PowerShell

When the LanmanWorkstation service is stopped on a computer, anyone who tries to access that computer from the network will see The specified network name is no longer an available error, as shown in the following screenshot:

The specified network name is no longer available

The specified network name is no longer available

If you get this error in your domain or workgroup environment, please make sure that the LanmanWorkstation service is running on the remote computer to which you're trying to connect. Once you start this service, also remember to start the dependent netlogon service; otherwise, you could get the following error:

An attempt was made to logon, but the network logon service was not started

An attempt was made to logon, but the network logon service was not started

Important note for network computers

If your computer is a part of a workgroup or domain network, I would highly suggest leaving both the LanmanServer and LanmanWorkstation services enabled. Disabling them will not do any good, but rather give you a lot of headaches as an admin. Instead of disabling them, properly restricting the access of the relevant ports (TCP 139 and 445) to a trusted network will be a sufficient security measure.

Various SMB protocol implementations ^

The SMB protocol is one of the most popular protocols for file and resource sharing over networks. And not only with Windows—it has also been widely adopted by other operating systems, such as Linux/Unix and macOS. Below are some of the most popular implementations of the SMB protocol:

  • CIFS—The common internet file system (CIFS) is Microsoft's implementation of the SMB protocol.
  • Samba—An open source SMB implementation that is highly popular in Linux/Unix and macOS.
  • NQ (YNQ, jNQ, NQ storage)—This is another SMB implementation developed by Visuality Systems.
  • Fusion File Share—Formerly known as Tuxera SMB, this is a proprietary implementation of Samba developed by Tuxera Inc.

Note that the SMB protocol is not a Windows-only thing. To give you a rough idea about the popularity of SMB, there are numerous other SMB implementations in various programming languages—JFileServer (Java-based), pySMB and impacket (Python-based), MoSMB (mojo-based), and so on.

Security considerations for the SMB protocol ^

Remember the infamous WannaCry and Petya attacks and the EternalBlue exploit? They all lead back to an SMB 1.0 vulnerability, one way or another. Therefore, it is vital to cover some SMB features that you can use to secure SMB communication in your network.

We will cover the following best practices to secure SMB communication:

  • Explicitly disable the obsolete SMB dialects (SMB 1.0 in particular) and NBT in your network.
  • Restrict the SMB ports' access to trusted networks and clients.
  • Always use the latest SMB dialect (SMB 3.1.1) whenever possible and enable security features.

Disabling SMB 1.0

As we have already discussed, SMB 1.0 is no longer considered safe. It is inefficient, doesn't support any encryption, and has been exploited in the past. A recommended best practice is to explicitly disable it in your network. There are multiple ways of doing this, and covering every possible way is beyond the scope of this article.

Remember, if there are still a lot of legacy clients (such as old printers, Windows XP computers, or other devices running really old firmware) in your network, don't just disable SMB 1.0 support straightaway, as it could cause problems and potential productivity loss. First, you need to enable audit logging and then monitor the logs to determine the devices that are still using SMB 1.0. By determining the number of such old clients, you can assess the overall impact of disabling SMB 1.0 support in your network. To enable audit logging, run the following PowerShell command on the file server where all the SMB shares are hosted:

Set-SmbServerConfiguration -AuditSmb1Access $True -Force

After running this command, wait for a few days, and then check the access logs in the Event Viewer. The location of the log file is:

Applications and Services Logs > Microsoft > Windows > SMBServer > Audit

The following screenshot shows what an SMB 1.0 access event log looks like:

Checking the SMB 1.0 access audit logs in the Event Viewer

Checking the SMB 1.0 access audit logs in the Event Viewer

Such events will be logged with Event ID: 3000 and Source: SMBServer. You can note the client IP address and identify such devices, or you could use the following PowerShell command to see these events:

Get-WinEvent -LogName Microsoft-Windows-SMBServer/Audit | Out-GridView

Once you identify such devices, you can then update them or take certain measures to properly isolate them from the rest of the network to mitigate the security risk.

When you are ready to disable SMB 1.0 support, follow these steps:

To determine whether SMB 1.0 is enabled, use the following command:

Get-SmbServerConfiguration | select EnableSMB1Protocol
Checking whether the SMB 1.0 protocol is enabled using PowerShell

Checking whether the SMB 1.0 protocol is enabled using PowerShell

If you see True under the EnableSMB1Protocol column, it means your server is still supporting SMB 1.0.

To disable SMB 1.0 support on your server, run the following command:

Set-SmbServerConfiguration -EnableSMB1Protocol $False -Force
Disabling SMB 1.0 support using PowerShell

Disabling SMB 1.0 support using PowerShell

If your network is running the latest devices completely and there is no legacy client, you can disable SMB 2.0 support and force every device to use the SMB 3.0 dialect, which is more secure. To disable SMB 2.0, use the following command:

Set-SmbServerConfiguration -EnableSMB2Protocol $False -Force

To learn which SMB dialect most client computers are using in your network from the file server's perspective, you can use the following command on the file server:

Get-SmbSession | select ClientComputerName, ClientUserName, NumOpens, Dialect

Here, the Get-SmbSession command shows the SMB dialect used by various clients to communicate with SMB shares hosted by the LanmanServer service on the file server.

Viewing the SMB sessions to show the SMB dialect used by clients on the file server

Viewing the SMB sessions to show the SMB dialect used by clients on the file server

The screenshot above shows that most of the client devices in my network are using SMB 3.1.1, except for one client that is still using SMB 3.0.2 (marked with orange). This is because it is a Windows Server 2012 R2 device, and we still have to update it to Server 2019.

Likewise, you could use the following command on a client computer to know which SMB dialect it is using to access SMB shares:

Get-SmbConnection
Viewing the SMB connections to show the SMB dialect used by a particular client

Viewing the SMB connections to show the SMB dialect used by a particular client

Here, the Get-SmbConnection command shows the SMB dialect used to access remote SMB shares utilizing the LanmanWorkstation service on your local computer.

Restricting SMB traffic to a trusted network

To restrict the SMB traffic only to the trusted network, you could use various techniques, such as implementing VLANs, utilizing the IPsec policy, or simply creating restrictive firewall rules.

You can configure the Windows Defender Firewall on every system to enable File and Printer Sharing for Private or Domain profiles only. To do so, use the following command in PowerShell:

Set-NetFirewallRule -DisplayGroup "File And Printer Sharing" -Enabled True -Profile Private

Never enable this rule for the Public profile. To do this using the UI, open the Windows Defender Firewall and then click the Allow an app or feature through Windows Defender Firewall link in the left corner. Now check the box for File and Printer Sharing under Domain or Public only. Do not check the box under Public. See the following screenshot for reference:

Allowing file and printer sharing through Windows Defender Firewall

Allowing file and printer sharing through Windows Defender Firewall

Of course, you could also use Windows Defender Firewall with Advanced Security to define more restrictive and granular rules for file and printer sharing.

One more thing that I want to emphasize is to explicitly disable the TCP 445 and 139 ports in your perimeter firewall to be absolutely sure that SMB traffic never leaves your network. Leaving these ports exposed to the Internet poses a great security risk.

Enabling security features in SMB 3.x

Microsoft made some major changes in SMB 3.0 to improve security and performance. It is highly recommended to always run the latest SMB dialect (SMB 3.1.1 is the latest at the time of writing) whenever possible. SMB 3.x offers the following security features that are worth mentioning:

  • SMB encryption
  • SMB signing
  • SMB pre-authentication integrity
  • SMB authentication rate limiter (in the upcoming Server version only)

SMB encryption

End-to-end encryption can either be enabled on each SMB share individually or on the entire file server. SMB encryption is controlled by the EncryptData property of both SMB servers. To enable encryption on a particular share (e.g., Projects), use the following PowerShell command:

Set-SmbShare -Name Projects$ -EncryptData $True -Force

To enable encryption on the entire file server, use the following PowerShell command:

Set-SmbServerConfiguration –EncryptData $True -Force

Once you enable encryption on an SMB share, clients that do not support the encryption will not be able to access it.

Enabling SMB encryption on an entire file server using PowerShell

Enabling SMB encryption on an entire file server using PowerShell

Now, there could be situations (such as during the transitioning period while upgrading the old clients) when you have to enable encryption on SMB shares, but still want to allow old clients that do not yet support encryption. In this situation, you can run the following PowerShell command:

Set-SmbServerConfiguration -RejectUnencryptedAccess $False -Force

This is not recommended, as it defeats the purpose of enabling encryption in the first place, but it is helpful for allowing legacy clients until they can be fully upgraded.

SMB protocol signing

The SMB signing or security signature is a security feature of the SMB protocol that prevents anyone from tampering with the data during SMB communication. This is achieved by adding the hash of the entire message inside the signature field of the SMB header. If someone changes the data in transit, the hash will not match, and SMB will know that the data has been tampered with. While SMB signing has been there since SMB 1.0, it has evolved over time to meet modern security needs. SMB 1.0 supported MD5-based message signing, and SMB 3.1.1 supports AES CMAC-based signing.

Note that signing is not the same as encryption. While encryption makes it hard for an eavesdropper to read the data on wire, signing is responsible for data integrity validation. SMB signing is controlled by the RequireSecuritySignature property of both the SMB server and client. To enable the SMB signing on the server, use the following command:

Set-SmbServerConfiguration -RequireSecuritySignature $True -Force

There is another property named EnableSecuritySignature, which is only used with SMB 1.0. With SMB 2.0 or higher, this setting is ignored and does not have any effect. You can also control SMB signing in your domain environment using group policy for both the SMB server and clients.

Enabling SMB signing using a group policy object

Enabling SMB signing using a group policy object

The following table shows when the signing will happen and when it will not during SMB communication:

SMB Server
RequireSecuritySignature = 0
SMB Server
RequireSecuritySignature = 1
SMB Client
RequireSecuritySignature = 0
Not signedSigned
SMB Client
RequireSecuritySignature = 1
SignedSigned

You can see that SMB signing will not happen only when both the SMB client and the SMB server have EnableSecuritySignature set to False. In all other cases, signing will happen.

SMB pre-authentication integrity

Pre-authentication integrity was introduced to supplement the SMB signing. The problem with SMB signing was that it could protect data integrity after the SMB session was set up. However, if someone becomes a middleman during the initial SMB negotiation stage, they could still tamper with the data. Pre-authentication integrity solved this problem. It is a mandatory security feature introduced in SMB 3.1.1 using SHA-512 hash to improve data integrity validation, even during the initial connection establishment stage. It protects against protocol downgrade attacks where an attacker could downgrade an SMB 3.1.1 encrypted connection to an SMB 2.x protocol to result in an unencrypted connection. As a mandatory feature, it is enabled by default with SMB 3.1.1.

All the SMB server security features discussed above can be viewed using the following PowerShell command:

Get-SmbServerConfiguration | select EnableSMB1Protocol, EncryptData, RejectUnencryptedAccess, EnableSecuritySignature, RequireSecuritySignature
Viewing selected security features of the SMB server configuration

Viewing selected security features of the SMB server configuration

All of these features accept a Boolean value. So, to enable or disable any feature, you just have to provide the parameter name along with the Set-SmbServerConfiguration cmdlet and then type $true or $false to toggle the feature setting. The following PowerShell command disables SMB 1.0 and enables all SMB security polices at the same time on the file server:

Set-SmbServerConfiguration -EnableSMB1Protocol $false -EncryptData $true -EnableSecuritySignature $true -RequireSecuritySignature $true -Force
Disabling SMB 1.0 and enabling SMB encryption, signing using a single PowerShell command

Disabling SMB 1.0 and enabling SMB encryption, signing using a single PowerShell command

SMB authentication rate limiter (available with Server vNext preview only)

Rainbow table attacks or brute force attacks are not uncommon on the Internet. It is a really bad idea to expose the SMB ports on the Internet, since SMB does not have any built-in features to slow down such attacks. With modern computing power, a normal PC today can try thousands of passwords per second.

With the upcoming version, Windows Server vNext, which is still under preview, Microsoft introduced a new SMB feature to slow down such brute force attacks. This feature is known as the SMB authentication rate limiter (or SMB rate limiter for short), and it can be controlled by the -InvalidAuthenticationDelayTimeInMs parameter of the Set-SmbServerConfiguration cmdlet. To view the current setting, use the following command:

Get-SmbServerConfiguration | select InvalidAuthenticationDelayTimeInMs

The default invalid authentication delay time is 2 seconds (2000 milliseconds), but you can set it up to 10,000 milliseconds (10 seconds). Imagine how much difference a delay of 10 seconds could make to slow down brute force attacks. To set the rate limiter using PowerShell, use the following command:

Set-SmbServerConfiguration -InvalidAuthenticationDelayTimeInMs 10000 -Force
Setting the invalid authentication delay time in Server vNext using PowerShell

Setting the invalid authentication delay time in Server vNext using PowerShell

This command sets the invalid authentication delay to 10 seconds, which is the maximum supported delay. Setting the value to 0 disables the feature. Remember, this feature is only available with Windows Server vNext Insider Preview (build 25075 or higher).

Conclusion ^

I hope that by reading this article, you will have a good understanding of how the SMB protocol works and the different ways to protect SMB communication in your network. This is not a comprehensive security checklist, but it gives a fair enough idea about a few SMB security measures.

In my next post, I will clear up some confusion about the SMB port number.

0 Comments

Leave a reply

Your email address will not be published.

*

© 4sysops 2006 - 2022

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account