OpenFlow スイッチを用いた学習型の通信集約法

(1)

2012 ^{年度修士論文}

OpenFlow ^{スイッチを用いた} 学習型の通信集約法

提出日： 2013 ^年 2 ^月 1 ^日

指導：後藤滋樹教授

早稲田大学大学院基幹理工学研究科情報理工学専攻学籍番号： 5111B111-1

山田建史

(2)

図一覧

2.1 ポリシールータ構成概要図 . . . . 10

3.1 フローエントリー概要 . . . . 13

3.2 OpenFlowアーキテクチャ . . . . 17

3.3 既存手法の構成図 . . . . 21

4.1 IPアドレスの判定機構 . . . . 23

4.2 提案手法による循環システム . . . . 25

4.3 提案手法の構成図 . . . . 26

5.1 既存手法1の実験構成図 . . . . 29

5.2 既存手法2の実験構成図 . . . . 30

5.3 提案手法の実験構成図 . . . . 30

5.4 時系列による収集率 . . . . 33

5.5 測定時間全体の既存手法と提案手法の平均スループット. . . . 36

(5)

表一覧

5.1 実験機器の仕様 . . . . 29 5.2 悪意のある通信の収集率 . . . . 32 5.3 平均スループットと分散 . . . . 35

(6)

第 1 ^章序論

1.1 ^{研究の背景}

インターネットの発展に伴い、情報量の増大とともに悪意のある通信による脅威が顕在化している。今や、情報セキュリティを取り巻く脅威はグローバルに広がっており、国際的なサイバー攻撃が頻発している [1]。また攻撃手法も、ボットネットによるネットワークを中心に多様かつ複雑な攻撃が行われている。ボットネットとは、悪意のある攻撃者がインターネットを介してコンピュータを裏で遠隔操作するネットワークのことである。このボットネットは、インターネット上において国境を越えて様々な形態のものが複数存在しているため、どの程度のボットネットがどのような活動をしているのかの全容を把握できていない。それは、2008年 11月以降に大規模感染を引き起こしたConﬁckerワームによる爆発的な感染ホストの増加に代表されるように、感染ホストの数や悪意のある通信によるパケット数が増加しているためであ

る [4]。しかし、ボットネットを摘発する捜査過程において、部分的ではあるがその実態が明

らかになってきており、引き続き調査が必要である。そのためには広域的な調査を行い、多様化した攻撃手法を収集し、調査することが求められている。また同時に、IT利用の利便性がますます高まっていく中で悪意のある通信によるトラフィックを防ぐことも必要である。そういった利便性を享受しながら情報セキュリティ対策を両立させるために、既存のネットワークに影響を与えずに導入可能であるネットワーク制御システムが求められている。

(7)

第 1 章序論

1.2 ^{研究の目的}

広域的な通信の調査及び通信の選別による悪意のある通信の収集には、通信の経路上にファイアウォールなどの機器を通す必要がある。しかし、通信の経路上に機器を通して広域的な通信の調査を行うと、スループットの低下や制御内容の変更に伴う機器のリプレース、スケールアウトによるコストの増大といった問題が生じる。これでは既存のネットワークに影響を与えてしまう可能性がある。そのため、通信の選別による悪意のある通信の収集において、セキュリティ機能を持った柔軟なネットワーク管理システムが必要である。

このような背景で、既存のスイッチ網を再構成するネットワークアーキテクチャとしてOpen-

Flow [19]スイッチング技術が注目されている。OpenFlowはスイッチの機能を再構成、細分化

してスイッチ部とコントローラ部に分けることにより、柔軟かつ集約的な制御を行うことができる。この技術を利用することによって広域の通信を制御しても既存のネットワークに影響を与えることなく、安定した通信を行う上で通信の選別を行うことが可能となる。そこで既存の研究として、OpenFlowコントローラに静的なポリシーを与えることで悪意のある通信を一定量だけハニーポット (Honeypot) へ集約するシステムがある。しかし、集約できる通信はポリシーとして設定した内容に依存してしまい、柔軟に対応することが出来ないという問題がある。

本研究ではOpenFlowコントローラにIDS（Intrusion Detection System）やSVM（Support Vector Machine）による機械学習との連携を行うことで、動的なポリシーを設定し、より柔軟で効率的な通信集約システムの構築を目的とする。これにより、悪意のある通信をよりきめ細かく柔軟に制御できるシステムを提案する。

1.3 ^{論文の構成}

本論文は以下の章により構成される。

第1章 序論

本論文の概要を述べる。

第2章 ポリシールーティング

ポリシールーティングとそれを用いた既存手法を紹介する。

第3章 OpenFlow

(8)

第 1 章序論

第4章 提案手法

本論文の提案手法について述べる。

第5章 実証実験

提案手法の動作検証を目的とした実験と考察を行う。

第6章 結論

本論文の結論と考察を述べるとともに、残された課題を示す。

(9)

第 2 ^章

ポリシールーティング

2.1 ポリシールーティングとは

本章では、ポリシールーティングについて述べる。ポリシールーティングとは、ネットワーク管理者によって定義されたポリシーをルータに与え、パケットの転送とルーティングを行う技術であり、ネットワーク機器のみによって通信の選別を行うことが出来る。ルータとポリシールーティングについて順に説明する。

ルータ

ルータはOSI参照モデルにおける第3層、ネットワーク層でパケットを中継する装置である。2つ以上の異なるネットワークを相互接続する際に使用され、ルータが持つルーティングテーブルを参照し、ルートを決定してパケット転送を行う。また、ルータにはネットワークの負荷を管理する機能があり、フィルタリングやQoS (Quality of Service) 制御を行うことが出来る。そのため、通信の選別やファイアウォールといったセキュリティ機能を備えたものも存在している。

ポリシールーティング

