Flowsint で自社ドメインを調べてみた——グラフ型 OSINT ツールを Docker で立ち上げ、キーなしで取れたもの、取れなかったもの、社内で使うときの線引き

自社のドメインの下に、外部から見えるサブドメインがいくつあるか。すぐに答えられる会社は少ないはずです。検証用に立てて忘れたままの環境、試作のまま残った画面、取引先ごとに切った環境。TLS 証明書を取った時点で、それらの名前は公開の記録に載り、誰でも一覧できます。

Flowsint は、ドメイン名や IP アドレスといった「点」を画面に置き、そこから自動収集の処理を走らせて関連する点と線を増やしていく、公開情報調査（OSINT）向けのオープンソースのツールです。この記事は、GitHub のリポジトリから手元の Mac に Docker で立ち上げ、自社の公開ドメイン hatenabase.jp を起点に調査を 1 件流して、何がどこまで取れたかを記録したものです。検証日は 2026 年 9 月 14 日、対象はリリース 1.2.12 相当のコミット 1820569 です。

調査対象は自社のドメインと、その公開資産だけに限りました。個人名、個人のメールアドレス、第三者の組織は一切対象にしていません。読み手として想定しているのは、自社の情報がどう見えているかを把握したい中小企業の担当者と、そのための道具を選ぶエンジニアです。AI が攻撃側の道具になった時代の守り方はAI に破られやすくなったセキュリティ対策の記事と企業サイトの WordPress を見直す記事に書きました。

Flowsint は Docker で 19 秒で立ち上がり、自社ドメインを起点にした調査は無料・API キーなしで実用になった。証明書透明性ログから 16 件のサブドメインが機械的に取れ、うち 6 件は検証用・試作用の環境だった。一方、組織名や人物名を起点にした調査は有料データベースの契約が前提で、キーなしでは何も出ない。ドキュメントが同梱と書く外部ツール 6 本のうち 5 本が公開イメージに入っておらず、macOS ではコンテナから Docker への接続も権限エラーになるため、DNS 解決、ポート走査、TLS 取得は完了扱いのまま空になる。.jp ドメインの WHOIS はほぼ取れない。API が整っているので、日次で自社ドメインを棚卸しするバッチに組み込むのが現実的な使いどころ。

この記事の要約

Flowsint とは何か

READMEの説明では、視覚的で柔軟に拡張できる、グラフを使った調査の基盤です。ドメイン、IP アドレス、メールアドレス、人物、組織といった対象を点として置き、右クリックで自動収集の処理（エンリッチャー）を選ぶと、結果が新しい点と線になってグラフに足されます。この操作の型は、リンク解析ツールの一般的なもので、実際にその型どおりに動きました。

Maltego などの商用ツールと比較した記述は、README にも公式ドキュメントにもありません。海外の紹介記事では代替として取り上げられていますが、公式が主張していないことをこの記事では書きません。

立ち上げは 19 秒、詰まったのはポートの衝突だけ

公式は macOS と Linux では make prod の 1 コマンドを案内しています。今回の Mac では 5173、5433、6379 の 3 つのポートが別の用途で埋まっていたため、標準の構成ファイルを書き換えず、上書き用の構成ファイルを 1 枚足して回避しました。

git clone https://github.com/reconurge/flowsint.git src
cd src
cp .env.example .env
cp .env.example flowsint-api/.env
cp .env.example flowsint-core/.env
cp .env.example flowsint-app/.env
docker compose -f docker-compose.prod.yml -f compose.ports.yml pull
docker compose -f docker-compose.prod.yml -f compose.ports.yml up -d

イメージ 5 本の合計は約 2.62 GB で、内訳は API と Celery が共用する flowsint-api が 1.05 GB、Neo4j が 1.01 GB、PostgreSQL が 408 MB、画面用の flowsint-app が 102 MB、Redis が 58.7 MB です。取得済みの状態から 6 つのコンテナがすべて健全になるまで 19.2 秒でした。1 回目の起動で 6 つとも健全になり、ポート以外の起動失敗は起きていません。

