Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
不要な DNS リソースレコードは消そう / Delete unused DNS records
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
wa6sn
June 06, 2024
Technology
4.2k
4
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
不要な DNS リソースレコードは消そう / Delete unused DNS records
https://yuru-sre.connpass.com/event/317749/
の LT 資料です
wa6sn
June 06, 2024
More Decks by wa6sn
See All by wa6sn
マルチアカウント環境での、そこまでがんばらない RI/SP 運用設計
wa6sn
2
1.4k
クロスアカウントな RDS Snapshot Export による カジュアルなデータ集約の仕組み
wa6sn
3
470
dev 補講: プロダクトセキュリティ / Product security overview
wa6sn
2
3.5k
開発者向け MySQL 入門 / MySQL 101 for Developers
wa6sn
47
13k
Other Decks in Technology
See All in Technology
クレデンシャル流出 ― 攻撃 3 時間 vs 復旧 10 時間。この非対称性にどう備えるか
kazzpapa3
3
560
ロボティクスの技術 / Robotics Technology
ks91
PRO
0
130
Deep Data Security 機能解説
oracle4engineer
PRO
2
110
本当の”仕事”を手放せる未来が見えた
mu7889yoon
0
110
元銀行員がAIだけでアプリを量産!「バイブコーディング実演セミナー 」
tatsuya1970
0
110
PostgreSQL 19 新機能概要 OSC Hokkaido 2026
nori_shinoda
0
240
脱SaaS!FDEを支えるプロビジョニングと分離設計
knih
0
300
Claude Codeをどのように キャッチアップしているか
oikon48
13
8.8k
千葉での単身赴任からAWSをやり続け、千葉に戻ってきた話
yama3133
1
120
AIチャットの改善から見えた、良いAI体験とは / What Constitutes a Good AI Experience: Insights from Improving AI Chat
kubode
0
120
Zenoh on Zephyr on LiteX
takasehideki
2
110
アラート調査向けAIエージェントの本番導入とその後/AI Agents for Alert Investigation: Production Deployment and After
taddy_919
0
100
Featured
See All Featured
What does AI have to do with Human Rights?
axbom
PRO
1
2.2k
The Curse of the Amulet
leimatthew05
2
13k
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
780
Accessibility Awareness
sabderemane
1
140
RailsConf 2023
tenderlove
30
1.5k
How To Speak Unicorn (iThemes Webinar)
marktimemedia
1
490
How to build a perfect <img>
jonoalderson
1
5.7k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
34
2.8k
Leveraging Curiosity to Care for An Aging Population
cassininazir
1
270
Build your cross-platform service in a week with App Engine
jlugia
234
18k
Building Applications with DynamoDB
mza
96
7.1k
Game over? The fight for quality and originality in the time of robots
wayneb77
1
200
Transcript
不要な DNS リソースレコードは消そう!(一敗) 2024/06/06 @ゆる SRE勉強会 #6 LT 1
$ whoami @wa6sn CCoE っぽいこと、データ基盤、セキュリティ、データベースなど 今年の目標 人と話す https://speakerdeck.com/wa6sn を 4
つぐらいに増やす 2
今日 サービス運用の過程で、様々な資産の棚卸しを行うと思いますが、 それが甘かった (ゆるかった?) ことで発生したことを話します さまざまな配慮により、一部ぼかしています 不要なリソースレコードはセキュリティリスクにつながるので消そう DNS のそれに限らず、不要なリソースはマメに消そう 懇親会は、せっかくオフラインなので、こういう話を聞きたいです
3
発端 コーポレートチーム「こんなメールが届いたんですが ……」 4
本当? 本当でした ドメインの乗っ取りって本当にあるんだなあ ※ 今回は善意の報告であり、実害を被ったわけではありません 5
DNS takeover DNS リソースレコードについて、紐づけ先が利用終了したあともレコードを残したまま になってしまっていることを利用し、第三者がそのドメインの乗っ取りを図る攻撃手法 特に目新しいものではなく、古くからある攻撃 Subdomain takeover や NS
takeover は、そのより細かい分類にあたる https://jprs.jp/tech/material/iw2020-lunch-L3-01.pdf が詳しいです "jprs iw2020 lunch" で検索すると出ます 6
例 1. 「イベント用ページを作りました! Netlify でホスティングして CNAME で event2023. に向けますね。
」 # wa6sn.com は wa6sn 社が所有するドメイン event2023.wa6sn.com. 300 IN CNAME temp-event.netlify.com. 2. 「イベントが終わったので、 Netlify のサイトは消しておきます!」 一方、リソースレコードを消し忘れる 3. 忘れたころに誰かが Netlify で temp-event.netlify.com を取得する。 event2023.wa6sn.com. にアクセスした人が、意図しないページに飛ぶ 7
例の解説 「建物を取り壊すなら、案内板(レコード)も外さないといけない」 任意のサブドメインを指定して取得できる Netlify や Vercel のような サービスでは、 temp-event.netlify.com. は誰でも取得できるので、
DNS リソースレコードも同時に消さないと、第三者が takeover できてしまう その他、 S3 バケットの Web hosting 機能が悪用された例も https://blog.flatt.tech/entry/s3_security CNAME レコードの例だけでなく、 AWS の Elastic IP のような 「共有プールから払い出されるような IP」を A レコードで指定している場合も、 第三者による takeover が起こりうる 8
補足 : NS takeover ネームサーバにおいても同様の仕組みでドメイン名を takeover できる 「委任先」が無くなっているのを確認して、なりかわるイメージ サービス提供者側が takeover
を防ぐような仕組みを用意していることがある https://github.com/indianajson/can-i-take-over-dns のような、 Vulnerable な DNS Provider かどうかをリストするようなリポジトリもある AWS の Route53 はネームサーバとしては Not Vulnerable(安全) https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/protection-from- dangling-dns.html 9
対応 DNS takeover という攻撃の概念を社内で共有した 会社にある全 AWS アカウントの Route53 に設定されているリソースレコードを 列挙・共有しつつ、レコードタイプ別にリスク判断と棚卸し
「 CNAME で向き先が Vercel や Netlifiy のように任意のサブドメインを取得できるもの」は リスク高、 「向き先が CloudFront」ならドメインの左端部分はランダム化されているのでリス ク低、みたいな それはそうと、使っていないものは消してほしいな、といった呼びかけ 10
わりとポロポロ 11
潜在的なリスクが 12
見つかるのであった 13
感想 クラウドサービスが前提になった昨今、様々なリソースを「作る」ハードルは 下がったけど、 「捨てる」ことまで気が回っていないことも多い(気がする) 思った以上に「不要なもの」は堆積する 意識しないと不要なものは掃除されないがち 掃除するリスクが高いと判断されて残ったまま、背景が分からなくなりがち 発覚したものは 5〜 10
年物のリソースばかり 今回は善意の報告がきっかけで運が良かったけど、 いつもそうとは限らないので気を引き締めていきたい 14