令和6年秋期試験 午後 問2 - 解説

出題趣旨
電子メール（以下，メールという）の送信者メールアドレスを詐称したフィッシングが多くなっている。送信者メールアドレスの正当性を判定する対策としてDMARCの導入が進んでいる。本問では，メールのドメイン名の変更を機とした新たなメールサービスの導入を題材として，メールサービスの設定及びDMARCの導入を問う。

設問1

    • a: A社ドメイン名
    • b: 全て
  • 〔aについて〕
    第三者中継（オープンリレー）とは、本来そのメールサーバを利用する権限がない外部からのメール送信要求を受け付けてしまう状態を指します。そのようなサーバは迷惑メールなどの踏み台にされるおそれがあるため、外部から外部への中継は原則として禁止し、正当な送信元だけが利用できるようにします。

    表2「第三者中継防止のためのルール」は、項番1～3で許可する条件を列挙し、それ以外は最後の項番4ですべて拒否するホワイトリスト型のルールになっています。したがって、空欄aには「転送元がインターネット」であるもののうち、宛先として受け入れるべきドメイン名が入ります。ここを「全て」としてしまうと、第三者中継を許してしまうため絶対にNGです。

    表1のメールサーバの説明には以下の記述があります。
    • インターネットとの間で、SMTPを用いてメールを転送する
    • 宛先メールアドレスのドメイン名がaであるメールをメールボックスに格納する
    この記述より、メールサーバは「宛先メールアドレスのドメイン名がaであるメール」を受信して、社内のユーザーのメールボックスに格納する役割をもつことがわかります。

    本文中には、A社は10年前に「a-sha.co.jp（以下，A社ドメイン名という）」を取得し、A-Webサイトとメールアドレスのドメイン名として利用しているとあります。従業員のメールアドレスは「ユーザー名@a-sha.co.jp」の形式であり、このメールアドレスのドメイン部分がA社ドメイン名です。A社の従業員は顧客との見積書や注文書の送受信、メールマガジンの購読など、インターネット上の相手と頻繁にメールをやり取りしているため、外部から送信されてくるメールのうち、A社の従業員宛てのメール（宛先がA社ドメイン名であるもの）を許可する必要があります。したがって、空欄aには「A社ドメイン名」が妥当します。

    ∴a＝A社ドメイン名

  • 〔bについて〕
    図1より、PC-LANはA社内のネットワークであり、従業員はPC-LAN内のPCで業務を行っています。本文では、A社では顧客との見積書や注文書の送受信を行っているとあり、PC-LANから複数の組織宛てにメールを送っていることが示されています。つまり、PC-LANからのメールの宛先ドメイン名はA社内に限られず、不特定多数になります。

    第三者中継防止の観点で問題となるのは、インターネットなど外部から来たメールを、そのまま別の外部ドメイン宛てに中継してしまう通信です。一方で、社内の正規利用者がPC-LANから外部の取引先にメールを送信する通信は、正常な業務として許可しなければなりません。項番2で宛先ドメイン名を限定してしまうと、PC-LANから外部の顧客宛てにメールを送れなくなり、業務に支障が出てしまいます。

    したがって、項番2では、社内LANから外部の不特定多数のドメインへ送信するメールを許可する必要があります。表2の項番4に示された記述ルールに従えば、空欄bに入る語句は「全て」となります。

    ∴b＝全て
広告

設問2

    • c: SMTPS
〔cについて〕
メール送信に用いるプロトコルとして何を使用するすべきかが問われています。

メールの送信処理自体にはSMTPが用いられますが、標準のSMTPでは通信内容が暗号化されず、そのままの形でネットワーク上を流れます。利用者の認証情報やメール本文を安全に送るためには、このSMTPの通信路をTLSによって暗号化する必要があります。

SMTPの通信をTLSで保護した方式を一般にSMTPSと呼びます。クライアントとメールサーバ間の送信経路を暗号化し、盗聴や改ざんのリスクを低減できるため、本問のように安全なメール送信プロトコルを求める設問ではSMTPSを選択するのが適切です。したがって、空欄cに入るのは「SMTPS」となります。

なお、メール送信を暗号化する仕組みとして「STARTTLS」がありますが、こちらはSMTPの拡張仕様（暗号化の開始方法・コマンド名）であり、プロトコルではないため解答としては不適切と言えます。

∴c＝SMTPS
広告

設問3

    • エ
    • d: イ
  • Z社がUサービスでDKIMを利用するときに、DNSに登録すべきDKIMレコードのFQDNが問われています。DKIMレコードは、デジタル署名の検証に使用される公開鍵を登録するDNSリソースレコードです。

    DKIMでは、メール送信時に送信側がメールにヘッダーや本文に対してデジタル署名を行い、DKIM-Signatureヘッダーとして付加します。受信側はDKIM-Signatureヘッダーからドメイン名とセレクタを読取り、その情報を基にDNSから公開鍵を取得して署名の検証を行います。このヘッダーには以下のような複数のタグが含まれています（他にもあります）。
    • v - バージョン情報
    • a - 署名アルゴリズム
    • d - ドメイン名
    • h - 署名対象となるヘッダーの一覧
    • s - セレクタ
    また、DKIMレコードの書式は次のようになっています。
    ＜セレクタ名＞._domainkey.＜ドメイン名＞
    DKIM-Signatureヘッダーのsタグ（z2024）がセレクタ名、dタグ（z-sha.co.jp）がドメイン名に対応しますから、DKIMレコードのFQDNは「z2024._domainkey.z-sha.co.jp」となります。

    ∴エ：z2024._domainkey.z-sha.co.jp

  • 〔dについて〕
    DMARCは、SPFやDKIMの認証結果を基に、受信側でメールをどのように扱うかをポリシーとして指定する仕組みです。SPFやDKIM認証で「なりすましかもしれない」と判定されたメールを、そのまま受信させるのか、迷惑メール扱いにするのか、受信自体を拒否するのかを送信側が宣言します。

    この設定ポリシーは、DMARCレコード内のpタグで指定します。指定できる値はnone、quarantine、rejectの3種類です。acceptやreceiveといった値は定義されていません。
    • none（なし） - 何もせずそのまま受信する
    • quarantine（隔離） - 受信メールを迷惑メールフォルダ等へ隔離する
    • reject（拒否） - 受信を拒否する
    図3のMail-Step1では、「DMARCポリシーを，特定のアクションを要求しないこととし，メールを受信してもらう」と記載されており、これに対応するpタグの内容は「none」です。

    ∴d＝イ：none

    【参考】
    ruaタグは、受信側で行われたDMARC検証の集計レポートの通知先メールアドレスです。
広告

