JP2019036830A - 端末識別装置、端末識別方法及びプログラム - Google Patents

Abstract

【課題】端末の種別を識別する。
【解決手段】ネットワークに収容される第１の端末の通信トラヒックから、該第１の端末の通信先を示す通信先ホストのリストを作成するリスト作成部と、前記リスト作成部が作成した通信先ホストのリストと、予め作成された識別器とから、前記第１の端末の端末種別を識別する識別部と、を有することを特徴とする。
【選択図】図３

Description

本発明は、端末識別装置、端末識別方法及びプログラムに関する。

インターネットの利用ユーザ数の増加やＩｏＴ（Internet of Things）機器を始めとする通信端末の多様化等に伴い、通信事業者において、特定のアプリケーションや端末の仕様、通信挙動等が原因となり、ネットワークの適切な運用に支障が生じる場合がある。

例えば、ある特定の種別の端末が同時刻に一斉に通信を行う仕様である場合、端末数が多いとネットワーク輻輳の原因となることがある。このため、ネットワークの適切な運用に支障が生じる原因となるようなリスクを有する端末やアプリケーションの種別を調査し、必要に応じて端末やアプリケーションの開発元に仕様変更の打診を行ったり、ネットワークレベルでの通信制限の措置を講じたりすることが求められている。

また、ある特定の種別の端末を対象とするマルウェアの大規模感染が生じた場合等には、影響を最小限に抑える必要がある。このため、通信事業者は、マルウェアに関する通信トラヒックを検出した際に、原因となっている端末の種別を早期に特定し、注意喚起や通信制限等の措置を講じる必要がある。

このように、通信事業者は、ネットワークの適切な運用に影響を及ぼす可能性のある通信トラヒックの発生原因となっている端末やアプリケーションの種別を早期に特定する必要がある。以降では、ある特定のプログラム（ＯＳ（Operating System）やアプリケーションソフトウェア、ミドルウェア、ファームウェア、端末の製造元ベンダ等によりプリインストールされる固有のプログラム等も含む）が搭載された端末を特定すること（すなわち、端末の種別を識別すること）を「端末識別」と称する。

ここで、通信事業者が各ユーザの端末の種別を個別に全数調査することは困難である。そこで、通信トラヒック（以降、単に「トラヒック」とも表す。）から端末識別を行うことが考えられる。

トラヒックから端末識別を行う方法として、パケットのアプリケーション・ヘッダに含まれる端末識別情報（例えば、ＨＴＴＰ（Hypertext Transfer Protocol）ヘッダのＵｓｅｒ−Ａｇｅｎｔフィールド）を参照する方法が知られている。しかしながら、通信が暗号化される場合には、アプリケーション・ヘッダも暗号化されるため、端末識別を行うことができないことがある。

これに対して、例えばＩＰ（Internet Protocol）ヘッダやＴＣＰ（Transmission Control Protocol）／ＵＤＰ（User Datagram Protocol）ヘッダ等から端末の種別を推定する方法が知られている（例えば非特許文献１）。非特許文献１に開示されている方法では、パケットのヘッダの一部のフィールドに設定されるネットワーク・パラメータ（例えば、ウィンドウサイズ、ＴＴＬ（Time To Live）等）がＯＳやアプリケーション固有のパラメータに依存することに着目し、これらのネットワーク・パラメータを特徴量（フィンガプリント）として端末識別を行う。

Zalewski, Michal. "p0f: Passive OS Fingerprinting tool.", [online], インターネット＜ＵＲＬ：http://lcamtuf.coredump.cx/p0f.shtml/＞

ここで、非特許文献１に開示されている方法では、特定したい端末の種別毎に、ＩＰヘッダやＴＣＰ／ＵＤＰヘッダの一部のフィールドに設定されるネットワーク・パラメータが異なる必要がある。

しかしながら、近年では、モバイル端末やＩｏＴ端末等の各種端末で用いられるネットワーク・パラメータの共通化が進んでいる。このため、特定したい端末の種別毎に、ネットワーク・パラメータに差異が生じない場合があり、非特許文献１に開示されている方法で端末識別を行うことができないことがある。

本発明の実施の形態は、上記の点に鑑みてなされたもので、端末の種別を識別することを目的とする。

上記課題を解決するため、ネットワークに収容される第１の端末の通信トラヒックから、該第１の端末の通信先を示す通信先ホストのリストを作成するリスト作成部と、前記リスト作成部が作成した通信先ホストのリストと、予め作成された識別器とから、前記第１の端末の端末種別を識別する識別部と、を有することを特徴とする。

端末の種別を識別することができる。

本発明の実施の形態における端末識別装置が含まれるシステムの全体構成の一例を示す図である。 本発明の実施の形態における端末識別装置のハードウェア構成の一例を示す図である。 本発明の実施の形態における端末識別の概略を説明する図である。 通信トラヒックから抽出する情報の一例を説明する図である。 本発明の実施の形態における端末識別処理部の機能構成の一例を示す図である。 端末識別処理部の学習フェーズにおける処理の一例を示すフローチャートである。 端末識別処理部の識別フェーズにおける処理の一例を示すフローチャートである。

以下、本発明の実施の形態について、図面を参照しながら説明する。

＜全体構成＞
まず、本発明の実施の形態において端末識別を行う端末識別装置１０が含まれるシステムの全体構成について、図１を参照しながら説明する。図１は、本発明の実施の形態における端末識別装置１０が含まれるシステムの全体構成の一例を示す図である。