メモリはグラフ本体を持つ Neo4j が最も多く、待機時には全体の約 7 割を占めます。ノート PC でも動きますが、8 GB の機械で他の作業と同時に回すのは厳しいです。社内サーバーに置くなら、n8n を VPS に立てたときの記事で書いた必要スペックの考え方がそのまま使えます。

自動収集の処理は 48 件。キーなしで使えるのはドメイン起点だけ

稼働中のインスタンスに問い合わせると 48 件の処理が登録されていました。公式の一覧に載っているのは 45 件で、文書は内部用と試験用の 3 件を掲載外と書いていますが、稼働中の実体とは 1 件ずつ食い違っていて、単純な引き算では一致しません。各処理は必須の API キーを自分で申告していて、その申告で分けるとキー必須が 19 件、不要が 29 件です。

つまり、組織名や人物名を起点にした調査は、ほぼすべて有料の商用データベースの契約が前提です。キーなしで使えるのは、ドメイン、IP、ウェブサイトを起点にした技術的な調査に限られます。

キー不要と申告されていても外部サービスの契約が要るのは、HudsonRock を使う 3 件だけでした。ただし「不要 29 件」には、後述する外部ツールを Docker 経由で起動する処理も含まれていて、今回の環境ではそれらが空の結果を返しています。真にキーなしで完結したのは、IP の解決と逆引き、証明書透明性ログ、WHOIS、ウェブサイトの取得といった公開の仕組みだけで成立する十数件です。

API キーは画面上の保管庫（Vault）にまとめて置きます。ただし公式が保管庫の説明で、画面からキーと処理を個別に紐づけることはまだできない、と既知の制約として明記しています。キー名はサービス名に _API_KEY を付けた規約に合わせて登録します。

自社ドメインを起点に 14 件の処理を流した結果

ドメイン hatenabase.jp を起点に 7 件、そこから見つかった IP とウェブサイトを起点に 7 件、計 14 件の処理を走らせました。ドメイン起点の 7 件は投入から約 24 秒で全件完了、ウェブサイトの巡回（website_to_links）だけ 61.9 秒かかりました。

できあがったグラフはノード 45 個、エッジ 66 本です。内訳はウェブページ 22、ドメイン 19（うち 1 個は後述する起点の重複）、計測タグ 2、IP アドレス 1、WHOIS 情報 1。関係の種類は、サブドメインを持つ（16）、ページへのリンク（21）、ページが属するドメイン（22）、計測タグを持つ（2）、名前解決、逆引き、WHOIS 情報、ウェブサイト、IP が持つドメインの各 1 です。

自社の公開インフラについて分かったことを 4 つ挙げます。1 つ目、外部から見えるサブドメイン 16 件が、証明書透明性ログ（発行された TLS 証明書を誰でも検索できる公開の記録）から機械的に列挙できました。このうち 6 件は、名前から検証用や試作用と読み取れる環境です。外部に公開する意図がない環境でも、証明書を取得した時点で記録に載り、誰でも一覧できます。名前にランダムな文字列を混ぜても、記録に載る以上は隠蔽になりません。これは自社にとって実務上の示唆でした。

2 つ目、公開ウェブサイトは共用のレンタルサーバー上で動いていることが、IP の逆引きで外部から確認できる状態にあります。3 つ目、ドメインの登録情報は登録日と有効期限だけが取れ、登録者や連絡先は取れませんでした。理由は後述します。4 つ目、アクセス計測のタグが 2 系統入っていました。意図して 2 系統入れているのでなければ、過去の設定が残っている可能性があります。

個人情報は出ませんでした。キーなしの範囲で走らせた限り、個人名、個人のメールアドレス、電話番号は 1 件も出力されていません。ウェブサイトの巡回処理のうち website_to_crawler はメールアドレスと電話番号を収集する仕様ですが、今回は起動していません。

API だけで調査を組み立てられる

