ファイアウォール設定：UFW、iptablesとセキュリティポリシー設計
深夜3時。サーバーからのアラートSMSで睡眠から引きずり出された——テスト環境のデータベースに異常なトラフィックが検出された。サーバーにログインしてみると、ファイアウォールが完全に無効になっていた。慌てて有効化したが、ルールリストは乱雑なテスト設定で埋め尽くされ、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学習後の転用は難しくない。
UFW：ファイアウォール設定の苦痛を解消
UFWが人気の理由
iptables経験者なら知っている——ルール書く時の緊張感。一つパラメータ間違えればSSHポートを封鎖、自分が外にロックされる恐怖。
UFWの設計理念は「簡素第一」。1コマンドでポート開放、-A INPUT -p tcp --dport 22 -j ACCEPTのような反人間構文を覚える必要なし。
比較：
iptables:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPTUFW:
ufw allow ssh一目瞭然。UFWは自動でプロトコル、状態検査、IPv6等を処理——「SSH開放したい」と言えばいい。
基本設定：ゼロから開始
新サーバー入手時、ファイアウォール設定はこう進める：
ステップ1：デフォルトポリシー設定
デフォルトポリシーは「ルールにマッチしない時どうする」を決める。セキュリティ基本原則：全インバウンド拒否、全アウトバウンド許可。
sudo ufw default deny incoming # 全インバウンド接続拒否
sudo ufw default allow outgoing # 全アウトバウンド接続許可これで、明示的に許可しない限り、外部リクエストは一切入らない。多くの人は面倒でallowに設定——サーバーは扉全開の家になり、誰でも出入り可能。
ステップ2：必要ポート開放
ここに落とし穴：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ステップ3：ファイアウォール有効化
sudo ufw enableシステム警告：「This may disrupt existing ssh connections」——慌てない、前にallow ssh実行済みなら問題なし。y入力で確認。
ステップ4：状態確認
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 AnywhereStatus: 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のみサービスアクセス許可したい時、例えばDB管理画面は会社内网のみ：
# 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リクエスト内恶意Payloadフィルタ等）
需要がこれら境界を超える場合、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はルータやゲートウェイ時に使用。
ルールマッチング順序
ルールは上から下に順次マッチング、最初マッチでアクション実行、後続ルールは検査なし。
例：
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にマッチ、直接通過、第二ルール検査なし。但し順序逆なら、192.168.1.100は最初のDROPで拦截、第二ルール到達不能。
これが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：インバウンドNIC（例-i eth0）-o：アウトバウンドNIC-m state --state：接続状態検査
アクション（Target）
- ACCEPT：パケット接受
- DROP：静默破棄（情報返却なし）
- REJECT：拒否しエラーメッセージ返却
- LOG：ログ記録（拦截なし、後続ルールマッチ継続）
- RETURN：現在チェーン停止、上位チェーン復帰
実戦設定：安全なサーバーファイアウォール
完全な本番環境設定流程：
ステップ1：既存ルール消去
新サーバーはデフォルトルール常有、先に清理：
sudo iptables -F # 全ルール消去
sudo iptables -X # 全カスタムチェーン削除
sudo iptables -t nat -F
sudo iptables -t mangle -Fステップ2：デフォルトポリシー設定
UFW同様、デフォルトでインバウンド拒否：
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPTステップ3：確立済接続許可
このルールは極重要：応答トラフィックと確立済接続データ通過許可。
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT意味：ウェブサイト訪問時、発信リクエストはOUTPUT（デフォルトACCEPT）、サイト応答はINPUT。このルールなし、応答パケットはDROP、データ受信不能。
ESTABLISHEDは接続確立済、RELATEDは関連接続（FTPデータ接続等）。
ステップ4：必要ポート開放
# 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ステップ5：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ステップ6：ログ記録
DROP前にLOGルール追加、トラブルシューティング用：
sudo iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 4--limit 5/minはログ爆発防止、最大5件/分。
ステップ7：最終DROP
デフォルトポリシーは既にDROP、但し明示的書くはより明確：
sudo iptables -A INPUT -j DROPステップ8：ルール保存
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/0UFWと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、クラウドサーバー、専用サーバー
- ウェブサービス、APIサービス展開
- 複雑ネットワーク需要なし（NAT、ポートフォワーディングなし）
- 非専門システム管理者（iptables構文学習不要）
- 高速セキュリティ設定（緊急攻撃対応等）
iptables推奨场景：
- ゲートウェイ、ルータ、VPNサーバー
- NAT、ポートフォワーディング、負荷分散必要
- 複雑ルールチェーン、多層条件判断
- 大規模展開（数十台サーバースクリプト管理）
- 高度フィルタリング（パケット内容、レート、時間）
- 運用チーム（専門ネット設定担当者）
混用可能か？
非推奨。双方同一Netfilterルール操作、混用で容易冲突。
例：iptablesでSSH開放後、UFWでSSH拒否——最後のルールが有効、ロックアウト発生。
混用必須時、ルール順序記憶：UFWルールはbefore.rulesとafter.rules間、iptables直接追加ルールはUFWデフォルトルールで覆写可能。
ファイアウォールセキュリティポリシー設計の核心原則**
ツール習熟は第一歩のみ、より重要なのは合理的セキュリティポリシー設計。多くの人はルール適当追加、結果漏洞多数。
原則1：デフォルト拒否（Default Deny）**
これはセキュリティ設定の基石。
核心思想：明示許可除外、全拒否。
逆は「デフォルト許可」——全開後、危険ポート逐一封鎖。この思考は2問題有：
- 全危険ポート不明（攻撃者は65535ポート全扫描）
- 1ポート漏れ、1隐患残
正解：
# UFW
sudo ufw default deny incoming
sudo ufw default allow outgoing
# iptables
sudo iptables -P INPUT DROP
sudo iptables -P OUTPUT ACCEPT業務必要ポートのみ開放。各ポート開放時、問：このポート用途？源IP制限可能か？
原則2：最小権限原則**
各ルールは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
原則3：多層防御（Defense-in-Depth）**
ファイアウォール万能ではない、第一防御層のみ。完全セキュリティ体系は多層保護必要：
- ネットワーク層ファイアウォール（UFW/iptables）：恶意トラフィック拦截
- アプリケーション層ファイアウォール（WAF）：SQL注入、XSS等HTTP層攻撃フィルタ
- ホスト層保護（SELinux/AppArmor）：プロセス権限制限
- 侵入検査（IDS/IPS）：リアルタイム異常行動監視
- 定期監査：ログ分析、脆弱性扫描
例：ファイアウォールHTTPポート80開放、WAFはHTTPリクエスト内恶意Payload検査、SELinuxはウェブサーバーファイルアクセス権限制限。3層突破後、攻撃者はアプリ層到達——但しアプリはコードセキュリティ有（入力検証、権限検査）。
原則4：ネットワーク分段（Network Segmentation）**
大規模ネットワークは一锅粥不可、区域分割必要。
典型分段モデル：
- DMZ（Demilitarized Zone）：公開面向サービス（ウェブサーバー、メールサーバー）
- 内部区域：データベース、内部サービス、オフィスネットワーク
- 管理区域：運用管理、監視、ログ
分段利点：
- 故障隔离：DMZ突破、攻撃者は更に1防线突破必要で内部進入
- 伝播制限：ワーム virus1区域伝播、越区域はファイアウォール拦截
- 権限細化：異区域ユーザーは異アクセス権限
iptables設定分段時、FORWARDチェーンは鍵：
# DMZから内部：DBアクセスのみ許可
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原則5：定期監査と更新**
ファイアウォール設定は一度完了ではない。
ルール審査：
- 月次検査：过期ルール有？（テストポート削除忘れ等）
- 季度評価：業務変化後、ポート開放合理？
- 年次重构：冗長ルール清理、性能优化
ログ分析：
- 週次ファイアウォールログ確認：どのIP拦截？理由？
- 異常トラフィック警告：阈值設定、超過自動通知
- 攻撃溯源：ログから攻撃源発見、针对性强化
変化対応：
- 新サービス上線：セキュリティリスク評価後ポート開放
- 攻撃事件：ルール調整、恶意IP封鎖、レート制限追加
- 業務調整：不要ルール削除、暴露面減少
本番環境実戦：落とし穴回避**
設定流程の安全ステップ**
ステップ1：テスト環境検証
本番サーバーで新ルール直接試験不可。先にテストVM或開発環境設定、問題ない確認後本番適用。
ステップ2：SSH後路保持
設定前SSHポート開放確認。カスタムポート使用時、記憶：
# UFW
ufw allow 2222/tcp # カスタムSSHポート
# iptables
iptables -A INPUT -p tcp --dport 2222 -j ACCEPTステップ3：段階的ポート開放
全ポート一度開放不可。核心（SSH）先、ログイン確認、次Webポート、次他サービス。
ステップ4：設定変化記録
各ファイアウォールルール修改記録：
- 修改時間
- 修改内容
- 修改理由
- 検証結果
Gitでルール設定ファイル管理、或ドキュメント記録。
常見エラーと解決**
エラー1：SSHロックアウト**
症状：ファイアウォール有効化後、SSH切断、再ログイン不可。
原因：SSHポート未開放、或ルール順序誤（DROP後ACCEPT）。
予防：
- 設定前現SSHポート確認
- 先
ufw allow ssh、次ufw enable - 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 saveUFWはデフォルト永続化、追加処理不要。
エラー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.v6UFWは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 :223. ファイアウォールログ確認
# 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、高度フィルタリング向き
- 混用不可：1ツール統一管理選択、ルール冲突回避
設定原則**
- デフォルト拒否：全インバウンド拒否、必要ポートのみ開放
- 最小権限：各ルール範囲最小、源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時アラートSMS事件も減少可能。
完全Linuxファイアウォール設定流程
ゼロからUFW或iptablesファイアウォール設定、サーバーセキュリティ保護
⏱️ 目安時間: 30 分
- 1
ステップ1: デフォルトポリシー設定
デフォルト全インバウンド接続拒否、全アウトバウンド許可：
• UFW: `sudo ufw default deny incoming`と`sudo ufw default allow outgoing`
• iptables: `sudo iptables -P INPUT DROP`と`sudo iptables -P OUTPUT ACCEPT`
• これはセキュリティ設定の基石、必要ポートのみ開放確保 - 2
ステップ2: SSHポート開放
ファイアウォール設定前にSSH開放、ロックアウト回避：
• UFW: `sudo ufw allow ssh`或`sudo ufw allow 22/tcp`
• iptables: `sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT`
• カスタムポートは対応ポート変更記憶（例2222） - 3
ステップ3: サービスポート開放
ウェブサービスと他必要ポート開放：
• HTTP: `sudo ufw allow 80/tcp`或`sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT`
• HTTPS: `sudo ufw allow 443/tcp`或`sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT`
• 他サービスは必要開放、源IP制限試行 - 4
ステップ4: ファイアウォール有効化と検証
ファイアウォール有効化と状態確認：
• UFW: `sudo ufw enable`次`sudo ufw status verbose`
• iptables: ルール確認`sudo iptables -L -n -v --line-numbers`
• ルール正確且ファイアウォールactive状態確認 - 5
ステップ5: 永続化ルール保存
iptablesルールはデフォルト非永続化、再起動消失：
• Ubuntu/Debian: `sudo apt install iptables-persistent`次`sudo netfilter-persistent save`
• 手動保存: `sudo iptables-save > /etc/iptables/rules.v4`
• UFWはデフォルト永続化、追加操作不要
FAQ
UFWとiptablesは同時使用可能？
UFWとiptablesに性能差有？
ファイアウォール設定時ロックアウト対応？
• VPS/クラウドサーバー：プロバイダーConsole経由ログイン（SSHバイパス）
• 物理サーバー：本地ログイン
• 予防：設定前`ufw allow ssh`実行、次`ufw enable`；iptablesはSSHルールDROP前に確保
iptablesルール再起動後消失対応？
UFWのlimitコマンド意味？
何时iptables選択べき？
• NAT、ポートフォワーディング、負荷分散
• 複雑ルールチェーン、多層条件判断
• ゲートウェイ、ルータ、VPNサーバー
• 大規模展開（数十台サーバースクリプト管理）
• 高度フィルタリング（パケット内容、レート、時間）
他场景（VPS、Webサービス）UFW十分且より簡易。
ファイアウォール設定最適セキュリティ原則？
• デフォルト拒否（Default Deny）：全インバウンド拒否、必要ポートのみ開放
• 最小権限：各ルール範囲最小、源IP制限
• 多層防御：ファイアウォール + WAF + SELinux多重保護
• 定期監査：月次ルール検査、季度評価、年次重构
参考文献**
- 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
11 min read · 公開日: 2026年4月3日 · 更新日: 2026年4月5日
関連記事
n8n ワークフロー構築：ノード接続から自動化シナリオ設計まで
n8n ワークフロー構築：ノード接続から自動化シナリオ設計まで
GitHub Actions 入門：YAMLワークフロー基礎とトリガー設定
GitHub Actions 入門：YAMLワークフロー基礎とトリガー設定
Supabase データベース設計：テーブル構造、リレーションとRLS完全ガイド
コメント
GitHubアカウントでログインしてコメントできます