JP2005223870A

JP2005223870A - 通信パケットのログから不正通信を発見する方法とそのシステム

Info

Publication number: JP2005223870A
Application number: JP2004063132A
Authority: JP
Inventors: Fujio Morita; 富治男森田
Original assignee: Individual
Current assignee: Individual
Priority date: 2004-02-05
Filing date: 2004-02-05
Publication date: 2005-08-18

Abstract

【課題】膨大な量のパケットキャプチャのデータについて、最小の情報検索から異常を見つけ、そこから段階的に元のパケットキャプチャのデータを調査する方法を実現する。
【解決手段】パケットキャプチャからデータを取得して累積ログデータへ貯める通信ログ取得累積機構と累積ログデータから必要とされるデータを取り出し、用途に応じて、データ通信関連のデータと通信確認関連のデータとルーティング関連のデータに分配するログ取り出し・分類機構と、特に、ログ取り出し・分類機構はデータ通信関連のデータを読み、サービス提供タイプのデータとサービス要求タイプのデータに分配する。これらのデータをデータベースへ登録するデータの索引化機構がポート番号アクセス定義とカウント記録領域を使い、通信パケットをカウントし、このデータを並べ替えポート番号カウントファイルへ書き出す。
【選択図】なし

Description

本発明は通信分野における通信記録の分析装置に関する発明である。

従来、通信パケットを分析する装置には、特定のパターンに一致する通信パケットを処理の対象にするＩＤＳ（ＩｎｔｒｕｓｉｏｎＤｅｔｅｃｔｉｏｎＳｙｓｔｅｍ）と通信に使われる通信パケットすべてを記録するパケットキャプチャという２つの種類のソフトウェアがあった。

通信速度の速い回線においてパケットキャプチャを使うと、すべての通信を記録するため膨大なデータ量になる。このデータを直接、検索の対象にすると時間がかかり現実的ではなかった。それゆえ、索引化するなど特殊な仕組みが必要となった。また、ＩＤＳ（ＩｎｔｒｕｓｉｏｎＤｅｔｅｃｔｉｏｎＳｙｓｔｅｍ）は正常な通信であっても、定義したパターンに一致すれば異常だと検知し、異常な通信でも定義したパターンに一致しなければ、正常な通信として処理対象から外されるという弱点があった。この状態では、データから異常な通信を検索することができない。

上記の問題を解決するには、パケットキャプチャのデータの重要な部分を抽出、索引化し、それに付随した処理により異常な通信を効果的に検索する環境を作るしかない。図１と図２は本発明の構成を示すブロック図である。図１はパケットキャプチャ１のデータを索引化する仕組みであり、図２は索引化されたデータから検索表示を行う仕組みである。
図１は、パケットキャプチャ１からデータを取得して累積ログデータ３へ貯める通信ログ取得累積機構２と累積ログデータ３から必要とされるデータを取り出し、用途に応じて、ＴＣＰやＵＤＰなどデータ通信関連のデータ５とＩＣＭＰなどの通信確認関連のデータ８とＡＲＰやＰＰＰＯＥなどルーティング関連のデータ９に分配するログ取り出し・分類機構４と、特に、ログ取り出し・分類機構４はデータ通信関連のデータ５を読み、サービス提供タイプのデータ６とサービス要求タイプのデータ７に分配する。これらのデータをデータベース（通信パケットテーブル）１３へ登録するデータの索引化機構１０により実現される。このとき、データの索引化機構１０はポート番号アクセス定義１１とカウント記録領域１２を使い通信パケットをカウントし、すべての登録が終了した時に、カウント記録領域１２のデータを並べ替えポート番号カウントファイル１４へ記録領域１２の内容を書き出す。
図２は、検索選択メニューのポート番号の表示順を決めるポート番号カウントファイル１４と検索定義１８と異常な通信の検索時、除外条件生成に利用するポート番号アクセス定義１１と指令を入力する入力装置１５とその指令を受け取り、データベース（通信パケットテーブル）１３を検索し時系列表示の指示があれば、検索結果を時間順にまとめて表示装置１６に表示する検索・時系列表示機構１７により構成される。検索・時系列表示機構１７はデータベース（通信パケットテーブル）１３の元になったデータ通信関連のデータ５、通信確認関連のデータ８、ルーティング関連のデータ９、累積ログデータ３を表示する。

