Slide 1

Slide 1 text

送信ドメイン認証 の現状(2024年版) 野々垣裕司 2024/10/05 DNS温泉10 in 熱海 1 KEYTEC

Slide 2

Slide 2 text

自己紹介 • 野々垣 裕司 (ののがき ひろし) • COBOLer (間接的にゲームソフトウェア開発に関わる) • 1996年からインターネットに携わる。IPv6は2001年から。 • 元々ISPを立ち上げたが、技術提供する方向に転換。 • SNS • Twitter xplntr • Facebook nonogaki • Tumblr https://memorandum.y0.net/ • 得意技? ルーティング(鉄道)、両声類 2024/10/05 DNS温泉10 in 熱海 2 KEYTEC

Slide 3

Slide 3 text

送信ドメイン認証とは • 送信されたメールが詐称されていないか • 技術 • 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

Slide 4

Slide 4 text

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"

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

大企業でも間違える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)

Slide 8

Slide 8 text

KEYTEC 2024/10/05 DNS温泉10 in 熱海 8

Slide 9

Slide 9 text

Sender ID • なにそれ 2024/10/05 DNS温泉10 in 熱海 KEYTEC 9

Slide 10

Slide 10 text

DKIM • ヘッダーの情報が改ざんされていないか判断 • To, From, Subject, Message-id, Date 等のヘッダー電子署名をして、その情報をヘッ ダに付加する • 公開鍵はDNSのTXTレコードに記述する • 受信側では、電子署名された内容を検証する 2024/10/05 DNS温泉10 in 熱海 KEYTEC 10

Slide 11

Slide 11 text

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==

Slide 12

Slide 12 text

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;

Slide 13

Slide 13 text

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: 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=

Slide 14

Slide 14 text

DKIM • 設定間違いは少ない • 受信側のヘッダーにて直ぐに確認できるため • 鍵の生成と更新が面倒 • 複数のセレクタを使って複数の鍵が作れる • 鍵の更新をやっている人見たことない(更新を推奨されている) • 運用の問題 • メーリングリストでひっかかる → ML側で署名を削除する • 作成者署名でなくても可 • 第三者署名ができる →詐称可能 / DMARC導入できない • Google Workspaceでは作成者署名もできるが、デフォルトは第三者署名 2024/10/05 DNS温泉10 in 熱海 KEYTEC 14

Slide 15

Slide 15 text

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"

Slide 16

Slide 16 text

DMARC DMARCレポート 受信先からDMARC認証結果レポートを 送ってくれる 正しく動作しているか確認できる 詐称や改ざんされたメールがどこから発信され ているかわかる 2024/10/05 DNS温泉10 in 熱海 KEYTEC 16

Slide 17

Slide 17 text

DMARC DMARCレポート 受信先からDMARC認証結果レポートを 送ってくれる 正しく動作しているか確認できる 詐称や改ざんされたメールがどこから発信され ているかわかる 2024/10/05 DNS温泉10 in 熱海 KEYTEC 17

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

困ったDMARCレポート1 2024/10/05 DNS温泉10 in 熱海 KEYTEC 19

Slide 20

Slide 20 text

困ったDMARCレポート2 2024/10/05 DNS温泉10 in 熱海 KEYTEC 20

Slide 21

Slide 21 text

困ったDMARCレポート3 2024/10/05 DNS温泉10 in 熱海 KEYTEC 21

Slide 22

Slide 22 text

現状での結論 • DNSが正しく設定できていないので、送信ドメイン認証も正しく設定でき る訳がない。間違いに気づかない。 • SPFは比較的普及してきていると思うが、設定していないところはキャリア メール宛メールを送らないのか? • DKIM導入済みだとしても、作成者署名が無さすぎる。G suiteは第三者署名 なのでとりあえずあるだけ。 • DNSもMTAもSPFもDKIMも全て正しく設定できないと、DMARCの運用なん てとても無理。 • RFC違反メールを弾いて正しい設定しようと少しずつ啓蒙した方が良い。 2024/10/05 DNS温泉10 in 熱海 KEYTEC 22

