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
wa6sn
June 06, 2024
Technology
4.1k
4
Share
不要な 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
450
dev 補講: プロダクトセキュリティ / Product security overview
wa6sn
1
3.4k
開発者向け MySQL 入門 / MySQL 101 for Developers
wa6sn
47
13k
Other Decks in Technology
See All in Technology
M5Stack CoreS3とZephyr(RTOS)で Edge AIっぽいことしてみた
iotengineer22
0
290
AI バイブコーティングでキーボード不要?!
samakada
0
610
Anthropic「Long-running a gents」をGeminiで再現してみた
tkikuchi
0
160
ハーネスエンジニアリングをやりすぎた話 ~そのハーネスは解体された~
gotalab555
5
1.8k
AI: Making Admin and Users, Lives Better
kbmsg
0
110
Oracle AI Database@AWS:サービス概要のご紹介
oracle4engineer
PRO
4
2.4k
独断と偏見で試してみる、 シングル or マルチエージェント どっちがいいの?
shichijoyuhi
1
120
Microsoft 365 / Microsoft 365 Copilot : 自分の状態を確認する「ラベル」について
taichinakamura
0
350
Expiration of Secure Boot Certificates for vSphere Virtual Machines
mirie_sd
0
110
EMから幅を広げるために最近挑戦していること / Recent challenges I'm undertaking to expand my horizons beyond EM
hiro_torii
1
120
UIライブラリに依存しすぎないReact Native設計を目指して
grandbig
0
140
基盤を育てる 外部SaaS連携の運用
gamonges_dresscode
1
120
Featured
See All Featured
Exploring anti-patterns in Rails
aemeredith
3
320
Into the Great Unknown - MozCon
thekraken
41
2.4k
SERP Conf. Vienna - Web Accessibility: Optimizing for Inclusivity and SEO
sarafernandez
2
1.4k
Art, The Web, and Tiny UX
lynnandtonic
304
21k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
508
140k
AI Search: Implications for SEO and How to Move Forward - #ShenzhenSEOConference
aleyda
1
1.2k
The Pragmatic Product Professional
lauravandoore
37
7.2k
Building Flexible Design Systems
yeseniaperezcruz
330
40k
Pawsitive SEO: Lessons from My Dog (and Many Mistakes) on Thriving as a Consultant in the Age of AI
davidcarrasco
0
120
Six Lessons from altMBA
skipperchong
29
4.2k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
38
2.8k
Designing for humans not robots
tammielis
254
26k
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