ファイアウォール設定：UFW・iptables とセキュリティ戦略設計

サーバーのアラートメールが、眠っていた人を叩き起こす——あるテスト環境のデータベースに、異常なトラフィックがスキャンされていた。サーバーにログインしてみると、なんとファイアウォールがオフになっている。急いで有効化すると、ルール一覧はテスト用の設定でぐちゃぐちゃ、SSH ポートにはレート制限すらかかっていなかった。

この出来事は、ある現実的な問題を突きつけてきます。多くの人はファイアウォールを設定するとき、適当にいくつかコマンドをコピーして済ませるか、そもそも UFW と iptables の違いを知らず、ましてやセキュリティ戦略を体系的に設計するなど考えてもいません。今回はこのテーマをじっくり掘り下げていきましょう。

---

Linux のファイアウォールとはそもそも何なのか

ファイアウォールの話をする前に、よく混同される概念を整理しておきましょう。Netfilter です。多くの人は iptables こそがファイアウォールだと思っていますが、それは正しくありません。

Netfilter は Linux カーネル内のネットワークパケット処理フレームワークです。カーネルのプロトコルスタックの要所にいくつかの「フック」（hooks）を仕込んでおき、通過する各ネットワークパケットがこれらのフックをトリガーします。ここに自分の処理ロジック——たとえば遮断、書き換え、記録——を取り付けられるのです。

一方、iptables、UFW、nftables といったツールは、ユーザー空間の設定インターフェースにすぎません。これらで書いたルールは、最終的にすべて Netfilter が理解できる形式に変換され、カーネル内で実行されます。

たとえるなら、Netfilter は路盤の下に埋められた配管のバルブシステム、iptables はその昔ながらの手動つまみ、UFW はタッチパネル付きのモダンなコントロールパネルです——どれもバルブを開閉できますが、操作方法はまったく異なります。

ユーザー空間ツールの進化

Linux のファイアウォールツールはここ数年で大きく変化しました：

• iptables：老舗ツールで、2000 年ごろから存在します。Netfilter を直接操作し、構文は複雑ですが機能は強力です。
• nftables：iptables のモダンな代替で、2014 年に導入されました。構文がより統一され、性能も向上し、新しいバージョンの Ubuntu ではすでにこれをバックエンドとして既定で使っています。
• UFW（Uncomplicated Firewall）：2008 年に Ubuntu がリリースした簡易ツールです。内部は依然として iptables/nftables ですが、コマンドが感動するほどシンプルです。
• firewalld：Red Hat 系ディストリビューションの動的ファイアウォール管理ツールで、接続を切断せずに実行時のルール変更をサポートします。

この記事では UFW と iptables を中心に扱います。実際の運用で最も多く使われるからです。nftables はよりモダンですが、概念は iptables と共通しているため、iptables を習得してから nftables に移るのも難しくありません。

---

UFW：ファイアウォール設定をもう苦痛にしない

なぜ UFW はこんなに人気なのか

iptables を使ったことがある人なら、ルールを書くときのあの恐る恐るの感覚を知っているでしょう——パラメータを一つ間違えただけで SSH ポートを封鎖してしまい、自分が締め出されて入れなくなるのではないかと。

UFW の設計思想はまさに「シンプル第一」です。一行のコマンドでポートを開放でき、-A INPUT -p tcp --dport 22 -j ACCEPT のような人間に優しくない構文を覚える必要がありません。

比較してみましょう：

iptables:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT

UFW:

ufw allow ssh

違いは一目瞭然です。UFW はプロトコル、状態検査、IPv6 といった細部を自動で処理してくれるので、あなたは「SSH を開放したい」と言うだけで済みます。

基本設定：ゼロから始める

新しいサーバーが手元に届いたら、ファイアウォールの設定はこう進めるべきです：

第一歩：デフォルトポリシーを設定する

デフォルトポリシーは「どのルールにもマッチしなかったときどうするか」を決めます。セキュリティの基本原則は、入ってくるものはすべて拒否し、出ていくものはすべて許可することです。

