JP2007249279A - サービス判定装置、脆弱性検査装置、攻撃検知装置、サービス判定方法、及びプログラム - Google Patents

Abstract

【課題】標準的なポート番号以外のポート番号でサービスが提供される場合であっても、そのポート番号で提供されるサービスを特定できるようにする。
【解決手段】情報の入出力を行う入出力部１１と、各処理部の動作を制御する制御部１２と、特定のポートに対する接続を指示する接続指示部１３と、特定のポートから送出されるバナー情報を取得するバナー情報取得部１４と、バナー情報を引き出すためのリクエストデータを記憶するデータ記憶部１５と、特定のポートで提供されているサービスを特定するサービス特定部１６と、サービスを特定する際に参照されるテーブルを記憶するテーブル記憶部１７と、特定されたサービスに応じた脆弱性検査の実施を指示する検査指示部１８と、各処理部とネットワークとの間で情報の送受信を行う通信部１９とを備える。
【選択図】図２

Description

本発明は、ネットワークを介して接続された他の装置が提供するサービスの脆弱性を検査する脆弱性検査装置等に関する。

近年、インターネットが爆発的に普及し、我々の生活を便利にしている。しかし、その反面、インターネットに潜む脅威も無視することはできない。特に、インターネット上で提供されるサービスに脆弱性があると、その脆弱性を突いた攻撃を受ける虞がある。例えば、ワームによる攻撃、サーバへの不正侵入によるホームページの改ざんや機密情報の漏洩等である。そこで、インターネット上のサービスについては、脆弱性が存在していないかどうかを検査することが重要になってきている。

ところで、一般に、インターネット上で公開されるサービスについては、そのサービスを提供する際に用いる標準的なポート番号が定められている。従って、各サービスは、通常、その標準的なポート番号で提供される。こうした事情から、従来、あるサービスの脆弱性の検査は、そのサービスに割り当てられた標準的なポート番号に対してのみ行うのが普通だった。

ここで、公報記載の従来技術としては、コンピュータウィルスの感染によってオープンされると想定するポート番号に対してポートスキャンを行うことにより、あるコンピュータ上で稼動しているソフトウェアの脆弱性を検査するものがある(例えば、特許文献１参照)。この特許文献１では、ユーザが意図してそのコンピュータ上に提供するサービスに対応するポート番号を検査対象から除外している。例えば、サービス「Ｗｅｂ(ＨＴＴＰ)」に対するポート番号「８０」、サービス「ＦＴＰ」に対するポート番号「２０」及び「２１」、サービス「ｔｅｌｎｅｔ」に対するポート番号「２３」が除外されている。

特開２００５−０２５２６９号公報

前述の通り、従来は、サービスに対して定められた標準的なポート番号に対して脆弱性検査を実施する検査方法が用いられていた。しかしながら、この標準的なポート番号は必ずこれを用いなければならないというものではなく、サービスの提供者が、サービスの提供に用いるポート番号を任意に変更することは可能である。
このように標準的なポート番号以外でサービスを提供するようにした場合、従来の検査方法では、そのサービスの脆弱性を検出することはできないという問題点があった。

また、特許文献１の技術は、あるポート番号のポートがコンピュータウィルスの感染によってオープンすることが分かっている状況におけるポートスキャンによる検査である。また、検査対象から除外するポート番号としても、各サービスに割り当てられた標準的なポート番号が例示されている。従って、特許文献１では、標準的なポート番号以外でサービスが提供されることなど全く考えられておらず、そうした場合に上記問題点を解決するための有効な手段を提供するものでもない。

本発明は、以上のような技術的課題を解決するためになされたものであって、その目的は、標準的なポート番号以外のポート番号でサービスが提供される場合であっても、そのポート番号で提供されるサービスを特定できるようにすることにある。
また、本発明の他の目的は、あるサービスの脆弱性の検査や、あるサービスに対する攻撃の検知を、効率的に実施できるようにすることにある。

