段階的通信制限システムを実現する
Openflow コントローラとスイッチの試作
M2012MM041 鈴木 雅喬
指導教員：河野 浩之

1

はじめに

GK は図 1 のように内部ネットワークと外部ネットワー
クを IP アドレス無しでブリッジとして動作させ，通過時に通信を制限する．IP アドレスをもたないので，攻撃対象にならないという利点がある．IDS を起動させた PCにパケットをミラーし，ネットワーク上で流れるパケッ
トを監視し，検知した攻撃の種類や発信元の IP などの情報を GK に渡し，これらの情報に基づいて GK がリアルタイムに通信制限をする．外部ネットワークから内部ネットワークへの攻撃を制限することを目的としているが，その逆の攻撃も同時に制限することができる．

近年，様々なベンダーによって多種多様なクラウドサー
ビスが提供されている．その中で，仮想化する端末の増加や，増大するトラフィックの管理，セキュリティ確保など様々な課題を抱えている．それらを解消する手段として近年，Software Deﬁned Network(以下，SDN) という技術が注目されている．OpenFlow[1] は，SDN の中の代表的なもので，米スタンフォード大学を中心とし，2008 年のOpenFlow: Enabling Innovation in Campus Networks
にて提案された技術である．
本研究では，増大するトラフィックの対策として，SDN 3 提案する段階的通信制限システムの概要の技術の一つである Openﬂow を利用し，研究室で開発を
本研究では Openﬂow を利用して図 2 のネットワークしている段階的通信制限システム (以下，GK)[2][3][4] の構成の GK を実現させる．Openﬂow は通信機器の制御実現をする．研究では Open vSwitch というオープンソーを行うコントローラと実際にパケット転送をするスイッスのソフトウェアスイッチを使用する．Open vSwitch はチで構成されている．コントローラに IDS のアラートやOpenﬂow に対応したスイッチとしての動作も可能であり，スイッチによって収集されるパケットの統計情報を元に，Openﬂow の研究やコントローラの開発などに用いら入れ
Openﬂow スイッチにフローテーブルにフロー書き込むこている．Open vSwitch に遅延などを模倣することが可とで，GK を実現する．
能である netem を組み合わせることで GK を実現するスイッチを実装する．Openﬂow コントローラを開発するさいに使用するフレームワークには Trema を用いる．通信異常を検知する IDS には Snort を使用する．
本研究の実験では，DoS 攻撃時の通信制限効果の検証，攻撃ホストに通信制限を掛けることでのスループットの変化，本研究で作成システムを用いて向上したスループットなどを調べる．実験には LOIC や apache bench などを用いてスループットの測定や疑似攻撃をする．本研究に
図 2 新段階的通信制限システムのネットワーク構成
よって Openﬂow を用いてシステムを構築することにより，ネットワークの構成の変更が容易になり，煩雑化を防ぐことが予想できる．また，同じパケットに対して複 3.1 Openflow の概要
数の通信制限を同時に掛けることが可能になる．加えて， Openﬂow のネットワーク機器は従来のネットワーク機本研究にて作成するシステムは全てオープンソースソフ 器と異なり，制御部分と転送部分を分離したアーキテクトウェアで構築されるため，安価にシステム構築するこ チャである．転送部分を Openﬂow スイッチ，制御部分をとが期待できる．
Openﬂow コントローラ，このふたつの間のやりとりを定2

既存システムの概要
本節では，既存の GK について説明する．

義する Openﬂow プロトコルから成り立っている．
Openﬂow スイッチはフローテーブルに基づいてパケットの参照と転送を実行する．Openﬂow スイッチは DataPath
ID という 64bit の識別子を持つ．コントローラ側から識別するために，Openﬂow スイッチはそれぞれ一意的なDataPath ID を持つ．
フローテーブルは以下の３つの要素から構成される．

• フローを特定するヘッダフィールド• 処理内容を決めるアクション• フローに関する統計情報
図 1 既存システムのネットワーク構成図

