DMARCを実装して、企業ドメインをなりすましから保護します

マンウェリの逃亡者



こんにちは、Habr！ この投稿では、送信者の改ざん（またはいわゆるなりすまし）の問題について再度説明します。 最近、そのようなケースは非常に頻繁になりました：すべてが偽造されています：税務検査官、銀行などからの住宅および共同サービスのための手形が付いている手紙。 厳密なDMARCポリシーを設定すると、この問題の解決に役立ちます。 郵便サービスとして、2013年2月以降にDMARCに到着したすべての手紙を確認します。 私たちは、 RuNetメールサービスでDMARC標準をサポートした最初の企業でした。 ただし、偽の電子メールの数を最小限に抑えるには、残念ながらこれでは十分ではありません。 主なことは、厳密なDMARCが送信側でサポートされていることです。 そのため、このトピックをダウンロードすることに飽きず、積極的な説明作業を行い、すべての人に厳格なDMARCを含めることを強く求めています。



すでに前向きな変化があります。毎月、DMARCを登録している企業の送信者の数は数十パーセント増加しています。 ただし、もちろん、まだやるべきことがあります。 実践は、IT文化が非常に異なるレベルであることを示しています。 誰かが私の耳の下からDMARCについて聞いたことがありますが、これまでのところ紹介しません。 電子メール転送プロトコルに送信者アドレスの検証と保護がないという事実は、まだ本当の暴露です。 さらに、DMARCのサポートは簡単な作業ではありません。 DNSにレコードを公開するだけで十分なように思えますが、追加のソフトウェアやハードウェアは必要ありません（詳細については、 DMARCの記事：メーリングリストを偽物から保護してください ）。 実際には、多数の電子メールストリームとメールドメインの無秩序な構造を持つ大企業では、すべてがはるかに複雑です。 そして、事前に考え、考えるべき瞬間があります。 このような難しいケースのために、私たちはこの記事を書き、その中のすべてのニュアンスを集めようとしました。



大企業や政府機関とやり取りする際に開発した推奨事項に基づいて、DMARCの実装に関する独自の経験と、踏み込んだ（取り消した）すべてのレーキを共有したいと考えています。 ドメイン名を保護するためのDMARCポリシーの実装のみを検討します。 企業のメールサーバーユーザーを偽のメールから保護するためのDMARCサーバーパーツの導入は、完全に独立した独立した独立したプロセスです。



DMARCは、[差出人]フィールドでポリシーを公開しているドメインを使用する着信文字によるアクションのポリシーです。 DMARCを使用すると、このようなメールの処理方法を指定できるだけでなく、DMARCサーバー部分をサポートするすべての受信者から統計を収集することもできます。



主な問題は、DMARCがすべての正当な手紙の承認を必要とすることです。 このためには、承認方法（SPFとDKIMが基本プロトコルとして使用されます）を導入するだけでなく、例外なくドメインリターンアドレスを持つすべての正当な文字に対して承認が渡されるようにする必要があります。 したがって、DMARCの導入は次の段落から始める必要があります。

1.ドメインとそのサブドメインからの正当なメールを監査する

このプロセスの典型的な省略：

• 外部のメールサービスプロバイダーを介して送信されるセールスレター。
• 内部メーリングリスト。
• ボックスからのメールのリダイレクト。
• サーバーおよび機器によって生成された技術文書。
• レターの配信レポート（DSN）または配信エラー（NDR）。

文字のカテゴリごとに、SPFを実装し、DKIMを使用して文字に署名する可能性または不可能性を見つける必要があります。

2.プライマリドメインとそのサブドメインにSPFを実装する

SPFは送信者アドレスが改ざんされないように保護しているとよく耳にします。 そうではありません。 SPFは、ユーザーに表示されないSMTPエンベロープのアドレスのみを制御します。 ただし、多数のドメインではまだ実装されておらず、多くの関係者はSPFと互換性のあるメール転送をサポートしていません。 このため、ニュートラルSPFポリシー（ニュートラル?



）またはソフトブロッキング（ソフト拒否、 ~



）が最もよく使用されます。 DMARCと共有する場合、どのデフォルトポリシー（ニュートラル?



