Network Services

Understanding Network Services on Linux

In Linux, “network services” are long‑running processes that provide functionality over the network: SSH, web servers, file shares, name resolution, etc. This chapter focuses on how these services fit together, how they’re typically managed on a modern Linux system, and the common patterns you’ll see across different daemons.

What Counts as a Network Service?

On a typical server, many of these are network services:

• Remote access: sshd, VNC, RDP gateways
• Web and application: httpd/apache2, nginx, php-fpm, gunicorn
• File sharing: NFS, Samba (smbd, nmbd)
• Name and directory: DNS (named/bind9), LDAP
• Mail: SMTP (postfix, exim), IMAP/POP3 (dovecot)
• Databases: mysqld, mariadbd, postgres
• Infrastructure: DHCP servers, VPN servers (WireGuard, OpenVPN), reverse proxies, load balancers

They are usually implemented as:

• Daemons: background processes listening on TCP/UDP ports
• Socket‑activated services: started on demand by systemd when a connection arrives
• Containers: services packaged and run via Docker/Podman, but still exposing ports

Common Architectural Patterns

Most network services follow a few recurring patterns.

Listening Ports and Protocols

A daemon binds to one or more IP addresses and ports. You’ll typically see in its config:

• Address to listen on (IPv4, IPv6, or both), e.g. 0.0.0.0, 127.0.0.1, ::
• Port number, e.g. 22, 80, 443, 5432
• Protocol: tcp, udp, or sometimes unix (UNIX domain sockets)

Patterns you’ll encounter:

• Public vs local listening
• Public: Listen 0.0.0.0:80 (accessible from any host, subject to firewall)
• Local‑only: bind-address = 127.0.0.1 (local process only; often for backends)
• UNIX sockets for local traffic
• Example: a web server talks to php-fpm over unix:/run/php/php-fpm.sock instead of TCP

Understanding where a service is listening is crucial for both connectivity and security.

Frontend / Backend and Layered Services

Many stacks are layered:

• Frontend / reverse proxy: nginx or apache terminates HTTP/HTTPS, handles TLS, static files, and routing.
• Backend application: Python, Ruby, Node.js, Java app server listening on a local port or UNIX socket.
• Database: MySQL/MariaDB, PostgreSQL, etc.

Typical pattern:

1. Client connects to port 443 on public IP (TLS).
2. Reverse proxy terminates TLS, inspects HTTP request.
3. Proxy forwards to internal backend (e.g. 127.0.0.1:8000).
4. Backend talks to DB on 127.0.0.1:5432 or via socket.

Network services chapters later in this part (SSH, NFS, Samba, etc.) each implement their role in patterns like these.

Authentication and Authorization Layers

Many services separate:

• Authentication (who are you?) via:
• Local users, /etc/passwd and /etc/shadow
• Central auth: LDAP, Active Directory, Kerberos
• Application‑level auth: database users, tokens, OAuth, API keys
• Authorization (what can you do?) via:
• Filesystem permissions
• Application roles and ACLs
• Service‑specific rules (e.g. “these IPs can query DNS”, “this subnet can mount NFS”)

You’ll see:

• PAM integration (/etc/pam.d/*) for services using OS accounts
• Database‑internal auth for DB servers
• HTTP‑level auth (Basic, Bearer, forms, etc.) for web services

Understanding which layer manages which kind of access is key when troubleshooting login or permission issues.

Managing Network Services with systemd

On most modern distributions, network daemons are controlled via systemd. You’ll deal with units such as:

• Service units: sshd.service, nginx.service, smb.service
• Socket units: sshd.socket, cups.socket

Typical workflows:

• Start/stop:
• sudo systemctl start nginx
• sudo systemctl stop nginx
• Enable on boot:
• sudo systemctl enable nginx
• Check status:
• systemctl status nginx
• View logs:
• journalctl -u nginx

Some services are socket‑activated: the socket unit listens on a port and starts the daemon on first connection. This is common for services that are rarely used but must be responsive when called.

Network Service Configuration Patterns

While each daemon has its own syntax and file locations, many share similar configuration concepts.

Common Configuration Locations

On typical distributions:

• Main config files:
• /etc/ssh/sshd_config
• /etc/nginx/nginx.conf
• /etc/samba/smb.conf
• /etc/postfix/main.cf
• Drop‑in directories:
• /etc/nginx/conf.d/
• /etc/systemd/system/*.d/
• /etc/ssh/sshd_config.d/
• Distribution‑specific:
• Debian/Ubuntu: /etc/default/* for environment and extra options
• RHEL/Fedora: /etc/sysconfig/* for service options

Common patterns:

• Global section: default settings (e.g. logging, default ports, base paths)
• Per‑instance blocks: virtual hosts, shares, databases, zones, etc.
• Include directives: include /etc/nginx/conf.d/*.conf; to modularize config

Listening, Binding, and Access Control

Key directives you’ll see across services:

• Listening/binding
• Listen 80 (Apache)
• listen 80; (nginx)
• bind 127.0.0.1 or bind-address = 0.0.0.0 in DBs
• Access control by IP / subnet
• Allow or deny lists (e.g. CIDR notations like 192.168.1.0/24)
• “Loopback only” configs for services not meant to be public

When hardening or debugging, you’ll confirm:

1. Is the daemon running?
2. Is it listening on the expected address/port?
3. Is a firewall blocking it?
4. Is the daemon’s own access control blocking it?

Interaction with Firewalls and SELinux/AppArmor

Network services don’t exist in isolation; they’re filtered by local security controls.

Host Firewall Basics

Typical layers:

• Kernel packet filter: iptables/nftables
• Frontends: UFW (Ubuntu), firewalld (RHEL/Fedora)

For any network service you deploy, you’ll usually:

• Open needed ports:
• UFW: sudo ufw allow 22/tcp
• firewalld: sudo firewall-cmd --add-service=ssh --permanent && sudo firewall-cmd --reload
• Prefer service names (ssh, http, https) over raw ports where available
• Avoid “allow all from anywhere” unless the service must be public

Firewall configuration is a separate topic, but you should always consider it when a service “refuses to connect”.

Mandatory Access Control (SELinux/AppArmor)

On systems with SELinux or AppArmor enabled:

• Services run in confined domains (SELinux types, AppArmor profiles).
• Access to ports, files, and other resources may be restricted beyond traditional permissions.

Typical interactions:

• A web server allowed to read some directories but not others
• A daemon forbidden from binding to a non‑standard port until a policy is adjusted
• Need to set SELinux booleans for common roles (e.g. “allow httpd to connect to the network”)

When a service starts but cannot access its files or ports, SELinux/AppArmor denials in logs are a common cause.

Service Discovery and Name Resolution

Once services are running, clients need a way to locate them.

Hostnames and DNS

Most network services assume:

• The server has a stable hostname and IP.
• DNS correctly maps:
• A/AAAA records: hostname → IP
• Possibly CNAME aliases used by users

You’ll often:

• Configure services to advertise or verify hostnames (e.g. TLS certificates bound to hostnames).
• Depend on correct DNS entries for clients to reach your services.

Service Discovery in Local Networks

Beyond DNS, small networks may use:

• mDNS / Avahi (hostname.local style names)
• Static /etc/hosts entries
• Application‑level discovery (e.g. broadcast/Bonjour protocols)

These are mostly transparent at the service level, but they influence how clients connect.

Logging and Observability for Network Services

Nearly all daemons log their behavior, and logs are your primary tool for understanding what’s happening.

Typical Logging Destinations

Common patterns:

• Syslog/journald:
• Logs accessible via journalctl -u servicename
• Or in /var/log/messages, /var/log/syslog
• Service‑specific log files:
• Access and error logs for web servers
• Query logs for DNS or databases
• Rotated logs:
• Managed by logrotate (e.g. /etc/logrotate.d/*)
• Compressed older logs with .gz suffix

Network services often generate high‑volume logs (e.g. web access logs), so you’ll see rotation and retention settings tuned to avoid filling disks.

Basic Observability Practices

For any network service:

• Confirm it started without errors via system logs.
• Watch live logs while testing from a client:
• journalctl -u servicename -f
• tail -f /var/log/servicename/*log
• Enable more detailed logging (debug levels) briefly when diagnosing complex issues.

Testing and Troubleshooting Connectivity

When working with network services, you use generic tools to test connectivity regardless of the specific daemon.

Checking if a Service Is Listening

You’ll often verify:

• Port bindings:
• ss -tulpen | grep :PORT
• ss -tulpen | grep servicename
• That the expected protocol is used (TCP vs UDP)
• The bound IP addresses (local‑only vs public)

This complements systemctl status to confirm not only that a daemon is running, but also that it is accessible on the expected ports.

Client‑Side Connectivity Tests

Common tools:

• curl or wget for HTTP(S) services
• Database client CLIs (e.g. psql, mysql) for DB services
• telnet or nc (netcat) for raw TCP connection checks
• Example: nc -vz server.example.com 22
• ping for basic reachability (though ICMP can be blocked while TCP is allowed)

For layer‑4 connectivity, a successful TCP handshake (e.g. “Connection succeeded”) is often enough to know that routing and firewalling are not the problem.

Layer Separation in Troubleshooting

When debugging a service, step through:

1. Process layer: Is the service running (systemctl status)? Any immediate crashes?
2. Socket layer: Is it listening on the expected address/port (ss -tulpen)?
3. Network layer: Can the client reach that IP (routing, ping/traceroute)?
4. Firewall layer: Is traffic allowed on host firewalls and any intermediate firewalls?
5. Application layer: Are credentials correct? Is the protocol configured properly?

Breaking problems down along these layers is crucial with complex stacks.

Security Considerations for Network Services

Because network services accept input from potentially untrusted sources, they are primary security exposure points.

Minimizing Attack Surface

General patterns you’ll apply regardless of the specific daemon:

• Install only the services you need.
• Disable or mask unused network daemons:
• sudo systemctl disable --now some-service
• Restrict listening scope:
• Prefer 127.0.0.1 or internal addresses where external access is not needed.
• Implement network segmentation:
• Expose only public‑facing services to the internet; keep others inside private networks.

Hardening at the Service Level

Typical actions:

• Keep services updated (including dependencies and OS libraries).
• Use TLS/SSL where appropriate; avoid plaintext logins on untrusted networks.
• Use strong authentication mechanisms (keys, strong passwords, multi‑factor where supported).
• Limit brute‑force attempts (e.g. fail2ban‑style rate limiting) where relevant.
• Run services as unprivileged users with minimal filesystem access.

Dedicated chapters later (firewalls in depth, SSH security, database hardening, etc.) cover the details for specific services.

Network Services in Containerized Environments

Increasingly, network services are deployed in containers instead of directly on the host.

Key differences:

• Port mapping:
• Container listens on an internal port (e.g. 0.0.0.0:80 inside container).
• The container runtime maps host ports to container ports (e.g. host :8080 → container :80).
• Isolation:
• Each container has its own network namespace by default.
• Services may be reachable only from other containers unless explicit host mappings are configured.
• Service discovery:
• Orchestration systems (Kubernetes, Docker Compose, Podman pods) provide internal DNS and service names.

The conceptual pieces—listening processes, ports, firewalls, DNS—remain, but the network topology becomes virtualized and more dynamic.

Planning Network Services on a Host

When designing or modifying a server’s network services, it helps to think systematically:

1. Inventory existing services:
• Which daemons are installed, enabled, and listening?
2. Define roles:
• Is this host a web server, DB server, file server, or multi‑role?
3. Assign ports and bindings:
• Avoid collisions and ensure internal/back‑end services don’t unintentionally listen publicly.
4. Plan access control:
• Decide which networks/clients can reach which services.
5. Document:
• Record hostnames, ports, firewall rules, and dependencies between services.

This planning step saves a great deal of time when you later extend, troubleshoot, or secure the system.

Subsequent chapters in this part will walk through configuring specific network services—SSH, NFS, Samba, FTP/SFTP, and firewalls in depth—using the general patterns you’ve seen here.