かかる目的のもと、本発明は、ネットワークを介して接続された他の装置が特定のポートで提供しているサービスを、そのポートから送出されたバナー情報の特徴に基づいて判定するようにした。即ち、本発明のサービス判定装置は、特定のポートに対して接続を行う接続手段と、この接続手段による接続に応じて返信されるバナー情報を取得するバナー情報取得手段と、バナー情報からサービスに関するキーワードを検出することにより、特定のポートで提供されるサービスを特定するサービス特定手段とを備えている。

また、本発明では、特定のポートへ接続する際に、バナー情報を引き出すようなリクエストを複数送信するようにした。即ち、本発明のサービス判定装置は、バナー情報取得手段が、サービスごとに用意されたバナー情報を返信させるためのデータを、特定のポートに繰り返し送信することにより、そのバナー情報を取得するように構成することもできるものである。そして、このような構成により、接続しただけでバナー情報が取得できるサービス以外にも、より多くのサービスに関するバナー情報を取得することができるようになる。

更に、本発明は、各ポートで提供されるサービスの調査結果を用いて、脆弱性検査の内容を最適化するようにした。即ち、本発明の脆弱性検査装置は、特定のポートから送出されるバナー情報を取得するバナー情報取得手段と、バナー情報に基づいて、特定のポートで提供されるサービスを特定するサービス特定手段と、このサービス特定手段により特定されたサービスに応じた脆弱性検査を実行する検査手段とを備えている。これにより、標準的なポート番号以外で稼働するサービスの脆弱性の検出を可能とし、ポートが開いていないサービスやそのサービスに関連のない無駄な検査を省く効果が期待できる。

更にまた、本発明は、各ポートで提供されるサービスの調査結果を用いて、攻撃検知の内容を最適化するようにした。即ち、本発明の攻撃検知装置は、複数のポートから送出されるバナー情報を取得するバナー情報取得手段と、バナー情報に基づいて、特定のサービスが提供されているポートを特定するポート特定手段と、このポート特定手段により特定されたポートに対する攻撃データを検知する検知手段とを備えている。これにより、標準的なポート番号以外で稼働するサービスに対する攻撃データの検出を可能とする。

また、本発明は、ネットワークを介して接続された他の装置が特定のポートで提供しているサービスを判定する方法として捉えることもできる。その場合、本発明のサービス判定方法は、特定のポートに対して接続を行うステップと、接続に応じて返信されるバナー情報を取得するステップと、サービスとそのサービスに関するキーワードとの対応情報を所定の記憶装置から読み出すステップと、対応情報に含まれるキーワードがバナー情報に含まれる場合に、そのキーワードに対応するサービスを、特定のポートで提供されるサービスとして特定するステップとを含んでいる。

一方、本発明は、ネットワークを介して接続された他の装置が特定のポートで提供しているサービスを判定するためのプログラムとして捉えることもできる。その場合、本発明のプログラムは、コンピュータに、特定のポートに対して接続を行う機能と、接続に応じて返信されるバナー情報を取得する機能と、バナー情報からサービスに関するキーワードを検出することにより、特定のポートで提供されるサービスを特定する機能とを実現させるためのものである。

本発明によれば、標準的なポート番号以外のポート番号でサービスが提供される場合であっても、そのポート番号で提供されるサービスを特定することが可能になる。

以下、添付図面を参照して、本発明を実施するための最良の形態(以下、「実施の形態」という)について詳細に説明する。
図１は、本実施の形態が適用されるコンピュータシステムの構成を示した図である。このコンピュータシステムは、検査装置１０と、被検査装置２０とが、ネットワーク３０を介して接続されている。
検査装置１０は、被検査装置２０がネットワーク３０上で提供するサービスの脆弱性を検査する装置である。例えば、汎用的なＰＣ(Personal Computer)であってよい。
また、被検査装置２０は、ネットワーク３０上でサービスを提供するサーバコンピュータである。この被検査装置２０としては、ＦＴＰ(File Transfer Protocol)サービスを提供するＦＴＰサーバ、ＳＳＨ(Secure SHell)サービスを提供するＳＳＨサーバ、ＳＭＴＰ(Simple Mail Transfer Protocol)サービスを提供するＳＭＴＰサーバ、ＨＴＴＰ(HyperText Transfer Protocol)サービスを提供するＨＴＴＰサーバ、Ｐｒｏｘｙサービスを提供するＰｒｏｘｙサーバ等が例示される。尚、図では、１台の被検査装置２０しか示していないが、被検査装置２０の数はこれに限るものではない。即ち、複数台の被検査装置２０がネットワーク３０に接続されていてもよい。
ネットワーク３０は、例えば、インターネットである。