sudo ufw default deny incoming   # すべての受信接続を拒否
sudo ufw default allow outgoing   # すべての送信接続を許可

こうすれば、明示的に許可しない限り、外部からのリクエストはすべて入ってこられません。多くの人は面倒がって既定を allow にしてしまい、結果としてサーバーは大扉を開け放った家のように、誰でも入って一周してこられる状態になります。

第二歩：必要なポートを開放する

ここに落とし穴があります。必ず先に SSH を開放してから、ファイアウォールを有効化してください！そうしないとリモート接続が即座に切れてしまいます。

sudo ufw allow ssh        # SSH を開放（ポート 22）
sudo ufw allow 80/tcp     # HTTP
sudo ufw allow 443/tcp    # HTTPS

カスタムポートの SSH（仮に 2222 とします）など、他のサービスを動かしている場合は：

sudo ufw allow 2222/tcp

第三歩：ファイアウォールを有効化する

sudo ufw enable

システムが警告を表示します：「This may disrupt existing ssh connections」——慌てないでください。先ほど allow ssh を実行していれば問題ありません。y を入力して確認します。

第四歩：状態を確認する

sudo ufw status verbose

出力はだいたいこんな感じです：

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere

Status: active が見えれば、ファイアウォールが有効になったということです。

応用テクニック：設定をもっと安全に

アプリケーション設定ファイル（App Profiles）

UFW にはとても便利な機能があります——App Profiles です。Nginx、Apache、OpenSSH といった一般的なサービスの多くには、あらかじめ設定ファイルが定義されています。

利用可能な設定を確認します：

sudo ufw app list

出力にはこのような内容が含まれるかもしれません：

Available applications:
  Apache
  Apache Full
  Apache Secure
  Nginx Full
  Nginx HTTP
  Nginx HTTPS
  OpenSSH

アプリ名をそのまま使ってポートを開けます：

sudo ufw allow 'Nginx Full'

このコマンドは HTTP (80) と HTTPS (443) を同時に開放してくれるので、手動で2行書く手間が省けます。

レート制限：ブルートフォース対策

SSH ポートはブルートフォース攻撃を最も受けやすいポートです。UFW にはレート制限機能が組み込まれています：

sudo ufw limit ssh

このルールの意味は、ある IP が30秒以内に6回を超えて接続を試みた場合、一時的にブロックするというものです。単なる allow ssh よりずっと安全です。

特定 IP のアクセスを制限する

特定の IP だけにあるサービスへのアクセスを許可したいこともあります。たとえばデータベース管理画面を社内ネットワークだけに許可する場合：

# 192.168.1.100 だけに MySQL へのアクセスを許可
sudo ufw allow from 192.168.1.100 to any port 3306

# 悪意のある IP を拒否
sudo ufw deny from 203.0.113.100

ログ記録

ファイアウォールのログは問題切り分けの鍵です：

sudo ufw logging on
sudo ufw logging medium   # ログレベル：low/medium/high

ログは /var/log/ufw.log に保存され、フォーマットはだいたいこんな感じです：

Mar 15 10:23:45 server kernel: [UFW BLOCK] IN=eth0 OUT= MAC=... SRC=203.0.113.100 DST=... PROTO=TCP SPT=54321 DPT=22

[UFW BLOCK] が見えれば、ファイアウォールがこのリクエストを遮断したということです。

UFW の限界

UFW は便利ですが、境界もあります：

• NAT とポートフォワーディング：サポートは限定的で、複雑な設定はやはり iptables が必要です
• 複雑なルールチェーン：カスタムチェーンや条件のネストには非対応です
• 内容によるフィルタリング：できません（HTTP リクエスト内の悪意あるペイロードのフィルタリングなど）

要件がこれらの境界を超える場合は、iptables に切り替える必要があります。

---

iptables：きめ細かな制御の切り札

iptables のアーキテクチャを理解する

iptables は UFW より複雑ですが、内部のロジックは実はかなり明快です。鍵は「テーブル - チェーン - ルール」の3層構造を理解することです。

テーブル（Tables）

異なるテーブルが異なる種類のタスクを処理します：

