Network Ports and Protocols Security Guide

Every listening port is a promise that something will answer, and attackers scan the whole IPv4 internet for the ones that answer without asking who is calling. Exposed RDP, SMB, databases and container APIs remain common entry points, and cleartext protocols such as Telnet, FTP and SNMPv2c still carry passwords internally. This guide is a working reference for network and infrastructure engineers, security architects and SOC teams. It explains how ports and protocols work, gives a verified table of high-risk ports with their secure alternatives, covers Windows and Active Directory protocols in depth, and sets out how to reduce exposure, monitor it and map the work to NIST, CIS and ISO controls. Port numbers are checked against the IANA registry, RFCs and vendor documentation.

Key takeaways

• A port number is a convention, not a guarantee. IANA assigns 6443 to a Sun service, yet it is the default Kubernetes API server port, and malware deliberately uses non-standard ports (MITRE ATT&CK T1571), so identify services by what answers, not by number.
• Some services should never face the internet. SMB (TCP 445), RDP (3389), NetBIOS (137 to 139), database ports, Redis (6379), the plain-text Docker API (2375) and etcd (2379 to 2380) belong behind a gateway or on loopback only.
• Replace cleartext protocols rather than wrapping them in policy. SSH replaces Telnet, SFTP or FTPS replace FTP, SNMPv3 with authentication and privacy replaces community strings, and RFC 8314 makes implicit TLS on 465, 993 and 995 the target for mail.
• Windows defaults have moved in your favour. Windows 11 24H2 Enterprise, Pro and Education require SMB signing inbound and outbound, SMBv1 is not installed by default, and NTLMv1 is removed; finish the job with LDAP signing and LLMNR disabled.
• Treat exposure as a measured, recurring control. Scan your own address space from outside, keep a per-zone allow list, and track the count of unexpected listening services as a KPI under NIST SP 800-53 CM-7(1).

Ports, protocols and what "open" means

TCP and UDP (User Datagram Protocol) use 16-bit port numbers at the transport layer, layer 4 of the Open Systems Interconnection model, to deliver traffic to the right process. RFC 6335 defines three ranges: System or Well Known Ports 0 to 1023, User Ports 1024 to 49151 (both assigned by IANA), and Dynamic or ephemeral Ports 49152 to 65535, which are never assigned. Windows uses that dynamic range for RPC services, which is why "allow RPC" through a firewall means far more than port 135.

• TCP three-way handshake: RFC 9293 describes the client sending SYN, the server replying SYN-ACK and the client completing with ACK. SYN-ACK means open, a reset means closed, silence usually means filtered.
• UDP has no handshake: a spoofed source address costs the attacker nothing, which is why UDP services such as NTP, SSDP and DNS are abused for reflection and amplification.
• Not everything is a port: Generic Routing Encapsulation (GRE, IP protocol 47), Encapsulating Security Payload (ESP, 50), AH (51), Open Shortest Path First (OSPF, 89) and SCTP (132) are IP protocol numbers. Rules that only list TCP and UDP ports ignore them.
• Loopback binding: a service bound to 127.0.0.1 (or ::1) is reachable only from the same host. Redis documents bind 127.0.0.1 as the way to restrict it.
• Names can mislead: IANA's "sftp" on port 115 is the obsolete Simple File Transfer Protocol. The SFTP everyone uses runs over SSH on port 22.
• Port scanning is how attackers find you (ATT&CK T1046 Network Service Discovery) and how you should find yourself first.

High-risk ports reference

Windows and Active Directory protocols

Microsoft's service overview lists the ports a domain needs: Kerberos 88 and kpasswd 464, LDAP 389, LDAP over SSL 636, Global Catalog 3268 and 3269, RPC 135 plus the dynamic range, SMB 445, DNS 53 and Windows Time on UDP 123. None of them should reach the internet.

SMB, formerly also called CIFS (TCP 445)