次に、本実施の形態における検査装置１０の機能構成について説明する。
図２は、検査装置１０の機能構成の一例を示したブロック図である。
図示するように、検査装置１０は、情報の入出力を行う入出力部１１と、後述する各処理部の動作を制御する制御部１２とを含む。また、被検査装置２０における特定のポートに対する接続を指示する接続指示部１３と、被検査装置２０における特定のポートから送出されるバナー情報を取得するバナー情報取得部１４と、バナー情報を引き出すためのリクエストデータを記憶するデータ記憶部１５とを含む。更に、被検査装置２０における特定のポートで提供されているサービスを特定するサービス特定部１６と、サービスを特定する際に参照されるテーブルを記憶するテーブル記憶部１７と、特定されたサービスに応じた脆弱性検査の実施を指示する検査指示部１８とを含む。更にまた、被検査装置２０との間で情報の送受信を行う通信部１９とを含んでいる。

尚、これらの各機能部は、ソフトウェアとハードウェア資源とが協働することにより実現される。具体的には、検査装置１０の図示しないＣＰＵが、入出力部１１、制御部１２、接続指示部１３、バナー情報取得部１４、サービス特定部１６、検査指示部１８、通信部１９の各機能を実現するプログラムを外部記憶装置から主記憶装置に読み込んで処理を行う。また、データ記憶部１５及びテーブル記憶部１７は、例えば、磁気ディスクによって実現される。

次いで、このような機能構成を有する検査装置１０の動作について詳細に説明する。
ここで、検査装置１０の動作は、大きく前半と後半とに分けることができる。前半は、ポートスキャン、バナー情報の取得、サービスの特定であり、後半は、脆弱性の検査である。そこで、以下では、前半の処理と後半の処理とに分けて動作を説明する。

［前半の処理］
図３は、前半の処理の流れを示したフローチャートである。
即ち、まず、ユーザが検査対象として指定した複数のポート番号に対して接続を試みる。そして、ポートへの接続が成功した場合は、バナー情報を取得し、そのポートで提供されるサービスが何であるかを判定する。
以下、順を追って詳しく説明する。

まず、検査装置１０は、例えば、入出力部１１がユーザによる動作開始を指示する操作を認識することで動作を開始する。これにより、制御部１２による制御の下、接続指示部１３が、指定されたポートに対する接続の試行、つまり、ポートスキャンを通信部１９に指示する。そして、通信部１９が、そのポートに対し実際にポートスキャンを実施する(ステップ１０１)。ここで、ポートスキャンとしては、一般的なConnect()方式のポートスキャンを実施することができる。Connect()方式のポートスキャンとは、オープン状態(外部からの接続を受付可能な状態)であるポートのポート番号を調査するものである。即ち、ポート番号ごとに接続を試行し、接続が成功したかどうかを判定する(ステップ１０２)。

ここで、接続に失敗したと判定された場合、このポートはクローズ状態にあると判断する。即ち、接続指示部１３が接続の失敗を検出し、その情報を制御部１２に返す。これにより、制御部１２による制御の下、処理は終了する。
一方、接続に成功したと判定された場合、このポートはオープン状態にあると判断する。即ち、接続指示部１３が接続の成功を検出し、その情報を制御部１２に返す。これにより、制御部１２による制御の下、バナー情報取得部１４が、バナー情報の取得処理を実行する(ステップ１０３)。尚、このバナー情報の取得処理の詳細については後述する。
また、バナー情報の取得処理が終了すると、同じく制御部１２による制御の下、サービス特定部１６が、サービスの特定処理を実行する(ステップ１０４)。尚、このサービスの特定処理の詳細についても後述する。

