Nicolas FISCHBACH シニアマネージャー、IP技術/セキュリティ - COLT Telecom

安全なネットワークインフラの展開 PacSec.JP 2003 - Pacific Security Japan Nicolas FISCHBACH シニアマネージャー、IP技術/セキュリティ - COLT Telecom 　　nico@securite.org - http://www.securite.org/nico/ version 1.0

議題 • ルータのセキュリティ • ルータのセキュリティの基本 • インフラのセキュリティ • フィルタリング, BGP/DNS • フォレンジック • 分散サービス妨害（DoS） • 攻撃、ワーム、及びbotnetsの傾向 • 検出と軽減 • 他に最近見られる新しい危険性 • IPv6, MPLS, Lawful Intercept, 等 • 結論

ルータのセキュリティ • ルータのセキュリティ 101（初級編） • インフラの堅牢なセキュリティは、ルータの確実なセキュリティから始まる • パケット転送対”受信”パケットの性能 • どのシステムにも当てはまるように： • VTY (バーチャル TTY) ACLを使用し、 “c”, “e”, “cisco”, “c1sco”のようなパスワードは避け、TACACS+のようなAAAシステムを使用する。 • 共用アカウントを使用せず、特権レベルや制限コマンドを使用する。 • 不要なサービスは停止し、SNMPdを制限する。 • ロギングを行う。（過剰にならないように！） • 設定とROMMON/IOSイメージの整合性 • ルーターを “フォレンジック対応”にする • その他

ルータのセキュリティ • ルータのセキュリティ 101 （初級編） • 最大のセキュリティ危険性は？ • 顧客診断/NOC担当者が、共用／共通パスワードや管理者ACL、TACACS+、サーバーIP等を含む設定を顧客に漏らす。 • フィルタリング・スクリプトやpeerの許可を検討する。 • どのプログラムやアプリケーションにも言えるように、クライアントからの入力を信用しない。 • 管理しているルーターを顧客が外して自分のルーターを接続したらどうなるか？（管理ACL、フィルタリング、等）

インフラのセキュリティ リンクの “タイプ” ルーターの “タイプ” 中継エッジピア (IX またはプライベート) コアアクセス (/30) アクセス顧客（アクセス）顧客（中継） ISPm ISPy ISPj ixpr ISPa cr tr cr cpe ccr cpe cr tr cr ar cpe cr cpe ISPy ISPb ar ppr ccr cpe ar ISPm ISPk cpe cpe ISPx