ルータは通常、パケットの転送をルーティングテーブル上の情報により宛先ベースのルーティングが行われる。そのため、通信経路が単一になってしまい柔軟なルーティングが出来ないという欠点がある。ポリシールーティングは、ルーティングテーブル上のルート情報に関わ

(10)

第 2 章 ポリシールーティング

機能である。通常このポリシーは、パケットの宛先アドレス以外にも送信元アドレスやプロトコル、ポート番号、パケットサイズ、ToS値をもとに規定できるため、高い柔軟性を持っている。ルーターに対し、ユーザーやプロバイダが独自のルーティング方針を与えることをポリシールーティングという。

2.2 ^既存技術

本項では、ポート番号に基づいたポリシーを用いた既存技術において、ポートポリシーとポリシールータについて順に説明する。

ポートポリシー

ポートポリシーは、ポート番号によるトラフィックの判別ルールである。トラフィックをプロトコル別に管理することで、多種のサービスを柔軟に管理することが可能である。ファイアウォールとしての機能が主として用いられるため、宛先ポート番号に基づくポリシーが規定される。

ポリシールータ

iptables [28]とiproute2 [29]を組み合わせることで一定のポリシーを設定しルーティングを行う例 [17]を説明する。構成の概要図を図3.1に示す。iptablesではパケットの判別及びマー

キング、iproute2ではルーティングを行い、パケットの種別に応じて宛先を変更する。マーキ

ングは、Linuxに実装されたパケットフィルタリング機能であるiptablesのMARKマッチを用いる。これは、ポリシーに対してマッチするパケットに対して関連付ける値を設定し、保持することでマーキングを行う。従って、マーキングはパケットに対して行われるものではないため、当該ルータにのみ適応される。そして、マーキングを適応してルーティングを行う機能がiproute2である。

(11)

第 2 章 ポリシールーティング

図 2.1: ポリシールータ構成概要図

既存技術の問題点

これまでに説明した既存技術では、ポリシールーティングによって細かい制御が可能であるが、ポート番号ベースに代表されるように単純な制御となる傾向にある。Linuxが保持できるルーティングテーブルは256個と制限されてしまうこともその要因として挙げられる。そのため、制御できる内容は通常のルータ機能と比べて多様になったとしても、その特長を活かせていない。また、ポリシールータの制御内容は当該ルータにのみ適応される。そこで広範囲の通信を制御するために複数のポリシールータを用いると、それぞれにポリシーを適応させなければならない。従ってポリシーを変更する際にはそれぞれを変更しなければならなく、スケールアウトできないという欠点がある。故に広範囲の通信を制御し、悪意のある通信を収集するためには効率が悪くなる。同時に、高機能のルータであるほどコストが高くなるため、スケールアウトするに従いコストが増大する問題がある。以上より、既存技術ではポリシールーティングの機能面に加え、コスト面や効率面で問題がある。

(12)

第 3 ^章

OpenFlow

3.1 OpenFlow ^とは

本章では、本研究で用いるOpenFlowの技術について説明する。OpenFlowアーキテクチャの概要及び具体的な動作、各モジュールの役割について述べる。その後、OpenFlowを用いたポリシールーティングを行う既存手法について述べる。

OpenFlow [19]とは、インターネットの再構築を目的としたClean Slate Program [21]のプロジェクトの一つとしてスタンフォード大学を中心に研究開発されているオープンソースの技術である。現在はOpen Networking Foundation [20]によって規格化及び標準化が進められている。インターネットの成熟が進むにつれ、次世代インターネットに向けた様々な実験的な取り組みがなされてきた。これまで実験的なネットワークを実装するときは既存のネットワークを停止させた上ですべての機器を新しいものに取り替える必要があった。このリプレースにかかるコストは非常に大きく手間もかかるため、大規模なネットワークでの実験が非現実的である。これに対してOpenFlowは従来技術のスイッチの機能を再構成、細分化して独立させることにより、既存ネットワーク上で実験的なプロトコルを実装することを可能にしたものである。

OpenFlowは通信の処理を行う基本単位をフローとして扱い、プログラムによって制御するこ

とが可能である。また、OpenFlowを使って構築したスイッチをプログラマブルフロースイッチと呼ぶ。また、プログラマブルフロースイッチによって構成されるネットワークをプログラマブルネットワークと呼ぶ。スタンフォード大学では実験用に一部のネットワークをOpenFlow によるプログラマブルネットワークで構築し、運用している [11]。また、日本では独立行政法人情報通信研究機構 (NICT) が持つ研究開発テストベッドネットワークJGN2plus [22]において実証実験が行われ、日米間を繋ぐ大規模なネットワーク上でOpenFlowの動作が確認され

(13)

第 3 章 OpenFlow

た [9]。現在ではJGN-X [23]においてOpenFlowテストベッドが提供されている。

3.2 OpenFlow ^{アーキテクチャの概要}

OpenFlowは、イーサネットスイッチにフローテーブルを持たせたOpenFlowスイッチと、

それを制御するOpenFlowコントローラで構成される。両者はOpenFlowプロトコルと呼ばれる独自のプロトコルで通信を行う。OpenFlowの基本動作は以下の通りである。

• スイッチとコントローラ間において、SSLによってコネクションを確立する。

• スイッチはフローの最初のパケットが到着すると、それをまずコントローラに転送する。

• コントローラはパケットのヘッダ情報などからどのようなフローテーブルを設定するかを決定し、フローエントリーをスイッチに返答する。

• フローエントリーを受け取ったスイッチはフローテーブルに設定を行い、パケットの転送を始める。

• 2番目以降に届いたそのフローのパケットはコントローラに転送されることなくスイッチ上で設定されたフローテーブルに従い処理される。

