How to close Port 135 (UDP/TCP)

Key Points
Introduction: Explains why leaving TCP/UDP port 135 open is a risk, what services it exposes (RPC/DCOM), and when you should block it.
Quick Setup: Provides guidance on how to detect “Inbound connection in port 135 (TCP/UDP) is not blocked in Windows firewall” as a misconfiguration using Vulnerability Manager Plus, and outlines the exact Windows Firewall steps to create inbound rules that block TCP 135 and UDP 135.
Frequently Asked Questions: Answers common questions about port 135, DCOM/RPC exposure, operational impact, and validation after blocking.

Introduction

TCP/UDP port 135 is commonly associated with Windows RPC Endpoint Mapper and DCOM. In many environments, leaving port 135 reachable from untrusted networks is unnecessary and increases exposure. When this port is open, it can help attackers discover RPC/DCOM services on a machine, which can support reconnaissance and enable lateral movement planning.

This risk becomes higher on roaming endpoints (laptops and remote systems) that connect to less trusted networks, where inbound connectivity may be easier to probe. If your environment does not require RPC/DCOM access to endpoints, it’s recommended to block inbound TCP 135 and UDP 135 at the host firewall to reduce the attack surface.

If you do rely on RPC/DCOM for approved management workflows, avoid leaving port 135 open to all. Instead, limit access to trusted management servers or specific internal subnets, and keep the port blocked on devices that do not need it.

You can detect this misconfiguration of leaving port 135 open using Vulnerability Manager Plus. This comes under the category of Windows Firewall and has a Moderate severity.

Spot port 135 and similar firewall gaps quickly using Vulnerability Manager Plus.

Spot Now

What is NetBIOS Name Service on UDP port 137?

NetBIOS Name Service, often referred to as NBNS, allows devices to register and resolve NetBIOS names to IP addresses, which was commonly used for older Windows networking and local network browsing. In practice, port 137 supports name query and name registration traffic, typically within a local subnet, and it is often seen alongside other NetBIOS and SMB-related ports in legacy configurations.

When NetBIOS over TCP/IP is enabled, a device may answer NBNS requests on port 137. That behavior can reveal system and network naming information and can assist discovery of systems that have file and printer sharing enabled. Even if you do not intend to expose these services broadly, allowing inbound port 137 can make endpoints more visible to scanning and enumeration attempts. Blocking port 137 with an inbound firewall rule prevents unsolicited NBNS queries from reaching the device, helps keep legacy name resolution from being exposed beyond trusted networks, and is commonly used as a baseline hardening measure when NetBIOS is not required.

Quick Setup

To detect the misconfiguration:

Open the Vulnerability Manager Plus console and go to Threats---> System Misconfiguration to start checking port 137, and you can see the detected misconfigurations list.
In the misconfiguration list, use the search box to type port 135 and filter results to focus only on related findings.
Open the misconfiguration named Inbound connection in port 135 (UDP/TCP) is not blocked in Windows firewall, confirm it matches the expected firewall finding, and review the details to understand why it is flagged.
Check the affected endpoints list to identify which devices need a fix, then prioritize devices where the service is reachable and not required.
For each affected device, plan remediation to close port 135 and document the remediation goal.

To remediate this misconfiguration:

Open the Control Panel.
Click on Windows Firewall / Windows Defender Firewall.
Navigate to Advanced settings.
Right-click on Inbound Rules and click on New Rule.
Select Port and click Next.
Select TCP, specify port 135 under Specific local ports, and click Next.
Click Block the connection and click Next.
Select Domain, Private, and Public and select Next.
Enter a name and description, then click Finish. Repeat the steps for the UDP port 135 as well. Your devices are now hardened against exposure on port 135.

Scheduling reports keeps teams informed without needing to log in manually.

Refer to this page to know in detail more about misconfiguration hardening

Frequently Asked Questions

What is port 135 used for in Windows?

Port 135 is commonly used by Microsoft RPC Endpoint Mapper and DCOM to help clients discover and connect to RPC services. Exposing it can enable service discovery and reconnaissance.

Why is leaving port 135 open considered a security risk?

When TCP/UDP 135 is reachable from untrusted networks, attackers may enumerate RPC and DCOM services, identify exposed interfaces, and use that information to plan lateral movement or exploitation attempts.

Should I block TCP 135, UDP 135, or both?

In most endpoint hardening scenarios, you should block inbound TCP 135 and block inbound UDP 135 unless a specific, approved business requirement depends on them. Blocking both reduces the attack surface.

Will blocking port 135 break anything?

It can impact workflows that rely on RPC/DCOM, such as certain remote administration tasks, legacy management tools, or applications that use DCOM. If you need RPC/DCOM for a limited scope, block it broadly and allow it only for approved systems and trusted management networks.

Is port 135 the same as the “dynamic RPC ports”?

No. Port 135 helps clients discover RPC services. Many RPC services then communicate over dynamic ports. Blocking 135 reduces discovery and initial RPC exposure, but you should also review whether any dynamic RPC ranges are unnecessarily reachable.

How can I check if port 135 is open on a Windows machine?

You can validate exposure by testing connectivity from another system on the same network and by reviewing Windows Defender Firewall inbound rules for TCP/UDP 135. You can also confirm listening services using built-in Windows networking tools.

How do I confirm the firewall rule is working after I block port 135?

After creating inbound rules to block TCP 135 and block UDP 135, retest connectivity from a separate machine. The connection attempt should fail, and the firewall rule should show hits depending on your logging configuration.

What is the recommended approach if I must keep port 135 accessible?

Restrict exposure rather than leaving it open to all. Allow access only from trusted management servers or specific subnets, and keep it blocked on roaming devices and endpoints that do not require RPC/DCOM.

Does blocking port 135 reduce lateral movement risk?

Yes. Blocking unnecessary inbound access to RPC/DCOM reduces service discovery and remote interaction paths that attackers commonly probe during reconnaissance and lateral movement.

How does Vulnerability Manager Plus detect this misconfiguration?

Vulnerability Manager Plus flags this when the endpoint’s firewall configuration does not block inbound connections for TCP/UDP 135. It helps you identify systems where the port remains reachable and requires an inbound blocking rule.