• Remove SMBv1: it is not installed by default since Windows 10 and Windows Server version 1709, and Microsoft's guidance is to disable it immediately if present. WannaCry and NotPetya spread through the SMBv1 EternalBlue flaw (MS17-010).
• Require signing: set "Microsoft network client: Digitally sign communications (always)" and "Microsoft network server: Digitally sign communications (always)" (registry value RequireSecuritySignature). Signing stops tampering and relay. Windows 11 24H2 Enterprise, Pro and Education already require it in both directions; Windows Server 2025 requires outbound only, so file servers need the server-side policy.
• Block at the edge: Microsoft recommends blocking TCP 445 inbound from and outbound to the internet; outbound SMB to the internet leaks credentials and data. From Windows 11 24H2 and Server 2025 the built-in firewall no longer opens 137 to 139 for SMB shares.
• Remote file access: use SMB over QUIC (UDP 443, TLS 1.3) or a VPN rather than exposing 445.
• Limit lateral movement: admin shares (C$, ADMIN$, IPC$) are the SMB/Windows Admin Shares technique (T1021.002). Block workstation-to-workstation SMB with host firewall rules.

Name resolution: LLMNR, NBT-NS and mDNS

Attackers answer broadcast lookups on LLMNR (UDP 5355), NBT-NS (UDP 137) and mDNS (UDP 5353) to capture or relay NTLM authentication (ATT&CK T1557.001, Name Resolution Poisoning and SMB Relay). Disable LLMNR with Computer Configuration, Administrative Templates, Network, DNS Client, "Turn Off Multicast Name Resolution" set to Enabled (registry EnableMulticast = 0), disable NetBIOS over TCP/IP on adapters or through DHCP, and rely on SMB signing to defeat relay.

LDAP, Kerberos and NTLM

• LDAP signing: set "Domain controller: LDAP server signing requirements" and "Network security: LDAP client signing requirements" to Require signing. Before enforcing, find clients with event 2887 (daily summary of unsigned binds) and 2889 (per-bind detail with client IP, enabled by setting "16 LDAP Interface Events" diagnostic logging to 2).
• Secure LDAP port: LDAPS uses 636 and the Global Catalog over TLS uses 3269. Signing on 389 and LDAPS on 636 solve the same problem; pick one per application and stop cleartext simple binds.
• NTLM: Microsoft has removed NTLMv1 from Windows Server and deprecated NTLMv2, recommending Negotiate so Kerberos (88) is used wherever possible.

RDP (3389) and WinRM (5985, 5986)

RDP listens on TCP and UDP 3389. Keep Network Level Authentication on, so users authenticate before a session is created, and follow the ATT&CK T1021.001 mitigations: do not expose RDP to the internet, use a remote desktop gateway with MFA, prune the Remote Desktop Users group and remove local Administrators from RDP logon rights where possible. For WinRM, prefer HTTPS on 5986 and restrict both ports to administrative hosts.

Infrastructure and legacy protocols

• NTP (UDP 123): the 2014 US-CERT amplification alert measured an NTP bandwidth amplification factor of 556.9. Disable legacy monitoring queries on servers, use authenticated time where possible (Network Time Security, RFC 8915, establishes keys over TLS 1.3 on TCP 4460, client-server mode only), and use SNTP only on clients that do not serve time.
• DNS (53): do not run open recursive resolvers. The same alert listed DNS amplification at 28 to 54. Encrypt resolver traffic with DNS over TLS (853) where clients support it.
• SNMP (161, 162): SNMPv3's User-based Security Model (RFC 3414) protects against modification, masquerade and, with privacy enabled, disclosure. SNMPv2c sends the community string in clear, and the US-CERT alert gave SNMPv2 an amplification factor of 6.3. Use authPriv, a dedicated management VLAN, and read-only views.
• UPnP and WS-Discovery: SSDP (1900, amplification factor 30.8 in the US-CERT alert) and WS-Discovery (3702) are local discovery protocols. Disable UPnP on internet gateways so internal devices cannot open inbound port forwards.
• Mail: RFC 8314 ("Cleartext Considered Obsolete") prefers implicit TLS: submission on 465 (registered as "submissions", previously smtps), IMAP on 993 and POP3 on 995. STARTTLS on 587 remains allowed during transition; plain POP3 (110) and IMAP (143) should be closed.
• Logging: syslog on UDP 514 has no integrity; RFC 5425 defines syslog over TLS on TCP 6514.
• VoIP: SIP uses 5060 and SIP over TLS 5061; pair SIPS with SRTP and allow-list SIP trunk provider addresses.
• Messaging and backup: AMQP 5672 has a TLS counterpart on 5671; NDMP (10000) backup control should be confined to the backup network, with NDMPS on 30000 where supported.
• Routing and tunnels: GRE (protocol 47) provides no encryption, so carry it inside IPsec ESP (protocol 50). Protect BGP and other adjacent sessions with the Generalized TTL Security Mechanism (GTSM, RFC 5082), which drops packets that do not arrive with TTL 255, and use OSPF authentication. Disable ICMP Router Discovery (IRDP) where not needed, and protect spanning tree edges with BPDU guard so a rogue switch cannot become root bridge.
• File transfer tools: SCP and SFTP clients such as PuTTY's PSCP use SSH on 22; FTP servers such as vsftpd should be configured to require TLS, or replaced.

