HOME»情報処理安全確保支援士掲示板»SPF認証ではヘッダの変更は検知困難なのでしょうか
投稿する
早々のお返事ありがとうございました。上記は知りませんでした。
よくよく考えればセンドポリシーなのでその通りですよね。
はい その認識であっています。
はい なりすましの検知に加えて、ディジタル署名を付与して
いることにより改ざん検知も可能です。
DKIMはSPFで問題となるメール転送が発生しても、正しく
処理できます。
欠点は鍵ペアを作成し、管理しなければらないとう手間が
かかることです。
SPF認証ではヘッダの変更は検知困難なのでしょうか [0813]
Lemさん(No.1)
エンベロープFROMの変更は検出できて、ヘッダ情報の変更は検出できないとどこかのページで読んだのですが、そうなのでしょうか？
なぜ、そのようなことになるのでしょうか？
悪意のある人は、エンベロープもヘッダ情報（Recieved内を除く）も変更可能ですよね？
なぜ、そのようなことになるのでしょうか？
悪意のある人は、エンベロープもヘッダ情報（Recieved内を除く）も変更可能ですよね？
2022.03.13 15:08
Lemさん(No.2)
この投稿は投稿者により削除されました。(2022.03.13 15:40)
2022.03.13 15:40
pixさん(No.3)
★SC ダイヤモンドマイスター
発想が逆です。
エンベロープFROM(MAIL FROM)もヘッダFROM(From:)もどちらも
送信者が自由に設定できます。
電子メール技術はこれらの値を送信者が正しい値を設定する前提で
成り立っています。
悪意のある人間がこれらの値を詐称して偽のメールを送信することも
簡単にできます。
このうちエンベロープFROM(MAIL FROM)については、SPFという既存の
DNS TXTレコードを流用（本来意図していない使い方で）した仕組みを
後付けで生み出し、送信元メールサーバのIPアドレスとの突合せに
よって詐称か否かを確認することができるようになりました。
それとは別にヘッダFROM(From:)の詐称を根本的に検知する方法は
技術的にありません。
MUAなどの迷惑メールフィルタもある程度は検出できますが、
絶対ではありません。
強いてゆうなら、人間が目視で注意するしかありません。
エンベロープFROM(MAIL FROM)もヘッダFROM(From:)もどちらも
送信者が自由に設定できます。
電子メール技術はこれらの値を送信者が正しい値を設定する前提で
成り立っています。
悪意のある人間がこれらの値を詐称して偽のメールを送信することも
簡単にできます。
このうちエンベロープFROM(MAIL FROM)については、SPFという既存の
DNS TXTレコードを流用（本来意図していない使い方で）した仕組みを
後付けで生み出し、送信元メールサーバのIPアドレスとの突合せに
よって詐称か否かを確認することができるようになりました。
それとは別にヘッダFROM(From:)の詐称を根本的に検知する方法は
技術的にありません。
MUAなどの迷惑メールフィルタもある程度は検出できますが、
絶対ではありません。
強いてゆうなら、人間が目視で注意するしかありません。
2022.03.13 18:50
pixさん(No.4)
★SC ダイヤモンドマイスター
補足します
SPFにDMARCを組み合わせれば、SPFをパスしたのちにDMARCによって
エンベロープFROM(MAIL FROM)とヘッダFROM(From:)の
ドメインの突合せをするので、ヘッダFROM(From:)が詐称かどうかの
確認は可能です。
SPFにDMARCを組み合わせれば、SPFをパスしたのちにDMARCによって
エンベロープFROM(MAIL FROM)とヘッダFROM(From:)の
ドメインの突合せをするので、ヘッダFROM(From:)が詐称かどうかの
確認は可能です。
2022.03.13 19:23
Lemさん(No.5)
この投稿は投稿者により削除されました。(2022.03.13 21:12)
2022.03.13 21:12
Lemさん(No.6)
なるほど！
補足については、DMARCのaspfのことですね。
エンベロープFROMは自由に設定できるんですね。
とすると、送信元情報がエンベロープ（MAIL FROM）、メールヘッダ（From）と2つ存在するのは何故なのでしょうか？
片方だけではまずいのでしょうか？
補足については、DMARCのaspfのことですね。
エンベロープFROMは自由に設定できるんですね。
とすると、送信元情報がエンベロープ（MAIL FROM）、メールヘッダ（From）と2つ存在するのは何故なのでしょうか？
片方だけではまずいのでしょうか？
2022.03.13 21:13
pixさん(No.7)
★SC ダイヤモンドマイスター
この2つは用途が違います
エンベロープFROM：メールサーバの処理用
メールサーバがメールを配信するために使用
エンベロープFROMのアドレスはメールヘッダ内部で
Return-Pathに設定されます。
メールヘッダ（From）：エンドユーザ用
エンドユーザが送信元を認識するために使用
R1秋 午後1 問1 [ニュースレターの配信］にもあるように、
エンベロープFROM:配信エラー用のメールアドレス
ヘッダーFROM:見かけの配信元アドレス
のように別のアドレスを用途によって使い分けることもできます。
エンベロープFROM：メールサーバの処理用
メールサーバがメールを配信するために使用
エンベロープFROMのアドレスはメールヘッダ内部で
Return-Pathに設定されます。
メールヘッダ（From）：エンドユーザ用
エンドユーザが送信元を認識するために使用
R1秋 午後1 問1 [ニュースレターの配信］にもあるように、
エンベロープFROM:配信エラー用のメールアドレス
ヘッダーFROM:見かけの配信元アドレス
のように別のアドレスを用途によって使い分けることもできます。
2022.03.13 22:02
Lemさん(No.8)
返信ありがとうございます。
Gmail等でパっと見で表示される宛先はヘッダFromですよね。
エンベロープFROMはいい加減なドメインを指定しても攻撃相手にはメールを送信することができ、エンベロープRCPT TOは偽装してしまうとそもそも相手に正しく届かない、という認識であっておりますでしょうか？
Gmail等でパっと見で表示される宛先はヘッダFromですよね。
エンベロープFROMはいい加減なドメインを指定しても攻撃相手にはメールを送信することができ、エンベロープRCPT TOは偽装してしまうとそもそも相手に正しく届かない、という認識であっておりますでしょうか？
2022.03.14 09:27
pixさん(No.9)
★SC ダイヤモンドマイスター
はい。あっています。
エンベロープRCPT TOはそもそも受信者のアドレスなので、偽装する・しない
という概念がありません。
ちなみにエンベロープTO(RCPT TO)とヘッダTO(To:)が異なるケースもあります。
BCC機能はメール受信者がヘッダTO(To:)にはいっていなくてもメールが届きます。
これはエンベロープTO(RCPT TO)に受信者のアドレスを設定して、ヘッダTO(To:)
には記載しないことによって、BCCを実現しています。
エンベロープRCPT TOはそもそも受信者のアドレスなので、偽装する・しない
という概念がありません。
ちなみにエンベロープTO(RCPT TO)とヘッダTO(To:)が異なるケースもあります。
BCC機能はメール受信者がヘッダTO(To:)にはいっていなくてもメールが届きます。
これはエンベロープTO(RCPT TO)に受信者のアドレスを設定して、ヘッダTO(To:)
には記載しないことによって、BCCを実現しています。
2022.03.14 10:37
質問させて下さい。さん(No.10)
失礼致します。上記のご質問とお答え、大変勉強になりました。
よろしければ追加で質問させて下さい。
令和元年度秋期午後１問１設問４で
https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2019h31_2/2019r01a_sc_pm1_qs.pdf
そのＳＰＦ、ＤＫＩＭ、ＤＭＡＲＫの認証技術を導入してもなりすましが防止できないケースが問われ、ＩＰＡの解答は、
「Ｎ社の取引先と似たメールアドレスから送信ドメイン技術を利用してメールを送信する」
とありますが、確かに似たようなアドレスになりすまされて送られてきたことがあります（すごく巧妙で吃驚しました）。プロバイダ側に似たようなメールを登録しないよう協力を仰ぐ他には目視で対策するしかないのでしょうか？
あるいはＳ／ＭＩＭＥかＰＧＰでエンドツーエンドで暗号化してメールの送受信するしかないのでしょうか？
これという対策の決定打がなくて困っています。
よろしければ追加で質問させて下さい。
令和元年度秋期午後１問１設問４で
https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2019h31_2/2019r01a_sc_pm1_qs.pdf
そのＳＰＦ、ＤＫＩＭ、ＤＭＡＲＫの認証技術を導入してもなりすましが防止できないケースが問われ、ＩＰＡの解答は、
「Ｎ社の取引先と似たメールアドレスから送信ドメイン技術を利用してメールを送信する」
とありますが、確かに似たようなアドレスになりすまされて送られてきたことがあります（すごく巧妙で吃驚しました）。プロバイダ側に似たようなメールを登録しないよう協力を仰ぐ他には目視で対策するしかないのでしょうか？
あるいはＳ／ＭＩＭＥかＰＧＰでエンドツーエンドで暗号化してメールの送受信するしかないのでしょうか？
これという対策の決定打がなくて困っています。
2022.03.16 12:46
pixさん(No.11)
★SC ダイヤモンドマイスター
メールはS/MIMEやPGPでメールの内容を暗号化するではなく、
ディジタル署名を付与することでなりすまし・改ざんは検知できます。
ですが、S/MIMEやPGPは準備に手間がかかるのと、相手にも準備が必要なので
実装するのにしきいが高いのが問題です。
類似ドメインの取得問題については現段階では確実な方法はないです。
おっしゃるとおり、目視で確認するのが最終手段となります。
JPCERT/CCでさえも、類似ドメインをとられて問題になったことがあります。
JPCERT/CCの本物のドメイン:jpcert.co.jp
取得された類似ドメイン:jpcert.org
以下のキーワードで検索すれば、詳細がでてきます
「JPCERT/CC、類似ドメイン」
対策の一つの方法として、取られてしまいそうなすべてのドメインを
すべて押さえてしまう方法もあります。
abc.com, abc.org, abc.net, abc.co.jp, abc.or.jpなど
しかし、費用やドメインの自由取得の面からも無理があります。
メール自体が性善説に基づいた情報通信を基本としていますので、
後付けの対策では完全にカバーできないのが現状です。
ディジタル署名を付与することでなりすまし・改ざんは検知できます。
ですが、S/MIMEやPGPは準備に手間がかかるのと、相手にも準備が必要なので
実装するのにしきいが高いのが問題です。
類似ドメインの取得問題については現段階では確実な方法はないです。
おっしゃるとおり、目視で確認するのが最終手段となります。
JPCERT/CCでさえも、類似ドメインをとられて問題になったことがあります。
JPCERT/CCの本物のドメイン:jpcert.co.jp
取得された類似ドメイン:jpcert.org
以下のキーワードで検索すれば、詳細がでてきます
「JPCERT/CC、類似ドメイン」
対策の一つの方法として、取られてしまいそうなすべてのドメインを
すべて押さえてしまう方法もあります。
abc.com, abc.org, abc.net, abc.co.jp, abc.or.jpなど
しかし、費用やドメインの自由取得の面からも無理があります。
メール自体が性善説に基づいた情報通信を基本としていますので、
後付けの対策では完全にカバーできないのが現状です。
2022.03.16 13:53
質問させて下さい。さん(No.12)
早速のご返答ありがとうございました。大変勉強になりました。
やはり最終的には「なりすましメールに気をつける」しかないのでしょうか。。。。
やはり最終的には「なりすましメールに気をつける」しかないのでしょうか。。。。
2022.03.16 14:57
類似ドメイン対策さん(No.13)
先日はありがとうございました。
あれから1日考え、SPFのtxtに「-」をつけて類似ドメインを前もって書いてブロックしてしまうのはどうだろうか？と考えました。
例えば
正→google.com
誤→google.co.jp
ne.jpやor.jp、orgやcomも「-」で記入。
大手ISPは迷惑メールフィルタリングも充実し対応済でしょうし、世界中の類似ドメインを押さえるのは不可能ですが
「6→ｂ」とか
「m→rn」とか
一見紛らわしいドメインをSPFに書いておく。目視のみに頼るよりは少しはマシになる程度の対処療法的方法かもしれませんが、どうでしょうか？
あれから1日考え、SPFのtxtに「-」をつけて類似ドメインを前もって書いてブロックしてしまうのはどうだろうか？と考えました。
例えば
正→google.com
誤→google.co.jp
ne.jpやor.jp、orgやcomも「-」で記入。
大手ISPは迷惑メールフィルタリングも充実し対応済でしょうし、世界中の類似ドメインを押さえるのは不可能ですが
「6→ｂ」とか
「m→rn」とか
一見紛らわしいドメインをSPFに書いておく。目視のみに頼るよりは少しはマシになる程度の対処療法的方法かもしれませんが、どうでしょうか？
2022.03.18 13:37
pixさん(No.14)
★SC ダイヤモンドマイスター
すみませんが、TXTレコードは所持しているドメインしか設定できないと思われます。
SPFはドメインと送信元IPアドレス（ドメイン）の紐づけを設定するものです。
書き込みの内容から察するに、メールアドレスのドメインと
除外する送信元IPアドレス（ドメイン）を混同されておられるように思われます。
SPFはドメインと送信元IPアドレス（ドメイン）の紐づけを設定するものです。
書き込みの内容から察するに、メールアドレスのドメインと
除外する送信元IPアドレス（ドメイン）を混同されておられるように思われます。
2022.03.18 14:38
有難うございましたさん(No.15)
＞すみませんが、TXTレコードは所持しているドメインしか設定できないと思われます。
早々のお返事ありがとうございました。上記は知りませんでした。
よくよく考えればセンドポリシーなのでその通りですよね。
2022.03.18 14:58
Lemさん(No.16)
pixさん、お礼が遅くなり申し訳ありません。
おかげさまでなんとか理解することができました。
質問させて下さい。さんとのやり取りも非常に勉強になりました。
ありがとうございます。
おかげさまでなんとか理解することができました。
質問させて下さい。さんとのやり取りも非常に勉強になりました。
ありがとうございます。
2022.03.19 16:11
Lemさん(No.17)
この投稿は投稿者により削除されました。(2022.03.20 00:01)
2022.03.20 00:01
Lemさん(No.18)
DKIMについて聞き忘れていたことがありました。
※MAIL FROMはエンベロープFROMと同義とします
SPFでは受け取ったメールのMAIL FROMのドメインを手がかりに送信者のDNSサーバにTXTレコードの要求を行いますよね。
DKIMでも同じく、MAIL FROMのドメインを手がかりにして送信者のDNSサーバに公開鍵の要求を行うのでしょうか？
であれば、DKIMはヘッダFROMだけでなくエンベロープFROMの認証もできてしまうことになりませんか？
※MAIL FROMはエンベロープFROMと同義とします
SPFでは受け取ったメールのMAIL FROMのドメインを手がかりに送信者のDNSサーバにTXTレコードの要求を行いますよね。
DKIMでも同じく、MAIL FROMのドメインを手がかりにして送信者のDNSサーバに公開鍵の要求を行うのでしょうか？
であれば、DKIMはヘッダFROMだけでなくエンベロープFROMの認証もできてしまうことになりませんか？
2022.03.20 00:04
pixさん(No.19)
★SC ダイヤモンドマイスター
質問内容に曖昧な点があるので、想像して解答します。
すみませんが、送信者のDNSサーバという意味をくみ取れませんでした。
SPFもDKIMもMAIL FROMのドメインのDNSサーバにTXTレコードの
問い合わせにいきます。
SPFの場合はTXTレコードに許可・拒否するIPアドレスのリストが、
DKIMはTXTレコードに公開鍵が記載されています。
DKIMはディジタル署名を利用していますので、なりすましだけではなく
メール本文・ヘッダの改ざん検知も可能です。
>であれば、DKIMはヘッダFROMだけでなくエンベロープFROMの認証も
>できてしまうことになりませんか？
すみませんが、送信者のDNSサーバという意味をくみ取れませんでした。
SPFもDKIMもMAIL FROMのドメインのDNSサーバにTXTレコードの
問い合わせにいきます。
SPFの場合はTXTレコードに許可・拒否するIPアドレスのリストが、
DKIMはTXTレコードに公開鍵が記載されています。
DKIMはディジタル署名を利用していますので、なりすましだけではなく
メール本文・ヘッダの改ざん検知も可能です。
2022.03.20 02:37
Lemさん(No.20)
回答いただきありがとうございます。
こちらの質問内容に不備があり、申し訳ないです。
SPFだけではなく、DKIMも"MAIL FROM"のドメインのDNSサーバに問い合わせにいくのですね。
送信者のDNSサーバとは、メール送信側のドメインにあるDNSサーバ、ということです。
Q.ここでいうディジタル署名の手順としては、
メール本文およびヘッダ情報からハッシュ値を生成し、それを秘密鍵で暗号化する
という理解でよいでしょうか？
Q.SPFではエンベロープFROMのなりすましを検知できますが、
DKIMでもエンベロープFROMのなりすましを検知できるという理解でよいでしょうか？
以上2点の質問になります。よろしくおねがいします。
こちらの質問内容に不備があり、申し訳ないです。
＞SPFもDKIMもMAIL FROMのドメインのDNSサーバにTXTレコードの
＞問い合わせにいきます。
SPFだけではなく、DKIMも"MAIL FROM"のドメインのDNSサーバに問い合わせにいくのですね。
送信者のDNSサーバとは、メール送信側のドメインにあるDNSサーバ、ということです。
＞DKIMはディジタル署名を利用していますので、なりすましだけではなく
＞メール本文・ヘッダの改ざん検知も可能です
Q.ここでいうディジタル署名の手順としては、
メール本文およびヘッダ情報からハッシュ値を生成し、それを秘密鍵で暗号化する
という理解でよいでしょうか？
Q.SPFではエンベロープFROMのなりすましを検知できますが、
DKIMでもエンベロープFROMのなりすましを検知できるという理解でよいでしょうか？
以上2点の質問になります。よろしくおねがいします。
2022.03.20 14:34
pixさん(No.21)
★SC ダイヤモンドマイスター
>Q.ここでいうディジタル署名の手順としては、
>メール本文およびヘッダ情報からハッシュ値を生成し、
>それを秘密鍵で暗号化するという理解でよいでしょうか？
はい その認識であっています。
>Q.SPFではエンベロープFROMのなりすましを検知できますが、
>DKIMでもエンベロープFROMのなりすましを検知できるという
>理解でよいでしょうか？
はい なりすましの検知に加えて、ディジタル署名を付与して
いることにより改ざん検知も可能です。
DKIMはSPFで問題となるメール転送が発生しても、正しく
処理できます。
欠点は鍵ペアを作成し、管理しなければらないとう手間が
かかることです。
2022.03.20 15:07
Lemさん(No.22)
pixさん
返信ありがとうございます。メールサーバまわりの過去問が解けるようになってきました。
pixさんの明快な回答のおかげです。
同時に、「ドメイン」については、まだ少々理解が足りていないのかなというのも痛感しました。
これは本スレッドとは別件になってきそうなので、また別のスレッドで質問させていただこうと思っております。
またメールまわりでわからないことがあれば、よろしくお願いいたします。（よろしければ）
返信ありがとうございます。メールサーバまわりの過去問が解けるようになってきました。
pixさんの明快な回答のおかげです。
同時に、「ドメイン」については、まだ少々理解が足りていないのかなというのも痛感しました。
これは本スレッドとは別件になってきそうなので、また別のスレッドで質問させていただこうと思っております。
またメールまわりでわからないことがあれば、よろしくお願いいたします。（よろしければ）
2022.03.21 00:58