This guide covers both sides of that coin: the routine, low-risk path (upgrading via your distribution’s package manager) and the deep-end path (fetching kernel source, configuring it, and compiling your own).

Why You’d Upgrade or Rebuild a Kernel at All

Three distinct motivations come up in practice:

1. Security and bug fixes. CVEs land in the kernel constantly — privilege escalation bugs, use-after-free bugs in drivers, netfilter issues. Distro vendors backport fixes into their “stable” kernel branch, and a routine apt upgrade or dnf update picks those up.
2. Hardware support. New NICs, new NVMe controllers, new GPUs — sometimes the driver only exists in a kernel version newer than what your distro ships, especially on LTS distros like Ubuntu 24.04 LTS or RHEL 9, which intentionally freeze kernel versions for stability.
3. Custom builds. You need a kernel feature disabled by default, you’re building an embedded or minimal image, you’re doing kernel development, or you want to apply a patch that isn’t in the distro’s tree.

For the first two reasons, package-manager upgrades cover the vast majority of situations. Reason three is where a full source rebuild becomes worthwhile.

Checking Your Current Kernel

Before touching anything, know exactly what you’re running:

uname -r
# 6.8.0-31-generic

uname -a
# Linux myserver 6.8.0-31-generic #31-Ubuntu SMP PREEMPT_DYNAMIC ... x86_64 GNU/Linux

cat /proc/version

On RHEL-family systems, rpm -q kernel lists installed kernel packages, since RHEL keeps several kernels installed side by side:

rpm -q kernel
# kernel-5.14.0-427.13.1.el9_4.x86_64

Method 1: Upgrading the Kernel via Package Manager (Recommended for Most Cases)

This is the path I use unless I have a specific reason not to. It’s tested by the distro, signed, and integrates cleanly with your bootloader and initramfs.

Debian / Ubuntu

sudo apt update
sudo apt list --upgradable | grep linux-image
sudo apt install linux-generic linux-headers-generic

Ubuntu also supports mainline kernel builds for bleeding-edge (non-LTS) kernels through a dedicated helper tool:

sudo add-apt-repository ppa:cappelikan/ppa
sudo apt update
sudo apt install mainline
mainline           # GUI/CLI tool to list and install upstream kernels

I’d caution against installing raw mainline .deb kernels from kernel.ubuntu.com on a production box — they’re unsigned, unsupported, and not integrated with Ubuntu’s Secure Boot chain. Fine for a test VM, risky for anything you can’t afford to lose.

RHEL / CentOS Stream / Fedora / Rocky / AlmaLinux

sudo dnf check-update kernel
sudo dnf update kernel

RHEL-family distros keep multiple kernels installed by default (usually 2-3), controlled by installonly_limit in /etc/dnf/dnf.conf. This is deliberate — if a new kernel fails to boot, you fall back to the previous one from the GRUB menu without any recovery media.

For Fedora specifically, which ships new kernel versions far more aggressively than RHEL:

sudo dnf upgrade --refresh

After the Package-Manager Upgrade

sudo reboot
uname -r   # confirm the new version is running

If it’s not the version you expect, check the default GRUB entry:

sudo grubby --default-kernel        # RHEL family
grep GRUB_DEFAULT /etc/default/grub  # Debian family

Method 2: Building the Kernel from Source

This is the deep-end approach. I’d only recommend it if you actually need something a stock kernel can’t give you, and I’d always do the first attempt on a VM or spare machine, never a production server you can’t get physical/console access to.

Step 1: Install Build Dependencies

Debian/Ubuntu:

sudo apt update
sudo apt install build-essential libncurses-dev bison flex libssl-dev \
    libelf-dev bc dwarves git fakeroot

RHEL/Fedora:

sudo dnf groupinstall "Development Tools"
sudo dnf install ncurses-devel bison flex openssl-devel elfutils-libelf-devel \
    bc dwarves rpm-build

libssl-dev/openssl-devel matters more than people expect — modern kernels sign modules during the build, and that step fails silently-ish without OpenSSL headers.

Step 2: Get the Kernel Source

Two common routes: pull the distro’s source package (safer, matches what you’re already running plus distro patches), or pull vanilla upstream from kernel.org (for the newest features or if you’re doing kernel development).

Vanilla source:

cd /usr/src
sudo git clone --depth 1 --branch v6.9 https://github.com/torvalds/linux.git
cd linux

Or download a release tarball directly:

wget https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.9.tar.xz
tar xf linux-6.9.tar.xz
cd linux-6.9

Step 3: Configure the Kernel

Don’t start from a blank config. Start from your running kernel’s config so you inherit a sane baseline:

zcat /proc/config.gz > .config       # if your kernel exposes /proc/config.gz
# or, if not available:
cp /boot/config-$(uname -r) .config

Then bring it up to date for the new source tree and choose defaults for anything new:

make olddefconfig

To actually customize options — enabling a driver, disabling something you don’t need, turning on a debug feature — use the interactive menu:

make menuconfig

This opens an ncurses UI organized into categories (Processor type, Device Drivers, Networking support, and so on). Search with / inside the menu to jump straight to an option by name — much faster than digging through submenus by hand.

Other config front-ends exist:

make xconfig     # Qt-based GUI, needs X11 and qt5 dev packages
make nconfig     # newer ncurses UI, arguably nicer than menuconfig
make defconfig   # generate a distro-default config from scratch (loses your customizations)

Step 4: Build

make -j$(nproc)

-j$(nproc) parallelizes the build across all CPU cores — on a modern multi-core machine this is the difference between a 45-minute build and a 6-hour one. On memory-constrained VMs, watch out: too many parallel jobs on too little RAM causes the compiler to OOM. A rough rule I use: don’t exceed 1.5 jobs per GB of RAM for a full kernel build.

Build the modules:

make modules -j$(nproc)

Step 5: Install

sudo make modules_install
sudo make install

make install on most distros will:

• Copy the new kernel image into /boot
• Generate a new initramfs (via dracut on RHEL-family, update-initramfs on Debian-family)
• Update the GRUB configuration automatically

If it doesn’t call these hooks automatically (common when building raw upstream source rather than a distro’s kernel package), do it manually:

Debian/Ubuntu:

sudo update-initramfs -c -k 6.9.0
sudo update-grub

RHEL/Fedora:

sudo dracut --force /boot/initramfs-6.9.0.img 6.9.0
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Step 6: Building a Distro Package Instead of Raw Install (Recommended for RHEL)

Rather than a raw make install, I generally prefer building an actual .rpm or .deb so the kernel is tracked by the package manager, uninstalls cleanly, and coexists properly with other installed kernels.

RHEL/Fedora:

make rpm-pkg
sudo rpm -ivh ~/rpmbuild/RPMS/x86_64/kernel-6.9.0*.rpm

Debian/Ubuntu:

make bindeb-pkg -j$(nproc)
sudo dpkg -i linux-image-6.9.0*.deb linux-headers-6.9.0*.deb

Step 7: Reboot and Verify

sudo reboot
uname -r
dmesg | less     # check for driver/module errors on the new kernel

Kernel Internals: What Actually Happens During a Build

Understanding the pipeline helps when a build fails halfway through:

1. Configuration produces .config, which drives conditional compilation via preprocessor macros (CONFIG_* symbols) throughout the source tree.
2. Kbuild, the kernel’s own build system layered on GNU Make, walks the tree and compiles each subsystem — process scheduler, memory management, VFS, networking stack, and every driver marked =y or =m in the config.
3. Anything marked =m becomes a loadable kernel module (a .ko file), compiled separately and installed under /lib/modules/$(uname -r)/.
4. The final image is linked and, on most modern distros, compressed (bzImage on x86_64) and optionally signed for Secure Boot.
5. depmod builds the module dependency map so modprobe can resolve dependencies at load time.
6. The bootloader config is regenerated so the new kernel entry appears in the GRUB menu, normally as the new default while the old kernel remains as a fallback entry.

Managing Multiple Installed Kernels

RHEL-family systems handle this natively:

sudo grubby --default-kernel                 # show current default
sudo grubby --set-default /boot/vmlinuz-5.14.0-427.13.1.el9_4.x86_64
sudo dnf remove kernel-5.14.0-284.el9.x86_64  # remove an old one explicitly

On Debian/Ubuntu, old kernels accumulate under /boot and can be cleaned up with:

sudo apt autoremove --purge
dpkg -l | grep linux-image      # see what's installed

I always keep at least one known-good older kernel around until I’ve confirmed the new one is stable under real load for at least a few days.

Troubleshooting

System won’t boot after upgrade — at the GRUB menu, select “Advanced options” and boot the previous kernel. Then investigate before trying again.

Missing module after custom build — usually means make modules_install wasn’t run, or the initramfs wasn’t regenerated to include a module needed at boot (like a storage controller driver). Check with:

lsinitrd /boot/initramfs-$(uname -r).img | grep module_name   # RHEL/dracut
lsinitramfs /boot/initrd.img-$(uname -r) | grep module_name   # Debian

Build fails on missing OpenSSL/cert error — modern kernels attempt to sign modules by default. Either install the OpenSSL dev headers (see Step 1) or disable module signing in menuconfig under Cryptographic API -> Certificates for signature checking.

Build fails with “No rule to make target” on menuconfig — usually a missing libncurses-dev/ncurses-devel, since the config UI is ncurses-based.

dmesg full of “unknown symbol” for a module — the module was built against a different kernel ABI than what’s currently running; rebuild the module against the exact running kernel’s headers.

Performance and Security Considerations

A custom-built kernel gives you levers a stock kernel doesn’t:

• Stripping unused drivers reduces attack surface and shrinks the compiled image, which matters for embedded/container-host use cases.
• You can disable debug options (CONFIG_DEBUG_*) that carry a measurable performance cost on production hardware.
• You can enable hardening options — CONFIG_STACKPROTECTOR_STRONG, CONFIG_FORTIFY_SOURCE, KASLR — some of which distro kernels already ship enabled, but not all.
• Custom builds mean you’re now responsible for tracking upstream CVEs yourself instead of relying on your distro’s security team. That’s a real ongoing cost, not a one-time decision.

Kernel Versioning and Release Cadence

Understanding how upstream kernel releases and distro release cycles relate helps explain why the “right” upgrade approach differs so much between distros. Upstream kernel.org follows roughly a 9-10 week release cycle for mainline versions, with a subset designated “longterm” (LTS) and maintained with backported fixes for several years. Distros pick one of these versions and then diverge:

• Ubuntu LTS (like 24.04) ships with a specific kernel at release, then periodically rebases to a newer HWE (Hardware Enablement) kernel partway through its lifecycle for newer hardware support, while still backporting security fixes to the original kernel branch throughout.
• RHEL takes a single upstream kernel version at major release time (e.g., RHEL 9 started on a 5.14 base) and then backports fixes and features into that exact version for the entire product lifecycle — meaning uname -r on RHEL can look “old” by upstream numbering while actually containing years of backported fixes invisible from the version string alone.
• Fedora tracks upstream far more aggressively, often within one or two mainline releases of the very latest kernel.

This is worth internalizing because comparing “kernel versions” across distros by number alone is misleading — a RHEL 5.14-based kernel from 2026 may contain security fixes that a naive comparison against a vanilla 5.14 release from years earlier would miss entirely. Check a distro’s actual changelog rather than assuming version number equals patch level.

rpm -q --changelog kernel | head -40

Understanding Kernel Module Signing and Secure Boot

If Secure Boot is enabled (common on modern hardware by default), the kernel and any modules it loads must be signed by a key the firmware trusts, or the system will refuse to boot the kernel or refuse to load the unsigned module.

Check Secure Boot status:

mokutil --sb-state

Distro-provided kernels are signed against a key chain that’s already enrolled in most firmware (via Microsoft’s UEFI signing service, for distros that go through that process, like Ubuntu and Fedora). A custom-built kernel is not signed against any key your firmware already trusts, which means either:

1. Disable Secure Boot in firmware settings (simplest, but weakens a real security boundary), or
2. Generate your own signing key, sign the kernel and any out-of-tree modules with it, and enroll that key into the firmware’s Machine Owner Key (MOK) database.

# Generate a signing key
openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=My Custom Kernel Signing Key/"

# Sign the kernel image
sudo /usr/src/linux-6.9/scripts/sign-file sha256 MOK.priv MOK.der /boot/vmlinuz-6.9.0

# Enroll the key with the firmware (prompts for a password used during the next boot's MOK enrollment)
sudo mokutil --import MOK.der
sudo reboot

On reboot, the firmware’s MOK management screen appears automatically, where you confirm enrollment using the password you set. Skipping this step on a Secure Boot system is the single most common reason a freshly built custom kernel simply refuses to boot with no obvious error message beyond a generic “not trusted” screen.

Kernel Command Line Parameters

Beyond the kernel image itself, boot-time parameters (passed via GRUB) control significant runtime behavior without requiring a rebuild:

cat /proc/cmdline

Common parameters worth knowing:

quiet splash                  # suppress boot messages, show splash screen
nomodeset                     # disable kernel mode setting (useful for graphics driver troubleshooting)
mem=4G                        # artificially cap visible memory (testing/debugging)
nosmp                         # disable multi-core support (extreme troubleshooting only)
systemd.unified_cgroup_hierarchy=1   # force cgroup v2

Edit persistently via GRUB config:

sudo nano /etc/default/grub
# Modify GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"
sudo update-grub          # Debian/Ubuntu
sudo grub2-mkconfig -o /boot/grub2/grub.cfg   # RHEL/Fedora

Real-World Example: Enabling a Specific Feature via Custom Build

A concrete scenario where a custom build genuinely earns its complexity: enabling CONFIG_USER_NS combined with specific unprivileged namespace restrictions for a container-hosting use case where the distro’s default kernel ships a restrictive default that blocks what you need.

# Check current setting
grep CONFIG_USER_NS /boot/config-$(uname -r)

# In menuconfig, this lives under:
# General setup -> Namespaces support -> UTS namespace / User namespace / ...
make menuconfig
# Navigate: General setup ---> [*] Namespaces support ---> [*] User namespace

This is a genuinely narrow use case — most people running containers do so on a stock distro kernel without any custom build at all, since mainstream distro kernels already enable the namespace features container runtimes need. Custom builds for this reason usually only make sense in specialized embedded, security-research, or kernel-development contexts.

Comparing Kernel Upgrade Approaches Across Distros

Summary

Package-manager kernel upgrades are the right default for nearly everyone — they’re tested, signed, and safe to roll back. Building from source is a specialized tool for specific situations: custom hardware support, kernel development, stripped-down images, or features a distro kernel disables. Either way, the fundamentals are the same: know your current version, keep a fallback kernel available, regenerate your initramfs and bootloader config, and verify with dmesg after reboot before you call it done.

References

• The Linux Kernel Archives
• Linux Kernel Documentation – Building the kernel
• Ubuntu Kernel documentation
• Red Hat Documentation – Managing kernels
• Debian Kernel Handbook

The post How to Upgrade and Rebuild the Linux Kernel: Complete Step-by-Step Guide appeared first on Abdul Wahab Junaid.

This guide covers the full command structure: tables, chains, targets, matches, and how to build a firewall ruleset that actually behaves the way you expect.

How iptables Fits Into the Kernel

iptables itself is just a userspace configuration tool. The actual packet filtering happens inside the kernel’s netfilter subsystem, which defines a series of hook points in the network stack: PREROUTING, INPUT, FORWARD, OUTPUT, and POSTROUTING. Every packet that passes through the kernel’s networking code passes through one or more of these hooks, and each hook corresponds to a chain that iptables lets you attach rules to.

