The SMB port number is TCP 445. If you've heard people saying the port number is 139, they could be partially correct. Let’s understand the SMB ports 445, 139, 138, and 137 in detail.
Latest posts by Surender Kumar (see all)

Admins need to know the SMB port number when it comes to setting up firewalls in Windows networks. The earlier version of SMB (SMB 1.0) was originally designed to operate on NetBIOS over TCP/IP (NBT), which uses port TCP 139 for session services, port TCP/UDP 137 for name services, and port UDP 138 for datagram services. (Read my previous comprehensive overview of the SMB protocol.

By default, NBT is installed and enabled in Windows for backwards compatibility, but it is known for exposing file shares and other information to everyone on the network. While it is not a big problem in local networks, it could be a security risk if exposed to the Internet. Man-in-the-middle (MITM) and NetBIOS name service (NBNS) spoofing attacks are common with NTB-enabled networks—particularly if the related ports are not properly safeguarded.

How are SMB and NBT related?

NetBIOS over TCP/IP (NBT) is a completely independent service from SMB, and it doesn't depend on SMB for anything. The SMB protocol, on the other hand, may rely on NetBIOS to communicate with old devices that do not support the direct hosting of SMB over TCP/IP.

Therefore, the SMB protocol relies on port 139 while operating over NBT. However, normally, for direct SMB over TCP/IP, the SMB port number is TCP 445. By the way, if both NetBIOS over TCP/IP and directly hosted SMB over TCP/IP are available (that is, if ports 445 and 139 are both listening), Windows tries both options at the same time. Whichever responds first is used for communication.

The SMB 2.0 that was introduced with Windows Vista and Windows Server 2008 can operate solely on TCP port 445, and you can safely disable NBT for improved security and reduced network overhead caused by NetBIOS broadcasts.

To see the status of ports 139 and 445 in your system, use the following PowerShell command:

Get-NetTCPConnection -LocalPort 139,445 -ea 0 | select Local*, Remote*, State, @{n="ProcessName";e={(Get-Process -Id $_.OwningProcess).ProcessName}} | ft -Auto
Viewing the status of ports TCP 139 and 445 using PowerShell

Viewing the status of ports TCP 139 and 445 using PowerShell

The above screenshot shows that both ports TCP 139 and 445 are in the listening state by default.

If you're interested in disabling the NBT, it needs to be done on each network interface individually. See the following screenshot for disabling it using the GUI on each network adapter:

Disabling NBT on a network interface using GUI

Disabling NBT on a network interface using GUI

Disabling NBT using the GUI becomes tedious if you've got more than one network adapter. The following PowerShell command can help you disable it on all network interfaces at once:

$adapters = (Get-WmiObject Win32_NetworkAdapterConfiguration | where {$_.IPEnabled -eq $true})

Foreach ($adapter in $adapters){
  $adapter.SetTcpipNetbios(2)
}

where the value "2" with the SetTcpipNetbios method is used to disable NBT. By the way, the value "1" means enable NBT, and "0" means configure NBT by DHCP.

Disabling NetBios on all network interfaces at once using PowerShell

Disabling NetBios on all network interfaces at once using PowerShell

After disabling it, if you view the status of TCP ports, you will notice that port 139 is no longer listening on your system.

Subscribe to 4sysops newsletter!

Confirming that TCP port 139 is no longer listening

Confirming that TCP port 139 is no longer listening

If you do not have any old clients in your network, it is a good idea to block other ports, except for TCP 445 in the Windows Defender firewall.

avatar
3 Comments
  1. PowerMe! 3 months ago

    Very nice article! The netbios ports (137-139) are scary I manually turn them off on firewall. But this is cool.

    Just to share my favorite gcim (or Get-CimInstance) over Get-WmiObject. Its been a few years I am away from powershell but I remember there was a recommendation on using gcim over get-wmiobject. I think it was a security concern related to get-wmiobject (TCP 135). Here is a nice short artcile: https://devblogs.microsoft.com/scripting/using-the-powershell-cim-cmdlets-for-fun-and-profit/. Gcim also formats outputs nicely, e.g., try $adapters = (Gcim Win32_NetworkAdapterConfiguration | where {$_.IPEnabled -ne $true}) ; $adapters, I set it to “-ne ” as you probably have nbt turned off.

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