JP6375047B1 - ファイアウォール装置 - Google Patents

Abstract

【課題】個々のＷＥＢサーバにとって必要なルールを自動的に選別することによって、ルールサイズの肥大化を招くことなく、新たな種類の攻撃に対していち早く対応できるファイアウォール装置を提供する。
【解決手段】本発明によるファイアウォール装置は、複数のＷＥＢサーバのそれぞれについて、リクエストのブロックに関する１以上のルールを記憶するルールデータベース２０と、複数のＷＥＢサーバのそれぞれにおける指標ごとの検知数に基づき、複数のＷＥＢサーバそれぞれの特徴量を算出する特徴量算出部３０と、特徴量算出部３０によって算出された特徴量に基づき、複数のＷＥＢサーバそれぞれについてルールデータベース２０に記憶されているルールを更新するルール更新部３１と、を備える。
【選択図】図２

Description

本発明はファイアウォール装置に関し、特に、アプリケーションレベルで送受信を管理することによって外部ネットワークからの不正アクセスを防御するファイアウォール装置に関する。

Ｗｅｂアプリケーションファイヤーウォール（以下、「ＷＡＦ」という）は、アプリケーションレベルで送受信を管理することによって外部ネットワークからの不正アクセスを防御するファイアウォールシステムである。ＷＡＦの代表的なサービスとして、非特許文献１に記載の「ＡＷＳ ＷＡＦ」が知られている。この技術では、ＷＥＢサーバとインターネットの間にフロントエンドサーバが設けられ、さらに、このフロントエンドサーバと通信可能に構成されたＷＡＦサーバが設けられる。フロントエンドサーバは、ＷＥＢサーバへのリクエストを受け取ると、そのリクエストを一旦ＷＡＦサーバに転送する。ＷＡＦサーバは、ブロックすべきリクエストと許可すべきリクエストとを識別するためのルール（具体的には、ブロックの対象となるリクエストが列挙されたシグネチャ）を有しており、転送されたリクエストにこのルールを適用することによって、リクエストのブロック又は許可を決定する。ブロックと決定された場合、フロントエンドサーバは、そのリクエストをＷＥＢサーバに転送することなく、破棄する。一方、許可と決定された場合、フロントエンドサーバは、そのリクエストをＷＥＢサーバに転送する。

特許文献１には、ＷＡＦを利用するコンピュータシステムが開示されている。同文献に記載の技術は、不正アクセスが検知された場合にのみＷＡＦを含むファイアウォールをネットワークに組み込むことにより、ファイアウォールのコストを削減しようとするものである。ただし、同技術においては、不正アクセスを検知するための不正アクセス検知装置がファイアウォールとは別に必要になる。不正アクセス検知装置は、ＷＡＦと同様に、あらかじめ登録されたシグネチャとのマッチングを行うことにより不正アクセスを検知するよう構成される。

特開２０１５−５０７１７号公報

「ＡＷＳ ＷＡＦ」、[online]、アマゾン・ドット・コム・インコーポレイテッド、[平成２９年１０月２３日検索]、インターネット＜ＵＲＬ：https://aws.amazon.com/jp/waf/＞

ところで、上記ＷＡＦサーバにはＷＥＢサーバごとの記憶領域が用意され、その中にルールが保持されている。したがって、ルールはＷＥＢサーバごとに保持されることになる。このようにしているのは、ブロック又は許可すべきリクエストの内容がＷＥＢサーバによって異なり得るためである。

各ＷＥＢサーバに対応するルールは、各ＷＥＢサーバの管理者が自身でＷＡＦサーバに設定する必要がある。しかしながら、この方法には、新たな種類の攻撃に対していち早く対応することが困難であるという問題があった。これに対し、コンピュータセキュリティの専門会社によって新たなルールが公開される都度、無条件で自サーバのルールに自動追加するという方法も考えられるが、そうするとルールのサイズが膨大になり、ＷＡＦサーバ内の記憶領域を圧迫してしまうという別の問題が発生する。

特許文献１によっても、不正アクセス検知装置に予め登録しておくシグネチャについて、同様の問題が生ずる。

したがって、本発明の目的の一つは、個々のＷＥＢサーバにとって必要なルールを自動的に選別することによって、ルールサイズの肥大化を招くことなく、新たな種類の攻撃に対していち早く対応できるファイアウォール装置を提供することにある。

本発明によるファイアウォール装置は、複数のＷＥＢサーバのそれぞれについて、リクエストのブロックに関する１以上のルールを記憶する記憶部と、前記複数のＷＥＢサーバのそれぞれにおける指標ごとの検知数に基づき、前記複数のＷＥＢサーバそれぞれの特徴量を算出する特徴量算出部と、前記特徴量算出部によって算出された前記特徴量に基づき、前記複数のＷＥＢサーバそれぞれについて前記記憶部に記憶されているルールを更新するルール更新部と、を備えるファイアウォール装置である。