このように、OpenFlowはスイッチの機能を転送部と制御部に独立させることで、OpenFlow コントローラがネットワークを集中管理する。これにより、フローの最初のパケット以外をスイッチ上のハードウェアで処理するため、転送部のスイッチに求めれられる機能を相対的に少なくできる。従って、複雑な処理が可能であるにもかかわらず高速で動作するという特長がある。OpenFlow Switching Performance [10]によると、OpenFlowスイッチは従来のルータやスイッチと遜色ない性能であることが示されている。

3.3 OpenFlow アーキテクチャの詳細

本項では、前項までに示したフロー、OpenFlowスイッチ、OpenFlowコントローラについてその詳細を説明する。

(14)

3.3.1 OpenFlow ^{におけるフローの定義}

OpenFlowは、処理を行う基本の単位としてフローを用いている。ここでいうフローとはネッ

トワーク・フローと呼ばれるもので、通信の開始から終了までを一つのフローとして扱うものである。そして、OpenFlowスイッチとOpenFlowコントローラ間でやりとりされるフローエントリーはルール、アクション、スタッツの3つから構成され、パケットのマッチングや処理方法、統計情報が設定される。以下にフローエントリーの概要を示す。

図 3.1: フローエントリー概要

上記のようにOpenFlowにおけるフローはレイヤ4までの情報すべてを用いて認識されるため、TCPコネクションごとにフローとみなすようなことが可能となる。OpenFlowがフローを認識する基準であるルールは、スイッチの入力ポート及びパケットのヘッダに含まれるレイヤ 4までのパラメータの任意の組み合わせである。以下にその組み合わせを示す。

• 受信したスイッチポート

• 送信元MACアドレス、宛先MACアドレス

• Etherタイプ

(15)

• VLANのタグID

• MPLSラベル、トラフィッククラス

• 送信元IPアドレス、宛先IPアドレス

• プロトコル番号

• ToS (Type of Service)

• 送信元ポート番号、宛先ポート番号

• ICMPの種類

レイヤ4情報まで取得していることにより、例えば同一IPからの複数の通信でもそれぞれを一意に認識することができるため、より柔軟な処理が可能である。フローテーブルで制御可能な処理は以下の任意の組み合わせであり、アクションとして決定される。

• スイッチの特定ポート出力

• スイッチの全ポート出力

• Flooding出力

• コントローラに対して出力

• パケットドロップ

• ヘッダの書き換え (送信元MACアドレス、宛先MACアドレス、VLANのタグID、送信元IPアドレス、宛先IPアドレス、送信元ポート番号、宛先ポート番号、ToS)

• OpenFlowスイッチ外の既存のL2/L3フォワーディング機能への処理委譲

このように、書きかえ等の処理についてもレイヤ4までの情報を扱うことができる。

(16)

3.3.2 OpenFlow ^スイッチ

OpenFlowスイッチは、入ってくるパケットを処理し、必要であればOpenFlowコントローラに転送する。OpenFlowスイッチでは物理インタフェースをまとめた単位をデータパス(datapath) と呼称する。データパスはスイッチを仮想的に定義するものである。データパスは単一のマシン中に複数作成できるため、これによってスイッチの機能を仮想的に分割することが可能である。前述のフローテーブルはこのデータパスごとに定義される。OpenFlowコントローラとの通信はこのデータパスもパラメータとして渡される。この情報を使って単一のコントローラで複数のデータパスを制御することが可能である。また、OpenFlowは基本の仕組みとしては

OpenFlowスイッチとOpenFlowコントローラの連携によって機能を実現するものであるが、

初期設定やテストなどのためにOpenFlowスイッチをコンソールで直接制御できる機能も備わっている。制御はdpctlコマンドによって実現される。主な機能を以下に示す。

• データパスの追加/削除

• データパスへの物理インタフェースの追加/削除

• データパスの状態表示

• フローテーブルの状態表示

• フローテーブルの定義

また、それぞれの状態表示において取得可能な情報を以下に示す。

• 送受信パケット数

• 送受信バイト数

• スイッチポートにおけるエラーパケット数

• スイッチポートにおけるドロップパケット数

• フローテーブルの数

• 各フローテーブルの詳細

OpenFlowスイッチは大きく分けてFlow Table部とSecure Channel部で構成される。図3.2 がその概念図である。それぞれについて次に述べる。

(17)

Flow Table部

Flow Table部はフローテーブルのリストを持つ。各フローテーブルはフローエントリー、フ

ローに対して行う動作リスト、テーブルの生存時間をパラメータとして持つ。すべてのパケットのヘッダはまずこの各フローテーブルのフローエントリと照合され、一致するフローテーブルの動作リストに従って処理される。一方、フローテーブルのリストにヘッダが一致しないパケットは、Secure Channel部に渡される。Flow Table部はハードウェアで実装されている。これは、Flow Table部が実際にすべての通信を処理する部分であり、処理の高速性が求められるためである。

Secure Channel部

Secure Channel部はFlow Table部から渡されたパケットをコントローラに渡したり、コントローラから渡されたフローテーブルの設定をFlow Table部に渡したりするなどスイッチとコントローラとの通信を行う。通信はOpenFlowプロトコルという独自の規則に従って行われ、

SSLで暗号化することが可能である。Secure Channel部は通常フローの最初のパケットを扱うときのみ動作するため、処理の高速性がFlow Table部と比べてあまり必要とされない。それに加えてソフトウェアで動作するOpenFlowコントローラと通信を行う必要がある。そのため、Secure Channel部はソフトウェアで実装されている。このように、処理速度が必要な機能についてのみハードウェアで実装し、その他の機能はソフトウェアで実装することで柔軟で高速な処理を可能にしたことが大きな特長である。

(18)

Controller OpenFlow Switch

Table Flow Flow Table Secure Channel Secure Channel

OpenFlow Protocol

SSL

hardware software

図 3.2: OpenFlowアーキテクチャ

(19)

3.3.3 OpenFlow ^{コントローラ}

OpenFlowコントローラはOpenFlowスイッチから受け取ったパケットに応じてフローを定

義し、スイッチに対して返答する。OpenFlowスイッチとの通信はOpenFlowプロトコルを介して行う。OpenFlowコントローラの実装はOpenFlowプロトコルに従ったものをプログラムで記述するもので、ユーザの要求に応じて自由な設計が可能である。OpenFlowコントローラの開発環境及び実装環境としてはnoxrepo.org [24]から提供されているNOXが広く使われ、前述のJGN2plusの実証環境においてもコントローラとして使われている。NOXは、OpenFlow プロジェクト自体と同じくオープンソースで開発されたOpenFlowコントローラであり、C++

及びPythonの開発環境を提供するため、容易に複雑な処理を定義することが可能である。本研

究においてもこのNOXを使ってOpenFlowコントローラを実装した。このように、OpenFlow コントローラはNOXなどを利用することで一般に利用されているプログラミング言語を用いることが可能である。これは、フローの最初のパケットについてのみ処理するという動作であるから、特別速度が要求されないためであり、OpenFlowに柔軟な開発環境という特長をもたせているものである。OpenFlowコントローラがOpenFlowスイッチに行える主な機能を以下に示す。

• データパスの状態表示

• フローテーブルの状態表示

• フローテーブルの定義

OpenFlowコントローラがOpenFlowスイッチに対して可能な動作は、OpenFlowスイッチ

上でのdpctlコマンドによるものとほぼ同一であるが、こちらはプログラミングによる処理で

あるから、条件文や変数定義などのより複雑で柔軟な制御が可能である。

3.4 ^{通信集約の既存手法}

本項では、既存手法としてOpenFLow スイッチを用いたポリシールーティングによる通信の集約法 [8]について説明する。

(20)

3.4.1 ^{既存手法の概要}

この手法はOpenFlowを用いて通信をより詳細に捉えてフローと定義し、コントローラが定めるポリシーに従い、悪意のある通信と判断されたフローをハニーポットへ集約することを実現する。この手法の動作は大きく分けて以下の3つである。また、既存手法の構成図を図 3.3 に示す。

1. フロー単位による通信の割り振り 2. コントローラ部によるポリシーの定義 3. ハニーポットによる通信の収集

ここで挙げた3項目について以下の本文で説明する。

フロー単位による通信の割り振り

OpenFlowでは、 3.3.1節で述べたように、レイヤ4までの情報を用いてフローを識別して

いることを利用して通信の割り振りを行う。ある通信に対して、フローの最初のパケットが到達したときにコントローラ部のソフトウェア処理で割り振り先を決定し、ハードウェアによるスイッチ部のテーブルにフローテーブルとして定義する。その後は定義されたフローテーブルに従いルーティング処理を行う。これによりスイッチ部の処理を高速に行うことができる。このように、この手法では転送部のスイッチと制御部のコントローラが分離するのでスケールアウト可能である。

コントローラ部によるポリシーの定義

この手法では、送信元IPアドレスによるブラックリストとポート番号によるポリシーを採用している。送信元IPアドレスは、Internet Storm Center (ISC) [30]が公開している攻撃元IP アドレスによるブラックリストを用いた。ポート番号は、ハニーポットの一種であるnepenthes が対応するポート番号に加え、警視庁セキュリティポータルサイト@police [3]が発行するインターネット治安情勢 2010年7月〜9月において報告されたポート番号を用いている。コントローラにはこれらを組み合わせたポリシーを持たせ、マッチングした通信をハニーポットへ経路を振り向ける。

(21)

ハニーポットによる通信の収集

OpenFlow によって集約する通信はすべて1つのハニーポットへ振り向ける。悪意のある通

信をハニーポットへ集約することによりホストに必要のないトラフィックが流れることを防ぐ。

また、広域の通信を一括してハニーポットに集約することで、多様な通信の傾向を容易に調査することが可能である。

ハニーポット

ハニーポットとは、マルウェア収集のため脆弱性の存在するホストをエミュレートすることにより、意図的に侵入しやすく設定されたサーバーやネットワーク機器である。ハニーポットは大きく2種類に分類される。1つ目はローインタラクションハニーポットと呼ばれ、脆弱性があるOSやアプリケーションの反応をエミュレートすることでマルウェア収集を行う。2つ目はハイインタラクションハニーポットと呼ばれ、脆弱性がある本物のOSやアプリケーションを用いて構築される。

この研究では、ローインタラクションハニーポットの一種であるNepenthesを使用した。

Nepenthesとは、マルウェア収集に特化したオープンソースのハニーポットである。シェル

コードの一部と著名なポート番号の脆弱性をエミュレートすることで、攻撃の収集を行う。また、攻撃パケットに応答してマルウェア検体のダウンロードを試み、応答結果をログファイルに出力する。ただし、この応答は既知の脆弱性に対して行われるため、未知の脆弱性に対する調査を行うことができない。

3.4.2 ^{既存手法の問題点}

この手法はOpenFlowスイッチング技術を用いることによってルータによるポリシールーティングに比べ、広域の通信をより効率良く制御することが可能となる。一方で、OpenFlow コントローラに設定したポリシーは静的なポリシーであるために、設定した内容に依存してしまう。これでは設定した内容以外の悪意のある通信はすべて見逃すという問題がある。そのため、見逃してしまう通信をよりきめ細かく判定するだけでなく、見逃してしまった通信の内容をポリシーへ反映する仕組みが必要である。

(22)

図 3.3: 既存手法の構成図

(23)

第 4 ^章提案手法

本章では、OpenFlowスイッチを用いた新しい学習型の通信集約法について説明する。

4.1 ^{提案手法の概要}

本提案手法は静的なポリシーに加え、IDSとSVMによる機械学習との連携を行うことで動的なポリシーを設定する。IDS、SVMについては 4.1.1節で後述する。実際には 3.4節で説明した既存手法の動作を以下のように変更することでシステムが稼働する。

