JP2004341578A

JP2004341578A - File providing device, file providing method, file providing program and recording medium with its program recorded

Info

Publication number: JP2004341578A
Application number: JP2003133948A
Authority: JP
Inventors: Naoko Shigematsu; 直子重松; Takeshi Mie; 武三栄
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2003-05-13
Filing date: 2003-05-13
Publication date: 2004-12-02

Abstract

<P>PROBLEM TO BE SOLVED: To provide a technique that can prevent leakage of file data by pretending to be a client. <P>SOLUTION: A system comprises a file providing device operated by a transfer protocol without client authentication to transfer a transfer-requested file to a client, and a mediation server for authenticating the client and notifying the client of a network address of the file providing device and the filename of the file transferred to the client. Storing means are provided to store filenames of files permitted to be transferred to the client in association with a network address of the client. A mechanism is provided to use the means in controlling file transfer, changing the filenames and notifying the changed filenames to the client via the mediation server. With the mechanism, file transfer is controlled. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

【０００１】
【発明の属する技術分野】
本発明は、ファイル提供装置と仲介サーバとで構成されるシステムで用いられるファイル提供装置及びその方法と、そのファイル提供方法の実現に用いられるファイル提供プログラム及びそのプログラムを記録した記録媒体とに関する。
【０００２】
クライアントの認証を行わない転送プロトコルで動作して、転送要求のあるファイルをクライアントに転送するファイル提供装置と、クライアントの認証を行って、クライアントに対して、ファイル提供装置のネットワークアドレスとそのクライアントに転送するファイルのファイル名とを通知する仲介サーバとで構成されるシステムがある。
【０００３】
本発明は、このようなシステムで用いられるファイル提供装置及びその方法と、そのファイル提供方法の実現に用いられるファイル提供プログラム及びそのプログラムを記録した記録媒体とに関するものであり、より具体的には、ディスクレスブートシステム環境において安全なブートを保障する技術に関するものである。
【０００４】
【従来の技術】
従来、ディスクレスブートシステムでは、ディスクレスクライアントとＤＨＣＰサーバとＴＦＴＰサーバとファイルサーバとがＩＰネットワークに接続されている（例えば、特許文献１参照）。
【０００５】
（１）ディスクレスクライアントの処理
ブートするディスクレスクライアントは、まず始めに、ＤＨＣＰサーバに対して問合せを行う。この問合せを受けたＤＨＣＰサーバは、問い合わせてきたディスクレスクライアントに割り当てるＩＰアドレスと、ＴＦＴＰサーバのＩＰアドレスと、ＴＦＴＰサーバから取得すべきブートストラップのファイル名とを、ディスクレスクライアントに回答する。
【０００６】
ディスクレスクライアントは、次に、ＤＨＣＰサーバの返答に基づいて、ＴＦＴＰサーバからブートストラップのファイルを、単純ファイル転送プロトコル（ＴＦＴＰ）を使用して取得する。
【０００７】
ディスクレスクライアントは、次に、取得したブートストラップを実行して、ブートストラップ内に記述してあるオペレーティング・システム（ＯＳ）イメージのファイル名に基づいて、ＴＦＴＰサーバからＯＳイメージのファイルを、ＴＦＴＰを使用して取得する。
【０００８】
ディスクレスクライアントは、次に、取得したＯＳイメージを使ってブートする。ＯＳイメージ内には、ディスクレスクライアントが使用すべきファイルサーバのＩＰアドレスとファイルシステム名とが記述してある。
【０００９】
ディスクレスクライアントは、続いて、ファイルサーバに接続して、使用可能なファイルシステムをマウントして、ブートを完了する。
【００１０】
（２）ＴＦＴＰサーバの処理
ＴＦＴＰサーバは、接続してくるクライアントに対して、ファイル名で指定されたファイルの読み出し、あるいは書き込みのみを提供する。ＴＦＴＰサーバは接続してくるクライアントの認証は行っていない。
【００１１】
ディスクレスブートシステムでは、ディスクレスクライアントに多くの機能や情報を持たせることが難しいため、機能が少なくて実装が容易なＴＦＴＰが用いられることが多い。
【００１２】
（３）ＤＨＣＰサーバの処理
ＤＨＣＰサーバは、問い合わせてくるディスクレスクライアントが使用しているＭＡＣアドレスの値によって、ディスクレスクライアントを識別可能である。よって、ＤＨＣＰサーバは、ＭＡＣアドレスの値に基づいてディスクレスクライアントを識別し、回答するＩＰアドレス、ＴＦＴＰサーバのＩＰアドレスおよびブートストラップのファイル名を、ディスクレスクライアント毎に変えることが可能である。
【００１３】
もちろん、ＤＨＣＰサーバは、ディスクレスクライアントの識別を行わず、回答するＩＰアドレスのみを変えて、同じＴＦＴＰサーバのＩＰアドレスおよび同じブートストラップのファイル名を回答することも可能である。
【００１４】
従って、ディスクレスブートシステムでは、複数のブートストラップのファイルや、複数のＯＳイメージのファイルや、複数のファイルシステムを用意しておき、ディスクレスクライアントのＭＡＣアドレスに基づいて、ＤＨＣＰサーバが異なるブートストラップのファイル名を回答することにより、複数のディスクレスクライアントを異なったＯＳ環境でブートすることが可能である。
【００１５】
図１０は、２台のディスクレスクライアントを持つディスクレスブートシステムの例である。ディスクレスクライアントＤＣ１とＤＣ２、ＤＨＣＰサーバ、ＴＦＴＰサーバ、ファイルサーバがＩＰネットワークにより接続されている。
【００１６】
ディスクレスクライアントＤＣ１は、ＭＡＣアドレス“ＭＡＣ１”を持ち、ディスクレスクライアントＤＣ２は、ＭＡＣアドレス“ＭＡＣ２”を持っている。ＴＦＴＰサーバは、ＩＰアドレス“ＩＰｔ”を使用している。
【００１７】
ＴＦＴＰサーバは、ＤＣ１用のブートストラップのファイル“ＢＳ１”と、ＤＣ１用のＯＳイメージのファイル“ＯＩ１”と、ＤＣ２用のブートストラップのファイル“ＢＳ２”と、ＤＣ２用のＯＳイメージのファイル“ＯＩ２”とを持っている。
【００１８】
ファイルサーバは、ＤＣ１用のファイルシステム“ＦＳ１”と、ＤＣ２用のファイルシステム“ＦＳ２”とを持っている。
【００１９】
ＤＨＣＰサーバは、設定ファイルと、ＤＣ１用のＩＰアドレス“ＩＰ１”と、ＤＣ２用のＩＰアドレス“ＩＰ２”とを持っている。
【００２０】
ＤＨＣＰサーバが持っている設定ファイルには、図１１に例示するように、ＤＣ１からの問合せには、ＩＰアドレス“ＩＰ１”とＴＦＴＰサーバのＩＰアドレス“ＩＰｔ”とブートストラップのファイル名“ＢＳ１”とを回答し、ＤＣ２からの問合せには、ＩＰアドレス“ＩＰ２”とＴＦＴＰサーバのＩＰアドレス“ＩＰｔ”とブートストラップのファイル名“ＢＳ２”とを回答するよう記述されている。
【００２１】
図１０の例では、ブートするディスクレスクライアントＤＣ１は、ＤＨＣＰサーバに問合せを行った結果、ＩＰアドレス“ＩＰ１”を使用してＴＦＴＰサーバからブートストラップのファイル“ＢＳ１”を取得する。その後、ディスクレスクライアントＤＣ１は、ＴＦＴＰサーバからＯＳイメージ“ＯＩ１”を取得して、それを起動し、ファイルシステム“ＦＳ１”をマウントする。
【００２２】
同様に、ブートするディスクレスクライアントＤＣ２は、ＤＨＣＰサーバに問合せを行った結果、ＩＰアドレス“ＩＰ２”を使用してＴＦＴＰサーバからブートストラップのファイル“ＢＳ２”を取得する。その後、ディスクレスクライアントＤＣ２は、ＴＦＴＰサーバからＯＳイメージ“ＯＩ２”を取得して、それを起動し、ファイルシステム“ＦＳ２”をマウントする。
【００２３】
その結果、ディスクレスクライアントＤＣ１とディスクレスクライアントＤＣ２とは、異なるＯＳ環境での起動が実現される。
【００２４】
【特許文献１】
特開２００２−１２３４００
【００２５】
【発明が解決しようとする課題】
しかしながら、従来技術で実現したディスクレスブートシステムでは、ＴＦＴＰが認証を必要としないことに起因する、ディスクレスクライアントの成りすましが容易にできてしまう問題がある。すなわち、あるディスクレスクライアントが、他のディスクレスクライアントとしてブートし、動作できてしまうことが問題である。
【００２６】
例えば図１０において、ブートストラップのファイル“ＢＳ２”を取得するようにとＤＨＣＰサーバから回答を得たディスクレスクライアントＤＣ２が、これに従わずに、ＴＦＴＰサーバからＯＳイメージ“ＯＩ１”を取得してブートを継続すれば、簡単にディスクレスクライアントＤＣ１としてブートを完了できてしまうことになる。
【００２７】
ＴＦＴＰはクライアントの認証を行わないプロトコルである。あるＵＮＩＸ計算機（ＵＮＩＸは登録商標）がＴＦＴＰサーバに接続して、ファイルを転送する場合を考える。
【００２８】
ＵＮＩＸ計算機のオペレータがコンソールに“ｇｅｔファイル名”と入力した場合、ＴＦＴＰサーバ上に、指定された“ファイル名”の名前を持つファイルが存在すれば、ＴＦＴＰサーバは、指定されたファイルをＵＮＩＸ計算機に転送する。一方、ＴＦＴＰサーバ上に、指定された“ファイル名”の名前を持つファイルが存在しなければ、エラーとなり、転送はされない。
【００２９】
よって、ディスクレスクライアントでなくとも、ディスクレスブートシステムのＩＰネットワークにＵＮＩＸ計算機を接続すれば、容易にＴＦＴＰサーバ上の全てのファイルを取得できてしまう問題がある。
【００３０】
これから、ＴＦＴＰサーバが、ブートストラップのファイルとＯＳイメージのファイルとを正しいディスクレスクライアントにのみ転送し、正しくないディスクレスクライアントには転送しない技術を提供することで、ディスクレスブートシステム環境において、ディスクレスクライアントの成りすましによるブートデータの漏洩を防ぐ必要がある。
【００３１】
本発明はかかる事情に鑑みてなされたものであって、クライアントの認証を行わない転送プロトコルで動作して、転送要求のあるファイルをクライアントに転送するファイル提供装置と、クライアントの認証を行って、クライアントに対して、ファイル提供装置のネットワークアドレスとそのクライアントに転送するファイルのファイル名とを通知する仲介サーバとで構成されるシステムにおいて、正しいクライアントにのみファイルを転送し、正しくないクライアントにはファイルを転送しないようにする新たな技術の提供を目的とする。
【００３２】
【課題を解決するための手段】
この目的を達成するために、本発明のファイル提供装置は、クライアントの認証を行わない転送プロトコルで動作して、転送要求のあるファイルをクライアントに転送するファイル提供装置と、クライアントの認証を行って、クライアントに対して、ファイル提供装置のネットワークアドレスとそのクライアントに転送するファイルのファイル名とを通知する仲介サーバとで構成されるシステムで用いられるときにあって、▲１▼転送要求を発行してくる可能性のあるクライアントのネットワークアドレスに対応付けて、そのクライアントへの転送を許可するファイルのファイル名を記憶する記憶手段と、▲２▼クライアントから発行されたファイル転送要求に従って、クライアントのネットワークアドレスと転送要求のファイル名とを取得する取得手段と、▲３▼取得手段の取得したネットワークアドレスとファイル名との対データが記憶手段に記憶されているのか否かを判断する判断手段と、▲４▼取得手段の取得したネットワークアドレスとファイル名との対データが記憶手段に記憶されていない場合には、転送要求を破棄し、記憶されている場合には、取得手段の取得したファイル名の指すファイルをクライアントに転送する転送手段とを備えるように構成する。
【００３３】
以上の各処理手段が動作することで実現される本発明のファイル提供方法はコンピュータプログラムで実現できるものであり、このコンピュータプログラムは、半導体メモリなどのような適当な記録媒体に記録して提供したり、ネットワークを介して提供することができる。
【００３４】
このように構成される本発明のファイル提供装置では、クライアントからファイル転送要求が発行されると、そのファイル転送要求に従って、クライアントのネットワークアドレスと転送要求のファイル名とを取得する。
【００３５】
続いて、その取得したネットワークアドレスとファイル名との対データが記憶手段に記憶されているのか否かを判断して、記憶されていない場合には、転送要求を破棄し、記憶されている場合には、その取得したファイル名の指すファイルをクライアントに転送する。
【００３６】
このように、本発明によれば、クライアントの認証を行わない転送プロトコルで動作して、転送要求のあるファイルをクライアントに転送するファイル提供装置と、クライアントの認証を行って、クライアントに対して、ファイル提供装置のネットワークアドレスとそのクライアントに転送するファイルのファイル名とを通知する仲介サーバとで構成されるシステムにおいて、転送要求を発行してくる可能性のあるクライアントのネットワークアドレスに対応付けて、そのクライアントへの転送を許可するファイルのファイル名を記憶する記憶手段を用意して、それを使ってファイル転送を制御するようにすることから、正しいクライアントにのみファイルを転送し、正しくないクライアントにはファイルを転送しないことを実現できるようになる。
【００３７】
また、上記目的を達成するために、本発明のファイル提供装置は、クライアントの認証を行わない転送プロトコルで動作して、転送要求のあるファイルをクライアントに転送するファイル提供装置と、クライアントの認証を行って、クライアントに対して、ファイル提供装置のネットワークアドレスとそのクライアントに転送するファイルのファイル名とを通知する仲介サーバとで構成されるシステムで用いられるときにあって、▲１▼ファイル名の変更契機に到達したのか否かを判断する判断手段と、▲２▼ファイル名の変更契機に到達したときに、自装置で保存している転送対象のファイルの一部又は全てのファイル名を変更するとともに、仲介サーバに登録されているそのファイル名を変更する変更手段とを備えるように構成する。
【００３８】
以上の各処理手段が動作することで実現される本発明のファイル提供方法はコンピュータプログラムで実現できるものであり、このコンピュータプログラムは、半導体メモリなどのような適当な記録媒体に記録して提供したり、ネットワークを介して提供することができる。
【００３９】
このように構成される本発明のファイル提供装置では、例えば、規定の周期に到達することでファイル名の変更契機に到達したことを判断すると、自装置で保存している転送対象のファイルの一部又は全てのファイル名を変更するとともに、仲介サーバに登録されているそのファイル名を変更する。また、例えば、クライアントに対してファイル転送が行われたことでファイル名の変更契機に到達したことを判断すると、転送ファイルのファイル名を変更対象としてファイル名を変更する。また、例えば、クライアントからファイル転送要求が発行されたことでファイル名の変更契機に到達したことを判断すると、ファイル転送の成功失敗にかかわらずに、転送対象となる全てのファイルのファイル名を変更対象としてファイル名を変更する。
【００４０】
このように、本発明によれば、クライアントの認証を行わない転送プロトコルで動作して、転送要求のあるファイルをクライアントに転送するファイル提供装置と、クライアントの認証を行って、クライアントに対して、ファイル提供装置のネットワークアドレスとそのクライアントに転送するファイルのファイル名とを通知する仲介サーバとで構成されるシステムにおいて、ファイル名を変更するとともに、その変更したファイル名が仲介サーバを介してクライアントに通知されるようにする機構を用意して、それを使ってファイル転送を制御するようにすることから、正しいクライアントにのみファイルを転送し、正しくないクライアントにはファイルを転送しないことを実現できるようになる。
【００４１】
次に、▲１▼１つ以上のディスクレスクライアントと、▲２▼ディスククライアントに対して、ＩＰアドレス等のネットワーク情報とＴＦＴＰサーバのＩＰアドレスとＴＦＴＰサーバからダウンロードするブートストラップのファイル名とを提供するＤＨＣＰサーバと、▲３▼ディスクレスクライアントがダウンロードするブートストラップおよびＯＳイメージを保有するＴＦＴＰサーバと、▲４▼ディスクレスクライアントがマウントするルートパーティションを保持するファイルサーバとがＩＰネットワークに繋がっているディスクレスブートシステムへの適用を具体例にして、本発明の構成について詳細に説明する。
【００４２】
本発明において、ディスクレスクライアントは、ＭＡＣアドレスとＤＨＣＰサーバから取得したＩＰアドレスとについては詐称しないと仮定する。これらの詐称を防止する手法については他の技術を用いるものとし、本発明では言及しない。
【００４３】
（１）第１の構成
上記目的を達成するため、本発明では、第１の構成として、ＴＦＴＰサーバが接続してくるクライアントのＩＰアドレスに基づいてクライアントを識別し、クライアントによって指定されたファイルの転送を許可するか、あるいは転送を禁止する構成を提供する。
【００４４】
具体的には、ＴＦＴＰサーバが、ディスクレスクライアントのＩＰアドレスとブートストラップのファイル名およびＯＳイメージのファイル名との対応表を持ち、この対応表に記述されるＩＰアドレスと異なるＩＰアドレスのディスクレスクライアントから、あるブートストラップのファイルまたはＯＳイメージのファイルについてＴＦＴＰによる取得要求を受信した場合には、その取得要求を破棄するという構成を採る。
【００４５】
すなわち、ＴＦＴＰサーバは、接続してくる予定のクライアントのＩＰアドレスと当該クライアントに転送を許可するファイルのファイル名との対応を示した表を新たに持つ。そして、ＴＦＴＰサーバは、クライアントが接続してきた際に、クライアントのＩＰアドレスを認識し、この表に基づいて、クライアントから指定されたファイルの転送（読み出し、あるいは書き込み）を許可あるいは禁止し、許可の場合のみ指定されたファイルの転送を実行する。
【００４６】
この構成により、ディスクレスブートシステムにおける、ＴＦＴＰサーバからの不正なファイル転送を防止することができる。
【００４７】
（２）第２の構成
また、上記目的を達成するため、本発明では、第２の構成として、ＴＦＴＰサーバが自らが保持するファイルのファイル名を自動的に変更する構成を提供する。ＴＦＴＰでは、転送するファイル名を指定する必要があることから、ファイル名が分からなければ不正なファイルの転送を防ぐことが可能となる。
【００４８】
具体的には、ＴＦＴＰサーバに保存されているブートストラップのファイル名、ＴＦＴＰサーバに保存されているＯＳイメージのファイル名、ＤＨＣＰサーバに登録されているブートストラップのファイル名、ブートストラップに記述されているＯＳイメージのファイル名とを、ランダムに発生した別のファイル名に変更するという構成を採る。
【００４９】
すなわち、ＴＦＴＰサーバに自動的にファイル名を変更する機能を新規に追加し、ＴＦＴＰサーバが適切な契機に推測されにくいファイル名へと変更し、正当なクライアントにのみ変更後のファイル名を知らせることで、クライアントからのファイル転送の要求に対して、正当なクライアントに対しては存在するファイル名を指定させることでファイル転送を成功させ、不正なクライアントに対しては存在するファイル名を指定させないことでファイル転送を失敗させることができる。
【００５０】
この構成により、ディスクレスブートシステムにおける、ＴＦＴＰサーバからの不正なファイル転送を防止することができる。
【００５１】
ここで、上記第１の構成と上記第２の構成とは背反した構成であるため、ＴＦＴＰサーバにいずれか片方あるいは両方を実装することが可能である。
【００５２】
（３）第３の構成〜第５の構成
また、上記目的を達成するため、本発明では、上記第２の構成におけるファイル名の変更の契機について、さらに３つの構成を提供する。
【００５３】
（３−１）第３の構成
上記目的を達成するため、本発明では、第３の構成として、上記第２の構成におけるファイル名の変更の契機を、管理者が定める時間間隔とする構成を提供する。
【００５４】
すなわち、ＴＦＴＰサーバは、定期的に、上記ファイル名変更対象のファイルの一部あるいは全部のファイル名を、推測されにくい新たなファイル名へ変更する。
【００５５】
この構成により、ＴＦＴＰサーバが保持するファイルのファイル名を入手した不正なクライアントが、入手したファイル名を指定してファイルをＴＦＴＰサーバから取得しようと試みても、既にファイル名が変更されていて、ファイルの転送を失敗させることが可能となる。
【００５６】
（３−２）第４の構成
上記目的を達成するため、本発明では、第４の構成として、上記第２の構成におけるファイル名の変更の契機を、正当なファイルの転送の時点とする構成を提供する。
【００５７】
すなわち、正当なクライアントからファイルの転送を要求されたＴＦＴＰサーバは、そのファイルの転送を契機として、転送したファイルのファイル名を変更する。
【００５８】
この構成により、正当なクライアントによるファイルの転送を監視していた不正なクライアントが、何らかの手法により現在転送されたファイルのファイル名を入手し、入手したファイル名を指定してＴＦＴＰサーバからのファイルの転送を試みても、既に該ファイルはファイル名が変更されていることから、不正なクライアントが指定したファイルが存在しないことにより、ファイルの転送を失敗させることができる。
【００５９】
（３−３）第５の構成
上記目的を達成するため、本発明では、第５の構成として、上記第２の構成におけるファイル名の変更の契機を、ファイルの転送の時点とする構成を提供する。
【００６０】
上記第２、第３、第４の構成では、ＴＦＴＰサーバが保持するファイルを推測しにくいファイル名に変更しているだけであるので、不正なクライアントが考えられる全てのパターンのファイル名を総当り的に指定して、転送を要求してきた場合に、偶然、ファイル名が一致して、転送が成功してしまう可能性がある。
【００６１】
これを回避するため、第５の構成では、ＴＦＴＰサーバが保持する全ファイルのファイル名を変更する契機として、転送の成功あるいは失敗に関わらず、ＴＦＴＰのファイル転送の要求を契機とする。
【００６２】
すなわち、不正なクライアントが考えられる全てのパターンのファイル名を総当り的に指定して、転送を要求してきた場合でも、転送が失敗する毎に全てのファイルのファイル名が変更されるために、ファイル名が偶然に一致する可能性を下げることができる。
【００６３】
【発明の実施の形態】
次に、本発明について図面を参照して詳細に説明する。
【００６４】
まず、図１に従って、第１の実施形態例（上記第１の構成に該当する）について説明する。
【００６５】
ここで、図中、１−ｉ（ｉ＝１〜ｎ）はディスクレスクライアント、２はＤＨＣＰサーバ、３はＴＦＴＰサーバ、４はファイルサーバ、５はＩＰネットワークを示している。
【００６６】
第１の実施形態例を実現する場合には、ＴＦＴＰサーバ３にはフィルタ機構３０が備えられており、このフィルタ機構３０は対応表３００を保持している。
【００６７】
この対応表３００は、図２に示すように、ディスクレスクライアント１−ｉのＩＰアドレスに対応付けて、そのディスクレスクライアント１−ｉに転送することが許可されているブートストラップのファイル名およびＯＳイメージのファイル名を管理する。
【００６８】
フィルタ機構３０は、ＴＦＴＰサーバ３が受信したイーサネットフレーム（イーサネットは登録商標）のうち、まず、ＴＦＴＰパケットを含むイーサネットフレームを抽出する。
【００６９】
この抽出については、ＴＦＴＰサーバ３が受信したイーサネットフレームのＩＰヘッダー内のプロトコル欄がＵＤＰで、かつ、ＵＤＰヘッダー内の宛先ポート番号が６９であるイーサネットフレームを、ＴＦＴＰパケットを含むイーサネットフレームと判断して抽出することにより行う。
【００７０】
続いて、この抽出したイーサネットフレームのうち、タイプがＲｅａｄｒｅｑｕｅｓｔ（ＲＲＱ）またはＷｒｉｔｅｒｅｑｕｅｓｔ（ＷＲＱ）であるＴＦＴＰパケットを含むイーサネットフレームをさらに抽出し、ＩＰヘッダー内の送信元ＩＰアドレス欄に記入されているＩＰアドレスと、ＴＦＴＰパケット内のファイル名欄に記入されているファイル名との組み合わせが対応表３００に登録されているのかを確認する。
【００７１】
この組合せが対応表３００に登録されている場合には、そのまま、ＴＦＴＰサーバ３での処理を継続する。一方、この組合せが対応表３００に登録されていない場合には、抽出したイーサネットフレームを破棄する。
【００７２】
ここで、フィルタ機構３０が上記破棄すべきイーサネットフレームを抽出する過程で、抽出されなかったイーサネットフレームについては、そのまま、ＴＦＴＰサーバ３での処理が継続されることになる。
【００７３】
以上に説明したように、フィルタ機構３０は、ＴＦＴＰサーバ３がイーサネットフレームを受信すると、図３の処理フローに示すように、先ず最初に、ステップ１０で、イーサネットフレームのＩＰヘッダー内のプロトコル欄がＵＤＰであるのか否かを判断して、ＵＤＰでないことを判断するときには、ステップ１５に進んで、イーサネットフレームへのＴＦＴＰサーバ３の処理が継続されるようにする。
【００７４】
一方、ステップ１０で、イーサネットフレームのＩＰヘッダー内のプロトコル欄がＵＤＰであることを判断するときには、ステップ１１に進んで、ＵＤＰヘッダー内の宛先ポート番号欄が６９であるのか否かを判断して、６９でないことを判断するときには、ステップ１５に進んで、イーサネットフレームへのＴＦＴＰサーバ３の処理が継続されるようにする。
【００７５】
一方、ステップ１１で、ＵＤＰヘッダー内の宛先ポート番号欄が６９であることを判断するときには、ステップ１２に進んで、抽出したＴＦＴＰパケットのタイプがＲＲＱまたはＷＲＱであるのか否かを判断して、ＲＲＱまたはＷＲＱでないことを判断するときには、ステップ１５に進んで、イーサネットフレームへのＴＦＴＰサーバ３の処理が継続されるようにする。
【００７６】
一方、ステップ１２で、抽出したＴＦＴＰパケットのタイプがＲＲＱまたはＷＲＱであることを判断するときには、ステップ１３に進んで、ＩＰヘッダー内の送信元ＩＰアドレス欄に記入されているＩＰアドレスと、ＴＦＴＰパケット内のファイル名欄に記入されているファイル名との組み合わせが対応表３００に登録されているのか否かを判断して、登録されていることを判断するときには、ステップ１５に進んで、イーサネットフレームへのＴＦＴＰサーバ３の処理が継続されるようにする。
【００７７】
一方、ステップ１３で、ＩＰヘッダー内の送信元ＩＰアドレス欄に記入されているＩＰアドレスと、ＴＦＴＰパケット内のファイル名欄に記入されているファイル名との組み合わせが対応表３００に登録されていないことを判断するときには、ステップ１４に進んで、受信したイーサネットフレームを破棄する。
【００７８】
このようにして、第１の実施形態例に従う場合、ＴＦＴＰサーバ３は、ディスクレスクライアント１−ｉがファイルの転送を要求してくるときに、ＩＰアドレスに従って、そのディスクレスクライアント１−ｉを識別して、対応表３００に基づいて、その転送要求のファイルの転送が許可されているのか否かを判断して、転送が許可されていない場合には、そのファイルの転送を行わないように処理するのである。
【００７９】
これにより、第１の実施形態例では、不正なディスクレスクライアント１−ｉの取得要求からブートストラップのファイルを保護できるようになる。
【００８０】
次に、図４に従って、第２の実施形態例（上記第３の構成に該当する）について説明する。
【００８１】
ここで、図中、１はディスクレスクライアント、２はＤＨＣＰサーバ、３はＴＦＴＰサーバ、４はファイルサーバ、５はＩＰネットワーク、２０はＤＨＣＰサーバ２の備える設定ファイル（図１１に示したもの）を示している。
【００８２】
第２の実施形態例を実現する場合には、ＴＦＴＰサーバ３にはファイル名変更機構３１が備えられており、このファイル名変更機構３１はファイル名表３１０を保持している。
【００８３】
このファイル名表３１０は、ファイル名を変更する際に、現在設定されているファイル名と同じファイル名を設定しないようにすることを実現するために用意されるものであり、図５に示すように、組み込むディスクレスクライアント１のＭＡＣアドレスに対応付けて、そのディスクレスクライアント１−ｉに転送するブートストラップのファイル名およびＯＳイメージのファイル名を管理する。
【００８４】
以下、説明の便宜上、図５に示すように、組み込むディスクレスクライアント１のＭＡＣアドレスとしてＭＡＣ１、そのディスクレスクライアント１に転送するブートストラップのファイル名としてＢＳ０、そのディスクレスクライアント１に転送するＯＳイメージのファイル名としてＯＩ０を想定する。
【００８５】
あるディスクレスクライアント１をディスクレスブートシステムに組み込むためには、ＤＨＣＰサーバ２の設定ファイル２０に対して、ディスクレスクライアント１のＭＡＣアドレス（ＭＡＣ１）と、このディスクレスクライアント１のためのＩＰアドレスおよびブートストラップのファイル名（ＢＳ０）とを登録するとともに、ＴＦＴＰサーバ３に対して、ブートストラップのファイル（ファイル名ＢＳ０）と、ＯＳイメージのファイル（ファイル名ＯＩ０）とを保存することになる。
【００８６】
この最初の登録時に、ＴＦＴＰサーバ３は、組み込むディスクレスクライアント１のＭＡＣアドレス（ＭＡＣ１）と、そのディスクレスクライアント１に転送するブートストラップのファイル名（ＢＳ０）と、そのディスクレスクライアント１に転送するＯＳイメージのファイル名（ＯＩ０）とをファイル名表３１０に保存する。
【００８７】
これを受けて、ファイル名変更機構３１は、ある一定時間（Ｔ時間）後に、ファイル名表３１０に記入されたＭＡＣ１のブートストラップのファイル名（ＢＳ０）とＯＳイメージのファイル名（ＯＩ０）とを確認して、ＤＨＣＰサーバ２に登録されているＭＡＣ１のブートストラップのファイル名（ＢＳ０）と、ＴＦＴＰサーバ３に保存されているブートストラップのファイル名（ＢＳ０）と、ブートストラップに記入されているＯＳイメージのファイル名（ＯＩ０）と、ＴＦＴＰサーバ３に保存されているＯＳイメージのファイル名（ＯＩ０）とを、確認したファイル名とは別のランダムに発生したファイル名（例えばＢＳ１とＯＩ１）に変更する。
【００８８】
このとき、ファイル名表３１０のブートストラップのファイル名をＢＳ０からＢＳ１に変更するとともに、ファイル名表３１０のＯＳイメージのファイル名をＯＩ０からＯＩ１に変更する。
【００８９】
同様に、ファイル名変更機構３１は、Ｔ時間毎に、ブートストラップのファイル名およびＯＳイメージのファイル名を変更する。
【００９０】
ここでは、ファイル名変更機構３１は、ファイル名表３１０にファイル名が初期登録された時点を起点にして、ある一定時間毎にファイル名の変更処理を行うことで説明したが、複数のディスクレスクライアント１が非同期のタイミングでディスクレスブートシステムに組み込まれることを考慮して、初期登録とは関係のない規定周期に到達するときに全てのファイル名の変更処理を行うようにしてもよい。
【００９１】
この場合には、ファイル名変更機構３１は、図６の処理フローに示すように、先ず最初に、ステップ２０で、前回のファイル名の変更処理から一定時間が経過するのを待って、一定時間の経過を検出すると、ステップ２１に進んで、ファイル名表３１０に記入されている全てのブートストラップのファイル名および全てのＯＳイメージのファイル名を確認する。
【００９２】
続いて、ステップ２２で、確認したブートストラップのファイル名とは異なるファイル名をランダムに生成するとともに、確認したＯＳイメージのファイル名とは異なるファイル名をランダムに生成する。
【００９３】
続いて、ステップ２３で、ＤＨＣＰサーバ２に登録されている全てのブートストラップのファイル名と、ＴＦＴＰサーバ３に保存されている全てのブートストラップのファイル名と、全てのブートストラップに記入されているＯＳイメージのファイル名と、ＴＦＴＰサーバ３に保存されている全てのＯＳイメージのファイル名とを、ステップ２２で生成したファイル名に変更する。
【００９４】
続いて、ステップ２４で、ファイル名表３１０に記入されている全てのブートストラップのファイル名と全てのＯＳイメージのファイル名とを、ステップ２２で生成したファイル名に変更してから、ステップ２０に戻る。
【００９５】
このようにして、第２の実施形態例に従う場合には、ＴＦＴＰサーバ３は、周期的に、全てのブートストラップのファイル名および全てのＯＳイメージのファイル名を変更するとともに、その変更したブートストラップのファイル名を、ＤＨＣＰサーバを介して正当なディスクレスクライアント１に間接的に通知するように処理するのである。
【００９６】
ここで、全てのブートストラップのファイル名および全てのＯＳイメージのファイル名を変更するのではなくて、一部のファイル名を変更するようにしてもよい。
【００９７】
これにより、第２の実施形態例では、不正なディスクレスクライアント１の取得要求からブートストラップのファイルを保護できるようになる。
【００９８】
次に、図７に従って、第３の実施形態例（上記第４の構成に該当する）について説明する。
【００９９】
ここで、図中、１−ｉ（ｉ＝１〜ｎ）はディスクレスクライアント、２はＤＨＣＰサーバ、３はＴＦＴＰサーバ、４はファイルサーバ、５はＩＰネットワーク、、２０は設定ファイル、３１はファイル名変更機構、３１０はファイル名表を示している。
【０１００】
第３の実施形態例を実現する場合には、ＴＦＴＰサーバ３にはファイル転送要求監視機構３２が備えられ、ファイル名変更機構３１は、周期的にファイル名の変更処理を行うのではなくて、このファイル転送要求監視機構３２からの実行指示に応答して、ファイル名の変更処理を実行することになる。
【０１０１】
第２の実施形態例と同様に、あるディスクレスクライアント１−ｉをディスクレスブートシステムに組み込むためには、ＤＨＣＰサーバ２の設定ファイル２０に対して、ディスクレスクライアント１−ｉのＭＡＣアドレス（例えばＭＡＣ１）と、このディスクレスクライアント１−ｉのためのＩＰアドレスおよびブートストラップのファイル名（例えばＢＳ０）とを登録するとともに、ＴＦＴＰサーバ３に対して、ブートストラップのファイル（例えばファイル名ＢＳ０）と、ＯＳイメージのファイル（例えばファイル名ＯＩ０）とを保存することになる。
【０１０２】
この最初の登録時に、ＴＦＴＰサーバ３は、組み込むディスクレスクライアント１−ｉのＭＡＣアドレス（例えばＭＡＣ１）と、そのディスクレスクライアント１−ｉに転送するブートストラップのファイル名（例えばＢＳ０）と、そのディスクレスクライアント１−ｉに転送するＯＳイメージのファイル名（例えばＯＩ０）とをファイル名表３１０に保存する。
【０１０３】
ファイル転送要求監視機構３２は、ＴＦＴＰサーバ３へのＯＳイメージのファイル転送要求を監視しており、ＯＳイメージのファイル（例えばＯＩ０）の転送終了後に、その転送終了と転送先ディスクレスクライアント１−ｉのＭＡＣアドレス（例えばＭＡＣ１）とをファイル名変更機構３１に通知する。
【０１０４】
この通知を受けて、ファイル名変更機構３１は、ファイル名表３１０に記入されたＭＡＣ１の指すブートストラップのファイル名（例えばＢＳ０）とＯＳイメージのファイル名（例えばＯＩ０）とを確認して、ＤＨＣＰサーバ２に登録されているＭＡＣ１の指すブートストラップのファイル名（例えばＢＳ０）と、ＴＦＴＰサーバ３に保存されているそのブートストラップのファイル名（例えばＢＳ０）と、そのブートストラップに記入されているＯＳイメージのファイル名（例えばＯＩ０）と、ＴＦＴＰサーバ３に保存されているそのＯＳイメージのファイル名（例えばＯＩ０）とを、確認したファイル名とは別のランダムに発生したファイル名（例えばＢＳ１とＯＩ１）に変更する。
【０１０５】
このとき、ファイル名表３１０のブートストラップのファイル名を例えばＢＳ０からＢＳ１に変更するとともに、ファイル名表３１０のＯＳイメージのファイル名を例えばＯＩ０からＯＩ１に変更する。
【０１０６】
このようにして、ファイル名変更機構３１は、図８の処理フローに示すように、先ず最初に、ステップ３０で、ファイル転送要求監視機構３２からＯＳイメージの転送終了通知が発行されるのを待って、ＯＳイメージの転送終了通知が発行されると、ステップ３１に進んで、転送先ディスクレスクライアント１−ｉのＭＡＣアドレスを受け取る。
【０１０７】
続いて、ステップ３２で、ファイル名表３１０に記入されている受け取ったＭＡＣアドレスの指すブートストラップのファイル名およびＯＳイメージのファイル名を確認する。
【０１０８】
続いて、ステップ３３で、確認したブートストラップのファイル名とは異なるファイル名をランダムに生成するとともに、確認したＯＳイメージのファイル名とは異なるファイル名をランダムに生成する。
【０１０９】
続いて、ステップ３４で、受け取ったＭＡＣアドレスが直接的又は間接的に指す、ＤＨＣＰサーバ２に登録されているブートストラップのファイル名と、ＴＦＴＰサーバ３に保存されているブートストラップのファイル名と、ブートストラップに記入されているＯＳイメージのファイル名と、ＴＦＴＰサーバ３に保存されているＯＳイメージのファイル名とを、ステップ３３で生成したファイル名に変更する。
【０１１０】
続いて、ステップ３５で、ファイル名表３１０に記入されている受け取ったＭＡＣアドレスの指すブートストラップのファイル名およびＯＳイメージのファイル名とを、ステップ３３で生成したファイル名に変更してから、ステップ３０に戻る。
【０１１１】
このようにして、第３の実施形態例に従う場合には、ＴＦＴＰサーバ３は、ＯＳイメージをディスクレスクライアント１−ｉへ転送すると、その転送を契機として、転送したファイルのファイル名を変更するように処理するのである。
【０１１２】
これにより、第３の実施形態例では、不正なディスクレスクライアント１の取得要求からブートストラップのファイルを保護できるようになる。
【０１１３】
次に、第４の実施形態例（上記第５の構成に該当する）について説明する。
【０１１４】
第３の実施形態例では、ＯＳイメージの転送を契機にして、転送したファイルのファイル名を変更するようにしているが、第４の実施形態例では、ＯＳイメージの転送の成功失敗に関係なく、それを契機にして全てのファイル名を変更するようにしている点に違いがある。
【０１１５】
すなわち、第４の実施形態例に従う場合には、ファイル転送要求監視機構３２は、ＴＦＴＰサーバ３へのＯＳイメージのファイル転送要求を監視しており、ＯＳイメージのファイルを転送要求された場合、転送が成功しても失敗しても、転送要求がなされたことをファイル名変更機構３１に通知する。
【０１１６】
この通知を受けて、ファイル名変更機構３１は、ファイル名表３１０に記入された全てのブートストラップのファイル名および全てのＯＳイメージのファイル名に関して、ＤＨＣＰサーバ２に登録されているブートストラップのファイル名と、ＴＦＴＰサーバ３に保存されているブートストラップのファイル名と、ブートストラップに記入されているＯＳイメージのファイル名と、ＴＦＴＰサーバ３に保存されているＯＳイメージのファイル名とを、ランダムに発生した別のファイル名に変更する。
【０１１７】
このとき、ファイル名表３１０のブートストラップのファイル名とＯＳイメージのファイル名とについても変更した通りに変更する。
【０１１８】
このようにして、ファイル名変更機構３１は、第４の実施形態例に従う場合には、図９の処理フローに示すように、先ず最初に、ステップ４０で、ファイル転送要求監視機構３２からＯＳイメージの転送成功または失敗通知が発行されるのを待って、ＯＳイメージの転送成功または失敗通知が発行されると、ステップ４１に進んで、ファイル名表３１０に記入されている全てのブートストラップのファイル名および全てのＯＳイメージのファイル名を確認する。
【０１１９】
続いて、ステップ４２で、確認したブートストラップのファイル名とは異なるファイル名をランダムに生成するとともに、確認したＯＳイメージのファイル名とは異なるファイル名をランダムに生成する。
【０１２０】
続いて、ステップ４３で、ＤＨＣＰサーバ２に登録されている全てのブートストラップのファイル名と、ＴＦＴＰサーバ３に保存されている全てのブートストラップのファイル名と、全てのブートストラップに記入されているＯＳイメージのファイル名と、ＴＦＴＰサーバ３に保存されている全てのＯＳイメージのファイル名とを、ステップ４２で生成したファイル名に変更する。
【０１２１】
続いて、ステップ４４で、ファイル名表３１０に記入されている全てのブートストラップのファイル名と全てのＯＳイメージのファイル名とを、ステップ４２で生成したファイル名に変更してから、ステップ４０に戻る。
【０１２２】
このようにして、ファイル名変更機構３１は、第３の実施形態例に従う場合には、ＯＳイメージの転送を契機にして、転送したファイルのファイル名を変更するのに対して、第４の実施形態例に従う場合には、ＯＳイメージの転送の成功失敗に関係なく、それを契機にして、全てのファイルのファイル名を変更するように処理することになる。
【０１２３】
これにより、第４の実施形態例では、不正なディスクレスクライアント１の取得要求からブートストラップのファイルを保護できるようになる。
【０１２４】
【発明の効果】
以上説明したように、本発明によれば、上述の構成のフィルタ機構を用意することで、ディスクレスクライアントのＩＰアドレスに従って、ＴＦＴＰサーバが転送を許可するブートストラップやＯＳイメージを決定できるため、他のディスクレスクライアントがあるディスクレスクライアントに成りすまして、ブートストラップやＯＳイメージを取得することを防ぐことができる。
【０１２５】
また、本発明によれば、上述の構成のファイル名変更機構を用意することで、ＴＦＴＰサーバが保持するブートストラップのファイル名やＯＳイメージのファイル名を変更することにより、ファイル名を入手した不正なクライアントが、入手したファイル名を指定してＴＦＴＰサーバからのファイルの転送を試みても、既にそのファイルのファイル名が変更されていることから、不正なクライアントが指定したファイルが存在しないことにより、ファイルの転送を失敗させることができ、ブートデータの漏洩を防ぐことができる。
【０１２６】
このようにして、本発明によれば、クライアントの認証を行わない転送プロトコルで動作して、転送要求のあるファイルをクライアントに転送するファイル提供装置と、クライアントの認証を行って、クライアントに対して、ファイル提供装置のネットワークアドレスとそのクライアントに転送するファイルのファイル名とを通知する仲介サーバとで構成されるシステムにおいて、正しいクライアントにのみファイルを転送し、正しくないクライアントにはファイルを転送しないことを実現できるようになり、これにより、クライアントの成りすましによるファイルデータの漏洩を防ぐことができるようになる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態例である。
【図２】フィルタ機構の持つ対応表の一例を示す図である。
【図３】フィルタ機構の実行する処理フローである。
【図４】本発明の第２の実施形態例である。
【図５】ファイル名変更機構の持つファイル名表の一例を示す図である。
【図６】ファイル名変更機構の実行する処理フローである。
【図７】本発明の第３の実施形態例である。
【図８】ファイル名変更機構の実行する処理フローである。
【図９】ファイル名変更機構の実行する処理フローである。
【図１０】ディスクレスブートシステムのシステム構成図である。
【図１１】ＤＨＣＰサーバの持つ設定ファイルの説明図である。
【符号の説明】
１ディスクレスクライアント
２ＤＨＣＰサーバ
３ＴＦＴＰサーバ
４ファイルサーバ
５ＩＰネットワーク
２０設定ファイル
３０フィルタ機構
３１ファイル名変更機構
３２ファイル転送要求監視機構
３００対応表
３１０ファイル名表[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a file providing apparatus and method used in a system including a file providing apparatus and an intermediary server, a file providing program used for realizing the file providing method, and a recording medium recording the program.
[0002]
A file providing device that operates with a transfer protocol that does not authenticate the client and transfers a file that has a transfer request to the client, and authenticates the client to the client to provide the network address of the file providing device and the client There is a system configured with an intermediary server that notifies a file name of a file to be transferred.
[0003]
The present invention relates to a file providing device and method used in such a system, a file providing program used for realizing the file providing method, and a recording medium recording the program, and more specifically, The present invention relates to a technology for ensuring a safe boot in a diskless boot system environment.
[0004]
[Prior art]
Conventionally, in a diskless boot system, a diskless client, a DHCP server, a TFTP server, and a file server are connected to an IP network (for example, see Patent Document 1).
[0005]
(1) Diskless client processing
The booting diskless client first queries the DHCP server. The DHCP server that has received this inquiry replies to the diskless client with the IP address to be assigned to the diskless client, the IP address of the TFTP server, and the bootstrap file name to be obtained from the TFTP server.
[0006]
The diskless client then obtains a bootstrap file from the TFTP server using a simple file transfer protocol (TFTP) based on the response of the DHCP server.
[0007]
The diskless client then executes the obtained bootstrap and uses the TFTP server to download the OS image file from the TFTP server based on the operating system (OS) image file name described in the bootstrap. And get.
[0008]
The diskless client then boots using the acquired OS image. The IP address and the file system name of the file server to be used by the diskless client are described in the OS image.
[0009]
The diskless client then connects to the file server, mounts an available file system, and completes booting.
[0010]
(2) TFTP server processing
The TFTP server provides the connecting client with only reading or writing of the file specified by the file name. The TFTP server does not authenticate the connecting client.
[0011]
In a diskless boot system, since it is difficult to provide a diskless client with many functions and information, a TFTP that has few functions and is easy to mount is often used.
[0012]
(3) DHCP server processing
The DHCP server can identify the diskless client by the value of the MAC address used by the diskless client inquiring. Therefore, the DHCP server can identify the diskless client based on the value of the MAC address, and change the IP address to be answered, the IP address of the TFTP server, and the file name of the bootstrap for each diskless client.
[0013]
Of course, it is also possible for the DHCP server to reply with the same TFTP server IP address and the same bootstrap file name by changing only the replying IP address without identifying the diskless client.
[0014]
Therefore, in the diskless boot system, a plurality of bootstrap files, a plurality of OS image files, and a plurality of file systems are prepared, and the DHCP server can use different bootstrap files based on the MAC address of the diskless client. By answering the names, it is possible to boot a plurality of diskless clients in different OS environments.
[0015]
FIG. 10 is an example of a diskless boot system having two diskless clients. Diskless clients DC1 and DC2, a DHCP server, a TFTP server, and a file server are connected by an IP network.
[0016]
The diskless client DC1 has a MAC address “MAC1”, and the diskless client DC2 has a MAC address “MAC2”. The TFTP server uses the IP address “IPt”.
[0017]
The TFTP server includes a bootstrap file “BS1” for DC1, an OS image file “OI1” for DC1, a bootstrap file “BS2” for DC2, and an OS image file “OI2” for DC2. And have
[0018]
The file server has a file system “FS1” for DC1 and a file system “FS2” for DC2.
[0019]
The DHCP server has a configuration file, an IP address “IP1” for DC1, and an IP address “IP2” for DC2.
[0020]
As illustrated in FIG. 11, in the setting file of the DHCP server, the inquiry from DC1 includes the IP address “IP1”, the IP address “IPt” of the TFTP server, and the file name “BS1” of the bootstrap. In the inquiry from DC2, it is described that the IP address “IP2”, the IP address “IPt” of the TFTP server, and the file name “BS2” of the bootstrap are answered.
[0021]
In the example of FIG. 10, the diskless client DC1 to be booted obtains a bootstrap file “BS1” from the TFTP server using the IP address “IP1” as a result of making an inquiry to the DHCP server. Thereafter, the diskless client DC1 obtains the OS image “OI1” from the TFTP server, starts it, and mounts the file system “FS1”.
[0022]
Similarly, as a result of making an inquiry to the DHCP server, the diskless client DC2 to boot acquires the bootstrap file “BS2” from the TFTP server using the IP address “IP2”. After that, the diskless client DC2 obtains the OS image “OI2” from the TFTP server, starts it, and mounts the file system “FS2”.
[0023]
As a result, the diskless client DC1 and the diskless client DC2 are activated in different OS environments.
[0024]
[Patent Document 1]
JP-A-2002-123400
[0025]
[Problems to be solved by the invention]
However, the diskless boot system realized by the conventional technique has a problem that the impersonation of the diskless client can be easily performed because the TFTP does not require authentication. That is, there is a problem that a certain diskless client can boot and operate as another diskless client.
[0026]
For example, in FIG. 10, the diskless client DC2 that has received a response from the DHCP server to obtain the bootstrap file “BS2” does not follow this, but obtains the OS image “OI1” from the TFTP server and boots. If it continues, the boot can be completed easily as the diskless client DC1.
[0027]
TFTP is a protocol that does not perform client authentication. Consider a case where a certain UNIX computer (UNIX is a registered trademark) connects to a TFTP server and transfers a file.
[0028]
When the operator of the UNIX computer inputs "get file name" to the console, if a file having the specified "file name" exists on the TFTP server, the TFTP server copies the specified file to the UNIX computer. Transfer to On the other hand, if a file having the specified “file name” does not exist on the TFTP server, an error occurs and the file is not transferred.
[0029]
Therefore, even if it is not a diskless client, if a UNIX computer is connected to the IP network of the diskless boot system, there is a problem that all files on the TFTP server can be easily obtained.
[0030]
From now on, the TFTP server will transfer the bootstrap file and the OS image file only to the correct diskless client, and will not transfer the file to the incorrect diskless client. It is necessary to prevent boot data leakage due to
[0031]
The present invention has been made in view of such circumstances, and operates by a transfer protocol that does not perform client authentication, performs a file providing device that transfers a file with a transfer request to a client, and performs client authentication. In a system configured with a mediation server that notifies a client of a network address of a file providing device and a file name of a file to be transferred to the client, a file is transferred only to a correct client, and a file is transferred to an incorrect client. The purpose of this is to provide a new technology that prevents the transfer of data.
[0032]
[Means for Solving the Problems]
In order to achieve this object, the file providing device of the present invention operates with a transfer protocol that does not perform client authentication, and performs file authentication with a file providing device that transfers a file requested to be transferred to the client. When used in a system composed of a mediation server for notifying a client of a network address of a file providing device and a file name of a file to be transferred to the client, a (1) transfer request is issued. Storage means for storing a file name of a file permitted to be transferred to the client in association with a network address of the client which may come, and (2) a network of the client according to a file transfer request issued from the client. Get address and file name of transfer request (3) a determining means for determining whether or not paired data of a network address and a file name obtained by the obtaining means are stored in the storage means; and (4) a network address obtained by the obtaining means. Transfer means for discarding the transfer request when the pair data of the file name and the file name is not stored in the storage means, and transferring the file indicated by the file name obtained by the obtaining means to the client when the data is stored in the storage means. It comprises so that it may have.
[0033]
The file providing method of the present invention realized by the operation of each of the above-described processing means can be realized by a computer program. The computer program is provided by being recorded on an appropriate recording medium such as a semiconductor memory. Or can be provided via a network.
[0034]
In the file providing apparatus of the present invention configured as described above, when a file transfer request is issued from a client, the network address of the client and the file name of the transfer request are acquired according to the file transfer request.
[0035]
Subsequently, it is determined whether or not the paired data of the acquired network address and file name is stored in the storage means. If not, the transfer request is discarded. , The file indicated by the obtained file name is transferred to the client.
[0036]
As described above, according to the present invention, a file providing device that operates with a transfer protocol that does not perform client authentication and transfers a file with a transfer request to a client, performs client authentication, In a system including a network address of a file providing device and an intermediary server for notifying a file name of a file to be transferred to the client, the system is associated with a network address of a client that may issue a transfer request, By providing a storage device that stores the file name of the file that is permitted to be transferred to that client and using it to control file transfer, transfer files only to the correct client and send it to the wrong client. Can realize that no files are transferred It made.
[0037]
Further, in order to achieve the above object, a file providing device of the present invention operates with a transfer protocol that does not perform client authentication, and a file providing device that transfers a file requested to be transferred to a client. When used in a system configured with a mediation server for notifying a client of a network address of a file providing device and a file name of a file to be transferred to the client, (1) the file name Judgment means for judging whether or not the change trigger has been reached, and (2) when the file name change trigger has been reached, change part or all of the file names of the transfer target files stored in the own device. And a changing means for changing the file name registered in the mediation server.
[0038]
The file providing method of the present invention realized by the operation of each of the above-described processing means can be realized by a computer program. The computer program is provided by being recorded on an appropriate recording medium such as a semiconductor memory. Or can be provided via a network.
[0039]
In the file providing apparatus of the present invention configured as described above, for example, when it is determined that a file name change opportunity has been reached by reaching a specified period, one of the transfer target files stored in the own apparatus is determined. A part or all the file names are changed, and the file names registered in the mediation server are changed. Further, for example, when it is determined that a file name change trigger has been reached because a file transfer has been performed to the client, the file name is changed with the file name of the transfer file being changed. Also, for example, when it is determined that a file transfer request has been issued from the client and the file name change trigger has been reached, the file names of all files to be transferred are changed regardless of the success or failure of the file transfer. Change the file name as the target.
[0040]
As described above, according to the present invention, a file providing device that operates with a transfer protocol that does not perform client authentication and transfers a file with a transfer request to a client, performs client authentication, In a system including a network address of a file providing device and a transfer server that notifies a file name of a file to be transferred to the client, the file name is changed, and the changed file name is transmitted to the client via the transfer server. By providing a mechanism to be notified and using it to control file transfer, it is possible to transfer files only to the correct client and not transfer files to the wrong client become.
[0041]
Next, (1) one or more diskless clients and (2) the network information such as the IP address, the IP address of the TFTP server, and the file name of the bootstrap downloaded from the TFTP server are provided to the disk client. A diskless boot system in which a DHCP server, (3) a TFTP server holding a bootstrap and an OS image downloaded by a diskless client, and (4) a file server holding a root partition mounted by the diskless client are connected to an IP network. The configuration of the present invention will be described in detail with a specific example of application to the present invention.
[0042]
In the present invention, it is assumed that the diskless client does not spoof the MAC address and the IP address obtained from the DHCP server. A technique for preventing such spoofing uses another technique, and is not described in the present invention.
[0043]
(1) First configuration
In order to achieve the above object, in the present invention, as a first configuration, a TFTP server identifies a client based on an IP address of a connecting client and permits transfer of a file specified by the client, or Provide a configuration to prohibit transfer.
[0044]
Specifically, the TFTP server has a correspondence table between the IP address of the diskless client, the file name of the bootstrap file, and the file name of the OS image, and the TFTP server transmits the IP address different from the IP address described in the correspondence table. When an acquisition request by a TFTP is received for a file of a certain bootstrap file or an OS image, the acquisition request is discarded.
[0045]
That is, the TFTP server newly has a table indicating the correspondence between the IP address of the client to be connected and the file name of the file permitted to be transferred to the client. When the client connects, the TFTP server recognizes the IP address of the client, and based on this table, permits or prohibits the transfer (read or write) of the file specified by the client, and prohibits the transfer. Only perform the specified file transfer.
[0046]
With this configuration, it is possible to prevent an unauthorized file transfer from the TFTP server in the diskless boot system.
[0047]
(2) Second configuration
In order to achieve the above object, the present invention provides, as a second configuration, a configuration in which the TFTP server automatically changes the file name of a file held by the TFTP server. In TFTP, it is necessary to specify the name of the file to be transferred, so if the file name is not known, it is possible to prevent the transfer of an unauthorized file.
[0048]
More specifically, the bootstrap file name stored in the TFTP server, the OS image file name stored in the TFTP server, the bootstrap file name registered in the DHCP server, and the bootstrap file name are described. A configuration is adopted in which the file name of the existing OS image is changed to another file name generated at random.
[0049]
That is, a new function of automatically renaming a file is newly added to the TFTP server, the TFTP server is changed to a file name that is difficult to be guessed at an appropriate timing, and only the legitimate client is notified of the changed file name. Therefore, in response to a file transfer request from a client, the file transfer succeeds by specifying the existing file name for the legitimate client and the existing file name must not be specified for the unauthorized client. Can cause the file transfer to fail.
[0050]
With this configuration, it is possible to prevent an unauthorized file transfer from the TFTP server in the diskless boot system.
[0051]
Here, since the first configuration and the second configuration are contrary configurations, it is possible to mount one or both of them on the TFTP server.
[0052]
(3) Third to fifth configurations
In addition, in order to achieve the above object, the present invention provides three more configurations with respect to the trigger for changing the file name in the second configuration.
[0053]
(3-1) Third configuration
In order to achieve the above object, the present invention provides, as a third configuration, a configuration in which a trigger for changing a file name in the second configuration is a time interval determined by an administrator.
[0054]
That is, the TFTP server periodically changes a part or all of the file name of the file whose file name is to be changed to a new file name that is hard to guess.
[0055]
With this configuration, even if an unauthorized client that obtains the file name of the file held by the TFTP server attempts to obtain the file from the TFTP server by specifying the obtained file name, the file name has already been changed, It is possible to cause the file transfer to fail.
[0056]
(3-2) Fourth configuration
In order to achieve the above object, the present invention provides, as a fourth configuration, a configuration in which the trigger of the change of the file name in the second configuration is a point in time when a valid file is transferred.
[0057]
That is, the TFTP server requested to transfer the file from the legitimate client changes the file name of the transferred file in response to the transfer of the file.
[0058]
With this configuration, an unauthorized client monitoring the transfer of a file by a legitimate client obtains the file name of the file currently transferred by some method, designates the obtained file name, and downloads the file from the TFTP server. Even if the transfer is attempted, the file transfer can be failed because the file name has already been changed and the file specified by the unauthorized client does not exist.
[0059]
(3-3) Fifth configuration
In order to achieve the above object, the present invention provides, as a fifth configuration, a configuration in which the timing of changing the file name in the second configuration is set to the time of file transfer.
[0060]
In the above second, third, and fourth configurations, the file held by the TFTP server is merely changed to a file name that is difficult to guess. When a transfer is requested by specifying the file name, there is a possibility that the file name coincides and the transfer succeeds.
[0061]
To avoid this, in the fifth configuration, the request to change the file names of all the files held by the TFTP server is triggered by a TFTP file transfer request regardless of the success or failure of the transfer.
[0062]
That is, even if an unauthorized client specifies the file names of all possible patterns in a brute force manner and requests transfer, the file names of all files are changed every time transfer fails. You can reduce the chance of accidentally matching file names.
[0063]
BEST MODE FOR CARRYING OUT THE INVENTION
Next, the present invention will be described in detail with reference to the drawings.
[0064]
First, a first embodiment (corresponding to the first configuration) will be described with reference to FIG.
[0065]
Here, in the figure, 1-i (i = 1 to n) denotes a diskless client, 2 denotes a DHCP server, 3 denotes a TFTP server, 4 denotes a file server, and 5 denotes an IP network.
[0066]
In the case of realizing the first embodiment, the TFTP server 3 is provided with a filter mechanism 30, and this filter mechanism 30 holds a correspondence table 300.
[0067]
As shown in FIG. 2, the correspondence table 300 stores, in association with the IP address of the diskless client 1-i, the file name of the bootstrap and the OS image that are permitted to be transferred to the diskless client 1-i. Manage file names.
[0068]
The filter mechanism 30 first extracts an Ethernet frame including a TFTP packet from Ethernet frames (Ethernet is a registered trademark) received by the TFTP server 3.
[0069]
Regarding this extraction, it is determined that the Ethernet frame in which the protocol column in the IP header of the Ethernet frame received by the TFTP server 3 is UDP and the destination port number in the UDP header is 69 is an Ethernet frame including a TFTP packet. This is done by extraction.
[0070]
Subsequently, of the extracted Ethernet frames, an Ethernet frame including a TFTP packet whose type is Read request (RRQ) or Write request (WRQ) is further extracted, and the extracted Ethernet frame is written in the source IP address field in the IP header. It is checked whether the combination of the existing IP address and the file name entered in the file name column in the TFTP packet is registered in the correspondence table 300.
[0071]
If this combination is registered in the correspondence table 300, the processing in the TFTP server 3 is continued as it is. On the other hand, if this combination is not registered in the correspondence table 300, the extracted Ethernet frame is discarded.
[0072]
Here, in the process of extracting the Ethernet frame to be discarded by the filter mechanism 30, the processing in the TFTP server 3 is continued for the Ethernet frame not extracted.
[0073]
As described above, when the TFTP server 3 receives the Ethernet frame, the filter mechanism 30 first sets the protocol column in the IP header of the Ethernet frame in step 10 as shown in the processing flow of FIG. When it is determined whether or not it is UDP, and when it is determined that it is not UDP, the process proceeds to step 15 so that the processing of the TFTP server 3 for the Ethernet frame is continued.
[0074]
On the other hand, when it is determined in step 10 that the protocol column in the IP header of the Ethernet frame is UDP, the process proceeds to step 11 to determine whether the destination port number column in the UDP header is 69. , 69, the process proceeds to step 15 so that the processing of the TFTP server 3 for the Ethernet frame is continued.
[0075]
On the other hand, when it is determined in step 11 that the destination port number field in the UDP header is 69, the process proceeds to step 12, where it is determined whether the type of the extracted TFTP packet is RRQ or WRQ. When it is determined that the frame is not RRQ or WRQ, the process proceeds to step 15 so that the processing of the TFTP server 3 for the Ethernet frame is continued.
[0076]
On the other hand, if it is determined in step 12 that the type of the extracted TFTP packet is RRQ or WRQ, the process proceeds to step 13 in which the IP address written in the source IP address field in the IP header and the TFTP packet It is determined whether or not the combination with the file name entered in the file name column in the table is registered in the correspondence table 300. The processing of the TFTP server 3 is continued.
[0077]
On the other hand, in step 13, the combination of the IP address written in the source IP address field in the IP header and the file name written in the file name field in the TFTP packet is not registered in the correspondence table 300. If it is determined, the process proceeds to step 14 where the received Ethernet frame is discarded.
[0078]
In this way, in the case of the first embodiment, when the diskless client 1-i requests a file transfer, the TFTP server 3 identifies the diskless client 1-i according to the IP address. Based on the correspondence table 300, it is determined whether or not the transfer of the file of the transfer request is permitted. If the transfer is not permitted, processing is performed so as not to transfer the file. is there.
[0079]
Thus, in the first embodiment, the bootstrap file can be protected from an unauthorized acquisition request of the diskless client 1-i.
[0080]
Next, a second embodiment (corresponding to the third configuration) will be described with reference to FIG.
[0081]
Here, 1 is a diskless client, 2 is a DHCP server, 3 is a TFTP server, 4 is a file server, 5 is an IP network, and 20 is a setting file (shown in FIG. 11) provided in the DHCP server 2. ing.
[0082]
In the case of realizing the second embodiment, the TFTP server 3 is provided with a file name changing mechanism 31, and this file name changing mechanism 31 holds a file name table 310.
[0083]
This file name table 310 is prepared to realize that the same file name as the currently set file name is not set when changing the file name. As shown in FIG. The bootstrap file name and the OS image file name to be transferred to the diskless client 1-i are managed in association with the MAC address of the diskless client 1 to be incorporated.
[0084]
Hereinafter, for convenience of explanation, as shown in FIG. 5, MAC1 is the MAC address of the diskless client 1 to be incorporated, BS0 is the file name of the bootstrap to be transferred to the diskless client 1, and the file name of the OS image to be transferred to the diskless client 1. Is assumed to be OI0.
[0085]
In order to incorporate a certain diskless client 1 into a diskless boot system, a MAC file (MAC1) of the diskless client 1 and a file of an IP address and a bootstrap for the diskless client 1 are added to a setting file 20 of the DHCP server 2. In addition to registering the name (BS0), the bootstrap file (file name BS0) and the OS image file (file name OI0) are stored in the TFTP server 3.
[0086]
At the time of the first registration, the TFTP server 3 transmits the MAC address (MAC1) of the diskless client 1 to be incorporated, the file name (BS0) of the bootstrap to be transferred to the diskless client 1, and the OS image to be transferred to the diskless client 1. The file name (OI0) is stored in the file name table 310.
[0087]
In response to this, the file name changing mechanism 31 confirms the file name of the bootstrap file (BS0) of the MAC1 and the file name of the OS image (OI0) entered in the file name table 310 after a certain time (T time). Then, the bootstrap file name (BS0) of MAC1 registered in the DHCP server 2, the bootstrap file name (BS0) stored in the TFTP server 3, and the OS image written in the bootstrap (OI0) and the OS image file name (OI0) stored in the TFTP server 3 are changed to randomly generated file names (for example, BS1 and OI1) different from the confirmed file names. .
[0088]
At this time, the file name of the bootstrap in the file name table 310 is changed from BS0 to BS1, and the file name of the OS image in the file name table 310 is changed from OI0 to OI1.
[0089]
Similarly, the file name changing mechanism 31 changes the file name of the bootstrap and the file name of the OS image every T time.
[0090]
Here, the file name changing mechanism 31 has been described as performing the file name changing process at certain time intervals starting from the time when the file name is initially registered in the file name table 310. Considering that the file is incorporated into the diskless boot system at an asynchronous timing, all the file names may be changed when the specified period irrespective of the initial registration is reached.
[0091]
In this case, as shown in the processing flow of FIG. 6, first, in step 20, the file name change mechanism 31 waits for a certain time to elapse from the previous file name change processing, When the process has been completed, the process proceeds to step 21, where the file names of all bootstraps and the file names of all OS images entered in the file name table 310 are confirmed.
[0092]
Subsequently, in step 22, a file name different from the confirmed bootstrap file name is randomly generated, and a file name different from the confirmed OS image file name is randomly generated.
[0093]
Subsequently, in step 23, the file names of all bootstraps registered in the DHCP server 2, the file names of all bootstraps stored in the TFTP server 3, and all the bootstraps are entered. The file names of the OS images and the file names of all OS images stored in the TFTP server 3 are changed to the file names generated in step 22.
[0094]
Subsequently, in step 24, the file names of all the bootstraps and the file names of all the OS images entered in the file name table 310 are changed to the file names generated in step 22, and the process returns to step 20. .
[0095]
In this way, in the case of following the second embodiment, the TFTP server 3 periodically changes the file names of all the bootstrap files and the file names of all the OS images, and changes the changed bootstrap file names. Is indirectly notified to the legitimate diskless client 1 via the DHCP server.
[0096]
Here, instead of changing all the bootstrap file names and all OS image file names, a part of the file names may be changed.
[0097]
As a result, in the second embodiment, the bootstrap file can be protected from an unauthorized acquisition request of the diskless client 1.
[0098]
Next, a third embodiment (corresponding to the fourth configuration) will be described with reference to FIG.
[0099]
Here, in the figure, 1-i (i = 1 to n) is a diskless client, 2 is a DHCP server, 3 is a TFTP server, 4 is a file server, 5 is an IP network, 20 is a setting file, 31 is a file name A change mechanism 310 indicates a file name table.
[0100]
In the case of realizing the third embodiment, the TFTP server 3 is provided with a file transfer request monitoring mechanism 32, and the file name changing mechanism 31 does not periodically perform a file name changing process. In response to the execution instruction from the file transfer request monitoring mechanism 32, the file name is changed.
[0101]
As in the second embodiment, in order to incorporate a certain diskless client 1-i into the diskless boot system, the MAC address (for example, MAC1) of the diskless client 1-i is added to the setting file 20 of the DHCP server 2. The IP address and the bootstrap file name (for example, BS0) for the diskless client 1-i are registered, and the bootstrap file (for example, the file name BS0) and the OS image A file (for example, file name OI0) is to be saved.
[0102]
At the time of the first registration, the TFTP server 3 sets the MAC address (for example, MAC1) of the diskless client 1-i to be incorporated, the file name of the bootstrap (for example, BS0) to be transferred to the diskless client 1-i, and the diskless client 1-i. The file name (for example, OI0) of the OS image to be transferred to i is stored in the file name table 310.
[0103]
The file transfer request monitoring mechanism 32 monitors an OS image file transfer request to the TFTP server 3, and after the transfer of the OS image file (for example, OI0), the transfer end and the transfer destination diskless client 1-i. The MAC address (for example, MAC1) is notified to the file name change mechanism 31.
[0104]
Upon receiving this notification, the file name changing mechanism 31 checks the file name of the bootstrap (for example, BS0) and the file name of the OS image (for example, OI0) indicated by the MAC1 written in the file name table 310, and 2, the file name of the bootstrap indicated by the MAC1 (eg, BS0), the file name of the bootstrap stored in the TFTP server 3 (eg, BS0), and the OS image written in the bootstrap The file name (for example, OI0) and the file name of the OS image (for example, OI0) stored in the TFTP server 3 are different from the confirmed file name and are randomly generated file names (for example, BS1 and OI1). Change to
[0105]
At this time, the file name of the bootstrap in the file name table 310 is changed from, for example, BS0 to BS1, and the file name of the OS image in the file name table 310 is changed, for example, from OI0 to OI1.
[0106]
In this way, as shown in the processing flow of FIG. 8, the file name change mechanism 31 first waits for the OS image transfer end notification from the file transfer request monitoring mechanism 32 to be issued in step 30. Then, when an OS image transfer end notification is issued, the process proceeds to step 31, where the MAC address of the transfer destination diskless client 1-i is received.
[0107]
Subsequently, in step 32, the file name of the bootstrap and the file name of the OS image indicated by the received MAC address written in the file name table 310 are confirmed.
[0108]
Subsequently, in step 33, a file name different from the confirmed bootstrap file name is randomly generated, and a file name different from the confirmed OS image file name is randomly generated.
[0109]
Subsequently, in step 34, the file name of the bootstrap registered in the DHCP server 2 and the file name of the bootstrap stored in the TFTP server 3, which are directly or indirectly indicated by the received MAC address, The file name of the OS image written in the bootstrap and the file name of the OS image stored in the TFTP server 3 are changed to the file names generated in step 33.
[0110]
Subsequently, in step 35, the bootstrap file name and the OS image file name indicated by the received MAC address written in the file name table 310 are changed to the file names generated in step 33, and then the step 30 is performed. Return to
[0111]
As described above, when the TFTP server 3 transfers the OS image to the diskless client 1-i according to the third embodiment, the TFTP server 3 changes the file name of the transferred file upon the transfer. Process it.
[0112]
Thus, in the third embodiment, the bootstrap file can be protected from an unauthorized acquisition request of the diskless client 1.
[0113]
Next, a fourth embodiment (corresponding to the fifth configuration) will be described.
[0114]
In the third embodiment, the file name of the transferred file is changed in response to the transfer of the OS image. However, in the fourth embodiment, regardless of the success or failure of the transfer of the OS image. There is a difference in that all file names are changed in response to the change.
[0115]
That is, according to the fourth embodiment, the file transfer request monitoring mechanism 32 monitors a file transfer request of the OS image to the TFTP server 3, and when the file transfer of the OS image is requested, the transfer is performed. Is successful or unsuccessful, the file name change mechanism 31 is notified that the transfer request has been made.
[0116]
In response to this notification, the file name changing mechanism 31 updates the bootstrap file names registered in the DHCP server 2 with respect to all bootstrap file names and all OS image file names entered in the file name table 310. And the file name of the bootstrap stored in the TFTP server 3, the file name of the OS image written in the bootstrap, and the file name of the OS image stored in the TFTP server 3 are randomly generated. To a different file name.
[0117]
At this time, the bootstrap file name and the OS image file name in the file name table 310 are also changed as changed.
[0118]
Thus, in the case of following the fourth embodiment, as shown in the processing flow of FIG. 9, the file name changing mechanism 31 first sends the OS image from the file transfer request monitoring mechanism 32 in step 40. When the notification of success or failure of the transfer of the OS image is issued after the notification of the success or failure of the transfer of the OS image is issued, the process proceeds to step 41, where the file names of all the bootstraps described in the file name table 310 are entered. And the file names of all OS images.
[0119]
Subsequently, in step 42, a file name different from the confirmed bootstrap file name is randomly generated, and a file name different from the confirmed OS image file name is randomly generated.
[0120]
Subsequently, in step 43, the file names of all bootstraps registered in the DHCP server 2, the file names of all bootstraps stored in the TFTP server 3, and all the bootstraps are entered. The file names of the OS images and the file names of all OS images stored in the TFTP server 3 are changed to the file names generated in step 42.
[0121]
Subsequently, in step 44, the file names of all bootstraps and all OS images entered in the file name table 310 are changed to the file names generated in step 42, and the process returns to step 40. .
[0122]
In this manner, in the case of following the third embodiment, the file name changing mechanism 31 changes the file name of the transferred file in response to the transfer of the OS image, whereas the fourth embodiment In the case of following the embodiment, regardless of the success or failure of the transfer of the OS image, the processing is performed so that the file names of all the files are changed with this as an opportunity.
[0123]
Thus, in the fourth embodiment, the bootstrap file can be protected from an unauthorized acquisition request of the diskless client 1.
[0124]
【The invention's effect】
As described above, according to the present invention, the provision of the filter mechanism having the above configuration enables the TFTP server to determine a bootstrap or an OS image to which transfer is permitted according to the IP address of the diskless client. It is possible to prevent bootstrapping and acquiring an OS image by impersonating a diskless client as a diskless client.
[0125]
Further, according to the present invention, by providing the file name changing mechanism having the above-described configuration, by changing the file name of the bootstrap and the file name of the OS image held by the TFTP server, the illegal Even if a client attempts to transfer a file from the TFTP server by specifying the obtained file name, the file name of the file has already been changed. In this case, file transfer can be failed and boot data leakage can be prevented.
[0126]
Thus, according to the present invention, a file providing device that operates with a transfer protocol that does not perform client authentication and transfers a file with a transfer request to the client, performs client authentication, and In a system comprising a network address of a file providing device and a mediation server notifying a file name of a file to be transferred to the client, transfer the file only to the correct client and do not transfer the file to the incorrect client. Can be realized, whereby leakage of file data due to impersonation of a client can be prevented.
[Brief description of the drawings]
FIG. 1 shows a first embodiment of the present invention.
FIG. 2 is a diagram illustrating an example of a correspondence table of a filter mechanism.
FIG. 3 is a processing flow executed by a filter mechanism.
FIG. 4 shows a second embodiment of the present invention.
FIG. 5 is a diagram showing an example of a file name table of a file name change mechanism.
FIG. 6 is a processing flow executed by a file name change mechanism.
FIG. 7 shows a third embodiment of the present invention.
FIG. 8 is a processing flow executed by a file name change mechanism.
FIG. 9 is a processing flow executed by a file name changing mechanism.
FIG. 10 is a system configuration diagram of a diskless boot system.
FIG. 11 is an explanatory diagram of a setting file possessed by a DHCP server.
[Explanation of symbols]
1 Diskless client
2 DHCP server
3 TFTP server
4 File server
5 IP network
20 Setting files
30 Filter mechanism
31 File name change mechanism
32 File transfer request monitoring mechanism
300 correspondence table
310 File name table

Claims

クライアントの認証を行わない転送プロトコルで動作して、転送要求のあるファイルをクライアントに転送するファイル提供装置と、クライアントの認証を行って、クライアントに対して、ファイル提供装置のネットワークアドレスとそのクライアントに転送するファイルのファイル名とを通知する仲介サーバとで構成されるシステムで用いられるファイル提供装置であって、
転送要求を発行してくる可能性のあるクライアントのネットワークアドレスに対応付けて、そのクライアントへの転送を許可するファイルのファイル名を記憶する記憶手段と、
クライアントから発行されたファイル転送要求に従って、クライアントのネットワークアドレスと転送要求のファイル名とを取得する取得手段と、
上記取得したネットワークアドレスとファイル名との対データが上記記憶手段に記憶されているのか否かを判断する判断手段と、
上記対データが上記記憶手段に記憶されていない場合には、上記転送要求を破棄し、記憶されている場合には、上記取得したファイル名の指すファイルをクライアントに転送する転送手段とを備えることを、
特徴とするファイル提供装置。A file providing device that operates with a transfer protocol that does not authenticate the client and transfers a file that has a transfer request to the client, and authenticates the client to the client to provide the network address of the file providing device and the client A file providing device used in a system including a transfer server that notifies a file name of a file to be transferred,
Storage means for storing a file name of a file permitted to be transferred to the client in association with a network address of the client that may issue the transfer request;
Acquiring means for acquiring a network address of the client and a file name of the transfer request according to a file transfer request issued from the client;
Determining means for determining whether or not the pair data of the acquired network address and file name is stored in the storage means;
Transfer means for discarding the transfer request when the pair data is not stored in the storage means, and transferring the file indicated by the obtained file name to the client when the pair request is stored. To
Characteristic file providing device.

クライアントの認証を行わない転送プロトコルで動作して、転送要求のあるファイルをクライアントに転送するファイル提供装置と、クライアントの認証を行って、クライアントに対して、ファイル提供装置のネットワークアドレスとそのクライアントに転送するファイルのファイル名とを通知する仲介サーバとで構成されるシステムで用いられるファイル提供装置であって、
ファイル名の変更契機に到達したのか否かを判断する判断手段と、
上記変更契機に、自装置で保存している転送対象のファイルの一部又は全てのファイル名を変更するとともに、上記仲介サーバに登録されているそのファイル名を変更する変更手段とを備えることを、
特徴とするファイル提供装置。A file providing device that operates with a transfer protocol that does not authenticate the client and transfers a file that has a transfer request to the client, and authenticates the client to the client to provide the network address of the file providing device and the client A file providing device used in a system including a transfer server that notifies a file name of a file to be transferred,
Determining means for determining whether a file name change trigger has been reached;
At the time of the change, a change means for changing a part or all of the file name of the transfer target file stored in the own device and changing the file name registered in the mediation server is provided. ,
Characteristic file providing device.

請求項２記載のファイル提供装置において、
上記判断手段は、規定の周期に到達したのか否かを判断することによりファイル名の変更契機に到達したのか否かを判断することを、
特徴とするファイル提供装置。3. The file providing device according to claim 2,
The determining means determines whether or not the opportunity to change the file name has been reached by determining whether or not the specified cycle has been reached,
Characteristic file providing device.

請求項２記載のファイル提供装置において、
上記判断手段は、クライアントに対してファイル転送が行われたか否かを判断することによりファイル名の変更契機に到達したのか否かを判断し、
上記変更手段は、転送ファイルのファイル名を変更対象としてファイル名を変更することを、
特徴とするファイル提供装置。3. The file providing device according to claim 2,
The determining means determines whether a file name change trigger has been reached by determining whether a file transfer has been performed to the client,
The changing means may change the file name of the transfer file with the file name changed,
Characteristic file providing device.

請求項２記載のファイル提供装置において、
上記判断手段は、クライアントからファイル転送要求が発行されたのか否かを判断することによりファイル名の変更契機に到達したのか否かを判断し、
上記変更手段は、ファイル転送の成功失敗にかかわらずに、転送対象となる全てのファイルのファイル名を変更対象としてファイル名を変更することを、
特徴とするファイル提供装置。3. The file providing device according to claim 2,
The determining means determines whether a file name change trigger has been reached by determining whether a file transfer request has been issued from the client,
The changing means, regardless of the success or failure of the file transfer, changing the file names of all the files to be transferred with the file names changed,
Characteristic file providing device.

クライアントの認証を行わない転送プロトコルで動作して、転送要求のあるファイルをクライアントに転送するファイル提供装置と、クライアントの認証を行って、クライアントに対して、ファイル提供装置のネットワークアドレスとそのクライアントに転送するファイルのファイル名とを通知する仲介サーバとで構成されるシステムで用いられるファイル提供方法であって、
クライアントから発行されたファイル転送要求に従って、クライアントのネットワークアドレスと転送要求のファイル名とを取得する過程と、
転送要求を発行してくる可能性のあるクライアントのネットワークアドレスに対応付けて、そのクライアントへの転送を許可するファイルのファイル名を記憶する記憶手段を参照することで、上記取得したネットワークアドレスとファイル名との対データが該記憶手段に記憶されているのか否かを判断する過程と、
上記対データが上記記憶手段に記憶されていない場合には、上記転送要求を破棄し、記憶されている場合には、上記取得したファイル名の指すファイルをクライアントに転送する過程とを備えることを、
特徴とするファイル提供方法。A file providing device that operates with a transfer protocol that does not authenticate the client and transfers a file that has a transfer request to the client, and authenticates the client to the client to provide the network address of the file providing device and the client A file providing method used in a system configured with an intermediary server that notifies a file name of a file to be transferred,
Obtaining the network address of the client and the file name of the transfer request according to the file transfer request issued by the client;
By referring to the storage unit that stores the file name of the file permitted to be transferred to the client in association with the network address of the client that may issue the transfer request, the network address and the file obtained above are obtained. Determining whether or not the paired data with the name is stored in the storage means;
If the paired data is not stored in the storage means, discarding the transfer request, and if the data is stored, transferring the file indicated by the obtained file name to the client. ,
Characteristic file provision method.

クライアントの認証を行わない転送プロトコルで動作して、転送要求のあるファイルをクライアントに転送するファイル提供装置と、クライアントの認証を行って、クライアントに対して、ファイル提供装置のネットワークアドレスとそのクライアントに転送するファイルのファイル名とを通知する仲介サーバとで構成されるシステムで用いられるファイル提供方法であって、
ファイル名の変更契機に到達したのか否かを判断する過程と、
上記変更契機に、自装置で保存している転送対象のファイルの一部又は全てのファイル名を変更するとともに、上記仲介サーバに登録されているそのファイル名を変更する過程とを備えることを、
特徴とするファイル提供方法。A file providing device that operates with a transfer protocol that does not authenticate the client and transfers a file that has a transfer request to the client, and authenticates the client to the client to provide the network address of the file providing device and the client A file providing method used in a system configured with an intermediary server that notifies a file name of a file to be transferred,
Determining whether the file name change trigger has been reached; and
At the time of the change, while changing a part or all of the file names of the transfer target files stored in the own device, a step of changing the file name registered in the mediation server,
Characteristic file provision method.

請求項７記載のファイル提供方法において、
上記判断する過程では、規定の周期に到達したのか否かを判断することによりファイル名の変更契機に到達したのか否かを判断することを、
特徴とするファイル提供方法。The file providing method according to claim 7,
In the determining step, it is determined whether or not the timing of changing the file name has been reached by determining whether or not the specified period has been reached.
Characteristic file provision method.

請求項７記載のファイル提供方法において、
上記判断する過程では、クライアントに対してファイル転送が行われたか否かを判断することによりファイル名の変更契機に到達したのか否かを判断し、
上記変更する過程では、転送ファイルのファイル名を変更対象としてファイル名を変更することを、
特徴とするファイル提供方法。The file providing method according to claim 7,
In the determining step, it is determined whether a file name change trigger has been reached by determining whether a file transfer has been performed to the client,
In the above change process, changing the file name of the transfer file to be changed
Characteristic file provision method.

請求項７記載のファイル提供方法において、
上記判断する過程では、クライアントからファイル転送要求が発行されたのか否かを判断することによりファイル名の変更契機に到達したのか否かを判断し、
上記変更する過程では、ファイル転送の成功失敗にかかわらずに、転送対象となる全てのファイルのファイル名を変更対象としてファイル名を変更することを、
特徴とするファイル提供方法。The file providing method according to claim 7,
In the determining step, it is determined whether a file name change trigger has been reached by determining whether a file transfer request has been issued from the client,
In the above changing process, regardless of the success or failure of the file transfer, the file names of all the files to be transferred are changed with the file names changed,
Characteristic file provision method.

請求項６ないし１０のいずれか１項に記載のファイル提供方法の実現に用いられる処理をコンピュータに実行させるためのファイル提供プログラム。A file providing program for causing a computer to execute a process used to implement the file providing method according to claim 6.

請求項６ないし１０のいずれか１項に記載のファイル提供方法の実現に用いられる処理をコンピュータに実行させるためのファイル提供プログラムを記録した記録媒体。A recording medium recording a file providing program for causing a computer to execute a process used for implementing the file providing method according to claim 6.