インフラのセキュリティ • インフラのセキュリティ • インターネットは”最重要インフラ”とみなされる。 • ルーティング情報のフィルタリングとトラフィックのフィルタリング（IPレイヤ）は相互補完する。 • BGP と DNSは中核となるプロトコルである。 • 貴社のバックボーン：大規模なファイアウォール、または通過ネットワーク？ • データ中心　対　中核インフラに基づく検出 • データ中心：インライン（”パケット全部”） • インフラ／分散：Netflow（”ヘッダーのみ”） • 両者の最適な組み合わせを見つける • 拡張性 • CAPEX • 抽出 Netflow (各個のパケットを見逃す確率が高い）に対し、大規模POPごとにひとつのインライン装置（ミラーリングされたトラフィック）

インフラのセキュリティ • 新しいACLs “タイプ” 受信 ACLs [rACL] インフラ ACLs [iACL] 通過 ACLs エッジ [tACLe] 通過 ACLs アクセス [tACLa] ルーター “タイプ” エッジコアアクセス顧客

インフラのセキュリティ • 新しいACLs “タイプ” • iACLs: インターネットに接続できる誰もが貴社のネットワークの中核と”話す”必要がどうして必要なのか？（トラフィックはインフラ段階で振り向けられる） • 体系的なアドレス計画が必要 • rACLs: ルータ・プロセッサの防御を助ける（トラフィックはルータで振り向けられる） • tACLs: 転送するパスをフィルタリング（ネットワークを”通過”するトラフィック） • 短く一般化し、例外を避ける • “既定設定値は許可”とするか”既定設定値は拒否”とするか？

インフラのセキュリティ • 新しい ACLs “タイプ” • エッジ部で、スプーフィング防止のACLs/uRPFと組み合わせる • 管理トラフィック (telnet/SSH, SNMP, TFTP, syslog, AAA, 等) と、ルーティング・プロトコルを忘れない • Pingとtracerouteをどうするか (ICMP/UDP): 入力と出力（障害診断のため） • 他のタイプの “フィルタリング” • Re-coloring (QoS): AS境界で強制実施 • レート制限: 排除すべきものとそれが破壊するものは ? • ルーターを守るための他の選択肢 • RPへのトラフィックをレート制限 (データ・パント/スロー・パス） • ”管理用トラフィックを発生するオプション”（ログ付きのACLsなど）を避ける • IP オプション, ICMP, mcast “フィルタリング”, 等

インフラのセキュリティ • ACLs (アクセス制御リスト) • 常に（できる限り）コンパイルされたACLsを使用し、log[-input]、source port、output ACLsなどは避ける。 • どこでフィルタリングするか：エッジ、コア、通過、ピアリング？ • 何をフィルタリングするか：プロトコル、src/dst IP、src/dstポート、ヘッダ？ • だれがフィルタリングをするか：レイヤ１、（家庭のブロードバンドユーザを持つ）レイヤ2/3プロバイダ、企業（ファイヤウォール）？ • どちらの方向：エンドユーザへ、またはエンドユーザから（インターネットをユーザから守るのか、その反対か、または両方か） • ハードウェアとソフトウェアの能力により：マイクロコード/IOS、及びエンジン　　(-: 0, 1, 4; +: 2; ++: 3) • 解決法の拡張性（分散ACLs方針の維持は容易でない） • これらのフィルターをいつまで入れておくべきか？

インフラのセキュリティ • uRPF (unicast Reverse Path Forwarding) • シングルホーム顧客用の厳格なuRPF（送出側IPへのルートが、逆に入口インターフェースを指し示す） • マルチホーム顧客用の緩いuRPF（ルーティングテーブルにルート/ネットワークのプリフィックスが存在する） • 緩いuRPFは、顧客のスプーフィングから保護しない • 貴社の顧客の設定により、厳格/緩い方策を適用する • 統計によればuRPFは実際に運用されていない。（緩くもなく、厳格でもない）

インフラのセキュリティ • 他の (“エッジ”のみ) 機能 • NBAR (Network Based Application Recognition) • いくつかの大学のネットワークにおいて、P2Pトラフィックを識別するため、カスタマイズさrたCisco PDLMs（パケット記述言語モジュール）と共に用いられる。 • TCP インターセプト • 通常、企業のファイアウォールで行われる。 • 今日のルータに、他に何を望むのか? ;-)

インフラのセキュリティ • BGP (Border Gateway Protocol) • BGPセッションをハイジャックするのは、思う（言われる）ほど容易でない • BGP フラップ (ダンパリング)、又はルート変更がより一般的 • 簡単なパスワードや、BGPを使うルータでVTY ACLがない：反体制/SPAM集団にとってCoolな“warez”(eBayアカウントや有効なCC番号のように） • フィルタリング： • コアでは既定値なしのルーティング（マグネット効果を避けるため） • 同じ厳格な方針を、顧客よりも中継/ピアに適用する (AS_path, プリフィックス, max-pref, RIR 割り当て, 等) • Martian/Bogons/RFC1918/RFC3330 • ISPsは、 AR<->CPE /30のアナウンス/ルート/フィルターを止めつつある • BGPセッションのアカウント（特に全メッシュ配備、RRs上、及びピア・ルータ上）及び、md5の使用

インフラのセキュリティ • BGP (Border Gateway Protocol) • Origin-AS/prefixの関係は決して確認されない • AS_pathを主要な場所へ (特にDNSルートサーバ) • 次は何か ? • セキュア BGP • RIRs が PKIs を実行し、 CAsのようにふるまう • “所有権”の確認 (Origin-AS/prefix) • 署名入りBGP更新メッセージ • SoBGP • 分散型Origin-AS/prefixチェック • 新しい “BGP セキュリティ” メッセージ • IGP (Internal Gateway Protocol) • 適用範囲はより限定されるが、保護するのを忘れないように　　　　（OSPF, IS-IS, 等）

インフラのセキュリティ • DNS (Domain Name System) • 最近かなりの攻撃がある • ネットワーク/システムの不適切な設定と切断されたクライアントによるDNSの“悪用”: AS112プロジェクト　（分散サーバが negative RFC1918 PTR queriesに応答) • IP anycastは助けになるがデバッグがより困難になる（どのサーバが実際にエラーを発生しているのか？） • gtld DNS サーバからの／への発信元-AS と AS_パスを監視するキー • BGP/DNS “乗っ取り（ハイジャック）”の脅威は現実か ?

インフラのセキュリティ • 障害調査: BGP, Netflow (及びACL ログ) • Hop-by-hop DDoS 攻撃をACLsやipソース・トラッカーを使って追跡するのはあまり有効でない • BGP更新メッセージや（抽出されたNetflowの）使用記録は次世代の高帯域IDSの一部となり、履歴データとして不可欠：より高いレベルの視点で（つまり流れを）見るNetflowと、低いレベルの視点で（つまり実際のデータを）見るためのトラフィック・ダンプ • 分散ルートコレクタはより見易い • これらの断片を組み合わせることで、有効な異常検出システムを構築し、履歴データの優れた供給源となる（より良いトラフィック管理を可能にすることに最も近い;-)