本発明によれば、複数のＷＥＢサーバのそれぞれにおける指標ごとの検知数に基づき、個々のＷＥＢサーバにとって必要なルールを自動的に選別することができる。したがって、ルールサイズの肥大化を招くことなく、新たな種類の攻撃に対していち早く対応することが可能になる。

（ａ）は、本発明の実施の形態によるファイアウォールシステム１のシステム構成を示す図であり、（ｂ）は、本発明の実施の形態によるファイアウォールシステム１のシステム構成の他の例を示す図である。 （ａ）は、図１に示したＷＡＦサーバ２のハードウェア構成を示す図であり、（ｂ）は、図１に示したＷＡＦサーバ２の機能ブロックを示す略ブロック図である。 図２（ｂ）に示した特徴量算出部３０によって実行される特徴量算出処理の処理フロー図である。 図２（ｂ）に示したユーザ類似度算出部４０によって実行されるユーザ類似度算出処理の処理フロー図である。 図２（ｂ）に示したレコメンドスコア算出部４１によって実行されるレコメンドスコア算出処理の処理フロー図である。 図２（ｂ）に示したグループ化処理部４２によって実行されるグループ化処理の処理フロー図である。 指標がルールである場合に取得される検知数の例を示す図である。 （ａ）（ｂ）は、指標がルールである場合における特徴量の算出例を示す図である。 指標としてルールを用いて作成される特徴量マトリクスの例を示す図である。 （ａ）は、それぞれＷＥＢサーバＩＤがｈｏｓｔ００００３９，ｈｏｓｔ００００４２である２つのＷＥＢサーバ３間で共起しているルールを示す図であり、（ｂ）は、（ａ）に示した例において算出される各ルールのユークリッド距離を示す図であり、（ｃ）は、（ａ）に示した例において算出されるユークリッド距離の合計値及びユーザ類似度を示す図である。 （ａ）は、ＷＥＢサーバＩＤがｈｏｓｔ００００３９であるＷＥＢサーバ３についての未登録ルールであって、他のＷＥＢサーバ３について登録されている１以上のルールを示す図であり、（ｂ）は、（ａ）に示した各ＷＥＢサーバ３の特徴量を示す図であり、（ｃ）は、（ｂ）に示した各ルールＩＤについて算出される加重平均を示す図である。 （ａ）（ｂ）は、指標がリクエスト種別である場合に取得される検知数の例を示す図であり、（ｃ）は、指標がリクエスト種別である場合における特徴量の算出例を示す図である。 指標としてリクエスト種別を用いて作成される特徴量マトリクスの例を示す図である。 クラスタリングによる複数のＷＥＢサーバのグループ化例を示す図である。 ＤＢＳＣＡＮの出力結果を示す図である。

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

図１（ａ）は、本発明の実施の形態によるファイアウォールシステム１のシステム構成を示す図である。同図に示すように、ファイアウォールシステム１は、１つのＷＡＦサーバ２と、複数のＷＥＢサーバ３とを備えて構成される。

ＷＥＢサーバ３は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）に従うクライアント（図示せず）からのリクエストを例えばインターネット経由で受信し、リクエストの内容に応じたサービスをクライアントに対して提供するコンピュータである。例えば、リクエストが特定の情報の転送（ＧＥＴ）である場合、ＷＥＢサーバ３は、要求された情報がファイル（画像ファイル、ＨＴＭＬファイル、テキストファイルなど）であればそのファイルの内容をクライアントに対して転送し、要求された情報がＰＨＰ（登録商標）やＪａｖａＳｃｒｉｐｔ（登録商標）などのプログラムの実行結果である場合には、そのプログラムを実行し、その結果として得られた情報をクライアントに対して転送する。また、リクエストがデータの処理（ＰＯＳＴ）である場合、ＷＥＢサーバ３は、クライアントから転送されてきたデータに応じた処理（データベースへの登録など）を行い、その結果として得られた情報をクライアントに対して転送する。さらに、リクエストには、ＷｏｒｄＰｒｅｓｓ（登録商標）などの特定のソフトウェアやその中に含まれるファイルの指定（ｗｏｒｄｐｒｅｓｓ、ｗｐ−ｃｒｏｎ、ｗｐ−ｃｏｎｔｅｎｔなど）が含まれ得る。この種のリクエストを受け取ったＷＥＢサーバ３は、対応するソフトウェア又はファイルを実行し、その結果として得られた情報をクライアントに対して転送する。

