Command Center · Reference 06
Ports, Protocols & Services
Fast recognition for common TCP and UDP ports, service purpose, Windows and Linux listener checks, and the reasoning needed to decide whether a network service is expected.
Memorize the common associations, but never treat a port number as proof of the application or as proof of a vulnerability.
Service Rule
Important
Ports are associations, not conclusions
The same application can use a different port, and a different application can bind to a familiar port. Always identify the owning process or service and compare it with the host's required role.
Transport
TCP
Transport
UDP
Port reference
Core Infrastructure
Legacy file-transfer data channel.
Context
FTP is unencrypted and should be reviewed carefully.
Legacy file-transfer control channel.
Context
Credentials and data may be exposed without protection.
Secure shell and secure remote administration.
Context
Confirm whether remote administration is required.
Legacy remote terminal access.
Context
Traffic is unencrypted; replace or disable when not required.
Mail transfer between servers.
Context
Do not confuse mail transport with user mailbox access.
Name resolution and zone-transfer related traffic.
Context
DNS is critical infrastructure; investigate before changing it.
Server-side DHCP traffic.
Context
DHCP availability may be essential for clients.
Client-side DHCP traffic.
Context
Do not block if clients depend on dynamic addressing.
Port reference
Web & Application
Unencrypted web traffic.
Context
An open HTTP port is not automatically a vulnerability if required by the scenario.
Encrypted web traffic using TLS.
Context
HTTPS still requires valid configuration and secure application behavior.
Common alternate web/application port.
Context
Port 8080 does not guarantee the application is HTTP.
Common alternate TLS web/application port.
Context
Confirm the actual listening process.
Port reference
Windows & File Sharing
Windows RPC service discovery.
Context
Common on Windows systems; evaluate with host role and firewall scope.
Legacy Windows name resolution.
Context
May be unnecessary in modern environments.
Legacy Windows datagram service.
Context
Review whether legacy compatibility is required.
Legacy SMB/session traffic.
Context
SMB can also operate directly over TCP 445.
Windows file sharing, named pipes, and related services.
Context
Required on many file servers and domain environments.
Port reference
Remote Access & Management
Encrypted remote shell.
Context
Strong authentication and access scope still matter.
Unencrypted remote shell.
Context
Avoid when secure alternatives are available.
Windows Remote Desktop.
Context
Check whether RDP is required before disabling it.
Remote graphical desktop on many implementations.
Context
Authentication and encryption vary by product.
Windows Remote Management over HTTP.
Context
HTTP transport can still use message-level security depending on configuration.
Windows Remote Management over TLS.
Context
Certificate and trust configuration matter.
Port reference
Directory & Authentication
Authentication protocol used heavily in Active Directory.
Context
Critical in domain environments.
Directory queries and updates.
Context
Plain LDAP may expose data unless protected.
LDAP over TLS.
Context
Certificate configuration matters.
Active Directory global catalog queries.
Context
Expected on domain controllers providing GC services.
Encrypted global catalog queries.
Context
Requires appropriate certificate support.
Port reference
Server-to-server mail transfer.
Context
Not usually used for end-user mailbox retrieval.
Legacy mailbox retrieval.
Context
Plain POP3 is unencrypted.
Mailbox access and synchronization.
Context
Plain IMAP is unencrypted unless upgraded.
SMTP over implicit TLS on many services.
Context
Usage varies by provider.
Authenticated client mail submission.
Context
Common for user-to-mail-server sending.
IMAP over TLS.
Context
Common secure mailbox access.
POP3 over TLS.
Context
Secure transport does not guarantee secure credentials or server policy.
Port reference
Monitoring & Time
Network time synchronization.
Context
Accurate time is critical for logs and authentication.
Network monitoring and management queries.
Context
SNMPv1/v2 community strings can be weak if poorly configured.
Asynchronous monitoring alerts.
Context
Check destination and community/security configuration.
Traditional syslog transport.
Context
UDP syslog is not encrypted or guaranteed delivery.
Encrypted syslog transport.
Context
Certificate and collector configuration matter.
Port reference
Databases
Common SQL Server database port.
Context
Confirm the actual process and whether remote access is required.
Common MySQL-family database port.
Context
Database exposure should be limited to required hosts.
Common PostgreSQL database port.
Context
Check listen addresses and access-control rules.
Interpretation
How to reason about a port correctly
A port number is a clue, not proof of the application.
A listening socket means a process is waiting for connections; it does not prove remote reachability.
A firewall rule that allows a port does not prove anything is actually listening.
An established connection proves communication occurred, not whether that communication was legitimate.
A standard service can run on a nonstandard port.
A nonstandard port can still host an ordinary service.
Always map the port to the owning process or service when possible.
Always consider the host's assigned role before deciding whether a service is unnecessary.
Windows
Listener and process checks
Get-NetTCPConnection -State Listen
Shows listening Windows TCP sockets.
Get-NetTCPConnection
Shows TCP endpoints, states, and owning PIDs.
Get-NetUDPEndpoint
Shows Windows UDP endpoints.
netstat -ano
Classic socket view with PID mapping.
Get-Process -Id <pid>
Maps a PID to a process.
Get-CimInstance Win32_Service | Select Name,State,StartName,PathName
Maps service configuration and executable paths.
Linux
Listener and process checks
ss -tulpn
Shows listening TCP/UDP sockets and processes when permissions allow.
ss -tpn
Shows active TCP connections and processes.
sudo lsof -i -P -n
Shows network sockets and owning processes where lsof is available.
ps -fp <pid>
Shows process details for one PID.
systemctl status <service>
Shows service state and recent logs.
journalctl -u <service> --since "1 hour ago"
Shows recent journal entries for one service.
Service decision check
Ask these before disabling a service or blocking a port
Is this service required by the scenario?
Which process owns the port?
Which account runs that process or service?
What executable path is associated with it?
Is the port bound to localhost, one interface, or all interfaces?
Does the firewall allow inbound access?
Is the service actually reachable from the required network?
Is there log evidence showing recent use?
What will break if I disable or remove it?
How will I verify required functionality after the change?
Common mistakes
Port mistakes that break working systems
Disabling every unfamiliar port without checking the host role.
Assuming port 80 means a web server is insecure simply because it is HTTP.
Assuming port 443 means the service is automatically safe.
Blocking DNS, DHCP, Kerberos, or SMB on systems that depend on them.
Treating a firewall allow rule as proof that a service is running.
Treating a listening socket as proof that it is reachable from another host.
Forgetting that services can run on nonstandard ports.
Changing several firewall or service settings at once and losing the cause of the result.