分散サービス妨害（DoS） • DDoSの傾向 • 過去: 帯域の悪用、バグの利用、TCP SYN, UDP及びICMP氾濫（アンプ） • 現在: • SPインフラ、非偽装の発信元（150kの以上のbotsがあっても誰も気にしない）、及びリフレクターに対するPPS (packet-per-second) • 寿命の短いルートアナウンス (通常SPAMのため) • 将来: • QoS/”拡張ヘッダー” • CPU (IPsec/SSL/TLS/等のように、cryptoが多用されるタスク) • 完全な状態情報とトラフィックを追跡する必要のある状況で、通常のトラフィックに隠され、混じり、またはその一部にさえなているプロトコルの複雑さや他の攻撃 • 分散コンテンツネットワークにおいて、キャッシングされない項目

分散サービス妨害（DoS） • DDoS 検出 • ACLs, キュー・カウンタ, NMS (CPU, インターフェース・カウンタ, など) • Netflow 及び dark IP space/bogons/backscatter 監視 • “Honeybot” 手法 • IRC/P2P/などを使った通信を監視 • bots を “セーフ・モード”で実行 • honeypot 技術に関するLanceのプレゼンを参考 • 顧客 ;-) • DDoS の抑制 • ACLs と CAR (レート制限) • null0 ルーティング (blackholing), (anycast) sinkhole, shunt, 　トラフィック・ルーティング、及び“クリーニング” • Propagated blackholing (special community)

分散サービス妨害（DoS） • ワームの傾向 • “夏のワーム”, botsとbotnets、及びルーティングの安定度への影響 • 最近のワームの作成者達が　手がかりや他の目的を持っていたとしたら？ • ワームの “心臓部”はますます発達し、より分散された負荷になりつつある • ワーム == SPAM (すなわち商業化) ? • SPがどの方針を適用するか: インフラに損害を与えるまですべてをオープンにしておくか、早期の警告により何日間も締出すか？ • 競争に勝てるか？（1時間以内で分析して軽減） • “すべてをIP上に”の後、傾向は“すべてをHTTP[s]上に (すなわち、ファイアウォールを回避する101）: もし次のものが80/tcp上で広まったら ? ;-) • ワームについてJoseの話を聞くこと

