特開 2022-49717 通信装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2022049717

(43)【公開日】2022-03-30

(54)【発明の名称】通信装置

(51)【国際特許分類】

   H04L 12/22 20060101AFI20220323BHJP

【ＦＩ】

H04L12/66 B

【審査請求】未請求

【請求項の数】7

【出願形態】ＯＬ

(21)【出願番号】P 2019015817

(22)【出願日】2019-01-31

【国等の委託研究の成果に係る記載事項】（出願人による申告）平成３０年度、国立研究開発法人科学技術振興機構、戦略的創造研究推進事業（ＣＲＥＳＴ）、産業技術力強化法第１９条の適用を受ける特許出願

(71)【出願人】

【識別番号】504137912

【氏名又は名称】国立大学法人 東京大学

(74)【代理人】

【識別番号】100142468

【弁理士】

【氏名又は名称】高山 裕志

(72)【発明者】

【氏名】岡田 和也

【テーマコード（参考）】

5K030

【Ｆターム（参考）】

5K030GA15

5K030HD09

5K030KA07

5K030MA04

(57)【要約】      （修正有）

【課題】サイバー攻撃をリアルタイムで検知する。
【解決手段】ネットワークに接続された端末からサーバー装置にアクセスする場合にサーバー装置が悪性ホストであるか否かを判定する通信装置であって、端末は、サーバー装置の絶対ドメイン名を含む名前解決要求をＤＮＳサーバーに送信し、ＤＮＳサーバーから送信された名前解決結果に基づいてサーバー装置との通信を開始する。通信装置は、サーバー装置が悪性ホストであるか否かを判定する判定部を備え、ＤＮＳサーバーに送信する名前解決要求を受信した場合には、名前解決要求に含まれる絶対ドメイン名に基づいてサーバー装置が悪性ホストであるか否かを判定し、サーバー装置が悪性ホストであるか否かの判定結果が導出されたか否かに関わらず名前解決要求をＤＮＳサーバーに送信し、ＤＮＳサーバーから名前解決結果を受信した場合には判定結果に基づいてサーバー装置が悪性ホストであるか否かを判定する。
【選択図】図４

【特許請求の範囲】

【請求項1】

ネットワークに接続された端末からサーバー装置にアクセスする場合に当該サーバー装置が悪性ホストであるか否かを判定する通信装置であって、
前記端末は、前記サーバー装置の絶対ドメイン名を含む名前解決要求を、当該絶対ドメイン名に対応するＩＰアドレスを特定するＤＮＳサーバーに送信し、
前記ＤＮＳサーバーは、前記名前解決要求に含まれる絶対ドメイン名に対応するＩＰアドレスを特定し、当該特定されたＩＰアドレスを含む名前解決結果を前記端末に送信し、
前記端末は、前記ＤＮＳサーバーから送信された名前解決結果に基づいて、前記サーバー装置との通信を開始し、
前記通信装置は、
前記端末から送信されたデータを、当該データの送信先にかかわらず受信するデータ受信部と、
前記サーバー装置が悪性ホストであるか否かを判定する判定部と、
前記データ受信部が受信したデータを、当該データの送信先に送信するデータ送信部と、
を備え、
前記データ受信部が前記ＤＮＳサーバーに送信する名前解決要求を受信した場合には、前記判定部が、当該名前解決要求に含まれる絶対ドメイン名に基づいて、前記サーバー装置が悪性ホストであるか否かを判定し、
前記データ送信部は、前記サーバー装置が悪性ホストであるか否かの判定結果が導出されたか否かに関わらず前記名前解決要求を前記ＤＮＳサーバーに送信し、
前記データ受信部が前記ＤＮＳサーバーから前記名前解決結果を受信した場合には、前記判定部が、当該名前解決結果に対応する名前解決要求による判定結果に基づいて、前記サーバー装置が悪性ホストであるか否かを判定することを特徴とする通信装置。

【請求項2】

請求項１に記載の通信装置において、
前記データ受信部が前記ＤＮＳサーバーから前記名前解決結果を受信したタイミングで前記名前解決要求による判定結果が導出されていない場合には、当該名前解決結果を前記端末に送信し、
前記データ受信部が前記端末から前記サーバー装置に対するアクセス要求を受信した場合には、前記判定部が、前記名前解決要求による判定結果に基づいて、前記サーバー装置が悪性ホストであるか否かを判定することを特徴とする通信装置。

【請求項3】

請求項１又は請求項２に記載の通信装置において、
前記端末と前記サーバー装置との通信を制御する通信制御部をさらに備え、
前記通信制御部は、前記サーバー装置が悪性ホストであると判定された場合には、前記端末と前記サーバー装置との通信を遮断することを特徴とする通信装置。

【請求項4】