図１に示すように、内部ネットワークＥ１は、利用ユーザＡの端末２１Ａ、利用ユーザＢの端末２１Ｂ、利用ユーザＣの端末２１Ｃ等の複数の端末２１を収容する。また、内部ネットワークＥ１には、種々の通信機器２２が収容されていても良い。以降では、内部ネットワークＥ１に収容される端末２１や通信機器２２を区別しない場合は、「ユーザ端末２０」とも表す。

内部ネットワークＥ１は、例えば、企業内のネットワーク環境やＩＳＰ（Internet Services Provider）内のネットワーク環境等である。内部ネットワークＥ１では、例えばＩＰアドレスや加入者ＩＤ等を用いて、収容されている各ユーザ端末２０を特定することができる。

内部ネットワークＥ１に収容される各端末２１としては、例えば、ＰＣ（パーソナルコンピュータ）やスマートフォン、タブレット端末、ゲーム機器等が挙げられる。また、各通信機器２２としては、例えば、ファクシミリ、コピー機、プリンタ、車載機（例えばカーナビ等）、監視カメラ、家電製品等の種々の通信可能な機器が挙げられる。

各ユーザ端末２０は、ＯＳ（例えば、Ｗｉｎｄｏｗｓ（登録商標）、ｍａｃＯＳ（登録商標）、Ａｎｄｒｏｉｄ（登録商標）、Ｌｉｎｕｘ（登録商標）等）で端末種別を分類できるものとする。なお、各ユーザ端末２０は、更に、例えば、モバイル端末であるか、固定端末であるか等により端末種別を分類できても良い。

また、内部ネットワークＥ１には、各ユーザ端末２０の端末種別を識別する端末識別装置１０と、各ユーザ端末２０のトラヒックを収集するトラヒック収集装置３０と、ドメイン名からＩＰアドレスへの名前解決を提供するＤＮＳ（Domain Name System）キャッシュサーバ４０とが含まれる。

一方で、外部ネットワークＥ２は、ユーザ端末２０がアクセスする通信先ホストサーバ５０が含まれるネットワーク環境である。通信先ホストサーバ５０は、例えば、Ｗｅｂサーバやクラウドサーバ等のコンテンツサーバであり、例えば、ユーザ端末２０に搭載されているＯＳ毎に存在する。ユーザ端末２０は、インターネットを介して、通信先ホストサーバ５０にアクセスすることで、例えば、ＯＳのバージョンアップやＯＳ固有のアプリケーションデータの同期等を行う。

ＤＮＳキャッシュサーバ４０は、ユーザ端末２０が通信先ホストサーバ５０にアクセスするための名前解決を行うサーバである。ＤＮＳキャッシュサーバ４０は、内部ネットワークＥ１に設置されている場合に限られず、例えば、外部ネットワークＥ２にも設置されていて良い。この場合、ユーザ端末２０は、内部ネットワークＥ１又は外部ネットワークＥ２のいずれかに設置されているＤＮＳキャッシュサーバ４０を選択的に利用すれば良い。

なお、後述する学習フェーズ及び識別フェーズで必要な情報をＨＴＴＰ又はＨＴＴＰＳ（Hypertext Transfer Protocol Secure）通信のトラヒックから収集する場合には、ＤＮＳキャッシュサーバ４０が設置されていなくても良い。

トラヒック収集装置３０は、ユーザ端末２０が通信先ホストサーバ５０にアクセスする際のトラヒック（ＨＴＴＰ／ＨＴＴＰＳ通信のトラヒック）と、これに先立って発生するＤＮＳ通信（すなわち、名前解決のためのＤＮＳキャッシュサーバ４０への問い合せ通信）のトラヒックとを端末識別装置１０に転送する。このため、トラヒック収集装置３０は、ユーザ端末２０から通信先ホストサーバ５０へのトラヒックと、ユーザ端末２０からＤＮＳキャッシュサーバ４０へのトラヒックとを収集可能な場所に設置される。

トラヒック収集装置３０は、例えば、通信トラヒックの複製（ミラーリング）機能を有するネットワーク・スイッチやタップ等を用いて実現可能である。すなわち、ミラーリング機能を有するネットワーク・スイッチやタップ等において、該当のトラヒックを端末識別装置１０に転送する設定を行うことで、トラヒック収集装置３０が実現される。

端末識別装置１０は、各ユーザ端末２０がアクセスする通信先ホストサーバ５０を示す情報（通信先ホスト）から、これら各ユーザ端末２０の端末種別を識別する１以上のコンピュータである。端末識別装置１０は、端末識別処理部１００を有する。端末識別処理部１００は、端末識別装置１０にインストールされた１以上のプログラム（スクリプトも含む）が、後述するＣＰＵ１６に実行させる処理により実現される。

また、端末識別装置１０は、通信記録ＤＢ１１０と、識別結果ＤＢ１２０とを有する。これら各ＤＢは、例えば、後述する補助記憶装置１８を用いて実現可能である。なお、これら各ＤＢのうちの少なくとも１つのＤＢが、端末識別装置１０とネットワークを介して接続される記憶装置等を用いて実現されていても良い。

端末識別装置１０は、端末識別処理部１００により、トラヒック収集装置３０から転送されたトラヒックから、通信先ホスト等が含まれる所定の情報を抽出した上で、通信記録ＤＢ１１０に格納する。そして、端末識別装置１０は、端末識別処理部１００により、通信記録ＤＢ１１０に格納されている情報を用いて、ユーザ端末２０の通信先ホストから端末種別を識別した上で、識別結果を識別結果ＤＢ１２０に格納する。

