トラヒック通過経路解析方法、プログラム及び装置
【課題】汎用的なファイアウォール装置において通常利用可能な機能に基づいてトラヒックフローを省力かつ高精度に把握可能とする。
【解決手段】所定の複数のファイアウォール装置より、各トラヒックの到達日時と、到達したファイアウォール装置と、送信元及び宛先と、の情報を対応付けて取得して個別トラヒック情報とする段階S2と、個別トラヒック情報を、その送信元及び宛先の一致並びに到達日時の所定基準内での近接に基づいてグループ化して集約トラヒック情報とする段階S3と、各集約トラヒックに対して、当該集約トラヒックに属する各個別トラヒックの到達日時の順に、各個別トラヒックが到達したファイアウォール装置の順列を求め、該順列を当該集約トラヒックに共通の送信元から宛先へ至るトラヒックフロー全体としての通過経路として推定する段階S4とを備えてトラヒック通過経路解析方法を提供する。
【解決手段】所定の複数のファイアウォール装置より、各トラヒックの到達日時と、到達したファイアウォール装置と、送信元及び宛先と、の情報を対応付けて取得して個別トラヒック情報とする段階S2と、個別トラヒック情報を、その送信元及び宛先の一致並びに到達日時の所定基準内での近接に基づいてグループ化して集約トラヒック情報とする段階S3と、各集約トラヒックに対して、当該集約トラヒックに属する各個別トラヒックの到達日時の順に、各個別トラヒックが到達したファイアウォール装置の順列を求め、該順列を当該集約トラヒックに共通の送信元から宛先へ至るトラヒックフロー全体としての通過経路として推定する段階S4とを備えてトラヒック通過経路解析方法を提供する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はトラヒック通過経路解析に関し、特に、汎用的なファイアウォール装置において通常利用可能な機能に基づいて、トラヒックフローを省力かつ高精度に把握可能とするトラヒック通過経路解方法、プログラム及び装置に関する。
【背景技術】
【０００２】
ファイアウォール(Firewall)装置は、管理対象ネットワークと外部ネットワークとの接続点に設置されるルータの一種である。ファイアウォール装置は、管理対象ネットワークの安全性を高めるために、組織毎のトラヒック疎通方針（セキュリティ・ポリシ、以下「ポリシ情報」という）に基づいて必要なパケットのみを通過させ、危険なパケットを阻止する。従って、ファイアウォール装置の構成情報（ルール情報）は、そのポリシ情報に基づいて適切に設定される必要がある。尚、ファイアウォール装置は、管理対象ネットワーク内のセグメントネットワーク同士の間（例えば部署aのイントラネットと部署bのイントラネットとの間）に配置されるものであってもよい。
【０００３】
一般に、ネットワーク管理者は、各部署（例えば各イントラネットの管理者）から、ファイアウォール装置の設定を依頼する「オーダシート（依頼書）」を受け取る。ネットワーク管理者は、それらオーダシートと組織の基本方針とに基づいて、「ポリシ情報」を作成する。ポリシ情報は、複数の「ポリシ要素」の順列によって構成される。ファイアウォール管理装置は、そのポリシ情報に基づいて、ファイアウォール装置毎に「ルール情報」を作成する。ルール情報も、複数の「ルール要素」の順列によって構成される。そして、ファイアウォール管理装置は、ファイアウォール装置毎に、ルール情報を送信する。
【０００４】
構築済みのネットワークを対象に、ファイアウォールやルータのトラヒック疎通状態が設計通りか否かを評価、診断の上、問題箇所を指摘し修正する作業を行う場合がある。そこではトラヒックフローの現状分析が課題となる。トラヒックフローとは、例えば、計算機A0から計算機B0へのトラヒックはファイアウォールFW1, FW2を経由する、といった通過経路の情報である。このような情報の解析は、小規模かつ静的な経路設定のみで運用されるネットワークでは、属人的な作業により実現することも可能である。しかし今日、ファイアウォールやルータが10台以上あったり、動的経路制御を用いるようなネットワーク構成が通常である。このような環境では属人的な作業によって誤りなく速やかに分析を行うことは不可能である。
【０００５】
このような事情に関連して、以下の従来技術(NetFlow, 非特許文献１, 非特許文献2)では、汎用のファイアウォール装置に新たな機能や付加装置を追加することで、ファイアウォール上のトラヒックフローの解析が可能となる。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】Cisco、「Introduction to Cisco IOS NetFlow - A Technical Overview」、[online]、［平成23年2月21日検索］、インターネット＜URL:http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6555/ps6601/prod_white_paper0900aecd80406232.html＞
【非特許文献２】Cisco、「IETF RFC 3954: Cisco Systems NetFlow Services Export Version 9」、[online]、［平成23年2月21日検索］、インターネット＜URL:http://www.ietf.org/rfc/rfc3954.txt＞
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら上記の従来技術は、在来の汎用的な装置で利用できないことや、ファイアウォール装置の負荷増大、負荷装置の導入・設置手間・コストが実用上の問題となる。
【０００８】
本発明の目的は、上記の従来技術の課題を解決し、必ずしも汎用には利用し難い手法(例えば、動的経路情報やNetFlowなど、ファイアウォール装置に負荷のかかる手法)を用いず、汎用的なファイアウォール装置にて通常利用可能な機能に基づいて、ネットワークのトラヒックフローを省力かつ高精度に把握可能とするトラヒック通過経路解析方法、プログラム及び装置を提供することにある。
【課題を解決するための手段】
【０００９】
上記の従来技術の課題を解決するため、本発明はトラヒック通過経路解析方法であって、所定の複数のファイアウォール装置より、各ファイアウォール装置における各トラヒックの到達日時と、当該トラヒックが到達したファイアウォール装置と、当該トラヒックの送信元及び宛先と、の情報を対応付けて取得して個別トラヒック情報とする段階と、前記個別トラヒック情報を構成する各個別トラヒックを、その送信元及び宛先の一致並びに到達日時の所定基準内での近接に基づいてグループ化して集約トラヒック情報とする段階と、前記集約トラヒック情報を構成する各集約トラヒックに対して、当該集約トラヒックに属する各個別トラヒックの到達日時の順に、各個別トラヒックが到達したファイアウォール装置の順列を求め、該順列を当該集約トラヒックに共通の送信元から宛先へ至るトラヒックフロー全体としての通過経路として推定する段階を備えることを特徴とする。
【００１０】
また、本発明はトラヒック通過経路プログラムであって、コンピュータに前記トラヒック解析方法を実行させることで当該コンピュータをトラヒック通過経路解析装置として機能させることを特徴とする。
【００１１】
また、本発明はトラヒック通過経路解析装置であって、所定の複数のファイアウォール装置より、各ファイアウォール装置における各トラヒックの到達日時と、当該トラヒックが到達したファイアウォール装置と、当該トラヒックの送信元及び宛先と、の情報を対応付けて取得して個別トラヒック情報を作成する個別トラヒック情報作成部と、前記個別トラヒック情報を構成する各個別トラヒックを、その送信元及び宛先の一致並びに到達日時の所定基準内での近接に基づいてグループ化して集約トラヒック情報を作成する集約トラヒック情報作成部と、前記集約トラヒック情報を構成する各集約トラヒックに対して、当該集約トラヒックに属する各個別トラヒックの到達日時の順に、各個別トラヒックが到達したファイアウォール装置の順列を求め、該順列を当該集約トラヒックに共通の送信元から宛先へ至るトラヒックフロー全体としての通過経路として推定する通過経路推定部を備えることを特徴とする。
【００１２】
さらに、前記個別トラヒック情報を各ファイアウォール装置の記録したトラヒックログを参照して求めることを特徴とする。
【発明の効果】
【００１３】
本発明によれば、汎用的なファイアウォール装置において通常取得可能な各種項目からなる個別トラヒック情報に基づいて、トラヒックフローの通過経路を推定することができる。特に、個別トラヒック情報を汎用的なファイアウォール装置におけるトラヒックログを参照して作成することで、過負荷や追加コストなどを避けて通過経路を推定することができる。
【図面の簡単な説明】
【００１４】
【図１】本発明に係るシステムの一例を示す図である。
【図２】本発明を説明するためのトラヒックフローおよびトラヒックログ(トラヒック情報)の例である。
【図３】本発明のトラヒック通過経路解析装置の機能ブロック図である。
【図４】本発明のトラヒック通過経路解析方法のフローチャートである。
【図５】個別トラヒック情報を表形式で示した例である。
【図６】集約トラヒック情報を表形式で示した例である。
【図７】通過経路を推定するフローチャートである。
【図８】通過経路推定フローに伴って更新される通過経路情報や、集約トラヒックと通過経路との対応情報の例である。
【発明を実施するための形態】
【００１５】
以下に、図面を参照して本発明を詳細に説明する。図1は、本発明に係るシステムの一例であり、トラヒック通過経路解析装置と、通過するトラヒックフローの解析対象となるファイアウォール装置との関係の一例を示す図である。
【００１６】
トラヒック通過経路解析装置1は、解析対象である所定の複数のファイアウォール装置20から必要な情報を取得して、トラヒックフローを解析する。ファイアウォール装置20は、管理対象ネットワーク50と、一般にインターネット全体70に含まれる外部ネットワーク60との間に配置される。管理対象ネットワーク50は複数の内部ネットワーク40を含み、当該ネットワーク内のパケット転送をルータ30が担う。
【００１７】
例えば、管理対象ネットワーク50はある会社のネットワークであり、内部ネットワーク40は当該会社の各部署のイントラネットである。なお、図1では必ずしもそのような配置で示されていないが、ファイアウォール装置20は、管理対象ネットワーク50と外部ネットワーク60との間のみでなく、管理対象ネットワーク50内の内部ネットワーク40の間に配置されるものであってもよい。
【００１８】
本発明では基本的に、図1のように解析対象のファイアウォール装置20が管理対象ネットワーク50内にあることを想定する。そしてトラヒック通過経路解析装置1は、これらファイアウォール装置20の管理も担う装置であれば、解析したトラヒックフローが管理上の基本情報として有効に活用できるため好ましい。しかし、必要な情報を取得できさえすれば、管理対象ネットワーク50の内外を問わず、任意のファイアウォール装置を解析対象に加えることができる。
【００１９】
ファイアウォール装置20は、外部ネットワーク60（又は内部のセグメントネットワーク40）から受信したパケットが、いずれのルール要素に該当するか照合する。そして、該当するルール要素に記述されるアクションに基づいて、そのパケットの転送可否が決定される。
【００２０】
ファイアウォール装置20は、パケット毎の疎通結果を、「トラヒックログ」(または「アクセスログ」)として記録することができる。「トラヒックログ」とは、どのパケットに対し、どのルール要素によって、どのアクションを採ったかを表す記録である。本発明においては、ファイアウォール装置20から必要な情報を取得できるように、予め対応するトラヒックログの項目を記録するように設定しておくものとする。
【００２１】
トラヒックログの取得は、ファイアウォール装置20が所定期間に渡って取得した後に、Syslogプロトコルなどによって図1に不図示のログ保管サーバに送信し、保管したログをトラヒック通過経路解析装置1が取得してもよい。また、ファイアウォール装置20から直接取得してもよい。いずれにせよ、ファイアウォール装置20に過負荷を掛けないような任意の手法によって取得することができる。
【００２２】
なおまた、本発明においてトラヒック通過経路解析装置1に必要となる情報はトラヒックログから取得するものとして説明するが、本発明はこれに限定されるものではない。すなわち、ファイアウォール装置20におけるトラヒックに対する同様の情報を取得することができ、ファイアウォール装置20に過負荷を掛けないならば、必ずしもログ経由で情報を取得する必要はない。本発明においてトラヒックログを利用するのは、汎用のファイアウォール装置20において通常の管理手法において記録することが可能であり、比較的容易に取得しうる情報の一実施形態としての利用である。この際、トラヒックログに記録可能な全ての種類の情報が必要となるわけでもない。なおまた、各情報の技術的意義の説明を容易にするための便宜としても、一般的なトラヒックログの用語又は略語を適宜借用して説明を行うものとする。
【００２３】
図2は、本発明を説明するために一貫して用いるトラヒックフロー及びトラヒックログ(前述の通り、トラヒックログはより一般には、トラヒック情報であってもよい)の例である。図2の上段側には、所定配置のファイアウォール装置FW1乃至FW5及びトラヒックの送信元又は宛先となるホスト(A)(B)(C)が例として示されている。なお、これらファイアウォール装置のうち、FW1及びFW2を解析対象として定めることとする。
【００２４】
なお、図1ではシステム全体を説明するために、特に区別を設けない一連のファイアウォール装置20として説明したが、本発明においてはファイアウォール装置同士の区別が必要である。よって、以降の説明でファイアウォール装置を参照する際には当該FW1乃至FW5などを用いるとする。
【００２５】
図2では、順次発生したトラヒックフローの例として以下のようなTf1、Tf2及びTf3が示されている。
Tf1及びTf2：送信元(src)=(A)、宛先(dst)=(B)、利用サービス(service)=http
Tf3：送信元(src)=(A)、宛先(dst)=(B)、利用サービス(service)=ssh
【００２６】
図2上段に示すように、Tf1は送信元(A)より宛先(C)へと送られたhttpサービスのパケットのトラヒックフローであり、途中でファイアウォール装置FW1、FW2及びFW3を順次疎通許可され通過して宛先に到達している。同じくTf2も送信元(A)より宛先(C)へと送られたhttpサービスのパケットのトラヒックフローであり、途中でファイアウォール装置FW1、FW2及びFW3を順次通過している宛先に到達している。さらに、Tf3は送信元(A)より宛先(C)へと送られたsshサービスのパケットのトラヒックフローであるが、途中でファイアウォール装置FW1において疎通拒否され、宛先には到達していない。
【００２７】
以上のように各トラヒックフローTf1乃至Tf3が順次疎通許可又は拒否された経過の後に、各ファイアウォール装置FW1乃至FW5には当該経過を記録したトラヒックログが残る。図2下段には各ファイアウォール装置のトラヒックログのうち、特に解析対象であるFW1及びFW2における例を示してある。(T1)、(T2)及び(T3)はFW1において記録されたそれぞれトラヒックフローTf1,Tf2及びTf3に対応するトラヒックログである。(T4)及び(T5)はFW2において記録されたそれぞれトラヒックフローTf1及びTf2に対応するトラヒックログである。なお、トラヒックログ(トラヒック情報)とトラヒックフローとの対応づけを行うことは本発明の特徴であり、詳細については後述する。
【００２８】
トラヒックログの項目内容は、例えば(T1)については項目の順に次の通りであり、上記トラヒックフローTf1の記録となっている。当該ログの項目の書式は、汎用的なファイアウォール装置の一例であるNetScreen(登録商標)における例であるが、別書式のログであっても同様に本発明は実施可能である。さらに前述の通り、本発明は必ずしもログという形式によらなくとも、同様の情報を取得することのできる任意のファイアウォール装置を対象とすることができる。
【００２９】
「FW1」ファイアウォール装置FW1にて取得されたトラヒックログである。
「acl1 policy=001」当該トラヒックT1のパケットは、FW1が有する各物理インタフェースのうち、アクセス制御リストacl1が設定されている物理インタフェースに到達し、当該アクセス制御リスト内のポリシID=001のポリシが適用された。
「src=(A)」当該トラヒックの送信元ホストは(A)である。（一般に、IPアドレスとして示される。）
「dst=(B)」当該トラヒックの宛先ホストは(B)である。（送信元と同様に、一般に、IPアドレスとして示される。）
【００３０】
「service=http」当該トラヒックが利用したサービスはhttpである。（その他にも、ssh,telnet,ftp,SMTPなど各種プロトコルのサービスがありうる。）
「action=allow」当該トラヒックはFW1において受信され、動作結果としては疎通を許可された。（拒否された場合は「action=deny」となる。）
「start_time=t1」当該トラヒックの発生日時すなわちFW1における受信日時はt1である。t1の部分は、一般に年・月・日・分・秒などで指定される。(なお、当該トラヒックフローに対応するFW2における受信日時はt1よりわずかに遅れたt1+dt1である。本発明では後述のように、このような情報から通過経路を求める。)
「duaration=1」当該トラヒックのFW1における継続時間は1(単位は所定の任意の単位)である。
「send=100」当該トラヒックの送信バイト数は100である。
「rcvd=10」当該トラヒックの受信バイト数は10である。
【００３１】
なおまた、図2下段には示していないが、トラヒックログの項目内容としてさらに送信元ポート番号「SrcPort」及び宛先ポート番号「DstPort」の指定があってもよい。その他にも種々の項目を利用してもよい。
【００３２】
図3に、本発明に係るトラヒック通過経路解析装置1の機能ブロック図を示す。トラヒック通過経路解析装置1は、ログ取得部2(又はトラヒック情報取得部2)、個別トラヒック情報作成部3、集約トラヒック情報作成部4、通過経路推定部5及び表示部6を備える。このうち個別トラヒック情報作成部3はさらに、到達装置識別部31、インタフェース識別部32、到達日時取得部33、送信元・宛先取得部34、ポート取得部35及び付属情報取得部36を含む。また通過経路推定部5は確度算出部51を含む。
【００３３】
図4に、本発明に係るトラヒック通過経路解析方法のフローチャートを示し、各ステップの説明と共に図3の各機能ブロックの役割を説明する。ステップS1では、ログ取得部2が、図1又は図2に示したような所定の複数のファイアウォール装置にアクセスして、又は当該複数のファイアウォール装置のトラヒックログを保管しているSyslogサーバ等にアクセスして、当該所定の複数のファイアウォール装置よりトラヒックログを取得する。あるいは、必ずしもログという形式を経ずに、所定の複数のファイアウォール装置に直接又は間接にアクセスして、トラヒック情報取得部2がトラヒックログの情報と同等のトラヒック情報を取得してもよい。
【００３４】
ステップS2では、ステップS1で取得した情報を用いて、個別トラヒック情報作成部3が個別トラヒック情報を作成する。個別トラヒック情報の例を図5に示す。図5の例は、図2で説明した解析対象となる各ファイアウォール装置FW1及びFW2の各ログ出力T1乃至T5に対する、個別トラヒック情報を表の形式で表している。図5に示すように、個別トラヒック情報とは、簡単に説明すれば各ファイアウォール装置から取得したトラヒックログをマージした情報である。
【００３５】
個別トラヒック情報作成部3はマージを行うためにまず、各トラヒックログに登場するトラヒック(T1乃至T5)に、一貫したユニークなIDを付与する。当該IDを、既にトラヒックログを説明した際に用いたT1乃至T5によって表すものとする。当該付与されたIDは、図5にトラヒックID(TID)の欄に示されている。
【００３６】
こうして識別された各トラヒック(個別トラヒックと呼ぶこととする)に対して、個別トラヒック情報作成部3に含まれる到達装置識別部31乃至付属情報取得部36は、以下のようにそれぞれトラヒックログから所定の情報を抽出して対応づける。なお、トラヒックログでは一般に1行毎に各トラヒックの情報が記載されているので、ある特定のトラヒックについての情報は全て同じ行より抽出される。
【００３７】
到達装置識別部31は当該個別トラヒックの到達したファイアウォール装置の情報を対応づける。例えば個別トラヒックT1にはファイアウォール装置FW1を対応付ける。また、インタフェース識別部32は、当該トラヒックが当該ファイアウォール装置において到達した物理インタフェースを取得する。
【００３８】
一般にファイアウォール装置は、パケット等の入力側及び出力側の両者において、複数の物理インタフェースを有することができる。インタフェース識別部32は、当該トラヒックが到達した(到達すなわち疎通許可及び疎通拒否の両方の場合を含む)、このような入力側及び出力側の物理インタフェースの識別情報を取得する。当該識別情報は、トラヒックログから取得するのであれば、各物理インタフェースにおいて設定されているアクセス制御リスト(acl)の名称などから取得することができる。例えば個別トラヒックT1には、ファイアウォール装置FW1におけるアクセス制御リストacl1の設定された物理インタフェースが、到達したインタフェースとして対応づけられる。なお、アクセス制御リストの項目が取得できない種類のログであれば、予め各ファイアウォール装置の構成情報を読み込んでおき、ログ内からアクセス制御リストの項目に対応する情報を抽出するようにすればよい。
【００３９】
これら到達装置識別部31及びインタフェース識別部32の両者で取得された情報はペアで、図5におけるトラヒック観測箇所(appeared at)の欄に示されている。例えば個別トラヒックT1に対しては「FW1 acl1」が対応づけられている。
【００４０】
到達日時取得部33は、当該個別トラヒックが当該ファイアウォール装置に到達した日時を取得する。すなわち、トラヒックログから取得するのでればstart_timeの項目を取得して当該個別トラヒックに対応づける。図5では例えば個別トラヒックT1に対しては、2010/09/16 20:29:00(2010年9月16日20時29分0秒)が対応づけられる。
【００４１】
送信元・宛先取得部34は、当該個別トラヒックの送信先及び宛先を取得する。すなわち、トラヒックログから取得するのであればsrc及びdstの項目をIPアドレスとして取得して当該個別トラヒックに対応づける。図5では例えば個別トラヒックT1に対しては送信元IPアドレス10.0.0.1及び宛先IPアドレス172.19.76.1が対応づけられる。
【００４２】
ポート取得部35は、当該個別トラヒックの送信元ポート番号及び宛先ポート番号の両者又はいずれか一方を取得する。ポート取得部35がポート番号を取得できる場合は、当該個別トラヒックはTCP又はUDPによるものとなる。
【００４３】
その他さらに、付属情報取得部36によって各種の情報を取得してもよい。例えば図5にそれぞれsend及びrcvdという項目で示されているように、当該個別トラヒックの送信バイト数及び受信バイト数を取得してもよい。
【００４４】
また付属情報取得部36では例えば利用プロトコルを取得してもよい。図5の例では個別トラヒックT1乃至T5は全てTCPプロトコルとなっておいる。付属情報取得部36はさらに、各プロトコルに特有の情報を取得してもよい。TCPプロトコルを利用している場合であれば、どのサービスを利用したかを取得してもよい。この場合トラヒックログから取得するのであれば、serviceの項目より取得する。
【００４５】
以上、ステップS2で各種情報を取得して個別トラヒック情報作成部3が個別トラヒック情報を作成すると、ステップS3では、集約トラヒック情報作成部4が個別トラヒック情報を用いて集約トラヒック情報を作成する。図6に集約トラヒック情報の例を示す。図6では集約トラヒック情報の例として、図5の個別トラヒック情報より作成された集約トラヒック情報が表形式で示されている。
【００４６】
集約トラヒック情報とは、個別トラヒック情報における個別トラヒックを集約すなわちグループ化して各集約トラヒックとした情報である。各集約トラヒックは、図2において説明したような順次発生したトラヒックフローの各々(Tf1,Tf2,Tf3等)を表すように、個別トラヒックから集約される。
【００４７】
集約トラヒック情報作成部4は各集約トラヒックを求めてIDを付与する。当該IDは図6においてATID(Aggregated Traffic ID)すなわち集約トラヒックIDの欄にAT1,AT2,AT3,…等のように示されている。例えばAT1は図2におけるトラヒックフローTf1に相当し、当該AT1を構成している個別トラヒック欄(consists of欄)に示されているように、図6の個別トラヒックT1及びT4を集約したものである。同様にAT2はトラヒックフローTf2に相当し、個別トラヒックT2及びT3を集約したものである。AT3はトラヒックフローTf3に相当し、集約の結果、構成個別トラヒックはT3のみとなったものである。
【００４８】
構成個別トラヒックの数は集約数(aggregate count)の欄に示され、AT1,AT2,AT3でそれぞれ2,2,1となっている。なお、図6では解析対象のファイアウォール装置がFW1及びFW2の2台であり、個別トラヒックが2個以内で構成される集約トラヒックが例として示されているが、解析対象のファイアウォール装置が3台以上であれば、個別トラヒックが3個以上で構成される集約トラヒックも作成されうる。
【００４９】
集約トラヒック情報作成部4がこのような集約トラヒックを作成する各実施形態は次の通りである。
【００５０】
一実施形態では、同一の集約トラヒックに属する個別トラヒック同士が満たすべき最低限の条件である、送信元及び宛先の同一性を利用する。送信元及び宛先については、送信元・宛先取得部34による取得によって、個別トラヒック情報において参照可能となっている。さらに、一般に送信元及び宛先のみならず、同一の集約トラヒックでは利用ポート番号も共通であるので、集約トラヒック情報作成部4はポート取得部35で取得されたポート番号の同一性も利用してよい。
【００５１】
図6に示されているように、例えば集約トラヒックAT1については、送信元IPアドレス(Src IP)及び宛先IPアドレス(Dst IP)はそれぞれ10.0.0.1及び172.19.76.1であり、構成個別トラヒックT1及びT4におけるアドレスと同一のアドレスである。また、ポート番号(送信元Src Port及び宛先Dst Port)も同様に、T1及びT4における番号と同一となっている。
【００５２】
また、ネットワークが正常に動作していれば一般に、同一ファイアウォール装置を2回以上経由するトラヒックフローは存在しない。よって、追加的な一実施形態として、集約トラヒック情報作成部4では、同一の集約トラヒック内に到達装置識別部31が取得したファイアウォール装置が同一のものが存在しないように集約トラヒック情報を作成してもよい。同様の理由でさらに、各ファイアウォール装置においてインタフェース識別部32が取得した物理インタフェースの区別まで含めて同一のものが存在しないように集約トラヒック情報を作成してもよい。
【００５３】
さらにまた、1つのトラヒックフローのデータが順次ファイアウォール装置で中継処理された場合、到達時刻はほぼ同一時刻となる。より正確には、到達時刻は所定範囲内での一連の値として得られる。よって、同一の集約トラヒックに属するための追加の条件として、到達日時取得部33で取得した到達日時同士が所定範囲内に収まることを利用することができる。
【００５４】
例えばAT1では、個別トラヒックT1及びT4の到達日時は、
T1：2010/09/16 20:29:00すなわち(2010年9月16日20時29分0秒)
T4：2010/09/16 20:29:01すなわち(2010年9月16日20時29分1秒)
である。T1とT4との到達日時の差が1秒（当該1秒は例としての値である）であり、T1又はT4とその他の個別トラヒックとの到達日時の差は1分以上ある。このことから、T1及びT4が同一の集約トラヒックAT1に属し、その他のトラヒックは別の集約トラヒックに属するという判断を行うことができる。AT1に対しては、到達日時の情報がstart timeの欄に最先のT1の値で代表して、2010/09/16 20:29:0〜として示されている。同様にして、到達日時の差が1秒である個別トラヒックT2とT5とが集約トラヒックAT2に属するという判断も行うことができる。
【００５５】
当該到達時刻を利用する実施形態も、送信元及び宛先の同一性と同様に、本発明において必須である。特に後述のステップS4で通過経路における順序を求めるために必須である。
【００５６】
なおまた、上記のような到達時刻による集約トラヒックの判断を行う前提として、図4のステップS1では、予め各ファイアウォール装置における計時情報同士の同期を取ってから、トラヒックログ等を取得するものとする。もしくは、各ファイアウォール装置における計時情報同士には誤差が存在することを前提に、ログ取得部2で取得するトラヒックログにおける各ファイアウォール装置のクロックで記載された到達時刻を、トラヒック通過経路解析装置1のクロックに修正するようにしてもよい。
【００５７】
例えば、ファイアウォール装置FW1のクロックを1秒後方に修正することでトラヒック通過経路解析装置1のクロックと一致し、また、ファイアウォール装置FW2のクロックを2秒後方に修正することでトラヒック通過経路解析装置1のクロックと一致する、ということを予め計測しておき、FW1での到達時刻とFW2での到達時刻とを一律にトラヒック通過経路解析装置1におけるクロック情報に修正する。
【００５８】
以上のような各実施形態の組み合わせの他にも、到達装置識別部31乃至付属情報取得部36で取得した各情報の同一性又は類似性を利用して、集約トラヒック情報の作成を行うことができる。例えば図6では、付属情報取得部36で取得した送信バイト数及び受信バイト数もsend/rcvd欄に示されている。このような情報も追加利用してよい。
【００５９】
以上のように、図4のステップS3において集約トラヒック情報作成部4が集約トラヒック情報を作成した後、ステップS4では、通過経路推定部5が集約トラヒック情報を用いて通過経路を推定する。図7は通過経路を推定するフローチャートであり、図4のステップS4内の詳細フローである。
【００６０】
図7の各ステップS41乃至S43は、繰り返し判断のステップS44に示されているように、集約トラヒック情報の各集約トラヒックATi(i=1,2,3,…)につき順次実行され、全ての集約トラヒックについて処理が行われる。開始ステップS40では集約トラヒックの識別カウンタi=1として、1番目の集約トラヒックAT1を処理対象として定め、ステップS41に進む。
【００６１】
ステップS41では、i番目の集約トラヒックATiにつき、通過経路情報を構築する。通過経路情報とは、集約トラヒックを構成する全個別トラヒックに共通の送信元から同じく共通の宛先に至る際の、当該集約トラヒックに対応するトラヒックフローが通過したファイアウォール装置及び物理インタフェースの順序としての通過経路(パス)を特定する情報であり、当該送信元及び宛先と対応付けて構築される。ここで、ファイアウォール装置及び物理インタフェースの通過順序は、集約トラヒック情報(及び個別トラヒック情報)を参照して、当該ファイアウォール装置及び物理インタフェースに対応する個別トラヒックの到達日時(図5のstart time)の順に定められる。
【００６２】
ステップS42では、ATiより構築された通過経路に基づき、それまでに作成されている通過経路情報の全体を更新する。すなわち、当該ATiの通過経路と同じ通過経路が既に作成されている通過経路情報内に存在するならば、新規の通過経路の追加(及びID付与)は行わず、逆に存在しないのならば、新規の通過経路として追加(及びID付与)を行う。
【００６３】
ステップS43では、当該集約トラヒックATiと通過経路情報との対応づけを行う。当該対応づけは、ステップS42と異なり、ATiより構築された通過経路が既に存在するか否かによらずに行う。
【００６４】
ステップS44では前述の通り、全ての集約トラヒックATiにつき処理が行われたか判断し、行われていないのであればカウンタiを1つ増やして次の集約トラヒックAT(i+1)につきステップS41乃至S43の処理を行う。
【００６５】
図8に、以上のようなフローに従って順次作成・更新される通過経路情報の例などを、表形式で示す。図8の(1)がステップS42での通過経路情報の例であり、(2)がステップS43での集約トラヒックと通過経路との対応づけの例である。各表はステップS40において項目部分以外が空欄の状態であり、以降のステップを辿るごとに上段側から順次作成される。図8では、(1)におけるP1及びP2の行と、(2)におけるAT1,AT2及びAT3の行は、図6に示す集約トラヒック情報をAT1から始めて順次処理して得られるものであり、AT1,AT2及びAT3については図6と図8で共通である。
【００６６】
図8の(1)には通過経路情報の例が示されている。PIDは通過経路情報を構成する通過経路に順次付与されるIDである。各通過経路には、送信元(Src IP)と、途中到達するファイアウォール装置及び物理インタフェース(FW/acl名)並びにそれらの到達順列と、宛先(Dst IP)とが対応付けられている。ＩＤがP1の通過経路P1は、最初の処理対象である図6の集約トラヒックAT1より構築されたものであり、以下[1]〜[4]のように順次特定されている。
[1]送信元(10.0.0.1)より送信→[2](FW1 acl1)を通過→[3](FW2 acl2)を通過→[4]宛先(172.19.76.1)に到達
ここで特に[2][3]の順序については、前述の個別トラヒックT1及びT4の到達時刻の順で定められている。そして当該最初に処理された集約トラヒックAT1は、(2)に示すように通過経路P1と対応づけられる。
【００６７】
AT1の次の、2番目に処理される集約トラヒックAT2は、通過経路がAT1で求められたP1と同様となるので、(1)の表に新規ID追加は行われない。そして(2)で示すように、AT2とP1とを対応づける。3番目に処理される集約トラヒックAT3は、図2で説明したようにFW1において疎通拒否され、図6に示すように個別トラヒックT3のみで構成される。従ってAT3の通過経路は、
[1]送信元(10.0.0.1)より送信→[2](FW acl1)に到達して遮断される→[3]宛先(172.19.76.1)には到達せず
となり、P1とは異なるので新規にIDが付与され、(1)に示すように通過経路P2が対応づけられる。さらに(2)に示すようにAT3とP2との対応づけが行われる。なお、(1)には示していないが、通過経路情報の各々は疎通許可／拒否の情報を追加で含んでいてもよい。
【００６８】
さらに、図8では4番目に処理された集約トラヒックAT4についての結果も示されている。当該AT4の通過経路はP1と宛先及びFW2における通過物理インタフェースが異なり、またP2とも異なるので、新たな通過経路としてP3が追加されている。
【００６９】
なお、図7及び図8の説明では、通過経路の特定は通過したファイアウォール装置及び物理インタフェースの順序によって行うとしたが、物理インタフェースの特定を除外して、より簡略に、通過したファイアウォール装置のみの順序によって行ってもよい。
【００７０】
以上、ステップS4で通過経路推定部5が通過経路の推定を行うと、次にステップS5では、推定された通過経路の情報に基づいて確度算出部51が各通過経路についての確度の算出を行う。なお、当該ステップS5はオプションであり、スキップしてもよい。
【００７１】
確度とは、各通過経路の「確からしさ」を数値化したものであり、次のような事情に基づいて数値化されるものである。通常、同一対地(送信元/宛先 IPの対)間のトラヒックフローには、すべて同一の通過経路が紐付く(対応付けられる)はずである。しかし障害、パケット順序逆転、ファイアウォール装置でのログ処理遅滞による記録到達時刻の誤差などのため、トラヒック登場順序の一時的ずれが生じる場合もありうる。この結果、同一対地間のトラヒックフローに複数の異なる通過経路が紐付いて見え、管理者が通過経路判別を誤る可能性がある。また、上記T3(AT3)のように中途でdenyとなるトラヒックフローとなる可能性もある。
【００７２】
そこで、同一対地間の通過経路であるが、途中通過するファイアウォール装置及び物理インタフェースが通過順列全体として異なる通過経路同士について、紐付けられた集約トラヒックの数（登場頻度）をカウントして確度を与えることができる。なお、一般に障害等の発生は正常状態に比べてまれであるという前提のもと、登場頻度を確度として利用することができる。
【００７３】
例えば、図8の(2)のAT1からAT4まで処理された状態での、同一対地(送信元 IPアドレス=10.0.0.1、宛先 IPアドレス=172.19.76.1)間の通過経路であるP1とP2についての確度f(P)は、次のように求めることができる。すなわち、P1にはAT1及びAT2の2個が紐付けられ、P2にはAT3の1個が紐付けられていることから、
f(P1)=2/3, f(P2)=1/3
として求められる。
【００７４】
すなわち上記の例は、確度算出部51が、送信元及び宛先が共通であり通過の順列が異なる通過経路の各々に対して、各通過経路に対応づけられた集約トラヒックの数に基づいた確度を与える例である。
【００７５】
前述のように、通過経路情報の各々に疎通許可／拒否の情報をも追加で含めるならば、当該情報を確度算出に利用することで、上記のような登場頻度のみで算出される確度よりもさらに精度の高い確度を求めるようにすることもできる。あるいは、登場頻度のみで確度を算出して、詳細を確認したい場合には、管理者が適宜トラヒックログの情報に遡って確認するようにしてもよい。
【００７６】
以上、図4の各ステップの処理及び対応する図3のログ取得部2乃至通過経路推定部5の役割を説明した。本発明においては、表示部6によって、適宜各ステップでの途中経過及び最終結果を表示し、管理者などの判断に供することができる。すなわち、管理者からの表示要求に応じて、図5のような個別トラヒック情報、図6のような集約トラヒック情報、図8のような通過経路情報、ステップS5で算出する同一対地間の通過経路同士の確度などを、表示部6を用いて適宜表示することができる。当該管理者からの要求に応じた表示に関しては、GUI(グラフィカルユーザインタフェース)やCLI(コマンドラインインタフェース)など、種々の周知の手法を利用することができる。
【００７７】
なお本発明は、図4の各ステップをコンピュータに実行させることで、当該コンピュータを図3に記載のトラヒック通過経路解析装置として機能させるトラヒック通過経路解析プログラムとして実施することもできる。当該コンピュータは当該プログラムを読み込んで、上記各ステップを実行するトラヒック通過経路解析装置として機能する。
【００７８】
以上、本発明によれば、汎用的なファイアウォール装置において通常取得可能な各種項目からなる個別トラヒック情報に基づいて、トラヒックフローの通過経路を推定することができる。特に、個別トラヒック情報を汎用的なファイアウォール装置におけるトラヒックログを参照して作成することで、過負荷や追加コストなどを避けて通過経路を推定することができる。
【符号の説明】
【００７９】
1…トラヒック通過経路解析装置、2…ログ取得部(トラヒック情報取得部)、3…個別トラヒック情報作成部、4…集約トラヒック情報作成部、5…通過経路推定部、6…表示部
【技術分野】
【０００１】
本発明はトラヒック通過経路解析に関し、特に、汎用的なファイアウォール装置において通常利用可能な機能に基づいて、トラヒックフローを省力かつ高精度に把握可能とするトラヒック通過経路解方法、プログラム及び装置に関する。
【背景技術】
【０００２】
ファイアウォール(Firewall)装置は、管理対象ネットワークと外部ネットワークとの接続点に設置されるルータの一種である。ファイアウォール装置は、管理対象ネットワークの安全性を高めるために、組織毎のトラヒック疎通方針（セキュリティ・ポリシ、以下「ポリシ情報」という）に基づいて必要なパケットのみを通過させ、危険なパケットを阻止する。従って、ファイアウォール装置の構成情報（ルール情報）は、そのポリシ情報に基づいて適切に設定される必要がある。尚、ファイアウォール装置は、管理対象ネットワーク内のセグメントネットワーク同士の間（例えば部署aのイントラネットと部署bのイントラネットとの間）に配置されるものであってもよい。
【０００３】
一般に、ネットワーク管理者は、各部署（例えば各イントラネットの管理者）から、ファイアウォール装置の設定を依頼する「オーダシート（依頼書）」を受け取る。ネットワーク管理者は、それらオーダシートと組織の基本方針とに基づいて、「ポリシ情報」を作成する。ポリシ情報は、複数の「ポリシ要素」の順列によって構成される。ファイアウォール管理装置は、そのポリシ情報に基づいて、ファイアウォール装置毎に「ルール情報」を作成する。ルール情報も、複数の「ルール要素」の順列によって構成される。そして、ファイアウォール管理装置は、ファイアウォール装置毎に、ルール情報を送信する。
【０００４】
構築済みのネットワークを対象に、ファイアウォールやルータのトラヒック疎通状態が設計通りか否かを評価、診断の上、問題箇所を指摘し修正する作業を行う場合がある。そこではトラヒックフローの現状分析が課題となる。トラヒックフローとは、例えば、計算機A0から計算機B0へのトラヒックはファイアウォールFW1, FW2を経由する、といった通過経路の情報である。このような情報の解析は、小規模かつ静的な経路設定のみで運用されるネットワークでは、属人的な作業により実現することも可能である。しかし今日、ファイアウォールやルータが10台以上あったり、動的経路制御を用いるようなネットワーク構成が通常である。このような環境では属人的な作業によって誤りなく速やかに分析を行うことは不可能である。
【０００５】
このような事情に関連して、以下の従来技術(NetFlow, 非特許文献１, 非特許文献2)では、汎用のファイアウォール装置に新たな機能や付加装置を追加することで、ファイアウォール上のトラヒックフローの解析が可能となる。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】Cisco、「Introduction to Cisco IOS NetFlow - A Technical Overview」、[online]、［平成23年2月21日検索］、インターネット＜URL:http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6555/ps6601/prod_white_paper0900aecd80406232.html＞
【非特許文献２】Cisco、「IETF RFC 3954: Cisco Systems NetFlow Services Export Version 9」、[online]、［平成23年2月21日検索］、インターネット＜URL:http://www.ietf.org/rfc/rfc3954.txt＞
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら上記の従来技術は、在来の汎用的な装置で利用できないことや、ファイアウォール装置の負荷増大、負荷装置の導入・設置手間・コストが実用上の問題となる。
【０００８】
本発明の目的は、上記の従来技術の課題を解決し、必ずしも汎用には利用し難い手法(例えば、動的経路情報やNetFlowなど、ファイアウォール装置に負荷のかかる手法)を用いず、汎用的なファイアウォール装置にて通常利用可能な機能に基づいて、ネットワークのトラヒックフローを省力かつ高精度に把握可能とするトラヒック通過経路解析方法、プログラム及び装置を提供することにある。
【課題を解決するための手段】
【０００９】
上記の従来技術の課題を解決するため、本発明はトラヒック通過経路解析方法であって、所定の複数のファイアウォール装置より、各ファイアウォール装置における各トラヒックの到達日時と、当該トラヒックが到達したファイアウォール装置と、当該トラヒックの送信元及び宛先と、の情報を対応付けて取得して個別トラヒック情報とする段階と、前記個別トラヒック情報を構成する各個別トラヒックを、その送信元及び宛先の一致並びに到達日時の所定基準内での近接に基づいてグループ化して集約トラヒック情報とする段階と、前記集約トラヒック情報を構成する各集約トラヒックに対して、当該集約トラヒックに属する各個別トラヒックの到達日時の順に、各個別トラヒックが到達したファイアウォール装置の順列を求め、該順列を当該集約トラヒックに共通の送信元から宛先へ至るトラヒックフロー全体としての通過経路として推定する段階を備えることを特徴とする。
【００１０】
また、本発明はトラヒック通過経路プログラムであって、コンピュータに前記トラヒック解析方法を実行させることで当該コンピュータをトラヒック通過経路解析装置として機能させることを特徴とする。
【００１１】
また、本発明はトラヒック通過経路解析装置であって、所定の複数のファイアウォール装置より、各ファイアウォール装置における各トラヒックの到達日時と、当該トラヒックが到達したファイアウォール装置と、当該トラヒックの送信元及び宛先と、の情報を対応付けて取得して個別トラヒック情報を作成する個別トラヒック情報作成部と、前記個別トラヒック情報を構成する各個別トラヒックを、その送信元及び宛先の一致並びに到達日時の所定基準内での近接に基づいてグループ化して集約トラヒック情報を作成する集約トラヒック情報作成部と、前記集約トラヒック情報を構成する各集約トラヒックに対して、当該集約トラヒックに属する各個別トラヒックの到達日時の順に、各個別トラヒックが到達したファイアウォール装置の順列を求め、該順列を当該集約トラヒックに共通の送信元から宛先へ至るトラヒックフロー全体としての通過経路として推定する通過経路推定部を備えることを特徴とする。
【００１２】
さらに、前記個別トラヒック情報を各ファイアウォール装置の記録したトラヒックログを参照して求めることを特徴とする。
【発明の効果】
【００１３】
本発明によれば、汎用的なファイアウォール装置において通常取得可能な各種項目からなる個別トラヒック情報に基づいて、トラヒックフローの通過経路を推定することができる。特に、個別トラヒック情報を汎用的なファイアウォール装置におけるトラヒックログを参照して作成することで、過負荷や追加コストなどを避けて通過経路を推定することができる。
【図面の簡単な説明】
【００１４】
【図１】本発明に係るシステムの一例を示す図である。
【図２】本発明を説明するためのトラヒックフローおよびトラヒックログ(トラヒック情報)の例である。
【図３】本発明のトラヒック通過経路解析装置の機能ブロック図である。
【図４】本発明のトラヒック通過経路解析方法のフローチャートである。
【図５】個別トラヒック情報を表形式で示した例である。
【図６】集約トラヒック情報を表形式で示した例である。
【図７】通過経路を推定するフローチャートである。
【図８】通過経路推定フローに伴って更新される通過経路情報や、集約トラヒックと通過経路との対応情報の例である。
【発明を実施するための形態】
【００１５】
以下に、図面を参照して本発明を詳細に説明する。図1は、本発明に係るシステムの一例であり、トラヒック通過経路解析装置と、通過するトラヒックフローの解析対象となるファイアウォール装置との関係の一例を示す図である。
【００１６】
トラヒック通過経路解析装置1は、解析対象である所定の複数のファイアウォール装置20から必要な情報を取得して、トラヒックフローを解析する。ファイアウォール装置20は、管理対象ネットワーク50と、一般にインターネット全体70に含まれる外部ネットワーク60との間に配置される。管理対象ネットワーク50は複数の内部ネットワーク40を含み、当該ネットワーク内のパケット転送をルータ30が担う。
【００１７】
例えば、管理対象ネットワーク50はある会社のネットワークであり、内部ネットワーク40は当該会社の各部署のイントラネットである。なお、図1では必ずしもそのような配置で示されていないが、ファイアウォール装置20は、管理対象ネットワーク50と外部ネットワーク60との間のみでなく、管理対象ネットワーク50内の内部ネットワーク40の間に配置されるものであってもよい。
【００１８】
本発明では基本的に、図1のように解析対象のファイアウォール装置20が管理対象ネットワーク50内にあることを想定する。そしてトラヒック通過経路解析装置1は、これらファイアウォール装置20の管理も担う装置であれば、解析したトラヒックフローが管理上の基本情報として有効に活用できるため好ましい。しかし、必要な情報を取得できさえすれば、管理対象ネットワーク50の内外を問わず、任意のファイアウォール装置を解析対象に加えることができる。
【００１９】
ファイアウォール装置20は、外部ネットワーク60（又は内部のセグメントネットワーク40）から受信したパケットが、いずれのルール要素に該当するか照合する。そして、該当するルール要素に記述されるアクションに基づいて、そのパケットの転送可否が決定される。
【００２０】
ファイアウォール装置20は、パケット毎の疎通結果を、「トラヒックログ」(または「アクセスログ」)として記録することができる。「トラヒックログ」とは、どのパケットに対し、どのルール要素によって、どのアクションを採ったかを表す記録である。本発明においては、ファイアウォール装置20から必要な情報を取得できるように、予め対応するトラヒックログの項目を記録するように設定しておくものとする。
【００２１】
トラヒックログの取得は、ファイアウォール装置20が所定期間に渡って取得した後に、Syslogプロトコルなどによって図1に不図示のログ保管サーバに送信し、保管したログをトラヒック通過経路解析装置1が取得してもよい。また、ファイアウォール装置20から直接取得してもよい。いずれにせよ、ファイアウォール装置20に過負荷を掛けないような任意の手法によって取得することができる。
【００２２】
なおまた、本発明においてトラヒック通過経路解析装置1に必要となる情報はトラヒックログから取得するものとして説明するが、本発明はこれに限定されるものではない。すなわち、ファイアウォール装置20におけるトラヒックに対する同様の情報を取得することができ、ファイアウォール装置20に過負荷を掛けないならば、必ずしもログ経由で情報を取得する必要はない。本発明においてトラヒックログを利用するのは、汎用のファイアウォール装置20において通常の管理手法において記録することが可能であり、比較的容易に取得しうる情報の一実施形態としての利用である。この際、トラヒックログに記録可能な全ての種類の情報が必要となるわけでもない。なおまた、各情報の技術的意義の説明を容易にするための便宜としても、一般的なトラヒックログの用語又は略語を適宜借用して説明を行うものとする。
【００２３】
図2は、本発明を説明するために一貫して用いるトラヒックフロー及びトラヒックログ(前述の通り、トラヒックログはより一般には、トラヒック情報であってもよい)の例である。図2の上段側には、所定配置のファイアウォール装置FW1乃至FW5及びトラヒックの送信元又は宛先となるホスト(A)(B)(C)が例として示されている。なお、これらファイアウォール装置のうち、FW1及びFW2を解析対象として定めることとする。
【００２４】
なお、図1ではシステム全体を説明するために、特に区別を設けない一連のファイアウォール装置20として説明したが、本発明においてはファイアウォール装置同士の区別が必要である。よって、以降の説明でファイアウォール装置を参照する際には当該FW1乃至FW5などを用いるとする。
【００２５】
図2では、順次発生したトラヒックフローの例として以下のようなTf1、Tf2及びTf3が示されている。
Tf1及びTf2：送信元(src)=(A)、宛先(dst)=(B)、利用サービス(service)=http
Tf3：送信元(src)=(A)、宛先(dst)=(B)、利用サービス(service)=ssh
【００２６】
図2上段に示すように、Tf1は送信元(A)より宛先(C)へと送られたhttpサービスのパケットのトラヒックフローであり、途中でファイアウォール装置FW1、FW2及びFW3を順次疎通許可され通過して宛先に到達している。同じくTf2も送信元(A)より宛先(C)へと送られたhttpサービスのパケットのトラヒックフローであり、途中でファイアウォール装置FW1、FW2及びFW3を順次通過している宛先に到達している。さらに、Tf3は送信元(A)より宛先(C)へと送られたsshサービスのパケットのトラヒックフローであるが、途中でファイアウォール装置FW1において疎通拒否され、宛先には到達していない。
【００２７】
以上のように各トラヒックフローTf1乃至Tf3が順次疎通許可又は拒否された経過の後に、各ファイアウォール装置FW1乃至FW5には当該経過を記録したトラヒックログが残る。図2下段には各ファイアウォール装置のトラヒックログのうち、特に解析対象であるFW1及びFW2における例を示してある。(T1)、(T2)及び(T3)はFW1において記録されたそれぞれトラヒックフローTf1,Tf2及びTf3に対応するトラヒックログである。(T4)及び(T5)はFW2において記録されたそれぞれトラヒックフローTf1及びTf2に対応するトラヒックログである。なお、トラヒックログ(トラヒック情報)とトラヒックフローとの対応づけを行うことは本発明の特徴であり、詳細については後述する。
【００２８】
トラヒックログの項目内容は、例えば(T1)については項目の順に次の通りであり、上記トラヒックフローTf1の記録となっている。当該ログの項目の書式は、汎用的なファイアウォール装置の一例であるNetScreen(登録商標)における例であるが、別書式のログであっても同様に本発明は実施可能である。さらに前述の通り、本発明は必ずしもログという形式によらなくとも、同様の情報を取得することのできる任意のファイアウォール装置を対象とすることができる。
【００２９】
「FW1」ファイアウォール装置FW1にて取得されたトラヒックログである。
「acl1 policy=001」当該トラヒックT1のパケットは、FW1が有する各物理インタフェースのうち、アクセス制御リストacl1が設定されている物理インタフェースに到達し、当該アクセス制御リスト内のポリシID=001のポリシが適用された。
「src=(A)」当該トラヒックの送信元ホストは(A)である。（一般に、IPアドレスとして示される。）
「dst=(B)」当該トラヒックの宛先ホストは(B)である。（送信元と同様に、一般に、IPアドレスとして示される。）
【００３０】
「service=http」当該トラヒックが利用したサービスはhttpである。（その他にも、ssh,telnet,ftp,SMTPなど各種プロトコルのサービスがありうる。）
「action=allow」当該トラヒックはFW1において受信され、動作結果としては疎通を許可された。（拒否された場合は「action=deny」となる。）
「start_time=t1」当該トラヒックの発生日時すなわちFW1における受信日時はt1である。t1の部分は、一般に年・月・日・分・秒などで指定される。(なお、当該トラヒックフローに対応するFW2における受信日時はt1よりわずかに遅れたt1+dt1である。本発明では後述のように、このような情報から通過経路を求める。)
「duaration=1」当該トラヒックのFW1における継続時間は1(単位は所定の任意の単位)である。
「send=100」当該トラヒックの送信バイト数は100である。
「rcvd=10」当該トラヒックの受信バイト数は10である。
【００３１】
なおまた、図2下段には示していないが、トラヒックログの項目内容としてさらに送信元ポート番号「SrcPort」及び宛先ポート番号「DstPort」の指定があってもよい。その他にも種々の項目を利用してもよい。
【００３２】
図3に、本発明に係るトラヒック通過経路解析装置1の機能ブロック図を示す。トラヒック通過経路解析装置1は、ログ取得部2(又はトラヒック情報取得部2)、個別トラヒック情報作成部3、集約トラヒック情報作成部4、通過経路推定部5及び表示部6を備える。このうち個別トラヒック情報作成部3はさらに、到達装置識別部31、インタフェース識別部32、到達日時取得部33、送信元・宛先取得部34、ポート取得部35及び付属情報取得部36を含む。また通過経路推定部5は確度算出部51を含む。
【００３３】
図4に、本発明に係るトラヒック通過経路解析方法のフローチャートを示し、各ステップの説明と共に図3の各機能ブロックの役割を説明する。ステップS1では、ログ取得部2が、図1又は図2に示したような所定の複数のファイアウォール装置にアクセスして、又は当該複数のファイアウォール装置のトラヒックログを保管しているSyslogサーバ等にアクセスして、当該所定の複数のファイアウォール装置よりトラヒックログを取得する。あるいは、必ずしもログという形式を経ずに、所定の複数のファイアウォール装置に直接又は間接にアクセスして、トラヒック情報取得部2がトラヒックログの情報と同等のトラヒック情報を取得してもよい。
【００３４】
ステップS2では、ステップS1で取得した情報を用いて、個別トラヒック情報作成部3が個別トラヒック情報を作成する。個別トラヒック情報の例を図5に示す。図5の例は、図2で説明した解析対象となる各ファイアウォール装置FW1及びFW2の各ログ出力T1乃至T5に対する、個別トラヒック情報を表の形式で表している。図5に示すように、個別トラヒック情報とは、簡単に説明すれば各ファイアウォール装置から取得したトラヒックログをマージした情報である。
【００３５】
個別トラヒック情報作成部3はマージを行うためにまず、各トラヒックログに登場するトラヒック(T1乃至T5)に、一貫したユニークなIDを付与する。当該IDを、既にトラヒックログを説明した際に用いたT1乃至T5によって表すものとする。当該付与されたIDは、図5にトラヒックID(TID)の欄に示されている。
【００３６】
こうして識別された各トラヒック(個別トラヒックと呼ぶこととする)に対して、個別トラヒック情報作成部3に含まれる到達装置識別部31乃至付属情報取得部36は、以下のようにそれぞれトラヒックログから所定の情報を抽出して対応づける。なお、トラヒックログでは一般に1行毎に各トラヒックの情報が記載されているので、ある特定のトラヒックについての情報は全て同じ行より抽出される。
【００３７】
到達装置識別部31は当該個別トラヒックの到達したファイアウォール装置の情報を対応づける。例えば個別トラヒックT1にはファイアウォール装置FW1を対応付ける。また、インタフェース識別部32は、当該トラヒックが当該ファイアウォール装置において到達した物理インタフェースを取得する。
【００３８】
一般にファイアウォール装置は、パケット等の入力側及び出力側の両者において、複数の物理インタフェースを有することができる。インタフェース識別部32は、当該トラヒックが到達した(到達すなわち疎通許可及び疎通拒否の両方の場合を含む)、このような入力側及び出力側の物理インタフェースの識別情報を取得する。当該識別情報は、トラヒックログから取得するのであれば、各物理インタフェースにおいて設定されているアクセス制御リスト(acl)の名称などから取得することができる。例えば個別トラヒックT1には、ファイアウォール装置FW1におけるアクセス制御リストacl1の設定された物理インタフェースが、到達したインタフェースとして対応づけられる。なお、アクセス制御リストの項目が取得できない種類のログであれば、予め各ファイアウォール装置の構成情報を読み込んでおき、ログ内からアクセス制御リストの項目に対応する情報を抽出するようにすればよい。
【００３９】
これら到達装置識別部31及びインタフェース識別部32の両者で取得された情報はペアで、図5におけるトラヒック観測箇所(appeared at)の欄に示されている。例えば個別トラヒックT1に対しては「FW1 acl1」が対応づけられている。
【００４０】
到達日時取得部33は、当該個別トラヒックが当該ファイアウォール装置に到達した日時を取得する。すなわち、トラヒックログから取得するのでればstart_timeの項目を取得して当該個別トラヒックに対応づける。図5では例えば個別トラヒックT1に対しては、2010/09/16 20:29:00(2010年9月16日20時29分0秒)が対応づけられる。
【００４１】
送信元・宛先取得部34は、当該個別トラヒックの送信先及び宛先を取得する。すなわち、トラヒックログから取得するのであればsrc及びdstの項目をIPアドレスとして取得して当該個別トラヒックに対応づける。図5では例えば個別トラヒックT1に対しては送信元IPアドレス10.0.0.1及び宛先IPアドレス172.19.76.1が対応づけられる。
【００４２】
ポート取得部35は、当該個別トラヒックの送信元ポート番号及び宛先ポート番号の両者又はいずれか一方を取得する。ポート取得部35がポート番号を取得できる場合は、当該個別トラヒックはTCP又はUDPによるものとなる。
【００４３】
その他さらに、付属情報取得部36によって各種の情報を取得してもよい。例えば図5にそれぞれsend及びrcvdという項目で示されているように、当該個別トラヒックの送信バイト数及び受信バイト数を取得してもよい。
【００４４】
また付属情報取得部36では例えば利用プロトコルを取得してもよい。図5の例では個別トラヒックT1乃至T5は全てTCPプロトコルとなっておいる。付属情報取得部36はさらに、各プロトコルに特有の情報を取得してもよい。TCPプロトコルを利用している場合であれば、どのサービスを利用したかを取得してもよい。この場合トラヒックログから取得するのであれば、serviceの項目より取得する。
【００４５】
以上、ステップS2で各種情報を取得して個別トラヒック情報作成部3が個別トラヒック情報を作成すると、ステップS3では、集約トラヒック情報作成部4が個別トラヒック情報を用いて集約トラヒック情報を作成する。図6に集約トラヒック情報の例を示す。図6では集約トラヒック情報の例として、図5の個別トラヒック情報より作成された集約トラヒック情報が表形式で示されている。
【００４６】
集約トラヒック情報とは、個別トラヒック情報における個別トラヒックを集約すなわちグループ化して各集約トラヒックとした情報である。各集約トラヒックは、図2において説明したような順次発生したトラヒックフローの各々(Tf1,Tf2,Tf3等)を表すように、個別トラヒックから集約される。
【００４７】
集約トラヒック情報作成部4は各集約トラヒックを求めてIDを付与する。当該IDは図6においてATID(Aggregated Traffic ID)すなわち集約トラヒックIDの欄にAT1,AT2,AT3,…等のように示されている。例えばAT1は図2におけるトラヒックフローTf1に相当し、当該AT1を構成している個別トラヒック欄(consists of欄)に示されているように、図6の個別トラヒックT1及びT4を集約したものである。同様にAT2はトラヒックフローTf2に相当し、個別トラヒックT2及びT3を集約したものである。AT3はトラヒックフローTf3に相当し、集約の結果、構成個別トラヒックはT3のみとなったものである。
【００４８】
構成個別トラヒックの数は集約数(aggregate count)の欄に示され、AT1,AT2,AT3でそれぞれ2,2,1となっている。なお、図6では解析対象のファイアウォール装置がFW1及びFW2の2台であり、個別トラヒックが2個以内で構成される集約トラヒックが例として示されているが、解析対象のファイアウォール装置が3台以上であれば、個別トラヒックが3個以上で構成される集約トラヒックも作成されうる。
【００４９】
集約トラヒック情報作成部4がこのような集約トラヒックを作成する各実施形態は次の通りである。
【００５０】
一実施形態では、同一の集約トラヒックに属する個別トラヒック同士が満たすべき最低限の条件である、送信元及び宛先の同一性を利用する。送信元及び宛先については、送信元・宛先取得部34による取得によって、個別トラヒック情報において参照可能となっている。さらに、一般に送信元及び宛先のみならず、同一の集約トラヒックでは利用ポート番号も共通であるので、集約トラヒック情報作成部4はポート取得部35で取得されたポート番号の同一性も利用してよい。
【００５１】
図6に示されているように、例えば集約トラヒックAT1については、送信元IPアドレス(Src IP)及び宛先IPアドレス(Dst IP)はそれぞれ10.0.0.1及び172.19.76.1であり、構成個別トラヒックT1及びT4におけるアドレスと同一のアドレスである。また、ポート番号(送信元Src Port及び宛先Dst Port)も同様に、T1及びT4における番号と同一となっている。
【００５２】
また、ネットワークが正常に動作していれば一般に、同一ファイアウォール装置を2回以上経由するトラヒックフローは存在しない。よって、追加的な一実施形態として、集約トラヒック情報作成部4では、同一の集約トラヒック内に到達装置識別部31が取得したファイアウォール装置が同一のものが存在しないように集約トラヒック情報を作成してもよい。同様の理由でさらに、各ファイアウォール装置においてインタフェース識別部32が取得した物理インタフェースの区別まで含めて同一のものが存在しないように集約トラヒック情報を作成してもよい。
【００５３】
さらにまた、1つのトラヒックフローのデータが順次ファイアウォール装置で中継処理された場合、到達時刻はほぼ同一時刻となる。より正確には、到達時刻は所定範囲内での一連の値として得られる。よって、同一の集約トラヒックに属するための追加の条件として、到達日時取得部33で取得した到達日時同士が所定範囲内に収まることを利用することができる。
【００５４】
例えばAT1では、個別トラヒックT1及びT4の到達日時は、
T1：2010/09/16 20:29:00すなわち(2010年9月16日20時29分0秒)
T4：2010/09/16 20:29:01すなわち(2010年9月16日20時29分1秒)
である。T1とT4との到達日時の差が1秒（当該1秒は例としての値である）であり、T1又はT4とその他の個別トラヒックとの到達日時の差は1分以上ある。このことから、T1及びT4が同一の集約トラヒックAT1に属し、その他のトラヒックは別の集約トラヒックに属するという判断を行うことができる。AT1に対しては、到達日時の情報がstart timeの欄に最先のT1の値で代表して、2010/09/16 20:29:0〜として示されている。同様にして、到達日時の差が1秒である個別トラヒックT2とT5とが集約トラヒックAT2に属するという判断も行うことができる。
【００５５】
当該到達時刻を利用する実施形態も、送信元及び宛先の同一性と同様に、本発明において必須である。特に後述のステップS4で通過経路における順序を求めるために必須である。
【００５６】
なおまた、上記のような到達時刻による集約トラヒックの判断を行う前提として、図4のステップS1では、予め各ファイアウォール装置における計時情報同士の同期を取ってから、トラヒックログ等を取得するものとする。もしくは、各ファイアウォール装置における計時情報同士には誤差が存在することを前提に、ログ取得部2で取得するトラヒックログにおける各ファイアウォール装置のクロックで記載された到達時刻を、トラヒック通過経路解析装置1のクロックに修正するようにしてもよい。
【００５７】
例えば、ファイアウォール装置FW1のクロックを1秒後方に修正することでトラヒック通過経路解析装置1のクロックと一致し、また、ファイアウォール装置FW2のクロックを2秒後方に修正することでトラヒック通過経路解析装置1のクロックと一致する、ということを予め計測しておき、FW1での到達時刻とFW2での到達時刻とを一律にトラヒック通過経路解析装置1におけるクロック情報に修正する。
【００５８】
以上のような各実施形態の組み合わせの他にも、到達装置識別部31乃至付属情報取得部36で取得した各情報の同一性又は類似性を利用して、集約トラヒック情報の作成を行うことができる。例えば図6では、付属情報取得部36で取得した送信バイト数及び受信バイト数もsend/rcvd欄に示されている。このような情報も追加利用してよい。
【００５９】
以上のように、図4のステップS3において集約トラヒック情報作成部4が集約トラヒック情報を作成した後、ステップS4では、通過経路推定部5が集約トラヒック情報を用いて通過経路を推定する。図7は通過経路を推定するフローチャートであり、図4のステップS4内の詳細フローである。
【００６０】
図7の各ステップS41乃至S43は、繰り返し判断のステップS44に示されているように、集約トラヒック情報の各集約トラヒックATi(i=1,2,3,…)につき順次実行され、全ての集約トラヒックについて処理が行われる。開始ステップS40では集約トラヒックの識別カウンタi=1として、1番目の集約トラヒックAT1を処理対象として定め、ステップS41に進む。
【００６１】
ステップS41では、i番目の集約トラヒックATiにつき、通過経路情報を構築する。通過経路情報とは、集約トラヒックを構成する全個別トラヒックに共通の送信元から同じく共通の宛先に至る際の、当該集約トラヒックに対応するトラヒックフローが通過したファイアウォール装置及び物理インタフェースの順序としての通過経路(パス)を特定する情報であり、当該送信元及び宛先と対応付けて構築される。ここで、ファイアウォール装置及び物理インタフェースの通過順序は、集約トラヒック情報(及び個別トラヒック情報)を参照して、当該ファイアウォール装置及び物理インタフェースに対応する個別トラヒックの到達日時(図5のstart time)の順に定められる。
【００６２】
ステップS42では、ATiより構築された通過経路に基づき、それまでに作成されている通過経路情報の全体を更新する。すなわち、当該ATiの通過経路と同じ通過経路が既に作成されている通過経路情報内に存在するならば、新規の通過経路の追加(及びID付与)は行わず、逆に存在しないのならば、新規の通過経路として追加(及びID付与)を行う。
【００６３】
ステップS43では、当該集約トラヒックATiと通過経路情報との対応づけを行う。当該対応づけは、ステップS42と異なり、ATiより構築された通過経路が既に存在するか否かによらずに行う。
【００６４】
ステップS44では前述の通り、全ての集約トラヒックATiにつき処理が行われたか判断し、行われていないのであればカウンタiを1つ増やして次の集約トラヒックAT(i+1)につきステップS41乃至S43の処理を行う。
【００６５】
図8に、以上のようなフローに従って順次作成・更新される通過経路情報の例などを、表形式で示す。図8の(1)がステップS42での通過経路情報の例であり、(2)がステップS43での集約トラヒックと通過経路との対応づけの例である。各表はステップS40において項目部分以外が空欄の状態であり、以降のステップを辿るごとに上段側から順次作成される。図8では、(1)におけるP1及びP2の行と、(2)におけるAT1,AT2及びAT3の行は、図6に示す集約トラヒック情報をAT1から始めて順次処理して得られるものであり、AT1,AT2及びAT3については図6と図8で共通である。
【００６６】
図8の(1)には通過経路情報の例が示されている。PIDは通過経路情報を構成する通過経路に順次付与されるIDである。各通過経路には、送信元(Src IP)と、途中到達するファイアウォール装置及び物理インタフェース(FW/acl名)並びにそれらの到達順列と、宛先(Dst IP)とが対応付けられている。ＩＤがP1の通過経路P1は、最初の処理対象である図6の集約トラヒックAT1より構築されたものであり、以下[1]〜[4]のように順次特定されている。
[1]送信元(10.0.0.1)より送信→[2](FW1 acl1)を通過→[3](FW2 acl2)を通過→[4]宛先(172.19.76.1)に到達
ここで特に[2][3]の順序については、前述の個別トラヒックT1及びT4の到達時刻の順で定められている。そして当該最初に処理された集約トラヒックAT1は、(2)に示すように通過経路P1と対応づけられる。
【００６７】
AT1の次の、2番目に処理される集約トラヒックAT2は、通過経路がAT1で求められたP1と同様となるので、(1)の表に新規ID追加は行われない。そして(2)で示すように、AT2とP1とを対応づける。3番目に処理される集約トラヒックAT3は、図2で説明したようにFW1において疎通拒否され、図6に示すように個別トラヒックT3のみで構成される。従ってAT3の通過経路は、
[1]送信元(10.0.0.1)より送信→[2](FW acl1)に到達して遮断される→[3]宛先(172.19.76.1)には到達せず
となり、P1とは異なるので新規にIDが付与され、(1)に示すように通過経路P2が対応づけられる。さらに(2)に示すようにAT3とP2との対応づけが行われる。なお、(1)には示していないが、通過経路情報の各々は疎通許可／拒否の情報を追加で含んでいてもよい。
【００６８】
さらに、図8では4番目に処理された集約トラヒックAT4についての結果も示されている。当該AT4の通過経路はP1と宛先及びFW2における通過物理インタフェースが異なり、またP2とも異なるので、新たな通過経路としてP3が追加されている。
【００６９】
なお、図7及び図8の説明では、通過経路の特定は通過したファイアウォール装置及び物理インタフェースの順序によって行うとしたが、物理インタフェースの特定を除外して、より簡略に、通過したファイアウォール装置のみの順序によって行ってもよい。
【００７０】
以上、ステップS4で通過経路推定部5が通過経路の推定を行うと、次にステップS5では、推定された通過経路の情報に基づいて確度算出部51が各通過経路についての確度の算出を行う。なお、当該ステップS5はオプションであり、スキップしてもよい。
【００７１】
確度とは、各通過経路の「確からしさ」を数値化したものであり、次のような事情に基づいて数値化されるものである。通常、同一対地(送信元/宛先 IPの対)間のトラヒックフローには、すべて同一の通過経路が紐付く(対応付けられる)はずである。しかし障害、パケット順序逆転、ファイアウォール装置でのログ処理遅滞による記録到達時刻の誤差などのため、トラヒック登場順序の一時的ずれが生じる場合もありうる。この結果、同一対地間のトラヒックフローに複数の異なる通過経路が紐付いて見え、管理者が通過経路判別を誤る可能性がある。また、上記T3(AT3)のように中途でdenyとなるトラヒックフローとなる可能性もある。
【００７２】
そこで、同一対地間の通過経路であるが、途中通過するファイアウォール装置及び物理インタフェースが通過順列全体として異なる通過経路同士について、紐付けられた集約トラヒックの数（登場頻度）をカウントして確度を与えることができる。なお、一般に障害等の発生は正常状態に比べてまれであるという前提のもと、登場頻度を確度として利用することができる。
【００７３】
例えば、図8の(2)のAT1からAT4まで処理された状態での、同一対地(送信元 IPアドレス=10.0.0.1、宛先 IPアドレス=172.19.76.1)間の通過経路であるP1とP2についての確度f(P)は、次のように求めることができる。すなわち、P1にはAT1及びAT2の2個が紐付けられ、P2にはAT3の1個が紐付けられていることから、
f(P1)=2/3, f(P2)=1/3
として求められる。
【００７４】
すなわち上記の例は、確度算出部51が、送信元及び宛先が共通であり通過の順列が異なる通過経路の各々に対して、各通過経路に対応づけられた集約トラヒックの数に基づいた確度を与える例である。
【００７５】
前述のように、通過経路情報の各々に疎通許可／拒否の情報をも追加で含めるならば、当該情報を確度算出に利用することで、上記のような登場頻度のみで算出される確度よりもさらに精度の高い確度を求めるようにすることもできる。あるいは、登場頻度のみで確度を算出して、詳細を確認したい場合には、管理者が適宜トラヒックログの情報に遡って確認するようにしてもよい。
【００７６】
以上、図4の各ステップの処理及び対応する図3のログ取得部2乃至通過経路推定部5の役割を説明した。本発明においては、表示部6によって、適宜各ステップでの途中経過及び最終結果を表示し、管理者などの判断に供することができる。すなわち、管理者からの表示要求に応じて、図5のような個別トラヒック情報、図6のような集約トラヒック情報、図8のような通過経路情報、ステップS5で算出する同一対地間の通過経路同士の確度などを、表示部6を用いて適宜表示することができる。当該管理者からの要求に応じた表示に関しては、GUI(グラフィカルユーザインタフェース)やCLI(コマンドラインインタフェース)など、種々の周知の手法を利用することができる。
【００７７】
なお本発明は、図4の各ステップをコンピュータに実行させることで、当該コンピュータを図3に記載のトラヒック通過経路解析装置として機能させるトラヒック通過経路解析プログラムとして実施することもできる。当該コンピュータは当該プログラムを読み込んで、上記各ステップを実行するトラヒック通過経路解析装置として機能する。
【００７８】
以上、本発明によれば、汎用的なファイアウォール装置において通常取得可能な各種項目からなる個別トラヒック情報に基づいて、トラヒックフローの通過経路を推定することができる。特に、個別トラヒック情報を汎用的なファイアウォール装置におけるトラヒックログを参照して作成することで、過負荷や追加コストなどを避けて通過経路を推定することができる。
【符号の説明】
【００７９】
1…トラヒック通過経路解析装置、2…ログ取得部(トラヒック情報取得部)、3…個別トラヒック情報作成部、4…集約トラヒック情報作成部、5…通過経路推定部、6…表示部
【特許請求の範囲】
【請求項１】
所定の複数のファイアウォール装置より、各ファイアウォール装置における各トラヒックの到達日時と、当該トラヒックが到達したファイアウォール装置と、当該トラヒックの送信元及び宛先と、の情報を対応付けて取得して個別トラヒック情報とする段階と、
前記個別トラヒック情報を構成する各個別トラヒックを、その送信元及び宛先の一致並びに到達日時の所定基準内での近接に基づいてグループ化して集約トラヒック情報とする段階と、
前記集約トラヒック情報を構成する各集約トラヒックに対して、当該集約トラヒックに属する各個別トラヒックの到達日時の順に、各個別トラヒックが到達したファイアウォール装置の順列を求め、該順列を当該集約トラヒックに共通の送信元から宛先へ至るトラヒックフロー全体としての通過経路として推定する段階を備えることを特徴とするトラヒック通過経路解析方法。
【請求項２】
前記個別トラヒック情報とする段階にてさらに、各トラヒックに割り当てられたポート番号を追加で取得して前記対応づけることで前記個別トラヒック情報とし、
前記集約トラヒック情報とする段階にてさらに、ポート番号の一致に基づいて各個別トラヒックをグループ化して前記集約トラヒック情報とする請求項1に記載のトラヒック通過経路解析方法。
【請求項３】
前記個別トラヒック情報とする段階にてさらに、トラヒックが到達したファイアウォール装置において当該トラヒックが到達した物理インタフェースを追加で取得して前記対応づけることで前記個別トラヒック情報とし、
前記通過経路として推定する段階にてさらに、前記到達日時の順に、各個別トラヒックが到達したファイアウォール装置と該ファイアウォール装置にて到達した物理インタフェースとのペアの順列を求め、該順列をトラヒック全体としての通過経路として推定することを特徴とする請求項1または2に記載のトラヒック通過経路解析方法。
【請求項４】
前記集約トラヒック情報とする段階にてさらに、個別トラヒックが到達したファイアウォール装置が同一となる個別トラヒック同士は同一グループとしないようにして前記集約トラヒック情報とすることを特徴とする請求項1ないし3のいずれかに記載のトラヒック通過経路解析方法。
【請求項５】
前記通過経路とする段階にてさらに、前記順列並びに各集約トラヒックで共通の送信元及び宛先、が共通となる集約トラヒックの全体に一つの通過経路を対応づけることを特徴とする請求項1ないし4のいずれかに記載のトラヒック通過経路解析方法。
【請求項６】
前記所定の複数のファイアウォール装置は汎用のファイアウォール装置であり、前記個別トラヒック情報とする段階にて、各ファイアウォール装置の記録したトラヒックログを参照して前記個別トラヒック情報を求める請求項1ないし5のいずれかに記載のトラヒック通過経路解析方法。
【請求項７】
管理者からの表示要求に応じて、前記個別トラヒック情報、前記集約トラヒック情報及び前記通過経路のうち少なくとも1つを表示する段階をさらに備えることを特徴とする請求項1ないし6のいずれかに記載のトラヒック通過経路解析方法。
【請求項８】
請求項1ないし7のいずれかに記載のトラヒック通過経路解析方法をコンピュータに実行させることで、当該コンピュータをトラヒック通過経路解析装置として機能させることを特徴とするトラヒック通過経路解析プログラム。
【請求項９】
所定の複数のファイアウォール装置より、各ファイアウォール装置における各トラヒックの到達日時と、当該トラヒックが到達したファイアウォール装置と、当該トラヒックの送信元及び宛先と、の情報を対応付けて取得して個別トラヒック情報を作成する個別トラヒック情報作成部と、
前記個別トラヒック情報を構成する各個別トラヒックを、その送信元及び宛先の一致並びに到達日時の所定基準内での近接に基づいてグループ化して集約トラヒック情報を作成する集約トラヒック情報作成部と、
前記集約トラヒック情報を構成する各集約トラヒックに対して、当該集約トラヒックに属する各個別トラヒックの到達日時の順に、各個別トラヒックが到達したファイアウォール装置の順列を求め、該順列を当該集約トラヒックに共通の送信元から宛先へ至るトラヒックフロー全体としての通過経路として推定する通過経路推定部を備えることを特徴とするトラヒック通過経路解析装置。
【請求項１】
所定の複数のファイアウォール装置より、各ファイアウォール装置における各トラヒックの到達日時と、当該トラヒックが到達したファイアウォール装置と、当該トラヒックの送信元及び宛先と、の情報を対応付けて取得して個別トラヒック情報とする段階と、
前記個別トラヒック情報を構成する各個別トラヒックを、その送信元及び宛先の一致並びに到達日時の所定基準内での近接に基づいてグループ化して集約トラヒック情報とする段階と、
前記集約トラヒック情報を構成する各集約トラヒックに対して、当該集約トラヒックに属する各個別トラヒックの到達日時の順に、各個別トラヒックが到達したファイアウォール装置の順列を求め、該順列を当該集約トラヒックに共通の送信元から宛先へ至るトラヒックフロー全体としての通過経路として推定する段階を備えることを特徴とするトラヒック通過経路解析方法。
【請求項２】
前記個別トラヒック情報とする段階にてさらに、各トラヒックに割り当てられたポート番号を追加で取得して前記対応づけることで前記個別トラヒック情報とし、
前記集約トラヒック情報とする段階にてさらに、ポート番号の一致に基づいて各個別トラヒックをグループ化して前記集約トラヒック情報とする請求項1に記載のトラヒック通過経路解析方法。
【請求項３】
前記個別トラヒック情報とする段階にてさらに、トラヒックが到達したファイアウォール装置において当該トラヒックが到達した物理インタフェースを追加で取得して前記対応づけることで前記個別トラヒック情報とし、
前記通過経路として推定する段階にてさらに、前記到達日時の順に、各個別トラヒックが到達したファイアウォール装置と該ファイアウォール装置にて到達した物理インタフェースとのペアの順列を求め、該順列をトラヒック全体としての通過経路として推定することを特徴とする請求項1または2に記載のトラヒック通過経路解析方法。
【請求項４】
前記集約トラヒック情報とする段階にてさらに、個別トラヒックが到達したファイアウォール装置が同一となる個別トラヒック同士は同一グループとしないようにして前記集約トラヒック情報とすることを特徴とする請求項1ないし3のいずれかに記載のトラヒック通過経路解析方法。
【請求項５】
前記通過経路とする段階にてさらに、前記順列並びに各集約トラヒックで共通の送信元及び宛先、が共通となる集約トラヒックの全体に一つの通過経路を対応づけることを特徴とする請求項1ないし4のいずれかに記載のトラヒック通過経路解析方法。
【請求項６】
前記所定の複数のファイアウォール装置は汎用のファイアウォール装置であり、前記個別トラヒック情報とする段階にて、各ファイアウォール装置の記録したトラヒックログを参照して前記個別トラヒック情報を求める請求項1ないし5のいずれかに記載のトラヒック通過経路解析方法。
【請求項７】
管理者からの表示要求に応じて、前記個別トラヒック情報、前記集約トラヒック情報及び前記通過経路のうち少なくとも1つを表示する段階をさらに備えることを特徴とする請求項1ないし6のいずれかに記載のトラヒック通過経路解析方法。
【請求項８】
請求項1ないし7のいずれかに記載のトラヒック通過経路解析方法をコンピュータに実行させることで、当該コンピュータをトラヒック通過経路解析装置として機能させることを特徴とするトラヒック通過経路解析プログラム。
【請求項９】
所定の複数のファイアウォール装置より、各ファイアウォール装置における各トラヒックの到達日時と、当該トラヒックが到達したファイアウォール装置と、当該トラヒックの送信元及び宛先と、の情報を対応付けて取得して個別トラヒック情報を作成する個別トラヒック情報作成部と、
前記個別トラヒック情報を構成する各個別トラヒックを、その送信元及び宛先の一致並びに到達日時の所定基準内での近接に基づいてグループ化して集約トラヒック情報を作成する集約トラヒック情報作成部と、
前記集約トラヒック情報を構成する各集約トラヒックに対して、当該集約トラヒックに属する各個別トラヒックの到達日時の順に、各個別トラヒックが到達したファイアウォール装置の順列を求め、該順列を当該集約トラヒックに共通の送信元から宛先へ至るトラヒックフロー全体としての通過経路として推定する通過経路推定部を備えることを特徴とするトラヒック通過経路解析装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１２−２０５２０５（Ｐ２０１２−２０５２０５Ａ）
【公開日】平成２４年１０月２２日（２０１２．１０．２２）
【国際特許分類】
【出願番号】特願２０１１−６９８９９（Ｐ２０１１−６９８９９）
【出願日】平成２３年３月２８日（２０１１．３．２８）
【出願人】（０００２０８８９１）ＫＤＤＩ株式会社 (2,700)
【Ｆターム（参考）】
【公開日】平成２４年１０月２２日（２０１２．１０．２２）
【国際特許分類】
【出願日】平成２３年３月２８日（２０１１．３．２８）
【出願人】（０００２０８８９１）ＫＤＤＩ株式会社 (2,700)
【Ｆターム（参考）】
[ Back to top ]