請求項１から請求項３のいずれか１項に記載の通信装置において、
前記判定部による判定結果に基づいて学習データを生成し、当該学習データを蓄積する学習部をさらに備え、
前記判定部は、前記蓄積された学習データに基づいて、前記サーバー装置が悪性ホストであるか否かを判定することを特徴とする通信装置。

【請求項5】

請求項４に記載の通信装置において、
前記判定部は、
悪性ホストでないサーバー装置の絶対ドメイン名が記憶されたドメインホワイトリストを有し、
前記学習データに基づく判定結果を前記ドメインホワイトリストに反映し、
前記ドメインホワイトリストに基づいて、前記サーバー装置が悪性ホストでないことを判定することを特徴とする通信装置。

【請求項6】

請求項４又は請求項５に記載の通信装置において、
前記判定部は、
悪性ホストであるサーバー装置の絶対ドメイン名が記憶されたドメインブラックリストを有し、
前記学習データに基づく判定結果を前記ドメインブラックリストに反映し、
前記ドメインブラックリストに基づいて、前記サーバー装置が悪性ホストであることを判定することを特徴とする通信装置。

【請求項7】

請求項６に記載の通信装置において、
前記判定部は、
悪性ホストであるサーバー装置のＩＰアドレスが記憶されたＩＰブラックリストを有し、
前記ドメインブラックリストに基づく判定結果を前記ＩＰブラックリストに反映し、
前記ＩＰブラックリストに基づいて、前記サーバー装置が悪性ホストであることを判定することを特徴とする通信装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ネットワークにおける不正な通信を検知する技術に関する。

【背景技術】

【0002】

近年、ネットワークサービスに対して個人や組織を狙ったサイバー攻撃が行われ、甚大な被害が発生している。これらの攻撃からネットワークに接続されたＷｅｂサーバーなどの通信機器を防御するために種々の攻撃検知方法が提案されているが、攻撃者は攻撃手法を頻繁に変更したり、巧妙化したりすることで検知を困難にしていた。従来の攻撃検知方法は、過去に攻撃を受けた手法を検知するものであり、新たな手法による攻撃を検知することは困難であった。

【0003】

そこで、大規模なトラフィックデータから異常な通信を行う端末のＩＰアドレス群を検知することによって攻撃を行っているホスト（悪性ホスト）を特定する技術などが提案されている（例えば、特許文献１参照）。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２０１８－１４８２７０号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

しかしながら、サイバー攻撃の検知はできるだけ早期に行う必要があるが、大規模なトラフィックデータを解析するためには多くの処理時間を必要とした。特に、未知の攻撃を検知するために、通信されるパケットを機械学習によりリアルタイムで攻撃の検知を行うことは困難であった。

【0006】

本発明は、上記事情に鑑みなされたもので、サイバー攻撃をリアルタイムに検知する技術の提供を目的とする。

【課題を解決するための手段】

【0007】

本発明の代表的な一形態によれば、ネットワークに接続された端末からサーバー装置にアクセスする場合に当該サーバー装置が悪性ホストであるか否かを判定する通信装置であって、前記端末は、前記サーバー装置の絶対ドメイン名を含む名前解決要求を、当該絶対ドメイン名に対応するＩＰアドレスを特定するＤＮＳサーバーに送信し、前記ＤＮＳサーバーは、前記名前解決要求に含まれる絶対ドメイン名に対応するＩＰアドレスを特定し、当該特定されたＩＰアドレスを含む名前解決結果を前記端末に送信し、前記端末は、前記ＤＮＳサーバーから送信された名前解決結果に基づいて、前記サーバー装置との通信を開始し、前記通信装置は、前記端末から送信されたデータを、当該データの送信先にかかわらず受信するデータ受信部と、前記サーバー装置が悪性ホストであるか否かを判定する判定部と、前記データ受信部が受信したデータを、当該データの送信先に送信するデータ送信部と、を備え、前記データ受信部が前記ＤＮＳサーバーに送信する名前解決要求を受信した場合には、前記判定部が、当該名前解決要求に含まれる絶対ドメイン名に基づいて、前記サーバー装置が悪性ホストであるか否かを判定し、前記データ送信部は、前記サーバー装置が悪性ホストであるか否かの判定結果が導出されたか否かに関わらず前記名前解決要求を前記ＤＮＳサーバーに送信し、前記データ受信部が前記ＤＮＳサーバーから前記名前解決結果を受信した場合には、前記判定部が、当該名前解決結果に対応する名前解決要求による判定結果に基づいて、前記サーバー装置が悪性ホストであるか否かを判定することを特徴とする。

【発明の効果】

【0008】

本発明の代表的な実施形態によると、通信速度の低下を利用者に感じさせることなくサイバー攻撃をリアルタイムで検知可能となる。

【図面の簡単な説明】

【0009】

【図1】本発明の実施形態の悪性ホストへのアクセスをリアルタイムに検知するパケット分類装置（通信装置）を含む通信システムの概要を説明する図である。

【図2】本発明の実施形態のネットワーク構成の一例を示す図である。

【図3】本発明の実施形態のパケット分類装置のハードウェア構成及びソフトウェアの構成の一例を示す図である。

【図4】本実施形態のパケット分類装置がパケットを転送するための構成の一例を示す図である。

【図5】本実施形態において端末がＷｅｂサーバーと通信を開始するまでの各工程の処理時間を示す図である。

【図6】本発明の実施の形態における悪性ホストを検知するタイミングを説明する図である。

【図7】本発明の実施形態において端末がＤＮＳサーバーに名前解決要求を送信するタイミングＴ１で悪性ホストを検知するための構成を説明する図である。

【図8】本発明の実施形態において端末がＤＮＳサーバーから名前解決結果を受信するタイミングＴ２で悪性ホストを検知するための構成を説明する図である。

【図9】本発明の実施形態において端末が接続先のＷｅｂサーバーにアクセスするタイミングＴ３で悪性ホストを検知するための構成を説明する図である。

【発明を実施するための形態】

【0010】

ネットワークに接続された端末から別のネットワークに接続されたサーバー装置（例えば、ＷＥＢサーバー）にアクセスする場合、まず、接続先のサーバー名（絶対ドメイン名）によってＤＮＳサーバーから接続先のＩＰアドレスを特定する（名前解決）。本実施形態では、名前解決を行っている間に接続先のサーバー装置が悪性ホスト（サイバー攻撃を行う計算機）であるか否かを判定する。接続先のサーバー装置を悪性ホストでない（良性ホスト）と判定した場合にはそのまま通信を継続し、悪性ホストと判定された場合には通信を遮断する。名前解決を行うための時間は通常の通信に必要な時間であるため、この間に悪性ホストを検知するための処理を行っても利用者は遅延を体感させる可能性は少ない。以下、添付図面を参照しながら本発明の実施形態について説明する。

【0011】

図１は、本発明の実施形態の悪性ホストへのアクセスをリアルタイムに検知するパケット分類装置（通信装置）を含む通信システムの概要を説明する図である。本実施形態ではＴＣＰ／ＩＰによる通信を対象とするが、他のプロトコルによる通信でも本発明を適用可能である。また、本実施形態では、利用者が端末を操作し、外部のネットワークに接続されたサーバー装置（例えば、Ｗｅｂサーバー）にアクセスする場合を想定している。

【0012】

利用者が端末を操作して外部のネットワークに接続されたＷｅｂサーバーにアクセスする場合、まず、接続先のＷｅｂサーバーのＩＰアドレスをＤＮＳサーバーに問い合わせて特定し、その後、特定されたＩＰアドレスに基づいてＷｅｂサーバーとの通信を開始する。このとき、利用者が端末の操作から指定したサイトを参照するまで待機する時間は、名前解決に要する時間、Ｗｅｂサーバーとの通信時間、及び、Ｗｅｂサーバーから受信したデータを端末で処理する時間となる。したがって、名前解決が完了し、接続先のＷｅｂサーバーとの通信を開始するまでの間に接続先のＷｅｂサーバーが悪性ホストであるか否かを判定することで悪性ホストへのアクセスを阻止することができる。

【0013】

続いて、本発明の実施形態における悪性ホストの検知方法を適用するネットワーク構成例について説明する。図２は、本発明の実施形態のネットワーク構成の一例を示す図である。本実施形態では、外部ネットワーク（第１ネットワーク）１０に接続されたＷｅｂサーバー１１と、内部ネットワーク（第２ネットワーク）２０に接続された端末２１との間で通信が行われる。

【0014】

外部ネットワーク１０と内部ネットワーク２０との間には、各ネットワークを相互接続する通信機器（ルーター４０）が配置される。さらに、端末２１が接続しようとするＷｅｂサーバー１１が悪性ホストであるか否かを判定するパケット分類装置（通信装置）１００がルーター４０と内部ネットワーク２０との間に配置されている。なお、パケット分類装置１００は、内部ネットワーク２０の内部に設置してもよい。本実施形態では、端末２１から外部ネットワーク１０に接続されたＷｅｂサーバー１１等の計算機に接続する場合、パケット分類装置１００を経由してＤＮＳキャッシュサーバー（ＤＮＳサーバー）３０に接続し、通信先の計算機のＩＰアドレスを特定する。ＤＮＳキャッシュサーバー３０が接続先のサーバー名（絶対ドメイン名）を特定できなかった場合には、ネットワーク経由で複数の権威ＤＮＳサーバー６０に再帰的に問い合わせて絶対ドメイン名を解決する。以降、ＤＮＳキャッシュサーバー３０と権威ＤＮＳサーバー６０を合わせてＤＮＳサーバーとする。

【0015】

パケット分類装置１００は、端末２１の接続先（Ｗｅｂサーバー１１）を悪性ホストと判定した（悪性ホストに分類した）場合には、外部ネットワーク１０に接続されたＷｅｂサーバー１１との通信を遮断する。このとき、ルーター４０、パケット分類装置１００等のネットワーク機器を管理するための管理計算機（図示せず）に分類結果（警報）を通知し、警告メッセージを表示するなどして管理者に報知するようにしてもよい。また、パケット分類装置１００が通信を遮断せずに、ルーター４０に指示して悪性ホストとの通信を遮断するようにしてもよい。

【0016】

また、本実施形態では、悪性ホストであるか否かを択一的に判定するものでなくてもよい。例えば、悪性ホストの判定値を１００、良性ホストの判定値を０とし、０から１００の判定値で悪性ホストである可能性を判定するのであれば、判定値が所定の閾値以上の場合には通信を遮断し、判定値が所定範囲内であれば警告メッセージを表示して利用者の判断で接続するか否かを選択するようにしてもよい。この場合、パケット分類装置１００に悪性ホストの判定結果のログを記録し、実際に悪性ホストであったか否かを判定可能としておくとよい。また、管理計算機に通知し、管理計算機がログを記録するようにしてもよい。さらに、パケット分類装置１００で通信ログを記録し、悪性ホストの可能性がある場合のみ管理計算機に通知するようにしてもよい。

【0017】

パケット分類装置１００は、悪性ホストの接続を阻止するために、外部のネットワークにアクセスする場合に必ずパケットが通過する箇所に配置される。また、ネットワーク内に配置されるパケット分類装置１００は単一であってもよいし、複数であってもよい。複数配置する場合には、トラフィックの増大を防ぐために、パケットが複数のパケット分類装置１００を通過することを避けるように配置するとよい。

【0018】

続いて、パケット分類装置１００のハードウェア及びソフトウェアの構成について説明する。図３は、本発明の実施形態のパケット分類装置１００のハードウェア構成及びソフトウェアの構成の一例を示す図である。パケット分類装置１００は、通信インターフェース（ＩＦ）１０１、プロセッサ（ＣＰＵ）１１０、メモリ１２０及び記憶装置１６０を備え、各構成はバスによって接続される。

【0019】

通信インターフェース（ＩＦ）１０１は、端末２１、ＤＮＳキャッシュサーバー３０などから転送されたパケットを受信したり、管理計算機からの命令入力を受け付けたりする。プロセッサ（ＣＰＵ）１１０は、メモリ１２０に記憶された各種プログラムを実行することによって各種機能を提供し、例えば、端末２１の接続先（Ｗｅｂサーバー１１）が悪性ホストであるか否かを判定する機能を提供する。メモリ１２０は、プロセッサ１１０によって実行される各種プログラムを記憶したり、プログラムの実行に必要なデータを一時的に記憶したりする。記憶装置１６０は、通信インターフェース（ＩＦ）１０１を介して受信したパケットの情報（例えば、名前解決要求に含まれる接続先（Ｗｅｂサーバー１１）の絶対ドメイン名、名前解決結果に含まれる接続先（Ｗｅｂサーバー１１）のＩＰアドレス等）を蓄積したり、プログラムによる処理結果（端末２１の接続先が悪性ホストであるか否かの判定結果等）を格納したりする。

【0020】

次に、メモリ１２０及び記憶装置１６０の構成について説明する。メモリ１２０には、パケットの通信制御を行う通信制御部１２１と、端末２１と通信する計算機が悪性ホストであるか否かを判定する検知部（判定部）１３０を記憶する。本実施形態では、悪性ホストを判定（分類）する手法は任意の方法でよいが、パケットの送信先となるサーバー装置の絶対ドメイン名、ＩＰアドレスなどの情報を蓄積し、学習することによって悪性ホストであるか否かを判定する手法を採用している。また、メモリ１２０は、悪性ホストを検知する精度を向上させるために学習データを収集及び生成する学習部１４０を記憶する。検知部１３０及び学習部１４０は、プログラム及び当該プログラムを実行するためのデータによって構成される。記憶装置１６０は、パケットデータ格納部１６１及び学習データ格納部１６２を提供する。以下、各構成について説明する。

【0021】

検知部１３０は、端末２１の接続先が悪性ホストであるか否かを判定する。検知部１３０は、解析部１３１、特徴抽出部１３２及び分類部１３３を含む。解析部１３１は、通信ＩＦ１０１から取得したパケットを一時的に記憶し、受信したパケットから取得した情報を解析し、必要に応じてパケットデータ格納部１６１に解析結果を格納する。

【0022】

特徴抽出部１３２は、解析部１３１による解析結果から特徴情報を抽出する。解析部１３１による解析結果は、解析部１３１から直接取得してもよいし、パケットデータ格納部１６１に記憶された解析結果を取得してもよい。