なお、図１に示すシステムの全体構成は一例であって、他の構成であっても良い。例えば、端末識別装置１０及びトラヒック収集装置３０は、内部ネットワークＥ１と外部ネットワークＥ２との間に存在する中継ネットワーク内に設置されていても良い。また、この場合、ＤＮＳキャッシュサーバ４０も中継ネットワーク内に設置されていても良い。

＜ハードウェア構成＞
次に、本発明の実施の形態における端末識別装置１０のハードウェア構成について、図２を参照しながら説明する。図２は、本発明の実施の形態における端末識別装置１０のハードウェア構成の一例を示す図である。

図２に示すように、本発明の実施の形態における端末識別装置１０は、入力装置１１と、表示装置１２と、外部Ｉ／Ｆ１３と、ＲＡＭ（Random Access Memory）１４と、ＲＯＭ（Read Only Memory）１５と、ＣＰＵ（Central Processing Unit）１６と、通信Ｉ／Ｆ１７と、補助記憶装置１８とを有する。これら各ハードウェアは、それぞれがバスＢを介して通信可能に接続されている。

入力装置１１は、例えばキーボードやマウス、タッチパネル等であり、ユーザが各種操作を入力するのに用いられる。表示装置１２は、例えばディスプレイ等であり、端末識別装置１０の処理結果を表示する。なお、端末識別装置１０は、入力装置１１及び表示装置１２の少なくとも一方を有していなくても良い。

外部Ｉ／Ｆ１３は、外部装置とのインタフェースである。外部装置には、記録媒体１３ａ等がある。端末識別装置１０は、外部Ｉ／Ｆ１３を介して、記録媒体１３ａ等の読み取りや書き込みを行うことができる。

記録媒体１３ａには、例えば、フレキシブルディスク、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disk）、ＳＤ（Secure Digital）メモリカード、ＵＳＢ（Universal Serial Bus）メモリカード等がある。

ＲＡＭ１４は、プログラムやデータを一時保持する揮発性の半導体メモリである。ＲＯＭ１５は、電源を切ってもプログラムやデータを保持することができる不揮発性の半導体メモリである。ＲＯＭ１５には、例えば、ＯＳ設定やネットワーク設定等が格納されている。

ＣＰＵ１６は、ＲＯＭ１５や補助記憶装置１８等からプログラムやデータをＲＡＭ１４上に読み出して、処理を実行する演算装置である。

通信Ｉ／Ｆ１７は、他の装置と通信を行うためのインタフェースである。端末識別装置１０は、通信Ｉ／Ｆ１７を介して、トラヒック収集装置３０からトラヒックを受信する。

補助記憶装置１８は、例えばＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）等であり、プログラムやデータを格納している不揮発性の記憶装置である。補助記憶装置１８に格納されているプログラムやデータには、例えば、ＯＳ、当該ＯＳ上において各種機能を実現するアプリケーションプログラム、端末識別処理部１００を実現するプログラム等がある。

本発明の実施の形態における端末識別装置１０は、図２に示すハードウェア構成を有することにより、後述する各種処理を実現することができる。

＜端末識別の概略＞
ここで、端末識別装置１０の端末識別処理部１００による端末識別の概略について、図３を参照しながら説明する。図３は、本発明の実施の形態における端末識別の概略を説明する図である。

端末識別処理部１００による端末識別は、端末種別の識別に用いられる端末識別器２００を作成するための「学習フェーズ」と、端末識別器２００を用いて実際に端末種別を識別する「識別フェーズ」とがある。

≪学習フェーズ≫
Ｓ１１）トラヒック収集装置３０からトラヒックが転送されると、端末識別処理部１００は、当該トラヒックから所定の情報（通信時刻、通信元アドレス、通信先ホスト及び端末種別）を抽出した上で、抽出した情報を対応付けて通信記録ＤＢ１１０に格納する。

通信記録ＤＢ１１０には、例えば所定の期間の間にトラヒック収集装置３０から転送されたトラヒックの通信時刻、通信元アドレス、通信先ホスト及び端末種別が対応付けて格納されている。

Ｓ１２）端末識別処理部１００は、通信記録ＤＢ１１０に格納されている情報（通信時刻、通信元アドレス、通信先ホスト及び端末種別）から端末識別器２００を作成する。端末識別器２００は、識別フェーズにおいて通信先ホストから端末種別を識別するための中間データであり、例えば、バイナリデータやテキストデータの形式で作成される。

≪識別フェーズ≫
Ｓ２１）トラヒック収集装置３０からトラヒックが転送されると、端末識別処理部１００は、当該トラヒックから所定の情報（通信時刻、通信元アドレス及び通信先ホスト）を抽出した上で、抽出した情報を対応付けて通信記録ＤＢ１１０に格納する。

Ｓ２２）端末識別処理部１００は、端末識別器２００を用いて、通信記録ＤＢ１１０に格納されている通信先ホストから端末種別を識別する。そして、端末識別処理部１００は、識別した端末種別と、通信元アドレスとを対応付けて識別結果ＤＢ１２０に格納する。これにより、通信元アドレスにより特定されるユーザ端末２０の端末種別が識別される。

≪通信トラヒックから抽出する情報≫
ここで、学習フェーズ及び識別フェーズにおいて通信トラヒックから抽出する情報について、図４を参照しながら説明する。図４は、通信トラヒックから抽出する情報の一例を説明する図である。

上述したように、学習フェーズでは、（ａ）通信時刻、（ｂ）通信元アドレス、（ｃ）通信先ホスト、及び（ｄ）端末種別が通信トラヒックから抽出される。一方で、識別フェーズでは、（ａ）通信時刻、（ｂ）通信元アドレス、及び（ｃ）通信先ホストが通信トラヒックから抽出される。

このとき、（ａ）通信時刻としては、例えば、（ａ−１）ＨＴＴＰ／ＨＴＴＰＳ通信開始時のパケットをトラヒック収集装置３０が収集した時刻、又は（ａ−２）ＤＮＳ通信のパケットをトラヒック収集装置３０が収集した時刻、のいずれか１つを用いれば良い。

また、（ｂ）通信元アドレスとしては、例えば、（ｂ−１）ＨＴＴＰ／ＨＴＴＰＳ通信のクライアント側ＩＰアドレス、又は（ｂ−２）ＤＮＳ通信の送信元ＩＰアドレス、のいずれか１つを用いれば良い。

また、（ｃ）通信先ホストとしては、（ｃ−１）ＨＴＴＰヘッダのＨｏｓｔフィールド、（ｃ−２）ＤＮＳ通信のＦＱＤＮ（Fully Qualified Domain Name）、又は（ｃ−３）ＨＴＴＰ通信のＳＮＩ（Server Name Indication）情報、のいずれか１つを用いれば良い。

更に、（ｄ）端末種別としては、（ｄ−１）ＨＴＴＰヘッダのＵｓｅｒ−Ａｇｅｎｔフィールド、又は（ｄ−２）通信元アドレスと端末種別とが対応付けられた外部ＤＢ等を参照して得られる端末種別、のいずれか１つを用いれば良い。

このため、例えば、トラヒック収集装置３０がＨＴＴＰ通信のトラヒックを収集することができる場合には、学習フェーズでは、（ａ−１）、（ｂ−１）、（ｃ−１）及び（ｄ−１）の情報を、それぞれ（ａ）通信時刻、（ｂ）通信元アドレス、（ｃ）通信先ホスト、及び（ｄ）端末種別の情報として抽出すれば良い。

一方で、例えば、トラヒック収集装置３０がＤＮＳ通信のトラヒックのみを収集することができる場合には、学習フェーズでは、（ａ−２）、（ｂ−２）及び（ｃ−２）の情報を、それぞれ（ａ）通信時刻、（ｂ）通信元アドレス及び（ｃ）通信先ホストの情報として抽出すれば良い。このとき、ＤＮＳ通信のトラヒックには、端末種別に相当する情報が含まれないため、（ｄ−１）通信元アドレスと端末種別とが対応付けられた外部ＤＢ等を参照して得られる端末種別を（ｄ）端末種別の情報として抽出する。

外部ＤＢとは、例えば、企業等の組織内で、ユーザ端末２０のＩＰアドレスと、当該ユーザ端末２０の端末種別とを対応付けて管理しているＤＢ（データベース）である。したがって、トラヒック収集装置３０がＤＮＳ通信のトラヒックのみを収集することができる場合には、端末識別装置１０（又はトラヒック収集装置３０）は、上記のような外部ＤＢにアクセスできる必要がある。

また、例えば、トラヒック収集装置３０がＨＴＴＰ通信のトラヒックを収集することができる場合には、識別フェーズでは、（ａ−１）、（ｂ−１）及び（ｃ−１）の情報を、それぞれ（ａ）通信時刻、（ｂ）通信元アドレス及び（ｃ）通信先ホストの情報として抽出すれば良い。なお、このとき、ＨＴＴＰＳ通信である場合には、（ｃ−１）の代わり、（ｃ−３）の情報を（ｃ）通信先ホストの情報として抽出すれば良い。

一方で、トラヒック収集装置３０がＤＮＳ通信のトラヒックのみを収集することができる場合には、識別フェーズでは、（ａ−２）、（ｂ−２）及び（ｃ−２）の情報を、それぞれ（ａ）通信時刻、（ｂ）通信元アドレス及び（ｃ）通信先ホストの情報として抽出すれば良い。

このように、トラヒック収集装置３０が収集可能なトラヒックの種類に応じて、端末識別処理部１００は、学習フェーズや識別フェーズで必要な情報を当該トラヒックから抽出する。なお、例えば、トラヒック収集装置３０がＨＴＴＰ通信及びＤＮＳ通信の両方のトラヒックを収集することができる場合には、抽出する項目に応じて、抽出する対象のトラヒックの種別を異ならせても良い。例えば、（ａ）通信時刻及び（ｂ）通信元アドレスはＤＮＳ通信のトラヒックから抽出し、（ｃ）通信先ホスト及び（ｄ）端末種別はＨＴＴＰ通信のトラヒックから抽出する等である。

なお、以降では、学習フェーズの処理を開始する前に、学習フェーズに必要な情報（すなわち、通信時刻、通信元アドレス、通信先ホスト及び端末種別）が通信記録ＤＢ１１０に格納されているものとする。同様に、識別フェーズを開始する前に、識別フェーズに必要な情報（すなわち、通信時刻、通信元アドレス及び通信先ホスト）が通信記録ＤＢ１１０に格納されているものとする。

＜機能構成＞
次に、本発明の実施の形態における端末識別処理部１００の機能構成について、図５を参照しながら説明する。図５は、本発明の実施の形態における端末識別処理部１００の機能構成の一例を示す図である。

図５に示すように、本発明の実施の形態における端末識別処理部１００には、集合作成部１０１と、学習データ作成部１０２と、識別器作成部１０３と、識別部１０４とが含まれる。

集合作成部１０１は、学習フェーズにおいて、予め決められた時間ウインドウＴ（すなわち、予め決められた時間幅）毎に、通信記録ＤＢ１１０に格納されている通信元アドレスａと、通信先ホストｈと、端末種別ｄとを取得する。そして、集合作成部１０１は、通信元アドレスａ毎に、通信先ホストｈと、端末種別ｄとの組の集合Ｒ_ｔ，ａを作成する。

ここで、ｔは、時間ウインドウＴ毎に取得された通信元アドレスａと、通信先ホストｈと、端末種別ｄとを代表する時刻である。例えば、ある時刻をＴ_１として、Ｔ_１以上、Ｔ_１＋Ｔ未満の通信時刻に対応付けられていた通信元アドレスａ、通信先ホストｈ及び端末種別ｄのｔは、Ｔ_１≦ｔ＜Ｔ_１＋Ｔを満たす任意の時刻（例えば、ｔ＝Ｔ_１）とすれば良い。また、例えば、Ｔ_１＋Ｔ以上、Ｔ_１＋２Ｔ未満の通信時刻に対応付けられていた通信元アドレスａ、通信先ホストｈ及び端末種別ｄのｔは、Ｔ_１＋Ｔ≦ｔ＜Ｔ_１＋２Ｔを満たす任意の時刻（例えば、ｔ＝Ｔ_１＋Ｔ）とすれば良い。同様に、例えば、Ｔ_１＋ｎＴ以上、Ｔ_１＋（ｎ＋１）Ｔ未満の通信時刻に対応付けられていた通信元アドレスａ、通信先ホストｈ及び端末種別ｄのｔは、Ｔ_１＋ｎＴ≦ｔ＜Ｔ_１＋（ｎ＋１）Ｔを満たす任意の時刻（例えば、ｔ＝Ｔ_１＋ｎＴ）とすれば良い。

また、集合作成部１０１は、識別フェーズにおいて、予め決められた時間ウインドウＴ毎に、通信記録ＤＢ１１０に格納されている通信元アドレスａと、通信先ホストｈとを取得する。そして、集合作成部１０１は、通信元アドレスａ毎に、通信先ホストｈの集合Ｓ_ｔ，ａを作成する。

学習データ作成部１０２は、学習フェーズにおいて、集合作成部１０１により作成された集合Ｒ_ｔ，ａに対して正解ラベルｄ´を割り当てることで学習データを作成する。正解ラベルｄ´とは、当該集合Ｒ_ｔ，ａの代表となる端末種別のことである。正解ラベルｄ´は、例えば、端末種別を表す文字又は文字列で表される。

識別器作成部１０３は、学習フェーズにおいて、学習データ作成部１０２により作成された学習データを用いて、機械学習の手法により端末識別器２００を作成する。識別器作成部１０３により作成された端末識別器２００は、例えば、補助記憶装置１８等に記憶される。

識別部１０４は、識別フェーズにおいて、端末識別器２００を用いて、集合作成部１０１により作成された集合Ｓ_ｔ，ａから、当該通信元アドレスａにより特定されるユーザ端末２０の端末種別ｄ´を識別する。

＜学習フェーズにおける処理の詳細＞
次に、端末識別処理部１００の学習フェーズにおける処理の詳細について、図６を参照しながら説明する。図６は、端末識別処理部１００の学習フェーズにおける処理の一例を示すフローチャートである。

ステップＳ６０１）集合作成部１０１は、集合Ｒ_ｔ，ａを作成する。集合作成部１０１は、以下のようにして集合Ｒ_ｔ，ａを作成することができる。

まず、集合作成部１０１は、予め決められた時間ウインドウＴ毎に、通信記録ＤＢ１１０に格納されている通信元アドレスａと、通信先ホストｈと、端末種別ｄとを取得する。このとき、通信元アドレスａと、通信先ホストｈと、端末種別ｄとの組を示すレコードを識別する変数をｉとすれば、ｔにおけるレコードｒ_ｔ，ｉの集合Ｒ_ｔは、以下の数１で表される。

なお、ａ_ｔ，ｉ、ｈ_ｔ，ｉ及びｄ_ｔ，ｉは、それぞれｔにおけるｉ番目のレコードｒ_ｔ，ｉに含まれる通信元アドレスａ、通信先ホストｈ及び端末種別ｄである。

次に、集合作成部１０１は、通信元アドレスａ毎に各ｒ_ｔ，ｉを集約することで、通信先ホストｈと、端末種別ｄとの組を示すレコードを作成する。このとき、通信先ホストｈと、端末種別ｄとの組を示すレコードを識別する変数をｊとすれば、ｊ番目のレコードｒ_{ｔ，ａ，ｊ}の集合Ｒ_ｔ，ａは、以下の数２で表される。

なお、ｈ_{ｔ，ａ，ｊ}及びｄ_{ｔ，ａ，ｊ}は、それぞれｔにおいて通信元アドレスａでレコードｒ_ｔ，ｉを集約した場合におけるｊ番目のレコードｒ_{ｔ，ａ，ｊ}に含まれる通信先ホストｈ及び端末種別ｄである。

ステップＳ６０２）学習データ作成部１０２は、上記のステップＳ６０１で作成された集合Ｒ_ｔ，ａに対して正解ラベルｄ´を割り当てることで学習データを作成する。学習データ作成部１０２は、以下のように学習データを作成することができる。

まず、学習データ作成部１０２は、集合Ｒ_ｔ，ａに含まれる各端末種別ｄを抽象化する。これは、例えば、ＨＴＴＰヘッダのＵｓｅｒ−Ａｇｅｎｔフィールドを端末種別として用いた場合等には、端末種別を示す表記が統一されていない場合があるためである。

より具体的に説明すると、ユーザ端末２０の端末種別が「Ｌｉｎｕｘ」であっても、あるユーザ端末２０ではＨＴＴＰヘッダのＵｓｅｒ−Ａｇｅｎｔフィールドに「ｌｉｎｕｘ」と設定され、別のあるユーザ端末２０ではＨＴＴＰヘッダのＵｓｅｒ−Ａｇｅｎｔフィールドに「ｕｂｕｎｔｕ」と設定されることがある。したがって、この場合、例えば、「ｌｉｎｕｘ」や「ｕｂｕｎｔｕ」等を、統一的な表記である「Ｌｉｎｕｘ」に抽象化する必要がある。

次に、学習データ作成部１０２は、集合Ｒ_ｔ，ａに対して正解ラベルｄ´を割り当てる。ここで、集合Ｒ_ｔ，ａには、端末種別が不明であることを示す情報が含まれるレコードｒ_{ｔ，ａ，ｊ}が存在することがある。また、集合Ｒ_ｔ，ａには、それぞれ異なる端末種別ｄが含まれるレコードｒ_{ｔ，ａ，ｊ}が存在することがある。このため、学習データ作成部１０２は、集合Ｒ_ｔ，ａに対して正解ラベルｄ´を一意に決定できないことがある。

そこで、学習データ作成部１０２は、任意の方法で、集合Ｒ_ｔ，ａに存在するレコードｒ_{ｔ，ａ，ｊ}の中から正解ラベルｄ´を選択すれば良い。例えば、集合Ｒ_ｔ，ａに存在するレコードｒ_{ｔ，ａ，ｊ}の中で、最も数が多い（すなわち、最も出現回数が多い）端末種別ｄを正解ラベルｄ´としても良いし、人間の経験則に基づいて手動で正解ラベルｄ´を選択しても良い。

正解ラベルｄ´が選択された場合、学習データ作成部１０２は、集合Ｒ_ｔ，ａに対して正解ラベルｄ´を割り当てる。これにより、学習データが作成される。すなわち、学習データは、集合Ｒ_ｔ，ａと、正解ラベルｄ´との組で表される。

ただし、学習データには、集合Ｒ_ｔ，ａに含まれる端末種別ｄが不要である場合もある。この場合、学習データは、通信先ホストｈ_{ｔ，ａ，ｊ}の集合と、正解ラベルｄ´との組であっても良い。

ステップＳ６０３）識別器作成部１０３は、上記のステップＳ６０２で作成された学習データを用いて、機械学習の手法により端末識別器２００を作成する。すなわち、識別器作成部１０３は、機械学習の手法により、学習データに含まれる通信先ホストｈの集合と、正解ラベルｄ´との関係性を学習させることで、端末識別器２００を作成する。

端末識別器２００には、通信先ホストｈの集合を入力として、正解ラベルｄ´を推定するために必要なデータが含まれる。端末識別器２００のデータ形式等は、識別器作成部１０３が利用する機械学習アルゴリズム又はその実装により異なる。機械学習アルゴリズムの要件は、以下の数３に示す関数ｆのように、通信先ホストｈのリスト（集合）から端末種別ｄ´を推定する処理を実施できることである。

機械学習アルゴリズムとしては、一般に、多クラス分類問題を解くができる任意のアルゴリズムを利用可能である。このようなアルゴリズムの一例としては、ランダムフォレストが挙げられる。ランダムフォレストについては、例えば「A. Liaw and M. Wiener (2002). Classification and Regression by randomForest. R News 2(3), 18-22.」等に開示されている。

以上により、本発明の実施の形態における端末識別装置１０は、識別フェーズにおいてユーザ端末２０の通信先ホストから端末種別を識別するための端末識別器２００を作成することができる。

＜識別フェーズにおける処理の詳細＞
次に、端末識別処理部１００の識別フェーズにおける処理の詳細について、図７を参照しながら説明する。図７は、端末識別処理部１００の識別フェーズにおける処理の一例を示すフローチャートである。

ステップＳ７０１）集合作成部１０１は、集合Ｓ_ｔ，ａを作成する。集合作成部１０１は、以下のようにして集合Ｓ_ｔ，ａを作成することができる。

まず、集合作成部１０１は、予め決められた時間ウインドウＴ毎に、通信記録ＤＢ１１０に格納されている通信元アドレスａと、通信先ホストｈとを取得する。このとき、通信元アドレスａと、通信先ホストｈとの組を示すレコードを識別する変数をｋとすれば、ｔにおけるレコードｒ_ｔ，ｋの集合Ｓ_ｔは、以下の数４で表される。

なお、ａ_ｔ，ｋ及びｈ_ｔ，ｋ及びｄ_ｔ，ｉは、それぞれｔにおけるｋ番目のレコードｒ_ｔ，ｋに含まれる通信元アドレスａ及び通信先ホストｈである。

次に、集合作成部１０１は、通信元アドレスａ毎に各ｒ_ｔ，ｋを集約することで、通信先ホストｈを示すレコードを作成する。このとき、通信先ホストｈを示すレコードを識別する変数をｍとすれば、ｍ番目のレコードｒ_{ｔ，ａ，ｍ}の集合Ｓ_ｔ，ａは、以下の数５で表される。

なお、ｈ_{ｔ，ａ，ｍ}は、ｔにおいて通信元アドレスａでレコードｒ_ｔ，ｋを集約した場合におけるｍ番目のレコードｒ_{ｔ，ａ，ｍ}に含まれる通信先ホストｈである。

ステップＳ７０２）識別部１０４は、端末識別器２００を用いて、上記のステップＳ７０１で作成された集合Ｓ_ｔ，ａから端末種別ｄ´を識別する。すなわち、識別部１０４は、端末識別器２００を用いて、集合Ｓ_ｔ，ａに含まれる通信先ホストｈ_{ｔ，ａ，ｍ}の集合から端末種別ｄ´を識別する。

そして、識別部１０４は、通信元アドレスａと、端末種別ｄ´とを対応付けて識別結果ＤＢ１２０に格納する。

以上により、本発明の実施の形態における端末識別装置１０は、通信先ホストから端末種別を識別することができる。このため、本発明の実施の形態における端末識別装置１０では、例えば、ユーザ端末２０の製造元ベンダ等によりプリインストールされたアプリケーションプログラム等に依存した通信先ホストサーバ５０の差異によって、ユーザ端末２０の端末種別を識別することができる。同様に、例えば、ユーザ端末２０の利用形態（例えば、モバイル端末や固定端末等）に伴う利用サービスの差異（すなわち、通信先ホストサーバ５０の差異）によっても、ユーザ端末２０の端末種別を識別することができる。

したがって、本発明の実施の形態における端末識別装置１０によれば、例えば、ユーザ端末２０間でネットワーク・パラメータが共通であったとしても、端末種別に応じて通信先ホストに差異があれば、ユーザ端末２０の端末種別を識別することができるようになる。

＜具体例＞
以降では、本発明の実施の形態における端末識別の具体例について述べる。ＨＴＴＰ通信とＤＮＳ通信との両方のトラヒックをトラヒック収集装置３０による収集対象とした上で、数千ユーザ規模の１２時間分のトラヒックから通信時刻、通信元アドレス、通信先ホスト及び端末種別を抽出して通信記録ＤＢ１１０に格納した。また、端末識別処理部１００が通信記録ＤＢ１１０から情報を抽出する際の時間ウインドウＴは５分とした。このとき、通信先ホストは、約３万件を抽出した。

更に、図６のステップＳ６０２において、ＨＴＴＰヘッダのＵｓｅｒ−Ａｇｅｎｔフィールドに含まれる文字列と、抽象化後の端末種別（正解ラベル）との関係は以下の（１）〜（４）の通りとした上で、学習データを作成した。Ｕｓｅｒ−Ａｇｅｎｔフィールドに含まれる文字列を判定する際、大文字と小文字の区別はないものとした。なお、いずれの端末種別にも抽象化できない場合には、識別不能を示す正解ラベルとした。

（１）Ｕｓｅｒ−Ａｇｅｎｔフィールドに含まれる文字列が大文字と小文字を区別せず「ｉＰｈｏｎｅ（登録商標）」、「ｉＰａｄ（登録商標）」、「ｉＰｏｄ（登録商標）」、「ｗａｔｃｈＯＳ（登録商標）」、又は「Ａｐｐｌｅ ＴＶ（登録商標）」（空白を除外した文字列（例えば、「ＡｐｐｌｅＴＶ」）も含む。）のいずれかである場合には、端末種別「ｉＯＳ（登録商標）」とする。

（２）Ｕｓｅｒ−Ａｇｅｎｔフィールドに含まれる文字列が大文字と小文字を区別せず「Ａｎｄｒｏｉｄ」である場合には、端末種別「Ａｎｄｒｏｉｄ」とする。

（３）Ｕｓｅｒ−Ａｇｅｎｔフィールドに含まれる文字列が大文字と小文字を区別せず「Ｌｉｎｕｘ」又は「Ｕｂｕｎｔｕ（登録商標）」である場合には、端末種別「Ｌｉｎｕｘ」とする。

（４）Ｕｓｅｒ−Ａｇｅｎｔフィールドに含まれる文字列が大文字と小文字を区別せず「Ｍｉｃｒｏｓｏｆｔ（登録商標）」又は「Ｗｉｎｄｏｗｓ」である場合には、端末種別「Ｗｉｎｄｏｗｓ」とする。

そして、上記で作成した学習データを用いて、端末識別器２００を作成した。続いて、ＤＮＳ通信のＦＱＤＮをユーザ端末２０毎の通信先ホストとして識別フェーズを行った結果、以下の（Ａ）〜（Ｃ）の通信元アドレスと端末種別との識別結果が得られた。

