- Kubernetes CoreDNS - Mon, Dec 4 2023
- Update container images with Copa - Mon, Nov 27 2023
- Deploying stateful applications with Kubernetes StatefulSets - Wed, Nov 1 2023
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
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 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
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
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.
Read the latest IT news and community updates!
Join our IT community and read articles without ads!
Do you want to write for 4sysops? We are looking for new authors.
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.
Thank you @ratan.
I agree on the use of Get-CimInstance cmdlet over Get-WmiObject. But unfortunately gcim does not offer SetTcpipNetbios method that I used to disable NetBIOS so I had to fallback to gwmi cmdlet instead.
Ah makes sense. You are right that is not available with ciminstance!
I was reading, it appears they have removed get-wmiobject in powershell-6: https://docs.microsoft.com/en-us/powershell/scripting/whats-new/differences-from-windows-powershell?view=powershell-7.2#wmi-v1-cmdlets
I found a reference that used cim to achieve this, doing a Query – thought might be of interest:
https://powershell.one/wmi/root/cimv2/win32_networkadapterconfiguration-SetTcpipNetbios
win32_networkadapterconfiguration seems to be an interesting class for network config tweaking.
On englist in this article it is too easy understand about smb than on my own russian language, because no one understand about that
😀
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
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.
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.
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.