【0023】

分類部１３３は、特徴抽出部１３２によって抽出された特徴情報をニューラルネットに入力し、学習データ格納部１６２に格納された学習データに基づいて端末２１の接続先（パケットの送信先、Ｗｅｂサーバー１１）が良性ホストであるか又は悪性ホストであるかを判定（分類）する。

【0024】

学習部１４０は、分類部１３３による分類（判定）精度を向上させるために、収集された学習データに基づいてニューラルネットワークによる判定の精度を向上させるためのパラメータを調整し、学習結果を学習データ格納部１６２に反映させる。学習データ収集部１４１は、パケットデータ格納部１６１及び学習データ格納部１６２から学習データを収集する。ニューラルネット学習部１４２は、学習データ収集部１４１によって収集された学習データに基づいてニューラルネットワークの学習を実施する。このとき、学習データ格納部１６２から学習結果を反映する前の学習データを取得し、学習実施後、学習結果を反映させた学習データを学習データ格納部１６２に格納する。学習データは、ニューラルネットによって端末２１の接続先を良性ホスト又は悪性ホストに分類するために必要なパラメータ及びデータである。

【0025】

ニューラルネットワークの学習は、管理計算機からの実行指示に基づいて実行してもよいし、定期的に実行するようにしてもよい。また、未学習のデータがパケットデータ格納部１６１に所定量以上蓄積された場合に実行するようにしてもよい。

【0026】

分類部１３３は、ニューラルネットによって端末２１の接続先を良性ホスト又は悪性ホストに分類（判定）する。本実施形態では、端末２１の接続先を分類するアルゴリズムとしてＴｅｎｓｏｒＦｌｏｗ、ＬＩＢＳＶＭなどの機械学習ライブラリを利用する。

【0027】

続いて、パケット分類装置１００が受信したパケットを外部ネットワークに転送する手順について説明する。図４は、本実施形態のパケット分類装置１００がパケットを転送するための構成の一例を示す図である。本実施形態のパケット分類装置１００では、ネットワーク処理を高速化するためにインテル（登録商標）のデータプレーン開発キット（ＤＰＤＫ；Ｄａｔａ Ｐｌａｎｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ）技術を利用している。ＤＰＤＫは、特定のアプリケーションに対してカーネル機能をバイパスした専用機能を提供する。なお、同等の機能を有していればＤＰＤＫ以外のソリューションを適用してもよい。

【0028】

通信ＩＦ１０１が受信したパケットは、ＤＰＤＫによって提供される受信バッファＲＸ（データ受信部）１０２に一旦格納され、検知部１３０に引き渡される。受信バッファＲＸ（データ受信部）１０２は、キュー構造となっており、パケットを受信した順序で検知部１３０に送り出す。その後、解析部１３１、特徴抽出部１３２及び分類部１３３によって受信したパケットの送信先（端末２１の接続先；Ｗｅｂサーバー１１）を良性ホスト又は悪性ホストに分類（判定）する。

【0029】

さらに、送信バッファＴＸ（データ送信部）１０３にパケットを格納し、通信ＩＦ１０１を介して外部ネットワーク１０に送信する。このとき、パケットの送信先が悪性ホストであれば、送信バッファＴＸ１０３にパケットを格納せずに破棄してもよい。このように構成することで、ルーター側で指定されたパケットを破棄する機能など、パケット分類装置１００以外は一般的なネットワーク機器を使用することが可能となり、導入コストを軽減することができる。一方、外部ネットワーク１０にパケットを転送するルーターに送信先が悪性ホストであることを通知し、ルーターがパケットを破棄するようにしてもよい。

【0030】

続いて、本発明を適用したリアルタイム検知システムの適用例について具体的に説明する。前述したように、本実施形態で悪性ホストを検知する手法は、既存の技術を採用し、具体的には、ＴｅｎｓｏｒＦｌｏｗ、ＬＩＢＳＶＭなどの機械学習ライブラリを利用している。これらの手法による悪性ホストの検知は、技術の進歩や学習データの蓄積などにより精度の向上が図られている。一方、受信したパケットから抜き出した情報に基づいて特徴量を抽出して解析するためには時間を要するため、悪性ホストをリアルタイムに検知することは困難であった。本実施形態では、実用的なパケット転送速度と高い攻撃検知精度を両立させることを目的としている。

【0031】

一方、アルゴリズムの高速化、ハードウェア性能の向上などによって悪性ホストの検知精度を高めながら実用的なパケット転送速度を維持することは容易ではない。前述のように、悪性ホストの検知精度については既存技術を使用するため、本発明ではパケット転送速度の維持を目的としている。ここで、端末２１から接続先のサーバー装置（Ｗｅｂサーバー１１）との通信を開始する実行される各工程の処理時間を計測した結果を示す。