1. フロー単位による通信の割り振り

2. コントローラ部によるポリシーの定義と更新 3. ハニーポットによる通信の収集

4. IDSによるポリシーの補完

ここで 3.4節から変更を行う2項目について説明する。

4.1.1 コントローラ部によるポリシーの定義と更新

本手法では、静的なポリシーと動的なポリシーの組み合わせを設定する。ポリシーとして使用する値は送信元IPアドレスとポート番号を採用している。以下にそれぞれについて説明する。

(24)

第 4 章 提案手法

送信元IPアドレス

送信元IPアドレスは、静的なポリシーとして既存手法と同じくInternet Storm Center (ISC) [30]が公開している攻撃元IPアドレスによるブラックリストを用いた。そして、本手法では静的にポリシーに加え、動的なポリシーとしてSVMによる機械学習[18]を採用した。SVMは教師あり機械学習法の一つであり、優れた識別機能を有するパターン認識手法として知られてい

る [5, 6, 7]。本研究における機械学習では、IPアドレスの構造的な特徴を利用することによっ

て、送信元IPアドレスが悪性であるか通常であるかの二値判別を行う。具体的には、はじめに悪性と通常を区別するラベル付きのIPアドレスリストを準備する。そして、与えられたIP アドレスから特徴ベクトルを抽出し、SVMの訓練アルゴリズムを適用することによって悪性であるか通常であるかの二値判別を行う。図 4.1に本判定機構の概要を示す。

図 4.1: IPアドレスの判定機構

本手法ではこの判定機構を用いることで、IPアドレスのブラックリストでは対応出来なかった未知のIPアドレスであっても判定を行い、悪意のある通信をきめ細かく制御することが可能となる。また、未知のIPアドレスに対して随時判定を行うため、リアルタイムの対応を行うことが可能である。

ポート番号

ポート番号は、ハニーポットの一種であるnepenthesが対応するポート番号に加え、警視庁セキュリティポータルサイト@police [3]が発行するインターネット治安情勢2012年7月〜9月

(25)

において報告されたポート番号を用いた。

コントローラ部にはこれらを組み合わせたポリシーを持たせ、マッチングした通信をハニーポットへ経路を振り向ける。

4.1.2 IDS ^{によるポリシーの補完}

4.1.1節ではOpenFlowコントローラ部に設定するポリシーを述べたが、悪意のある通信を

完全に判別することは難しい。そこで、ホストに転送された通信をIDSによって監視することで再度判定を行う。IDSは不正侵入を検知するためのツールであり、侵入検知システムと呼ばれる。ネットワークやホストの状況を監視し、侵入や攻撃を検知すると管理者にアラートとして通知する。IDS はパケットに含まれる全データを確認できるので、目的に応じて設定を変えることで様々な検知手法を実装することができる。また、設置場所や検知方法によってホスト型IDS（HIDS）とネットワーク型IDS（NIDS）、不正検出型（Misuse Detection）と異常検出

型（Anomaly Detection）に分類される。本研究では複数のホストを一括して管理するために

ネットワーク型IDSであるsnort [27]を採用した。また、IDSは危険度に応じたアラートを生成するので、この危険度が高であるアラートとなる通信の送信元IPアドレスとポート番号をコントローラ部のポリシーへ追加する。このように、ポリシーによって転送する通信が制御しきれなかった場合に、IDSによるフィードバックを与えることでポリシーの補完を行う循環システムが可能となる。図 4.2に本循環システムの概要を示す。これにより、より柔軟で動的なポリシーを設定することができ、見逃してしまった攻撃が再度行われた場合にも対応することができる。

4.2 ^{提案手法の詳細}

本項では、提案手法の具体的な動作について詳細に説明する。

4.2.1 ^{提案手法の動作}

提案手法の構成図を図 4.3に示す。OpenFlowスイッチに新しいフローがもたらされたとき、そのフローに対する最初のパケット情報がコントローラ部に転送される。この

(26)

図 4.2: 提案手法による循環システム

OpenFlowのコントローラ部には 4.1.1節で述べたように、送信元IPアドレスとポート番号

によるポリシーを定義しており、OpenFlowコントローラはパケット情報を受け取った段階でのポリシーを参照し、宛先を決定する。宛先の決定は以下の通りに分岐される。

1. ポリシーに適合した場合、宛先をハニーポットへ変更

2. 適合しなかった場合、SVMによる送信元IPアドレスの悪性判定を行う悪性とされた場合、宛先をハニーポットへ変更

悪性ではなかった場合、パケット情報に従ってフローを定義

次に、ポリシーによる分岐から決定された宛先に基づいてOpenFlowスイッチにフローテーブルの設定を命令する。スイッチはコントローラから受け取った命令に従ってフローテーブルを設定し、パケットの転送を開始する。フローテーブルに登録された情報に合致するパケット

は、以後OpenFlowコントローラに問い合わせを行わずに同じ動作を行うため、安定して通信

が行われるようになる。一方で、フローテーブルに合致しない新しいフローのパケットが到着したならば、先ほどと同じようにOpenFlowコントローラに転送される。

また、ホストに届く通信に対しては常時IDSが監視を行い、アラートの危険度が高の場合についてはポリシーの更新を行う。再度同様の通信が転送された場合はコントローラ部のポリシーが更新されているため、宛先をハニーポットへ変更し、転送される。

(27)

図 4.3: 提案手法の構成図

(28)

第 5 ^章実証実験

本章では、提案手法の実証実験の説明をする。仮想サーバ上に構築したネットワークでシミュレーションによる実験を行い、本研究の評価を行う。

5.1 ^{実験の概要}