ＷＡＦサーバ２は、アプリケーションレベルで送受信を管理することによって、ＷＥＢサーバ３に対する外部ネットワークからの不正アクセスを防御するファイアウォール装置である。通常、ＷＡＦサーバ２はＷＥＢサーバ３とは物理的に異なるコンピュータ内に設けられるが、ＷＥＢサーバ３と同じコンピュータ内に設けることも可能である。

各ＷＥＢサーバ３は、クライアントからリクエストを受信した場合、そのリクエストを一旦ＷＡＦサーバ２に転送する。ＷＡＦサーバ２は、ブロックすべきリクエストと許可すべきリクエストとを識別するためのルール（具体的には、ブロックの対象となるリクエストが列挙されたシグネチャ）をＷＥＢサーバ３ごとに記憶しており、転送されたリクエストをこのルールに照合することによってリクエストのブロック又は許可を決定し、その結果をＷＥＢサーバ３に返送する。ＷＥＢサーバ３は、ブロックと決定された場合には、そのリクエストを破棄する。一方、許可と決定された場合には、そのリクエストに応じたサービスをクライアントに対して提供する。

ＷＡＦサーバ２はまた、後述する図２（ｂ）に示す各機能部を定期的に動作させることにより、各ＷＥＢサーバ３について記憶しているルールの内容を定期的に更新するように構成される。この処理の具体的な内容については後述するが、この処理を実行することにより、個々のＷＥＢサーバ３にとって必要なルールを自動的に選別することが実現される。

図１（ｂ）は、本発明の実施の形態によるファイアウォールシステム１のシステム構成の他の例を示す図である。同図に示す構成と図１（ａ）に示した構成の違いは、フロントエンドサーバ４が設けられている点にある。フロントエンドサーバ４は、ＷＥＢサーバ３に代わってクライアントからのリクエストを受信し、そのリクエストを一旦ＷＡＦサーバ２に転送する。そして、ＷＡＦサーバ２がブロックと決定した場合には、そのリクエストをＷＥＢサーバ３に転送することなく破棄し、許可と決定した場合には、そのリクエストをＷＥＢサーバ３に転送する。本発明は、図１（ａ）の構成によるＷＡＦサーバ２だけでなく、図１（ｂ）の構成によるＷＡＦサーバ２にも同様に適用できる。

図２（ａ）はＷＡＦサーバ２のハードウェア構成を示す図であり、図２（ｂ）はＷＡＦサーバ２の機能ブロックを示す略ブロック図である。

図２（ａ）に示すように、ＷＡＦサーバ２は、プロセッサ１０と、入出力インターフェイス１１と、記憶部１２とがバス１３を介して相互に接続された構成を有して構成される。プロセッサ１０は、内蔵しているメインメモリ（図示せず）に記憶されるプログラムに従う処理を行う処理装置であり、後述するＷＡＦサーバ２の各機能はプロセッサ１０が実行する処理により実現される。入出力インターフェイス１１は、ユーザの入力を受け付けるマウスやキーボードなどの入力手段と、ユーザに対して出力を行うディスプレイやスピーカーなどの出力手段と、各ＷＥＢサーバ３を含む他のコンピュータと通信を行う通信手段とを含んで構成される。記憶部１２は、ハードディスクなどの補助記憶装置である。後述するルールデータベース２０及び履歴データベース２１は、この記憶部１２内に構築される。

機能的には、ＷＡＦサーバ２は、図２（ｂ）に示すように、ルールデータベース２０、履歴データベース２１、特徴量算出部３０、及びルール更新部３１を有して構成される。ルール更新部３１はさらに、内部にユーザ類似度算出部４０、レコメンドスコア算出部４１、及びグループ化処理部４２を有して構成される。

ルールデータベース２０は、複数のＷＥＢサーバ３のそれぞれについて、リクエストのブロックに関する１以上のルールを記憶するデータベースである。各ＷＥＢサーバ３についてのルールは、互いに独立してルールデータベース２０内に格納される。ルールデータベース２０内に格納されるルールは、いわゆるブラックリストを構成する。したがって、ＷＡＦサーバ２は、ＷＥＢサーバ３又はフロントエンドサーバ４から転送されてきたリクエストがルールデータベース２０内に記憶されている場合に、そのリクエストのブロックを決定し、記憶されていない場合に、そのリクエストの許可を決定する。

履歴データベース２１は、複数のＷＥＢサーバ３のそれぞれについて、リクエストのログ（アクセスログ）を記憶するデータベースである。アクセスログには、リクエスト送信元のＩＰアドレス、リクエストが受信された時刻、ＨＴＴＰメソッドの種類（ＧＥＴ、ＰＯＳＴなど）、アクセスされたファイルのＵＲＩ（ファイル名及び拡張子を含む）、リクエストを送信したデバイスの情報（ＯＳ又はブラウザの種類など）、及びリクエストの処理方法（ブロック又は許可）を示す情報が含まれる。処理方法を示す情報には、ブロック又は許可の根拠となったルールを示す情報が含まれる。

特徴量算出部３０は、複数のＷＥＢサーバ３のそれぞれにおける指標ごとの検知数に基づき、複数のＷＥＢサーバ３それぞれの特徴量を算出する機能部である。指標は、例えばルールデータベース２０に記憶されるルール、又は、履歴データベース２１に記憶されるリクエストの種別である。リクエスト種別には、ＨＴＴＰメソッド（ＧＥＴ、ＰＯＳＴなど）、アクセスされたファイルのＵＲＩから判定されるアクセス先プロセス（ｌｏｇｉｃ、ｗｏｒｄｐｒｅｓｓ、ｗｐ−ｃｒｏｎ、ｗｐ−ｃｏｎｔｅｎｔなど）、アクセスされたファイルのＵＲＩに含まれる拡張子（ｐｈｐ、ｃｓｓ、ｊｓ、ｇｉｆ、ｊｐｇ、ｐｎｇ、ｔｘｔ、ｈｔｍｌなど）などが含まれる。なお、リクエスト種別は、これらのうちの一部をグループ化することによって構成してもよく、以下では、アクセス先プロセス「ｗｏｒｄｐｒｅｓｓ」、「ｗｐ−ｃｒｏｎ」、「ｗｐ−ｃｏｎｔｅｎｔ」を「ｗｏｒｄｐｒｅｓｓ」という１つのリクエスト種別として用い、拡張子「ｇｉｆ」、「ｊｐｇ」、「ｐｎｇ」を「ｉｍａｇｅ」という１つのリクエスト種別として用いることとする。

図３は、特徴量算出部３０によって実行される特徴量算出処理の処理フロー図である。同図に示すように、特徴量算出部３０は、まず初めに複数のＷＥＢサーバ３のそれぞれについて、指標ごとの検知数を取得する（ステップＳ１）。次いで特徴量算出部３０は、複数のＷＥＢサーバ３のそれぞれにおける指標ごとの検知数に基づき、これら複数のＷＥＢサーバ３それぞれの特徴量を算出する（ステップＳ２）。以下、指標がルールである場合と、指標がリクエスト種別である場合とのそれぞれについて、具体的に説明する。

まず指標がルールである場合に関して、図７は、指標がルールである場合に取得される検知数の例を示す図である。なお、同図に示したＷＥＢサーバＩＤは個々のＷＥＢサーバ３を識別するための情報であり、ルールＩＤは個々のルールを識別するための情報である。以下の説明では、ＷＥＢサーバＩＤ及びルールＩＤのみの記述により、それぞれＷＥＢサーバ３及びルールを特定する場合がある。特徴量算出部３０は、各ＷＥＢサーバ３についてのアクセスログを履歴データベース２１から読み出し、その中に含まれるブロックされたリクエストの数を対応するルールごとに積算することによって、図７に示すように各ＷＥＢサーバ３におけるルールごとの検知数を取得する。

図８（ａ）（ｂ）は、指標がルールである場合における特徴量の算出例を示す図である。図８（ａ）は、ｈｏｓｔ００００３９についての特徴量の算出を示し、図８（ｂ）は、ｈｏｓｔ００００４１についての特徴量の算出を示している。これらの図に例示するように、特徴量算出部３０は、ＷＥＢサーバ３ごとに、検知数の総計に占める個々の検知数の割合を各ルールについて算出し、さらに、その結果を１から減じてなる値を各ルールの特徴量として算出する。これを数式で表すと、次の式（１）及び式（２）のようになる。各ＷＥＢサーバ３についての特徴量は、こうして当該ＷＥＢサーバ３について算出された各ルールの特徴量と、検知されていないルールについての特徴量（＝０）とを含む特徴量の集合によって表される。
割合＝検知数／総検知数・・・（１）
ルールの特徴量＝１−割合・・・（２）

図９は、指標としてルールを用いて作成される特徴量マトリクスの例を示す図である。特徴量算出部３０は、上述したようにして算出した各ＷＥＢサーバ３の特徴量（ルールごとの特徴量の集合）を、図９に示すようなマトリクス形式で保持するよう構成される。

