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

解答の論理構成

1. 【問題文】には
   “DNSの名前解決通信は、主にaを用いる。”
   とあり、一般に DNS の標準ポート 53/UDP が用いられることからaは UDP です。
2. 続けて
   “aは、bハンドシェイクを用いてコネクションを確立するTCPと比べて…”
   と記載されています。TCP で接続を確立する手順は 3way ハンドシェイク であるためbは 3way です。
3. キャッシュポイズニング対策について
   “公開鍵暗号によるディジタル署名の仕組みを応用したcというDNSセキュリティ拡張方式”
   と説明されており、公開鍵署名で DNS 応答を保護する方式は DNSSEC です。

誤りやすいポイント

• DNS＝UDP と短絡し、TCP が併用される（ゾーン転送など）事実を忘れがちです。設問は「主に」と書かれている点に注意します。
• “3way” を “3-way” や “threeway” と表記して減点されるケースがあります。原文に合わせ 3way と書くのが安全です。
• DNSSEC を “DNS‐SEC” や “DNSSec” と表記すると誤答になります。英字 8 字以内で DNSSEC と記述します。

FAQ

解答の論理構成

1. 攻撃者は DNS の“キャッシュポイズニング攻撃（CP攻撃）”を試みています。問題文には「大量のDNSパケットは、応答PTの送信元IPアドレスや宛先ポート番号を細工した、キャッシュポイズニング攻撃…」とあります。
2. CP攻撃では、権威ある応答より先に偽応答をキャッシュ DNS に届かせる必要があり、攻撃者は UDP の特性を利用して“宛先ポート番号”と“識別子(Transaction ID)”を総当たりします。
3. したがって防御側は、攻撃者が推測しにくいように“送信元ポート番号を毎回変化させる”ことで組合せ総数を増やし、偽応答が一致する確率を下げられます。
4. 問題文には「C－DNSサーバの設定を調べたところ、CP攻撃を成功しにくくする設定がなされていることを確認」とだけ書かれており、その具体策を答える設問です。
5. DNS ソフトウェアにおいて CP攻撃対策として最も一般的で、かつ“ポート番号”を使う設定は“送信元ポート番号ランダム化”であるため、解答は「問合せPTの送信元ポート番号をランダムに変えること」となります。

誤りやすいポイント

• 「TCP を使う」と書く誤答
  UDP の欠点を補うのは 権威問い合わせ側 であって再帰 DNS が常時 TCP を使う訳ではありません。
• 「Transaction ID を長くする」と書く誤答
  ID は 16bit 固定なので“長くする”こと自体はできず、実際の対策はランダム化です。
• 「宛先ポートをランダム化」と書く誤答
  宛先は常に 53/udp。ランダムにするのは“送信元”です。

FAQ

解答の論理構成

1. C-DNSサーバのポリシを確認した結果、 「再帰的な名前解決の問合せPTの送信元を限定する設定が行われていることも確認した。」
   と記載されています。すなわち、許可対象となる送信元だけが再帰問合せを出せます。
2. 図2(1)の問合せPTは
   「送信元が外部メールサーバであり、かつ、宛先がC-DNSサーバであり、かつ、FW-Aが通過を許可した問合せPT」
   です。
3. 外部メールサーバは、MXレコードやSPFレコードの確認などメール配送処理で再帰的な名前解決を頻繁に行います。そのため、C-DNSサーバ側で当該送信元を許可リストに入れておく必要があります。
4. したがって、図2(1)の問合せPTを拒否しない理由は、外部メールサーバが正当な再帰的名前解決の利用者だから、となります。

誤りやすいポイント

• 「外部メールサーバ＝インターネット向けだから内部向けDNSは不要」と早合点しがちですが、実際には内部DNSを介して外部の名前解決を行う運用も一般的です。
• 「限定する設定」とあるため“全ての外部から拒否”と誤読すると失点します。送信元のホワイトリスト方式であり、外部メールサーバがリスト内に含まれる点を見落とさないことが重要です。
• 問題文中の「再帰的な名前解決」と「権威DNSへの問い合わせ」の違いを混同すると論点がずれます。

FAQ

解答の論理構成

1. IP アドレス詐称対策ルールの目的
   表２の項番１は、外部側インタフェース「IF-1」に到着したパケットのうち、送信元 IP アドレスが内部のどれかを名乗っているものを検知し、 “拒否” する設定です。「外から来たのに送信元が社内アドレス」を即座に遮断することで IP スプーフィングを防ぎます。
2. 「内部に該当するネットワーク」を整理
   図１で FW-A の内側に配置されているのは次の３領域です。
   ・「DMZ1」…図中の (d)
   ・「DMZ2」…図中の (e)
   ・「内部ネットワーク」…図中の (f)
   これらはいずれも FW-A の背後（社内）にあるため、外部インタフェース IF-1 から到着する正当なパケットの送信元になることはありません。
3. 欠落していた設定内容
   表２の項番１には【送信元：DMZ1, 内部ネットワーク】とありましたが、上記３領域のうち「DMZ2」が抜け落ちていたため、(e) からの詐称パケットが通過してしまうリスクが残っていました。
   したがって、送信元として設定すべきネットワークは (d) DMZ1、(e) DMZ2、(f) 内部ネットワーク の３つとなります。
4. よって解答
   (d)、(e)、(f)

誤りやすいポイント

• DMZ2 を「外部公開サーバ用だから社外」と思い込み除外してしまう。DMZ も FW‐A の内側であり、詐称対策対象に含める必要があります。
• 「宛先」で考えてしまい、送信元アドレスをチェックするルールであることを見落とす。
• IF-1 が “外向き” ではなく “外部から到着するインタフェース” である点を取り違え、(b) や (c) を設定してしまう。

FAQ

解答の論理構成

1. 図2の(2)では「送信元がG社のDNSサーバであり、かつ、宛先がC-DNSサーバである応答PTが100個届き、FW-Aが通過を拒否した」とあります。
2. その応答内容は「G社のドメイン名のTXTレコード」であり、「TXTレコードには、SPFレコードが設定されていた」と明記されています。
3. さらに「SPFレコードに設定されていたIPアドレスは、G社に割り当てられたものではなかった」とあるため、攻撃者が偽のSPF情報を注入しようとしていると分かります。
4. SPFはメール送信元を検証する仕組みであり、偽のSPFがキャッシュに登録されると当該IPから送られるメールを正当と誤認してしまいます。
5. したがって下線②「TXT レコードを利用する機能への攻撃」とは、偽SPFを使って「G社のドメイン名になりすましメールを外部メールサーバへ送信」しようとする行為だと導けます。

誤りやすいポイント

• TXT＝SPFと短絡し、メール以外の用途（DKIM、DMARC 等）を答えてしまう。
• 攻撃対象を「C-DNSサーバ」や「FW-A」と誤解し、メール送信という最終目的を見落とす。
• 「G社」ではなく自社や取引先など別の名称で記述してしまう（固有名詞の改変）。

FAQ

解答の論理構成

• 【問題文】には「送信元が支社プロキシサーバに詐称された問合せPT を拒否する設定は不可能であり、FW-A のIP アドレス詐称対策機能が有効に機能しないことが分かった。」とある。
• 支社プロキシサーバからの正規の DNS 問合せも、攻撃者が送る詐称パケットも、どちらも B 社サービス経由で FW-A の外向けインタフェース「IF-1」に到達する。
• FW-A の IP アドレス詐称対策は「受信インタフェースと送信元アドレス帯の組合せ」で不正を判定する仕組みである（表2のルール構造）。
• 正規・詐称のいずれも「IF-1 から入り、送信元アドレス＝支社プロキシサーバ」と一致するため、FW-A から見れば両者は区別できない。
• よって「IF-1経由で届く支社プロキシサーバからの正規の問合せPTと、詐称された問合せPTとを識別できないから」という結論になる。

誤りやすいポイント

• IF-1 は“外部”インタフェースであるにもかかわらず、支社プロキシサーバの正規通信もここを通る点を見落としやすい。
• IP アドレス詐称対策＝パケットフィルタリングルールの追加と早合点し、インタフェース判定ロジックを忘れる。
• DMZ1／DMZ2 と内部ネットワークのアドレス帯を混同し、支社プロキシサーバを内部側と思い込むミス。

FAQ

解答の論理構成

1. 支社プロキシサーバの名前解決は当初、既存の「C-DNSサーバ」に委ね、通信は「B社サービス」経由で行う計画でした。本文には「送信元が支社プロキシサーバに詐称された問合せPT を拒否する設定は不可能であり、FW-A のIP アドレス詐称対策機能が有効に機能しない」とあります。
2. このままでは、支社側から C-DNS サーバへ届く“詐称パケット”を FW-A で見分けられず、IP アドレス詐称対策が破綻します。
3. そこで「再検討した結果、③支社システムに機能を追加することで対応することにした。この対応策によって、支社プロキシサーバとC-DNSサーバ間の通が不要になることも確認した」と記述されています。
4. “通が不要”になるのは、支社側だけで名前解決を完結できる場合です。X システムの C-DNS サーバが持つ下記の機能を支社側へ実装すれば実現できます。
   • 表1より「C-DNSサーバ」は「リゾルバ機能及びDNSキャッシュ機能」がある。
5. したがって、支社システムに追加すべきなのは「リゾルバ機能及びDNSキャッシュ機能」です。これにより、支社プロキシサーバは自前で再帰問い合わせ・キャッシュ保持を行い、FW-A を経由する DNS 通信が発生しなくなります。

誤りやすいポイント

• 「DNSSEC を導入する」と誤解しやすいですが、③は支社側だけの対処であり本文でも「DNSSEC」には触れていません。
• 「IP アドレス詐称対策ルールをFW-Aに追加」と考えがちですが、本文が示す課題は“FW-A を経由しない構成にする”ことで解決すると明言されています。
• 支社側に置くのは「DNSサーバ」そのものではなく、プロキシサーバ内、または DMZ 内の装置に「リゾルバ機能及びDNSキャッシュ機能」を持たせる点を取り違えやすいです。

FAQ