JP6724367B2 - 通信システムおよび通信装置 - Google Patents

通信システムおよび通信装置 Download PDF

Info

Publication number
JP6724367B2
JP6724367B2 JP2016002100A JP2016002100A JP6724367B2 JP 6724367 B2 JP6724367 B2 JP 6724367B2 JP 2016002100 A JP2016002100 A JP 2016002100A JP 2016002100 A JP2016002100 A JP 2016002100A JP 6724367 B2 JP6724367 B2 JP 6724367B2
Authority
JP
Japan
Prior art keywords
identifier
data
packet
stored
data block
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2016002100A
Other languages
English (en)
Other versions
JP2017123580A (ja
Inventor
一浩 里吉
一浩 里吉
刑部 和浩
和浩 刑部
晃久 小野田
晃久 小野田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Yamaha Corp
Original Assignee
Yamaha Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Yamaha Corp filed Critical Yamaha Corp
Priority to JP2016002100A priority Critical patent/JP6724367B2/ja
Publication of JP2017123580A publication Critical patent/JP2017123580A/ja
Application granted granted Critical
Publication of JP6724367B2 publication Critical patent/JP6724367B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)
  • Communication Control (AREA)

Description

本発明は、通信装置におけるフィルタリング技術に関する。
通信装置におけるフィルタリング技術とは、クライアント装置からの要求に応じて所定の処理を実行するサーバ装置やルータなどの通信装置に対する不正アクセス等の攻撃を防御するための技術の一つである。フィルタリング機能を備えた通信装置は、予め定めた条件(例えば、ポート、アドレス、プロトコル等に関する条件)を満たすパケットのみを受け入れ、当該条件を満たさないパケットを破棄する、といった具合である。このようなフィルタリングに関する先行技術としては特許文献1に開示の技術が挙げられる。特許文献1に開示された通信システムでは、送信側の通信装置(以下、「送信装置」と呼ぶ)においてIPv6に準拠したパケットの拡張ヘッダにフィルタキーを格納してその宛先となる通信装置、すなわち、パケットの受信側の通信装置(以下、「受信装置」と呼ぶ)に送信する。フィルタキーとは、判定対象のパケットについてのネットワーク層よりも上位階層の情報を要約した情報である。受信装置は、受信したパケットからフィルタキーを生成し、生成したフィルタキーと受信したパケットの拡張ヘッダに格納されたフィルタキーとを比較し、両者が一致しない場合にはそのパケットを破棄する。
特許第4330342号公報
特許文献1に開示された技術では、送信装置と受信装置に予め、フィルタキーの生成ルールを共有させておく必要がある。しかし特許文献1には、この生成ルールについての具体的な共有手順が開示されておらず、実施困難である、といった問題がある。また、受信装置がいわゆるDoS攻撃を受けた場合や受信パケットがフラグメントパケットである場合には、受信装置に過大な負荷がかかり、受信装置本来の処理の実行に支障を来す場合があるという問題がある。さらに、特許文献1に開示された技術には、IPv6に準拠したパケットのみに対応し、IPv4に準拠したパケットには対応していないといった問題、すなわち汎用性が低いという問題がある。
この発明は以上のような事情に鑑みてなされたものであり、汎用性が高く、かつ受信装置に過大な負荷を掛けることのないフィルタリング技術を提供することを目的としている。
上記課題を解決するために本発明は、プロトコル階層毎に予め定められた通信プロトコルにしたがって通信網を介してデータブロックの送受信を行う送信装置と受信装置とを含み、前記送信装置は、前記受信装置側でのフィルタリング条件を満たすデータブロックのヘッダに、当該フィルタリング条件を満たすことを示す識別子を追記して送信する送信手段を有し、前記受信装置は、前記通信網を介して受信したデータブロックのヘッダに前記識別子が格納されているか否かを判定する判定手段と、前記識別子が格納されていた場合に所定の処理を実行する一方、前記識別子が格納されていない場合には当該データブロックを破棄する制御手段とを有することを特徴とする通信システムを提供する。この通信システムにおいて、識別子を送信装置と受信装置の両者の記憶部に記憶させてもよいし、通信網を介して送信装置と受信装置の両者と送受信が可能な記憶装置に識別子を記憶させてもよい。両者の識別子は、同一のものであってもよいし、内容的に同一視できるものであってもよい。内容的に同一視できるとは、例えば送信装置の識別子の情報が受信装置の識別子の情報に含まれることである。さらに、通信網を介して送信装置と受信装置の両者と送受信が可能な記憶装置に識別子が記憶されている場合、送信装置と受信装置の送受信の都度、記憶装置に識別子を問い合わせても良い。
上記通信プロトコルはIPv4であっても良いし、IPv6であっても良い。上記通信プロトコルは、IPv4やIPv6以外のネットワーク層の通信プロトコルであっても良い。また、上記通信プロトコルはネットワーク層よりも下位のプロトコル階層の通信プロトコルであっても良い。本通信システムでは、特定の通信プロトコルを前提としないため、特許文献1に開示の技術に比較して汎用性が高い。加えて、本発明の通信システムにおいては、受信装置は、上記識別子の有無のみを判定対象とするので、DoS攻撃を受けた場合や受信パケットがフラグメントパケットであった場合であっても受信装置に過大な負荷がかかることはない。なお、上記識別子の追記先としては、上記通信プロトコルがIPv4である場合には、ヘッダにおける未使用領域およびIPオプションヘッダが考えられる。上記通信プロトコルがIPv6である場合には、ヘッダにおける未使用領域および拡張ヘッダが考えられる。また、IPv4もIPv6も、すでに使用されているフィールドの解釈を変えることで、このフィールドを使用することもできる。
より好ましい態様において、前記送信手段は、前記フィルタリング条件を満たすデータブロックのヘッダに前記識別子に加えて前記識別子の算出元になった算出元データを追記して送信し、前記判定手段は、受信したデータブロックのヘッダに前記識別子と前記算出元データとが格納されているか否かを判定し、前記制御手段は、前記識別子が格納されており、かつ当該算出元データを用いて算出された値と、当該識別子とが一致する場合に前記所定の処理を実行する。このような態様によれば、上記識別子のみをヘッダに追記する態様に比較してきめ細やかなフィルタリングを実現することが可能になる。
より好ましい態様において、前記識別子は、所定のハッシュ関数により算出されるハッシュ値である。このような態様によれば、ハッシュ関数を用いたフィルタリングを実現することが可能になる。なお、ハッシュ化されるアルゴリズムは事前に同じものを使うことを約束しておいても良いし、接続前に特定のプロトコルによって交換しても良い。
より好ましい態様において、前記送信手段は、前記識別子と前記算出元データを複数のプロトコル階層のうちの互いに異なるプロトコル階層のヘッダに追記して送信する。このような態様によれば、本発明の通信システムにおけるフィルタリングアルゴリズムの第三者による解読が困難になり、不正アクセス等に対する耐性をさらに高めることができる。
また別の好ましい態様において、プロトコル階層毎に予め定められた通信プロトコルにしたがって通信網を介してデータブロックの送受信を行う送信装置と受信装置とを前記通信網に接続するのに先立って、前記受信装置側でのフィルタリング条件を満たすことを示す識別子を両者に記憶させておくステップと、前記送信装置が、前記フィルタリング条件を満たすデータブロックのヘッダに、前記識別子を追記して送信するステップと、前記受信装置が、前記通信網を介して受信したデータブロックのヘッダに前記識別子が格納されているか否かを判定し、格納されていた場合に所定の処理を実行する一方、格納されていない場合には当該データブロックを破棄するステップと、を有することを特徴とする通信方法を提供する。この通信方法では、特定の通信プロトコルを前提としないため、特許文献1に開示の技術に比較して汎用性が高い。加えて、この通信方法においては、受信装置は、上記識別子の有無のみを判定対象とするので、DoS攻撃を受けた場合や受信パケットがフラグメントパケットであった場合であっても受信装置に過大な負荷がかかることはない。また、送信装置と受信装置を通信網に接続するのに先立って両者に記憶させておくのは、識別子だけでなく、ハッシュ化するアルゴリズム(番号)や、どのフィールドを見るかなどの情報であってもよい。
また別の好ましい態様において、相手装置側でのフィルタリング条件を満たすデータブロックのヘッダに、前記フィルタリング条件に対応する識別子を追記し、プロトコル階層毎に予め定められた通信プロトコルにしたがって通信網を介して前記データブロックを前記相手装置へ送信する送信手段を有することを特徴とする通信装置を提供する。この通信装置では、特定の通信プロトコルを前提としないため、特許文献1に開示の技術に比較して汎用性が高い。
また別の好ましい態様においては、プロトコル階層毎に予め定められた通信プロトコルにしたがって通信網を介して相手装置から受信したデータブロックのヘッダに、前記データブロックを受信する際のフィルタリング条件に対応する識別子が格納されているか否かを判定する判定手段と、前記判定手段により前記識別子が格納されていると判定された場合に所定の処理を実行する一方、前記判定手段により前記識別子が格納されていないと判定された場合には当該データブロックを破棄する制御手段と、を有することを特徴とする通信装置を提供する。この通信装置では、特定の通信プロトコルを前提としないため、特許文献1に開示の技術に比較して汎用性が高い。加えて、この通信装置では、上記識別子の有無のみを判定対象とするので、DoS攻撃を受けた場合や受信パケットがフラグメントパケットであった場合であっても当該通信装置に過大な負荷がかかることはない。
本発明の第1実施形態の通信システム1の構成例を示すブロック図である。 同通信システム1の送信装置102の構成例を示すブロック図である。 同通信システム1のパケット送信の流れを示すフローチャートである。 本発明の第2実施形態の通信システム2を説明するための図である。 本発明の第3実施形態の通信システム3を説明するための図である。 本発明の第4実施形態の通信システム4の構成例を示すブロック図である。 同通信システム4を説明するための図である。 本発明の第5実施形態の通信システム5を説明するための図である。
以下、図面を参照しつつ、この発明の実施の形態について説明する。
<第1実施形態>
図1は、本発明の第1実施形態の通信システム1の構成例を示す図である。通信システム1では、OSI参照モデルに基づいた通信プロトコルに従った通信が行われる。図1に示すように、通信システム1は、LAN(Local Area Network)101に各々接続された送信装置102と受信装置103とを含んでいる。送信装置102と受信装置103は利用者が操作する端末である。送信装置102の利用者が送信装置102に対して、受信装置103へのパケットの送信を指示すると、送信装置102はパケットを生成し受信装置103へ送信する。このようにして送信装置102から送信されたパケットは受信装置103へ伝送される。パケットとは、ネットワーク層におけるデータの送受信単位となるデータブロックのことである。通信システム1では、ネットワーク層の通信プロトコルとしてIPv4が採用されている。つまり、送信装置102と受信装置103の間では、IPv4に準拠したパケットがLAN101を介して送受信される。本実施形態では、送信装置102と受信装置103がLAN101に有線接続される場合について説明するが、LAN101は無線LANであってもよい。これは、他の実施形態においても同様である。
送信装置102と受信装置103は、例えばパーソナルコンピュータやルータ等のネットワーク機器である。両者には受信装置103におけるフィルタリング条件に関するデータを格納したテーブルが記憶されている。以下、送信装置102に記憶されたテーブルを送信ルールテーブルといい、受信装置103に記憶されたテーブルを受信ルールテーブルという。送信ルールテーブルと受信ルールテーブルは、送信装置102と受信装置103に記憶されているのではなく、例えば送信装置102と受信装置103以外のネットワーク機器内やLAN101上のサーバ等に記憶されていてもよい。送信ルールテーブルには、条件データと判定条件識別子とが格納されている。条件データとは、受信装置103が実施するフィルタリングの条件(本実施形態では、受信を許容するパケットの条件、例えば、送信元のIPアドレスや上位層の通信プロトコルに関する条件)を表すデータである。判定条件識別子とは、各フィルタリング条件を一意に識別する識別子(例えば、フィルタリング条件に対応した文字列)であり、条件データ毎に予め異なる値が設定される。一方、受信ルールテーブルには、比較値データと動作定義データとが格納されている。比較値データとは、フィルタリングの条件毎に予め異なる値に設定された比較値を示すデータであり、動作定義データとは、比較値データの示す比較値に対応した受信装置103の動作(例えば、パケットに対する応答を返信する等)を定義するデータである。つまり、本実施形態では、1つのフィルタリング条件に対して、判定条件識別子と比較値とがそれぞれ1つずつ対応付けられており、これらの判定条件識別子と比較値は同じ値となっている。なお、受信装置103が判定条件識別子と比較値が一致すると比較値に対応した動作を行う場合、受信装置103の受信ルールテーブルに動作定義データが格納されていなくてもよい。
従来の通信システムにおける受信装置は、受信装置におけるフィルタリング条件を示す条件データと、当該フィルタリング条件に対応した受信装置の動作を定義する動作定義データとが格納されたフィルタリングテーブルを記憶していた。本実施形態の通信システム1では、このフィルタリングテーブルに格納された条件データと動作定義データの両者を互いに対応付ける識別子を導入し、フィルタリングテーブルを2つのテーブルに分割している。条件データと判定条件識別子を格納したテーブルが送信ルールテーブルであり、上記識別子(すなわち、比較値データ)と動作定義データを格納したテーブルが受信ルールテーブルである。
送信装置102は、利用者によって受信装置103へのパケットの送信を指示されると、受信装置103へ送信するパケットを生成し、当該パケットが送信ルールテーブルに格納されている条件データの示すフィルタリング条件の何れかを満たしているか否かを判断する。そして、当該パケットが何れかのフィルタリング条件を満たしている場合には、送信装置102は、該当するフィルタリング条件に対応する判定条件識別子を当該パケットのヘッダに追記して、受信装置103に送信する。当該パケットがフィルタリング条件の何れも満たさない場合には、送信装置102は、上記判定条件識別子の追記を行わずに当該パケットを受信装置103に送信する。
一方、受信装置103は、パケットを受信すると、受信したパケットのヘッダに受信ルールテーブルに格納されている比較値データの示す比較値の何れかと一致する判定条件識別子が格納されているか否かを判定する。そして、当該パケットのヘッダに比較値の何れかと一致する判定条件識別子が格納されている場合は、受信装置103は、該当する比較値に対応する動作定義データの示す動作を行う。当該パケットのヘッダに判定条件識別子が格納されていない場合やヘッダに格納されている判定条件識別子が比較値の何れとも一致しない場合には、受信装置103は、受信したパケットを破棄する。これによりフィルタリングが実現される。
図2は、送信装置102の構成例を示すブロック図である。図2に示すように送信装置102は、制御部100、通信インタフェース(以下、「I/F」と略記)部110、外部機器I/F部120、記憶部130、およびこれら構成要素間のデータ授受を仲介するバス140を含んでいる。
制御部100は例えばCPU(Central Processing Unit)である。制御部100は記憶部130(より正確には不揮発性記憶部134)に記憶されている各種プログラムを実行することにより、送信装置102の制御中枢として機能する。制御部100が各種プログラムにしたがって実行する処理の詳細については後に明らかにする。通信I/F部110は、例えばNIC(Netwоrk Interface Card)であり、LAN101に接続されている。通信I/F部110は、LAN101から送信されてくるデータフレームを受信して制御部100に与える一方、制御部100から与えられるデータフレームをLAN101へと送出する。データフレームとはデータリンク層におけるデータの送受信単位となるデータブロックのことである。このデータフレームにはIPv4に準拠したパケットが内包されている。また、外部機器I/F部120は、例えばUSB(Universal Serial Bus)である。
記憶部130は、図2に示すように、揮発性記憶部132と不揮発性記憶部134を含んでいる。揮発性記憶部132は例えばRAM(Randоm Access Memory)である。この揮発性記憶部132は各種プログラムを実行する際のワークエリアとして制御部100によって利用される。不揮発性記憶部134は例えばハードディスクである。
不揮発性記憶部134には各種プログラムと各種データが記憶されている。不揮発性記憶部134に記憶されているプログラムの一例としては、OS(Operating System)を制御部100に実現させるためのOSプログラム(図2では図示略)や通信制御プログラム134bが挙げられる。また、不揮発性記憶部134に記憶されているデータの一例としては、送信ルールテーブル134aが挙げられる。制御部100は、通信制御プログラム134bを実行することにより送信手段として機能する(図1参照)。これらプログラムやデータの概略は以下の通りである。
送信ルールテーブル134aは、上記で説明した通り、受信装置103が実施するパケットフィルタリングの条件を示す条件データと、条件データに対応づけられた判定条件識別子とを含む。OSプログラムは、送信装置102の電源(図示略)の投入またはリセットを契機として実行されるプログラムである。OSプログラムにしたがって作動し、OSを実現している状態の制御部100には、複数のプログラムを並列に実行する機能等が付与される。
通信制御プログラム134bは、IPv4に準拠したデータ通信を制御部100に行わせるためのプログラムである。OSプログラムの実行を完了しOSを実現している状態の制御部100は、通信制御プログラム134bを不揮発性記憶部134から揮発性記憶部132に読み出し、その実行を開始する。通信制御プログラム134bにしたがって作動している制御部100には、利用者の指示に応じてパケットを生成し送信する機能や、他の通信装置から送信されたパケットを受信する機能が付与されている。制御部100は、パケットの送信(本実施形態では、受信装置103への送信)を指示されると、受信装置103へ送信するパケットを生成し、当該パケットが送信ルールテーブル134aに格納された条件データの示すフィルタリング条件の何れかを満たすか否か判定する。そして、制御部100は、何れかのフィルタリング条件を満たす場合には、該当するフィルタリング条件に対応する判定条件識別子を送信ルールテーブル134aから読み出し、当該判定条件識別子を当該パケットのヘッダの所定の領域(未使用領域のうちの予め定められた領域)に追記して受信装置103に送信する。
以上が送信装置102の構成であるが、受信装置103の構成も以下の2点を除いて同様である。第1に、不揮発性記憶部134に送信ルールテーブル134aに代えて受信ルールテーブル134cが記憶されている点である(図1参照)。受信ルールテーブル134cは、上記で説明した通り、比較値を示す比較値データと、比較値データに対応づけられた動作定義データとを含む。第2に、通信制御プログラム134bにしたがって作動している制御部100は、通信I/F部110を介して受信したパケットのヘッダの所定の領域に判定条件識別子が格納されているか否かを判定する判定手段として機能し、格納されており、かつ当該判定条件識別子が受信ルールテーブル134cに格納されている比較値データの示す比較値の何れかと一致する場合に、該当する比較値に対応する動作を実行し、それ以外の場合には、受信したパケットを破棄する制御手段として機能する点である(図1参照)。
以上が通信システム1の構成である。
次に、通信システム1の動作について、図3を参照しつつ説明する。まず、送信装置102と受信装置103をLAN101に接続する前に行われる通信システム1の初期設定(ステップS100)について説明する。この初期設定では、通信システム1の運用管理者は、まず、通信線(例えば、USBケーブル)を用いて送信装置102に受信装置103を直接接続する。
次いで、運用管理者は受信装置103の外部機器I/F120にキーボード等の入力装置を接続し、当該入力装置を操作してフィルタリングテーブルを生成する。次いで、運用管理者は、当該フィルタリングテーブルに格納されている各条件データに対して、各フィルタリング条件を一意に示す識別子を割り当て、当該フィルタリングテーブルを送信ルールテーブル134aと受信ルールテーブル134cの2つのテーブルに分割する。
上記の要領で送信ルールテーブル134aおよび受信ルールテーブル134cの生成が完了すると、運用管理者は上記入力装置を操作し、前者のテーブルを受信装置103から上記通信線経由で送信装置102へ送信して当該テーブルを送信装置102に記憶させるとともに、後者のテーブルを受信装置103に書き込む。これにより、送信装置102と受信装置103との間のフィルタリング条件の共有が完了する。これにより通信システム1の初期設定は終了する。このようにして初期設定を完了すると、運用管理者は、送信装置102と受信装置103を接続する通信線を取り外し、両者をLAN101に接続する。また、初期設定では、通信網(ネットワーク)を介して送信装置102と受信装置103を接続し、運用管理者は、クラウド上のフィルタリングテーブルを受信装置103に受信させ、当該フィルタリングテーブルから送信ルールテーブル134aと受信ルールテーブル134cの2つのテーブルを分割し、前者のテーブルを受信装置103から通信網経由で送信装置102へ送信してもよい。
次に、通信システム1におけるパケットの伝送過程について説明する。例えば利用者により送信装置102が操作され、通信相手である相手装置(本実施形態では、受信装置103)へのパケット送信が指示される。送信装置102の制御部100は、まず、受信装置103へ送信するパケットを生成する(ステップS101)。次いで、制御部100は、ステップS101で生成したパケットが送信ルールテーブル134aに格納された条件データの示す条件の何れかを満たすか否かを判断する。ステップS102の判断結果が「TRUE」である場合には、制御部100は当該パケットのヘッダの所定の領域に、該当する条件に対応する判定条件識別子を追記し(ステップS103)、パケットをその宛先の通信装置へ送信する(ステップS104)。一方、ステップS102の判断結果が「FALSE」の場合には、制御部100は、ステップS103の処理を実行することなくステップS104の処理を実行する。
受信装置103は、ステップS105において、送信装置102から送信されたパケットを受信する。受信装置103の制御部100は、受信ルールテーブル134cに示される当該パケットのヘッダの所定の領域に比較値との比較対象となる判定条件識別子が格納されているか否か、格納されていた場合にはさらにその判定条件識別子が受信ルールテーブル134cに格納された比較値データの示す比較値の何れかと一致するか否かを判定する(ステップS106)。ステップS106の判定結果が「TRUE」の場合には、制御部100は、該当する比較値に対応する動作を行う(ステップS108)。すなわち、受信装置103は、当該パケットに応じた処理を実行する。一方、ステップS106の判定結果が「FALSE」の場合には制御部100は、ステップS105にて受信したパケットを破棄する(ステップS107)。
以上が通信システム1の動作である。
上記識別子(すなわち、判定条件識別子)の追記先はIPv4に準拠したパケットのヘッダにおける未使用領域の何れであっても良く、ネットワーク層の通信プロトコルとしてIPv6を採用する場合も同様である。つまり、通信システム1におけるネットワーク層の通信プロトコルはIPv4であっても良いし、IPv6であっても良い。このように通信システム1では、特定の通信プロトコルを前提としないため、特許文献1に開示の技術に比較して汎用性が高い。加えて、通信システム1においては、パケットフィルタリング条件を満たすか否かの判断は送信装置102で行われ、上記識別子の有無および比較値との比較のみが受信装置103における判定対象であるため、DoS攻撃を受けた場合や受信パケットがフラグメントパケットであった場合であっても受信装置103に過大な負荷が掛かることはない。つまり、本実施形態によれば、汎用性が高く、かつ受信装置に過大な負荷を掛けることのないフィルタリング技術を提供することができる。なお、初期設定において、送信装置102側でフィルタリングテーブルを生成し、当該フィルタリングテーブルを送信ルールテーブル134aと受信ルールテーブル134cの2つのテーブルに分割し、前者のテーブルを送信装置102に書き込み、後者のテーブルを受信装置103へ送信して当該テーブルを受信装置103に記憶させてもよい。これは、他の実施形態においても同様である。また、送信装置102と受信装置103がルータの場合、不揮発性記憶部134は例えばフラッシュROMであり、図3のステップS108では、制御部100は、送信装置102から送信されたパケットを後段に送信する。
<第2実施形態>
図4(a)は、本発明の第2実施形態の通信システム2の構成例を示す図である。図4(a)では、図1におけるものと同一の構成要素には同一の符号が付されている。この通信システム2の構成は、送信ルールテーブル134aと受信ルールテーブル134cの内容を除いて通信システム1の構成と同様である。本実施形態における送信装置102および受信装置103も、前述した第1実施形態におけるものと同様にIPv4に準拠したデータ通信を行う。図4(a)に示すように、送信装置102に割り当てられているIPアドレスは192.168.100.1であり、受信装置103に割り当てられているIPアドレスは10.0.1.1である。
送信ルールテーブル134aには、ルール1、ルール2、ルール3・・・の各フィルタリング条件を表す条件データが格納されており、ルールn(n=1、2、3・・・)を表す条件データには値nを表す判定条件識別子が対応付けられている。同様に受信ルールテーブル134cには、値1、値2、値3・・・の各比較値を表す比較値データが格納されており、それら比較値データの各々に対応する動作を表す動作定義データが格納されている。本実施形態では、ルールnを満たすパケットであれば、受信装置103による受信が許容されているため、上記動作定義データとして、パケットの受信を許容する旨を表す文字列“pass”が用いられている。
図4(b)は、送信ルールテーブル134aに格納された条件データの示すルール1の一例を示す図である。このルール1は、以下の(Ra1)〜(Ra5)の条件を満たすパケットは受信装置103による受信が許容されていることを表している。
(Ra1)パケットの送信元のIPアドレスが192.168.100.1であり、かつ同送信先のIPアドレスが10.0.1.1であること
(Ra2)ICMPのプロトコルにしたがって送信されたパケットであること
(Ra3)ICMPタイプの値が8であり、かつICMPコードの値が0のパケットであること(すなわち、エコー要求であること)
(Ra4)パケットのデータサイズは不問であること
(Ra5)上位層のプロトコルがpingであること、なお、pingにしたがって生成されたパケットであれば上記(Ra2)〜(Ra4)の条件は自ずから満たされる。
図4(c)は、ルール1を示す条件データに対応付けて送信ルールテーブル134aに格納された判定条件識別子の示す値1の一例を示す図である。本実施形態では、ルール1を示す識別子として所定のハッシュ関数(図4(c)に示す例では、MD5)にしたがって算出されたハッシュ値が用いられている。そして、本実施形態の判定条件識別子には、上記識別子(図4(c)では「hash」)の他に、上記ハッシュ関数を表すデータ、上記ハッシュ値の算出元となったデータ(図4(c)では「Keyword of hash」)、および送信対象のパケットのヘッダにおけるこれらのデータの格納場所を示すデータ(本実施形態では、「IP OPTION」)が含まれている。
図4(d)は、受信ルールテーブル134cに格納された比較値データの示す値1の一例を示す図である。この比較値データには、識別子との比較対象となる比較値の算出方法(すなわち、上記「Keyword of hash」に相当する「Keyword」および所定の「salt」をMD5に入力して比較値を算出すること)を表すデータ、およびその算出元になるデータの受信パケットのヘッダにおける格納場所を示すデータ(本実施形態では、「IP OPTION」)が含まれている。
利用者が送信装置102に受信装置103へのICMPパケットの送信を指示すると、送信装置102は、ICMPパケットを生成する。このICMPパケットは、IPアドレスが192.168.100.1である送信装置102からIPアドレスが10.0.1.1である受信装置103に送信されるので、(Ra1)の条件を満たす。さらに、このICMPパケットが(Ra2)〜(Ra5)の条件を満たす場合、送信装置102は、ルール1に対応する判定条件識別子の示す値1にしたがってICMPパケットのIPヘッダの所定の領域(IP OPTION)に当該ルール1を満たすことを示す識別子(hash)、その算出に用いたハッシュ関数を表すデータおよび算出元のデータを追記する。そして、送信装置102は受信装置103に当該ICMPパケットを送信する。
受信装置103は、ICMPパケットを受信すると、当該ICMPパケットのIPヘッダを参照し、受信ルールテーブル134cに格納された比較値データの示す格納場所に、比較対象の識別子を表すデータと、当該識別子と比較する比較値の算出に用いるハッシュ関数を表すデータと、当該識別子と比較する比較値の算出元データとが格納されているか否かを判定する。これらのデータが格納されていた場合には、受信装置103は、さらに比較値を算出し、当該比較値と当該識別子とが一致するか否かを判定する。以降の動作は第1実施形態におけるものと同様である。
本実施形態においても、ネットワーク層の通信プロトコルは、IPv6であっても良い。つまり、本実施形態によっても、汎用性が高く、かつ受信装置に過大な負荷を掛けることのないフィルタリング技術を提供することが可能になる。なお、本実施形態によれば、ルール毎に当該ルールを満たすことを示す識別子の判定対象のパケットにおける格納先を変えることや、ルール毎に当該識別子の算出方法を異ならせることが可能になり、きめ細やかなフィルタリング制御を行うことが可能になる。
<第3実施形態>
図5(a)は、本発明の第3実施形態の通信システム3の構成例を示す図である。図5(a)では、図1におけるものと同一の構成要素には同一の符号が付されている。この通信システム3の構成は、通信システム1の構成と以下の2点を除いて同様である。第1に、送信ルールテーブル134aと受信ルールテーブル134cの内容が異なる点である。第2に、送信装置102と受信装置103は、ともにルータであり、送信装置102には端末Aが、受信装置103には端末Bが接続されている点である。通信システム3では、利用者が端末Aに対して、端末Bへのパケットの送信を指示すると、端末Aは端末B宛てのパケットを生成し、当該パケットを送信する。このようにして端末Aから送信されたパケットは、送信装置102および受信装置103を介して端末Bへ伝送される。
本実施形態における送信装置102および受信装置103も、前述した第1実施形態におけるものと同様にIPv4に準拠したデータ通信を行う。図5(a)に示すように、送信装置102に割り当てられているIPアドレスは192.168.100.1であり、受信装置103に割り当てられているIPアドレスは10.0.1.1である。これらのIPアドレスは初期設定用に割り当てられている。前述した初期設定におけるデータ通信では、このIPアドレスが利用される。さらに、端末Aに割り当てられているIPアドレスは192.168.100.2であり、端末Bに割り当てられているIPアドレスは10.0.1.2である。
送信ルールテーブル134aには、ルール1、ルール2、ルール3・・・の各フィルタリング条件を表す条件データが格納されており、ルールn(n=1、2、3・・・)を表す条件データには値nを表す判定条件識別子が対応付けられている。同様に受信ルールテーブル134cには、値1、値2、値3・・・の各比較値を表す比較値データが格納されており、それら比較値データの各々に対応する動作を表す動作定義データが格納されている。本実施形態では、ルールnを満たすパケットであれば、受信装置103による受信が許容されているため、上記動作定義データとして、パケットの受信を許容すること、すなわち受信したパケットをその宛先へ転送することを表す文字列“pass”が用いられている。
図5(b)は、送信ルールテーブル134aに格納された条件データの示すルール2の一例を示す図である。このルール2は、以下の(Rb1)〜(Rb4)の条件を満たすパケットは受信装置103による受信が許容されていることを表している。
(Rb1)パケットの送信元のIPアドレスが192.168.100.0/24に含まれ、かつ同送信先のIPアドレスが10.0.1.0/24に含まれること
(Rb2)TCPにしたがって送信されたSYNパケットであること
(Rb3)パケットの送信元のポート番号は不問であるが、送信先のポート番号は23であること
(Rb4)パケットのデータサイズは不問であること
図5(c)は、ルール2を示す条件データに対応付けて送信ルールテーブル134aに格納された判定条件識別子の示す値2の一例を示す図である。本実施形態では、ルール2を示す識別子として、端末Aと端末Bの利用者が属するグループ名(図5(c)に示す例では、「NetwоrkDev1grоup1」)が用いられている。本実施形態の判定条件識別子には、上記識別子の他に、判定対象のパケットのヘッダにおける上記識別子の格納場所(本実施形態では、「TCP OPTION」)を示すデータが含まれている。
図5(d)は、受信ルールテーブル134cに格納された比較値データの示す値2の一例を示す図である。この比較値データには、識別子との比較対象の比較値と、受信パケットのヘッダにおける当該識別子の格納場所(本実施形態では、「TCP OPTION」)を示すデータが含まれている。
利用者が端末Aに端末BへのTELNET接続を指示すると、端末Aは、TELNET接続を要求するSYNパケットを生成する。このパケットは、IPアドレスが192.168.100.2である端末AからIPアドレスが10.0.1.2である端末Bに送信されるので、(Rb1)の条件を満たす。さらに、このパケットが(Rb2)〜(Rb4)の条件を満たす場合、送信装置102は、端末Aから当該パケットを受信すると、ルール2に対応する判定条件識別子の示す値2にしたがって当該パケットのヘッダの所定の領域(TCP OPTION)に当該ルール2を満たすことを示す識別子(NetwоrkDev1grоup1)を追記する。そして、送信装置102は受信装置103に当該パケットを送信する。
受信装置103は、送信装置102を介して端末Aから送信されたパケットを受信すると、当該パケットのヘッダを参照し、受信ルールテーブル134cに格納された比較値データの示す格納場所に同比較値データの示す比較値と一致する識別子が格納されているか否かを判定する。本実施形態では、この判定結果は「YES」となり、受信装置103は、当該パケットを、その宛先、すなわち端末Bへ転送する。
本実施形態においても、ネットワーク層の通信プロトコルは、IPv6であっても良い。つまり、本実施形態によっても、汎用性が高く、かつ中継装置に過剰な負荷を掛けることのないフィルタリング技術を提供することが可能になる。
<第4実施形態>
図6は、本発明の第4実施形態の通信システム4の構成例を示す図である。図6では、図1におけるものと同一の構成要素には同一の符号が付されている。通信システム4の構成は、通信システム1の構成と以下の3つの点を除いて同様である。第1に、送信ルールテーブル134aと受信ルールテーブル134cの内容が異なる点である。第2に、図6に示すように、中継装置104が送信装置102と受信装置103の間に設けられ、送信装置102と中継装置104はLAN105に接続され、受信装置103と中継装置104はLAN106に接続されている点である。そして、第3に、本実施形態の受信装置103は、DNSサーバである点である。
本実施形態における送信装置102および受信装置103は、前述した第1実施形態とは異なり、IPv6に準拠したデータ通信を行う。中継装置104は、IPv6に準拠したパケットの中継を行うルータであるが、LAN105を経由して送信装置102から送信されたパケットのFlоw Labelの値によってパケットを破棄したり、別の値に書き換えたりせずに、当該パケットをLAN106経由で受信装置103に転送する点がIPv6に準拠した一般的なルータと異なる。
図7(a)は、本発明の第4実施形態の通信システム4の構成例を示す図である。図7(a)に示すように、LAN105において、送信装置102に割り当てられているIPアドレスはa::1であり、中継装置104に割り当てられているIPアドレスはa::10である。さらに、LAN106において、中継装置104に割り当てられているIPアドレスはb::10であり、受信装置103に割り当てられているIPアドレスはb::1である。
送信ルールテーブル134aには、ルール1、ルール2、ルール3・・・の各フィルタリング条件を表す条件データが格納されており、ルールn(n=1、2、3・・・)を表す条件データには値nを表す判定条件識別子が対応付けられている。同様に受信ルールテーブル134cには、値1、値2、値3・・・の各比較値を表す比較値データが格納されており、それら比較値データの各々に対応する動作を表す動作定義データが格納されている。本実施形態では、ルールnを満たすパケットであれば、受信装置103による受信が許容されているため、上記動作定義データとして、パケットの受信を許容する旨を表す文字列“pass”が用いられている。
図7(b)は、送信ルールテーブル134aに格納された条件データの示すルール1の一例を示す図である。このルール1は、以下の(Rc1)〜(Rc5)の条件を満たすパケットは受信装置103による受信が許容されていることを表している。
(Rc1)パケットの送信元のIPアドレスがa::1に含まれ、かつ同送信先のIPアドレスがb::1に含まれること
(Rc2)UDPにしたがって送信されたパケットであること
(Rc3)パケットの送信元のポート番号は不問であるが、送信先のポート番号は53であること
(Rc4)パケットのデータサイズは不問であること
(Rc5)上位層のプロトコルがDNSであること、なお、DNSにしたがって生成されたパケット、すなわちドメイン名からIPアドレスの変換(以下、名前解決と呼ぶ)を要求するパケットであれば上記(Rc2)〜(Rc4)の条件は自ずから満たされる。
図7(c)は、ルール1を示す条件データに対応付けて送信ルールテーブル134aに格納された判定条件識別子の示す値1の一例を示す図である。本実施形態では、ルール1を示す識別子として文字列(図7(c)に示す例では、「0x12345」)が用いられている。本実施形態の判定条件識別子には、上記識別子の他に、判定対象のパケットのIPv6ヘッダにおける上記識別子の格納場所(本実施形態では、「Flow Label」)を示すデータが含まれている。
図7(d)は、受信ルールテーブル134cに格納された比較値データの示す値1の一例を示す図である。この比較値データには、識別子との比較対象の比較値と、受信パケットのIPv6ヘッダにおける当該識別子の格納場所(本実施形態では、「Flow Label」)を示すデータが含まれている。
利用者が送信装置102に対して、ある通信装置(送信装置102ではなく、受信装置103でもない通信装置)の名前解決を指示すると、送信装置102は、名前解決要求を含むUDPパケットを生成する。このUDPパケットは、IPアドレスがa::1である送信装置102からIPアドレスがb::1である受信装置103に送信されるので、(Rc1)の条件を満たす。さらに、このUDPパケットは、名前解決を要求するパケットであるので、前述の通り、(Rc2)〜(Rc5)の条件を満たす。そのため、送信装置102は、ルール1に対応する判定条件識別子の示す値1にしたがってUDPパケットのIPv6ヘッダの所定の領域(Flow Label)に当該ルール1を満たすことを示す識別子(0x12345)を追記する。そして、送信装置102は受信装置103に当該UDPパケットを送信する。このようにして送信装置102から受信装置103へ宛てて送信されたUDPパケットは、中継装置104による中継を経て、その宛先(すなわち、受信装置103)に到達する。なお、中継装置104はFlow Labelを参照しないため、Flow Labelに識別子が格納されていることに起因する誤動作が発生することはない。
受信装置103は、上記の要領でUDPパケットを受信すると、当該UDPパケットのIPv6ヘッダを参照し、受信ルールテーブル134cに格納された比較値データの示す格納場所に同比較値データの示す比較値と一致する識別子が格納されているか否かを判定する。以降の動作は第1実施形態におけるものと同様である。すなわち、受信装置103は、受信したUDPパケットに何れかの比較値と一致する判定条件識別子が格納されていた場合、名前解決要求に応答するパケットを生成する。この場合、当該パケットのFlоw Labelに0を格納してもよい。これは、当該パケットが中継装置104以外のFlow Label対応のルータを経由したとしても、誤動作が発生しないようにするためである。
中継装置104を挟んだ本実施形態においても、ネットワーク層の通信プロトコルは、IPv4であっても良い。つまり、本実施形態によっても、汎用性が高く、かつ受信装置に過剰な負荷を掛けることのないフィルタリング技術を提供することが可能になる。通信プロトコルがIPv4の場合は、上記識別子の格納場所として、IPヘッダの未使用領域を用いる、或いはすでに使用されているフィールドの解釈を変えることで、このフィールドを使用すればよい。
<第5実施形態>
図8(a)は、本発明の第5実施形態の通信システム5の構成例を示す図である。通信システム5は、例えばストリーミング配信サービスに用いられる。図8(a)では、図1におけるものと同一の構成要素には同一の符号が付されている。この通信システム5の構成は、送信ルールテーブル134aと受信ルールテーブル134cの内容を除いて通信システム1の構成と同様である。本実施形態における送信装置102および受信装置103は、前述した第1実施形態におけるものと異なり、IPv6に準拠したデータ通信を行う。図8(a)に示すように、送信装置102に割り当てられているIPアドレスはa::1であり、受信装置103に割り当てられているIPアドレスはb::1である。本実施形態の受信装置103は、Webサーバの機能を有していればよく、例えばルータであってもよい。
送信ルールテーブル134aには、ルール1、ルール2、ルール3・・・の各フィルタリング条件を表す条件データが格納されており、ルールn(n=1、2、3・・・)を表す条件データには値nを表す判定条件識別子が対応付けられている。同様に受信ルールテーブル134cには、値1、値2、値3・・・の各比較値を表す比較値データが格納されており、それら比較値データの各々に対応する動作を表す動作定義データが格納されている。本実施形態では、ルールnを満たすパケットであれば、受信装置103による受信が許容されているため、上記動作定義データとして、パケットの受信を許容すること、すなわち受信したパケットをその宛先へ転送することを表す文字列“pass”が用いられている。
図8(b)は、送信ルールテーブル134aに格納された条件データの示すルール2の一例を示す図である。このルール2は、以下の(Rd1)〜(Rd5)の条件を満たすパケットは受信装置103による受信が許容されていることを表している。
(Rd1)パケットの送信元のIPアドレスがa::1に含まれ、かつ同送信先のIPアドレスがb::1に含まれること
(Rd2)TCPにしたがって送信されたパケットであること
(Rd3)パケットの送信元のポート番号は不問であるが、送信先のポート番号は80であること
(Rd4)パケットのデータサイズは不問であること
(Rd5)上位層のプロトコルがHTTPであること、なお、HTTPにしたがって生成されたパケットであれば上記(Rd2)〜(Rd4)の条件は自ずから満たされる。
図8(c)は、ルール2を示す条件データに対応付けて送信ルールテーブル134aに格納された判定条件識別子の示す値2の一例を示す図である。本実施形態では、ルール2を示す識別子としてストリーミングの配信を示すURL(図8(c)に示す例では、「http://www.jp.yamaha.cоm」)と、ストリーミングのカテゴリーを示す文字列(図8(c)に示す例では、「Music instruments」)と、セキュリティレベル(図8(c)に示す例では、「30」)が用いられている。なお、URLとカテゴリーは、ストリーミング配信サービスの利用開始時に送信装置102の利用者によって指定され、セキュリティレベルは予め設定された固定値である。固定値は、例えば外部データベースのURLコンテンツフィルタサーバが有するキーワードであってもよい。本実施形態の判定条件識別子には、上記識別子の他に、判定対象のパケットのIPv6ヘッダにおける上記識別子の格納場所(本実施形態では、「extensiоn header」)を示すデータが含まれている。
図8(d)は、受信ルールテーブル134cに格納された比較値データの示す値2の一例を示す図である。この比較値データには、識別子との比較対象の比較値と、受信パケットのヘッダにおける当該識別子の格納場所(本実施形態では、「extensiоn header」)を示すデータが含まれている。
利用者が送信装置102にサービスの利用指示を与えると、送信装置102は、TCPパケットを生成する。このTCPパケットは、IPアドレスがa::1である送信装置102からIPアドレスがb::1である受信装置103に送信されるので、(Rd1)の条件を満たす。さらに、このTCPパケットは、HTTPにしたがって生成されたパケットであるので、前述の通り、(Rd2)〜(Rd5)の条件を満たす。そのため、送信装置102は、ルール1に対応する判定条件識別子にしたがってTCPパケットのヘッダの所定の領域(extensiоn header)に当該ルール1を満たすことを示す識別子(「http://www.jp.yamaha.cоm」、「Music instruments」、「30」)を追記する。そして、送信装置102は受信装置103に当該TCPパケットを送信する。
受信装置103は、TCPパケットを受信すると、当該TCPパケットのIPv6ヘッダを参照し、受信ルールテーブル134cに格納された比較値データの示す格納場所に比較対象の識別子が格納されているか否かを判定する。格納されていた場合、格納された識別子の中でURLが禁止リストに含まれているか否かを判定する。受信装置103は、URLが禁止リストに含まれている場合、当該TCPパケットを破棄し、禁止リストに含まれていない場合、当該TCPパケットの識別子のカテゴリーが禁止リストに含まれているか否かを判定する。受信装置103は、カテゴリーが禁止リストに含まれている場合、当該TCPパケットを破棄し、禁止リストに含まれていない場合、さらに当該TCPパケットのセキュリティレベルが16以上であるか否かを判定する。受信装置103は、セキュリティレベルが16以上でない場合、当該TCPパケットを破棄し、16以上である場合、当該TCPパケットをその宛先へ転送する。本実施形態では、URLとカテゴリーは禁止リストに含まれておらず、セキュリティレベルは16以上であるため、受信装置103は、当該TCPパケットをその宛先へ転送する。
本実施形態では、通信プロトコルに関するフィルタリング条件を満たすか否かの判断は送信装置102で行われ、禁止リストに含まれたURLであるか否か等の判断は受信装置103で行われる。このため、両者の判断を受信装置103で行う従来技術に比較して受信装置103に掛かる負荷を低く抑えることができる。また、本実施形態においても、ネットワーク層の通信プロトコルは、IPv4であっても良い。つまり、本実施形態によっても、汎用性が高く、かつ受信装置に過剰な負荷を掛けることのないフィルタリング技術を提供することが可能になる。通信プロトコルがIPv4の場合は、上記識別子の格納場所として、IPヘッダの未使用領域を用いる、或いはすでに使用されているフィールドの解釈を変えることで、このフィールドを使用すればよい。
<変形例>
以上、本発明の一実施形態について説明したが、この実施形態を以下のように変形しても良い。
(1)第2実施形態では、識別子としてハッシュ値を用いていたが、これを第3〜第5実施形態に用いてもよい。ハッシュ値を用いた方が、通信システムにおけるフィルタリングアルゴリズムの第三者による解読が困難になり、不正アクセス等に対する耐性を高めることができる。また、ハッシュ値の算出に用いるハッシュ関数はMD5に限られず、他のハッシュ関数を用いてもよい。なお、ハッシュ値の算出にsaltを用いなくてもよい。
(2)上記実施形態では、送信装置102は、パケットのヘッダに送信ルールテーブル134aに格納された判定条件識別子を追記し、受信装置103は、パケットのヘッダにおいて比較値データの示す比較値が格納されているか否かを判定していた。しかし、送信装置102と受信装置103の間のデータ通信を規定する複数のプロトコル階層のうちの互いに異なるプロトコル階層のヘッダに判定条件識別子を追記する態様をとってもよい。例えば、第2実施形態では、送信装置102が識別子であるハッシュ値と算出元データとを、ICMPパケットのIPヘッダと当該パケットを内包したフレームのヘッダに各々追記してもよい。この態様では、受信装置103は、ネットワーク層およびデータリンク層の各ヘッダにハッシュ値と算出元データとが格納されているか否かを判定する。他にも例えば、第4実施形態では、URL、カテゴリー、セキュリティレベルを互いに異なるプロトコル階層のヘッダに追記してもよい。これらの態様によれば、通信システムにおけるフィルタリングアルゴリズムの第三者による解読が困難になり、不正アクセス等に対する耐性をさらに高めることができる。
(3)上記実施形態では、通信システムの初期設定において、通信線により送信装置102と受信装置103を直接接続し、受信装置103が生成した送信ルールテーブル134aを送信装置102に通信線経由で送信した。しかし、送信装置102と受信装置103を直接接続する通信線の代わりに、USBメモリなどの記憶装置を介してデータを授受する態様をとってもよい。また、受信装置103は、送信ルールテーブル134aと受信ルールテーブル134cを生成せず、USBメモリに運用管理者が予め生成した送信ルールテーブル134aと受信ルールテーブル134cが格納されている態様をとってもよい。この態様では、USBメモリを送信装置102に接続し、USBメモリに格納された送信ルールテーブル134aを読み出して記憶する処理を送信装置102に実行させた後に、当該USBメモリを受信装置103に接続し、USBメモリに格納された受信ルールテーブル134cを読み出して記憶する処理を受信装置103に実行させる。この態様であっても、送信装置102と受信装置103でルールを共有して、フィルタリングを実現することができる。また、受信装置103は、送信ルールテーブル134aと受信ルールテーブル134cを生成せず、送信ルールテーブル134aと受信ルールテーブル134cが格納されたサーバから通信線を介して両者を取得する態様をとってもよい。
(4)上記実施形態では、送信装置102と受信装置103がセットになった通信システムとして提供していたが、送信装置102と受信装置103を単体で提供する態様をとってもよい。また、通信制御プログラム134bを単体で提供してもよい。一般的なコンピュータ(CPU)を通信制御プログラム134bにしたがって作動させることで、当該コンピュータを本発明の通信装置(送信装置102、あるいは受信装置103)として機能させることができるからである。なお、通信制御プログラム134bの具体的な提供態様としては、CD−ROMなどのコンピュータ読み取り可能な記憶媒体に書き込んで提供する態様や、インターネットなどの電気通信回線経由のダウンロードにより配布する態様が考えられる。
1,2,3,4,5……通信システム、101,105,106……LAN、102……送信装置、103……受信装置、104……中継装置、100……制御部、110……通信I/F部、120……外部機器I/F部、130……記憶部、132……揮発性記憶部、134……不揮発性記憶部、134a……送信ルールテーブル、134b……通信制御プログラム、134c……受信ルールテーブル、140……バス、A……端末、B……端末。

Claims (8)

  1. プロトコル階層毎に予め定められた通信プロトコルにしたがって通信網を介してデータブロックの送受信を行う送信装置と受信装置とを含み、
    前記送信装置は、前記受信装置側でのフィルタリング条件を満たすデータブロックのヘッダに、当該フィルタリング条件を満たすことを示す識別子と前記識別子の算出元になった算出元データとを追記して送信する送信手段を有し、
    前記受信装置は、前記通信網を介して受信したデータブロックのヘッダに前記識別子と前記算出元データとが格納されているか否かを判定する判定手段と、前記識別子が格納されていない場合には前記受信したデータブロックを破棄する一方、前記識別子と前記算出元データとが格納されていると前記判定手段により判定され、かつ当該算出元データを用いて算出された値と当該識別子とが一致する場合に所定の処理を実行する制御手段とを有する
    ことを特徴とする通信システム。
  2. プロトコル階層毎に予め定められた通信プロトコルにしたがって通信網を介してデータブロックの送受信を行う送信装置と受信装置とを含み、
    前記送信装置は、前記受信装置へ送信するデータブロックが受信装置側でのフィルタリング条件を満たすか否かを判定し、前記フィルタリング条件を満たすと判定されたデータブロックのヘッダに、当該フィルタリング条件を満たすことを示す識別子を追記して送信する送信手段を有し、
    前記受信装置は、前記通信網を介して受信したデータブロックのヘッダに前記識別子が格納されているか否かを判定する判定手段と、前記識別子が格納されていた場合に所定の処理を実行する一方、前記識別子が格納されていない場合には当該データブロックを破棄する制御手段とを有する
    ことを特徴とする通信システム。
  3. 前記送信手段は、前記フィルタリング条件を満たすデータブロックのヘッダに前記識別子に加えて前記識別子の算出元になった算出元データを追記して送信し、
    前記判定手段は、受信したデータブロックのヘッダに前記識別子と前記算出元データとが格納されているか否かを判定し、
    前記制御手段は、前記識別子が格納されており、かつ当該算出元データを用いて算出された値と、当該識別子とが一致する場合に前記所定の処理を実行する
    ことを特徴とする請求項2に記載の通信システム。
  4. 前記識別子は、所定のハッシュ関数により算出されるハッシュ値である
    ことを特徴とする請求項1〜3の何れか1項に記載の通信システム。
  5. 前記送信手段は、前記識別子と前記算出元データとを複数のプロトコル階層のうちの互いに異なるプロトコル階層のヘッダに追記して送信する
    ことを特徴とする請求項1又は請求項3に記載の通信システム。
  6. 相手装置側でのフィルタリング条件を満たすデータブロックのヘッダに、前記フィルタリング条件に対応する識別子と前記識別子の算出元になった算出元データとを追記し、プロトコル階層毎に予め定められた通信プロトコルにしたがって、前記識別子と前記算出元データとを追記済みの前記データブロックを通信網を介して前記相手装置へ送信する送信手段
    を有することを特徴とする通信装置。
  7. 相手装置へ送信するデータブロックが前記相手装置でのフィルタリング条件を満たすか否かを判定し、前記フィルタリング条件を満たすと判定されたデータブロックのヘッダに、前記フィルタリング条件を満たすことを示す識別子を追記して送信する送信手段
    を有することを特徴とする通信装置。
  8. プロトコル階層毎に予め定められた通信プロトコルにしたがって通信網を介して相手装置から受信したデータブロックのヘッダに、前記データブロックを受信する際のフィルタリング条件に対応する識別子と前記識別子の算出元となった算出元データとが格納されているか否かを判定する判定手段と、
    前記識別子が格納されていない場合には前記受信したデータブロックを破棄する一方、前記識別子と前記算出元データとが格納されていると前記判定手段により判定され、かつ当該算出元データを用いて算出された値と当該識別子とが一致する場合に所定の処理を実行する制御手段と
    を有することを特徴とする通信装置。
JP2016002100A 2016-01-07 2016-01-07 通信システムおよび通信装置 Active JP6724367B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2016002100A JP6724367B2 (ja) 2016-01-07 2016-01-07 通信システムおよび通信装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2016002100A JP6724367B2 (ja) 2016-01-07 2016-01-07 通信システムおよび通信装置

Publications (2)

Publication Number Publication Date
JP2017123580A JP2017123580A (ja) 2017-07-13
JP6724367B2 true JP6724367B2 (ja) 2020-07-15

Family

ID=59305879

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016002100A Active JP6724367B2 (ja) 2016-01-07 2016-01-07 通信システムおよび通信装置

Country Status (1)

Country Link
JP (1) JP6724367B2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7234726B2 (ja) * 2019-03-20 2023-03-08 富士フイルムビジネスイノベーション株式会社 通信装置、通信システム、及びプログラム
CN111225052B (zh) * 2020-01-04 2023-03-28 普联技术有限公司 设备功能拓展方法、设备及存储介质

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3599552B2 (ja) * 1998-01-19 2004-12-08 株式会社日立製作所 パケットフィルタ装置、認証サーバ、パケットフィルタリング方法及び記憶媒体
FI109319B (fi) * 1999-12-03 2002-06-28 Nokia Corp Päätelaitteelle välitettävän elektronisen informaation suodattaminen
JP2002158699A (ja) * 2000-11-20 2002-05-31 Nippon Telegr & Teleph Corp <Ntt> DoS攻撃防止方法および装置およびシステムおよび記録媒体
JP4330342B2 (ja) * 2001-02-19 2009-09-16 富士通株式会社 通信のセキュリティを確保するためのパケットフィルタリング方法およびパケット通信システム
JP2006352917A (ja) * 2001-02-19 2006-12-28 Fujitsu Ltd 通信のセキュリティを確保するためのパケットフィルタリング方法およびパケット通信システム
KR100859664B1 (ko) * 2006-11-13 2008-09-23 삼성에스디에스 주식회사 전자메일의 바이러스 감염여부 판정방법

Also Published As

Publication number Publication date
JP2017123580A (ja) 2017-07-13

Similar Documents

Publication Publication Date Title
US12010135B2 (en) Rule-based network-threat detection for encrypted communications
US10298601B2 (en) Embedding information or information identifier in an IPv6 address
JP4664257B2 (ja) 攻撃検出システム及び攻撃検出方法
US10009271B2 (en) Routing method and network transmission apparatus
US20170034174A1 (en) Method for providing access to a web server
US8335858B2 (en) Transparent auto-discovery of network devices logically located between a client and server
US20100281159A1 (en) Manipulation of dhcp packets to enforce network health policies
US10009282B2 (en) Self-protecting computer network router with queue resource manager
JP6737610B2 (ja) 通信装置
US8630296B2 (en) Shared and separate network stack instances
JP6724367B2 (ja) 通信システムおよび通信装置
US9509600B1 (en) Methods for providing per-connection routing in a virtual environment and devices thereof
CN113872933B (zh) 隐藏源站的方法、系统、装置、设备及存储介质
JP4499622B2 (ja) トラフィック分散装置,トラフィック分散プログラム及びパケット中継方法
US20120047271A1 (en) Network address translation device and method of passing data packets through the network address translation device
JP5587085B2 (ja) 通信システム、制御装置及び制御プログラム
Wachs A secure and resilient communication infrastructure for decentralized networking applications
CN110650222A (zh) 一种网络访问方法及装置
US9800591B2 (en) Method and apparatus for processing packet on trill network
JP2014165560A (ja) サーバおよびプログラム
Bonica et al. RFC 8900: IP Fragmentation Considered Fragile
Enghardt et al. TAPS Working Group A. Brunstrom, Ed. Internet-Draft Karlstad University Intended status: Informational T. Pauly, Ed. Expires: 6 May 2021 Apple Inc.
Enghardt et al. TAPS Working Group A. Brunstrom, Ed. Internet-Draft Karlstad University Intended status: Informational T. Pauly, Ed. Expires: 10 September 2020 Apple Inc.
Enghardt et al. TAPS Working Group A. Brunstrom, Ed. Internet-Draft Karlstad University Intended status: Informational T. Pauly, Ed. Expires: May 7, 2020 Apple Inc.
WO2010114937A1 (en) Manipulation of dhcp packets to enforce network health policies

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20181126

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20190822

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20190903

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20191028

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200114

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200214

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20200526

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200608

R151 Written notification of patent or utility model registration

Ref document number: 6724367

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151