セキュリティのための段階的通信制限システムの評価と改良

セキュリティのための段階的通信制限システムの評価と改良

2004MT012

福井 麻美

2004MT097

末吉 昭仁

指導教員

後藤 邦夫

1

はじめに

インターネットが普及している近年，その安全性が 大きな問題となっている．特に DoS攻撃 (Denial of Service attack)などの不正アクセスについては，掲示板 や検索サイトなどがターゲットとして狙われ，その被害 について報道される場合が多い[3]． 本研究では，この対策手段のひとつである「段階的通 信制限を実現するゲートキーパーの提案と試作」(以下， 既存手法とする)[2]の改良に重点を置いて進めていく． なお，待ち行列での処理にはGINE論文のQueue処理 の手法[1]を用いる． 主な改良点はフィルタリングルールの管理方法であ る．既存手法では，既存のネットワーク型IDSが発する アラートを元にルールをフィルタリングするという方法 をとっていたが，本研究ではIDS，メイルサーバ等の外 部アプリケーションからいつでも自由にフィルタリング ルールを追加，削除出来るマニュアル操作機能を追加す る．マニュアル操作機能を実現するため，IDS，メイル サーバ等の複数の外部アプリケーションからの要求を受 け付ける機能を付け加える．メールサーバやIDSなど の外部アプリケーションからフィルタをコントロールす るために，疑似アタックのテストによる効果，基本性能 の向上を目指す． GK本体の作成と実験は共同で行い，末吉は主に実験 環境構築と疑似アタックを担当し，福井は主にGKと外 部アプリケーションとの通信機能，ルールのエントリと フィルタ操作を担当した．

2

システムの概要

この節では，本研究で提案するシステムの概要を既 存手法と比較して，GKの基本的なネットワーク構成， フィルタリングルールの追加，更新，削除について述 べる． 2.1 既存システムの概要 hostA (External) hostB (Internal) Switch mirroring IDS GateKeeper eth0 : 192.168.0.3 eth0 : IPなし eth1 : IPなし eth0 : IPなし eth1 : 192.168.0.2 eth2 : 192.168.0.1 eth0 : 192.168.0.4 図1 ネットワーク構成 既存システムでは，GKを外部ネットワークと内部 ネットワーク間でIPアドレスをつけずにブリッジとし て動作させ，フレーム通過時に通信を制限する(図1参 照)．IDSはスイッチでミラーリングされたネットワー ク上を流れるパケットを監視し，検知した攻撃の種類， 攻撃下のIPアドレスなどの情報を直結したGKに渡 す．GKはこの情報に基づいてリアルタイムに通信制限 を行う．

GKは主に，Receiver，Queue，Sender，Real Time Clock Timer(以下，RTCTimerとする)，Filter， Filter-Manager，RuleUpdatorから成り立っている(図2参 照)． Receiver Filter RuleUpdator 更新 参照 Queue: DELAY Queue: THROTTLE Queue: LOSS Sender RTCTimer 参照 eth0 eth1 DROP THROUGH GINEの技術を用いた部分 FilterManager 追加と削除 DataBase 読み込み eth2 IDSからの警告 図2 GKの構成 Receiverは制限対象リストの Filter をチェックし， 受 信 フ レ ー ム を ど の 経 路 に 振 り 分 け る か 判 断 す る ．

THROUGHの場合は直接送信し，DELAY，

THROT-TLE，LOSSの場合は各Queueに入れる．またDROP

の場合は全てのフレームをその場で破棄する．各Queue

に入れられたフレームは，障害を発生される処理を行っ た後，RTCTimerと連動したSenderによって送信さ れる．Filterの情報はFilterManagerとRuleUpdator

によって管理されている．FilterManagerはデータベー スに出力されたIDSからの警告を読み込み，Filterに 書き加える．また同時に古くなった情報の削除も行う． RuleUpdatorは，FilterManagerが書き込んだ制限対象 をどの経路に振り分けるかという情報を管理する． 2.2 新システムの概要 本研究では，外部アプリケーションからフィルタ変更 要求を受け付けることで，より正確で効率の良いフィル タリングを実現できると考えた． 本研究の主な改良点は，以下の3点である． • 外部からのルール追加，削除，表示要求を受け付け るコマンド受付・返信スレッドの実装 • ホスト管理表の実装 • Filterのルール処理機能の追加 本研究では，フィルタ変更をする際の必要情報は，IDS を含めたその他の外部アプリケーション(メイルサー

バ，IDS等)から送信される．そのためには，外部アプ リケーションから必要情報を受け付けるためのコマン ド受付・返信スレッドを新たに実装する必要があると考 えた． 次に，ホスト管理表の実装である．ホスト管理表は外 部アプリケーションとGK内のコマンド受付・返信ス レッドの通信の際に参照される．GKの信頼性を高める ため，通信を行う相手ホストの情報はホスト管理表で管 理し，一覧に無いホストからの要求は受け付けないこと にする．そうすることで悪意のあるホストからの接続が 大幅に軽減されると考えた． 最後に，Filterのルール処理機能の追加である．外部 アプリケーションからルールの追加，削除，表示要求を 受け付けるようにしたことで，ルールの処理方法にも変 更を加えた．詳しくは次節で述べる．

