The issue of binding a service to a port in Linux strongly depends on the operating system’s environment. A Linux OS environment exists either as a desktop or a server. The Linux server is a better candidate for the assessment of this topic.
This assessment is in comparison to how these two OS environments deal with ports and services. The Linux server OS environment is more dynamic in offering ports and services functionalities.
A Linux server machine is characterized by an IP address linked with the Network Layer and several port numbers linked with the Transport Layer. This characterization is under a normal network topography. In terms of functionality, a machine that exists in a defined network will depend on its assigned IP address for it to be located.
So when an IP address points to a machine’s destination on an existing network, a port number will be associated with the machine system’s destination service.
Service-to-port bind relationship
To better understand this service-to-port relationship on an active network, consider the following logic. Let’s say that an active machine network is a town estate. This town estate has several apartment buildings. So we can associate each apartment building to a machine on this active network. The address of each apartment building can be linked to the IP address of individual machines on an existing network.
Inside these apartment buildings, we have different apartments and apartment numbers that uniquely identify them. You can associate these apartment numbers with port numbers on a machine network. So when a network system or machine requires a specific packet delivered to a machine process, this packet request has to be associated with a port number the same way a pizza delivery guy needs to know exactly where you live.
So before a service binds to a port, the destination IP address has to be identified first. Afterward, the port number associated with the service request is then revealed. This Network Layer to Transport Layer protocol ensures that a packet request on a network gets to the correct process. Before a packet request is executed on such a network, the packet’s transport header is given the specifics of the targeted port number.
The actual interpretation of port-to-service binding
When we talk of binding a service to a port in Linux, we imply that the service is actively listening to that particular port. It is the same way you would be anticipating the pizza delivery guy at your doorstep. For this service to anticipate or listen to the port on a computer network or system, it first needs to open a socket. Under the computer network topography, the definition of a socket encapsulates a computer’s IP address linked to a specific port. So a socket is the ratio IP: PORT.
Rules of binding a service to a port in Linux
Not all system services require an association with a port number, meaning they do not need to open a socket on a network to receive packets. However, if the network services need to communicate with other network processes continuously, a socket is required, making it mandatory for these services to bind to specific ports.
Port numbers make it easy to identify requested services. Their absence implies that a client-to-server request would be unsuccessful because the transport headers associated with these requests will not have port numbers that link them to specific machine services.
A service such as HTTP has a default binding to port 80. This default binding does not imply that the HTTP service can only receive network packets or respond to network requests via port 80. With access to the right config files, you can associate this service with a new custom port. After this successful configuration, accessing the service with the new port number would imply specifying the machine’s IP address or domain name and the new port number as part of its URL definition.
For example, a machine on an HTTP service network that was initially accessed via the IP address http://10.10.122.15 may have a new access URL like http://10.10.122.15:83 if the port number is changed from 80 to a custom port number like 83.
Service-to-process communications always require open sockets (IP address plus specific port number) since all services are not tied to ports. Network services have the flexibility of not relying on ports, but these same ports cannot exist without services.
Modifying the /etc/services files
Since we now understand the relationship between network services and ports, any open network connection on a Linux server associates the client machine that opened that connection to a targeted service through a specific port. This active network classifies these ports as “well-known ports” because both the server and the client computers need to know beforehand.
The configuration that binds a service to a port on a Linux machine is defined in the small local database file “/etc/services”. To explore the content of this file structure, you can use the nano command.
$ sudo nano /etc/services
The first column of this configuration file lists the associated Linux services. In contrast, the second column lists the port number associated with each service and the network protocol associated with the ports.
a snippet of the services-to-ports configuration file
For example, connection-oriented protocols are represented by TCP, and connectionless protocols represented by UDP. TCP might not have the speed and efficiency of UDP, but it is the go-to protocol for lost data packet re-transmission.
Whenever you need to bind a service to a port on your Linux desktop or server environment, this /etc/services configuration file is the one you need to access. For this configuration to be successful, both the client and server computers need these modifications beforehand. Any incorrect modifications implemented on this /etc/services configuration file can severely affect your Linux operating system operability.
We have already covered the first step to accessing this service configuration file on your Linux machine. Make sure you have the needed administrative privileges, or you are a sudo user. You may want to modify an exiting service or bind a new one to a custom port number. In this case, you have to be sure that the set custom port number does not exist or is not being used by another service on that same configuration file.
When adding a new service port number, you will need to populate three important columns on this file in the following order.
Service_Name Port_Number #Comment
Under the port number column, remember to associate it with either a connection-oriented (tcp) or a connectionless (udp) protocol. Let’s, for example, say that we have a service called “foss5srv” that does not yet exist on this list. Adding it will take the following format approach through your vi, nano, or any other text editor of your choice.
foss5srv 1100/tcp # FOSS/5 file service
The comment column is important for remembering your service-to-port customization edits, especially if you plan to make multiple changes to this configuration file.
Final note
The ports that a Linux service binds to are categorically defined as either untrusted or trusted ports. The ports defined under TCP and UDP are considered “trusted ports”. A user can communicate with a trusted port through an untrusted port. The trusted port classification status is a security measure for retaining the integrity of privileged information on a targeted system. For instance, port 23 deals with telnet services.
If this port were not protected, it would be easy to write a program that communicates with this port. Unsuspecting users might think they are interacting with a telnet server and end up losing their system passwords to this server. With that said, ports can never be trusted.
It is because a user-defined server program can still use an unassigned or assigned port. It is why organizations need strict measures implemented to filter the permissions of IP ports that are allowed to enter or leave their network systems.