次に指標がリクエスト種別である場合に関して、図１２（ｂ）は、指標がリクエスト種別である場合に取得される検知数の例を示す図である。同図及び後述する図１２（ａ）（ｃ）には、各種のプログラミング言語間で交換されるデータのフォーマットであるＪＳＯＮ（JavaScript（登録商標） Object Notation）に従って作成されたデータを示している。特徴量算出部３０は、各ＷＥＢサーバ３についてのアクセスログを履歴データベース２１から読み出し、その中に含まれるリクエストの数をリクエスト種別ごとに積算することによって、図１２（ｂ）に示すように各ＷＥＢサーバ３におけるリクエスト種別ごとの検知数を取得する。

ここで、図１２（ａ）は、特徴量算出部３０によって一部のリクエスト種別がグループ化される前の状態を示している。図１２（ａ）と図１２（ｂ）とを比較すると理解されるように、図１２（ｂ）に示すリクエスト種別「ｗｏｒｄｐｒｅｓｓ」は、図１２（ａ）に符号Ａ１で示した３つのリクエスト種別「ｗｏｒｄｐｒｅｓｓ」、「ｗｐ−ｃｒｏｎ」、「ｗｐ−ｃｏｎｔｅｎｔ」をグループ化したものであり、図１２（ｂ）に示すリクエスト種別「ｉｍａｇｅ」は、図１２（ａ）に符号Ａ１で示した３つのリクエスト種別「ｇｉｆ」、「ｊｐｇ」、「ｐｎｇ」をグループ化したものである。特徴量算出部３０は、グループを構成する複数のリクエスト種別（例えば、リクエスト種別「ｗｏｒｄｐｒｅｓｓ」、「ｗｐ−ｃｒｏｎ」、「ｗｐ−ｃｏｎｔｅｎｔ」）を同一のリクエスト種別（例えば、リクエスト種別「ｗｏｒｄｐｒｅｓｓ」）と見なして、上記積算を行う。

図１２（ｃ）は、指標がリクエスト種別である場合における特徴量の算出例を示す図である。同図に示すように、特徴量算出部３０は、リクエスト種別をその内容ごとに複数の分類Ｂ１，Ｂ２に分類し、ＷＥＢサーバ３ごとかつ分類ごとに、上記式（１）により検知数の総計に占める個々の検知数の割合を各リクエスト種別の特徴量として算出する。各ＷＥＢサーバ３についての特徴量は、こうして当該ＷＥＢサーバ３について算出された各リクエスト種別の特徴量と、検知されていない各リクエスト種別についての特徴量（＝０）とを含む特徴量の集合によって表される。

図１３は、指標としてリクエスト種別を用いて作成される特徴量マトリクスの例を示す図である。特徴量算出部３０は、上述したようにして算出した各ＷＥＢサーバ３の特徴量（リクエスト種別ごとの特徴量の集合）を、図１３に示すようなマトリクス形式で保持するよう構成される。

図２に戻る。ルール更新部３１は、特徴量算出部３０によって算出された特徴量に基づき、複数のＷＥＢサーバ３それぞれについてルールデータベース２０に記憶されているルールを更新する機能部である。ルール更新部３１の具体的な処理は、指標としてルールを用いて作成される特徴量マトリクスに対してはユーザ類似度算出部４０及びレコメンドスコア算出部４１を用いて実行され、指標としてリクエスト種別を用いて作成される特徴量マトリクスに対してはグループ化処理部４２を用いて実行される。以下、それぞれについて詳しく説明する。

ユーザ類似度算出部４０は、特徴量算出部３０によって算出された特徴量に基づいて、複数のＷＥＢサーバ３相互の類似度を示すユーザ類似度を算出する機能部である。

図４は、ユーザ類似度算出部４０によって実行されるユーザ類似度算出処理の処理フロー図である。同図に示すように、ユーザ類似度算出部４０は、複数のＷＥＢサーバ３のすべての組み合わせについて、ステップＳ１２〜Ｓ１６の処理を実行する（ステップＳ１０，Ｓ１１）ことにより、ユーザ類似度を算出する。

具体的に説明すると、ユーザ類似度算出部４０はまず、特徴量マトリクスから２つの注目ＷＥＢサーバ３に対して共起しているルールを抽出する（ステップＳ１２）。ここでいう共起とは、両方のＷＥＢサーバ３において検知数が０より大きい値となっていることを意味する。

図１０（ａ）は、それぞれｈｏｓｔ００００３９，ｈｏｓｔ００００４２の間で共起しているルールを示す図である。この例では、４つのルール（ルールＩＤ：３１１５１，３１５０８，３１５１５，３１５１６）が共起している。図１０（ａ）においてＷＥＢサーバＩＤとルールＩＤの交点に示した数値は、特徴量マトリクスに含まれる特徴量の値である。このうちの一部は、図９にも示されている。

