パニックモード

はじめに

ときには、問題が起こります。それも非常に深刻な問題です。サーバーがハッカーの攻撃を受けている、またはウイルスが急速に拡散している状況を想定してください。その場合は、コンピューターを直ちにネットワークから切断する必要があります。

firewalld には、パニックモード（panic mode）という機能があります。パニックモードを有効にすると、ファイアウォールはすべての受信接続と送信接続を直ちに破棄します。

そのため、パニックモードは通常の設定調整ではなく、インシデント対応で使用します。通信を直ちに停止することが接続性の維持より重要な場合に、迅速な封じ込めを行うための機能です。

これは緊急時の封じ込め機能です。通常の管理作業で使用するものではありませんが、インシデント発生時にファイアウォールポリシーを迅速なネットワーク分離ツールとしても利用できることを理解するうえで役立ちます。

リモートサーバーでの問題：

物理サーバーの前に座って作業している場合は問題ありません。しかし、この LabEx VM やクラウドサーバーのようなリモート環境では、パニックモードを有効にすると、自分の接続も直ちに切断されます。アクセスできなくなり、パニックモードを無効に戻せなくなります。

この実験では、「Dead Man's Switch」スクリプトを作成して、この機能を安全にシミュレーションおよびテストする方法を学びます。このスクリプトはパニックモードを有効にしてテストを実行した後、自動的にパニックモードを無効にするため、再びアクセスできるようになります。

安全なテストスクリプトを作成する

firewall-cmd --panic-on を直接実行するとセッションを失う可能性があるため、処理を自動化するスクリプトを作成します。

これは、より広く使われる運用上の手法でもあります。ネットワーク変更によって自分が締め出される可能性がある場合は、危険な変更を行う前にロールバックを自動化します。これにより、テストが障害に発展するリスクを減らせます。

このスクリプトでは、次の処理を行います。

「Before」の ping 結果を記録します（成功するはずです）。
パニックモードを有効にします。
「During」の 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）を使用します。nohup を使うと、ターミナルセッションが終了しても、スクリプトをバックグラウンドで実行し続けることができます。

これは、プロセスの存続期間とターミナルの存続期間を分離するよい例です。対話型セッションを維持できなくなっても復旧用スクリプトが動き続けることが、この実験の安全性を支えます。

sudo と nohup を使ってスクリプトを実行します。

sudo nohup ./safe_panic_test.sh &

予想される動作：

パニックモードが有効になると、ターミナルが約 5～10 秒間停止したり、応答しなくなったりすることがあります。ページを更新しないでください。
スクリプトのフェーズ 3（パニックモードの無効化）が完了すると、接続は自動的に復旧するはずです。

少なくとも 15 秒待ちます。

結果を分析する

接続が復旧したら、ログファイルを確認して、パニックモードが実際に機能したことを検証します。

パニックモードは意図的に通信を妨害するため、ここでの検証は特に重要です。テスト中にネットワーク分離が発生し、その後通常の接続が復元されたことを示す証拠を確認します。

ログファイルを読み取ります。

cat panic_test.log

次のような順序で表示されます。

PHASE 1：Ping が成功します。
PHASE 2：パニックモードが ON になります。このフェーズの ping は、Network is unreachable や 100% packet loss などのエラーを示すはずです。
PHASE 3：パニックモードが OFF になります。Ping が再び成功します。

これにより、数秒間、サーバーがネットワークから完全に分離されていたことを確認できます。

ステータスを確認する

最後に、システムが通常の状態に戻り、パニックモードが確実に無効になっていることを手動で確認します。

パニックモードのステータスを確認します。

sudo firewall-cmd --query-panic

no と表示されるはずです。

この「スクリプトによる切り替え」手法は、DevOps エンジニアにとって非常に重要なスキルです。自分の接続を切断する可能性があるネットワーク設定を変更するときは、必ず復元コマンドをあらかじめスケジュールするか、このようなラッパースクリプトを使用してください。

より大きな教訓は、運用上の安全性です。危険なファイアウォール変更を行う前に、アクセスを失ってからその場で対処するのではなく、あらかじめ復旧手段を計画しておく必要があります。

まとめ

この実験では、リモート環境でパニックモードを安全に使用する方法を学びました。次の操作を行いました。

パニックモードを自動的に ON／OFF へ切り替える 「Dead Man's Switch」スクリプトを作成しました。
nohup を使用して、ネットワーク接続が切断されてもスクリプトが実行を続けられるようにしました。
ログを分析して、ネットワーク分離が実際に発生したことを確認しました。

この方法により、サーバーから締め出されることなく、危険性の高いセキュリティ設定を管理できます。