Godaddy – How to Fix SSH/WHM Lockout from Rescue Mode by Cleaning Saved Firewall Rules

Uncategorized

A Practical Recovery Tutorial for WHM/cPanel, AlmaLinux, CentOS, Rocky Linux, and RHEL Servers

Firewall lockout is one of the most stressful server incidents. A small mistake in iptables, nftables, CSF, or firewalld can suddenly block SSH, WHM, cPanel, and ping while websites may still continue working on ports 80 and 443.

This tutorial explains how to recover a Linux VPS/server from rescue mode by cleaning the saved firewall rules of the original operating system, not the temporary rescue environment.

This is useful when:

SSH is not accessible
WHM/cPanel is not accessible
Ping stops after boot
Only websites on 80/443 are working
Firewall rules were saved incorrectly
Your own IP changed after adding firewall allow rules
The server boots normally but you cannot log in

Important Concept: Rescue Mode Firewall Is Not the Real Server Firewall

When a server is booted into rescue mode, you are usually running a temporary operating system provided by the hosting provider.

So this command in rescue mode:

systemctl disable firewalld nftables iptables ip6tables csf lfd

may affect only the rescue OS, not your real WHM/cPanel installation.

To fix the real server, you must:

1. Mount the original root partition
2. Edit the saved firewall files inside the mounted disk
3. Disable firewall services inside the original OS
4. Reboot back into normal mode
5. Rebuild safe firewall rules

Common Symptoms

You may see something like this from your local machine:

Request timeout for icmp_seq 141
Request timeout for icmp_seq 142
64 bytes from SERVER_IP: icmp_seq=145 ttl=33 time=283 ms
64 bytes from SERVER_IP: icmp_seq=146 ttl=33 time=285 ms
Request timeout for icmp_seq 149
Request timeout for icmp_seq 150

This usually means:

Network comes up during boot
Then firewall rules load
Then ping/SSH/WHM gets blocked

If websites are still accessible, the server is alive. The issue is usually firewall access, not a dead server.


Example Scenario

Assume:

Server IP: 92.205.20.47
Your current admin IP: 1.73.146.125
Original root partition: /dev/sda4
Mount point: /mnt/original

Do not blindly use old IPs. First confirm your current public IP from your local machine:

curl -4 ifconfig.me

If your IP changes frequently, do not rely on only one fixed IP without a recovery method.


Part 1: Boot Server into Rescue Mode

Use your hosting provider panel to boot the server into rescue mode.

Then log in to the rescue shell as root.

Confirm available disks:

lsblk -f

You may see something like:

sda
├─sda1
├─sda2
├─sda3
└─sda4

In many systems, the real root partition may be:

/dev/sda4

But it may also be:

/dev/sdb4
/dev/vda4
/dev/nvme0n1p4

Always verify before mounting.


Part 2: Mount the Original OS

Assuming your real root partition is /dev/sda4:

mkdir -p /mnt/original
mount /dev/sda4 /mnt/original

If the partition is different, replace /dev/sda4 with the correct partition.

Confirm it looks like a real Linux root filesystem:

ls -lah /mnt/original

You should see directories like:

etc
root
home
usr
var
boot

For a WHM/cPanel server, you may also see:

ls -ld /mnt/original/usr/local/cpanel /mnt/original/var/cpanel 2>/dev/null

Part 3: Backup Existing Firewall Configuration

Before changing anything, create one backup directory and copy all firewall-related files there.

BACKUP_DIR="/mnt/original/root/firewall-backup-$(date +%F-%H%M)"
mkdir -p "$BACKUP_DIR"

cp -a /mnt/original/etc/sysconfig/iptables* "$BACKUP_DIR"/ 2>/dev/null || true
cp -a /mnt/original/etc/nftables.conf "$BACKUP_DIR"/ 2>/dev/null || true
cp -a /mnt/original/etc/firewalld "$BACKUP_DIR"/ 2>/dev/null || true
cp -a /mnt/original/etc/csf "$BACKUP_DIR"/ 2>/dev/null || true

echo "Backup saved at: $BACKUP_DIR"

This protects files such as:

/etc/sysconfig/iptables
/etc/sysconfig/ip6tables
/etc/nftables.conf
/etc/firewalld/
/etc/csf/

Part 4: Reset Saved iptables Rules to ACCEPT