On modern kernels (post-3.13), the classic iptables binary is often really just a compatibility shim (iptables-nft) that translates your commands into nftables rules, while iptables-legacy still exists using the old x_tables kernel API directly. You can check which backend you’re on:

iptables --version
# iptables v1.8.10 (nf_tables)   <- this system is using the nft backend

Tables

iptables organizes rules into tables, each meant for a different kind of packet manipulation:

If you don’t specify -t, iptables assumes filter.

Chains

Each table has built-in chains tied to netfilter hook points:

• PREROUTING — packets as they arrive, before routing decisions (nat, mangle, raw)
• INPUT — packets destined for the local machine (filter, mangle)
• FORWARD — packets being routed through this machine to somewhere else (filter, mangle)
• OUTPUT — packets generated locally (filter, nat, mangle, raw)
• POSTROUTING — packets about to leave the interface, after routing (nat, mangle)

You can also define your own custom chains for organization, which is genuinely useful once your ruleset grows past a dozen rules.

Basic Syntax

iptables [-t table] COMMAND CHAIN RULE-SPEC [-j TARGET]

Core Commands

iptables -A INPUT ...     # Append a rule to the end of a chain
iptables -I INPUT 1 ...   # Insert a rule at a specific position (here, position 1)
iptables -D INPUT 3       # Delete rule number 3 from INPUT
iptables -R INPUT 2 ...   # Replace rule number 2
iptables -L               # List rules
iptables -F               # Flush (delete) all rules in a chain (or all chains if none specified)
iptables -P INPUT DROP    # Set the default policy for a chain
iptables -N LOGGING       # Create a new custom chain
iptables -X LOGGING       # Delete a custom chain (must be empty and unreferenced)
iptables -Z               # Zero the packet/byte counters

Listing Rules Usefully

iptables -L -n -v --line-numbers

• -n — numeric output (skip DNS/service-name resolution, much faster and clearer)
• -v — verbose (shows packet/byte counters and interface names)
• --line-numbers — shows rule numbers, essential for using -D or -I precisely

Example output:

Chain INPUT (policy DROP 152 packets, 9120 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     0    --  lo     *       0.0.0.0/0            0.0.0.0/0
2       48  3840 ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
3        0     0 ACCEPT     6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22

Match Criteria (Rule Specifications)

Protocol and Ports

iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --sport 1024:65535 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 80,443,8080 -j ACCEPT

Source / Destination

iptables -A INPUT -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -s 10.0.0.5 -d 10.0.0.10 -j ACCEPT
iptables -A INPUT ! -s 192.168.1.0/24 -j DROP   # negation with !

Interfaces

iptables -A INPUT -i eth0 -j ACCEPT     # incoming interface
iptables -A OUTPUT -o eth1 -j ACCEPT    # outgoing interface

Connection State (via conntrack)

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m conntrack --ctstate NEW -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

This is arguably the single most important rule pattern in any stateful firewall — accept ESTABLISHED/RELATED traffic early so you don’t have to write separate rules for return traffic on every connection.

ICMP

iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT

Rate Limiting

iptables -A INPUT -p tcp --dport 22 -m limit --limit 5/minute --limit-burst 10 -j ACCEPT

Useful as a crude brute-force mitigation on SSH before you set up something more robust like fail2ban.

Targets

-j ACCEPT     # allow the packet
-j DROP       # silently discard the packet
-j REJECT     # discard and send back an error (ICMP unreachable or TCP RST)
-j LOG        # log the packet via the kernel log, then continue processing (does not stop the chain)
-j SNAT       # source NAT (nat table, POSTROUTING)
-j DNAT       # destination NAT (nat table, PREROUTING)
-j MASQUERADE # dynamic SNAT for interfaces with changing IPs (nat table, POSTROUTING)
-j RETURN     # stop processing this chain, return to the calling chain

DROP vs REJECT is a real design decision: DROP makes port scans slower (the scanner waits for a timeout) but can look like network trouble to legitimate clients; REJECT responds immediately with a clear “connection refused,” which is friendlier for internal networks but reveals a host is alive.

Logging example:

iptables -A INPUT -p tcp --dport 22 -j LOG --log-prefix "SSH-ATTEMPT: " --log-level 4
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

LOG doesn’t terminate rule processing, so you always need a following ACCEPT/DROP/REJECT rule to actually decide the packet’s fate.

Building a Complete Basic Firewall

This is the pattern I reach for on nearly every fresh server:

# Flush existing rules
iptables -F
iptables -X

# Set default policies: deny everything unless explicitly allowed
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Allow loopback traffic
iptables -A INPUT -i lo -j ACCEPT

# Allow established/related connections
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow SSH, HTTP, HTTPS
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Allow ping
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# Log and drop everything else
iptables -A INPUT -j LOG --log-prefix "IPT-DROPPED: "
iptables -A INPUT -j DROP

I verified this exact ruleset builds correctly, applies in order, and lists with proper line numbers on a live Ubuntu 24.04 system running the nf_tables iptables backend.

Saving and Restoring Rules

iptables rules live only in kernel memory — they vanish on reboot unless you persist them.

iptables-save > /etc/iptables/rules.v4
iptables-restore < /etc/iptables/rules.v4

Debian/Ubuntu — install iptables-persistent to auto-load rules at boot:

sudo apt install iptables-persistent
sudo netfilter-persistent save
sudo netfilter-persistent reload

RHEL/Fedora — the iptables-services package provides a systemd unit:

sudo dnf install iptables-services
sudo systemctl enable iptables
sudo service iptables save

Note that RHEL 8+ and Fedora default to firewalld as the front-end firewall manager, which itself manages nftables/iptables rules underneath. Running raw iptables alongside firewalld on the same box is a common source of confusing, conflicting rules — pick one management layer.

Comparing iptables, nftables, ufw, and firewalld

• iptables — the classic tool, extremely well documented, works everywhere, syntax gets verbose for complex rulesets.
• nftables — the modern kernel framework and its own nft command, more efficient rule evaluation, unified IPv4/IPv6 syntax, but a different (and to many, less familiar) syntax.
• ufw — a friendly wrapper around iptables/nftables aimed at simplicity, standard on Ubuntu desktop and common on Ubuntu servers.
• firewalld — a dynamic, zone-based firewall manager standard on RHEL/Fedora/CentOS, backed by nftables on modern versions.

For a single, simple server, ufw or firewalld will get you there faster. For fine-grained control, scripting, and understanding exactly what’s happening at the packet level, raw iptables/nft is worth knowing properly.

How Rule Evaluation Actually Works Internally

A detail that clears up a lot of confusion: for every packet, netfilter walks the relevant chain top to bottom, evaluating each rule’s match criteria in order. The moment a rule matches and its target is a “terminating” target (ACCEPT, DROP, REJECT), evaluation of that chain stops immediately — later rules in the same chain are never even consulted for that packet. Non-terminating targets like LOG don’t stop evaluation; the packet continues to the next rule after being logged.

This is why rule order is just as important as rule content. A DROP rule sitting above an ACCEPT rule for the same traffic wins, full stop, regardless of how correct the ACCEPT rule looks in isolation. When debugging “my rule isn’t working,” the very first thing to check is always whether something earlier in the chain already terminated processing for that packet.

iptables -L INPUT -n -v --line-numbers

The pkts and bytes counters shown with -v are genuinely useful here — a rule with a zero packet count after traffic you expect to match it has definitely not been the one handling that traffic, telling you the match is happening somewhere else (or not at all).

The Extension/Match Module System

Everything after -m in a rule invokes a kernel module that extends what iptables can match on beyond basic protocol/port/address. This is a genuinely extensible system, and knowing a few of the more useful matches beyond conntrack opens up a lot of capability:

# Match based on time of day
iptables -A INPUT -m time --timestart 09:00 --timestop 18:00 -p tcp --dport 8080 -j ACCEPT

# Match based on how many connections a single source IP currently has open
iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 20 -j DROP

# Match a specific TCP flag combination directly (rather than via conntrack state)
iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN,RST SYN -j ACCEPT

# Match based on packet size (unusual, but useful for spotting certain attack patterns)
iptables -A INPUT -p udp -m length --length 1400:65535 -j DROP

# Match a whole address list maintained dynamically (used heavily by fail2ban)
iptables -A INPUT -m set --match-set blocklist src -j DROP

That last example, -m set, pairs with ipset — a companion tool for managing large, efficiently-indexed lists of addresses that would be painfully slow to represent as individual iptables rules:

sudo apt install ipset
ipset create blocklist hash:ip
ipset add blocklist 203.0.113.99
iptables -I INPUT -m set --match-set blocklist src -j DROP

Tools like fail2ban commonly use ipset under the hood for exactly this reason — checking membership in a hash set scales far better than iptables evaluating hundreds of individual per-IP rules linearly.

Handling Fragmented Packets and Common Evasion Patterns

A subtlety worth knowing: by default, only the first fragment of a fragmented packet carries full Layer 4 header information (source/destination port), which means match criteria like --dport may not apply as expected to later fragments of the same original packet. This has historically been used as a firewall evasion technique.

# Explicitly handle fragments — a conservative default is to drop them outright on inbound
# unless you have a specific documented need for fragmented traffic
iptables -A INPUT -f -j DROP

Most modern conntrack implementations reassemble fragments before your filter rules ever see them, largely neutralizing this as a practical evasion vector on current kernels — but it’s still worth knowing the underlying mechanism, especially if you’re working with an older kernel or reviewing an inherited ruleset that includes explicit fragment handling.

A Deeper Look at REJECT Response Types

REJECT isn’t a single behavior — it supports different rejection messages via --reject-with, which matters for how a blocked connection actually appears to the other end:

iptables -A INPUT -p tcp --dport 8080 -j REJECT --reject-with tcp-reset
iptables -A INPUT -p udp --dport 8080 -j REJECT --reject-with icmp-port-unreachable
iptables -A INPUT -j REJECT --reject-with icmp-host-prohibited

tcp-reset is often the most honest choice for TCP services you’re intentionally blocking (rather than one that doesn’t exist) — it tells the connecting client immediately and unambiguously that the connection was refused, rather than leaving them to wait for a timeout as DROP would.

Auditing an Existing Ruleset You Didn’t Write

A situation that comes up constantly in practice: inheriting a server with an iptables ruleset nobody documented. A methodical read-through:

# Get the full picture in one readable pass
iptables-save

# Check for any custom chains and where they're referenced from
iptables -L -n | grep "^Chain"

# Check what's actually being hit (non-zero counters) vs dead rules
iptables -L -n -v | awk '$1 != "0" {print}'

Rules with zero packet counts after the system has been running for a while under normal traffic are worth scrutinizing — they might be defending against a threat that no longer applies, referencing an IP that’s since changed, or simply dead weight left over from a service that was decommissioned.

Comparing Rule-Writing Approaches: iptables vs nft Syntax Side by Side

Since the underlying nf_tables engine is what’s actually running under iptables-nft on modern systems anyway, it’s worth seeing the same rule expressed both ways, since you’ll likely encounter both in documentation and inherited configs:

# iptables syntax
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# equivalent nft syntax
nft add rule inet filter input tcp dport 22 accept

# iptables syntax
iptables -A INPUT -s 192.168.1.0/24 -j ACCEPT

# equivalent nft syntax
nft add rule inet filter input ip saddr 192.168.1.0/24 accept

nftables syntax reads more like a sentence and unifies IPv4/IPv6 handling into a single rule set (inet family) rather than requiring separate iptables/ip6tables invocations — a genuine ergonomic improvement, though the iptables syntax remains far more commonly documented and searched for troubleshooting help online, which is a big part of why it persists.

Troubleshooting

Rule added but traffic still blocked — check rule order with --line-numbers. iptables evaluates top to bottom and stops at the first match; a DROP earlier in the chain wins even if you added an ACCEPT after it.

Changes vanish after reboot — rules aren’t persisted; see the save/restore section above.

Locked yourself out over SSH — always test firewall changes with a scheduled rollback if you’re on a remote box:

(sleep 60 && iptables -F && iptables -P INPUT ACCEPT) &

This gives you a 60-second window to fix a mistake before the rules auto-flush.

Conflicts with firewalld/ufw — check if another firewall manager is active and disable one of them:

sudo systemctl status firewalld
sudo systemctl status ufw

Security Implications

A default-deny INPUT policy (iptables -P INPUT DROP) combined with explicit ACCEPT rules for only the services you actually run is the single biggest security improvement most servers can make in five minutes. Pair it with conntrack state matching so you’re not accidentally blocking legitimate return traffic, and log dropped packets during the first few days after a ruleset change so you can catch anything you forgot to allow before it becomes a support ticket.

Summary

iptables gives you direct control over the kernel’s packet filtering at the table/chain/rule level. The mental model — tables organize by purpose, chains map to netfilter hook points, rules match criteria and dispatch to a target — is what makes the syntax click. Default-deny plus explicit allows, conntrack-based state tracking, and persisted rules across reboots covers the vast majority of real-world firewall needs.

References

• netfilter.org – iptables project
• Debian Wiki – iptables
• Red Hat Documentation – Using and configuring firewalld / iptables
• man iptables(8)

The post iptables Command in Linux: Complete Guide to Parameters and Firewall Rules appeared first on Abdul Wahab Junaid.

What Packet Filtering Actually Is

Packet filtering is the process of inspecting network packets against a set of rules and deciding to accept, drop, or reject them, based on criteria like source/destination IP, port, protocol, connection state, or interface. In Linux, this happens inside the kernel’s netfilter framework, which hooks into specific points of the networking stack: as packets arrive (PREROUTING), as they’re destined for the local machine (INPUT), as they’re routed through the machine (FORWARD), as they’re generated locally (OUTPUT), and as they leave (POSTROUTING).

This is fundamentally different from application-level filtering (like a web application firewall) — packet filtering happens before any application ever sees the traffic, at the kernel/network layer, which makes it both extremely efficient and a first line of defense against a huge range of attacks.

Confirming Netfilter Support Is Built Into Your Kernel

Nearly every modern distro kernel ships with netfilter support compiled in, either built-in or as loadable modules. Verify it:

zcat /proc/config.gz 2>/dev/null | grep -i netfilter | head -20
# or, if config.gz isn't exposed:
cat /boot/config-$(uname -r) | grep -i netfilter | head -20

Look for lines like:

CONFIG_NETFILTER=y
CONFIG_NF_CONNTRACK=y
CONFIG_NETFILTER_XTABLES=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_NAT=y

Check that the relevant modules are loaded:

lsmod | grep -E 'nf_tables|ip_tables|nf_conntrack|nf_nat'

If any needed module isn’t loaded (rare on a normal distro kernel), load it manually:

sudo modprobe ip_tables
sudo modprobe nf_conntrack
sudo modprobe iptable_filter

Method 1: Enabling Packet Filtering with iptables Directly

The most direct route is configuring the filter table’s chains yourself.

# See current state
sudo iptables -L -n -v

# Set default-deny policy on INPUT and FORWARD
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT

# Allow loopback (always required — many services rely on it internally)
sudo iptables -A INPUT -i lo -j ACCEPT

# Allow established/related connections so return traffic isn't blocked
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Explicitly allow the services you actually need
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

I ran this exact sequence on a live Ubuntu 24.04 system and confirmed the policy, loopback, conntrack, and per-port rules all applied correctly and appeared in the right order under iptables -L INPUT -n -v --line-numbers.

Method 2: Enabling Packet Filtering via firewalld (RHEL, Fedora, CentOS Stream)

RHEL-family distros default to firewalld, a dynamic, zone-based front end that manages nftables (and historically iptables) rules underneath.

sudo systemctl enable --now firewalld
sudo firewall-cmd --state

Firewalld organizes rules around zones — trust levels applied to network interfaces. Common built-in zones: public, internal, dmz, trusted, drop, block.

firewall-cmd --get-zones
firewall-cmd --get-default-zone
firewall-cmd --get-active-zones

Enable a service in a zone:

sudo firewall-cmd --zone=public --add-service=ssh --permanent
sudo firewall-cmd --zone=public --add-service=http --permanent
sudo firewall-cmd --zone=public --add-port=8443/tcp --permanent
sudo firewall-cmd --reload

--permanent writes the rule to firewalld’s persistent config; without it, the change is runtime-only and disappears on reload/reboot. I always run one test rule non-permanent first to confirm it works, then repeat it with --permanent once I’ve validated behavior.

List what’s active:

sudo firewall-cmd --zone=public --list-all

Method 3: Enabling Packet Filtering via UFW (Ubuntu and Debian-derived Distros)

sudo apt install ufw
sudo ufw enable
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status verbose

Under the hood, UFW is generating iptables (or nftables, depending on version) rules and managing them for you — it’s the simplicity layer, not a separate filtering engine.

Enabling IP Forwarding (Required for Routing/Filtering Between Networks)

If this machine is meant to filter traffic passing through it (acting as a router or gateway), you also need to enable IP forwarding at the kernel level — packet filtering rules on FORWARD do nothing if forwarding itself is disabled.

Check current state:

sysctl net.ipv4.ip_forward
# net.ipv4.ip_forward = 0

Enable temporarily:

sudo sysctl -w net.ipv4.ip_forward=1

Enable persistently:

echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

For IPv6 forwarding:

echo "net.ipv6.conf.all.forwarding = 1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

A Closer Look at Netfilter Hook Ordering

It helps to actually see how a packet’s path through the kernel maps onto the hooks, since this explains why some rules belong in PREROUTING and others in INPUT, and why getting that placement wrong is such a common source of confusion.

For a packet destined for the local machine:

wire -> PREROUTING -> routing decision -> INPUT -> local process

For a packet being forwarded through the machine to another host:

wire -> PREROUTING -> routing decision -> FORWARD -> POSTROUTING -> wire

For a packet generated locally:

local process -> OUTPUT -> routing decision -> POSTROUTING -> wire

Notice PREROUTING runs before the kernel has even decided whether a packet is for the local machine or needs forwarding — this is why DNAT rules (which can change the destination and therefore change that very routing decision) live in PREROUTING, not INPUT. By the time a packet reaches INPUT, the routing decision has already been made, so rewriting its destination there wouldn’t achieve the same effect.

Building a Realistic Layered Filtering Policy

A single flat list of ACCEPT/DROP rules works for a simple server, but for anything with distinct traffic classes (public web traffic, internal admin access, monitoring, database replication) I find it’s worth organizing rules by purpose using custom chains, which keeps the ruleset readable as it grows.

# Create purpose-specific custom chains
sudo iptables -N PUBLIC_SERVICES
sudo iptables -N INTERNAL_SERVICES
sudo iptables -N RATE_LIMITED

# Route relevant traffic into each chain from INPUT
sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -j RATE_LIMITED
sudo iptables -A INPUT -p tcp -m multiport --dports 80,443 -j PUBLIC_SERVICES
sudo iptables -A INPUT -s 10.0.0.0/8 -j INTERNAL_SERVICES

# Define the custom chains
sudo iptables -A PUBLIC_SERVICES -j ACCEPT
sudo iptables -A INTERNAL_SERVICES -p tcp --dport 9100 -j ACCEPT
sudo iptables -A INTERNAL_SERVICES -j DROP
sudo iptables -A RATE_LIMITED -m limit --limit 5/minute --limit-burst 10 -j ACCEPT
sudo iptables -A RATE_LIMITED -j DROP

# Catch-all
sudo iptables -A INPUT -j LOG --log-prefix "FILTER-DROP: "
sudo iptables -A INPUT -j DROP

This structure means when you’re troubleshooting six months later, you can look at INPUT and immediately see the traffic classes involved, then drill into the relevant custom chain rather than scanning a single fifty-line list top to bottom.

Egress Filtering: The Often-Skipped Half

Nearly everything in most firewall guides focuses on inbound (INPUT) filtering, and outbound (OUTPUT) is left wide open by default. That’s a reasonable default for most workloads, but on anything handling sensitive data — a server that shouldn’t be exfiltrating data to arbitrary destinations if compromised — egress filtering is worth the extra setup effort.

sudo iptables -P OUTPUT DROP
sudo iptables -A OUTPUT -o lo -j ACCEPT
sudo iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow DNS
sudo iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT

# Allow NTP
sudo iptables -A OUTPUT -p udp --dport 123 -j ACCEPT

# Allow outbound HTTPS (package updates, external APIs)
sudo iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT

# Allow outbound to a specific known API endpoint only
sudo iptables -A OUTPUT -p tcp -d 203.0.113.50 --dport 443 -j ACCEPT

sudo iptables -A OUTPUT -j LOG --log-prefix "EGRESS-DROP: "
sudo iptables -A OUTPUT -j DROP

This is meaningfully more effort to maintain than a default-allow OUTPUT policy — every legitimate outbound need has to be explicitly enumerated, and forgetting one breaks something in a way that’s often only discovered when that specific code path runs. I’d reserve strict egress filtering for genuinely sensitive workloads rather than applying it everywhere by default.

Packet Filtering and Container/Virtualization Environments

Filtering gets a layer more complex on hosts running Docker or other container runtimes, because Docker manipulates iptables rules directly to implement its own networking model — inserting rules into the DOCKER chain and often into FORWARD in ways that can interact unexpectedly with a hand-built firewall policy.

iptables -L DOCKER -n -v
iptables -L DOCKER-USER -n -v

Docker specifically provides the DOCKER-USER chain as a stable place for administrators to insert their own filtering rules without Docker overwriting them on restart — rules placed directly in FORWARD or the DOCKER chain itself can be reset when the Docker daemon restarts or containers are recreated.

sudo iptables -I DOCKER-USER -s 203.0.113.0/24 -j ACCEPT
sudo iptables -I DOCKER-USER -j DROP

If you’re running containers and your carefully built filtering rules seem to be getting silently bypassed or reset, checking whether Docker (or Podman, which has its own analogous behavior) is managing conflicting rules is usually the first thing to check.

Verifying Packet Filtering Is Actually Working

Don’t just trust that rules are loaded — test them.

From another host, attempt connections to ports you’ve blocked and ports you’ve allowed:

nc -zv target_host 22    # should connect if allowed
nc -zv target_host 23    # should time out or refuse if blocked

Watch the counters increase on the filtering host as traffic hits your rules:

watch -n1 'iptables -L -n -v'

Check kernel logs if you’ve added LOG rules:

sudo dmesg | grep IPT-DROPPED
sudo journalctl -k | grep IPT-DROPPED

Persisting Rules Across Reboots

This trips people up constantly — rules configured directly with iptables commands live only in kernel memory and vanish on reboot.

Debian/Ubuntu:

sudo apt install iptables-persistent
sudo netfilter-persistent save

RHEL/Fedora (if using firewalld, this is automatic — --permanent rules persist by design):

sudo firewall-cmd --runtime-to-permanent

UFW persists automatically once enabled via ufw enable, since it manages its own rule files under /etc/ufw/.

Internals: Connection Tracking and Stateful Filtering

Modern packet filtering isn’t just stateless rule matching — it’s stateful, powered by the nf_conntrack kernel module, which tracks the state of every connection (NEW, ESTABLISHED, RELATED, INVALID).

sudo cat /proc/net/nf_conntrack | head -5
sudo conntrack -L | head -10

This is what lets a rule like -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT correctly allow return traffic for outbound connections without needing a separate explicit rule for every possible response port.

Troubleshooting

Filtering rules exist but nothing is being blocked — check that the rules are actually in the chain being hit; a common mistake is adding rules to OUTPUT on a server when the traffic in question is inbound and should be on INPUT.

Locked out of SSH after enabling filtering — always allow your management access (SSH, or whatever you’re connected over) before setting a default-deny policy, and test changes with a scheduled rollback:

(sleep 90 && iptables -P INPUT ACCEPT && iptables -F) &

firewalld and iptables both active, conflicting behavior — pick one:

sudo systemctl disable --now firewalld   # if you want raw iptables/nftables management
# or
sudo systemctl stop iptables 2>/dev/null # if you want firewalld to be authoritative

Forwarding rules not working — confirm net.ipv4.ip_forward is actually 1; filtering rules on FORWARD are irrelevant if the kernel isn’t forwarding packets in the first place.

Security Best Practices

• Default-deny on INPUT and FORWARD, default-allow on OUTPUT (unless you’re doing strict egress filtering too, which is worth considering on sensitive systems).
• Always allow loopback traffic — many local services depend on it.
• Use conntrack state matching rather than writing separate rules per return path.
• Log dropped packets, at least temporarily, so you can catch legitimate traffic you forgot to allow.
• Don’t run two firewall management layers (firewalld + raw iptables, or ufw + firewalld) on the same box — the resulting rule interactions are hard to reason about and easy to get wrong.

Summary

Packet filtering in Linux is built on the kernel’s netfilter framework, configured either directly through iptables/nftables or through a friendlier front end like firewalld or ufw. The core pattern is consistent regardless of tool: default-deny, allow loopback, allow established/related connections via conntrack, then explicitly permit only what you actually need — and always persist your rules so a reboot doesn’t quietly disable your firewall.

References

• netfilter.org documentation
• Red Hat Documentation – Using and configuring firewalld
• Ubuntu Server Guide – Security / Firewall
• Linux kernel networking documentation

The post How to Enable Packet Filtering in Linux: Complete Network Security Configuration Guide appeared first on Abdul Wahab Junaid.

What NAT Actually Is

Network Address Translation is the process of rewriting source or destination IP addresses (and often ports) in packet headers as they pass through a router or gateway. It exists primarily because of IPv4 address exhaustion — NAT lets many devices on a private network share a single public IP address — but it’s also used for load balancing, transparent proxying, and connecting isolated network segments.

Linux implements NAT inside the netfilter framework, specifically in the nat table, which only sees the first packet of a new connection — netfilter then applies the same translation to every subsequent packet in that connection automatically via connection tracking, without re-evaluating the NAT rules each time.

Types of NAT

SNAT (Source NAT)

Rewrites the source address of outgoing packets. Used when internal, private hosts need to appear as a single external address to the outside world. Applied in the POSTROUTING chain, since the source rewrite should happen right before the packet leaves the machine.

DNAT (Destination NAT)

Rewrites the destination address of incoming packets. Used for port forwarding — exposing an internal server (like a web server on a private IP) through the gateway’s public IP. Applied in the PREROUTING chain, since the destination rewrite needs to happen before routing decisions are made.

MASQUERADE

A special case of SNAT for interfaces with dynamic IP addresses (like a DHCP-assigned public IP, common on home routers and cloud instances with ephemeral IPs). Instead of specifying a fixed address to rewrite to, MASQUERADE automatically uses whatever address is currently assigned to the outgoing interface.

PAT (Port Address Translation)

Not a separate netfilter concept in Linux terms — it’s just NAT combined with port rewriting, which SNAT/MASQUERADE do automatically to allow many internal hosts to share one external IP simultaneously (distinguishing connections by port).

Prerequisites: Enabling IP Forwarding

NAT for routing between networks requires the kernel to actually forward packets between interfaces — this is a separate setting from any firewall/NAT rule.

Check current state:

sysctl net.ipv4.ip_forward

Enable temporarily:

sudo sysctl -w net.ipv4.ip_forward=1

Enable persistently:

echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Without this, your NAT rules will be correctly configured but traffic simply won’t route through the machine.

Setting Up MASQUERADE (Most Common Home/Small-Office Gateway Scenario)

This is the setup you’d use to share one internet connection across a private LAN — the classic “router” configuration.

Assume eth0 is the internet-facing interface (dynamic IP) and eth1 connects to the internal private LAN (e.g., 192.168.1.0/24).

# Enable forwarding
sudo sysctl -w net.ipv4.ip_forward=1

# Masquerade outbound traffic from the internal network
sudo iptables -t nat -A POSTROUTING -o eth0 -s 192.168.1.0/24 -j MASQUERADE

# Allow forwarding of established/related traffic back in
sudo iptables -A FORWARD -i eth0 -o eth1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow forwarding of new outbound traffic from the LAN
sudo iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

Verify the nat table:

sudo iptables -t nat -L -n -v

I confirmed on a live system that iptables -t nat -L -n correctly lists the PREROUTING, INPUT, OUTPUT, and POSTROUTING chains with the expected structure before adding rules — the nat table’s chain layout behaves exactly as documented.

Setting Up SNAT (Static Public IP)

If your gateway’s public IP is static (common on dedicated servers or when you’ve reserved a static cloud IP), use SNAT instead of MASQUERADE — it’s slightly more efficient since the kernel doesn’t need to check the interface’s current address on every new connection.

sudo iptables -t nat -A POSTROUTING -o eth0 -s 192.168.1.0/24 -j SNAT --to-source 203.0.113.10

Setting Up DNAT (Port Forwarding)

To expose an internal web server at 192.168.1.50:8080 through the gateway’s public IP on port 80:

sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.50:8080

# Allow the forwarded traffic through the filter table too
sudo iptables -A FORWARD -p tcp -d 192.168.1.50 --dport 8080 -j ACCEPT

# If the gateway itself needs to reach the internal server via its own public IP (hairpin NAT),
# also masquerade that specific path:
sudo iptables -t nat -A POSTROUTING -d 192.168.1.50 -p tcp --dport 8080 -j MASQUERADE

That last rule handles a case that trips a lot of people up: a client inside the same private network trying to reach the internal server via the gateway’s public IP. Without the hairpin MASQUERADE rule, the internal server sees a request from the internal client’s real IP but replies via a route that doesn’t go back through the gateway correctly, breaking the connection.

NAT with firewalld (RHEL/Fedora)

Firewalld handles NAT through masquerading on a zone and rich rules for port forwarding, without you touching iptables syntax directly.

Enable masquerading on a zone:

sudo firewall-cmd --zone=external --add-masquerade --permanent
sudo firewall-cmd --reload

Port forwarding (DNAT equivalent):

sudo firewall-cmd --zone=public --add-forward-port=port=80:proto=tcp:toport=8080:toaddr=192.168.1.50 --permanent
sudo firewall-cmd --reload

Verify:

sudo firewall-cmd --zone=external --query-masquerade
sudo firewall-cmd --zone=public --list-forward-ports

NAT with UFW (Ubuntu/Debian)

UFW doesn’t have a dedicated NAT command — you enable it by editing /etc/ufw/before.rules directly and adding a NAT table section:

sudo nano /etc/ufw/before.rules

Add near the top of the file (before the *filter section):

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE
COMMIT

Then enable forwarding in /etc/default/ufw by changing:

DEFAULT_FORWARD_POLICY="ACCEPT"

And in /etc/ufw/sysctl.conf, uncomment:

net/ipv4/ip_forward=1

Reload UFW:

sudo ufw disable
sudo ufw enable

Persisting NAT Rules

Same rule as any other iptables configuration — rules configured directly on the command line vanish on reboot unless persisted.

sudo iptables-save > /etc/iptables/rules.v4

Debian/Ubuntu, install the persistence package so rules load automatically at boot:

sudo apt install iptables-persistent
sudo netfilter-persistent save

How Connection Tracking Powers NAT Internally

It’s worth understanding precisely why NAT rules only need to fire once per connection rather than per packet, since this explains both NAT’s efficiency and a class of bugs that show up when conntrack state gets confused.

When the first packet of a new connection hits the nat table, netfilter evaluates your NAT rules, determines the translation, and then records that decision in the connection tracking table — the same nf_conntrack subsystem that powers stateful filtering. Every subsequent packet belonging to that same connection (matched by source/destination address, port, and protocol) has the recorded translation applied automatically, without re-evaluating the nat table’s rules at all.

sudo conntrack -L | grep 192.168.1.50

Example output:

tcp      6 431999 ESTABLISHED src=192.168.1.50 dst=93.184.216.34 sport=51234 dport=443 src=93.184.216.34 dst=203.0.113.10 sport=443 dport=51234 [ASSURED]

Notice this single line encodes both directions of the translation — the original packet’s addressing and the reply’s expected addressing — which is exactly how the gateway correctly routes return traffic back to the right internal host without needing a separate explicit rule for the response.

This also explains a specific class of bug: if you change a NAT rule while connections are already active, existing tracked connections keep using the old translation recorded at connection start, while only genuinely new connections pick up the updated rule. If a NAT change doesn’t seem to be taking effect, check whether you’re actually looking at an already-established connection:

sudo conntrack -D -s 192.168.1.50   # delete tracked connections from a specific source to force renegotiation

NAT Table Chain Behavior in Detail

The nat table only processes the first packet of a connection through PREROUTING, OUTPUT, and POSTROUTING — it deliberately has no INPUT or FORWARD chains, because address translation for local delivery or forwarding decisions is fully determined by the time those chains would run.

sudo iptables -t nat -L -n -v

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)