Databases, containers and cloud-native ports

Many cloud and container ports assume a trusted network. ATT&CK T1133 External Remote Services notes that exposed Docker APIs, Kubernetes API servers and kubelets may need no authentication at all.

• Docker: by default the daemon uses a non-networked Unix socket. Docker's documentation warns that only trusted users should control the daemon, which runs as root unless rootless mode is used, and requires TLS for any network endpoint. IANA lists 2375 as the plain-text API and 2376 as TLS. The TeamTNT worm spread across exposed Docker hosts, mining cryptocurrency and stealing AWS credential files.
• Kubernetes: the API server listens on 6443, etcd on 2379 to 2380, the kubelet API on 10250, the scheduler on 10259 and the controller manager on 10257. Keep etcd and kubelet ports reachable only from control plane nodes. See the Kubernetes NHI Security Guide.
• Redis (6379): Redis says it is designed for trusted clients and should not be exposed to the internet. Protected mode (since 3.2.0) answers only loopback clients when no password is set; use ACLs (Redis 6 and later) and TLS, because AUTH alone travels in clear.
• MongoDB (27017) and other databases: enable access control, restrict net.bindIp, enforce TLS and allow only trusted clients through security groups. Internet-exposed servers are what turned MongoBleed into a mass secret-leak risk, and an open ClickHouse database exposed chat logs and API secrets in the DeepSeek exposure.
• Dashboards on high ports: admin consoles on 8080 and similar ports are easily forgotten. The Tesla Kubernetes cryptojacking case began with an open console that exposed cloud credentials.

Reducing exposure step by step

1. See yourself from outside: scan every public IP range and cloud account you own, including IPv6, and compare results with internet-wide scan data.
2. Inventory internally: collect listening ports from hosts (EDR or configuration management) and enable flow logs (CIS Safeguard 13.6) to see which ports actually carry traffic.
3. Define the allow list per zone: internet to DMZ, user to server, server to server, management. Everything else is denied by default (NIST SP 800-53 SC-7(5)).
4. Test before you block: add log-only or monitor rules for the planned denies, run them for two to four weeks, and review hits with application owners. For Windows protocols use the audit features first: LDAP event 2889, and on Windows 11 24H2 the SMB signing audit events (SMBClient 31998 and 31999, SMBServer 3021 and 3022).
5. Pilot, then enforce: apply to one site, VLAN or ring, then expand. Disable services at the host (CIS Safeguard 4.8) as well as blocking them on the network.
6. Roll back cleanly: keep the previous rule set versioned in change control, with a named owner able to re-enable a single rule quickly.
7. Review on a schedule: rerun external scans at least monthly and after every major change, as CM-7(1) Periodic Review expects.

Choosing between block, restrict and replace

• Block: for services with no business need on that path, such as SMB, NetBIOS and SSDP at the internet edge, or workstation-to-workstation SMB.
• Restrict: for services that must run but only for a few sources, such as RDP, WinRM, SSH and database ports, through a jump host, privileged access gateway or source IP allow list.
• Replace: where a secure protocol exists, such as Telnet to SSH, FTP to SFTP, SNMPv2c to SNMPv3, LDAP simple binds to LDAPS, and PPTP to IKEv2.
• VPN or application gateway: a VPN gives network-level access and broad reach; an identity-aware gateway or ZTNA product exposes one application at a time with per-request checks.
• Small organisations: focus on the edge: no inbound RDP, SMB or databases, UPnP off on routers, managed remote access with MFA, and a quarterly external scan. Large organisations also need internal segmentation, flow-log analytics and automated detection of new listeners in cloud accounts.

