発信者情報開示請求の対応方法について~地方ISPの場合~

株式会社ジェーミックス
情報インフラソリューション部
青海 京介

公開用資料
https://www.jmixnet.co.jp/

はじめに
おうみ きょうすけ

青海 京介 と申します。はじめまして!!
‣仕事について- (株)ジェーミックス 情報インフラ部 所属- 2021年新卒入社 26歳 業界4年目- ネットワーク周りを全般的にやってます‣私事について- 新潟県上越市出身- 進学で静岡に移り住んだ後、地元にUターン就職-

はじめに‣本発表で扱う内容
テクニカルな側面についてはお話します- FTTH/IPネットワークでのノードトレース- 運用の自動化‣本発表で扱わない内容
リーガルな側面についてはお話しません- 法的な解釈（専門外です・・・）- 個別の事例（通秘と個人情報に抵触する恐れがあるため）

はじめに発信者情報開示請求やばくないですか?

はじめに‣昨年、いろんなところで話題になってました‣P2Pネットワークを監視し、著作権対象コンテンツの違法アップロードノードに対する発信者情報開示請求がここ2年程の間に急増。
‣民事紛争の示談解決を目的として、P2PNW監視システムに上がってきたノードに対して広範に請求を掛けているという噂。

非公開

はじめに
‣発信者情報開示請求の処理件数

非公開

CATVのFTTHネットワーク（よくある構成）

サーバ群
OLT

Core NW

THE
Internet

収容SW

CATVインターネットの特徴
OLT
User

・自営敷設の伝送路網
・ethernet Layerの上に直接TCP/IPを展開（tunnel無し）

CATVのFTTHネットワーク（よくある構成）

DHCPによるアドレス割当て
サーバ群
OLT

Core NW

THE
Internet

収容SW

CATVインターネットの特徴
OLT
User

・自営敷設の伝送路網
・ethernet Layerの上に直接TCP/IPを展開（tunnel無し）

CATVのFTTHネットワーク（よくある構成）‣ONUはIPアドレスを持たない（IPアドレスを持つのは、CPEルータ）‣ONUがCPEの今現在の取得IPを把握する（DHCP Snooping）ことはできるが、過去のIPアドレス取得履歴等はOLT側では保持していない‣DHCPサーバのログから発信者をトレースする
責任分界点
DHCPサーバ

FTTH網
CPEルータONU

ユーザ宅内

DHCPシーケンス
Mar 25 10:45:30 host01 dhcpd[4069513]: DHCPDISCOVER from 00:00:5e:00:53:99 via 10.181.224.1

アドレスください!
Mar 25 10:45:30 host01 dhcpd[4069513]: DHCPOFFER on 192.0.2.100 to 00:00:5e:00:53:99

このアドレスはいかが?
Mar 25 10:45:30 host01 dhcpd[4069513]: DHCPREQUEST for 192.0.2.100 from 00:00:5e:00:53:99

そのアドレスいいね!ください!
Mar 25 10:45:30 host01 dhcpd[4069513]: DHCPACK on 192.0.2.100 to 00:00:5e:00:53:99

いいよ!

DHCPシーケンス‣この時間帯、「192.0.2.100」というIPアドレスは「00:00:5e:00:53:99」に割り当てられたみたいだね!
‣で、「00:00:5e:00:53:99」って誰のルータ???

FTTH網でのトレース
L3終端

目的ノード

> show ip route> show fdb> show fdb> show fdb←コア層(L3) アクセス網(L2)→FTTH網でのトレース①収容OLTまでたどり着く②ONUの学習MACをshowして、目的のMACアドレスが含まれているものを見つける(ユーザ宅に設置しているONUはMACアドレスで特定できることが前提)
L3終端

L3SW

> show ip route

L3SW> show fdb【OLTでのコマンド出力例】> show maclearn
onu
xx:xx:xx:xx:xx:xx
port1
00:00:5e:00:53:99
port2
……

L2SW

> show fdb

OLT> show maclearn

ONUCPEFTTH網でのトレース‣昔は、1件1件手作業で機器にログイン→showコマンドを打つ→接続先機器を探す→→次の機器にログイン…… のようにやってましたが‣ここ1-2年で開示請求の件数が急増。全く追いつかなくなり……
会社♪

attack!!

attack!!

時間♪

attack!!

attack!!
悩み事♪

眼精疲労
♪

attack!!
工数♪

そうだ。
自動化しよう。

