Network Daemons  «Prev  Next»

Lesson 5 Well-known port numbers and /etc/services
Objective Describe the conventions for establishing an association between certain port numbers and services.

Well-known Port Numbers and /etc/services

When a client application connects to a server application, it must target the correct transport-layer endpoint. The destination host is identified by its IP address, but the specific server process is identified by a port number. This is why a client can reliably “find” an SSH server on TCP port 22 or a web server on TCP port 443.

These conventions are not a UNIX invention. They are administered globally by the Internet Assigned Numbers Authority (IANA), which maintains registries that associate service names with port numbers for TCP, UDP, and other transport protocols. When a port assignment is widely recognized and consistently used, it is commonly referred to as a well-known port.

Historically, services like Telnet (TCP 23) and FTP (TCP 21) were common, but modern security practice strongly prefers encrypted alternatives: SSH instead of Telnet, and SFTP/FTPS instead of cleartext FTP.

On Linux and other UNIX-like systems, the file /etc/services provides a local mapping of service names to port numbers and protocols. It enables humans and programs to reference a service by name instead of memorizing numeric port values.

View the excerpt below to see the structure of /etc/services. This file is informational and does not, by itself, start any service.

Example excerpt from /etc/services showing service names, port/protocol pairs, and optional aliases. Note that some services (such as DNS) appear for both TCP and UDP because they can use both transport protocols.

#
# Network services, Internet style
#
tcpmux          1/tcp
echo            7/tcp
echo            7/udp
discard         9/tcp          sink null
discard         9/udp          sink null
daytime         13/tcp
daytime         13/udp
chargen         19/tcp         ttytst source
chargen         19/udp         ttytst source
ftp-data        20/tcp
ftp             21/tcp
telnet          23/tcp
smtp            25/tcp         mail
time            37/tcp         timserver
time            37/udp         timserver
whois           43/tcp         nickname
domain          53/udp
domain          53/tcp
http            80/tcp
https           443/tcp
ssh             22/tcp
    

What /etc/services Does and Does Not Do

The primary purpose of /etc/services is to support a naming convention for ports. Programs can look up a port by service name using the system services database APIs (for example, getservbyname()), rather than hard-coding a port number.

Key point: /etc/services is a mapping file, not a runtime authority. Editing it does not automatically reconfigure a daemon. Whether a service actually listens on a port depends on how that service is configured (systemd unit files, daemon config files, container port publishing rules, firewall policy, and so on).

It’s also important to understand that the port mapping is not a guarantee of availability. A line can exist in /etc/services even if no process is listening on that port. Think of it like a dictionary: it defines names, but it does not start anything.

Why Some Services Use Both TCP and UDP

Some protocols intentionally support multiple transports. DNS is a classic example: UDP is commonly used for standard query/response traffic, while TCP is used for zone transfers and for responses that do not fit within a UDP payload (or when reliability is required).

This explains why you may see the same service name appear twice in /etc/services, once as 53/udp and once as 53/tcp. They represent distinct endpoints.

Security Notes on Legacy Services

Many older “well-known” services exist primarily for compatibility or historical reference. In hardened environments, these services are typically disabled and blocked at the firewall:

  • Telnet (TCP 23): cleartext remote login ➜ use SSH (TCP 22).
  • FTP (TCP 21/20): cleartext credentials/data ➜ use SFTP (SSH) or FTPS (TLS).
  • CHARGEN (TCP/UDP 19): rarely used and commonly filtered due to abuse potential.

A modern operational posture is to expose only required ports, prefer encrypted protocols, and continuously verify what is actually listening.

Find Which Processes Are Actually Bound to Ports

If you need to verify which services are truly listening on a system, use tooling that interrogates the kernel’s socket tables. On Linux, two common approaches are ss (modern) and lsof. The command netstat may still exist on some systems, but it is often deprecated in favor of ss.

Option 1: ss (recommended on modern Linux)


# List listening TCP/UDP sockets with numeric ports
ss -lntup

# Show who is listening on TCP port 22
ss -lntp '( sport = :22 )'
  

Option 2: lsof (excellent for mapping ports to processes)


# Show all network sockets with numeric IPs and ports
sudo lsof -i -P -n

# Show the process using a specific port (example: 443)
sudo lsof -i :443
  

Use these commands when troubleshooting firewall rules, validating service startup, confirming container port publishing, or auditing a host’s external attack surface.

Quick Summary

  • IANA maintains global conventions that associate common services with port numbers.
  • /etc/services provides local name-to-port mappings for programs and administrators.
  • The file does not enable or disable services; it only names them.
  • To confirm what is really running, use ss or lsof.
  • Prefer encrypted protocols (SSH/HTTPS/SFTP/FTPS) and block legacy cleartext services where possible.

[1] Domain: In networking, “domain” often refers to the Domain Name System (DNS), which maps hostnames to IP addresses. In business contexts, “domain” can also refer to a naming boundary (for example, an organization’s DNS namespace).


SEMrush Software 5 SEMrush Banner 5