KEEP LEARNING

アウトプット至上主義

【SPF/DKIM】送信ドメイン認証技術

 

f:id:food_blog:20200617005942p:plain

本記事ではセキスペ 過去問(R.01/秋 午後I 問1)を例題として解説する中で送信ドメイン認証技術の理解を深めます。

※IPA公式サイトから実際の問題を使用しております。 

 

1.前提知識

  • ディジタル署名
  •  SMTP

 

2.知識のインプット

 

エンべロープForm(Envelope-Form)

SMTPという送信プロトコルのコマンドを利用して送信されるFromアドレスで送信者のアドレスが記載される。

受信側が意図的に確認しない限りは見えない値

また配信エラー時の戻り先のメールアドレス

ヘッダForm

こちらも送信者のアドレスが記載されるが、実際の差出人とは異なる情報を記載することができる。

こちらはメールクライアントツール等で実際に出てくる差出人の値

SPF(Sender Policy Framework)

SPFとは電子メールの送信時に「送信のなりすましメール」を防ぐためのセキュリティ技。

SPFは送信側が設定する仕組みであり、DNSにSPFレコードと呼ばれるものを設定することで受信者がDNSのSPFレコードを取得して本人かどうかを検証できる。

O365等のクラウドメールサービスを経由してメールを送信する場合は仕組み上、実際に送信するドメインと元々の送信者のドメインが異なるのでなりすましの判定がされる可能性があるため、SPFレコードの登録は必須レベルです。

SPFの仕組みとしては、送信元が送信元ドメインのDNSに送信元のサーバ名もしくはIPアドレス等をあらかじめSPFレコード(TEXTレコード)を設定しておき、受信側がDNSのSPFレコードを参照しIPアドレス、サーバ名が一致してるか確認することで検証できる。

検証に失敗したメールを受け取るかどうかの設定は受信側の設定に依存する 

DKIM(DomainKeys Identified Mail) 

DKMIもメール送信に関するドメイン認証の仕組み。SPFとの違いとしてはSPFはDNSのSPFレコードで検証するのに対し、DKMIは電子署名で認証を実現する仕組み

 

DMARC

DMARCはSPFとDKIMの両方を利用することでよりセキュアを高める技術

送信側の設定だけでなく受信側のポリシを設定することができる 

 

3.背景

昨今、なりすましメールによって企業機密や金銭を騙し取られるなどの被害が発生しており、その対策として、送信ドメイン認証技術を普及させようとする働きかけがある。送信ドメイン認証技術の基礎知識を含め、実際の業務において与えられた環境に送信ドメイン認証技術を適切に能力を問う

4.過去問の要約

f:id:food_blog:20200616233730p:plain

f:id:food_blog:20200616234000p:plain

f:id:food_blog:20200616233839p:plain

f:id:food_blog:20200616234107p:plain

f:id:food_blog:20200616234158p:plain

f:id:food_blog:20200616234221p:plain

 

5.解説

本文中の空欄にaにはMAIL FROMが入ります

SMTPにおいて送信者のメールアドレスはMAIL FROMコマンド、受信者のアドレスにはRCPT TOコマンドで設定されます。

 

本文中のb〜iには以下が入ります

b:× c:×

bに関しては取引先のDNSサーバでSPFの設定ができていないので認証できません。

cの場合は自社にてSPFの問い合わせを実施しないので認証できません。

 

d:× e:×

dに関しては自社にてSPFの問い合わせを実施しないので認証できません。

eに関しては取引先でSPFの問い合わせを実施しないので認証できません。

 

f:× g:◯

fに関しては自社にてSPFの問い合わせを実施しないので認証できません。

gに関しては自社のDNSにSPFレコードが設定されていて、取引先側もSPFレコードの確認をするので認証できます。

 

h:× i:×

hに関しては自社にてSPFの問い合わせを実施しないので認証できません。

i に関しては自社のSPFレコードが設定されていないので認証できません。

 

図中のjにはx1.y1.z1.1が入ります。

SFPレコードには送信元のIPアドレスまたはホスト名をしてできるので、ここでは送信元メールサーバのIPアドレスであるx1.y1.z1.1が入ります。

 

メール受信側のメールサーバにおいて、SPF認証が失敗してしまう

本文中の下線①で ここでSPF認証が失敗してしまう理由としては以下になります。

送信元のDNSサーバに設定されたSPFレコードのIPアドレスと転送メールサーバのDNSサーバに設定されたSPFレコードのIPアドレスが異なるため。

 

受信した公開鍵、並びに署名対象としたメール本文及びメールヘッダを基に生成したハッシュ値を用いて、DKIM-Signatureヘッダに付与されているディジタル署名を検証する

 上記の検証によってメールの送信元の正当性だけでなく以下を確認することができます。

メール本文とメールヘッダを合わせてハッシュ値にしているためメール本文とメールヘッダの改竄の有無を確認することができます。

 

図7のk,l 表3のm,nにはそれぞれ以下が入ります。

k:mail.x-sha.co.jp     l:x2.y2.z2.1

kに関してMXレコードにはX社のメールサーバを設定する必要があるのでホスト名のmail.x-sha.co.jpが入ります。

SPFレコードには送信元(X社)のグローバルIPアドレスを設定するのでx2.y2.z2.1が入ります。

 

m:quarantine  n:r

mには本文中に受信側で検証に失敗した場合はメールを隔離すると記載があるので、quarantineが入ります。

nには今回はサブドメインを使用しているのでドメインの完全修飾が一致しないのでrが入ります。

 

攻撃者がどのようにN社の取引先になりすましてN社にメールを送信すると、N社がSPF,DKIM,DMARCでは防ぐことができなくなるか?

この問いに関しての回答は以下になります。

 

なりすましの方法としてはHeader-FROMを偽称することで受信側から見たときには、深く見ない限りは判別がつかないが、DMARCのaspfタグを利用することでメールの受信を拒否することができます。

そのため、SPF,DKIM,DMARCが適切に設定された環境下において、なりすましをする方法としてはSPFレコード、電子署名が正しく設定されている、取引先と似たメールアドレスを利用することが方法として考えられます。