Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
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
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.2k
クロスアカウントな RDS Snapshot Export による カジュアルなデータ集約の仕組み
wa6sn
2
340
dev 補講: プロダクトセキュリティ / Product security overview
wa6sn
1
3.3k
開発者向け MySQL 入門 / MySQL 101 for Developers
wa6sn
47
13k
Other Decks in Technology
See All in Technology
評価駆動開発で不確実性を制御する - MLflow 3が支えるエージェント開発
databricksjapan
1
210
MLflowダイエット大作戦
lycorptech_jp
PRO
1
140
WordPress は終わったのか ~今のWordPress の制作手法ってなにがあんねん?~ / Is WordPress Over? How We Build with WordPress Today
tbshiki
1
800
re:Invent2025 3つの Frontier Agents を紹介 / introducing-3-frontier-agents
tomoki10
0
230
Database イノベーショントークを振り返る/reinvent-2025-database-innovation-talk-recap
emiki
0
220
Databricks向けJupyter Kernelでデータサイエンティストの開発環境をAI-Readyにする / Data+AI World Tour Tokyo After Party
genda
1
520
Debugging Edge AI on Zephyr and Lessons Learned
iotengineer22
0
220
mairuでつくるクレデンシャルレス開発環境 / Credential-less development environment using Mailru
mirakui
5
530
今からでも間に合う!速習Devin入門とその活用方法
ismk
1
750
寫了幾年 Code,然後呢?軟體工程師必須重新認識的 DevOps
cheng_wei_chen
1
1.4k
会社紹介資料 / Sansan Company Profile
sansan33
PRO
11
390k
IAMユーザーゼロの運用は果たして可能なのか
yama3133
1
450
Featured
See All Featured
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
25
1.6k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
12
970
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
132
19k
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
390
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.5k
Building Adaptive Systems
keathley
44
2.9k
Site-Speed That Sticks
csswizardry
13
1k
How To Stay Up To Date on Web Technology
chriscoyier
791
250k
Rebuilding a faster, lazier Slack
samanthasiow
85
9.3k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
7.9k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
2.6k
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