そして、サービス特定部１６から処理結果を受けると、最後に、制御部１２は、サービスが確定したかどうかを判定する(ステップ１０５)。
ここで、サービスが確定できなかったと判定された場合は、ステップ１０３及びステップ１０４の処理を、サービスが確定するまで繰り返す。そして、サービスが確定すれば、処理は終了する。

次に、図３で説明を省略したバナー情報の取得処理及びサービスの特定処理の詳細について述べる。
―バナー情報の取得処理―
まず、バナー情報取得部１４がバナー情報を取得する際の動作について説明する。
図４は、このときのバナー情報取得部１４の動作を示したフローチャートである。ここで、バナー情報取得部１４の動作は、図３のステップ１０２に引き続き行われる場合と、図３のステップ１０５から戻って行われる場合とで、若干動作が異なるので、分けて説明する。
まず、図３のステップ１０２に引き続き行われる場合について説明する。
この場合、バナー情報取得部１４は、図３のステップ１０１で実施したポートスキャンに対する応答として、バナー情報が返されたかどうかを判定する(ステップ１１１)。
即ち、ポートスキャンで接続に成功した場合、ある種のサービスが提供されているポートからは、接続しただけでバナー情報が返される。例えば、ＦＴＰサービス、ＳＳＨサービス、ＳＭＴＰサービスがこのようなサービスに該当する。一方、接続に成功した後に、何らかのデータを送信しなければ、何の応答も返さないサービスも存在する。例えば、ＨＴＴＰサービス、Ｐｒｏｘｙサービスがこのようなサービスに該当する。従って、ここではまず、このサービスごとの動作の違いを考慮して、ポートスキャンに応じてバナー情報が返されたかどうかを判定しているのである。

ここで、バナー情報を取得できたと判定された場合、バナー情報取得部１４は、取得したバナー情報を制御部１２に返す(ステップ１１２)。
一方、バナー情報を取得できなかったと判定された場合は、バナー情報を引き出すためのリクエストデータを送信する必要がある。ここで、リクエストデータを送信することが必要となるサービスとしては、上述したように、ＨＴＴＰサービス、Ｐｒｏｘｙサービスが例示される。バナー情報を引き出すためのリクエストデータは、サービスごとに異なるので、リクエストデータを送信しても、サービスがそのリクエストデータを認識できないものであった場合は、何の応答も返されない可能性がある。従って、バナー情報を引き出すためには、検査対象のポートで提供されるサービスが認識できるまで、各種サービスに対して用意されたリクエストデータを送信することになる。

具体的には、データ記憶部１５が、サービスごとのリクエストデータを記憶しておく。この状態で、バナー情報取得部１４は、データ記憶部１５からリクエストデータを読み込む(ステップ１１３)。そして、読込みが成功したかどうかを判定する(ステップ１１４)。
ここで、リクエストデータの読込みが成功したと判定された場合、つまり、ＥＯＦ(End Of File)ではない場合、バナー情報取得部１４は、そのリクエストデータの送信を通信部１９に指示する。これにより、通信部１９が、リクエストデータを検査対象のポートに対して送信する(ステップ１１５)。尚、ここでは、図３のステップ１０２に引き続き行われる動作を想定しているので、リクエストデータは、先頭から順番に読み出すようにする。

そして、バナー情報取得部１４は、このリクエストデータに応じてバナー情報が返信されたかどうかを再び判定する(ステップ１１１)。その後の処理は、ポートスキャンに応じてバナー情報が返された場合と同様であるため、説明を省略する。
また、ステップ１１１〜ステップ１１５を繰り返していき、どのリクエストデータを送信してもバナー情報が返されないことも理論的には想定できる。その場合、バナー情報取得部１４は、エラー情報を制御部１２に返す(ステップ１１６)。尚、この場合は、図３のステップ１０４の処理が行えないため、ステップ１０５での判定が「Ｎｏ」となる。