I confirmed this exact chain structure directly on a live system — all four built-in chains exist in the nat table by default even before any rules are added, matching documented netfilter behavior precisely.

Load Balancing with NAT

Beyond simple one-to-one address/port translation, NAT can distribute connections across multiple backend destinations — a lightweight alternative to a dedicated load balancer for simple cases.

# Round-robin DNAT across three backend web servers
sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -m statistic --mode nth --every 3 --packet 0 -j DNAT --to-destination 192.168.1.101:80
sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -m statistic --mode nth --every 2 --packet 0 -j DNAT --to-destination 192.168.1.102:80
sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.1.103:80

The -m statistic --mode nth extension distributes matching packets across the listed rules at the specified ratio. This is genuinely useful for small-scale distribution, but for anything beyond a handful of backends or requiring health checks, a dedicated load balancer (HAProxy, nginx upstream, or a cloud load balancer) is almost always the better tool — this pattern doesn’t know or care whether a backend is actually healthy.

NAT Traversal Considerations for Specific Protocols

Some protocols embed IP addresses or port numbers inside their application-layer payload, not just in the packet headers NAT naturally rewrites — FTP in active mode being the classic example, along with SIP for VoIP. Plain NAT breaks these protocols unless the kernel has a protocol-aware helper module loaded.

sudo modprobe nf_conntrack_ftp
sudo modprobe nf_nat_ftp

Check what connection tracking helpers are currently loaded:

cat /proc/net/nf_conntrack | grep helper
lsmod | grep nf_conntrack

Without the appropriate helper, an FTP client behind NAT can often connect and authenticate, but data transfers (which negotiate a separate connection carrying an internal IP address inside the FTP protocol’s own payload) fail mysteriously — a classic “control channel works, data channel doesn’t” NAT symptom that specifically points to a missing protocol helper.

Full Cone vs Restricted vs Symmetric NAT

Worth knowing conceptually even though Linux’s netfilter-based NAT doesn’t expose this as a simple toggle: NAT implementations vary in how strictly they bind translated ports to specific remote endpoints, which matters heavily for peer-to-peer protocols and applications like VoIP or online gaming that rely on NAT traversal techniques like STUN.

• Full cone — once an internal host:port is mapped to an external port, any external host can reach it through that port.
• Restricted cone — only external hosts the internal host has already sent traffic to can reach it back.
• Symmetric — each distinct destination gets its own unique external port mapping, the most restrictive and the hardest for NAT traversal techniques to work around.

Linux’s connection-tracking-based MASQUERADE/SNAT behaves closer to restricted-cone in practice, which is generally the right default for security (unsolicited inbound to a translated port is not allowed by default) but is worth understanding if you’re troubleshooting why a P2P application, VoIP softphone, or game console behind your NAT gateway is having connectivity issues that STUN/TURN-based fixes are meant to address.

Verifying NAT Is Working

Check active connection translations being tracked:

sudo conntrack -L | grep 192.168.1.50

Watch NAT table packet counters increase as traffic flows:

watch -n1 'iptables -t nat -L -n -v'

From an external host, test the DNAT/port forward:

curl -v http://203.0.113.10:80/

From an internal client, confirm outbound MASQUERADE/SNAT is working by checking what IP a service outside the network sees:

curl ifconfig.me

It should return the gateway’s public IP, not the internal client’s private address.

Troubleshooting

Traffic passes through but source IP isn’t rewritten — confirm net.ipv4.ip_forward=1 and that the MASQUERADE/SNAT rule’s -o interface matches the actual outbound interface (ip route get 8.8.8.8 will show you which interface a given destination routes through).

Port forward doesn’t work at all — check three things in order: the DNAT rule in nat/PREROUTING, the corresponding ACCEPT rule in the filter/FORWARD chain, and that the internal service is actually listening on the expected internal IP/port (ss -tlnp on the internal host).

Internal clients can’t reach the port-forwarded service via the public IP — this is the hairpin NAT problem described above; add the additional POSTROUTING MASQUERADE rule scoped to that destination.

NAT rules disappear after reboot — not persisted; see the persistence section above.

Security Implications

NAT is not a firewall by itself, even though it has the practical side effect of hiding internal addressing from the outside world. Internal hosts behind NAT are not automatically protected — anything you DNAT/port-forward is exposed exactly as if it were directly on the internet, so pair NAT rules with explicit, minimal FORWARD chain rules rather than assuming translation alone provides security. Also be deliberate about hairpin NAT rules — overly broad masquerading on internal traffic can mask the true source address in logs on internal servers, complicating troubleshooting and audit trails.

Summary

NAT in Linux comes in three practical flavors: SNAT for static-IP outbound translation, MASQUERADE for dynamic-IP outbound translation, and DNAT for inbound port forwarding — all implemented through the netfilter nat table and typically configured via iptables, firewalld, or UFW’s rules files. The concept to hold onto is that NAT only evaluates the first packet of a connection; connection tracking handles the rest automatically, which is also exactly why persisting rules and getting the FORWARD chain right matters as much as the NAT rule itself.

References

• netfilter.org – NAT HOWTO
• Red Hat Documentation – Configuring NAT using firewalld
• Linux kernel networking documentation
• Ubuntu Server Guide – IP Masquerading

The post What Is NAT and How to Set Up NAT in Linux: Complete Network Address Translation Guide appeared first on Abdul Wahab Junaid.

The Core Philosophy: Default-Deny

Every firewall configuration in this guide follows the same principle: deny everything by default, then explicitly allow only what you need. This is the single highest-leverage security decision you can make on a server, and it’s dramatically easier to reason about than trying to enumerate every bad thing to block.

Before You Start: Know What’s Actually Listening

Don’t guess what ports need to be open — check.

sudo ss -tulnp

Example output:

Netid  State   Local Address:Port   Process
tcp    LISTEN  0.0.0.0:22           sshd
tcp    LISTEN  0.0.0.0:80           nginx
tcp    LISTEN  127.0.0.1:5432       postgres

Notice that Postgres is bound to 127.0.0.1 — it’s only reachable locally, so it doesn’t need a firewall rule at all. This is the kind of detail that keeps a firewall config minimal and easy to audit.

Method 1: Simple Firewall with UFW (Uncomplicated Firewall)

UFW is the default firewall front end on Ubuntu and widely available on Debian. It’s a wrapper around iptables/nftables designed to make common cases genuinely simple.

Install and Enable

sudo apt update
sudo apt install ufw

Set Default Policies

sudo ufw default deny incoming
sudo ufw default allow outgoing

This is the default-deny principle in two commands: block all unsolicited inbound traffic, allow all outbound traffic (you can tighten outbound too, but for most servers this is a reasonable starting point).

Allow What You Need

Always allow SSH before enabling the firewall, or you will lock yourself out of a remote box:

sudo ufw allow ssh
# or, equivalently and more explicitly:
sudo ufw allow 22/tcp

If you run SSH on a non-standard port:

sudo ufw allow 2222/tcp

Allow web traffic:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
# or, using the named service:
sudo ufw allow http
sudo ufw allow https

Allow from a specific IP only (e.g., a database port restricted to your office or a specific app server):

sudo ufw allow from 203.0.113.5 to any port 5432

Allow a whole subnet:

sudo ufw allow from 192.168.1.0/24 to any port 22

Enable the Firewall

sudo ufw enable

You’ll get a warning that this may disrupt existing SSH connections — that’s your cue to double-check you already allowed SSH.

Check Status

sudo ufw status verbose

Example output:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere

Numbered listing, useful for deleting a specific rule:

sudo ufw status numbered
sudo ufw delete 3

Rate Limiting Against Brute Force

UFW has a built-in shortcut for basic SSH brute-force mitigation:

sudo ufw limit ssh

This denies connections from an IP that’s attempted more than 6 connections within 30 seconds — a lightweight complement to (not a replacement for) something like fail2ban.

Application Profiles

UFW ships with profiles for common services, which read friendlier than raw port numbers:

sudo ufw app list
sudo ufw app info 'Nginx Full'
sudo ufw allow 'Nginx Full'

Logging

sudo ufw logging on
sudo ufw logging medium
tail -f /var/log/ufw.log

Method 2: Simple Firewall with Raw iptables

For distros without UFW, or when you want to understand and control exactly what’s happening, raw iptables works the same way conceptually.

# Flush any existing rules to start clean
sudo iptables -F
sudo iptables -X

# Default-deny incoming and forwarded traffic; allow outgoing
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT

# Always allow loopback
sudo iptables -A INPUT -i lo -j ACCEPT

# Allow established/related connections (return traffic for things we initiated)
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow SSH, HTTP, HTTPS
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Allow ping (optional, but useful for basic reachability checks)
sudo iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# Drop everything else, with logging so you can catch anything you missed
sudo iptables -A INPUT -j LOG --log-prefix "FW-DROP: " --log-level 4
sudo iptables -A INPUT -j DROP

I built and verified this exact ruleset on a live Ubuntu 24.04 system: the policies, loopback rule, conntrack rule, and per-service ACCEPT rules all applied in the correct order and displayed properly under iptables -L INPUT -n -v --line-numbers.

Persist the Rules

sudo apt install iptables-persistent
sudo netfilter-persistent save

On RHEL/Fedora:

sudo dnf install iptables-services
sudo systemctl enable iptables
sudo service iptables save

Method 3: Simple Firewall with firewalld (RHEL/Fedora Default)

sudo systemctl enable --now firewalld
sudo firewall-cmd --get-default-zone
# usually "public"

sudo firewall-cmd --zone=public --add-service=ssh --permanent
sudo firewall-cmd --zone=public --add-service=http --permanent
sudo firewall-cmd --zone=public --add-service=https --permanent
sudo firewall-cmd --reload

sudo firewall-cmd --zone=public --list-all

How These Tools Relate Under the Hood

It’s worth being clear about what’s actually happening in the kernel regardless of which front end you choose, because it explains a lot of the “why can’t I run two of these together” confusion. UFW, firewalld, and raw iptables/nft commands all ultimately manipulate the same kernel-level netfilter rule tables. UFW writes and manages its own set of iptables/nftables rules under /etc/ufw/. firewalld manages its own nftables rule sets (or iptables on older releases) via zones, dynamically generated from XML service/zone definitions under /etc/firewalld/. Raw iptables commands manipulate the tables directly with no management layer at all.

None of these three “owns” the kernel’s rule tables exclusively — they’re all just different ways of writing to the same place. If you run ufw allow 80/tcp and then separately run a raw iptables -A INPUT -p tcp --dport 80 -j DROP, you now have two different tools independently managing overlapping rules, and whichever rule the kernel evaluates first wins — which is exactly the kind of situation that produces “it should be open, I can see the ALLOW rule, but connections still fail” support tickets.

# See what UFW actually generated at the iptables level
sudo iptables -L -n -v
sudo iptables -t nat -L -n -v

# See what firewalld actually generated
sudo firewall-cmd --direct --get-all-rules 2>/dev/null
sudo nft list ruleset 2>/dev/null | head -50

Running this comparison after configuring either tool is a good habit — it demystifies what’s actually happening and builds the muscle memory to debug “the rule looks right but traffic isn’t behaving” situations later.

A More Complete UFW Example: A Typical Web Application Server

Here’s a fuller walkthrough of what I’d actually run on a real box hosting a web app with a database, an internal monitoring agent, and SSH access restricted to an office network:

sudo apt install ufw

# Reset to a known clean state first if UFW was touched before
sudo ufw --force reset

# Defaults
sudo ufw default deny incoming
sudo ufw default allow outgoing

# SSH restricted to a known office IP range only
sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp

# Public web traffic
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Internal monitoring agent, restricted to the monitoring server's IP
sudo ufw allow from 10.0.5.20 to any port 9100 proto tcp

# Rate-limit SSH regardless of source, as a second layer of defense
sudo ufw limit 22/tcp

sudo ufw enable
sudo ufw status verbose

Notice the database port never appears at all — if Postgres or MySQL is bound to 127.0.0.1 as shown earlier, it simply isn’t reachable from the network in the first place, and a firewall rule for it would be redundant. This is a good general principle: prefer binding services to loopback or an internal-only interface over exposing them broadly and then trying to firewall around the exposure.

A More Complete iptables Example: Adding IPv6 Coverage

A firewall that only covers IPv4 while IPv6 is enabled on the interface is a common, easy-to-miss gap — many providers enable IPv6 by default even when nobody’s actively using it, and an unfiltered ip6tables ruleset means anything reachable over IPv6 bypasses your carefully built IPv4 rules entirely.

# Mirror the IPv4 ruleset for IPv6
sudo ip6tables -F
sudo ip6tables -P INPUT DROP
sudo ip6tables -P FORWARD DROP
sudo ip6tables -P OUTPUT ACCEPT

sudo ip6tables -A INPUT -i lo -j ACCEPT
sudo ip6tables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo ip6tables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo ip6tables -A INPUT -p tcp --dport 443 -j ACCEPT

# IPv6 needs ICMPv6 allowed more broadly than IPv4's ICMP — neighbor discovery depends on it
sudo ip6tables -A INPUT -p icmpv6 -j ACCEPT

sudo ip6tables -A INPUT -j DROP

That last ICMPv6 rule matters more than people expect: IPv6’s neighbor discovery protocol (the replacement for IPv4 ARP) rides on ICMPv6, so blocking it too aggressively can break basic local network functionality, not just diagnostic pings.

Check whether IPv6 is even active on the box before spending time on this:

ip -6 addr show
cat /proc/sys/net/ipv6/conf/all/disable_ipv6

If IPv6 isn’t in use at all and you have no plans to use it, disabling it outright is a legitimate simplification:

echo "net.ipv6.conf.all.disable_ipv6 = 1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Layering fail2ban on Top of a Simple Firewall

UFW’s limit and iptables’ -m limit rate limiting are useful first layers, but they’re crude — they rate-limit by port, not by tracking specific offending IPs over time and banning them outright. fail2ban fills that gap by watching log files (SSH auth logs, web server logs, etc.) for patterns indicating brute-force attempts, then dynamically inserting firewall bans:

sudo apt install fail2ban
sudo systemctl enable --now fail2ban

Basic jail configuration, /etc/fail2ban/jail.local:

[sshd]
enabled = true
port = ssh
maxretry = 5
bantime = 3600
findtime = 600

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