本発明を利用することで膨大な量のパケットキャプチャのデータを初めから調べることはなくなり、最少の情報検索から通信の異常を見つけることが可能になる。データベースに登録されるデータは用途により分けられたものが登録されるので、その用途に特有な異常を別々に検索することが可能となり、異常発見の精度が向上する。同じ送信先ポート番号を持つ通信パケットをカウントすることで、自分のセンターに設置してあるサーバの通信において許されていないポート番号のアクセス量がわかり、それがポート番号の選択メニューの順番に反映されるので、アクセス（攻撃）の多いポート番号から調べる。若しくはアクセス（攻撃）の少ないポート番号から調べることが可能になる。また、異常な通信を検索する場合、正常な通信が除外される検索条件が生成されるので、より精度の高い検索を実行することができる。また、発見の難しいポートスキャンの検索条件が生成できるので、データベースの検索により、ピンポイントでポートスキャンの実態を把握できるようになる。

累積ログデータ３をそのままデータベース（通信パケットテーブル）１３へ登録すると、データ量が多いため検索性能が低下する。そこで、ログ取り出し・分類機構４が累積ログデータ３から図１８に示される代表的な部分を抽出すると共に通信の性質上、３つに分類しデータを生成する。１つはＡＲＰ、ＰＰＰｏＥなど接続や通信経路に属する手順の通信で、ルーティング関連のデータ９である。２つ目はＩＣＭＰなど接続の確認を目的とする手順の通信で、通信確認関連のデータ８である。３つ目はＴＣＰやＵＤＰなどデータ通信に重点を置いた手順の通信で、データ通信関連のデータ５である。このように用途に応じてデータを分離することによりデータ通信の異常を発見しやすくなる。通常のデータは異なるプロトコルが混合しているため、通信の前後関係が把握しにくかった。以上の分類は用途により分離しているわけで、プロトコルを固定しているわけではない。新たな手順が発明され利用されても、用途から見て、どれかの分類に入れられ処理する方式である。次に、データ通信関連のデータ５をサービス提供タイプのデータ６とサービス要求タイプのデータ７に分離する。
サービス提供タイプのデータ６とは自分のセンターでサーバを運用しインターネットへサービスを公開している時、これらサーバの通信を取り出したもの。逆に、サービス要求タイプのデータ７とは、自分のセンター内部のクライアントからファイアウォールを抜けてインターネット上のサーバと交信している通信を取り出したものを言う。
このように、データ通信関連のデータ５を２つのタイプに分離することで、異常な通信を検索しやすくなる。本発明は、上記の逆の場合、すなわち、初めにサービス提供タイプのデータ６とサービス要求タイプのデータ７に分離し、それを処理対象にする方式やサービス提供タイプのデータ６とサービス要求タイプのデータ７に分離後、さらに用途別に分離しデータ登録する場合も含むものとする。
サービス提供タイプのデータ６とサービス要求タイプのデータ７をデータベース（通信パケットテーブル）１３へ登録する場合、サービス提供タイプのデータ６の場合は受信データ、サービス要求タイプのデータ７の場合は送信データを対象に登録する。これらのデータはインターネット上の攻撃や情報漏洩で良く利用されるリクエスト（要求）データを含むため、このデータを索引化することは、データベースのデータ量の削減と異常発見の近道となる。
データの索引化機構１０はこれらのデータをデータベース（通信パケットテーブル）１３に登録するが、このとき、登録するデータがサービス提供タイプのデータ６の場合、自分のセンターにあるサーバの通信記録なので、攻撃情報を把握しておく必要がある。
そのため、データの索引化機構１０はポート番号アクセス定義１１を参照し、カウント記録領域１２を利用し、図４に示す手順により通信パケットの数をカウントする。この時、カウント記録領域１２にある「送信先ＩＰアドレスと送信先ポート番号」又は「プロトコル名と送信先ポート番号」と対になったカウンタが利用される。データの登録処理が終了した時、カウント記録領域１２の情報をカウントの多い順又は少ない順に並べ替えポート番号カウントファイル１４へ書き出す。
検索・時系列表示機構１７はデータベース（通信パケットテーブル）１３を検索する機能を持つが、データベースを構成するデータの検索だけでなく、ポート番号カウントファイル１４により、通信を許していない送信先ポート番号を指定する検索選択メニューにおいてアクセスカウントの多い順又は少ない順で送信先ポート番号を表示できる。これにより、自分のセンターに設置してあるサーバの通信を許していないポート番号において、アクセスの多い順又は少ない順に送信先ポート番号をキーにした検索が行えるようになる。
検索定義１８には「ＷＥＢアクセスの検索定義（図１５）」、「ＷＥＢ攻撃の検索定義（図１６）」、「ユーザ専用の検索定義（図１７）」の種類が存在し、検索・時系列表示機構１７はこの定義を読み、選択メニューを表示装置１６に表示する。この選択メニューから選択することで、これらの検索条件をデータベース（通信パケットテーブル）１３を構成するデータの検索条件に追加して利用する。
特に「ＷＥＢ攻撃の検索定義（図１６）」、「ユーザ専用の検索定義（図１７）」は異常な通信の検索に利用する場合が多い。この場合、正常な通信とみなされる通信パケットは検索から除外する必要がある。そこで検索・時系列表示機構１７はポート番号アクセス定義１１の「通常通信の定義（図１０）」と「認可通信の定義（図１１）」をもとに検索から除外する条件を生成し、異常な通信を検索する検索条件に付加する機能を持つ。この機能により高い検索精度が実現される。
検索・時系列表示機構１７は他に、発見の難しいポートスキャンの検索条件の生成も行う。ポートスキャンとは、悪意を持つ者が目標のサーバへ侵入する場合、最初に行うもので、目標のサーバのポート番号が使用可能か判定する行為である。これは目標のサーバのポート番号へアクセスする形で行われる。短時間に目標のサーバのポート番号を変えてアクセスする行為もあれば、時間をおいて目標のサーバのポート番号を少しずつ変えアクセスする行為もある。一般に後者の発見が難しいとされている。このポートスキャンの特徴を参考にし「送信元ＩＰアドレスが同じであり、送信先ポート番号が同じである通信パケットの数が一定数以下、且つ異なる送信先ポート番号の数が一定数以上」の検索条件を生成するか、データベース（通信パケットテーブル）１３の通信パケットデータの送信元ＩＰアドレスに範囲を持たせていた場合、「送信元ＩＰアドレスが同じＩＰアドレス範囲にあり、送信先ポート番号が同じである通信パケットの数が一定数以下且つ異なる送信先ポート番号の数が一定数以上」の検索条件を生成し検索を行うことでポートスキャンを発見することができる。
検索・時系列表示機構１７は図５の流れ図に示されるようにデータベース（通信パケットテーブル）１３の元になったデータ通信関連のデータ５、通信確認関連のデータ８、ルーティング関連のデータ９、それらデータの元である累積ログデータ３へさかのぼりデータ表示ができる。
また、検索時に累積ログデータ３やデータ通信関連のデータ５、通信確認関連のデータ８、ルーティング関連のデータ９は必ずしも必要ではなく、参照の必要がない場合、別媒体に退避しておく。つまり、異常な通信の検索はデータベース（通信パケットテーブル）１３のみあれば実行できる。そこから詳細な情報であるデータ通信関連のデータ５、通信確認関連のデータ８、ルーティング関連のデータ９、累積ログデータ３を参照したい場合、別媒体に退避したデータを復元して参照すればよい。別々のデータに分離する目的は、それぞれが退避可能であることも意味している。
以上の仕組みにより、膨大な量のパケットキャプチャのデータを初めから調べることをせず、最少の情報検索から異常を見つけ、そこから段階的に元のパケットキャプチャのデータを調査する方法を実現したのが本発明の主な特徴である。

図１と図２は本発明の構成を示すブロック図である。図１はパケットキャプチャ１のデータを索引化する仕組みであり、図２は索引化されたデータから検索表示を行う仕組みである。まず、図１のデータを索引化する仕組みを説明する。図１のブロック図を構成する機構は図３と図４に示す流れ図に従って動作する。

処理ステップ１で、通信ログ取得累積機構２がパケットキャプチャ１からデータを取得し累積ログデータ３へ累積する。

処理ステップ２で、ログ取り出し・分類機構４が累積ログデータ３を読み、代表的なデータを取り出し、ルーティング関連のデータ９と通信確認関連のデータ８とデータ通信関連のデータ５に分ける。取り出されたデータの構成を図１８に示す。

処理ステップ３で、ログ取り出し・分類機構４がデータ通信関連のデータ５を読み、サービス提供タイプのデータ６とサービス要求タイプのデータ７に分ける。具体的に言うとサービス提供タイプのデータ６とは自分のセンターに設置してあるサーバの通信データであり、サービス要求タイプのデータ７とは自分のセンター内部のクライアントからファイアウォールを抜けてインターネット上のサーバと通信するデータを言う。

処理ステップ４で、データの索引化機構１０がポート番号アクセス定義１１を読む。ポート番号アクセス定義１１には「通常通信の定義（図１０）」、「認可通信の定義（図１１）」、「各ポート番号に対する通信の定義（図１２）」がある。

