Survey of Network Services on Unix and Linux Systems

Unix and Linux systems have historically functioned as network servers, providing essential services that enable distributed computing, file sharing, remote administration, email delivery, web hosting, and countless other network operations. Understanding which services a system offers, how they operate, their security implications, and their modern relevance constitutes essential knowledge for system administrators managing contemporary infrastructure.

A network service is a program running on a computer that listens for incoming network connections on specific TCP or UDP ports, processes requests from client systems, and returns responses. Services implement standardized protocols defined in RFCs (Request for Comments documents), enabling interoperability between systems from different vendors running different operating systems. This standardization allowed heterogeneous networks to flourish—a Linux client can access files from a Solaris NFS server, send mail through a BSD SMTP server, and browse websites hosted on Windows IIS servers, all because these services implement common, well-defined protocols.

The landscape of Unix network services has transformed dramatically over the past four decades. Services that were standard in the 1980s and 1990s—TELNET for remote login, FTP for file transfer, RLOGIN and RSH for Berkeley-style remote access—transmitted data and credentials in cleartext, assuming trustworthy network environments. As the internet expanded beyond academic and government networks into commercial use, these assumptions collapsed. Attackers could trivially capture cleartext passwords using packet sniffers, compromise systems, and pivot to attack additional targets.

The security crisis of the late 1990s and early 2000s drove the development and adoption of encrypted alternatives. SSH (Secure Shell) replaced TELNET, RLOGIN, and RSH with authenticated, encrypted remote access. SFTP (SSH File Transfer Protocol) and FTPS (FTP over TLS) replaced cleartext FTP. HTTPS (HTTP Secure) became mandatory for web traffic carrying sensitive data. Modern Unix systems continue offering these legacy services for backward compatibility, but best practices dictate disabling them in favor of secure alternatives.

This lesson surveys both legacy and modern network services, explaining their purposes, architectures, security characteristics, and current relevance. Understanding legacy protocols remains valuable—many organizations operate decades-old systems that still rely on them, and administrators must recognize insecure services to properly harden infrastructure.

Before examining specific services, understanding the common patterns in how network services operate provides context for the entire ecosystem.

Network services bind to specific TCP or UDP ports and listen for incoming connections. Well-known ports (0-1023) are reserved for standard services and require root privileges to bind. Registered ports (1024-49151) are assigned by IANA for specific applications but don't require privileges. Ephemeral ports (49152-65535) are dynamically allocated for client connections.

When a service starts, it:

1. Creates a socket (TCP SOCK_STREAM or UDP SOCK_DGRAM)
2. Binds the socket to its designated port (e.g., port 22 for SSH, port 80 for HTTP)
3. For TCP services, calls listen() to mark the socket as accepting connections
4. Enters a loop calling accept() (TCP) or recvfrom() (UDP) to receive client requests
5. Processes each request according to the protocol specification
6. Sends responses back to the client

This model applies universally—whether examining ancient TELNET servers or modern HTTPS servers, the underlying socket programming patterns remain consistent.

Modern Linux distributions manage network services through systemd, which replaced the older System V init scripts and xinetd/inetd super-servers. Systemd provides:

• Service units: Configuration files defining how to start, stop, and manage services
• Socket activation: Services start on-demand when connections arrive, reducing resource consumption
• Dependency management: Services can depend on other services, ensuring proper startup order
• Resource limits: Memory, CPU, and I/O limits prevent services from consuming excessive resources
• Security sandboxing: Filesystem access controls, capability restrictions, and system call filtering isolate services

Common systemd commands for managing services:

# Check service status
systemctl status service_name

# Start a service
systemctl start service_name

# Stop a service
systemctl stop service_name

# Enable service to start on boot
systemctl enable service_name

# Disable service from starting on boot
systemctl disable service_name

# Restart a service
systemctl restart service_name

# Reload configuration without restarting
systemctl reload service_name

# List all running services
systemctl list-units --type=service --state=running

