OpenGFW 実践ユースケース

OpenGFW は、Linux 上で動く L7 までトラフィックを解析できるオープンソースのパケットフィルタ です。Netfilter で捕捉したパケットを DPI (Deep Packet Inspection) にかけ、HTTP / TLS SNI / DNS / QUIC / SSH / WireGuard などのプロトコルを識別、YAML ルールに基づいて allow / block / log 等のアクションを選択できます。

本記事では、自身が管理するネットワーク に対して OpenGFW を適用する代表的な 3 ユースケースを解説します。

⚠ 倫理と合法性: OpenGFW は dual-use ツールです。本記事のユースケースはすべて「自身が管理するネットワーク」または「明示的同意を得たネットワーク」での利用を前提としています。業務ネットワークに適用する場合は就業規則への明記、通信の秘密に関する法令への準拠を確認してください。第三者ネットワークへの検閲・監視目的での使用は想定していません。

基本情報

全体像

デプロイメントコンテキスト (ゲートウェイが置かれる環境) が 3 つに分かれ、どのコンテキストでも OpenGFW エンジンは同じ 4 層構成 (capture → analyze → match → act) で動きます。差分は ルール YAML に凝縮されます。

前提: OpenGFW が「見えるもの」と「見えないもの」

OpenGFW は SSL/TLS を復号せず、平文の情報 + TLS ハンドシェイクのメタデータ までで判断します。したがって:

検知できる

• HTTP の URL・ヘッダ
• TLS の SNI (接続先ホスト名) · ALPN
• DNS クエリ内容 (非 DoH)
• QUIC の SNI (TLS ハンドシェイクが露出する部分)
• WireGuard・OpenVPN のプロトコル特徴
• BitTorrent · SSH · SOCKS5 等の署名ベース判定

検知が難しい / できない

• 中身を見ないと分からないコンテンツ (TLS で暗号化された本文)
• DoH (DNS over HTTPS) 内の DNS クエリ本体
• 強く難読化された VPN (Tor obfs4 等)
• アプリケーション層での End-to-End 暗号化内容

SNI・ALPN レベルで「どのサービスに通信しているか」までは分かるが、「そのサービスで何をしているか」までは分からない、と理解しておくと期待値が合います。

ユースケース 1: 社内 egress ポリシー適用

シナリオ

拠点ネットワークの egress 経路上に Linux ゲートウェイを置き、OpenGFW で以下のトラフィックを遮断する。

• 暗号通貨マイニング: Stratum プロトコル経由の通信
• BitTorrent: 業務外の P2P トラフィック
• 未承認 SaaS (shadow IT): 情報システム部が許可していないクラウドストレージ

ルール例 (YAML)

 1rules:
 2  - name: block-bittorrent
 3    action: block
 4    expr: bittorrent != nil
 5
 6  - name: block-stratum-mining
 7    action: block
 8    expr: 'tcp != nil && string(tcp.payload[0:7]) == "stratum"'
 9
10  - name: block-unapproved-saas
11    action: block
12    expr: >
13      tls != nil &&
14      tls.req != nil &&
15      tls.req.sni in [
16        "pastebin.com",
17        "transfer.sh",
18        "anon-example-storage.net"
19      ]      
20
21  - name: log-everything
22    action: log
23    expr: 'true'

落とし穴

• 誤検知の洗い出し: 本番ルールを即 block にすると業務影響が出ます。最初の 1〜2 週間は全ルールを log モードで走らせ、Grafana (後述の UC3 で紹介) で誤検知率を見ながら段階的に block へ切り替えるのが安全です。
• QUIC/HTTP3 の普及: Chrome の QUIC が盛んに流れるネットワークでは、「TLS SNI」単独ではなく QUIC の SNI も見る必要があります。OpenGFW は QUIC analyzer を持っていますが、設定で有効化を忘れがち。
• SSL inspection はしない方針: TLS 内部を復号したい要件があるなら、OpenGFW ではなく MITM プロキシ (mitmproxy・Squid + Bump) が必要です。OpenGFW は「SNI / ALPN レベル止まり」と割り切る。

ユースケース 2: 教育機関のアプリケーション制限

シナリオ

大学・学校の学内 Wi-Fi で、授業時間帯 (平日 9:00–16:00) のみ、ゲーム / ストリーミング / SNS の一部を制限する。昼休みと放課後は制限解除。

ルール例

