経路ハイジャックとROAの話

実際に経路ハイジャックにあった体験談をもとにした対策や監視、対策の一つとして取り組んでいるRPKI（ROA作成）ついてIRS31で発表した際の資料になります。

Transcript

1. 経路ハイジャックとROAの話 2019/10/17 (C) Copyright 1996-2016 SAKURA Internet Inc さくらインターネット株式会社 技術本部 バックボーンチーム 山口 勝司
2. はじめに • 本資料は2019年10月17日に開催されたIRS31での発表で使用した資料になり ます。 • 一部情報の削除、誤りの修正、補足説明の追加など、発表時に使用した資料と は異なる部分があります。 • 本資料に含まれる情報は2019年10月15日時点の情報に基づいています。 2
3. 本日お話したいこと • 実際に経路ハイジャックされた話と対応 - 会場の運用者の皆様と対応のノウハウをディスカッションしたい • 経路の監視してますか？ - その監視で経路ハイジャックに本当に気づけますか？ • RPKI（ROA作成）で苦労したこと - 実は簡単ではなかったROA作成 3
4. 経路ハイジャック対応手順 • 経路ハイジャックに対しては対応手順が以前からあった • 今回のケースではこの手順では対応できなかった • 何も対策してなかった訳ではありませんのでご承知おきください 4 経路奉行のアラートメール受信 ⇒ Looking Glass で経路の広報確認 ⇒ 広報が止まっていた場合は静観 ハイジャックされた経路のmore-specificを広報 ⇒ 必要に応じIRR登録やUpstreamへの連絡 ⇒ Webに障害情報の掲載 ハイジャックが止まったことを確認したら ⇒ more-specificの経路広報停止 ⇒ 必要に応じIRR削除やUpstreamへの連絡 ⇒ Webに掲載した障害情報の更新
5. 経路ハイジャックの認知 • 2019/07/31 社内Slackで１通のメッセージが飛んできた 5 59.106.0.0/17（弊社AS9370広報）に含まれる 59.106.15.0/24 が AS21547 から広報されているみたい？？
6. 経路ハイジャックされたIPアドレス • 59.106.15.0/24 • 弊社サービス用として利用していたアドレス • 経路ハイジャックされた時点では利用していなかった • 結果としてお客様に影響はなかった • 東京地区（AS9370）で分割利用 • 59.106.0.0/17としてインターネットに広報 • JPIRR・RADBにOrigin AS9370として登録 • 1年前の2018年7月にも同経路のハイジャックが発生 • その際は問い合わせに返信も無かったが自然収束 6
7. 調査でどのようなツールを使っているか • 以下のツールを使うことが多い • ハリケーン • https://bgp.he.net/ • 最低限の情報が見やすくまとめられている • 情報の更新は遅く1-2日は掛かっている • RIPE • https://stat.ripe.net/ • 非常に高機能で知りたい情報の多くはここで得られる • Looking Glass • 各RIRのリージョンで何か所か 使うところを決めておくと良い 7 1カ月間もハイジャックされていたままで気付かなかった BGPlayの機能はとても便利
8. 調査でどのようなツールを使っているか • BGPMon（bgpstream.com） • AS21547のUpstreamのAS13536とその上のAS6939周辺に伝搬している • RIPEのBGPlay同様に経路変動を可視化された情報が提供される • 今回のハイジャック：https://bgpstream.com/event/210236 8
9. 詳細の調査 • 国内には問題の経路は殆ど入ってこなかった模様 • RIPE のRC(観測ポイント)は複数あるがRC6(大手町)で観測されたのはAS6939 （HE）経由のパスでAS25152（K-ROOT-Server）のみ • IIJやGINなどの国内主要トランジッターのLookingGlassでは観測できなかった • NewYork(RC11)やPaloAlto(RC14),Maiami(RC16) などの北米では他の地域より多くのASで観測できていた • 日本はフィルタを比較的しっかり書くから入ってこなかった？ • 問題の経路はピアだけに広報されていた？ 9 理由は分からないが影響は局所的だった模様
10. 対応 • まずはAS21547に連絡したい • PeeringDB • 連絡先の記載が無かった • 昨年ハイジャックされた時は連絡先があった • Aut-num Object • notify,changedには他組織（Upstream AS13536）の連絡先 • AS13536のサービス名と企業名と思われるドメインのアドレス • IPアドレスの管理者アドレスと個人アドレスと思われる • Whois • tech,noc,abuseには他組織（Upstream AS13536 ）の連絡先 10 Upstream AS に運用まで委託しているようなケース？？ 昨年のアドレス＋上流のAbuseとNOC(サービス名と思われるドメイン)宛にメール 同日はこれで様子見することに
11. 対応 • 約24時間経過しても返信が無かった • JPNIC岡田さんに相談してアドバイスを貰う • UpstreamASに相談してみると良いかも？ • nanog@nanogにメールしてみると良いかも？ • Upstream AS • 連絡先(2種あるドメインの1つ)は昨日のメールに返信なし… • そのもう１つ上となるとTier1相当のASしかない… • NANOG • 購読者が多くいきなりメールして波風が立たないだろうか… 11
12. 対応 • 連絡先を変えてAS13536に連絡 • PeeringDBのnoc,peering+IPアドレスの管理者の連絡先 • 色々なメールアドレスを巻き込んでメールを送った • 少し厳しめの表現でメールしてみた • その経路広報は許可していないから直ぐに止めるように！ • 昨年も発生しているので原因と対応を報告して！ • 迅速に対応してもらえた • 2019/08/01 15:30 広報停止を依頼 • 2019/08/01 21:00 謝罪のメールを受信 • 2019/08/02 経路広報停止を確認 12
13. 対応 • 原因は回答してくれなかった • 何が原因で広報されたのか？（意図的？設定ミス？） • なぜ過去に同一の経路ハイジャックが起きたのか？ • 再発しないように対策したのか？ • 深くは原因を追及しなかった • 原因を深く追求するより発生時の対応を優先すべき • 他のASで経路ハイジャックが起きる可能性は十分にある • 時間的な都合とあまり関わりたくない思い 13
14. 経路ハイジャックを検出する仕組みを作った • RIS Live (RIPE) • https://ris-live.ripe.net/ • BGPアップデートのライブフィード • RIPEの25RCが合計約250ピアから受信するアップデートメッセージを WebSocket JSON APIでストリーム配信 • 試験的な試みとして提供されている • Bgpalerter (NLNOG) • https://github.com/NLNOG/bgpalerter • RIS Liveのデータの処理に利用 • 不具合の修正と機能を弊社にて追加したブランチを利用 • https://github.com/tamihiro/bgpalerter/tree/br01 14
15. 経路ハイジャックを検出する仕組みを作った • 監視対象 • IRRに登録された弊社OriginのRouteObjectを対象とする • CronjobでRADBから毎日1回取得する • Slackへの通知 • 最低１ピアから経路ハイジャックのアップデートを受信した場合 • 同一経路について最低10ピアからwithdrawnアップデートを受信 した場合 15 １ピアのみから検出された/32の経路 ハイジャックも検知してアラート
16. 月に数回経路ハイジャックが発生しており効果を発揮 • 2019/10/15も経路ハイジャックが発生 • 弊社の複数のPrefixをAS41497がOriginで広報 • UpstreamのAS6762経由で局地的に伝搬 • RIPEのRC10（イタリア/ミラノ）のみで検知 • 約80分程で広報停止 16
17. 教訓と課題 • 経路ハイジャックを長期間検知できなかった • 経路奉行は国内の経路情報を用いた試験的サービス • 海外の局所的な経路ハイジャックを検知するには 別の仕組みを用意(適切なサービスを選択)する必要がある • 経路ハイジャックを止めてもらうために • 広報ASの返信が無ければUpstream ASに連絡するのは有効 • メールはできるだけ多くの連絡先を巻き込んで対応 • これでもダメな場合「nanog@nanog」に送ってみよう • 影響範囲を迅速かつ正確に特定する方法があると良い 17
18. 今回の経路ハイジャック事件には 直接関係ありませんが… ルーティングセキュリティ強化のため RPKIの導入を進めています。 18 経路ハイジャック対策として
19. 経路ハイジャック対策として RPKI（ROA作成）を9月末までに完了 19 ハリケーンのサイトではROA作成済のPrefixには緑のカギアイコンがつきます 日本国内の主要ホスティング事業者の商用ネットワークでは初？？
20. 直接は関係ないけど経路ハイジャック対策として 20 • 1年ほどの期間をかけて準備を進めていた • RPKIに限らず新技術の採用はかなり慎重になって進めたい • 何か失敗するとネガティブな発言がでてきてハードルが上がる • 何かに失敗してInvalidになるとその時点で経路障害の発生 • ほんとうにあったRPKIの話 • https://www.nic.ad.jp/ja/materials/iw/2018/proceedings/s03/s3-sugiyama.pdf • 社内手順の作成やドキュメントの整備も必要 • IPアドレスの運用は必ずしもルーティングの専門家がやるわけではない • テストPrefixでスタートし影響の少ないものから徐々に • 2018/03 社内のミーティングでROA作成をやることを宣言 • 2018/12 テストPrefixのROAを作成 • 2019/04-05 IPv6アドレスのROA作成開始 • 2019/08 IPv4アドレスのROA作成開始
21. ROA作成、実は難しかった • 非広報アドレスの扱い • 弊社では一部のIPv4アドレスを非広報としている （バックボーン機器のLoopbackアドレスなど） • RPKIでは使わないIPをAS0としてROA作成することを推奨（RFC6483） • 作成したらRIPE StatのRoutingConsistencyでInvalidASN表示になった • 各IRRにはAS9370で登録していたことが理由 • 経路情報、IRR、RPKIのどれかにミスマッチがあるとエラー表示する仕様 • 実害は無いけどなんか気持ち悪いよね… • IRRにはOriginAS0でRouteObjectは書けない仕様になっている • OriginAS0で書こうとすると表記のチェックでエラーが返ってきます 21 こんなケースではIRRには何も書かないのが正しいの？ ⇒次のセッションでJPNIC岡田さんからお話があるようです
22. ROA作成、実は難しかった • 歴史的経緯PIアドレスの扱い • 133.0.0.0/8に含まれる空間への対応は不十分 • 正確には作成はできるがAPNIC TALに反映することができない • APNICとJPNICのシステムの間の技術的な都合による • 歴史的PIのAPNICアカウントとは連携していないそう • 133.0.0.0/8以外にも同様のアドレスがある • JPNICに問い合わせれば対象かどうかを教えてくれる 22 JPNIC APNIC アカウントA APNIC アカウントB （歴史的PI） 将来的には連携できるようになると嬉しい
23. ROA作成、実は難しかった • 弊社AS間でIPアドレスを移動する場合 • 東京(AS9370)、大阪(AS9371)、石狩(AS7684)を運用 • サービスの都合でアドレスをAS間移動することがある • 作成後のROAがAPNIC-TALに反映するのに時間が掛かるかも？ • 急なアドレスの移動を行う場合などには困るかもしれない • 現在のJPNIC ROA Webの仕様 23 JPNIC TAL ・ユーザがRPKIWebで作成ボタンをクリックすれば直ぐに反映 APNIC TAL ・JPNICとAPNICの連携はJPNICの担当者が確認した上で手動でAPNICにrsyncしている 即時反映しないので作成ミスをした場合に影響を最小限に抑えられるメリットがある反面 休日や夜間などをはじめとして即時の対応は難しい。 当面の間は納期に余裕をもって作業をすることにした
24. ROA作成、実は難しかった • 弊社の割り振りPrefixの一部を他組織より広報するケース • 例えば/16の割り振りの中で/24を別ASから広報する • Multiple Originとかパンチングホール的な使い方 • 余り好ましくは無いが様々な事情で必要となっている • この空間のROAを作成するのは難しい • 他組織が広報するAS番号が変わる可能性がある • 例えば、組織の変更や、DDoS攻撃緩和サービスの利用など… • 広報ASの変更について細かいルールが決められていないケースもある • ある日突然Invalidになってしまうと困る 24 今回はこの空間の他組織広報部分についてはROA作成をしないことにした
25. ROA作成、実は難しかった • /19の空間の一部の/24が他組織AS広報となっている場合 • インターネットには/19で弊社がAS9370で広報 • /24の一部空間は他組織ASからパンチングホール的に広報 • RPKIのPrefix、Origin、Max-Lenでは表現が難しい • ROAを/19-/24 とすると他AS広報の経路がInvalidとなってしまう ※ 他ASOriginの/24（exact match）のROAを作成すれば良いが 前ページ記載の通り、今回はROAを作成しないものとした • /19（exact match）とするとDDoS対策などで/24の広報を弊社が行えなくなる 25 弊社への割り振り空間（AS9370広報） XXX.YYY.192.0/19 他組織AS広報 XXX.YYY.210.0/24 他組織AS広報 XXX.YYY.222.0/24
26. ROA作成、実は難しかった • 完璧ではないけどこんな書き方をした • 他組織AS広報Prefix以外を埋めるようにROAを作成した 26 割り振り空間 XXX.YYY.192.0/19 他組織AS広報 XXX.YYY.210.0/24 他組織AS広報 XXX.YYY.222.0/24 XXX.YYY.192.0/19-19 192.0 /20-24 208.0 /23-24 211.0 /24 212.0 /22-24 216.0 /22-24 220.0 /23-/24 運用上あまりキレイなやり方とは言えない ⇒他組織との取り決めや広報の方法の見直しなどを長期的に考えていきたい
27. ROAの状態監視 • 作成したROAが本当に世界中で参照可能か監視が必要 • JPNICやAPNICのシステム障害などでUnknownになるかも？ • 我々のオペミスや更新作業の失念で未登録やInvalidになるかも？ • 監視アプリを用意した • GitHubに作成したROAマスタと実際のROAキャッシュ情報を比較 • 変化があった場合はSlackに通知する仕組み • キャッシュサーバにはCloudFlareのGoRTRとOctoPRKIを利用 27
28. 会場の皆様とディスカッション • 経路ハイジャックの検出と対応 • どんな方法でハイジャックを検出していますか？ • 不正な経路広報を止めてもらうために良い方法はありますか？ • どのように影響範囲と伝搬範囲を迅速に特定していますか？ • ROAの作成 • 当初の想定以上に考慮が必要な点が多かった • 計画している人は早めの準備を（JPNICも相談に乗ってくれる） 28