Panic Mode

Introduction

Sometimes, things go wrong. Very wrong. Maybe you see a hacker attacking your server, or a virus spreading rapidly. You need to disconnect the computer from the network immediately.

firewalld provides a feature called panic mode. When enabled, the firewall drops all incoming and outgoing connections immediately.

That is why panic mode belongs to incident response, not normal tuning. It is designed for rapid containment when preserving connectivity matters less than stopping communication immediately.

This is an emergency containment feature. It is not for normal administration, but it is useful to understand because it shows that firewall policy can also be used as a rapid isolation tool during incidents.

The Problem with Remote Servers:

If you are sitting in front of the physical server, this is fine. But in a remote environment (like this LabEx VM or a cloud server), turning on Panic Mode will instantly cut your own connection. You will be locked out, unable to turn it back off!

In this lab, you will learn how to simulate and test this feature safely by creating a "Dead Man's Switch" script. This script will turn Panic Mode on, run a test, and then automatically turn it back off, ensuring you regain access.

Create a Safe Test Script

Since we cannot run firewall-cmd --panic-on directly without losing our session, we will write a script to handle the process automatically.

This is also a broader operations technique: when a network change could lock you out, automate the rollback before you make the risky change. That reduces the chance of turning a test into an outage.

This script will:

1. Log a "Before" ping (Success).
2. Enable Panic Mode.
3. Log a "During" ping (Should fail).
4. Disable Panic Mode (Restoring access).

Create a file named safe_panic_test.sh:

nano safe_panic_test.sh

Paste the following content into it:

#!/bin/bash
LOGFILE="panic_test.log"

echo "--- PHASE 1: Normal State ---" > $LOGFILE
ping -c 2 8.8.8.8 >> $LOGFILE 2>&1

echo "" >> $LOGFILE
echo "--- PHASE 2: Enabling PANIC MODE ---" >> $LOGFILE
firewall-cmd --panic-on
echo "Panic Mode is ON." >> $LOGFILE

echo "Attempting to ping 8.8.8.8 (Should fail)..." >> $LOGFILE
## -W 2 means wait max 2 seconds for response
ping -c 2 -W 2 8.8.8.8 >> $LOGFILE 2>&1

echo "" >> $LOGFILE
echo "--- PHASE 3: Disabling PANIC MODE ---" >> $LOGFILE
firewall-cmd --panic-off
echo "Panic Mode is OFF." >> $LOGFILE

echo "Checking connectivity restored..." >> $LOGFILE
ping -c 2 8.8.8.8 >> $LOGFILE 2>&1

Save and exit (Ctrl+O, Enter, Ctrl+X).

Make the script executable:

chmod +x safe_panic_test.sh

Run the Test Safely

Now comes the critical part. If you run this script normally, your session might disconnect the moment Panic Mode turns on, killing the script before it can turn Panic Mode off.

To prevent this, we use nohup (No Hang Up). This allows the script to keep running in the background even if your terminal session dies.

This is a good example of separating process lifetime from terminal lifetime. The safety of the experiment depends on the recovery script surviving even if your interactive session cannot.

Run the script with sudo and nohup:

sudo nohup ./safe_panic_test.sh &

What to expect:

1. Your terminal might freeze or become unresponsive for about 5-10 seconds. Do not refresh the page.
2. Once the script finishes phase 3 (Disabling Panic Mode), your connection should automatically recover.

Wait for at least 15 seconds.

Analyze Results

Now that your connection is back, let's examine the log file to verify that Panic Mode actually worked.

Verification here is especially important because panic mode is intentionally disruptive. You want proof that isolation occurred during the test and that normal connectivity returned afterward.

Read the log file:

cat panic_test.log

You should see a sequence like this:

1. PHASE 1: Ping successful.
2. PHASE 2: Panic Mode ON. The ping attempt here should show errors like Network is unreachable or 100% packet loss.
3. PHASE 3: Panic Mode OFF. Ping successful again.

This confirms that for those few seconds, your server was completely isolated from the network.

Verify Status

Finally, let's manually confirm that the system is back to normal and Panic Mode is definitely disabled.

Check the panic status:

sudo firewall-cmd --query-panic

It should return no.

This "scripted toggle" technique is a life-saving skill for DevOps engineers. Whenever you modify network settings that might disconnect you, always schedule a revert command or use a wrapper script like this!

The larger lesson is operational safety: risky firewall changes should have a recovery path planned in advance, not improvised after access is lost.

Summary

In this lab, you learned how to use Panic Mode safely in a remote environment. You:

1. Created a "Dead Man's Switch" script to toggle Panic Mode on and off automatically.
2. Used nohup to ensure the script survived the network disconnection.
3. Analyzed logs to verify that network isolation actually occurred.

This approach demonstrates how to manage dangerous security settings without locking yourself out of your server.