- There’s no filtering out the truth: You need to protect your company’s email.
- Sender Policy Framework (RFC 4408)
- DomainKeys Identified Mail (RFC 6376, RFC 4871 と RFC 5672 を置き換えるもので、現在は廃止されています)
- Domain-based Message Authentication, Reporting, and Conformance (RFC 7489)
- SPF、DKIM、および DMARC の実装方法
- SPFの実装
- Implementing DomainKeys Identified Mail
- Implementing Domain-based Message Authentication, Reporting, and Conformance
- Minimum Config
- But Wait, What About TLS?
There’s no filtering out the truth: You need to protect your company’s email.
2013年には、毎日1000億以上のビジネスメールが送受信された。 2013年に送信された全メールのうち正当なものは5通に1通で、違法なメールの92%には潜在的に悪意のあるコンテンツへのリンクが含まれていました。
しかし改善の兆しもあり、今月は過去12年間で初めて、Symantecの顧客のメールの半分以下がスパムでした。
スパム減少については、3つのメールセキュリティ標準（および他の取り組み）に感謝できます。 SPF、DKIM、および DMARC です。 それでも、セキュリティ リスクは広く存在しています。 最近、ある CFO がフィッシングの被害に遭ったという話を聞きました。 この試みは失敗しましたが、もし成功していたら、その組織は 5 万ドルの損失を被ったでしょう。
これらの電子メール標準に関しては、まだ非常に多くの混乱があります。 この投稿で、SPF、DKIM、および DMARC の実装方法を説明し、少しでも明確にできればと思います。
Sender Policy Framework (RFC 4408)
Sender Policy Framework（SPF）は、メール認証パーティにおける老舗中の老舗です。 SPF は、openspf.org によれば、送信者アドレスの偽造を防止する方法を規定するオープン スタンダードです。 SPF はスパムを阻止するのではなく、送信者偽造の試みを制御し阻止するものです。
SPF により、ドメインの正当なメール ソースを識別し、未許可のソースがドメインから何千、何百万の不正なメールを送るのを阻止することができます。
メール送信者偽造によく関連する 4 種類の不正メールがあります。
- スパム（迷惑なバルク メール & 迷惑な商用メール）
- 詐欺師（419詐欺）
- マルウェア（アドウェア、ゼロデイ、ウイルス、トロイの木馬、その他）
- 。)
- フィッシャー (スピアフィッシング)
組織のドメインがこれらのいずれかに関連付けられることは、明白な理由から避けたいものです。 SPF は、組織のメールが実際にあなたから来ていることを確認するのに役立ちます。
DomainKeys Identified Mail (RFC 6376, RFC 4871 と RFC 5672 を置き換えるもので、現在は廃止されています)
DKIM または DomainKeys Identified Mail は、ドメインネームシステム（DNS）で発行される TXT レコードです。 DKIM に潜入する前に、キーとは何か、キーがどのように機能するかを理解することが重要です。 鍵、この場合、公開鍵暗号方式は、公開鍵 (誰もが知っている) と秘密鍵 (しばしば秘密と呼ばれる) から構成されます。 公開鍵と秘密鍵は数学的にリンクされており、公開チャンネルでの安全な通信を可能にします。
これらの鍵は、透明な封筒の改ざん防止シールのようなものです。 dkim.org によれば、「技術的には、DKIM は暗号化認証を通じてメッセージに関連付けられたドメイン名 ID を検証する方法を提供します」。 言い換えれば、DKIM は、電子メールの送信者が自分で言う通りの人物であることを確認するために鍵を使用します。
DKIM では、公開鍵と秘密鍵のペアが生成されて、メール サーバーと通信が認証された状態に保たれます。
DKIM により、メール サーバーと通信の認証を維持するために、公開鍵と秘密鍵のペアが生成されます。各送信 SMTP (Simple Mail Transfer Protocol) サーバーは、受信メール サーバーが検証する公開 DNS レコードに一致するように、正しい秘密鍵とプレフィックスを必要とします。 これはDKIMとDMARCの一部です(これについては後ほど説明します)。 下図では、mailed-byがSPFとのマッチングを、signed-byがDKIMとのマッチングを表しています。 DKIM と DMARC はまだ必須ではありませんが、IPv6 のように、テストラボからより良いものへと急速に移行しています。
Domain-based Message Authentication, Reporting, and Conformance (RFC 7489)
DMARC (ドメインベースのメッセージ認証、報告、および適合) は、送信側と受信側の協力によってより安全なメールコミュニケーションを実現できるよう手助けをします。 DMARC は、dmarc.org によれば、「電子メール認証プロトコルに関連する、運用、展開、および報告に関するいくつかの長年の問題を解決することにより」、電子メールによる不正使用を制限するために、組織のグループによって作成されました。 DMARCポリシーは、電子メールがSPFまたはDKIM認証に合格しなかった場合、メッセージ受信者が従うべき明確な指示-たとえば、拒否または迷惑メール-を適用します。
SPF、DKIM、および DMARC の実装方法
さて、これら 3 つの標準についてそれぞれ理解が深まったので (そして、なぜこれらが重要なのか)、これらを実装することによって、電子メールのセキュリティをどのように改善できるかを見ていきましょう。
注意: このステップバイステップのウォークスルーのために、あなたが 301 Moved という Google Apps を使用する小さな Web デザイン会社の IT 責任者であると仮定しましょう。 エンドユーザーは、見たこともメッセージを送ったこともないアドレスから電子メールのバウンス通知を受け取ったと不満を漏らしています。
そこで、どのようにそれらを止めるのでしょうか。
注：プレーンテキストでの標準のBINDフォーマットと、GoDaddy DNSでレコードがどのように見えるかのスクリーンショットを含めています。 GoDaddyでは、トップレベルドメイン301Moved.comのすべてのレコードはホスト「@」を使用していますが、あなたのホストはおそらく異なるでしょう。 この演習では、外部送信者からの受信メールに関連してこれらの標準をどのように扱うかではなく、送信メールについてだけ説明することにします。
SPFの実装
ステップ1: Google Appsで動作するSPFレコードを設定するためのGoogleのガイドは、開始するには良い場所です。 これらの指示に従って、パブリックDNSに新しいTXTレコードを追加します。
301Moved.com. IN TXT "v=spf1 include:_spf.google.com ~all"
301 Movedも、ドメインから直接メールを送信するチケットシステムであるZendeskを使用しています。
Step 2: ZendeskのSPFレコードを見つけて追加する。
301Moved.com. IN TXT "v=spf1 include:mail.zendesk.com include:_spf.google.com ~all"
重要なのは、2番目のSPFレコードを追加しないことで、それは状況を壊すことになるのですが、代わりに、それらを単一のレコードに組み合わせ、送信者が増えると長くなります。
注意: 1 つのドメインまたはサブドメインにつき 1 つの SPF レコードしか追加できません。
また、301 Moved は、レガシーなものを処理する古いメール ゲートウェイを構内に持っているので、彼らの IP ブロックも追加しましょう。 301 Movedは、所有するIPブロック-198.51.100.0/24 (192.51.100.0-254) を定義するのに「IP4」メカニズムを使用します。
DmarcianのSPF Surveyorを使って、SPF記録を表示します。
ステップ3。 単体の IPv4 アドレスを追加し、Classless Inter-Domain Routing (CIDR) 表記でネットブロックを追加します。 198.51.100.0 は単一の IP アドレス (/32 は不要)、198.51.100.0/24 はサブネットです。
301Moved.com. IN TXT "v=spf1 ip4:198.51.100.0/24 include:mail.zendesk.com include:_spf.google.com ~all"
古いメール ゲートウェイを追加すると、ゲートウェイからの送信メールが SPF 認証されます。
上記のメカニズムは最もよく使用されていますが、奇妙で非推奨となるものを含め合計 8 種類存在します。 これらのメカニズムはマッチの範囲を定義するだけで、アクションそのものは定義しません。
次のセクションの修飾子は、PASS、SOFTFAIL、FAIL を定義できる場所です。マッチすると、3つのアクション (PASS, SOFTFAIL, FAIL) のいずれかがトリガーされます。
次は修飾子です。 ブラックリストやホワイトリストモデルとこれらを組み合わせる方法はいくらでもありますが、ここでは、ホワイトリストを作るために、先に述べた3つのルックアップ機構と最後に1つの修飾子を含めることにします。 4つの修飾子は次のとおりです：
- +はPASSの結果を表します。 これは省略可能で、例えば +mx は mx と同じです。
- ? は NEUTRAL の結果で、NONE (no policy) のように解釈されます。
- ~ (tilde) は SOFTFAIL で、NEUTRAL と FAIL の間のデバッグ補助になります。 通常、SOFTFAILを返すメッセージは受け入れられますが、タグ付けされます。
- – (マイナス) はFAIL、メールは拒否されるべきです (以下を参照)。
ステップ4: SOFTFAILポリシーを適用します。
今のところ、301 MovedはSOFTFAILのためにチルダを使用します。 チルダを使用すると、Google、Zendesk、または言及された IP ブロックに一致しないすべてのメールが SOFTFAIL になります。 メールはまだ届きますが、スパムまたは迷惑メールフォルダに送られる可能性があります。 しかし、これは完全に受信者のメールサーバーに依存します。
A “-“. (マイナス)を使用すると、一致しないメールは完全にFAIL(バウンス)になる可能性が高いです。 送信メールの可視化 (DMARC を待つ) を開始し、メール インフラストラクチャに慣れてきたら、これをオンにすることができます。
SPF は、メールサーバ自体に変更がないため、すばらしいものです。 ヘッダはそのままでいいのです。 単純なTXTレコード（実際の専用SPFレコードタイプはそれほど普及しておらず、現在は非推奨）だけで、世界中のメールサーバーのほとんどに、あなたの名前を点滅させるべき人を指示できます。
一日の終わりに、受信SMTPサーバーは、照会したSPFレコードと送信者IPをチェックし、あなたの指示に基づいてポリシーを適用します。 言い換えれば、アクセス制御リスト (ACL) を一般に公開しているため、自分自身やプロバイダーが (ほとんど) 信頼できるメールを送信することを承認しています。
しかしながら、メッセージはまだ送信中に変更でき、ずる賢い偽造者やフィッシャーはいくつかの興味深い方法で SPF を回避できます (別の日のトピックになるかもしれません)。 SMTPでは、エンドツーエンドのTLSは保証されていないため、常にクリアテキストを想定する必要があります。
But enter stage right…
Implementing DomainKeys Identified Mail
メールが送信されると、301Moved.comは秘密鍵で（暗号化せずに）メールに署名します。 今後、本文、ヘッダー、添付ファイルを含め、メッセージに何らかの変更を加えると、署名が壊れてメッセージが無効となります。 ここでも、Googleの記事「Authenticate email with DKIM
Step Five」を参照してください。
google._domainkey.301Moved.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCsC1iZ3D7AR3FrKtBYfnoKztCGgExFIReC0b1MPY1rpGZa9aTBYq7cDV6F8lzDVr8/K+z9Xt1gUV4P7tT8wuwgacR4oqiAWaUprbnINAxinJr4ohB1TIW3diX2fEA2t5kyUGCGziJFlHicZyJbk5QEaVLcSFD4V8R9f0Voz4P4jQIDAQAB"
各 DKIM レコードには一意のセレクタ プレフィックスがあり、複数のレコードを発行できることを意味します。 SPFで行ったように1つのレコードにまとめるのではなく、ユニークなセレクタを使用して、必要な数だけ公開鍵を公開することができるのです。
上記のプレフィックスが「google」であることにお気づきでしょう。これはGoogle Appsが公開するDKIMレコードを生成するときに使用するデフォルトのものです。 Google や他のほとんどのセットアップでこれを変更できるので、接頭辞を「dkimawesome」にしたい場合、それを止めるものは何もありません。
一部のクラウド プロバイダーは、これを別の方法で行います。 クラウド テナントごとに固有のキー ペアを生成するのではなく、すべてのドメインのすべての送信メールに同じキーで署名し、そのキーに対してCanonical Name (CNAME) を代わりに発行させるのです。 DKIM または DMARC を使用して電子メールにデジタル署名する (Plus および Enterprise)
Step 6 (該当する場合) を参照してください。 あなたのDNS上のキーを彼らのDNSにCNAMEします。 zendesk1._domainkey.301Moved.com を探しているすべての DNS クエリは、DNS によって zendesk1._domainkey.zendesk.com にリダイレクトされます。
zendesk1._domainkey.301Moved.com IN CNAME zendesk1._domainkey.zendesk.comzendesk2._domainkey.301Moved.com IN CNAME zendesk2._domainkey.zendesk.com
ローカルで nslookup ツール (Unix または Windows) を使用すると、これが他のサーバーにどのように見えるかを見ることができます。 Google Apps は当然サポートしていますが、レガシー メール サーバーはサポートしていないかもしれません。
Implementing Domain-based Message Authentication, Reporting, and Conformance
DMARC (Domain-based Message Authentication, Reporting, and Conformance) は、悪質なメールに立ち向かうための最後の手段です。 DMARC は、リッスンするメール サーバーに対して、SPF と DKIM をどのように扱うか、また、どのように報告するかを中継し、配信率や記録のコンプライアンスについて必要な可視性を提供します。 DMARC ポリシーを設定し、mailto アドレスを特定し、アライメント モードを設定し、ポリシーを適用するメッセージの割合を特定します（心配しないでください、これは思ったより簡単です）。
301Moved.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=100; sp=none"
上のポリシーは p=none として指定されています。 まだメールの流れは全く変えていません-単にポリシーとそれに関連するレポートを設定するだけです。 DMARC 状態の XML レポートが送信されるアドレスは rua= で指定されます。
受信メール サーバーは、SPF、DKIM および DMARC の試練に対して、あなたのドメインからのメッセージ、およびドメインからのメッセージであると主張するメッセージがどのように蓄積されたかを示す XML 添付ファイルを送信します。 また、DKIM が失敗したか、アライメントに失敗したか、成功したか、および上記のポリシーがどのように適用されたかが示されます。
最後に、これらのレポートにはメッセージの最終的な配信処分が示されています。 これらを解析するのに役立つ素晴らしいツールがいくつかあります。 メッセージにポリシーを適用していなくても、ファイアウォール、DNS、および IDS/IPS ログのように、さかのぼって見ることができるものがあるのは常に良いことです。
adkim=rはリラックスしたDKIMアライメントモードを指定し、「r」はリラックス、「s」はストリクトを意味します。 relaxedモードは、メールヘッダ-From:アドレスの共通のOrganizational Domain内の認証されたDKIM d=ドメインが、DMARCチェックをPASSすることを許可します。 Strictモードでは、DKIMのd=ドメインとメールのヘッダーFromアドレスが完全に一致することが必要です。
aspf=r は、SPF チェックを除いて、まったく同じことをします。
pct=100 は、実際に DKIM ポリシーに従って処理されるメッセージの割合です。 ランダムに選ばれ、受信メールサーバーは、あなたのドメインからのメッセージのこのパーセンテージでポリシーを実施します。
ポリシーを適用する前に、p=ポリシー フラグを隔離または拒否にすると、20メッセージのうち1メッセージだけがポリシーを適用するように、これを5つに絞り込みます。 この方法では、完全に失敗した場合でも、pct=100 で開始した場合の 0%ではなく、95% の電子メールが配信されます。
DMARC チェックに失敗したメッセージ、または上記で設定した adkim= と aspf= の整合モードは、隔離ポリシーでは上記のようにソフトバウンスされ、拒否に設定されると完全にバウンスされます。
DMARC は、SPF と DKIM のどちらかがパスすればメッセージを PASS し、SPF と DKIM の両方が失敗した場合のみメッセージを FAIL することに注意することは非常に重要なことです。 つまり、SPFのみ、DKIMのみのメッセージはDMARCに合格しますが、SPF/DKIMのどちらかがないメッセージは常に不合格となります。
Dmarcian の DMARC Inspector を使用して、DMARC レコードを確認します。
Dmarcian は DMARC レポートを簡単に管理できる有料ツールで、他にもたくさんありますが、Dmarcian がたまたま私のお気に入りです。
Update: サブドメイン ポリシー sp=none について尋ねるいくつかのメール (DMARC 準拠！) を受け取りました。 sp=none を含むポリシーでは、どのサブドメインに対しても DMARC ポリシーを指定するわけではありません。 これは、特定のサブドメインごとに適切なDMARCレコードを設定するか、sp=quarantineまたはsp=rejectでメインのDMARCレコードに含めることによって、手動で行われます。
Minimum Config
これを試したい場合、非常にオープンに開始し、何かを強制し始めるのに十分な DMARC レポートが得られるまでシンプルに保つことをお勧めします。
301Moved.com. IN TXT "v=spf1 ip4:198.51.100.0/24 include:mail.zendesk.com include:_spf.google.com MX ?all"
大きなプロバイダは “include:” で、メールを送信できる IP ブロックは “IP4” または “IP6” で定義してください。 受信メールサーバーの認証には「MX」を使用します。 そして、あなたのウェブサイトをホストしているのと同じボックス/サーバーから直接メールを送らない限り（ところで、悪い習慣ですが）、上で述べた「A」メカニズムを省略することができます。 2401>
google._domainkey.301Moved.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCsC1iZ3D7AR3FrKtBYfnoKztCGgExFIReC0b1MPY1rpGZa9aTBYq7cDV6F8lzDVr8/K+z9Xt1gUV4P7tT8wuwgacR4oqiAWaUprbnINAxinJr4ohB1TIW3diX2fEA2t5kyUGCGziJFlHicZyJbk5QEaVLcSFD4V8R9f0Voz4P4jQIDAQAB"
正しいセレクタ、この場合は “google” と正しいキーを取得します。
Note: Please don’t publish this actual key or I’ll be able to DKIM-sign your mail.
301Moved.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=5; sp=none"
For DMARC, we have no policy applied, we are in relaxed mode, but we are asking to the XML reports to the mailbox we can access.これは、XMLレポートが、我々がアクセスできるメールボックスに送られるよう依頼されています。 そこから、DMARC は、3 つのレコードの異なるポリシーをどのように強化するかについて、かなり迅速なフィードバック (リアルタイムではない) を与えてくれます。
But Wait, What About TLS?
Transport Layer Security または TLS は DMARC 標準に含まれていませんし、DNS レコードでもありません。 SMTP を TLS で包んだもので、TLS の内側/外側で他の多くのことができるように、SNMP over TLS や FTP over TLS が一般的な例として挙げられます。 TLS は転送中のみメッセージを暗号化し、静止状態では暗号化しません。
DKIM 署名のメッセージを TLS で送信する場合、それは終始署名されていますが、Google Apps から相手の Cisco Ironport、またはメールが転送される場所にホッピングするときのみ暗号化されます。 TLS は、同じメッセージを読んでいるときに、Web メールへの HTTPS:// セッションにも使用されますが、これも転送中の話です。
TLS は可能な限り使用すべきですが、他のパブリック メール システムに平文を話す準備もできている必要があります。 2015年でさえ、一部のメール サーバーは STARTTLS (TLS ハンドシェイクを開始するためのサーバー用語) をサポートしていません。
簡単な設定変更で、Google Apps の特定の外部ドメインでの TLS 使用を強制することが可能です。 関連する外部のビジネス、パートナー、およびその他の組織のためにオンにするのは良いことですが、TLS が信頼でき、その特定のドメイン上のすべてのメール サーバーでサポートされていることが確認されてから、TLS を強制してください。 確かに、それぞれが何をするのか、どのように連携するのか、少しごちゃごちゃしていますが、これらを実装するのは比較的簡単で、そのメリットは時間をかけるだけの価値があります
。