Linuxのファイアウォール設定で自分のサーバーにログインできなくなった日の話｜SE時代の修羅場と現役講師が今も守る「戻り口」の鉄則

ＨＯＭＥ ＞ リナックスマスター.JP 公式ブログ ＞ Linux学習ガイド ＞ Linuxのファイアウォール設定で自分のサーバーにログインできなくなった日の話｜SE時代の修羅場と現役講師が今も守る「戻り口」の鉄則
宮崎智広 この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
「ファイアウォールの設定を変更したら、本番サーバーにSSHで繋がらなくなってしまいました……どうすれば良いですか？」
セミナーで、この相談を受けることが少なくありません。画面の前で途方に暮れる気持ち——私にも覚えがあります。SE時代に実際にやらかしたことがあるので。

この記事では、20年以上Linuxサーバーを運用してきた経験から、ファイアウォール設定がなぜ「現場の難所」なのかを、自分が本番サーバーを締め出してしまった体験をもとに解説します。そして、今も現場で徹底している「戻り口の確保」という鉄則と、firewalldを使った安全な変更手順をお伝えします。

この記事のポイント

・ファイアウォール設定は「失敗すると遠隔アクセス手段が失われる」唯一の設定変更
・SE時代に実際にロックアウトを経験した現役講師が「戻り口の確保」を解説
・firewalldの「ランタイム変更 → 永続化」2段階方式でリスクを下げる
・トラブル時の復旧手順と確認コマンドを実例つきで紹介


Linuxのファイアウォール設定で自分のサーバーにログインできなくなった日の話

Linuxのファイアウォール設定で自分のサーバーにログインできなくなった日の話｜SE時代の修羅場と現役講師が今も守る「戻り口」の鉄則
「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

なぜファイアウォール設定だけが「現場の難所」と呼ばれるのか

Linuxの設定変更にはいろいろな種類があります。設定ファイルを書き換える、パーミッションを変える、サービスを再起動する——。どれも間違えれば問題が起きますが、ほとんどの変更には共通点があります。「ログインさえできれば元に戻せる」ということです。

たとえば設定ファイルの書き方を誤っても、そのファイルを再編集すれば済みます。パーミッションを間違えても、正しい値をchmodで再設定できます。サービスが起動しなくなっても、ログを確認して原因を潰していける。すべての対処は「リモートからサーバーに繋がっている」前提で成立します。

ところが、ファイアウォールの設定変更だけは話が違います。設定を間違えると、遠隔からサーバーに接続する手段そのものが失われるからです。

例えばSSHポート（22番）への通信を誤ってブロックしてしまった場合、リモートからは接続できません。正しい設定に戻そうにも、サーバーへのアクセス手段がすでに閉ざされているのです。これは論理パズルのような状況ですが、現場では実際に起きます。私自身がその体験者です。

また、ファイアウォール設定は「すぐに変更が反映される」という特性を持っています。設定ファイルへの変更はreloadやrestartで反映されますが、iptablesやfirewalldのランタイム変更は即座に適用されます。実行した瞬間に接続が切れることがある。これが経験者が口をそろえて「ファイアウォール設定は慎重に」と言う理由です。

あの夜、私は自分でサーバーを締め出した

1. iptablesの変更作業は「深夜の予定残業」から始まった

2002年ごろ、SIer時代に客先のLinuxサーバー（Red Hat Linux 7.3）の管理を担当していた頃の話です。セキュリティポリシーの見直しに伴い、iptablesの設定を強化するよう依頼されました。それまでは比較的緩い設定で運用されていたサーバーに、不要なポートをすべてDROPする設定を入れる作業です。

本番環境での変更なので、業務時間外のメンテナンス時間を確保して実施することになりました。確保したのは平日の深夜0時から2時。変更の内容はシェルスクリプトにまとめ、自分のPCの検証機で何度もテストして問題ないことを確認した——はずでした。

2. スクリプトを流した瞬間、新規接続が沈黙した

深夜0時過ぎ、メンテナンス時間に入ったタイミングでスクリプトを実行しました。iptablesにルールを流し込むコマンドが次々と実行されていきます。変更を流した後も、SSHのセッションはそのまま維持されていました。コマンドの応答も返ってきます。「成功した」と思いました。

念のため確認しようと、別のターミナルを開いて同じサーバーにSSH接続を試みました。繋がりません。

原因はすぐに分かりました。スクリプトの中でSSHポートを許可するACCEPTルールを書いていたのですが、ルールの適用順序を誤っていたのです。iptablesはルールを上から順番に評価します。私が書いたスクリプトでは、全ポートをDROPするルールがSSHを許可するACCEPTルールより前に処理されていました。結果として、SSH（22番）への新規接続がすべてDROPされていたのです。