処理ステップ５で、データの索引化機構１０が「通常通信の定義（図１０）」からカウント記録領域１２上に図１３の構成をもつカウンタを、「各ポート番号に対する通信の定義（図１２）」から図１４の構成をもつカウンタを作成し、カウント記録領域１２に「認可通信の定義（図１１）」を複製する。
以降、データの索引化機構１０のカウント処理はカウント記録領域１２を使って行われる。

処理ステップ６で、データの索引化機構１０がサービス提供タイプのデータ６、サービス要求タイプのデータ７、通信確認関連のデータ８、ルーティング関連のデータ９を読み込み、データベース（通信パケットテーブル）１３へ登録する。このとき、サービス提供タイプのデータ６の場合、図４の流れ図に従い、送信先ポート番号に着目し、該当する通信パケットの数を数え、カウント記録領域１２上に記録する。
サービス提供タイプのデータ６の登録では受信データが登録され、サービス要求タイプのデータ７の登録では送信データが登録される。データベース（通信パケットテーブル）１３は図１９に示す構成になっている。

サービス提供タイプのデータ６をデータベース（通信パケットテーブル）１３へ登録する場合、図４の流れ図に従い、登録する通信パケットを数える。

以降、図４の流れ図を説明する。処理ステップ８で、通信パケットがカウント記録領域１２上の図１３の項２（送信先ＩＰアドレス）と項３（送信先ポート番号）に一致するか判定する。
一致（ＹＥＳ）の場合、処理ステップ９へ進む。
ＮＯの場合、処理ステップ１０へ進む。

処理ステップ９で、カウント記録領域１２の図１３の項２（送信先ＩＰアドレス）と項３（送信先ポート番号）に対応するデータの項４（カウント数）をカウンアップする。

処理ステップ１０で、通信パケットがカウント記録領域１２上の「認可通信の定義（図１１）」の項２（送信元ポート番号）と項３（送信先ＩＰアドレス）に一致するか判定する。
一致（ＹＥＳ）の場合、通信パケットは異常とみなされないので図４の終了へ進む。ＮＯの場合、処理ステップ１１へ進む。

処理ステップ１１で、通信パケットがカウント記録領域１２上の図１４の項３（プロトコル名）と項４（送信先ポート番号）に一致するか判定する。
一致（ＹＥＳ）の場合、処理ステップ１２へ進む。
ＮＯの場合、処理ステップ１３へ進む。

処理ステップ１２で、カウント記録領域１２の図１４の項３（プロトコル名）と項２（送信先ポート番号）に対応するデータの項５（カウント数）をカウントアップする。