Administrators must be able to identify which network services are running, which ports they're listening on, and which processes own those sockets. Several tools provide this visibility.

The ss command (socket statistics) is the modern replacement for netstat, providing faster and more detailed socket information:

# Show all listening TCP sockets with process information
ss -tlnp

# Show all listening TCP and UDP sockets
ss -tulnp

# Show established TCP connections
ss -tnp state established

# Show sockets by specific port
ss -tlnp sport = :80

Example output:

State    Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process
LISTEN   0       128     0.0.0.0:22          0.0.0.0:*          users:(("sshd",pid=1234,fd=3))
LISTEN   0       128     0.0.0.0:80          0.0.0.0:*          users:(("nginx",pid=2345,fd=6))
LISTEN   0       128     [::]:22             [::]:*             users:(("sshd",pid=1234,fd=4))
LISTEN   0       128     [::]:80             [::]:*             users:(("nginx",pid=2345,fd=7))

This reveals SSH (port 22) and HTTP (port 80) services listening on both IPv4 and IPv6, with their process names and IDs.

Since "everything is a file" in Unix including network sockets, lsof lists network connections:

# Show all network connections
lsof -i

# Show listening TCP ports
lsof -iTCP -sTCP:LISTEN

# Show what's using a specific port
lsof -i :443

# Show network connections by specific process
lsof -p 1234 -a -i

The /etc/services file maps service names to port numbers and protocols. While not listing running services, it documents well-known port assignments:

# View standard port assignments
grep "^ssh" /etc/services
grep "^http" /etc/services

# Search by port number
grep "22/tcp" /etc/services

Several remote access services were standard on Unix systems for decades but are now considered dangerously insecure and should never be used on networks where security matters.

TELNET (Telecommunication Network) protocol, defined in RFC 854 (1983), provided remote terminal access to Unix systems. A user could telnet to a remote host, authenticate with username and password, and receive a command shell. TELNET implemented a Network Virtual Terminal (NVT) abstraction allowing terminals with different characteristics to communicate, with option negotiation determining terminal type, window size, and other parameters.

Critical Security Flaw: TELNET transmits all data including passwords in cleartext. An attacker with network access can trivially capture credentials using tools like tcpdump or Wireshark:

# Capture TELNET traffic (demonstrates the security problem)
tcpdump -i eth0 -A port 23

Every keystroke—including password characters—appears in the packet capture in readable text.

Modern Replacement: SSH (Secure Shell) on port 22 provides authenticated, encrypted remote access. SSH replaced TELNET entirely in security-conscious environments. TELNET should be disabled on all production systems:

# Disable and stop TELNET service
systemctl stop telnet.socket
systemctl disable telnet.socket
systemctl mask telnet.socket

TELNET remains useful for one specific purpose: manually testing other network services. Since TELNET is just a raw TCP connection, administrators can use TELNET clients to "speak" protocols manually for debugging. For example, connecting to port 80 and typing HTTP commands demonstrates how the protocol works. However, this testing use doesn't require running a TELNET server—only a TELNET client is needed.

The Berkeley "r" commands (so named because they all start with 'r' for "remote") provided alternatives to TELNET with convenience features like automatic authentication based on hostnames and user IDs:

• rlogin (port 513): Remote login similar to TELNET but using trusted host authentication
• rsh (port 514): Remote shell execution—run commands on remote systems without interactive login
• rexec (port 512): Remote execution with password authentication

These services used /etc/hosts.equiv and ~/.rhosts files to define trusted hosts and users. If user "alice" on "hostA" listed in "hostB's" trust files, alice could rlogin or rsh to hostB without password authentication.

Critical Security Flaws:

• Authentication based on IP addresses, easily spoofed
• No encryption—all data transmitted in cleartext
• Trust relationships create security dependencies—compromise of one trusted host compromises all trusting hosts
• Misconfigured .rhosts files (especially with "+" wildcards) create massive security holes