【0032】

図５は、本実施形態において端末２１がＷｅｂサーバー１１と通信を開始するまでの各工程の処理時間を示す図である。グラフは箱ひげ図とし、縦軸は処理時間（μ秒）で対数軸となっており、横軸は工程である。図５では、分類部１３３にＬＩＢＳＶＭを適用する場合（左）とＴｅｎｓｏｒＦｌｏｗを適用する場合（右）について、アルゴリズムごとに各工程の処理時間を示している。各工程は、受信（ＲＸ）、解析（パース、Ｐａｒｓｅｒ）、特徴量抽出（Ｅｘｔｒａｃｔｏｒ Ｐｒｏｃｅｓｓｉｎｇ）、分類（Ｃｌａｓｓｉｆｉｅｒ ｐａｒｔｓ）、合計（Ｔｏｔａｌ）となっている。

【0033】

図５に示すように、分類（破線）が他の工程と比較して多くの処理時間を要している。また、分類以外の工程はアルゴリズムごとの処理時間の差は少ないが、分類の工程ではＬＩＢＳＶＭよりもＴｅｎｓｏｒＦｌｏｗを適用した方が高速に処理できる。なお、１パケット分の総処理時間は、悪性ホストを検知しない場合には０．４２３１μｓ（２．１１８Ｇｂｐｓ）、ＬＩＢＳＶＭを適用した場合には５５７．８μｓ（１．２６４Ｍｂｐｓ）、ＴｅｎｓｏｒＦｌｏｗを適用した場合には７２．４９２μｓ（９．６０Ｍｂｐｓ）となっている。なお、分類のためのアルゴリズムは、要求される処理速度及び検知精度に応じて選択すればよい。

【0034】

以上のように、悪性ホストを検知する処理がパケット転送時にボトルネックとなってしまうため、実用的なパケット転送速度を実現するためには１００～１０００倍程度の高速化を必要とする。そこで、本発明では通信の手順に着目し、端末２１が通信しようとする外部ネットワークに接続されたサーバー装置の名前解決を行っている間に接続先のサーバー装置が悪性ホストであるか良性ホストであるかを判定（分類）する。本発明の特徴は、端末２１から送信される接続先のサーバー装置（Ｗｅｂサーバー１１）の名前解決要求に含まれる情報（絶対ドメイン名等）に基づいて悪性ホストの検知を開始し、ＤＮＳサーバーによって接続先のサーバー装置のＩＰアドレスが特定されるまでの間に悪性ホストの検知を完了させることで実際に悪性ホストに端末２１が接続することを阻止する。

【0035】

図６は、本発明の実施の形態における悪性ホストを検知するタイミングを説明する図である。パケット分類装置１００は、（１）端末２１がＤＮＳキャッシュサーバー３０に名前解決要求を送信するタイミングＴ１、（２）ＤＮＳキャッシュサーバー３０が名前解決の結果を端末２１に送信するタイミングＴ２、（３）端末２１がＷｅｂサーバー１１との通信を開始するタイミングＴ３でＷｅｂサーバー１１が悪性ホストであるか否かを判定する。タイミングＴ１、Ｔ２、Ｔ３で接続先（Ｗｅｂサーバー１１）が悪性ホストであるか否かを判定することで悪性ホストに接続する前に（サイバー攻撃を受ける前に）通信を遮断できる。以下、各タイミングで悪性ホストを検知するための構成について説明する。

【0036】

図７は、本発明の実施形態において端末２１がＤＮＳキャッシュサーバー３０に名前解決要求を送信するタイミングＴ１で悪性ホストを検知するための構成を説明する図である。タイミングＴ１では、端末２１がＤＮＳキャッシュサーバー３０に対して接続先（Ｗｅｂサーバー１１）のＩＰアドレスを特定するための名前解決要求（ＤＮＳクエリ）を送信する。パケット分類装置１００は、端末２１から送信された名前解決要求を受信し、名前解決要求に含まれる情報に基づいて、接続先（Ｗｅｂサーバー１１）が悪性ホストであるか否かを判定する。

【0037】

パケット分類装置１００は、端末２１から名前解決要求を受信すると、通信ＩＦ１０１を介して受信バッファＲＸ１０２に名前解決要求に対応するパケットを格納する。解析部１３１は、受信した名前解決要求の内容を参照し、絶対ドメイン名（ＦＱＤＮ）を抽出する。さらに、良性ホストの絶対ドメイン名が記録されたドメインホワイトリストを参照し、抽出された絶対ドメイン名がドメインホワイトリストに含まれているか否かを判定する。抽出された絶対ドメイン名がドメインホワイトリストに含まれている場合には（“ｌｅｇｉｔｉｍａｔｅ”）、接続先が良性ホストであるため、送信バッファＴＸ１０３に名前解決要求に対応するパケットを格納する。送信バッファＴＸ１０３に格納されたパケットは、通信制御部１２１によってＤＮＳキャッシュサーバー３０に送信される。

