【ITニュース解説】decoy-hunter — Countering the "All Ports Are Open" Deception Author: Antonio José Socorro Marín Date: September 28, 2025

近年のサイバーセキュリティにおいて、防御側が攻撃者の混乱を狙って意図的に偽の情報を提供する「デコイ」という手法が注目されている。例えば、実際には利用されていないにもかかわらず、システムのすべての通信ポートが開いているように見せかけることがある。これは、不正アクセスを試みる者がどこが本物のサービスで、どこが偽の情報なのかを見分けにくくさせ、攻撃にかかる時間を増やしたり、自動スキャンツールの結果を誤らせたりすることを目的としている。このようなデコイは、iptablesというネットワーク設定ツールによるリダイレクトや、portspoofのような専用ツール、あるいは単に偽のバナー（サービスが提供する情報）を表示するエミュレーターによって実装される。

しかし、多くのデコイは表面的な実装に留まっており、偽物であると見破られる手がかりを残してしまう場合がある。例えば、同じポートへのスキャンなのに時間帯によってバナーが変わったり、偽のサービスがどのような入力に対しても常に同じ応答を返したりすることが挙げられる。また、ウェブサービス用のポート（HTTPポート）なのにSSH（リモートログイン）サービスのバナーが表示されるといった、プロトコルの不一致もデコイの弱点となる。このような脆弱性は、バナー情報だけを鵜呑みにせず、実際のプロトコル（通信ルール）の振る舞いを検証することで、デコイを見破るための実践的な機会を提供する。

「decoy-hunter」は、このようなデコイの欺瞞を見破るためのフレームワークとして開発された。その主な目的は二つある。一つは、多くの偽のサービスに紛れて隠されている、実際に利用可能で攻撃者が悪用できる本物のサービスを検出することである。もう一つは、システム管理者が自社のデコイ設定がどの程度効果的か、あるいは設定ミスによってかえってセキュリティ上の誤った安心感を生み出していないかを評価するための実用的なツールを提供することだ。このツールは、許可を得て活動する攻撃チーム（レッドチーム）や、企業の内部セキュリティ検証、あるいは攻撃と防御が共同で行う演習といった、正式なセキュリティ評価での利用を想定している。

decoy-hunterの設計には五つの核となる原則がある。第一に「現実的なプロービング」だ。これは、サービスを調査する際に、単にポートが開いているかを確認するだけでなく、例えば「nmap-service-probes」のようなサービス識別データベースから得られた、実際のクライアントが送るような正当なリクエストを使用することである。具体的には、ウェブサービスには適切なUser-Agent情報を含むHTTP GET/HEADリクエストを、暗号化通信のTLSサービスにはSNIやALPNを含むClientHelloメッセージを、メールサービスにはEHLOシーケンスを送るなど、そのプロトコルに特化した問い合わせを行う。第二は「状態を意識したプロトコル検証」で、これはバナー情報を信用するだけでなく、通信が決められたプロトコル手順に従って進行するかどうか、そして期待される振る舞いをするかを検証する。例えば、SSH通信における鍵交換のシーケンスが正しく行われるか、TLSハンドシェイクが完了し、証明書のプロパティが適切であるか、SMTPコマンドのシーケンスと応答コードが整合性を持つかなどを確認する。第三に「トラフィックの隠蔽」がある。これは、decoy-hunterが行う調査活動が、簡易的なスキャナー検知システムによって見破られないようにするための工夫である。具体的には、リクエストの間隔をランダムに遅延させたり、同時に送るリクエストの数を低く抑えたり、様々なリクエストパターンや重複しないシーケンスを使用することで、通信が正当なクライアントの活動のように見えるようにする。第四は「データ最小化と監査可能性」で、デフォルトではサービスからの応答本文を永続的に保存しない。もし、調査の証拠として通信内容を記録する必要がある場合は、明確な許可の下で行い、厳格なガバナンス管理のもとで記録する。また、監査ログや出力されるレポートは、その完全性を保つために署名される。第五は「成果物の完全性」で、調査に使用するプローブデータベースやリリースされるツール自体が改ざんされていないことを保証するために、暗号学的な署名を維持する。そして、ツールが実行される際には、プローブデータベースを使用する前に必ずその署名を検証する。

decoy-hunterはモジュール化されたアーキテクチャを採用しており、それぞれの責任が分離され、レビューや導入が容易になっている。主要なコンポーネントとしては、コマンドラインからの入力処理、実行ポリシーの決定、レポート作成などを行うメインのスクリプト「decoy_hunter.py」、実際にリクエストを送信し、通信のゆらぎ（ジッター）、同時実行数、再試行、タイムアウトなどを管理する「probes.py」（スケーラビリティのためにasyncioを用いた非同期I/Oを実装）、サービス識別データベース（nmap-service-probes）を解析し、署名を検証する「service_probes_parser.py」、TLS通信のJA3/JA3SハッシュやTCP/IPスタックの特性（TTL、ウィンドウサイズなど）から受動的にフィンガープリントを行う「fingerprints.py」、そしてプローブ結果を集約し、バナーの一致、ハンドシェイクの成功、複数プローブ間の一貫性、証明書の有効性などを根拠に信頼度スコアを算出する「スコアリング＆評価モジュール」がある。さらに、証拠として署名付きのJSONレポートや、オプションで通信キャプチャファイル（PCAP）を出力する「監査/フォレンジックエクスポート」モジュールも備えている。