画面を一切触らずに、API だけで今回の調査を組み立てました。OpenAPI の定義がポート 5001 の openapi.json で無認証のまま公開されていて、Swagger UI と ReDoc も見られます。定義されているパスは 65 本です。

# 1) アカウント登録（初回のみ）
curl -X POST http://127.0.0.1:15001/api/auth/register 
  -H 'Content-Type: application/json' -d '{"email":"...","password":"..."}'
# 2) トークン取得（OAuth2 のパスワード方式。フォーム形式で送る）
curl -X POST http://127.0.0.1:15001/api/auth/token -d "username=...&password=..."
# 3) 調査を作る → 4) グラフを作る → 5) 起点ノードを置く
# 6) 処理を走らせる
curl -X POST http://127.0.0.1:15001/api/enrichers/domain_to_subdomains/launch 
  -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' 
  -d '{"node_ids":["<ノードID>"],"sketch_id":"<グラフID>"}'
# 7) 進捗を見る
curl http://127.0.0.1:15001/api/scans/sketch/<グラフID> -H "Authorization: Bearer $TOKEN"
# 8) 結果を取り出す
curl http://127.0.0.1:15001/api/sketches/<グラフID>/graph -H "Authorization: Bearer $TOKEN"

処理の投入は非同期で、すぐにジョブ ID が返ります。完了は進捗の API で COMPLETED になるのを待つか、イベントを流し続ける経路を使います。定期的に自社ドメインのサブドメインを棚卸しする用途なら、この 8 手順をそのまま日次バッチにできます。

詰まりどころ 5 つ

すべて実機で遭遇したものです。

1）起点に置いたノードが、処理結果と別物として二重に残る

画面から Domain 型で置いたノードと、自動収集の処理が作る小文字の domain 型のノードが別物として扱われ、同じ hatenabase.jp がグラフ上に 2 個できました。線は後者にしかつながりません。一覧に同じ名前が 2 行並ぶので気づけますが、ノード数を数える調査では数え間違いのもとになります。ノードを統合する API はあるので、後から手で 1 つにまとめられます。

2）.jp ドメインの WHOIS はほとんど何も返ってこない

domain_to_whois は完了扱いになりますが、返ってきたのは登録日と有効期限だけで、登録事業者、登録者組織、所在地、連絡先はすべて空でした。使っているのが汎用の Python ライブラリで、日本の登録管理機関（JPRS）の応答形式を解釈しきれていません。完了したのに中身が空、という結果になるので、処理が失敗したのか、そもそも公開されていないのか、画面からは判別できません。日本企業のドメインを調べる用途では、別の手段を用意する前提で考えたほうがよいでしょう。

3）外部ツールが同梱されているという記述と、実物が食い違う

公式の処理一覧の末尾には、サブドメイン探索などに使う外部ツール（subfinder、asnmap、dnsx、naabu、httpx、jq）は Docker コンテナに導入済みと書かれています。公開イメージの中を調べたところ、6 本のうち 5 本（subfinder、asnmap、dnsx、naabu、jq）が入っていませんでした。httpx という名前のコマンドはありましたが、文書が指す ProjectDiscovery のものではなく、Python の HTTP クライアントに付属する同名のコマンドです。ソースを読むと、これらは同梱ではなく、ホストの Docker に接続して別コンテナとして都度起動する作りで、イメージは実行時に取得します。本番用の構成が Docker のソケットをコンテナに渡しているのはこのためです。ところが今回の Mac では、コンテナからそのソケットに書き込む権限がなく、Docker への接続自体が権限エラーで失敗しました。これらの処理は例外を記録せず空の結果を返すため、画面上は完了に見えます。