本研究で提案する動的ポリシーを採用した手法が、既存手法と比べて安定的により多くの悪意ある通信を集約できることを実証する。そのために悪意のある通信の集約率を測定すると共に、提案手法を導入しても安定して通信が行われることを示すスループットの2点についての比較を行う。今回は既存手法としてポート番号によるポリシールータとOpenFlowによる静的ポリシーのシステムをとりあげる。

また、悪意のある通信はhping3 [31]によって再現する。hping3は、icmpプロトコルで動作するpingライクなコマンドで、多種様々なパケットの生成が可能である。今回はポートスキャンとIPスプーフィングによる送信元IPアドレスの変更を行ったパケットを生成し、悪意のある通信をシミュレートする。実験ではiperf [32]による擬似トラフィックを含めることで、正常な通信の中に悪意のある通信が混在する環境で行う。iperfとは、トラフィックを発生してネットワークのスループットを測定するツールである。実験は仮想化ソフトVMware ESXI [26]をインストールした物理サーバ上に構築した仮想マシン及び仮想スイッチを用いる。

(29)

第 5 章 実証実験

5.2 ^{実験の環境}

実験の環境は、VMware ESXiを用いて仮想ネットワークを構築した。Mware ESXiは物理サーバ上に、複数の仮想マシン及び仮想スイッチからなるネットワークを自由に構成することを実現するハイパーバイザである。既存手法の構成図を図 5.1、 5.2に、提案手法の構成図を図 5.3に示す。本研究では広域通信においてもネットワーク環境に影響を与えないことが必要である。従って、本研究ではネットワーク機器を複数用意した。具体的には、NOXコントローラ1台、OpenFlowスイッチ及びポリシールータをそれぞれ2台、ホスト4台、サーバマシン1 台、ハニーポット稼働用マシン1台を設置した。実験に使用した物理サーバおよび仮想マシンの設定を表 5.1に示す。これらの仮想マシンをそれぞれ仮想スイッチで結ぶことでネットワークを構築した。また、本実験で用いたポリシーは以下の通りである。

ポリシールータによる既存手法

nepenthesが対応するポート番号とインターネット治安情勢2012年7月〜9月において報告されたポート番号の組み合わせ21/TCP, 23/TCP, 25/TCP, 42/TCP, 80/TCP, 110/TCP, 135/TCP, 139/TCP, 143/TCP, 443/TCP, 445/TCP, 465/TCP, 993/TCP, 995/TCP, 1023/TCP, 1025/TCP, 1433/TCP, 2103/TCP, 2105/TCP, 2107/TCP, 3372/TCP, 3389/TCP, 5000/TCP, 6129/TCP,

9415/TCP, 10000/TCP

OpenFlowを用いた静的ポリシーによる既存手法

上記のポート番号に加え、ISC公開の攻撃元IPアドレス上位100件 OpenFlowを用いた動的ポリシーによる提案手法

上記のポート番号に加え、SVMによるIPアドレス判定機構及びIDSによるアラート

(30)

表 5.1: 実験機器の仕様

機器 OS CPU Memory

仮想マシン設置用物理サーバ VMware ESXi 5.0.0 4 CPUs : 3.058GHz * 4 12GB NOXコントローラ Ubuntu 10.04 2 CPU 2048MB

OpenFlowスイッチ1,2 Debian 5.0.4 1 CPU 512MB

ポリシールータ1,2 Debian 5.0.4 1 CPU 512MB

ホスト1〜4 Ubuntu 10.04 1 CPU 256MB

ハニーポット Ubuntu 10.04 1 CPU 256MB

サーバ Ubuntu 10.04 1 CPU 256MB

図 5.1: 既存手法1の実験構成図

(31)

図 5.2: 既存手法2の実験構成図

図 5.3: 提案手法の実験構成図

5.3 実験 1: 悪意のある通信の集約における優位性評価

5.3.1 実験 1 の概要

(32)

信の全トラフィックから、集約した通信の割合とする。割合はtcpdumpによって観測されたパケットのうちサーバから送信されたパケットを元にして算出する。また、5.1節で述べたように、悪意のある通信とはhping3コマンドによるポートスキャンとIPスプーフィングによる通信を指す。また、正常な通信はiperfを用いてTCPのファイルダウンロードによる擬似トラフィックを指す。これにより、悪意のある通信と正常な通信が混在する環境下における提案手法の優位性を示す。

5.3.2 ^{実験の内容}

hping3とiperfによって悪意のある通信と正常な通信が混在する通信を再現する。hping3ではポートスキャンとIPスプーフィング、iperfではファイルダウンロードによるトラフィック生成を行う。具体的には、以下のような通信を行った。

ポートスキャン

ポリシーで用いたポートに対してSYNパケットを等間隔で10回送出 IPスプーフィング

ランダムに生成したIPアドレスとISC公開の攻撃元IPアドレス上位100件から20件を抽出し、pingを行う

ファイルダウンロード

ファイルサイズ1Mbyteのダウンロードを発生させる

以上の設定でトラフィックを生成し、ハニーポットへの通信集約率を測定する。

実験1では、上記のトラフィックを用いて以下の5通りの環境で実験を行った。

既存手法1

図 5.1に示すポリシールーティング 既存手法2

図 5.2に示すOpenFlowを用いた静的ポリシーのシステム 提案手法1

図 5.3においてOpenFlowコントローラとIDSを連携させたシステム

(33)

提案手法2

図 5.3においてOpenFlowコントローラとSVMを連携させたシステム 提案手法3

図 5.3に示すOpenFlowコントローラとIDS、SVMを連携させたシステム

5.3.3 結果と考察

既存手法と提案手法による通信の収集率を表 5.2に示す。実験1では悪意のある通信と正常な通信を混在させ、実トラフィックに近いモデルを再現することにより実験を行った。その結果、IDS、SVMをそれぞれ適用した場合に既存手法と比べてより多くの通信を集約できたことが確認され、その2つを組み合わせた場合は最も多く70.1％の通信を集約することができた。

