情報処理安全確保支援士 2016年 春期 午後1 問02

解答の論理構成

1. 問題文では外部メールサーバのフィルタ順序①に
   ――「迷惑メールの送信に悪用されるaを防止するために、エンベロープの宛先メールアドレスのドメイン名がU社ドメイン以外のメールを拒否」――
   とあり、「迷惑メールの送信に悪用」「宛先ドメインが自社以外」から、SMTPサーバが第三者中継と化す“オープンリレー”の防止であることがわかります。したがって a は「オープンリレー」です。
2. フィルタ順序②に
   ――「迷惑メール対策として、b認証技術の一つであるSPF (Sender Policy Framework)によってFailと判定されたメールを拒否」――
   とあるため、bには SPF の属する技術分野名が入ります。SPF は「送信ドメイン認証」の代表例であり、実際に総務省などのガイドラインでも“送信ドメイン認証技術”と表記されます。よって b は「送信ドメイン」と判断できます。

誤りやすいポイント

• “オープンプロキシ”と混同しやすい
  プロキシサーバの設定点検が同一問題文に登場するため、a に「オープンプロキシ」を入れてしまうミスが散見されます。宛先ドメインを自社限定にする制御＝SMTP の中継制御である点に着目しましょう。
• SPF＝IPアドレス照合とだけ覚えている
  SPF のメカニズム自体より、「送信ドメイン認証」というカテゴリ名を書かせる設問です。“SPF＝DNSで送信元IP照合”とだけ記憶していると、b に「IPアドレス」など不正解を書いてしまいます。
• DKIM・DMARCとの取り違え
  SPF が「送信ドメイン認証」に含まれることを忘れ、b に「DKIM」と製品名／方式名単体を書いて失点するケースがあります。

FAQ

解答の論理構成

1. 【問題文】には、図3の説明として「オープンリゾルバ防止機能が適切に設定されていない場合に起きる DNS c 攻撃」と記載されています。
2. さらに本文では「プロキシサーバがDNSc攻撃に悪用されないようにする対策」と繰り返し述べられています。
3. オープンリゾルバが放置されると、攻撃者は送信元 IP を詐称した DNS クエリを大量送信し、応答パケットをターゲットに押し付けてトラフィックを増幅させます。この手口は「DNS リフレクション攻撃」または「DNS アンプリフィケーション攻撃」と呼ばれます。
4. 「リフレクション（reflection）」は“反射”を意味し、詐称されたリクエストが第三者サーバで“反射”される点が語源です。
5. したがって、c に入る字句は「リフレクション」となります。

誤りやすいポイント

• 「DNS キャッシュポイズニング」と混同してしまい、c に「キャッシュポイズニング」と書いてしまうケースがありますが、オープンリゾルバに関する記述なので誤答です。
• 「アンプリフィケーション」と書きたくなる受験者もいますが、本文中は “反射” に焦点を当てており、代表的名称「リフレクション」が適切です。
• DoS 攻撃全般を指す「DDoS」や「フラッド」といった広い表現を入れると設問の趣旨（DNS 特有の反射攻撃）から外れてしまいます。

FAQ

解答の論理構成

• 問題文は、DNSキャッシュ機能の安全性向上策として「名前解決問合せパケットのdのランダム化設定」を確認したと述べています。
• さらに「DNS名前解決通信ではUDPが使われており、UDPヘッダのdのランダム化が設定されていないと、図4に示すようなDNSキャッシュ機能への攻撃が成功する可能性が高まる」と説明されています。
• UDPでキャッシュDNSが外部に問い合わせを出す際、攻撃者は応答パケットの偽造を試みます。識別子となるトランザクションIDだけでなく、問い合わせの送信元ポートまで推測できれば、偽応答を当てる確率が飛躍的に上がります。
• したがってランダム化対象はUDPヘッダのポート番号のうち、サーバ側が自由に選べる「送信元ポート番号」です。
• 以上より d に入る字句は「送信元ポート番号」となります。

誤りやすいポイント

• トランザクションIDも乱数化対象であるため、d に誤って「識別子」や「トランザクションID」を入れてしまう。
• TCPと混同し「宛先ポート番号」と答えてしまう。実際にはDNS問い合わせの宛先ポートは固定で「53」であり、ランダム化の対象になりません。
• DNSSECなど別の対策を連想してキーワードをずらしてしまう。設問はDNSキャッシュポイズニング対策としてもっとも基本的なソースポートランダム化に着目しています。

FAQ

解答の論理構成

1. 問題文の引用
   – 「W氏は、図4の攻撃の結果、eが、DNSキャッシュに保存させられたMXレコードを参照するので、①メール配送に影響が生じることを説明した。」
   – 図1のDMZ内には「外部メールサーバ」が存在し、インターネットと「内部メールサーバ」の間でメールを転送する役割を持つ（表2の機能概要）。
2. e が参照する MX レコード
   – MX レコードは「どのメールサーバへ配送するか」を示す DNS レコードであり、メール転送を行うサーバが参照する。
   – 図1でインターネットと直接やり取りするメール関連機器は「外部メールサーバ」だけである。
3. 以上より、e に当てはまる機器名は「外部メールサーバ」と決定できる。
4. ①で言及される「メール配送に影響」
   – 図4の(2)(3)では「攻撃者が、取引先ドメイン名のMXレコードを用意」し、それをキャッシュポイズニングで置き換える。
   – 置き換え後、正規の宛先ドメインに送るはずのメールが攻撃者の用意したサーバへ届く。
   – 従って具体的影響は「取引先宛てのメールが攻撃者のメールサーバに転送されてしまう」。

誤りやすいポイント

• MX レコードを最初に引くのは「内部メールサーバ」だと誤認しやすいが、インターネット側へ最初に問い合わせるのは DMZ の「外部メールサーバ」。
• 「メール配送に影響が生じる」を抽象的に書きすぎると減点される。誰あてのメールがどこへ行くのかまで具体的に示す必要がある。
• DNS キャッシュポイズニングと SPF などの送信ドメイン認証を混同し、対策を誤って記述しやすい。

FAQ

解答の論理構成

• 【問題文】には、CONNECT メソッド利用時の手順として
  「PCのWebブラウザは、CONNECTメソッドを用いてプロキシサーバに接続し、サーバwww.example.ne.jpとの間のトンネルの確立を要求する。」
  と記載されています。
• CONNECT は “TLS 通信のトンネルを張るためのメソッド” であり、要求行に含めるのは「ホスト名:ポート番号」のみです。ここでパス名（/user035/index.html など）は送出されません。
• したがってプロキシサーバはホスト単位の情報しか得られず、「パス名を含めたURL全体」に基づくフィルタリングは技術的に実施できません。
• この仕様こそが本文中の下線②「HTTP over TLS通信ではURLフィルタリングがホスト単位となる」理由であり、模範解答は
  「パス名を送信しないという仕様」
  となります。

誤りやすいポイント

• 「HTTPS でもプロキシが暗号化前に URL 全体を見られる」と誤解する。実際には CONNECT でトンネルを張った後は暗号化され、プロキシはパスを取得できません。
• ホスト名を SNI (Server Name Indication) で取得できるからパスも取れると混同する。SNI で得られるのはホスト名のみです。
• GET と CONNECT を混同し、GET の書式（パス付き）をそのまま当てはめてしまう。

FAQ

解答の論理構成

1. 脅威の指摘
   本文に「複合機用メールアドレスを詐称したメールがインターネットから送信されて、マルウェア感染が起きるおそれがある」と記載されています。
2. 防御のための操作対象を特定
   外部メールサーバのフィルタ順序(1)〜(6)のうち、送信者を基に拒否できるのは(3)と(5)です。
   • (3)「エンベロープの送信者メールアドレスとブラックリスト1」
   • (5)「メールヘッダの送信者メールアドレスとブラックリスト3」
     詐称メールは一般に “From:” ヘッダを書き換えますが、エンベロープまで偽装するとは限りません。したがってヘッダの送信者を照合する(5)が有効です。
3. 変更箇所の決定
   (5)で用いられるリストは「ブラックリスト3」です。ここに監視対象となるアドレスを登録することで、ヘッダ詐称メールを拒否できます。
4. 登録すべき文字列
   表1で複合機用メールアドレスは「scanner@u-sha.co.jp」と明示されています。
5. 結論
   以上より、変更箇所は「ブラックリスト3」、変更内容は「scanner@u-sha.co.jpを登録する」となります。

誤りやすいポイント

• エンベロープとヘッダの違いを混同し、ブラックリスト1を選んでしまう。
• 「postmaster@u-sha.co.jp」を登録すると、正規の管理者連絡まで遮断してしまう。
• ドメイン単位（@u-sha.co.jp）で登録すると、従業員メールまで拒否対象になり業務停止の原因となる。

FAQ