• filter テーブル（既定）：パケットフィルタリング、受け入れるか拒否するかを決める
• nat テーブル：アドレス変換（NAT）、送信元／宛先アドレスを書き換える
• mangle テーブル：パケットの TOS、TTL などのメタデータを変更する
• raw テーブル：例外を設定し、コネクション追跡を迂回する

ほとんどのシーンでは filter テーブルしか使わないので、既定でこれを操作します。

チェーン（Chains）

チェーンはルールの集合で、順番に実行されます。filter テーブルには5つの組み込みチェーンがあります：

• INPUT：受信パケット（宛先アドレスが本機）
• OUTPUT：送信パケット（送信元アドレスが本機）
• FORWARD：転送パケット（本機は中継するだけ）
• PREROUTING：ルーティング前の処理
• POSTROUTING：ルーティング後の処理

日常の設定では主に INPUT と OUTPUT を使い、FORWARD はルーターやゲートウェイを作るときに使います。

ルールのマッチ順序

ルールは上から下へ1行ずつマッチングされ、最初にマッチした時点でアクションを実行し、後続のルールはチェックされません。

例を挙げましょう：

iptables -A INPUT -s 192.168.1.100 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -j DROP

この2つのルールでは、192.168.1.100 は最初の ACCEPT にマッチして即座に通過し、2つ目はチェックされません。しかしルールの順番が逆なら、192.168.1.100 は最初の DROP に遮断され、2つ目にはまったく到達しません。

これこそが iptables 設定の中心原則です：より具体的なルールを前に、より汎用的なルールを後ろに置く。

基本構文の分解

iptables コマンドの基本フォーマット：

iptables -t テーブル名 -A チェーン名 マッチ条件 -j アクション

よく使うパラメータ：

• -t：テーブルを指定（既定は filter、省略可）
• -A：チェーンの末尾にルールを追加（Append）
• -I：指定位置にルールを挿入（Insert）
• -D：ルールを削除（Delete）
• -L：ルールを一覧表示（List）
• -F：すべてのルールをクリア（Flush）
• -P：デフォルトポリシーを設定（Policy）

マッチ条件

• -s：送信元 IP アドレス（例：-s 192.168.1.100）
• -d：宛先 IP アドレス
• -p：プロトコル（tcp、udp、icmp）
• --sport：送信元ポート
• --dport：宛先ポート
• -i：受信ネットワークインターフェース（例：-i eth0）
• -o：送信ネットワークインターフェース
• -m state --state：コネクション状態の検査

アクション（Target）

• ACCEPT：パケットを受け入れる
• DROP：静かに破棄する（何の情報も返さない）
• REJECT：拒否してエラーメッセージを返す
• LOG：ログに記録する（遮断せず、後続のルールのマッチを続ける）
• RETURN：現在のチェーンを停止し、一つ上のチェーンに戻る

実践設定：安全なサーバーファイアウォール

以下は本番環境向けの完全な設定フローです：

第一歩：既存ルールをクリアする

新しいサーバーには既定のルールがあることが多いので、まずきれいにします：

sudo iptables -F        # すべてのルールをクリア
sudo iptables -X        # すべてのカスタムチェーンを削除
sudo iptables -t nat -F
sudo iptables -t mangle -F

第二歩：デフォルトポリシーを設定する

UFW と同じく、既定で受信を拒否します：

sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT

第三歩：確立済みの接続を許可する

このルールは特に重要です。応答トラフィックと確立済み接続のデータの通過を許可します。

sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

どういう意味でしょうか。あなたが Web サイトにアクセスするとき、送り出すリクエストは OUTPUT（既定で ACCEPT）、サイトからの返信は INPUT です。もしこのルールがなければ、返信パケットは DROP されてしまい、データをまったく受け取れません。

ESTABLISHED は接続が確立済みであることを、RELATED は関連する接続（FTP のデータ接続など）を表します。

第四歩：必要なポートを開放する

# SSH
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# HTTP
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT

# HTTPS
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

第五歩：ICMP を制限する（任意）

ICMP は ping が使うプロトコルです。一部のセキュリティポリシーでは ping を禁止します：

