PacSec.JP 2003 - Pacific Security Japan 安全なネットワークインフラの展開 Nicolas FISCHBACH シニア マネージャー、IP技術/セキュリティ - COLT Telecom [email protected] - http://www.securite.org/nico/ version 1.0 PacSec.JP 2003 - Pacific Security Japan 議題 » ルータのセキュリティ » » » » > ルータのセキュリティの基本 インフラのセキュリティ > フィルタリング, BGP/DNS > フォレンジック 分散サービス妨害（DoS） > 攻撃、ワーム、及びbotnetsの傾向 > 検出と軽減 他に最近見られる新しい危険性 > IPv6, MPLS, Lawful Intercept, 等 結論 © 2003 Nicolas FISCHBACH 2 PacSec.JP 2003 - Pacific Security Japan ルータのセキュリティ » ルータのセキュリティ 101（初級編） > インフラの堅牢なセキュリティは、ルータの確実なセキュリティから始まる > パケット転送対”受信”パケットの性能 > どのシステムにも当てはまるように： - VTY (バーチャル TTY) ACLを使用し、 “c”, “e”, “cisco”, “c1sco”のようなパ スワードは避け、TACACS+のようなAAAシステムを使用する。 - 共用アカウントを使用せず、特権レベルや制限コマンドを使用する。 - 不要なサービスは停止し、SNMPdを制限する。 - ロギングを行う。（過剰にならないように！） - 設定とROMMON/IOSイメージの整合性 - ルーターを “フォレンジック対応”にする - その他 © 2003 Nicolas FISCHBACH 3 PacSec.JP 2003 - Pacific Security Japan ルータのセキュリティ » ルータのセキュリティ 101 （初級編） > 最大のセキュリティ危険性は？ - 顧客診断/NOC担当者が、共用／共通パスワードや管理者 ACL、TACACS+、サーバーIP等を含む設定を顧客に漏らす。 - フィルタリング・スクリプトやpeerの許可を検討する。 > どのプログラムやアプリケーションにも言えるように、クライアントから の入力を信用しない。 - 管理しているルーターを顧客が外して自分のルーターを接続したら どうなるか？（管理ACL、フィルタリング、等） © 2003 Nicolas FISCHBACH 4 PacSec.JP 2003 - Pacific Security Japan インフラのセキュリティ リンクの “タイプ” ルーターの “タイプ” 中継 ISPm エッジ ピア (IX またはプライベート) ISPy コア ISPj アクセス アクセス (/30) 顧客（アクセス） ixpr ISPa 顧客（中継） cr tr cr cpe ccr cpe cr tr cr cr ar cpe cpe ISPb ppr ar ccr cpe ar ISPk ISPm ISPx © 2003 Nicolas FISCHBACH ISPy cpe cpe 5 PacSec.JP 2003 - Pacific Security Japan インフラのセキュリティ » インフラのセキュリティ > インターネットは”最重要インフラ”とみなされる。 > ルーティング情報のフィルタリングとトラフィックのフィルタリング（IPレ イヤ）は相互補完する。 > BGP と DNSは中核となるプロトコルである。 > 貴社のバックボーン：大規模なファイアウォール、または通過ネットワ ーク？ > データ中心 対 中核インフラに基づく検出 - データ中心：インライン（”パケット全部”） - インフラ／分散：Netflow（”ヘッダーのみ”） - 両者の最適な組み合わせを見つける . 拡張性 . CAPEX . 抽出 Netflow (各個のパケットを見逃す確率が高い）に対し、大規模POPご とにひとつのインライン装置（ミラーリングされたトラフィック） © 2003 Nicolas FISCHBACH 6 PacSec.JP 2003 - Pacific Security Japan インフラのセキュリティ » 新しいACLs “タイプ” 受信 ACLs [rACL] インフラ ACLs [iACL] 通過 ACLs エッジ [tACLe] 通過 ACLs アクセス [tACLa] ルーター “タイプ” エッジ コア アクセス 顧客 © 2003 Nicolas FISCHBACH 7 PacSec.JP 2003 - Pacific Security Japan インフラのセキュリティ » 新しいACLs “タイプ” > iACLs: インターネットに接続できる誰もが貴社のネットワークの 中核と”話す”必要がどうして必要なのか？（トラフィックはインフ ラ段階で振り向けられる） - 体系的なアドレス計画が必要 > rACLs: ルータ・プロセッサの防御を助ける（トラフィックはルータ で振り向けられる） > tACLs: 転送するパスをフィルタリング（ネットワークを”通過”する トラフィック） > 短く一般化し、例外を避ける > “既定設定値は許可”とするか”既定設定値は拒否”とするか？ © 2003 Nicolas FISCHBACH 8 PacSec.JP 2003 - Pacific Security Japan インフラのセキュリティ » 新しい ACLs “タイプ” > エッジ部で、スプーフィング防止のACLs/uRPFと組み合わせる > 管理トラフィック (telnet/SSH, SNMP, TFTP, syslog, AAA, 等) と、ルー ティング・プロトコルを忘れない > Pingとtracerouteをどうするか (ICMP/UDP): 入力と出力（障害診断の ため） » 他のタイプの “フィルタリング” > Re-coloring (QoS): AS境界で強制実施 > レート制限: 排除すべきものとそれが破壊するものは ? > ルーターを守るための他の選択肢 - RPへのトラフィックをレート制限 (データ・パント/スロー・パス） - ”管理用トラフィックを発生するオプション”（ログ付きのACLsなど）を避ける - IP オプション, ICMP, mcast “フィルタリング”, 等 © 2003 Nicolas FISCHBACH 9 PacSec.JP 2003 - Pacific Security Japan インフラのセキュリティ » ACLs (アクセス制御リスト) > 常に（できる限り）コンパイルされたACLsを使用し、log[-input]、source port、 output ACLsなどは避ける。 > どこでフィルタリングするか：エッジ、コア、通過、ピアリング？ > 何をフィルタリングするか：プロトコル、src/dst IP、src/dstポート、ヘッダ？ > だれがフィルタリングをするか：レイヤ１、（家庭のブロードバンドユーザを持つ） レイヤ2/3プロバイダ、企業（ファイヤウォール）？ > どちらの方向：エンドユーザへ、またはエンドユーザから（インターネットをユー ザから守るのか、その反対か、または両方か） > ハードウェアとソフトウェアの能力により：マイクロコード/IOS、及びエンジン (-: 0, 1, 4; +: 2; ++: 3) > 解決法の拡張性（分散ACLs方針の維持は容易でない） > これらのフィルターをいつまで入れておくべきか？ © 2003 Nicolas FISCHBACH 10 PacSec.JP 2003 - Pacific Security Japan インフラのセキュリティ » uRPF (unicast Reverse Path Forwarding) > シングルホーム顧客用の厳格なuRPF（送出側IPへのルートが、 逆に入口インターフェースを指し示す） > マルチホーム顧客用の緩いuRPF（ルーティングテーブルにルー ト/ネットワークのプリフィックスが存在する） > 緩いuRPFは、顧客のスプーフィングから保護しない > 貴社の顧客の設定により、厳格/緩い方策を適用する > 統計によればuRPFは実際に運用されていない。（緩くもなく、厳 格でもない） © 2003 Nicolas FISCHBACH 11 PacSec.JP 2003 - Pacific Security Japan インフラのセキュリティ » 他の (“エッジ”のみ) 機能 > NBAR (Network Based Application Recognition) - いくつかの大学のネットワークにおいて、P2Pトラフィックを識別する ため、カスタマイズさrたCisco PDLMs（パケット記述言語モジュール ）と共に用いられる。 > TCP インターセプト - 通常、企業のファイアウォールで行われる。 > 今日のルータに、他に何を望むのか? ;-) © 2003 Nicolas FISCHBACH 12 PacSec.JP 2003 - Pacific Security Japan インフラのセキュリティ » 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の使用 © 2003 Nicolas FISCHBACH 13 PacSec.JP 2003 - Pacific Security Japan インフラのセキュリティ » 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, 等） © 2003 Nicolas FISCHBACH 14 PacSec.JP 2003 - Pacific Security Japan インフラのセキュリティ » DNS (Domain Name System) > 最近かなりの攻撃がある > ネットワーク/システムの不適切な設定と切断されたクライアント によるDNSの“悪用”: AS112プロジェクト （分散サーバが negative RFC1918 PTR queriesに応答) > IP anycastは助けになるがデバッグがより困難になる（どのサー バが実際にエラーを発生しているのか？） > gtld DNS サーバからの／への発信元-AS と AS_パスを監視す るキー » BGP/DNS “乗っ取り（ハイジャック）” の脅威は現実か ? © 2003 Nicolas FISCHBACH 15 PacSec.JP 2003 - Pacific Security Japan インフラのセキュリティ » 障害調査: BGP, Netflow (及びACL ログ) > Hop-by-hop DDoS 攻撃をACLsやipソース・トラッカーを使って追 跡するのはあまり有効でない > BGP更新メッセージや（抽出されたNetflowの）使用記録は次世 代の高帯域IDSの一部となり、履歴データとして不可欠： より高 いレベルの視点で（つまり流れを）見るNetflowと、低いレベルの 視点で（つまり実際のデータを）見るためのトラフィック・ダンプ > 分散ルートコレクタはより見易い > これらの断片を組み合わせることで、有効な異常検出システム を構築し、履歴データの優れた供給源となる（より良いトラフィッ ク管理を可能にすることに最も近い;-) © 2003 Nicolas FISCHBACH 16 PacSec.JP 2003 - Pacific Security Japan 分散サービス妨害（DoS） » DDoSの傾向 > 過去: 帯域の悪用、バグの利用、TCP SYN, UDP及びICMP氾濫（アン プ） > 現在: - SPインフラ、非偽装の発信元（150kの以上のbotsがあっても誰も気にしな い）、及びリフレクターに対するPPS (packet-per-second) - 寿命の短いルートアナウンス (通常SPAMのため) > 将来: - QoS/”拡張ヘッダー” - CPU (IPsec/SSL/TLS/等のように、cryptoが多用されるタスク) - 完全な状態情報とトラフィックを追跡する必要のある状況で、通常のトラフ ィックに隠され、混じり、またはその一部にさえなているプロトコルの複雑さ や他の攻撃 - 分散コンテンツネットワークにおいて、キャッシングされない項目 © 2003 Nicolas FISCHBACH 17 PacSec.JP 2003 - Pacific Security Japan 分散サービス妨害（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) © 2003 Nicolas FISCHBACH 18 PacSec.JP 2003 - Pacific Security Japan 分散サービス妨害（DoS） » ワームの傾向 > “夏のワーム”, botsとbotnets、及びルーティングの安定度への影響 > 最近のワームの作成者達が 手がかりや他の目的を持っていたとしたら？ - ワームの “心臓部”はますます発達し、より分散された負荷になりつつある - ワーム == SPAM (すなわち商業化) ? > SPがどの方針を適用するか: インフラに損害を与えるまですべてをオープ ンにしておくか、早期の警告により何日間も締出すか？ > 競争に勝てるか？（1時間以内で分析して軽減） > “すべてをIP上に”の後、傾向は“すべてをHTTP[s]上に (すなわち、ファイ アウォールを回避する101）: もし次のものが80/tcp上で広まったら ? ;-) > ワームについてJoseの話を聞くこと © 2003 Nicolas FISCHBACH 19 » Netflowに基づく検出 > 流れ(src/dst IP, src/dst ポート, プロトコル, ToS, もし、負荷がなけれ ば) > 通常のトラフィック分類 (90% TCP, 8% UDP, <1% ICMP/GRE/IPsec/ その他 - 小パケットの50%) > IDSと同じような微調整が必要 ixpr NOC 流れ (抽出された) Netflow tr controller 集約された Netflow (SNMP) 警告 ccr collector collector PacSec.JP 2003 - Pacific Security Japan 分散サービス妨害（DoS） tr ルータの“タイプ” ar エッジ アクセス ppr ar ccr ar © 2003 Nicolas FISCHBACH 20 PacSec.JP 2003 - Pacific Security Japan 分散サービス妨害（DoS） » トラフィック迂回 (及び検査/クリーニング） > 厳格なフィルタリングの代替（通常これは攻撃者が勝ったことを 意味する）? > レイヤ3以上とステートフル情報が必要な場合に要求される > BGPかPolicy Based Routing (PBR)、またはその両方が開始の きっかけ > トンネル: MPLS, GRE, L2TPv3, IPsec, 等 > このような “クリーニングセンター”はネットワーク全体に分散さ れているべき (大規模 POPs, 既知の攻撃侵入口など,) > 同じ概念をhoneynetsにも適用できる（分散型 honeynets/honeyfarms) © 2003 Nicolas FISCHBACH 21 » トラフィック迂回 (及び検査/クリーニング) Flows ixpr “攻撃” トラフィック cr tr “良い” トラフィック cr “悪い” トラフィック ccr cr cr cr ppr ar ccr ar server tr ルーター “タイプ” エッジ 検査 PacSec.JP 2003 - Pacific Security Japan 分散サービス妨害（DoS） アクセス コア © 2003 Nicolas FISCHBACH 22 PacSec.JP 2003 - Pacific Security Japan 他の最近の新しい危険性 » 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境界はもうない © 2003 Nicolas FISCHBACH 23 PacSec.JP 2003 - Pacific Security Japan 他の最近の新しい危険性 » 合法的インターセプト > 多くの国で積極的に展開されている > ネットワーク・オペレーションがトラフィックをダンプするための便 利な遠隔スニファーで、祈ったり、“debug ip packet details”と 入力した後で“Return”を押すたびに“しまった!”と言う必要がな い。 > アタッカが同じことをするための簡単な方法か? > ルータは、あなたが所有する唯一の装置ではなく、MD (Mediation Device) もその一部である。 © 2003 Nicolas FISCHBACH 24 PacSec.JP 2003 - Pacific Security Japan 他の最近の新しい危険性 » もしこれが氷山の一角だったとしたら… > … そして誰かが、フォワード経路のコード中のバグを見つけだし たら？ > … そしてCisco IPv4ウェッジ・バグが漏れたり、一般に発表され てしまったら？ > Core/Edgeの“手っ取り早い”アップグレードに対し、 bugscrub ? > non-diversityの影響/危険性 (ハードとソフト) ? > Cisco IOS 脆弱性に関するFXのプレゼンを参考 » “故障した” デバイス > [欠陥のあるルータ] NTP “DDos” > tcp.win == 55808 ? © 2003 Nicolas FISCHBACH 25 PacSec.JP 2003 - Pacific Security Japan 結論 » 結論 » 参考 > バックボーン及びインフラのセキュリティ プレゼンテーション - http://www.securite.org/presentations/secip/ > (分散) サービス妨害（DoS) プレゼンテーション - http://www.securite.org/presentations/ddos/ » Q&A Image: http://www.inforamp.net/~dredge/funkycomputercrowd.html © 2003 Nicolas FISCHBACH 26
© Copyright 2024 ExpyDoc
