Linuxのファイアウォールは、まず使用中の管理ツールを特定し、Ubuntu系のufwならufw status verbose、RHEL系のfirewalldならfirewall-cmd --stateと--get-active-zonesで状態を確認します。有効化する前にSSHなど現在の管理経路を許可し、別セッションで再接続できることを確かめてください。トラブル解決のためにファイアウォール全体を無効化するのではなく、必要なサービスまたは特定送信元のルールだけを追加・削除します。
Linuxカーネルのパケットフィルタリング基盤はnetfilterで、ufwやfirewalldはその管理を簡単にする上位ツールです。nftablesやiptablesを直接操作する構成もあります。同じホストで複数の管理ツールを無計画に混ぜると、表示上は許可されていても別ルールで拒否される、reloadで手動ルールが消えるなど予測しにくい状態になります。運用上の正とするツールを一つ決めます。
最初に管理方式を特定する
| 環境・ツール | 状態確認 | 設定の単位 |
|---|---|---|
| Ubuntuのufw | sudo ufw status verbose | 番号付きルール、アプリ、送信元、ポート |
| RHEL系のfirewalld | firewall-cmd –state / –get-active-zones | zone、service、port、rich rule |
| nftables直接管理 | sudo nft list ruleset | table、chain、rule |
| クラウドFW | クラウド管理画面・IaC | セキュリティグループ、ネットワークACL |
| コンテナ基盤 | Docker/Kubernetes/CNI設定 | 公開ポート、Service、NetworkPolicy |
cat /etc/os-release
systemctl is-active ufw 2>/dev/null || true
systemctl is-active firewalld 2>/dev/null || true
sudo nft list ruleset最後のnft list rulesetは表示だけですが、ルールには内部ネットワーク、公開サービス、管理IPなど機密情報が含まれ得ます。外部へ貼る前にマスキングします。ルールセットが表示されても、ufwやfirewalldが生成したものなら直接編集せず、上位ツールから変更します。構成管理やクラウドinitが定期的に再適用する環境では、その定義を修正しないと手動変更が戻ります。
遠隔作業の事前チェック
- クラウドのシリアルコンソール、仮想コンソール、物理アクセスなど代替管理経路を確保する。
- 現在のSSH接続元IP、接続先ポート、利用インターフェース、firewalld zoneを確認する。
- 既存ルールと既定ポリシーを保存し、切り戻し担当と時間を決める。
- 許可ルールを追加してから有効化し、現在の接続を閉じず別セッションで再接続を試す。
- ホスト側だけでなくクラウドFW、ルーター、VPN、踏み台の経路を確認する。
SSHの接続元が動的IP、VPN、踏み台経由の場合、見えているクライアントIPとサーバーが受け取る送信元IPが違うことがあります。ログと既存接続から実際の送信元を確認し、広い0.0.0.0/0許可へ逃げません。管理ポートをインターネット全体へ公開せず、VPN、踏み台、多要素認証、鍵認証と組み合わせます。
Ubuntuでufwを有効化する
Ubuntu Serverの公式資料では、ufwは既定で無効であり、sudo ufw enableで有効化できます。ただし遠隔サーバーでは、その前にSSHルールを追加します。次の例の192.0.2.10は文書用アドレスです。実際の管理端末または管理ネットワークへ置き換え、--dry-runで生成内容を確認します。
sudo ufw status verbose
sudo ufw --dry-run allow proto tcp from 192.0.2.10 to any port 22
sudo ufw allow proto tcp from 192.0.2.10 to any port 22
sudo ufw enable
sudo ufw status numbered環境によってSSHポートが22以外なら実際の待受を指定します。ufwを有効にした直後は現在のSSH接続を閉じず、別の端末から新規接続を確認します。失敗した場合に備えてコンソールを開いたままにします。『SSH』というアプリプロファイルを使う場合はufw app infoで内部のポートとプロトコルを確認し、名前だけで信用しません。
必要なサービスを許可する
Webサーバーを公開するなら、サービスが実際に待ち受けていることをローカルで確認してから、必要な送信元とポートだけを許可します。社内管理画面を全世界へ開かず、社内ネットワークやリバースプロキシの送信元へ限定します。IPv4とIPv6の両方が有効なホストでは、両方のルールと外部到達性を確認します。
sudo ufw --dry-run allow proto tcp from 198.51.100.0/24 to any port 443
sudo ufw allow proto tcp from 198.51.100.0/24 to any port 443
sudo ufw status numbered許可ルールを取り消す
サービスを止めるときはファイアウォール全体を無効にせず、不要になった許可ルールを削除します。番号は変更のたびに振り直されるため、削除直前にstatus numberedを再表示し、対象を確認します。まずアプリケーションの利用者へ告知し、接続中セッションとロードバランサーのヘルスチェックを確認します。
sudo ufw status numbered
# 表示された対象番号を確認してから実行
sudo ufw delete 3
sudo ufw status verboseufw自体を停止するdisable操作は、全ルールによる保護を外すため本記事では通常の障害切り分けとして推奨しません。明示的なインシデント対応手順で必要と判断された場合だけ、ローカルコンソール、作業時間、通信隔離、直後の再有効化、変更記録を揃え、Ubuntu公式資料と組織手順に従います。
RHEL系でfirewalldを有効化する
RHEL 9ではfirewalldが通常のファイアウォールサービスとして提供され、公式資料はsystemctl enable --now firewalldで起動と自動起動を行う手順を示しています。ただし既にnftablesサービスや別管理ツールが本番ルールを所有しているホストへ、確認なくfirewalldを起動してはいけません。現行ルール、構成管理、ディストリビューションの標準を確認します。
sudo systemctl status firewalld --no-pager
sudo systemctl enable --now firewalld
sudo firewall-cmd --state
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-allzoneを確認してサービスを追加する
firewalldのルールはzoneに属します。publicが既定だと決めつけず、対象インターフェースがどのzoneへ結び付いているかを--get-active-zonesで確認します。最初はruntimeへ追加して別セッションから動作を確認し、正しければ同じzoneのpermanent設定へ追加します。runtimeとpermanentの差分がないかを最後に照合します。
sudo firewall-cmd --get-active-zones
# 例: publicゾーンへHTTPSを一時追加
sudo firewall-cmd --zone=public --add-service=https
sudo firewall-cmd --zone=public --list-all
# 動作確認後に永続化
sudo firewall-cmd --zone=public --add-service=https --permanent
sudo firewall-cmd --zone=public --list-all --permanent事前定義serviceは、単一ポート名よりアプリケーションに必要なプロトコル群を表せるため管理しやすい方法です。ただしservice定義が期待どおりかを確認します。独自ポートを開く場合は--add-port=番号/プロトコルを使えますが、用途、所有者、期限を記録し、不要になったら削除します。
firewalldの許可を取り消す
公開を止める場合、対象zoneのruntimeとpermanentからサービスを削除し、一覧を確認します。まずruntimeだけを削除して接続影響を確認し、その後permanentも削除する段階的な方法が使えます。reloadはpermanent設定をruntimeへ反映するため、別の未保存runtime変更が消えないか確認してから行います。
sudo firewall-cmd --zone=public --remove-service=https
sudo firewall-cmd --zone=public --remove-service=https --permanent
sudo firewall-cmd --zone=public --list-all
sudo firewall-cmd --zone=public --list-all --permanentfirewalldサービス全体の停止・無効化は、すべてのzone保護を外し得るため通常のポート切り分けには使いません。firewalld公式ページにも別のiptables系サービスへ切り替える手順がありますが、これは管理方式の移行です。二つを同時運用せず、全ルール変換、起動順、再起動試験、切り戻しを設計したメンテナンスとして行います。
nftablesを直接管理する場合
nftablesではtable、chain、ruleの評価順とhook、priority、policyを理解して変更します。nft flush rulesetは全ルールを消す破壊的操作なので、障害切り分けや『初期化』として実行しません。既存ルールセットをバックアップし、構成ファイルの所有元を確認し、テスト用namespaceまたはコンソール付き環境で構文と到達性を検証します。
sudo nft list ruleset
sudo nft --check --file /etc/nftables.conf--checkは構文と一部の意味を検証しますが、適用後の管理接続維持やアプリケーション通信までは保証しません。ルールハンドルで特定ルールを変更する場合、再読込でハンドルが変わることがあります。手作業の一時修正を恒久設定と構成管理へ反映し、再起動後も同じ状態になることを確認します。
ポートが開かないときの切り分け
| 症状 | 確認 | 次の行動 |
|---|---|---|
| connection refused | アプリの待受、IP、ポート | ssでLISTENを確認しサービス側を修正 |
| timeout | ホストFW、クラウドFW、経路 | 各層の送信元・宛先・プロトコルを照合 |
| ローカルだけ成功 | 外部インターフェース待受、上流FW | 0.0.0.0等へ安易に変えず公開設計を確認 |
| IPv4は成功、IPv6は失敗 | IPv6待受と別ルール | AAAA、経路、ip6ルールを確認 |
| 再起動で戻る | runtime/permanent、構成管理 | 正しい永続定義を修正 |
| 許可しても拒否 | zone、別ツール、ルール順、SELinux | 正の管理ツールと監査ログを確認 |
アプリケーションが待ち受けているか
ファイアウォールは、起動していないサービスを起動しません。ss -ltnpでプロセス、ローカルアドレス、ポートを確認します。127.0.0.1だけで待ち受けるサービスは外部から到達できませんが、外部公開へ変更する前に認証、TLS、想定クライアント、リバースプロキシ構成を確認します。
SELinuxとファイアウォールを区別する
RHEL系でサービスが特定ポートを使えない、ファイルへアクセスできない場合、SELinux拒否が原因のことがあります。ファイアウォール許可を増やしても直りません。監査ログ、プロセスドメイン、ポートラベル、ファイルコンテキストを確認し、SELinuxを無効化せず正しい許可へ修正します。
クラウドとコンテナの層
AWS、Azure、Google Cloudなどでは、ホストFWに加えてセキュリティグループやネットワークACLがあります。Dockerのポート公開やKubernetes Serviceはホストのルールへ影響し、NetworkPolicyはPod間通信を制御します。一つの層だけを見て『ファイアウォールは問題ない』と判断せず、送信元からプロセスまでの各境界を図にして確認します。
変更とロールバック
- 変更前の状態、ルール一覧、active zone、待受、接続元を記録する。
- 必要なサービスと送信元を一つだけ追加し、現在の管理接続を保持する。
- 別セッションとアプリケーションのヘルスチェックで確認する。
- 成功後に永続設定へ反映し、runtimeとの一致を確認する。
- 問題があれば追加した一つのルールだけを削除し、一覧と接続を再確認する。
- 作業後に不要な一時許可、広いCIDR、期限切れルールをレビューする。
誤って管理接続を失った場合、同じネットワークから再試行を繰り返すより、確保したコンソールから直前の変更だけを戻します。パニックで全ルールをflushすると公開範囲が広がり、元構成も失います。構成管理が正なら承認済みの前版を再適用し、ホスト、クラウド、ロードバランサーの変更履歴を照合します。
監視と定期レビュー
許可ルールにはサービス所有者、目的、送信元、申請番号、期限を紐付けます。ログを常時大量出力するとディスクやCPUを圧迫するため、必要な拒否・異常だけをレート制限付きで記録し、中央監視へ送ります。繰り返すスキャン、想定外の国・ネットワーク、管理ポートへの失敗、ルール変更をアラートにします。
四半期やサービス廃止時に、実際の待受とファイアウォール許可を突き合わせます。サービスが停止していても広い許可が残れば、将来別プロセスが同じポートを使ったとき露出します。不要ルールを削除し、IPv4とIPv6、runtimeとpermanent、ホストとクラウドの差分を解消します。
エスカレーションの目安
遠隔管理を失った、ルールセットをflushした疑いがある、複数ツールが同じルールを管理している、公開範囲が不明な管理ポートを発見した、DDoSや侵入の兆候がある、コンテナ再起動でルールが変わる場合は、追加の試行を止めてネットワーク・セキュリティ担当へ連絡します。変更時刻、実行コマンド、ルール一覧、接続元、待受、クラウドFW、ログを保全します。
元記事の再利用ショートコード
以下の再利用ショートコードは、広告・共通部品を含む元記事の収益化構造を保つため、IDと記法を変えず元の順序で引き継いでいます。
よくある質問
ufwとfirewalldは同時に使えますか？
複数管理ツールを無計画に併用すると予測しにくくなります。ディストリビューションと組織が正とする一つを選び、移行は全ルールと再起動を検証します。
ポート確認のためファイアウォール全体を止めてもよいですか？
推奨しません。アプリの待受、対象zone、特定送信元の一時ルール、ログで切り分けます。全体停止は明示的な隔離・復旧計画がある承認済み作業に限定します。
ufw enableでSSHが切れませんか？
事前に実際の接続元とSSHポートを許可し、現在の接続を保持し、コンソールを確保したうえで別セッションから確認します。
firewalldの変更が再起動で消えました。
runtimeだけに追加した可能性があります。動作確認後、同じzoneのpermanent設定へ追加し、両方の一覧を比較します。
許可したのにconnection refusedです。
拒否はアプリが待ち受けていない、または別IP/ポートで待っている可能性があります。ssとsystemd状態を確認します。
nft flush rulesetで初期化してよいですか？
全ルールを消す破壊的操作なので行いません。管理元とバックアップを確認し、対象ルールだけを変更します。
公式情報源
まとめ
Linuxのファイアウォールは、ufw、firewalld、nftablesのどれが正の管理ツールかを確認し、SSHなど管理経路を先に許可してから有効化します。公開・停止はファイアウォール全体ではなく、zone、service、送信元、番号付きルールの単位で行い、別セッションで試してから永続化してください。接続不能はアプリの待受、ホストFW、クラウドFW、経路、SELinuxを層ごとに確認し、flushや全体無効化を近道にしないことが安全な運用の基本です。
コメント