処理ステップ１３で、通信パケットのプロトコル名、送信先ポート番号を図１４の項３、項４に設定、項１に識別コード、項５に１、項２に「定義なし」を設定し、カウント記録領域１２に新規カウンタを作成する。

以上、データの索引化機構１０がサービス提供タイプのデータ６をデータベース（通信パケットテーブル）１３へ登録する場合、図４の流れ図に従って、通信パケットをカウントしていく。すべてのデータの登録が終了すると、図３の処理ステップ７へ進む。

処理ステップ７で、データの索引化機構１０がカウント記録領域１２のデータをカウントの多い順又は少ない順に並べ替え、ポート番号カウントファイル１４へ書き出す。以上が、図１のブロック図を構成する機構の処理の流れである。

次に、図２の索引化されたデータから検索表示を行う仕組みを説明する。図２のブロック図を構成する機構は図５に示す流れ図に従って動作する。図５はまた、図５の検索指令に対する前処理の流れ図図６と、図５の検索指令に対する本処理の流れ図図７と、図５のポートスキャンの検索指令に対する処理の流れ図図８と、図５のログ取り出し・分類機構が出力したデータの表示処理の流れ図図９を呼び出す。

処理ステップ１４で、検索・時系列表示機構１７がポート番号カウントファイル１４を読み、ポート番号の検索選択メニューを表示装置１６に表示する。
この時、データベース（通信パケットテーブル）１３を構成するデータの検索選択メニューも同時に表示される。

処理ステップ１５で、検索・時系列表示機構１７が検索定義１８を読み、検索選択メニューを表示装置１６に表示する。

処理ステップ１６で、利用者が入力装置１５から指示を入力する。

処理ステップ１７で、処理ステップ１６で入力された指令が終了か判定する。
終了（ＹＥＳ）の場合、検索・時系列表示機構１７は終了する。
ＮＯの場合、処理ステップ１８へ進む。

処理ステップ１８で、処理ステップ１６で入力された指令が検索指令か判定する。
検索指令（ＹＥＳ）の場合、図６の処理ステップ２３へ進む。
ＮＯの場合、処理ステップ１９へ進む。

図６の処理ステップ２３で、指令が「検索定義」の指定か判定する。ここから図６の流れを説明する。
「検索定義」の指定（ＹＥＳ）の場合、処理ステップ２４へ進む。
ＮＯの場合、処理ステップ２５へ進む。

処理ステップ２４で、検索・時系列表示機構１７が検索定義１８の該当する定義から検索条件を生成し、もとの検索条件に追加する。検索定義１８とは「ＷＥＢアクセスの検索定義（図１５）」、「ＷＥＢ攻撃の検索定義（図１６）」「ユーザ専用の検索定義（図１７）」である。指令には処理の対象にする検索定義が指定してあり、指定された検索定義から検索条件が作成され、データベース（通信パケットテーブル）１３を構成するデータの検索条件に追加される。

処理ステップ２５で、指令が異常な通信の検索か判定する。
異常な通信の検索の指定がある（ＹＥＳ）の場合、処理ステップ２６へ進む。
ＮＯの場合、図７の処理ステップ２７へ進む。
異常な通信の検索の指定は検索定義１１の「ＷＥＢ攻撃の検索定義（図１６）」と「ユーザ専用の検索定義（図１７）」により指令が付加される場合、表示装置１６に表示された選択から指定する場合と、図８の処理ステップ３１に示すように処理の延長上で設定される場合がある。

処理ステップ２６で、検索・時系列表示機構１７が「通常通信の定義（図１０）」と「認可通信の定義（図１１）」を読み、「通常通信の定義（図１０）」から「送信先ＩＰアドレスと送信先ポート番号に一致しない」という検索条件と「認可通信の定義（図１１）」から「送信先ＩＰアドレスと送信元ポート番号に一致しない」という検索条件を生成し、現在までに構築された条件条件に追加する。
処理の流れは図７へ進む。