ソフト拒否~



または拒否-



）が使用される?



は関係ありません。 特にセキュリティを要求するドメインを除き、拒否（ -



）ポリシーを使用することはお勧めしません。これは、転送やメーリングリストなど、間接的な方法で正当なメッセージの配信に悪影響を及ぼす可能性があるためです。 受信者の大部分は、厳格なポリシーを公開する場合でもSPFの文字をブロックしませんが、重み分類子の一部としてSPFを使用します。 一般的な信念に反して、実際に最も頻繁に適用されるのはまさにこのSPFモードであり、標準の推奨事項に完全に準拠しています。



SPFを実装するには、次の推奨事項を提供できます。

• エンベロープ送信元アドレス（別名MAIL FROMおよびReturn-Path）からドメインのSPFがチェックされることを忘れないでください。 SPFを使用してメッセージの送信者を認証するには、エンベロープ送信元ドメインがFromヘッダードメインを組織ドメイン（つまり、.ruまたは.comの第2レベルドメイン）に一致させる必要があります。 エンベロープ送信元に間違ったアドレスを使用することは、最も一般的なサーバー構成エラーの1つであり、CMSおよびサーバースクリプトです。
  
  
  
  
• SMTPでは、メッセージの一部のカテゴリ（ NDR 、 DSN ）に空のエンベロープ送信元アドレスがあります。 このようなレターの場合、認証は送信者のSMTPサーバーがHELO / EHLOコマンドで使用し、原則としてサーバーの正規名と一致するドメインに従って実行されます。 HELOコマンドの誤った名前は、別の一般的な問題です。 HELOのドメイン名が正しいことを確認し、そのための適切なSPFポリシー（ mailserver.example.org. TXT "v=spf1 a -all"



mailserver.example.org. TXT "v=spf1 a -all"
  
  
  
  。 配信の不可能性に関するメッセージでは、送信者アドレスにドメインをまったく指定できません（たとえば、 From: mailer-daemon:;
  
  
  
  ）、または組織のドメインまでのHELOドメインに一致するドメインを使用できません（通常、 From: mailer-daemon@example.org
  
  
  
  などの第2レベルドメインです） From: mailer-daemon@example.org
  
  
  
  ）。
  
  
  
  
• SPFはサブドメインに影響しないことに注意してください。 サブドメインごとに実装するか、 ワイルドカードDNSに頼る必要があります 。
  
  
  
  
• SPFには、レコードごとに10個の名前解決の制限があります。 したがって、 mx
  
  
  
  やinclude
  
  
  
  など、追加のアクセス許可につながる要素の使用を最小限に抑える必要がありinclude
  
  
  
  。 たとえば、 mx
  
  
  
  要素の場合、MXレコード自体を取得するために1つの追加要求が必要であり、MXレコード内のサーバーごとに1つの要求が名前でIPアドレスを取得するために必要です。

3.プライマリドメインとサブドメインのポリシーなしでDMARCレコードを公開します

そのような記録の例：

 _dmarc.example.com. TXT "v=DMARC1;p=none;rua=mailto:rua@example.com;ruf=mailto:ruf@example.com;fo=s"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このレコードは、受信者に毎日の統計レポートをrua@example.com



に送信するように指示します。 レポートから、ドメインに代わってメールが送信されたすべてのIPアドレスと、これらのレターの承認ステータスSPF、DKIM、およびDMARCが表示されます。 IPアドレスからのメールには特に注意してください。 リビジョンで文字のカテゴリまたはソースを逃したかどうかをレポートで確認します。 必要に応じて、SPFを調整します。 一部の受信者は、SPF（ fo=s



）の問題の個々のケースに関するレポートをruf



に送信できます。これらのレポートは、問題のあるメールを識別するのに役立ちます。



典型的な問題と推奨事項：

• メインメッセージフローに対して少なくとも1つのSPFまたはDKIM認証メカニズムが実装される前に、 none
  
  
  
  タグを使用してポリシーを公開することはお勧めしません。