実際の運用フローは次のように進む。まず、初期化と完全性チェックの段階で、プローブデータベースの署名が検証され、信頼できない場合は処理が中断される。次に、調査対象のホストやポート範囲、TCP/UDPモード、同時に実行する処理の数、通信のタイミングやステルス性といった設定が行われる（デフォルトでは同時実行数やタイミングは控えめな設定が推奨される）。その後、「プロービング段階」に入り、解析されたプローブ定義に従って現実的なリクエストが実行される。TLSエンドポイントに対してはClientHelloを送信しサーバーの応答を詳細に分析し、SSHエンドポイントに対しては認証を行わずに鍵交換の進行を試みることで、鍵交換の振る舞いを検証する。続いて、「状態を意識した検証」が行われ、サービスからの応答が期待されるプロトコルの状態遷移通りに進むか、そして不正な入力や異なる入力に対してもプロトコルに矛盾しないエラー処理が行われるかを確認する。さらに、「クロスプローブ相関」の段階では、同じホストの異なるプローブタイプやポートからの応答間に一貫性があるかを比較する。例えば、無関係な複数のポートで全く同じバナーが表示される場合は、デコイであるという疑いが強まる。これらの結果に基づき、サービスは「本物（REAL）」「偽物（FAKE）」「曖昧（AMBIGUOUS）」のいずれかに分類され、0.0から1.0までの信頼度スコアと、その判断に至った根拠が詳細に提供される。「レポートと証拠出力」の段階では、コンソールへの結果表示に加え、オプションとして監査のために署名付きのJSONレポートやPCAPファイルが出力される。

具体的な利用例としては、「python3 decoy_hunter.py 192.168.1.10」と実行することで、指定されたIPアドレスの主要なTCPポートをスキャンする。出力例では、「22/tcp」は本物のSSHサービスとして信頼度0.92で検出され、正確なSSHバージョンが表示されている。一方で、「8080/tcp」は、HTTPポートであるにもかかわらずSSHのバナーが返ってきたため、「プロトコル不一致」というフラグが立てられ、信頼度0.12で偽物（FAKE）と判断されている。このように、本来あるべきサービスと異なる振る舞いをしている場合、即座にデコイ設定の不備を示す指標となる。

ツールの有効性を検証するためには、堅牢な評価戦略が不可欠である。これには、本物のOpenSSH、nginx、SMTPサーバー、Redisなどのサービスコンテナ、様々なバナーを返す簡易的なデコイコンテナ、さらにTLS/SSHプロトコルの部分的な手順をエミュレートする状態を持つデコイコンテナ、そしてSuricataやZeekのようなIDS（侵入検知システム）センサーを含む、Docker Composeなどで再現可能なテスト環境の構築が推奨される。このテスト環境で、本物のサービス検出における検出精度と再現率、ステルス設定下でのホストあたりの平均スキャン時間、IDSのアラート発動率、デコイの種類ごとの誤検知・見逃し数といった指標を収集する。そして、デコイの複雑さ（簡易な静的デコイから状態を持つ高度なデコイまで）、通信のタイミングや同時実行数のプロファイル、ロードバランサーやリバースプロキシなどのネットワーク機器の有無といった様々な条件を変えて系統的な実験を行うことで、ツールの性能と信頼性を客観的に評価する。

decoy-hunterは、必ず許可された環境でのみ使用されるべきであり、運用にあたっては厳格なセキュリティ、プライバシー、ガバナンスの管理が求められる。具体的には、スキャン実行前に文書による正式な承認を必須とし、その記録を監査ログに残すこと。使用するプローブデータベースやリリースされたツール自体が改ざんされていないことを、承認された暗号技術（ECDSA P-256 / SHA-256など）を用いて実行時に検証すること。TLS証明書の有効性（証明書チェーンや失効ステータス）を検証し、証明書検証に失敗したエンドポイントは「曖昧」として分類し、その理由を明記すること。取得した通信内容は必要最低限に留め、ペイロードを保存する場合には暗号化を施し、保持期間を制限すること。出力される署名付きJSONレポートやPCAPファイルは、法的要件に応じて保管管理（Chain-of-Custody）メタデータを維持すること。そして、システムに意図しない障害を引き起こす可能性のある攻撃的なプロービングモードはデフォルトでは避けるべきであり、破壊的または侵入的な操作を行う場合は明示的な承認と記録が必要である。デフォルトの運用設定としては、同時実行数を低く（例：8）、プローブ間のランダムな遅延（例：0.3～1.5秒）、ペイロードの保存をデフォルトで無効にする（明示的な指示でのみ有効化）、本番環境でのスキャンには明示的な対話型承認または承認トークンを必須とすることなどが推奨される。これらの設定は、偶発的なシステム中断のリスクを減らし、許可された範囲内での検出可能性を維持するのに役立つ。

デコイは有効な防御手段となり得るが、不適切なデコイ設定は誤ったセキュリティ上の安心感を生み出す可能性がある。decoy-hunterは、単なるバナー情報だけでなく、現実的なプロービングと状態を意識したプロトコル検証を組み合わせることで、デコイの真偽を評価するための実践的なフレームワークである。トラフィックの隠蔽、証拠の完全性、再現可能な検証戦略といった特徴を持ち、サイバーセキュリティの防御において、偽りの見せかけではなく、真の堅牢性と検証可能性を追求する上で非常に有用なツールとなる。