Create safe, open saved rules for IPv4:

mkdir -p /mnt/original/etc/sysconfig

cat > /mnt/original/etc/sysconfig/iptables << 'EOF'
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
EOF

Create safe, open saved rules for IPv6:

cat > /mnt/original/etc/sysconfig/ip6tables << 'EOF'
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
EOF

This removes saved DROP rules that may block SSH, WHM, or cPanel after reboot.


Part 5: Reset nftables Rules

If nftables was used, reset its saved config too:

cat > /mnt/original/etc/nftables.conf << 'EOF'
flush ruleset
EOF

This prevents old nftables rules from being restored during boot.


Part 6: Disable Firewall Services in the Original OS

Do not just run systemctl disable in rescue mode without pointing to the original OS.

Use systemctl --root:

systemctl --root=/mnt/original disable firewalld 2>/dev/null || true
systemctl --root=/mnt/original disable nftables 2>/dev/null || true
systemctl --root=/mnt/original disable iptables 2>/dev/null || true
systemctl --root=/mnt/original disable ip6tables 2>/dev/null || true
systemctl --root=/mnt/original disable csf 2>/dev/null || true
systemctl --root=/mnt/original disable lfd 2>/dev/null || true

If systemctl --root does not work, use chroot:

mount --bind /dev /mnt/original/dev
mount --bind /proc /mnt/original/proc
mount --bind /sys /mnt/original/sys
mount --bind /run /mnt/original/run

chroot /mnt/original /bin/bash -c "systemctl disable firewalld nftables iptables ip6tables csf lfd 2>/dev/null || true"

Part 7: Disable CSF If It Exists

If CSF exists, create a disable marker:

touch /mnt/original/etc/csf/csf.disable 2>/dev/null || true

You can also inspect CSF files:

ls -lah /mnt/original/etc/csf 2>/dev/null

Check if your IP was blocked:

grep -R "YOUR_IP_HERE" /mnt/original/etc/csf/ 2>/dev/null

Example:

grep -R "1.73.146.125" /mnt/original/etc/csf/ 2>/dev/null

Part 8: Reboot into Normal Mode

Once saved firewall rules are cleaned:

reboot

Now boot the server back into normal mode from your provider panel if required.


Part 9: Verify Access After Normal Boot

From your local machine:

ping 92.205.20.47

Test important ports:

for p in 22 80 443 2087 2086 2083 2082 2095 2096; do
  echo "Testing port $p"
  nc -vz -G 5 92.205.20.47 $p
done

Meaning:

succeeded  = port reachable
timeout    = firewall drop or network block
refused    = service not listening

If SSH gives a host key warning:

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

verify the server fingerprint from console:

ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub

Then remove the old known host entry from your local machine:

ssh-keygen -R 92.205.20.47

Reconnect:

ssh USERNAME@92.205.20.47

Part 10: Rebuild Firewall Rules Safely After Login

After you regain SSH/WHM access, rebuild firewall rules carefully.

First, confirm your current public IP:

curl -4 ifconfig.me

Example:

1.73.146.125

Set it:

MYIP="1.73.146.125"

Now create safer rules.

Important: Always include this rule:

-m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

This protects existing SSH sessions from being killed when new DROP rules are added.

Run as root:

iptables -F INPUT
iptables -P INPUT ACCEPT

iptables -I INPUT 1 -i lo -j ACCEPT
iptables -I INPUT 2 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I INPUT 3 -p tcp -m multiport --dports 80,443 -j ACCEPT
iptables -I INPUT 4 -p tcp -s "$MYIP" -m multiport --dports 22,2087,2086,2083,2082,2095,2096 -j ACCEPT
iptables -I INPUT 5 -p icmp -s "$MYIP" --icmp-type echo-request -j ACCEPT

iptables -A INPUT -p tcp -m multiport --dports 22,2087,2086,2083,2082,2095,2096 -j DROP

Save rules:

iptables-save > /etc/sysconfig/iptables

Important WHM/cPanel Ports

For WHM/cPanel servers:

22    SSH
80    HTTP
443   HTTPS
2082  cPanel non-SSL
2083  cPanel SSL
2086  WHM non-SSL
2087  WHM SSL
2095  Webmail non-SSL
2096  Webmail SSL

Usually:

80 and 443 should be public
22, 2086, 2087, 2082, 2083 should be restricted to admin IPs