# ping を許可
sudo iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# あるいは ping を拒否
sudo iptables -A INPUT -p icmp -j DROP

第六歩：ログを記録する

DROP の前に LOG ルールを1つ加えると、切り分けが楽になります：

sudo iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 4

--limit 5/min はログの爆発を防ぎ、1分あたり最大5件まで記録します。

第七歩：最後の DROP

実はデフォルトポリシーがすでに DROP ですが、明示的に1行書くとより明確です：

sudo iptables -A INPUT -j DROP

第八歩：ルールを保存する

iptables のルールは既定では永続化されず、再起動すると消えます。Ubuntu/Debian では iptables-persistent が使えます：

sudo apt install iptables-persistent
sudo netfilter-persistent save

あるいは手動で保存します：

sudo iptables-save > /etc/iptables/rules.v4
sudo ip6tables-save > /etc/iptables/rules.v6  # IPv6 ルール

ルールの状態を確認する

sudo iptables -L -n -v --line-numbers

• -n：数値表示（ドメイン名を解決しないので速い）
• -v：詳細モード（パケットカウントを表示）
• --line-numbers：ルール番号を表示

出力例：

Chain INPUT (policy DROP 0 packets, 0 bytes)
num  pkts bytes target     prot opt in     out     source               destination
1      42  2848 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state ESTABLISHED,RELATED
2       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
3       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
4       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443
5       0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 5/min burst 5 LOG flags 0 level 4 prefix "iptables denied: "
6       0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

---

UFW と iptables：結局どちらを選ぶべきか

ここまで話してきて、まだ迷っているかもしれません。UFW を使うべきか、iptables を使うべきか？

中心的な違い：使いやすさ vs 柔軟性

観点	UFW	iptables
コマンドの簡潔さ	超シンプル（ufw allow ssh）	複雑（iptables -A INPUT -p tcp --dport 22 -j ACCEPT）
学習曲線	数時間で使いこなせる	数日から数週間の深い学習が必要
内部の仕組み	結局は iptables/nftables	iptables を直接操作
性能	同じ（どちらも Netfilter に依存）	同じ
NAT／ポートフォワーディング	基本的にサポート、複雑なシーンでは不十分	完全サポート
複雑なルールチェーン	カスタムチェーンに非対応	完全サポート、多層ネスト可
アプリケーション設定	App Profiles があり便利	手動でルールを書く必要あり
IPv6	自動処理	ip6tables で個別に設定が必要
スクリプト管理	手動設定向き	スクリプトでの一括デプロイ向き

性能の真実

多くの人は iptables の方が性能が良いと思っていますが、実際には内部の仕組みはまったく同じです——どちらもカーネル内で Netfilter が処理します。唯一の性能差はルール数によるもので、ルールが多いほどマッチングが遅くなります。ただし中小規模のサーバーへの影響は小さいです。

選択のアドバイス

UFW がおすすめのシーン：

• VPS、クラウドサーバー、専用サーバー
• Web サービス、API サービスのデプロイ
• 複雑なネットワーク要件がない（NAT やポートフォワーディングをしない）
• 専門のシステム管理者ではない（iptables の構文を学びたくない）
• 迅速なセキュリティ設定（攻撃への緊急対応など）

iptables がおすすめのシーン：

• ゲートウェイ、ルーター、VPN サーバー
• NAT、ポートフォワーディング、負荷分散が必要
• 複雑なルールチェーン、多層的な条件判定
• 大規模デプロイ（数十台のサーバーをスクリプトで管理）
• 高度なフィルタリング（パケット内容、レート、時間による制御）
• 運用チーム（ネットワーク設定の専任者がいる）

併用できるのか？

おすすめしません。UFW と iptables はどちらも同じ Netfilter のルールを操作するため、混在すると競合しやすくなります。

例を挙げましょう。iptables で SSH ポートを開放した後、UFW で SSH を deny すると、最後のルールが有効になり、あなたは締め出されてしまいます。