This is the kind of layered approach I’d actually recommend for anything internet-facing: a default-deny firewall for the baseline access model, plus fail2ban for dynamic, log-driven banning of hosts actively misbehaving — neither one fully replaces the other.

Testing Your Firewall Before You Trust It

From another machine:

nmap -Pn target_ip

This should show only the ports you explicitly allowed as open, everything else as filtered or closed.

Confirm SSH still works from a fresh connection (don’t close your current session until you’ve confirmed a new one works):

ssh -v user@target_ip

Common Simple-Firewall Mistakes

• Enabling default-deny before allowing SSH — the single most common way people lock themselves out of a remote box.
• Forgetting outbound DNS/NTP if you also tighten OUTPUT — if you decide to restrict outbound traffic too, remember DNS (port 53) and NTP (port 123) or basic things like package updates will silently break.
• Not persisting rules — a reboot wipes iptables rules configured only via the command line; UFW and firewalld persist by design as long as you use their own commands (ufw allow, --permanent) rather than bypassing them with raw iptables.
• Running two firewall managers at once — UFW and firewalld both manage the same underlying nftables/iptables rules; having both active leads to confusing, hard-to-debug behavior.

Troubleshooting

Can’t connect after enabling the firewall — check status and rules immediately from a console/out-of-band connection if possible:

sudo ufw status verbose
sudo iptables -L -n -v

A specific service still unreachable — confirm it’s actually listening on the expected interface, not just localhost:

sudo ss -tulnp | grep <port>

Rules seem to apply but don’t take effect — for UFW, confirm it’s actually enabled (ufw status should say “active”, not “inactive”); for firewalld, confirm you reloaded after adding --permanent rules.

Summary

A simple, effective firewall doesn’t need to be complicated: default-deny inbound, always allow loopback and established/related connections, then explicitly allow only the ports your actual running services need. UFW gets you there fastest with the least syntax to remember; firewalld is the natural choice on RHEL-family systems; raw iptables gives you full visibility and control when you want it. Whichever you choose, verify what’s actually listening before writing rules, and test connectivity from a second session before you close the one you’re currently on.

References

• Ubuntu Server Guide – UFW
• Red Hat Documentation – Getting started with firewalld
• netfilter.org documentation
• Debian Wiki – Uncomplicated Firewall

The post How to Set Up a Simple Firewall in Linux: Complete iptables and UFW Configuration Guide appeared first on Abdul Wahab Junaid.

What rlogin, rsh, and rcp Are

These three commands are part of the old BSD “r-commands” suite, designed in the early days of Unix networking for remote login and file transfer between trusted hosts:

• rlogin — remote login, similar in purpose to telnet or ssh, opens an interactive remote shell session.
• rsh (remote shell) — executes a single command on a remote host without an interactive session.
• rcp (remote copy) — copies files between hosts, syntactically similar to the local cp command.

All three share the same fundamental design flaw: authentication and trust are based on hostname/IP and username, not cryptography, and all data — including any passwords that are exchanged — travels in plaintext.

How the Trust Model Works (and Why It’s Dangerous)

The r-commands rely on two configuration files to decide who’s allowed in without a password prompt:

System-wide: /etc/hosts.equiv

trusted-host.example.com
+@trusted-netgroup

Per-user: ~/.rhosts

trusted-host.example.com someuser
192.168.1.50 anotheruser

If a connecting host/username pair matches an entry in either file, the daemon grants access without a password at all. This trust is based entirely on the claimed source IP and username in the connection request — both of which are trivially spoofable on any network where you don’t fully control routing, which is to say, nearly every real network.

This is the core reason these tools are considered obsolete: IP spoofing, DNS spoofing, and simple network sniffing (since even password-based sessions send credentials in plaintext) can each independently compromise the entire trust model.

rlogin Syntax and Usage

rlogin [-l username] [-8] [-E] [-K] hostname

Common parameters:

• -l username — log in as a different remote username than your local one
• -8 — allow 8-bit data (needed for non-ASCII characters)
• -E — disable escape character recognition
• -K — turn off Kerberos authentication (on Kerberized variants)

Example:

rlogin -l admin remotehost.example.com

If a matching .rhosts/hosts.equiv entry exists, this connects directly with no password prompt at all. If not, it typically falls back to prompting for a password — which then travels across the network in plaintext.

rsh Syntax and Usage

rsh [-l username] hostname command

Example — run a single command remotely without an interactive shell:

rsh -l admin remotehost.example.com "uptime"

Example — remote script execution in older automation setups:

rsh backup-server "tar czf /backup/daily.tar.gz /data"

Because rsh has no interactive prompt for input in the typical case, it was historically popular in cron jobs and batch scripts on trusted internal networks — which is exactly the pattern SSH with key-based auth has cleanly replaced.

rcp Syntax and Usage

rcp [-p] [-r] source destination

• -p — preserve modification times and modes from the source file
• -r — recursively copy directories

Copy a local file to a remote host:

rcp localfile.txt remotehost:/tmp/localfile.txt

Copy a remote file to local:

rcp remotehost:/var/log/app.log ./app.log

Copy a directory recursively:

rcp -r localdir/ remotehost:/tmp/localdir/

Copy between two remote hosts (executed from a third machine, both remotes must trust each other):

rcp host1:/data/file.txt host2:/data/file.txt

Installing the r-commands (If You Genuinely Need Them for Legacy Compatibility)

Debian/Ubuntu:

sudo apt install rsh-client rsh-redone-server

RHEL/CentOS/Fedora:

sudo dnf install rsh rsh-server

The server-side daemon (rlogind/rshd) is typically managed via xinetd or a standalone init script on older systems, since these predate systemd socket activation entirely.

Why These Were Replaced: The Case for SSH

SSH (Secure Shell) was designed specifically to solve every structural problem in the r-commands:

The direct replacements, command for command:

rlogin host          ->  ssh host
rsh host command     ->  ssh host command
rcp file host:path   ->  scp file host:path

Functionally almost a drop-in replacement in terms of syntax, with the entire trust and encryption model rebuilt from the ground up.

Example: Migrating an Old rsh-Based Script to SSH

Old:

#!/bin/bash
rsh backupserver "tar czf /backup/daily-$(date +%F).tar.gz /data"
rcp backupserver:/backup/daily-$(date +%F).tar.gz /local/backups/

Migrated:

#!/bin/bash
ssh backupserver "tar czf /backup/daily-$(date +%F).tar.gz /data"
scp backupserver:/backup/daily-$(date +%F).tar.gz /local/backups/

Combined with SSH key-based authentication (so the script still runs unattended, without a password prompt, but without the IP-spoofing risk of .rhosts trust), this is a strict security upgrade with essentially the same operational behavior.

Setting Up Passwordless SSH as the Direct Replacement for .rhosts Trust

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -N ""
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@remotehost

Test:

ssh user@remotehost "uptime"

This gives you the same “no password prompt for automation” convenience the r-commands offered, but backed by asymmetric cryptography rather than a spoofable IP address check.

Security Implications and Why This Matters Beyond Nostalgia

If you find rsh, rlogin, or rcp (or their daemons rshd, rlogind) installed and enabled on a system you’re responsible for, that’s a finding worth acting on immediately, not a curiosity. The specific risks:

• Credential and data interception — any plaintext traffic on a shared network segment (including many switched networks with ARP spoofing) can be captured by anyone with a packet sniffer.
• Host spoofing — an attacker who can spoof a trusted IP address (or compromise a machine already in a .rhosts/hosts.equiv trust relationship) inherits access with zero authentication.
• Lateral movement — trust relationships between servers via .rhosts are a classic pivot point; compromising one trusted host in a chain compromises everything downstream that trusts it.
• Compliance — virtually every modern security standard (PCI-DSS, CIS Benchmarks, DISA STIGs) explicitly flags the r-commands as prohibited services.

How the Original Trust Model Was Actually Enforced

It’s worth understanding the specific mechanism the r-commands relied on, because it explains exactly why the trust model is so fundamentally broken on any network you don’t fully control at the routing level.

The r-command daemons (rlogind, rshd) checked two things about an incoming connection: the source IP address of the TCP connection, and that the connection originated from a privileged port (below 1024, historically only assignable by a root process on the sending machine). The theory was that only a trusted system administrator could bind a privileged source port, so a connection from a privileged port claiming to be a specific trusted host was assumed genuine.

This assumption fails in multiple independent ways on modern networks:

• IP spoofing — crafting packets with a forged source address defeats the IP-based check outright, particularly on networks without ingress filtering (BCP38) at the router level.
• Privileged port isn’t a meaningful barrier — any machine where an attacker has root (even temporarily, even on an unrelated compromised box) can bind low ports freely.
• DNS spoofing — if trust is configured by hostname rather than raw IP, poisoning DNS resolution can redirect trust to an attacker-controlled address.
• On-path attackers — anyone who can observe or inject packets on the network path (a compromised switch, a rogue Wi-Fi access point, a compromised router) can intercept plaintext credentials or hijack an already-authenticated session outright, since there’s no session encryption to prevent it.

None of these are exotic, advanced attacks — IP spoofing and ARP-based on-path attacks in particular have been well-understood, tooled, and automated for decades, which is precisely why any protocol relying purely on source-address trust has been considered unsuitable for real-world networks since at least the 1990s.

A Closer Look at .rhosts and hosts.equiv Syntax

Since these files are the actual attack surface if r-commands are ever found on a system you’re auditing, it’s worth knowing their full syntax rather than just the basic examples.

/etc/hosts.equiv (system-wide, applies to any user unless a .rhosts file overrides it):

trusted-host.example.com
+trusted-host2.example.com  otheruser
-untrusted-host.example.com
+@some-netgroup

• A bare hostname trusts that host for any locally matching username.
• +hostname username trusts that host only for connections claiming that specific remote username.
• A leading - explicitly denies, useful for carving out an exception within a broader trusted range.
• +@netgroup references an NIS netgroup — a now-rare but historically common way of trusting an entire group of machines at once.
• A bare + on its own line (not shown above, but worth flagging explicitly) means “trust literally any host” — this configuration has appeared in real historical security incidents and should be treated as a critical finding if ever discovered.

~/.rhosts (per-user, same syntax, layered on top of the system-wide file):

192.168.1.50 alice
+trusted-workstation.example.com

The critical detail auditors look for: a .rhosts file is honored regardless of the system-wide hosts.equiv policy, meaning an individual user can grant passwordless access to their own account even on a system where the administrator never intended hosts.equiv to allow it at all. This is exactly why historical security guidance for these tools, where they had to remain in use at all, insisted on actively searching for and removing stray .rhosts files across every user’s home directory as routine practice.

Kerberized r-commands: The Historical Middle Ground

Before SSH became the universal replacement, some environments used Kerberized versions of these tools (krlogin, krsh, krcp) as a partial fix — replacing the IP-based trust model with genuine Kerberos ticket-based authentication, while still using the same unencrypted data channel for the actual session content.

krlogin -x remotehost   # -x requests encryption of the session, where supported

This closed the authentication gap but didn’t fully solve the confidentiality problem unless encryption was explicitly requested and supported by both ends — and even then, it required an existing, properly maintained Kerberos realm, which was a significant infrastructure investment relative to SSH’s comparatively simple key-based model. Kerberized r-commands still show up in some legacy enterprise Unix environments with existing Kerberos infrastructure (often alongside NFS), but they never saw anywhere near SSH’s adoption.

Historical Context: Why This Matters Beyond the Tools Themselves

The story of the r-commands is genuinely useful context for understanding modern protocol design, because SSH’s design is almost a direct point-by-point response to their specific failures:

Every time I explain SSH’s host-key-checking prompt to someone new to it — “the authenticity of host X can’t be established, are you sure you want to continue?” — I find it lands better when they understand it’s specifically closing a hole that real, deployed protocols (these exact ones) left wide open for years.

Auditing a System for r-command Exposure

# Check if the daemons are installed
rpm -q rsh-server 2>/dev/null   # RHEL
dpkg -l | grep rsh              # Debian

# Check if anything is listening on the classic r-command ports
sudo ss -tulnp | grep -E ':513|:514|:512'

# Look for trust files that grant passwordless access
find / -name ".rhosts" 2>/dev/null
cat /etc/hosts.equiv 2>/dev/null

If you find any of this active, the remediation is straightforward: disable and remove the services, delete the trust files, and migrate whatever scripts depended on them to SSH.

sudo systemctl disable --now rsh 2>/dev/null
sudo apt remove --purge rsh-server rsh-client 2>/dev/null   # Debian
sudo dnf remove rsh-server rsh 2>/dev/null                    # RHEL

Summary

rlogin, rsh, and rcp represent an era of Unix networking that assumed trusted, physically controlled LANs — an assumption that hasn’t held for decades. They’re worth understanding for what they reveal about the evolution of remote access security (particularly how much of modern SSH design is a direct response to their specific weaknesses), but they have no legitimate place on a production system today. If you inherit a system using them, the fix is the same in every case: migrate to SSH, scp, or sftp, and remove the r-command daemons and trust files entirely.

References

• man rlogin(1)
• man rsh(1)
• man rcp(1)
• CIS Benchmarks
• OpenSSH Project documentation

The post rlogin, rsh, and rcp Commands in Linux: Complete Guide to Remote Access Tools and Parameters appeared first on Abdul Wahab Junaid.

What SSH Actually Does

SSH (Secure Shell) provides an encrypted channel between a client and a server for remote command execution, file transfer, and port forwarding. Under the hood, an SSH session goes through:

1. TCP connection to the server, typically port 22.
2. Key exchange — client and server negotiate a shared session key using asymmetric cryptography (commonly Diffie-Hellman or elliptic-curve variants), establishing a symmetric encryption key for the actual session without ever transmitting it.
3. Host verification — the client checks the server’s host key against its known_hosts file, protecting against man-in-the-middle attacks.
4. Authentication — password, public key, keyboard-interactive (2FA), or GSSAPI/Kerberos.
5. Session — once authenticated, all further traffic (interactive shell, file transfer, port forwarding) is encrypted inside this single channel.

Basic Connection

ssh user@remotehost
ssh user@192.168.1.50
ssh -p 2222 user@remotehost     # non-standard port

First connection to a new host:

The authenticity of host 'remotehost (192.168.1.50)' can't be established.
ED25519 key fingerprint is SHA256:abcd1234...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

This fingerprint check matters — in a genuinely secure workflow, you’d verify this fingerprint against one provided by the server administrator through a separate channel before typing “yes,” rather than accepting blindly.

Key-Based Authentication (What You Should Actually Be Using)

Password authentication over SSH is encrypted, but it’s still vulnerable to brute-force attempts and doesn’t scale well for automation. Key-based authentication is both more secure and more convenient.

Generate a Key Pair

ssh-keygen -t ed25519 -C "your_email@example.com"

• -t ed25519 — modern, fast, and secure key type (preferred over the older rsa type for new keys)
• -C — a comment, usually your email, to help identify the key later

For environments requiring RSA specifically (some older systems, some compliance requirements):

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

You’ll be prompted for a passphrase — use one. An unencrypted private key sitting on disk is a single-file compromise away from full account takeover; a passphrase-protected key at least requires an attacker to also crack the passphrase.

Copy the Public Key to the Server

ssh-copy-id user@remotehost

Or manually, if ssh-copy-id isn’t available:

cat ~/.ssh/id_ed25519.pub | ssh user@remotehost "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Test It

ssh user@remotehost

You should be prompted for your key’s passphrase (if set) instead of the account’s server-side password — and if you’re using ssh-agent (below), not even that.

ssh-agent: Avoid Retyping Your Passphrase

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Now your passphrase is cached in memory for the duration of the agent’s life (or until you explicitly remove it), and every SSH connection using that key authenticates silently.