図４に戻り、ユーザ類似度算出部４０は、抽出した各ルールについて、ユークリッド距離の算出を行う（ステップＳ１３，Ｓ１４）。ユークリッド距離の算出は、具体的には以下の式（３）により実行される。
ユークリッド距離＝（一方のＷＥＢサーバ３の特徴量−他方のＷＥＢサーバ３の特徴量）^２・・・（３）

図１０（ｂ）は、図１０（ａ）に示した例において算出される各ルールのユークリッド距離を示す図である。同図に示すように、ユークリッド距離はルールごとに算出される。

図４に戻り、ユーザ類似度算出部４０は続いて、各ルールについて算出したユークリッド距離の合計値を算出し（ステップＳ１５）、算出した合計値に基づいてユーザ類似度を算出する（ステップＳ１６）。ステップＳ１６の算出は、具体的には以下の式（４）により実行される。これにより得られるユーザ類似度は、大きいほど特徴量の差が小さいことを示し、したがって、大きいほど攻撃の状況が似ていることを示す値となる。
ユーザ類似度＝１／（１＋合計値^０．５）・・・（４）

図１０（ｃ）は、図１０（ａ）に示した例において算出されるユークリッド距離の合計値及びユーザ類似度を示す図である。この図において、ユークリッド距離の合計値は図１０（ｂ）に示したユークリッド距離を合計することによって得られる値であり、ユーザ類似度はユークリッド距離の合計値を式（４）に代入して得られる値となっている。

図２に戻る。レコメンドスコア算出部４１は、複数のＷＥＢサーバ３ごとに、当該ＷＥＢサーバ３についてルールデータベース２０に記憶されておらず他のＷＥＢサーバ３についてルールデータベース２０に記憶されている１以上のルールのそれぞれについて、ユーザ類似度算出部４０により算出されたユーザ類似度で重み付けした上記特徴量の加重平均であるレコメンドスコアを算出する機能部である。

図５は、レコメンドスコア算出部４１によって実行されるレコメンドスコア算出処理の処理フロー図である。同図に示す処理は、レコメンドスコア算出部４１が各ＷＥＢサーバ３について実行する処理である。同図に示すように、レコメンドスコア算出部４１はまず、注目ＷＥＢサーバ３について登録されておらず（すなわち、ルールデータベース２０に記憶されておらず）、他のＷＥＢサーバ３について登録されている（すなわち、ルールデータベース２０に記憶されている）ルールを抽出する（ステップＳ２０）。そして、抽出した各ルールについて、ステップＳ２２の処理を実行する（ステップＳ２１）。

ステップＳ２２では、レコメンドスコア算出部４１は、ユーザ類似度算出部４０により算出されたユーザ類似度で重み付けした特徴量（特徴量算出部３０が算出したもの）の加重平均を算出し、注目ＷＥＢサーバ３への推奨の度合いを示すレコメンドスコアとする。具体的には、次の式（５）を用いて、レコメンドスコアの算出を行う。ただし、「登録状況」は、そのルールが登録されているＷＥＢサーバ３については１となり、登録されていないＷＥＢサーバ３については０となる数値である。これにより得られるレコメンドスコアは、大きいほど、対応するルールが攻撃状況の似ている他のＷＥＢサーバ３で頻繁に使用されていることを示す値となる。
レコメンドスコア＝Σ（特徴量×ユーザ類似度）／Σ（登録状況×ユーザ類似度）・・・（５）

図１１（ａ）は、ｈｏｓｔ００００３９についての未登録ルールであって、他のＷＥＢサーバ３について登録されている１以上のルールを示す図である。この例では簡単のため、ｈｏｓｔ００００４２及びｈｏｓｔ００００４９の２ＷＥＢサーバ３のみにそのようなルールが記憶されていた場合を例示している。同図に示すように、この例では、ｈｏｓｔ００００４２に５つの未登録ルール「３１１０３」、「３１５１０」、「３１５１１」、「３１５３３」、「２００００２」が登録され、ｈｏｓｔ００００４９に３つの未登録ルール「３１１０３」、「３１１５３」、「３１５３３」が登録されている。

図１１（ｂ）は、図１１（ａ）に示した各ＷＥＢサーバ３の特徴量を示す図である。同図に示した特徴量は、図９に示した特徴量マトリクスに含まれるものである。ただし、同図には、特徴量マトリクスに記載される特徴量のうち、図１１（ａ）に列挙したルールに関する部分のみを抜き出して示している。

図１１（ｃ）は、図１１（ｂ）に示した各ルールＩＤについて、上記式（５）により算出されるレコメンドスコアを示す図である。このように、レコメンドスコア算出部４１は、未登録のルールごとにレコメンドスコアを算出することになる。

図２に戻る。ルール更新部３１は、レコメンドスコア算出部４１によって算出されたレコメンドスコアに基づいて、複数のＷＥＢサーバ３それぞれについてルールデータベース２０に記憶されているルールを更新する。この場合において、レコメンドスコアの参照の仕方は任意である。例えば、レコメンドスコアが所定値以上であるルールを追加することとしてもよいし、大きい方から所定数以内のレコメンドスコアに対応するルールを追加することとしてもよいし、レコメンドスコアの偏差値が所定値以上であるルールを追加することとしてもよい。上記したように、レコメンドスコアが大きいということは、対応するルールが攻撃状況の似ている他のＷＥＢサーバ３で頻繁に使用されていることを意味するので、この方法でルールを更新することにより、個々のＷＥＢサーバ３にとって必要なルールを適切に選別することが可能になる。

図１１の例で言えば、例えばレコメンドスコアが大きい方から３つ以内に入るルールを追加することとすると、ルール更新部３１は、ルールＩＤ「３１１５３」、「２００００２」、「３１５１０」に対応する３つのルールを、ｈｏｓｔ００００３９についてルールデータベース２０に新たに登録することになる。

図２に戻る。グループ化処理部４２は、特徴量算出部３０によって算出された特徴量に基づいて、複数のＷＥＢサーバ３をグループ化する機能部である。

図６は、グループ化処理部４２によって実行されるグループ化処理の処理フロー図である。同図に示すように、グループ化処理部４２は、まず特徴量マトリクスに対してクラスタリングを実行し（ステップＳ３２）、その結果に基づいてＷＥＢサーバ３のグループ化を行う（ステップＳ３３）。クラスタリングの具体的なアルゴリズムとしては各種のものを使うことが可能であるが、例えばＤＢＳＣＡＮ(Density-based spatial clustering of applications with noise)を用いることが好適である。ＤＢＳＣＡＮを用いれば、互いの特徴量の近さによって複数のＷＥＢサーバ３をグループ化することが可能になる。

図１４は、クラスタリングによる複数のＷＥＢサーバのグループ化例を示す図である。また、図１５は、ＤＢＳＣＡＮの出力結果を示す図である。図１４に示したグループＧ０〜Ｇ２はそれぞれ、図１５に示したグループＧ０〜Ｇ２に対応している。図１５には、さらにグループＧ３〜Ｇ５も示されている。

図１５に示す黒点は、１つ１つがＷＥＢサーバ３を表している。このように、クラスタリングを用いることで、複数のＷＥＢサーバ３を特徴量の近さによってグループ化することができる。この特徴量は、上述したようにリクエスト種別を指標として算出されたものであるから、同一グループに割り当てられたＷＥＢサーバ３は、リクエストの状況が類似していると言うことができる。

図２に戻る。ルール更新部３１は、グループ化処理部４２によって同じグループに分類された１以上のＷＥＢサーバ３についてルールデータベース２０に記憶されているルールを共通化することによって、複数のＷＥＢサーバ３それぞれについてルールデータベース２０に記憶されているルールを更新する。リクエストの状況が似ているＷＥＢサーバ３は、必要とするルールも似ていると考えられるので、この方法でルールの更新を行うことにより、個々のＷＥＢサーバ３にとって必要なルールを適切に選別することが可能になる。

以上説明したように、本実施の形態によるＷＡＦサーバ２によれば、複数のＷＥＢサーバ３のそれぞれにおける指標ごとの検知数に基づき、個々のＷＥＢサーバ３にとって必要なルールを自動的に選別することができる。したがって、ルールサイズの肥大化を招くことなく、新たな種類の攻撃に対していち早く対応することが可能になる。

特に、指標としてルールを用いる場合には、攻撃の状況が似ている他のＷＥＢサーバ３での各ルールの使用状況を反映したレコメンドスコアを算出し、このレコメンドスコアに基づいてルールを更新しているので、個々のＷＥＢサーバ３にとって必要なルールを適切に選別することが可能になる。

また、指標としてリクエスト種別を用いる場合には、リクエストの状況が似ているＷＥＢサーバ３をクラスタリングによってグループ化し、グループ内でルールを共通化することによってルールを更新しているので、この場合にも、個々のＷＥＢサーバ３にとって必要なルールを適切に選別することが可能になる。加えて、実際の攻撃状況によらずルールを更新することができるので、あまり攻撃を受けていないＷＥＢサーバ３についても、適切にルールを更新することが可能になる。