どうしても併用する場合は、ルールの順序を覚えておきましょう。UFW のルールは before.rules と after.rules の間にあり、iptables で直接追加したルールは UFW の既定ルールに上書きされることがあります。

---

ファイアウォールのセキュリティ戦略設計の中心原則

ツールを使いこなすのは第一歩にすぎません。より重要なのは、合理的なセキュリティ戦略を設計することです。多くの人はファイアウォールを設定するとき、適当にいくつかルールを足し、結果として穴だらけになります。

原則一：デフォルト拒否（Default Deny）

これがセキュアな設定の土台です。

中心的な考え方：明示的に許可しない限り、すべてを拒否する。

反面教師は「デフォルト許可」——まず全部開けてから、リスクのあるポートを一つずつ封鎖していく方法です。この考え方には2つの問題があります：

1. どのポートがリスクなのか、そもそもわからない（攻撃者は全 65535 ポートをスキャンする）
2. 1つでもポートを見落とせば、そこが弱点になる

正しいやり方：

# UFW
sudo ufw default deny incoming
sudo ufw default allow outgoing

# iptables
sudo iptables -P INPUT DROP
sudo iptables -P OUTPUT ACCEPT

そのうえで、業務に必須のポートだけを開放します。ポートを1つ開けるたびに、自問しましょう。このポートは何のためのものか？送信元 IP を制限できないか？

原則二：最小権限の原則

各ルールは1つのことだけを行い、開放する範囲はできるだけ狭くすべきです。

ポート開放：

• ❌ ufw allow 3306（世界中が MySQL に接続できる）
• ✅ ufw allow from 192.168.1.100 to any port 3306（特定 IP のみ許可）

サービスアクセス：

• ❌ すべての内部サービスのポートを開放する
• ✅ 公開向けのサービス（Web、API）だけを開放し、内部サービスは社内ネットワークか VPN でアクセスする

SSH 管理：

• ❌ ufw allow ssh（誰でもログインを試せる）
• ✅ ufw allow from 会社IP to any port 22 + ufw limit ssh

原則三：多層防御（Defense-in-Depth）

ファイアウォールは万能ではなく、第一の防衛線にすぎません。完全なセキュリティ体制には、複数の層の防護があるべきです：

1. ネットワーク層ファイアウォール（UFW/iptables）：悪意あるトラフィックを遮断
2. アプリケーション層ファイアウォール（WAF）：SQL インジェクション、XSS などの HTTP 層攻撃をフィルタリング
3. ホスト層防護（SELinux/AppArmor）：プロセスの権限を制限
4. 侵入検知（IDS/IPS）：異常な挙動をリアルタイム監視
5. 定期監査：ログ分析、脆弱性スキャン

例を挙げましょう。ファイアウォールが HTTP 80 ポートを開放していても、WAF が HTTP リクエスト内の悪意あるペイロードをチェックし、SELinux が Web サーバーのファイルアクセス権限を制限します。3つの層をすべて通過してようやく攻撃者はアプリケーション層に到達しますが、アプリケーション層にはさらにコードのセキュリティ（入力検証、権限チェック）があります。

原則四：ネットワークセグメンテーション（Network Segmentation）

大規模ネットワークをひとまとめにしてはいけません。ゾーンに分割します。

典型的なセグメンテーションモデル：

• DMZ（Demilitarized Zone）：公開向けのサービス（Web サーバー、メールサーバー）
• 内部ゾーン：データベース、内部サービス、オフィスネットワーク
• 管理ゾーン：運用管理、監視、ログ

セグメンテーションのメリット：

1. 障害の隔離：DMZ が突破されても、攻撃者は内部ネットワークに入るためにもう一つの防衛線を突破しなければならない
2. 伝播の制限：ワームウイルスが1つのゾーンで広まっても、ゾーンをまたぐ際にファイアウォールが遮断する
3. 権限の細分化：ゾーンごとにユーザーのアクセス権限が異なる

iptables でセグメンテーションを設定するとき、FORWARD チェーンが鍵になります：

# DMZ から内部ネットワークへ：データベースアクセスのみ許可
iptables -A FORWARD -s dmz_network -d internal_network -p tcp --dport 3306 -j ACCEPT
iptables -A FORWARD -s dmz_network -d internal_network -j DROP

