セッション追跡によるプロトコルアノーマリの検知と対処 SING mizutani(B3) Parent　true

Road to Bachelor’s Paper 2004年秋 「ホストベース型防御機構の 設計と実装」（予定） 卒業論文 「不正侵入に対する総合的な セキュリティ環境の実現（仮）」 （あくまで予定） 2004年春「Session Based IDSの 設計と実装」電子情報通信学会 和文論文誌 （投稿中） 2004年春 「セッション追跡によるプロトコル アノーマリの検知と対処」 2003年秋 「The Design and Implementation of Session Based IDS」 USENIX ※ failed 2003年春 「セッション追跡型IDSの設計と実装」 2002年秋 「ホスト情報をもとにした 　攻撃情報のリスク評価」 2003年1月 「IDSのログ視覚化システムの開発」 情報処理学会 DMSシンポジウム 2002年春 IDSログ視覚化システム「pigeye」の開発

問題点 Intrusion Prevention System (IPS) 遮断できない攻撃 正常な通信を阻害する恐れ 攻撃と判断した通信を遮断 定型的、かつ確実な攻撃（ex:ワーム）を防御 遮断できない攻撃 未知の攻撃 非定型の攻撃（自作ツール等） 正常な通信を阻害する恐れ Preventionが困難

アプローチ 厳密なプロトコルアノーマリは困難 悪意のある通信と判断できる要素 ベンダの独自仕様、ユーザの設定ミス、アプリケーションのバグ 攻撃の可能性がある通信を検知、通信の追跡 内部ホストの応答 正常な応答の場合、攻撃の失敗、あるいは独自仕様、設定ミス、バグなど 異常な応答の場合、攻撃をうけた可能性

解決方法 プロトコルアノーマリから攻撃か否かを判断 攻撃の可能性がある通信 正常とされている通信の方式を登録 反応を含めた通信を監視 継続的に監視する事で判断 攻撃が成功したと考えられるホストへの内外ともに拒否 被害の拡大を防止

具体例 正常な通信 異常が発生 した通信 成功コード(200) や エラーコード(400等）を含む応答 とても長いHTTP GET Request （入力ミス等） HTTPのレスポンスコードを含まない応答 異常が発生 した通信 とても長いHTTP GET Request （Exploit Codeを含む）

プロトコルアノーマリ防御に関する設計 Inlineモード シグネチャによる検知 Out of scope トラフィックの転送、遮断の設定 マルチプラットホーム シグネチャによる検知 プロトコルの要求と応答をルールとして定義 数字、アルファベット、バイナリコードを指定するよう拡張 Out of scope unknownなプロトコル（自作/非公開プロトコル） 暗号化されたトラフィック

防御機構の概要 異常のあった通信を遮断 Layer-3 Layer-2 Interface-2 Interface-1 本実装

システム概要 Search Signature Interface-1 Packet Capture Interface-2 Search Trigger Signature Search Tracking Packet Capture Search Signature Forward / Drop Interface-1 Interface-2 Reject Address List

実装 C言語による実装 テスト環境 Session-Based IDSを拡張 libpcap, libnet Debian GNU/Linux testing 3.0 FreeBSD 5.2.1-Release Session-Based IDSを拡張 http://www.sfc.wide.ad.jp/~mizutani/blitz 防御ができたかどうかを、示さなければいけない。

シグネチャ例 alert “Web Too-Long Request Attempt” tcp any->80 { シグネチャの名前 TCP port 80へのアクセス alert “Web Too-Long Request Attempt” tcp any->80 { fac:(payload=0:3,”GET” & “HTTP/1.1”; payload_len=100: ;); res:rp_p<1(payload!=0:12,”HTTP/1.1 \d\d\d”;); } [drop: ever, all, 2;]; 行きと帰りがかける、ということがわかればよい。 GETとHTTP/1.1を含み、100byte以上のパケットを最初に検知 永続的に 攻撃元、および攻撃対象を遮断 2つ目のシグネチャ（3行目）を検知したら適用 応答にHTTP/1.1と結果コード（３桁の数字）が含まれなければ攻撃と判断 パケットをdropさせるオプション

実験環境 Host-1 : Lavie M LM500J CPU: Pentium III 500MHz Memory: 192MB IF: 100Base-TX OS: Debian GNU/Linux testing 3.0 Host-2 : ThinkPad X24 CPU: Pentium III 1.13GHz Memory: 640MB IF: 100Base-TX (On Board) OS: Debian GNU/Linux testing 3.0 This System : Dell PowerEdge 1750 CPU: Xeon™ 2.4GHz Memory: 512MB IF: 100Base-TX OS: Debian GNU/Linux testing 3.0

評価 (動作検証) 使用するシグネチャ テストサーバプログラム Port 80（HTTP)へのアクセス 100byte以上のGETリクエストを検知 応答にHTTPの結果コードがふくまれていなければ遮断 テストサーバプログラム あらゆるリクエストに対してHTTPによるHTMLファイルを返すサーバ ただし、リクエストにバイナリコードが含まれると結果コードを含まないデータが返される

評価 (動作検証) リクエストの内容 リクエストの長さ 期待される動作 結果 テキストのみ 100byte未満 何もしない 発見だけする バイナリ含む 発見、遮断する

評価 (速度測定) 50.3026 Mbps 74.3930 Mbps 74.4322 Mbps Host-1,2 間で10MBのファイルをHTTPで転送（100回試行） シグネチャ数 2055個 シングルユーザモード インラインモード、kernelブリッジ、直接接続 平均速度 本システム 50.3026 Mbps Linux kernel bridge 74.3930 Mbps 直接接続 74.4322 Mbps

今後の課題 転送・処理速度 改善策 UserLandで転送処理 パフォーマンスで劣る kernelの機能(libipq on Linuxなど）を用いる kernel中への実装

まとめ 既存の防御手法における問題点を指摘 セッション追跡による解決手法を提案 プロトコルアノーマリ機能追加のための設計 これを用いた防御機構を実装 DPSワークショップに論文提出予定 7月30日 論文提出 「卒論」 卒論としてはこんなことをやろうと思っている！ 全体のどの部分までやっているのか。 卒論の一部であると主張。 最初にやることは論文！？ 前回USENIX残念だったので、がんばる。 IPS あくまで卒論の一部！？ 論文の話とIPS、二つの話が平行している。 論文誌書いたり、ワークショップに出すからいいでしょ！　って言っちゃう。

シグネチャ例 プロトコル シグネチャの種類 HTTP, SMTP, FTP, DNS 通常より長いリクエスト バイナリコードを含むリクエスト、あるいは通信 “/bin/sh” を含むリクエスト 連続した0x90(x86 NOOP)を含むリクエスト 0xB0 0x17 0xCD 0x80 (x86 setuid(0))を含むリクエスト *.exe を含むリクエスト

設計 各セッションの情報を保持 プロトコルの要求と応答をルールとして定義 セッションの定義 ネットワークプレフィックス毎にハッシュ検索 Session HTTP 3201 80 10.1.23.24 192.168.2.3 7634 25 SMTP