特許ウォッチ

公開番号2024118424
公報種別公開特許公報(A)
公開日2024-08-30
出願番号2023221466
出願日2023-12-27
発明の名称通信分析装置、通信分析プログラム及び通信分析方法
出願人沖電気工業株式会社
代理人個人,個人
主分類H04L 69/22 20220101AFI20240823BHJP(電気通信技術)
要約【課題】通信トラフィックのデータからサービスポートを判別する際の精度を向上させる。
【解決手段】本発明は、通信分析装置に関する。そして本発明の通信分析装置は、分析対象のネットワーク上を流れる通信トラフィックデータを通信フローごとに分類し、通信フローごとにパケットのヘッダ情報に基づくフロー情報を用いてサービスポートを判定し、IPアドレスごとにサービスポートの一覧であるサービスポートリストを管理し、フロー情報だけでサービスポートが特定できない通信フローに対してサービスポートリストを用いてサービスポートを推定し、フロー情報だけでサービスポートが特定できない通信フローについてはサービスポート推定処理の結果をサービスポート判定処理の結果とすることを特徴とする。
【選択図】図1

特許請求の範囲【請求項１】
分析対象のネットワーク上を流れる通信トラフィックデータを通信フローごとに分類する通信フロー処理手段と、
前記通信フローごとに、前記通信フローを構成するパケットのヘッダ情報に基づくフロー情報を用いてサービスポートを判定するサービスポート判定処理を行うサービスポート判定手段と、
前記ネットワーク上で分析対象となるＩＰアドレスごとに、サービスポートの一覧であるサービスポートリストを管理するサービスポートリスト管理手段と、
フロー情報だけでサービスポートが特定できない前記通信フローに対して、前記サービスポートリスト管理手段が管理する前記サービスポートリストを用いてサービスポートを推定するサービスポート推定処理を行うサービスポート推定手段とを備え、
前記サービスポート判定手段は、フロー情報だけでサービスポートが特定できない前記通信フローについては前記サービスポート推定手段による前記サービスポート推定処理の結果を前記サービスポート判定処理の結果とする
ことを特徴とする通信分析装置。
続きを表示（約 1,900 文字）【請求項２】
前記サービスポートリスト管理手段は、前記サービスポート判定手段による前記サービスポート判定処理の結果に基づいて、前記サービスポート判定処理の対象となる前記通信フローに係る前記ＩＰアドレスの前記サービスポートリストのサービスポートを追加することを特徴とする請求項１に記載の通信分析装置。
【請求項３】
前記サービスポートリスト管理手段が保持する前記サービスポートリストには、前記ＩＰアドレスがクライアントとしてアクセスするポートのリストである第１のサブリストと、前記ＩＰアドレスがサーバとしてアクセスされるポートのリストである第２のサブリストが含まれていることを特徴とする請求項２に記載の通信分析装置。
【請求項４】
前記サービスポートリスト管理手段が保持する前記サービスポートリストには、プロトコルごとの前記第１のサブリスト及び前記第２のサブリストが含まれることを特徴とする請求項３に記載の通信分析装置。
【請求項５】
前記サービスポート推定手段は、前記通信フローの送信元アドレスに対応する前記サービスポートリスト及び前記通信フローの宛先アドレスに対応する前記サービスポートリストと、前記通信フローの送信元通信ポート及び前記通信フローの宛先通信ポートとを比較することにより前記サービスポート推定処理を行うことを特徴とする請求項４に記載の通信分析装置。
【請求項６】
前記サービスポートリスト管理手段が管理する前記サービスポートリストを構成するサービスポートごとに、前記通信フローの特徴量に基づいて一致又は不一致を判定する通信パターン分析モデルを構築する通信パターン学習手段をさらに備え、
前記サービスポートリスト管理手段は、前記通信パターン学習手段が構築した前記通信パターン分析モデルを保持し、
前記サービスポート推定手段は、前記サービスポートリスト管理手段が保持する前記通信パターン分析モデルも用いて、前記サービスポート推定処理を行う
ことを特徴とする請求項１に記載の通信分析装置。
【請求項７】
前記サービスポートリスト管理手段は、プロトコルごとに前記サービスポートリストを保持し、
プロトコルがＵＤＰの前記サービスポートリストを作成するために、ＵＤＰの通信フローの履歴情報として、通信フローの宛先ポート番号ごとに、通信フローの発生数、通信フローの送信元ポート番号を管理する、ＵＤＰポート履歴情報管理手段をさらに備え、
前記サービスポートリスト管理手段は、前記ＵＤＰの通信フローの履歴情報に含まれる宛先ポート番号ごとに、通信フローの発生数と、通信フローの送信元ポート番号を宛先ポートとしてみたときの通信フローの発生数を比較し、いずれかの送信元ポート番号との比較で前記宛先ポート番号の発生数の方が多い場合に、前記宛先ポート番号をＵＤＰのサービスポートリストに追加する
ことを特徴とする請求項２に記載の通信分析装置。
【請求項８】
前記ＵＤＰポート履歴情報管理手段は、前記ＵＤＰの通信フローの履歴情報として、通信フローの宛先ポート番号ごとに、通信フローの発生日数をさらに管理し、
前記サービスポートリスト管理手段は、前記ＵＤＰの通信フローの履歴情報に含まれる宛先ポートについて、通信フローの発生日数が予め決められた閾値を満たない場合は、前記ＵＤＰのサービスポートリストに追加しない
ことを特徴とする請求項７に記載の通信分析装置。
【請求項９】
前記ＵＤＰポート履歴情報管理手段は、
前記ＵＤＰの通信フローの履歴情報として、端末ごとに同じ送信元ポート番号が何回使われたかの情報をさらに管理し、
前記通信フローの発生日数の閾値について、予め決められた初期値から、前記送信元ポート番号の使用回数の増加に合わせて増加させていく
ことを特徴とする請求項８に記載の通信分析装置。
【請求項１０】
前記サービスポートリスト管理手段は、前記通信フローの発生日数の閾値の他に、前記ＵＤＰの通信フローの履歴情報に含まれる宛先ポートごとに、通信フローの送信元ポート番号の種類数、あるいは前記宛先ポートの通信フローの送信元ＩＰアドレス種類数が予め決められた閾値以上であることを、サービスポートと判定するかの条件にさらに設定することを特徴とする請求項８に記載の通信分析装置。
（【請求項１１】以降は省略されています）
発明の詳細な説明【技術分野】
【０００１】
この発明は、通信分析装置、通信分析プログラム及び通信分析方法に関し、例えば、通信トラフィックデータに基づいて通信セキュリティに関する分析を行う装置に適用し得る。
続きを表示（約 3,200 文字）【背景技術】
【０００２】
現在、ＩｏＴ機器の利活用拡大により、組織ネットワークにおいて従業員のＰＣやＩｏＴ機器が接続される末端のネットワーク（エッジネットワークと呼ぶ）の監視の需要が高まっている。例えば、オフィスや工場などのエッジネットワークにＩｏＴ機器が多数接続されるようになり、ＩＴ管理者がエッジネットワークにどのような機器が接続されているか、各機器がどこと通信しているか、マルウェア感染等によるセキュリティ脅威が発生していないか、といった情報を収集し管理することが困難になってきている。そのため、現在、こういった情報を自動的に収集し管理するエッジネットワーク監視の実現が求められている。
【０００３】
従来、エッジネットワーク監視を実現するために、通信トラフィックログ分析を用いる方法がある。従来の通信トラフィックログ分析では、監視対象ネットワークの機器が収容されるネットワークスイッチのミラーポートに通信分析装置を接続し、ネットワークを流れるトラフィックをキャプチャし分析することで、リアルタイムに通信状況を可視化しセキュリティリスクやセキュリティ脅威の発生を検出する。通信状況の可視化情報として、どの機器から他のどの機器に対して通信が発生したかを示したい場合がある。また、セキュリティリスクを把握するため、ネットワーク内に存在するサーバが待ち受けるサービスを把握し、意図しないポートが空いていないか確認したい場合がある。さらに、セキュリティ脅威を検出するため、ある機器が普段と異なるサーバのサービスにアクセスしていないか確認したい場合がある。従来の通信トラフィックログ分析において、これらを実現する場合、通信フロー（送信元ＩＰアドレス、送信元ポート番号、宛先ＩＰアドレス、宛先ポート番号、プロトコル番号の組で識別されるトラフィックの流れ）において、サーバが待ち受ける側のポート番号（以下、「サービスポート」と呼ぶ）の識別が必要である。
【０００４】
ところで、従来の通信トラフィックログ分析では、サービスポートの識別方法として、ウェルノウンポートとして定義されているポート番号に代表されるように、番号の若いものがサービスポートとして使われる場合が多いことから、送信元ポート番号と宛先ポート番号の小さい方のポート番号をサービスポートとして識別する方法がある。しかしながら実トラフィックを観測すると、必ずしもポート番号の小さい方がサービスポートとして利用されないことが分かっている。
【０００５】
サービスポートの別の識別方法として、一般に通信はクライアントからサーバに対して発生する特徴を利用し、通信フローの先頭パケットを観測し、当該パケットの宛先ポート番号をサービスポートとして識別する方法が考えられる。しかしながら、この方法では、少なくとも以下３つのケースでサービスポートを誤判別する事象が発生してしまう。
［第１のケース］ミラーするスイッチの特性により、最初に送られたパケットより後に送られたパケットが先にミラーポートに入ってくる場合がある。この場合、後続パケットをフロー先頭パケットとして受信処理することになるため誤判別が生じる
［第２のケース］運用中のネットワークに、トラフィック分析装置を後付けする形でトラフィックミラーリングを開始する場合、設置前に始まっていた通信フローは先頭パケットを観測できないため、サービスポートを誤判別する可能性がある
［第３のケース］ある一種のブロードキャスト通信として、ある機器がブロードキャストでネットワーク全体にリクエストを発信し、それを受信した機器がリクエストに対する応答パケットを送信するような通信を考える。このような通信では、ブロードキャストリクエストパケットは、送信元アドレスがリクエスト発信元のＩＰアドレス、宛先アドレスがネットワークセグメントのブロードキャストＩＰアドレスとなる。一方応答パケットは、送信元アドレスが応答パケット発信元のＩＰアドレス、宛先アドレスがリクエスト送信元のＩＰアドレスとなり、リクエストパケットと応答パケットでＩＰアドレスの組が異なるため別の通信フロー扱いになる。このとき、応答パケットの送信元ポート番号および宛先ポート番号はリクエストパケットのポート番号を反転させたものとなる場合が多いため、応答パケットの通信フローのサービスポートはリクエストパケットの送信元ポート番号と一致する。一般にクライアント側のポート番号はフローが発生する度に異なる値が設定されるため、応答パケットのサービスポートは通信フロー発生の度に異なるポート番号とみなされてしまう。これにより、例えば普段と異なるサービスにアクセスした通信を異常検出する場合に、このようなブロードキャスト通信が発生する度に異常検出し、誤検出が多発することになる。そのため応答パケットのサービスポート番号は、送信元ポート番号（つまりリクエストパケットの宛先ポート番号）とみなした方が適切な場合が多いと考えられる。またこのようなブロードキャストリクエストパケットとその応答パケットはひとまとまりの通信として扱うことが望ましい場合もあると考えられる。上記一番目と二番目の誤判別ケースは、ＴＣＰ通信の場合、ＴＣＰ制御フラグのＳＹＮフラグの情報によってサービスポートを識別することが可能だが、誤判別二番目のケースでＳＹＮフラグを取り逃した場合は識別できない。またＵＤＰ通信の場合は、ＴＣＰ通信のように制御フラグがないため、フローの先頭パケットを確実に把握する方法がない。また上記三番目のブロードキャスト通信のケースで示されるように、通信フロー単位でのサービスポート識別にも課題がある。
【０００６】
以上のように、通信トラフィックログ分析では、サービスポートの誤判別を低減し判別精度を向上させる仕組みが求められているが、このような課題に対しては、従来特許文献１、２の記載技術が存在する。
【０００７】
特許文献１では、トラフィックミラーリングで取得されるパケットの到着順序が変わって受信してしまう課題に対して、ＴＣＰヘッダやＩＰヘッダに含まれるシーケンス番号を用いて、パケット到着順序を整える方法について言及されている。また、特許文献２では、制御ネットワークの異常検知のために、トラフィックミラーリングで取得される通信トラフィックをフロー単位に分析して異常検知する方法について言及されている。
【先行技術文献】
【特許文献】
【０００８】
特開２０１４－１８３４８３号公報
特開２０２０－６１６６７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
特許文献１の記載技術では、通信プロトコルとしてコネクション指向のプロトコルが利用される必要があり、ＵＤＰのサービスポート誤判別のケースには対応できない。また、特許文献１の記載技術では、前述の第２と第３のケースに対処することができない。さらに、特許文献２の記載技術では、サービスポートの判定に送信元ポート番号と宛先ポート番号の小さい方の値を用いており、サービスポート誤判別の課題について考慮されていない。
【００１０】
以上のような従来技術における問題に鑑みて、通信トラフィックのデータからサービスポートを判別する際の精度を向上させることができる通信分析装置、通信分析プログラム及び通信分析方法が望まれている。
【課題を解決するための手段】
（【００１１】以降は省略されています）

関連特許