次に、図３のステップ１０５から戻って行われる場合について説明する。
この場合も、バナー情報取得部１４は、バナー情報が返されたかどうかを判定する(ステップ１１１)が、この時点でバナー情報が返されていることはない。従って、バナー情報取得部１４は、データ記憶部１５からリクエストデータを読み込む(ステップ１１３)。そして、読込みが成功したかどうかを判定する(ステップ１１４)。
ここで、リクエストデータの読込みが成功したと判定された場合、つまり、ＥＯＦではない場合、バナー情報取得部１４は、そのリクエストデータの送信を通信部１９に指示する。これにより、通信部１９が、リクエストデータを検査対象のポートに対して送信する(ステップ１１５)。尚、ここでは、図３のステップ１０５から戻って行われる動作を想定しているので、リクエストデータは、図３のステップ１０３を前回実行した時に最後に読み込んだリクエストデータの次のリクエストデータから順番に読み出すようにする。

そして、バナー情報取得部１４は、このリクエストデータに応じてバナー情報が返信されたかどうかを再び判定する(ステップ１１１)。その後の処理は、これまで述べた場合と同様であるため、説明を省略する。
また、ステップ１１１〜ステップ１１５を繰り返していき、どのリクエストデータを送信してもバナー情報が返されないことも理論的には想定できる。その場合、バナー情報取得部１４は、エラー情報を制御部１２に返す(ステップ１１６)。尚、この場合は、図３のステップ１０４の処理が行えないため、ステップ１０５での判定が「Ｎｏ」となる。

ここで、バナー情報取得部１４で取得されるバナー情報の一部を例示しておく。
図５は、ＦＴＰサービス、ＳＳＨサービス、ＳＭＴＰサービス、ＨＴＴＰサービス、Ｐｒｏｘｙサービスが提供されるポートから送出されるバナー情報の例を示したものである。同じサービスであっても、製品ごとにバナー情報は異なるので、ここでは、対応する製品の情報についても併せて示している。尚、図では、紙面の都合上、ＦＴＰサービス、ＳＳＨサービス、ＳＭＴＰサービスについては、それぞれ、２種類のバナー情報を示し、ＨＴＴＰサービス、Ｐｒｏｘｙサービスについては、それぞれ、１種類のバナー情報を示している。しかしながら、各サービスが提供されるポートから送出されるバナー情報は、これらに限らず、更に多くのものが存在する。

―サービスの特定処理―
このようにバナー情報を取得すると、取得したバナー情報から、何のサービスが提供されているかを判断することができる。即ち、サービスに特有のバナー情報や応答の特徴等の情報をプログラム内に持ち、この特徴等とバナー情報とを照合することで、サービスの判断が可能となる。
或いは、サービスとそのサービスに特有のバナー情報の特徴等との対応テーブルをテーブル記憶部１７に持ち、これをプログラムが参照することにより、サービスを特定することもできる。

ここで、このような対応テーブルの一例として、キーワード/サービステーブルについて説明する。キーワード/サービステーブルは、バナー情報に含まれるキーワードと、そのキーワードに関係するサービスとを対応付けたテーブルである。
図６は、キーワード/サービステーブルの一例を示した図である。
このキーワード/サービステーブルにより、例えば、「Microsoft FTP Service (Version 5.0)」というキーワードを含むバナー情報は、ＦＴＰサービスが提供されるポートから送出されたものであり、「OpenSSH_3.7.1p1」というキーワードを含むバナー情報は、ＳＳＨサービスが提供されるポートから送出されたものであることが分かる(「Microsoft」は、米国マイクロソフト社の米国及びその他の国における登録商標)。

次に、サービス特定部１６が、バナー情報とキーワード/サービステーブルとに基づいてサービスを特定する際の動作について説明する。尚、サービス特定部１６に対しては、制御部１２からバナー情報が渡されているものとする。
図７は、このときのサービス特定部１６の動作を示したフローチャートである。
まず、サービス特定部１６は、キーワード/サービステーブルから１つのキーワードを読み込む(ステップ１２１)。そして、キーワードの読込みが成功したかどうかを判定する(ステップ１２２)。

