JP2012029144A - パケット監視システム - Google Patents

パケット監視システム Download PDF

Info

Publication number
JP2012029144A
JP2012029144A JP2010167141A JP2010167141A JP2012029144A JP 2012029144 A JP2012029144 A JP 2012029144A JP 2010167141 A JP2010167141 A JP 2010167141A JP 2010167141 A JP2010167141 A JP 2010167141A JP 2012029144 A JP2012029144 A JP 2012029144A
Authority
JP
Japan
Prior art keywords
packet
packets
tcp
unit
monitoring system
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.)
Pending
Application number
JP2010167141A
Other languages
English (en)
Inventor
Keisuke Takemori
敬祐 竹森
Toshiki Matsui
利樹 松井
Makoto Nishikawa
真 西川
Kei Amano
圭 天野
Yuji Sawada
裕史 澤田
Narihito Fujita
業仁 藤田
Katsuhiro Kozuki
勝博 上月
Kenji Koga
賢児 古賀
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.)
KDDI Corp
Original Assignee
KDDI Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by KDDI Corp filed Critical KDDI Corp
Priority to JP2010167141A priority Critical patent/JP2012029144A/ja
Publication of JP2012029144A publication Critical patent/JP2012029144A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

【課題】パケットの監視に係る負荷を低減することができるパケット監視システムを提供する。
【解決手段】端末3は、インターネット7から不要なパケットを受信した場合に、受信したパケットの種類毎に固定された内容の応答パケットをインターネット7へ送信する。パケット監視装置6は、注目ネットワーク2からインターネット7へ送信されるパケットを収集し、収集したパケットのうち、上記の応答パケットに基づくカウントを行う。
【選択図】図1

Description

本発明は、通信経路上でパケットを監視するパケット監視システムに関する。
インターネット上の未使用のIPアドレス空間はダークネットと呼ばれる。ダークネットに到来するパケットを観測することで、インターネットを経由して感染を広めるマルウェアの活動傾向などを把握することができる。これまで、ダークネットに対するパケットの監視と解析に関する技術が提案されている(例えば、非特許文献1,2参照)。ダークネットには端末が存在せず、外部からダークネットに到来するInbound方向のパケットに対して、ダークネットから外部へ送信されるOutbound方向の応答パケットがない。このため、Inbound方向のパケットを監視することによって、マルウェアによる攻撃を受けやすいIPアドレスやポート番号を容易に知ることができる。
山形昌也,村田康裕,井上大介,衛藤将史,中尾康二,"変化点検出システムにおける全ポートアクセス観測機構の実装とダークネットの観測事例に関する考察",電子情報通信学会,SICS2009,2E1-2,2009年1月 中里純二,島村隼平,衛藤将史,井上大介,中尾康二,"パケットヘッダの特徴に基づいたダークネットトラフィックのパケット生成手法の分類",信学技報,vol. 109,no. 285,ICSS2009-61,pp.43-48,2009年11月
端末が存在しないダークネットに到来するパケットは、攻撃による不要なパケットであることが分かるが、端末が存在する実ネットワークに到来するパケットが不要なパケットであるか否かは、端末上で起動しているアプリケーションに依存する。また、実ネットワークでは、外部から監視対象のネットワークに到来するInbound方向のパケットだけでなく、監視対象のネットワークから外部へ送信されるOutbound方向のパケットもある。このため、以下で説明するように、Inbound方向およびOutbound方向のパケットの監視が必要である。多数の端末が収容されたネットワークにおいてInbound方向およびOutbound方向のパケットを監視する場合、監視対象のネットワークと外部とが接続する位置等の1箇所にパケット監視装置を設け、効率的にパケットの監視を行うことが望ましい。
端末が、自身で起動しているアプリケーションにとって不要なパケットに対する応答パケットを送信すれば、Outbound方向の応答パケットを監視することによって、不要なパケットが監視対象のネットワークに到来していたことを検知することは可能である。しかし、特定のサービスに係るパケット以外のパケットを棄却するファイアウォールが監視対象のネットワーク内に設置されている場合、または端末上で起動しているアプリケーションが提供するサービスに係るパケット以外のパケットを棄却する設定が端末上でなされている場合、応答パケットが送信されないため、Outbound方向のパケットを監視するだけでは、不要なパケットが監視対象のネットワークに到来していたことを検知することができない。
このため、パケット監視装置では、送受信のIPアドレスをペアとした通信セッション単位でInbound方向およびOutbound方向のパケットを監視することが必要になる。このような監視により、Inbound方向のパケットに対応するOutbound方向の応答パケットが存在しなかった場合に、不要なパケットが監視対象のネットワークに到来していたことを検知することができる。しかし、送受信のIPアドレスの数が膨大であるため、この方法では、通信セッション単位でInbound方向およびOutbound方向のパケットを監視するためのCPUやメモリの負荷が増大する。
本発明は、上述した課題に鑑みてなされたものであって、パケットの監視に係る負荷を低減することができるパケット監視システムを提供することを目的とする。
本発明は、上記の課題を解決するためになされたもので、監視対象のネットワーク内の複数の通信端末と、前記監視対象のネットワークから外部へ送信されるパケットを監視するパケット監視装置とを有するパケット監視システムであって、前記複数の通信端末は、パケットを受信する受信部と、前記監視対象のネットワークの外部から特定種類のパケットを受信した場合に、受信したパケットの種類毎に固定された内容の応答パケットを前記監視対象のネットワークの外部へ送信する送信部と、を有し、前記パケット監視装置は、前記監視対象のネットワークから外部へ送信されるパケットを収集する収集部と、収集されたパケットのうち前記応答パケットに基づくカウントを行うカウント部と、を有し、前記監視対象のネットワーク内の各装置において、前記特定種類のパケットを棄却する設定がなされていないことを特徴とするパケット監視システムである。
また、本発明のパケット監視システムにおいて、前記収集部によるパケットの収集と、前記カウント部によるカウントとが交互に行われることを特徴とする。
また、本発明のパケット監視システムにおいて、前記カウント部は、前記応答パケットであるTCP-RST-ACKパケットの発信元IPアドレス毎に前記TCP-RST-ACKパケットの数をカウントすることを特徴とする。
また、本発明のパケット監視システムにおいて、前記カウント部は、前記応答パケットであるTCPのICMP unreachableパケットの発信元TCPポート番号毎に前記TCPのICMP unreachableパケットの数をカウントすることを特徴とする。
また、本発明のパケット監視システムにおいて、前記カウント部は、前記応答パケットであるUDPのICMP unreachableパケットの発信元UDPポート番号毎に前記UDPのICMP unreachableパケットの数をカウントすることを特徴とする。
また、本発明のパケット監視システムにおいて、前記カウント部は、前記応答パケットであるICMP echo replyパケットの数をカウントすることを特徴とする。
本発明によれば、外部から監視対象のネットワークに特定種類のパケットが到来すると、そのパケットの種類毎に固定された内容の応答パケットが監視対象のネットワークから外部へ送信され、パケット監視装置は、その応答パケットに基づくカウントを行う。これによって、パケット監視装置は監視対象のネットワークから外部へのパケットのみを監視すればよくなるので、パケットの監視に係る負荷を低減することができる。
本発明の一実施形態によるパケット監視システムの構成を示す構成図である。 本発明の一実施形態によるパケット監視システムが備える端末の構成を示すブロック図である。 本発明の一実施形態によるパケット監視システムが備えるパケット監視装置の構成を示すブロック図である。 本発明の一実施形態によるパケット監視システムが備えるパケット監視装置の動作の手順を示すフローチャートである。 本発明の一実施形態によるパケット監視システムが備えるパケット監視装置の動作のシーケンスを示すシーケンス図である。
以下、図面を参照し、本発明の実施形態を説明する。図1は、本発明の一実施形態によるパケット監視システムの構成を示している。図1に示すパケット監視システム1は、監視対象である注目ネットワーク2内の複数の端末3と、ゲートウェイ4と、光タップ5と、パケット監視装置6とを有する。
端末3は、パケットの送受信を行う通信端末である。ゲートウェイ4は、注目ネットワーク2とインターネット7とを接続する。光タップ5は、通信トラフィックを分岐(ミラーリング)して出力することが可能である。光タップ5に入力された通信トラフィックは光信号として光ファイバ内を伝送し、伝送経路の途中に設けられたハーフミラーで2つの経路に分岐する。本実施形態では、注目ネットワーク2からインターネット7へのOutbound方向の通信トラフィックが分岐され、一方の通信トラフィックはインターネット7へ出力され、他方の通信トラフィック(インターネット7への通信トラフィックと同一)はパケット監視装置6へ出力される。パケット監視装置6は、光タップ5から出力されたOutbound方向のパケットを監視する。
本実施形態の注目ネットワーク2内では、パケットの棄却を行うファイアウォールが設置されていない(あるいはファイアウォール機能がOFFに設定されていてもよい)。したがって、注目ネットワーク2に到来したパケットはいずれかの端末3で受信される。
次に、端末3の構成および動作を説明する。図2は端末3の構成を示している。図2に示すように、端末3は、アプリケーション30と、制御部31と、通信インタフェース部32とを有する。
アプリケーション30は、アプリケーションの処理として規定された各種処理を実行する。図2では、複数種類のアプリケーション30が端末3上で起動している状態を示しているが、起動しているアプリケーションは端末3毎に異なる。
制御部31は端末3内の各部を制御する。本実施形態では、制御部31が有する各種制御機能のうち、パケット制御機能についてのみ説明する。制御部31は、アプリケーションインタフェース部31aとパケットフィルタリング部31bとを有する。アプリケーションインタフェース部31aは、アプリケーション30との間でパケットの受け渡しを行う。パケットフィルタリング部31bは、パケット制御用のiptablesを備えており、端末3で受信されたパケットのフィルタリングを行う。アプリケーションインタフェース部31aとパケットフィルタリング部31bの設定は全ての端末3で同一である。通信インタフェース部32は、例えばネットワークインタフェースカード(NIC)で構成され、外部と通信を行う。端末3は、情報を表示する表示部や、ユーザによる操作を受け付ける操作部等を有していてもよい。
パケット受信時の端末3の動作を説明する。通信インタフェース部32は、パケットを受信すると、受信したパケットを制御部31へ出力する。パケットフィルタリング部31bは、iptablesの設定内容に基づいて、通信インタフェース部32から出力されたパケットのフィルタリングを行う。iptablesの設定によって、特定のサービスに係るパケット(すなわち、特定のポート番号をDestination Portとするパケット)を棄却することが可能である。しかし、本実施形態では、iptablesによるパケットの棄却設定が予め全て解除されており、通信インタフェース部32から出力されたパケットはパケットフィルタリング部31bでは棄却されないものとする。
上記のように、通信インタフェース部32から出力された全てのパケットはパケットフィルタリング部31bを通過する。アプリケーションインタフェース部31aは、パケットフィルタリング部31bを通過したパケットの振り分けを行う。具体的には、パケットのDestination Portによって指定されるポート番号が、いずれかのアプリケーション30が使用しているポート番号と一致する場合、アプリケーションインタフェース部31aはそのアプリケーション30にパケットの内容を通知する。また、パケットのDestination Portによって指定されるポート番号が、どのアプリケーション30が使用しているポート番号とも一致しない場合、アプリケーションインタフェース部31aは、端末3で受信されたパケットが不要なパケットであると判断する。
アプリケーションインタフェース部31aは、端末3で受信されたパケットが不要なパケットであると判断した場合、パケットの種類に応じた内容の応答パケットを生成する。本実施形態では、以下の4種類の応答パケットが生成される。
(1)Inbound Port/TCP-SYNパケットに対するOutbound Port/TCP-RST-ACKパケット
TCPのポート番号を指定したTCP-SYNパケットが不要なパケットであると判断された場合、TCP-SYNパケットが指定するTCPのポート番号と同一のポート番号を指定したTCP-RST-ACKパケットが生成される。
(2)Inbound Port/TCP-RST-ACKパケットに対するOutbound ICMP unreachable(Port/TCP)パケット
インターネット7側の端末が、送信元のIPアドレスを注目ネットワーク2内の端末3のIPアドレスに詐称してインターネット7側の他の端末へ攻撃のためのTCP-SYNパケットを送信することがある。このTCP-SYNパケットを受信した端末は、注目ネットワーク2内の端末3のIPアドレス宛てにTCP-RST-ACKパケットを送信する。このTCP-RST-ACKパケットを受信した端末3では、TCP-RST-ACKパケットが不要なパケットであると判断され、TCP-RST-ACKパケットが指定するTCPのポート番号を指定したICMP unreachableパケットが生成される。
(3)Inbound Port/UDPパケットに対するOutbound ICMP unreachable(Port/UDP)パケット
UDPのポート番号を指定したUDPパケットが不要なパケットであると判断された場合、UDPパケットが指定するUDPのポート番号と同一のポート番号を指定したICMP unreachableパケットが生成される。
(4)Inbound ICMPパケットに対するOutbound ICMP echo replyパケット
ネットワーク上の端末の存在を確かめるpingコマンド等の実行時に送信されたICMPパケットは端末3では不要なパケットであると判断され、ICMP echo replyパケットが生成される。
アプリケーションインタフェース部31aは、生成した応答パケットを通信インタフェース部32へ出力する。通信インタフェース部32は応答パケットを送信する。本実施形態では、全ての端末3のアプリケーションインタフェース部31aが同一の動作を行うように予め設定されているため、不要なパケットに対する応答パケットは上記の4種類のパケットのいずれかとなる。
次に、パケット監視装置6の構成および動作を説明する。図3はパケット監視装置6の構成を示している。図3に示すように、パケット監視装置6は、パケット収集部60と、記憶部61と、パケット解析部62と、制御部63とを有する。
パケット収集部60は、光タップ5から出力されたパケットを収集し、記憶部61に格納する。記憶部61はハードディスクドライブ等の記録媒体である。パケット解析部62は、記憶部61からパケットを読み出し、パケットの内容を解析する。制御部63はパケット監視装置6内の各部を制御する。
パケット監視装置6の動作を説明する。図4はパケット監視装置6の動作の手順を示している。パケット監視装置6が動作を開始すると、制御部63は、パケットの収集時間を計測するためのタイマをクリア(初期化)する(ステップS100)。続いて、パケット収集部60は、光タップ5から出力されたパケットを受信し、記憶部61に格納する(ステップS105)。
続いて、制御部63は、タイマが計測した時間が所定時間を超えたか否かを判定する(ステップS110)。計測時間が所定時間を超えていない場合、処理はステップS105に戻り、パケットの収集が継続される。
計測時間が所定時間を超えた場合、パケット解析部62は記憶部61から未解析のパケットを読み出し、パケットを解析する(ステップS115)。具体的には、まず、パケット解析部62はパケットの種類を判定する。パケットが、前述した(1)〜(4)のいずれかの応答パケットである場合、パケット解析部62は、応答パケットに基づくカウントを行う。
パケット解析部62は、発信元のIPアドレスであるSource IPアドレス毎のPort/TCP-RST-ACKパケット数、発信元のTCPポート番号であるSource Port/TCP毎のICMP unreachable(Port/TCP)パケット数、発信元のUDPポート番号であるSource Port/UDP毎のICMP unreachable(Port/UDP)パケット数、およびICMP echo replyパケット数をカウントする。パケット解析部62は、これら4種類の数のカウントを個別に行うためのテーブルを有している。
Source IPアドレス毎のPort/TCP-RST-ACKパケット数をカウントするためのテーブルは、Source IPアドレスとカウント値が関連付けられたエントリ(行)を複数個有している。パケットから検出されるSource IPアドレスの数は数百万オーダであることを想定しており、エントリ数もこれと同等となる。パケット解析部62は、記憶部61から読み出したパケットがPort/TCP-RST-ACKパケットであり、そのSource IPアドレスが既にテーブルに登録されている場合、そのSource IPアドレスのカウント値を1増加する。また、パケット解析部62は、記憶部61から読み出したパケットがPort/TCP-RST-ACKパケットであり、そのSource IPアドレスがテーブルに登録されていない場合、テーブルにそのSource IPアドレスのエントリ(行)を追加し、そのSource IPアドレスのカウント値を1とする。このようなカウントを行うことによって、Port/TCP-SYNパケットによる攻撃を受けやすいIPアドレスを知るための情報を生成することができる。
Source Port/TCP毎のICMP unreachable(Port/TCP)パケット数をカウントするためのテーブルは、Source Port/TCPとカウント値が関連付けられたエントリ(行)を複数個有している。Source Port/TCPの数は約6万5千個であり、エントリ数もこれと同等となる。パケット解析部62は、記憶部61から読み出したパケットがICMP unreachable(Port/TCP)パケットであり、そのSource Port/TCPが既にテーブルに登録されている場合、そのSource Port/TCPのカウント値を1増加する。また、パケット解析部62は、記憶部61から読み出したパケットがICMP unreachable(Port/TCP)パケットであり、そのSource Port/TCPがテーブルに登録されていない場合、テーブルにそのSource Port/TCPのエントリ(行)を追加し、そのSource Port/TCPのカウント値を1とする。このようなカウントを行うことによって、Port/TCP-RST-ACKパケットによる攻撃を受けやすいTCPのポート番号を知るための情報を生成することができる。
Source Port/UDP毎のICMP unreachable(Port/UDP)パケット数をカウントするためのテーブルは、Source Port/TCP毎のICMP unreachable(Port/TCP)パケットをカウントするためのテーブルと同様であり、カウントの方法も同様である。Source Port/UDP毎のICMP unreachable(Port/UDP)パケット数をカウントすることによって、Port/UDPパケットによる攻撃を受けやすいUDPのポート番号を知るための情報を生成することができる。
ICMP echo replyパケット数をカウントするためのテーブルは、カウント値のみを有する1つのエントリ(行)を有している。パケット解析部62は、ICMP echo replyパケットを検出した場合、カウント値を1増加する。このようなカウントを行うことによって、ping攻撃等の発生の状況を知るための情報を生成することができる。
上記のカウントを行ったパケット解析部62は、カウント結果を記憶部61に格納する。記憶部61に格納されたカウント結果は、適宜、表示装置等に出力することが可能である。
ステップS115に続いて、制御部63は、記憶部61に格納されているパケットの解析が終了したか否かを判定する(ステップS120)。解析を行っていないパケットが記憶部61に残っている場合、処理はステップS115に戻り、パケットの解析が継続される。また、記憶部61に格納されている全てのパケットの解析が終了している場合、処理はステップS100に戻り、パケットの収集が再開される。
本実施形態では、注目ネットワーク2内にファイアウォールが設置されておらず、また、全ての端末3において、iptablesによるパケットの棄却設定が解除されている。このため、注目ネットワーク2に到来した不要なパケットは端末3によって受信され、端末3は、不要なパケットの種類毎に固定された内容の応答パケットを必ず送信することになる。したがって、Inbound方向の不要なパケットとOutbound方向の応答パケットとが一対一で対応することになる。よって、パケット監視装置6はOutbound方向についてのみパケットの監視を行えばよいので、パケットの監視に係る負荷を低減することができる。
図5は、図4に示した手順に従った動作のシーケンスを示している。図5に示すように、所定の長さの期間T1でパケットの収集が行われた後、期間T2でパケットの解析が行われる。期間T1で収集されたパケットの解析が終了すると、所定の長さの期間T3で再度パケットの収集が行われた後、期間T4でパケットの解析が行われる。以降はこの繰り返しとなる。
光回線のように高速な通信回線上の1箇所で大量のパケットを収集する場合、収集したパケットを記憶装置に保存するためのバスアクセスが頻繁に行われるため、このバスアクセスと、解析用のパケットを記憶装置から読み出すためのバスアクセスとが競合してしまう。このため、高速な通信回線を伝送するパケットの一部を収集できなかったり、パケットの解析処理が遅延したりする。
しかし、本実施形態では、上記のように、パケットの収集とパケットの解析とが同一のタイミングでは行われず、排他的に(交互に)行われるので、収集したパケットを記憶部61に保存するためのバスアクセスと、解析用のパケットを記憶部61から読み出すためのバスアクセスとが競合しなくなる。これによって、所定期間内に高速な通信回線を伝送する全てのパケットを収集し、その解析を行うことができる。
上述したように、本実施形態によれば、パケット監視装置6がOutbound方向のパケットのみを監視することによって、Inbound方向およびOutbound方向のパケットを監視する手法よりも、パケットの監視に係る負荷を低減することができる。また、パケットの収集とパケットの解析とを排他的に(交互に)行うことによって、所定期間内に高速な通信回線を伝送する全てのパケットを収集し、解析を行うことができる。さらに、パラメータ毎にパケット数をカウントすることによって、攻撃の状況を把握するための情報を生成することができる。
なお、パケットの解析結果に基づいてパケットフィルタリングを行ってもよい。例えば、ファイアウォール機能を有する装置において、解析結果を得るまではファイアウォール機能をOFFにし、解析結果を得た後は解析結果に基づいてパケットフィルタリングを行うようにファイアウォール機能をONにしてもよい。
以上、図面を参照して本発明の実施形態について詳述してきたが、具体的な構成は上記の実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等も含まれる。
1・・・パケット監視システム、2・・・注目ネットワーク、3・・・端末、4・・・ゲートウェイ、5・・・光タップ、6・・・パケット監視装置、7・・・インターネット、30・・・アプリケーション、31・・・制御部、31a・・・アプリケーションインタフェース部、31b・・・パケットフィルタリング部、32・・・通信インタフェース部、60・・・パケット収集部、61・・・記憶部、62・・・パケット解析部、63・・・制御部

Claims (6)

  1. 監視対象のネットワーク内の複数の通信端末と、前記監視対象のネットワークから外部へ送信されるパケットを監視するパケット監視装置とを有するパケット監視システムであって、
    前記複数の通信端末は、
    パケットを受信する受信部と、
    前記監視対象のネットワークの外部から特定種類のパケットを受信した場合に、受信したパケットの種類毎に固定された内容の応答パケットを前記監視対象のネットワークの外部へ送信する送信部と、
    を有し、
    前記パケット監視装置は、
    前記監視対象のネットワークから外部へ送信されるパケットを収集する収集部と、
    収集されたパケットのうち前記応答パケットに基づくカウントを行うカウント部と、
    を有し、
    前記監視対象のネットワーク内の各装置において、前記特定種類のパケットを棄却する設定がなされていない
    ことを特徴とするパケット監視システム。
  2. 前記収集部によるパケットの収集と、前記カウント部によるカウントとが交互に行われることを特徴とする請求項1に記載のパケット監視システム。
  3. 前記カウント部は、前記応答パケットであるTCP-RST-ACKパケットの発信元IPアドレス毎に前記TCP-RST-ACKパケットの数をカウントすることを特徴とする請求項1または請求項2に記載のパケット監視システム。
  4. 前記カウント部は、前記応答パケットであるTCPのICMP unreachableパケットの発信元TCPポート番号毎に前記TCPのICMP unreachableパケットの数をカウントすることを特徴とする請求項1〜請求項3のいずれか一項に記載のパケット監視システム。
  5. 前記カウント部は、前記応答パケットであるUDPのICMP unreachableパケットの発信元UDPポート番号毎に前記UDPのICMP unreachableパケットの数をカウントすることを特徴とする請求項1〜請求項3のいずれか一項に記載のパケット監視システム。
  6. 前記カウント部は、前記応答パケットであるICMP echo replyパケットの数をカウントすることを特徴とする請求項1〜請求項4のいずれか一項に記載のパケット監視システム。