3

システムの実現

本研究で提案するシステムを実現するためには，外部 アプリケーションからフィルタリングルールの追加・削 除要求を受け付けるコマンド受付・返信スレッドの実装 が必要である． プ ロ グ ラ ム の ク ラ ス は 主 に ，Commander，Filter，

DatalinkSocket，Reciver，Sender，Timerによって構 成される(図3参照)．Commanderは本研究で新しく Receiver Filter RuleUpdator 更新 参照 Queue: DELAY Queue: THROTTLE Queue: LOSS Sender RTCTimer 参照 eth0 eth1 DROP GINEの技術を用いた部分 Commander 追加と削除 送受信 外部ホスト Queue: THROUGH Queue: THROTTLE 参照 ホスト_管理表 図3 提案するシステムの構成 加えた外部ホストとの通信部である．ここでフィルタ 操作の振り分けを行う．Filterでは，外部ホストから の要求でルールの追加，削除，表示等の処理を行う． DatalinkSocketでは，経路の設定を行う．

なお，Commander，Receiver，Sender，Timerはプ ログラム内でそれぞれスレッドとして動作し，その実現 にはGKと同様にオブジェクト指向のC++言語を用 いた． 本研究では，通信制限のアクションがTHROUGHの 場合もQueueを作成し，他のアクションのQueueと 同様に扱えるように改良した．また，THROTTLEは ルールによって設定する帯域幅が異なるので，ルール毎 にQueueを作成した． 3.1 コマンド受付・返信スレッド(Commander)の実装 GK内に実装したコマンド受付・返信スレッド(以下， Commander)でおこなう主な処理は，外部アプリケー ションとの通信，外部アプリケーションからの要求に応 じて，フィルタリングルールの追加や削除，表示などの 処理を行うことである．また，Commanderは外部アプ リケーションからの依頼を設定する時の設定内容の確認 通知や，依頼された処理が成功したか失敗したかの結果 の返信も行うことにする． 3.2 フィルタの管理 ここでは，フィルタリングルールのエントリと，追加， 削除，表示の各処理について説明する． フィルタリングルールのエントリ 外部アプリケーションからの要求でルールが追加され る．ルールをエントリするために必要な情報は，パケッ トの配信元IPアドレス・マスク，宛先IPアドレス・マ スク，プロトコル番号，配信元ポート番号，宛先ポート番 号，設定する通信制限の種類(DELAY, THROTTLE, LOSS)，通信制限のパラメータ，ルールの有効期限，攻 撃のタイプである．これらの情報に加え，そのルールの 追加要求をしてきた外部ホストのIPアドレスもエント リの際に取得しておく．また，ルールの管理はルール番 号で行うため，ルール番号を格納する変数も用意して おく． フィルタの各処理 フィルタの処理には，フィルタリングルールの追加， 削除，表示，挿入がある．追加，挿入はどちらも新たに ルールを作成する処理であるが，その相異点は，ルール を格納する位置である(図4参照)． ルールの追加の場 ☆ADD

head Rule:0 Rule:50 tail

Rule:60

☆INSERT

head Rule:0 Rule:10 tail

Rule:5 図4 ルールの追加と挿入 合，ルールは常にフィルタの最後尾に格納する．挿入処 理では，ルールを追加する位置をHost側で決めること が出来る．また，挿入と削除と併せて利用することで， ルールの更新を実現できると考えた．また，ルールの削 除は，ルール番号を使用するため，表示と併せて利用す るものとする．ルールの削除を希望するHostは，まず ルールの表示依頼をする．ルールの表示は，そのHost が設定しているルールの一覧が表示される．Hostは，一 覧のルール番号を元にルールの削除依頼を行う．

4

実験による評価

本研究で試作したシステム(以下，GK2とする)を用 いて実験を行い，ネットワーク上でのGK2の有効性に

ついて述べる． 評価項目は以下の通りである． • 制限なしの状態で，GK2がブリッジとして高速に 動作するか．通信自体を妨害しないか． • 各制限が設定値通りの挙動を示すか． • フィルタ追加，削除，表示のフィルタ操作が正確に できるか． • TCPやUDPに対して，各制限はどのような効果 が期待できるか． • 疑似アタックに対して，GK2の有効性が示せるか． 上記の点に注目して実験を進めた． 4.1 実験ネットワークの構成 図5は実験環境について示した図である．実験環境 は端末としてLinuxマシンを2台用意し，それぞれを

