- はじめに
- firewalldを起動する前に考える2つの状況
- 新規構築サーバで安全にfirewalldを起動する考え方
- サービス提供済みサーバで安全にfirewalldを起動する考え方
- firewalld起動前に確認する設定
- firewalld起動後に確認する設定
- zone / target の基本
- RHEL 10.1で確認した実測結果
- 安全な初期設定手順
- よくある質問
- firewalldを起動するとSSHは必ず切れますか？
- 新規構築サーバならすぐfirewalldを起動してよいですか？
- サービス提供済みサーバではどう起動すべきですか？
- trusted zoneを使えば通信断対策になりますか？
- サービス提供済みサーバでtrusted zoneから起動するにはどうしますか？
- SSH接続中にfirewalldを起動して、SSHがブロックされていた場合、今つながっているSSHもすぐ切れますか？
- public zoneとは何ですか？
- portsとservicesの違いは何ですか？
- runtimeとpermanentの違いは何ですか？
- クラウド環境でコンソール接続できない場合はどうしますか？
- まとめ
はじめに
firewalldは、RHEL系Linuxサーバで通信を制御するための重要なサービスです。
ただし、firewalldを起動すると、zoneに設定された通信制御が有効になります。その結果、SSH接続やWeb、DB、監視などの既存通信が切れる可能性があります。
この記事は、firewalldを起動する前に次の不安を解消するための記事です。
- firewalldを起動して大丈夫か
- SSHが切れない根拠はどこで確認するのか
- 起動すると何がブロックされるのか
- サービス提供済みサーバではどう安全に始めるのか
- 新規構築サーバではどう必要な通信だけ開けるのか
- zone、target、active zone、DefaultZoneをどう理解すればよいか
RHEL 10.1で確認した実測結果も紹介しますが、この記事の主役は検証結果ではありません。
主役は、firewalld初期設定と起動前の注意事項です。
【注意】
本番環境やサービス提供中のサーバで、いきなり`systemctl start firewalld`を実行しないでください。
先にSSH、既存通信、復旧経路、DefaultZone、起動後に適用される可能性があるzoneを確認してください。
firewalldを起動する前に考える2つの状況
firewalldを起動する前に、まず対象サーバの状況を分けます。
| 状況 | 優先する考え方 |
| 新規構築サーバ | public zoneを前提に、必要な通信だけを許可する |
| サービス提供済みサーバ | 既存通信を止めず、firewalld管理下へ段階的に移行する |
新規構築サーバでは、public zoneを前提に、最初から必要な通信だけを許可する方針が基本です。
一方、サービス提供済みサーバでは、firewalld起動によって既存通信が止まる可能性があります。こちらは、起動前の確認と戻し手順がより重要です。
どちらの場合でも、SSH接続中に作業しているならSSH切断リスクがあります。
新規構築サーバで安全にfirewalldを起動する考え方
新規構築サーバでは、public zoneを前提に、最初から必要な通信だけを許可する方針が基本です。
ただし、SSHで作業している場合は、firewalldを起動してもSSHがつながる根拠を確認してから進めます。
確認することは次のとおりです。
- sshdが待ち受けているか
- SSH接続元IPは何か
- DefaultZoneは何か
- 起動後に適用される可能性があるzoneは何か
- public zoneに`ssh` serviceが含まれるか
- firewalld起動後に`firewall-cmd --list-all`で何が許可されているか
- `firewall-cmd --query-service=ssh`でSSHが許可されているか
新規構築サーバでは、SSH、HTTP、HTTPSなど、実際に必要な通信だけを許可します。
ブロックされていた通信は、本当に必要か確認してから開放します。不要な通信は開けません。
【補足】
firewalld停止中は、`firewall-cmd`でzoneやserviceを確認しようとしても`FirewallD is not running`になる場合があります。
停止中に確認できる情報と、起動後に確認する情報を分けて考えてください。
サービス提供済みサーバで安全にfirewalldを起動する考え方
サービス提供済みサーバでは、既存通信を止めないことが最優先です。
firewalld停止中は、firewalldによる受信制御が効いていない状態です。 既存サービスが動いているサーバで、いきなりpublic zone前提でfirewalldを起動すると、許可漏れにより既存サービス通信が遮断される可能性があります。
起動前に全通信を完全に洗い出せれば理想ですが、サービス提供済みサーバでは、監視、バックアップ、管理用通信、外部連携などが後から判明することもあります。
起動前に、少なくとも次を洗い出します。
- SSH接続元
- sshdの待受状態
- Web、DB、監視、バックアップなどの待受ポート
- 接続元IPや接続元セグメント
- サービス利用者や監視サーバ
- firewalld起動後に適用される可能性があるzone
- 必要なservices、ports、rich rules
既存通信断を避ける必要がある場合は、trusted zone相当で暫定的に起動し、firewalld管理下へ移行する考え方があります。
trusted zoneは全許可に近いため、firewalld停止中に近い通信状態を維持しやすい一方で、防御としては弱い状態です。 そのため、trusted zoneを「安全な設定」とは考えません。 あくまでサービス提供済みサーバで通信断リスクを下げるための暫定方式、またはfirewalld管理下へ移行するための開始点として扱います。
サービス提供済み環境では、既存通信を止めないために「まず通すべき通信を広めに把握し、段階的に絞る」考え方があります。
これは、緊急の通信断を避ける考え方としては理解しやすいです。
しかし、全開放に近い状態を恒久運用にするのは危険です。必ず見直し計画を入れ、最終的には必要な通信だけに絞ってください。
【注意】
trusted zoneは全許可に近い扱いになります。
サービス提供済みサーバで既存通信を止めないための暫定方式として使う考え方はありますが、trusted zoneは安全策ではありません。
trusted zoneのまま放置せず、起動後にactive zone、services、ports、rich rules、interfaces、sourcesを確認し、段階的にpublicなど必要な通信だけを許可する構成へ移行してください。
サービス提供済み環境では、メンテナンス時間、戻し手順、コンソールまたはクラウド復旧経路を確保してから作業してください。
サービス提供済みサーバでtrusted zone相当から起動する考え方
サービス提供済みサーバでは、どのzoneでfirewalldを起動するかを先に考えます。
新規構築サーバなら、public zoneを前提に、SSH、HTTP、HTTPSなど必要な通信だけを許可する方針が基本です。
一方、すでにサービス提供しているサーバでは、firewalld停止中に近い通信状態を保ちながらfirewalld管理下へ移行したい場合があります。 この場合、trusted zoneを暫定的な開始点にする考え方があります。
trusted zoneは、サービス提供済みサーバで既存通信断を避けてfirewalld管理下へ移行するための暫定的な開始点です。 trusted zoneは全許可に近いため、恒久運用には向きません。 起動後に状態を確認し、段階的に必要な通信だけを許可する構成へ移行します。
どのzoneで起動するかを決める
| サーバの状態 | 起動時の考え方 | 注意点 |
| 新規構築サーバ | public zoneを前提にする | 必要な通信だけを許可する |
| サービス提供済みサーバ | trusted zone相当を暫定起動候補にする | 既存通信断を避けるための一時的な開始点として扱う |
trusted zoneは防御が弱い状態です。 通信断リスクを下げる暫定方式ではありますが、安全な恒久設定とは考えないでください。
firewalld停止中に確認すること
firewalld停止中に確認する項目は次のとおりです。
| 確認項目 | コマンド例 | 見る理由 |
| firewalld状態 | `systemctl is-active firewalld` | 起動中か停止中か確認する |
| DefaultZone | `grep '^DefaultZone=' /etc/firewalld/firewalld.conf` | 明示的なzoneがない場合に使われる可能性があるzoneを確認する |
| NetworkManager接続一覧 | `nmcli connection show` | 対象の接続名を確認する |
| NetworkManager側のzone指定 | `nmcli connection show <接続名>` | connection.zoneが明示されているか確認する |
| 待受ポート | `ss -ltnp` | 現在提供中の通信を洗い出す |
| SSH接続元 | `echo "$SSH_CLIENT"` | 今どこからSSH接続しているか確認する |
RHEL 10.1検証環境では、`nmcli connection show enp0s3 | grep connection.zone` の結果として `connection.zone: --` が確認されました。 この結果は、今回の環境でNetworkManagerのconnectionに明示的なzoneが設定されていない状態として確認された、という扱いにします。 すべての環境で同じとは断定しません。
出力を絞り込みたい場合は、次のように確認します。
nmcli connection show <接続名> | grep connection.zoneなお、今回のRHEL 10.1 / NetworkManager 1.54環境では、`GENERAL.ZONE`をフィールド指定する確認方法は無効フィールドになりました。 そのため、この記事では`GENERAL.ZONE`を確認コマンドとして採用しません。
public以外で起動したい場合の設定観点
firewalld起動時にどのzoneが使われるかは、DefaultZoneだけでなく、interfaceやNetworkManagerの`connection.zone`設定にも影響される可能性があります。
interfaceやconnectionに明示的なzoneが設定されていない場合、DefaultZoneが使われる可能性があります。 そのため、trustedで暫定起動したい場合は、DefaultZoneをtrustedにする方法が考えられます。
ただし、NetworkManager側で`connection.zone`が指定されている場合、DefaultZoneだけを変更しても意図したzoneにならない可能性があります。
起動後は必ず、次のコマンドで実際に適用されたzoneを確認してください。
firewall-cmd --get-active-zones
firewall-cmd --list-allRHEL 10.1で確認したtrusted暫定起動の設定例
今回のRHEL 10.1環境では、firewalld停止中に`firewall-offline-cmd --set-default-zone=trusted`を実行し、DefaultZoneをtrustedへ変更できることを確認しました。
検証環境:
| 項目 | 確認結果 |
| Kernel | `6.12.0-124.8.1.el10_1.x86_64` |
| firewalld | `firewalld-2.3.1-1.el10_0.noarch` |
| firewall-cmd | `2.3.1` |
| NetworkManager | `1.54.0-1.el10` |
検証前の状態:
| 項目 | 確認結果 |
| firewalld状態 | `active` / `running` |
| 自動起動 | `disabled` |
| DefaultZone | `public` |
| connection.zone | `--` |
| 接続名 | `enp0s3` |
| SSH接続元 | `172.16.82.51 61774 22` |
| sshd待受 | `0.0.0.0:22` |
| IPアドレス | `enp0s3 UP 172.16.81.152/18` |
trustedで暫定起動する検証では、次の流れを確認しました。
systemctl stop firewalld
systemctl is-active firewalld
firewall-offline-cmd --set-default-zone=trusted
grep '^DefaultZone=' /etc/firewalld/firewalld.conf
systemctl start firewalld
firewall-cmd --state
firewall-cmd --get-default-zone
firewall-cmd --get-active-zones
firewall-cmd --zone=trusted --list-all確認結果の要点:
inactive
success
DefaultZone=trusted
running
trusted
trusted (default)
interfaces: enp0s3`firewall-cmd --zone=trusted --list-all`では、今回の環境で次のように表示されました。
trusted (default, active)
target: ACCEPT
interfaces: enp0s3
sources:
services:
ports:
rich rules:今回のRHEL 10.1環境では、NetworkManagerの`connection.zone`が`--`の状態で、`DefaultZone=trusted`へ変更したあと、firewalld起動後に`enp0s3`がtrusted zoneへ所属しました。
ただし、NetworkManager側で`connection.zone`が明示設定されている環境では、DefaultZoneだけを変更しても意図したzoneにならない可能性があります。 起動後は必ず`firewall-cmd --get-active-zones`で実際のactive zoneを確認してください。
【注意】
この手順は、サービス提供済みサーバで既存通信断を避けてfirewalld管理下へ移行するための暫定方式です。
trusted zoneは全許可に近く、今回のRHEL 10.1環境でもtargetが`ACCEPT`と表示されました。
services、ports、rich rulesが空でも、target ACCEPTのため広く許可される方向のzoneです。
trusted zoneのまま恒久運用せず、必要通信を整理してpublicなど必要な通信だけを許可するzoneへ移行してください。
起動後の確認
trusted zone相当で暫定起動した場合でも、起動後に必ず確認します。
firewall-cmd --get-active-zones
firewall-cmd --get-default-zone
firewall-cmd --list-all
firewall-cmd --zone=trusted --list-all
firewall-cmd --list-all-zones確認する観点は次のとおりです。
- active zoneがtrustedになっているか
- interfacesに対象NICが表示されているか
- servicesに何が表示されているか
- portsに直接開放されたポートがあるか
- rich rulesに条件付きルールがあるか
- sourcesが設定されているか
- trustedのまま恒久運用になっていないか
publicへ戻す方法
今回のRHEL 10.1検証環境では、次の流れでDefaultZoneをpublicへ戻せることも確認しました。
systemctl stop firewalld
firewall-offline-cmd --set-default-zone=public
grep '^DefaultZone=' /etc/firewalld/firewalld.conf
systemctl start firewalld
firewall-cmd --get-default-zone
firewall-cmd --get-active-zones
firewall-cmd --list-all確認結果の要点:
success
DefaultZone=public
public
public (default)
interfaces: enp0s3戻した後の`public` zoneでは、今回の環境で`services: cockpit dhcpv6-client ssh`が確認されました。
本番環境でtrustedからpublicへ戻す場合は、通信断リスクがあります。 メンテナンス時間、復旧経路、必要通信の許可設定を確認してから実施してください。
trustedから段階的に移行する
trustedで暫定起動したあとは、次の流れで段階的に移行します。
- trustedで既存通信を止めずにfirewalldを起動する
- firewalld管理下で現在の通信状態を確認する
- 待受ポートと接続元を整理する
- 必要なサービス・ポートだけを洗い出す
- publicなど制限されたzoneで許可すべき設定を準備する
- 検証環境またはメンテナンス時間で切り替えを確認する
- trustedから必要な通信だけを許可する構成へ移行する
- 最終的に不要な通信を閉じてセキュリティを強化する
trusted zoneは、サービス提供済みサーバで既存通信断を避けるための一時的な状態です。 最終形は、必要な通信だけを許可する構成です。
firewalld起動前に確認する設定
firewalld起動前に確認できるものと、起動後でないと確認しにくいものを分けます。
| 確認項目 | コマンド例 | 確認タイミング | 見る理由 | |
| sshdの待受確認 | `ss -ltnp | grep ':22'` | 起動前 | SSHサーバが待ち受けているか確認する |
| SSH接続元確認 | `echo "$SSH_CLIENT"` | 起動前 | どこから接続しているか確認する | |
| IPアドレス確認 | `ip -brief address` | 起動前 | 対象インターフェースとIPを把握する | |
| ルーティング確認 | `ip route` | 起動前 | デフォルトゲートウェイや経路を把握する | |
| DefaultZone確認 | `grep '^DefaultZone=' /etc/firewalld/firewalld.conf` | 起動前 | 標準zoneの設定を確認する | |
| firewalld状態確認 | `systemctl is-active firewalld` | 起動前 | 起動中か停止中か確認する | |
| 復旧経路確認 | コンソール、クラウド管理画面、スナップショット | 起動前 | SSH切断時に戻れるか確認する |
DefaultZoneは、明示的にzoneへ紐づいていない通信やinterfaceに適用される可能性がある基本zoneです。
旧記事では、`/etc/firewalld/firewalld.conf` の `DefaultZone=public` が重要な確認点でした。
RHEL 10.1主軸のこの記事でも、`DefaultZone=` は確認観点として有用です。
ただし、設定ファイルの直接編集は主手順にしません。
旧記事では、`/etc/firewalld/firewalld.conf` を開き、`DefaultZone=public` の行を確認していました。 firewalld起動前に「起動後にどのzoneが使われる可能性があるか」を考える材料になります。
ただし、`DefaultZone=public` が見えたとしても、それだけでSSHや既存通信が安全とは判断できません。 起動後にactive zoneと許可内容を確認するところまでを、必ずセットで考えてください。
この画像で見るべき箇所は、`DefaultZone=public` です。 public zoneが使われる可能性を意識するための確認点として扱います。 public zoneで何が許可されているかは、firewalld起動後に `firewall-cmd --list-all` で確認します。
確認例:
grep '^DefaultZone=' /etc/firewalld/firewalld.conf結果例:
DefaultZone=public【重要】
DefaultZoneだけを見て「安全」と判断しないでください。
実際にどのzoneが適用されているかは、firewalld起動後にactive zoneと`--list-all`で確認します。
firewalld起動後に確認する設定
firewalld起動後は、実際に適用されているzoneと許可内容を確認します。
| 確認項目 | コマンド例 | 見る理由 |
| active zone確認 | `firewall-cmd --get-active-zones` | 実際に使われているzoneを確認する |
| default zone確認 | `firewall-cmd --get-default-zone` | 標準zoneを確認する |
| 現在zoneの詳細確認 | `firewall-cmd --list-all` | services / ports / rich rulesを見る |
| 全zone確認 | `firewall-cmd --list-all-zones` | 全zone設定を確認する |
| 特定zone確認 | `firewall-cmd --zone=public --list-all` | publicなど特定zoneを確認する |
| SSH許可確認 | `firewall-cmd --query-service=ssh` | 現在のzoneでSSHが許可されているか確認する |
| 永続設定確認 | `firewall-cmd --permanent --list-all` | reloadや再起動後に残る設定を確認する |
`--list-all` は、現在のdefault / active zoneの確認に使いやすいです。
`--list-all-zones` は全zoneの設定確認に使えますが、出力が長くなります。
特定のzoneだけ確認したい場合は、次のようにzoneを指定します。
firewall-cmd --zone=public --list-all確認するときは、特に次を見ます。
- `services`
- `ports`
- `rich rules`
- `interfaces`
- `sources`
どの通信が許可されているかは、`services`、`ports`、`rich rules` のどこに設定されているかで見え方が変わります。
旧記事では、zoneごとの設定確認結果を画像で示していました。 firewalld起動後は、active zoneやzoneごとの許可内容を確認し、特に `services`、`ports`、`rich rules`、`interfaces`、`sources` を見ます。 SSHが許可されているかは、`services` に `ssh` があるか、または `firewall-cmd --query-service=ssh` で確認します。
この画像は、zoneごとの設定結果を見るための補足です。 `services` に何があるか、`ports` に直接開放されたポートがあるか、`rich rules` に条件付きルールがあるかを確認する流れをつかむために使います。 画像は確認箇所を理解するための例であり、読者の環境で同じ結果になるとは限りません。
【補足】
firewalld停止中に一部の`firewall-cmd`を実行すると、`FirewallD is not running`になる場合があります。
停止中に判断できることと、起動後に確認することを分けてください。
zone / target の基本
zoneは、firewalldが通信を分類する単位です。
通信元、interface、ネットワークの信頼度などに応じて、どのzoneのルールを適用するかを考えます。
| zone | 位置づけの目安 | 注意点 |
| public | 公開ネットワーク向けの一般的なzone | 必要な通信を許可していく考え方で使う |
| dmz | DMZ向け | 公開サービス用の分離領域で使われることがある |
| internal | 内部ネットワーク向け | 内部向けでも不要な通信は許可しない |
| work | 職場など比較的信頼できるネットワーク向け | 許可内容を確認して使う |
| home | 自宅など比較的信頼できるネットワーク向け | 許可内容を確認して使う |
| external | 外部ネットワーク向け | NATや転送設定と関係する場合がある |
| block | 基本的に受信を拒否する用途 | 拒否応答が返る場合がある |
| drop | 基本的に受信パケットを破棄する用途 | 応答が返らず、原因切り分けが難しくなる場合がある |
| trusted | 通信を広く信頼する用途 | 全許可に近いため慎重に扱う |
| nm-shared | NetworkManager共有接続で使われることがあるzone | 通常のサーバ運用では意図せず使わないよう確認する |
DefaultZoneとは
DefaultZoneは、明示的にzoneへ紐づいていない場合に使われる可能性がある標準zoneです。
ただし、DefaultZoneだけで実際の通信制御を判断しないでください。
起動後は、active zoneと`--list-all`で実際に使われているzoneを確認します。
active zoneとは
active zoneは、現在実際に使われているzoneです。
active zoneは、interfaceやsourceの設定によって表示されます。
たとえば、あるinterfaceが`public`に所属していれば、そのinterfaceに対する通信では`public` zoneのルールが重要になります。
また、sourceをzoneに紐づけると、そのsourceに対して該当zoneがactiveになる考え方があります。
ただし、この記事ではsource追加やinterface変更の変更系操作は主手順にしません。
【注意】
`firewall-cmd --zone=trusted --change-interface=...` や `firewall-cmd --add-source=... --zone=drop` のような変更操作は、通信断や意図しない許可・遮断につながる可能性があります。
RHEL 10.1主軸のこの記事では、概念説明にとどめます。
sourceをzoneに割り当てた場合の考え方
zoneは、通信に適用するルールの入れ物です。 public zoneにはpublic zoneのルールがあり、drop zoneにはdrop zoneのルールがあり、trusted zoneにはtrusted zoneのルールがあります。
ただし、すべてのzoneのルールが同時に適用されるわけではありません。 firewalldは、通信ごとにどのzoneを適用するかを決める、と考えると理解しやすいです。
interfaceがpublic zoneに所属していれば、通常の通信はpublic zoneで処理されます。 しかし、特定の送信元IPをdrop zoneへsource登録すると、そのIPからの通信はdrop zoneで処理されます。
この場合、public zoneの設定そのものが変わるわけではありません。 該当IPからの通信だけが、public zoneではなくdrop zoneに振り分けられる、という考え方です。
source指定は、interfaceやDefaultZoneより優先して適用されるものとして考えると理解しやすくなります。 trusted zoneで暫定起動している場合でも、特定IPをdrop zoneへsource登録すれば、そのIPからの通信はdrop zoneで処理される考え方になります。
public zoneで稼働している場合
たとえば、次の状態を考えます。
default zone = public
interface = public
192.168.11.19 = drop zoneにsource登録この場合の考え方は次のとおりです。
通常の通信 → public zoneで処理
192.168.11.19 → drop zoneで処理public zoneのservicesやportsが変更されるわけではありません。 `192.168.11.19`からの通信だけがdrop zoneで処理されます。
trusted zoneで暫定起動している場合
サービス提供済みサーバでtrusted zone相当から暫定起動している場合も、考え方は同じです。
default zone = trusted
interface = trusted
192.168.11.19 = drop zoneにsource登録この場合の考え方は次のとおりです。
通常の通信 → trusted zoneで処理
192.168.11.19 → drop zoneで処理trusted zoneで広く通信を許可している状態でも、特定IPをdrop zoneへsource登録すれば、そのIPからの通信はdrop zoneのルールで処理されます。
source登録コマンドは慎重に扱う
source登録の例としては、次のようなコマンドがあります。
firewall-cmd --add-source=192.168.11.19 --zone=dropこのコマンドは、指定した送信元IPからの通信をdrop zoneで処理させる例です。 本番環境で実行すると、対象IPからの通信が遮断される可能性があります。 設定前に接続元IP、復旧経路、影響範囲を確認してください。
`--permanent` を付けると永続設定になります。 ただし、reloadや再起動後の影響があるため、検証環境で確認してから実施してください。
この記事では、source登録をfirewalld初期設定の主手順としては扱いません。 zoneの適用順序を理解するための補足例として扱います。
targetとは
targetは、zoneに明示的なルールがない通信をどのように扱うかに関係する考え方です。
| target | 考え方 | 見え方 |
| default | zone既定の扱いに従う | zoneや設定により動作が変わる |
| ACCEPT | 対象通信を受け入れる方向の扱い | 許可範囲が広がりやすい |
| REJECT | 対象通信を拒否し、拒否応答を返す方向の扱い | 拒否されたことが分かる場合がある |
| DROP | 対象通信を破棄する方向の扱い | 応答が返らずタイムアウトに見える場合がある |
targetを考えるときは、「拒否から始めて必要な通信を許可する」のか、「許可から始めて不要な通信を拒否する」のかを分けると理解しやすくなります。
publicやdmzなどは、基本的に必要な通信を追加していく考え方で使います。
一方、trustedは全許可に近い扱いです。考え方としては「許可から始めて拒否したい通信を追加する」方向になります。
ただし、trusted zoneは安易に使わないでください。trusted zoneを「安全に起動するための逃げ道」として推奨しません。
DROP / REJECT / default と ping / ICMP の見え方
ping / ICMP の見え方は、障害切り分けでも重要です。
| target | ping / ICMP の見え方の例 | 注意点 |
| DROP | 応答が返らず、通信元からは反応がないように見える場合がある | タイムアウトに見え、原因切り分けに時間がかかることがある |
| REJECT | 拒否応答が返る場合がある | 拒否されていることを通信元が判断しやすい場合がある |
| default | zoneの既定動作に従う | 単純にREJECTと同一とは断定しない |
| ACCEPT | 許可される方向の扱い | trusted zoneでは許可範囲が広がりやすい |
ただし、ping / ICMP の応答は、zone、target、icmp-block、OS設定、ネットワーク経路によって変わります。
「応答なし」と「拒否応答あり」は、障害切り分けで見え方が違うと理解してください。
RHEL 10.1で確認した実測結果
ここからは、RHEL 10.1で実際に確認した結果です。
この記事では、RHEL 10.1検証結果を判断材料として扱います。記事の主役は、あくまでfirewalld初期設定と起動前注意です。
検証環境
| 項目 | RHEL 10.1 |
| OS | Red Hat Enterprise Linux release 10.1 |
| Kernel | `6.12.0-124.8.1.el10_1.x86_64` |
| firewalld | `firewalld-2.3.1-1.el10_0.noarch` |
| NetworkManager | `1.54.0-1.el10` |
firewalld起動前の状態
RHEL 10.1環境では、firewalldは停止中でした。
実行コマンド:
systemctl is-enabled firewalld
systemctl is-active firewalld
firewall-cmd --state確認結果:
disabled
inactive
not runningfirewalld停止中にzoneやserviceを確認しようとすると、次のように表示されました。
FirewallD is not running起動前に確認した安全確認
firewalld起動前に、次を確認しました。
who
echo "$SSH_CLIENT"
ss -ltnp | grep ':22'
ip -brief address
ip route確認できたこと:
- コンソールログインが存在する
- SSH接続が存在する
- SSH接続元を確認できた
- sshdが`0.0.0.0:22`で待ち受けている
- IPアドレスとデフォルトルートを確認できた
firewalld起動後の状態
RHEL 10.1検証環境では、コンソールログインと復旧手段を確認したうえでfirewalldを起動しました。
systemctl start firewalld
systemctl is-active firewalld
firewall-cmd --state確認結果:
active
runningactive zone / default zone
firewall-cmd --get-active-zones
firewall-cmd --get-default-zone確認結果:
public (default)
interfaces: enp0s3
public今回のRHEL 10.1環境では、active zoneもdefault zoneも`public`でした。
public zoneの内容
firewall-cmd --list-all確認結果:
public (default, active)
target: default
ingress-priority: 0
egress-priority: 0
icmp-block-inversion: no
interfaces: enp0s3
sources:
services: cockpit dhcpv6-client ssh
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:今回のRHEL 10.1環境では、`public` zoneのservicesに`ssh`が含まれていました。
ただし、すべての環境で`ssh`が含まれるとは断定しません。
services / ports / rich rules
| 項目 | 確認結果 | 意味 |
| services | `cockpit dhcpv6-client ssh` | service名で許可されている通信 |
| ports | 空 | ポート番号で直接追加された許可は確認されなかった |
| rich rules | 空 | 細かい条件付きルールは確認されなかった |
SSHは`ports`に`22/tcp`として表示されるのではなく、`services`に`ssh`として表示されていました。
firewalldでよく使うポート開放コマンドを別途確認したい場合は、[【Linux】Firewalldでよく利用するポート開放コマンド(firewall-cmd)](https://isleofhoso.com/linux-firewall-cmd/)も参考になります。
SSHサービスの許可確認
firewall-cmd --query-service=ssh
echo $?確認結果:
yes
0`yes`かつ終了コード`0`の場合、現在のactive zoneで`ssh` serviceが許可されていると判断できます。
runtime設定とpermanent設定
firewalldには、現在動作中のruntime設定と、永続設定であるpermanent設定があります。
firewall-cmd --permanent --list-all
firewall-cmd --permanent --query-service=ssh
echo $?今回の環境では、runtime側とpermanent側の両方で`ssh`が許可されていました。
ただし、すべての環境でruntime側とpermanent側が同じとは限りません。`--reload`や再起動の前後で設定の見え方が変わる場合があります。
【補足】
RHEL 9.4ではfirewalld停止中の挙動のみ確認しました。
停止中に`firewall-cmd`を実行すると、`FirewallD is not running`となりました。
RHEL 9.4の起動後挙動は未確認のため、この記事では主章として扱いません。
安全な初期設定手順
ここでは、新規構築サーバとサービス提供済みサーバに分けて、安全な初期設定の流れを整理します。
新規構築サーバの場合
- コンソールまたは復旧経路を確認する
- sshdの待受を確認する
- SSH接続元を確認する
- DefaultZoneを確認する
- public zoneを前提に、必要な通信だけを許可する方針を決める
- firewalldを起動する
- active zoneを確認する
- `--list-all`で`services`、`ports`、`rich rules`を確認する
- `--query-service=ssh`でSSH許可を確認する
- 必要な通信だけを追加する
- 不要な通信は開けない
新規構築サーバでは、public zoneを前提に、必要な通信だけを許可する方針が基本です。
サービス提供済みサーバの場合
- メンテナンス時間を確保する
- コンソールまたはクラウド復旧経路を確認する
- スナップショットまたはバックアップを取得する
- 現在の待受ポートを確認する
- SSH接続元を確認する
- 現在提供中のサービス通信を洗い出す
- 既存通信を止めない暫定起動方針を決める
- firewalld起動後にactive zone、services、ports、rich rules、interfaces、sourcesを確認する
- 現在必要な通信をfirewalld設定として整理する
- 段階的に不要な通信をブロックする
- 最終的には、必要な通信だけを許可する構成へ移行する
サービス提供済みサーバでは、既存通信を止めないことを最優先にします。
現在の待受ポートは、たとえば次のように確認します。
ss -ltnpSSH接続元は、次のように確認します。
echo "$SSH_CLIENT"洗い出す通信の例は次のとおりです。
- Web
- DB
- 監視
- バックアップ
- 管理用通信
起動前に全通信を完全に把握できない場合、既存通信を止めない暫定方式として、trusted zone相当で起動し、firewalld管理下へ移行する考え方があります。
ただし、trusted zoneは全許可に近いため、恒久運用として推奨しません。 trusted zoneのまま放置せず、firewalld起動後に状態を確認し、最終的にはpublicなど必要な通信だけを許可する構成へ段階的に移行してください。
よくある質問
firewalldを起動するとSSHは必ず切れますか？
必ず切れるわけではありません。
今回のRHEL 10.1環境では、起動後の`public` zoneに`ssh` serviceが含まれていたため、SSHは許可されている状態でした。
ただし、すべての環境で同じとは断定できません。起動前に復旧手段を確保し、起動後にSSH許可状態を確認してください。
新規構築サーバならすぐfirewalldを起動してよいですか？
新規構築サーバでも、SSH接続中に作業している場合は切断リスクがあります。
sshdの待受、SSH接続元、DefaultZone、復旧経路を確認してから起動してください。
サービス提供済みサーバではどう起動すべきですか？
いきなり起動しないでください。
先に復旧手段、現在の待受ポート、接続元、必要な通信を確認します。
既存通信を止めない必要がある場合は、trusted zone相当で暫定的に起動し、firewalld管理下へ移行する考え方があります。
ただし、これは恒久運用ではありません。 起動後にactive zone、services、ports、rich rules、interfaces、sourcesを確認し、段階的に必要な通信だけを許可する構成へ移行してください。
trusted zoneを使えば通信断対策になりますか？
通信断リスクを下げるための暫定方式として検討されることはありますが、安全策として扱うものではありません。
trusted zoneは通信を広く信頼する前提のzoneです。許可範囲が広がりすぎる可能性があるため、慎重に扱ってください。
サービス提供済みサーバでは、既存通信断を避けるための暫定方式としてtrusted zone相当から始める考え方があります。 ただし、trusted zoneのまま放置せず、firewalld管理下へ移行するための一時的な状態として扱ってください。
サービス提供済みサーバでtrusted zoneから起動するにはどうしますか？
まず、復旧経路、メンテナンス時間、スナップショットまたはバックアップを確保します。
次に、DefaultZoneとNetworkManager側のzone指定を確認します。
grep '^DefaultZone=' /etc/firewalld/firewalld.conf
nmcli connection show
nmcli connection show <接続名> | grep connection.zone今回のRHEL 10.1環境では、`connection.zone`が`--`の状態で、`firewall-offline-cmd --set-default-zone=trusted`によりDefaultZoneをtrustedへ変更し、firewalld起動後に`enp0s3`がtrusted zoneへ所属することを確認しました。
systemctl stop firewalld
firewall-offline-cmd --set-default-zone=trusted
grep '^DefaultZone=' /etc/firewalld/firewalld.conf
systemctl start firewalld
firewall-cmd --get-default-zone
firewall-cmd --get-active-zones
firewall-cmd --zone=trusted --list-allただし、設定方法は環境依存です。 DefaultZoneだけでなく、interfaceやNetworkManagerの`connection.zone`が影響する可能性があります。 起動後は、active zoneがtrustedになっているかを必ず確認します。
firewall-cmd --get-active-zones
firewall-cmd --zone=trusted --list-alltrustedのまま放置せず、段階的に必要な通信だけを許可する構成へ移行してください。
SSH接続中にfirewalldを起動して、SSHがブロックされていた場合、今つながっているSSHもすぐ切れますか？
既存セッションは維持される場合があります。ただし、再接続できるとは限りません。
firewalldには、確立済み通信を継続させる状態追跡の考え方があります。 そのため、すでに確立済みのSSHセッションは、そのまま維持される場合があります。
ただし、新規接続や再接続はブロックされる可能性があります。 今のSSHがつながっているから安全とは判断できません。
SSHを切断した後に再接続できない可能性があります。 また、ネットワーク瞬断、端末側切断、タイムアウト、reload、設定変更などで影響が出る可能性があります。
必ず別の復旧経路を確保してからfirewalldを起動してください。
public zoneとは何ですか？
public zoneは、公開ネットワーク向けの一般的なzoneです。
必要な通信を許可していく考え方で使います。
許可されていない通信は通らない可能性があるため、`services`、`ports`、`rich rules`を確認してください。
portsとservicesの違いは何ですか？
servicesは、firewalldに定義されたサービス名で許可する方法です。
portsは、ポート番号とプロトコルを直接指定して許可する方法です。
今回のRHEL 10.1環境では、SSHは`services`に`ssh`として表示され、`ports`に`22/tcp`としては表示されませんでした。
runtimeとpermanentの違いは何ですか？
runtimeは現在動作中の設定です。
permanentは永続設定です。
runtimeだけ変更した設定は、reloadや再起動で変わる場合があります。継続利用する設定はpermanent側も確認してください。
クラウド環境でコンソール接続できない場合はどうしますか？
firewalld起動やzone変更を急がないでください。
クラウド環境では、SSHが切れると復旧が難しくなる場合があります。管理コンソール、シリアルコンソール、スナップショット、バックアップ、別経路のアクセス方法を先に確認してください。
まとめ
firewalld初期設定で重要なのは、起動前に「自分のサーバでは何が起こるか」を判断することです。
新規構築サーバでは、public zoneを前提に、必要な通信だけを許可する方針が基本です。
サービス提供済みサーバでは、既存通信を止めないことが最優先です。 必要に応じて、通信断リスクを下げるための暫定方式としてtrusted zone相当からfirewalld管理下へ移行する考え方があります。
firewalldを起動すると、active zoneのルールが適用されます。
SSHが許可されていなければ、SSH接続が切れる可能性があります。
起動前には、sshd待受、SSH接続元、DefaultZone、復旧経路を確認します。
起動後には、active zone、`--list-all`、services、ports、rich rules、interfaces、sources、SSH許可、runtime/permanentを確認します。
trusted zoneは恒久運用ではなく、サービス提供済みサーバで通信断リスクを下げるための一時的な開始点として扱います。 最終的には、不要な通信を閉じ、必要な通信だけを許可する構成へ移行しましょう。
コメント