Configuring A Firewall With Iptables On Older RHEL

On older Red Hat Enterprise Linux systems, iptables provides a direct way to control IPv4 traffic. It evaluates packets against an ordered ruleset and accepts, rejects, or drops them according to the first matching rule. This remains useful on RHEL 5 and 6, CentOS 5 and 6, and carefully maintained legacy systems where firewalld is not installed.

A firewall policy should be planned before commands are entered. A remote administrator in Sydney, Melbourne, or Perth can lock themselves out with one incorrect rule, especially when working over SSH. Test from a second session, keep console access available, and record the existing configuration before making changes.

Check The Existing Firewall

First identify the operating system and inspect the current rules:

cat /etc/redhat-release
sudo iptables -L -n -v --line-numbers
sudo iptables -t nat -L -n -v
sudo service iptables status

The -n option avoids slow DNS lookups, while -v shows counters and interfaces. Check whether another firewall manager is active. On RHEL 7, firewalld commonly owns the filtering framework, so stopping it before enabling the traditional service prevents competing configurations.

sudo service firewalld stop
sudo chkconfig firewalld off

Define A Safe Default Policy

A small server often needs to allow loopback traffic, established connections, SSH, and selected application ports. Set the input policy to drop only after allowing the traffic required for administration:

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

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 -m conntrack \
  --ctstate NEW -j ACCEPT

Older installations may use -m state --state ESTABLISHED,RELATED instead of the conntrack syntax. Confirm that SSH is really listening on port 22 before relying on this rule. If SSH uses a custom port, substitute it accordingly and retain an existing administrative session while testing.

Allow Web And Essential Services

For a web server, allow HTTP and HTTPS only when those services are installed and intended to be public:

sudo iptables -A INPUT -p tcp -m multiport \
  --dports 80,443 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

ICMP can help with diagnostics, although some organisations restrict it. DNS, SMTP, database, and monitoring ports should be opened only to known networks where possible. For practical Nginx and Apache deployment references, consult these web server guides alongside the firewall rules.

Restrict Administrative Access

Publicly exposing SSH increases password-guessing noise and the risk of compromise. If administration comes from a fixed office, VPN, or management subnet, narrow the rule:

sudo iptables -D INPUT -p tcp --dport 22 \
  -m conntrack --ctstate NEW -j ACCEPT

sudo iptables -A INPUT -p tcp --dport 22 -s 203.0.113.0/24 \
  -m conntrack --ctstate NEW -j ACCEPT

Replace the example network with a real trusted range. An Australian business may administer a host in a Brisbane office while its workloads run in a Sydney data centre, so verify the public source address rather than assuming the office LAN address will appear remotely. VPN users should generally be permitted through the VPN interface or address pool.

Add Logging Without Creating Noise

Logging rejected traffic can reveal scans and configuration errors, but an unrestricted log rule may fill /var/log/messages quickly. Add a rate limit and place the logging rule immediately before the final drop:

sudo iptables -A INPUT -m limit --limit 5/min \
  --limit-burst 10 -j LOG --log-prefix "iptables denied: " \
  --log-level 4

The default INPUT DROP policy then discards packets that did not match an allow rule. Review messages with grep iptables /var/log/messages and coordinate retention with logrotate. On a busy public service, centralised logging and monitoring are preferable to verbose local output.

Test Rules In A Controlled Order

Inspect the completed ruleset and its packet counters:

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

From another host, test SSH, HTTP, HTTPS, and any deliberately restricted port. Use curl, nc, or nmap from an authorised test machine, and confirm the service itself is listening with ss -lntup. Rules are processed from top to bottom, so an early broad accept can make a later restrictive rule ineffective.

If a rule is wrong, delete it by number:

sudo iptables -D INPUT 5

Avoid flushing a working remote ruleset without a recovery plan. A scheduled rollback script, out-of-band console, or hosting-provider rescue console is valuable when maintaining systems during Australian business hours across different time zones.

Save And Restore The Configuration

Runtime rules disappear after a reboot unless they are saved. On RHEL 6 and systems using the legacy service scripts, use:

sudo service iptables save
sudo service iptables restart
sudo chkconfig iptables on

This normally writes /etc/sysconfig/iptables. On RHEL 7, install the compatibility service if required:

sudo yum install iptables-services
sudo systemctl enable iptables
sudo systemctl start iptables
sudo service iptables save

Keep a readable backup outside the host:

sudo iptables-save | sudo tee /root/iptables-$(date +%F).rules

When editing saved files manually, careful terminal workflows and Emacs configuration notes can help, but always validate the resulting syntax before rebooting. Test restoration with iptables-restore < /path/to/rules only when console access is available.

Account For IPv6 And Legacy Limits

iptables manages IPv4. If IPv6 is enabled, inspect and secure it separately with ip6tables; otherwise, an application may remain reachable over an unfiltered IPv6 address:

sudo ip6tables -L -n -v
sudo service ip6tables status

Older RHEL releases also lack newer nftables features and may use obsolete cryptographic libraries or kernels. Keep the host patched within its supported lifecycle, minimise exposed services, and plan migration to a maintained platform. The firewall is one control in a wider security policy, not a replacement for updates, strong authentication, and application hardening.

The key point to remember is that a reliable legacy RHEL firewall has an explicit policy, carefully ordered exceptions, tested remote access, separate IPv6 consideration, and rules saved for the next reboot.