設問4

    • ソフトウェア修正プログラムに見せかけたマルウェアをダウンロードさせる。
    • メール: 社外サービスのパスワード再設定画面のURLが書かれたメール
    • 攻撃: 任意のパスワードを設定し，アカウントを乗っ取る。
    • e: ア
  • 失効後のA社ドメイン名を取得した第三者が、そのドメインを使用してWebでどのような悪用ができるか、その具体的な攻撃方法が問われています。

    まず、A-Webサイトでどのようなコンテンツが提供されていたかを確認します。本文冒頭には、A社のWebサイトでは「一般向けにIR情報と関連会社へのリンクを，顧客向けに自社製の工作機械管理用アプリケーションプログラムとそのソフトウェア修正プログラムを提供している」とあります。これらは顧客が業務で利用するプログラムであり、ダウンロードしてPCにインストールして使うことが想定されます。

    次に、Aドメイン名の悪用例をまとめた表7を見ます。Webの悪用の例として、第三者がA社ドメイン名を用いて現在のA-Webサイトと見た目が同じWebサイトを立ち上げることができ、さらにコンテンツを細工してWebサイトの見た目を変えずに顧客に影響を及ぼす攻撃を行うことが考えられるとあります。

    上記2点を踏まえると、攻撃者は見た目を正規のA-Webサイトと同じに保ったまま、ダウンロードさせるプログラム（コンテンツ）の中身だけを悪意のあるものに差し替える、という攻撃が想定されます。具体的な攻撃方法としては、A-Webサイトと同じ見た目の偽サイトを用意し、そこで提供するソフトウェア修正プログラムのダウンロードリンクを、本物に見せかけたマルウェアに差し替えておく、という形になります。既にアプリケーション本体を利用している顧客が更新のために偽サイトにアクセスした場合、正規の更新プログラムだと信じてダウンロード・実行してしまうおそれがあります。その結果、顧客のPCや工作機械管理システムがマルウェアに感染し、業務に直接の悪影響が及ぶことになります。

    ∴ソフトウェア修正プログラムに見せかけたマルウェアをダウンロードさせる。

  • 使用されなくなったA社ドメイン名が第三者に取得され、その第三者が社外サービスからのメールを受信できるようになってしまった場合に、どのような悪用が考えられるかが問われています。

    下線③の状態では、もともとA社の従業員が社外サービスに登録していたメールアドレス（例：user@a-sha.co.jp）が、ドメイン名の再取得によって第三者の管理下に移っています。ところが、社外サービス側の登録メールアドレスは古いまま残っていることがあります。利用者本人もメールアドレスの変更漏れに気付かないまま、その社外サービスでパスワード変更や再発行の手続きを行うことが想定されます。

    多くの社外サービスでは、パスワードリセットの操作を行うと、登録済みメールアドレス宛にパスワード再設定画面のURLを記載したメールを送信します。このとき、登録メールアドレスに古いA社ドメインのアドレスが設定されたままであれば、そのメールは第三者が取得したドメインのメールサーバに届きます。攻撃者は、このパスワード再設定用URLが書かれたメールを受信し、自分の環境からURLにアクセスして任意のパスワードを設定します。こうして本来の利用者とは無関係のパスワードに変更してしまうことで、その社外サービスのアカウントを乗っ取ることができます。

    このように、問題が想定しているメールの内容は「社外サービスのパスワード再設定画面のURLが書かれたメール」であり、攻撃内容は「任意のパスワードを設定し、アカウントを乗っ取る」という流れになります。なお、多要素認証が適用されているサービスではリスクを低減できますが、本問ではそこまでの前提は置かれておらず、パスワードリセット手順だけでアカウント乗っ取りが成立するケースを考えています。

    ∴メール：社外サービスのパスワード再設定画面のURLが書かれたメール
    　攻撃：任意のパスワードを設定し，アカウントを乗っ取る。

    【参考】
    (1)や本問のように、解約されて使われなくなったドメイン名が再び取得可能になった瞬間を狙って登録し、以前そのドメインを使っていたメールアドレスなどを悪用する行為は一般に「ドロップキャッチ」と呼ばれます。

  • A社ドメイン名のSPFレコード中の記述内容が問われています。

    図3では、Mail-Step4後のA社ドメイン名メールの運用について、A社ドメイン名使用の契約は継続する一方で、「DMARCの受信対応を行った組織がA社ドメイン名からのメールを拒否できるようにする。・・・そのために，A社ドメイン名についてSPFレコードを図5のように設定する。DKIMレコードは設定しない」と説明されています。

    SPFレコードは「v=spf1」から始まり、その後に許可する送信元や評価方法を並べ、最後に「all」によってデフォルトの動作を定義する形式となります。このとき「all」の前に付ける記号（限定子という）で動作が変わります。
    • +all　認証する（Pass：デフォルト）
    • -all　認証しない（Fail）
    • ~all　疑わしい（Softfail）
    • ?all　判断できない（Neutral）
    block、deny、refuseはSPFの構文として無効なので、そもそも適切ではありません。

    本問の条件では、Mail-Step4でA社ドメイン名宛てのメールの受信を停止し、メールサーバ用DNSレコードも削除した後、A社ドメイン名についてDMARCレコードとSPFレコードだけを残します。これは、A社自身はもうA社ドメイン名でメールを送らない前提で、第三者がA社ドメイン名を取得して不正なメールを送った場合に、DMARCの受信対応を行っている組織がそれを拒否できるようにするためです。

    この目的を確実に達成するには、「A社ドメイン名から送信してよい送信元は1つもない」とSPFで宣言し、どのIPアドレスから送られてきてもSPF認証が失敗するようにしておく必要があります。そのための記述が「v=spf1 -all」です。許可ドメインを記述しなければ、allが全ての送信元を対象となり、「-」はSPF認証失敗（fail）を意味するため、このレコードを参照する受信側では必ずSPFが失敗します。DKIMレコードは設定しないと明記されているので、DKIMでも認証成功することはありません。結果として、DMARC対応している受信側はA社ドメイン名からのメールを認証失敗と判定し、送信元ドメインのDMARCポリシーに従って拒否できるようになります。

    ∴e＝ア：-all
広告