ここで、キーワードの読込みが成功したと判定された場合、つまり、ＥＯＦではない場合、サービス特定部１６は、そのキーワードがバナー情報に含まれるかどうかを判定する(ステップ１２３)。
ここで、キーワードがバナー情報に含まれていないと判定された場合は、ステップ１２１に戻り、次のキーワードを読み込む(ステップ１２１)。また、キーワードがバナー情報に含まれていると判定された場合は、キーワード/サービステーブルから、そのキーワードに対応付けられたサービスの情報を取得する。そして、そのサービスの情報を制御部１２に返す(ステップ１２４)。
一方、キーワード/サービステーブル内の全てのキーワードが、バナー情報に含まれていない場合は、全てのキーワードを読み込んだ後、ステップ１２２でキーワードの読込みが失敗する。その場合、サービス特定部１６は、エラー情報を制御部１２に返す(ステップ１２５)。尚、この場合は、図３のステップ１０５での判定が「Ｎｏ」となる。

［後半の処理］
後半の処理においては、検査対象のポートで提供されるサービスの脆弱性を検査する。即ち、前半の処理により、オープン状態のポートとそのポートで提供されるサービスが判明するので、後半の処理では、そのオープン状態のポートに対し、そのポートで提供されるサービスに応じた脆弱性検査を実施する。
図８は、サービスごとの脆弱性の検査項目を示した図である。即ち、各サービスに対して、１又は複数の検査項目が定義され、各検査項目は、対応するサービスに関する１又は複数の脆弱性を検出する機能を持つ。これらの検査項目は、予めサービスごとに分類しておく。そして、サービスを指定することでそのサービスに関連する検査項目の検査を実施可能な脆弱性検査処理を用意しておく。

具体的には、検査指示部１８が、サービス特定部１６が特定したサービスの情報を制御部１２から受け取り、そのサービスに関連する検査項目の実施を通信部１９に指示する。これにより、通信部１９が、指示された検査項目、つまり、サービスに応じた脆弱性検査を実施する。

このように、本実施の形態では、脆弱性検査の前に検査対象のポートで提供されるサービスを判定し、サービスごとに分類された脆弱性検査のうちそのサービスに応じた検査を実施するようにした。これにより、効率の良い脆弱性検査が実現されることとなった。

例えば、脆弱性検査の前にポートスキャンを実施し、オープン状態を検出した全てのポートに対し、複数のサービスに関する脆弱性検査を実施する、という方法も考えられる。このような方法を採用すれば、標準的なポート番号以外で提供されるサービスの検査も一応可能にはなる。しかしながら、１つのポートに対して複数のサービスに関する脆弱性検査を実施するため、検査の無駄が多く、余計な検査時間と通信トラフィックを発生させてしまうのである。これに対し、本実施の形態では、ポートスキャンにサービス判定機能を追加している。これにより、各ポートで無駄のない適切な脆弱性検査を実施することができ、脆弱性検査の検査時間を短縮し、通信トラフィックも削減できる。

ところで、本実施の形態では、あるポートに着目し、そのポートで提供されているサービスを判定するようにした。そして、提供されているサービスに応じた脆弱性検査を行うようにした。
しかしながら、本実施の形態は、次のように捉えることもできる。即ち、複数のポートに対して同様の処理を実行することにより、標準的なポート番号以外でサービスを提供していたとしても、サービスとポート番号との対応関係を把握することができる、というものである。従って、サービスに着目すれば、そのサービスが提供されているポートを特定するポート特定手段を備えたポート判定装置として捉えることもできる。

このような捉え方をした場合、ポートの判定結果は、例えば、あるサービスに対する攻撃データを検知する侵入検知システム(ＩＤＳ)に用いることができる。従来のＩＤＳでは、あるサービスに対する攻撃データを検知する場合、そのサービスが提供される標準的なポート番号に対する攻撃データしか監視していなかった。従って、サービスを標準的なポート番号以外のポート番号で提供しており、攻撃者がそのことを知って攻撃データを送ってきた場合は、その攻撃データを検知することはできなかった。これに対し、本実施の形態のようにポートの判定を行ってから攻撃を検知するようにすれば、標準的なポート番号以外のポート番号に対する攻撃データも検知することが可能となる。

