このメモは古いです！https://git.softlab.cs.tsukuba.ac.jp/ichiki/docker-coins-thesis を参照してください。概要
近年、多くの人々が複雑なアプリケーションを身近に利用している。そのようなアプリケーションは、しばしばインターネットと通信する。アプリケーションが行う通信内容とその通信先を検証し、利用者が意図しない通信を防ぎたいという要求がある。例えば、あるアプリケーションが開発元に統計情報を送信しているとき、その通信内容に事前の許可なく個人情報が含まれてないか確認したい場合や、他のホストとは通信させたくない場合が考えられる。そのような場合、Little Snitch~\cite{LittleSnitch} のようなアプリケーションレベルでのファイアウォールを使うことが有効である。
アプリケーションレベル・ファイアウォールとは、一般にアプリケーションが動作する OS 上で動作し、各アプリケーションや通信先の種類に基づいてアクセス制御を行うファイアウォールである。ルータ等のネットワーク機器におけるファイアウォールとの相違点として、アプリケーションが動作する OS 上で動作することや、アプリケーションを認識して個別のアクセス制御ができる点が挙げられる。また、ユーザと対話的にルールを設定するための機能を持つことが一般的である。
従来のアプリケーションレベル・ファイアウォールの実装は比較的容易であるが、TLS 等を用いて暗号化された通信はファイアウォール側で復号する機能を有さない場合に内容の検証が困難であるという問題がある\cite{Alphakai}。
また、あるアプリケーションについて、特定の内容を持つ通信を行おうとした場合にそれを検知し、遮断したいという要求がある。このような目的のためには、侵入検知システムである Zeek NMS\cite{やる}などが用いられてきた。しかし、侵入検知システムは一般にユーザと対話する機能を提供しておらず、ネットワーク上を流れる異常なパケットを発見しても遮断しない。また、侵入検知システムは一般的なファイアウォールと同様に管理者がネットワーク上に設置するものであり、ユーザが自らセットアップしてアプリケーションごとのアクセス制御を適用することは難しい。
本研究の目的は、暗号通信含め、利用者が予期しないような通信が発生していないか確認・検査、およびフィルタリングできるようにすることである。この目的を達成するため、本研究では仮想マシン上で実行されるアプリケーションによる暗号通信含む通信を対象とするアプリケーションレベル・ファイアウォールを実装する。本研究で提案する手法では、コンテナ上の OS でアプリケーションを動作させ、フィルタ用 eBPF プログラムが ingress と egress で動作するネットワークインターフェイスにコンテナが送受信するパケットを導くことでアクセス制御を実現する。アプリケーション単位でのアクセス制御を行うために、本研究では 1 アプリケーションあたり 1 つのコンテナを起動する。これにより、アクセス制御の実装の簡素化およびパケットと関連するアプリケーションの対応付けが簡単になり、アプリケーション単位でのアクセス制御が可能となる。本研究では、アプリケーションレベル・ファイアウォールを eBPF プログラムのコントローラとして実装し、ユーザとの対話を行う機能を持たせる。また、暗号通信の内容について検証しアクセス制御を行うために、コンテナ上のアプリケーションが提供する SSL keylog インターフェイスから取得した TLS 公開鍵でネットワークインターフェイスに導かれたパケットを復号し平文をユーザに表示する。本論文の構成を以下に示す。第 1 章では本研究の背景と概要について述べた。第 2 章では本研究に関連する研究について述べる。第 3 章では既存のアプリケーションレベル・ファイアウォールの課題と提案手法について述べる。第 4 章では本研究で提案する仮想マシンと仮想スイッチを用いたアプリケーションレベル・ファイアウォールの設計について述べる。第 5 章では本研究で提案する仮想マシンと仮想スイッチを用いたアプリケーションレベル・ファイアウォールの実装について述べる。第 6 章では本研究の評価を行い、セキュリティの向上を達成できたことと本研究の限界について述べる。第 7 章では本研究のまとめと今後の課題について述べる。第 2 章
本章では、本研究に関連する研究について述べる。2.1 侵入検知システム
侵入検知システムとは、ネットワーク上の通信を監視し、不正な通信を検知するシステムである。そのような通信があると、ログの書き込みやユーザへの通知などを行う。侵入検知システムの実装として Zeek が挙げられる。Zeek ではユーザが JavaScript や Zeek script を用いて HTTP リクエストやレスポンスを示すパケットが到達した際のイベントハンドラを記述できるため、複雑なパターンマッチを含むルールが適用できる。また、監視したいホストが持つ TLS の鍵材料を受け取れば、復号結果に対して通信の解析が実施できる。しかし、Zeek はネットワーク上に配置されて動作するシステムであるため、ユーザが自分の PC にインストールし、自分の PC 上の通信を監視する用途には適さない。また、Zeek はネットワーク上の通信を受動的に監視するのみであり、通信の遮断は実施しない。さらに、Zeek は対話的なインターフェイスを用いたルールの変更などを行う機能を提供せず、アプリケーション単位でのアクセス制御は実現できない。
本研究は、ユーザの PC 上で動作し、不正または不明な通信は遮断して、さらにユーザとの対話的なインターフェイスを持つ点が Zeek とは異なる。2.2 コンテナによるセキュリティの向上
（いらないかも？）第 3 章
本章では、アプリケーションレベル・ファイアウォールの概要と課題について述べる。3.1 アプリケーションレベル・ファイアウォール
アプリケーションレベル・ファイアウォールとは、アプリケーションのネットワーク通信やシステムコールの呼び出しを制御するファイアウォールの一種である。
ネットワーク内の通信を監視する形式のものを network-based firewall といい、他ホストとのネットワークを介した通信などを監視する形式のものを host-based firewall という。本研究で実装するファイアウォールはアプリケーションの通信に関してアクセス制御を行う host-based firewall である。3.2 既存のアプリケーションレベル・ファイアウォールの課題
既存のアプリケーションレベル・ファイアウォールでは、暗号通信に含まれるアプリケーションデータを復号して平文を解析する機能を一般に持たない。そのため、暗号通信に対するアクセス制御は実施できない。
また、ユーザの PC 上で動作させるにあたって仮想スイッチや SDN（Software Defined Network）を要求する場合、それらのソフトウェアが脆弱性を持っていた際に新たな攻撃ベクターをユーザの PC にもたらす可能性がある。 第 4 章
アプリケーションレベル・ファイアウォールの設計
本章では、本研究で提案するアプリケーションレベル・ファイアウォールの設計について述べる。4.1 概要
本研究で提案するアプリケーションレベル・ファイアウォールのアーキテクチャを図 ? に示す。このアーキテクチャの構成要素は主に n つから構成される。- コンテナ
- 他の環境から隔離されたアプリケーションの実行環境として用いる。
- eBPF プログラム
- コンテナが持つネットワークインターフェイスを流れる通信を制御・監視するために用いる。ホスト OS のカーネル空間で動作する。
- ファイアウォールを制御するためのコントローラ
- アクセス制御はここで行われる。ユーザとの対話機能を持つ（これから実装して持ちたい）。ホスト OS のユーザ空間で動作する。
- 通信内容解析処理
- 実装したい
- アプリケーションから受け取ったパケットの内容をバックグラウンドで解析する。
本研究では、次のような特徴をもつアプリケーションレベル・ファイアウォールを実現する。
- アプリケーション単位でのアクセス制御が行えること
- ユーザと対話し、動的にルールを更新可能であること
- TLS 1.3 の暗号通信の内容についても解析可能であること
この特徴を持つファイアウォールを実現するための設計について、それぞれの観点から説明する。4.1.1 アプリケーション単位でのアクセス制御を行うための設計
本研究では、アプリケーション単位でのアクセス制御を簡単に実現するために、1 つのアプリケーションあたり 1 つのコンテナを起動する。このとき、それぞれのコンテナは固有のネットワークインターフェイスをホスト OS に追加する。アプリケーションレベル・ファイアウォールが監視するネットワークインターフェイスをコンテナのものとすれば、パケットと関連するアプリケーションの対応付けが簡単になり、アクセス制御の実装の簡素化が可能となる。また、複数のアプリケーションを実行するときには、アプリケーションの数だけコンテナを起動し、ホスト OS にネットワークインターフェイスを追加する。ユーザはアプリケーションに対するアクセス制御のルールをコンテナが持つネットワークインターフェイスごとに記述できる。4.1.2 ユーザとの対話を可能とする設計
本研究では、ネットワークインターフェイスに eBPF プログラムをアタッチし、コントローラでパケットの解析を行う。eBPF プログラムはコントローラと共有する 5tuple ルール表とキャプチャしたパケットを突合し、当てはまる 5tuple ルールがあればそれに基づいてパケットを通過または遮断する。このとき、5tuple ルール表に当てはまる 5tuple ルールがなかったならば、キャプチャしたパケットはコントローラに送信され、ネットワークインターフェイスから破棄する。
コントローラがパケットを受け取ると、アプリケーションレイヤの内容に基づいたルールの表とキャプチャしたパケットを突合し、当てはまるルールがあればそのパケットの 5tuple に対応する新たな 5tuple ルールを 5tuple ルール表に追加する。ここで当てはまるルールがなかった場合、コントローラでもパケットに対するアクセス制御を決定できない。
そのような場合にコントローラがユーザと対話し、動的にルールを設定・適用するための機能を提供する。また、前述の通りコントローラはホスト OS 上のリッチなプログラミング環境を用いて実装可能であるため、対話機能は TUI を用いて実装する。コントローラは、TUI 上に表示されたダイアログを用いてユーザと対話し、そのパケットに対するルールを生成してルール表に追加する。ユーザは、最初にルールの有効期限を設定する。これにより、ルールを永続的に有効にしたり、ある期間の間だけ有効にすることが可能となる。続いて、ユーザはルールの適用範囲を定める。ここでは、アプリケーションによるすべての通信に対して適用するか、特定のプロトコルの通信に対して適用するか、特定のホストに対して適用するかなどが選択可能である。最後に、これまでに設定したルールに当てはまる通信を通過または遮断することを選択してルールを追加する。
ダイアログにはホスト名を表示する。しかし、コントローラが受け取ったパケットからは宛先や送信元の IP アドレスのみが明らかである。ユーザに IP アドレスを提示しても、どのホストと通信しているかすぐに判断することは難しいため、本研究では DNS の応答パケットをキャプチャして保持しておき、IP アドレスに対応するホスト名が判明している場合にはそれを表示する。これにより、ユーザによる対話的なルール設定がより簡単になることが期待される。4.1.3 TLS 1.3 の暗号通信の内容を解析可能とする設計
本研究では、アプリケーションによる暗号通信の内容を解析可能とするために、ユーザが通信内容を解析したい TLS アプリケーションを実行する際には特定の環境変数を与えてアプリケーションに SSL keylog ファイルを書き出させ、これをホスト OS に共有するものとする。
SSL keylog ファイルにはアプリケーションが通信時に利用した TLS の鍵材料や対応するセッションの識別子が含まれており、この情報を利用してコンテナから送出された TLS パケットの内容を復号できる。鍵に関する情報はコンテナ内のアプリケーションが新たな TLS セッションを確立するたびにファイルへ書き込まれるため、コントローラはこのファイルに対する変更を inotify システムコールを用いて監視し、随時新たな鍵材料を保持する。
コントローラが暗号化されたパケットを受け取ったとき、SSL keylog ファイルに含まれる TLS の鍵材料と照らし合わせ、共通鍵が既知の TLS セッションであった場合は復号して通信内容に相当する平文を得る。その後、他の平文のパケットと同様にしてアプリケーションレイヤの内容に基づいたルールの突合を行う。
TLS セッションの確立からコントローラによる鍵情報の取得までにはレイテンシが生じるため、コントローラがパケットを受け取ってから通信の検証を実施するために適切な遅延を挟む必要がある。類似する仕組みとして、ローカルネットワーク上の異なるホスト間で鍵情報を共有する事例 \cite{Zeek NMS の拡張} では 40 ミリ秒の遅延が必要最低限であるとの結論が得られているが、本研究ではユーザの PC 上でのプロセス間の通信であるためより短い遅延のみが必要であると考えられる（TODO: 評価に必要最低限の遅延がどの程度か調べる。そのためには、コントローラが SSL keylog ファイルを読み込んで保持するタイミングと、BPF map 上の ringbuf からパケットを読み込んでくるタイミングを比較してあげる必要がありそう）。4.2 通信の検証
本研究で実装するアプリケーションレベル・ファイアウォールは、2 種類の方法を用いて通信を検証し、アクセス制御を実現する。
1 つ目は、通信の宛先や送信元に関する検証である。パケットが持つ宛先・送信元 IP アドレス、宛先・送信元ポート番号、そして IP プロトコル番号の、いわゆる 5tuple に基づいた検証である。
2 つ目は、アプリケーションレベルの通信内容に関する検証である。通信内容についての検証を行う際は、まず宛先や送信先についての検証を行い、そこで許可された際に追加で行う。通信内容について検証するために、パケットがコントローラに到達するたびにパケットの解析を行う。このとき、パケットが TLS 1.3 などの暗号通信であった際は、復号処理も実施する。そして、パケットの内容を解析した結果、そのパケットに対してあらかじめユーザが設定した特定の好ましくない内容が含まれていたと判明した場合、そのホストとの通信を遮断する。その後、ユーザに対して、悪意のある通信を検知したためにアプリケーションの通信を遮断したことを通知する。4.n 脅威モデル
本研究では、コンテナランタイムにはバグがなくホスト OS での権限昇格は不可能なものとする。コンテナ内で動作するアプリケーションとゲスト OS は、ネットワーク通信を行う際に必ずコンテナランタイムおよび対応するホスト OS 上のネットワークインターフェイスを経由することになる。この状況下では、アプリケーションが動作するコンテナが外部と通信する際には仮想的なネットワークインターフェイスのみが利用可能であり、eBPF プログラムがアタッチされるのはホスト OS 上のネットワークインターフェイスであるため、結果として本アプリケーションレベル・ファイアウォールはバイパス不可能である。
また、本研究ではゲスト OS 上でプログラムを実行する際に特定の環境変数を与えたり、ホスト OS からゲスト OS のファイルを監視する。第 5 章
アプリケーションレベル・ファイアウォールの実装
本章では、本研究で提案するアプリケーションレベル・ファイアウォールの実装について述べる。5.1 実装に用いた環境
本研究で実装するアプリケーションレベル・ファイアウォールおよびアクセス制御の対象とするアプリケーションの実行環境として、eBPF アプリケーションを tc qdisc にアタッチすることをサポートした Linux x.yz 以上を想定する。5.2 構成
本研究で実装するアプリケーションレベル・ファイアウォールの構成図を図 ? に表す。主要な構成要素は次の n つである。- コンテナ
- 他の環境から隔離されたアプリケーションの実行環境として用いる。コンテナ実行環境を構成するために Docker Desktop を用いる。
- eBPF プログラム
- コンテナが利用するネットワークインターフェイスにアタッチされて動作し、当該インターフェイス上を流れるフレームに対するフィルタリングおよびパケットキャプチャを実施する。Rust 言語で aya~\cite{aya} クレートを用いて実装する。コントローラとの通信には BPF map を用いる。
- コントローラ
- eBPF プログラムによるフィルタリングの制御や、TUI によりユーザと対話しアクセス制御を行う機能を持つ。本研究では、アプリケーションレベル・ファイアウォールをコントローラ内で実装し、アクセス制御をコントローラで行う。
【ここに構成図を挿入する】
5.3 ルール
【内容を詰めなければいけない。アプリケーションレベルのルールを表現するためにはどうすればよいか】
本研究では、アクセス制御のルールは以下のような構造で表現される。なお、本研究で提案するアプリケーションレベル・ファイアウォールはネットワークインターフェイス毎に起動されることが想定されるため、アクセス制御のルール内にコンテナやそこに付けられたネットワークインターフェイスの名前は出現しない。- Policy
- このルールにパケットがマッチしたときの転送の許可または拒否を表し、それぞれ allow または deny によって表現される
- 5tuple
- このルールを適用する対象となるパケットに当てはまる 5tuple の
5.4 5tuple ルール
本研究における eBPF プログラムは、各パケットをその 5tuple に基づいてフィルタリングする。5tuple は、パケットが持つ以下の 5 つの情報の組のことである。ただし、L4 プロトコルが TCP または UDP でない場合はポート番号の情報が欠落しているものとみなす。- 送信元 IP アドレス
- 送信元ポート番号
- 宛先 IP アドレス
- 宛先ポート番号
- IP プロトコル番号
5.4.1 5tuple のマッチング仕様
本研究では、ルールまたは 5tuple ルールでパケットに対してマッチさせるための 5tuple 情報について、各情報に関してワイルドカードとして振舞わせるための特殊な値を以下のように定める。- 宛先 IP アドレス、送信元 IP アドレス
- 224.0.1.20
- IPv4 アドレスのうちで実験のために利用できるアドレスはこれしか存在しない \cite{RFC 4727}。
- 宛先ポート番号、送信元ポート番号
- 1021
- TCP・UDP ヘッダのうち、システムポートであって実験用に使えるものは 1021 と 1022 のみであり、そのうちの一つを使用する\cite{RFC 4727}。
- IP プロトコル番号
これらの値が格納されている 5tuple のフィールドについては、マッチング処理を実施する際にパケットの当該フィールドの値を無視し、いかなる場合でもそのフィールドの値がルールにマッチしているものとみなす。例えば、(192.168.0.1, 1021, 192.168.0.2, 80, 6) という 5tuple がルールに組み込まれていた場合、192.168.0.1 の任意のポートを送信元として 192.168.0.2 の 80 番ポートに対する TCP のパケットにマッチする。このように、通信時にクライアント側が任意にポートを選択するようなプロトコルに関するルールを記述する際には有用である。5.5 コントローラの実装
この節では、本研究で実装するアプリケーションレベル・ファイアウォールの実装について説明する。5.5.1 概要
本研究では、コントローラの実装のために Rust 言語を用いる。eBPF プログラムとコントローラ間の通信をするために BPF map を利用するため、aya クレートを用いる。
本研究で実装するコントローラの機能を以下に列挙する。- パケットを受け取り、ユーザと TUI を用いて対話的に対応するルールを追加する機能
- パケットの宛先や送信元についてアクセス制御を行う機能
- コンテナによる TLS 1.2 の通信で利用される共通鍵を取得し、暗号化されたパケットの内容を復号してアクセス制御を行う機能
それぞれの機能について後続の項にて述べる。
5.5.2 対話的なルール追加機能
本アプリケーションレベル・ファイアウォールが動作している様子を示す。ユーザーが 1.1.1.1 に向けた ICMP Echo Request の通信を行い、かつ 1.1.1.1 宛ての ICMP Echo Request の通信は拒否されていないものとする。このとき、ping コマンドにより ICMP の通信を行うと、図 ? のような画面が表示される。第 6 章 評価
この章では、本研究の目的が達成できているか評価する。本研究の目的は、アプリケーションの行なう通信に対してアクセス制御を行うことでセキュリティの向上を図ることである。
そして、本研究では、コンテナおよび VMI といった仮想化技術を用いて、通信の内容についてアクセス制御が可能なアプリケーションレベル・ファイアウォールの提案と実装を行った。このファイアウォールを用いて実際にセキュリティの向上ができていることを確認する。続いて、本研究で実装したアプリケーションレベル・ファイアウォールを用いた場合の性能について論じる。最後に、本研究の限界について論じる。6.1 定性的な機能評価
本研究では、アプリケーションによるバイパスが難しいファイアウォールを提案した。従来のアプリケーションレベル・ファイアウォールでは、アプリケーションを実行する OS とアプリケーションレベル・ファイアウォールを実行する OS が同一であることから、OS に脆弱性が存在するとバイパスできた。しかし、本研究ではコンテナを用いてアプリケーションの動作する環境の外側からアクセス制御を行うことにより、概念的にアプリケーションの通信のバイパスが不可能となっている。6.2 実験による機能評価
6.2.1 通信の宛先に基づくアクセス制御
6.2.2 通信の内容に基づくアクセス制御
6.2.3 暗号通信の内容に基づくアクセス制御6.3 性能評価
6.4 現在の実装の制限事項と今後の課題7 結論謝辞参考文献