Configure iptables firewall rules on RHEL 8

Knowing how to configure a firewall with iptables on RHEL 8 starts with identifying which service owns the rules. The commands work with RHEL 8’s iptables interface whether it is backed by nftables or the separately selected legacy implementation.

Plan policy around SSH access, required services and IPv6 before changing defaults. Keep a console session open, back up the ruleset and test the saved configuration so a mistaken rule does not lock out an administrator.

Understand the RHEL 8 firewall stack

RHEL 8 normally ships with firewalld and supports both the legacy iptables service and the newer nftables service. The installed iptables command may report nf_tables or legacy, depending on package alternatives and the selected backend. Check iptables --version and avoid mixing rules from the two implementations.

Choose one owner: firewalld, nftables or a direct iptables service. Overlapping managers can flush or overwrite each other, and the iptables and nftables services should not manage the same host simultaneously. For broader administration context, the site’s Linux administration guides cover service hardening and practical command-line workflows.

The host firewall is only one layer. Cloud security groups, hypervisor controls and upstream firewalls still apply, especially when the same RHEL image runs across on-premises and public-cloud infrastructure.

Prepare safely before changing rules

Install the package if needed, then inspect the active chains, default policies, services and IPv4 and IPv6 rules:

sudo dnf install -y iptables
sudo iptables --version
sudo iptables -L -n -v
sudo iptables -S
sudo ip6tables -L -n -v
systemctl is-active firewalld

Save the current state in your home directory and keep the recovery command handy:

sudo iptables-save > "$HOME/iptables.backup"
sudo ip6tables-save > "$HOME/ip6tables.backup"
sudo iptables-restore < "$HOME/iptables.backup"

The restore command is for recovery rather than routine execution. Keep an out-of-band or provider console available, and do not begin by flushing every chain. This packet filtering fundamentals guide explains the traversal paths that determine where each rule belongs.

Define the trusted network policy

Start with trust boundaries. Restrict SSH to a bastion, VPN or fixed administration address instead of the whole internet. Australian home broadband may use dynamic addressing or carrier-grade NAT, so a blanket SSH allowance can become unexpectedly broad.

On a reviewed ruleset, allow local traffic, tracked connections and the approved SSH source before tightening the input policy:

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 -s 192.0.2.10/32 --dport 22 \
  -m conntrack --ctstate NEW -j ACCEPT

Replace the documentation address 192.0.2.10/32 with the actual administration source. Locate and remove any earlier catch-all ACCEPT rule before applying conservative defaults:

sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT

Leave the FORWARD policy unchanged on hosts running containers, VPNs or routed services until their dependency chains are mapped. Log unmatched traffic sparingly because excessive logging can consume disk space:

sudo iptables -A INPUT -m limit --limit 5/min --limit-burst 10 \
  -j LOG --log-prefix "iptables-input-drop: "
sudo iptables -A INPUT -j DROP

Allow required services and protocols

Expose only the ports the host actually provides. For a public web server running Nginx or Apache, an HTTP and HTTPS allowance may resemble this:

sudo iptables -A INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT

If the server requires only HTTPS, permit port 443 alone. Database, Redis and management ports should normally remain restricted to application servers or private administration networks.

Cloud instances in AWS Sydney (ap-southeast-2) and Melbourne (ap-southeast-4) commonly sit behind network security groups as well as iptables. Match those groups to the host policy: permit inbound traffic only to required ports and keep SSH reachable through the approved administration path.

Treat IPv6 separately. ip6tables may carry different rules, so inspect both address families and repeat the required allowances and restrictions for IPv6 rather than assuming an IPv4 rule protects it.

Persist and verify the ruleset

When a direct iptables service owns the rules, save the tested ruleset to the path used by that service:

sudo iptables-save | sudo tee /etc/sysconfig/iptables >/dev/null
sudo ip6tables-save | sudo tee /etc/sysconfig/ip6tables >/dev/null

Check which units are installed, then enable the applicable service:

systemctl list-unit-files 'iptables*' 'ip6tables*'
sudo systemctl enable --now iptables

Enable a separate ip6tables unit when one is provided and required. After starting or reloading the service, open a second SSH session and confirm the expected rules and counters. Schedule a reboot test only after normal access has been verified. The site’s RHEL administration tutorials include persistence, Nginx and troubleshooting workflows for comparable tasks.

Operational safeguards for Australian teams

Australian SMEs and managed service providers often support RHEL estates in Sydney, Melbourne and regional locations across widely separated business hours. Documented changes, out-of-band access and tested rollback paths are especially valuable for small teams managing cloud and on-premises systems together.

The legal context also matters. The Privacy Act 1988 and Australian Privacy Principles govern many organisations’ handling of personal information, while state and territory privacy laws may also apply. The ASD Essential Eight is a security framework rather than legislation, and a firewall alone satisfies neither privacy obligations nor broader risk controls.

Restrict SSH to named administrators or a VPN, and review dynamic source addresses regularly.
Apply an equivalent IPv6 policy and align it with cloud security groups.
Keep versioned rules, service status and rule-counter output in change records.
Test restoration and a fresh SSH session after every firewall change.

The essential point to remember is that a reliable RHEL 8 firewall combines one clear policy owner, least-privilege rules, persistent configuration and a tested recovery path.