The Morris Worm of 1988, one of the first internet worms, exploited rsh and rexec vulnerabilities to propagate. This demonstrated the danger of trust-based authentication systems.

Modern Replacement: SSH completely replaced the Berkeley r commands. SSH provides:

# SSH replaces rlogin
ssh user@hostname

# SSH replaces rsh
ssh user@hostname 'command args'

# SCP replaces rcp for file copying
scp file user@hostname:/path/

The r commands should be disabled on all systems:

# Disable Berkeley r services
systemctl stop rlogin.socket rsh.socket rexec.socket
systemctl disable rlogin.socket rsh.socket rexec.socket
systemctl mask rlogin.socket rsh.socket rexec.socket

# Remove trust files
rm /etc/hosts.equiv
find /home -name .rhosts -delete

More information: Berkeley "r" commands (rlogin, rsh)

FTP (File Transfer Protocol), defined in RFC 959 (1985), enabled file transfers between systems. FTP uses two connections: a control connection on port 21 for commands and responses, and a data connection (typically port 20 in active mode or ephemeral ports in passive mode) for actual file transfers.

Security Issues:

• Cleartext authentication—usernames and passwords transmitted without encryption
• Cleartext data transfer—file contents readable by network sniffers
• Complex firewall configuration due to dynamic data connections
• Anonymous FTP servers historically targeted for hosting pirated software and malware

Modern Replacements:

• SFTP (SSH File Transfer Protocol): Encrypted file transfer over SSH connections. Not related to FTP despite the name—completely different protocol built on SSH.
• FTPS (FTP Secure): FTP wrapped in TLS encryption. Maintains FTP compatibility while adding security.
• SCP (Secure Copy): Simple encrypted file copying over SSH.
• rsync over SSH: Efficient incremental file synchronization with encryption.
• HTTPS file uploads: Web-based file transfer using standard HTTP/HTTPS.

Organizations should migrate away from cleartext FTP:

# Disable FTP service
systemctl stop vsftpd
systemctl disable vsftpd

# Use SFTP instead
sftp user@hostname

# Or SCP for simple transfers
scp file user@hostname:/path/

More information: FTP Bulk Data Transfer Service

Contemporary Unix systems rely on a core set of network services that provide essential functionality with appropriate security controls.

SSH (Secure Shell), defined in RFC 4250-4254, revolutionized remote administration by providing encrypted, authenticated remote access. SSH replaced TELNET, rlogin, and rsh with a single secure protocol that became the universal standard for Unix remote access.

Key Features:

• Strong Authentication: Password, public key, certificate-based, or multi-factor authentication
• Encryption: All data including authentication credentials encrypted using modern algorithms (AES, ChaCha20)
• Integrity Protection: Cryptographic message authentication prevents tampering
• Port Forwarding: Tunnel other protocols through SSH for secure transmission
• SFTP Subsystem: Secure file transfer built into SSH
• X11 Forwarding: Run graphical applications remotely

SSH server configuration (/etc/ssh/sshd_config) allows fine-grained access control:

# Disable root login via SSH
PermitRootLogin no

# Disable password authentication (require keys)
PasswordAuthentication no
PubkeyAuthentication yes

# Restrict SSH to specific users
AllowUsers alice bob charlie

# Limit authentication attempts
MaxAuthTries 3

# Enable only secure algorithms
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
MACs hmac-sha2-256,hmac-sha2-512
KexAlgorithms curve25519-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384

Check SSH service status:

systemctl status sshd
ss -tlnp | grep :22

DNS (Domain Name System), defined in RFC 1034 and 1035, provides the critical function of translating human-readable domain names (www.example.com) into IP addresses (192.0.2.45) that computers use for communication. Without DNS, users would need to memorize IP addresses for every website and service.

DNS Architecture:

• Authoritative Servers: Provide definitive answers for domains they manage
• Recursive Resolvers: Query on behalf of clients, caching results for performance
• Root Servers: 13 sets of servers (A through M) that provide top-level domain information
• TLD Servers: Servers for top-level domains (.com, .org, .edu, etc.)

Common DNS server software:

• BIND (Berkeley Internet Name Domain): The reference DNS implementation, most widely deployed
• dnsmasq: Lightweight DNS forwarder and DHCP server for small networks
• Unbound: Validating recursive resolver with DNSSEC support
• PowerDNS: Modern authoritative and recursive DNS server

DNS uses both TCP and UDP on port 53. UDP for most queries (fast, stateless), TCP for zone transfers and large responses exceeding UDP's 512-byte limit (now extended to 4096 bytes with EDNS0).

Check DNS service:

systemctl status named  # or bind9 on Debian/Ubuntu
ss -tulnp | grep :53

# Test DNS resolution
dig example.com
nslookup example.com
host example.com

Security Considerations:

• DNSSEC: Cryptographically signs DNS records to prevent spoofing
• DNS over TLS (DoT): Encrypts DNS queries on port 853
• DNS over HTTPS (DoH): Tunnels DNS through HTTPS connections
• Rate Limiting: Prevents DNS amplification attacks
• Access Controls: Restrict recursive queries to authorized networks

HTTP (Hypertext Transfer Protocol), defined in RFC 2616 for HTTP/1.1 and RFC 7540 for HTTP/2, powers the World Wide Web. Web servers listen on port 80 (HTTP) and port 443 (HTTPS) to serve web pages, APIs, and web applications.

HTTP Evolution:

• HTTP/0.9 (1991): Single-line protocol, GET only
• HTTP/1.0 (1996): Headers, methods (GET, POST, HEAD), status codes
• HTTP/1.1 (1997): Persistent connections, chunked encoding, caching
• HTTP/2 (2015): Binary protocol, multiplexing, header compression, server push
• HTTP/3 (2022): Based on QUIC (UDP), improved performance, better mobile experience

Common web servers on Unix/Linux:

• Apache HTTP Server: Most widely deployed web server historically, highly extensible
• Nginx: High-performance web server and reverse proxy, event-driven architecture
• Lighttpd: Lightweight server optimized for speed
• Caddy: Modern server with automatic HTTPS via Let's Encrypt

HTTPS (HTTP Secure):
HTTPS encrypts HTTP traffic using TLS (Transport Layer Security), protecting data in transit from eavesdropping and tampering. Modern browsers mark HTTP sites as "Not Secure" and web standards mandate HTTPS for sensitive operations.

Check web service status:

systemctl status nginx  # or apache2/httpd
ss -tlnp | grep -E ':(80|443)'

# Test HTTP/HTTPS
curl -I http://localhost
curl -I https://localhost

Modern Web Service Security:

• TLS 1.3: Latest protocol version with improved security and performance
• HSTS (HTTP Strict Transport Security): Forces browsers to use HTTPS
• Certificate Transparency: Public logs of TLS certificates prevent misissuance
• Content Security Policy (CSP): Prevents XSS attacks
• Rate Limiting: Prevents abuse and DDoS attacks

SMTP (Simple Mail Transfer Protocol), defined in RFC 5321, handles email transmission between mail servers. Email delivery involves multiple protocols working together:

• SMTP (port 25): Server-to-server mail relay
• SMTP Submission (port 587): Client-to-server email submission with authentication
• SMTPS (port 465): SMTP over TLS (deprecated but still used)
• POP3 (port 110): Client downloads mail from server
• IMAP (port 143): Client synchronizes with server-side mail storage

Common mail transfer agents (MTAs) on Unix:

• Postfix: Modern, secure MTA designed as Sendmail replacement
• Sendmail: Original Unix MTA, complex configuration
• Exim: Flexible MTA popular in UK and Europe
• Qmail: Security-focused MTA with modular design

Email security enhancements:

• SPF (Sender Policy Framework): DNS records specify authorized sending servers
• DKIM (DomainKeys Identified Mail): Cryptographic email signing
• DMARC (Domain-based Message Authentication): Policy framework building on SPF and DKIM
• TLS Encryption: STARTTLS upgrades plaintext connections to encrypted
• Authentication: SASL authentication for submission prevents unauthorized relay