Openﬂow プ ロ ト コ ル は Openﬂow コ ン ト ロ ー ラ とOpenﬂow スイッチとの間のやりとりの内容を規定するものである.
Openﬂow コントローラは，Openﬂow の制御部分を担っており，コントローラのプログラムを記述することで様々なネットワーク処理が実現できる．コントローラを最初からで開発するのは困難なため，コントローラソフトウェアの開発にはフレームワークを用いるのが一般的である．
3.2

新システムと既存システムの違い

既存システムでのシステムの稼働方法やパケット情報の管理は以下のようになっている．

• パケットの情報はルール毎に管理している• ネットワークの設定が煩雑化しやすい• ネットワーク機器それぞれに設定しなければならない
Openﬂow を用いた新システムでは次のようになる．
• フロー毎にパケット情報が管理されていて，コントローラで集計できる• 既存システムの機能をネットワーク機器に持たせることができる• コントローラで構成を管理するため，変更が容易に可能である4

提案する段階的通新制限システムの実現

本節では，本研究で実装する GK を実現するコントロー
ラとスイッチについて記述する．

4.1

queue id
12
3
4
5
6

LOIC を用いて HTTP リクエストの大量送信をしたさいのパケット数とバイト数を参考にして，10 秒毎のフロー毎の統計情報から 1 秒間あたり 200 パケット以上，または 10000 バイト以上の通信があった場合に通信制限が 1
段階厳しくなり，条件を満たさない場合は 1 段階通信制限が緩和されるように設定した．
4.2

netem の概要

netem はネットワーク上でのプロトコルテストなどのために提供されている．遅延とパケット欠損とパケット重複などがエミュレ ート可能である．netem はネットワー
クデバイスにルールを設定し，そのデバイスから出ていくパケットに対してパケットの処理をする．netem は遅延とパケット欠損を同時に設定することなどもできる．
4.3

コントローラの実装

実装するコントローラは以下の流れの処理をする．

スイッチの実現

Openﬂow 関連の機器は高価なものが多く，製品の種類も少ない．そのため、Open vSwitch を用いて PC を Openﬂow スイッチとして動作するブリッジとする．表 1 の通り，段階的通信制限には 5 種類の処理があるが，Openﬂow の標準仕様では 5 種類の中の遅延とパケット欠損を処理することができない．
表 1 Openﬂow の仕様と GK
通信制限
内容
Openﬂow
THROUGH 素通し○DELAY
遅延×LOSS
パケット欠損 ×
LIMIT
帯域制限
○
DROP
パケット破棄 ○表 2 Queue 設定
内容
1 秒の遅延1 秒の遅延と 10%のパケット欠損
2 秒の遅延
2 秒の遅延と 10%のパケット欠損
3 秒の遅延
3 秒の遅延と 10%のパケット欠損

GK
○
○
○
○
○

1. ネットワーク上で流れるパケットをスイッチから IDSを起動させたホストへミラーする．
2. IDS がミラーされたパケットの中から異常を検知した場合，異常を検知したこととその内容を Openﬂowコントローラにアラートとして送信する．
3. Openﬂow コントローラが読み込んだアラートを元にOpenﬂow スイッチにフローを書き込む．
4. コントローラが登録された Openﬂow スイッチからフロー毎の統計情報を取得する．
5. コントローラが統計情報を元に，必要な場合はフローのアクションを変更する命令をスイッチに出す．
フローテーブルを制御をするコントローラには Tremaフレームワークを利用する．IDS には先行研究 [3] でも使われている Snort を使用する．
次にコントローラを構成するメソッドについて説明する．

今回はスイッチで作られる queue に traﬃc control の start
コントローラ起動時に呼び出される．switch readynetem を利用して，デバイスに遅延やパケット欠損の処理で接続した Openﬂow スイッチの datapath id を管理を設定することで GK の実現に必要な通信制限の queueするインスタンス変数を作る．IDS のアラートを読を用意する．表 2 の 6 段階通信制限を用意して状況によっみ込む read alert スレッドを起動する．て使い分けることで段階的な通信制限を実現する．
通信制限の遷移は 10 秒毎にフローが書き込まれてから read alert
経過した時間とフローで処理されたパケット数やバイト
IDS からのアラートを読み込み，アラートの情報と数を照し合せて，異常な数値と思われるものは段階的にスイッチに書き込まれているフローの情報を照合す
通信制限を厳しくしていく．通信制限の監視対象となった
る AggregateStatsRequest を送信する．出した命令
フローは素通しの状態から開始される．今回の設定では，は stats reply を通じて処理される．IDS のアラート