【0038】

解析部１３１は、抽出された絶対ドメイン名がドメインホワイトリストに含まれていない場合には（“ｎｏｔ ｍａｔｃｈｅｄ”）、悪性ホストの絶対ドメイン名が記録されたドメインブラックリストを参照し、抽出された絶対ドメイン名がドメインブラックリストに含まれているか否かを判定する。抽出された絶対ドメイン名がドメインブラックリストに含まれている場合には（“ｍａｌｉｃｉｏｕｓ”）、接続先が悪性ホストであるため、送信するパケットを破棄する。このとき、端末２１には接続できない旨のメッセージを端末２１に応答するようにしてもよい。

【0039】

また、抽出された絶対ドメイン名がドメインブラックリストに含まれていない場合には（“ｎｏｔ ｍａｔｃｈｅｄ”）、接続先が悪性ホストであるか良性ホストであるかを特定できないため、特徴抽出部１３２によって名前解決要求に含まれる情報から特徴情報を抽出し、分類部１３３によって接続先を悪性ホスト又は良性ホストに分類する。また、悪性ホスト又は良性ホストの分類には処理時間を必要とするため、接続先へのアクセスの遅延を防ぐために、送信バッファＴＸ１０３に名前解決要求に対応するパケットを格納する。これにより、ＤＮＳキャッシュサーバー３０に名前解決要求が送信され、ＤＮＳキャッシュサーバー３０が名前解決を行っている間に並行して接続先の分類を実行することができる。分類結果が導出されると、分類部１３３は、分類結果が良性ホストの場合にはドメインホワイトリストに反映し（“ｌｅｇｉｔｉｍａｔｅ”）、悪性ホストの場合にはドメインブラックリストに反映する（“ｍａｌｉｃｉｏｕｓ”）。

【0040】

以上のように、端末２１からＤＮＳキャッシュサーバー３０に名前解決要求が送信されると、パケット分類装置１００が名前解決要求に含まれる絶対ドメイン名などの情報に基づいて接続先が良性ホストであるか悪性ホストであるかを判定する。絶対ドメイン名がドメインブラックリスト又はドメインホワイトリストに含まれておらず、良性ホストであるか悪性ホストであるかを特定できない場合には、検知部１３０が接続先の特徴情報及び学習データに基づいて接続先が悪性ホストであるか良性ホストであるかを分類（判定）する。このとき、名前解決要求をＤＮＳキャッシュサーバー３０に送信し、ＤＮＳキャッシュサーバー３０が名前解決を行っている間に接続先を分類し、分類結果をドメインブラックリスト又はドメインホワイトリストに反映する。このように、ＤＮＳキャッシュサーバー３０が名前解決を行っている間に接続先の絶対ドメイン名を分類することで通信の遅延を最小限に抑制できる。

【0041】

ＤＮＳキャッシュサーバー３０は、端末２１から送信された名前解決要求を受信すると、接続先のＩＰアドレスを特定し、特定されたＩＰアドレスを含む名前解決結果を端末２１に送信する。パケット分類装置１００は、ＤＮＳキャッシュサーバー３０から名前解決結果を受信すると（タイミングＴ２）、再度接続先が悪性ホストであるか否かを判定する。以下、タイミングＴ２における処理について説明する。

【0042】

図８は、本発明の実施形態において端末２１がＤＮＳキャッシュサーバー３０から名前解決結果を受信するタイミングＴ２で悪性ホストを検知するための構成を説明する図である。パケット分類装置１００は、ＤＮＳキャッシュサーバー３０から名前解決結果を受信すると、通信ＩＦ１０１を介して受信バッファＲＸ１０２に名前解決結果に対応するパケットを格納する。

【0043】

解析部１３１は、名前解決要求の受信時（タイミングＴ１）に絶対ドメイン名を分類した結果が反映されたドメインブラックリスト及びドメインホワイトリストに基づいて再度接続先が悪性ホストであるか否かを判定する。さらに説明すると、まず、接続先の絶対ドメイン名がドメインホワイトリストに含まれているか否かを判定する。このとき、接続先の絶対ドメイン名がドメインホワイトリストに含まれている場合には（“ｌｅｇｉｔｉｍａｔｅ”）、接続先が良性ホストであるため、送信バッファＴＸ１０３に名前解決結果に対応するパケットを格納する。送信バッファＴＸ１０３に格納されたパケットは、通信制御部１２１によって端末２１に送信される。

【0044】