要件‣トレース1件当たりにかかる時間をとにかく短くしたい‣かつ、正確な結果が欲しい‣タイムスタンプと、IPアドレスと、ポート番号を入力したら自動でトレースを実行して加入者情報を割出したい‣サービスの違いを透過的に扱えること（グローバルIP、シェアードIP、固定IPなど）‣機器の違いを透過的に扱えること（ベンダー、型番、世代）‣ついでに、解析レポート（テキスト＋スクリーンショット付き）も自動出力したい

方針‣構成管理とかZTPとかはツールが豊富だし、Open Sourceも溢れている‣だけど、”トレース自動化ツール”なんてものは調べた感じ無さそう(ニッチだし環境依存だし、そりゃ見つからないですよね・・・)※ SD-WAN機能を持った某社のオフィスNW向け製品だとノードの収容APまで全て自動収集して制御できるらしい
ただし、あくまでオフィスNW向け‣当然だけど、システム導入は見込めない（運用で吸収…!!）⇒ pythonでの専用スクリプト作成を手段に- テキスト処理が一通り可能- ライブラリの豊富さ（telnet, ssh, web scraping）- web上の情報が多いので、初心者でもできそう?
- 入社後の研修で触ったような気が・・・すっかり忘れてました実装‣古き良き（?）telnet/ssh自動実行型スクリプト。
‣NW機器にログインし、ログ / Routing Table / ARP Table / Forwarding DBをテキスト情報として取得。ノードの収容方向（次の接続先）を求める。
‣各種機器の管理情報（ホスト名、管理IP等）は管理台帳から取得。
L3終端

L3SW

L3SW

L2SW

OLT

ONU

NAS上の管理ドキュメント
DHCP
実行デバイスCPE

実装‣開示請求のタイムスタンプと、DHCPサーバのログ上のタイムスタンプを比較‣請求時刻の前後で対象IPを払出しているログを検索- 前後の時刻で挟み、別ホストへ払出していないことを確認‣3/30 午前7:00にIP 192.0.2.100を払出しているホストが知りたかったら…
Mar 30 05:10:03: IPv4 192.0.2.100 is leased to 04:ab:18:e7:1e:b0, xid=0x890d032b
Mar 30 11:10:03: IPv4 192.0.2.100 is leased to 04:ab:18:e7:1e:b0, xid=0xe7cd941e‣同じTransaction IDを持つパケット=一連のDHCPシーケンス‣Transaction IDを引っ掛けてoption情報を検索する‣クライアントのMACアドレスを拾う

実装‣Forwarding DBから対向機器を求めるには?
FTTHSW1>show mac address-table
Vlan Mac AddressTypePorts---- ------------------ ----3001 0003.3020.3ff6 DYNAMIC
Twe1/0/44

この先のホストはだれ?

‣L2DPを動かせば簡単に情報が取れるかも?
- CDPとかLLDPとか- 実際には、商用NWでL2DPを動かしてることは稀‣結局、収容InterfaceのDescription情報から対向ホストの情報を拾うことに- “description host_A”“host_Aの管理IP = 192.0.2.1” 的な変換
- descのpolicyを共通化し、対向ホストの情報を統一的に拾える形とした

実装‣DHCP Option82- Relay Agent Information Option- DHCPパケットを中継するリレーエージェントが情報を付加するフィールド‣OLTでOption82を有効にすると、ONU情報を中継時に付加してくれる- 実装的には、sub-option code 2にONUのMACアドレスを埋め込むものが多い- DHCPログから直接、ONU=加入者情報に辿り着くことが可能となる実装‣ethernet網のトレースを丸々すっ飛ばすことが可能
L3終端

L3SW

> show ip route

L3SW> show fdb【OLTでのコマンド出力例】> show maclearn
onu
xx:xx:xx:xx:xx:xx
port1
00:00:5e:00:53:99
port2
……

L2SW

> show fdb

OLT> show maclearn

ONUCPE

実装‣加入者情報の取得はどうする?
‣運用権限上の制約で、Webインターフェースのみ利用可能（apiとかはない）‣ブラウザの自動実行、webスクレイピングにより必要な情報を取得- Google Chrome: ウェブブラウザ- Chrome WebDriver : seleniumからchromeを操作するためのコンポーネント。
- selenium: ブラウザ自動化フレームワーク‣加入者DBの情報と整合性を取り、一致した場合にのみノード特定結果として出力‣ついでにスクリーンショットも撮れるため、提出エビデンス作成の観点から一石二鳥だった

実装‣CGNの場合- 先にGlobal IP
Shared IPの変換を行う必要あり- DHCPログよりもかなり読みづらい……
Jun 7 15:01:09 CGN1 NAT-UDP-D: 100.64.74.174:25903<-->192.168.93.250:53, 103.118.93.250:53<->192.168.92.229:25903#015#012<166> Jun 7 15:01:09 CGN1 NAT-UDP-D: 100.64.74.174:51103<->192.168.93.250:53, 192.168.93.250:53<-->192.168.92.229:51103#015#012<166> Jun 7 15:01:09
CGN1 NAT-UDP-D: 100.64.74.174:29938<-->103.118.93.250:53, 103.118.93.250:53<->192.168.92.229:29938#015#012<166> Jun 7 15:01:09 CGN1 NAT-UDP-D: 100.64.40.249:22958<->192.168.93.250:53, 192.168.93.250:53<-->192.168.95.177:22958#015#012<166> Jun 7 15:01:09
CGN1 NAT-UDP-D: 100.64.40.249:42218<-->192.168.93.250:53, 192.168.93.250:53<-‣当初は、graylogに収集したログをwebGUIから手作業検索していた- Web GUIもSeleniumによるブラウザ操作で自動化しようか……

実装

実装
‣Graylog APIあるじゃん!!!
- ある日、REST APIが使えることに気付く- クエリパラメータ: query & from & to・ query: IPアドレス（キーワード）を指定
・ from, to: タイムレンジを指定- CGNの膨大なログをgrepしてテキスト処理するよりも簡単◎ 時短◎
syslog
受信
ログ転送
CGNAT

DB

ログ管理
ログ検索
エンジン処理

ログサーバ

Graylog

インターフェース
提供

P

実装‣フローチャート設計（右図）‣実装し易そうなところから、業務の合間&休日に着手- 学習のoutputも兼ねているので、一貫した設計思想はなし!
・ 最初期はfunc()すら知らない状態
・ いきなりclassが出てきたり、命名ルール混在したり‣一人開発なので過程がグチャグチャでもなんとかなる‣足掛け4ヶ月くらいかけてなんとか完成やってみてどうだった?
【効果測定】‣目が疲れなくなった（!!）‣ツール作成前と比べ、請求IPアドレス1件当たりの処理時間は1/3程度に‣NW構成やシステムのログ仕様に詳しくない人でも同じ結果が出せるように（運用の平準化）‣運用ツール作成辺りから入ると、若手がプログラミングを学ぶのに適しているかもしれない(作るべきものがイメージしやすい、アウトプットが分かり易い)【振返りと今後の課題】‣運用自動化の前提: 自分のオペレーションをしっかり理解すること‣後任に引き継げる程度にリファクタリングすること（飽きた）困りごといろいろ‣某社製の家庭用ルータ- なんか、DHCPサーバのログが途中で途切れる。特定メーカの特定機種のみ- 調べたら、ホスト名にnull終端文字が入っているみたい- 近年のルータでは改善されてる?
‣某社製のOLT- option82にhexエンコードされた情報を乗っける仕様- decodeしないとまともにログ情報が読めない- 海外製品だとhexエンコード割と見ますよね（SNMPとかも・・・）‣開示請求の文書- scanされた画像形式のpdf- タイムスタンプやIPアドレスを目視で拾う必要あり(TesseractでOCRを試したけどイマイチ精度が出ず、、、OCRに詳しい方いたら教えてください)皆さんに聞きたいこと etc.
‣発信者情報開示請求どうですか? Eyeball側のNW運用者はどう向き合うべき?
- ISPの社会的責務に基づいた努力のみで成り立っている状態?安定的な体制は構築できてる?
特に小さいISPさんだと、対応がなかなか難しいですよね……
- 発信ノードの特定容易性

通秘のトレードオフになってしまわないか?

‣どうやって発信元ノードのトレースしてますか?
- 全部手作業!!
- ツール/スクリプト作ったよ!! / こんなツール使うと便利だよ!! /専用システム導入したよ!!
- CPEルータまでManageしてるのでこんな苦労してないよ!!
- etc.
‣たまに、ノードに辿り着けない開示請求が来る……
- syslog転送でパケ落ちしているだけ?
- 開示請求システムの信頼性って、どの程度のものなんでしょうか?

余談
https://www.telesa.or.jp/consortium/provider/p2ptechreq/

ご清聴ありがとうございました