既存のSSHセッションはコネクションが確立済みのため生きていましたが、新規接続は一切受け付けない状態です。そのセッションで設定を修正すれば良いとも思いましたが、作業中にネットワーク瞬断やタイムアウトが起きたら、二度と繋がれなくなります。その後まもなく、作業中のセッションも切れました。

3. 翌朝の電話と、客先データセンターへの緊急駆け込み

その日の早朝7時すぎ、客先の担当者から電話が入りました。「業務システムにアクセスできない人が続出している」という内容です。

私はすぐに状況を把握しました。前夜の変更で業務システムへの接続に必要なポートも遮断してしまっていたのです。iptablesの設定に自信を持っていただけに、そこまで確認が行き届いていなかった。

急いで客先のデータセンターへ向かいました。当時のサーバーはオンプレミスで物理設置されていたため、コンソール端末を直接繋いで操作するしかありません。現地でコンソールを接続し、iptablesのルールを一旦すべてフラッシュして元の状態に戻す作業をしました。復旧そのものは30分ほどで完了しましたが、その後の謝罪と原因説明で午前中が丸々潰れました。

上司にも客先にも頭を下げました。あのプレッシャーは今でも忘れられません。セミナーで受講生から「ファイアウォール設定が怖くて手が出せません」という声を聞くたびに、私は「その感覚は正しいです。私も実際に痛い目を見ました」とお伝えしています。

ファイアウォール設定でトラブルになった時の確認コマンド

ファイアウォール設定のトラブルに直面した時、まず現在の状態を正確に把握することが先決です。焦って不用意な変更を重ねると、状況がさらに複雑になります。

現在のRHEL系Linux（AlmaLinux、Rocky Linuxを含む）ではfirewalldが標準的なファイアウォール管理ツールです。旧環境ではiptablesが使われていました。それぞれの確認コマンドを押さえておきましょう。

firewalldの状態確認： 

# firewalldの動作状態を確認する
# systemctl status firewalld

# firewalldが有効かどうか確認する
# firewall-cmd --state

# 現在有効なゾーンの設定を全て表示する
# firewall-cmd --list-all

# 開放されているポートのみ確認する
# firewall-cmd --list-ports

# 許可されているサービス一覧を確認する
# firewall-cmd --list-services
iptablesでの確認（旧環境・Ubuntu系）： 

# 全チェーンのルール一覧を確認する（ルール番号付き）
# iptables -L -n -v --line-numbers

# INPUTチェーンのみを確認する
# iptables -L INPUT -n --line-numbers

# NATテーブルのルールも確認する（NAT環境の場合）
# iptables -t nat -L -n -v
ここで重要なのが、もしSSH接続が完全に失われた場合の復旧ルートです。接続できないのに設定を修正しようとすれば、当然手詰まりになります。事前に以下を確認しておくことが不可欠です。

・物理サーバー：コンソール端末を直接接続して操作できるか
・VPS（さくらインターネット、ConoHa等）：管理画面から「コンソール接続」が使えるか
・AWS EC2：Systems Manager Session Managerが有効になっているか
・GCP Compute Engine：Cloud Shellやシリアルコンソールが使えるか

これらの「コンソールからの緊急アクセス手段」が事前に使えることを確認しておく。これがファイアウォール設定変更の大前提です。
ファイアウォールトラブル時の復旧手順

現役講師が今も徹底している「戻り口の確保」という発想

あの失敗の後、私がファイアウォール変更前に必ず行うようになったことがあります。「タイムアウト方式」と私が呼んでいる手順です。

考え方はシンプルです。ファイアウォールの変更を適用する前に、「一定時間後に設定を元に戻す」仕掛けをあらかじめセットしておくのです。変更が成功すれば、その仕掛けをキャンセルします。失敗しても、タイマーが切れれば自動的に元の状態に戻ります。

2002年当時はatコマンドを使っていました。手順はこうです。

・ステップ1：変更前のiptables設定を保存する（iptables-save > /root/iptables.backup）
・ステップ2：「5分後に保存した設定を復元する」atジョブを仕掛ける
・ステップ3：iptablesの変更を実施する
・ステップ4：別のターミナルから接続テストを行う
・ステップ5：テスト成功ならatジョブをキャンセルする（atrmコマンド）
・テスト失敗：5分後に自動的に元の設定に戻る

このフローを使っていれば、あの夜の事故は防げました。

現在のfirewalldには、同様の考え方を実現する--timeoutオプションが用意されています。指定した秒数が経過すると変更が自動的に解除されます。これを使えばatコマンドなしで同じ安全網を張れます。

3,100名以上を指導してきた中で、「ファイアウォール設定のミスで復旧に数時間かかった」という経験を持つエンジニアは珍しくありません。ベテランほど「怖いから慎重」ではなく「仕組みで安全を担保する」という発想で動いています。これは習慣の差です。

もう一つ重要な習慣があります。変更後のテストは、変更したターミナルとは別のターミナルで行うことです。変更を流したSSHセッション自体は既存のコネクションが維持されるため、そのセッションから確認しても「繋がっている」ように見えます。これが私がはまった罠でした。必ず別の端末を開いて新規接続をテストしてください。