を読み込む read alert スレッドを起動する．

テム使用率を示す．

switch ready
コントローラとスイッチが接続した時に呼び出される．接続したスイッチにスイッチングハブとして動作するフローの書き込みと，捕捉したスイッチの datapath id を記憶する．
switches flow check
コントローラに接続されているスイッチに一定間隔毎にフローテーブルの状態を問い合わせる FlowStatsRequest を送信する．このメソッドで送った命令の結果を stats reply を通じて表示する．
stats reply
接続されているスイッチから送られてくる応答があったときに呼び出される．AggregateStatsReply の場
合，一致するフローがない場合は新たにフローの書き込みを行う．FlowStatsReply の場合，フロー毎のパケット統計情報を参照して通信制限の変化をする．

図 4 2 秒遅延時の CPU システム使用率の比較

遅延のみを掛けた場合と比べて使用率が低下しており，サーバー負荷がより軽減されていることが分かる．パケッflow mod
ト欠損では 10%，30%，50%の 3 種類で計測したが，50%フローに新たに通信制限を書き込むために利用する． 以外は効果が見られなかった．
queue modify
5.2 通信制限によるスループット改善
フローに書き込まれている通信制限を変更するため正常な通信として Client から Server へ 10 クライアント，に利用する．queue id 毎に通信制限の内容が変化す
合計 200 リクエストを送信し，それを妨害する通信としてるように設定する．
Attacker から Server へ apache bench を用いて 140 クラ
drop modify
フローに書き込まれている通信制限をパケット破棄 イアント，合計 100000 リクエストを送信する．Attackerに変更するためのメソッド．パケット破棄の場合は からの通信に制限を変化させることで Client-Server 間のaction に何も指定しないフローを書き込むことでパ 通信パフォーマンスがどのように変化するかを測定する．
ケット破棄を実現している．そのため，queue modify 攻撃用ホストの通信を素通しした場合，5 秒の遅延を掛では queue id やポート番号を指定するなど，引数が けた場合，50%のパケット欠損を掛けた場合の 3 パターンを想定し，それぞれ 10 回計測する．Rps(Request per異なるため別のメソッドを用意した．
Second) は 1 秒間あたりの処理されたリクエストの数を5 性能評価実験示していて，スループットの目安となる．測定した結果
本節では，実験と評価に関して記述する．図 3 の実験 を表 3 に示す．
環境を構築する．
通信制限
平均
最小値
最大値
分散
図 3 実験ネットワーク

5.1

通信制限効果評価

表 3 Rps の測定結果
素通し
遅延 パケット欠損

2.21
1.99
2.33
0.01

20.59
14.96
30.74
25.84

25.24
15.32
28.36
13.74

グラフと表から攻撃ホストの通信を素通ししたときは
1 秒間あたり 2.2 リクエストしか処理されなかったのが，5 秒の遅延を掛けた場合は約 9.5 倍，50%のパケット欠損を掛け場合は約 12 倍にまで向上している．また，遅延よりパケット欠損の方が分散の値が小さく，通信が安定していることがわかる．

通信制限を攻撃ホストに掛けたときにサーバーへの負荷の変化を確認した．Attacker から Server へと 150 ク
ライアントから合計 100000 HTTP リクエストを apachebench を利用して発生させた．負荷を掛けた 2 分間の間， 5.3 試作システムの評価
CPU の使用率とメモリのスワップが発生量を計測する．
本研究で作成したシステム全体が正確に動作するか，本研究で作成した GK では複数の通信制限を同時に設定
IDS アラートと Openﬂow の統計情報で段階的に通信制できるようになっている．図 4 では，2 秒遅延の通信制限限できることを確認する．コントローラを起動した状態とそれに 10%のパケット欠損を比べたときに CPU シス