• 録音はv = DMARC1で始まる必要があり、文字の大文字小文字が重要です。
• 一部のDNSクライアントは、セミコロンの前にバックスラッシュを表示しますv=DMARC1\;p=none
  
  
  
  -しかし、DNSゾーンレコードでは、通常、バックスラッシュは必要ありません。
• rua / rufアドレスは、ポリシーが公開されているのと同じ組織ドメインに属している必要があります。または、受信ドメインは、レポートを受け入れる同意を示す特別なポリシーを公開する必要があります。 パブリックメールなどのアドレスへのレポートを受信することはできません。
• DKIMの実装を完了していない場合、パブリックメール（Mail.Ru、Gmail、Hotmail / Outlook、Yahooなど）のIPアドレスから多くのDMARC違反を受け取ります。 これは、これらのサービスのユーザーが他のメールボックスへのリダイレクトを頻繁に使用するためであり、SPF認証の違反につながります。 この問題は、DKIM署名を実装することで修正されます。
• DMARCレポートを視覚化するための優れたツールがあります。 Dmarcianは、有料および無料（少量のメール用）のサービスと、DMARCレポートを表示するための便利な無料のXML-to-Humanコンバーターツールを提供します。 Agariとproofpointは、 DMARCの実装とサポートのための商用サービスも提供しています。

4. DKIMを展開する

推奨事項：

• サーバーによって生成された文字が構造、エンコード、ヘッダーの数に関する推奨事項に準拠していることを確認してください。そうしないと、メールリレーによってメッセージが送信されたときに、文字が標準に合わせて変更される可能性があり（ほとんどの場合、長い行が壊れます）、DKIM署名に違反します。
• 長さが1024または2048ビットのキーを使用します。
• DNSサーバーが大解像度をサポートしていることを確認してください。 通常、このためには、UDP / 53を介してサーバーにアクセスすることに加えて、TCP / 53を介したアクセスをさらに許可する必要があります。 DKIMキーを持つTXTレコードが外部ネットワークから正しく解決されていることを確認してください。
• relaxed / relaxed canonicalizationモードを使用すると、送信中の文字の正規化に関連する問題が発生することはほとんどありません。
• メッセージの配信時に変更されるヘッダー（Received：やReturn-Path：など）に署名しないでください。DKIM署名を適用する前に、必要なヘッダー（Date：、Message-ID：、From :)が形成されていることを確認してください
• すべてのサブドメインのすべての電子メールソースにDKIMを展開します。
• 必要に応じてキーを無効にできるように、外部ソース（メール配信サービスプロバイダー）に個別のキーを持つ個別のセレクターを使用します。
• DMARCの場合、DKIM署名で使用されるドメインは、Fromヘッダーのドメインと組織のドメインを組織の正確さに一致させる必要があります。 他のDKIM署名が存在する場合がありますが、無視されます。
• 外部サービスからの統計レポートでDKIMの実装を監視します。
• DMARCポリシーでfo=1
  
  
  
  を使用します。これにより、DMRC承認に合格した手紙であっても、SPFおよびDKIMのすべての問題に関するフォレンジックレポートを受け取ることができます。

5.厳格なポリシーへの切り替えを開始します

検疫ポリシーは、既存の問題を隠してしまう可能性があるため、長時間使用しないでください。 集約されたレポートからのみ問題の存在について学習することが保証されており、受信するのに1日以上かかる場合があります。



配信エラーの潜在的な問題を追跡するために、拒否ポリシーを10％（ p=reject; pct=10



）有効にすることから開始できます。 ただし、このようなポリシーを長期間保持することはお勧めしません。残りの90％の応答では、検疫ポリシーが適用され、単一の問題をスキップできます。



DMARCに関連するエラーのレターを配信できないことについては、サーバーのログとレポートに注意してください。 標準では、DMARCサーバーパーツを展開する受信者がエラーメッセージで理由としてそれを示す必要があるため、問題を特定するには、エラーメッセージのキーワードとして「DMARC」を使用することをお勧めします。 サーバーログによると、レポートよりもはるかに早く問題が表示され、どのアドレスが配信されなかったかを正確に知ることができます。



メインドメインのポリシーとは異なるポリシーを実装するには、サブドメインに個別のポリシーを公開するか、メインドメインのポリシーで指定することにより（ p=none; sp=reject