Check mail service:

systemctl status postfix
ss -tlnp | grep -E ':(25|587|465)'

# Test SMTP
telnet localhost 25
# Then type: EHLO localhost

More information: Simple Mail Transfer Protocol (SMTP)

Several other services appear on Unix systems for specific purposes or as legacy holdovers from earlier eras.

NTP (Network Time Protocol), defined in RFC 5905, synchronizes system clocks across networks. Accurate time is critical for:

• Log file correlation across multiple systems
• Cryptographic operations (certificate validity periods)
• Distributed system coordination
• Financial transactions requiring timestamps
• Forensic investigation of security incidents

NTP achieves millisecond accuracy over internet paths and microsecond accuracy on LANs through statistical algorithms that account for network delay variations.

Modern systems often use chronyd (part of Chrony project) or traditional ntpd:

systemctl status chronyd  # or ntpd

# Check time synchronization status
chronyc tracking
ntpq -p

SNMP (Simple Network Management Protocol), defined in RFC 3411-3418, enables network management systems to monitor and configure network devices. Network administrators query SNMP agents running on routers, switches, servers, and other devices to collect metrics (CPU usage, interface statistics, temperature sensors) and receive traps (alerts about significant events).

SNMP versions:

• SNMPv1: Original protocol, cleartext community strings (insecure)
• SNMPv2c: Improved efficiency, still cleartext authentication
• SNMPv3: Adds authentication and encryption, secure

Only SNMPv3 should be deployed on untrusted networks. SNMPv1 and v2c transmit community strings (essentially passwords) in cleartext.

NNTP (Network News Transfer Protocol), defined in RFC 3977, powers Usenet newsgroups—a distributed discussion system that predates web forums. Newsgroups organized messages into hierarchical categories (comp.*, sci.*, alt.*) and servers exchanged articles through flooding algorithms that propagated posts across thousands of servers worldwide.

Usenet thrived in the 1980s and 1990s as a primary internet communication medium. However, web forums, mailing lists, Reddit, Discord, and other modern platforms largely displaced Usenet. NNTP servers still operate for niche technical discussions and binary file distribution, but the protocol's relevance has declined dramatically.

More information: Network News Transfer Protocol (NNTP)

The X Window System (X11 or simply X) provides graphical user interfaces on Unix systems. Unlike Windows or macOS where the GUI is local, X11 uses a client-server architecture where the X server runs on the machine with the display and keyboard, and X clients (applications) can run on remote machines.

X11 traditionally used TCP ports starting at 6000 (display :0 uses port 6000, display :1 uses 6001, etc.). However, network-transparent X11 has largely been replaced by:

• X11 forwarding over SSH: Tunnel X11 through encrypted SSH connections
• VNC (Virtual Network Computing): Platform-independent remote desktop
• RDP (Remote Desktop Protocol): Microsoft's remote desktop protocol
• Wayland: Modern display server protocol replacing X11 locally

Direct X11 network connections are insecure (no encryption, weak authentication) and rarely used today. SSH X11 forwarding provides the same functionality securely:

# Enable X11 forwarding in SSH
ssh -X user@hostname

# Run graphical application
xclock &
firefox &

More information: X Protocol Graphical Display

Several extremely simple services exist primarily for network testing and debugging:

• echo (port 7 TCP/UDP): Returns whatever data it receives, useful for testing connectivity
• discard (port 9 TCP/UDP): Accepts and discards all data, useful for throughput testing
• daytime (port 13 TCP/UDP): Returns human-readable date and time
• time (port 37 TCP/UDP): Returns time as 32-bit integer (seconds since 1900)
• chargen (port 19 TCP/UDP): Generates continuous stream of characters

These services are typically disabled by default on modern systems as they can be exploited for amplification attacks. However, administrators can temporarily enable them for troubleshooting:

# Test echo service
echo "Hello World" | nc localhost 7

# Test daytime service
nc localhost 13

Securing network services requires multiple layers of defense implementing the principle of defense in depth—no single security mechanism is sufficient.

Only run services that are actually needed. Every running service represents potential attack surface. Audit systems regularly:

# List all active services
systemctl list-units --type=service --state=running

# Disable unnecessary services
systemctl disable service_name
systemctl stop service_name

Use host-based firewalls (firewalld, iptables, nftables) to restrict which services accept connections from which networks:

# Example: Allow SSH only from specific network
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" service name="ssh" accept'
firewall-cmd --reload

# Or with iptables
iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

Services compiled with libwrap support honor /etc/hosts.allow and /etc/hosts.deny for access control:

# /etc/hosts.allow - allow SSH from local network
sshd: 192.168.1.0/255.255.255.0

# /etc/hosts.deny - deny all others
sshd: ALL

Mandatory Access Control systems confine services, limiting damage if compromised:

# Check SELinux status
sestatus
getenforce

# View SELinux context of running service
ps auxZ | grep sshd

# AppArmor status
aa-status

Keep services updated with security patches:

# Update all packages (Debian/Ubuntu)
apt update && apt upgrade

# Update all packages (RHEL/CentOS/Fedora)
dnf update

# Enable automatic security updates
apt install unattended-upgrades  # Debian/Ubuntu
dnf install dnf-automatic && systemctl enable --now dnf-automatic.timer  # Fedora

Administrators should regularly audit which services are running and assess their necessity and security posture.

# List all active services
systemctl list-units --type=service --state=running --no-pager

# List all listening sockets
ss -tulnp | grep LISTEN

For each service, determine:

• What does this service do?
• Who needs access to it?
• Is it still required?
• What are the security implications?

# View service configuration
systemctl cat service_name

# Check service status and recent logs
systemctl status service_name
journalctl -u service_name -n 100

# Check firewall rules
firewall-cmd --list-all

# Check SELinux denials
ausearch -m avc -ts recent

# Review listening ports
ss -tulnp

Maintain documentation of:

• Which services run on which systems
• Purpose and business justification for each
• Access control requirements
• Configuration standards
• Responsible parties and contacts

Unix and Linux systems offer a rich ecosystem of network services spanning four decades of development. Understanding this landscape requires knowledge of both historical context and modern practice. Legacy protocols like TELNET, FTP, and the Berkeley r commands served critical roles in Unix's networking heritage but are now dangerous anachronisms that must be disabled in favor of secure alternatives like SSH, SFTP, and HTTPS.

Modern essential services—SSH for remote access, DNS for name resolution, HTTP/HTTPS for web services, and SMTP for email—form the foundation of contemporary networked Unix systems. Each requires proper configuration, regular updates, access controls, and monitoring to maintain security.

Administrators must regularly audit running services, understanding which are necessary, which represent excessive attack surface, and how to properly configure and secure each. The tools examined in this lesson—systemctl, ss, lsof, firewall-cmd—provide the visibility needed to manage service infrastructure effectively.

The evolution from insecure cleartext protocols to encrypted alternatives reflects the broader maturation of internet security over the past three decades. Modern administrators must maintain this security posture, disabling legacy protocols, enforcing encryption, implementing defense in depth, and staying current with emerging threats and mitigations. The services running on Unix systems form the connective tissue of internet infrastructure; securing them properly is fundamental to maintaining trustworthy systems in an increasingly hostile threat environment.

[1] Domain Name System (DNS): The Domain Name System is the internet's distributed hierarchical naming system that translates human-readable domain names (like www.example.com) into IP addresses (like 192.0.2.1) that computers use to identify each other on networks. DNS operates through a hierarchy of servers starting from root servers, through top-level domain (TLD) servers (.com, .org, .edu), down to authoritative name servers for specific domains. This distributed architecture prevents any single point of failure and scales to handle billions of daily queries across the global internet.