から HTTP DoS 攻撃として Attacker から合計 100000 リ
クエストを送信する．開始から 2 分間 Server の CPU 使
用率の変化を図 5 に示す．

した状態と比べて約 8 倍になっている．

図 6 一定時間内にリクエストが処理された割合
図 5 システム起動時の攻撃による CPU 使用率6

おわりにコントローラのログから通信開始すぐに Snort がアラー
本研究では，Openﬂow を利用した GK の試作と HTTP
トを発し，Attacker が通信制限の監視対象となった．そDoS
攻撃を対象とした通信制限効果の評価，本研究で作の後，図 5 の経過時間が横に移動していくと CPU の使用率が段々と低くなっているのが分かる．10 秒毎のパケッ 成したシステムの評価を行った．DoS 攻撃への通信制限
ト統計情報のチェックで通信制限が厳しくなり，70 秒経 効果の評価をし，通信制限をどのように設定することで過後，6 段階の通信制限を経て Attacker からの通信が破 DoS 攻撃に対して効果が現れるか，スループットがどの棄されるようになった．その後 1 度突発的に CPU 使用率 ように変化するかが分かった．本研究で作成したシステがあがったものの，サーバーに負荷が掛かっていないの ムの評価で HTTP リクエストを用いた DoS 攻撃に効果があることが分かった．
が分かる．
今後の課題として，DoS 攻撃や spam メーラー以外の
次に，コントローラを起動した状態で Attacker から様々な攻撃に対して実ネットワーク上での実験，それに対Server へ apache bench で 140 クライアントから合計100000 リクエストを送信開始すると同時に Client から 応するコントローラの設定追加．内部ネットワークだけ
Server へ 10 クライアントから合計 2000 リクエストの通 での実験ではなく，外部ネットワークからの攻撃を用い信を開始する．その Client からの通信結果を測定する． た実験をする．現在用いているフレームワークの Trema
また，Attacker から攻撃がない状況での Client からの同 がサポートしている Openﬂow のバージョンは 1.0 であり，このバージョンでは Ipv6 に対応していない． コント
じ条件での通信も測定し，その結果を表 4 に示す．
ローラ開発に用いるフレームワークを Trema-edge にすることで Ipv6 への対応を考える．また，スイッチに使用
表 4 1 リクエストあたりの処理時間と Rpsする PC の性能を上げることで実際のネットワーク環境条件
最小値 平均 中央値 最大値Rpsでの効果が期待できる．
攻撃あり
62545
34610093 18.31
攻撃なし
62264
250889 37.74
参考文献[1] N. Mckeown, et al., “OpenFlow: Enabling Innovaシステムの構成上，Snort がアラートを発して疑わしい
tion in Campus Networks”, ACM SIGCOMM Comホストを監視対象とした場合，最初のパケット統計情報
puter Communication Review, pp.69–74 (2008).
をチェックするまで通信制限を掛けることはない．その[2] 伊藤遼平, 嶋田伊吹: IPS の実現とネットワークエミュため，攻撃がある場合とない場合のベンチマークを比べ
レータ上での評価, 2009 年度卒業論文, 南山大学数理
たさい，1 リクエストに掛かった処理時間の最大値に大情報学部情報通信学科 (2010).
きな開きがあることが表 4 から分かる．図 6 は横軸に示されているパーセントで表示されている割合の数のリク [3] 青山正樹, 小島正和: 段階的通信制限を実現するゲー
トキーパーの提案と試作, 2006 年度卒業論文, 南山大エストのうちの最大の処理時間の推移を示したものであ
学数理情報学部情報通信学科 (2007).
り，50%での値が中央値にあたる．95%から最大値の間は攻撃の有無の差は大きいことが分かる．表 4 と図 6 から， [4] 福井麻美: 通信制限システムにおける TCP セッショ
ンの途中切替と安全なリモートアクセス機能の実装,中央値に近づけば近づく程，差は小さくなっており攻撃2009 年度修士論文, 南山大学大学院数理情報研究科数ホストの影響を抑えることに成功 しており，表 3 の攻撃
理情報専攻 (2010).
を素通しした場合の Rps と攻撃をシステムによって防御