図７の処理ステップ２７で、指令が時系列表示付きか判定する。
以降、図７で処理の流れを説明する。
指令が時系列表示付き（ＹＥＳ）の場合、処理ステップ２８へ進む。
ＮＯの場合、処理ステップ２９へ進む。
時系列表示付きの検索指令は表示装置１６に表示された選択から指定される。

処理ステップ２８で、上記処理により作成された条件を使い、検索・時系列表示機構１７がデータベース（通信パケットテーブル）１３を検索し、検索条件に該当するデータを時刻系列にまとめ、表示装置１６に表示する。表示後は図５の処理ステップ１６へ戻る。

図７の処理ステップ２９で、上記処理により作成された条件を使い、検索・時系列表示機構１７がデータベース（通信パケットテーブル）１３を検索し、検索条件に該当するデータを表示装置１６に表示する。表示後は図５の処理ステップ１６へ戻る。

図５の処理ステップ１９で、図５の処理ステップ１６で入力された指令がポートスキャンの検索指令か判定する。
ポートスキャンの検索指令（ＹＥＳ）の場合、図８の処理ステップ３０へ進む。ＮＯの場合、図５の処理ステップ２０へ進む。

図８の処理ステップ３０で、検索・時系列表示機構１７が、「送信元ＩＰアドレスが同じか又は送信元ＩＰアドレスが同じＩＰアドレス範囲にあり、送信先ポート番号が同じである通信パケットの数が一定数以下、且つ異なる送信先ポート番号の数が一定数以上」という検索条件を生成し図８の処理ステップ３１へ進む。

図８の処理ステップ３１で、検索・時系列表示機構１７が異常な通信の検索のフラグをオンにし、処理を図６の処理ステップ２３へ進める。これにより、前述の流れに従い検索・時系列表示機構１７が検索条件に該当するデータを検索し、表示装置１６に表示する。

図５の処理ステップ２０で、図５の処理ステップ１６で入力された指令が、ログ取り出し・分類機構４が出力したデータの表示指令か判定する。
ログ取り出し・分類機構４が出力したデータの表示指令（ＹＥＳ）の場合、図９の処理ステップ３２へ進む。ＮＯの場合、図５の処理ステップ２１へ進む。

図９の処理ステップ３２で、検索・時系列表示機構１７がデータベース（通信パケットテーブル）１３の元となるデータ通信関連のデータ５又は通信確認関連のデータ８又はルーティング関連のデータ９を読み、表示指令にある通信パケットの記録時刻をキーにして該当データを探し、そこから一定数の通信パケットを表示装置１６に表示する。
検索・時系列表示機構１７はデータベース（通信パケットテーブル）１３へ格納する形態によりデータベース内のデータ（通信パケット）がデータ通信関連のデータ５に所属するのか、通信確認関連のデータ８に所属するのか、ルーティング関連のデータ９に所属するのか把握している。表示後は図５の処理ステップ１６へ戻る。

図５の処理ステップ２１で、図５の処理ステップ１６で入力された指令が、累積ログデータ３の表示指令か判定する。
累積ログデータ３の表示指令（ＹＥＳ）の場合、図５の処理ステップ２２へ進む。ＮＯの場合、図５の処理ステップ１６へ戻る。

図５の処理ステップ２２で、検索・時系列表示機構１７が累積ログデータ３を読み、表示指令にある通信パケットの記録時刻とプロトコル名、それに付随する情報をキーに該当データを探し、通信パケットの内容を表示装置１６に表示する。表示後は図５の処理ステップ１６へ戻る。

は本発明の構成を示すブロック図（データを索引化する仕組み）は本発明の構成を示すブロック図（データを検索表示する仕組み）は本発明の処理の流れ図（データを索引化する手順）は本発明の処理の流れ図（通信パケットをカウントする手順）は本発明の処理の流れ図（データを検索表示する手順）は図５の検索指令に対する前処理の流れ図は図５の検索指令に対する本処理の流れ図は図５のポートスキャンの検索指令に対する処理の流れ図は図５のログ取り出し・分類機構が出力したデータの表示処理の流れ図は通常通信の定義の構成要素図は認可通信の定義の構成要素図は各ポートに対する通信の定義の構成要素図はポート番号カウントファイル（その１）の構成要素図はポート番号カウントファイル（その２）の構成要素図はＷＥＢアクセスの検索定義の構成要素図はＷＥＢ攻撃の検索定義の構成要素図はユーザ専用の検索定義の構成要素図はログ取り出し・分類機構４が出力したデータの構成要素図はデータベース（通信パケットテーブル）の構成要素図