（Ａ）通信元アドレス「ａ．ａ．ａ．ａ」のユーザ端末２０は端末種別「ｉＯＳ」
（Ｂ）通信元アドレス「ｂ．ｂ．ｂ．ｂ」のユーザ端末２０は端末種別「Ａｎｄｒｏｉｄ」
（Ｃ）通信元アドレス「ｃ．ｃ．ｃ．ｃ」のユーザ端末２０は端末種別「Ｗｉｎｄｏｗｓ」
上記の（Ａ）〜（Ｃ）の識別結果は、別途平行して収集したＨＴＴＰ通信におけるＨＴＴＰヘッダのＵｓｅｒ−Ａｇｅｎｔフィールドに設定されている端末種別と一致していることを確認した。このため、本発明の実施の形態における端末識別装置１０によれば、高い精度で、通信先ホストから端末種別を識別できていることがわかる。

＜同一のネットワーク・パラメータを有するユーザ端末２０における端末識別＞
ここで、同一のネットワーク・パラメータを有するユーザ端末２０における端末識別について補足する。ネットワーク・パラメータとＯＳとに関する調査文献（例えば、「MONTIGNY-LEBOEUF, De, et al. A multi-packet signature approach to passive operating system detection. DEFENCE RESEARCH AND DEVELOPMENT CANADAOTTAWA (ONTARIO), 2005.」）によれば、例えば、Ｌｉｎｕｘ２．４．０とＭａｃＯＳ１０．２．６とは、環境によっては、同一の初期ＴＴＬ値と、ＴＣＰパラメータ又はＳＹＮヘッダパラメータとを有する（ただし、実際にはカーネル・パラメータやパッチの適用状態等で異なる場合もある。）。

このため、Ｌｉｎｕｘ２．４．０とＭａｃＯＳ１０．２．６とは、非特許文献１に開示されているパケットシグネチャを用いる方法では区別することができない。仮に、ＯＳの設定によりネットワーク・パラメータが変化した場合においても、この変化はＬｉｎｕｘ２．４．０及びＭａｃＯＳ１０．２．６の両者で発生する可能性がある。このため、ＯＳの設定による変化を、Ｌｉｎｕｘ２．４．０及びＭａｃＯＳ１０．２．６の両者を区別するシグネチャとして用いるのは困難である。

一方で、例えば、Ｌｉｎｕｘには、固有の通信先ホスト（例えば、ＯＳリポジトリ・サーバ、各ソフトウェアのバージョン更新用のサーバ等）が存在する。同様に、ＭａｃＯＳにも固有の通信先ホスト（例えば、ＯＳバージョン確認用のサーバ、クラウドアプリの同期用サーバ等）が存在する。

したがって、本発明の実施の形態における端末識別装置１０では、各ＯＳ固有の通信先ホストの差異を特徴として、これらのＯＳを識別することができる。

本発明は、具体的に開示された上記の実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。

１０ 端末識別装置
２０ ユーザ端末
３０ トラヒック収集装置
４０ ＤＮＳキャッシュサーバ
５０ 通信先ホストサーバ
１００ 端末識別処理部
１０１ 集合作成部
１０２ 学習データ作成部
１０３ 識別器作成部
１０４ 識別部
１１０ 通信記録ＤＢ
１２０ 識別結果ＤＢ

Claims (6)

1. ネットワークに収容される第１の端末の通信トラヒックから、該第１の端末の通信先を示す通信先ホストのリストを作成するリスト作成部と、
   前記リスト作成部が作成した通信先ホストのリストと、予め作成された識別器とから、前記第１の端末の端末種別を識別する識別部と、
   を有することを特徴とする端末識別装置。
2. 予め蓄積された通信トラヒックから、該通信トラヒックの発生元の第２の端末と、該第２の端末の通信先ホストとの集合を作成する集合作成部と、
   前記集合作成部が作成した集合に対して、前記第２の端末の端末種別を示す正解ラベルを割り当てることで、学習データを作成する学習データ作成部と、
   前記学習データ作成部が作成した学習データを用いて、機械学習の手法により、前記端末種別を識別するための識別器を作成する識別器作成部と、を有し、
   前記識別部は、
   前記リスト作成部が作成した通信先ホストのリストと、前記識別器作成部が作成した識別器とから、前記第１の端末の端末種別を識別する、ことを特徴とする請求項１に記載の端末識別装置。
3. 前記集合作成部は、
   前記通信トラヒックの発生元の第２の端末と、該第２の端末の通信先ホストと、前記第２の端末の端末種別との集合を作成し、
   前記学習データ作成部は、
   前記集合作成部が作成した集合に対して、該集合に含まれる端末種別のうち、最も出現回数が多い端末種別又はユーザにより選択された端末種別のいずれかを示す正解ラベルを割り当てることで、学習データを作成する、ことを特徴とする請求項２に記載の端末識別装置。
4. 前記通信トラヒックは、ＨＴＴＰ通信、ＨＴＴＰＳ通信及びＤＮＳ通信のうちの少なくとも１つの通信により発生する通信トラヒックである、ことを特徴とする請求項１乃至３の何れか一項に記載の端末識別装置。
5. ネットワークに収容される第１の端末の通信トラヒックから、該第１の端末の通信先を示す通信先ホストのリストを作成するリスト作成手順と、
   前記リスト作成手順が作成した通信先ホストのリストと、予め作成された識別器とから、前記第１の端末の端末種別を識別する識別手順と、
   をコンピュータが実行することを特徴とする端末識別方法。
6. ネットワークに収容される第１の端末の通信トラヒックから、該第１の端末の通信先を示す通信先ホストのリストを作成するリスト作成手順と、
   前記リスト作成手順が作成した通信先ホストのリストと、予め作成された識別器とから、前記第１の端末の端末種別を識別する識別手順と、
   をコンピュータに実行させることを特徴とするプログラム。

Images