紧急模式 | LabEx

简介

有时，事情会出错，而且可能非常严重。比如，你发现黑客正在攻击服务器，或者病毒正在快速传播。此时，你需要立即断开计算机与网络的连接。

firewalld 提供了一个名为紧急模式的功能。启用后，防火墙会立即丢弃所有传入和传出的连接。

因此，紧急模式属于事件响应功能，而不是日常调优功能。它的设计目标是在需要快速遏制事件时，优先立即阻止通信，而不是保留网络连接。

这是一个用于紧急遏制的功能，不适合日常管理。但了解它很有用，因为它展示了在安全事件期间，防火墙策略也可以作为快速隔离工具使用。

远程服务器面临的问题：

如果你坐在物理服务器前操作，这样做没有问题。但在远程环境中（例如本实验使用的 LabEx 虚拟机或云服务器），启用紧急模式会立即切断你自己的连接。你将被锁在服务器外，无法再次关闭紧急模式！

在本实验中，你将通过创建一个「死手开关」脚本，安全地模拟和测试此功能。该脚本会启用紧急模式，执行测试，然后自动将其关闭，确保你能够重新访问服务器。

创建安全测试脚本

由于直接运行 firewall-cmd --panic-on 会导致当前会话断开，我们需要编写一个脚本来自动完成整个过程。

这也是一种更广泛的运维技巧：如果网络更改可能导致你失去访问权限，就应在执行高风险更改之前自动安排回滚。这样可以降低测试演变成服务中断的风险。

该脚本将执行以下操作：

记录「启用前」的 ping 结果（应成功）。
启用紧急模式。
记录「启用期间」的 ping 结果（应失败）。
禁用紧急模式（恢复访问）。

创建名为 safe_panic_test.sh 的文件：

nano safe_panic_test.sh

将以下内容粘贴到文件中：

#!/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

保存并退出（Ctrl+O、Enter、Ctrl+X）。

为脚本添加可执行权限：

chmod +x safe_panic_test.sh

安全运行测试

现在进入关键步骤。如果直接运行该脚本，紧急模式启用的瞬间，你的会话可能会断开，从而导致脚本在关闭紧急模式之前被终止。

为避免这种情况，我们使用 nohup（No Hang Up，不挂断）。即使终端会话断开，它也能让脚本继续在后台运行。

这很好地说明了如何将进程生命周期与终端生命周期分离。即使交互式会话无法继续，恢复脚本仍然必须存活，这样实验才安全。

使用 sudo 和 nohup 运行脚本：

sudo nohup ./safe_panic_test.sh &

预期现象：

终端可能会冻结或暂时无响应约 5–10 秒。不要刷新页面。
脚本完成第 3 阶段（禁用紧急模式）后，连接应自动恢复。

至少等待 15 秒。

分析结果

现在连接已经恢复，检查日志文件，确认紧急模式确实生效。

这里的验证尤其重要，因为紧急模式会有意中断网络连接。你需要确认测试期间确实发生了网络隔离，并且之后恢复了正常连接。

读取日志文件：

cat panic_test.log

你应该看到类似下面的顺序：

PHASE 1：Ping 成功。
PHASE 2：紧急模式已启用。此处的 ping 尝试应显示类似 Network is unreachable 或 100% packet loss 的错误。
PHASE 3：紧急模式已禁用。Ping 再次成功。

这表明，在那几秒钟内，服务器已与网络完全隔离。

验证状态

最后，手动确认系统已恢复正常，并确认紧急模式确实已禁用。

检查紧急模式状态：

sudo firewall-cmd --query-panic

命令应返回 no。

这种「脚本化切换」技术是 DevOps 工程师应掌握的重要技能。每当你修改可能导致连接断开的网络设置时，都应提前安排恢复命令，或使用类似本实验的包装脚本。

更重要的经验是运维安全：对于高风险的防火墙更改，应提前规划恢复路径，而不是在失去访问权限后再临时处理。

总结

在本实验中，你学习了如何在远程环境中安全使用紧急模式。你完成了以下任务：

创建了一个「死手开关」脚本，自动启用和禁用紧急模式。
使用 nohup，确保脚本能够在网络断开后继续运行。
分析日志，确认确实发生了网络隔离。

这种方法展示了如何管理高风险的安全设置，同时避免将自己锁在服务器之外。