OpenGFW 単体には「時間帯条件」が無いため、ホスト側で systemd の timer から 2 つのルールファイルをローテートする運用が現実的です。

 1# daytime-rules.yaml (授業時間に適用)
 2rules:
 3  - name: block-games
 4    action: block
 5    expr: >
 6      tls != nil && tls.req != nil && tls.req.sni in [
 7        "steamcommunity.com",
 8        "api.pubg.com",
 9        "live.leagueoflegends.com"
10      ]      
11
12  - name: block-video-streaming
13    action: block
14    expr: >
15      tls != nil && tls.req != nil && (
16        tls.req.sni endsWith ".youtube.com" ||
17        tls.req.sni endsWith ".netflix.com"
18      )      

 1# /etc/systemd/system/opengfw-schedule.service (抜粋)
 2ExecStart=/usr/local/bin/opengfw-schedule.sh
 3
 4# opengfw-schedule.sh
 5#!/bin/bash
 6hour=$(date +%H)
 7dow=$(date +%u)   # 1=Mon .. 7=Sun
 8
 9if [[ $dow -le 5 && $hour -ge 9 && $hour -lt 16 ]]; then
10  ln -sf /etc/opengfw/daytime-rules.yaml /etc/opengfw/active.yaml
11else
12  ln -sf /etc/opengfw/offtime-rules.yaml /etc/opengfw/active.yaml
13fi
14systemctl reload opengfw

落とし穴

• VPN による回避: 学生が WireGuard / OpenVPN / Shadowsocks で回避する可能性があります。VPN プロトコル自体を block するかは組織のポリシー次第 (研究用途で VPN が必要な場合もある)。
• プライバシー配慮: ログに過度に個人を特定できる情報を残さない。IP アドレスは残すが、HTTP ヘッダの全文保存等は避ける。保管期間ポリシーも事前に決める。
• DNS over HTTPS の普及: Firefox の DoH デフォルト ON により、DNS レベルでのフィルタリングが効かなくなっています。SNI ベースの判定に寄せる必要があります。

ユースケース 3: セキュリティリサーチ / 分類精度評価

シナリオ

ネットワークセキュリティの研究室やラボ環境で、以下を実施する。

• 新しい QUIC パーサー実装の分類精度・誤検知率を実トラフィックで計測
• IDS/IPS 向けの新シグネチャの性能評価
• 大学院のネットワーク授業で、プロトコル識別の仕組みをハンズオンで体験させる

ルール例

実環境では 何も block せず、全部 log して観察 することで、ラベル付きデータセットを生成します。

 1rules:
 2  - name: observe-quic
 3    action: log
 4    expr: quic != nil
 5
 6  - name: observe-wireguard
 7    action: log
 8    expr: wireguard != nil
 9
10  - name: observe-tls-sni-sample
11    action: log
12    expr: 'tls != nil && tls.req != nil'

連携: InfluxDB で可視化

OpenGFW の log 出力は構造化できます。syslog や fluent-bit を介して InfluxDB に書き込み、Grafana で「protocol 別の分類件数・経時変化」をダッシュボード化すると、研究用途でも実運用用途でも非常に便利です。

InfluxDB 側のデータモデル (抜粋):

1measurement: opengfw_event
2tags:
3  protocol  = "quic" | "tls" | "wireguard" | ...
4  action    = "allow" | "block" | "log"
5  rule      = "observe-quic"
6fields:
7  sni       = "example.com"
8  bytes     = 1420

→ 詳しくは InfluxDB 実践ユースケース の「アプリケーションのビジネスメトリクス」セクションと同じパターンで書けます。

落とし穴

• データ保護: 研究用途でも学生・教職員の通信内容が含まれるため、倫理審査 (IRB) に通してからキャプチャすること。SNI は PII に当たり得るので匿名化の検討を。
• PCAP の生成: 分類の答え合わせには元パケットが欲しくなるが、無差別キャプチャは法令上グレーです。「同意済み被験者端末のみ」等、スコープを狭める。

まとめ: OpenGFW をいつ使うか / 使わないか

使う

• 自己管理下のネットワーク (社内・校内・自宅・ラボ) で、アプリケーションレベルのトラフィック制御が必要
• NAT 内のパケット全体を Linux ゲートウェイで一元的に捕捉できる構成
• 「業務外トラフィックの可視化・制限」等、ポリシーが明文化されていて、全ユーザーに事前周知されている
• 商用 NGFW (Palo Alto・Fortinet) に投資するほどではないが、L7 の制御が欲しい小〜中規模ネットワーク

使わない / 使ってはいけない

• 自身が管理していない第三者のネットワークに対する検閲・監視 (違法になり得ます)
• SSL inspection レベルの詳細なコンテンツ検査が必要なケース (MITM プロキシを別途導入)
• 既存の商用 NGFW・UTM で要件を満たせる場合 (運用コスト・サポート観点)
• 利用者に無断で全トラフィックを記録・分析する運用 (通信の秘密に抵触する可能性)

OpenGFW は「L7 の見える化」に特化した軽量ツールです。見える範囲 (SNI・ALPN レベル) と見えない範囲 (暗号化本文) を正しく理解した上で、自己管理ネットワークのポリシー適用 という本来の用途に当てはめるのが、現場で後悔しない運用のコツです。