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

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

2. Road to Bachelor’s Paper 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. 背景 • FirewallによるFiltering • 現在、最も一般的な不正侵入防御手法 • IP address range • Port number • Domain name • Passさせざるを得ないtraffic • 提供しているサービスへの通信 • 内部からの通信 • 信頼しているアドレスからの攻撃 → IPS (Intrusion Prevention System)

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

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

6. 問題点 • 定型的な攻撃以外は遮断できない • Overflow Attempt, Assemble Code, Anomaly Packet • 攻撃パケットのProtocol Anomalyは過剰検知 • 誤遮断の可能性 • 通信エラー、入力データのミス、ソフトウェアのバグ/仕様、あるいは実際の攻撃 • 正常な通信を妨害してしまう可能性 • 確実なルールのみで運用 • 悪意のあるトラフィックか否かの判断が困難 • 未知の攻撃をうけた場合、被害が拡大

7. 解決方法 • プロトコルアノーマリから攻撃か否かを判断 • 正常とされている通信の方式を登録 • 反応を含めた通信を監視 • 規格外の通信に対してエラーを返さない場合 • 継続的に監視する事で判断要素を増やす • 攻撃が成功したと考えられるホストへの内外ともに拒否 • 被害の拡大を防ぐ

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

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

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

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

12. まとめ • 内部ホストに対する攻撃の被害を減らす • セッション追跡による防御機構を実装する • DPSワークショップに論文提出予定 • 7月30日 論文提出