原則五：定期的な監査と更新

ファイアウォールの設定は一度やれば終わりではありません。

ルールの見直し：

• 毎月1回チェック：期限切れのルールはないか？（テスト用ポートの削除を忘れていないかなど）
• 四半期ごとに評価：業務の変化後、ポート開放は妥当か？
• 毎年再構築：冗長なルールを整理し、性能を最適化する

ログ分析：

• 毎週ファイアウォールのログを確認：どの IP が遮断されたか？遮断の理由は？
• 異常トラフィックのアラート：しきい値を設定し、超過したら自動で通知する
• 攻撃の追跡：ログから攻撃元を特定し、的を絞って強化する

変化への対応：

• 新サービスの公開：先にセキュリティリスクを評価してから、ポートを開放する
• 攻撃イベント：ルールを調整し、悪意ある IP を封鎖し、レート制限を加える
• 業務の調整：不要なルールを削除し、露出面を減らす

---

本番環境設定の実践：落とし穴を避ける

設定フローの安全な手順

第一歩：テスト環境で検証する

本番サーバーで新しいルールを直接試してはいけません。まずテスト VM や開発環境で一度設定し、問題ないことを確認してから本番に上げます。

第二歩：SSH の退路を残す

設定前にまず SSH ポートが開放されているか確認します。カスタムポートを使う場合は忘れずに：

# UFW
ufw allow 2222/tcp  # カスタム SSH ポート

# iptables
iptables -A INPUT -p tcp --dport 2222 -j ACCEPT

第三歩：段階的にポートを開放する

一度にすべてのポートを開放してはいけません。まず最も中心的なもの（SSH）を開放してログインできるか確認し、次に Web ポート、そして他のサービスと進めます。

第四歩：設定変更を記録する

ファイアウォールのルールを変更するたびに記録します：

• 変更日時
• 変更内容
• 変更理由
• 検証結果

ルール設定ファイルを Git で管理したり、ドキュメントで記録したりできます。

よくあるミスと解決策

ミス 1：SSH ロックアウト

症状：ファイアウォールを有効化したあと、SSH 接続が切れ、二度とサーバーにログインできなくなる。

原因：先に SSH ポートを開放していない、またはルールの順序ミス（先に DROP、後に ACCEPT）。

予防：

1. 設定前に既存の SSH ポートを確認する
2. 先に ufw allow ssh、その後 ufw enable
3. iptables を使う場合は、SSH ルールを DROP より前に置くことを確実にする

緊急対応：

• VPS：プロバイダーの管理画面 Console からログイン（SSH を迂回）
• クラウドサーバー：プロバイダーが提供する「Recovery Mode」や「Rescue System」
• 物理サーバー：ローカルでログイン

ミス 2：ルールの順序が混乱している

症状：あるポートに明らかに ACCEPT ルールを書いたのに、やはり接続できない。

原因：ルールの順序の問題で、前にある DROP が先にマッチしてしまった。

切り分け：

iptables -L -n -v --line-numbers

ルール番号を確認し、ACCEPT が DROP より前にあるか確かめます。

解決：

# 誤った位置のルールを削除
iptables -D INPUT 3

# 正しい位置に挿入
iptables -I INPUT 2 -p tcp --dport 80 -j ACCEPT

ミス 3：設定が永続化されていない

症状：再起動後にファイアウォールのルールがすべて消える。

原因：iptables のルールは既定でメモリ上にしか存在せず、再起動で消える。

解決：

# Ubuntu/Debian
sudo apt install iptables-persistent
sudo netfilter-persistent save

# CentOS/RHEL
sudo service iptables save

UFW はデフォルトで永続化されるので、追加の対応は不要です。

ミス 4：IPv6 が無視されている

症状：IPv4 は正常だが、IPv6 でアクセスできない。

原因：iptables は IPv4 だけを設定しており、IPv6 は ip6tables を使う必要がある。

解決：