結果として、サブドメイン探索は代替経路の証明書透明性ログに切り替わって動きました。16 件取れたのはこの経路です。ポート走査（ip_to_ports）、TLS 情報の取得（domain_to_tls）、DNS 解決（domain_to_dns）、技術要素の判定（tech_detect）、ルートドメインの判定（domain_to_root_domain）は、完了扱いのまま 1 件も出力しませんでした。ASN 系の 4 件も同じ経路なので、仮に有料キーを買ってもこの状態では動かないと見られます（今回は実行していません）。Docker Desktop のソケットは所有者が限られるため、この構成は macOS ではそのままでは機能しません。Linux のサーバーに置くか、ソケットの権限を別途整えることになります。

4）Docker のソケットをコンテナに渡す構成は、そのまま社内サーバーに置けない

3）の仕組みの副作用として、本番用の構成は API と Celery の両コンテナに Docker のソケットを渡しています。読み取り専用ではありますが、Docker のソケットに触れることは、そのホストに対する管理者権限とほぼ同じです。README は、ネットワークに公開する前に認証の秘密値、保管庫の暗号鍵、Neo4j のパスワードの 3 つを変更し、nginx の Host ヘッダの許可リストに自分のホスト名を足すよう注意していますが、ソケットについての注意書きは見当たりませんでした。社内の共有サーバーに置くなら、ここは自分で判断して外すか、隔離します。GitHub への侵入事例の記事で書いたとおり、開発用の道具が持つ権限は、侵入後の権限拡大に使われます。

5）自動収集で増えたノードが全部同じ座標に重なる

処理が作ったノードは座標がすべて (100, 100) で入ります。45 個のノードが 1 点に積み上がり、グラフ画面では点が 1 個だけあるように見えます。画面左の配置ボタンをひととおり押しても再配置されませんでした。今回は API で座標を計算して流し込み、読める配置にしています。手で 1 個ずつドラッグするか、API で座標を入れるかの二択です。

日本の会社が使うときの線引き

ライセンスは Apache License 2.0 なので、社内利用、改変、商用利用に制限はありません。ただし公式は免責で無保証を明記しています。顧客に対して、このツールの出力だから正しい、とは言えません。公式が倫理指針で禁じているのは、権限のない侵入、監視、データ収集、嫌がらせ、個人の特定情報の暴露、脅迫、個人を狙った攻撃、政治的な世論操作、偽情報、プライバシー侵害、国際人権基準に反する行為です。公式はこの列挙を網羅的なものではないと断っています。

社内で使うなら、調査対象の許諾（自社資産なら管理部門の承認、顧客資産なら契約書）を調査ごとに残す、設置場所を社内ネットワークに閉じる、Docker のソケット付与を外すか隔離されたホストで動かす、有料データベースの契約を結ぶ前にその利用規約が自社の顧客向け調査に使えるかを確認する、の 4 つは最低限そろえておきます。多くの商用データベースは再販や第三者提供を制限しています。ルール作りの進め方は中小企業の生成 AI 運用ルール整備ガイドの枠組みが流用できます。

使いどころは、自社ドメインの日次棚卸し

立ち上げは速く、手順は素直で、詰まったのはポートの衝突だけでした。自社ドメインのサブドメイン棚卸しという用途には、キーなし、無料で、実際に使えます。証明書透明性ログ経由で 16 件を機械的に拾えました。API が整っているので、日次で自社ドメインを棚卸しし、前日と差分が出たら通知する、という運用に組み込むのがいちばん現実的です。

一方で、組織名や人物名を起点にした調査は有料データベースの契約が前提で、キーなしでは何も出ません。ドキュメントと実物の食い違いが 1 か所あり、加えて macOS では Docker 経由の外部ツールが権限エラーで起動しないため、ポート走査や TLS 取得が完了したのに空、という結果になって原因が分かりません。.jp ドメインの WHOIS がほとんど取れないため、日本企業の調査に使うならそこは別の手段で補う必要があります。

今回の検証でいちばん実務に響いたのは、自社の検証用環境が外から一覧できていた事実です。道具の評価より先に、その 6 件の環境が今も必要かを見直すところから着手しています。AI エージェントに社内の情報を扱わせるときの経路の整理は企業データを漏らす 5 つの経路の記事にまとめてあります。