Claims

ネットワークに設置された通信パケット記録装置の通信パケットの記録から代表的な部分を取り出すと共に、用途別にルーティング関連のデータと通信確認関連のデータとデータ通信関連のデータに分け、さらにデータ通信関連のデータをサービス提供タイプのデータとサービス要求タイプのデータに分け、サービス提供タイプのデータでは受信データを、サービス要求タイプのデータでは送信データをデータベースへ登録する点を特徴としたデータ登録方法を有し、データベースの元データであるルーティング関連のデータ、通信確認関連のデータ、データ通信関連のデータの表示と通信パケットの記録の表示が可能なシステム。
データ通信関連のデータである通信パケットをデータベースへ登録するとき、ＩＰアドレスとポート番号を識別する定義である「通常通信の定義」、「認可通信の定義」、「各ポート番号に対する通信の定義」をそれぞれ用意し、通信パケットのＩＰアドレスとポート番号とこの定義の示すＩＰアドレスとポート番号を照合させる。「通常通信の定義」は通信を許しているＩＰアドレスとポート番号の定義であり、「各ポート番号に対する通信の定義」は通信を許していないポート番号の定義である。通信パケットの送信先ＩＰアドレスと送信先ポート番号が「通常通信の定義」の送信先ＩＰアドレスと送信先ポート番号と一致した場合、正常なアクセスとして「通常通信の定義」に対応するカウンタをカウントアップし、それ以外の通信パケットは「認可通信の定義」の送信先ＩＰアドレスと送信元ポート番号と一致するか調べ、一致しない通信パケットは「各ポート番号に対する通信の定義」の送信先ポート番号と照合し、一致した場合、この定義に対応するカウンタをカウントアップする。一致しない場合、未定義の（未知の）攻撃として、新規にカウンタを生成し、以降、該当する通信パケットをカウントする。
この結果、通信を許している送信先ＩＰアドレスと送信先ポート番号ごとのアクセス数と通信を許していない送信先ポート番号ごとのアクセス数が判明するので、これらデータをカウント数の多い順又は少ない順で並べ替え、ファイルへ書き出すことで、後に、通信を許している送信先ＩＰアドレスと送信先ポート番号の検索選択メニュー及び通信を許していない送信先ポート番号を指定する検索選択メニューにおいてカウントの多い順又は少ない順に送信先ポート番号を表示させることを目的とするデータのカウント方法とその結果の利用方法。
データベースに格納されたデータを検索する場合、データベースに属する検索条件又はこの条件に利用者が独自に定義できる「検索定義」を追加する時、この検索条件が異常な通信の検索を行うものであったなら正常とみなす通信は検索から除外する必要がある。この時、請求項２で使用した「通常通信の定義」と「認可通信の定義」から検索の除外条件、すなわち、「通常通信の定義」からは「送信先ＩＰアドレスと送信先ポート番号に一致しない」という検索条件と「認可通信の定義」からは「送信先ＩＰアドレスと送信元ポート番号に一致しない」という検索条件を生成し、この検索条件を元の検索条件に付加して検索実行する方法とその方法をもつシステム。
通信パケットが格納されたデータベースを検索する場合、「ポートスキャン」という異常な通信を検索する目的で「送信元ＩＰアドレスが同じか又は送信元ＩＰアドレスが同じＩＰアドレス範囲にあり、送信先ポート番号が同じである通信パケットの数が一定数以下且つ異なる送信先ポート番号の数が一定数以上」の検索条件を生成し、請求項３で示す検索除外条件を加え、データベースを検索する方法とその方法をもつシステム。