ExternalHost A(攻撃ホスト)，Internal Host B(保護さ

れるホスト)に見立て，その間にGK2をインストールし

たPCを挟むような形でLANケーブルをつなぎ構築し

た．PCのスペックは表1の通りである． また，全ての

表1 機器のスペック

GK2 hostA，B CPU Intel(R)Xeon(R)1.86GHz Intel(R)Celeron(R) M processor 1200MHz メモリ 512MB 1GB

NIC - eth0 Broadcom BCM5712 Gigabit Ethernet Intel Corp.82801BD PRO/100VE(MOB) Ethernet NIC - eth1 Broadcom BCM5754 Gigabit Ethernet −

  PCのOSにVineLinuxを用い，ルールの追加はtelnet コマンドを用いてGK2内のコマンド受付・返信スレッ ドに接続して行った． External Host A eth0: 192.168.233.1 eth0: 192.168.233.2 eth1: 192.168.233.254 eth0: IPなし GK Internal_{Host B} 図5 実験環境 4.2 試行する疑似アタックの種類 試行する疑似アタックは以下の3通りである． • WWWサーバに対するDoS攻撃． • パスワード解析系攻撃． • 大量のメールを勝手に送り付けるスパムメール． 各疑似アタックを行うためのLinuxコマンドは，WWW サーバに対するDoS攻撃は「ab」，パスワード解析系攻 撃は「expect」，スパムメールは「sendmail」で疑似する ことにした． 4.3 GK2の性能評価

hostAからhostBに向かって，pingとiperfを用い

てGK2の性能評価のための実験を行った．hostAから

hostBに向かう通信に対して，DELAY，THROTTLE，

LOSS，DROPの各通信制限のルールを設定した．設定 値は表の通りである． 実験結果は表2のようになる．DELAYのRTTと LOSSの損失率を見ると，設定値がそれぞれ反映され ていることがわかる．通信の遮断であるDROPも正常 に動作している．また，フレーム損失が起きるLOSS とDROP以外では損失が起きていない点，遅延を発

生させない設定遅延0msecのDELAYとLOSSや設

定帯域幅0.1Mbps，1.0MbpsのTHROTTLEのRTT がTHROUGHのRTTと比較してほとんど差がない点 から，GKがブリッジとして高速に動作し，期待通り の通信制限が行われていることがわかる．設定帯域幅 0.05MbpsのTHROTTLEではICMPパケットの通過 に影響をもたらす結果となった． 実験結果より，外部ホ 表2 RTTとスループット，フレーム損失率の測定結果 設定値 測定値 制限 遅延(msec) 帯域幅(Mbps) 損失率(％) RTT(msec) スループット(Mbps) 損失率(％) THROUGH − − − 0.52 367.80 0 DELAY 0 − − 0.50 232.00 0 DELAY 300 − − 300.58 0.86 0 DELAY 500 − − 500.55 0.49 0 DELAY 1000 − − 1000.52 0.22 0 THROTTLE − 0 − 0.52 232.00 0 THROTTLE − 0.05 − 1.92 0.047 0 THROTTLE − 0.1 − 0.53 0.095 0 THROTTLE − 1.0 − 0.51 0.95 0 LOSS − − 0 0.52 − 0 LOSS − − 25 0.53 − 26 LOSS − − 50 0.57 − 49 LOSS − − 75 0.61 − 75 LOSS − − 100 − − 100 DROP − − 100 − − 100   ストから追加要求をしたルールがきちんと反映されてい ること，また，設定したパラメータどおりに通信制限が 行われていることがわかった． 4.4 WWW DoS疑似アタック WWWサーバに対する疑似アタックはabコマンド を使用した．この実験において重要と言える項目は以下 の5つである． • Complete Requests(CR)：総リクエスト数 • Failed Requests(FR)：失敗したリクエスト数 • Requests per second(R/s)：1秒当たりの平均処理

リクエスト数

• Time per Request(T/R)：1リクエスト当たりの平 均処理時間

• Transfer Rate(TR)：1秒当たりに受け取ったbyte

数 実験結果を表3に示す．表からわかるように，全ての制 限においてTHROUGHの時より，各項目がサ−バ−に とって良い測定値を示している．特にLOSSによる制 限が最も効果的であると言える．LOSSの制限は50％， 75％とまだまだ重くできるので，より激しい攻撃に対し ても効果が期待できる．

表3 WWW DoS疑似アタックの測定結果 測定値

