✳ The reference desk / In practice

Port

A number on a host that distinguishes one listening service from another.

What it means

Transport protocols use port numbers to distinguish communication endpoints on a host. A server commonly listens on a port while a client uses a temporary source port for its side of a connection. The address, protocol, and ports together help identify the traffic being discussed.

A familiar number is only a convention. Port 443 often carries HTTPS, but a service can listen elsewhere and unrelated software can use that number. Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) also have separate port spaces. Practitioners use port information to inventory services, interpret logs, and restrict network access, then verify the application actually behind the listener.

The idea at a glance / Networks

The address and port identify both ends.

Compare two TCP connections to the same server. Each names a client endpoint and a configured service endpoint.

Authored network: client 192.0.2.17 uses temporary TCP ports 53124 and 53125. Server 198.51.100.44 is configured for HTTPS on TCP 443 and SSH on TCP 22. No translation is shown.

Port: Compare two TCP connections to the same server. Each names a client endpoint and a configured service endpoint. The explanation below describes the relationships.Two TCP connections · same serverClient source → server destinationWeb connection · TCPClient: 192.0.2.17:53124Server: 198.51.100.44:443Administration connection · TCPClient: 192.0.2.17:53125Server: 198.51.100.44:22Two configured server listenersHTTPS on TCP 443 · SSH on TCP 22The client uses temporary source portsNumber alone does not prove serviceTCP 443 and UDP 443 are differentReachability + permission need checksADDRESS + TRANSPORT + PORT

READ THE PICTURE

Read the connections and checks

The client’s TCP 53124 connects to the server’s 443; TCP 53125 connects to its 22. These are separate connections on the same destination IP. The transport protocol matters, and the configured service still needs its own checks.

Keep in mindConfigured listeners are assumptions, not scan results. A port number does not prove the application, safety, reachability, or user permission. TCP and UDP have separate endpoint spaces.

Read the complete example
  1. Read the connections and checks. The client’s TCP 53124 connects to the server’s 443; TCP 53125 connects to its 22. These are separate connections on the same destination IP. The transport protocol matters, and the configured service still needs its own checks. In this authored example, a browser uses client endpoint 192.0.2.17:53124 with server endpoint 198.51.100.44:443, while an administration client uses 192.0.2.17:53125 with 198.51.100.44:22. Both are TCP. The client source ports are temporary selections in the dynamic range, not universal fixed requirements. The server has two explicitly configured listeners: HTTPS at TCP 443 and SSH at TCP 22. The pair of endpoints and transport identify each connection in this network context. Responses reverse the source/destination roles within the same connection; they do not start by choosing a new server listener. TCP 443 and UDP 443 are different transport endpoints, even though the number is the same. Assigned service numbers are conventions, not proof that observed traffic uses that service. A configured listener does not establish reachability from every starting point, good TLS/SSH configuration, or application permission. No connection or scan is performed by this still comparison; both address blocks are documentation-only.

Configured listeners are assumptions, not scan results. A port number does not prove the application, safety, reachability, or user permission. TCP and UDP have separate endpoint spaces.

Diagram references: RFC 9293 - TCP endpoints and header ports · RFC 6335 - port spaces, dynamic ports, and service conventions · RFC 5737 - documentation addresses

AN ILLUSTRATIVE SCENARIO

A manufacturer support interface

A manufacturer discovers that a maintenance server listens on a management port as well as its normal web port. The maintenance service was intended for administrators, but a firewall rule exposes it to a much wider network. The team identifies the owning process and confirms the access requirement with operations. It restricts the management path and safely checks the result from both an approved administration device and an ordinary workstation. Renumbering the service alone would not provide the required access control.

Put it to work

  1. List listening services on a system you administer, recording the transport protocol, port, binding address, owning process, and business owner.
  2. Compare those listeners with firewall and network rules to determine which sources can actually reach them, including alternate interfaces.
  3. Remove unnecessary listeners or restrict them to approved sources, then test both the intended connection and the connection that should fail.
List TCP listeners on a Linux machine you administer (requires ss). This does not test reachability from another network.
ss --listening --tcp --numeric

How to check your work

Verify the permitted management connection still works and an unauthorized test source cannot reach it. Retain the relevant rule, owner, and test location so the result has a clear scope.

Connect the ideas

  • IP address

    A numeric locator used to deliver packets to a host on a network.

  • Exposure

    Whether and how a vulnerability or service can actually be reached in this environment.

  • HTTP

    The application protocol that names methods, paths, headers, and bodies for web requests.

  • Least privilege

    Granting each identity only the actions, objects, and time window required for the current job.

Explore a field lesson

Find your next idea.

Tip: press / to open search. Escape closes this window.