JP2010167141A 2010-07-26 2010-07-26 パケット監視システム Pending JP2012029144A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2010167141A JP2012029144A (ja) 2010-07-26 2010-07-26 パケット監視システム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010167141A JP2012029144A (ja) 2010-07-26 2010-07-26 パケット監視システム

Publications (1)

Publication Number Publication Date
JP2012029144A true JP2012029144A (ja) 2012-02-09

Family

ID=45781540

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010167141A Pending JP2012029144A (ja) 2010-07-26 2010-07-26 パケット監視システム

Country Status (1)

Country Link
JP (1) JP2012029144A (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014086927A (ja) * 2012-10-24 2014-05-12 Fujitsu Ltd 情報処理方法、プログラム、情報処理装置、及び情報処理システム
JP2022031741A (ja) * 2018-02-13 2022-02-22 パロ アルト ネットワークス,インコーポレイテッド 次世代ファイアウォールを用いたトランスポート層の信号安全性

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014086927A (ja) * 2012-10-24 2014-05-12 Fujitsu Ltd 情報処理方法、プログラム、情報処理装置、及び情報処理システム
JP2022031741A (ja) * 2018-02-13 2022-02-22 パロ アルト ネットワークス,インコーポレイテッド 次世代ファイアウォールを用いたトランスポート層の信号安全性
JP7340582B2 (ja) 2018-02-13 2023-09-07 パロ アルト ネットワークス,インコーポレイテッド 次世代ファイアウォールを用いたトランスポート層の信号安全性

Similar Documents

Publication Publication Date Title
Svoboda et al. Network monitoring approaches: An overview
US10397260B2 (en) Network system
EP1742416B1 (en) Method, computer readable medium and system for analyzing and management of application traffic on networks
Qadeer et al. Network traffic analysis and intrusion detection using packet sniffer
US10129115B2 (en) Method and system for network monitoring using signature packets
CN101026505B (zh) 用于监控通信网络中的恶意流量的方法和装置
US9306816B2 (en) System and method for replaying network captures
Kekely et al. Software defined monitoring of application protocols
Hofstede et al. Towards real-time intrusion detection for NetFlow and IPFIX
Asrodia et al. Network traffic analysis using packet sniffer
JP5660198B2 (ja) ネットワークシステム、及びスイッチ方法
EP2509262B1 (en) Unaddressed device communication from within an MPLS network
JP2009231890A (ja) パケット中継装置およびトラフィックモニタシステム
Balas et al. SciPass: a 100Gbps capable secure Science DMZ using OpenFlow and Bro
Shirali-Shahreza et al. Empowering software defined network controller with packet-level information
Dubendorfer et al. A framework for real-time worm attack detection and backbone monitoring
US8717925B2 (en) Testing TCP connection rate
JP2012029144A (ja) パケット監視システム
JP2009077136A (ja) トラヒック情報提供装置、トラヒック情報取得装置、トラヒック情報収集システム、トラヒック情報提供プログラム、トラヒック情報取得プログラム及びトラヒック情報収集方法
US10547560B1 (en) Monitoring network communications queues
CN108156052B (zh) 一种设备稳定性测试的方法及系统
Visoottiviseth et al. REFLO: Reactive firewall system with OpenFlow and flow monitoring system
WO2022121454A1 (zh) 一种流表发送方法及相关装置
Reichle et al. Analysis and detection of DDoS attacks in the internet backbone using netflow logs
Kobayashi et al. Method of measuring VoIP traffic fluctuation with selective sFlow