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){

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.

  1. Avatar
    PowerMe! (Rank 3) 1 year 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: 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.

  2. Avatar
    Oleg 11 months ago

    On englist in this article it is too easy understand about smb than on my own russian language, because no one understand about that

  3. Avatar
    sale 9 months ago

    Nice article
    we have network shared resources (folders and printers) using \\PCNAME . Is it okay if we disable NetBIOS over TCP/IP? I think although it’s SMB, but at the first step system uses NetBIOS to find the IP behind PCNAME

    • Avatar Author

      Thank you for the comment. If all of your network devices support direct SMB over TCP/IP, you can safely disable NetBIOS. Its there for backwards compatibility.

      • Avatar
        sale 9 months ago

        So, how source computer resolves PCNAME (not FQDN format ) without NetBIOS or LLMNR? The only remained way is DNS.
        As I know, source computer uses DNS and if it fails it goes for NetBIOS or LLMNR.

        *NetBIOS has a backup named LLMNR which is still active when we disable NetBIOS.

        • Avatar Author

          My bad, I forgot to mention you need to have dns server configured before disabling these services.
          You’re right, system falls back to llmnr and netbios when dns resolution fails. But that’s why system allows you to configure two or more dns servers to act as backup when primary one fails. You don’t have to rely on these vulnerable protocols if your devices already support dns.

Leave a reply

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2023


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


Log in with your credentials


Forgot your details?

Create Account