これは既存手法1と比べて59.6％、既存手法2と比べて37.5％にあたる通信を多く集約できたことが分かる。図 5.4を見ると、提案手法では通信を開始してからしばらく時間が経過するまでに大きく収集率が向上していることが分かる。これは、IDSが検出した通信がコントローラ部に転送され、ポリシーが改善されたためであると考えられる。また、その後においても断続的に提案手法に比べて収集率が改善している。これは定期的に送信されたIPスプーフィングの検出がSVMによってきめ細かく検出されたためであると考えられる。以上より、IDSと SVMによって動的なポリシーを設定した結果、柔軟に通信を制御し、悪意のある通信を集約することが示された。

表 5.2: 悪意のある通信の収集率手法収集率 (％) 既存手法1 10.5 既存手法2 32.6 提案手法1 41.4 提案手法2 63.7 提案手法3 70.1

(34)

図 5.4: 時系列による収集率

(35)

5.4 ^実験 2: スループットの優位性評価

5.4.1 ^実験 2 ^の概要

実験2では、iperfによってスループットの測定を行う。測定する対象は、ルータ内で処理を

行うポリシールータ、及びOpenFlowコントローラに問い合わせを行うOpenFlowスイッチのスループットを比較する。実験1で柔軟な制御を行うことを示したことに対し、既存のネットワークに影響を与えずに安定した通信が行われることを示すため、提案手法が既存手法に対して遜色ないスループットで動作することを示す。

5.4.2 ^{実験の内容}

実験1で使用したiperfを用いてパラメータの調整を行うことで、擬似Webトラヒックを再現する。具体的には、以下のような設定を行った。

• データサイズ：100Kbyte

• 生起間隔：ポアソン分布平均生起時間0.1s

• ウインドウサイズ：1400byte

以上の設定でトラヒックを生成し、通信開始後しばらく時間を置く。これは通信量を安定させるためである。そして、既存手法と提案手法についてそれぞれ360秒間、10秒間隔の平均スループットを測定する。

また、実験2では以下の3通りの環境で実験を行った。

既存手法1

図 5.1に示すポリシールーティング 既存手法2

図 5.2に示すOpenFlowによる静的ポリシーのシステム 提案手法

図 5.3に示すOpenFlowとIDS、SVMを連携させたシステム

(36)

5.4.3 ^{結果と考察}

既存手法と提案手法における平均スループットの測定結果を図5.5に示す。また、既存手法と提案手法それぞれの、測定時間全体における平均スループットと分散を表5.3に示す。実験

2ではiperfによりスループットの測定を行った。結果を見ると、提案手法よりも既存手法がス

ループットが大きいことが分かる。これは、IPアドレスのブラックリストを参照するよりも SVMのIPアドレス判定が処理に時間がかかってしまったことが考えられる。一方で、提案手法は既存手法1よりも分散が小さく、安定的な通信が行われていることが分かる。これは通信

がOpenFlowスイッチのフローテーブルに登録されて以降コントローラに問い合わせを行わず

に転送を行っているためであると考えられる。そのため、OpenFlowスイッチを用いた既存手法2と提案手法の分散は同程度の結果が得られている。これにより、本提案手法は既存のネットワークに影響を与えることなく、通信を柔軟に制御した上で安定した通信が可能であると示された。

表 5.3: 平均スループットと分散

手法平均スループット (Mbps) 分散

既存手法1 14.36 0.76

既存手法2 13.51 0.58

提案手法 13.27 0.59

(37)

図 5.5: 測定時間全体の既存手法と提案手法の平均スループット

(38)

第 6 ^章結論

6.1 ^まとめ

本論文では、OpenFlowを用いた広域通信の選別による悪意のある通信の収集に有効なシステムに対して、静的ポリシーだけではなく動的ポリシーの導入を提案した。提案手法は、

OpenFlowコントローラ部にIDSとSVMを連携させることで、動的なポリシーを設定した。

これにより、既存手法では制御しきれないポリシーを制御し、きめ細かく通信を選別することでより多くの通信を集約することを目指した。この提案手法の実用性を示すため、仮想サーバ上で実験を行った結果、集約率に大きな改善がみられ、リアルタイムに通信を制御することが示された。また、スループットは既存手法と比較して遜色なく、安定した通信が観測されたことから、既存のネットワークに影響を与えずに動作できることが示された。従って、動的ポリシーを採用した本提案手法は既存手法と比べてリアルタイムによる通信の制御と既存のネットワークに影響を与えない安定した通信システムという点において優れている。

6.2 ^{今後の課題}

本論文で残された今後の課題を以下に挙げる。

6.2.1 False Positive の検討

提案手法では、SVMによる送信元IPアドレスの悪性判定によってブラックリストに依らない動的な通信選別を行った。しかし、SVMによる悪性判定の精度は完全ではなく、正常の通

(39)

第 6 章結論

信を悪性とみなしてしまう可能性がある。OpenFlowはフローテーブルに登録しても、コマンドによって削除することができる。そのため、再度OpenFlowコントローラへ問い合わせることができるため、対応は可能である。しかし、悪性と判定されてしまった正常通信は一度はハニーポットへ転送されてしまう。よって、IPアドレスの判定としてSVMを導入するにあたって誤検知の検討を行う必要がある。

6.2.2 OpenFlow コントローラの冗長化

本研究ではポリシーをOpenFlowコントローラに集中させることで、中央集権的に制御を行なっている。これにより制御を管理することは容易になるが、OpenFlowコントローラに障害が起こると制御を行うことができなくなってしまう。そのため、セカンダリOpenFlowコントローラを用意するといった検討を行う必要がある。

6.2.3 実機による評価

本研究では仮想サーバ上で仮想マシン、仮想ネットワークを用いて性能の評価を行った。これは実機による動作を完全に保証するものではない。従って、今後実機を用いた提案手法の性能評価が必要である。

(40)

謝辞

本学士論文の作成にあたり、日頃より御指導を頂いた早稲田大学理工学部の後藤滋樹教授に深く感謝致します。また、卒論時から貴重な助言とご協力を頂いたNTT サービスインテグレーション基盤研究所の森達哉氏を始め、修士論文に向けて貴重なご意見を頂いたすべての皆様に感謝致します。特に、後藤研究室OBの下田晃弘氏、石遺眛氏、戸部和洋氏、後藤研究室修士2年の千葉大紀氏にはたいへんお世話になりました。実験環境の構築から研究の方向性について多くの助言を頂き感謝致します。特に千葉大紀氏にはOpenFlowスイッチと機械学習との連携において同氏の研究を参照させて頂くだけでなく、構築にも多大な協力を寄せて頂いたことに感謝致します。卒論時と同様に仮想サーバ上で実験を行うが故の苦労も多かったですが、彼らのおかげですべての実験を仮想サーバ上で行うことができました。最後に、学部時代から常に研究室で共に助け合い、励ましあった修士2年の同期にも感謝致します。

(41)

参考文献

[1] 情報処理推進機構, 情報セキュリティ白書2012 狙われる機密情報求められる情報共有体制の整備, 初版第1刷, pp.6–44, 情報処理推進機構, August 2012.

[2] 日経BP社, すべてわかる仮想化大全2013, pp.90–107,日経BP社, November 2012.

[3] @police, インターネット観測結果等平成24年度第2／四半期 (7月〜9月) , http://www.npa.go.jp/cyberpolice/detect/pdf/20121114.pdf, 2012.

[4] 中里純二, 大高一弘, nicter レポート〜長期ネットワーク観測に基づく攻撃の変遷に関する分析〜, http://www.nict.go.jp/publication/shuppan/kihou-journal/

kihou-vol57no3 4/kihou-vol57no3-4 0203.pdf,情報通信研究機構季報Vol.57, pp.27–

34, June 2011.

[5] 麻生英樹, 津田宏治,村田昇, パターン認識と学習の統計学―新しい概念と手法, 統計科学のフロンティア 6,岩波書店, April 2003.

[6] 津田宏治, サポートベクターマシンとは何か,電子情報通信学会誌, Vol. 83, No. 6, pp. 460–466, June 2000.

[7] 前田英作, 痛快! サポートベクトルマシン: 古くて新しいパターン認識手法, 情報処理, Vol. 42, No. 7, pp.676–683, July 2001.

[8] 山田建史,戸部和洋, 森達哉, 後藤滋樹, OpenFLowスイッチによる悪意のある通信の集約, CSS (Computer Security Symposium) 2011, pp.301–306 October 2011.

[9] 金海好彦, 高島正徳, 鈴木順,ビラウォンミナイサイ, 田中仁, 太田善之,下西英之, 岩田淳, JGN2plus上でのOpenFlow実証実験, 2009年電子情報通信学会総合大会, S-135, 2009.

[10] Manuel Palacin, 「OpenFlow Switching Performance」,

(42)

参考文献

[11] Othman M., Improvement of Content Server with Contents Anycast Using OpenFlow, Department of Advanced Science and Electrical Engineering,

Network Research Workshop, August 2010.

[12] Nikhil Handigol, Pulg-n-Serve: Load-Balancing Web Traﬃc using OpenFlow, ACM SIGCOMM Demo, August 2009.

[13] Nick McKeown, OpenFlow: enabling innovation in campus networks, SESSION: Editorial zone, pp.69–74, 2008.

[14] Hardeep Uppal, Dane Brandon, OpenFlow Based Load Balancing, CSE561: Networking Project Report, University of Washington, 2010.

[15] 曽根直人, 森井昌克, ポートスキャン対策を目的としたハニーポットの提案とその応用, 電子情報通信学会技術研究報告, pp.19–24, 2006.

[16] 山本真里子, 岡本栄司, 岡本健,侵入検知システムを用いた動的ファイアウォールの実装, 筑波大学大学院 2006年修士論文, 2006.

[17] 白畑真, 南政樹,村井純, ポリシールーティングを用いたネットワークハニーポットの構築, 情報処理学会研究報告, pp.55–58, 2005.

[18] Daiki Chiba, Kazuhiro Tobe, Tatsuya Mori, Shigeki Goto, Detecting Malicious Websites by Learning IP Address Features, Proc. 12th IEEE/IPSJ International Symposium on Applications and the Internet (SAINT2012), pp.29–39, Izmir, Turkey, Jul. 2012.

[19] The OpenFlow Switch Consortium,http://www.openflow.org/

[20] Open Networking Foundation, http://www.opennetworking.org/

[21] Clean Slate Design for the Internet,http://cleanslate.stanford.edu/

[22] JGN2plus, http://www.jgn.nict.go.jp/

[23] 新世代通信網テストベッド JGN-X, http://www.jgn.nict.go.jp/

[24] NOX - An OpenFlow Controller, http://noxrepo.org/

[25] Open vSwitch - An Open Virtual Switch,http://openvswitch.org/

(43)

参考文献

[26] 無償のVMware ESXi：ライブマイグレーションを実現するベアメタルハイパーバイザー,

http://www.vmware.com/jp/products/esxi/

[27] Snort, http://www.snort.org/

[28] netﬁlter/iptables project homepage, http://www.netfilter.org/

[29] IPROUTE2 Utility Suite Documentation,http://www.policyrouting.org/

[30] Internet Storm Center, http://www.dshield.org/

[31] hping, http://www.hping.org/

[32] iperf, http://iperf.sourceforge.net/

OpenFlow スイッチを用いた学習型の通信集約法

2012 年度 修士論文