Firewall (ファイアウォール) #

Firewall (ファイアウォール) は 「事前に定義したルール (policy) に合致しない通信を遮断する」アクセス制御装置。最も基本的な動作は 「パケットの 5-tuple (送信元 IP / 送信先 IP / 送信元 Port / 送信先 Port / Protocol) を見て、allow / deny / drop のいずれかを決める」 こと。

1988 年に DEC (Digital Equipment Corporation) が SEAL という世界初の商用 Firewall を出荷して以降、1990 年代に企業 LAN とインターネットの境界の標準装備となり、現代のあらゆるネットワーク・セキュリティ製品の土台になっている。Stateful Inspection (1990 年代の Check Point 特許)、NGFW (Next Generation Firewall、2000 年代後半)、WAF (Web Application Firewall、2000 年代以降)、クラウド時代の Security Group / NACL (2010 年代) と進化を重ねたが、「ルールにマッチしない通信を遮断する」という基本動作は今も変わっていない。

本稿は Firewall を「型・歴史・限界」の 3 軸で整理する — 5 世代の進化 (SVG 1) / Stateful Inspection の中身 (SVG 2) / 置き場所による分類 (Network / Host / WAF / Cloud SG) / NAT との混同 / NGFW と WAF / クラウド時代の Firewall / そして「Firewall だけでは守れなくなった」現代と Zero Trust への遷移 までを扱う。「ルータ・スイッチに次いで世界で最も普及したネットワーク装置」が今どこで限界に直面しているかが本稿の主題。

1. Firewall とは — 5-tuple とポリシー #

ネットワーク Firewall の最も基本的な処理は次のループ:

1. パケットを受信する (NIC レベル)
2. 5-tuple を抽出する — 送信元 IP / 送信先 IP / 送信元 Port / 送信先 Port / Protocol (TCP/UDP/ICMP 等)
3. ルールリスト (ACL = Access Control List) を上から順に照合
4. 最初にマッチしたルールの action (allow / deny / drop / log) を実行
5. どのルールにもマッチしなければ default policy (通常は deny)

ルールの典型例:

# 内部 LAN から外部 Web (HTTPS) は許可
allow from 10.0.0.0/24 to any port 443 proto tcp

# 外部から DMZ 内 Web サーバ (port 80, 443) は許可
allow from any to 203.0.113.10 port {80,443} proto tcp

# それ以外の外部→内部は全部破棄
deny from any to 10.0.0.0/24

deny と drop の違い: deny (= reject) は ICMP unreachable を返す、drop は何も返さない (パケットを黙って捨てる)。攻撃者の偵察を遅らせるために drop の方が好まれる傾向 (port が「閉じている」と「無応答」を区別させない)。

「何を許可するか」を白リストで書く (default deny) のが現代の正しい設計。「何を拒否するか」を黒リストで書く (default allow) は新しいプロトコル / アプリケーションが出るたびに穴が空くため非推奨。

2. 5 世代の進化 — 何ができるようになってきたか #

Firewall の歴史は 「より上位の階層を見る能力」 を獲得してきた歴史。Packet Filter → Stateful → Application Proxy → NGFW → Cloud/Zero Trust の 5 段階で整理できる:

重要なのは 「新しい世代が古い世代を置き換えた」のではなく、現代のシステムは複数世代を同時に層として重ねること:

• 境界: NGFW (4 世代目)
• DMZ 内 Web サーバ前: WAF (5 世代目の L7 専用版)
• 各 EC2 / VM: クラウド SG (5 世代目)
• OS 内部: Host Firewall (1-2 世代目の踏襲)
• コンテナ間: Network Policy / Service Mesh (5 世代目)

Defense in Depth の思想で、1 層が抜けても次の層で止める設計になっている。

3. Stateless vs Stateful — 中核概念 #

第 2 世代の Stateful Inspection が現代 Firewall の事実上の基準。Stateless と Stateful の違いを一枚で見る:

Stateful Inspection の本質的な強み:

• 「内側からの自発的な接続」とその戻りだけを許可 — 外側からの新規接続は default で deny
• 応答パケット偽装 (例: 攻撃者が偽の TCP ACK を送って外→内に入る) を防げる
• ルール記述が直感的になる — 「許可したい片方向だけ書く」で済む

State Table の制約:

• テーブル容量 は数十万〜数百万エントリ程度。膨大な接続数を受ける Firewall ではテーブル溢れが性能ボトルネック
• TTL が短すぎると正規セッションが切れ、長すぎるとテーブルが埋まる
• SYN Flood 攻撃 は テーブルを満杯にして正規接続を弾く ことを狙う (Stateful の宿命的弱点)
• UDP のような stateless プロトコルにも擬似 state を持たせる (5-tuple + 一定 TTL でセッションを模倣)

Linux で実物を見る: conntrack テーブルが iptables/nftables Stateful の実装。

# 現在の接続テーブル
sudo conntrack -L
# tcp 6 431999 ESTABLISHED src=10.0.0.5 dst=93.184.216.34 sport=48772 dport=443 ...

# テーブル容量上限と現在使用数
sudo sysctl net.netfilter.nf_conntrack_max
cat /proc/sys/net/netfilter/nf_conntrack_count

# DDoS / 大量同時接続でテーブル溢れが見られる場合
sudo sysctl -w net.netfilter.nf_conntrack_max=1048576

4. 置き場所と種類による分類 #

「Firewall」という言葉は現代では複数の異なる装置を指している。何を守るか / どこに置くか で大きく 4 系統:

これら 4 系統は競合しない、組み合わせて使うもの。例えば AWS 上の Web 3 層アプリでは:

• AWS WAF: CloudFront / ALB の前段で L7 攻撃 (SQLi / XSS / Bot / Rate limit) を弾く
• Security Group: ALB は port 80/443 のみ、App は ALB からのみ、DB は App からのみ、と instance ごとの最小許可
• NACL: VPC サブネット境界の broad 制御 (Stateless、SG の補助)
• Host Firewall: EC2 内の OS レベルで nftables で更に絞る (defense in depth)

「1 つの Firewall に全てを期待しない」のが現代の設計。各層で役割を切り分けることで、1 層がミス設定でも他層が守る。

5. NAT との関係 — Firewall とよく混同される #

家庭の Wi-Fi ルータが「Firewall も内蔵」 とよく言われるが、これは正確には NAT (Network Address Translation) が偶然 Firewall として機能しているだけ。NAT と Firewall は本来別の機能:

NAT は「内→外」の接続から自動でマッピングを作る ため、外→内の unsolicited 接続はマッピングが存在せず到達できない。これが**「NAT のお陰で偶然守られている」現象**。

しかし NAT は Firewall ではない ので:

• ポートフォワーディングを設定すれば穴が開く (= 多くの家庭ルータの設定ミスがここ)
• UPnP / NAT-PMP が有効だとアプリが勝手にマッピングを作る (例: 一部 IoT カメラ / ゲーム機)
• IPv6 では NAT を使わない のが基本 — IPv6 移行で 「NAT の偶然の防御」が無くなるので明示的な Firewall ルールが必須になる

IPv6 時代の家庭ルータは NAT に頼らず明示的な Firewall を有効にする ことが、現代の標準ガイダンス。

6. NGFW (Next Generation Firewall) — L7 で何ができるか #

NGFW は 2007 年頃 Palo Alto Networks が市場を作った概念で、Stateful Firewall + DPI (Deep Packet Inspection) + IPS + Application ID + URL Filtering + User ID + SSL Inspection を統合した装置。「ポート 443 で何が来ているか」を中身を見て判別できることが特徴。

従来 Firewall との違い:

SSL Inspection (= SSL/TLS 復号) は NGFW の最大の論点:

• 企業の CA 証明書を端末にインストール → NGFW が中継して復号 → スキャン → 再暗号化
• ○ L7 攻撃や DLP (Data Loss Prevention) が実現できる
• × プライバシー (社員の HTTPS 通信を企業が読める)
• × 一部サイトが Certificate Pinning で復号失敗 (銀行アプリ / Google サービスの一部)
• × 性能ペナルティ (10 Gbps 級ハードウェアでも復号は重い)

運用面の壁:

• アプリ ID シグネチャの更新 に依存する (新しいアプリ / バージョン / トラフィック偽装で識別が破られる)
• ルール肥大化 — 「アプリ × ユーザ × カテゴリ」の組合せで数千ルールになりがち
• 誤検知 で業務影響 (例: SaaS のアップデートで突然弾かれる)

7. WAF (Web Application Firewall) — L7 専用の Firewall #

WAF は Web アプリケーション (HTTP/HTTPS) 専用の L7 Firewall。NGFW より深く・狭く Web に特化し、SQLi / XSS / CSRF / コマンドインジェクション / Path Traversal / Bot / Rate limit などを HTTP リクエストレベルで検査する。

典型的な構成:

[インターネット] → [CDN/WAF] → [ALB/Load Balancer] → [Web Server] → [App Server] → [DB]

OWASP CRS (Core Rule Set) がデファクト・スタンダードのルール集で、OWASP Top 10 の大半を 1 セットでカバーできる。

主要 WAF:

• AWS WAF / Cloudflare / Akamai / Fastly — クラウド型 (= Web の前段に置く)
• F5 BIG-IP ASM / Imperva — オンプレ型アプライアンス
• ModSecurity (OSS) — Apache / Nginx モジュール、CRS と組合せ

WAF が防げるもの・防げないもの:

WAF は「アプリの実装バグの代わりにはならない」 — あくまで多層防御の 1 層。「WAF があるから SQLi 対策はしなくていい」は危険で、プリペアドステートメント + ORM + 入力検証が一次対策、WAF は最後の砦。

8. クラウド時代の Firewall — Security Group / NACL / SASE #

クラウド (AWS / Azure / GCP) では Firewall の概念が大きく変質した。**「IP 境界」ではなく「リソース単位」「Identity 単位」**で制御する:

AWS の場合:

Security Group の特徴的な点:

• 「SG から SG を許可」 — IP CIDR ではなく 他の SG ID を source に書ける。これによりインスタンスがスケールしても自動で IP が更新される
• デフォルト deny / outbound default allow (アウトバウンド絞りは別途設定)
• ステートフル — 戻りは自動

# Terraform 例: ALB が App を呼ぶ
resource "aws_security_group_rule" "app_from_alb" {
  type                     = "ingress"
  from_port                = 8080
  to_port                  = 8080
  protocol                 = "tcp"
  source_security_group_id = aws_security_group.alb.id  # IP ではなく SG ID
  security_group_id        = aws_security_group.app.id
}

SASE (Secure Access Service Edge) — 2019 年 Gartner が提唱した概念で、Firewall / VPN / SWG (Secure Web Gateway) / CASB / ZTNA をクラウド側で統合するモデル。Cloudflare One / Zscaler / Netskope / Palo Alto Prisma が主要プレイヤー。

従来 (Hub & Spoke):

従業員 → 拠点 → 本社 Firewall → 各 SaaS

SASE モデル:

従業員 → クラウド POP (Firewall+SWG+ZTNA) → 各 SaaS / 本社

「ユーザがどこにいても同じ Firewall ポリシーが適用される」のが SASE の本質で、コロナ以降のリモートワークで一気に採用が進んだ。

9. なぜ Firewall だけでは守れなくなったのか — Zero Trust への遷移 #

現代の現実は 「Firewall だけでは大半の侵害を防げない」 ことが業界の共通認識。Verizon DBIR / Mandiant M-Trends の報告でも、Firewall を通り抜けた攻撃が侵害の主流:

Firewall が無力な攻撃パターン:

• HTTPS の中で来るマルウェア / フィッシング / DropperPDF (= L4 Firewall は見えない、NGFW でも SSL 復号しないと見えない)
• 正規の認証情報を使った侵入 (Phishing で奪った credential / Initial Access Broker から購入) → Firewall は正規通信として通す
• 内部での横移動 (= 一度侵入すれば、AD / SSH / RDP / SMB は内部 Firewall が薄いほど自由)
• サプライチェーン攻撃 (= SolarWinds 等、正規ソフトのアップデート経由) → Firewall は信頼済通信
• SaaS 経由のデータ流出 (= 内部 → SaaS は許可されているので Firewall は止めない)

ファイアウォール「以後」の侵害が中心になった結果、業界は Zero Trust へ移行している:

Zero Trust の中で Firewall はどう変わったか:

• 境界 Firewall は引き続き必要 (= 基本のフィルタ)、ただし「ここを通れば信頼」ではなくなった
• ZTNA (Zero Trust Network Access) が VPN を置き換え始めた — 「VPN で社内に入る」ではなく「個別アプリ毎に Identity 確認して直接接続」
• micro-segmentation で内部も Firewall まみれに — VM / コンテナ / Pod 単位で Firewall ルール
• Service Mesh (Istio / Linkerd) が 「マイクロサービス間の Firewall」 として機能 (mTLS + 認可ポリシー)

現代の優れた防御は「Firewall + EDR + SIEM + ZTNA + WAF + DLP + IAM の組合せ」で、Firewall は「重要だが 1 層に過ぎない」 という位置付け。

10. 代表的な事件 — Firewall の限界が露呈したケース #

共通パターン: 「Firewall が無いから侵害された」のではなく、「Firewall を通る正規通信に紛れて侵入された」「Firewall の内側を緩めに作っていた」「Firewall 装置自体が攻撃された」。境界の Firewall を維持することは依然必須だが、それだけに頼る発想が古い。

11. 防御 — Firewall を活かす現代的な設計 #

Firewall を有効に保つための実務的なポイント:

# Linux nftables での最小ファイアウォール (内→外/戻り/ssh のみ許可)
sudo nft add table inet filter
sudo nft add chain inet filter input '{ type filter hook input priority 0 ; policy drop ; }'
sudo nft add chain inet filter forward '{ type filter hook forward priority 0 ; policy drop ; }'
sudo nft add chain inet filter output '{ type filter hook output priority 0 ; policy accept ; }'
sudo nft add rule inet filter input ct state established,related accept
sudo nft add rule inet filter input iifname "lo" accept
sudo nft add rule inet filter input tcp dport 22 accept

Firewall は 「ルールに合致しない通信を遮断する」アクセス制御装置 という基本は変わらないまま、Packet Filter → Stateful → Application Proxy → NGFW → Cloud/Zero Trust と 「見る階層」を上げてきた歴史を持つ。Stateful Inspection (1990) が現代の事実上の基準で、その上に L7 アプリ識別 (NGFW) / Web 専用 (WAF) / クラウド SG / SASE が積み上がっている。

「Firewall = ネットワーク境界の装置」という古典的理解はもう不十分で、Host Firewall / WAF / Cloud SG / Service Mesh の各層が同時に Firewall として機能しているのが現代のシステム。Defense in Depth で多層に組み合わせるのが基本設計。

そして Firewall だけでは守れない 時代に確実に入った — HTTPS 内の攻撃、正規認証情報の悪用、サプライチェーン、内部横移動、Firewall 装置自体の脆弱性 が現実の主流。Zero Trust の発想で 「内側を信頼しない / Identity と Device 姿勢で判定する / マイクロセグメンテーションで横移動を止める」設計に移行することが、Firewall を活かす唯一の道筋になっている。