以上、本発明の好ましい実施の形態について説明したが、本発明はこうした実施の形態に何等限定されるものではなく、本発明が、その要旨を逸脱しない範囲において、種々なる態様で実施され得ることは勿論である。

例えば、ＷＡＦサーバ２は、予めグループ化した状態で複数のＷＥＢサーバ３を記憶しておき、グループ内に閉じて上記各処理を実行することとしてもよい。こうすることで、ルールの更新状態が企業や組織の枠を超えて波及していくことを防止することが可能になる。

また、図２（ａ）にはＷＡＦサーバ２が１つのコンピュータによって構成される例を示したが、複数のコンピュータの集合体によってＷＡＦサーバ２を構成することとしてもよい。ＷＥＢサーバ３やフロントエンドサーバ４についても、同様である。

１ ファイアウォールシステム
２ ＷＡＦサーバ
３ ＷＥＢサーバ
４ フロントエンドサーバ
１０ プロセッサ
１１ 入出力インターフェイス
１２ 記憶部
１３ バス
２０ ルールデータベース
２１ 履歴データベース
３０ 特徴量算出部
３１ ルール更新部
４０ ユーザ類似度算出部
４１ レコメンドスコア算出部
４２ グループ化処理部

Claims (4)

1. 注目ＷＥＢサーバを含む複数のＷＥＢサーバのそれぞれについて、互いに独立して、リクエストのブロックに関する１以上のルールを記憶する記憶部と、
   前記複数のＷＥＢサーバのそれぞれにおける指標ごとの検知数に基づき、前記複数のＷＥＢサーバそれぞれの特徴量を算出する特徴量算出部と、
   前記特徴量算出部によって算出された前記特徴量に基づき、前記注目ＷＥＢサーバについて前記記憶部に登録されておらず、前記注目ＷＥＢサーバ以外の前記ＷＥＢサーバについて前記記憶部に登録されているルールのうちの１つ以上を、前記注目ＷＥＢサーバについてのルールとして前記記憶部に追加するルール更新部と、
   を備えるファイアウォール装置。
2. 前記指標は、前記ルールである、
   請求項１に記載のファイアウォール装置。
3. 複数のＷＥＢサーバのそれぞれについて、リクエストのブロックに関する１以上のルールを記憶する記憶部と、
   前記複数のＷＥＢサーバのそれぞれにおける前記ルールごとの検知数に基づき、前記複数のＷＥＢサーバそれぞれの特徴量を算出する特徴量算出部と、
   前記特徴量算出部によって算出された前記特徴量に基づき、前記複数のＷＥＢサーバそれぞれについて前記記憶部に記憶されているルールを更新するルール更新部と、を備え、
   前記ルール更新部は、
   前記特徴量算出部によって算出された前記特徴量に基づいて、前記複数のＷＥＢサーバ相互の類似度を示すユーザ類似度を算出するユーザ類似度算出部と、
   前記複数のＷＥＢサーバごとに、当該ＷＥＢサーバについて前記記憶部に記憶されておらず他のＷＥＢサーバについて前記記憶部に記憶されている１以上のルールのそれぞれについて、前記ユーザ類似度算出部により算出された前記ユーザ類似度で重み付けした前記特徴量の加重平均であるレコメンドスコアを算出するレコメンドスコア算出部と、を有し、
   前記ルール更新部は、前記レコメンドスコア算出部によって算出された前記レコメンドスコアに基づいて、前記複数のＷＥＢサーバそれぞれについて前記記憶部に記憶されているルールを更新する、
   ファイアウォール装置。
4. 複数のＷＥＢサーバのそれぞれについて、互いに独立して、リクエストのブロックに関する１以上のルールを記憶する記憶部と、
   前記複数のＷＥＢサーバのそれぞれにおける前記リクエストの種別ごとの検知数に基づき、前記複数のＷＥＢサーバそれぞれの特徴量を算出する特徴量算出部と、
   前記特徴量算出部によって算出された前記特徴量に基づき、前記複数のＷＥＢサーバそれぞれについて前記記憶部に記憶されているルールを更新するルール更新部と、を備え、
   前記ルール更新部は、前記特徴量算出部によって算出された前記特徴量に基づいて、前記複数のＷＥＢサーバをグループ化するグループ化処理部を有し、
   前記ルール更新部は、前記グループ化処理部によって同じグループに分類された１以上のＷＥＢサーバについて前記記憶部に記憶されているルールを共通化することによって、前記複数のＷＥＢサーバそれぞれについて前記記憶部に記憶されているルールを更新する、
   ファイアウォール装置。

Images