Safer Temporary Rule for Dynamic IP Users

If your ISP changes your IP often, a single IP rule may lock you out.

Example problem:

Allowed IP: 1.73.128.79
Actual IP:  1.73.146.125
Result: SSH blocked

In emergency situations, you can temporarily allow a small subnet:

MYNET="1.73.146.0/24"

iptables -I INPUT 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I INPUT 2 -p tcp -s "$MYNET" -m multiport --dports 22,2087,2086,2083,2082,2095,2096 -j ACCEPT

Then test access. After recovery, narrow the rule if you have a static VPN or fixed office IP.


How to Check Current Firewall Rules

iptables -L INPUT -n --line-numbers

Check saved rules:

cat /etc/sysconfig/iptables

Check nftables:

nft list ruleset

Check active firewall services:

systemctl status firewalld --no-pager
systemctl status nftables --no-pager
systemctl status iptables --no-pager
systemctl status csf --no-pager
systemctl status lfd --no-pager

Emergency Rollback from Normal Mode

If your SSH session is still active but firewall rules are wrong, immediately run:

iptables -F INPUT
iptables -P INPUT ACCEPT
iptables-save > /etc/sysconfig/iptables

This opens INPUT traffic again.

Then rebuild rules slowly.


Emergency Rollback from Rescue Mode

If you are locked out again, boot into rescue mode and run:

mkdir -p /mnt/original
mount /dev/sda4 /mnt/original

Then reset saved firewall rules:

cat > /mnt/original/etc/sysconfig/iptables << 'EOF'
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
EOF

cat > /mnt/original/etc/sysconfig/ip6tables << 'EOF'
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
EOF

cat > /mnt/original/etc/nftables.conf << 'EOF'
flush ruleset
EOF

Disable firewall services for the original OS:

systemctl --root=/mnt/original disable firewalld nftables iptables ip6tables csf lfd 2>/dev/null || true

Then reboot:

reboot

Common Mistake That Causes Lockout

This is risky:

MYIP="1.73.128.79"

iptables -I INPUT 1 -p tcp -m multiport --dports 80,443 -j ACCEPT
iptables -I INPUT 2 -p tcp -s $MYIP -m multiport --dports 22,2087,2086,2083,2082,2095,2096 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 22,2087,2086,2083,2082,2095,2096 -j DROP

Why?

Because if your real current IP is different, for example:

1.73.146.125

then your SSH will be blocked.

Also, without:

iptables -I INPUT 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

your active SSH session may freeze or become unstable.

The safer version is:

MYIP="$(curl -4 -s ifconfig.me)"

iptables -F INPUT
iptables -P INPUT ACCEPT

iptables -I INPUT 1 -i lo -j ACCEPT
iptables -I INPUT 2 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I INPUT 3 -p tcp -m multiport --dports 80,443 -j ACCEPT
iptables -I INPUT 4 -p tcp -s "$MYIP" -m multiport --dports 22,2087,2086,2083,2082,2095,2096 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 22,2087,2086,2083,2082,2095,2096 -j DROP

iptables-save > /etc/sysconfig/iptables

Final Recommended Recovery Flow

Use this sequence:

1. Boot into rescue mode
2. Mount original OS root partition
3. Backup firewall config files
4. Reset /etc/sysconfig/iptables
5. Reset /etc/sysconfig/ip6tables
6. Reset /etc/nftables.conf
7. Disable firewalld/nftables/iptables/csf/lfd in original OS
8. Reboot normal mode
9. Confirm SSH/WHM access
10. Rebuild firewall with current IP
11. Add ESTABLISHED,RELATED rule
12. Save firewall rules
13. Test from a second terminal before closing existing session

Conclusion

Yes, you can clean saved firewall rules from rescue mode, but the key is this:

Do it on the mounted original OS, not the rescue OS.

The safest recovery strategy is to temporarily reset firewall rules to ACCEPT, regain SSH/WHM access, then rebuild firewall rules carefully using your current public IP.

For WHM/cPanel servers, keep websites public on:

80, 443

Restrict admin services to your trusted IP:

22, 2086, 2087, 2082, 2083, 2095, 2096

And always add this before applying DROP rules:

iptables -I INPUT 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

That one rule can save you from locking yourself out again.

0 0 votes
Article Rating
Subscribe
Notify of
guest
0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x