Windows File Sharing with SMB: Port 445, 139, 138, and 137 Explained

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.

Quick overview of SMB

SMB is a client‑server protocol that enables devices to share files, printers, named pipes, and other resources over a network. It underpins:

• Windows file sharing
• Remote administration
• Active Directory operations
• Distributed File System (DFS)
• Modern hybrid identity and cloud file access

SMB over TCP/IP vs. SMB over NetBIOS

SMB originally depended on NetBIOS over TCP/IP, using ports 137–139.
Since Windows 2000, SMB can run directly over TCP using Port 445, eliminating the NetBIOS requirement.

Why these ports are still relevant

Legacy systems, misconfigurations, and hybrid networks mean that all four ports may still appear in enterprise environments, sometimes unintentionally.

How does file sharing via the SMB protocol work?

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.

The set of network traffic packets that defines a specific version of the protocol is called a dialect. The Common Internet File System (CIFS) Protocol is one such dialect and is very old.

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!

SMB protocol dialects

Dialect / Version	Performance	Security	Platform Support	Key Features
SMB 1.0	Poor — very chatty, high overhead, slow on WAN.	Very low — insecure, deprecated.	Legacy Windows, older NAS devices.	Basic file/print sharing; uses NetBEUI & IPE; no encryption.
Samba	Good — varies by implementation.	Moderate to high depending on SMB version.	Linux, Unix, macOS; integrates with AD.	Open‑source SMB server; cross‑platform interoperability.
CIFS	Moderate — more efficient than SMB1 but outdated.	Low — inherits SMB1 weaknesses.	Cross‑platform; common on NAS devices.	Transport‑independent file/print sharing; NAS standard.
NQ	High — optimized portable implementation.	High — supports SMB 3.1.1 and modern encryption.	Embedded devices, storage appliances, Java environments.	Portable SMB stack; supports latest SMB dialects.
SMB 2.0	High — reduced commands, pipelining, larger packet sizes.	Improved — more secure than SMB1.	Windows Vista/Server 2008+.	Symbolic links; durable handles; reduced chattiness.
Tuxera Fusion File Share	Very high — kernel/user‑space optimized performance.	High — full SMB 3.1.1 support with encryption.	Cross‑platform, embedded, cloud appliances.	RDMA/SMB Direct; Multichannel; scale‑out; compression.
Likewise	High — OEM/storage appliance optimized.	Moderate to high depending on SMB dialect.	Linux/Unix NAS, gateways, cloud storage.	Identity‑aware file access; AD integration.
SMB 2.1	Higher — MTU & locking improvements.	Moderate — incremental security increase.	Windows 7/Server 2008 R2.	Better caching; opportunistic locking.
SMB 3.0	Very high — RDMA, multichannel, failover.	High — AES‑based signing & encryption.	Windows 8/Server 2012+.	Transparent Failover; SMB Direct; Multichannel.
SMB 3.1.x (3.0.2 & 3.1.1)	Very high — latest modern optimizations.	Very high — AES‑128 CCM & GCM; secure negotiation.	Windows 8.1/Server 2012 R2 → Windows 10/Server 2016+.	Mandatory secure negotiation; SMB1 disabled; modern encryption.

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.

What ports are used by the SMB protocol?

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.

Port 445

In modern and supported versions of Windows, File and Printer Sharing services use TCP port 445 for direct TCP/IP communications. When you need to make adjustments (carefully) to firewall setups, either on the client or a router, TCP port 445 needs to be open to be able to accept incoming file share requests from an SMB client. Enabling this feature in Windows will automatically allow this port in the local Windows (Defender) firewall software.

Port 139

In the earliest versions of SMB 1.0, three ports were used in tandem to allow client/server SMB file-sharing activity using NetBIOS over TCP/IP (NBT). Port 139 was used for session services.

Port 138

As a part of the original SMB 1.0, UDP port 138 was used for datagram services.

Port 137

And finally, with the initial implementation of SMB 1.0, TCP/UDP port 137 was used for name services.

Relationship between ports 139 and 445

Let me explain and clarify the relationship between ports 139 and 445 regarding SMB file sharing. I previously stated that SMB (Server Message Block) is a network protocol used for file/printer sharing. It is very well known and widely known throughout the file-sharing universe.

Port 139 and Port 445 are network ports used with the SMB protocol.

• Port 139 – This is primarily used by the NetBIOS (Network Basic Input/Output System) session service. NetBIOS over TCP/IP (NetBT) utilizes this port to communicate.
• Port 445 – This is used by the SMB protocol over TCP/IP, otherwise known as “Direct Host SMB”. This is used without the need for the (very) legacy NetBIOS transport. This was introduced way back in Windows 2000 and, to this day, is the default method used in Windows file sharing.

The ‘relationship’ – they are both used for SMB file sharing, but the more modern TCP/IP port, 445, is the default and recommended for new installations of Windows (client and server), whereas port 139 requires NetBIOS to function. This is only used to support backward compatibility with older applications – it would behoove you to remove this legacy protocol infrastructure from your networks.

You can use this single PowerShell command to determine if either of these ports is actively being used (listening).

Get-NetTCPConnection -LocalPort 139,445 -ea 0 | select Local*, Remote*, State, @{n="ProcessName";e={(Get-Process -Id $_.OwningProcess).ProcessName}} | ft -Auto

Using PowerShell’s ‘Get-NetTCPConnection’ cmdlet to find listening ports related to SMB (Image Credit: Petri.com/Michael Reinders)

Port 445 vs ports 139, 138, and 137 – Quick comparison table

Here’s a clear comparison table to illustrate the differences between legacy and more modern ports.

Port	Transport	Service/Name	SMB Role	NetBIOS Dependency	Typical Uses	Common Exposure/Risk	Notes
445	TCP	SMB over TCP	Primary port for modern SMB (SMBv2/SMBv3); direct hosting over TCP/IP	No	File & printer sharing, domain/AD operations, IPC	High-value target on the internet; should be blocked externally; segment internally	Introduced with Windows 2000; required for modern Windows file sharing and many AD features
139	TCP	NetBIOS Session Service	SMB over NetBIOS/NetBT session transport (legacy)	Yes	Legacy file & printer sharing; older client compatibility	Should be disabled where possible; block externally	Used when NetBIOS over TCP/IP is enabled and 445 is unavailable or not used
138	UDP	NetBIOS Datagram Service	Connectionless datagrams for NetBIOS (browsing, announcements)	Yes	Network neighborhood browsing, printer announcements (legacy)	Unnecessary in modern domains; block externally	Supports broadcasts; noisy on flat networks; not used by SMB direct hosting
137	UDP	NetBIOS Name Service (NBNS)	Name registration and resolution for NetBIOS names	Yes	Legacy name resolution, WINS	Block externally; avoid in favor of DNS	Pre-DNS era mechanism; persists only for backward compatibility

Port 445 vs ports 139, 138, and 137 – Quick comparison table

Quick guidance:

• Prefer SMB over TCP (Port 445) only; disable NetBIOS over TCP/IP where feasible to eliminate 137/138/139 chatter.
• Block all four ports at the internet perimeter; allow 445 internally only where needed, restrict with host firewalls, and require authentication/signing.
• If legacy systems require NetBIOS, scope 139/138/137 to specific VLANs and phase out over time.

How to enable and disable SMB ports on Windows

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.

With the graphical user interface

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 the 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.

That’s it!

With PowerShell

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.

How to check the status of SMB ports on your PC

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.

6 ways to keep SMB ports secure

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.

How to secure port 445

Let me provide you with an actionable high-level checklist you can follow to harden port 445 in your network.

1. Block port 445 at the network perimeter
Never allow SMB traffic from and to the public internet. Configure edge firewalls to drop inbound and outbound TCP 445. Nearly all ransomware campaigns and wormable exploits target SMB exposure.

2. Restrict SMB access internally using firewalls
Use Windows Defender Firewall or your network firewall to allow TCP 445 only from trusted subnets (e.g., domain controllers → file servers, etc.).