List currently loaded keys:

ssh-add -l

Remove all cached keys:

ssh-add -D

The SSH Config File: Making Connections Effortless

~/.ssh/config lets you define shortcuts and per-host settings instead of typing full connection strings every time:

Host prodweb
    HostName 203.0.113.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_prod

Host *.internal.example.com
    User admin
    ProxyJump bastion.example.com

Host bastion
    HostName bastion.example.com
    User jump-user
    IdentityFile ~/.ssh/id_ed25519_bastion

Now instead of ssh -p 2222 -i ~/.ssh/id_ed25519_prod deploy@203.0.113.10, you just run:

ssh prodweb

The ProxyJump directive is genuinely one of my favorite SSH features — it transparently routes your connection through a bastion/jump host, which is an extremely common production pattern for reaching private-network servers without exposing them directly to the internet.

Copying Files: scp and sftp

scp localfile.txt user@remotehost:/tmp/
scp user@remotehost:/var/log/app.log ./
scp -r localdir/ user@remotehost:/tmp/localdir/

Interactive file transfer session:

sftp user@remotehost
sftp> put localfile.txt
sftp> get remotefile.txt
sftp> ls
sftp> cd /var/log

For serious file syncing, rsync over SSH is generally the better tool — it only transfers changed data:

rsync -avz -e ssh /local/dir/ user@remotehost:/remote/dir/

Port Forwarding (Tunneling)

Local Forwarding — Reach a Remote-Only Service Through Your Local Machine

ssh -L 8080:localhost:80 user@remotehost

Now http://localhost:8080 on your machine reaches port 80 on the remote host — useful for reaching an internal admin panel that isn’t directly exposed.

Remote Forwarding — Expose a Local Service to the Remote Side

ssh -R 9000:localhost:3000 user@remotehost

Now connections to port 9000 on the remote host reach port 3000 on your local machine — useful for letting a remote server temporarily reach a service running on your laptop during development.

Dynamic Forwarding — a SOCKS Proxy Through SSH

ssh -D 1080 user@remotehost

Configure your browser or another application to use localhost:1080 as a SOCKS5 proxy, routing that traffic through the encrypted SSH tunnel — a lightweight, no-additional-software VPN alternative for browsing through a trusted remote network.

Running Commands Without an Interactive Session

ssh user@remotehost "df -h"
ssh user@remotehost "systemctl status nginx"

Useful in scripts, combined with key-based auth for fully unattended automation:

#!/bin/bash
ssh backup-server "tar czf /backup/daily-$(date +%F).tar.gz /data"
scp backup-server:/backup/daily-$(date +%F).tar.gz /local/backups/

Hardening the SSH Server (sshd_config)

Configuration lives at /etc/ssh/sshd_config. Key settings I check on every server I stand up:

# Disable root login entirely — use sudo after logging in as a normal user
PermitRootLogin no

# Disable password auth once keys are set up and confirmed working
PasswordAuthentication no

# Only allow protocol version 2 (version 1 is ancient and broken; modern sshd doesn't even offer it, but explicit is good)
Protocol 2

# Limit which users/groups can SSH in at all
AllowUsers deploy admin

# Change the default port (mild obscurity benefit — reduces automated scan noise, not a real security boundary on its own)
Port 2222

# Disable empty passwords
PermitEmptyPasswords no

# Limit authentication attempts per connection
MaxAuthTries 3

# Set an idle timeout
ClientAliveInterval 300
ClientAliveCountMax 2

Apply changes:

sudo sshd -t                     # test config syntax before restarting — always do this
sudo systemctl restart sshd

Test the new configuration from a second, separate SSH session before closing your current one. This is the single most important operational habit for SSH hardening — if PasswordAuthentication no gets applied before you’ve confirmed key-based auth actually works, and your current session drops, you may be locked out entirely without console access.

Multi-Factor Authentication with SSH

For an additional layer beyond key-based auth, PAM-based TOTP (via Google Authenticator PAM module) is a common addition:

sudo apt install libpam-google-authenticator    # Debian/Ubuntu
sudo dnf install google-authenticator           # RHEL/Fedora

google-authenticator

Then in /etc/pam.d/sshd, add:

auth required pam_google_authenticator.so

And in sshd_config:

ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

This requires both a valid SSH key and a TOTP code, combining something-you-have with something-you-know.

A Deeper Look at the SSH Protocol Handshake

Understanding the sequence a bit more precisely helps when debugging connection issues with -vvv, since the verbose output maps directly onto these stages:

1. Version exchange — client and server each announce their SSH protocol version and software identifier.
2. Algorithm negotiation — both sides propose supported key exchange algorithms, ciphers, MACs, and compression methods; they agree on the strongest mutually-supported option.
3. Key exchange (KEX) — using algorithms like curve25519-sha256 (the modern default), client and server derive a shared session key without ever transmitting it directly, even over an otherwise-observed connection.
4. Server host key verification — the client checks the server’s public host key against ~/.ssh/known_hosts; a mismatch from a previously-seen host produces the well-known (and important) warning about a potential man-in-the-middle attack.
5. User authentication — publickey, password, keyboard-interactive, or GSSAPI, attempted in an order controlled by both client preference and server’s AuthenticationMethods/PubkeyAuthentication settings.
6. Channel/session establishment — once authenticated, a logical channel is opened inside the encrypted connection for the shell, command execution, port forward, or SFTP subsystem.

ssh -vvv user@remotehost 2>&1 | grep -E "kex|Server host key|Authentication"

This kind of targeted grep against verbose output is genuinely useful for isolating exactly which stage a connection is failing at, rather than scrolling through the full firehose of debug output.

Understanding known_hosts and Host Key Rotation

cat ~/.ssh/known_hosts | head -3

Each line records a hostname (or hashed hostname, if HashKnownHosts yes is set), the key type, and the base64-encoded public host key. When a server’s host key legitimately changes — a reinstall, a migration to new hardware, an intentional key rotation — every client that’s previously connected will see the “REMOTE HOST IDENTIFICATION HAS CHANGED” warning and refuse to connect until the stale entry is removed.

ssh-keygen -R oldhostname   # remove a specific stale entry safely

Modern OpenSSH also supports host key rotation notifications via the UpdateHostKeys client option, letting a server proactively inform already-connected clients of additional or replacement host keys through an authenticated in-band mechanism — a meaningful improvement over the old “figure out if the change is legitimate by out-of-band means” workflow, though it still requires the first connection to have been trustworthy.

Certificate-Based SSH Authentication (Beyond Individual Keys)

For anything beyond a handful of servers, distributing individual public keys to every host and managing revocation by hand doesn’t scale. OpenSSH supports a certificate authority model, where a central CA key signs both user keys and host keys, and individual servers/clients simply trust the CA rather than needing every individual key added manually.

Generate a CA key (done once, kept extremely secure):

ssh-keygen -t ed25519 -f ssh_ca -C "internal SSH CA"

Sign a user’s public key, producing a short-lived certificate:

ssh-keygen -s ssh_ca -I "alice-cert" -n alice -V +8h -z 1 alice_key.pub

• -V +8h — certificate expires 8 hours from signing, a genuinely powerful control that individual static keys don’t offer.
• -n alice — restricts the certificate to authenticating as the alice principal.
• -z 1 — a serial number, used for targeted revocation later.

On the server side, configure sshd_config to trust the CA:

TrustedUserCAKeys /etc/ssh/ssh_ca.pub

This is the pattern behind most modern “ephemeral SSH access” tooling in larger organizations — rather than managing hundreds of individual authorized_keys entries across a fleet, servers trust a CA, and short-lived certificates are issued per-session, often gated behind an additional approval or SSO step.

SSH Multiplexing for Faster Repeated Connections

If you connect to the same host repeatedly in a short span (common during active administration or scripting), SSH’s connection multiplexing avoids repeating the full handshake for every single connection:

Host prodweb
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h-%p
    ControlPersist 10m

mkdir -p ~/.ssh/sockets

The first connection to prodweb establishes the underlying TCP/SSH session normally; every subsequent connection within the ControlPersist window reuses that same already-authenticated connection as a transport, making each additional ssh/scp call to the same host nearly instantaneous.

Comparing SSH to Other Remote Access Approaches

Mosh in particular is worth knowing about if you frequently work over unreliable connections — it authenticates via a normal SSH handshake, then hands off to its own UDP-based, session-persistent protocol that survives IP changes and network interruptions far more gracefully than a raw SSH TCP session does.

Auditing Who Has SSH Access to a Server

# List all authorized keys across every user's home directory
sudo find /home /root -name "authorized_keys" -exec echo {} \; -exec cat {} \;

# Check sshd's actual effective configuration (merges config file with compiled defaults)
sudo sshd -T | grep -E "permitrootlogin|passwordauthentication|allowusers"

Running sshd -T (test/dump effective config) rather than just reading sshd_config directly is worth doing periodically — it shows exactly what the daemon is actually enforcing, including any defaults not explicitly set in the file, which can differ from what a quick read of the config alone would suggest.

Troubleshooting

Connection refused — sshd isn’t running or isn’t listening on the expected port:

sudo systemctl status sshd
sudo ss -tulnp | grep ssh

Permission denied (publickey) — verify permissions on the server side; SSH is strict about this and silently refuses keys with overly permissive file modes:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Host key verification failed — the server’s host key changed (legitimate reinstall, or a potential MITM attack). Investigate before blindly removing the old entry:

ssh-keygen -R remotehost   # only after confirming the change is legitimate

Verbose debugging for any connection issue:

ssh -vvv user@remotehost

Best Practices Summary

• Use ed25519 keys with a passphrase, protected by ssh-agent for convenience.
• Disable password authentication once keys are confirmed working.
• Disable direct root login; use sudo from a normal account instead.
• Use ~/.ssh/config and ProxyJump instead of manually chaining connections.
• Test every sshd_config change with sshd -t and from a second session before closing your current one.
• Consider MFA for anything internet-facing.

Summary

SSH is the backbone of secure remote Linux administration: encrypted transport, cryptographic host verification, and flexible authentication that scales from a single interactive login to fully unattended automation. The habits that matter most are the boring ones — key-based auth over passwords, testing config changes before you commit to them, and never closing your only working session until you’ve verified the new one works.

References

• OpenSSH Project
• man sshd_config(5)
• man ssh(1)
• Red Hat Documentation – Using secure communications between two systems with OpenSSH
• Ubuntu Server Guide – OpenSSH

The post How to Use Secure Shell (SSH) for Remote Logins in Linux: Complete Connection and Security Guide appeared first on Abdul Wahab Junaid.

What TCP Wrappers Actually Are

TCP Wrappers is a library (libwrap) and a pair of configuration files (/etc/hosts.allow and /etc/hosts.deny) that provide simple access control for network services, based on the connecting client’s hostname or IP address. A service that’s been “wrapped” — either compiled against libwrap directly, or launched through the tcpd wrapper binary via inetd/xinetd — checks these two files before deciding whether to accept a connection.

This is fundamentally an application-layer access control, not a kernel-level one like netfilter/iptables. The service itself (or the wrapper daemon in front of it) consults the rules; the kernel’s network stack has no awareness of them at all.

Checking Whether a Service Supports TCP Wrappers

Not every service uses libwrap. Check if a binary is linked against it:

ldd /usr/sbin/sshd | grep libwrap

On modern OpenSSH builds, this typically returns nothing — recent OpenSSH versions dropped TCP Wrappers support in favor of relying on the OS firewall. Historically supported services include sshd (older builds), vsftpd, xinetd-launched services, and various daemons compiled with --with-libwrap.

Check what package provides the library on your system:

dpkg -l | grep tcpd        # Debian/Ubuntu
rpm -q tcp_wrappers         # RHEL/CentOS (older releases)

On many current RHEL/Fedora releases, tcp_wrappers is no longer packaged at all, reflecting its status as effectively deprecated technology.

Configuration Files

/etc/hosts.allow

Lists rules that explicitly permit access. Checked first.

/etc/hosts.deny

Lists rules that explicitly deny access. Checked second, only if nothing in hosts.allow already matched.

The Decision Logic

1. If a connection matches a rule in hosts.allow, it’s allowed, and processing stops there.
2. If not, and it matches a rule in hosts.deny, it’s denied.
3. If it matches neither file, it’s allowed by default — an important and frequently misunderstood detail. TCP Wrappers is “default allow” unless you explicitly set up a deny-everything catch-all.

Basic Syntax

service_list : client_list [: option : option ...]

• service_list — daemon name(s) as they identify themselves to libwrap (often the binary name, e.g., sshd, vsftpd), or ALL.
• client_list — hostnames, IP addresses, IP/netmask pairs, wildcards, or ALL.

Practical Examples

Allow SSH Only from a Specific Network

/etc/hosts.allow:

sshd : 192.168.1.0/255.255.255.0
sshd : 10.0.0.5

/etc/hosts.deny:

sshd : ALL

This allows SSH only from the 192.168.1.0/24 subnet and the single host 10.0.0.5, denying everyone else.

Deny Everything by Default, Allow Explicitly (Recommended Pattern)

/etc/hosts.deny:

ALL : ALL

/etc/hosts.allow:

sshd : 192.168.1.0/24
vsftpd : 192.168.1.0/24, 10.0.0.10
ALL : 127.0.0.1

This is the security-conscious default-deny approach: block everything, then poke specific holes for specific services and networks, mirroring the same philosophy used with iptables/firewalld default-deny policies.

Allow by Hostname/Domain

sshd : .example.com

The leading dot means “any host in this domain” — resolved via reverse DNS, which is itself a weakness (DNS-based rules depend on DNS integrity and can be slow if reverse lookups aren’t fast).

Using Wildcards

ALL : LOCAL
sshd : ALL EXCEPT 203.0.113.0/24

LOCAL matches any hostname without a dot (i.e., on the local domain). EXCEPT lets you carve out an exclusion within a broader match.

Combining with Actions (spawn / banners)

TCP Wrappers supports basic logging and command execution via the spawn directive, historically used for simple intrusion notification:

sshd : ALL : spawn (/usr/bin/logger -t tcpwrapper "SSH connection attempt from %h") : allow

%h expands to the client hostname. This is a genuinely dated pattern by modern logging standards (compare to structured logging via journald, or a proper IDS), but it illustrates how flexible — and how easy to misconfigure — the option syntax can get.

Testing Your Configuration

The tcpdmatch utility simulates a connection against your current rules without actually needing a live client:

tcpdmatch sshd 192.168.1.50

Example output:

client:   address  192.168.1.50
server:   process  sshd
matched:  /etc/hosts.allow line 3
access:   granted

This is worth running after every change — it’s a fast, safe way to confirm your rule logic actually does what you think before a real connection attempt tests it for you.

Real-World Use Case: xinetd-Launched Services

TCP Wrappers historically paired closely with xinetd (and its predecessor inetd), since many services launched on-demand through the super-server were compiled against libwrap or launched via the tcpd binary explicitly:

service telnet
{
    disable     = no
    socket_type = stream
    protocol    = tcp
    wait        = no
    user        = root
    server      = /usr/sbin/tcpd
    server_args = /usr/sbin/in.telnetd
}

Here, tcpd is invoked first, consults hosts.allow/hosts.deny, and only then execs the real service (in.telnetd) if access is granted.

Why TCP Wrappers Declined in Favor of Netfilter-Based Firewalls

A few structural reasons this technology has largely faded from active use:

