JP6330814B2 - 通信システム、制御指示装置、通信制御方法及びプログラム - Google Patents
通信システム、制御指示装置、通信制御方法及びプログラム Download PDFInfo
- Publication number
- JP6330814B2 JP6330814B2 JP2015532863A JP2015532863A JP6330814B2 JP 6330814 B2 JP6330814 B2 JP 6330814B2 JP 2015532863 A JP2015532863 A JP 2015532863A JP 2015532863 A JP2015532863 A JP 2015532863A JP 6330814 B2 JP6330814 B2 JP 6330814B2
- Authority
- JP
- Japan
- Prior art keywords
- node
- communication
- packet
- unit
- control instruction
- 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
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/64—Hybrid switching systems
- H04L12/6418—Hybrid transport
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
[関連出願についての記載]
本発明は、日本国特許出願:特願2013−171266号(2013年8月21日出願)に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、通信システム、制御指示装置、通信制御方法及びプログラムに関し、特に、ノード間の通信を制御する通信システム、制御指示装置、通信制御方法及びプログラムに関する。
本発明は、日本国特許出願:特願2013−171266号(2013年8月21日出願)に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、通信システム、制御指示装置、通信制御方法及びプログラムに関し、特に、ノード間の通信を制御する通信システム、制御指示装置、通信制御方法及びプログラムに関する。
近年、オープンフロー(OpenFlow)という技術が提案されている(非特許文献1、2参照)。オープンフローは、通信をエンドツーエンドのフローとして捉え、フロー単位で経路制御、障害回復、負荷分散、最適化を行うものである。非特許文献2に仕様化されているオープンフロースイッチは、オープンフローコントローラとの通信用のセキュアチャネルを備え、オープンフローコントローラから適宜追加または書き換え指示されるフローテーブルに従って動作する。フローテーブルには、フロー毎に、パケットヘッダと照合するマッチ条件(Match Fields)と、フロー統計情報(Counters)と、処理内容を定義したインストラクション(Instructions)と、の組が定義される(非特許文献2の「4.1 Flow Table」の項参照)。
例えば、オープンフロースイッチは、パケットを受信すると、フローテーブルから、受信パケットのヘッダ情報に適合するマッチ条件(非特許文献2の「4.3 Match Fields」参照)を持つエントリを検索する。検索の結果、受信パケットに適合するエントリが見つかった場合、オープンフロースイッチは、フロー統計情報(カウンタ)を更新するとともに、受信パケットに対して、当該エントリのインストラクションフィールドに記述された処理内容(指定ポートからのパケット送信、フラッディング、廃棄等)を実施する。一方、検索の結果、受信パケットに適合するエントリが見つからなかった場合、オープンフロースイッチは、セキュアチャネルを介して、オープンフローコントローラに対してエントリ設定の要求、即ち、受信パケットを処理するための制御情報の送信要求(Packet−Inメッセージ)を送信する。オープンフロースイッチは、処理内容が定められたフローエントリを受け取ってフローテーブルを更新する。このように、オープンフロースイッチは、フローテーブルに格納されたエントリを制御情報として用いてパケット転送を行う。
特許文献1には、ロールベースアクセス制御(Role−Based Access Control、以下、「RBAC」)を行うアクセス制御装置の一例が開示されている。同文献のアクセス制御装置は、ユーザ毎に属性値が設定されるユーザ情報テーブルと、属性値の組み合わせを示すロールが設定されるロール情報テーブルと、コンテンツ毎にアクセス条件としてロールIDが設定されるアクセス制御テーブルとを記憶する。そして、同文献のアクセス制御装置は、ユーザ情報テーブルとロール情報テーブルとに基づいて、属性値がロールに対応するユーザのリストをロール毎にユーザリスト情報テーブルに設定する。コンテンツへのアクセス要求が発生した場合、アクセス制御部は、アクセス制御テーブルに基づいてアクセス条件のロールを特定し、特定したロールのユーザリストにアクセスユーザが含まれるかによりアクセス権限を判定する、と記載されている。
Nick McKeownほか7名、"OpenFlow: Enabling Innovation in Campus Networks"、[online]、[平成25(2013)年8月7日検索]、インターネット〈URL: http://www.openflow.org/documents/openflow-wp-latest.pdf〉
"OpenFlow Switch Specification" Version 1.1.0 Implemented (Wire Protocol 0x02)、[online]、[平成25(2013)年8月7日検索]、インターネット〈URL:http://www.openflow.org/documents/openflow-spec-v1.1.0.pdf〉
以下の分析は、本発明によって与えられたものである。非特許文献1、2の技術を用いれば、経路上のオープンフロースイッチにロールを考慮したフローエントリを設定することで、特許文献1のようなロールベースのアクセス制御はもちろんのこと、経路制御まで実現可能となる。
ところで、近年のサイバーアタックは、社外から社内のノードにアクセスし、その社内のノードを踏み台にして社内の他のノードに更にアクセスして情報を収集することが行われる。よって、このような攻撃を防ぐためには、あるノードが、いつの間にか踏み台(英語圏では、「Zombie」と呼ばれる)として動作していることを検出し、かかる踏み台の挙動を制御する技術が望まれている。
しかしながら、上記の特許文献及び非特許文献記載の技術では、上記踏み台や「Zombie」として動作するノードの挙動を制御することが出来ないという問題点がある。その理由は、あるノードの接続時に相応のアクセス制御を行うものの、その後に、踏み台や「Zombie」として動作を開始したことを検出する仕組みが存在しないからである。
本発明は、通信を許可したノードが、上述した踏み台や「Zombie」として動作することを抑止することのできる通信システム、制御指示装置、通信制御方法及びプログラムを提供することを目的とする。
第1の視点によれば、所定の制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置と、前記制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部と、前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードにサービスを提供する側にあるか否かを判断するノード状態判断部と、少なくとも前記ノードが他のノードにサービスを提供する側にある場合、当該ノードから他のノードへの新規通信を禁止する制御指示部と、を備える制御指示装置と、を含む通信システムが提供される。
第2の視点によれば、制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部と、前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードにサービスを提供する側にあるか否かを判断するノード状態判断部と、少なくとも前記ノードが他のノードにサービスを提供する側にある場合、当該ノードから他のノードへの新規通信を禁止する制御指示部と、を備える制御指示装置が提供される。
第3の視点によれば、所定の制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置に接続され、前記制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部を備えたコンピュータが、前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードにサービスを提供する側にあるか否かを判断するステップと、少なくとも前記ノードが他のノードにサービスを提供する側にある場合、当該ノードから他のノードへの新規通信を禁止するステップと、を含む通信制御方法が提供される。本方法は、制御実施装置を制御する制御指示装置として機能するコンピュータという、特定の機械に結びつけられている。
第4の視点によれば、所定の制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置に接続され、前記制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部を備えたコンピュータに、前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードにサービスを提供する側にあるか否かを判断する処理と、少なくとも前記ノードが他のノードにサービスを提供する側にある場合、当該ノードから他のノードへの新規通信を禁止する処理と、を実行させるプログラムが提供される。なお、このプログラムは、コンピュータが読み取り可能な(非トランジエントな)記憶媒体に記録することができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。
本発明によれば、通信を許可したノードが、上述した踏み台や「Zombie」として動作することを抑止することが可能となる。
はじめに本発明の一実施形態の概要について図面を参照して説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、本発明を図示の態様に限定することを意図するものではない。
本発明は、その一実施形態において、図1に示すように、所定の制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置(図1の20)と、この制御実施装置に対して指示を与える制御指示装置(図1の10)とを接続した構成にて実現できる。
より具体的には、制御指示装置(図1の10)は、前記制御実施装置(図1の20)を介したノード間の通信履歴を管理する通信履歴管理部(図1の13)と、前記通信履歴管理部(図1の13)の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードにサービスを提供する側にあるか否かを判断するノード状態判断部(図1の12)と、少なくとも前記ノードが他のノードにサービスを提供する側にある場合、当該ノードから他のノードへの新規通信を禁止する制御指示部(図1の11)と、を備える。
以上のように、制御指示装置(図1の10)を動作させることで、サービスを提供する側にあるノード、即ち、サーバ等として動作しているコンピュータが、踏み台にされ、通信を開始しようとしていることを検出し、その通信を禁止することが可能となる。
[第1の実施形態]
続いて、本発明の第1の実施形態について図面を参照して詳細に説明する。図1は、本発明の第1の実施形態の通信システムの構成を示す図である。図1を参照すると、制御実施装置20と、制御実施装置20に指示を与えることでノード間の通信を実現する制御指示装置10と、を接続した構成が示されている。
続いて、本発明の第1の実施形態について図面を参照して詳細に説明する。図1は、本発明の第1の実施形態の通信システムの構成を示す図である。図1を参照すると、制御実施装置20と、制御実施装置20に指示を与えることでノード間の通信を実現する制御指示装置10と、を接続した構成が示されている。
制御指示装置10は、受信パケットのヘッダ等に格納された情報を記録することで、ノード間の通信履歴を管理する通信履歴管理部13と、通信履歴管理部13に記録された通信履歴を参照して、制御実施装置20から処理方法の問い合せを受けたパケットの送信元又は送信先のノードの状態を判断するノード状態判断部12と、制御実施装置20に対し、前記ノード状態に基づいて決定した受信パケットの処理に関する指示メッセージ等を送信する制御指示部11とを備える。
制御実施装置20は、制御指示装置10と制御情報を含んだ制御メッセージを送受信する通信部21と、通信部21から受信した制御情報を用いて受信パケットを処理するパケット処理部22とを備えている。
制御指示装置10の通信履歴管理部13は、受信パケットのヘッダ等に格納された情報を記録するためのエントリを保持している。
図2は、通信履歴管理部13に保持されるエントリの一例を示す図である。図2の例では、パケットの発信元や送信先の識別子や、サービスやプロトコルの識別子が記録される。なお、図2の例では、送信元の識別子を1つ記録する例を示したが、ネットワークの各レイヤの識別子など、複数の識別子を記録してもよい。例えば、OSI(Open Systems Interconnection)参照モデルのレイヤ2(L2)の識別子であるMAC(Media Access Control)アドレスやレイヤ3(L3)の識別子であるIP(Internet Protocol)アドレスを記録してもよい。同様に、送信先の識別子も複数記録してもよい。また、送信元および送信先のサービスやプロトコルの識別子についても、1つだけではなく、複数記録してもよい。
制御指示装置10のノード状態判断部12は、通信履歴管理部13に記録されている情報を参照して、これから通信を行おうとしているノードの状態の判定を行う。ノードの状態の判定方法については、後に具体例を示して詳細に説明する。
制御指示装置10の制御指示部11は、ノード状態判断部12の判定結果に基づいたアクセス制御(制御実施装置への指示)を行う。また、制御指示部11は、通信履歴管理部13に、処理対象のパケットから抽出した上記識別子等を記録する。
ここで、ノード状態判断部12におけるノードの状態の判定の動作について説明する。ノード状態判断部12は、制御実施装置20から処理方法の問い合わせを受けたパケットの送信元又は送信先のノードの識別子等が通信履歴管理部13に記録されている場合、その情報に基づいて、前記ノードが「クライアント状態」又は「サーバ状態」となっていないかを確認する。ここで、「サーバ状態」とは、そのノードが通信のコネクションを受け付けている状態、つまり、クライアント等からの要求に応じてサービスを提供している状態である。一方、クライアント状態とは、そのノードから他のノードへコネクションを張っている状態、つまり、サーバ等に対してサービスの提供を受けているである。
具体的には、ノード状態判断部12は、通信履歴管理部13に記録されている情報を参照して、当該ノードをパケット送信先として通信が開始された通信履歴があった場合、前記ノードが他のノードからコネクションを受け付けているとみなし、当該ノードを「サーバ状態」であると判定する。また、当該ノードがパケットの送信元として通信が開始された通信履歴があった場合、当該ノードから他のノードへコネクションを張っているとみなし、「クライアント状態」であると判定する。なお、通信履歴に当該ノードに関する情報が無い場合、ノード状態判断部12は、サーバ状態とクライアント状態のどちらでもないと判定する。
ノード状態判断部12は、制御実施装置20から処理方法の問い合わせを受けたパケットの送信元のノードについても同様の判定を行う。
制御指示部11は、前記ノード状態判断部12による判定結果に基づいたアクセス制御を行う。
図3は、制御指示部11が通信を許可するか否かを判断するため使用するポリシーの一例を示す図である。図3の1番目のエントリは、パケットの送信先ノードが、クライアント状態ではないとき、すなわちサーバ状態もしくはどちらの状態でもないとき、通信を許可することを定めている。
逆に、制御実施装置20から処理方法の問い合わせを受けたパケットの送信先のノードが、クライアント状態である場合、制御指示部11は、当該ノードがサーバ状態になることを禁止する。具体的には、制御指示部11は、制御実施装置20に対し、当該ノードが他のノードからコネクションを受け付けないように、パケットを破棄するように指示を行う。
図3の2番目のエントリは、パケットの送信元ノードが、サーバ状態ではないとき、すなわちクライアント状態もしくはどちらの状態でもないとき、通信を許可することを定めている。具体的には、制御実施装置20から処理方法の問い合わせを受けたパケットの送信元ノードがサーバ状態ではないとき、制御指示部11は、前記パケットを転送するように、制御実施装置20に指示する。
逆に、制御実施装置20から処理方法の問い合わせを受けたパケットの送信元のノードが、サーバ状態である場合、制御指示部11は、当該ノードがクライアント状態になることを禁止する。具体的には、制御指示部11は、制御実施装置20に対し、当該ノードが他のノードにコネクションを張らないように、パケットを破棄するように指示を行う。
以上を総合し、パケット送信元と送信先の両方のノードについて、判定が「許可」であるとき、制御指示部11は、制御実施装置20から処理方法の問い合わせを受けたパケットを転送する(アクセスを許可)ように、制御実施装置20に指示する。一方、どちらかでも「禁止」の判定であった場合は、制御指示部11は、パケットの破棄を指示(アクセスを禁止)する。
また、制御指示部11は、以上の判定の結果を用いて、通信履歴管理部13への記録を行う。即ち、前記アクセス可否の判定が「許可」であり、かつ、送信元と送信先が同じであるエントリがテーブルに存在しないとき、制御指示部11は、通信履歴管理部13に、送信元と送信先の識別子等を対応付けたエントリとして追加する。このとき、サービスやプロトコルの識別子も、エントリの中に含めてもよい(図2参照)。
図4は、ノード間の通信履歴による制御指示装置の動作をまとめたものである。大きく分けて6つのパターンに類別されるので、以下、これらについて説明する。
(1)通信履歴に、制御実施装置からの問い合わせの通信の送信先と送信元のどちらも出現しないとき
まず、ノードの状態の判断について説明する。この場合、通信履歴に送信元であるノード1の記録が無いので、「サーバでもクライアント状態でもない」、また、通信履歴に送信先であるノード2の記録も無いので、「サーバでもクライアント状態でもない」と判断される。
この結果、図3のテーブルを用いたアクセス可否の判定は、送信元は「サーバでもクライアント状態でもない」ので「許可」である。また、送信先も「サーバでもクライアント状態でもない」ので「許可」である。送信元と送信先が許可であるので、このアクセスは許可される。
また、通信記憶にはこの通信の記録が存在しないので、制御指示部11は、新たなエントリを追加する。
まず、ノードの状態の判断について説明する。この場合、通信履歴に送信元であるノード1の記録が無いので、「サーバでもクライアント状態でもない」、また、通信履歴に送信先であるノード2の記録も無いので、「サーバでもクライアント状態でもない」と判断される。
この結果、図3のテーブルを用いたアクセス可否の判定は、送信元は「サーバでもクライアント状態でもない」ので「許可」である。また、送信先も「サーバでもクライアント状態でもない」ので「許可」である。送信元と送信先が許可であるので、このアクセスは許可される。
また、通信記憶にはこの通信の記録が存在しないので、制御指示部11は、新たなエントリを追加する。
(2)通信履歴に、制御実施装置からの問い合わせの通信の送信元(ノード1)と送信先(ノード2)と同一の組み合わせの通信があるとき
この場合、通信履歴に、制御実施装置からの問い合わせの通信の送信元(ノード1)は、送信元と記録されており、「クライアント状態」であると判定される。制御実施装置20からの問い合わせの通信の送信先(ノード2)も、通信履歴に送信先と記録されており、「サーバ状態」であると判定される。
この結果、図3のテーブルを用いたアクセス可否の判定は、パケット送信元(ノード1)は「クライアント状態」なので「許可」である。同様に、パケット送信先(ノード2)は「サーバ状態」であるので「許可」である。送信元(ノード1)と送信先(ノード2)のいずれもが許可であるので、当該アクセスは許可される。
また、通信記憶には同一の通信記録がすでに存在するので、制御指示部11は、通信記憶管理部13への新たなエントリの追加を行わない。
この場合、通信履歴に、制御実施装置からの問い合わせの通信の送信元(ノード1)は、送信元と記録されており、「クライアント状態」であると判定される。制御実施装置20からの問い合わせの通信の送信先(ノード2)も、通信履歴に送信先と記録されており、「サーバ状態」であると判定される。
この結果、図3のテーブルを用いたアクセス可否の判定は、パケット送信元(ノード1)は「クライアント状態」なので「許可」である。同様に、パケット送信先(ノード2)は「サーバ状態」であるので「許可」である。送信元(ノード1)と送信先(ノード2)のいずれもが許可であるので、当該アクセスは許可される。
また、通信記憶には同一の通信記録がすでに存在するので、制御指示部11は、通信記憶管理部13への新たなエントリの追加を行わない。
(3)通信履歴に、制御実施装置からの問い合わせの通信の送信元(ノード2)が通信の送信先として記録されているとき
この場合、通信履歴に、制御実施装置からの問い合わせの通信の送信元(ノード2)は、送信先と記録されているので、「サーバ状態」と判定される。
この結果、図3のテーブルを用いたアクセス可否の判定は、通信の送信元(ノード2)は「サーバ状態」なので「禁止」である。よって、送信先(ノード3)の状態に拘らず、当該通信は禁止される。
また、この場合も通信記憶管理部13への新たなエントリの追加を行わない。なぜなら、通信は禁止され、パケットが破棄されるため、実際の通信は発生しないためである。
この場合、通信履歴に、制御実施装置からの問い合わせの通信の送信元(ノード2)は、送信先と記録されているので、「サーバ状態」と判定される。
この結果、図3のテーブルを用いたアクセス可否の判定は、通信の送信元(ノード2)は「サーバ状態」なので「禁止」である。よって、送信先(ノード3)の状態に拘らず、当該通信は禁止される。
また、この場合も通信記憶管理部13への新たなエントリの追加を行わない。なぜなら、通信は禁止され、パケットが破棄されるため、実際の通信は発生しないためである。
(4)通信履歴に、制御実施装置からの問い合わせの通信の送信先(ノード2)が通信の送信元として記録されているとき
この場合、通信履歴に、制御実施装置からの問い合わせの通信の送信先(ノード2)は、送信元と記録されているので、「クライアント状態」であると判定される。
この結果、図3のテーブルを用いたアクセス可否の判定は、送信先が「クライアント状態」であるので、「禁止」と判断される。よって、送信元(ノード1)の状態に拘らず、当該通信は禁止される。
また、この場合も通信記憶管理部13への新たなエントリの追加を行わない。なぜなら、通信は禁止され、パケットが破棄されるため、実際の通信は発生しないためである。
(5)通信履歴に、制御実施装置からの問い合わせの通信の送信元(ノード1)が別の通信の送信元として記録されているとき
この場合、(2)の場合と同様に、制御実施装置からの問い合わせの通信の送信元(ノード1)は、テーブルにも送信元と記載されているので、「クライアント状態」であると判定される。また、図3のテーブルを用いたアクセス可否の判定は、「許可」となる。
制御実施装置からの問い合わせの通信の送信先(ノード3)が、(4)で示した例のようにクライアント状態で無い場合、すわなち(1)の場合のようにサーバとクライアントのどちらでもない状態の場合か、(1)の例のように、送信先(ノード3)がサーバ状態の場合、送信先(ノード3)についても「許可」の判定となる。この結果、送信元と送信先の両方が「許可」であるため、当該通信は許可される。
また、通信記憶にはこの通信の記録が存在しないので、制御指示部11は、新たなエントリを追加する。
なお、送信先(ノード3)が、(4)の場合のように、クライアント状態である場合は、通信は禁止され、テーブルにもエントリは追加されない。
(6)通信履歴に、制御実施装置からの問い合わせの通信の送信先が別の通信の送信先として記録されているとき
この場合、(2)の場合と同様に、制御実施装置からの問い合わせの通信の送信先(ノード2)は、テーブルにも送信先と記録されているので「サーバ状態」であると判定される。また、図3のテーブルを用いたアクセス可否の判定も、「許可」となる。
一方で、送信元(ノード3)が(1)の場合のように「サーバ状態でもクライアント状態でもない」場合や、(2)のようにクライアント状態であるときは、送信元(ノード3)についても許可であり、送信元と送信先の両方が「許可」の判定であるので、通信は許可される。
なお、通信記憶にはこの通信の記録が存在しないので、制御指示部11は、新たなエントリを追加する。
なお、送信先(ノード2)が、(4)の場合のように、クライアント状態である場合は、通信は禁止され、通信履歴へのエントリの追加も行われない。
この場合、通信履歴に、制御実施装置からの問い合わせの通信の送信先(ノード2)は、送信元と記録されているので、「クライアント状態」であると判定される。
この結果、図3のテーブルを用いたアクセス可否の判定は、送信先が「クライアント状態」であるので、「禁止」と判断される。よって、送信元(ノード1)の状態に拘らず、当該通信は禁止される。
また、この場合も通信記憶管理部13への新たなエントリの追加を行わない。なぜなら、通信は禁止され、パケットが破棄されるため、実際の通信は発生しないためである。
(5)通信履歴に、制御実施装置からの問い合わせの通信の送信元(ノード1)が別の通信の送信元として記録されているとき
この場合、(2)の場合と同様に、制御実施装置からの問い合わせの通信の送信元(ノード1)は、テーブルにも送信元と記載されているので、「クライアント状態」であると判定される。また、図3のテーブルを用いたアクセス可否の判定は、「許可」となる。
制御実施装置からの問い合わせの通信の送信先(ノード3)が、(4)で示した例のようにクライアント状態で無い場合、すわなち(1)の場合のようにサーバとクライアントのどちらでもない状態の場合か、(1)の例のように、送信先(ノード3)がサーバ状態の場合、送信先(ノード3)についても「許可」の判定となる。この結果、送信元と送信先の両方が「許可」であるため、当該通信は許可される。
また、通信記憶にはこの通信の記録が存在しないので、制御指示部11は、新たなエントリを追加する。
なお、送信先(ノード3)が、(4)の場合のように、クライアント状態である場合は、通信は禁止され、テーブルにもエントリは追加されない。
(6)通信履歴に、制御実施装置からの問い合わせの通信の送信先が別の通信の送信先として記録されているとき
この場合、(2)の場合と同様に、制御実施装置からの問い合わせの通信の送信先(ノード2)は、テーブルにも送信先と記録されているので「サーバ状態」であると判定される。また、図3のテーブルを用いたアクセス可否の判定も、「許可」となる。
一方で、送信元(ノード3)が(1)の場合のように「サーバ状態でもクライアント状態でもない」場合や、(2)のようにクライアント状態であるときは、送信元(ノード3)についても許可であり、送信元と送信先の両方が「許可」の判定であるので、通信は許可される。
なお、通信記憶にはこの通信の記録が存在しないので、制御指示部11は、新たなエントリを追加する。
なお、送信先(ノード2)が、(4)の場合のように、クライアント状態である場合は、通信は禁止され、通信履歴へのエントリの追加も行われない。
続いて、本実施形態の制御実施装置20について、再度図1を参照して詳細に説明する。制御実施装置20は、通信部21と、パケット処理部22とを備えている。
通信部21は、パケット処理部22から、受信パケットに対する処理内容の問い合わせを要求するメッセージの送信指示を受けると、制御指示装置10に対して該メッセージを送信する。また、制御指示装置10から該メッセージに対する応答メッセージを受け取ると、通信部21は、パケット処理部22に対し制御指示装置10から受け取った指示を送信する。
制御実施装置20のパケット処理部22は、新規パケットを受信した際、パケット処理部22に備えられた指示キャッシュ23の中から、受信パケットに適合するエントリを検索する。前記検索の結果、前記受信パケットに適合するエントリが見つかった場合、パケット処理部22は、該エントリに従いパケットを処理する。一方、前記受信パケットに適合するエントリが見つからなかった場合、パケット処理部22は、通信部21に対して、制御指示装置10へ前記受信パケットに対する処理内容を問い合わせるメッセージの送信を要求する。前記メッセージに対する応答として、指示キャッシュ23に格納するエントリを受信した場合、パケット処理部22は、指示キャッシュ23は、当該エントリを指示キャッシュ23に格納する。これにより、同一の特徴を持つパケットは、前記指示キャッシュ23に格納されたエントリを用いて処理される。また、前記メッセージに対する応答として、制御指示装置10からパケットの出力指示の処理命令等を受けた場合、パケット処理部22は、制御指示装置10から受信したパケットに対し、指示された処理内容を適用する。
なお、図1に示した制御指示装置10及び制御実施装置20の各部(処理手段)は、これらの装置を構成するコンピュータに、そのハードウェアを用いて、上記した各処理を実行させるコンピュータプログラムにより実現することもできる。
続いて、本実施形態の動作について図面を参照して詳細に説明する。図5、図6は、本発明の第1の実施形態の制御指示装置による通信制御の具体例を説明するための図である。図5は、ノードB、ノードC間の通信が確立された後(パケットBを送信)、ノードAからノードBへアクセスを試みる場合(パケットAを送信)を示している。この図では、ノードBは、ノードCと通信をしている際はクライアント状態である。この状態で、ノードAからアクセスを受け付けるとサーバ状態となり、所謂踏み台として動作している状態となってしまう。本実施形態の制御指示装置10により、クライアント状態で動作中のノードのサーバ状態での通信が禁止されるまでの流れを図7〜図10を参照して説明する。
図7、図8は、本発明の第1の実施形態の通信システムの全体の動作を表したシーケンス図である。図7を参照すると、まず、通信を開始するノードBが、ノードC宛てのパケットを制御実施装置20へ送る(ステップX1)。または、ノードBがノードCへ送信したパケットを、制御実施装置20がフックしてもよい。
制御実施装置20は、ノードBからのパケットを受信すると、ノードBからノードCへコネクションを張って良いかどうか確認するために、制御実施装置20の指示キャッシュ23から、当該パケットに適合するエントリを検索する(ステップX2)。
ここで、図9を参照してステップX2の動作の詳細を説明する。制御実施装置20のパケット処理部22は、ノードBからノードCへのパケットを受信すると(ステップS1)、受信パケットのヘッダ情報を基に指示キャッシュ23内に該当エントリがあるか検索を行う(ステップS2)。既にノードB、ノードC間のコネクションが張られている場合は、指示キャッシュ23に該当するエントリが存在するため、そのエントリの処理内容をパケットに適用することになる。ここでは、新規通信であるため、指示キャッシュ23に、当該パケットに適合するエントリがないので、パケット処理部22は、通信部21に対し、制御指示装置10へ当該パケットの処理内容を問い合わせるメッセージの送信を依頼する(ステップS3)。
再度、図7に戻ると、制御実施装置20の通信部21からの問い合わせメッセージを受信した、制御指示装置10は、受信したメッセージに含まれるパケットの情報を元に、送受信ノードの状態を確認する(ステップX3)。
ここで、図10を参照してステップX3の動作の詳細を説明する。制御指示装置10内のノード状態判断部12は、制御実施装置20からの問い合わせメッセージを受信すると(ステップT1)、受信したメッセージ内にパケットヘッダの情報から、送信元と送信先として指定されたノードBとノードCの識別子をキーに通信履歴管理部13内の通信履歴を検索する(ステップT2)。この例の場合、ノードB、ノードC間の通信履歴は記録されていないので、ノード状態判断部12は「履歴なし」と回答する。この回答を受けた制御指示部11は、パケットBが初めてのパケットであり、ノードBとノードCの双方がサーバ状態とクライアント状態のいずれでもないと判定し、通信を許可する(ステップT3)。
再度、図7に戻ると、制御指示装置10の制御指示部11は、通信履歴管理部13に、前記通信を許可すると判定したノードB、ノードC間の通信履歴を登録する(ステップX4)。次に、制御指示装置10の制御指示部11は、制御実施装置20に対し、ノードBからノードC宛てのパケットを送受信するよう指示する。具体的には、制御指示装置10は、制御実施装置20に対し、ステップX1にて受信したパケットをノードCへ転送するよう指示するメッセージと、以降のノードBからのパケットをノードCへ転送することを指示する処理内容を含むエントリを指示キャッシュ23に格納させるメッセージとを送信する(ステップX5)。
前記メッセージを受け取った制御実施装置20は、受信したパケットをノードCに送信するとともに、制御指示装置10からの指示内容を、指示キャッシュ23に格納する(ステップX6)。
ノードCは、制御実施装置20から送信されたパケットを受信する(ステップX7)。以上により、ノードBからノードCへのパケット送信が可能化される。
次に、図8を参照して、その後、ノードAがノードBへパケットを送信する場合の動作を説明する。ノードAがノードBへパケットを送信すると(ステップX8)、制御実施装置20は、制御実施装置20内の指示キャッシュ23を検索する。これまでのステップX1〜ステップX7の処理では、ノードAからノードB宛てのパケットに関する指示は、指示キャッシュ23へ格納されていないため、制御実施装置20は、制御指示装置10に対し、受信したパケットの処理内容を問い合わせるメッセージを送信する(ステップX9)。
制御実施装置20の通信部21からの問い合わせメッセージを受信した制御指示装置10のノード状態判断部12は、受信したメッセージに含まれるパケットの情報を元に、送受信ノードの状態を確認する(ステップX10)。通信履歴管理部13にはノードB−ノードC間の通信履歴が登録されているため、ノード状態判断部12は、通信履歴管理部13からノードBに関する情報を取得することになる。この結果、制御指示部11は、ノードBがパケットを送信していることを確認し、ノードBは「クライアント状態」であると判断する。一方、ノードAに関する通信履歴は、通信履歴管理部13に登録されていないので、制御指示部11は、ノードAがサーバとクライアントのどちらの状態でもないと判断する(ステップX10)。
その後、制御指示部11は、ノードBが既にクライアント状態として動作しているため、ノードAからノードBへのアクセスを禁止する(ステップX11)。具体的には、制御指示部11は、ノードAからノードB宛てのパケットを破棄することを指示するエントリを指示キャッシュ23に追加するよう、制御実施装置20へ指示する。また、この際、ノードA、ノードB間の通信履歴は、通信履歴管理部13にも登録されない。
制御実施装置20は、制御指示装置10の制御指示部11からの指示に基づいて、以降ノードAからノードB宛てのパケットを破棄する(ステップX12)。
以上の動作によって、ノードAからノードBへの通信、すなわち、クライアント状態であったノードBがサーバとなるような通信を禁止することができる。
次にサーバ状態で動作するノードがさらにクライアント状態として動作することを禁止する例について説明する。図6は、ノードA、ノードB間の通信が確立された後(パケットAを送信)、ノードBがノードCへのアクセスを試みる場合(パケットBを送信)を示している。この図では、ノードBは、ノードAと通信をしている際はサーバ状態である。この状態で、ノードCへのアクセスを開始するとクライアント状態となり、所謂踏み台として動作している状態となってしまう。本実施形態の制御指示装置10により、サーバ状態で動作中のノードによる新たな通信が禁止されるまでの流れを図11〜図12を参照して説明する。
図11、図12は、本発明の第1の実施形態の通信システムの全体の動作を表した別のシーケンス図である。図11を参照すると、まず、通信を開始するノードAが、ノードB宛てのパケットを制御実施装置20へ送る(ステップY1)。
制御実施装置20は、ノードAからのパケットを受信すると、ノードAからノードBへコネクションを張って良いかどうか確認するために、制御実施装置20の指示キャッシュ23から、当該パケットに適合するエントリを検索する(ステップY2)。ステップY2の動作は、図9に示したものと同様であり、制御実施装置20から制御指示装置10に対し、受信パケットに適用する処理内容を問い合わせるメッセージが送信される。その他の詳細は、図9と同様であるため説明を省略する。
制御実施装置20の通信部21からの問い合わせメッセージを受信した、制御指示装置10は、受信したメッセージに含まれるパケットの情報を元に、送受信ノードの状態を確認する(ステップY3)。ここでは、通信履歴管理部13にノードA、ノードB間の通信履歴は記録されていないので、制御指示装置10は、ノードAとノードBの双方がサーバ状態とクライアント状態のいずれでもないと判定し、通信を許可することになる。その他の詳細は、図10と同様であるため説明を省略する。
その後、制御指示装置10の制御指示部11は、通信履歴管理部13に、前記通信を許可すると判定したノードA、ノードB間の通信履歴を登録する(ステップY4)。次に、制御指示装置10の制御指示部11は、制御実施装置20に対し、ノードAからノードB宛てのパケットを送受信するよう指示する。具体的には、制御指示装置10は、制御実施装置20に対し、ステップY1にて受信したパケットをノードBへ転送するよう指示するメッセージと、以降のノードAからの受信パケットをノードBへ転送することを指示する処理内容を含むエントリを指示キャッシュ23に格納させるメッセージとを送信する(ステップY5)。
前記メッセージを受け取った制御実施装置20は、受信したパケットをノードBに送信するとともに、制御指示装置10からの指示内容を、指示キャッシュ23に格納する(ステップY6)。
ノードBは、制御実施装置20から送信されたパケットを受信する(ステップY7)。以上により、ノードAからノードBへのパケット送信が可能化される。
次に、図12を参照して、その後、ノードBがノードCへパケットの送信を試みた場合の動作を説明する。ノードBがノードCへパケットを送信すると(ステップY8)、制御実施装置20は、制御実施装置20内の指示キャッシュ23を検索する。これまでのステップY1〜ステップY7の処理では、ノードBからノードC宛てのパケットに関する指示は、指示キャッシュ23へ格納されていないため、制御実施装置20は、制御指示装置10に対し、受信したパケットの処理内容を問い合わせるメッセージを送信する(ステップY9)。
制御実施装置20の通信部21からの問い合わせメッセージを受信した制御指示装置10のノード状態判断部12は、受信したメッセージに含まれるパケットの情報を元に、送受信ノードの状態を確認する(ステップY10)。通信履歴管理部13にはノードA−ノードB間の通信履歴が登録されているため、ノード状態判断部12は、通信履歴管理部13からノードBに関する情報を取得することになる。この結果、制御指示部11は、ノードBがパケットを受信していることを確認し、ノードBは「サーバ状態」であると判断する。一方、ノードCに関する通信履歴は、通信履歴管理部13に登録されていないので、制御指示部11は、ノードAがサーバとクライアントのどちらの状態でもないと判断する(ステップY10)。
その後、制御指示部11は、ノードBが既にサーバ状態として動作しているため、ノードBからノードCへのアクセスを禁止する(ステップY11)。具体的には、制御指示部11は、ノードBからノードC宛てのパケットを破棄することを指示するエントリを指示キャッシュ23に追加するよう、制御実施装置20へ指示する。また、この際、ノードB、ノードC間の通信履歴は、通信履歴管理部13にも登録されない。
制御実施装置20は、制御指示装置10の制御指示部11からの指示に基づいて、以降ノードBからノードC宛てのパケットを破棄する(ステップY12)。
以上の動作によって、ノードBからノードCへの通信、すなわち、サーバ状態であったノードBがクライアントとなるような通信を禁止することができる。
なお、上記した実施形態では、通信履歴管理部13に、送信元と送信先の識別子等を対応付けたエントリを登録するものとして説明したが、これらの識別子に代えて、受信パケットの送信先IPアドレスおよびポート番号を用いることができる。
また、上記した実施形態では、制御指示装置10の通信履歴や、制御実施装置20の指示キャッシュ23のエントリを掃き出すタイミングについて触れなかったが、例えば、一定時間使用されないエントリをタイムアウトとして削除する制御を行うことが望ましい(エージング処理)。なお、制御実施装置20において、このタイムアウトが起こった場合、制御実施装置20は、制御指示装置10に対し、タイムアウトによりエントリを削除したことを示すメッセージを送信することが望ましい。制御指示装置10は、前記通知に基づいて、制御指示装置10側の通信履歴管理部13の対応するエントリを削除することができる。
あるいは、制御実施装置20側に、ノード間の通信終了を検出する機構を追加し、より的確に指示キャッシュ23のエントリの要否を判断させるようにしてもよい。前記ノード間の通信終了を検出する機構としては、コネクション型通信プロトコルの終了メッセージをチェックする方法が挙げられる。例えば、TCP(Transmission Control Protocol)では、FINフラグやその逆方向からのACKフラグのチェックにより、通信の終了を検知することができる。この場合も、制御実施装置20が、制御指示装置10に対し、フロー終了検出により指示キャッシュ23のエントリを削除したことを示すメッセージを送信することが望ましい。制御指示装置10は、前記通知に基づいて、制御指示装置10側の通信履歴管理部13の対応するエントリを削除することができる。
また、上述した制御実施装置20は、ファイアーウォールやネットワークスイッチとして実装されてもよい。また、上記した説明では、制御実施装置20は、物理的な装置であるものとして説明したが、例えば、ノードA、ノードB、ノードC上、即ち、通信端末上で動作するソフトウェアで実装されたパーソナルファイアウォールや仮想スイッチであってもよい。
[第2の実施形態]
続いて、より細かく通信許可/禁止判定を判断できるようにした本発明の第2の実施形態について、図面を参照して詳細に説明する。図13は、本発明の第2の実施形態の通信システムの構成を示す図である。図13を参照すると、第1の実施形態と比較して、制御指示装置10a側の構成に変更が加えられており、通信履歴管理部13に代えて、通信履歴のほか、ノード状態判定情報やアクセス制御ポリシーを格納するテーブル群13aが備えられている。また、第1の実施形態では、ノード状態判断部12は、ノードがコネクションを受け付けていればサーバ状態、当該ノードから他ノードへコネクションを張っていればクライアント状態であると判定したが、第2の実施形態では、これらのテーブル群13aを参照してノード状態やアクセス可否の判定を行う点が異なっている。以下、第1の実施形態との相違点を中心に説明する。
続いて、より細かく通信許可/禁止判定を判断できるようにした本発明の第2の実施形態について、図面を参照して詳細に説明する。図13は、本発明の第2の実施形態の通信システムの構成を示す図である。図13を参照すると、第1の実施形態と比較して、制御指示装置10a側の構成に変更が加えられており、通信履歴管理部13に代えて、通信履歴のほか、ノード状態判定情報やアクセス制御ポリシーを格納するテーブル群13aが備えられている。また、第1の実施形態では、ノード状態判断部12は、ノードがコネクションを受け付けていればサーバ状態、当該ノードから他ノードへコネクションを張っていればクライアント状態であると判定したが、第2の実施形態では、これらのテーブル群13aを参照してノード状態やアクセス可否の判定を行う点が異なっている。以下、第1の実施形態との相違点を中心に説明する。
以下の説明では、テーブル群13aとして、3つのテーブルを備えている例を挙げて説明する。なお、テーブルの数は、3つに限られるものではなく、必要とされる判断の内容や各テーブルの管理の容易性等を考慮して変更することができる。
第1のテーブルは、第1の実施形態の通信履歴管理部13に相当する通信履歴を保持するテーブルである(図2参照)。
第2のテーブルは、第1のテーブルによるノード状態の判断に加えて、受信したパケットのヘッダ等の情報からノードの状態を判定するための、予め生成されたポリシーを格納したテーブルである。図14は、第2のテーブルの一例である。図14の例では、ノードが送信したパケットのヘッダに含まれるサービスやプロトコルの識別子を元に、ノードの状態を判定するエントリが格納されている。例えば、図14の1番目のエントリは、あるサービス(Service a)に関する通信が発生し、制御実施装置20から、その最初のパケットの処理内容について問い合わせがあった場合、制御指示装置10aは、その送信先に指定されているノードを「サーバ状態」と判断することを示している。同様に、図14の2番目のエントリは、あるサービス(Service a)のパケットの処理内容について問い合わせがあった場合、制御指示装置10aは、その送信元に指定されているノードを「クライアント状態」と判断することを示している。なお、図14の例は、あくまで一例であり、適宜フィールドを加えてより細かい判断を行うようにしても良い。このようなテーブルを用いることで、どのようなサービスやプロトコルの通信を開始しようとしているか、もしくは、受けようとしているかによってノードの状態を判断することができる。また図14の例では、サーバ状態もしくはクライアント状態のいずれかに決定するエントリが格納されているが、「サーバ状態とクライアント状態のどちらでも無い」という状態と判断する条件を設定したエントリを追加してもよい。
また、第1のテーブルのエントリに第2のテーブルを検索する際のキーとして用いることのできるメタ情報を設定しておき、第1のテーブルの検索結果を用いて第2のテーブルを検索できるようにすることもできる。このようにすることで、特定のノードの組み合わせならば、キー「Priority=1」が得られ、第2のテーブルの検索時に「Priority=1」であるエントリを検索するといったきめ細かい判断を行わせることができる。
第3のテーブルは、送信元と送信先に設定されたノード間の通信の可否を判定するための、予め生成されたアクセス制御ルールを格納するテーブルである。図15は、第3のテーブルの一例である。図15の例では、送信元と送信先に設定されたノードの組み合わせを元に、アクセス可否を定めたエントリが格納されている。例えば、図15の1番目のエントリは、識別子がHost aであるノードから、識別子がHost bであるノードへのアクセスを禁止することを示している。同様に、図15の2番目のエントリは、任意のノード(「*」はワイルドカードを表す。)から、識別子がHost cであるノードへのアクセスを許可することを示している。同様に、図15の3番目のエントリは、識別子がHost dであるノードから任意のノード(「*」はワイルドカードを表す。)へのアクセスを許可することを示している。
なお、図15の例では、ノードの識別子を用いてアクセス可否を判定する例を挙げたが、例えば、図16に示すように、ノードのアドレス(図15の例ではIPアドレス)の組を用いて、ノード間のアクセス可否を判断するテーブルを用いることもできる。なお、図15、図16に、例えば、サービスやプロトコルの識別子を条件とするフィールドを加えてより細かい判断を行うようにすることもできる。
本実施形態の制御指示装置10aのノード状態判断部12aは、上記のようなテーブルを参照して、ノードの状態の判定と、アクセス可否の判断を行う。具体的には、第1の実施形態では、サーバ状態であるときはコネクションを張ることを一律に禁止し、クライアント状態であるときはコネクションを受け付けることを一律に禁止していたが、第2の実施形態では、ノード状態判断部12aは、第1、第2のテーブルによるノードの状態の判定と第3のテーブルを用いたアクセス可否の判定を行うことになる。
ノード状態判断部12aは、第1のテーブルの通信記録に基づくノード状態の判断の後、第2のテーブルによるノード状態の判断を行う。ノード状態判断部12aは、これら3つのテーブルに該当するエントリに従い、対象のノードをサーバ状態とするのか、クライアント状態とするのか、を判断する。なお、第1のテーブルと、第2のテーブルによるノード状態の判断結果が異なる場合も起こりうるが(例えば、新規通信のため、第1のテーブルで「ノードでもサーバでもない状態」と判断、第2のテーブルでは「サーバ状態」とされる等)、その場合には、どちらかを優先するかを予め決めておけばよい。
さらに、本実施形態のノード状態判断部12aは、第3のテーブルに、制御実施装置20から処理内容の問い合わせを受けたパケットの送信元と送信先間の通信が認められているか否かを確認する。
さらに、本実施形態の制御指示部11は、上記ノード状態判断部12aによる判断結果に基づいて、制御実施装置20への応答を実施する。これにより、第1の実施形態ではノードの状態のみでしかアクセス制御を行えなかったが、第2の実施形態では、例えば、ノード状態による判断では通信が許可される組み合わせであっても、通信を禁止したり、逆に、ノード状態による判断では通信が禁止される組み合わせであっても、通信を許可するといった運用を行うことが可能となる。
続いて、本実施形態の動作について図面を参照して詳細に説明する。図17は、本発明の第2の実施形態の制御指示装置が制御実施装置からパケットの処理内容を問い合わせるメッセージを受信した際の処理の流れを表したシーケンス図である。なお、以下の説明で用いるノードの構成およびパケット名は図5と同様であり、制御指示装置以外の動作は第1の実施形態と同様である。
図5、図17を参照すると、まず、制御装置10aのノード状態判断部12aは制御実施装置20から処理内容を問い合わせるメッセージを受信すると(ステップU1)、受信パケットのヘッダ情報を基に、第1のテーブルに既に該当するエントリがあるか確認する(ステップU2)。次に、ノード状態判断部12aは、必要に応じ第1のテーブルから得られた情報も用いて、第2のテーブルから、受信パケットに適合するエントリを検索し、パケットBの送信ノード、受信ノードの状態を確認する(ステップU3)。さらに、ノード状態判断部12aは、第3のテーブルを参照して、各ノードの例外処理も含めて送信元、送信先ノード間の通信可否を確認する(ステップU4)。ノード状態判断部12aは、上記した判断の結果を制御指示部11へ送信し、その内容を受信した制御指示部11は、制御実施装置へ処理を要求する(ステップU5)。
以上説明した本発明の第2の実施形態によれば、第1の実施形態のようなノード状態だけでなく、あるノードが受け付けたコネクション情報をもとに、ユーザごとのアクセス制御や、例外処理を行うことができる。
なお、上記した例では、第1のテーブルから得られた情報も用いて、第2のテーブルの検索を行うことがあるため、テーブルの参照順序を決めているが、受信パケットの情報のみを用いて、それぞれのテーブルから該当エントリを検索可能な場合、上記したテーブルの参照順序に制約はなく、適宜変更することができる。
[第3の実施形態]
続いて、より具体的な構成で第1の実施形態相当の機能を実現する本発明の第3の実施形態について説明する。以下の説明では、制御指示装置11として、オープンフローコントローラ(以下、「制御装置」)、制御実施装置としてオープンフロースイッチ(以下、「スイッチ」)を用いる。また、制御実施装置20の指示キャッシュ23は、OFSのフローテーブルにて実現できる(非特許文献2参照)。
続いて、より具体的な構成で第1の実施形態相当の機能を実現する本発明の第3の実施形態について説明する。以下の説明では、制御指示装置11として、オープンフローコントローラ(以下、「制御装置」)、制御実施装置としてオープンフロースイッチ(以下、「スイッチ」)を用いる。また、制御実施装置20の指示キャッシュ23は、OFSのフローテーブルにて実現できる(非特許文献2参照)。
図18は、本発明の第3の実施形態の通信システムの構成を示す図である。図18を参照すると、制御装置10bと、スイッチ20bと、ノード群が示されている。制御装置10bは、スイッチにつながる各ノードの位置情報を蓄積するForwarding DB(以下、「FDB」)12bと、受信パケットの送信先IPアドレスとポート番号を記録することで通信履歴を蓄積するRoute DB(以下、「RDB」)13bと、これらの情報を基にノード状態に基づく通信可否を判定し、スイッチ20bに対し指示を行うスイッチ制御部11bとを備えている。
スイッチ20bは、通信部21b、パケット処理部22bに加えて、上記した指示キャッシュ23に相当し、フローエントリを保持するためのフローテーブル23bを備えている。フローテーブル23bには、受信パケットと照合するマッチ条件と、このマッチ条件に適合するパケットに適用する処理内容を定めたエントリが格納される。パケット処理部22bは、パケットを受信すると、フローテーブル23bから受信パケットに適合するマッチ条件を持つエントリを検索し、検索されたエントリに定められた処理内容(パケット転送、ヘッダ書換え、パケット破棄等)を実行する。
ここで、制御装置10bは、スイッチ20bからARP(Address Resolution Protocol)パケットを受信した場合、スイッチ20bにつながる各ノードの位置情報を記録するFDB12bのみ更新することとし、RDB13bの更新は行わないこととする。これにより、スイッチ20bも、ARPパケット受信時に、フローテーブル23bの更新は行わないことになる。
続いて、本実施形態の動作について図面を参照して詳細に説明する。以下の説明では、図19のノード1からノード2へリモートログインし、その後、ノード3へアクセスする状況を例に説明する。この際流れるパケットを図19に示すようにパケットA〜Dと名付ける。なお、リモートログイン用のプロトコルとしては、RDP(Remote Desktop Protocol)を用いるものとする。
図20は、本発明の第3の実施形態の通信システムの全体の動作を表したシーケンス図である。まず、ノード1がノード2に対し最初にSYNパケット(ここではパケットA)を送信すると(ステップZ1)、スイッチ20bは、フローテーブル23bに該当するフローエントリがあるか否かを確認する(ステップZ2)。
ここで、パケットAに適合するフローエントリが見つかった場合、スイッチ20bは、ノード2が接続するスイッチ20bのポートにパケットを送る。一方、フローテーブル23bに、パケットAに適合するフローエントリがなかった場合、スイッチ20bは、制御装置20bに対して、Packet−inメッセージを用いてパケットAを送信する(ステップZ3)。
このPacket−inメッセージを受け取った制御装置10bのスイッチ制御部11bは、RDB13bにパケットAの送信元IPアドレス(今回の例ではノード1のIPアドレス)が登録されているか否かを確認する(ステップZ4)。ここで、該当するエントリがあった場合、スイッチ制御部11bは、当該エントリに記載されているTCPポート番号を取得し、ノード状態の判断を行う(これについては図22で説明する)。
一方、前記RDB13bに該当するエントリがない場合、スイッチ制御部11bは、RDB13b内に該当するIPアドレスのエントリ(通信履歴)が存在しないため、ノード1、2がサーバ状態でもクライアント状態でもないと判断し、アクセス許可と判断する。スイッチ制御部11bは、RDB13bに、パケットAの送信元であるノード1のIPアドレス及びポート番号と、パケットAの送信先であるノード2のIPアドレス及びポート番号を登録する(ステップZ6、Z7)。
RDB13bへの登録後、スイッチ制御部11bは、FDB12bへ、パケットAの送信先スイッチが接続されたスイッチ20bのポート番号を問い合わせる(ステップZ8)。FDB12bは、パケットAの送信先MACアドレス(ノード2のMACアドレス)に対するスイッチ20bのポート番号を探す。なお、FDB12bに該当するポート番号がない場合、スイッチ制御部11bは、スイッチ20bのすべてのポート番号からパケットを送信することでフラッディングを行い、ノード2へパケットを届ける。
一方、FDB12bに、パケットAの送信先MACアドレスに対応するポート番号があった場合(ステップZ9)、スイッチ制御部11bは、Packet−outメッセージにより、スイッチ20bに、ノード2が接続されているポートからパケットを送信するよう指示する。さらに、スイッチ制御部11bは、Flow−modメッセージにより、スイッチ20bに、フローテーブル23bにパケットAの送信先を定めたエントリを追加するよう指示する(ステップZ10)。フローテーブル23bにエントリを追加する際、現在許可したフローエントリ(ノード2からノード1はポート番号A番に送信)と一緒に、逆向きのフローエントリ(ノード1からノード2はポート番号B番に送信)と登録してしまうこともできる。これは、ノード1からノード2へRDPパケットを送信した後、ノード2からノード1への応答パケットが、RDB13bを参照するアクセス制御により届かなくなってしまうことを防ぐためである。
Packet−outメッセージを受信したスイッチ20bは、FDB12bに記載されている該当ポート番号からノード2に宛ててパケットAを送信する(ステップZ11)。
パケットAを受信したノード2は、パケットAに対するSYN/ACKパケット(パケットB)を返す(ステップZ12)。パケットAの時と同様に、スイッチ20bは、自身のフローテーブル23bを確認する(ステップZ13)。今回はパケットAのやりとり時に生成されたフローエントリが登録されているので、スイッチ20bは、制御装置10bに対しPacket−inを送信せず、フローエントリにて指定されたポートからパケットBを送信する(ステップZ14)。
以上の動作で、ノード1からノード2へリモートログインできたことになる。
この状態で、図5に示すように、ノード2からノード3へアクセスを試みる。図22に示すように、ノード2からノード3へパケットCが送信されると(ステップZ15)、スイッチ20bのスイッチ制御部11bは、フローテーブル23bに、パケットCを処理するためのフローエントリが存在するか否かを確認する。この時点では、フローテーブル23bにはパケットAを処理するフローエントリは登録されていないため、スイッチ20bは、制御装置10bに対し、Packet−inメッセージを送信する(ステップZ16)。Packet−inメッセージによりパケットCを受け取った制御装置10bのスイッチ制御部11bは、パケットCの送信元IPアドレスを基に、RDB13b内に該当情報があるか検索する(ステップZ17)。パケットAがノード2に届いた時点でRDB13bに、「ノード2のIPアドレス、3389(RDPを表すポート番号)」が記載されているため、RDB13bからスイッチ制御部11bに、3389という値が返される(ステップZ18)。スイッチ制御部11bは、3389を受信すると、ノードBがサーバ状態であると判定する。そして、パケット送信元がサーバ状態であるので、パケットを破棄するようスイッチ20bに指示する(ステップZ19)。この時、RDPのポート番号3389以外のポート番号でアクセス制御をすることも可能である。
上記の動作によって、ノード2が踏み台となることを、防止することができる。
なお、非特許文献2のオープンフロースイッチは、Flow−removedメッセージを用いて、オープンフローコントローラ(制御装置10b)に対し、フローエントリがタイムアウトしたことを通知できる。より具体的には、オープンフロースイッチのフローテーブル23bのフローエントリにタイムアウトを設定し、一定期間該当パケットを受信しないなどしてタイムアウトが成立した時、スイッチ20bは制御装置10bに対して、Flow−removedメッセージによってタイムアウトの通知を行う。Flow−removedメッセージを受け取った制御装置10bは、タイムアウトの通知に含まれている、パケットの送信先IPアドレス、ポート番号を基に、RDB13bのエントリを検索し、削除を実行する。
[第4の実施形態]
続いて、より具体的な構成で第2の実施形態相当の機能を実現する本発明の第4の実施形態について説明する。図23は、本発明の第4の実施形態の通信システムの構成を示す図である。図23を参照すると、第1の実施形態の構成に加えて、制御装置10bに、第2のテーブルに相当するアクセス制御ルールデータベース(アクセス制御ルールDB)13cと、第2のテーブルに相当するポリシーデータベース(ポリシーDB)13dを追加した構成となっている。
続いて、より具体的な構成で第2の実施形態相当の機能を実現する本発明の第4の実施形態について説明する。図23は、本発明の第4の実施形態の通信システムの構成を示す図である。図23を参照すると、第1の実施形態の構成に加えて、制御装置10bに、第2のテーブルに相当するアクセス制御ルールデータベース(アクセス制御ルールDB)13cと、第2のテーブルに相当するポリシーデータベース(ポリシーDB)13dを追加した構成となっている。
図24は、ポリシーDB13dに保持されるノード状態判断用テーブルの一例を示す図である。図24の例では、ポート番号3389(RDP)を用いて、コネクションを受け付けたならサーバ状態とし、ポート番号3389を用いてコネクションを張ったならクライアント状態とする、という判定ポリシーが登録されている。コネクションを受け付けた側か、コネクションを張った側かの判断は、該当するIPアドレスが送信元に設定されているか、送信先に設定されているかによって判断できる(図24の「src/dst」参照。)。
図25は、アクセス制御ルールDB13cに保持されるアクセス可否判断用テーブルの一例を示す図である。図25の上から1番目のエントリは、IPアドレス192.168.0.2のノードから、IPアドレス192.168.0.3のノードへアクセスがあった場合、アクセスを許可するというルールとなっている。なお、本実施形態では、アクセス制御ルールDB13cによる判定がポリシーDB13dによる判定よりも優先されるものとする。このような優先度を持たせることにより、IPアドレス192.168.0.2のノードが既にサーバ状態で動作している、もしくは、IPアドレス192.168.0.3のノードが既にクライアント状態で動作していても、アクセスを許可する、という制御が可能となる。また、図25の*はすべてのIPアドレスを意味しており、既にクライアントとして動作していても、IPアドレス192.168.0.1のノードへのアクセスは常に許可する、というルール(図25の上から2つ目のエントリ)や、既にサーバとして動作していても、IPアドレス192.168.0.3のノードからのアクセスは常に許可する、というルール(図18の上から3つ目のエントリ)を設けることも可能となっている。
続いて、本実施形態の動作について図面を参照して詳細に説明する。以下、スイッチ20bからのPacket−inメッセージが制御装置10bにパケットが届いた後から、受信パケットの処理が決定し、制御装置10bからスイッチ20bへPacket−outメッセージ及びFlow−modメッセージを送信するところまでを詳細に説明する。なお、スイッチ20b内でのパケットの処理の仕方は、第3の実施形態と同様であるため、説明を省略する。
また、以下の説明では、第3の実施形態と同様に、図19のノード1からノード2へリモートログインし、その後、ノード3へアクセスする状況を例に説明する。この際流れるパケットを図19に示すようにパケットA〜Dと名付ける。なお、リモートログイン用のプロトコルとしては、RDP(Remote Desktop Protocol)を用いるものとする。
次に、ノード1からノード2へリモートログインし、その後、ノード2がノード3へアクセスする状況を例に説明する。
図26、図27は本発明の第4の実施形態の通信システムの全体の動作を表したシーケンス図である。図26のステップV1〜ステップV3までは、第3の実施形態の図20のステップZ1〜Z3と同様である。
次にステップV4、ステップV5について、図28、図29を参照して詳細に説明する。Packet−inメッセージによってSYNパケット(パケットA)を受信すると(ステップW1)、スイッチ制御部11bは、RDB13bから、当該パケットAのヘッダ中のポート番号と、送信元IPアドレス又は送信先IPアドレスのいずれか適合するエントリを検索する(ステップW2)。この時点では、RDB13bに上記SYNパケットに対応するエントリは存在しないため、スイッチ制御部11bは、RDB13bから、該当するIPアドレスが記載されたエントリが存在しないとの応答を受ける(ステップW3)。スイッチ制御部11bは、ポリシーDB13dを参照することなく、ノード1、ノード2はいずれもクライアント状態及びサーバ状態のいずれでもないと判断する(ステップW4)。
次に、スイッチ制御部11bは、アクセス制御ルールDB13cから、SYNパケット(パケットA)の送信元IPアドレス、送信先IPアドレスに示されるノードに適用すべきルールを検索する(ステップW5)。アクセス制御ルールDB13cが図25のようなルールが格納されているとすると、上記SYNパケットに適合するするルールが存在しない。このため、スイッチ制御部11bは、アクセス制御ルールDB13cから、該当するルールが存在しないとの応答を受ける(ステップW6)。
以上の結果、スイッチ制御部11bは、図29に示すように、パケットAの送受信が可能であると判断し、RDB13bに対し、上記SYNパケットに対応するエントリを登録するようメッセージを送信し(ステップW8)、上記SYNパケットの送信元IPアドレス又は送信先IPアドレスのいずれかとポート番号とを対応付けたエントリを登録する(ステップW9、ステップV5)。
以降、図29におけるステップW10〜ステップW12及び図26〜図27におけるステップV6〜ステップV12は、それぞれ第3実施形態の図21、22のステップZ8〜ステップZ10、ステップZ11〜ステップZ16と同様であるため説明を省略する。
その後、ノード2がパケットCを送信した場合の動作のうち、図27のステップV13〜ステップV15について、図30を参照して詳細に説明する。まず、図27のステップV13について説明する。Packet−inメッセージによりスイッチ20bからパケットCを受信すると(ステップR1)、スイッチ制御部11bは、RDB13bから、PパケットCの送信元、送信先IPアドレス情報に対応するエントリを検索する(ステップR2)。この時点では、先のステップ図29のW9にてSYNパケットに対応するエントリを登録済みであるため、RDB13bには、ノード2の情報が登録されているため、RDB13bから、ノード2のIPアドレスが送信先であったという情報と、ポート番号を得る。一方、ノード3については、RDB13bの該当エントリが存在しないことが分かる。さらに、スイッチ制御部11bは、ポリシーDB13dから、ノード2のIPアドレスが送信先であったという情報と、ポート番号に対応するエントリを検索する。以上の結果、スイッチ制御部11bは、ノード2はサーバ状態で動作しており、ノード3はクライアント状態及びサーバ状態のいずれでもないことを判断する(ステップR4;図24のポリシーDB13dの1番目のエントリ参照)。
次に、スイッチ制御部11bは、アクセス制御ルールDB13cから、パケットCの送信元IPアドレス、送信先IPアドレスに示されるノードに適用すべきルールを検索し、該当するルールがあるか確認する(ステップR5)。この結果、図25に示す192.168.0.2(ノード2のIPアドレス)から192.168.0.3(ノード3のIPアドレス)へのアクセスを許可するとのルールが応答される。
以上の結果、スイッチ制御部11bは、ノード2がサーバ状態であるものの、ノード2−ノード3間の通信を許可するアクセス制御ルールを優先し、アクセスは許可という判断をする。さらに、ステップR4によってノード3がRDB13bに登録されていないことが判明しているので、スイッチ制御部13bは、図31に示すように、RDB13bに、ノード3の情報を登録するようメッセージを送信し(ステップR7)、送信先IPアドレスとしてノード3のIPアドレスとポート番号とを対応付けたエントリを登録する(ステップR8、ステップV14)。
その後の図31のステップR9〜ステップR11は、図29のステップW10〜W12と同様であるため説明を省略する。再度、図27を参照して説明を継続すると、スイッチ制御部11bは、スイッチ20bに対し、ノード3が接続されているポートよりパケットCを送信することを指示するPacket−outメッセージと、フローテーブル23bにフローエントリを登録することを指示するFlow−modメッセージとを送信する(ステップV15)。
前記各メッセージを受信したスイッチ20bは、パケットCをノード3へ送信する(ステップV16)。このように、第1の実施形態ではノード2から送信することができなかったパケットCが、第2の実施形態ではノード3へ到着することになる(ステップV17)。
以上のように、本実施形態では、RDB13b及びポリシーDB13dによるノード状態の判断よりもアクセス制御ルールを優先適用するため、例えば、アクセス制御ルールDB13cが図32に示すようなルールであった場合、ステップV5の時点でノード1からノード2へのアクセスは拒否される。このため、ノード1、ノード2共に既にクライアント・サーバ状態となっていない場合でも、コネクションを確立させないことも可能である(SYNパケットを破棄する)。
もちろん、アクセス制御ルールよりも、RDB13b及びポリシーDB13dによるノード状態による判断を優先させることも可能である。
[第5の実施形態]
続いて、位置情報も併用してノードの状態の判断を行うようにした本発明の第5の実施形態について説明する。図33は、本発明の第5の実施形態の通信システムの構成を示す図である。図33を参照すると、第1の実施形態の構成に加えて、制御指示装置10eに、位置ベースポリシーテーブル13eを追加した構成となっている。その他の構成は第1の実施形態と同様であるため、以下、その相違点を中心に説明する。
続いて、位置情報も併用してノードの状態の判断を行うようにした本発明の第5の実施形態について説明する。図33は、本発明の第5の実施形態の通信システムの構成を示す図である。図33を参照すると、第1の実施形態の構成に加えて、制御指示装置10eに、位置ベースポリシーテーブル13eを追加した構成となっている。その他の構成は第1の実施形態と同様であるため、以下、その相違点を中心に説明する。
図34は、本発明の第5の実施形態の制御指示装置によるノード状態の判定処理を説明するための図である。図34の上段は、位置ベースポリシーテーブル13eの例である。図34の上段の上から1〜2番目のエントリは、同図下段に示すように、スイッチ#1のノード#1に接続されているノードについては、通信履歴に拘らず、サーバ状態と判定するとのポリシーを表している。上段の下から1〜3番目のエントリは、無線APを介してスイッチ#3に接続されているノードについては、通信履歴に拘らず、クライアント状態と判定するとのポリシーを表している。また、図34の例では、スイッチによってノードの属性が一意に決定できないスイッチ#2については、ノード状態「Any」となっている。
以上のような本実施形態の制御指示装置10eによれば、ノードの位置を併用したノードの判断を行うことができる。位置ベースポリシーテーブル13eと、通信履歴による判断に優劣を付けることで、例えば、位置ベースポリシーテーブル13eによればサーバ状態と判断すべき位置にあるノードであっても、特定の通信履歴を持つ場合には、クライアント状態と判断することができる。また逆に、例えば、通信履歴によればサーバ状態と判断すべき位置にあるノードであっても、特定の位置にある場合には、クライアント状態と判断することができる。また、位置ベースポリシーテーブル13eにより、ノード状態が不定「Any」である場合にのみ、通信履歴による判断を行うようにすることもできる。
またあるいは、位置ベースポリシーテーブル13eによる判断と、通信履歴による判断が一致した場合にのみ、ノードをサーバ状態、あるいは、クライアント状態と判断し、その他はサーバ状態及びクライアント状態のいずれでもないと判断するようにしてもよい。
また、上記第5の実施形態においても、第2、第4実施形態にて説明したアクセス制御ルールによる判断を行ってもよいことはもちろんである。
以上、本発明の好適な実施形態を説明したが、本発明の技術的範囲は、上記した各実施形態の記載に限定されるものではない。例えば、上記した第3、第4の実施形態では、非特許文献1、2のオープンフローの制御装置(コントローラ)とスイッチを用いるものとして説明したが、同等の機能を持つ制御装置と制御実施装置であればかまわない。
最後に、本発明の好ましい形態を要約する。
[第1の形態]
(上記第1の視点による通信システム参照)
[第2の形態]
第1の形態の通信システムにおいて、
前記ノード状態判断部は、さらに、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードに対しサービスの提供を要求した側にあるか否かを判断し、
前記制御指示部は、前記ノードが他のノードに対しサービスの提供を要求した側にある場合、他のノードから当該ノードへの新規通信を禁止する通信システム。
[第3の形態]
所定の制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置と、
前記制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部と、
前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードに対しサービスの提供を要求した側にあるか否かを判断するノード状態判断部と、
少なくとも前記ノードが他のノードに対しサービスの提供を要求した側にある場合、他のノードから当該ノードへの新規通信を禁止する制御指示部と、
を備える制御指示装置と、を含む通信システム。
[第4の形態]
第1から第3いずれか一の形態の通信システムにおいて、
さらに、ノード間の通信に適用するアクセス制御ルールを格納するアクセス制御ルール記憶部を備え、
前記ノードの状態と、前記アクセス制御ルールによる通信可否を用いて、前記新規通信を禁止するか否かを決定する通信システム。
[第5の形態]
第1から第4いずれか一の形態の通信システムにおいて、
さらに、前記ノードの位置から、前記他のノードにサービスを提供する側にあるか否かを判断するためのノード状態判定テーブルを備え、
前記ノード状態判断部は、前記通信履歴管理部の通信履歴に加え、前記ノードの位置情報を参照して、ノードの状態を判断する通信システム。
[第6の形態]
第1から第4いずれか一の形態の通信システムにおいて、
さらに、前記ノードの位置から、前記他のノードにサービスを提供する側にあるか否かを判断するためのノード状態判定テーブルを備え、
前記制御指示部は、前記ノードの位置が所定の位置にある場合、前記ノード状態判断部の判断結果に拘らず、当該ノードから他のノードへの新規通信を禁止する通信システム。
[第7の形態]
第1から第4いずれか一の形態の通信システムにおいて、
さらに、前記ノードの位置から、前記他のノードにサービスを提供する側にあるか否かを判断するためのノード状態判定テーブルを備え、
前記制御指示部は、前記ノードの位置が所定の位置にある場合、前記ノード状態判断部の判断結果に拘らず、他のノードから当該ノードに対する新規通信を禁止する通信システム。
[第8の形態]
第1から第7いずれか一の形態の通信システムにおいて、
前記ノード状態判断部は、前記処理方法の問い合わせを受けたパケットを分析し、送信元のノードが、コネクション接続要求を発信したか、コネクションを受け付けたかに基づいて、前記ノードの状態を判断する通信システム。
[第9の形態]
第1から第8いずれか一の形態の通信システムにおいて、
前記制御実施装置は、前記制御指示装置から設定された制御指示を記憶するテーブルを備え、
前記パケット処理部は、前記テーブルから受信パケットに適合するマッチ条件を持つエントリを検索することで、前記制御指示装置からの指示に基づいたパケット処理を実行する通信システム。
[第10の形態]
(上記第2の視点による制御指示装置参照)
[第11の形態]
第3の形態対応の制御指示装置。
[第12の形態]
(上記第3の視点による通信制御方法参照)
[第13の形態]
第3の形態対応の通信制御方法。
[第14の形態]
(上記第4の視点によるプログラム参照)
[第15の形態]
第3の形態対応のプログラム。
なお、上記第10〜第15の形態は、第1の形態と同様に、第2、第4〜第9の形態に展開することが可能である。
[第1の形態]
(上記第1の視点による通信システム参照)
[第2の形態]
第1の形態の通信システムにおいて、
前記ノード状態判断部は、さらに、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードに対しサービスの提供を要求した側にあるか否かを判断し、
前記制御指示部は、前記ノードが他のノードに対しサービスの提供を要求した側にある場合、他のノードから当該ノードへの新規通信を禁止する通信システム。
[第3の形態]
所定の制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置と、
前記制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部と、
前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードに対しサービスの提供を要求した側にあるか否かを判断するノード状態判断部と、
少なくとも前記ノードが他のノードに対しサービスの提供を要求した側にある場合、他のノードから当該ノードへの新規通信を禁止する制御指示部と、
を備える制御指示装置と、を含む通信システム。
[第4の形態]
第1から第3いずれか一の形態の通信システムにおいて、
さらに、ノード間の通信に適用するアクセス制御ルールを格納するアクセス制御ルール記憶部を備え、
前記ノードの状態と、前記アクセス制御ルールによる通信可否を用いて、前記新規通信を禁止するか否かを決定する通信システム。
[第5の形態]
第1から第4いずれか一の形態の通信システムにおいて、
さらに、前記ノードの位置から、前記他のノードにサービスを提供する側にあるか否かを判断するためのノード状態判定テーブルを備え、
前記ノード状態判断部は、前記通信履歴管理部の通信履歴に加え、前記ノードの位置情報を参照して、ノードの状態を判断する通信システム。
[第6の形態]
第1から第4いずれか一の形態の通信システムにおいて、
さらに、前記ノードの位置から、前記他のノードにサービスを提供する側にあるか否かを判断するためのノード状態判定テーブルを備え、
前記制御指示部は、前記ノードの位置が所定の位置にある場合、前記ノード状態判断部の判断結果に拘らず、当該ノードから他のノードへの新規通信を禁止する通信システム。
[第7の形態]
第1から第4いずれか一の形態の通信システムにおいて、
さらに、前記ノードの位置から、前記他のノードにサービスを提供する側にあるか否かを判断するためのノード状態判定テーブルを備え、
前記制御指示部は、前記ノードの位置が所定の位置にある場合、前記ノード状態判断部の判断結果に拘らず、他のノードから当該ノードに対する新規通信を禁止する通信システム。
[第8の形態]
第1から第7いずれか一の形態の通信システムにおいて、
前記ノード状態判断部は、前記処理方法の問い合わせを受けたパケットを分析し、送信元のノードが、コネクション接続要求を発信したか、コネクションを受け付けたかに基づいて、前記ノードの状態を判断する通信システム。
[第9の形態]
第1から第8いずれか一の形態の通信システムにおいて、
前記制御実施装置は、前記制御指示装置から設定された制御指示を記憶するテーブルを備え、
前記パケット処理部は、前記テーブルから受信パケットに適合するマッチ条件を持つエントリを検索することで、前記制御指示装置からの指示に基づいたパケット処理を実行する通信システム。
[第10の形態]
(上記第2の視点による制御指示装置参照)
[第11の形態]
第3の形態対応の制御指示装置。
[第12の形態]
(上記第3の視点による通信制御方法参照)
[第13の形態]
第3の形態対応の通信制御方法。
[第14の形態]
(上記第4の視点によるプログラム参照)
[第15の形態]
第3の形態対応のプログラム。
なお、上記第10〜第15の形態は、第1の形態と同様に、第2、第4〜第9の形態に展開することが可能である。
なお、上記の特許文献および非特許文献の各開示を、本書に引用をもって繰り込むものとする。本発明の全開示(請求の範囲を含む)の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素(各請求項の各要素、各実施形態ないし実施例の各要素、各図面の各要素等を含む)の多様な組み合わせ、ないし選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。
10、10a、10e 制御指示装置
10b、10c 制御装置
11 制御指示部
11b スイッチ制御部
12、12a ノード状態判断部
12b Forwarding DB(FDB)
13 通信履歴管理部
13a テーブル群
13b Route DB(RDB)
13c アクセス制御ルールDB
13d ポリシーDB
13e 位置ベースポリシーテーブル
20 制御実施装置
20b スイッチ
21、21b 通信部
22、22b パケット処理部
23 指示キャッシュ
23b フローテーブル
10b、10c 制御装置
11 制御指示部
11b スイッチ制御部
12、12a ノード状態判断部
12b Forwarding DB(FDB)
13 通信履歴管理部
13a テーブル群
13b Route DB(RDB)
13c アクセス制御ルールDB
13d ポリシーDB
13e 位置ベースポリシーテーブル
20 制御実施装置
20b スイッチ
21、21b 通信部
22、22b パケット処理部
23 指示キャッシュ
23b フローテーブル
Claims (15)
- 所定の制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置と、
前記制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部と、
前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードにサービスを提供する側にあるか否かを判断するノード状態判断部と、
少なくとも前記ノードが他のノードにサービスを提供する側にある場合、当該ノードから他のノードへの新規通信を禁止する制御指示部と、
を備える制御指示装置と、を含む通信システム。 - 前記ノード状態判断部は、さらに、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードに対しサービスの提供を要求した側にあるか否かを判断し、
前記制御指示部は、前記ノードが他のノードに対しサービスの提供を要求した側にある場合、他のノードから当該ノードへの新規通信を禁止する請求項1の通信システム。 - 所定の制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置と、
前記制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部と、
前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードに対しサービスの提供を要求した側にあるか否かを判断するノード状態判断部と、
少なくとも前記ノードが他のノードに対しサービスの提供を要求した側にある場合、他のノードから当該ノードへの新規通信を禁止する制御指示部と、
を備える制御指示装置と、を含む通信システム。 - さらに、ノード間の通信に適用するアクセス制御ルールを格納するアクセス制御ルール記憶部を備え、
前記ノードの状態と、前記アクセス制御ルールによる通信可否を用いて、前記新規通信を禁止するか否かを決定する請求項1から3いずれか一の通信システム。 - さらに、前記ノードの位置から、前記他のノードにサービスを提供する側にあるか否かを判断するためのノード状態判定テーブルを備え、
前記ノード状態判断部は、前記通信履歴管理部の通信履歴に加え、前記ノードの位置情報を参照して、ノードの状態を判断する請求項1から4いずれか一の通信システム。 - さらに、前記ノードの位置から、前記他のノードにサービスを提供する側にあるか否かを判断するためのノード状態判定テーブルを備え、
前記制御指示部は、前記ノードの位置が所定の位置にある場合、前記ノード状態判断部の判断結果に拘らず、当該ノードから他のノードへの新規通信を禁止する請求項1から4いずれか一の通信システム。 - さらに、前記ノードの位置から、前記他のノードにサービスを提供する側にあるか否かを判断するためのノード状態判定テーブルを備え、
前記制御指示部は、前記ノードの位置が所定の位置にある場合、前記ノード状態判断部の判断結果に拘らず、他のノードから当該ノードに対する新規通信を禁止する請求項1から4いずれか一の通信システム。 - 前記ノード状態判断部は、前記処理方法の問い合わせを受けたパケットを分析し、送信元のノードが、コネクション接続要求を発信したか、コネクションを受け付けたかに基づいて、前記ノードの状態を判断する請求項1から7いずれか一の通信システム。
- 前記制御実施装置は、前記制御指示装置から設定された制御指示を記憶するテーブルを備え、
前記パケット処理部は、前記テーブルから受信パケットに適合するマッチ条件を持つエントリを検索することで、前記制御指示装置からの指示に基づいたパケット処理を実行する請求項1から8いずれか一の通信システム。 - 制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部と、
前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードにサービスを提供する側にあるか否かを判断するノード状態判断部と、
少なくとも前記ノードが他のノードにサービスを提供する側にある場合、当該ノードから他のノードへの新規通信を禁止する制御指示部と、
を備える制御指示装置。 - 制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部と、
前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードに対しサービスの提供を要求した側にあるか否かを判断するノード状態判断部と、
前記ノードが他のノードに対しサービスの提供を要求した側にある場合、他のノードから当該ノードへの新規通信を禁止する制御指示部と、
を備える制御指示装置。 - 所定の制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置に接続され、
前記制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部を備えたコンピュータが、
前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードにサービスを提供する側にあるか否かを判断するステップと、
少なくとも前記ノードが他のノードにサービスを提供する側にある場合、他のノードから当該ノードへの新規通信を禁止するステップと、
を含む通信制御方法。 - 所定の制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置に接続され、
前記制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部を備えたコンピュータが、
前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードに対しサービスの提供を要求した側にあるか否かを判断するステップと、
少なくとも前記ノードが他のノードに対しサービスの提供を要求した側にある場合、他のノードから当該ノードへの新規通信を禁止するステップと、
を含む通信制御方法。 - 所定の制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置に接続され、
前記制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部を備えたコンピュータに、
前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードにサービスを提供する側にあるか否かを判断する処理と、
少なくとも前記ノードが他のノードにサービスを提供する側にある場合、当該ノードから他のノードへの新規通信を禁止する処理と、
を実行させるプログラム。 - 所定の制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置に接続され、
前記制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部を備えたコンピュータに、
前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードに対しサービスの提供を要求した側にあるか否かを判断する処理と、
少なくとも前記ノードが他のノードに対しサービスの提供を要求した側にある場合、他のノードから当該ノードへの新規通信を禁止する処理と、
を実行させるプログラム。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2013171266 | 2013-08-21 | ||
JP2013171266 | 2013-08-21 | ||
PCT/JP2014/071662 WO2015025848A1 (ja) | 2013-08-21 | 2014-08-19 | 通信システム、制御指示装置、通信制御方法及びプログラム |
Publications (2)
Publication Number | Publication Date |
---|---|
JPWO2015025848A1 JPWO2015025848A1 (ja) | 2017-03-02 |
JP6330814B2 true JP6330814B2 (ja) | 2018-05-30 |
Family
ID=52483622
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2015532863A Active JP6330814B2 (ja) | 2013-08-21 | 2014-08-19 | 通信システム、制御指示装置、通信制御方法及びプログラム |
Country Status (3)
Country | Link |
---|---|
US (1) | US10469498B2 (ja) |
JP (1) | JP6330814B2 (ja) |
WO (1) | WO2015025848A1 (ja) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11100046B2 (en) * | 2016-01-25 | 2021-08-24 | International Business Machines Corporation | Intelligent security context aware elastic storage |
US20180176181A1 (en) * | 2016-12-19 | 2018-06-21 | Cisco Technology, Inc. | Endpoint admission control |
CN117252559B (zh) * | 2023-11-20 | 2024-07-23 | 迈为技术(珠海)有限公司 | 业务流程的处理方法、装置、计算机设备、存储介质 |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002312316A (ja) | 2001-04-13 | 2002-10-25 | Sumisho Computer Systems Corp | 不正アクセス防止装置および方法、不正アクセス防止用プログラム、記録媒体 |
US20050249214A1 (en) * | 2004-05-07 | 2005-11-10 | Tao Peng | System and process for managing network traffic |
US8904535B2 (en) * | 2006-12-20 | 2014-12-02 | The Penn State Research Foundation | Proactive worm containment (PWC) for enterprise networks |
JP5159571B2 (ja) | 2008-11-13 | 2013-03-06 | 三菱電機株式会社 | アクセス制御装置、アクセス制御装置のアクセス制御方法およびアクセス制御プログラム |
JP5660202B2 (ja) | 2011-04-15 | 2015-01-28 | 日本電気株式会社 | コンピュータシステム、コントローラ、及びネットワークアクセスポリシ制御方法 |
KR101414959B1 (ko) * | 2012-02-29 | 2014-07-09 | 주식회사 팬택 | 네트워크 공격을 감지하는 이동 통신 단말기 및 그 감지 방법 |
US9942250B2 (en) * | 2014-08-06 | 2018-04-10 | Norse Networks, Inc. | Network appliance for dynamic protection from risky network activities |
-
2014
- 2014-08-19 JP JP2015532863A patent/JP6330814B2/ja active Active
- 2014-08-19 WO PCT/JP2014/071662 patent/WO2015025848A1/ja active Application Filing
- 2014-08-19 US US14/913,457 patent/US10469498B2/en active Active
Also Published As
Publication number | Publication date |
---|---|
US20160205099A1 (en) | 2016-07-14 |
JPWO2015025848A1 (ja) | 2017-03-02 |
WO2015025848A1 (ja) | 2015-02-26 |
US10469498B2 (en) | 2019-11-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5811171B2 (ja) | 通信システム、データベース、制御装置、通信方法およびプログラム | |
JP5880560B2 (ja) | 通信システム、転送ノード、受信パケット処理方法およびプログラム | |
JP5943006B2 (ja) | 通信システム、制御装置、通信方法およびプログラム | |
JP5987902B2 (ja) | ネットワークシステム、コントローラ、及びパケット認証方法 | |
JP4630896B2 (ja) | アクセス制御方法、アクセス制御システムおよびパケット通信装置 | |
JP5862577B2 (ja) | 通信システム、制御装置、ポリシ管理装置、通信方法およびプログラム | |
JP5994851B2 (ja) | 転送装置の制御装置、転送装置の制御方法、通信システムおよびプログラム | |
JP6424820B2 (ja) | 機器管理システム、機器管理方法及びプログラム | |
JP5800019B2 (ja) | 通信経路制御システム、経路制御装置、通信経路制御方法および経路制御プログラム | |
EP2619953B1 (en) | A control apparatus, a communication system, a communication method and a recording medium having recorded thereon a communication program | |
JP6330814B2 (ja) | 通信システム、制御指示装置、通信制御方法及びプログラム | |
JP7139252B2 (ja) | 転送装置 | |
JP5720162B2 (ja) | 通信システム、スイッチングハブ、およびルータ | |
JP5747997B2 (ja) | 制御装置、通信システム、仮想ネットワークの管理方法およびプログラム | |
JP5742268B2 (ja) | 通信システム、制御装置、通信方法 | |
JP5797597B2 (ja) | 中継装置 | |
WO2015145976A1 (ja) | 通信システム、制御指示装置、制御実施装置、通信制御方法およびプログラムを記憶する記憶媒体 | |
KR20180015959A (ko) | 스위칭 망에서의 데이터 패킷 전송 경로 제어 장치, 및 이를 이용한 보안 통신 방법 | |
JP2002199003A (ja) | 移動端末位置登録方法及びその実施装置 | |
US20210051076A1 (en) | A node, control system, communication control method and program | |
WO2015129727A1 (ja) | 通信端末、通信方法およびプログラム | |
WO2015025817A1 (ja) | 通信端末、通信システム、通信方法およびプログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20170703 |
|
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: 20180327 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20180409 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 6330814 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |