Firewall は「事前に定義したルールに合致しない通信を遮断する」アクセス制御装置。5-tuple (src/dst IP・src/dst Port・Proto) の照合という素朴な基本動作から、Stateful → NGFW → クラウド SG / SASE まで進化を重ねてきた。本稿は 5 世代の進化軸・Stateful の中身・置き場所による分類・NGFW / WAF / クラウド SG・そして Zero Trust への遷移までを、現代の限界も含めて通しで扱う。
難しく見えても本質は次の 3 つだけ。(1) Firewall は 「事前に書いたルールに合わない通信を捨てる関所」。インターネットと社内の間に立ち、許可リストに無い通信を通さない。(2) 5 世代の進化があり、古い「ポートで判断」(Packet Filter) から、現代の「アプリ・ユーザ・コンテキストで判断」(NGFW / Zero Trust) へ。(3) Firewall 1 つに頼る時代は終わった — HTTPS の中身は見えない / 内部に侵入後の横移動は止められない / 装置自体に脆弱性が出る、ため EDR / WAF / ZTNA との多層防御が現代の標準。— ここを土台に各章を順に開いていけばいい。
Firewall とは — 5-tuple とポリシー #
ネットワーク Firewall の最も基本的な処理は次のループ。
Firewall は 「クラブの入口に立つ警備員」そのもの。お客 (パケット) が来るたびに 身分証 (送信元 IP / 行き先 / ポート / プロトコル) をチェックし、事前にもらった許可リスト (ACL) と照合して入れるかどうかを決める。「リストに無い客はとりあえず断る (default deny)」のが現代の正しい運用。逆に「とりあえず入れて、リストに載った客だけ追い出す (default allow)」は穴だらけになるので非推奨。「警備員 1 人で全部判断する」のは無理なので、後で見るように複数の警備員 (Host FW / WAF / クラウド SG) を組み合わせるのが現代の設計。
# 内部 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/24deny (= reject) は ICMP unreachable を返す、drop は何も返さずパケットを黙って捨てる。攻撃者の偵察を遅らせるため drop の方が好まれる (port の「閉」と「無応答」を区別させない)。
「何を許可するか」を白リストで書く default deny が現代の正しい設計。default allow は新しいプロトコルが出るたびに穴が空くため非推奨。
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 層が抜けても次の層で止める設計になっている。
Stateless vs Stateful — 中核概念 #
第 2 世代の Stateful Inspection が現代 Firewall の事実上の基準。Stateless はパケット単位で独立に評価し、過去の状態を持たない。Stateful は接続状態テーブルでセッションを追跡し、戻りパケットを自動許可する。
Stateless 警備員は記憶喪失で、お客が出入りするたびに毎回身分証を確認する。だから「内→外を許可するルール」と「戻りパケットを許可するルール」の両方を書かないといけない (= 戻り通信のために広く穴を開ける羽目になる)。Stateful 警備員は 「さっき出ていった客が戻ってきた」と覚えているので、内→外を 1 行書くだけで戻りは自動で通す。「ポート 443 への外向き通信を許可」だけ書けば、戻りの HTTP レスポンスも自動で通る — これが現代 Firewall のルール記述が直感的になった理由。
| Stateless | Stateful | |
|---|---|---|
| ルール記述 | 戻り (port >1024 等) も明示が必要 |
「内→外 443 許可」だけで OK |
| 攻撃面 | 戻り側を広く開ける → 応答偽装攻撃 | 追跡テーブルで応答偽装を阻止 |
| 状態 | なし | TCP/UDP の 5-tuple + state を保持 |
State Table には次のような行が並ぶ (Linux conntrack / Check Point):
| Src→Dst | Proto | State | TTL | Bytes |
|---|---|---|---|---|
10.0.0.5:48772 → 93.184.216.34:443 |
TCP | ESTABLISHED | 295s | 14.2 KB |
10.0.0.5:51123 → 8.8.8.8:53 |
UDP | ESTABLISHED (擬似) | 28s | 220 B |
| 戻りパケット | — | RELATED via parent | — | — |
State による判定:
- NEW — テーブルに無い新規。ACL で許可された場合のみテーブルに追加
- ESTABLISHED — 既存セッションの続き。テーブル参照で許可 (ACL 走査不要)
- RELATED — FTP データ転送のような付随接続。ALG helper が判定 (FTP/PPTP/IRC/H.323)
- INVALID — 不正なフラグ組合せ / テーブルと矛盾 — drop
テーブル容量は数十万〜数百万エントリ程度。SYN Flood 攻撃はテーブルを満杯にして正規接続を弾く Stateful の宿命的弱点。TTL が短すぎると正規セッションが切れ、長すぎると埋まる。容量管理が性能の鍵。
$ 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
# 大量同時接続でテーブル溢れが見られる場合
$ sudo sysctl -w net.netfilter.nf_conntrack_max=1048576置き場所と種類による分類 #
「Firewall」という言葉は現代では複数の異なる装置を指す。何を守るか / どこに置くか で大きく 4 系統:
| 系統 | 守る対象 | 代表 |
|---|---|---|
| Network Firewall (perimeter) | LAN 全体の境界 | Palo Alto / Fortinet / Check Point / Cisco ASA / pfSense |
| Host Firewall | 個々の OS | iptables/nftables (Linux), Windows Defender, macOS PF, ufw, firewalld |
| WAF | Web アプリの L7 | AWS WAF / Cloudflare / Akamai / F5 / ModSecurity |
| Cloud Firewall | クラウドリソース毎 | AWS Security Group / NACL, Azure NSG, GCP Firewall Rules |
これら 4 系統は競合しない、組み合わせて使う。AWS 上の Web 3 層アプリで言うと:
- AWS WAF — CloudFront / ALB 前段で L7 攻撃 (SQLi / XSS / Bot / Rate limit) を弾く
- Security Group — ALB は 80/443 のみ、App は ALB からのみ、DB は App からのみ、と instance ごとの最小許可
- NACL — VPC サブネット境界の broad 制御 (Stateless、SG の補助)
- Host Firewall — EC2 内の OS レベルで
nftablesで更に絞る (defense in depth)
「1 つの Firewall に全てを期待しない」のが現代の設計。各層で役割を切り分けることで、1 層がミス設定でも他層が守る。
NAT との関係 — Firewall とよく混同される #
家庭の Wi-Fi ルータが「Firewall も内蔵」とよく言われるが、これは正確には NAT (Network Address Translation) が偶然 Firewall として機能している だけ。NAT と Firewall は本来別の機能。
家庭の Wi-Fi ルータが「外から守ってくれている」と感じるが、実はそれは NAT (= マンションの管理人) が「外から来た知らない客に取次先が分からない」から偶然守っているだけ。本物の Firewall (= 警備員) は別の仕事。NAT が無くなる IPv6 時代では、この「偶然の防御」が消えるので、明示的に Firewall ルールを書く必要がある。家庭用ルータでもポートフォワーディングや UPnP で穴が開くと、NAT は防御として完全に無力になる、という点だけ覚えておくと混乱しない。
| NAT | Firewall | |
|---|---|---|
| 目的 | IP アドレス変換 (内部 private → 外部 global) | アクセス制御 |
| 動作 | 送信元・送信先 IP/Port を書き換える | 通す / 通さない判定 |
| 副作用 | 外→内の unsolicited 接続は変換先が決まらず到達不能 | (副作用なし、純粋なフィルタ) |
NAT は「内→外」の接続から自動でマッピングを作るため、外→内の unsolicited 接続はマッピングが存在せず到達できない。これが「NAT のお陰で偶然守られている」現象。
NAT は Firewall ではない。ポートフォワーディングを設定すれば穴が開き、UPnP / NAT-PMP が有効だとアプリが勝手にマッピングを作る (一部 IoT カメラ / ゲーム機)。IPv6 では NAT を使わないのが基本のため、明示的な Firewall ルールが必須になる。IPv6 時代の家庭ルータは NAT に頼らず Firewall を有効にするのが標準ガイダンス。
NGFW — L7 で何ができるか #
NGFW (Next Generation Firewall) は 2007 年頃 Palo Alto Networks が市場を作った概念で、Stateful + DPI + IPS + Application ID + URL Filtering + User ID + SSL Inspection を統合した装置。「ポート 443 で何が来ているか」を中身を見て判別できることが特徴。
| 従来 Stateful | NGFW | |
|---|---|---|
| 判断軸 | IP / Port / Proto | + アプリ (Skype/Zoom/Dropbox/SSH) / ユーザ (AD ID) / カテゴリ (SNS/ニュース) / 脅威 (シグネチャ) |
| HTTPS | 中身は見えない (ヘッダのみ) | SSL 復号で中身を見る (= MITM 構成) |
| 典型ルール | 「10.0.0.0/24 → any:443 許可」 | 「営業部 → Salesforce のみ許可、Dropbox は拒否、Twitter は読み取り専用」 |
SSL Inspection (= SSL/TLS 復号) は NGFW の最大の論点:
- 企業 CA 証明書を端末にインストール → NGFW が中継して復号 → スキャン → 再暗号化
- ○ L7 攻撃検知 / DLP (Data Loss Prevention) が実現できる
- × プライバシー (社員の HTTPS 通信を企業が読める)
- × 一部サイトが Certificate Pinning で復号失敗 (銀行アプリ / Google 一部)
- × 性能ペナルティ (10 Gbps 級でも復号は重い)
アプリ ID シグネチャの更新に依存 (新アプリ / バージョン / トラフィック偽装で識別が破られる)、ルール肥大化 (アプリ × ユーザ × カテゴリの組合せで数千ルール)、誤検知での業務影響 (SaaS のアップデートで突然弾かれる) が日常的な問題。
WAF — L7 専用の Firewall #
WAF (Web Application Firewall) は Web アプリケーション (HTTP/HTTPS) 専用の L7 Firewall。NGFW より深く・狭く Web に特化し、SQLi / XSS / CSRF / コマンドインジェクション / Path Traversal / Bot / Rate limit などを HTTP リクエストレベルで検査する。
通常の Firewall は 「誰が来たか (IP / ポート)」を見るが、WAF は 「客が何を注文したか (HTTP の中身)」を読んで判断する Web サイト専門の用心棒。SQL インジェクションのような 「お客が悪意のあるリクエストを書いてくる」攻撃を Firewall は通してしまうが、WAF は中身を読んで弾く。個人サイトでも Cloudflare の無料プランを前段に置けば基本的な WAF が無料で付く。ただし 「WAF があるから SQL 対策はしなくていい」は危険 — アプリ側でも必ずプリペアドステートメントを使う、というのが正しい多層防御。
典型構成は [インターネット] → [CDN/WAF] → [ALB] → [Web] → [App] → [DB]。
OWASP CRS (Core Rule Set) がデファクトのルール集で、OWASP Top 10 の大半を 1 セットでカバーできる。
| 攻撃 | WAF で防げる? |
|---|---|
SQL Injection (古典的 ' OR 1=1) |
◎ 既知パターン |
XSS (古典的 <script>) |
◎ 既知パターン |
| CSRF | △ Origin / Referer 検査くらいまで |
| ロジック不備 (例: price 改ざん) | × アプリしか知らない |
| 認証/認可バグ | × 同上 |
| ゼロデイ | × シグネチャに無い |
| Bot / Credential Stuffing | ○ Rate limit / Bot 検知 |
| L7 DDoS | ○ Rate limit / CAPTCHA |
主要 WAF: AWS WAF / Cloudflare / Akamai / Fastly (クラウド型)、F5 BIG-IP ASM / Imperva (オンプレ)、ModSecurity (OSS, Apache/Nginx モジュール)。
「WAF があるから SQLi 対策はしなくていい」は危険。プリペアドステートメント + ORM + 入力検証が一次対策、WAF はあくまで多層防御の最後の砦。
クラウド時代の Firewall — SG / NACL / SASE #
クラウド (AWS / Azure / GCP) では Firewall の概念が大きく変質した。「IP 境界」ではなく「リソース単位」「Identity 単位」で制御する。
AWS の場合:
| 機能 | 種類 | 動作 |
|---|---|---|
| Security Group (SG) | Stateful, instance / ENI 単位 | デフォルト deny / 許可ルールだけ書く / 戻りは自動 |
| NACL | Stateless, subnet 単位 | 番号順評価 / allow と deny を明示 / 戻りは別ルール |
| AWS WAF | L7, CloudFront/ALB/API GW 前 | OWASP / 独自シグネチャ |
| AWS Network Firewall | Stateful + DPI, VPC ゲートウェイ | 商用 NGFW 相当 (Suricata ベース) |
Security Group の特徴は 「SG から SG を許可」 が書けること。IP CIDR ではなく他の SG ID を source に書ける → インスタンスがスケールしても自動で IP が更新される。
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 の本質で、コロナ以降のリモートワークで一気に採用が進んだ。
なぜ Firewall だけでは守れなくなったのか #
「Firewall だけでは大半の侵害を防げない」が業界の共通認識。Verizon DBIR / Mandiant M-Trends でも、Firewall を通り抜けた攻撃が侵害の主流。
Firewall は 「家の玄関の鍵」で、これだけで家を完全に守れる訳ではない。(1) 玄関を開けて入った人 (= 正規ログインで侵入された場合) には無力。(2) 鍵がかかっていても 窓 (HTTPS) から覗かれた中身は見えない。(3) 玄関の鍵自体が壊れる (Firewall 装置の脆弱性 — Fortinet / Ivanti 0day 連発) こともある。だから現代の防御は 「玄関の鍵 (Firewall) + 室内の警報装置 (EDR) + 金庫 (バックアップ) + 各部屋ごとの鍵 (マイクロセグメンテーション)」の多層構成が必須、と覚えればよい。
Firewall が無力な攻撃パターン:
- HTTPS の中で来るマルウェア / フィッシング / Dropper PDF (L4 Firewall は見えない、NGFW でも SSL 復号しないと見えない)
- 正規認証情報を使った侵入 (Phishing で奪った credential / Initial Access Broker から購入) → Firewall は正規通信として通す
- 内部の横移動 — 一度侵入すれば AD / SSH / RDP / SMB は内部 Firewall が薄いほど自由
- サプライチェーン攻撃 — SolarWinds 等、正規ソフトのアップデート経由 → Firewall は信頼済通信
- SaaS 経由のデータ流出 — 内部 → SaaS は許可されているので止めない
| 従来 (Perimeter) | Zero Trust | |
|---|---|---|
| 信頼の前提 | 内側 LAN は信頼、外側は不信 | 何も信頼しない (Never Trust, Always Verify) |
| 境界 | 物理ネットワーク境界 | Identity / Device / Context が境界 |
| アクセス判定 | IP / Port | + ユーザ / デバイス姿勢 / 時間 / 場所 / 行動 |
| 横移動 | 内部は緩い → 容易 | マイクロセグメンテーションで 1 リソース毎に検査 |
Zero Trust の中で Firewall はどう変わったか:
- 境界 Firewall は引き続き必要 (基本のフィルタ)、ただし「ここを通れば信頼」ではなくなった
- ZTNA (Zero Trust Network Access) が VPN を置き換え始めた — 「VPN で社内に入る」ではなく「個別アプリ毎に Identity 確認して直接接続」
- micro-segmentation で内部も Firewall まみれに (VM / コンテナ / Pod 単位でルール)
- Service Mesh (Istio / Linkerd) が「マイクロサービス間の Firewall」として機能 (mTLS + 認可ポリシー)
現代の優れた防御は Firewall + EDR + SIEM + ZTNA + WAF + DLP + IAM の組合せ。Firewall は「重要だが 1 層に過ぎない」位置付け。
代表的な事件 — Firewall の限界が露呈したケース #
| 年 | 事件 | Firewall 観点の教訓 |
|---|---|---|
| 2010 | Stuxnet (ICS) | エアギャップされたイラン濃縮施設に USB 経由で侵入 → Firewall 無関係。物理層信頼前提が崩壊 |
| 2013 | Target (4000 万件) | HVAC ベンダー経由で侵入後、内部 Firewall が薄く POS まで横移動可能。境界は機能していた |
| 2017 | Equifax (1.4 億件) | 公開 Web の Struts 脆弱性で侵入 → WAF が期限切れ証明書で動作不全 |
| 2017 | NotPetya | 会計ソフト経由のサプライチェーン (M.E.Doc) → 正規ソフト通信として通過 → EternalBlue で SMB 横移動 |
| 2020 | SolarWinds Orion | 正規アップデートにバックドア → C2 は HTTPS で正規 CDN 通過 |
| 2021 | Colonial Pipeline | 使われていない VPN アカウントから侵入 → Firewall は「正規 VPN 接続」として通した |
| 2024 | Fortinet / Ivanti / Check Point 0day 連発 | Firewall 装置自体の脆弱性 — 守るはずの装置が踏み台になる事例が増加 |
共通パターン: 「Firewall が無いから侵害された」のではなく、「Firewall を通る正規通信に紛れて侵入された」「Firewall の内側を緩めに作っていた」「Firewall 装置自体が攻撃された」。境界 Firewall を維持することは依然必須だが、それだけに頼る発想が古い。
防御 — Firewall を活かす現代的な設計 #
Firewall を有効に保つための実務的なポイント:
| 設計 | 内容 |
|---|---|
| Default deny | 全レイヤ (perimeter / SG / host) で「明示許可以外は拒否」 |
| 最小権限 | SG / NSG ルールは「from any → all ports」ではなく必要最小に絞る |
| マイクロセグメンテーション | 内部も平坦な LAN にせず、サービス / Tier 毎に Firewall 境界を引く |
| NGFW の SSL Inspection | 可能な範囲で復号して L7 検査 (法務・労務面と協議) |
| WAF + OWASP CRS | 公開 Web には必ず WAF を前段で。CRS を最新に保つ |
| ルール棚卸し | 半年〜年次で「使われていないルール」を削除 (hit-count 機能を使う) |
| ベンダー脆弱性 | Firewall 装置自体の KEV を即パッチ。EoL モデルは即交換 |
| Log + SIEM | deny / allow ログを SIEM (Splunk / Sumo / Elastic) に流して異常通信を検知 |
| ZTNA / SASE 検討 | VPN を置き換え、リモート時代に合った Firewall モデルへ |
$ 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 acceptFirewall は「ルールに合致しない通信を遮断する」基本動作のまま、Packet Filter → Stateful → Application Proxy → NGFW → Cloud/Zero Trust と 見る階層を上げてきた歴史を持つ。Host Firewall / WAF / Cloud SG / Service Mesh の各層が同時に Firewall として機能しているのが現代のシステムで、Defense in Depth で多層に組み合わせるのが基本設計。Firewall だけで守れない時代に入った今、Zero Trust の発想 (内側を信頼しない / Identity と Device 姿勢で判定 / マイクロセグメンテーションで横移動を止める) に移行することが Firewall を活かす唯一の道筋になる。
