(57)【要約】【課題】ワームの検知のために発生するネットワーク負荷を軽減する。【解決手段】検知装置は、送信部、制御部、および、検知部を備える。送信部は、ネットワーク中で使用されている１つ以上の通信装置の各々に、通信装置が使用しているオペレーティングシステムの種類に対応付けられたパラメータを含む応答フレームの送信を要求する要求フレームを送信する。制御部は、受信した応答フレームから特定したオペレーティングシステムに応じた周期で、応答フレームの送信元に送信フレームを送信するための制御を行う。検知部は、１つ以上の通信装置のいずれかからのアクセスに含まれるマルウェアを検知する。【選択図】図８
2020109927.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク中で使用されている１つ以上の通信装置の各々に、当該通信装置が使用しているオペレーティングシステムの種類に対応付けられたパラメータを含む応答フレームの送信を要求する要求フレームを送信する送信部と、
受信した前記応答フレームから特定したオペレーティングシステムに応じた周期で、前記応答フレームの送信元に送信フレームを送信するための制御を行う制御部と、
前記１つ以上の通信装置のいずれかからのアクセスに含まれるマルウェアを検知する検知部
を含むことを特徴とする検知装置。
【請求項２】
前記送信部は、前記ネットワーク中で使用されている可能性のある１つ以上のＩＰアドレスの各々に対するアドレス解決要求を送信し、
前記制御部は、前記アドレス解決要求に応答するアドレス解決応答を受信すると、前記アドレス解決応答の送信元を前記１つ以上の通信装置として特定する
ことを特徴とする請求項１に記載の検知装置。
【請求項３】
前記制御部は、
処理対象である対象ＩＰアドレスを用いる通信装置から前記アドレス解決応答で通知された第１のＭＡＣアドレスを取得し、
前記対象ＩＰアドレス宛の前記送信フレームとして、前記対象ＩＰアドレスを用いる装置のＭＡＣアドレスを問合わせる他のアドレス解決要求を生成し、
前記他のアドレス解決要求に応答する他のアドレス解決応答に、前記第１のＭＡＣアドレスとは異なる第２のＭＡＣアドレスが含まれる場合、前記対象ＩＰアドレスに宛てて他の要求フレームを送信するための制御を行い、
前記他の要求フレームに応答する他の応答フレーム中の前記パラメータを用いて特定したオペレーティングシステムに応じて、前記対象ＩＰアドレスに前記送信フレームを送信する周期を更新する
ことを特徴とする請求項２に記載の検知装置。
【請求項４】
前記制御部は、前記１つ以上のＩＰアドレスのうちで前記アドレス解決応答を受信していないＩＰアドレスに対して、所定の時間間隔で前記アドレス解決要求を前記送信部から送信させる
ことを特徴とする請求項２または３に記載の検知装置。
【請求項５】
前記ネットワークからフレームを受信する受信部をさらに備え、
前記制御部は、前記受信部が受信した受信フレームが、前記受信フレームの送信元が使用するＩＰアドレスを通知する通知フレームである場合、前記通知フレームの送信元を前記１つ以上の通信装置として特定する
ことを特徴とする請求項１に記載の検知装置。
【請求項６】
前記制御部は、
処理対象である対象ＩＰアドレスを用いる通信装置から前記通知フレームを受信した後に、前記対象ＩＰアドレスに宛てに他の要求フレームを送信するための制御を行い、
前記他の要求フレームに応答する他の応答フレーム中の前記パラメータを用いて特定したオペレーティングシステムに応じて、前記対象ＩＰアドレスに宛てた前記送信フレームを送信する周期を更新する
ことを特徴とする請求項５に記載の検知装置。
【請求項７】
前記制御部は、前記送信フレームを送信する周期を、前記特定したオペレーティングシステムが通信履歴を更新する時間間隔以下の周期に設定する
ことを特徴とする請求項１〜６のいずれか１項に記載の検知装置。
【請求項８】
ネットワーク中で使用されている１つ以上の通信装置の各々に、当該通信装置が使用しているオペレーティングシステムの種類に対応付けられたパラメータを含む応答フレームの送信を要求する要求フレームを送信し、
受信した前記応答フレームから特定したオペレーティングシステムに応じた周期で、前記応答フレームの送信元に送信フレームを送信し、
前記１つ以上の通信装置のいずれかからのアクセスに含まれるマルウェアを検知する
処理をコンピュータが実行することを特徴とする検知方法。
【請求項９】
ネットワーク中で使用されている１つ以上の通信装置の各々に、当該通信装置が使用しているオペレーティングシステムの種類に対応付けられたパラメータを含む応答フレームの送信を要求する要求フレームを送信し、
受信した前記応答フレームから特定したオペレーティングシステムに応じた周期で、前記応答フレームの送信元に送信フレームを送信し、
前記１つ以上の通信装置のいずれかからのアクセスに含まれるマルウェアを検知する
処理をコンピュータに実行させることを特徴とする検知プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書は、検知装置、検知方法、および、検知プログラムに関する。
【背景技術】
【０００２】
近年、機械の制御や管理等のために工場内で利用される端末へのマルウェアの感染が問題になっている。また、マルウェアの感染に起因して端末の利用が妨げられたことによって、生産ラインが停止するケースも発生している。このため、工場でマルウェア感染への対策を行うことが求められている。しかし、工場では管理対象の機械との関係などから、既知の脆弱性が残っている端末が使用されることもある。また、工場内の作業者によって、セキュリティ対策の施されていない外部端末やＵＳＢ（Universal Serial Bus）がネットワークに接続されることもあり得る。このため、外部端末やＵＳＢの接続に起因して、工場内の端末がマルウェアに感染（１次感染）することを防ぐことは難しい。
【０００３】
ここで、ワーム型のマルウェア（ワーム）は、ネットワーク中の端末に感染した後で、自身を複製してネットワーク内の他の端末にも感染（２次感染）することで被害を拡大する。このため、ワームの２次感染の発生を早い段階で検知することにより、被害の拡大を防ぐことが考えられる。例えば、到達可能かつ未使用のアドレス空間をなすダークネット宛ての信号の送信元アドレスが、監視対象の通信ネットワークで使用されたアドレスである場合に、アラートを出力する監視システムが提案されている（例えば、特許文献１）。
【０００４】
しかし、ワームの中には、１次感染した端末のＡＲＰ（Address Resolution Protocol）テーブルなどを用いることにより、１次感染した端末と通信実績のある通信装置に感染拡大先を限定するものもある。このようなワーム型マルウェアは、未使用のアドレスを監視する方法では検出されない。
【０００５】
図１は、ワームの検知例を説明する図である。ネットワーク中には、検知装置１０の他に、端末２ａ〜２ｄ、ルータ５が接続しているとする。端末２には、例えば、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）に対応していないアクチュエータ１ａ〜１ｃが接続していても良い。また、ルータ５を介してタブレット６が通信を行っても良い。
【０００６】
検知装置１０は、ネットワークに接続している端末２ａ〜２ｄ、ルータ５などの各装置に対して１秒ごとなどの短い周期で定期的にアクセスすることにより、ネットワーク中の各装置との間の通信実績を維持する（矢印Ａ１）。図１の例では、検知装置１０に割り当てられたＩＰアドレスは１９２．１６８．１０．５０であり、ＭＡＣ（Media Access Control）アドレスはＡＡ：ＢＢ：ＣＣ：ＤＤ：ＥＥ：ＦＦであるとする。矢印Ａ１に示す通信により、端末２ａ〜２ｄ、ルータ５のいずれも、検知装置１０のＩＰアドレスとＭＡＣアドレスをＡＲＰテーブルに記録する。図１の例では、端末２ａはＡＲＰテーブル４ａを保持し、端末２ｂはＡＲＰテーブル４ｂを保持しているとする。さらに、端末２ｃはＡＲＰテーブル４ｃを保持し、端末２ｄはＡＲＰテーブル４ｄを保持する。同様に、ルータ５はＡＲＰテーブル４ｅを有するものとする。
【０００７】
その後、端末２ｄがワーム７に１次感染したとする。ワーム７は、端末２ｄが保持するＡＲＰテーブル４ｄを参照することにより、ＡＲＰテーブル４ｄにアドレスが記録されている装置に対してアクセスする。図１の例では、ＡＲＰテーブル４ｄには、端末２ｂのアドレス情報（ＩＰアドレス＝１９２．１６８．１０．２３、ＭＡＣアドレス＝ＣＣ：ＤＤ：ＥＥ：ＦＦ：００：１１）と検知装置１０のアドレス情報が記録されている。このため、端末２ｄから検知装置１０と端末２ｂに対してワーム７の感染拡大の原因となるアクセスが行われる（矢印Ａ２、Ａ３）。端末２ｄから検知装置１０へのアクセスにより、検知装置１０は、ワーム７を検知することができる（Ａ４）。なお、図１では、端末２ｄがワーム７に感染した場合を例としたが、ネットワーク中の通信装置のいずれも検知装置１０の情報をＡＲＰテーブル４に保持しているので、いずれの装置がワーム７に感染した場合にも、検知装置１０は同様の処理によってワーム７の２次感染を検知できる。
【０００８】
関連する技術として、ＡＲＰリクエストに対するリプライ中のＭＡＣアドレスを用いて、リプライを送信した端末を所定のＶＬＡＮ（Virtual Local Area Network）に収容するシステムが提案されている（例えば特許文献２）。ＡＲＰ応答パケットの数量がＡＲＰ要求パケットの数量と同じ場合に、ＡＲＰ応答パケット中のＩＰアドレスとＭＡＣアドレスの間の対応関係を記録する装置も知られている（例えば、特許文献３）。この装置は、ＡＲＰデータパケット中の送信元ＩＰアドレスと送信元ＭＡＣアドレスが記録されたものと異なる場合に早期警告を行う。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２０１０−１６１４８８号公報
【特許文献２】特開２０１０−１３６０１４号公報
【特許文献３】特開２００９−１７５６２号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
通信実績を維持するために検知装置が短い周期で監視対象の装置との間で通信を行うと、ネットワークの負荷が増大してしまう。しかし、検知装置と監視対象の装置の間の通信の頻度が低いと、監視対象の装置が検知装置の情報を保持していない間にワームに感染してしまい、ワームの検出に失敗する可能性がある。関連する技術として述べた方法を用いても、ワームの検知を行うために発生する通信を削減することは困難である。
【００１１】
本発明は、１つの側面として、ワームの検知のために発生するネットワーク負荷を軽減することを目的とする。
【課題を解決するための手段】
【００１２】
ある１つの態様にかかる検知装置は、送信部、制御部、および、検知部を備える。送信部は、ネットワーク中で使用されている１つ以上の通信装置の各々に、当該通信装置が使用しているオペレーティングシステムの種類に対応付けられたパラメータを含む応答フレームの送信を要求する要求フレームを送信する。制御部は、受信した前記応答フレームから特定したオペレーティングシステムに応じた周期で、前記応答フレームの送信元に送信フレームを送信するための制御を行う。検知部は、前記１つ以上の通信装置のいずれかからのアクセスに含まれるマルウェアを検知する。
【発明の効果】
【００１３】
ワームの検知のために発生するネットワーク負荷を軽減できる。
【図面の簡単な説明】
【００１４】
【図１】ワームの検知例を説明する図である。
【図２】実施形態にかかる検知方法の例を説明する図である。
【図３】検知装置の構成の例を説明する図である。
【図４】検知装置のハードウェア構成の例を説明する図である。
【図５】ＰＩＮＧフレームの構成例を説明する図である
【図６】タイマ設定値テーブルの例を説明する図である。
【図７】タイマテーブルの例を説明する図である。
【図８】第１の実施形態にかかる検知方法の例を説明する図である。
【図９】第１の実施形態にかかる検知方法の例を説明するフローチャートである。
【図１０】ステートの設定方法の例を説明する図である。
【図１１】ステートの設定方法の例を説明する図である。
【図１２】端末の差し替えが発生した際に行われる処理の例を説明する図である。
【図１３】新たに端末が追加された際に行われる処理の例を説明する図である。
【図１４】第２の実施形態にかかる検知方法の例を説明するフローチャートである。
【図１５】新たに端末が追加された際に行われる処理の例を説明する図である。
【図１６】端末が変更された際に行われる処理の例を説明する図である。
【図１７】第３の実施形態にかかる検知方法の例を説明するフローチャートである。
【発明を実施するための形態】
【００１５】
図２は、実施形態にかかる検知方法の例を説明する図である。図２では、ネットワーク中に、検知装置２０、端末２ａ〜２ｄ、および、ルータ５が含まれているとする。さらに、ＴＣＰ／ＩＰに対応していないアクチュエータ１ａ、１ｂが端末２ａに接続しており、アクチュエータ１ｃが端末２ｂに接続している。また、ルータ５を介してタブレット６が通信を行っているとする。なお、端末２ａ〜２ｄに含まれる装置の種類は同じであっても異なっていても良い。例えば、端末２ａと端末２ｂは、アクチュエータ１を制御するための機械制御装置（Programmable Logic Controller、ＰＬＣ）であっても良い。また、端末２ｃと端末２ｄは、工場での生産状況等の管理に用いられる生産管理装置（Human Machin Interface、ＨＭＩ）であっても良い。なお、図２に示すネットワークは一例であり、ネットワーク中の端末２およびルータ５の数や種類は実装に応じて変更され得る。さらに、端末２やルータ５に接続する装置の数や種類も、実装に応じて任意に変更され得る。
【００１６】
検知装置２０は、ネットワーク中の装置のうちでＩＰプロトコルを用いて通信可能な装置である端末２ａ〜２ｄとルータ５の各々に、要求フレームを送信する（矢印Ａ１１）。ここで、要求フレームは、要求フレームの宛先の装置に対して、その装置が使用しているオペレーティングシステム（Operating System、ＯＳ）の種類に対応付けられたパラメータを含む応答フレームの送信を要求するフレームである。ＯＳの種類に対応付けられたパラメータは、例えば、ＩＰヘッダ中のＴＴＬ（Time to live）の値などであっても良い。図２の例において、ＡというＯＳを示すパラメータはαであるとする。同様に、ＢというＯＳを示すパラメータはβであり、ＣというＯＳを示すパラメータはγであるとする。
【００１７】
図２の例では、端末２ａは、要求フレームを受信すると、パラメータ＝βを含む応答フレームを検知装置２０に送信する（矢印Ａ１２）。また、端末２ｂ〜２ｄは、要求フレームを受信すると、パラメータ＝αを含む応答フレームを検知装置２０に送信する（矢印Ａ１３〜Ａ１５）。さらに、ルータ５は、要求フレームを受信すると、パラメータ＝γを含む応答フレームを検知装置２０に送信する（矢印Ａ１６）。
【００１８】
検知装置２０は、要求フレームの送信先の各装置から受信した応答フレーム中のパラメータを用いて、各装置で使用されているＯＳの種類を特定する。図２の例では、端末２ａからの応答フレームにパラメータ＝βが含まれているので、検知装置２０は、端末２ａで使用されているＯＳはＢであると判定する。同様に、端末２ｂ〜２ｄから受信した応答フレームにパラメータ＝αが含まれているので、検知装置２０は、端末２ｂ〜２ｄで使用されているＯＳはＡであると判定する。さらに、ルータ５からの応答フレームにパラメータ＝γが含まれているので、検知装置２０は、ルータ５で使用されているＯＳはＣであると判定する。
【００１９】
検知装置２０は、予め、ネットワーク中の装置が使用する可能性のあるＯＳの各々について、そのＯＳが通信履歴を保持する期間についての情報を認識しているとする。例えば、ＡというＯＳは、ｘ秒間にわたって使用されていない通信先に関するエントリを通信履歴から削除するとする。同様に、ＯＳ＝Ｂはｙ秒間にわたって使用されていない通信先に関するエントリを通信履歴から削除し、ＯＳ＝Ｃはｚ秒間にわたって使用されていない通信先に関するエントリを通信履歴から削除するものとする。
【００２０】
検知装置２０は、各装置に対して、その装置が使用するＯＳが通信履歴を削除する周期以下の時間間隔で、定期的に送信フレームを送信する。例えば、端末２ａではＯＳ＝Ｂが使用されているので、端末２ａではｙ秒間以上にわたって検知装置２０が端末２ａに通信しないと、検知装置２０との間の通信履歴が消去される。そこで、検知装置２０は、端末２ａに対して、要求フレームの送信からｙ秒後にフレームを送信することを決定する。さらにその後も、検知装置２０は、ｙ秒おきに端末２ａに対してフレームを送信する。
【００２１】
同様に、端末２ｂ〜２ｄではＯＳ＝Ａが使用されているので、検知装置２０は、端末２ｂ〜２ｄに対して、要求フレームの送信からｘ秒後にフレームを送信することを決定する。その後も、検知装置２０は、ｘ秒ごとに端末２ｂ〜２ｄにフレームを送信する。ルータ５ではＯＳ＝Ｃが使用されているので、検知装置２０は、要求フレームの送信からｚ秒後に、ルータ５にフレームを送信することを決定し、その後も、ｚ秒ごとにルータ５にフレームを送信する。
【００２２】
以上の処理により、検知装置２０との間の通信履歴は、端末２ａ〜２ｄ、および、ルータ５のいずれにおいても維持される。このため、端末２ａ〜２ｄ、ルータ５のいずれかがワーム型マルウェア（ワーム７）に感染した場合に、検知装置２０に対してワーム７を感染させるためのアクセスが行われる。従って、検知装置２０は、ワーム７の２次感染の発生を検知できる。
【００２３】
実施形態にかかる検知装置２０は、ネットワーク中の各装置が使用するＯＳで通信履歴が削除されるタイミングに合わせて、フレームを送信することで、各装置との間の通信実績を維持する。このため、検知装置２０は、検知装置２０とネットワーク中の各装置との間の通信実績を維持するためのフレームの送信を効率化して、送信するフレーム数を削減することにより、通信量を削減することができる。従って、検知装置２０を用いることにより、ワーム７の検知を行うために発生する通信量を削減しつつ、ワーム７の２次感染を検知することができる。
【００２４】
＜装置構成＞
図３は、検知装置２０の構成の例を説明する図である。検知装置２０は、通信部２１、制御部３０、記憶部４０を備える。
【００２５】
通信部２１は、送信部２２と受信部２３を有する。送信部２２は、端末２やルータ５などのネットワーク中の他の装置にフレームを送信する。受信部２３は、端末２やルータ５などのネットワーク中の他の装置からフレームを受信する。
【００２６】
制御部３０は、生成処理部３１、ＯＳ特定部３２、および、検知部３４を有し、さらにオプションとして、ステート更新処理部３３を含むことができる。生成処理部３１は、要求フレームや通信実績の維持のために送信する送信フレームなどのフレームを生成する。ＯＳ特定部３２は、応答フレームに含まれているパラメータの値を用いて、応答フレームの送信元で使用されているＯＳの種類を特定する。さらに、ＯＳ特定部３２は、タイマ設定値テーブル４１を参照することにより、特定したＯＳに応じて、応答フレームの送信元に次にフレームを送信するまでの待機時間を決定する。ステート更新処理部３３は、検知処理の対象のネットワークに接続している端末２などに対して、ステートの設定や変更を行う。ステートは、ネットワークに接続している端末などの装置に対して、検知装置２０が認識している情報の種類に対応して設定される。ステート更新処理部３３は、各装置について設定されている最新のステートをステート情報４４に記録する。検知部３４は、ネットワーク中の装置からのアクセスに含まれるワーム型マルウェアなどのマルウェアを検知する。
【００２７】
記憶部４０は、タイマ設定値テーブル４１、タイマテーブル４２、および、ＡＲＰテーブル４３を備え、さらに、オプションとしてステート情報４４を備える。タイマ設定値テーブル４１は、検知装置２０が送信フレームを次に送信するまでの待機時間を、送信フレームの宛先が使用するＯＳの種類に対応付けて記録する。タイマテーブル４２は、検知装置２０が送信フレームを送信するまでの残り時間を管理する。例えば、ＯＳ特定部３２は、応答フレームを受信した端末２などに対してタイマ設定値テーブル４１を用いて特定した待機時間をタイマテーブル４２に記録する。タイマテーブル４２は、時間の経過と共に設定されている待機時間の値を減算する。このため、タイマテーブル４２に格納されている待機時間が０となった端末２などに対して、フレームの送信処理が行われる。タイマ設定値テーブル４１やタイマテーブル４２の例は後述する。
【００２８】
ＡＲＰテーブル４３は、検知装置２０との通信実績を有する装置に割り当てられているＩＰアドレスとＭＡＣアドレスの組み合わせを記録する。ステート情報４４は、検知対象となっているネットワーク中の各装置に対して、ステート更新処理部３３によって設定されたステートなどの情報を記録する。
【００２９】
図４は、検知装置２０のハードウェア構成の例を説明する図である。検知装置２０は、プロセッサ１０１、メモリ１０２、バス１０３、ネットワーク接続装置１０４を有する。プロセッサ１０１は、任意の処理回路であり、例えば、ＣＰＵ（Central Processing Unit）とすることができる。プロセッサ１０１は、メモリ１０２をワーキングメモリとして使用して、プログラムを実行することにより、様々な処理を実行する。メモリ１０２には、ＲＡＭ（Random Access Memory）が含まれ、さらに、ＲＯＭ（Read Only Memory）等の不揮発性のメモリも含まれる。メモリ１０２は、プログラムやプロセッサ１０１での処理に使用されるデータを格納する。ネットワーク接続装置１０４は、ネットワークを介した他の装置との通信に使用される。バス１０３は、プロセッサ１０１、メモリ１０２、ネットワーク接続装置１０４を、互いにデータの入出力が可能になるように接続する。
【００３０】
検知装置２０において、制御部３０はプロセッサ１０１によって実現される。通信部２１は、ネットワーク接続装置１０４によって実現される。さらに、記憶部４０は、メモリ１０２により実現される。検知装置２０は、コンピュータ、ゲートウェイ装置、ルータ、Ｌ３スイッチなどとして実現され得る。
【００３１】
＜要求フレームと検知装置が保持する情報の例＞
以下、検知装置２０からネットワーク中の装置に送信される要求フレームとしてＰＩＮＧリクエストが使用される場合を例として説明する。要求フレームとしてＰＩＮＧリクエストが使用される場合、応答フレームはＰＩＮＧリプライである。また、応答フレーム中のＯＳの種類に対応付けられたパラメータとして、ＰＩＮＧリプライ中のＴＴＬ（Time to live）値が使用される。
【００３２】
図５は、ＰＩＮＧフレームの構成例を説明する図である。なお、図５に示すＰＩＮＧフレームは、ＰＩＮＧフレームに含まれている情報要素の一部を示している。ＰＩＮＧフレームは、イーサネット（登録商標）フレーム中のイーサネットヘッダに、送信元ＭＡＣアドレス（Ｓｏｕｒｃｅ  ＭＡＣ）と宛先ＭＡＣアドレス（Ｄｅｓｔｉｎａｔｉｏｎ  ＭＡＣ）を含む。イーサネットフレーム中のＩＰフレームには、ＩＰヘッダとＩＣＭＰ（Internet Control Message Protocol）メッセージが含まれている。ＩＰヘッダには、ＴＴＬ、送信元ＩＰアドレス（Ｓｏｕｒｃｅ  ＩＰ）、および、宛先ＩＰアドレス（Ｄｅｓｔｉｎａｔｉｏｎ  ＩＰ）が含まれている。ＩＣＭＰメッセージには、タイプ、コード、データが含まれる。ＩＣＭＰメッセージ中のタイプはＩＣＭＰメッセージ中の機能タイプを示す値である。コードは、ＩＣＭＰメッセージの機能コードを表わす。
【００３３】
なお、以下の説明では、ＰＩＮＧリクエストが要求フレームとして使用されている場合を例とするが、要求フレームは、ＰＩＮＧリクエストに限られない。例えば、ＩＰヘッダ中のＴＴＬを含む任意のフレームが要求フレームとして使用され得る。また、ＴＴＬ以外の値がＯＳの種類に対応付けられたパラメータとして用いられる場合、そのパラメータを含む任意のフレームの送信を要求するフレームが要求フレームとして使用され得る。
【００３４】
図６は、タイマ設定値テーブル４１の例を説明する図である。タイマ設定値テーブル４１には、ＯＳの種類に対応付けて、各ＯＳで採用されるＴＴＬ値、および、タイマ設定値が含まれる。タイマ設定値は、ＯＳ特定部３２が待機時間の初期値としてタイマテーブル４２に設定する値である。タイマ設定値は、各ＯＳでのＡＲＰテーブルのエントリの保持時間のデフォルト値以下になるように設定されている。
【００３５】
例えば、Ｗｉｎｄｏｗｓ系のＯＳでは、ＡＲＰテーブルにエントリが保持される期間のデフォルト値は１５〜４５秒であるか２分である。このため、図６の例では、Ｗｉｎｄｏｗｓ系のＯＳを用いている装置に対するタイマ設定値は１５秒に設定されている。また、Ｗｉｎｄｏｗｓ系のＯＳでのＴＴＬ値が１２８であることも、Ｗｉｎｄｏｗｓ系のＯＳに対応付けてタイマ設定値テーブル４１に記録される。
【００３６】
一方、Ｌｉｎｕｘ（登録商標）系のＯＳでは、ＡＲＰテーブルにエントリが保持される期間のデフォルト値は１秒である。このため、図６では、Ｌｉｎｕｘ系のＯＳを用いている装置に対するタイマ設定値は１秒に設定されている。また、Ｌｉｎｕｘ系のＯＳでのＴＴＬ値＝６４もタイマ設定値テーブル４１に記録される。
【００３７】
同様に、ルータ５などのネットワーク機器では、ＡＲＰテーブルにエントリが保持される期間のデフォルト値は２０分程度である。このため、図６では、ネットワーク機器に対するタイマ設定値は１２００秒に設定される。また、ネットワーク機器が指定するＴＴＬ値＝２５５もタイマ設定値テーブル４１に記録される。
【００３８】
図７は、タイマテーブル４２の例を説明する図である。タイマテーブル４２は、装置のＩＰアドレスに対応付けて、タイマ満了までの残り時間を記録する。ここで、タイマ満了までの残り時間は、エントリ中のＩＰアドレスを使用している装置へ次の送信フレームを送信するまでの時間である。タイマテーブル４２−１では、ＩＰアドレス＝１９２．１６８．１０．２３の装置に対するタイマ満了までの残り時間が１５秒であり、ＩＰアドレス＝１９２．１６８．１０．２４の装置に対するタイマ満了までの残り時間が１２００秒である。例えば、タイマテーブル４２−１が得られた１０秒後にＩＰアドレス＝１９２．１６８．１０．２２の装置からＰＩＮＧリプライが得られたとする。また、ＯＳ特定部３２は、ＩＰアドレス＝１９２．１６８．１０．２２の装置で使用されているＯＳに対応付けられたタイマ設定値が１秒であると認識したとする。すると、ＯＳ特定部３２は、タイマテーブル４２−２に示すように、ＩＰアドレス＝１９２．１６８．１０．２２の装置に対するタイマ満了までの残り時間を１秒に設定する。なお、タイマテーブル４２−２は、タイマテーブル４２−１の状態が観測されてから１０秒後の状態を示しているので、ＩＰアドレス＝１９２．１６８．１０．２３の装置に対するタイマ満了までの残り時間はタイマテーブル４２−２では５秒である。同様に、ＩＰアドレス＝１９２．１６８．１０．２４の装置に対するタイマ満了までの残り時間はタイマテーブル４２−２では１１９０秒である。
【００３９】
＜第１の実施形態＞
第１の実施形態では、検知装置２０がステート更新処理部３３とステート情報４４を備えていない場合に行われる処理の例を説明する。
【００４０】
工場などで使用されるネットワークでは、接続している装置の情報が管理されておらず、どのＩＰアドレスをどの装置が使用しているかが把握されていないことが多い。そこで、以下では、検知装置２０がネットワークに接続している端末２やルータ５などの装置の情報を保持していない場合に、検知装置２０が行う処理の例を説明する。なお、検知装置２０は、ネットワークに接続している装置の情報を記憶していないが、ネットワークで使用され得るＩＰアドレスの範囲を記憶部４０に記憶しているものとする。
【００４１】
検知装置２０は検知対象のネットワーク中の装置が使用しているＩＰアドレスの情報を保持していないので、要求フレームの送信先を認識していない。そこで、検知装置２０の生成処理部３１は、ネットワークで使用され得るＩＰアドレス範囲に含まれる各々のＩＰアドレスについて、ＡＲＰリクエストを生成する。生成処理部３１は、生成したＡＲＰリクエストの各々を、送信部２２を介して送信する。自装置が使用しているＩＰアドレスを含むＡＲＰリクエストを受信した装置は、検知装置２０に対してＡＲＰリプライを送信する。
【００４２】
受信部２３は、ＡＲＰリプライを受信する。ＯＳ特定部３２は、受信したＡＲＰリプライの送信元のＩＰアドレスとＭＡＣアドレスをＡＲＰテーブル４３に記録する。ＡＲＰテーブル４３が更新されると、生成処理部３１は、ＡＲＰテーブル４３にＩＰアドレスとＭＡＣアドレスの組み合わせが記録されている装置の各々に宛てて、ＰＩＮＧリクエストを生成する。
【００４３】
図８は、第１の実施形態にかかる検知方法の例を説明する図である。図８の例では、端末２ａはＬｉｎｕｘ系のＯＳを使用しており、端末２ｂ〜２ｄはＷｉｎｄｏｗｓ系のＯＳを使用しているとする。また、端末２ａ〜２ｄ、ルータ５の各々が検知装置２０にＡＲＰリプライを送信しているとする。すると、検知装置２０の生成処理部３１は、端末２ａ〜２ｄ、ルータ５の各々に宛てたＰＩＮＧリクエストを生成し、送信部２２を介して送信する（矢印Ａ２１）。
【００４４】
端末２ａは、ＰＩＮＧリクエストを受信すると、検知装置２０に向けてＴＴＬ＝６４を含むＰＩＮＧリプライを送信する（矢印Ａ２２）。検知装置２０のＯＳ特定部３２は、端末２ａから送信されたＰＩＮＧリプライを、受信部２３を介して取得する。ＯＳ特定部３２は、端末２ａが送信したＰＩＮＧリプライにＴＴＬ＝６４が含まれているため、タイマ設定値テーブル４１（図６）を用いて、端末２ａで使用されているＯＳがＬｉｎｕｘ系のＯＳであると判定する。さらに、ＯＳ特定部３２は、Ｌｉｎｕｘ系のＯＳに対応付けられたタイマ設定値が１秒であるため、端末２ａには、前回のＰＩＮＧリクエストの送信の１秒後にＰＩＮＧリクエストを送信することを決定する。ＯＳ特定部３２は、端末２ａが使用しているＩＰアドレスに対応付けて、タイマ満了までの時間としてタイマ設定値である１秒をタイマテーブル４２に記録する。
【００４５】
端末２ｂは、ＰＩＮＧリクエストを受信すると、検知装置２０に向けてＴＴＬ＝１２８を含むＰＩＮＧリプライを送信する（矢印Ａ２３）。検知装置２０のＯＳ特定部３２は、端末２ｂから送信されたＰＩＮＧリプライを、受信部２３を介して取得する。ＯＳ特定部３２は、端末２ｂが送信したＰＩＮＧリプライにＴＴＬ＝１２８が含まれているため、タイマ設定値テーブル４１（図６）を用いて、端末２ｂで使用されているＯＳがＷｉｎｄｏｗｓ系のＯＳであると判定する。さらに、ＯＳ特定部３２は、Ｗｉｎｄｏｗｓ系のＯＳに対応付けられたタイマ設定値が１５秒であるため、端末２ｂには、前回のＰＩＮＧリクエストの送信の１５秒後にＰＩＮＧリクエストを送信することを決定する。ＯＳ特定部３２は、端末２ｂが使用しているＩＰアドレスに対応付けて、タイマ満了までの時間としてタイマ設定値である１５秒をタイマテーブル４２に記録する。
【００４６】
端末２ｃおよび端末２ｄも、端末２ｂと同様に、ＴＴＬ＝１２８を含むＰＩＮＧリプライを検知装置２０に送信する（矢印Ａ２４、Ａ２５）。このため、端末２ｂから受信したＰＩＮＧリプライに対する処理と同様の処理により、ＯＳ特定部３２は、端末２ｃおよび端末２ｄが使用しているＩＰアドレスに対応付けて、タイマ満了までの時間として１５秒をタイマテーブル４２に記録する。
【００４７】
ルータ５は、ＰＩＮＧリクエストを受信すると、検知装置２０に向けてＴＴＬ＝２５５を含むＰＩＮＧリプライを送信する（矢印Ａ２６）。検知装置２０のＯＳ特定部３２は、ルータ５から送信されたＰＩＮＧリプライを、受信部２３を介して取得する。ＯＳ特定部３２は、ルータ５が送信したＰＩＮＧリプライにＴＴＬ＝２５５が含まれているため、タイマ設定値テーブル４１（図６）を用いて、ルータ５がネットワーク機器であると判定する。さらに、ＯＳ特定部３２は、ネットワーク機器に対応付けられたタイマ設定値が１２００秒であるため、ルータ５には、前回のＰＩＮＧリクエストの送信の１２００秒後にＰＩＮＧリクエストを送信することを決定する。ＯＳ特定部３２は、ルータ５が使用しているＩＰアドレスに対応付けて、タイマ満了までの時間としてタイマ設定値である１２００秒をタイマテーブル４２に記録する。
【００４８】
検知装置２０の生成処理部３１は、タイマテーブル４２をモニタしており、タイマ満了までの残り時間が０秒になったＩＰアドレスに宛てたＰＩＮＧリクエストを生成する。送信部２２は、生成されたＰＩＮＧリクエストを送信する。このため、図８の例では、検知装置２０は、端末２ａに対して１秒ごとにＰＩＮＧリクエストを送信することになる。同様に、検知装置２０は、端末２ｂ〜２ｄに対しては１５秒ごとにＰＩＮＧリクエストを送信し、ルータ５に対しては１２００秒ごとにＰＩＮＧリクエストを送信する。２回目以降に送信されたＰＩＮＧリクエストに応答するＰＩＮＧリプライを受信したときの検知装置２０の処理は、１回目のＰＩＮＧリプライの受信の際と同様である。
【００４９】
図９は、第１の実施形態にかかる検知方法の例を説明するフローチャートである。なお、図９の処理が行われる時点では、ＡＲＰリクエストの送信とＡＲＰリプライの受信により、検知装置２０が保持するＡＲＰテーブル４３に監視対象の装置が使用しているＩＰアドレス（処理対象のＩＰアドレス）が記録されているものとする。また、図９の例では、検知装置２０は図６に示すタイマ設定値テーブル４１を保持しているとする。
【００５０】
生成処理部３１は、送信部２２を用いて、処理対象のＩＰアドレスにＰＩＮＧリクエストを送信する（ステップＳ１）。ＯＳ特定部３２は、ＰＩＮＧリクエストの送信からタイムアウトが発生するまでの間にＰＩＮＧリプライを受信したかを判定する（ステップＳ２）。ＰＩＮＧリプライを受信した場合、ＯＳ特定部３２は、ＰＩＮＧリプライ中のＴＴＬを参照して、ＰＩＮＧリプライの送信元で使用されているＯＳを特定する（ステップＳ２でＹｅｓ、ステップＳ３）。その後、生成処理部３１は、特定されたＯＳに対応付けられたタイマ設定値の間にわたって待機し、ステップＳ１に戻る（ステップＳ３）。なお、ステップＳ３において、特定されたＯＳに対応付けられたタイマ設定値は、タイマ設定値テーブル４１から取得される。
【００５１】
一方、ＰＩＮＧリクエストの送信先において、セキュリティ上の理由などからＰＩＮＧリプライを送信しないように設定される場合がある。このような場合には、検知装置２０はＰＩＮＧリプライを受信しない（ステップＳ２でＮｏ）。所定期間内にＰＩＮＧリプライを受信しない場合、ＯＳ特定部３２は、ＰＩＮＧリクエストの送信先がＡＲＰテーブル中のエントリの保持時間が最短のＯＳを使用していると仮定する。この仮定は、ＰＩＮＧリクエストの送信先が保持しているＡＲＰテーブルに検知装置２０の情報が含まれなくなることにより、ＰＩＮＧリクエストの送信先からのワーム７の２次感染を見落とすことを防ぐために行われる。図６に示すタイマ設定値テーブル４１では、Ｌｉｎｕｘ系のＯＳが使用されている場合にタイマ設定値が最小値をとる。そこで、ＯＳ特定部３２は、Ｌｉｎｕｘに対応付けられたタイマ設定値の間にわたって待機し、ステップＳ１に戻る（ステップＳ４）。
【００５２】
このように、検知装置２０は、ネットワーク中の各装置で用いているＯＳの種類に応じて、端末２などが保持するＡＲＰテーブル４から検知装置２０のアドレス情報が削除される前に、端末２などに再度ＰＩＮＧリクエストを送信する。このため、ネットワーク中の装置からのワーム７の２次感染を検知できる。一方、検知装置２０は、ＯＳの種類を特定することによって、ネットワーク中の装置のＡＲＰテーブル４に検知装置２０のアドレス情報が保持されている間は、その装置に対するフレームの送信を控えることができる。このため、検知装置２０からネットワーク中の各装置への無駄なフレームの送信を防いで、通信量を削減することができる。
【００５３】
例えば、ネットワーク中の２５０台の装置との間で通信実績を維持するために使用される通信量を計算してみる。ここで、ネットワーク中の２５０台の装置のうち、２５台がＬｉｎｕｘ系のＯＳを使用し、残りの２２５台がＷｉｎｄｏｗｓ系のＯＳを使用しているとする。実施形態にかかる検知装置２０を用いない場合、ネットワーク中の装置が使用しているＯＳに関わらず、全ての装置に対して、１秒ごとにＰＩＮＧリクエストを送信することができる。この場合、ＰＩＮＧリクエスト（７４バイト）の送信の前にＡＲＰリクエスト（４２バイト）も送信されるとすると、１秒あたりの通信量は、２５０×（７４＋４２）＝２９０００バイトとなる。１秒ごとにＡＲＰリクエストだけを２５０台の装置に送信したとしても、１秒あたりの通信量は、２５０×４２＝１０５００バイトとなる。一方、第１の実施形態によると、ＰＩＮＧリクエスト（７４バイト）の送信の前にＡＲＰリクエスト（４２バイト）も送信されると仮定したとしても、１秒あたりの通信量は、２５×（７４＋４２）＋２２５×１／１５×（７４＋４２）＝４６４０バイトですむ。従って、検知装置２０を用いることにより、ワーム７の検知を行うために発生する通信量を削減しつつ、ワーム７の２次感染を検知することができる。
【００５４】
第１の実施形態に示すように、検知装置２０のエントリがＡＲＰテーブル４から削除されるタイミングに合わせてＰＩＮＧリクエストを送信する場合、ネットワークに接続されている装置が変更されても、装置の変更に応じてフレームの送信周期が変更される。例えば、時刻Ｔ１の時点では、端末２ｂが１９２．１６８．１０．２３というＩＰアドレスを使用していたとする。その後、端末２ｂがネットワークから切断され、端末２ｂの代わりにルータ５ａ（図示せず）が接続され、１９２．１６８．１０．２３というアドレスの使用を開始したとする。この場合に、時刻Ｔ１から１５秒後に検知装置２０がＰＩＮＧリクエストを送信すると、ルータ５ａがＰＩＮＧリクエストを受信する。ルータ５ａは、ＴＴＬ＝２５５を含むＰＩＮＧリプライを検知装置２０に送信するので、検知装置２０のＯＳ特定部３２では、ＩＰアドレス＝１９２．１６８．１０．２３を用いている装置はネットワーク機器であると認識できる。このため、ＯＳ特定部３２は、ＩＰアドレス＝１９２．１６８．１０．２３宛ての次回のＰＩＮＧリクエストを、前回のＰＩＮＧリクエストの送信の１２００秒後に設定できる。
【００５５】
このように、検知装置２０は、ＰＩＮＧリプライの送信のたびに、ＰＩＮＧリプライの送信元が使用しているＯＳを特定して、特定したＯＳに応じた頻度でフレームを送信するので、ネットワーク中の各装置への無駄なフレームの送信を削減できる。
【００５６】
＜第２の実施形態＞
第２の実施形態では、検知装置２０は、ステート更新処理部３３とステート情報４４を備えているものとする。第２の実施形態でも検知装置２０は図６に示すタイマ設定値テーブル４１を保持しているとする。さらに、第２の実施形態でも、要求フレームとしてＰＩＮＧリクエストが使用され、ＯＳの種類に対応付けられたパラメータとしてＴＴＬ値が使用されるものとする。
【００５７】
ステート更新処理部３３は、ネットワーク中で使用され得る個々のＩＰアドレスに対して、そのＩＰアドレスを使用している装置について検知装置２０が認識している情報量に応じて、ステート０〜ステート３までの４段階のステートを設定する。ステート更新処理部３３は、設定したステートをステート情報４４に記録する。
【００５８】
図１０は、ステートの設定方法の例を説明する図である。以下、図１０を参照しながら、ステートの設定例を説明する。図１０の例では、検知装置２０は、１９２．１６８．１０．５０というＩＰアドレスとＡＡ：ＢＢ：ＣＣ：ＤＤ：ＥＥ：ＦＦというＭＡＣアドレスを使用している。また、ネットワークには、端末２ａ、端末２ｂ、端末２ｄ、ルータ５が接続しているとする。端末２ａが使用するアドレスは、ＩＰアドレス＝１９２．１６８．１０．２２、ＭＡＣアドレス＝００：１１：２２：３３：４４：５５である。端末２ｂが使用するアドレスは、ＩＰアドレス＝１９２．１６８．１０．２３、ＭＡＣアドレス＝ＣＣ：ＤＤ：ＥＥ：ＦＦ：００：１１である。端末２ｄが使用するアドレスは、ＩＰアドレス＝１９２．１６８．１０．２６、ＭＡＣアドレス＝２２：３３：４４：５５：６６：７７である。さらに、ルータ５が使用するアドレスは、ＩＰアドレス＝１９２．１６８．１０．２５、ＭＡＣアドレス＝３３：４４：５５：６６：７７：８８である。なお、第２の実施形態でも、端末２に任意の数のアクチュエータ１などが接続でき、ルータ５にも任意の数のタブレット６などの装置が接続できるものとする。
【００５９】
ステート情報４４−１は、起動時に検知装置２０が保持するステート情報４４の例である。ステート情報４４−１は、ＩＰアドレス（ＩＰ  ａｄｄｒ．）、ＭＡＣアドレス（ＭＡＣ  ａｄｄｒ．）、ＯＳ、および、ステートを含む。ステート更新処理部３３は、検知装置２０がＡＲＰリクエストを送信したことのないＩＰアドレスに対して、ステート０を設定する。このため、起動時には、ネットワーク中で使用され得る全てのＩＰアドレスについて、ステート０が設定されている。検知装置２０は、ステート０の装置と通信していないので、ステート０のＩＰアドレスがネットワーク中の装置に使用されているかも認識していない。
【００６０】
生成処理部３１は、ネットワーク中で使用され得る全てのＩＰアドレスの各々について、ＡＲＰリクエストを生成し、送信部２２を介してＡＲＰリクエストを送信する（矢印Ａ３１）。ＡＲＰリクエストが送信されると、ステート更新処理部３３は、ＡＲＰリクエストでアドレス解決の対象となっているＩＰアドレスに対してステート１を設定する。このため、矢印Ａ３１の処理が行われると、ステート情報４４中の全てのＩＰアドレスに対してステート１が設定される。ステート１の段階では、検知装置２０はＡＲＰリクエストを送信しているがＡＲＰリプライを受信していない。換言すると、装置が使用するＭＡＣアドレスとＯＳのいずれも検知装置２０が認識していないが、検知装置２０から少なくとも１回ＡＲＰリクエストを送信したことがあるＩＰアドレスに対して、ステート１が割り当てられる。このため、ステート１のＩＰアドレスは、ＡＲＰリクエストの送信時点において、端末２やルータ５などのネットワーク中の装置によって使用されていないアドレスであるか、検知装置２０が使用状況を認識していないアドレスであるといえる。
【００６１】
端末２ａは、端末２ａが使用しているＩＰアドレスに関するアドレス解決を要求するためのＡＲＰリクエストを受信する。端末２ａは、検知装置２０から送信されたＡＲＰリクエストを受信すると、端末２ａが保持するＡＲＰテーブル４ａに検知装置２０のアドレスの情報を記録する。さらに、端末２ａのＭＡＣアドレスを検知装置２０に通知するためのＡＲＰリプライを送信する（矢印Ａ３２）。検知装置２０のＯＳ特定部３２は、受信部２３を介してＡＲＰリプライを取得すると、検知装置２０が備えるＡＲＰテーブル４３に端末２ａのアドレスの情報を記録する。ステート更新処理部３３は、ＡＲＰリプライの送信元である端末２ａが使用しているＩＰアドレスにステート２を割り当てる。すなわち、ＡＲＰリクエストに応答するＡＲＰリプライの送信元であって、ＯＳの特定をまだ行っていない装置が使用するＩＰアドレスがステート２に分類される。その後、ステート更新処理部３３は、設定したステートの情報と共に、端末２ａのＭＡＣアドレスをステート情報４４に記録する。
【００６２】
端末２ｂ、端末２ｄ、ルータ５も、自装置が使用しているＩＰアドレスに関するアドレス解決のために検知装置２０から送信されたＡＲＰリクエストを受信すると、端末２ａと同様の処理を行う。このため、ＡＲＰテーブル４ｂ、４ｄ、４ｅのそれぞれに、検知装置２０のアドレスの情報が記録される。なお、端末２ｂはＡＲＰテーブル４ｂを保持し、端末２ｄはＡＲＰテーブル４ｄを保持するものとする。さらに、ルータ５はＡＲＰテーブル４ｅを保持しているとする。端末２ｂ、端末２ｄ、ルータ５の各々は、自装置が使用しているＭＡＣアドレスを検知装置２０に通知するためのＡＲＰリプライを送信する（矢印Ａ３３〜Ａ３５）。
【００６３】
検知装置２０中のＯＳ特定部３２やステート更新処理部３３がＡＲＰリプライを受信したときに行う処理は、端末２ａから送信されたＡＲＰリプライを受信したときの処理と同様である。このため、ＡＲＰリプライの受信に伴って、ステート更新処理部３３は、端末２ｂ、端末２ｄ、ルータ５の各々をステート２に設定する。設定されたステートの情報と端末２ａ、端末２ｂ、端末２ｄ、ルータ５の各々のＭＡＣアドレスがステート情報４４に記録されるため、ステート情報４４−１はステート情報４４−２に更新される。
【００６４】
図１０の例では、１９２．１６８．１０．２４というＩＰアドレスは使用されていない。このため、１９２．１６８．１０．２４に宛てたＡＲＰリクエストに対する応答は送信されない。従って、ステート情報４４−２では、ＩＰアドレス＝１９２．１６８．１０．２４にはステート１が設定されたままになっている。
【００６５】
図１１は、ステートの設定方法の例を説明する図である。図１１を参照しながら、図１０での処理の後に行われる処理を説明する。
【００６６】
生成処理部３１は、ステート１に設定されているＩＰアドレスの使用開始を検出するために、ステート１に設定されているＩＰアドレスに宛てて、定期的にＡＲＰリクエストを送信する。例えば、ステート情報４４−２ではＩＰアドレス＝１９２．１６８．１０．２４がステート１に設定されている。そこで、生成処理部３１は、ＩＰアドレス＝１９２．１６８．１０．２４のアドレス解決を要求するためのＡＲＰリクエストを所定の周期で生成し、送信部２２を介して送信する（矢印Ａ４１）。ステート１に設定されているＩＰアドレスの使用開始を検出するためのＡＲＰリクエストの送信周期は、実装に応じて設定され得る。
【００６７】
一方、ステート２に分類されているＩＰアドレスを使用する装置については、図１０を参照しながら説明した処理により、ＭＡＣアドレスがＡＲＰテーブル４３やステート情報４４に記録されている。従って、検知装置２０は、ステート２に分類されたＩＰアドレスを使用する装置と通信が可能であるが、ステート２のＩＰアドレスを使用する装置で使用されているＯＳはまだ特定していない。そこで、生成処理部３１は、ステート２に分類されたアドレスの各々を宛先としたＰＩＮＧリクエストを生成し、送信部２２を介して送信する（矢印Ａ４２）。
【００６８】
ＰＩＮＧリクエストを受信した端末２ｂは、ＰＩＮＧリプライを検知装置２０に送信する（矢印Ａ４３）。なお、この処理により端末２ｂと検知装置２０との間の通信が発生しているので、端末２ｂが備えるＡＲＰテーブル４ｂから検知装置２０のＭＡＣアドレス等の情報が削除されるまでの期間は初期値に戻る。従って、ＡＲＰテーブル４ｂには検知装置２０の情報が保持される。
【００６９】
端末２ｂからＰＩＮＧリプライを受信すると、ＯＳ特定部３２は、タイマ設定値テーブル４１を用いてＰＩＮＧリプライの送信元が使用しているＯＳの種類を特定する。ＯＳを特定するための処理は、第１の実施形態と同様である。ここでは、端末２ｂから送信されたＰＩＮＧリプライにはＴＴＬ＝１２８が含まれていたとする。すると、ＯＳ特定部３２は、端末２ｂ（１９２．１６８．１０．２３）で使用されているＯＳはＷｉｎｄｏｗｓ系のＯＳであると判定する。ステート更新処理部３３は、ＯＳが特定された装置が使用しているＩＰアドレスに、ステート３を割り当てる。さらに、ステート更新処理部３３は、特定されたＯＳの種類と変更後のステートの情報を用いて、ステート情報４４を更新する。このため、端末２ｂが用いているＩＰアドレスに関する情報は以下のようになる。
【００７０】
ＩＰアドレス      １９２．１６８．１０．２３
ＭＡＣアドレス    ＣＣ：ＤＤ：ＥＥ：ＦＦ：００：１１
ＯＳ              Ｗｉｎｄｏｗｓ
ステート          ステート３
端末２ｄおよびルータ５も、ＰＩＮＧリクエストの受信に応答してＰＩＮＧリプライを検知装置２０に送信したとする（矢印Ａ４４、Ａ４５）。また、端末２ｄおよびルータ５のいずれも、検知装置２０との通信が発生しているので検知装置２０に関するエントリをＡＲＰテーブル４中に保持する。従って、図１１に示すように、ＡＲＰテーブル４ｄ、および、ＡＲＰテーブル４ｅのいずれにおいても、検知装置２０の情報が維持される。
【００７１】
端末２ｄおよびルータ５からＰＩＮＧリプライを受信した場合にも、端末２ｂからのＰＩＮＧリプライの受信時と同様の処理が行われる。この結果、端末２ｄ（１９２．１６８．１０．２６）で使用されているＯＳはＷｉｎｄｏｗｓ系のＯＳであると判定されたとする。また、ルータ５（１９２．１６８．１０．２５）はネットワーク機器であると判定されたとする。
【００７２】
一方、端末２ａでは、ＰＩＮＧリクエストに応答しない設定が行われているとする。この場合、端末２ａはＰＩＮＧリクエストを受信してもＰＩＮＧリプライを送信しない。なお、端末２ａでも、ＰＩＮＧリクエストの受信により、端末２ａが保持するＡＲＰテーブル４ａに検知装置２０の情報が維持される。
【００７３】
ＰＩＮＧリクエストの送信から所定期間が経過してもＰＩＮＧリプライを受信しない場合、ステート更新処理部３３は、ＰＩＮＧリクエストの宛先で使用されているＯＳをタイマ設定時間が最短のＯＳであると仮定する。この仮定は、ＰＩＮＧリプライを送信しない装置が保持するＡＲＰテーブル４から検知装置２０の情報が削除される期間を作らないために行われる。ステート更新処理部３３は、タイマ設定値テーブル４１（図６）に基づいて、端末２ａで使用されているＯＳをＬｉｎｕｘであると仮定する。
【００７４】
ステート更新処理部３３は、端末２ａ、端末２ｄ、ルータ５に関して得られたＯＳの情報やステートもステート情報４４に記録する。このため、ステート情報４４−２は、ステート情報４４−３に示すように更新される。
【００７５】
図１１を参照しながら説明したように、ＭＡＣアドレスとＯＳのいずれも検知装置２０が認識している装置が使用するＩＰアドレスに対して、ステート３が割り当てられる。ここで、ネットワーク中の装置のＯＳを特定した後は、各装置のＯＳによって検知装置２０の情報が各装置の保持するＡＲＰテーブル４から削除されない間隔で通信を行うことによって、検知装置２０と各装置との間の通信実績が維持される。また、通信実績の維持に使用できるフレームの種類は任意である。換言すると、ステート３に分類されているＩＰに宛てて送信されるフレームを、ＰＩＮＧリクエストよりもフレーム長の短いフレームにすることにより、ネットワーク中の通信量を削減することができる。ＰＩＮＧリクエストよりもフレーム長の短いフレームとして、例えば、ＡＲＰリクエストが挙げられる。
【００７６】
そこで、生成処理部３１は、ステート３に分類されているＩＰアドレスに対しては、そのＩＰアドレスについてのＡＲＰリクエストを、そのＩＰアドレスを使用する装置のＯＳの種類に応じた周期で生成する。生成処理部３１が生成したＡＲＰリクエストを送信することにより、検知装置２０は、ＡＲＰリクエストで問合わせたＩＰアドレスを使用している装置との間の通信実績を維持できる。例えば、図１１の例では端末２ａ（１９２．１６８．１０．２２）のＯＳはＬｉｎｕｘであると判定されているので、生成処理部３１は、端末２ａが使用しているＩＰアドレスについてのＡＲＰリクエストを１秒ごとに送信する。一方、端末２ｂ（１９２．１６８．１０．２３）と端末２ｄ（１９２．１６８．１０．２６）のＯＳはＷｉｎｄｏｗｓであると判定されている。そこで、生成処理部３１は、端末２ｂと端末２ｄの各々が使用するＩＰアドレスについてのＡＲＰリクエストを、１５秒ごとに送信するための処理を行う。さらに、ルータ５（１９２．１６８．１０．２５）はネットワーク機器であると判定されているので、生成処理部３１は、ルータ５が使用するＩＰアドレスについてのＡＲＰリクエストを１２００秒ごとに送信する。
【００７７】
このように、第２の実施形態では、ネットワーク中の装置で使用されているＯＳに合わせて通信周期を調整する上に、ＯＳの特定の前後で通信に使用するフレームを変更することで、検知装置２０とネットワーク中の各装置との間の通信量をさらに削減できる。
【００７８】
図１２は、端末の差し替えが発生した際に行われる処理の例を説明する図である。工場などのネットワークでは、装置の差し替えが行われる場合もある。さらに、あるＩＰアドレスを使用している第１の装置が、その装置とは異なるＯＳを使用する第２の装置に差し替えられ、さらに、第１の装置と第２の装置が同じＩＰアドレスを使用する場合もあり得る。そこで、通信実績の維持のためにＯＳの種類の特定に使用可能なパラメータを含まないフレームを用いる場合、ステート更新処理部３３は、装置の差し替えの有無を検出するために、ＭＡＣアドレスの変化が発生したかをモニタする。以下、ＩＰアドレス＝１９２．１６８．１０．２３を使用する装置が端末２ｂから端末２ｆに変更される場合を例として説明する。
【００７９】
検知装置２０がステート情報４４−３を保持している場合、図１１を参照しながら説明したように、ＩＰアドレス＝１９２．１６８．１０．２３についてのＡＲＰリクエストが１５秒ごとに送信される。ＩＰアドレス＝１９２．１６８．１０．２３を使用する装置が端末２ｂのままである場合、端末２ｂはＡＲＰリクエストを受信すると、ＡＲＰテーブル４ｂ中の検知装置２０の情報を維持すると共に、検知装置２０に宛ててＡＲＰリプライを送信する。端末２ｂが生成するＡＲＰリプライには、ＩＰアドレス＝１９２．１６８．１０．２３とＭＡＣアドレス＝ＣＣ：ＤＤ：ＥＥ：ＦＦ：００：１１が含まれている。
【００８０】
ステート更新処理部３３は、受信部２３を介してＡＲＰリプライを取得すると、ＡＲＰリプライ中に含まれているＩＰアドレスとＭＡＣアドレスの組み合わせをステート情報４４−３中に記録されている組み合わせと比較する。この段階では、ＡＲＰリプライに含まれているＩＰアドレスとＭＡＣアドレスの組み合わせは、ステート情報４４−３の情報と一致している。そこで、ステート更新処理部３３は、ＡＲＰリプライの送信元では装置の変更が発生していないと判定する。装置の変更が発生していないので、通信実績維持のための通信処理は変更されない。
【００８１】
その後、ＩＰアドレス＝１９２．１６８．１０．２３を使用する装置が端末２ｂから端末２ｆに変更されたとする。検知装置２０の生成処理部３１は、ＩＰアドレス＝１９２．１６８．１０．２３についてのＡＲＰリクエストを、前回のＡＲＰリクエストの送信から１５秒後に送信するための処理を行う。端末２ｆがＩＰアドレス＝１９２．１６８．１０．２３を使用しているため、検知装置２０からのＡＲＰリクエストが端末２ｆで受信される（矢印Ａ５１）。
【００８２】
端末２ｆは、これまで検知装置２０との通信実績がないため、ＡＲＰリクエストに含まれている検知装置２０のアドレス情報を、端末２ｆが保持するＡＲＰテーブル４ｆに記録する。さらに、端末２ｆは、ＩＰアドレス＝１９２．１６８．１０．２３とＭＡＣアドレス＝ＡＡ：ＡＡ：ＡＡ：ＡＡ：ＡＡ：ＡＡを含むＡＲＰリプライを検知装置２０に向けて送信する（矢印Ａ５２）。
【００８３】
ステート更新処理部３３は、受信部２３を介してＡＲＰリプライを取得すると、ＡＲＰリプライ中に含まれているＩＰアドレスとＭＡＣアドレスの組み合わせをステート情報４４−３中に記録されている組み合わせと比較する。ＡＲＰリプライにはＩＰアドレス＝１９２．１６８．１０．２３とＭＡＣアドレス＝ＡＡ：ＡＡ：ＡＡ：ＡＡ：ＡＡ：ＡＡが含まれている。一方、ステート情報４４−３では、ＩＰアドレス＝１９２．１６８．１０．２３に対して、ＭＡＣアドレス＝ＣＣ：ＤＤ：ＥＥ：ＦＦ：００：１１が対応付けられている。このため、ステート更新処理部３３は、ＡＲＰリプライ中のＩＰアドレスとＭＡＣアドレスの組み合わせがステート情報４４−３の情報と一致していないと判定し、ＡＲＰリプライの送信元で装置の変更が発生したと判定する。また、装置の変更によりＩＰアドレス＝１９２．１６８．１０．２３を使用する装置のＯＳが変更されている可能性もある。そこで、ステート更新処理部３３は、ＩＰアドレス＝１９２．１６８．１０．２３に対応付けられているＯＳの情報を削除する。さらに、変更後の装置で使用されているＯＳを特定するために、ステート更新処理部３３は、ＩＰアドレス＝１９２．１６８．１０．２３に対するステートをステート２に変更する。さらに、ステート更新処理部３３は、ＡＲＰリプライで通知された新たなＭＡＣアドレスをステート情報４４に記録する。このため、ステート情報４４−３は、ステート情報４４−４に示すように更新される。
【００８４】
ステート情報４４−４に示すようにステート情報４４が更新されると、生成処理部３１は、ステート２に分類されたＩＰアドレス＝１９２．１６８．１０．２３に宛てたＰＩＮＧリクエストを生成し、送信部２２を介して送信する。このため、図１１を参照しながら説明した処理と同様の処理により、端末２ｆで使用されているＯＳの種類が特定され、ステート情報４４が適宜更新される。
【００８５】
一方、ＡＲＰリプライとステート情報４４の両者でＩＰアドレスとＭＡＣアドレスの組み合わせが一致している場合、ステート更新処理部３３は、装置の変更が発生していないと判定して、そのアドレスに対する情報を更新しない。このため、通信実績維持のための通信処理は変更されない。
【００８６】
例えば、端末２ａが使用するＩＰアドレス（１９２．１６８．１０．２２）についてのＡＲＰリクエストは、１秒ごとに送信される（矢印Ａ５３）。このため、端末２ａは、ＡＲＰテーブル４ａ中に検知装置２０の情報を維持すると共に、検知装置２０に宛ててＡＲＰリプライを送信する。ＡＲＰリプライとステート情報４４−４の間でＩＰアドレスとＭＡＣアドレスの組み合わせが一致しているので、ＩＰアドレス＝１９２．１６８．１０．２２への処理やＩＰアドレス＝１９２．１６８．１０．２２のステートは変更されない。
【００８７】
同様に、検知装置２０は端末２ｄが使用するＩＰアドレスについてのＡＲＰリクエストを１５秒ごとに送信し、ルータ５が使用するＩＰアドレスについてのＡＲＰリクエストを２０分ごとに送信する（矢印Ａ５４、Ａ５５）。端末２ｄやルータ５はＡＲＰリクエストの受信に際して端末２ａと同様の処理を行うので、端末２ｄやルータ５でも検知装置２０との間の通信実績は維持される。さらに、ＩＰアドレスとＭＡＣアドレスの組み合わせを用いて、ステート更新処理部３３は、端末２ｄとルータ５が使用しているＩＰアドレスについても、装置の変更が発生していないと判定する。このため、これらの装置についても、通信実績維持のための通信処理は変更されない。
【００８８】
このように、第２の実施形態では、ＩＰアドレスとＭＡＣアドレスの組み合わせが変化するかをステート更新処理部３３がモニタしているので、検知装置２０は、ＰＩＮＧリクエストなどの要求フレームを送信しなくても、装置の変更を検出できる。
【００８９】
図１３は、新たに端末が追加された際に行われる処理の例を説明する図である。以下、図１１を参照しながら説明した処理の後で新たにネットワークに接続された端末２ｃが、ＩＰアドレス＝１９２．１６８．１０．２４を使用する場合を例として説明する。なお、図１３では、端末２ｃが保持するＡＲＰテーブル４ｃを示しているが、図を見やすくするために、他の端末２やルータ５が保持するＡＲＰテーブル４は省略している。
【００９０】
ステート情報４４−３では、ＩＰアドレス＝１９２．１６８．１０．２４にステート１が設定されている。従って、ＩＰアドレス＝１９２．１６８．１０．２４は通信に使用されていない。そこで、生成処理部３１は、ＩＰアドレス＝１９２．１６８．１０．２４の使用開始を検知するために、所定の周期でＩＰアドレス＝１９２．１６８．１０．２４についてのＡＲＰリクエストを送信する（矢印Ａ６１）。
【００９１】
端末２ｃがネットワークに接続され、ＩＰアドレス＝１９２．１６８．１０．２４を使用し始めたとする。すると、端末２ｃは、検知装置２０から送信されたＡＲＰリクエストを受信する。端末２ｃは、ＡＲＰテーブル４ｃに検知装置２０のアドレス情報（ＩＰアドレス＝１９２．１６８．１０．５０、ＭＡＣアドレス＝ＡＡ：ＢＢ：ＣＣ：ＤＤ：ＥＥ：ＦＦ）を記録する。さらに、端末２ｃは、検知装置２０に宛ててＡＲＰリプライを送信する（矢印Ａ６２）。
【００９２】
検知装置２０の受信部２３は、端末２ｃから送信されたＡＲＰリプライを受信する。ＯＳ特定部３２は、ＡＲＰリプライを用いて、端末２ｃの情報をＡＲＰテーブル４３に登録する。さらに、ステート更新処理部３３は、ＡＲＰリプライの送信元ＩＰアドレスである１９２．１６８．１０．２４のステートをステート２に更新すると共に、端末２ｃのＭＡＣアドレスをステート情報４４に記録する。このため、ステート情報４４−３はステート情報４４−５に示すように更新される。ステート情報４４−５が得られた後にステート２に設定されているＩＰアドレスに対して行われる処理は、図１１を参照しながら説明したい処理と同様である。このため、新たにネットワークに接続された端末２ｃが使用しているＩＰアドレスに対してＰＩＮＧリクエストが送信され、ＰＩＮＧリプライを用いて端末２ｃで使用されているＯＳが特定される。従って、端末２ｃで使用されているＯＳに対応付けられた時間間隔ごとに、端末２ｃが使用しているＩＰアドレスについてのＡＲＰリクエストの送信処理が行われる。
【００９３】
図１４は、第２の実施形態にかかる検知方法の例を説明するフローチャートである。生成処理部３１は、送信部２２を用いて、処理対象のＩＰアドレスについてのＡＲＰリクエストを送信する（ステップＳ１１）。ＯＳ特定部３２は、ＡＲＰリプライを受信したかを判定する（ステップＳ１２）。ＡＲＰリプライを受信していない場合、ステート更新処理部３３はＡＲＰリクエストで問合わせたＩＰアドレスをステート１に設定し、生成処理部３１は所定時間待機する（ステップＳ１２でＮｏ、ステップＳ１３）。その後、ステップＳ１１以降の処理が繰り返される。
【００９４】
ＡＲＰリプライを受信した場合、ステート更新処理部３３はＡＲＰリプライの送信元のＩＰアドレスをステート２に設定し、ＡＲＰリプライの送信元のＭＡＣアドレスをステート情報４４に記録する。さらに、生成処理部３１は、ＡＲＰリプライの送信元にＰＩＮＧリクエストを送信する（ステップＳ１２でＹｅｓ、ステップＳ１４）。
【００９５】
ＯＳ特定部３２は、ＰＩＮＧリクエストの送信先からＰＩＮＧリプライを受信したかを判定する（ステップＳ１５）。ＰＩＮＧリプライを受信した場合、ＯＳ特定部３２は、ＰＩＮＧリプライ中のＴＴＬを参照してＰＩＮＧリプライの送信元で使用されているＯＳを同定し、ステート情報４４に記録する（ステップＳ１５でＹｅｓ、ステップＳ１６）。一方、ＰＩＮＧリプライを受信していない場合、ＯＳ特定部３２は、ＰＩＮＧリクエストの宛先装置で使用されているＯＳをＬｉｎｕｘに仮定して、ステート情報４４に記録する（ステップＳ１５でＮｏ、ステップＳ１７）。ステート更新処理部３３は、ステップＳ１６またはＳ１７の処理の対象となったＩＰアドレスをステート３に設定する。さらに、生成処理部３１は、ＯＳに対応付けられたタイマ設定値の間に渡って待機した後、ＡＲＰリクエストを送信する（ステップＳ１８）。
【００９６】
ＯＳ特定部３２は、ＡＲＰリプライを受信したかを判定する（ステップＳ１９）。ＡＲＰリプライを受信していない場合、ＡＲＰリクエストで問合わせたＩＰアドレスを使用していた装置がネットワークから切断されているので、ステート更新処理部３３はステップＳ１３に戻る（ステップＳ１９でＮｏ）。ＡＲＰリプライを受信した場合、ステート更新処理部３３は、ＡＲＰリプライ中のＭＡＣアドレスがステート情報４４中の記録と一致するかを判定する（ステップＳ１９でＹｅｓ、ステップＳ２０）。ＡＲＰリプライ中のＭＡＣアドレスがステート情報４４中の記録と一致した場合、ステップＳ１８以降の処理が繰り返される（ステップＳ２０でＹｅｓ）。一方、ＡＲＰリプライ中のＭＡＣアドレスがステート情報４４中の記録と一致しない場合、ステップＳ１４以降の処理が繰り返される（ステップＳ２０でＮｏ）。
【００９７】
一例として、第２の実施形態についてもネットワーク中の２５０台の装置との間で通信実績を維持するために使用される通信量を計算してみる。ここでも、ネットワーク中の２５０台の装置のうち、２５台がＬｉｎｕｘ系のＯＳを使用し、残りの２２５台がＷｉｎｄｏｗｓ系のＯＳを使用しているとする。第２の実施形態によると、全ての装置がステート３となっている場合、１秒あたりの通信量は、２５×４２＋２２５×１／１５×４２＝１６８０バイトですむ。なお、同じ条件下では、第１の実施形態では１秒当たり４６４０バイトの通信が発生する。
【００９８】
このように、第２の実施形態では、ネットワーク中の装置で使用されているＯＳに応じた通信周期でＡＲＰリクエストを送信することで、検知装置２０とネットワーク中の各装置との間の通信量を第１の実施形態よりもさらに削減できる。
【００９９】
第２の実施形態では、ＡＲＰリプライ中の送信元ＭＡＣアドレスがステート情報４４中のＭＡＣアドレスから変化しているかをモニタすることにより、１つのＩＰアドレスを使用する装置が変更された場合を検出し、再度ＯＳの特定を行うことができる。１つのＩＰアドレスを使用する装置が変更された場合も、ＯＳの特定後は特定したＯＳに応じて通信周期が調整される。従って、第２の実施形態によっても、検知装置２０は、ネットワーク中の各装置との通信実績を維持しつつ、通信量を削減できる。このため、ワーム７への２次感染の検知の見落としを発生させずに、検知装置２０とネットワーク中の装置との間の通信量を削減できる。
【０１００】
＜第３の実施形態＞
第３の実施形態では、検知装置２０がネットワーク中の装置からＧＡＲＰ（Ｇｒａｔｕｉｔｏｕｓ  ＡＲＰ）によるメッセージを受信した場合に、ネットワークに新たな装置が接続されたことを検出する場合について説明する。なお、ネットワークに新たな装置が接続される場合は、未使用のＩＰアドレスを使用する装置がネットワークに接続される場合と、あるＩＰアドレスを使用する装置が変更される場合の両方を含む。なお、第３の実施形態においても、端末２にアクチュエータ１が接続されていても良く、ルータ５を介してタブレット６が通信を行っていても良い。
【０１０１】
図１５は、新たに端末が追加された際に行われる処理の例を説明する図である。図１５の初期状態では、図１１を参照しながら説明した処理により、検知装置２０がステート情報４４−３を保持しているものとする。ただし、第３の実施形態では、生成処理部３１は、ステート１に設定されたＩＰアドレスに対してＡＲＰリクエストを送信するための処理を行わない。
【０１０２】
その後、端末２ｃがネットワークに接続されたとする。端末２ｃにＩＰアドレス＝１９２．１６８．１０．２４が割り当てられたとする。端末２ｃは割り当てられたＩＰアドレスを他の装置が使用しているかを確かめるために、ＧＡＲＰによるＡＲＰリクエストを送信する（矢印Ａ７１）。ＡＲＰリクエストはブロードキャストされるので、検知装置２０の受信部２３は、端末２ｃからのＧＡＲＰによるＡＲＰリクエストを受信できる。
【０１０３】
ＯＳ特定部３２は、ＧＡＲＰによるＡＲＰリクエストに記録されている送信元ＩＰアドレスに対してＡＲＰリクエストを送信し、端末２ｃからのＡＲＰリプライに記録されている送信元ＭＡＣアドレスの情報を、ＡＲＰテーブル４３に記録する。ステート更新処理部３３は、ＡＲＰリクエストの送信元が使用しているＩＰアドレスにステート２を設定すると共に、ＡＲＰリクエスト中の送信元ＭＡＣアドレスをステート情報４４に記録する。すると、ステート情報４４−３は、ステート情報４４−１１に示すように更新される。
【０１０４】
図１６は、端末が変更された際に行われる処理の例を説明する図である。図１６は、ステート情報４４−１１が得られた直後に端末２ｂが端末２ｆに変更された場合を例として説明する。
【０１０５】
端末２ｆにＩＰアドレス＝１９２．１６８．１０．２３が割り当てられたとする。すると、端末２ｆは割り当てられたＩＰアドレスを他の装置が使用しているかを確かめるために、ＧＡＲＰによるＡＲＰリクエストをブロードキャストする。このため、検知装置２０の受信部２３は、端末２ｆからのＧＡＲＰによるＡＲＰリクエストを受信できる。
【０１０６】
ＯＳ特定部３２は、ＧＡＲＰによるＡＲＰリクエストに記録されている送信元ＩＰアドレスに対してＡＲＰリクエストを送信する。ステート更新処理部３３は、端末２ｆからのＡＲＰリプライに記録されている送信元ＩＰアドレスと送信元ＭＡＣアドレスの情報の組み合わせが、ステート情報４４−１１に含まれていないと判定する。すると、ステート更新処理部３３は、ＡＲＰリプライに記録されている送信元ＩＰアドレスに対するステートをステート２に更新すると共に、ＡＲＰリクエスト中の送信元ＭＡＣアドレスを用いてステート情報４４を更新する。このため、ステート情報４４−１１は、ステート情報４４−１２に更新される。
【０１０７】
図１５と図１６を参照しながら、ネットワークに新たな装置が接続された場合、新たに接続された装置が使用するＩＰアドレスに対してステート２が設定されることを説明した。第３の実施形態においても、ステート２に設定されたＩＰアドレスには、図１１を参照しながら説明した処理と同様の処理が行われる。このため、生成処理部３１は、ステート情報４４−１２中のステート２に設定されているＩＰアドレスの各々に対してＰＩＮＧリクエストを送信する。その後の処理は第２の実施形態と同様である。このため、ＧＡＲＰによるＡＲＰリクエストの送信元である端末２ｃや端末２ｆが保持するＡＲＰテーブル４中に検知装置２０のアドレスの情報が記録される。さらに、生成処理部３１は、端末２ｃとの間の通信実績を維持するために、端末２ｃで使用されているＯＳに対応付けられた時間間隔ごとに、端末２ｃが使用しているＩＰアドレスについてのＡＲＰリクエストの送信処理を行う。同様の処理により、検知装置２０は端末２ｆとの間の通信実績も維持する。
【０１０８】
図１７は、第３の実施形態にかかる検知方法の例を説明するフローチャートである。生成処理部３１は、送信部２２を用いて、処理対象のＩＰアドレスについてのＡＲＰリクエストを送信する（ステップＳ３１）。ＯＳ特定部３２は、ＡＲＰリプライを受信したかを判定する（ステップＳ３２）。ＡＲＰリプライを受信していない場合、ステート更新処理部３３はＡＲＰリクエストで問合わせたＩＰアドレスをステート１に設定する（ステップＳ３２でＮｏ）。さらに、生成処理部３１は、ステート１に設定されているＩＰアドレスについてのＧＡＲＰによるＡＲＰリクエストを受信するまで待機する（ステップＳ３４でＮｏ）。ステップＳ３４においてＧＡＲＰによるＡＲＰリクエストを受信したと判定すると、ステップＳ３３以降の処理が行われる（ステップＳ３４でＹｅｓ）。
【０１０９】
ＡＲＰリプライを受信した場合、ステート更新処理部３３はＡＲＰリプライの送信元のＩＰアドレスをステート２に設定し、ＡＲＰリプライの送信元のＭＡＣアドレスをステート情報４４に記録する。さらに、生成処理部３１は、ＡＲＰリプライの送信元にＰＩＮＧリクエストを送信する（ステップＳ３２でＹｅｓ、ステップＳ３３）。ステップＳ３５〜Ｓ３７で行われる処理は、図１４を参照しながら説明したステップＳ１５〜Ｓ１７と同様である。ステート更新処理部３３は、ステップＳ３６かＳ３７の処理の対象となったＩＰアドレスをステート３に設定する。さらに、生成処理部３１は、ＡＲＰリクエストを送信した後、ＡＲＰリクエストでアドレス解決の対象となっているＩＰアドレスを使用する装置のＯＳに対応付けられたタイマ設定値に従って、タイマテーブル４２を設定する（ステップＳ３８）。ＯＳ特定部３２は、ＡＲＰリプライを受信したかを判定する（ステップＳ３９）。
【０１１０】
ステップＳ３９でＡＲＰリプライを受信していないと判定すると、ステップＳ３４以降の処理が行われる（ステップＳ３９でＮｏ）。なお、ステップＳ３９でＮｏと判定されるケースは、ＡＲＰリクエストで問合わせられたＩＰアドレスを使用している装置がネットワークから切断された場合などである。
【０１１１】
一方、ステップＳ３９でＡＲＰリプライを受信したと判定すると、ステート更新処理部３３は、処理対象のＩＰアドレスについて、ＧＡＲＰによるＡＲＰリクエストを受信したかを判定する（ステップＳ３９でＹｅｓ、ステップＳ４０）。ＧＡＲＰによるＡＲＰリクエストを受信した場合は、ＧＡＲＰによるＡＲＰリクエストの送信元は、新たにネットワークに接続されている。従って、ＧＡＲＰによるＡＲＰリクエストの送信元ＩＰアドレスを使用している装置は、ステート情報４４の最終更新時から変更されていることになる。そこで、ステップＳ３３以降の処理が行われる（ステップＳ４０でＹｅｓ）。
【０１１２】
ＧＡＲＰによるＡＲＰリクエストを受信していない場合、処理対象のＩＰアドレスを使用している装置は、ステート情報４４の最終更新時から変更されていない（ステップＳ４０でＮｏ）。そこで、生成処理部３１は、処理対象のＩＰアドレスを使用している装置のＯＳに対応付けて設定されたタイマが満了しているかを判定する（ステップＳ４１）。タイマが満了していない場合、ステップＳ４０以降の処理が行われる（ステップＳ４１でＮｏ）。一方、タイマが満了している場合、処理対象のＩＰアドレスを使用している装置との間の通信実績を維持するために、ステップＳ３８以降の処理が繰り返される（ステップＳ４１でＹｅｓ）。
【０１１３】
このように、第３の実施形態では、未使用のＩＰアドレスを使用する装置がネットワークに接続された場合や、あるＩＰアドレスを使用する装置が変更された場合を、ＧＡＲＰを用いて検出することができる。このため、第３の実施形態では、未使用のＩＰアドレスの使用開始などを検出するために検知装置２０がＡＲＰリクエストを送信しなくても良い。従って、第３の実施形態では、第２の実施形態よりも検知装置２０の処理負荷を軽減することができる。
【０１１４】
＜その他＞
なお、実施形態は上記に限られるものではなく、様々に変形可能である。以下にその例をいくつか述べる。
【０１１５】
以上の説明で図示したフレームやテーブルは一例であり、フレームやテーブル中に含まれる情報要素は実装に応じて変更され得る。例えば、第３の実施形態では、ＧＡＲＰを用いて装置の変更等を検出しており、各ＩＰアドレスに対応するのでＭＡＣアドレスの変更はモニタされていないので、ステート情報４４にＭＡＣアドレスが含まれていなくても良い。さらに、第２の実施形態でも、ステート更新処理部３３がＡＲＰテーブル４３とステート情報４４の両方にアクセスするように処理を変形すれば、ステート情報４４にはＭＡＣアドレスが含まれていなくても良い。また、ステート情報４４は、第２の実施形態などで説明したように、ステート０を記録する代わりに、ステート０に該当する場合には空欄を保持していても良い。
【０１１６】
第２の実施形態において、ＭＡＣアドレス同士の比較を行う場合であっても、アドレスの比較に支障の出ない程度にＭＡＣアドレスを圧縮して記録しても良い。この場合、テーブルに使用するメモリ容量を削減できる。さらに、テーブル中のＯＳの情報などは、適宜、符号化されても良い。
【０１１７】
以上の説明では、送信フレームの送信周期をタイマテーブル４２でのタイマ満了までの残り時間を用いて計測しているが、検知装置２０は、タイマをハードウェアとして備えていても良い。この場合、検知装置２０は、個々のＩＰアドレスについてのタイマ満了をハードウェアのタイマで計測できるので、タイマテーブル４２を備えていなくても良い。
【０１１８】
以上の説明では、検知装置２０が所定期間内にＰＩＮＧリプライを受信しない場合に、ＰＩＮＧリクエストの宛先ではＬｉｎｕｘ系のＯＳが使用されていると仮定する場合を例としたが、これは一例に過ぎない。仮定に使用されるＯＳの種類はタイマ設定値テーブル４１の設定実装に応じて変更され得る。ＰＩＮＧリクエストの宛先の装置で使用されていると仮定されるＯＳは、タイマ設定値テーブル４１のうちでタイマ設定値が最小のＯＳであれば良い。
【０１１９】
第３の実施形態において、ＧＡＲＰによるメッセージがＡＲＰリクエストである場合を例として説明したが、これは一例に過ぎない。ＧＡＲＰによるメッセージは、ある装置が使用するＩＰアドレスの通知のためのメッセージであれば、実装に応じてＡＲＰリクエスト以外であっても良い。
【符号の説明】
【０１２０】
１  アクチュエータ
２  端末
４、４３  ＡＲＰテーブル
５  ルータ
６  タブレット
７  ワーム
１０、２０  検知装置
２１  通信部
２２  送信部
２３  受信部
３０  制御部
３１  生成処理部
３２  ＯＳ特定部
３３  ステート更新処理部
４０  記憶部
４１  タイマ設定値テーブル
４２  タイマテーブル
４４  ステート情報
１０１  プロセッサ
１０２  メモリ
１０３  バス
１０４  ネットワーク接続装置
【図１】
2020109927.tif 000003
【図２】
2020109927.tif 000004
【図３】
2020109927.tif 000005
【図４】
2020109927.tif 000006
【図５】
2020109927.tif 000007
【図６】
2020109927.tif 000008
【図７】
2020109927.tif 000009
【図８】
2020109927.tif 000010
【図９】
2020109927.tif 000011
【図１０】
2020109927.tif 000012
【図１１】
2020109927.tif 000013
【図１２】
2020109927.tif 000014
【図１３】
2020109927.tif 000015
【図１４】
2020109927.tif 000016
【図１５】
2020109927.tif 000017
【図１６】
2020109927.tif 000018
【図１７】
2020109927.tif 000019