セッション追跡によるプロトコルアノーマリの検知と対処

Presentation on theme: "セッション追跡によるプロトコルアノーマリの検知と対処"— Presentation transcript:

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

2 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」の開発

3 背景 → IPS (Intrusion Prevention System) FirewallによるFiltering
現在、最も一般的な不正侵入防御手法 IP address range Port number Domain name Passさせざるを得ないtraffic 提供しているサービスへの通信 内部からの通信 信頼しているアドレスからの攻撃 → IPS (Intrusion Prevention System)

4 Intrusion Prevention System
悪意のある通信をフィルタ パケットを落とす 例）ウィルス、ワーム、攻撃ツール 悪意のあるホストからの通信をフィルタ 一定時間 / 管理者が解除するまでフィルタ

5 動作例 ？ IPS Exploited !! Attacker Target Malicious packet! Known Unknown
Exploit Code Unknown Exploit Code Attacker Exploited !! ？ Target

6 問題点 定型的な攻撃以外は遮断できない 誤遮断の可能性 確実なルールのみで運用
Overflow Attempt, Assemble Code, Anomaly Packet 攻撃パケットのProtocol Anomalyは過剰検知 誤遮断の可能性 通信エラー、入力データのミス、ソフトウェアのバグ/仕様、あるいは実際の攻撃 正常な通信を妨害してしまう可能性 確実なルールのみで運用 悪意のあるトラフィックか否かの判断が困難 未知の攻撃をうけた場合、被害が拡大 悪意をもつ、持たないの判断をどうするか？ 忙しいネットワークは大変っぽい。スケールするのか？ 現時点で適切な言い訳ができるようにする。 IDSの検知数を見て、未知の攻撃がどのくらい来ているのか？　セッション数に対してどのくらいの異常があるか。 ５分観測したセッション数の変化、グラフの変化を見る。怪しい、というフラグがついたのはどのくらいか？

7 解決方法 プロトコルアノーマリから攻撃か否かを判断 規格外の通信に対してエラーを返さない場合 正常とされている通信の方式を登録
反応を含めた通信を監視 規格外の通信に対してエラーを返さない場合 継続的に監視する事で判断要素を増やす 攻撃が成功したと考えられるホストへの内外ともに拒否 被害の拡大を防ぐ セッションってなんなのか？ 追跡ってなんなのか？ の抽象的な定義 IPアドレス、ポート番号、 （モデル）

8 具体例 HTTP SMTP Out of scope
最初のリクエスト（“GET”、“POST”等）に対して結果コード (200、403、404、500等）が応答に含まれない SMTP HELOコマンドに対して結果コード（250、501）が含まれない HELOコマンドに対する応答にバイナリコードが含まれる Out of scope unknownなプロトコル（自作/非公開プロトコル） 暗号化されたトラフィック

9 動作例 Attacker Target Exploited! ???? No Problem Protocol Anomaly Packet
Unknown Exploit Code Attacker Exploited! Error Message ???? Target

10 有効な環境 不特定多数の人間が使うネットワーク 熟練した管理者がいないネットワーク 外来者のあるネットワーク 大学のネットワーク
家庭内ネットワーク 中小企業のネットワーク

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

12 今後の予定 6月24日までは電子情報通信学会の論文誌 6月25日から心を入れ替えて、実装 RG-NET内で運用し、評価を行う
(和文ですが）USENIXに提出した内容でリベンジ 6月25日から心を入れ替えて、実装 RG-NET内で運用し、評価を行う 正常な通信を阻害しないか 悪意ある通信を遮断できるか

13 まとめ 内部ホストに対する攻撃の被害を減らす セッション追跡による防御機構を実装する DPSワークショップに論文提出予定
7月30日 論文提出 「卒論」 卒論としてはこんなことをやろうと思っている！ 全体のどの部分までやっているのか。 卒論の一部であると主張。 最初にやることは論文！？ 前回USENIX残念だったので、がんばる。 IPS あくまで卒論の一部！？ 論文の話とIPS、二つの話が平行している。 論文誌書いたり、ワークショップに出すからいいでしょ！　って言っちゃう。