解析部１３１は、絶対ドメイン名がドメインホワイトリストに含まれていない場合には（“ｎｏｔ ｍａｔｃｈｅｄ”）、絶対ドメイン名がドメインブラックリストに含まれているか否かを判定する。絶対ドメイン名がドメインブラックリストに含まれている場合には（“ｍａｌｉｃｉｏｕｓ”）、接続先が悪性ホストであるため、名前解決結果に対応するパケットを破棄する。さらに、名前解決結果に接続先のドメインのＩＰアドレスが含まれている場合には（“ｄｏｍａｉｎ ｅｘｉｓｔ”）、悪性ホストのＩＰアドレスが記録されたＩＰブラックリストに追加（更新）する。

【0045】

一方、プロセッサ１１０は、絶対ドメイン名がドメインブラックリストに含まれていない場合には（“ｎｏｔ ｍａｔｃｈｅｄ”）、送信バッファＴＸ１０３に名前解決結果に対応するパケットを格納し、通信制御部１２１によって端末２１に送信する。

【0046】

以上のように、ＤＮＳキャッシュサーバー３０から端末２１に名前解決結果が送信されると、ＤＮＳキャッシュサーバー３０が名前解決を実行している間に接続先ドメインの分類結果が反映されたドメインブラックリスト及びドメインホワイトリストに基づいて再度良性ホストであるか又は悪性ホストであるかを判定（分類）する。接続先ドメインの名前解決と並行して接続可否を判定するため、利用者は悪性ホストの判定に要する時間を意識することなく端末２１を操作可能となる。なお、名前解決結果の応答時に接続先の分類が終了していない場合には、検知精度を優先して分類が終了するまで待機してもよいし、通信時間の遅延抑制を優先して悪性ホストの判定を省略してもよい。

【0047】

端末２１は、ＤＮＳキャッシュサーバー３０から名前解決結果を受信すると、名前解決結果に含まれる接続先のＩＰアドレスに基づいて接続先のＷｅｂサーバー１１にアクセスする。パケット分類装置１００は、Ｗｅｂサーバー１１へのアクセス要求を受信すると（タイミングＴ３）、接続先のＩＰアドレスに対応する計算機が悪性ホストであるか否かを判定する。以下、タイミングＴ３における処理について説明する。

【0048】

図９は、本発明の実施形態において端末２１が接続先のＷｅｂサーバー１１にアクセスするタイミングＴ３で悪性ホストを検知するための構成を説明する図である。パケット分類装置１００は、端末２１から接続先のＷｅｂサーバー１１へのアクセス要求（接続要求）を受信すると、通信ＩＦ１０１を介してアクセス要求に対応するパケットを受信バッファＲＸ１０２に格納する。

【0049】

解析部１３１は、アクセス要求に含まれる接続先（Ｗｅｂサーバー１１）のＩＰアドレスを抽出し、ＩＰブラックリストに含まれるか否かを判定する。抽出されたＩＰアドレスがＩＰブラックリストに含まれている場合には（“ｄｏｍａｉｎ ｅｘｉｓｔ”）、接続先が悪性ホストであるため、送信するパケット（アクセス要求）を破棄する。一方、抽出されたＩＰアドレスがＩＰブラックリストに含まれていない場合には（“ｎｏｔ ｍａｔｃｈｅｄ”）、送信バッファＴＸ１０３に接続先へのアクセス要求に対応するパケットを格納し、通信制御部１２１によって接続先（Ｗｅｂサーバー１１）に送信する。

【0050】

以上のように、本発明の実施形態によれば、端末２１がＷｅｂサーバー１１と通信を開始する際に、名前解決を実行する間に接続先のＷｅｂサーバー１１が悪性ホストであるか否かを判定することが可能となるため、通信速度の低下を利用者に感じさせることなくサイバー攻撃をリアルタイムで検知することが可能となる。

【0051】

以上、本発明の実施形態について説明したが、上記実施形態は本発明の適用例の一部を示したに過ぎず、本発明の技術的範囲を上記実施形態の具体的構成に限定する趣旨ではない。

【符号の説明】

【0052】

１０ 外部ネットワーク（第１ネットワーク）
１１ Ｗｅｂサーバー（サーバー装置）
２０ 内部ネットワーク（第２ネットワーク）
２１ 端末
３０ ＤＮＳキャッシュサーバー（ＤＮＳサーバー）
４０ ルーター
６０ 権威ＤＮＳサーバー
１００ パケット分類装置（通信装置）
１０１ 通信インターフェース（ＩＦ）
１０２ 受信バッファＲＸ（データ受信部）
１０３ 送信バッファＴＸ（データ送信部）
１１０ プロセッサ（ＣＰＵ）
１２０ メモリ
１２１ 通信制御部
１３０ 検知部（判定部）
１３１ 解析部
１３２ 特徴抽出部
１３３ 分類部
１４０ 学習部
１４１ 学習データ収集部
１４２ ニューラルネット学習部
１６０ 記憶装置
１６１ パケットデータ格納部
１６２ 学習データ格納部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】