# IPv6 ルール（IPv4 と同様）
sudo ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo ip6tables -A INPUT -p tcp --dport 80 -j ACCEPT

# 保存
sudo ip6tables-save > /etc/iptables/rules.v6

UFW は IPv6 を自動処理するので、個別の設定は不要です。

トラブルシューティングのコツ

ファイアウォールの設定で問題が起きたら、この手順で切り分けます：

1. ファイアウォールの状態を確認する

# UFW
sudo ufw status verbose

# iptables
sudo iptables -L -n -v

ファイアウォールが有効か、ルールが正しいかを確認します。

2. ポートの疎通をテストする

# 外部からテスト
telnet server_ip 22
nc -zv server_ip 80

# ローカルでテスト
sudo netstat -tulnp | grep :22

3. ファイアウォールのログを確認する

# UFW
tail -f /var/log/ufw.log

# iptables
tail -f /var/log/kern.log | grep "iptables"

遮断されたリクエストの記録があるか確認します。

4. 一時的に無効化して切り分ける

# UFW
sudo ufw disable

# iptables
sudo iptables -F

無効化してから疎通をテストし、ファイアウォールの問題なのか、サービス自体の問題なのかを確認します。

注意：ファイアウォールを無効化するとサーバーは完全に露出します。切り分けが終わったらすぐに復旧してください！

---

まとめ：あなたのファイアウォールセキュリティ体制を構築する

いろいろ話してきましたが、最後に中心となるポイントをまとめます。

ツールの選択

• シンプルなシーン：UFW で十分。数分で設定でき、手間がかからず楽
• 複雑なシーン：iptables の方が柔軟で、ゲートウェイ、NAT、高度なフィルタリングに向く
• 併用しない：どちらか一方のツールに統一して管理し、ルールの競合を避ける

設定原則

• デフォルト拒否：すべての受信を拒否し、必要なポートだけを開放する
• 最小権限：各ルールの範囲をできるだけ狭くし、送信元 IP を制限する
• 多層防御：ファイアウォールは第一の層にすぎず、WAF や SELinux と組み合わせて多層防護する
• ネットワークセグメンテーション：DMZ、内部ネットワーク、管理ゾーンを隔離する
• 定期監査：毎月ルールを確認、四半期ごとに評価、毎年再構築する

実践のポイント

• 先に SSH を開放：ファイアウォール設定前にまず SSH ポートにアクセスできることを確保する
• ルールの順序：iptables のルールは具体的なものから汎用的なものへ、順序が重要
• 永続化して保存：iptables のルールは保存し、再起動後に自動で読み込まれるようにする
• IPv6 設定：iptables は ip6tables を個別に設定する必要があり、UFW は自動処理する
• テスト環境で検証：本番設定の前にまずテスト環境で一度試す
• ログを残す：ファイアウォールのログを有効にし、異常トラフィックを定期的に分析する

次のステップの学習

ファイアウォールとサーバーセキュリティをさらに深めたいなら、次を探求できます：

• nftables：iptables のモダンな代替で、構文がより統一され、性能も良い
• firewalld：動的ファイアウォール管理、実行時の変更をサポート
• WAF 設定：Nginx ModSecurity、Cloudflare WAF
• 侵入検知：Fail2ban（ブルートフォースを自動封鎖）、OSSEC
• SELinux/AppArmor：ホスト層の権限制御

ファイアウォール設定はサーバーセキュリティの基礎です。UFW と iptables の使い方を習得し、セキュリティ戦略の設計原則を理解すれば、あなたのサーバーは大扉を開け放った家のように誰もが出入りできる状態にはなりません。深夜3時にアラートメールを受け取る、そんなことも少しは減らせるはずです。

---

---

参考資料

• UFW Essentials: Common Firewall Rules and Commands - DigitalOcean
• UFW vs iptables: Simple Firewall Rules That Actually Work - WeHaveServers
• Difference Between ufw vs. nftables vs. iptables - Baeldung on Linux
• Firewall Design Principles In Network Security - Fortinet
• Linux Firewall: Configuration, Tools, Best Practices - TuxCare
• Ubuntu Community Help Wiki - UFW