How to Close the Dangerous Ports 135, 137, 138, 139, and 445 on Windows Servers

Ports 135, 137, 138, 139, and 445 are the five most heavily scanned ports on Windows servers, and the main entry points of large-scale ransomware incidents like WannaCry and EternalBlue all live here. An open port 445 on the public internet usually survives less than a day against automated scanners, and inside an intranet these ports are the standard springboard for lateral movement. Closing all five requires no third-party tools — the built-in Windows firewall is enough. This post first explains what service each port maps to and why it is dangerous, then gives two ways to block them (GUI and command line), and finally covers how to verify the block works and what dependencies to check beforehand.

Note: Windows cannot be containerized for a live run, so the steps and command syntax in this post come from Microsoft’s official documentation and the original article’s production operations records; they were not re-tested on a live machine. Run through them on a test machine before executing.

What These Five Ports Are

Before closing ports, know what you are closing. The five ports belong to two mechanisms: 135 is the entry point for RPC, 137/138/139 are the NetBIOS family, and 445 carries SMB directly.

Port	Protocol	Service	Why it’s dangerous
135	TCP	RPC Endpoint Mapper	The remote procedure call entry point; WMI/DCOM depend on it; exploited for lateral movement and remote code execution
137	UDP	NetBIOS Name Service	Name resolution; exposes hostname/domain info; a staple of intranet reconnaissance
138	UDP	NetBIOS Datagram Service	Datagram service; works with 137 for intranet broadcast discovery
139	TCP	NetBIOS Session Service	The early SMB file-sharing channel; the predecessor of 445
445	TCP	SMB over TCP	The core Windows file-sharing port; the attack surface of EternalBlue/WannaCry; exposing 445 to the internet = waiting to be scanned

135 deserves an extra sentence: it carries no business traffic itself — it only provides RPC endpoint mapping. A client first connects to 135 and asks “what is the real port of the service I want to call,” then uses the dynamic port it receives (default range 49152-65535 after Windows Vista/Server 2008) to make the actual call. WMI remote execution, some remote-control tools, and lateral-movement tooling all take this route. So “blocking 445 alone is enough” is a common misconception — with 135 open, the remote-call channel is still there.

The NetBIOS trio (137/138/139) is the legacy protocol stack for file sharing before Windows 2000; in today’s LANs it is little more than historical baggage: it exposes hostnames and workgroup info and responds to broadcast probes, with no legitimate use beyond handing attackers intelligence. Scenarios where legacy devices truly require NetBIOS name resolution are rare these days.

In one sentence: if the server hosts no intranet file sharing and no domain environment services, closing all five ports has no side effects.

GUI Steps

For a single machine or a quick fix, the GUI is fastest. The example uses Windows Server 2016/2019/2022 (menu locations differ slightly in older versions, but the logic is the same):

Press win+R and run wf.msc to open “Windows Defender Firewall with Advanced Security” (also reachable via Control Panel → System and Security → Windows Defender Firewall → Advanced Settings);
Once open, first confirm the firewall state on the right — all three profiles (domain, private, public) should be enabled; rules have no effect while the firewall is off;
In the left pane select “Inbound Rules” → click “New Rule” on the right;
For rule type choose “Port” → Next;
Choose TCP, and in “Specific local ports” enter 135,139,445 (comma-separated);
For action choose “Block the connection” → Next;
Keep profiles at the default (domain, private, public all checked) → Next;
Name it Block-NetBIOS-SMB-TCP (easy to manage via scripts later), description optional, then Finish;
Repeat steps 3-8 to create a second UDP rule with ports 137,138, named Block-NetBIOS-Name-UDP.

Both rules take effect immediately, no restart needed. The new block rules appear in the Inbound Rules list sorted by name; the absence of a green check icon means the rule is enabled.

Command Line (netsh / PowerShell, Scriptable)

For batch deployment or automation scripts, the command line is the right path. Two tools, pick either: netsh is available on all supported versions, and PowerShell’s NetSecurity module (built in since Windows Server 2012) reads better.

netsh way (elevated CMD):

:: Block TCP ports
netsh advfirewall firewall add rule name="Block-NetBIOS-SMB-TCP" ^
  dir=in action=block protocol=TCP localport=135,139,445

:: Block UDP ports
netsh advfirewall firewall add rule name="Block-NetBIOS-Name-UDP" ^
  dir=in action=block protocol=UDP localport=137,138

PowerShell way (administrator):

New-NetFirewallRule -DisplayName "Block-NetBIOS-SMB-TCP" `
  -Direction Inbound -Action Block -Protocol TCP -LocalPort 135,139,445

New-NetFirewallRule -DisplayName "Block-NetBIOS-Name-UDP" `
  -Direction Inbound -Action Block -Protocol UDP -LocalPort 137,138

The rules created by the two toolsets are equivalent; both show up in wf.msc‘s Inbound Rules list and can be managed interchangeably. If one was created by mistake or the business changes and you need to roll back, delete the rule by name:

1 2	netsh advfirewall firewall delete rule name="Block-NetBIOS-SMB-TCP" netsh advfirewall firewall delete rule name="Block-NetBIOS-Name-UDP"

Verifying the Block Actually Works

Verification after blocking is a step you cannot skip — scenarios where firewall rules silently fail (profile disabled, rule overridden by Group Policy, wrong direction) are more common than you’d think. Verification has three layers.

Layer one, check the rule state on the local machine:

1	netsh advfirewall firewall show rule name="Block-NetBIOS-SMB-TCP"

Normal output should include Enabled: Yes, Action: Block, and LocalPort: 135, 139, 445, with the profile hit across all four configured profiles (domain/private/public, depending on version).

Layer two, test connectivity from another machine. PowerShell’s Test-NetConnection is the most convenient:

1
2
3

# Run on another machine
Test-NetConnection -ComputerName 192.168.1.100 -Port 445
Test-NetConnection -ComputerName 192.168.1.100 -Port 135

TcpTestSucceeded should return False for the blocked ports. Keep a control: test a port that is definitely not blocked (say an open 3389) and confirm it returns True — that proves the test itself works, otherwise the False could simply mean the network is unreachable.

Layer three, UDP ports are their own case. Test-NetConnection only supports TCP, so there is no way to verify 137/138-style UDP blocks this way; the practical approach is confirming the rule state (layer one) plus confirming no response from the peer with a UDP scan via PortQry or nmap.

One more reminder: the firewall blocks connections, not listeners. After the block, netstat -ano | findstr ":445" on the local machine still shows the listening entry — that is normal. The service is still there; outside connections just can’t get in.

The Root Fix: Stop the Ports from Listening (Optional Hardening)

A firewall blocks; retiring the services means nothing listens. Walking on both legs is sturdier:

Disable NetBIOS over TCP/IP: network adapter properties → IPv4 → Advanced → WINS tab → select “Disable NetBIOS over TCP/IP”. Then 137/138/139 stop listening entirely — cleaner than firewall blocking. In a domain environment, confirm first that no legacy clients depend on NetBIOS name resolution.
Disable the Server service (LanmanServer): on servers that do no file sharing, disable the Server service in services.msc, and the 445 listener disappears with it. Domain controllers and machines that must provide shares cannot do this — a DC’s SYSVOL/NETLOGON shares depend on it.
135 cannot be closed this way: RPC is core system infrastructure; forcibly disabling the related services breaks large swaths of system functionality. 135 can only be restricted by source through the firewall.

Caveats

The firewall must be on: with the firewall off, rules have no effect and blocking equals not blocking. Check with netsh advfirewall show allprofiles state.
Check business dependencies first: intranet file sharing (SMB), printer sharing, and some domain controller services (AD replication, Group Policy distribution) use 135/139/445. Assess the impact before closing everything — domain controllers in a domain environment usually need to keep 135/445; block only on member servers.
Keep patching: closing ports is only a mitigation; the system patches for SMB vulnerabilities (the MS17-010 family) still need to go in on schedule — if a block rule is accidentally deleted, the patch is the last line of defense.
Outbound direction: the rules above only block inbound (dir=in), not outbound. Protecting against intranet lateral movement requires adding rules on every member server, not just the edge device.
Group Policy batch deployment: in a domain environment, put the firewall rules into Group Policy (GPO) and push them to all servers uniformly to avoid missed per-machine logins; locally created rules and GPO-delivered rules stack, so check both places when troubleshooting.

Closing ports with the Windows firewall is technically trivial: eight GUI steps or two netsh commands. The real work is checking dependencies beforehand — domain controllers, shares, printing; any one mistakenly blocked is a production incident — and verifying afterward — a rule being created is not the same as traffic being blocked. Commands can be scripted; the verification step always needs a human in the loop.