Linuxサーバーを運用するとき、「アクセス制御は何を使うべきか？」と悩んだ経験はないでしょうか。
定番のiptablesを知ってはいるけれど、最近ではfirewalldという仕組みを耳にする機会も増えています。
両者は同じように見えて、実はアプローチや管理の考え方が大きく異なります。では、なぜfirewalldが導入され、iptablesと併存する形で利用されているのでしょうか。
管理のしやすさを優先するのか、細かい制御を突き詰めるのか、選び方一つで運用効率やトラブル対応のスピードは変わります。
さらに「通信が突然遮断された」「設定を変えたのに反映されない」といった現場でよくある問題も、ツールごとの仕組みを理解していれば解決しやすくなります。
本記事ではfirewalldとiptablesの違いを整理し、それぞれの実践的な使い方を具体的に解説していきます。
Linuxの基礎知識
firewalldとiptablesとは
Linuxサーバーのセキュリティを担う主要な仕組みとして、古くから利用されてきたiptablesと、後発のfirewalldがあります。どちらもネットワークアクセスを制御する役割を持ちますが、仕組みや管理のしやすさが異なります。
ここでは両者の違いを整理していきます。
基本概要
iptablesはLinuxカーネルに備わる「netfilter」を直接操作して通信を制御する仕組みです。細かい条件をルールとして積み重ねることで、非常に高い柔軟性を持つことが特徴です。
iptables -L -n
【出力例:】
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 192.168.1.0/24 0.0.0.0/0
DROP all -- 203.0.113.5 0.0.0.0/0
一方でfirewalldはiptablesをベースにしながら「ゾーン」や「サービス」という抽象化レイヤーを導入しています。
これによりユーザーは複雑なルールを直接書かなくても、ポートやサービス単位で直感的に制御できます。
firewall-cmd --list-all
【出力例:】
public (active)
target: default
services: ssh dhcpv6-client
ports: 8080/tcp
ファイアウォールの２つの方式
ファイアウォールには大きく分けて2つの方式があります。
ひとつは「ステートレスフィルタ」、もうひとつは「ステートフルインスペクション」です。Linuxで標準的に利用されるのはステートフルインスペクションであり、firewalldもiptablesもこの仕組みを備えています。
ステートレスフィルタはパケットごとに独立して判定を行います。そのため、送信元や宛先アドレス、ポート番号など静的な条件だけで制御しますが、戻り通信を許可するルールを個別に設定する必要があり、運用が煩雑になりがちです。
ステートフルインスペクションは通信状態を保持し、「新規」「確立済み」「関連する応答」といったセッション単位で判定します。これにより、外向きに発信した通信の戻りパケットは自動的に許可されるため、効率的で安全な運用が可能になります。
| 方式 | 特徴 | メリット | デメリット |
|---|---|---|---|
| ステートレスフィルタ | 各パケットを独立して判定 | 処理が高速でシンプル | 戻り通信を個別に許可する必要がある |
| ステートフルインスペクション | 通信状態を保持しセッション単位で判定 | 戻り通信を自動的に許可でき効率的 | 状態保持にメモリを消費する |
このように、現在のLinux環境で利用されるファイアウォールは標準でステートフル方式を採用しているため、セキュリティと利便性の両立が可能です。
アクセス制御で取得できる情報と特徴
iptablesは送信元・宛先IPアドレス、ポート番号、プロトコルといった詳細な条件をもとに通信を制御できます。
これにより非常にきめ細かいルール設計が可能です。 firewalldは同じ情報を扱いつつも、ゾーンごとにまとめる設計を取っており、サーバーが複数のネットワークに接続されていても管理が容易になります。
| 項目 | iptables | firewalld |
|---|---|---|
| 操作対象 | パケット単位 | ゾーン・サービス単位 |
| 管理方法 | 手動でルールを記述 | 抽象化されたコマンド |
| 即時反映 | ルール再適用が必要 | 動的に反映可能 |
どちらを使うべきか
結論から言うと、環境と目的によって選ぶべき仕組みは異なります。
AWSなどのクラウド環境では現在もiptablesが広く利用されており、既存システムとの互換性や高度な制御が求められる現場では有効な選択肢です。
一方で、オンプレミスや社内サーバーのように日常的な運用負担を軽減したい場面では、設定変更を即時反映できるfirewalldが適しています。
つまり「厳格で細かいルールが必要ならiptables」「直感的で運用しやすさを優先するならfirewalld」と整理でき、環境に応じた使い分けがメリットにつながります。
ポイント
- iptables
クラウドや互換性重視の環境（特にAWSなど）で依然多く利用される。パケット単位で制御できるが、設定は複雑で運用負荷が高い。 - firewalld
RHEL系の標準で、大規模環境でも運用効率を優先する現場で採用が進んでいる。ゾーンやサービス単位で扱えるため、ルールの整理や管理が容易。
結局のところ、選択の分かれ目は「互換性を取るか、運用効率を取るか」にあります。
iptablesは既存資産やクラウド環境で根強く使われており、firewalldは新しいRHEL系環境で標準となりつつあります。
以下の表にまとめると、どのような状況でどちらを選ぶのが適しているかが一目で分かります。
| 選択基準 | 推奨される仕組み | 代表的な利用環境 |
|---|---|---|
| 既存資産や互換性を重視 | iptables | AWS、旧来のシステム |
| 直感的で運用効率を重視 | firewalld | オンプレミスの業務サーバー、RHEL系の標準構成 |
| 大規模環境でのルール管理 | firewalld | ゾーン単位で整理しやすく、動的変更に対応 |
firewalldとiptablesの導入手順
Linux環境でアクセス制御を行うためには、まず使用する仕組みを導入して有効化する必要があります。ここではfirewalldとiptablesの導入手順をそれぞれ紹介し、環境に応じて選べるように整理します。
firewalldのインストールと起動方法
firewalldはCentOSやRHEL系のディストリビューションでは標準で採用されていることが多く、直感的に扱えるのが特徴です。
導入にはパッケージをインストールし、サービスを有効化して稼働させます。
dnf install firewalld -y
【出力例:】
Installed: firewalld-1.2.3-1.el9.x86_64
Dependency Installed: python3-firewall-1.2.3-1.el9.noarch
続いてサービスを起動し、システム起動時に自動で有効化する設定を行います。
systemctl enable --now firewalld
【出力例:】
Created symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service → /usr/lib/systemd/system/firewalld.service.
Created symlink /etc/systemd/system/multi-user.target.wants/firewalld.service → /usr/lib/systemd/system/firewalld.service.
起動後の状態は次のコマンドで確認できます。
systemctl status firewalld
【出力例:】
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
Active: active (running)
iptablesの導入方法と有効化
iptablesはより細かい制御が可能なため、セキュリティポリシーを厳密に管理したい環境で利用されます。
RHEL8以降では「iptables-services」というパッケージを導入する必要があります。
dnf install iptables-services -y
【出力例:】
Installed: iptables-services-1.8.8-6.el9.x86_64
Dependency Installed: iptables-1.8.8-6.el9.x86_64
インストール後はサービスを有効化して起動します。
systemctl enable --now iptables
【出力例:】
Created symlink /etc/systemd/system/multi-user.target.wants/iptables.service → /usr/lib/systemd/system/iptables.service.
ルールの適用状況は次のコマンドで確認できます。
iptables -L -n
【出力例:】
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 192.168.1.0/24 0.0.0.0/0
DROP all -- 203.0.113.5 0.0.0.0/0
firewalldとiptablesの基本的な使い方
firewalldとiptablesはどちらもアクセス制御を行うための強力なツールですが、使い方の感覚は大きく異なります。
ここでは主要なオプションと操作を整理し、実際のコマンドと出力例を交えて紹介します。使い分けを理解することで、自分の環境に合った運用方法を選びやすくなります。
firewalldとiptablesのオプションや操作方法を並べると、それぞれの強みが理解しやすくなります。
| 用途 | firewalld | iptables |
|---|---|---|
| サービスの許可 | --add-service=http | -A INPUT -p tcp --dport 80 -j ACCEPT |
| 特定ポートの拒否 | --remove-port=22/tcp | -A INPUT -p tcp --dport 22 -j DROP |
| 設定の確認 | --list-all | -L -n |
| 設定の永続化 | --permanent | service iptables save |
firewalldの基本操作
firewalldはゾーンやサービス単位で制御できるため、直感的に設定できるのが特徴です。例えば、サービスを許可する場合は以下のように操作します。
firewall-cmd --zone=public --add-service=http
【出力例:】
success
設定を永続化したい場合はオプションを追加します。
firewall-cmd --zone=public --add-service=https --permanent
【出力例:】
success
現在の設定を確認するには次のコマンドを使用します。
firewall-cmd --list-all
【出力例:】
public (active)
target: default
services: ssh http https
ports: 8080/tcp
iptablesの基本操作
iptablesはより細かい制御が可能で、特定のIPやポートを指定してアクセスを制御できます。たとえば特定のアドレスを許可する場合は次のように設定します。
iptables -A INPUT -s 192.168.1.100 -j ACCEPT
【出力例:】
(ルールが追加されても直接出力はありません)
特定のポートを拒否する場合は以下のように記述します。
iptables -A INPUT -p tcp --dport 22 -j DROP
【出力例:】
(ルールが追加されても直接出力はありません)
現在のルールは次のコマンドで確認できます。
iptables -L -n
【出力例:】
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 192.168.1.100 0.0.0.0/0
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
firewalldとiptablesの応用設定
基本的な使い方を理解したうえで、実際の運用に役立つ応用設定を押さえておくことは重要です。
永続化の方法やログ管理、そして実際の環境でどちらを選ぶべきかを理解することで、セキュリティを確保しながら効率的な運用が可能になります。
永続化設定とルール管理
firewalldでは、通常の設定は再起動すると消えてしまいます。そのため永続化するには「--permanent」を付与して保存する必要があります。
firewall-cmd --zone=public --add-port=443/tcp --permanent
【出力例:】
success
設定を反映させるためにはリロードを実行します。
firewall-cmd --reload
【出力例:】
success
iptablesの場合は、追加したルールをファイルに保存して再起動後も有効にします。
service iptables save
【出力例:】
Saving firewall rules to /etc/sysconfig/iptables: [ OK ]
ログ管理と保存方法
通信を遮断するだけではなく、その記録を残すことも大切です。firewalldは内部でjournaldと連携しており、専用の設定を行わなくてもログが残ります。確認には以下を利用します。
journalctl -u firewalld
【出力例:】
Sep 09 11:00:01 server firewalld[1234]: Added port tcp/8080 to zone public
iptablesではLOGターゲットを指定してログに出力できます。例えば22番ポートへの接続を記録する場合は以下の通りです。
iptables -A INPUT -p tcp --dport 22 -j LOG --log-prefix "SSH attempt: "
【出力例:】
Sep 09 11:05:12 server kernel: SSH attempt: IN=eth0 OUT= MAC=... SRC=192.168.1.50 DST=192.168.1.10 LEN=60
運用環境での使い分け
結局のところ、どちらを使うべきかは運用環境の性質によって決まります。
firewalldはサービスやゾーン単位で管理できるため、日常的に変更が発生する環境では効率的です。一方でiptablesはパケット単位で細かく制御できるため、厳格なポリシーが求められる場面や、AWSのようにいまだに標準として利用される環境で強みを発揮します。
| 環境の特徴 | 推奨される仕組み | メリット |
|---|---|---|
| 頻繁なルール変更が発生 | firewalld | 動的に即時反映でき、運用効率が高い |
| 既存システムとの互換性重視 | iptables | AWSを含む既存環境で安定して利用可能 |
| セキュリティを厳格に管理 | iptables | 細かい条件指定ができ、監査要件にも対応しやすい |
| 中小規模の社内サーバー | firewalld | ゾーンやサービス単位で直感的に設定できる |
トラブルシュートと活用例
アクセス制御を導入すると、意図した通りに通信が通らないことや、運用中に特定のサービスだけ制御したいケースが発生します。
ここでは、firewalldとiptablesを用いたトラブルシュートや実践的な活用例を紹介します。これらを理解しておくと、現場での対応スピードが大きく向上します。
通信が通らない場合の確認手順
まずは設定状況を確認することが基本です。firewalldでは現在のゾーンにどのサービスやポートが許可されているかを表示できます。
firewall-cmd --zone=public --list-all
【出力例:】
public (active)
target: default
services: ssh http
ports: 8080/tcp
iptablesの場合はルールを一覧表示し、対象ポートやIPが制御されていないかを確認します。
iptables -S
【出力例:】
-P INPUT ACCEPT
-A INPUT -s 192.168.1.50/32 -j DROP
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
このように両方のツールで状況を把握すれば、問題箇所を特定しやすくなります。
サービス単位とポート単位の制御例
firewalldは「サービス単位」での制御に強みがあり、既知のサービスなら簡単に許可できます。
firewall-cmd --zone=public --add-service=https
【出力例:】
success
一方でiptablesはポート番号を直接指定するため、細かな条件設定に適しています。
iptables -A INPUT -p tcp --dport 3306 -j ACCEPT
【出力例:】
(ルール追加時は標準出力に表示されません)
このように、サービス単位で効率的に設定するならfirewalld、ポートやIPを細かく指定するならiptablesが便利です。
他ツールとの組み合わせによる強化
firewalldやiptables単体でも十分に強力ですが、他のツールと組み合わせることでさらに効果を発揮します。たとえば「fail2ban」と連携させれば、不正アクセスを検知して自動的にファイアウォールルールを追加できます。
systemctl status fail2ban
【出力例:】
● fail2ban.service - Fail2Ban Service
Loaded: loaded (/usr/lib/systemd/system/fail2ban.service; enabled)
Active: active (running)
また、監視ツール（ZabbixやNagios）と連携すれば、不正通信を検知した時点で通知を受け取り、即座に対応することも可能です。
| 利用シーン | 活用方法 | メリット |
|---|---|---|
| 不正ログイン対策 | fail2banと連携 | 攻撃元IPを自動遮断できる |
| 運用監視 | ZabbixやNagiosと連携 | 異常を早期検知し通知を受け取れる |
| 柔軟なアクセス制御 | iptablesとfirewalldを併用 | 効率的な管理と詳細な制御を両立 |
利用時の注意点
firewalldやiptablesは強力なアクセス制御を実現しますが、その分だけ注意すべき点もあります。性能への影響や設定ミスによる通信断、さらに運用中に起こりがちな落とし穴を理解しておくことで、安定したシステム運用につなげることができます。
パフォーマンスへの影響
ルールが増えすぎると、パケットごとのチェック回数が増加し、パフォーマンスに影響を与えることがあります。特にiptablesはルールを上から順に評価する仕組みのため、効率的に設計しないと処理が遅くなります。firewalldの場合も、ゾーンやサービスを重複して設定すると無駄な負荷がかかります。
iptables -L -v
【出力例:】
Chain INPUT (policy ACCEPT 500 packets, 40K bytes)
pkts bytes target prot opt in out source destination
このようにパケット数やバイト数を確認することで、どのルールが多く処理されているかを把握でき、不要なルールを整理するメリットがあります。
設定ミスによる通信断のリスク
最も多いトラブルは、意図せず全ての通信を遮断してしまうケースです。リモートから作業している場合、SSH接続をブロックするとサーバーにアクセスできなくなります。事前にSSHを許可するルールを入れてから他の制御を行うことが重要です。
firewall-cmd --zone=public --add-service=ssh
【出力例:】
success
先に必須サービスを許可しておけば、設定変更後もサーバーへ接続でき、作業が止まるリスクを防げます。
運用管理での落とし穴
ルールを一度設定して安心してしまうのも落とし穴です。環境の変化に合わせて更新されないルールは、不要な開放や逆に必要な通信を妨げる原因になります。また、複数の管理者が関わる場合、ルールの意図が分からなくなることも少なくありません。
iptables-save
【出力例:】
# Generated by iptables-save v1.8.8 on Mon Sep 9 11:15:00 2025
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 192.168.1.50/32 -j DROP
このようにルールを定期的に保存・確認しておくことで「なぜこのルールが存在するのか」を追跡でき、トラブルを未然に防ぐメリットがあります。
まとめ
firewalldとiptablesは同じファイアウォール機能を担うツールですが、設計思想や運用のしやすさに大きな違いがあります。firewalldはゾーンやサービス単位で直感的に扱えるため、頻繁に設定変更を行う環境や中小規模のシステムでメリットを発揮します。一方でiptablesはパケット単位で緻密な制御ができるため、既存資産との互換性が必要なクラウド環境や、厳格なセキュリティを求められる現場に適しています。
また、応用設定として永続化やログ管理を正しく行うことで、意図しない通信断やトラブルを防ぐことができます。さらに、fail2banや監視ツールと組み合わせることで、不正アクセス対策や異常検知を自動化できるのも大きな強みです。
最終的に大切なのは「どちらを選ぶか」ではなく「自分の環境に合った使い分け」を理解することです。ルールを整理し、ログを定期的に確認しておけば、セキュリティを維持しながら運用効率を高めることができます。これらを実践することで、日々の業務に余裕が生まれ、安定したサーバー運用が可能になります。