firewalldを使った安全な変更手順

現代のRHEL系環境で使うfirewalldには、安全な変更を実現する仕組みが整っています。その核心が「ランタイム設定と永続設定の分離」です。

・ランタイム設定：即座に反映されるが、firewalld再起動やOS再起動で消える
・永続設定（--permanentフラグ付き）：再起動後も残る設定。適用にはreloadが必要

この仕組みを活用した安全な変更フローが「ランタイムでテスト → 成功後に永続化」の2段階方式です。

実務での安全な変更手順： 

# ステップ1：変更前の現在の状態を記録しておく
# firewall-cmd --list-all

# ステップ2：ランタイムのみでポートを開放（--permanent なし）
# この変更はfirewalld再起動で自動的に消える
# firewall-cmd --add-port=8080/tcp

# ステップ3：別のターミナルから接続テストを実施する
# （テストが成功したら次のステップへ。失敗したらステップ2bへ）

# ステップ2b（テスト失敗時）：手動でランタイム変更を削除する
# firewall-cmd --remove-port=8080/tcp

# ステップ4（テスト成功時）：永続化する
# firewall-cmd --add-port=8080/tcp --permanent
# firewall-cmd --reload

# ステップ5：永続設定が正しく反映されているか確認する
# firewall-cmd --list-all --permanent
さらに安全性を高めたい場合は--timeoutオプションを使います。

タイムアウト付き変更（300秒=5分後に自動解除）： 

# --timeout=300 で300秒（5分）後に変更が自動解除される
# まずタイムアウト付きで変更を適用する
# firewall-cmd --add-port=8080/tcp --timeout=300

# 別ターミナルから接続テストを実施する
# 成功したら永続化する（タイムアウト前に実行すること）
# firewall-cmd --add-port=8080/tcp --permanent
# firewall-cmd --reload

# タイムアウト前に --permanent で永続化しておけば
# 5分後のランタイム解除は永続設定で上書きされるので問題ない
このフローの大きなメリットは、もし変更後に接続が切れても「5分待てば自動的に元に戻る」点です。あとは物理コンソールで確認する必要もなく、新規接続を試みれば元の状態に戻っているはずです。

最後にもう一点。ファイアウォール変更を行う前に確認しておくべき事項を整理します。

・現在の設定をfirewall-cmd --list-allで記録しているか
・作業用のSSH接続元IPが許可リストに含まれているか
・変更用のターミナルとは別に、接続テスト用のターミナルが開いているか
・コンソール経由の緊急アクセス手段が確保されているか

この4点を確認してから変更に入るのが、私が現場で実践している事故を防ぐ基本です。
安全なファイアウォール変更のまとめ

まとめ

ファイアウォール設定は、他のLinux設定変更とは根本的に異なる特性を持っています。「失敗すると遠隔アクセス手段が失われる」という事実を常に意識し、変更の前に安全網を張る習慣を持つことが何より重要です。

私がSE時代に経験したロックアウトは、スクリプトのテスト不足とルール順序の確認漏れが原因でした。しかし根本には「戻り口を確保せずに変更した」という習慣の問題がありました。

やること 具体的な手順・コマンド
変更前の状態確認 firewall-cmd --list-all で現在のルールを記録
戻り口の確保 コンソールアクセス手段を事前確認・atジョブで自動復旧を仕込む
ランタイムでのテスト firewall-cmd --add-port=XXXX/tcp（--permanentなし）で変更し、別ターミナルで接続確認
タイムアウト方式の活用 firewall-cmd --add-port=XXXX/tcp --timeout=300
テスト成功後に永続化 firewall-cmd --add-port=XXXX/tcp --permanent → firewall-cmd --reload
別ターミナルで確認 変更したセッションとは別の端末から新規接続をテストする
ファイアウォール設定を「怖いもの」と感じるのは正常な感覚です。重要なのは、怖さを理由に避けるのではなく、「仕組みで安全を担保する」習慣を身につけることです。その習慣こそが、現場で長く信頼されるLinuxエンジニアを作ります。

関連記事も参考にしてください。
・Linuxのポート確認方法｜ss・lsofコマンドの使い分けと実践例
・chkconfigとsystemctlの違いと使い方——サービス管理の基本を押さえる

ファイアウォールを含むLinuxサーバー設定を、「感覚」ではなく「型」で習得したい方へ

iptablesやfirewalldの設定を学ぼうとしても、「何がどう繋がっているのか分からない」という方は多いものです。
ネットの断片情報を組み合わせるだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。

今すぐ無料でダウンロード（登録10秒） ＞＞ 図解60P『Linux入門マニュアル』を受け取る

※ 「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

関連記事

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

Linux無料マニュアル（図解60P） 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広（みやざき ともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。