JP2008066945A - 攻撃検出システム及び攻撃検出方法 - Google Patents

攻撃検出システム及び攻撃検出方法 Download PDF

Info

Publication number
JP2008066945A
JP2008066945A JP2006241287A JP2006241287A JP2008066945A JP 2008066945 A JP2008066945 A JP 2008066945A JP 2006241287 A JP2006241287 A JP 2006241287A JP 2006241287 A JP2006241287 A JP 2006241287A JP 2008066945 A JP2008066945 A JP 2008066945A
Authority
JP
Japan
Prior art keywords
packet
address
attack
destination
request message
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.)
Granted
Application number
JP2006241287A
Other languages
English (en)
Other versions
JP4664257B2 (ja
Inventor
Atsushi Ogawa
淳 小川
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.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
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 Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2006241287A priority Critical patent/JP4664257B2/ja
Priority to US11/700,449 priority patent/US7979575B2/en
Publication of JP2008066945A publication Critical patent/JP2008066945A/ja
Application granted granted Critical
Publication of JP4664257B2 publication Critical patent/JP4664257B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227Filtering policies
    • H04L63/0236Filtering by address, protocol, port number or service, e.g. IP-address or URL
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227Filtering policies
    • H04L63/0245Filtering by information in the payload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1416Event detection, e.g. attack signature detection

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

【課題】通信網における内部網から外部網への攻撃の検出を低廉に実現する。
【解決手段】IPS202は、内部網200と外部網100との間で授受される通信パケットを検査して特定の条件に合致する特定パケットを検出する。ここで、内部網200から送られてきた特定パケットを検出したときには、該特定パケットの送信元を検出する依頼を含んでおり仮想サーバ300のアドレス(仮想アドレス)を宛先にした検出依頼メッセージを作成してSLB201へ送信する。RIP検出装置303は、SLB201によって宛先が仮想アドレスから特定パケットの送信元であるサーバ(301a若しくは301b)の実アドレスへと書き換えられた検出依頼メッセージを受け取ったときに、該検出依頼メッセージに宛先として示されている実アドレスを抽出する。
【選択図】図1

Description

本発明は、データ交換通信網の技術に関し、特に、通信網に接続されている装置を不正なアクセスから防護する技術に関する。
まず、IPS(Intrusion Prevention System :不正侵入検出システム)について説明する。
組織体によって使用されているITシステムを守るための代表的な装置であるファイアウォールは、組織外の通信網(外部網)と組織内の通信網(内部網)との接続点に設置して、外部網からの接続を許可するサービス(ポート)を制限することで、不正アクセスから内部網を防御するものである。しかし、悪意のあるコードが、接続を許可しているサービスに対してのアクセスに埋め込まれている場合には、このコードをファイアウォールが検出できないという問題がある。IPSは、このような悪意のあるコードを検出して内部網を防御する機能を有している装置である。
IPSは、通信網上を流れる全パケットを対象にしてそのプロトコルヘッダやデータグラム中のデータを解析して、攻撃パケットの検出及び廃棄を行うと共に、攻撃があった旨の通知を管理者用端末へ行う。このデータの解析は、パケットのヘッダやデータグラムに対し、攻撃パターン毎に配布されるパターンファイルを適用して検査を行うことで実現する。このパターンファイルは、最新の攻撃に対応するために、日々更新されており、最新の検索パターンはインターネットを利用する等して提供されている。ここで、攻撃パケットを検出した場合には、IPSはTCP(Transfer Control Protocol )プロトコルにおけるRST(Reset )パケットを攻撃元(攻撃パケットの送信元)へ送信してTCPコネクションを強制的に切断させる。内部網の防御はこうして行われる。
IPSのうち、特にWebアプリケーションへの攻撃を対象としたものはWAF(Web Application Firewall)と称されているが、本願においては、この両者を特に区別することなく、「IPS」と称することとする。
次に、SLB(Server Load Balancer:サーバ負荷分散装置)について説明する。
SLBは、外部網上のクライアント端末から内部網に設置されているサーバへの接続要求を一元的に管理して、同等の機能を持つ内部網上の複数のサーバに要求を転送する装置である。例えば、ユーザからのアクセスが一台のWebサーバの処理能力に比して過大であると、Webサーバは過負荷となってユーザへの応答速度が遅くなってしまう。SLBは、ユーザからの要求を分散して複数のなるべく多くのサーバに送信することで、各サーバが快適な応答速度を保てるようにする。また、SLBは、ダウンしたサーバに対しては接続要求を割り振らないようにする機能を有しているので、SLBを使用することで、Webサーバに対する耐故障性を向上させるという効果も得られる。
図16について説明する。同図に示す通信網の構成例は、内部網200に4台のサーバ301a、301b、301c、301dを負荷分散した構成を示している。この構成においてはSLB201を備えたことにより、サーバ1台での運用時に比べて4倍の性能向上を実現すると共に耐故障性の向上も実現している。
以下、図16におけるSLB201の動作を説明する。
図16において、外部網100に存在するクライアント端末101a、101b、…のうちのクライアント端末101aが、http://www.a.comへリクエストを発行した場合を想定する。なお、クライアント端末101aのIPアドレスは、172.16.10.55であるとする。
クライアント端末101aから発行されたリクエストは、まず、不図示のDNS(Domain Name Server)で名前の解決が行われる。ここでは、DNSによって、ドメインネームwww.a.comのIPアドレスが10.10.1.100であることが判明したとする。このIPアドレスを受け取ったクライアント端末101aは、このIPアドレスが付与されているサーバ(ここでは内部網200上の仮想サーバ300)へ接続要求を発行する。
内部網200では、SLB201と、サーバ301a、301b、301c、及び301dとによって仮想サーバ300が構成されている。なお、サーバ301a、301b、301c、及び301dの各々には、それぞれ、192.168.20.1、192.168.20.2、192.168.20.3、及び192.168.20.4のIPアドレスが付与されているものとする。
クライアント端末101aで発行された接続要求は、まず、SLB201で受信される。すると、SLB201は、内部網200内に備えられている4台のサーバ301a、301b、301c、及び301dのうちから現在稼働中のものを、ラウンドロビン(Round-robin)等といった所定の負荷分散アルゴリズムに従って選択する。そして、選択されたもの(「実サーバ」と称することとする。)へ、クライアント端末101aからの接続要求を割り振る。このとき、SLB201は、クライアント端末101aで発行された接続要求における宛先IPアドレスを実サーバのものに書き換える。従って、クライアント端末101aからは、実サーバは意識されず、あたかも仮想サーバ300との通信を行っているかのように見える。
一方、実サーバからクライアント端末101aへの通信においては、SLB201は、上述したものとは逆の手順の処理を行って、接続要求に対して実サーバで発行された応答における送信元IPアドレスを、実サーバのIPアドレス(このIPアドレスを「RIP」(Real IP address :実IPアドレス)と称することとする。)から仮想サーバ300のIPアドレス(このIPアドレスを「VIP」(Virtual IP address:仮想IPアドレス)と称することとする。)へと書き換える。
このように、SLB201は、一種のアドレス変換装置としての機能を提供するものである。
次に、図16に構成を示した通信網において、前述したIPSを設置して外部網100からの不正アクセスより内部網200を防御することを考える。このためには、図17に示すように、IPS202は、外部網100と内部網200との境界、すなわち、外部網100とSLB201との間に通常設置される。また、図17には図示していないが、内部網200の防御のために、外部網100とIPS202との間にファイアウォールを設置する場合もある。
なお、図17においては、IPS202と共に管理者用端末203も表している。IPS202は、攻撃パケットを検出するとその旨を管理者用端末203へ通知して、内部網200の管理者204に知らせる。また、図17の構成例においては、2台のサーバ301a及び301bを内部網200に設置している。
ところで、このようにして外部網からの攻撃に対して内部網を保護する技術に関し、例えば特許文献1には、ファイアウォールを通過するデータパケットを検査し、攻撃を表すデータパケットを検出した場合には、該データパケットから内部網を保護するためのポリシをファイアウォールにインストールして該データパケットの分析に資する情報を設定するという技術が開示されている。
特開2005−293550号公報
昨今は、例えば悪意ある内部網の運用者が攻撃のコードをサーバに仕込むなど、内部網のサーバから外部網のクライアント端末を攻撃するという事例も増えている。このような事例について、図18を用いて説明する。
図18に例示した通信網の構成は、図17に示した構成と同一である。この構成において、悪意の運用者が、サーバ301a及び301bのうちのどちらかに、クライアント端末101aを攻撃するためのコードを仕込んだとする。このときにサーバ301a若しくは301bから発行される通信パケットには、送信元IPアドレスとして、RIP1(サーバ301aが発行した場合)若しくはRIP2(サーバ301aが発行した場合)のどちらかのIPアドレスが示されている。
しかし、図18に示した構成では、SLB201が内部網200に設けられている。SLB201は、サーバ301a及び301bのどちらから発行される通信パケットであっても、そこに示されている送信元IPアドレスを仮想サーバ300に付与されているものへ、すなわちVIPへと書き換えるアドレス変換処理を実行する。このため、SLB201から送られてきた通信パケットよりIPS202がクライアント端末101aを攻撃するためのコードを検出し(図18における(1))、その通信パケットに示されている送信元IPアドレスを管理者用端末203へ通知しても(図18における(2))、通知される送信元IPアドレスはVIPである。このため、管理者204は、この通知のみでは、クライアント端末101aを攻撃するためのコードが仕込まれたのがサーバ301a及び301bのどちらであるかを特定できない(図18における(3))。また、攻撃元の特定ができないため、前述したRSTパケットを攻撃元へ送信してTCPコネクションを強制的に切断させることによる、クライアント端末101aの防御も行うことができない。
従来は、このような内部網から外部網への攻撃に対処するために、図19に示した通信網の構成のように、IPS202とは別個に、SLB201とサーバ301a及び301bとの間にもIPS302を設置していた。すなわち、外部網100のクライアント端末101a、101b、…からの攻撃の検出及び防御並びに管理者用端末203への通知はIPS202が行い、内部網200のサーバ301a及び301bのどちらかからの検出及び防御並びに管理者用端末203への通知はIPS302が行うようにして、内部網200から外部網100への攻撃の発信元を特定できるようにしていた。
しかし、この従来構成では、2台のIPS202及び302を全く別個に設置していたため、システムコストの上昇要因となっていた。
本発明は上述した問題に鑑みてなされたものであり、その解決しようとする課題は、通信網における内部網から外部網への攻撃の検出を低廉に実現することである。
本発明の態様のひとつである攻撃検出システムは、ある組織内の通信網に存在しており各自固有の実アドレスに加えてアドレス変換装置によって共通の仮想アドレスが割り当てられている複数のサーバ装置のうちのいずれかから該組織外の通信網に存在する端末装置への攻撃を検出する攻撃検出システムであって、組織内通信網と組織外通信網との間で授受される通信パケットを検査して特定の条件に合致する特定パケットを検出するパケット検査部と、パケット検査部が組織内通信網から送られてきた特定パケットを検出したときに、該特定パケットの送信元を検出する依頼を含んでおり仮想アドレスを宛先にした検出依頼メッセージを作成してアドレス変換装置へ送信する検出依頼メッセージ作成部と、アドレス変換装置によって宛先が仮想アドレスから特定パケットの送信元であるサーバ装置の実アドレスへと書き換えられた検出依頼メッセージを受け取ったときに、該検出依頼メッセージに宛先として示されている実アドレスを抽出する宛先抽出部と、を有することを特徴とするものであり、この特徴によって前述した課題を解決する。
この構成によれば、アドレス変換装置によって宛先が書き換えられた検出依頼メッセージの該宛先を宛先抽出部が抽出することにより、特定パケットの送信元であるサーバ装置の実アドレスが取得できる。従って、仮想アドレスが送信元とされている特定パケットによる組織内通信網から組織外通信網への攻撃における攻撃元(すなわち特定パケットの送信元)のサーバ装置を特定することができる。
なお、上述した本発明に係る攻撃検出システムにおいて、特定パケットの伝送に使用されているコネクションを強制切断させるメッセージを、宛先抽出部が抽出した実アドレスで特定されるサーバ装置へ宛てて送信する強制切断メッセージ送信部を更に有するように構成することもできる。
この構成によれば、特定パケットでの攻撃における攻撃元のサーバ装置と攻撃先との間の通信コネクションを強制的に切断させることが可能となる。
また、前述した本発明に係る攻撃検出システムにおいて、検出依頼メッセージ作成部は、検出依頼メッセージとして、TCPプロトコルにおけるRSTパケットであって特定パケットの伝送に使用されているコネクションを強制切断させるものであり、且つ該特定パケットの送信元を検出する依頼を示す情報をデータグラムとして含んでいるものを作成するように構成することもできる。
この構成によれば、TCPプロトコルに準拠しているアドレス変換装置を使用している場合に、攻撃元のサーバ装置の特定が可能となる。
なお、この構成において、アドレス変換装置によって宛先が仮想アドレスから特定パケットの送信元であるサーバ装置の実アドレスへと書き換えられた検出依頼メッセージであるRSTパケットを宛先抽出部が受け取ったときに、該RSTパケットからデータグラムのみを削除したものを該実アドレスで特定されるサーバ装置へ宛てて送信する強制切断メッセージ送信部を更に有するように構成することもできる。
この構成によれば、特定パケットでの攻撃における攻撃元のサーバ装置と攻撃先との間の通信コネクションを強制的に切断させることが可能となる。
なお、この構成において、組織外通信網に存在する端末装置から送られてきたTCPプロトコルにおけるRSTパケットをパケット検査部が検出したときに、該RSTパケットを、該RSTパケットに含まれていたデータグラムのみを自身のデータグラムとして含んでおり且つ送信元及び宛先を該RSTパケットと同一にしたTCPパケットと、該RSTパケットから該データグラムのみを削除したRSTパケットとに分離してアドレス変換装置へ送信するRSTパケット分離部を更に有するように構成することもできる。
この構成によれば、組織外通信網に存在する端末装置から送られてきたRSTパケットで指示されている処理をサーバ装置が適切に実行できると共に、該RSTパケットと検出依頼メッセージであるRSTパケットとの識別を容易に行えるようになる。
なお、この構成において、宛先抽出部は、アドレス変換装置から受け取ったRSTパケットが検出依頼メッセージであるか否かを、該RSTパケットのパケットサイズに基づいて判定する検出依頼メッセージ判定部を有するように構成することもできる。
この構成によれば、アドレス変換装置から受け取ったRSTパケットが検出依頼メッセージでない場合の誤作動を防止できる。
また、前述した本発明に係る攻撃検出システムにおいて、パケット検査部は、該パケット検査部で検出された特定パケットに関する情報である特定パケット情報を所定の管理用端末装置へ送信する特定パケット情報送信部を有しており、宛先抽出部は、該宛先抽出部で抽出された実アドレスに関する情報を管理用端末装置へ送信する実アドレス情報送信部を有している、ように構成することもできる。
この構成によれば、攻撃検出システムによる特定パケットでの攻撃の検出結果を管理用端末装置に集中させることができるので、管理者による検出結果の把握が容易になる。
なお、この構成において、検出依頼メッセージには、特定パケット情報についての識別情報が含まれており、実アドレス情報送信部は、アドレス変換装置から受け取った検出依頼メッセージに含まれていた識別情報を実アドレスに関する情報に付加して送信する、ように構成することもできる。
この構成によれば、特定パケットに関する情報と該特定パケットの送信元を特定する実アドレスに関する情報との管理用端末装置での対応付けが容易になる。
また、この構成において、検出依頼メッセージには、管理用端末装置を特定するアドレス情報が含まれており、実アドレス情報送信部は、アドレス変換装置から受け取った検出依頼メッセージに含まれていたアドレス情報を宛先として実アドレスに関する情報を送信する、ように構成することもできる。
この構成によれば、管理用端末装置を特定するアドレス情報を予め宛先抽出部に与えておく必要がなくなる。
なお、上述した本発明に係る攻撃検出システムにおいて使用されている攻撃検出方法も本発明に係るものであり、本発明に係る攻撃検出システムと同様の作用・効果を奏するので、前述した課題が解決される。
本発明によれば、以上のようにすることにより、通信網における内部網から外部網への攻撃の検出が低廉に実現できるようになるという効果を奏する。
以下、本発明の実施の形態を図面に基づいて説明する。
まず図1について説明する。同図は、本発明を実施する攻撃検出システムを含む通信網の構成例を示している。同図に示す構成においては、IPS202とRIP検出装置303とからなる攻撃検出システムにより本発明が実施される。なお、この構成では、RIP検出装置303を他の装置から独立したものとしているが、この代わりに、RIP検出装置303によって提供される全ての機能をSLB201が提供するように構成して、IPS202とSLB201とからなる攻撃検出システムにより本発明を実施することも可能である。また、本発明の実施においては、必要に応じて管理者用端末203が使用される。
図1に示す構成において、ある組織内において使用されている通信網である内部網200は、IPS202を介して外部網100に接続されている。内部網200に対する外部の通信網である外部網100には、クライアント端末101a、101b、…が存在している。
内部網200では、サーバ301a及び301bとアドレス変換装置であるSLB201とによってWebへのアクセスを提供する仮想サーバ300が構成されており、SLB201がIPS202に接続されている。また、SLB201とサーバ301a及び301bとの間には、RIP検出装置303が設けられている。ここで、サーバ301a及び301bに個別に付与されているIPアドレス(実アドレス)をそれぞれ「RIP1」及び「RIP2」とし、仮想サーバ300に付与されているIPアドレス(仮想アドレス)を「VIP」とする。
なお、図1では、仮想サーバ300を2台のサーバ301a及び301bで構成しているが、更に多数の実サーバで仮想サーバ300を構成しても本発明の実施は可能である。
IPS202は、内部網200と外部網100との間で授受される通信パケットを検査して、特定の条件に合致するもの(特定パケット)を検出する。ここで、特定パケットとして前述した攻撃パケットが検出された場合には、この攻撃パケットの検出及び廃棄を行うと共に、攻撃があった旨の通知を管理者用端末202へ行う。特に、IPS202は、仮想サーバ300(すなわち、サーバ301a若しくは301b)から外部網100のクライアント端末101a、101b、…への攻撃パケットを検出した場合には、宛先IPアドレスを「VIP」にした(すなわち、仮想サーバ300宛ての)RSTパケットにデータグラムとしてRIP検出依頼を含ませたものを作成してSLB201へ送信する。このRIP検出依頼付きのRSTパケット(このRSTパケットを「検出依頼メッセージ」とも称することとする)は、IPS202で検出された攻撃パケットの送信元のサーバの検出と、この攻撃パケットに対応するTCPコネクションの強制的な切断とを、RIP検出装置303に依頼するためのものであり、本発明特有の検出依頼メッセージである。更に、IPS202は、攻撃パケットの解析によって判明した攻撃先のIPアドレス(攻撃パケットの宛先IPアドレス)と攻撃の内容を示す情報(攻撃種別)とを含む通信パケット(図1における「攻撃通知A」)を管理者用端末203へ送信する。
一方、IPS202で発行されたRIP検出依頼付きのRSTパケットは、SLB201によって従前のアドレス逆変換の処理が施され、その宛先IPアドレスが、「VIP」から、サーバ301a及び301bのうちIPS202で検出された攻撃パケットを発行したものの実アドレス(すなわち、「RIP1」及び「RIP2」のいずれか)へと書き換えられる。この書き換えがされたRIP検出依頼付きRSTパケットは、SLB201からRIP検出装置303へと送られる。
RIP検出装置303は、RIP検出依頼付きRSTパケットをSLB201から受け取ると、このRSTパケットに示されている宛先IPアドレスを抽出する。そして、抽出した宛先IPアドレス、すなわち、サーバ301a及び301bのうち攻撃パケットを発行したものの実アドレスを含む通信パケット(図1における「攻撃通知B」)を管理者用端末203へ送信する。
管理者用端末203は、IPS202から通知された攻撃通知AとRIP検出装置303から通知された攻撃通知Bとの対応付けを行い、その結果を表示装置に表示させる等して出力する。内部網200の管理者204は、この出力を参照することにより、サーバ301a及び301bのうち、外部網100のクライアント端末101a、101b、…を攻撃するためのコードが仕込まれたものを特定することができる。
また、以上の動作と並行して、RIP検出装置303は、SLB201から送られてきたRIP検出依頼付きRSTパケットからRIP検出依頼のみを削除して従前のRSTパケットを作成する。そして、作成したRSTパケットを、先に抽出していた宛先IPアドレスで特定されるサーバへ宛てて送信して、IPS202で検出された攻撃パケットに対応するTCPコネクションを強制的に切断させる。これにより、攻撃パケットから攻撃先(外部網100のクライアント端末101a、101b、…)が保護される。
次に図2について説明する。同図は、RIP検出依頼付きのIPパケットのデータ構造を示している。
図2に示すように、このIPパケットには、データグラムとしてRIP検出依頼の情報が含まれており、既知であるIPヘッダ及びTCPヘッダがこの情報に付されて構成されている。例えば、IPS202が発行するRIP検出依頼付きのRSTパケット(検出依頼メッセージ)には、攻撃パケットの宛先(すなわち攻撃先)のIPアドレスが送信元のIPアドレスとして、また、仮想アドレス「VIP」が宛先のIPアドレスとして、それぞれIPヘッダに格納されており、更に、TCPヘッダ中のコードビットフィールドにおけるRSTビットが“1”にセットされている。
図2に示すように、RIP検出依頼は、「攻撃検出ID」及び「管理者用端末のIPアドレス」の情報フィールドを有している。ここで、「攻撃検出ID」のフィールドには、攻撃パケットを検出する度にIPS202により一意に決定される識別情報が格納される。この識別情報は、前述した攻撃通知Aと攻撃通知Bとの対応関係を明らかにするために使用される。また、「管理者用端末のIPアドレス」のフィールドには、管理者用端末203に付与されているIPアドレスが格納される。これは、管理者用端末203のIPアドレスをIPS202からRIP検出装置303に通知するようにして、攻撃通知Bの送信先についての情報をRIP検出装置303へ直接設定する手間を不要にするためのものである。
次に図3について説明する。同図は、攻撃通知Aをデータグラムとして含むIPパケットのデータ構造を示している。IPS202は、IPS202自身のIPアドレスを送信元のIPアドレスとして、また、管理者用端末203のIPアドレスを宛先のIPアドレスとして、それぞれIPヘッダに格納して、このIPパケットを管理者用端末203へ送信する。
図3に示すように、攻撃通知Aは、「攻撃先IPアドレス」、「攻撃種別」、及び「攻撃検出ID」の情報フィールドを有している。ここで、「攻撃先IPアドレス」のフィールドには、IPS202による攻撃パケットの解析によって判明した攻撃先(クライアント端末101a、101b、…)のIPアドレス(攻撃パケットの宛先IPアドレス)が格納される。また、「攻撃種別」のフィールドには、IPS202による攻撃パケットの解析によって判明した攻撃の内容を示す情報が格納される。更に、「攻撃検出ID」のフィールドには、前述したRIP検出依頼における「攻撃検出ID」のフィールドに格納されるものと同一の識別情報が格納される。
次に図4について説明する。同図は、攻撃通知Bをデータグラムとして含むIPパケットのデータ構造を示している。RIP検出装置303は、RIP検出装置303自身のIPアドレスを送信元のIPアドレスとして、また、管理者用端末203のIPアドレスを宛先のIPアドレスとして、それぞれIPヘッダに格納して、このIPパケットを管理者用端末203へ送信する。ここで、管理者用端末203のIPアドレスは、IPS202が発行したRIP検出依頼付きのRSTパケットにデータグラムとして示されているものが用いられる。
図4に示すように、攻撃通知Bは、「攻撃元IPアドレス」及び「攻撃検出ID」の情報フィールドを有している。ここで、「攻撃元IPアドレス」のフィールドには、SLB201によるアドレス逆変換が施されたRIP検出依頼付きのRSTパケットのIPヘッダ部に宛先のIPアドレスとして格納されていたものが格納される。このIPアドレスは、攻撃パケットの発信元であるサーバ装置の実アドレスである。また、「攻撃検出ID」のフィールドには、前述したRIP検出依頼における「攻撃検出ID」のフィールドに格納されるものと同一の識別情報が格納される。
管理者用端末203は、攻撃通知Aと攻撃通知Bとを受け取ると、その各々に格納されている「攻撃検出ID」の識別情報を比較し、この両者が一致しているものを対応付けて出力する。内部網200の管理者204は、この対応付けられた攻撃通知Aと攻撃通知Bとの出力を参照することにより、サーバ301a及び301bのうち、外部網100のクライアント端末101a、101b、…を攻撃するためのコードが仕込まれたものを特定することができる。
次に、RIP検出装置によるRIP検出依頼の識別機能について、図5及び図6を用いて説明する。
図5及び図6に示したシステムは、管理者用端末203が不図示ではあるが、図1に示したものと同様の構成である。
図5と図6との両方に(a)として示すように、本発明を実施する攻撃検出システムでは、IPS202が内部網200から送られてきた攻撃パケットを検出したときには、RIP検出装置303には、RIP検出依頼をデータグラムとして含ませたRSTパケットがIPS202から送られてくる。また、これとは別に、図5に(b)として示すように、RIP検出装置303には、仮想サーバ300とのTCPコネクションの切断を要求するRSTパケットが、クライアント端末101a、101b、…からIPS202を経てRIP検出装置303へと送られてくる場合も考えられる。
RIP検出装置303は、この(b)に示したRSTパケットを受け取った場合には、そのデータグラムに含まれていたデータを、消失させることなく、RSTパケットの宛先のサーバ(サーバ301a若しくは301b)へ適切に転送すると共に、そのサーバにTCPコネクションの切断を実行させる必要がある。このためには、RIP検出装置303は、IPS202から送られてきたRSTパケットのデータグラムにRIP検出依頼が含まれているか否かを識別する必要がある。ところが、TCPパケットのデータグラムの解析を厳密に行うにはIPS202と同等の能力が一般的には必要である。これでは内部網200のシステムコストが高騰しかねない。
そこで、上述したRSTパケットの識別がRIP検出装置303で容易に行えるようにするために、IPS202は、図6の(b)に示すように、クライアント端末101a、101b、…から送られてきたRSTパケットに対し、該RSTパケットのデータグラムのみを自身のデータグラムとして含んでおり且つ送信元及び宛先と該RSTパケットと同一にしたTCPパケットと、該RSTパケットから該データグラムのみを削除したRSTパケットとに分離する処理を施す。そして、この処理によって得られたTCPパケット及びRSTパケットをSLB201へ送信する。
SLB201は、このTCPパケット及びRSTパケットに対して従前のアドレス逆変換の処理を施すことにより、その宛先IPアドレスを、サーバ301a及び301bのうちIPS202で検出された攻撃パケットを発行したものの実アドレスへと書き換えた上でRIP検出装置303へと送信する。
RIP検出装置303は、SLB201から受け取るパケットの識別を行う。ここで、IPS202によって分離されたRSTパケットはデータグラムが空であるので、RIP検出依頼付きのRSTパケットとはパケットサイズが明らかに異なっている。そこで、RIP検出装置303は、受け取ったRSTパケットをそのパケットサイズに基づいて分別する。つまり、IPS202が上述したようにしてRSTパケットの分離を行ったことにより、RIP検出装置303は、データグラムを厳密に解析することなく、RSTパケットにRIP検出依頼が付されているか否かを容易に識別することができるようになるのである。
ここで図7について説明する。同図は、図1のRIP検出装置303で行われるRIP検出処理をフローチャートで示したものである。
この図7の処理は、SLB201から専用の通信インタフェースを介して送られてきた通信パケットを、RIP検出装置303が受信する度に開始される。
図7において、まず、S101では、受信パケットがRSTパケットであるか否かを判定する処理が行われる。この判定は、具体的には、受信パケットのTCPヘッダ中のコードビットフィールドにおけるRSTビットが“1”にセットされているか否かを以って行われる。ここで、受信パケットがRSTパケットであると判定したとき(判定結果がYESのとき)にはS102に処理を進め、受信パケットがRSTパケットではないと判定したとき(判定結果がNOのとき)にはS108に処理を進める。
S102では、受信したRSTパケットのパケットサイズが40オクテットよりも大きいか否かを判定する処理が行われる。
既知のTCPパケットでは、IPヘッダ及びTCPヘッダのヘッダ長はそれぞれ20オクテットである。従って、この両者のヘッダ長の和である40オクテットよりもパケットサイズが大きいTCPパケットには、データグラムとして何らかのデータを有している。ところが、図1に示した攻撃検出システムにおけるIPS202は、クライアント端末101a、101b、…から送られてきたRSTパケットに対し前述したRSTパケットの分離処理を施しているので、ここでパケットサイズが40オクテットよりも大きいと判定されるRSTパケットは、RIP検出依頼付きのRSTパケットのみである。つまり、このS102の処理は、SLB201から受け取ったRSTパケットが検出依頼メッセージであるか否かを、該RSTパケットのパケットサイズに基づいて判定する処理、すなわち検出依頼メッセージ判定処理なのである。
このS102の判定処理において、受信したRSTパケットのパケットサイズが40オクテットよりも大きいと判定したとき(判定結果がYESのとき)は、検出依頼メッセージを受信したものとして、S103に処理を進める。一方、この判定処理において、受信したRSTパケットのパケットサイズが40オクテット以下であると判定したとき(判定結果がNOのとき)は、RIP検出依頼が付されていないRSTパケットを受信したものとして、S108に処理を進める。
S103では、RIP検出依頼解析処理、すなわち、受信した検出依頼メッセージを図2に示したデータ構造に基づいて解析して、攻撃検出IDと管理者用端末203のIPアドレスとを取得する処理が行われる。
S104では、受信パケットの宛先IPアドレス抽出処理、すなわち、受信した検出依頼メッセージにおけるIPヘッダを解析して、このメッセージの宛先のIPアドレスを抽出する処理が行われる。この処理によって抽出されるIPアドレスは、攻撃元IPアドレス、すなわち、攻撃パケットの送信元のサーバの実IPアドレスである。
S105では、攻撃通知B送信処理が行われる。すなわち、S103の処理によって取得された攻撃種別IDとS104の処理によって抽出された攻撃元IPアドレスとからなる攻撃通知Bを図4に示したデータ構造に従ってデータグラムとして格納し、更に、S103の処理によって取得された管理者用端末203のIPアドレスを宛先IPアドレスにすると共にRIP検出装置303自身に割り当てられているIPアドレスを送信元IPアドレスにしてIPヘッダを構成した通信パケットを、管理者用端末203へ送信する処理が行われる。
S106では、RIP検出依頼削除処理、すなわち、SLB201から送られてきた検出依頼メッセージからRIP検出依頼のみを削除して従前のRSTパケットを作成する処理が行われる。そして、続くS107では、RIP検出依頼を削除したRSTパケットを、サーバ301a及び301bのうちそのパケットの宛先のサーバへと送信する処理が行われ、その後はこの図7の処理を終了する。
ところで、S101若しくはS102の判定結果がNOである場合には、S108において受信パケット転送処理が行われる。すなわち、S101の判定結果がNOとなった受信パケット、すなわちRSTパケットでない受信パケット、及び、S102の判定結果がNOとなった受信パケット、すなわち検出依頼メッセージでない受信パケットを、宛先のサーバへと転送する処理が行われる。その後はこの図7の処理を終了する。
次に図8及び図9について説明する。図8はIPS202の機能構成を示すブロック図であり、図9はRIP検出装置303の機能構成を示すブロック図である。
まず、図8に示したIPS202の機能構成について説明する。
第一通信部211は、外部網100用の通信インタフェースと内部網200用の通信インタフェースとを備えており、外部網100及び内部網200の双方に対する通信パケットの送受信の処理を行う。
攻撃検出機能部212は、内部網200若しくは外部網100から受信される通信パケットを検査して、特定の条件に合致するもの(特定パケット)を検出する。ここで、前述したパターンファイルの適用等により、データグラムに悪意あるコードが含まれている攻撃パケットが特定パケットとして検出された場合には、この攻撃パケットの攻撃種別の判別を行い、判別結果を攻撃通知A作成部221に送ると共に、第二受信パケット判断部215を起動する。一方、受信パケットが攻撃パケットでないと判定した場合には、その判定結果を第一受信パケット判断部213に送る。
第一受信パケット判断部213は、受信パケットが、外部網100側の通信インタフェースから受信したデータグラム付きのRSTパケットであるか否かを判断し、この条件に合致する受信パケットをパケット分離部214へ送る。一方、この条件に合致しない受信パケットは第一通信部211へ送ってそのまま内部網200へ送信させる。
パケット分離部214は、第一受信パケット判断部213から受け取ったRSTパケットを、該RSTパケットのデータグラムのみを自身のデータグラムとして含んでおり且つ送信元及び宛先を該RSTパケットと同一にしたTCPパケット(「Dataパケット」と称することとする)と、該RSTパケットから該データグラムのみを削除したRSTパケットとに分離する。そして、得られたDataパケットとRSTパケットとを第一通信部211へ送って内部網200へ送信させる。なお、このとき、DataパケットをRSTパケットよりも先に送信させるようにする。
第二受信パケット判断部215は、攻撃パケットを受信した通信インタフェースが、内部網200用のものか外部網100用のものかを判断する。ここで、内部網200用の通信インタフェースから攻撃パケットを受信していたと判断した場合には、攻撃検出ID付与部217を起動する。一方、外部網100用の通信インタフェースから攻撃パケットを受信していたと判断した場合には、従来処理216、すなわち、外部網100からの攻撃に対して内部網200を防護するためにIPS202により従来から行われていた処理が実行される。
攻撃検出ID付与部217は、攻撃通知Aと攻撃通知Bとの対応関係を明らかにするための識別情報である前述した攻撃検出IDを、内部網200からの攻撃パケットが検出される度に付与すると共に、RIP検出依頼作成部219と攻撃先IPアドレス抽出部220とを起動する。ここでは、攻撃検出ID付与部217は、攻撃検出IDとして、攻撃パケット毎にユニークな番号を生成して付与するものとする。付与された攻撃検出IDは、RIP検出依頼作成部219と攻撃通知A作成部221とに送られる。そして、RIP検出依頼作成部219と攻撃先IPアドレス抽出部220とを起動する。
管理者用端末IPアドレス保持部218は半導体等のメモリである。管理者用端末IPアドレス保持部218には、管理者用端末203のIPアドレスが予め格納されて保持されている。
RIP検出依頼作成部219は、管理者用端末IPアドレス保持部218から得られる管理者用端末203のIPアドレスと、攻撃検出ID付与部217で付与された攻撃検出IDとよりRIP検出依頼を作成する。そして、図2にデータ構造を示したRIP検出依頼付きのIPパケットを作成する。なお、このIPパケットのIPヘッダは、送信元IPアドレスを、検出した攻撃パケットの宛先(すなわち攻撃先)のIPアドレスとし、宛先IPアドレスを、仮想アドレス「VIP」とする。更に、作成したIPパケットにおけるTCPヘッダ中のコードビットフィールドにおけるRSTビットを“1”にセットして検出依頼メッセージを作成する。そして、作成した検出依頼メッセージを第一通信部211へ送って内部網200へ送信させる。送信された検出依頼メッセージは、SLB201で受信されて宛先IPアドレスの逆変換処理が施された後、RIP検出装置303で受信される。
攻撃先IPアドレス抽出部220は、検出した攻撃パケットの宛先IPアドレスを、攻撃先のIPアドレスとして抽出する。そして、抽出したIPアドレスを攻撃通知A作成部221へ送る。
攻撃通知A作成部221は、攻撃検出ID付与部217で付与された攻撃検出ID、攻撃検出機能部212で判別された攻撃パケットの攻撃種別、及び攻撃先IPアドレス抽出部220で抽出された攻撃先IPアドレスより攻撃通知Aを作成する。そして、この攻撃通知Aをデータグラムとして含む図3に示したIPパケットを作成する。このIPパケットにおけるIPヘッダは、IPS202自身のIPアドレスを送信元のIPアドレスとし、また、管理者用端末IPアドレス保持部218から得られる管理者用端末203のIPアドレスを宛先のIPアドレスとする。そして、作成したIPパケットを第一通信部211へ送って内部網200へ送信させる。送信されたIPパケットは、その後管理者用端末203で受信される。
次に、図9に示したRIP検出装置303の機能構成について説明する。
第二通信部311は、内部網200用の通信インタフェースを備えており、内部網200に対する通信パケットの送受信の処理を行う。
第三受信パケット判断部312は、図7のS101及びS102の処理を行い、SLB201から受信される通信パケットが、RSTパケットであって且つパケットサイズが40オクテッドよりも大きいか否かを判断する。そして、受信パケットがこの条件に合致した場合には、この受信パケットをRIP検出依頼解析部313へ送る。一方、この条件に合致しない受信パケットは第二通信部311へ送ってそのままサーバ301a若しくは301bへ宛てて送信させる。
RIP検出依頼解析部313は、図7のS103の処理を行い、受信パケットに含まれているRIP検出依頼の各フィールドのデータを抽出し、その後は攻撃元IPアドレス抽出部314を起動する。なお、ここで抽出されたデータは、攻撃通知B作成部315とRIP検出依頼削除部316とへ送られる。
攻撃元IPアドレス抽出部314は、受信パケットの宛先IPアドレスを、攻撃元IPアドレスとして抽出して攻撃通知B作成部315に送ると共に、RIP検出依頼削除部316を起動する。
攻撃通知B作成部315は、RIP検出依頼解析部313で抽出された攻撃検出IDと、攻撃元IPアドレス抽出部314で抽出された攻撃元IPアドレスとより攻撃通知Bを作成する。そして、この攻撃通知Bをデータグラムとして含む図4に示したIPパケットを作成する。このIPパケットにおけるIPヘッダは、RIP検出装置303自身のIPアドレスを送信元のIPアドレスとし、また、RIP検出依頼解析部313で抽出された管理者用端末203のIPアドレスを宛先のIPアドレスとする。そして、作成したIPパケットを第二通信部311へ送って内部網200へ送信させる。送信されたIPパケットは、その後管理者用端末203で受信される。
RIP検出依頼削除部316は、受信パケットにデータグラムとして含まれているRIP検出依頼を削除する。そして、生成されたRSTパケットを第二通信部311へ送り、攻撃パケットを送信した攻撃元のサーバへ宛ててこのRSTパケットを送信させる。
以下、図1に示した通信網における攻撃検出システムの動作説明を、内部網200のサーバ301aが外部網100のクライアント端末101a宛の攻撃パケットを送信した場合と、外部網100のクライアント端末101aが内部網200の仮想サーバ300宛のRSTパケットを送信した場合とに分けて説明する。
まず図10A及び図10Bについて説明する。図10Aは、サーバ301aが攻撃パケットを送信した場合における各種通信パケットの授受の様子を示したものであり、図10Bは、図10Aの場合に授受される通信パケットの一覧を示している。なお、図10Aにおいては、簡単のため、外部網100に存在するものとして、クライアント端末101aのみを表示している。
図10Aに示した通信網に存在する各装置のIPアドレスは、以下のように定義されているものとする。
・サーバ301aの実アドレス :AA.BB.CC.D1
・サーバ301bの実アドレス :AA.BB.CC.D2
・仮想サーバ300の仮想アドレス :WW.XX.YY.ZZ
・RIP検出装置303のアドレス :AA.BB.CC.E1
・クライアント端末101aのアドレス:FF.GG.HH.II
・管理者用端末203のアドレス :JJ.KK.LL.MM
・IPS202のアドレス :NN.OO.PP.QQ
以下、図10A及び図10Bに記した項番号に従って各通信パケットの授受の様子を説明する。
(1)まず、サーバ301aは、悪意のあるコードを含んでいる、クライアント端末101a宛の通信パケット(例えばHTTP Replyメッセージ)を送信する。
(2)上記(1)のパケットは、送信元IPアドレスがSLB201によって仮想サーバ300の仮想アドレスに変換された後、RIP検出装置303を通過してIPS202で受信される。
(3)ここで、IPS202は受信した通信パケットが攻撃パケットであることを検出する。すると、IPS202はこの攻撃パケットを外部網100へ送出することなく廃棄する一方で、攻撃検出IDの割り当て、この攻撃パケットの攻撃種別の特定、この攻撃パケットの宛先IPアドレス(すなわち攻撃先のIPアドレス)の抽出、及び、攻撃通知Aを含む通信パケットの管理者用端末203への送信の各処理を行う。
(4)次に、IPS202は、RIP検出依頼をデータグラムとして有するRSTパケットを作成する。そして、該RSTパケットのIPヘッダについて、攻撃先であるクライアント端末101aのIPアドレスを送信元IPアドレスに設定すると共に、仮想サーバ300の仮想アドレスを宛先IPアドレスに設定した上で、該RSTパケットを送信する。
(5)上記(3)においてIPS202から送信された攻撃通知Aを含む通信パケットは、管理者用端末203で受信される。この攻撃通知Aに格納される攻撃検出IDは、上記(3)で割り当てがされたものである。なお、IPS202は、この攻撃通知Aを含む通信パケットの送信を、上記(4)のRIP検出依頼付きRSTパケットの送信後に行うが、この通信パケットの送信タイミングは、下記(6)の通信パケットの送信タイミングとは独立のものである。
(6)上記(4)のRIP検出依頼付きRSTパケットは、SLB201によるアドレス逆変換により、宛先IPアドレスが上記(1)の送信元IPアドレス(すなわち、攻撃パケットの送信元であるサーバ301aの実アドレス)に変換された後、RIP検出装置303で受信される。
(7)RIP検出装置303は、攻撃パケットの送信元が宛先IPアドレスに示されているRIP検出依頼付きRSTパケットに対して図7に示したRIP検出処理を施し、RIP検出依頼の解析、受信したRSTパケットの宛先IPアドレスの抽出、受信したRSTパケットからのRIP検出依頼の削除、RIP検出依頼を削除したRSTパケットの転送、及び、攻撃通知Bを含む通信パケットの管理者用端末203への送信の各処理を行う。
(8)上記(7)に示した、RIP検出依頼を削除したRSTパケットは、攻撃パケットの送信元であるサーバ301aの実アドレスが宛先IPアドレスに示されているので、サーバ301aで受信される。すると、サーバ301aは、サーバ301a自身とクライアント端末101aとのコネクションを強制的に切断する。この結果、クライアント端末101aは、サーバ301aからの攻撃から保護される。
(9)一方、上記(7)においてIPS202から送信された攻撃通知Bを含む通信パケットは、管理者用端末203で受信される。この攻撃通知Bに格納される攻撃検出IDは、上記(3)で割り当てがされたものであり、上記(7)でのRIP検出依頼の解析によってRIP検出依頼付きRSTパケットから抽出されたものである。
(10)管理者用端末203は、上記(5)に示した攻撃通知Aを含む通信パケットと、上記(9)に示した攻撃通知Bを含む通信パケットとを受信すると、この両者に示されている攻撃検出IDをキーとして両者を対応付ける。そして、対応付けられた攻撃通知Aと攻撃通知Bとに示されている攻撃先IPアドレス(すなわちクライアント端末101aのIPアドレス)、攻撃元IPアドレス(すなわちサーバ301aのIPアドレス)、及び攻撃種別を表示装置に表示する等して出力し、管理者204へ通知する。
次に、上記(3)から(5)にかけてIPS202で行われる処理の詳細について、図11を用いて説明する。図11は、図8に示したIPS202の機能構成ブロック図において、上記(3)から(5)にかけての処理が実行されるときに使用される部分を太線で示したものである。
まず、送信元IPアドレスがSLB201によって仮想サーバ300の仮想アドレスへ変換されている上記(2)のパケットを第一通信部211が受信する。ここで、攻撃検出機能部212が、この受信パケットが攻撃パケットであることを検出する。すると、攻撃検出機能部212は、この攻撃パケットの攻撃種別を特定し、その結果を攻撃通知A作成部221に送ると共に、第二受信パケット判断部215を起動する。
第二受信パケット判断部215は、ここで、攻撃パケットを受信した通信インタフェースが、内部網200用のものであると判断し、この判断結果に応じて攻撃検出ID付与部217を起動する。
攻撃検出ID付与部217は、この攻撃パケットに割り当てられる攻撃検出IDを生成して、RIP検出依頼作成部219と攻撃通知A作成部221とに送る。そして、RIP検出依頼作成部219と攻撃先IPアドレス抽出部220とを起動する。
RIP検出依頼作成部219は、管理者用端末IPアドレス保持部218から得られる管理者用端末203のIPアドレスと、攻撃検出ID付与部217で付与された攻撃検出IDとよりRIP検出依頼を作成する。そして、RIP検出依頼付きのRSTパケットを作成し、そのIPヘッダにおける送信元IPアドレスをクライアント端末101a(すなわち攻撃先)のIPアドレスとし、そのIPヘッダにおける宛先IPアドレスを仮想サーバ300の仮想アドレスとする。そして、作成したRIP検出依頼付きのRSTパケットを第一通信部211へ送って内部網200へ送信させる(上記(4))。
一方、攻撃先IPアドレス抽出部220では、検出した攻撃パケットの宛先IPアドレスが、攻撃先のIPアドレスとして抽出される。そして、攻撃先IPアドレス抽出部220は、抽出したIPアドレスを攻撃通知A作成部221へ送る。
攻撃通知A作成部221は、攻撃検出ID付与部217で付与された攻撃検出ID、攻撃検出機能部212で特定された攻撃パケットの攻撃種別、及び攻撃先IPアドレス抽出部220で抽出された攻撃先IPアドレスより攻撃通知Aを作成する。そして、この攻撃通知Aをデータグラムとして含むIPパケットを作成する。このIPパケットのIPヘッダにおいて、IPS202自身のIPアドレスが送信元のIPアドレスとされ、また、管理者用端末IPアドレス保持部218から得られる管理者用端末203のIPアドレスが宛先のIPアドレスとされる。そして、作成したIPパケットを第一通信部211へ送って内部網200へ送信させる(上記(5))。
次に、上記(7)から(9)にかけてRIP検出装置303によって行われる処理の詳細について、図12を用いて説明する。図12は、図9に示したRIP検出装置303の機能構成ブロック図において、上記(7)から(9)にかけての処理が実行されるときに使用される部分を太線で示したものである。
まず、宛先IPアドレスがSLB201によって攻撃パケットの送信元であるサーバ301aの実アドレスに変換されている上記(6)のパケット(すなわちRIP検出依頼付きRSTパケット)を第二通信部311が受信する。すると、第三受信パケット判断部312は、この受信パケットが、RSTパケットであって且つパケットサイズが40オクテッドよりも大きいとの判断を下し、この判断結果に基づいて受信パケットをRIP検出依頼解析部313へ送る。
RIP検出依頼解析部313は、受信パケットに含まれているRIP検出依頼の各フィールドのデータを抽出し、抽出されたデータを、攻撃通知B作成部315とRIP検出依頼削除部316とへ送ると共に、攻撃元IPアドレス抽出部314を起動する。
攻撃元IPアドレス抽出部314は、受信パケットの宛先IPアドレスを、攻撃元IPアドレスとして抽出して攻撃通知B作成部315に送ると共に、RIP検出依頼削除部316を起動する。
攻撃通知B作成部315は、RIP検出依頼解析部313で抽出された攻撃検出IDと、攻撃元IPアドレス抽出部314で抽出された攻撃元IPアドレスとより攻撃通知Bを作成する。そして、この攻撃通知Bをデータグラムとして含むIPパケットを作成し、そのIPヘッダについて、RIP検出装置303自身のIPアドレスを送信元のIPアドレスとし、また、RIP検出依頼解析部313で抽出された管理者用端末203のIPアドレスを宛先のIPアドレスとする。そして、作成したIPパケットを第二通信部311へ送って内部網200へ送信させる(上記(9))。
一方、RIP検出依頼削除部316は、受信パケットにデータグラムとして含まれているRIP検出依頼を削除する。そして、生成されたRSTパケットを第二通信部311へ送り、攻撃パケットを送信した攻撃元のサーバ301aへ宛ててこのRSTパケットを送信させる(上記(8))。
次に図13A及び図13Bについて説明する。図13Aは、クライアント端末101aが仮想サーバ300宛のRSTパケットを送信した場合における各種通信パケットの授受の様子を示したものであり、図13Bは、図13Aの場合に授受される通信パケットの一覧を示している。なお、図13Aにおいては、簡単のため、外部網100に存在するものとして、クライアント端末101aのみを表示している。
なお、図13Aに示した通信網に存在する各装置のIPアドレスは、図10Aにおけるものと同一に定義されているものとする。
以下、図13A及び図13Bに記した項番号に従って各通信パケットの授受の様子を説明する。
(1)まず、クライアント端末101aは、正常な(悪意のない)データをデータグラムとして含むRSTパケットを仮想サーバ300へ宛てて送信する。このRSTパケットはIPS202で受信される。
(2)IPS202は、このRSTパケットを外部網100用のインタフェースで受信したことを検出すると、このRSTパケットを、データグラムのみのTCPパケットとデータグラムが空のRSTパケットとに分離し、その両者を送信する。
(3)上記(2)で分離された通信パケットのうち、データグラムのみのTCPパケットがまずSLB201で受信される。
(4)上記(3)のTCPパケットは、SLB201によるアドレス変換処理が施された後、RIP検出装置303で受信される。なお、ここでは、SLB201によるアドレス変換によって、このTCPパケットの宛先IPアドレスがサーバ301bの実アドレスに変換されるものとする。
(5)RIP検出装置303は、上記(4)のTCPパケットに対して図7に示したRIP検出処理を施すが、結果として何ら変更を加えることなく、そのまま該TCPパケットをサーバ301bへ宛てて転送する。
(6)サーバ301bは、上記(4)のTCPパケットを受信すると、該TCPパケットのデータグラムを読み出して所定の処理を実行する。
(7)一方、上記(2)で分離された通信パケットのうち、データグラムが空のRSTパケットは、データグラムのみのTCPパケットに続いてSLB201で受信される。
(8)上記(7)のRSTパケットは、SLB201でのアドレス変換処理により宛先IPアドレスがサーバ301bの実アドレスへと変換された後に、RIP検出装置303で受信される。
(9)RIP検出装置303は、上記(8)のRSTパケットに対して図7に示したRIP検出処理を施すが、結果として何ら変更を加えることなく、そのまま該RSTパケットをサーバ301bへ宛てて転送する。
(10)サーバ301bは、上記(9)のRSTパケットを受信すると、サーバ301b自身とクライアント端末101との間のTCPコネクションを強制的に切断する。
以上のように、図1の通信網では、クライアント端末101aが送信した正常な(悪意のない)データをデータグラムとして含むRSTパケットを上述したようにして分離しているが、サーバ301bは、このRSTパケットで指示されている内容に応じた処理を適切に実行する。
次に、上記(2)から(3)にかけて及び(7)においてIPS202で行われる処理の詳細について、図14を用いて説明する。図14は、図8に示したIPS202の機能構成ブロック図において、上記(2)から(3)にかけて及び(7)の処理が実行されるときに使用される部分を太線で示したものである。
まず、送信元IPアドレスがSLB201によって仮想サーバ300の仮想アドレスへ変換されている上記(2)のパケットを第一通信部211が受信する。ここで、攻撃検出機能部212が、この受信パケットが攻撃パケットではないと判定する。すると、攻撃検出機能部212は、その判定結果を第一受信パケット判断部213に送る。
ここで、第一受信パケット判断部213は、受信パケットが外部網100側の通信インタフェースから受信したデータグラム付きのRSTパケットであると判断し、受信パケットをパケット分離部214へ送る。
パケット分離部214は、第一受信パケット判断部213から受け取ったRSTパケットを、該RSTパケットのデータグラムのみを自身のデータグラムとして含んでおり且つ送信元及び宛先と該RSTパケットと同一にしたDataパケットと、該RSTパケットから該データグラムのみを削除したRSTパケットとに分離する。そして、得られたDataパケットとRSTパケットとを第一通信部211へ送り、この両者をこの順序で内部網200へ送信させる(上記(3)及び(7))。
次に、上記(5)から(6)にかけてRIP検出装置303によって行われる処理の詳細について、図15を用いて説明する。図15は、図9に示したRIP検出装置303の機能構成ブロック図において、上記(5)から(6)にかけての処理が実行されるときに使用される部分を太線で示したものである。
まず、SLB201によるアドレス変換によって、宛先IPアドレスがサーバ301bの実アドレスに変換されているTCPパケット(データグラムのみのTCPパケット)を第二通信部311が受信する。すると、第三受信パケット判断部312は、この受信パケットが、RSTパケットではないとの判断を下し、この判断結果に基づいて受信パケットを第二通信部311へ送ってそのままサーバ301bへ宛てて送信させる(上記(6))。
次に、上記(9)から(10)にかけてRIP検出装置303によって行われる処理の詳細について説明する。図9に示したRIP検出装置303の機能構成ブロック図において、上記(9)から(10)にかけての処理が実行されるときに使用される部分を太線で示すと、この図は図15と同一の図となる。
まず、SLB201によるアドレス変換によって、宛先IPアドレスがサーバ301bの実アドレスに変換されているRSTパケット(データグラムが空のRSTパケット)を第二通信部311が受信する。すると、第三受信パケット判断部312は、この受信パケットのパケットサイズが、40オクテット以下であるとの判断を下し、この判断結果に基づいて受信パケットを第二通信部311へ送ってそのままサーバ301bへ宛てて送信させる(上記(6))。
以上のように、図1に示した通信網に設けた攻撃検出システムでは、SLB201によるアドレス変換後の内部網200から、該変換前のアドレスを検出する機能を、低廉に提供することができる。
なお、上述した実施形態において、図8に示したIPS202の機能構成や図9に示したRIP検出装置303の機能構成を、共通のハードウェアで実現することも可能である。すなわち、これらの構成によって提供される機能を、例えば、ROM(Read Only Memory)などの不揮発性メモリと、RAM(Random Access Memory)などの揮発性メモリと、MPU(Micro Processing Unit)とを備えるコンピュータによって実現することができる。すなわち、各構成要素の機能を実現するプログラムを予め作成して不揮発性メモリに格納しておき、MPUがそのプログラムを読み込み揮発性メモリを作業用記憶領域として利用しながら該プログラムを実行することによって、実現させることも可能である。
以上、本発明の実施形態を説明したが、本発明は、上述した実施形態に限定されることなく、本発明の要旨を逸脱しない範囲内で種々の改良・変更が可能である。
なお、上記した実施の形態から次のような構成の技術的思想が導かれる。
(付記1)ある組織内の通信網に存在しており各自固有の実アドレスに加えてアドレス変換装置によって共通の仮想アドレスが割り当てられている複数のサーバ装置のうちのいずれかから該組織外の通信網に存在する端末装置への攻撃を検出する攻撃検出システムであって、
前記組織内通信網と前記組織外通信網との間で授受される通信パケットを検査して特定の条件に合致する特定パケットを検出するパケット検査部と、
前記パケット検査部が前記組織内通信網から送られてきた前記特定パケットを検出したときに、該特定パケットの送信元を検出する依頼を含んでおり前記仮想アドレスを宛先にした検出依頼メッセージを作成して前記アドレス変換装置へ送信する検出依頼メッセージ作成部と、
前記アドレス変換装置によって宛先が前記仮想アドレスから前記特定パケットの送信元であるサーバ装置の実アドレスへと書き換えられた前記検出依頼メッセージを受け取ったときに、該検出依頼メッセージに宛先として示されている実アドレスを抽出する宛先抽出部と、
を有することを特徴とする攻撃検出システム。
(付記2)前記特定パケットの伝送に使用されているコネクションを強制切断させるメッセージを、前記宛先抽出部が抽出した実アドレスで特定されるサーバ装置へ宛てて送信する強制切断メッセージ送信部を更に有することを特徴とする付記1に記載の攻撃検出システム。
(付記3)前記検出依頼メッセージ作成部は、前記検出依頼メッセージとして、TCPプロトコルにおけるRSTパケットであって前記特定パケットの伝送に使用されているコネクションを強制切断させるものであり、且つ該特定パケットの送信元を検出する依頼を示す情報をデータグラムとして含んでいるものを作成することを特徴とする付記1に記載の攻撃検出システム。
(付記4)前記アドレス変換装置によって宛先が前記仮想アドレスから前記特定パケットの送信元であるサーバ装置の実アドレスへと書き換えられた前記検出依頼メッセージであるRSTパケットを前記宛先抽出部が受け取ったときに、該RSTパケットからデータグラムのみを削除したものを該実アドレスで特定されるサーバ装置へ宛てて送信する強制切断メッセージ送信部を更に有することを特徴とする付記3に記載の攻撃検出システム。
(付記5)前記組織外通信網に存在する端末装置から送られてきたTCPプロトコルにおけるRSTパケットを前記パケット検査部が検出したときに、該RSTパケットを、該RSTパケットに含まれていたデータグラムのみを自身のデータグラムとして含んでおり且つ送信元及び宛先を該RSTパケットと同一にしたTCPパケットと、該RSTパケットから該データグラムのみを削除したRSTパケットとに分離して前記アドレス変換装置へ送信するRSTパケット分離部を更に有することを特徴とする付記4に記載の攻撃検出システム。
(付記6)前記宛先抽出部は、前記アドレス変換装置から受け取ったRSTパケットが前記検出依頼メッセージであるか否かを、該RSTパケットのパケットサイズに基づいて判定する検出依頼メッセージ判定部を有することを特徴とする付記5に記載の攻撃検出システム。
(付記7)前記パケット検査部は、該パケット検査部で検出された特定パケットに関する情報である特定パケット情報を所定の管理用端末装置へ送信する特定パケット情報送信部を有しており、
前記宛先抽出部は、該宛先抽出部で抽出された実アドレスに関する情報を前記管理用端末装置へ送信する実アドレス情報送信部を有している、
ことを特徴とする付記1に記載の攻撃検出システム。
(付記8)前記検出依頼メッセージには、前記特定パケット情報についての識別情報が含まれており、
前記実アドレス情報送信部は、前記アドレス変換装置から受け取った前記検出依頼メッセージに含まれていた識別情報を実アドレスに関する情報に付加して送信する、
ことを特徴とする付記7に記載の攻撃検出システム。
(付記9)前記検出依頼メッセージには、前記管理用端末装置を特定するアドレス情報が含まれており、
前記実アドレス情報送信部は、前記アドレス変換装置から受け取った前記検出依頼メッセージに含まれていたアドレス情報を宛先として前記実アドレスに関する情報を送信する、
ことを特徴とする付記7に記載の攻撃検出システム。
(付記10)ある組織内の通信網に存在しており各自固有の実アドレスに加えてアドレス変換装置によって共通の仮想アドレスが割り当てられている複数のサーバ装置のうちのいずれかから該組織外の通信網に存在する端末装置への攻撃を検出する攻撃検出方法であって、
前記組織内通信網と前記組織外通信網との間で授受される通信パケットを検査して特定の条件に合致する特定パケットを検出し、
前記組織内通信網から送られてきた前記特定パケットを検出したときに、該特定パケットの送信元を検出する依頼を含んでおり前記仮想アドレスを宛先にした検出依頼メッセージを作成して前記アドレス変換装置へ送信し、
前記アドレス変換装置によって宛先が前記仮想アドレスから前記特定パケットの送信元であるサーバ装置の実アドレスへと書き換えられた前記検出依頼メッセージを受け取ったときに、該検出依頼メッセージに宛先として示されている実アドレスを抽出する、
ことを特徴とする攻撃検出方法。
(付記11)前記特定パケットの伝送に使用されているコネクションを強制切断させるメッセージを、前記実アドレスの抽出によって抽出された実アドレスで特定されるサーバ装置へ宛てて送信することを特徴とする付記10に記載の攻撃検出方法。
(付記12)前記アドレス変換装置へ送信する検出依頼メッセージの作成においては、TCPプロトコルにおけるRSTパケットであって前記特定パケットの伝送に使用されているコネクションを強制切断させるものであり、且つ該特定パケットの送信元を検出する依頼を示す情報をデータグラムとして含んでいるものを該検出依頼メッセージとして作成することを特徴とする付記10に記載の攻撃検出方法。
(付記13)前記特定パケットの伝送に使用されているコネクションを強制切断させるメッセージの送信において、前記アドレス変換装置によって宛先が前記仮想アドレスから前記特定パケットの送信元であるサーバ装置の実アドレスへと書き換えられた前記検出依頼メッセージであるRSTパケットを受け取ったときには、該RSTパケットからデータグラムのみを削除したものを該実アドレスで特定されるサーバ装置へ宛てて送信することを特徴とする付記12に記載の攻撃検出方法。
(付記14)前記特定パケットの検出において、前記組織外通信網に存在する端末装置から送られてきたTCPプロトコルにおけるRSTパケットを検出したときには、該RSTパケットを、該RSTパケットに含まれていたデータグラムのみを自身のデータグラムとして含んでおり且つ送信元及び宛先を該RSTパケットと同一にしたTCPパケットと、該RSTパケットから該データグラムのみを削除したRSTパケットとに分離して前記アドレス変換装置へ送信することを特徴とする付記13に記載の攻撃検出方法。
(付記15)前記実アドレスの抽出の前に、前記アドレス変換装置から受け取ったRSTパケットが前記検出依頼メッセージであるか否かを、該RSTパケットのパケットサイズに基づいて判定することを特徴とする付記14に記載の攻撃検出方法。
(付記16)前記検査によって前記特定パケットが検出されたときに、該特定パケットに関する情報である特定パケット情報を所定の管理用端末装置へ送信し、
前記実アドレスの抽出を行ったときに、抽出された実アドレスに関する情報を前記管理用端末装置へ送信する、
ことを特徴とする付記10に記載の攻撃検出方法。
(付記17)前記検出依頼メッセージには、前記特定パケット情報についての識別情報が含まれており、
前記実アドレスに関する情報を送信するときには、前記アドレス変換装置から受け取った前記検出依頼メッセージに含まれていた識別情報を実アドレスに関する情報に付加して送信する、
ことを特徴とする付記16に記載の攻撃検出方法。
(付記18)前記検出依頼メッセージには、前記管理用端末装置を特定するアドレス情報が含まれており、
前記実アドレスに関する情報を送信するときには、前記アドレス変換装置から受け取った前記検出依頼メッセージに含まれていたアドレス情報を宛先として該実アドレスに関する情報を送信する、
ことを特徴とする付記16に記載の攻撃検出方法。
本発明を実施する攻撃検出システムを含む通信網の構成例を示す図である。 RIP検出依頼付きのIPパケットのデータ構造を示す図である。 攻撃通知Aをデータグラムとして含むIPパケットのデータ構造を示す図である。 攻撃通知Bをデータグラムとして含むIPパケットのデータ構造を示す図である。 RIP検出依頼の識別機能を説明する図(その1)である。 RIP検出依頼の識別機能を説明する図(その2)である。 RIP検出処理をフローチャートで示した図である。 図1に示したIPSの機能構成を示すブロック図である。 図1に示したRIP検出装置の機能構成を示すブロック図である。 図1に示したサーバ301aが攻撃パケットを送信した場合における各種通信パケットの授受の様子を示す図である。 図10Aの場合に授受される通信パケットの一覧を示す図である。 図10Aの場合にIPSで行われる処理の詳細を説明する図である。 図10Aの場合にRIP検出装置で行われる処理の詳細を説明する図である。 クライアント端末が仮想サーバ宛のRSTパケットを送信した場合における各種通信パケットの授受の様子を示す図である。 図13Aの場合に授受される通信パケットの一覧を示す図である。 図13Aの場合にIPSで行われる処理の詳細を説明する図である。 図13Aの場合にRIP検出装置で行われる処理の詳細を説明する図である。 通信網の構成例を示す図である。 図16に示した通信網におけるIPSの配置例を示す図である。 従来技術の問題点を説明する図(その1)である。 従来技術の問題点を説明する図(その2)である。
符号の説明
100 外部網
101a、101b クライアント端末
200 内部網
201 SLB(サーバ負荷分散装置)
202、302 IPS(不正侵入検出システム)
203 管理者用端末
204 管理者
211 第一通信部
212 攻撃検出機能部
213 第一受信パケット判断部
214 パケット分離部
215 第二受信パケット判断部
216 従来処理
217 攻撃検出ID付与部
218 管理者用端末IPアドレス保持部
219 RIP検出依頼作成部
220 攻撃先IPアドレス抽出部
221 攻撃通知A作成部
300 仮想サーバ
301a、301b、301c、301d サーバ
303 RIP検出装置
311 第二通信部
312 第三受信パケット判断部
313 RIP検出依頼解析部
314 攻撃元IPアドレス抽出部
315 攻撃通知B作成部
316 RIP検出依頼削除部

Claims (10)

  1. ある組織内の通信網に存在しており各自固有の実アドレスに加えてアドレス変換装置によって共通の仮想アドレスが割り当てられている複数のサーバ装置のうちのいずれかから該組織外の通信網に存在する端末装置への攻撃を検出する攻撃検出システムであって、
    前記組織内通信網と前記組織外通信網との間で授受される通信パケットを検査して特定の条件に合致する特定パケットを検出するパケット検査部と、
    前記パケット検査部が前記組織内通信網から送られてきた前記特定パケットを検出したときに、該特定パケットの送信元を検出する依頼を含んでおり前記仮想アドレスを宛先にした検出依頼メッセージを作成して前記アドレス変換装置へ送信する検出依頼メッセージ作成部と、
    前記アドレス変換装置によって宛先が前記仮想アドレスから前記特定パケットの送信元であるサーバ装置の実アドレスへと書き換えられた前記検出依頼メッセージを受け取ったときに、該検出依頼メッセージに宛先として示されている実アドレスを抽出する宛先抽出部と、
    を有することを特徴とする攻撃検出システム。
  2. 前記特定パケットの伝送に使用されているコネクションを強制切断させるメッセージを、前記宛先抽出部が抽出した実アドレスで特定されるサーバ装置へ宛てて送信する強制切断メッセージ送信部を更に有することを特徴とする請求項1に記載の攻撃検出システム。
  3. 前記検出依頼メッセージ作成部は、前記検出依頼メッセージとして、TCPプロトコルにおけるRSTパケットであって前記特定パケットの伝送に使用されているコネクションを強制切断させるものであり、且つ該特定パケットの送信元を検出する依頼を示す情報をデータグラムとして含んでいるものを作成することを特徴とする請求項1に記載の攻撃検出システム。
  4. 前記アドレス変換装置によって宛先が前記仮想アドレスから前記特定パケットの送信元であるサーバ装置の実アドレスへと書き換えられた前記検出依頼メッセージであるRSTパケットを前記宛先抽出部が受け取ったときに、該RSTパケットからデータグラムのみを削除したものを該実アドレスで特定されるサーバ装置へ宛てて送信する強制切断メッセージ送信部を更に有することを特徴とする請求項3に記載の攻撃検出システム。
  5. 前記組織外通信網に存在する端末装置から送られてきたTCPプロトコルにおけるRSTパケットを前記パケット検査部が検出したときに、該RSTパケットを、該RSTパケットに含まれていたデータグラムのみを自身のデータグラムとして含んでおり且つ送信元及び宛先を該RSTパケットと同一にしたTCPパケットと、該RSTパケットから該データグラムのみを削除したRSTパケットとに分離して前記アドレス変換装置へ送信するRSTパケット分離部を更に有することを特徴とする請求項4に記載の攻撃検出システム。
  6. 前記宛先抽出部は、前記アドレス変換装置から受け取ったRSTパケットが前記検出依頼メッセージであるか否かを、該RSTパケットのパケットサイズに基づいて判定する検出依頼メッセージ判定部を有することを特徴とする請求項5に記載の攻撃検出システム。
  7. 前記パケット検査部は、該パケット検査部で検出された特定パケットに関する情報である特定パケット情報を所定の管理用端末装置へ送信する特定パケット情報送信部を有しており、
    前記宛先抽出部は、該宛先抽出部で抽出された実アドレスに関する情報を前記管理用端末装置へ送信する実アドレス情報送信部を有している、
    ことを特徴とする請求項1に記載の攻撃検出システム。
  8. 前記検出依頼メッセージには、前記特定パケット情報についての識別情報が含まれており、
    前記実アドレス情報送信部は、前記アドレス変換装置から受け取った前記検出依頼メッセージに含まれていた識別情報を実アドレスに関する情報に付加して送信する、
    ことを特徴とする請求項7に記載の攻撃検出システム。
  9. 前記検出依頼メッセージには、前記管理用端末装置を特定するアドレス情報が含まれており、
    前記実アドレス情報送信部は、前記アドレス変換装置から受け取った前記検出依頼メッセージに含まれていたアドレス情報を宛先として前記実アドレスに関する情報を送信する、
    ことを特徴とする請求項7に記載の攻撃検出システム。
  10. ある組織内の通信網に存在しており各自固有の実アドレスに加えてアドレス変換装置によって共通の仮想アドレスが割り当てられている複数のサーバ装置のうちのいずれかから該組織外の通信網に存在する端末装置への攻撃を検出する攻撃検出方法であって、
    前記組織内通信網と前記組織外通信網との間で授受される通信パケットを検査して特定の条件に合致する特定パケットを検出し、
    前記組織内通信網から送られてきた前記特定パケットを検出したときに、該特定パケットの送信元を検出する依頼を含んでおり前記仮想アドレスを宛先にした検出依頼メッセージを作成して前記アドレス変換装置へ送信し、
    前記アドレス変換装置によって宛先が前記仮想アドレスから前記特定パケットの送信元であるサーバ装置の実アドレスへと書き換えられた前記検出依頼メッセージを受け取ったときに、該検出依頼メッセージに宛先として示されている実アドレスを抽出する、
    ことを特徴とする攻撃検出方法。
JP2006241287A 2006-09-06 2006-09-06 攻撃検出システム及び攻撃検出方法 Expired - Fee Related JP4664257B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2006241287A JP4664257B2 (ja) 2006-09-06 2006-09-06 攻撃検出システム及び攻撃検出方法
US11/700,449 US7979575B2 (en) 2006-09-06 2007-01-31 Attack detecting system and attack detecting method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2006241287A JP4664257B2 (ja) 2006-09-06 2006-09-06 攻撃検出システム及び攻撃検出方法

Publications (2)

Publication Number Publication Date
JP2008066945A true JP2008066945A (ja) 2008-03-21
JP4664257B2 JP4664257B2 (ja) 2011-04-06

Family

ID=39153324

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006241287A Expired - Fee Related JP4664257B2 (ja) 2006-09-06 2006-09-06 攻撃検出システム及び攻撃検出方法

Country Status (2)

Country Link
US (1) US7979575B2 (ja)
JP (1) JP4664257B2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018500830A (ja) * 2014-12-22 2018-01-11 ホアウェイ・テクノロジーズ・カンパニー・リミテッド 攻撃データパケット処理のための方法、装置、及びシステム

Families Citing this family (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8347383B2 (en) * 2007-09-28 2013-01-01 Nippon Telegraph And Telephone Corporation Network monitoring apparatus, network monitoring method, and network monitoring program
US8369343B2 (en) * 2008-06-03 2013-02-05 Microsoft Corporation Device virtualization
JP2011015095A (ja) * 2009-06-30 2011-01-20 Fujitsu Ltd 通信装置、アドレス設定方法およびアドレス設定プログラム
CN102045307B (zh) * 2009-10-10 2014-08-13 中兴通讯股份有限公司 一种网络设备管理的方法及相应的网络系统
KR101109669B1 (ko) * 2010-04-28 2012-02-08 한국전자통신연구원 좀비 식별을 위한 가상 서버 및 방법과, 가상 서버에 기반하여 좀비 정보를 통합 관리하기 위한 싱크홀 서버 및 방법
US8891532B1 (en) * 2011-05-17 2014-11-18 Hitachi Data Systems Engineering UK Limited System and method for conveying the reason for TCP reset in machine-readable form
CN103051677A (zh) * 2012-11-30 2013-04-17 中国电信股份有限公司云计算分公司 网络服务能力的提供方法及设备
US10165004B1 (en) 2015-03-18 2018-12-25 Cequence Security, Inc. Passive detection of forged web browsers
CN104811383B (zh) * 2015-03-19 2018-01-09 新华三技术有限公司 一种报文转发方法和设备
US11418520B2 (en) * 2015-06-15 2022-08-16 Cequence Security, Inc. Passive security analysis with inline active security device
US9787641B2 (en) 2015-06-30 2017-10-10 Nicira, Inc. Firewall rule management
US11018970B2 (en) 2016-10-31 2021-05-25 Nicira, Inc. Monitoring resource consumption for distributed services
US10567440B2 (en) * 2016-12-16 2020-02-18 Nicira, Inc. Providing application visibility for micro-segmentation of a network deployment
US11258681B2 (en) 2016-12-16 2022-02-22 Nicira, Inc. Application assessment and visibility for micro-segmentation of a network deployment
US11233809B2 (en) * 2017-03-03 2022-01-25 Nippon Telegrape And Telephone Corporation Learning device, relearning necessity determination method, and relearning necessity determination program
US10742673B2 (en) 2017-12-08 2020-08-11 Nicira, Inc. Tracking the dynamics of application-centric clusters in a virtualized datacenter
US11296960B2 (en) 2018-03-08 2022-04-05 Nicira, Inc. Monitoring distributed applications
US11176157B2 (en) 2019-07-23 2021-11-16 Vmware, Inc. Using keys to aggregate flows at appliance
US11288256B2 (en) 2019-07-23 2022-03-29 Vmware, Inc. Dynamically providing keys to host for flow aggregation
US11743135B2 (en) 2019-07-23 2023-08-29 Vmware, Inc. Presenting data regarding grouped flows
US10911335B1 (en) 2019-07-23 2021-02-02 Vmware, Inc. Anomaly detection on groups of flows
US11340931B2 (en) 2019-07-23 2022-05-24 Vmware, Inc. Recommendation generation based on selection of selectable elements of visual representation
US11188570B2 (en) 2019-07-23 2021-11-30 Vmware, Inc. Using keys to aggregate flow attributes at host
US11349876B2 (en) 2019-07-23 2022-05-31 Vmware, Inc. Security policy recommendation generation
US11140090B2 (en) 2019-07-23 2021-10-05 Vmware, Inc. Analyzing flow group attributes using configuration tags
US11398987B2 (en) 2019-07-23 2022-07-26 Vmware, Inc. Host-based flow aggregation
US11436075B2 (en) 2019-07-23 2022-09-06 Vmware, Inc. Offloading anomaly detection from server to host
US11588854B2 (en) 2019-12-19 2023-02-21 Vmware, Inc. User interface for defining security groups
US11321213B2 (en) 2020-01-16 2022-05-03 Vmware, Inc. Correlation key used to correlate flow and con text data
US11991187B2 (en) 2021-01-22 2024-05-21 VMware LLC Security threat detection based on network flow analysis
US11785032B2 (en) 2021-01-22 2023-10-10 Vmware, Inc. Security threat detection based on network flow analysis
US11997120B2 (en) 2021-07-09 2024-05-28 VMware LLC Detecting threats to datacenter based on analysis of anomalous events
US11831667B2 (en) 2021-07-09 2023-11-28 Vmware, Inc. Identification of time-ordered sets of connections to identify threats to a datacenter
US11792151B2 (en) 2021-10-21 2023-10-17 Vmware, Inc. Detection of threats based on responses to name resolution requests
US11683286B2 (en) 2021-11-18 2023-06-20 Cisco Technology, Inc. Anonymizing server-side addresses

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003348113A (ja) * 2002-05-22 2003-12-05 Takeshi Hosohara スイッチおよびlan
JP2004282364A (ja) * 2003-03-14 2004-10-07 Ntt Data Corp パケット追跡方法およびパケット追跡プログラム
JP2005204027A (ja) * 2004-01-15 2005-07-28 Nippon Telegr & Teleph Corp <Ntt> パケット転送装置、パケット転送方法、プログラムおよび記録媒体
JP2006217039A (ja) * 2005-02-01 2006-08-17 Canon Inc ネットワーク中継装置

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6725378B1 (en) * 1998-04-15 2004-04-20 Purdue Research Foundation Network protection for denial of service attacks
US7664963B2 (en) * 2002-11-04 2010-02-16 Riverbed Technology, Inc. Data collectors in connection-based intrusion detection
DE102004016582A1 (de) 2004-03-31 2005-10-27 Nec Europe Ltd. Verfahren zur Überwachung und zum Schutz eines privaten Netzwerks vor Angriffen aus einem öffentlichen Netz
EP1798890B1 (en) * 2005-12-15 2009-03-18 Nokia Corporation Methods, device and computer program product for maintaining mapping relationship

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003348113A (ja) * 2002-05-22 2003-12-05 Takeshi Hosohara スイッチおよびlan
JP2004282364A (ja) * 2003-03-14 2004-10-07 Ntt Data Corp パケット追跡方法およびパケット追跡プログラム
JP2005204027A (ja) * 2004-01-15 2005-07-28 Nippon Telegr & Teleph Corp <Ntt> パケット転送装置、パケット転送方法、プログラムおよび記録媒体
JP2006217039A (ja) * 2005-02-01 2006-08-17 Canon Inc ネットワーク中継装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018500830A (ja) * 2014-12-22 2018-01-11 ホアウェイ・テクノロジーズ・カンパニー・リミテッド 攻撃データパケット処理のための方法、装置、及びシステム
US10742682B2 (en) 2014-12-22 2020-08-11 Huawei Technologies Co., Ltd. Attack data packet processing method, apparatus, and system

Also Published As

Publication number Publication date
US7979575B2 (en) 2011-07-12
US20080059596A1 (en) 2008-03-06
JP4664257B2 (ja) 2011-04-06

Similar Documents

Publication Publication Date Title
JP4664257B2 (ja) 攻撃検出システム及び攻撃検出方法
US10033696B1 (en) Identifying applications for intrusion detection systems
US9634943B2 (en) Transparent provisioning of services over a network
EP2612488B1 (en) Detecting botnets
US7020783B2 (en) Method and system for overcoming denial of service attacks
CN105099821B (zh) 基于云的虚拟环境下流量监控的方法和装置
JP5826920B2 (ja) 遮断サーバを用いたスプーフィング攻撃に対する防御方法
US7474655B2 (en) Restricting communication service
JP4829982B2 (ja) ピアツーピア通信の検出及び制御
US20110154477A1 (en) Dynamic content-based routing
IL151522A (en) Firewall with fast filtering of information packets
US11005813B2 (en) Systems and methods for modification of p0f signatures in network packets
KR101281160B1 (ko) 하이퍼 텍스터 전송규약 요청 정보 추출을 이용한침입방지시스템 및 그를 이용한 유알엘 차단방법
KR20200109875A (ko) 유해 ip 판단 방법
US20230367875A1 (en) Method for processing traffic in protection device, and protection device
EP1294141A2 (en) Method and apparatus for transferring packets in network
CN110581843B (zh) 一种拟态Web网关多应用流量定向分配方法
EP2204953A1 (en) Method, apparatus and system for realizing dynamic correlation of control plane traffic rate
JP2012014437A (ja) データ転送装置及びアクセス解析方法
JP2006222662A (ja) 不正アクセス防止システム、不正アクセス防止方法、および不正アクセス防止プログラム
JP2006165877A (ja) 通信システム、通信方法および通信プログラム
JP3917546B2 (ja) ネットワーク攻撃防止方法、ネットワーク攻撃防止装置、ネットワーク攻撃防止プログラム及びそのプログラムを記録した記録媒体
KR100520102B1 (ko) 네트워크 유해 트래픽 방역 시스템 및 그 방법
CN116723020A (zh) 网络服务模拟方法、装置、电子设备及存储介质
JP2005117100A (ja) 侵入検知システムおよびトラヒック集約装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20090512

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20101213

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: 20101228

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110106

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140114

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees