電子メールのスプーフィングの検出と防止

はじめに

このドキュメントでは、Cisco Secure Emailを使用する際に、電子メールのスプーフィングを検出して防止する方法について説明します。

前提条件

要件

次のトピックに関する知識を身に付けておくことをお勧めします。

• Ciscoセキュアメール

使用するコンポーネント

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

このドキュメントについて

このドキュメントは、Cisco Secure Emailを導入しているお客様、シスコチャネルパートナー、およびシスコエンジニアを対象としています。このドキュメントでは、次の内容について説明します。

• 電子メールのスプーフィングとは
• 電子メールスプーフィング防御ワークフロー
• さらに、スプーフィング防止を使用して何ができるか？

電子メールスプーフィングとは

電子メールのスプーフィングは、メッセージが実際の送信元とは別の誰かまたは任意の場所から発信されたように見える電子メールヘッダーの偽造です。電子メールのスプーフィングは、フィッシングやスパムキャンペーンで使用されます。これは、信頼できる正当な送信元から送信されたと考えられる電子メールを開く可能性が高いためです。スプーフィングの詳細については、「電子メールのスプーフィングとは」および「スプーフィングを検出する方法」を参照してください。

電子メールスプーフィングは次のカテゴリに分類されます。

[Category]	説明	メインターゲット
ダイレクトドメインスプーフィング	エンベロープの差出人に受信者のドメインと同じドメインを偽装します。	従業員
表示名の偽装	Fromヘッダーには、組織の経営幹部名を持つ正当な送信者が表示されます。ビジネスメール侵害(BEC)とも呼ばれます。	従業員
ブランド名のなりすまし	Fromヘッダーには、既知の組織のブランド名を持つ正当な送信者が表示されます。	お客様/パートナー
フィッシングURLベースの攻撃	機密データの盗難や被害者からのログインを試みるURLが記載された電子メール。リンクをクリックしてアカウントの詳細を確認するように求める銀行からの偽の電子メールは、フィッシングURLベースの攻撃の一例です。	従業員/パートナー
従兄弟または似たようなドメイン攻撃	エンベロープのfromまたはfromヘッダーの値は、実際のアドレスになりすましてSender Policy Framework(SPF)、DomainKeys Identified Mail(DKIM)、およびDomain-based Message Authentication, Reporting and Conformance(DMARC)インスペクションをバイパスする、同様の送信者アドレスを示しています。	従業員/パートナー
アカウントの乗っ取り/侵害されたアカウント	誰かに属する実際の電子メールアカウントへの不正アクセスを取得し、正当な電子メールアカウントの所有者として他の被害者に電子メールを送信します。	Everyone

最初のカテゴリは、電子メールのインターネットヘッダーのエンベロープの送信元の値で所有者のドメイン名を悪用することに関連します。Cisco Secure Emailでは、送信者のドメインネームサーバ(DNS)検証を使用して、正当な送信者だけを許可することで、この攻撃を修復できます。同じ結果は、DMARC、DKIM、およびSPF検証を使用してグローバルに実現できます。

ただし、その他のカテゴリは、送信者の電子メールアドレスのドメイン部分の一部にのみ違反します。したがって、DNSテキストレコードまたは送信者検証のみを使用する場合は、抑止することは簡単ではありません。理想的には、Cisco Secure Emailのいくつかの機能とCisco Secure Email Threat Defense(ETD)を組み合わせて、このような高度な脅威に対抗するのが最善です。ご存知のとおり、Cisco Secure Emailの管理と機能の設定は組織によって異なり、不適切なアプリケーションによって誤検出の発生率が高くなる可能性があります。したがって、組織のビジネスニーズを理解し、機能を調整することが不可欠です。

電子メールスプーフィング防御ワークフロー

スプーフィング攻撃を監視、警告、および防止するためのベストプラクティスに対応するセキュリティ機能を図（図1）に示します。 各機能の詳細は、このドキュメントに記載されています。ベストプラクティスは、電子メールのスプーフィングを検出するための綿密な防御アプローチです。攻撃者は時間の経過とともに組織に対する方法を変更できるため、管理者は変更を監視し、適切な警告と適用を確認する必要があります。

画像 1.Cisco Secure Emailスプーフィング防御パイプライン

レイヤ1：送信側のドメインの妥当性チェック

送信者検証は、従兄弟ドメインのスプーフィングなど、偽の電子メールドメインから送信された電子メールを防止するより簡単な方法です(たとえば、c1sc0.comはcisco.comの詐欺師です)。 Cisco Secure Emailは、送信者の電子メールアドレスのドメインに対してMXレコードのクエリを実行し、SMTPカンバセーション中にMXレコードのAレコード検索を実行します。DNSクエリからNXDOMAINが返された場合、そのドメインは存在しないものとして扱われる可能性があります。これは、検証されていない送信者からの電子メールが受け入れられ、さらに処理されるように、攻撃者がエンベロープ送信者の情報を偽造する一般的なテクニックです。Cisco Secure Emailでは、送信者のドメインまたはIPアドレスが例外テーブルに事前に追加されていない限り、この機能を使用する検証チェックに失敗したすべての着信メッセージを拒否できます。

ベストプラクティス：エンベロープ送信者フィールドの電子メールドメインが無効な場合にSMTPカンバセーションを拒否するようにCisco Secure Emailを設定します。メールフローポリシー、送信者検証、および例外テーブル（オプション）を設定することで、正規の送信者のみを許可します。 詳細については、「送信者検証を使用したスプーフィング保護」を参照してください。

画像 2.既定のメールフローポリシーの送信者確認セクション

レイヤ2:DMARCを使用したFromヘッダーの確認

DMARC検証は、ダイレクトドメインスプーフィングと戦うための非常に強力な機能であり、表示名とブランド偽装攻撃も含まれています。DMARCは、SPFまたはDKIM（送信ドメインの送信元または署名）で認証された情報を、Fromヘッダーの最終受信者に表示されるものと関連付け、SPFおよびDKIMの識別子がFROMヘッダーの識別子と一致していることを保証します。

DMARCの検証に合格するには、着信Eメールで、これらの認証メカニズムの少なくとも1つが合格する必要があります。さらに、Cisco Secure Emailでは、管理者がDMARC検証プロファイルを定義して、ドメイン所有者のDMARCポリシーを上書きし、集約(RUA)レポートと障害/調査(RUF)レポートをドメイン所有者に送信することもできます。これにより、代わりに認証導入を強化できます。

ベストプラクティス：送信者がアドバイスするDMARCポリシーアクションを使用するデフォルトのDMARCプロファイルを編集します。また、DMARC検証のグローバル設定を編集して、正しいレポートを生成できるようにする必要があります。プロファイルを適切に設定したら、メールフローポリシーのデフォルトポリシーでDMARC検証サービスを有効にする必要があります。

画像 3.DMARC検証プロファイル

第3層：スプーフィングされた電子メールをスパマーが送信しないようにする

スパムキャンペーンのもう1つの一般的な形態は、スプーフィング攻撃です。したがって、スパム/フィッシング要素を含む不正な電子メールを効果的に特定し、確実にブロックするためには、アンチスパム保護を有効にすることが不可欠です。スパム対策は、このドキュメントで詳細に説明されている他のベストプラクティスのアクションと組み合わせることで、正当な電子メールを失うことなく最良の結果を得ることができます。

ベストプラクティス：デフォルトのメールポリシーでアンチスパムスキャンを有効にし、スパム設定を明確に識別するための検疫アクションを設定します。スパムメッセージの最小スキャンサイズをグローバルで200万以上に増やします。

図 4.デフォルトのメールポリシーのスパム対策設定

スパムのしきい値は、スパムの陽性と疑いのあるスパムに対して感度を増減するように調整できます（図5）。ただし、シスコでは、特に指示がない限り、管理者がこの調整を行うことを避け、デフォルトのしきい値を基準としてのみ使用することを推奨しています。

図 5.デフォルトメールポリシーのスパム対策しきい値の設定

レイヤ4：電子メールドメインによる悪意のある送信者の特定

Cisco Talos Sender Domain Reputation(SDR)は、電子メールエンベロープおよびヘッダーのドメインに基づいて電子メールメッセージのレピュテーション判定を行うクラウドサービスです。ドメインベースのレピュテーション分析では、共有IPアドレス、ホスティング、またはインフラストラクチャプロバイダーのレピュテーションの範囲を超えて調査を行うことにより、スパムの検出率を高めることができます。代わりに、完全修飾ドメイン名(FQDN)に関連する機能と、シンプルメール転送プロトコル(SMTP)メッセージ交換およびメッセージヘッダー内の他の送信者情報に基づいて判定を行います。

送信者の成熟度は、送信者のレピュテーションを確立するために不可欠な機能です。送信者の成熟度は、複数の情報源に基づくスパム分類に対して自動的に生成され、Whoisベースのドメイン年齢とは異なる場合があります。送信者の成熟度は30日の制限に設定されており、この制限を超えると、ドメインは電子メール送信者として成熟したと見なされ、詳細は提供されません。

ベストプラクティス：SDRレピュテーション判定が信頼できない/要注意に該当する、または送信者の成熟度が5日以下である送信ドメインをキャプチャする着信コンテンツフィルタを作成します。推奨処置は、メッセージを検疫し、Eメールセキュリティ管理者と元の受信者に通知することです。SDRの設定方法の詳細については、『Cisco Eメールセキュリティアップデート（バージョン12.0）：送信者ドメインレピュテーション(SDR)』のシスコのビデオをご覧ください。

図 6.SDRレピュテーションおよびドメイン経過時間のコンテンツフィルタと通知および検疫アクション

レイヤ5:SPFまたはDKIM検証結果による誤検出の削減

ほとんどの攻撃タイプに対してスプーフィングEメール検出のマルチレイヤを構築するには、SPFまたはDKIMの検証（両方またはいずれか一方）を実施する必要があります。シスコでは、最終的なアクション（廃棄や検疫など）を実行する代わりに、SPFまたはDKIMの検証に失敗したメッセージに[X-SPF-DKIM]などの新しいヘッダーを追加し、スプーフィング電子メールの捕捉率の向上を支持して、その結果を後で説明するForged Email Detection(FED)機能と連携させることを推奨しています。

ベストプラクティス：以前のインスペクションを通過した各着信メッセージのSPFまたはDKIM検証結果を検査するコンテンツフィルタを作成します。SPFまたはDKIMの検証に失敗し、次のスキャニングレイヤであるForged Email Detection(FED)に配信するメッセージに新しいXヘッダー（たとえば、X-SPF-DKIM=Fail）を追加します。

図 7.失敗したSPFまたはDKIMの結果を含むメッセージを検査するコンテンツフィルタ

レイヤ6：偽造された可能性のある送信者名を含むメッセージの検出

SPF、DKIM、およびDMARCの検証を補完するForged Email Detection(FED)は、電子メールのスプーフィングに対するもう1つの重要な防御ラインです。FEDは、メッセージ本文のFrom値を悪用するスプーフィング攻撃の修復に最適です。組織内の経営幹部の名前を既に知っている場合は、これらの名前のディクショナリを作成し、コンテンツフィルタでそのディクショナリをFED条件で参照できます。さらに、経営幹部名とは別に、DNSTWIST(DNSTWIT)を使用して、ドメインの外観が似ているドメインのスプーフィングと照合することにより、ドメインに基づいていとこや外観が似ているドメインの辞書を作成できます。

ベストプラクティス：メッセージが偽造されている可能性がある組織内のユーザを特定します。役員向けのカスタム辞書を作成します。すべての経営幹部の名前に対して、辞書にはユーザ名とすべての可能なユーザ名を用語として含める必要があります（図8）。 ディクショナリが完成したら、コンテンツフィルタでForged Email Detection(FED)を使用して、着信メッセージのFrom値をこれらのディクショナリエントリと照合します。

図 8.Forged Email Detection用のカスタムディレクトリ

オプションで、エンベロープ送信に電子メールドメインの例外条件を追加して、FEDインスペクションをバイパスできます。あるいは、FED検査をバイパスして、Fromheader（図9）に表示される電子メールアドレスのリストに対するカスタムアドレスリスト(QAD)を作成することもできます。

図 9.FEDインスペクションをバイパスするアドレスリストの作成

Forged Email Detection独自のアクションを適用して、Fromの値を削除し、メッセージの受信トレイにある実際のエンベロープ送信者の電子メールアドレスを確認します。次に、最終的なアクションを適用するのではなく、条件に一致するメッセージに新しいXヘッダー（たとえば、X-FED=Match）を追加し、そのメッセージを次の検査レイヤに引き続き配信します（図10）。

図 10.FEDの推奨コンテンツフィルタ設定

レイヤ7：確実に識別されるスプーフィング電子メール

実際のスプーフィングキャンペーンを特定することは、SPF/DKIMエンフォースメントおよびFEによって生成されるXヘッダー情報など、パイプラインのさまざまなセキュリティ機能からの他の判定を参照することによって、より効果的です。たとえば、管理者は、SPF / DKIM検証結果の失敗(X-SPF-DKIM=Fail)が原因で新しいXヘッダーと、FEDディクショナリエントリに一致するFromヘッダー(X-FED=Match)の両方で追加されたメッセージを識別するコンテンツフィルタを作成できます。

推奨されるアクションは、メッセージを隔離して受信者に通知するか、元のメッセージの配信を続行し、受信者への警告として[POSSIBLE FORGED]という語を件名の行に追加することです（図11）。

図 11.すべてのXヘッダーを単一（最終）ルールに結合

レイヤ8：フィッシングURLからの保護

フィッシングリンクに対する保護は、Cisco Secure EmailのURLおよびアウトブレイクフィルタリングに組み込まれています。混合型脅威は、スプーフィングとフィッシングメッセージを組み合わせて、ターゲットに対してより正当に見せます。アウトブレイクフィルタリングを有効にすることは、このような脅威をリアルタイムで検出、分析、および阻止するうえで非常に重要です。URLレピュテーションはアンチスパムエンジン内で評価され、スパム検出の決定の一部として使用できることを知る価値があります。アンチスパムエンジンがURLをスパムとして含むメッセージを停止しない場合、セキュリティパイプラインの後半にあるURLおよびアウトブレイクフィルタリングによって評価されます。

推奨事項：悪意のあるレピュテーションスコアでURLをブロックし、ニュートラルレピュテーションスコアでURLをCisco Security Proxyにリダイレクトするコンテンツフィルタルールを作成します（図12）。 メッセージの変更を有効にして、脅威アウトブレイクフィルタを有効にします。URL書き換えにより、疑わしいURLをCisco Security Proxyで分析できます（図13）。 詳細については、「セキュアEメールゲートウェイおよびクラウドゲートウェイのURLフィルタリングの設定」を参照してください。

図 12.URLレピュテーションのコンテンツフィルタ

図 13.アウトブレイクフィルタリングでのURLリライトの有効化

レイヤ9:Cisco Secure Email Threat Defense(ETD)によるスプーフィング検出機能の強化

シスコは、Cisco Talosの優れた脅威インテリジェンスを活用するクラウドネイティブソリューションであるEメール脅威対策を提供しています。応答時間の短縮を実現するAPI対応アーキテクチャ、内部Eメールを含むEメール全体の可視化、状況に応じた情報を提供するカンバセーションビュー、Microsoft 365のメールボックスに潜む脅威を自動または手動で修復するツールを備えています。詳細については、Cisco Secure Email Threat Defenseデータシートを参照してください。 

Cisco Secure Email Threat Defenseは、送信者認証とBEC検出機能を使用してフィッシングと闘います。ローカルのアイデンティティとリレーションシップモデリングをリアルタイムの行動分析と組み合わせた機械学習と人工知能エンジンを統合し、アイデンティティ詐欺ベースの脅威から保護します。組織内および個人間の信頼できる電子メールの動作をモデル化します。Eメール脅威に対する防御の主な機能には、次のような利点があります。

• 高度な脅威検出機能を使用して、既知の脅威、新しい脅威、およびターゲットを絞った脅威を検出します。
• 悪意のある手法を特定し、特定のビジネスリスクに関するコンテキストを把握します。
• 危険な脅威をすばやく検索し、リアルタイムで修復します。
• 検索可能な脅威テレメトリを利用して脅威を分類し、組織のどの部分が攻撃に対して最も脆弱であるかを把握します。

図 14.Cisco Secure Email Threat Defenseは、組織がどのようにターゲット化されているかについての情報を提供します。

図 15.Cisco Email Threat Defenseポリシー設定により、メッセージが選択された脅威カテゴリに一致するかどうかが自動的に判断されます

スプーフィング防止の機能に加えて

多くのスプーフィングは、次のような簡単な予防策を講じて修復できます（ただし、これらに限定されるわけではありません）。

• ホストアクセステーブル(HAT)にリストされているドメインの数を、ごく少数のコアビジネスパートナーに制限します。
• SPOOF_ALLOW送信者グループを作成し、ベストプラクティスリンクに記載されている指示に従っている場合は、送信者グループのメンバーを継続的に追跡および更新します。
• グレイメールの検出を有効にし、スパム検疫にも配置します。

しかし、最も重要なことは、SPF、DKIM、およびDMARCを有効にして、適切に実装することです。ただし、SPF、DKIM、およびDMARCレコードの公開に関するガイダンスはこのドキュメントの範囲外です。詳細については、このホワイトペーパー『Email Authentication Best Practices: The Optimal Ways To Deploy SPF, DKIM, and DMARC』を参照してください。

ここで説明したスプーフィングキャンペーンのように、電子メール攻撃を修復する際の課題を理解します。これらのベストプラクティスの実装に関して質問がある場合は、シスコテクニカルサポートに連絡してサービスリクエストをオープンしてください。または、ソリューションと設計ガイダンスについてシスコアカウントチームにお問い合わせください。Cisco Secure Emailの詳細については、Cisco Secure Email のWebサイトを参照してください。

更新履歴

改定	発行日	コメント
4.0	28-May-2026	再認定
3.0	23-Aug-2024	改善のフラグが設定されたドキュメントと、これらの推奨事項に対応するための変更が行われました。「フォロー」を削除し、1つのSEOエラーを修正しました。
2.0	07-Jun-2023	「代替テキストと前提条件」セクションを追加。 PII、SEO、タイトル、イントロダクション、機械翻訳、スタイル要件、ゲルンド、フォーマットを更新。
1.0	13-Sep-2019	初版