ssecutils
Network / Browser-native guide

ファイアウォールの基本

ステートレス、ステートフル、L7、WAF、クラウドのセキュリティグループまで整理します。

約7分Zero tracking reading surface

「ファイアウォール」と一言で済ませがちだけど

会社の PC にも、家庭ルーターにも、AWS のセキュリティグループにも「ファイアウォール」という言葉が出てきます。が、それぞれ守る範囲も動作原理も違うものです。

この記事では、ファイアウォールの 3 世代分類と、ホストベース vs ネットワークベース、現代のクラウド時代における意味を初学者向けに整理します。

第1世代: パケットフィルタ（ステートレス）

最も古典的なファイアウォール。パケットの IP / ポートを見て、許可/拒否を決めるだけのシンプルな仕組みです。

ルール例:
ALLOW src=any           dst=10.0.0.5  port=80    proto=TCP
ALLOW src=any           dst=10.0.0.5  port=443   proto=TCP
DENY  src=any           dst=10.0.0.5  port=any   proto=any

各パケットを単独で評価するため「ステートレス」と呼ばれます。Cisco ルーターの ACL（Access Control List）が代表例。

メリット：シンプル・高速・処理が軽い
デメリット：戻りパケットの扱いが不器用、TCP の状態を追えない

戻りパケット問題

例えば「内側から外への HTTP は許可」したい場合、ステートレスではどうやって戻りパケットを受け入れるかが難題です。「TCP ACK ビットが立っているもの」だけ許可する等のヒューリスティクスを使うのですが、攻撃者がこれを偽装することもできてしまいます。

第2世代: ステートフル インスペクション

各 TCP コネクションの状態を覚えておき、「これは内側から張った通信の戻りパケットだから OK」と判断できる仕組みが ステートフルファイアウォールです。

内側から外への新規接続を ALLOW
   ↓ 同時にルーターが「コネクションテーブル」に登録
   src=10.0.0.5:54321 → dst=example.com:443 (ESTABLISHED)

戻りパケットが届く
   ↓ コネクションテーブルにマッチ → 自動的に通す

現代の家庭ルーター・AWS Security Group・Linux iptables（の state モジュール）はすべてステートフルです。「アウトバウンドだけ許可していれば、レスポンスは自動で通る」のはこのおかげです。

第3世代: アプリケーション層ファイアウォール（次世代 FW / WAF）

IP/ポートだけでなく、HTTP の中身まで見て判断するファイアウォール。L7 で動くので、「URL パスごとの許可/拒否」「特定の SQL インジェクション攻撃文字列をブロック」のような細かい制御が可能です。

  • WAF（Web Application Firewall）: HTTP/HTTPS 専門。AWS WAF / Cloudflare WAF / ModSecurity
  • NGFW（Next-Generation Firewall）: アプリ識別 + IPS + アンチウイルスを統合。Palo Alto Networks / Fortinet 等
  • IDS / IPS: 侵入検知/防御。シグネチャベース（Snort、Suricata）

ホストベース vs ネットワークベース

ホストベースネットワークベース
導入場所各サーバー / PC 内ネットワーク境界の機器
例iptables / nftables / Windows Defender FWクラウドの SG、専用 FW アプライアンス
強み細かい個別制御一括管理、性能
弱み各台で個別運用が必要横移動（lateral movement）に弱い

実運用では両者を組み合わせて多層防御するのがセオリーです。

クラウド時代のファイアウォール

AWS / GCP / Azure では伝統的なファイアウォールアプライアンスは登場せず、代わりに論理的なセキュリティポリシーとして実装されています：

  • Security Group（AWS）: ENI 単位のステートフル FW。allow ルールのみ（deny は書けない）
  • Network ACL（AWS）: サブネット単位のステートレス FW。allow と deny 両方書ける
  • Firewall Rules（GCP）: VPC 全体に対するルール
  • NSG（Azure）: NIC / サブネット単位

これらをコード（Terraform / CloudFormation 等）で管理する Infrastructure as Code が標準になっています。

WAF が守るもの・守らないもの

WAF は「Web 層の攻撃」に特化しています：

WAF が得意

  • SQL インジェクションのシグネチャマッチ
  • XSS（Cross-Site Scripting）の検出
  • DDoS 緩和（レート制限）
  • OWASP Top 10 系の攻撃

WAF が苦手

  • ビジネスロジックの脆弱性（権限昇格・水平権限突破等）
  • 暗号化トラフィック内の精密な検査（TLS 終端が必要）
  • 0day 攻撃（シグネチャがない）

WAF は補助輪であり、アプリ自体のセキュリティ実装が本丸であることは忘れないでください。

「全許可」「全拒否」の哲学

ファイアウォールルールの設計には 2 つの基本姿勢があります：

  • デフォルト拒否（allow-list）: 必要なものだけ許可、それ以外は全部 deny。セキュリティの原則
  • デフォルト許可（deny-list）: 危険なもののみブロック。穴を見落としやすい

本番環境ではほぼ常にデフォルト拒否が正解です。「足りないものに気づく」運用負荷より、「気づかないうちに開いていた穴」のリスクの方が遥かに高いからです。

セキュリティグループ設計の例（AWS）

Web サーバー SG:
  Inbound:
    - HTTPS (443/TCP) from 0.0.0.0/0       # ユーザーのブラウザ
    - SSH (22/TCP) from 踏み台 SG          # 管理アクセスは踏み台経由のみ
  Outbound:
    - HTTPS (443/TCP) to 0.0.0.0/0          # 外部 API 呼び出し
    - PostgreSQL (5432/TCP) to DB SG

DB SG:
  Inbound:
    - PostgreSQL (5432/TCP) from Web SG    # Web サーバーからのみ
  Outbound:
    - 必要なものだけ

DB に直接インターネットから繋がせない、SSH は踏み台のみ、というレイヤ分離が定石です。

おわりに

ファイアウォールは「ルールを作る → 動かす」のは簡単ですが、「適切な粒度のルールを設計する」のが本当の難しさです。最小権限の原則、デフォルト拒否、レイヤごとの責務分離、を意識すると、長期運用でも穴が空きにくいルール体系を維持できます。

Learn の記事一覧へ戻る