本実施の形態が適用されるコンピュータシステムの全体構成図である。 本実施の形態における検査装置の機能構成を示したブロック図である。 本実施の形態における検査装置の全体動作を示したフローチャートである。 本実施の形態におけるバナー情報取得部の動作を示したフローチャートである。 本実施の形態において取得されるバナー情報の例を示した図である。 本実施の形態において参照されるキーワード/サービステーブルの例を示した図である。 本実施の形態におけるサービス特定部の動作を示したフローチャートである。 本実施の形態における脆弱性検査について説明するための図である。

符号の説明

１０…検査装置、２０…被検査装置、３０…ネットワーク

Claims (8)

1. ネットワークを介して接続された他の装置が特定のポートで提供しているサービスを判定するサービス判定装置であって、
   前記特定のポートに対して接続を行う接続手段と、
   前記接続手段による接続に応じて返信されるバナー情報を取得するバナー情報取得手段と、
   前記バナー情報からサービスに関するキーワードを検出することにより、前記特定のポートで提供されるサービスを特定するサービス特定手段と
   を備えたことを特徴とするサービス判定装置。
2. 前記バナー情報取得手段は、サービスごとに用意された前記バナー情報を返信させるためのデータを、前記特定のポートに繰り返し送信することにより、当該バナー情報を取得することを特徴とする請求項１記載のサービス判定装置。
3. ネットワークを介して接続された他の装置が特定のポートで提供しているサービスを対象として、当該サービスの脆弱性を検査する脆弱性検査装置であって、
   前記特定のポートから送出されるバナー情報を取得するバナー情報取得手段と、
   前記バナー情報に基づいて、前記特定のポートで提供されるサービスを特定するサービス特定手段と、
   前記サービス特定手段により特定されたサービスに応じた脆弱性検査を実行する検査手段と
   を備えたことを特徴とする脆弱性検査装置。
4. ネットワークを介して接続された他の装置が提供している特定のサービスを対象として、当該特定のサービスに対する攻撃データを検知する攻撃検知装置であって、
   複数のポートから送出されるバナー情報を取得するバナー情報取得手段と、
   前記バナー情報に基づいて、前記特定のサービスが提供されているポートを特定するポート特定手段と、
   前記ポート特定手段により特定されたポートに対する攻撃データを検知する検知手段と
   を備えたことを特徴とする攻撃検知装置。
5. ネットワークを介して接続された他の装置が特定のポートで提供しているサービスを判定するサービス判定方法であって、
   前記特定のポートに対して接続を行うステップと、
   前記接続に応じて返信されるバナー情報を取得するステップと、
   サービスと当該サービスに関するキーワードとの対応情報を所定の記憶装置から読み出すステップと、
   前記対応情報に含まれるキーワードが前記バナー情報に含まれる場合に、当該キーワードに対応するサービスを、前記特定のポートで提供されるサービスとして特定するステップと
   を含むことを特徴とするサービス判定方法。
6. 前記バナー情報を取得するステップでは、前記特定のポートに対する接続に応じてバナー情報が返信されなかった場合に、サービスごとに用意された前記バナー情報を返信させるためのデータを、当該特定のポートに繰り返し送信することにより、当該バナー情報を取得することを特徴とする請求項５記載のサービス判定方法。
7. ネットワークを介して接続された他の装置が特定のポートで提供しているサービスを判定するためのプログラムであって、
   コンピュータに、
   前記特定のポートに対して接続を行う機能と、
   前記接続に応じて返信されるバナー情報を取得する機能と、
   前記バナー情報からサービスに関するキーワードを検出することにより、前記特定のポートで提供されるサービスを特定する機能と
   を実現させるためのプログラム。
8. 前記バナー情報を取得する機能では、前記特定のポートに対する接続に応じてバナー情報が返信されなかった場合に、サービスごとに用意された前記バナー情報を返信させるためのデータを、当該特定のポートに繰り返し送信することにより、当該バナー情報を取得することを特徴とする請求項７記載のプログラム。

Images