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
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
wa6sn
June 06, 2024
Technology
4
4.1k
不要な DNS リソースレコードは消そう / Delete unused DNS records
https://yuru-sre.connpass.com/event/317749/
の LT 資料です
wa6sn
June 06, 2024
Tweet
Share
More Decks by wa6sn
See All by wa6sn
マルチアカウント環境での、そこまでがんばらない RI/SP 運用設計
wa6sn
2
1.3k
クロスアカウントな RDS Snapshot Export による カジュアルなデータ集約の仕組み
wa6sn
2
370
dev 補講: プロダクトセキュリティ / Product security overview
wa6sn
1
3.3k
開発者向け MySQL 入門 / MySQL 101 for Developers
wa6sn
47
13k
Other Decks in Technology
See All in Technology
30万人の同時アクセスに耐えたい!新サービスの盤石なリリースを支える負荷試験 / SRE Kaigi 2026
genda
1
150
Amazon S3 Vectorsを使って資格勉強用AIエージェントを構築してみた
usanchuu
3
420
入社1ヶ月でデータパイプライン講座を作った話
waiwai2111
1
220
システムのアラート調査をサポートするAI Agentの紹介/Introduction to an AI Agent for System Alert Investigation
taddy_919
2
1.6k
CDK対応したAWS DevOps Agentを試そう_20260201
masakiokuda
1
160
分析画面のクリック操作をそのままコード化 ! エンジニアとビジネスユーザーが共存するAI-ReadyなBI基盤
ikumi
0
130
コスト削減から「セキュリティと利便性」を担うプラットフォームへ
sansantech
PRO
3
1.1k
ブロックテーマでサイトをリニューアルした話 / 2026-01-31 Kansai WordPress Meetup
torounit
0
420
ファインディの横断SREがTakumi byGMOと取り組む、セキュリティと開発スピードの両立
rvirus0817
1
1k
IaaS/SaaS管理における SREの実践 - SRE Kaigi 2026
bbqallstars
4
1.5k
変化するコーディングエージェントとの現実的な付き合い方 〜Cursor安定択説と、ツールに依存しない「資産」〜
empitsu
4
1.3k
Meshy Proプラン課金した
henjin0
0
200
Featured
See All Featured
Fashionably flexible responsive web design (full day workshop)
malarkey
408
66k
Google's AI Overviews - The New Search
badams
0
900
The Invisible Side of Design
smashingmag
302
51k
jQuery: Nuts, Bolts and Bling
dougneiner
65
8.4k
So, you think you're a good person
axbom
PRO
2
1.9k
Why Mistakes Are the Best Teachers: Turning Failure into a Pathway for Growth
auna
0
50
Scaling GitHub
holman
464
140k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.6k
Navigating Algorithm Shifts & AI Overviews - #SMXNext
aleyda
0
1.1k
It's Worth the Effort
3n
188
29k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
34
2.6k
Accessibility Awareness
sabderemane
0
47
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