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
送信ドメイン認証の現状(2024年版) DNS温泉10
Search
Nonogaki Hiroshi
October 06, 2024
Technology
260
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
送信ドメイン認証の現状(2024年版) DNS温泉10
Nonogaki Hiroshi
October 06, 2024
More Decks by Nonogaki Hiroshi
See All by Nonogaki Hiroshi
Google Cloud spammerの状況 (JANOG57 Mail BoF)
hinono
0
24
ドメイン名を浸透させよ & Google Cloud spammerの状況
hinono
0
99
浸透しなさいRFC 5322&7208
hinono
0
310
メールヘッダーを見てみよう
hinono
0
510
RFC 5322 に浸かろう 続編
hinono
0
390
メールサーバ管理者のみ知る話
hinono
1
260
総務担当者のOSINT
hinono
0
1.7k
OSINTから得られる組織評価
hinono
0
320
総務担当者のOSINT
hinono
1
640
Other Decks in Technology
See All in Technology
[AWS Summit Japan 2026]迷っているあなたへ_小さな一歩が、やがて自分を助けてくれる
sh_fk2
1
180
SONiCの統計情報を取得したい
sonic
0
230
10年間のブログ発信を振り返って見えたWebアプリケーションエンジニアとしての軌跡
stefafafan
0
170
2026TECHFRESH畢業分享會 - Lightning Talk - 打造精準高效的 MCP 設計模式與測試實務
line_developers_tw
PRO
0
1.3k
AI-DLCを “そのまま導入しなかった”話 ~組織に合わせてアジャストした 私たちの実践共有~
hiroramos4
PRO
0
230
ぼっちではじめた登壇が「51名」「241件」の発信に化けた
subroh0508
1
250
MUSUBI 田中裕一『AIと共に行う「しごとのリデザイン」- スモールバックオフィス編』AI Ops Lab #4
musubi
0
270
フィジカル版Github Onshapeの紹介
shiba_8ro
0
290
就職⽀援サービスにおけるキャリアアドバイザーのシフトスケジューリング
recruitengineers
PRO
1
150
AWS Security Agent といっしょに脅威モデリングをやってみよう
amarelo_n24
1
180
マルチアカウント環境での コーディングエージェントを使った障害調査が大変なので AIエージェントにReadOnly権限を付与してみた / ReadOnly AI Agents for Multi-Account AWS Incident Response
yamaguchitk333
2
110
Bucharest Tech Week 2026 - Reinventing testing practices in the AI era
edeandrea
PRO
1
170
Featured
See All Featured
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
34
2.8k
Claude Code のすすめ
schroneko
67
230k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
17k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.8k
Effective software design: The role of men in debugging patriarchy in IT @ Voxxed Days AMS
baasie
0
420
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
35k
jQuery: Nuts, Bolts and Bling
dougneiner
66
8.5k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
133
19k
Code Review Best Practice
trishagee
74
20k
Building Experiences: Design Systems, User Experience, and Full Site Editing
marktimemedia
0
530
Ecommerce SEO: The Keys for Success Now & Beyond - #SERPConf2024
aleyda
1
2k
Transcript
送信ドメイン認証 の現状(2024年版) 野々垣裕司 2024/10/05 DNS温泉10 in 熱海 1 KEYTEC
自己紹介 • 野々垣 裕司 (ののがき ひろし) • COBOLer (間接的にゲームソフトウェア開発に関わる) •
1996年からインターネットに携わる。IPv6は2001年から。 • 元々ISPを立ち上げたが、技術提供する方向に転換。 • SNS • Twitter xplntr • Facebook nonogaki • Tumblr https://memorandum.y0.net/ • 得意技? ルーティング(鉄道)、両声類 2024/10/05 DNS温泉10 in 熱海 2 KEYTEC
送信ドメイン認証とは • 送信されたメールが詐称されていないか • 技術 • SPF (Sender Policy Framework)
RFC 7208 • Sender ID RFC 4406, RFC 4407 • DKIM (DomainKeys Identified Mail) RFC 6376 • DMARC (Domain-based Message Authentication,Reporting, and Conformance) RFC 7489 2024/10/05 DNS温泉10 in 熱海 KEYTEC 3
SPF • 送信元のIPアドレスで判断する • MAIL FROMのホスト名、HELOのホスト名 • -all Fail 一致していないとREJECT
• ~all Softfail 信頼できないが受信する • DNS参照は最大10回まで • 設定したら必ず確認しましょう。 2024/10/05 DNS温泉10 in 熱海 KEYTEC 4 keytec.jp. 86400 IN TXT “v=spf1 include:spf.keytec.jp -all” spf.keytec.jp. 86400 IN TXT "v=spf1 ip6:2001:f58:2003:1::/126 ip6:2001:f58:2003:1::a ip4:202.124.214.192/30 ip4:202.124.214.202 ~all"
SPF RR書き方 • a:mx.examplejp mx.example.jp のIPアドレス • mx example.jp のMX
• exist 説明が長くなるのでしない • include:spf.keytec.jp spf.keytec.jp txtを利用する 2回DNSが引けなかったらエラーとなる。 2024/10/05 DNS温泉10 in 熱海 KEYTEC 5
SPF py.spf を使いましょう To check an incoming mail request: %
python spf.py [-v] {ip} {sender} {helo} % python spf.py 127.0.0.1
[email protected]
mta.example.jp % spf.py 127.0.0.1 keytec.jp helo % spf.py ::1 keytec.jp helo # pkg install mail/py-pyspf 2024/10/05 DNS温泉10 in 熱海 KEYTEC 6
大企業でも間違えるSPF 2024/10/05 DNS温泉10 in 熱海 KEYTEC 7 @ IN A
TXT “v=spf1 ip4:192.0.2.10/24 ~all” @ IN A TXT “v=spf1 ip6:2001:db8::/32 ~all” SPF Permanent Errorとなっていた 全て私が世界中で一番最初に発見したらしい(Xにて) 2021年6月 amazon.com 2021年9月 docomo.ne.jp 2022年6月 icloud.com 2024年8月 ezweb.ne.jp (au.com)
KEYTEC 2024/10/05 DNS温泉10 in 熱海 8
Sender ID • なにそれ 2024/10/05 DNS温泉10 in 熱海 KEYTEC 9
DKIM • ヘッダーの情報が改ざんされていないか判断 • To, From, Subject, Message-id, Date 等のヘッダー電子署名をして、その情報をヘッ
ダに付加する • 公開鍵はDNSのTXTレコードに記述する • 受信側では、電子署名された内容を検証する 2024/10/05 DNS温泉10 in 熱海 KEYTEC 10
DKIM 2024/10/05 DNS温泉10 in 熱海 KEYTEC 11 202408-keytec-jp._domainkey.keytec.jp 86400 IN
TXT "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4f/ICsTDCd1wiWYNnfN5hLrSj6kbZTf3h MgZElJoJf9h6Wu7cXplWiEc8QMqSoWlcENtGXOYspd4wd21XwlrdXeIsOb2YgCtS0QsJ9oOJDeFw0PU 6ImSfuLLD6nD8Cb2i6ol70gvbAKSCdrIwSjm9q/Dui+QaBNkDvgKnWIWn3gZZwLgMBROG2MW/Q9g QkRRaNUFouq56kRMpZ" "19ytcrdvlHcne97q5qox7WUuO7mxgvQPzH/RmGmmg7Rp95quI80PnIUZhUMecrZfaxMvs+kxuURIKb GrI/BG6ZDaubDIr/c7T4gTTieZeYHzwjxKSFKyc8tMEDRtRhhKjwOnrXKwIDAQAB" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=keytec.jp; s=202408-keytec-jp; t=1727481671; bh=N0HYlIpa0d/PXB0VfW3fFl7lEe7rjWhQnxrq4ShLn3w=; h=To:From:Subject:Date:Message-ID; b=wwErb4bT5PXdQhT2fWFUYyRMhqxCyvp2iiObVJtmID0Dp4Bb/55kzyrUelDP7eeWY EYi00xid5rFRR+zsb9hP5q43cBBOym5FTsfurutVrvU7d2gNMul8iMOaZRDGenMmHf fv/PERwT/7Dh4Dw0DxECiFoIwtb0arMVUJfwkshrix2y6enPBpkjk+VMlgwyuiITjJ oV5amik6gdy5bvg/f5WacHKjv811wkWIhVnPcg0ce6XomyBhQlLII8AJT37gzpI1Su 9LV7Zh0wHdpwyTGfju6F6uLW8TMdC9/Qtzo1GwgnCjAY+4ufjfWbcyT9hvlUCsccB6 3y93LsTujSLLw==
DKIM主な項目 2024/10/05 DNS温泉10 in 熱海 KEYTEC 12 ボディハッシュ bh=N0HYlIpa0d/PXB0VfW3fFl7lEe7rjWhQnxrq4ShLn3w=; 署名対象ヘッダ
h=To:From:Subject:Date:Message-ID; ドメイン名 d=keytec.jp; セレクタ(使用する鍵) s=202408-keytec-jp; 公開鍵は 202408-keytec-jp._domainkey.keytec.jp となる タイムスタンプ (Epoch UNIX時刻) t=1727481671;
DKIM署名方法 2024/10/05 DNS温泉10 in 熱海 KEYTEC 13 次の内容を秘密鍵で署名する from:
[email protected]
to:
[email protected]
date:Sat, 5 Nov 2024 12:01:02 +0900 message-id:<
[email protected]
> dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=keytec.jp; s=202408-keytec- jp; t=1727481671; bh=N0HYlIpa0d/PXB0VfW3fFl7lEe7rjWhQnxrq4ShLn3w=; h=To:From:Subject:Date:Message-ID;b=
DKIM • 設定間違いは少ない • 受信側のヘッダーにて直ぐに確認できるため • 鍵の生成と更新が面倒 • 複数のセレクタを使って複数の鍵が作れる •
鍵の更新をやっている人見たことない(更新を推奨されている) • 運用の問題 • メーリングリストでひっかかる → ML側で署名を削除する • 作成者署名でなくても可 • 第三者署名ができる →詐称可能 / DMARC導入できない • Google Workspaceでは作成者署名もできるが、デフォルトは第三者署名 2024/10/05 DNS温泉10 in 熱海 KEYTEC 14
DMARC • SPFとDKIMの結果で判断する • TXTレコード v=DMARC1 記述する (Fromヘッダのメールアドレス) • p=none
なにもしない(実態) • p=quarantine 隔離 • p=reject 拒否 • DMARCレポート • 受信先からDMARC認証結果レポートを送ってくれる(受信報告書) • rua=メールアドレス にて記述する 2024/10/05 DNS温泉10 in 熱海 KEYTEC 15 _dmarc.keytec.jp. 3600 IN TXT "v=DMARC1; p=reject; fo=1; aspf=s; rua=mailto:postmaster_rua◦×△@keytec.jp"
DMARC DMARCレポート 受信先からDMARC認証結果レポートを 送ってくれる 正しく動作しているか確認できる 詐称や改ざんされたメールがどこから発信され ているかわかる 2024/10/05 DNS温泉10 in
熱海 KEYTEC 16
DMARC DMARCレポート 受信先からDMARC認証結果レポートを 送ってくれる 正しく動作しているか確認できる 詐称や改ざんされたメールがどこから発信され ているかわかる 2024/10/05 DNS温泉10 in
熱海 KEYTEC 17
MTA-STS(Mail Transfer Agent Strict Transport Security) • 送信側と受信側で両方対応していないと機能しない • STARTTLSを必ず使用する
• 受信側がTLS1.2以上を必ず使用する • 証明書が有効であること • 上記条件を満たさない場合は配信されない • 受信側サーバ設定 • 受信したいメールドメイン名のMTA-STSコードを記述する • ポリシーのhttpsを用意する 2024/10/05 DNS温泉10 in 熱海 KEYTEC 18 _mta-sts.keytec.jp. 86400 IN TXT "v=STSv1; id=20210911000001;" https://mta-sts.keytec.jp/.well-known/mta-sts.txt version: STSv1 mode: enforce max_age: 604800 mx: *.keytec.jp
困ったDMARCレポート1 2024/10/05 DNS温泉10 in 熱海 KEYTEC 19
困ったDMARCレポート2 2024/10/05 DNS温泉10 in 熱海 KEYTEC 20
困ったDMARCレポート3 2024/10/05 DNS温泉10 in 熱海 KEYTEC 21
現状での結論 • DNSが正しく設定できていないので、送信ドメイン認証も正しく設定でき る訳がない。間違いに気づかない。 • SPFは比較的普及してきていると思うが、設定していないところはキャリア メール宛メールを送らないのか? • DKIM導入済みだとしても、作成者署名が無さすぎる。G suiteは第三者署名
なのでとりあえずあるだけ。 • DNSもMTAもSPFもDKIMも全て正しく設定できないと、DMARCの運用なん てとても無理。 • RFC違反メールを弾いて正しい設定しようと少しずつ啓蒙した方が良い。 2024/10/05 DNS温泉10 in 熱海 KEYTEC 22
神奈川県高校出願システム • 2024年1月に問題が起きた • Gmail宛に送信しても届かない ドコモ等キャリアメール等は問題無し • 技術スキルの低い企業が入札して行った • メールサーバの構築がいろいろとおかしい
ソフトウェア開発しか知らない企業 • 脆弱性だらけのサーバ • インターネットの事を知らなさすぎる KEYTEC 2024/10/05 DNS温泉10 in 熱海 23
MX RR がIPアドレス KEYTEC 2024/10/05 DNS温泉10 in 熱海 24
MX RR がIPアドレス KEYTEC 2024/10/05 DNS温泉10 in 熱海 25 mail.shutsugankanagawa.jp.
300 IN MX 10 13.113.157.93. mail.shutsugankanagawa.jp. 300 IN MX 10 52.193.62.66. mail.shutsugankanagawa.jp. 300 IN MX 10 52.194.140.218. mail.shutsugankanagawa.jp. 300 IN MX 10 feedback-smtp.ap-northeast-1.compute.amazonaws.com.
メールのドメイン名が増えたよ KEYTEC • shutsugankanagawa.jp • shutsugan-kanagawa.jp • nyuushi-kanagawa.jp メールログ見ていないのか? 見かたを知らないのか?
2024/10/05 DNS温泉10 in 熱海 26
入札企業のサイト KEYTEC 2024/10/05 DNS温泉10 in 熱海 27
入札企業のサイト KEYTEC • SSLv3喋るよ(使用厳禁) • TLSv1.0, v1.1喋るよ(使用禁止) • 暗号スイート 3DES,RC4,MD5喋るよ(使用厳禁)
• 鍵交換DH 1024bit(いつの時代だよ) 恐らく8年ぐらい脆弱性放置と思われる。 本日現在でも直っていない。 2024/10/05 DNS温泉10 in 熱海 28
推測される原因 KEYTEC • ある日突然大量送信されていると思われる。 過去比数百倍のメールが送信されたらDoSかと思われますよね。 • Googleでは浸透していないドメイン名で大量に届いた。 最近登録されたドメイン名だな。 なんで浸透している神奈川県のサブドメインをつかわないのだ。 •
DNSやメールサーバの設定がおかしい。 • そういったこともあってGmailでrejectされた。 5xx とかではなく4xx と思われる。 • メールログをみれば原因分析できるはず。 ソフトウェアが本業なのでインターネットに関しては無知。 2024/10/05 DNS温泉10 in 熱海 29
インターネットにかかわる入札 KEYTEC • 予算だけで落札される • 落札企業の技術スキルの判断ができない • ちゃんとしたスキルのある企業は、安いだけの金額で入札しない • まるで中国の高速鉄道国際入札状態
• 脆弱性等の維持管理は年月とともに増える。当初予算だけでは判断できな い。 • 予算が無いと脆弱性放置となる。(徳島県半田病院) • 予算が無い場合、道路の災害等も行う必要はないのか。 同じインフラというならば扱いは同じにするべき。 2024/10/05 DNS温泉10 in 熱海 30
予防保守は必要 KEYTEC • 機器が故障するまで何もしないのか • 定期的に機器交換やソフトウェアアップデートは必須 • 今は動いているから何もしない、費用もさかないのか • 車のタイヤはバーストするまで何もしないのか
可視化できないネットワークは調べる必要はある • ネットワーク機器、コンピュータハードウェア、ソフトウェアもタイヤと 同じ様に予防保守は必要 2024/10/05 DNS温泉10 in 熱海 31
ポリシーと技術者が不足 KEYTEC • 正しい技術とスキルを身につけましょう。 • 時間も費用も貰えないならやめましょう。 • DNS温泉など技術者の交流の場所に行きましょう。 • 自分だけで頑張る必要はありません。
• 書き出すとキリがないのでこのぐらい。 • OSINTで得られる情報で確認をして間違いの無い企業を選びましょう。 2024/10/05 DNS温泉10 in 熱海 32