Slide 23

Slide 23 text

神奈川県高校出願システム • 2024年1月に問題が起きた • Gmail宛に送信しても届かない ドコモ等キャリアメール等は問題無し • 技術スキルの低い企業が入札して行った • メールサーバの構築がいろいろとおかしい ソフトウェア開発しか知らない企業 • 脆弱性だらけのサーバ • インターネットの事を知らなさすぎる KEYTEC 2024/10/05 DNS温泉10 in 熱海 23

Slide 24

Slide 24 text

MX RR がIPアドレス KEYTEC 2024/10/05 DNS温泉10 in 熱海 24

Slide 25

Slide 25 text

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.

Slide 26

Slide 26 text

メールのドメイン名が増えたよ KEYTEC • shutsugankanagawa.jp • shutsugan-kanagawa.jp • nyuushi-kanagawa.jp メールログ見ていないのか? 見かたを知らないのか? 2024/10/05 DNS温泉10 in 熱海 26

Slide 27

Slide 27 text

入札企業のサイト KEYTEC 2024/10/05 DNS温泉10 in 熱海 27

Slide 28

Slide 28 text

入札企業のサイト KEYTEC • SSLv3喋るよ(使用厳禁) • TLSv1.0, v1.1喋るよ(使用禁止) • 暗号スイート 3DES,RC4,MD5喋るよ(使用厳禁) • 鍵交換DH 1024bit(いつの時代だよ) 恐らく8年ぐらい脆弱性放置と思われる。 本日現在でも直っていない。 2024/10/05 DNS温泉10 in 熱海 28

Slide 29

Slide 29 text

推測される原因 KEYTEC • ある日突然大量送信されていると思われる。 過去比数百倍のメールが送信されたらDoSかと思われますよね。 • Googleでは浸透していないドメイン名で大量に届いた。 最近登録されたドメイン名だな。 なんで浸透している神奈川県のサブドメインをつかわないのだ。 • DNSやメールサーバの設定がおかしい。 • そういったこともあってGmailでrejectされた。 5xx とかではなく4xx と思われる。 • メールログをみれば原因分析できるはず。 ソフトウェアが本業なのでインターネットに関しては無知。 2024/10/05 DNS温泉10 in 熱海 29

Slide 30

Slide 30 text

インターネットにかかわる入札 KEYTEC • 予算だけで落札される • 落札企業の技術スキルの判断ができない • ちゃんとしたスキルのある企業は、安いだけの金額で入札しない • まるで中国の高速鉄道国際入札状態 • 脆弱性等の維持管理は年月とともに増える。当初予算だけでは判断できな い。 • 予算が無いと脆弱性放置となる。(徳島県半田病院) • 予算が無い場合、道路の災害等も行う必要はないのか。 同じインフラというならば扱いは同じにするべき。 2024/10/05 DNS温泉10 in 熱海 30

Slide 31

Slide 31 text

予防保守は必要 KEYTEC • 機器が故障するまで何もしないのか • 定期的に機器交換やソフトウェアアップデートは必須 • 今は動いているから何もしない、費用もさかないのか • 車のタイヤはバーストするまで何もしないのか 可視化できないネットワークは調べる必要はある • ネットワーク機器、コンピュータハードウェア、ソフトウェアもタイヤと 同じ様に予防保守は必要 2024/10/05 DNS温泉10 in 熱海 31

Slide 32

Slide 32 text

ポリシーと技術者が不足 KEYTEC • 正しい技術とスキルを身につけましょう。 • 時間も費用も貰えないならやめましょう。 • DNS温泉など技術者の交流の場所に行きましょう。 • 自分だけで頑張る必要はありません。 • 書き出すとキリがないのでこのぐらい。 • OSINTで得られる情報で確認をして間違いの無い企業を選びましょう。 2024/10/05 DNS温泉10 in 熱海 32