Table of Contents
Understanding Network Services on Linux
Linux is frequently used as the foundation for networked applications and infrastructure. Network services are programs that listen for requests over the network and provide responses. Typical examples include secure remote access, file sharing, web hosting, name resolution, and many others. In this part of the course, individual chapters will cover several specific services in depth, such as SSH, NFS, Samba, and FTP. This chapter focuses on what is common to all of them and on how Linux exposes and controls services at the network level.
What Makes a Program a Network Service
A general user program runs, does some work, and then exits. A network service is usually designed to run continuously and to accept connections from clients over the network. Such a program binds to one or more network addresses and ports, waits for incoming traffic, and then handles each request according to a protocol.
On Linux, a listening service is typically a process that has a socket open in a listening state. This process may be started and supervised by the init system, most commonly systemd, or by older tools like inetd or xinetd in some environments. The important point is that a service exposes itself through an IP address and a port, and speaks a defined network protocol so that clients can interact with it.
Some services are intended for human interaction, such as a shell over SSH, while others are intended for other programs, such as HTTP APIs or file sharing protocols. Regardless of their purpose, they can all be inspected and controlled using standard Linux networking tools.
A process becomes a network service when it listens on a network socket, typically identified by an IP address and a port, and responds to requests following a specific protocol.
Ports and Protocols
Every network service uses one or more transport protocols. On Linux, the most common are TCP and UDP. TCP provides a connection oriented byte stream, while UDP provides connectionless datagrams. Services are identified on a host by port numbers within these protocols.
Ports in the range 0 to 1023 are called well known ports. They are traditionally reserved for standard services such as HTTP on port 80, HTTPS on port 443, SSH on port 22, and so on. Ports from 1024 to 49151 are registered ports typically used by less common or vendor specific services. Ports from 49152 to 65535 are dynamic or private ports, usually chosen temporarily by clients for outgoing connections.
Most services that you will configure in later chapters, such as SSH, NFS, Samba, and FTP, have default ports, but in practice you can change these ports in the service configuration files. When doing so you must remember that firewall rules and client configurations may also need to be updated.
When a service listens, it usually binds to a specific IP address or to a special address that means all addresses on the host. A service can listen only on IPv4, only on IPv6, or on both, depending on its configuration and the capabilities of the operating system.
Daemons and Service Management
On Linux, server side network services are conventionally implemented as daemons. A daemon is a background process that is not directly tied to a terminal and that expects to run for a long time.
Modern daemons are typically managed using systemd, which standardizes how processes are started, stopped, and monitored. Each network service usually has a corresponding systemd service unit file, often in /lib/systemd/system or /etc/systemd/system. Although a later chapter covers systemd in detail, it is useful here to understand that enabling a network service generally means configuring systemd so that the associated daemon is launched at boot and is restarted if it fails.
Some network daemons are designed to handle multiple connections within a single process. Others spawn worker processes or threads. From the administrator’s perspective, the main concern is that the daemon is running, listening on the expected ports, and integrated with logging and security controls such as firewalls and authentication systems.
Discovering and Inspecting Services
Before you configure specific services like SSH or a file server, you should be able to see what is already running on a system. Linux provides several tools for this. The exact syntax will be described in detail in later chapters that focus on networking tools, but at a high level you can query the kernel for active sockets and match them to processes.
To list listening sockets with associated processes on many systems, you can use commands such as ss or lsof. For example, ss can display TCP and UDP sockets along with their listening state, addresses, and owning processes. These tools let you confirm that a service is bound to the expected port and IP address.
If you connect to a service from the same machine, for example with curl for HTTP or ssh for SSH, you can then observe new established connections appearing in these tools. This is an important diagnostic technique, because it demonstrates that the server and firewall are both permitting communication.
Most network services also produce log entries when they start, stop, or encounter errors. On systems that use systemd, you can review these logs with journalctl for the relevant service. When debugging connection problems, logs complement low level socket listings and can reveal authentication failures, protocol errors, or misconfiguration.
Service Security Basics
All network services expose some surface area to the outside world, so configuring them securely is an essential part of administration. Each specific service chapter will detail its own security controls, such as SSH key authentication or Samba permissions, but there are some common principles.
First, do not run services you do not need. Every listening port is a potential point of attack, so it is wise to disable or remove unused daemons. Second, restrict who can reach a service. This usually involves host based firewalls, which are examined further in the chapter on firewalls, and sometimes external network devices.
Third, prefer encrypted protocols over unencrypted ones. For example, prefer SSH to Telnet, and HTTPS or SFTP over plain HTTP or FTP for sensitive data. Many legacy protocols can be wrapped with TLS, often through the use of a reverse proxy, which is discussed in the chapter on reverse proxy concepts.
Fourth, keep services updated. Vulnerabilities in network daemons are common targets for attackers. Package managers, described earlier in the course, are the primary way you keep these components current.
Only expose the minimum set of network services that you actually need, restrict their reachability with firewalls, and keep them updated to reduce the system’s attack surface.
Service Discovery and Name Resolution
While IP addresses and ports identify services technically, humans and applications often rely on hostnames and sometimes on service specific records. Name resolution, which is covered in detail in the section on DNS and hostnames, determines how these names map to IP addresses.
Some environments use service discovery mechanisms beyond basic DNS, such as mDNS or SRV records, to advertise the presence of network services. Linux clients and servers can participate in these schemes through various daemons. For example, a file server may publish itself so that clients can find it without manual configuration.
On the server side, you should be aware that your services might be reached by name or by direct IP. When configuring binding addresses or access control lists, it is therefore not enough to think only in terms of hostnames. You must ensure that both DNS and the server listen configuration are consistent with your deployment plan.
Integrating Services in an Architecture
Network services rarely operate in complete isolation. They are usually part of a larger architecture. A web server might rely on a database server. An SSH server might be used to deploy containers. A file sharing service might be accessed from both Linux and Windows clients.
As you build and maintain these systems, you must consider how the various services interact. This includes network topology, firewalls, routing, and authentication components. For example, a web server and its database might reside on different machines. In that case, they need to be able to reach each other on specific ports, but the database should usually not be reachable from the public internet.
Some designs use a reverse proxy service as a front end that terminates TLS and then dispatches requests to backend services. This creates a layered structure in which the reverse proxy is the only publicly visible component, while application servers and databases are only reachable from within a private network.
Later chapters on reverse proxy concepts and load balancing will discuss how services can be scaled and made highly available. For now, it is enough to understand that Linux provides the basic building blocks from which complex service architectures are constructed.
Configuration Files and Conventions
Every network service has its own configuration format and files, but there are common patterns. Most daemons store their configuration under /etc and provide one or more main configuration files, sometimes supported by directories of additional fragments.
These files typically specify the addresses and ports to listen on, logging options, access controls, and protocol specific settings. For example, you may find settings that control whether a service listens only on a loopback interface for local use or on all network interfaces for remote access. Misconfiguring these directives can result in a service that appears to be running but is not reachable from where you expect.
Before modifying configuration files, it is good practice to make a backup. Many daemons provide a way to test the syntax of their configuration without fully restarting, which is valuable on production systems. After a configuration change, you almost always need to reload or restart the service using systemd or the service’s own control utility.
Testing Connectivity
When you bring up or modify a network service, you need to confirm that it behaves as intended. This testing happens at a few layers. First, you can test basic network reachability, for example by sending ICMP echo requests if allowed, or by using tools that attempt a connection to a specific port.
Second, you test the application protocol itself. For HTTP, that might mean issuing a request using curl and examining the response. For SSH, you attempt a login and verify that your authentication and banner appear correctly. For file sharing, you might mount a network share and read and write files.
Diagnostic tools can help you distinguish between problems in the lower network layers and problems in the application layer. If attempting a TCP connection to the right port fails immediately, the issue may be firefwall rules or a non listening daemon. If the connection is established but the protocol interaction fails, you are likely dealing with a configuration or logic error within the service.
Consistent testing practices are especially important when you automate deployments. Scripts and configuration management tools that configure services should be accompanied by tests that confirm that each service is listening where expected and responds correctly.
The Role of Network Services in Linux Administration
Managing network services is central to Linux system administration. Almost every server role that Linux fulfills is defined by the services it runs and how they are exposed to clients. As you progress through the remaining chapters in this part of the course, you will work with specific services such as SSH, file sharing, and data transfer protocols. Each of these builds on the notions introduced here, such as daemons, ports, security considerations, configuration management, and testing.
By understanding the common patterns that underlie all network services, you can apply your knowledge across many different technologies. Whether you are deploying a simple internal tool or a large scale cluster, the same core Linux mechanisms are at work when a service accepts a connection and returns a response over the network.