分散サービス妨害（DoS） 流れ (抽出された) Netflow 集約された Netflow ルータの“タイプ” (SNMP) 警告エッジアクセス • Netflowに基づく検出 • 流れ(src/dst IP, src/dst ポート, プロトコル, ToS, もし、負荷がなければ) • 通常のトラフィック分類 (90% TCP, 8% UDP, <1% ICMP/GRE/IPsec/その他 - 小パケットの50%) • IDSと同じような微調整が必要 ixpr NOC tr controller ccr collector collector tr ar ar ppr ccr ar

分散サービス妨害（DoS） • トラフィック迂回 (及び検査/クリーニング） • 厳格なフィルタリングの代替（通常これは攻撃者が勝ったことを意味する）? • レイヤ3以上とステートフル情報が必要な場合に要求される • BGPかPolicy Based Routing (PBR)、またはその両方が開始のきっかけ • トンネル: MPLS, GRE, L2TPv3, IPsec, 等 • このような “クリーニングセンター”はネットワーク全体に分散されているべき (大規模 POPs, 既知の攻撃侵入口など,) • 同じ概念をhoneynetsにも適用できる（分散型honeynets/honeyfarms)

分散サービス妨害（DoS） Flows “攻撃” トラフィック “良い” トラフィック “悪い” トラフィック • トラフィック迂回 (及び検査/クリーニング) ixpr cr tr cr ccr cr tr cr cr ar server ppr ccr ar ルーター “タイプ” エッジ検査アクセスコア

他の最近の新しい危険性 • IPv6 • IPv6は、IPv4を128ビット・アドレスフィールドにしたものではない • 新規/更新されたプロトコ−ルと新規具体化 • 同じ古く既知のバグは新しいコードに残る • 現在の IPv6 “ネットワーク” は大規模な実験室! • IPv6セキュリティに関するitojunのプレゼンを参考 • Inter-AS MPLS VPNs • Multi-Protocol Label Switchingは、FRやATMのようなレイヤ2の技術と同様に安全であるとみなされている: しかし、環境はIPベースであり、より一層複雑でオープンである • Inter-Service プロバイダ MPLS VPNs は transitive trustを示唆し、AS境界はもうない

他の最近の新しい危険性 • 合法的インターセプト • 多くの国で積極的に展開されている • ネットワーク・オペレーションがトラフィックをダンプするための便利な遠隔スニファーで、祈ったり、“debug ip packet details”と入力した後で“Return”を押すたびに“しまった!”と言う必要がない。 • アタッカが同じことをするための簡単な方法か? • ルータは、あなたが所有する唯一の装置ではなく、MD (Mediation Device) もその一部である。

他の最近の新しい危険性 • もしこれが氷山の一角だったとしたら… • … そして誰かが、フォワード経路のコード中のバグを見つけだしたら？ • … そしてCisco IPv4ウェッジ・バグが漏れたり、一般に発表されてしまったら？ • Core/Edgeの“手っ取り早い”アップグレードに対し、 bugscrub ? • non-diversityの影響/危険性 (ハードとソフト) ? • Cisco IOS 脆弱性に関するFXのプレゼンを参考 • “故障した” デバイス • [欠陥のあるルータ] NTP “DDos” • tcp.win == 55808 ?

結論 • 結論 • 参考 • バックボーン及びインフラのセキュリティ　プレゼンテーション • http://www.securite.org/presentations/secip/ • (分散) サービス妨害（DoS)　プレゼンテーション • http://www.securite.org/presentations/ddos/ • Q&A Image: http://www.inforamp.net/~dredge/funkycomputercrowd.html

Nicolas FISCHBACH シニアマネージャー、IP技術/セキュリティ - COLT Telecom