制限 CR FR R/s(#/sec) T/R(msec) TR(kbytes/sec) THROUGH 538.54 18.57 1622.09 DELAY(300) 16.10 621.17 48.49 DELAY(500) 1000 0 9.66 1035.38 29.12 THROTTLE(0.1) 25.52 391.86 76.86 LOSS(25％) 5.95 1681.74 17.91 LOSS(100％) − − − − −   4.5 パスワ−ド解析系疑似アタック 今回の実験においてはexpectというプログラムを用 いて，パスワ−ド解析系攻撃を疑似した．expectは他の 対話形式プログラムとプログラムされた問答を行なうプ ログラムで，通信の流れを自動化するものである． 制限なしの状態ではジョブ接続後，パスワ−ドの問答 が繰り返され，loop.shで指定した回数だけexpectスク リプトを実行して終了した．全体的にスムーズに通信を 行ったという感覚だった．次にDELAY(300)を追加し て行ったところ，全体的に動作が鈍くなった．しかしな がら，遅いながらも通信自体は成立しておりジョブがパ スワ−ド解析攻撃を受け続けていた．expectスクリプ トのタイムアウトのデフォルトが20秒なので，GK2の DELAYで20000(msec)の遅延を追加したところ，ジョ ブの応答よりも早くパスワ−ドを送信して，接続をす ることができなかった．これによりパスワ−ド解析系攻 撃においてもGK2の通信制限が有効的であると考えら れる． 4.6 スパムメ−ル疑似アタック スパムメ−ルを疑似するために，Linuxコマンドの

sendmailを用いた．sendmailとはLinuxに標準的に用 意されているコマンドで，以下の入力方法で使用できる． • /usr/lib/sendmail -i 04mt012@[192.168.233.2]<test.txt まず相手に送るためのメール内容を記述したファイル をテキスト形式で用意する．端末のコマンドラインから 上記の入力で1通のメールが04mt012@[192.168.233.2] 宛に送信できる．上記のコマンドをシェルスクリプトに 100回繰り返し記述し，それを実行することで大量送信 を実現した．今回送るメールのサイズは平均的なメ−ル サイズである12KBとした．なお，表4の送信時間の目 安は次の4段階とした． • 1：非常に遅い • 2：遅い • 3：どちらかというと遅い • 4：普通 実験結果は表4の通りである．まず全ての制限におい てメール到着時間にかなりの遅延が発生し，もしスパム メ−ル送信者がメ−ルの到着率が悪いとすぐに他の標 的に変更するという古いタイプのスパムメ−ルソフト を使用した場合は効果が期待できる．DELAYの50000 では，タイムアウトしてしまい，メールを送信すること ができなかった．LOSSが設定値通りにいかなかったの は，postfixの再送機能によるものだが，それでもLOSS の75％に至っては100通中90通送り終わったところ で1時間近くかかった． これらの実験結果より，スパ 表4 メールの送信時間と損失率の測定結果 測定値 測定値 制限 遅延(msec) 帯域幅(Mbps) 損失率(％) 送信時間 メ−ル損失率(％) THROUGH − − − 4 0 DELAY 300 − − 3 0 DELAY 500 − − 3 0 DELAY 1000 − − 2 0 DELAY 10000 − − 1 0 DELAY 50000 − − − 100 THROTTLE − 0.1 − 2 0 THROTTLE − 1.0 − 2 0 LOSS − − 25 2 0 LOSS − − 50 1 5 LOSS − − 75 1 10 DROP − − 100 − 100 ムメールに対して最も有効であるのはDELAYである ことがわかった．また，LOSSも有効であることがわ かった．

5

おわりに

本研究では，外部アプリケーションからの要求を受け 付けるために，コマンド受付・返信スレッドを実装した． コマンド受付・返信スレッドを実装したことで，外部ア プリケーションの要求に柔軟に対応することが可能と なった． また，運用レベルでの効果測定として疑似アタックを 試行することで評価を行った．実験結果から，本研究で 提案したシステムが実ネットワーク環境下で設置した場 合にも効果的に作用するだろうと考えられる． 今後の課題としては以下の3点が挙げられる． • セキュリティ強化のためのホスト管理表の実装 • インターネット環境下での運用テスト • 攻撃に対しての情報を収集するハニーポットへの 切り替え機能の追加

参考文献

[1] Ihara, A., Murase, S., and Goto, K.: IPv4/v6 Network Emulator using Divert Socket, Proc.

of 18th InternationalConference on Systems En-gineering (ICSE2006), Coventry, UK, pp.

159-166(Sep.2006) [2] 青山 正樹, 小島正和: “段階的通信制限を実現する ゲートキーパーの提案と試作”,卒業論文,南山大学 数理情報学部情報通信学科(2007) [3] 警察庁セキュリティポータルサイト@police: “我が 国におけるインターネット治安情勢の分析につい て”,警察庁(2007). (http://www.cyberpolice.go.jp/detect/pdf/200707 26.pdf)