1. Application-layer only — TCP Wrappers only protects services actually compiled against libwrap or launched through tcpd; it does nothing for services that bypass it, which is most modern software.
2. No port-level granularity — rules match on service name and client address, not on the specific port/protocol combination the way iptables can.
3. Default-allow by design — a genuinely dangerous default for a security control; forgetting a rule silently leaves access open, rather than silently blocking it.
4. glibc dropped built-in support — modern glibc doesn’t include libwrap hooks by default, so fewer and fewer services support it at all.
5. Kernel-level filtering is strictly more capable — iptables/nftables/firewalld operate before traffic even reaches the application, covering every service uniformly regardless of whether it was compiled with wrapper support.

Migrating TCP Wrapper Rules to iptables

If you’re modernizing a legacy configuration, the translation is generally straightforward. This TCP Wrappers rule:

sshd : 192.168.1.0/24

Becomes this iptables equivalent:

sudo iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -j DROP

Or the firewalld rich-rule equivalent:

sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" port protocol="tcp" port="22" accept'
sudo firewall-cmd --reload

The kernel-level version has the advantage of covering the port explicitly and applying regardless of whether the target service was ever compiled with libwrap support.

How libwrap Actually Intercepts Connections

It’s worth understanding the specific mechanism by which a service ends up consulting hosts.allow/hosts.deny at all, since “is this service even wrapped” is the very first question in any troubleshooting session.

There are two structurally different ways a service ends up subject to TCP Wrappers:

1. Compiled-in support — the daemon’s own source code is linked against libwrap and explicitly calls its hosts_ctl() function as part of its own connection-acceptance logic. The daemon itself is aware of and cooperating with TCP Wrappers.
2. External wrapping via tcpd — the daemon isn’t aware of TCP Wrappers at all; instead, a super-server (traditionally inetd, later xinetd) launches the generic tcpd binary first, which itself is linked against libwrap, checks the access rules, and only then exec()s the real service binary if access is granted.

The practical difference matters for troubleshooting: for the first case, the actual daemon’s own binary needs to show a libwrap dependency; for the second case, it’s tcpd (or the super-server’s config referencing tcpd) that matters, and the wrapped service’s own binary may show no libwrap linkage at all, since it was never compiled with awareness of the mechanism.

# Case 1: check the daemon binary directly
ldd /usr/sbin/some-daemon | grep libwrap

# Case 2: check whether xinetd is launching it through tcpd
grep -r "tcpd" /etc/xinetd.d/

The Full Option Syntax Beyond spawn

Beyond the spawn directive shown earlier, TCP Wrappers supports a small set of additional options worth knowing when reading an inherited configuration:

sshd : 192.168.1.0/24 : allow
sshd : ALL : deny
in.telnetd : ALL : twist /bin/echo "Access denied by policy."
vsftpd : .suspicious-domain.example : severity emerg

• allow/deny — explicit terminal actions, useful when you want a single line to unambiguously decide the outcome rather than relying on which file (hosts.allow vs hosts.deny) the rule happens to live in.
• twist — replaces the requested service entirely with a different command (historically used to run a decoy/honeypot response instead of the real service for connections you want to actively mislead rather than just silently reject).
• severity — overrides the syslog severity level used for logging this particular match, useful for making certain rule matches stand out more prominently in log monitoring.

Comparing hosts.allow/hosts.deny Ordering With a Concrete Example

Because the “first file wins, then check the second” logic is easy to get backwards when reading it too quickly, here’s a fully worked example showing exactly how a specific connection gets evaluated.

/etc/hosts.allow:

sshd : 192.168.1.100

/etc/hosts.deny:

sshd : 192.168.1.0/24

A connection from 192.168.1.100 (specifically):

1. Check hosts.allow — matches sshd : 192.168.1.100 — access granted, and evaluation stops entirely; hosts.deny is never consulted for this connection at all.

A connection from 192.168.1.50 (same subnet, different specific host):

1. Check hosts.allow — no match (the allow rule was for one specific address, not the whole subnet).
2. Check hosts.deny — matches sshd : 192.168.1.0/24 — access denied.

This ordering — always hosts.allow first, in full, before hosts.deny is even opened — is precisely why a single specific-host exception in hosts.allow can override an entire subnet block in hosts.deny, which is a genuinely useful pattern (allow one trusted host within an otherwise-blocked range) but also a common source of “why is this one host still getting through” confusion when reviewing an unfamiliar configuration.

TCP Wrappers and IPv6

A specific, often-overlooked limitation: classic TCP Wrappers syntax and the underlying libwrap implementation were designed in an IPv4-only era. IPv6 address matching support varies significantly by implementation and distro vintage, and older deployments may not correctly evaluate IPv6 client addresses against rules written in IPv4 dotted-decimal or CIDR notation at all.

tcpdmatch sshd ::1
tcpdmatch sshd 2001:db8::1

If you’re auditing or maintaining a system that still relies on TCP Wrappers and IPv6 is enabled on that host, explicitly verify IPv6 matching behaves as expected with tcpdmatch rather than assuming your IPv4-oriented rules automatically extend to IPv6 clients — a genuinely common gap that’s led to unintentional IPv6 exposure on hosts where the administrator believed the same access restrictions applied uniformly across both protocol families.

Practical Migration Path for a Mixed Legacy Environment

If you’re maintaining a system where some services still use TCP Wrappers and you’re gradually modernizing, a reasonable interim approach is layering both mechanisms rather than doing a risky big-bang cutover:

# Keep the existing TCP Wrappers rules as a documented, understood baseline
cat /etc/hosts.allow /etc/hosts.deny

# Add equivalent kernel-level rules as the actual enforcement layer
sudo iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -j DROP

# Verify both layers agree before removing the TCP Wrappers rules entirely
tcpdmatch sshd 192.168.1.50
sudo iptables -L INPUT -n -v

Running both simultaneously for a transition period, confirming they produce consistent decisions, then retiring the TCP Wrappers configuration once you’re confident the kernel-level rules fully cover the same access model, is a safer path than assuming a translation is correct without verification.

Troubleshooting

Rule doesn’t seem to apply — confirm the service is actually linked against libwrap in the first place; if ldd shows no libwrap dependency, TCP Wrappers has no effect on that service regardless of what’s in the config files.

Access granted when you expected denial — remember the default-allow behavior; check for a catch-all ALL : ALL in hosts.deny, since without one, anything not matched in either file is permitted.

Hostname-based rules behaving inconsistently — reverse DNS lookups can fail, time out, or resolve differently than expected; prefer IP/netmask-based rules for anything security-critical rather than relying on DNS.

Changes don’t take effect immediately — TCP Wrappers rules are read per-connection by the daemon (or by tcpd), so no service restart is typically required, but confirm with tcpdmatch rather than assuming.

Summary

TCP Wrappers offers simple, application-layer host-based access control via /etc/hosts.allow and /etc/hosts.deny, checked in that order, with default-allow behavior for anything unmatched. It’s largely superseded by kernel-level packet filtering (iptables, nftables, firewalld) on modern systems, both because fewer services support libwrap at all and because kernel-level filtering is strictly more capable and applies uniformly. Worth knowing for legacy systems and historical context; not something to build new security architecture around today.

References

• man hosts_access(5)
• man hosts.allow(5) / hosts.deny(5)
• man tcpd(8)
• Red Hat Documentation – TCP Wrappers (legacy)

The post How to Configure TCP Wrapper Security in Linux: Complete Host-Based Access Control Guide appeared first on Abdul Wahab Junaid.

What a Super-Server Does and Why It Existed

Before xinetd (and its predecessor, the original inetd), every network service — telnet, FTP, finger, talk, and dozens of smaller utilities — had to run as its own persistent daemon, sitting in memory and listening on its port continuously, whether or not anyone was actually using it. On systems with limited memory (which was essentially every system, historically), this was wasteful.

The super-server model solves this: one process, xinetd, listens on all the ports for configured services simultaneously. When a connection arrives on one of those ports, xinetd accepts it, forks, and executes the actual service binary to handle that specific connection, then the service process exits when the connection ends — no persistent per-service daemon required.

This model has genuinely fallen out of favor for most workloads, replaced by systemd socket activation (which does something conceptually similar but integrates with the modern service manager) or simply running services as always-on daemons on systems with plenty of RAM to spare. But xinetd is still present, actively used, and worth understanding on older RHEL/CentOS systems, embedded distributions, and specific service categories (like certain TFTP, time, or diagnostic services) that still default to it.

Installing xinetd

Debian/Ubuntu:

sudo apt update
sudo apt install xinetd

RHEL/CentOS/Fedora:

sudo dnf install xinetd

Enable and start it:

sudo systemctl enable --now xinetd
sudo systemctl status xinetd

Configuration Structure

xinetd’s configuration lives in two places:

• /etc/xinetd.conf — global defaults applied to all services unless overridden.
• /etc/xinetd.d/ — a directory containing one file per service, each defining that service’s specific settings.

Global Config Example (/etc/xinetd.conf)

defaults
{
    instances       = 60
    log_type        = SYSLOG authpriv
    log_on_success  = HOST PID
    log_on_failure  = HOST
    cps             = 25 30
}

includedir /etc/xinetd.d

• instances — max simultaneous instances of any one service.
• log_type — where logs go (typically syslog’s authpriv facility).
• log_on_success/log_on_failure — what detail to log for successful/failed connection attempts.
• cps — connections-per-second rate limiting: cps 25 30 allows 25 connections/second, then waits 30 seconds if that rate is exceeded, a basic built-in DoS mitigation.
• includedir — pulls in every service definition file from /etc/xinetd.d/.

Per-Service Configuration File Structure

Each file in /etc/xinetd.d/ follows this pattern:

service SERVICE_NAME
{
    disable         = no
    socket_type     = stream
    protocol        = tcp
    wait            = no
    user            = root
    server          = /path/to/server/binary
    server_args     = arguments
    port            = PORT_NUMBER
    only_from       = allowed hosts/networks
    no_access       = denied hosts/networks
    log_on_success  += extra logging options
    log_on_failure  += extra logging options
}

Key Directive Reference

Example: Configuring a TFTP Server

TFTP is one of the more common services still legitimately run under xinetd today, particularly for PXE network boot environments.

sudo dnf install tftp-server    # RHEL/Fedora
sudo apt install tftpd-hpa      # Debian/Ubuntu (note: Debian's tftpd-hpa typically uses its own init/systemd unit rather than xinetd by default)

/etc/xinetd.d/tftp (RHEL-style):

service tftp
{
    socket_type     = dgram
    protocol        = udp
    wait            = yes
    user            = root
    server          = /usr/sbin/in.tftpd
    server_args     = -s /var/lib/tftpboot
    disable         = no
    per_source      = 11
    cps             = 100 2
    flags           = IPv4
}

Restart xinetd to apply:

sudo systemctl restart xinetd

Access Control Within xinetd