Detection and measurement

• Firewall and flow logs: alert on inbound connections to management ports, outbound SMB (445) to the internet, and well-known protocols on unusual ports (ATT&CK T1571 Non-Standard Port).
• Windows: successful RDP logons appear as Security event 4624 with logon type 10; track 2887 and 2889 for unsigned LDAP binds and file share access with event 5140.
• Scanning activity: internal hosts sweeping many ports usually mean post-compromise discovery (T1046).

Metrics that show the programme is working:

• Number of internet-reachable services outside the approved list (target zero), and median time to close a new one.
• Count of hosts still offering Telnet, FTP, SNMPv1/v2c or SMBv1.
• Unsigned LDAP binds per day from event 2887 trending to zero.
• Percentage of administrative protocol sessions (RDP, SSH, WinRM) brokered through a gateway with MFA.
• Percentage of network segments with flow logging enabled.

Where identity fits

Ports decide who can knock; credentials decide who gets in. Exposed remote access is only as strong as the accounts behind it: the Change Healthcare breach started with a remote access login that had no MFA. Many protocols also carry machine credentials: SNMP community strings, LDAP bind accounts used by applications, Redis passwords, database service accounts and network device secrets, which the Salt Typhoon telecom intrusions exploited to stay inside for years. Store these in a vault, rotate them, and give each application its own account so a captured credential cannot be replayed everywhere. See the Remote Access Identity Guide and the Service Account Security Guide.

Framework mapping

Common failure patterns

• Trusting the cloud console's defaults: a security group opened to 0.0.0.0/0 "temporarily" for a database or dashboard stays open, and internet-wide scanners find it.
• Moving RDP to a high port: scanners fingerprint the service, not the number. Moving 3389 to 33890 changes nothing except your own documentation.
• Allowing "any" RPC: permitting 135 plus 49152 to 65535 between all subnets permits all Windows remote management.
• Filtering TCP and UDP only: GRE, ESP and other IP protocols pass or fail unexpectedly because rules never mentioned them.
• Enforcing signing without auditing first: requiring LDAP or SMB signing before checking events 2889 or the SMB audit events breaks old printers, scanners and appliances, and the change is rolled back permanently.
• Forgetting IPv6 and outbound rules: an IPv4-only deny list, or no outbound control on 445, leaves services reachable.

Practitioner checklist

• Scan your public IPv4 and IPv6 ranges and cloud accounts monthly and investigate every unexpected listener.
• Block SMB, NetBIOS, RDP, database, Redis, Docker, etcd and kubelet ports from the internet.
• Remove SMBv1, require SMB signing on file servers, and block outbound 445 at the edge.
• Disable LLMNR and NetBIOS over TCP/IP; audit and then require LDAP signing.
• Replace Telnet, FTP, SNMPv1/v2c and PPTP with SSH, SFTP or FTPS, SNMPv3 authPriv and IKEv2.
• Broker RDP, SSH and WinRM through a gateway with MFA; keep NLA on.
• Bind local-only services such as Redis and Memcached to loopback and enable authentication.
• Enable flow logs and alert on management ports, outbound SMB and non-standard port use.
• Vault and rotate protocol credentials such as SNMPv3 users, LDAP bind accounts and database passwords.

Standards and references

• IANA: Service Name and Transport Protocol Port Number Registry
• IETF: RFC 6335, Procedures for the Management of the Service Name and Transport Protocol Port Number Registry
• IETF: RFC 8314, Cleartext Considered Obsolete: Use of TLS for Email Submission and Access
• NIST: SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
• Microsoft Learn: Service overview and network port requirements for Windows
• Microsoft Learn: Secure SMB traffic in Windows Server
• MITRE ATT&CK: T1557.001 Name Resolution Poisoning and SMB Relay
• Kubernetes: Ports and Protocols

Related NHI Mgmt Group resources: Remote Access Identity Guide · Active Directory and Entra ID Hardening Guide · Service Account Security Guide · Zero Trust Identity Guide