）、spポリシーは独自のポリシーを公開しないサブドメインに作用します。



すべてのサブドメインが厳格なポリシーに切り替えられた場合、サブドメインのポリシーを削除するか、自分の判断でポリシーを残すことができます。 これは、確立された慣行（現在、標準では議論されていません）に従ったレポートの生成にのみ影響します。 サブドメインがポリシーを公開すると、個別のレポートが届きます。 個別のポリシーがない場合、サブドメインレポートは親ドメインレポートに含まれます。

6.調整ポリシーDMARC

以下は、DMARCレコードのいくつかのオプションフィールドの解析、使用例と推奨事項です。



p （ p=reject



）-DMARCポリシー。 認証に失敗したメールの処理方法を受信者に伝えます。 値none



（受信者に手紙を配達する）、 quarantine



（Spamフォルダーに手紙を配達する）、 reject



（手紙を受け入れない）の値を取ることができます。



sp （ sp=quarantine



）-独立したポリシーを公開しないサブドメインのポリシー。 サブドメインに独自のDMARCポリシーがある場合、 sp



はそれに影響しません。 sp



フィールドが、独自のポリシーを持たないサブドメインのDMARCレコードにない場合、 p



フィールドのポリシーが適用されます。



pct （ pct=20



）-このポリシーの対象となる文字の割合。 たとえば、 reject



ポリシーをpct=20



に設定すると、 reject



ポリシーは20％の確率で受信メッセージに適用され、 quarantine



ポリシーは80％の確率で適用されます。



rua （ rua=mailto:ruamailbox@example.com



）-受信者が集約（統計）レポートを送信するアドレス。 アドレスは同じ組織ドメインに属している必要があります。 集約されたレポートのアドレスを公開し、少なくともDMARCポリシーの実装フェーズ中にそれらを監視することをお勧めします。



ruf （ ruf=mailto:rufmailbox@example.com



）-フォレンジックレポート（つまり、調査）が別の文字で送信されるアドレス。 デフォルトでは、法医学レポートはDMARC違反に対してのみ送信されます。 foオプションを使用して、動作を制御できます。 現在、比較的少数の受信者がフォレンジックレポートを送信しています。



fo （ fo=1



）-違反が通知を送信する対象。 fo=0



（デフォルトの動作）は、両方の認証が失敗した場合にのみレポートを送信します：SPFおよびDKIM。 fo=1



代替方法が合格した場合でも、認証のいずれかが失敗した場合。 fo=s



、SPF認証の問題に関するフォレンジックレポートを送信します。 fo=d



-DKIM問題の場合。



adkim （ adkim=r



） adkim=r



ドメインコンプライアンス検証モード。 デフォルトでは、 r



（緩和）モードが使用され、組織ドメインのみが一致する必要があります。 厳密（ s



）モードでは、送信者アドレスのドメインとDKIM署名のドメインが完全に一致する必要があります。 サブドメインの一部が信頼できない当事者に委任されている場合は、厳密なドメインマッチングを使用するのが理にかなっています。



aspf （ aspf=r



） aspf=r



-fromのドメインについても同様で、SPFとFromがチェックされます。 aspf=s



SPF認証に合格するにaspf=s



これらのドメインが正確に一致する必要があります。



ri （ ri=86400



）-集約されたレポートを受信するための望ましい間隔（秒単位）。 デフォルトでは、レポートは1日に1回送信されますが、一部の受信者（このオプションのサーバーサポートはオプションであるため、すべてではない）は、より短い間隔でのレポートの送信をサポートします。 ポリシーの実装の段階で、たとえばri=3600



ように、より小さいriを使用しようとすることができます。



ドメイン所有者が電子通信でドメイン名を保護することを検討し始めたことを非常に嬉しく思います。 DMARCの設定に関するヘルプは、 ここから入手できます 。 SPF、DKIM、DMARCの設定に関して質問がある場合、またはアドバイスやヘルプが必要な場合は、dmarc_support @ corp.mail.ruに連絡するか、こちらで質問してください。 一緒になって、すべてのユーザーのメールをより安全にできることを願っています。