設問5

    • SPFレコードに，Tサービスのメール送信元IPアドレスを追加する。
    • SPF: SPFレコードにYサービスの情報が登録されていないのに，メールがYサービスから送られる。
    • DKIM: DKIMレコードのhタグにSubjectが含まれているのに，YサービスでメールのSubjectが変わる。
  • 下線④では「Mail-Step3以降で，一斉配信されたメールが届かない場合がある。メールが届くように，Mail-Step2の期間で，表3の項番3での登録内容を見直す必要がある」と説明されています。Mail-Step3は送信対応のDMAERCポリシーを隔離～拒否に変更するフェーズであり、表3項番3は「DMARCレコード，SPFレコード及びDKIMレコードをSサービスに登録する」という内容です。したがって、一斉配信用にTサービスを利用することでメールが届かない内容を、3種類のレコードの変更で解決する手段を答える必要があります。

    表4項番3にあるように、DMARCでは、SPF又はDKIMによる認証（ヘッダーFromとの整合性チェックも含む）のいずれかが成功すれば認証成功と判断されます。つまり、メールが届かない場合では、SPF、DKIMの両方が失敗することになります。

    Uサービスを利用したメール送信とは異なり、Tサービスを利用したメーリングリストでは、SPFとDKIMの取扱いは次のようになります。
    • SPF - メール転送によりMAIL FROM（エンベロープFrom）にはZ社ドメイン名が使用されるが、送信元メールサーバはTサービスのドメインとなる
    • DKIM - 「他のヘッダーは，Tサービスが設定する」とあるため、そもそも付与されない（Uサービスで付与された署名は破棄される）
    その結果、受信側のDMARC認証では次のように判定されます。
    • SPF - Z社ドメインのSPFレコードにTサービスのドメインが存在しないため認証失敗
    • DKIM - 付与されていないため認証失敗となる
    このようにDMARCには、単にメール再配送しても認証が通らない課題があります。

    DKIM認証をパスさせるためには、メールを再配送する側（本問ではTサービス）がDKIM署名を再度付与する必要があります。しかし、この対応をメーリングリスト運営者側に求めることは実務上困難であり、本文で示されている「表3項番3の登録内容を見直す」という記述とも整合しません。このような場合、一般的には、メーリングリストサービスのドメインをSPFレコードに登録することで、DMARC認証をパスできるようにします。したがって、適切な対応は「SPFレコードにTサービスのメール送信元IPアドレスを追加する」となります。

    ∴SPFレコードに，Tサービスのメール送信元IPアドレスを追加する。

  • 図8の説明にあるとおり、ヘッダーFrom設定1とSubject設定2の組合せを用いると、SPFとDKIMの両方で認証に失敗して不達になる理由を、Sサービスへの登録内容とYサービスの仕様から説明する必要があります。

    【SPFについて】
    SPFは受信メールのエンベロープFrom（＝SMTPのMAIL FROM＝Return-Path）と送信元メールサーバのIPアドレスの関係に基づいて、メールの正当性を検証します。Z社の送信対応では、Uサービスを利用してメールを送信し、そのIPアドレスなどをSPFレコードとしてSサービス（DNS）に登録しています。Tサービスを利用する一斉配信についても、見直しでTサービスの送信元IPアドレスをSPFレコードに追加することにしましたが、YサービスについてはSPFレコードに登録したとは書かれていません。

    Yサービスでは、メーリングリストから配信されるメールのエンベロープFromに、メーリングリスト管理者のメールアドレス（Z社ドメイン名のアドレス）を設定する仕様です。一方で、実際に各メンバーに送信するのはYサービスのメールサーバです。受信側でZ社ドメイン名のSPFレコードを参照しても、YサービスのIPアドレスは登録されていませんから、SPF認証は失敗します。

    【DKIMについて】
    DKIMでは、署名対象とするヘッダーの一覧をhタグで指定します。表6を見ると、hタグにはFrom、To、Subjectなどが含まれていることがわかります。

    YサービスのSubject設定は2通りあり、設定1では元メールのSubjectをそのまま使用し、設定2では元メールのSubjectに通番情報を付加するとされています。元メールに対してUサービスがDKIM署名を付けた時点では、hタグに含まれるSubjectは「通番情報が付く前」の値です。その後、YサービスでSubject設定2が選ばれていると、メーリングリスト配信時にSubjectの末尾に通番情報が付加され、署名対象であるSubjectヘッダーの内容が途中で変わってしまいます。署名時のSubjectと、受信時に検証に使われるSubjectが一致しなくなるため、DKIM署名の検証は失敗します。

    このように、ヘッダーFrom設定1とSubject設定2が組み合わさると、両方の検証が失敗し、DMRAC認証をパスすることができません。これによりメールが届かなくなります。

    ∴SPF：SPFレコードにYサービスの情報が登録されていないのに，メールがYサービスから送られる。
    　DKIM：DKIMレコードのhタグにSubjectが含まれているのに，YサービスでメールのSubjectが変わる。
広告
広告
▲
Pagetop