Beyond the older TCP Wrappers integration (xinetd can be compiled with libwrap support, honoring /etc/hosts.allow//etc/hosts.deny in addition to its own rules), xinetd has native access control directives that don’t depend on that separate mechanism:

service telnet
{
    disable     = no
    only_from   = 192.168.1.0/24 10.0.0.5
    no_access   = 192.168.1.100
    access_times = 08:00-18:00
}

This example allows telnet only from the 192.168.1.0/24 subnet and 10.0.0.5, explicitly blocks 192.168.1.100 even though it’s inside that subnet (a more specific rule overriding a broader one), and only during business hours.

Rate Limiting and DoS Mitigation

xinetd includes several built-in protections worth knowing:

per_source  = 5      # max simultaneous connections from a single source IP
cps         = 25 30  # max connections per second globally, then pause N seconds if exceeded
max_load    = 4       # refuse new connections if system load average exceeds this

These are genuinely useful defenses against simple flooding attacks targeting a specific service, applied before the connection ever reaches the actual service binary.

Logging

Check what xinetd has logged:

sudo journalctl -u xinetd
sudo grep xinetd /var/log/syslog       # Debian/Ubuntu
sudo grep xinetd /var/log/messages      # RHEL/CentOS

Increase verbosity for troubleshooting by adding to the service block:

log_on_success += DURATION
log_on_failure += RECORD

Enabling and Disabling Individual Services

Rather than editing files by hand every time, RHEL-family systems traditionally provided a helper:

sudo chkconfig telnet on
sudo chkconfig telnet off

On systems without chkconfig, edit the disable line directly and restart xinetd:

sudo sed -i 's/disable.*=.*yes/disable = no/' /etc/xinetd.d/telnet
sudo systemctl restart xinetd

Always verify the actual running state after any change:

sudo ss -tulnp | grep xinetd

The wait Directive: A Deeper Look at Concurrency Handling

The wait directive is one of the more commonly misunderstood settings, and getting it wrong produces genuinely confusing behavior — either a service that can’t handle concurrent connections at all, or one that spawns far more instances than intended.

wait = yes (single-threaded mode) — xinetd hands off the listening socket itself to the service and then stops managing that socket entirely until the service process exits. The service is fully responsible for its own concurrency (accepting multiple simultaneous connections on the same socket itself). This mode is appropriate for datagram-based services like TFTP, where the “connection” is really a self-contained series of independent request/response exchanges the daemon manages internally.

wait = no (multi-threaded mode) — xinetd keeps managing the listening socket itself, and for every new connection, forks a fresh instance of the service to handle just that one connection, then continues listening for the next. This is the appropriate mode for typical connection-oriented services like a shell or FTP session, where each client genuinely needs its own separate, isolated process.

# Verify which mode a running instance is actually configured for
grep wait /etc/xinetd.d/tftp

Getting this backwards for a stream-oriented service (setting wait = yes when it should be no) typically manifests as the service handling only one client at a time, with subsequent connection attempts hanging until the first client disconnects — a symptom that looks like a completely different kind of bug until you check this specific setting.

A Complete Walkthrough: Adding a New Custom Service to xinetd

Beyond configuring existing packaged services, it’s worth walking through adding an entirely custom service — a pattern that comes up when integrating a small internal tool that doesn’t ship its own systemd unit or standalone daemon mode.

Suppose you have a simple diagnostic script at /usr/local/bin/status-check.sh that you want reachable on a specific internal port, restricted to your monitoring subnet:

sudo tee /etc/xinetd.d/status-check <<'EOF'
service status-check
{
    disable         = no
    type            = UNLISTED
    socket_type     = stream
    protocol        = tcp
    port            = 9999
    wait            = no
    user            = nobody
    server          = /usr/local/bin/status-check.sh
    only_from       = 10.0.5.0/24
    log_on_success  += DURATION
    log_on_failure  += HOST
}
EOF

The type = UNLISTED directive is required for any service not already registered in /etc/services under that exact name — without it, xinetd refuses to start the service, since it can’t resolve the service name against the standard services database. You’d also add a matching entry to /etc/services if you want the port to have a friendly name for other tools’ benefit:

echo "status-check    9999/tcp" | sudo tee -a /etc/services

Restart and verify:

sudo systemctl restart xinetd
sudo ss -tulnp | grep 9999

Environment and Resource Controls Per Service

Beyond access control, xinetd can constrain the resource footprint of each service it manages, which is genuinely useful for preventing one misbehaving service from starving the whole system:

service heavy-tool
{
    disable      = no
    rlimit_cpu   = 60
    rlimit_as    = 256M
    nice         = 10
    env          = PATH=/usr/local/bin:/usr/bin
    passenv      = LANG
}

• rlimit_cpu — maximum CPU seconds a single instance may consume before being killed.
• rlimit_as — maximum virtual memory (address space) a single instance may use.
• nice — process scheduling priority adjustment, useful for de-prioritizing a background/diagnostic service relative to more important workloads.
• env/passenv — explicitly set or pass through specific environment variables to the launched service, rather than inheriting xinetd’s own full environment by default.

Interfacing xinetd With systemd on Modern Distros

On systemd-based systems, xinetd itself runs as a regular systemd-managed service (xinetd.service), which means it benefits from systemd’s own dependency ordering, restart policies, and logging integration even though the services xinetd itself manages don’t get individual systemd units of their own.

systemctl cat xinetd

This shows xinetd’s own unit file — worth checking if you need to adjust its restart behavior, resource limits at the xinetd process level itself (as opposed to per-service limits configured within xinetd’s own config), or startup ordering relative to networking being fully available.

[Unit]
Description=xinetd Service
After=network.target

[Service]
ExecStart=/usr/sbin/xinetd -stayalive -pidfile /run/xinetd.pid
Type=forking
PIDFile=/run/xinetd.pid

[Install]
WantedBy=multi-user.target

If you need to override any of this (a common override being adding Restart=on-failure for extra resilience), use systemctl edit xinetd rather than modifying the packaged unit file directly, so your customization survives package upgrades.

Comparing xinetd Service Definitions Across Distro Conventions

A subtlety worth knowing if you maintain configs across both Debian and RHEL-family systems: while the xinetd configuration syntax itself is identical (it’s the same upstream project), the packaged default service files that ship with common daemons sometimes differ slightly in default settings between distros — RHEL-family packages have historically been somewhat more conservative with default only_from and logging settings than some Debian-packaged equivalents. Always read the actual shipped file after installing a package rather than assuming a configuration you’ve seen on one distro applies identically on another.

diff <(cat /etc/xinetd.d/tftp) <(ssh other-distro-host cat /etc/xinetd.d/tftp)

Troubleshooting

Service enabled in config but not responding — confirm xinetd itself is running and was restarted after the config change:

sudo systemctl status xinetd
sudo systemctl restart xinetd

“Address already in use” errors — another process (possibly a standalone daemon for the same service) is already bound to that port:

sudo ss -tulnp | grep :PORT

Connections accepted but immediately dropped — check server path is correct and the binary is actually executable by the configured user:

ls -l /path/to/server/binary

only_from/no_access rules not behaving as expected — remember more specific rules can override broader ones; test carefully and check logs (log_on_failure) to confirm which rule actually matched a given connection attempt.

xinetd vs systemd Socket Activation

Modern systemd provides a conceptually similar mechanism — socket units (.socket files) that listen on a port and start the associated service unit on first connection. The philosophical difference: systemd socket activation is meant primarily for startup efficiency and dependency ordering on services that will typically run continuously once started, while xinetd’s model assumes services genuinely start and stop per connection, with more built-in per-connection access control and rate limiting baked directly into the super-server itself.

For new deployments on systemd-based distros, socket activation is generally the more idiomatic choice; xinetd remains relevant primarily for maintaining existing configurations, embedded systems, and specific legacy services that ship with xinetd definitions by default.

Security Implications

• xinetd centralizes exposure for every service it manages — a misconfiguration in /etc/xinetd.conf (like default log_on_success settings, or an overly permissive only_from) can weaken every service under its control at once.
• Because many of the classic xinetd-managed services (telnet, tftp, finger, rsh-related daemons) are themselves legacy plaintext protocols, running xinetd at all is sometimes a signal worth auditing — the question isn’t just “is xinetd configured securely” but “should this particular service exist on this network at all.”
• Combine xinetd’s own access controls with kernel-level firewall rules (iptables/firewalld) rather than relying on xinetd’s only_from/no_access as your only line of defense — defense in depth matters here as much as anywhere else.

Summary

xinetd is a super-server that listens on behalf of multiple network services and launches them on demand, configured through /etc/xinetd.conf for global defaults and per-service files in /etc/xinetd.d/. It provides genuinely useful built-in access control (only_from/no_access/access_times) and rate limiting (cps/per_source/max_load) beyond what the underlying services might implement themselves. While largely superseded by always-on daemons and systemd socket activation for new deployments, it remains actively relevant for services like TFTP and for maintaining legacy infrastructure.

References

• man xinetd(8)
• man xinetd.conf(5)
• Red Hat Documentation – xinetd (legacy service management)
• xinetd project documentation

The post How to Configure Internet Super Server (xinetd) in Linux: Complete Service Management Guide appeared first on Abdul Wahab Junaid.

What “Standalone Service” Means

A standalone service, in this context, is a daemon that runs continuously and independently, managed directly by the init system (systemd on virtually every current distro) — as opposed to a service launched on-demand by a super-server like xinetd, or spun up transiently by socket activation. Standalone services are the persistent background processes you’d see with systemctl list-units --type=service.

Step 1: Inventory What’s Actually Running

Before disabling anything, know your baseline.

systemctl list-units --type=service --state=running

For a full list including inactive/disabled services:

systemctl list-unit-files --type=service

Cross-reference with what’s actually listening on the network — a strong signal for what’s worth scrutinizing first:

sudo ss -tulnp

Example output:

Netid  State   Local Address:Port   Process
tcp    LISTEN  0.0.0.0:22           sshd
tcp    LISTEN  0.0.0.0:631          cupsd
udp    LISTEN  0.0.0.0:5353         avahi-daemon

If this is a headless server, cupsd (printing) and avahi-daemon (mDNS/Bonjour-style service discovery) are both classic examples of services that add attack surface for zero operational benefit.

Step 2: Understand the Difference Between Stop, Disable, and Mask

This distinction trips people up constantly, so it’s worth being precise:

sudo systemctl stop SERVICE      # stops it right now, but it will start again on next boot if enabled
sudo systemctl disable SERVICE   # prevents it from starting on boot, but doesn't stop it if currently running
sudo systemctl mask SERVICE      # prevents it from being started at all, even manually or as a dependency of another unit

For genuinely turning off a service you don’t need, you typically want both stop and disable together:

sudo systemctl stop cups
sudo systemctl disable cups

Or in one command:

sudo systemctl disable --now cups

mask is the strongest option — it symlinks the unit file to /dev/null, so nothing can start it even accidentally as a dependency of something else. Reach for this when a service is not just unwanted but something you want to guarantee can never come back without deliberate intervention:

sudo systemctl mask cups

To reverse a mask later:

sudo systemctl unmask cups

Step 3: Verify a Service Is Actually Stopped

systemctl status cups

Confirm it’s no longer listening:

sudo ss -tulnp | grep cups

Confirm it won’t reappear on next boot:

systemctl is-enabled cups
# should print: disabled  (or "masked" if you masked it)

Common Services Worth Reviewing on a Server

This isn’t a “disable all of these blindly” list — it’s a starting point for asking “do I actually need this here”:

Check what a given service actually is before disabling it if you’re unsure:

systemctl status SERVICE
man SERVICE 2>/dev/null

Disabling Multiple Services at Once

sudo systemctl disable --now cups avahi-daemon bluetooth ModemManager

Auditing and Disabling Legacy Standalone Daemons (Non-systemd Remnants)

On systems with SysV init compatibility scripts still present (common on older RHEL/CentOS systems even under systemd), you might also encounter services managed through /etc/init.d/ and chkconfig:

chkconfig --list
sudo chkconfig SERVICE off
sudo service SERVICE stop

Modern systemd transparently wraps most of these, so systemctl disable --now SERVICE typically works even for these legacy-style services, but chkconfig --list is still useful for surfacing what’s actually configured to run.

A Practical Server Hardening Pass

Here’s the sequence I actually run when hardening a fresh server image:

# See what's running and listening
systemctl list-units --type=service --state=running
sudo ss -tulnp

# Disable common unnecessary services on a headless box (review this list per your actual use case first!)
sudo systemctl disable --now cups cups-browsed avahi-daemon bluetooth ModemManager 2>/dev/null

# Confirm nothing unexpected is still listening afterward
sudo ss -tulnp

# Check for any remaining SysV-style legacy services
chkconfig --list 2>/dev/null

I always run the ss -tulnp check both before and after — the “after” check confirms the disabling actually took effect and nothing else quietly restarted the service as a dependency.

Handling Services That Restart Themselves

Some services get re-triggered by socket activation, timers, or another unit’s dependency chain, even after you’ve disabled them. Diagnose with:

systemctl status SERVICE
journalctl -u SERVICE --since "10 minutes ago"

Look specifically for “Triggered by” or dependency information in the status output — if another unit (like a .socket or .path unit) is what’s actually starting it, you need to disable that unit as well:

systemctl list-dependencies SERVICE --reverse
sudo systemctl disable --now SERVICE.socket

Automating This as Part of Provisioning

For fleets of servers, doing this by hand every time doesn’t scale. A simple hardening script:

#!/bin/bash
UNWANTED_SERVICES=(cups cups-browsed avahi-daemon bluetooth ModemManager)

for svc in "${UNWANTED_SERVICES[@]}"; do
    if systemctl list-unit-files | grep -q "^${svc}.service"; then
        systemctl disable --now "$svc" 2>/dev/null
        echo "Disabled: $svc"
    fi
done

For configuration management at scale, tools like Ansible make this declarative and idempotent:

- name: Disable unnecessary services
  ansible.builtin.systemd:
    name: "{{ item }}"
    state: stopped
    enabled: false
  loop:
    - cups
    - avahi-daemon
    - bluetooth

Understanding systemd Unit Dependency Chains Before You Disable Anything

The single most common mistake in a service-disabling pass isn’t disabling something genuinely needed — it’s disabling something that a different, more important service quietly depends on, and only discovering that dependency when the important thing breaks later. Before disabling anything you’re not already confident about, check its reverse dependencies:

systemctl list-dependencies --reverse cups

This shows what would be affected if cups stopped — if the output includes something you actually care about, that’s your signal to investigate further before proceeding, rather than a green light to disable freely.

It’s also worth understanding the different kinds of unit relationships systemd tracks, since not all of them mean “requires”:

• Requires= — a hard dependency; if the required unit fails, the dependent unit is stopped too.
• Wants= — a soft dependency; the wanted unit is started alongside, but its failure doesn’t stop the dependent unit.
• After=/Before= — pure ordering, with no dependency implication at all — a unit can be ordered after another without requiring it to even be running.

systemctl show cups -p Requires -p Wants -p RequiredBy -p WantedBy

Reading these fields directly, rather than guessing from the service name alone, is the difference between a confident disabling decision and one you’ll be debugging at an inconvenient hour later.

Socket-Activated and Path-Activated Services: A Special Case

Some services aren’t started directly at boot at all — they’re started on-demand the first time something connects to a socket or a watched file/path changes, via a corresponding .socket or .path unit. Disabling the .service unit alone in these cases often has no effect, because it’s the socket/path unit doing the actual triggering.

systemctl list-units --type=socket --state=active
systemctl list-units --type=path --state=active

If you disable cups.service but cups.socket remains enabled, the very next print-related connection attempt will start cups.service right back up, regardless of its own enabled/disabled state — the socket unit’s activation bypasses that check. The fix is to disable both:

sudo systemctl disable --now cups.socket cups.path cups.service 2>/dev/null

This is a genuinely common source of “I disabled it but it keeps coming back” confusion, and checking for a same-named .socket or .path unit is the first thing worth doing whenever a disable doesn’t stick.

A More Thorough Server Hardening Checklist

Beyond the handful of commonly-cited services (cups, avahi, bluetooth), a more thorough pass through a fresh server image worth walking through explicitly:

# Full inventory of enabled services, sorted for readability
systemctl list-unit-files --type=service --state=enabled | sort

# Cross-reference against what's actually listening
sudo ss -tulnp

# Check for services that are running but weren't part of the base image
# (useful after inheriting a server someone else configured)
rpm -qa --last | head -20     # RHEL — recently installed packages, oldest install activity first
grep " install " /var/log/dpkg.log | tail -20   # Debian equivalent

Beyond the obvious desktop-oriented services, it’s worth specifically reviewing:

• rpcbind — required for NFS and some legacy RPC-based services; if nothing on the box actually serves or mounts NFS, this can typically be disabled, closing off a service that’s had a long history of security advisories.
• postfix/sendmail — many distros install a local MTA by default purely so system utilities and cron can send local notification mail; if nothing on the box actually needs to send external mail, consider configuring it in local-only mode rather than leaving it listening on all interfaces, or disabling it entirely if local mail delivery genuinely isn’t needed.
• snapd — relevant primarily on Ubuntu; if you don’t use snap packages at all, this can often be removed rather than merely disabled.
• cockpit — a web-based server management UI on some RHEL-family installs; convenient, but represents meaningful attack surface (a full web application and its own auth stack) if you’re not actually using it for management.

Handling Firmware/Hardware-Triggered Services Carefully

A category worth extra caution: services tied to physical hardware detection (like udisks2 for removable media, or various hardware-monitoring daemons). These are usually harmless to disable on a headless server that will never have removable media inserted, but on physical hardware (as opposed to a VM/cloud instance), some of these also feed into legitimate hardware health monitoring — disabling blindly on bare-metal without checking what depends on it can occasionally remove monitoring capability you actually wanted.

systemctl status smartd    # disk health monitoring — usually worth KEEPING on physical hardware
systemctl status lm-sensors 2>/dev/null    # temperature/voltage sensors — same caution applies

The general principle: services tied to network exposure (listening ports, discovery protocols) are almost always safe disable candidates on a server that doesn’t need them; services tied to local hardware health monitoring deserve a second look specifically on physical hardware, since disabling them trades away visibility rather than just reducing attack surface.

Automating the Audit Itself, Not Just the Disabling

Beyond the one-time disabling script shown earlier, it’s worth having a standing audit script that reports (without acting) on anything that’s changed since the last known-good baseline — useful for catching a service that got silently re-enabled by a package update or a colleague’s troubleshooting session:

#!/bin/bash
BASELINE="/etc/service-baseline.txt"
CURRENT=$(systemctl list-unit-files --type=service --state=enabled | sort)

if [ ! -f "$BASELINE" ]; then
    echo "$CURRENT" > "$BASELINE"
    echo "Baseline created."
    exit 0
fi

diff <(cat "$BASELINE") <(echo "$CURRENT")

Running this periodically (via cron or a configuration-management drift check) turns “turn off unnecessary services” from a one-time hardening pass into an ongoing, low-effort control rather than something that quietly erodes the first time someone installs a new package that pulls in an unwanted service as a dependency.

Troubleshooting

Disabled a service and something else broke — check reverse dependencies before disabling anything on a production system you don’t fully understand yet:

systemctl list-dependencies --reverse SERVICE

Service keeps coming back after disable — check for socket/path/timer units and any other unit that lists it as a dependency, as covered above.

Not sure if a service is safe to disable — check its actual resource usage and recent logs before deciding; a service that’s been silently running for years with zero connections and zero log activity is a much safer disable candidate than one with regular recent activity:

journalctl -u SERVICE --since "30 days ago" | tail -50

Security and Performance Implications

Every standalone service running is: additional code that could contain a vulnerability, additional listening ports that widen the network attack surface, additional memory and CPU consumed at idle, and additional complexity when auditing what a system actually does. None of that is hypothetical — unused services with old, unpatched code are a recurring theme in real-world compromises, precisely because nobody’s paying attention to a thing they forgot was even running. Disabling what you don’t use is one of the few security improvements that costs essentially nothing in terms of functionality lost.

Summary

Turning off standalone services in Linux comes down to three systemd commands — stop, disable, and mask — applied deliberately after actually auditing what’s running and what’s listening on the network. The habit worth building is doing this audit as a routine part of provisioning any new server, not as a one-time cleanup exercise, and always verifying with ss -tulnp and systemctl is-enabled that a change actually took effect and stuck across a reboot.

References

• systemd.unit(5) man page
• systemctl(1) man page
• CIS Benchmarks
• Red Hat Documentation – Managing systemd services

The post How to Turn Off Standalone Services in Linux: Complete Service Disabling and Security Hardening Guide appeared first on Abdul Wahab Junaid.