3. Enforce SMB signing and enable SMB encryption where supported
SMB signing prevents tampering and MITM attacks, while SMB encryption protects data in transit. Configure these settings via Group Policy to ensure security and consistency across the domain. SMB 3.x encryption is lightweight and supported on all modern Windows versions.

4. Disable legacy SMB versions (SMBv1)
Disable and remove SMBv1 as soon as possible. It is insecure and vulnerable to numerous exploits. Use PowerShell or GPO to confirm SMBv1 is disabled on all servers and endpoints.

5. Disable NetBIOS over TCP/IP (if not needed)
Turning off NetBIOS removes reliance on Ports 137–139 and reduces network broadcast noise. This tightens the SMB attack surface and eliminates legacy security risks.

6. Keep SMB servers patched and monitored
Apply Windows security patches promptly—many major SMB vulnerabilities have been wormable. Monitor for suspicious SMB activity using tools like Windows Defender, SIEM alerts, and network traffic analytics.

How to secure specific exploits and high-profile vulnerabilities

Modern threats targeting SMB and Port 445 continue to be some of the most damaging vectors in Windows environments. Over the last decade, several high‑profile vulnerabilities and attack techniques have demonstrated how quickly unpatched systems can lead to catastrophic and costly compromise.

Table: Major security threats involving SMB and Port 445

Threat / Attack	Type	Key Impact	How It Works	SMB/Port 445 Relevance
EternalBlue (MS17‑010)	Remote Code Execution (RCE) exploit	Enables unauthenticated takeover of Windows systems; rapid worm‑like propagation	Exploits CVE‑2017‑0144 in SMBv1 via crafted packets that trigger memory corruption, allowing arbitrary code execution	Directly abuses SMBv1 traffic over Port 445 to execute code and move laterally
NotPetya	Wiper malware using SMB exploits	Global destructive impact; billions in damages; spreads rapidly inside networks	Uses EternalBlue and EternalRomance for SMB RCE, plus credential theft (Mimikatz) for privileged lateral movement	Relies on SMBv1 exploitation through Port 445 to self‑propagate
SMBGhost (CVE‑2020‑0796)	Wormable SMBv3 RCE vulnerability	Allows full compromise of Windows 10/Server 1903–1909 systems without authentication	Exploits an integer overflow in SMB3 compression handling, enabling remote code execution	Attack traffic delivered over Port 445; Microsoft recommended blocking 445 as mitigation
SMB Relay Attacks	Authentication relay (credential attack)	Unauthorized access, command execution, and lateral movement using victim credentials	Captures NTLM authentication attempts and relays them to another SMB server without cracking hashes	SMB signing weaknesses allow relaying to Port 445 endpoints to impersonate users
Pass‑the‑Hash (PtH)	Credential replay / lateral movement	Lets attackers authenticate as a user without the password; major post‑compromise technique	Uses stolen NTLM password hashes to authenticate across systems, bypassing password requirements	SMB accepts NTLM hashes for authentication over Port 445, making it a common vector

Troubleshooting and diagnostic checklist

Follow these general steps to assist you in creating your own checklists when SMB access is not working as expected. This is also helpful as a security lockdown of sorts for your security and compliance team.

Check	Details
Verify Basic Port 445 Connectivity	Use this PowerShell command to verify connectivity: Test-NetConnection -ComputerName FileServerName -Port 445
Test SMB Share Accessibility	You can use – Test-Path \FileServerName\Share to test connectivity to a share on your network
Inspect Active SMB Sessions, Connections, and Open Files	PowerShell commands: Get-SmbConnection – verifies existing SMB sessions Get-SMBSession – checks active SMB sessions on the server Get-SmbOpenFile – shows files opened via SMB
Check Firewalls, Network Discovery, DNS, and SMB Configurations	Port 445 problems often stem from fundamental network failures. Admins should verify: Windows Defender Firewall rules, if the product is in use DNS resolution for server names (FQDN) Network Discovery settings in Windows Network Control Panel Correct and secure SMB protocols in use (SMBv2/SMBv3)
Diagnose Authentication Failures to Domain Controllers (DCs)	Verify Port 445 connectivity Investigate possible Netlogon connectivity errors/events in Event Viewer

Conclusion

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.