情報処理安全確保支援士 2010年 春期 午後2 問01

解答の論理構成

1. 問題文では、SSH接続について「パスワード認証方式の利用を中止し、公開鍵認証方式に変更すること」と指摘されています。公開鍵認証方式では、クライアントはサーバの“公開鍵”を正しく把握していることが前提です。
2. 初回接続時にクライアントへ提示される“フィンガプリント”は、SSHサーバの公開鍵に対して計算されたハッシュ値です。
3. 利用者がこのフィンガプリントを事前に信頼できる経路で受け取った値と照合できれば、(a)公開鍵が改ざんされていないこと、(b)攻撃者が別サーバを“なりすまし”として差し込んでいないこと—すなわち「SSHサーバの公開鍵が正しく、なりすましがないこと」を確認できます。
4. 以上から、フィンガプリントで確認できる事項として模範解答の内容が導かれます。

誤りやすいポイント

• フィンガプリント＝接続先サーバそのもののハッシュと誤解し、公開鍵との対応を忘れる。
• フィンガプリントを「暗号化が行われていること」を示す情報とだけ理解し、真正性確認の目的を落とす。
• 事前共有が不要と考え、提示された値をそのまま受け入れてしまう（初回 MITM 攻撃を防げない）。

FAQ

解答の論理構成

1. 現状の FW ルール
   表1の項番12は
   ― 送信元:「すべて」
   ― あて先:「DMZ」
   ― サービス:「SSH」
   ― 動作:「許可」
   と定義されています。これではインターネット上のどこからでも DMZ へ SSH 接続できてしまいます。
2. 技術Ｇの審査指摘と対策の方向性
   図4の指摘(1)で「FWルールの設定内容を見直し、より厳しく制限すること。」と明示されています。
3. 接続元ネットワークの見直し
   文章中に
   「見直しの結果、契約通信サービスを、Y社専用のIPアドレスが割り当てられるものに変更し、更に①FWルールの設定内容も変更することにした」
   とあります。つまり SSH を使うのは “契約通信サービス経由で接続してくる運用ＧのノートPC” のみでよいことになります。
4. 変更箇所の決定
   ・あて先は従来どおり DMZ の各サーバ（SSH サーバ）で問題なし。
   ・許可対象を絞るには送信元を「すべて」から “Y社専用 IP のみ” へ変更すればよい。
5. 変更後の送信元内容
   文中の表現を引用すると
   「契約通信サービスを、Y社専用のIPアドレスが割り当てられるもの」
   となるため、送信元は「契約通信サービスにおいて割り当てられるY社専用のIPアドレス」と記述するのが適切です。

誤りやすいポイント

• 「あて先」を DMZ ではなく個々の SSH 対応サーバ名に変更すべきと勘違いする。あて先は従来ルールでも DMZ 内に限定されているため問題ありません。
• 動的に割り当てられる IP=不定だからフィルタ出来ないと誤認する。文中には “Y社専用のIPアドレスが割り当てられる” とあり、範囲を固定で把握できる前提です。
• 公開鍵認証への変更と FW ルール修正を混同し、「SSH のポート番号を変更する」など別次元の対応を書いてしまう。

FAQ

解答の論理構成

1. 問題文には次の記述があります。
   ――「根本的な対策として、aというDNSのセキュリティ拡張方式の導入が考えられた。aは、DNSのレコードに公開鍵暗号方式によるbを付加し、応答を受け取った側ではそのbを検証する方式である。」
   ここから、aは“DNSのセキュリティ拡張方式”であり、公開鍵暗号で付加・検証されるbは“ディジタル署名”であることが読み取れます。
2. DNSで公開鍵暗号を用いてレコードに署名を付加し、キャッシュポイズニングなどの改ざんを検出できる標準技術は「DNS Security Extensions」、すなわち「DNSSEC」です。
   したがって、a＝「DNSSEC」と判断できます。
3. 「公開鍵暗号方式によるbを付加し…検証する方式」という説明は、DNSSECが各リソースレコードセットに付与する「RRSIG＝ディジタル署名」を指します。
   よって、b＝「ディジタル署名」となります。
4. 以上より、解答は
   a：「DNSSEC」
   b：「ディジタル署名」
   となります。

誤りやすいポイント

• 「TSIG」や「DNS over HTTPS」など、別のDNS関連セキュリティ技術と混同しやすい点に注意が必要です。TSIGはゾーン転送や動的更新の認証技術であり、問題文の説明「DNSのレコードに…付加」は当てはまりません。
• bを「公開鍵」や「鍵ペア」と誤記するケースが多いですが、DNSSECが付加・検証する対象は公開鍵そのものではなく「ディジタル署名」です。
• DNSSEC導入には“ゾーン署名”や“鍵管理”が不可欠ですが、設問は名称のみを問うているため運用面の記述と混同しないようにしましょう。

FAQ

解答の論理構成

1. 【問題文】には「DNSキャッシュポイズニング対策を行う」と明記されています。
   これは DNS サーバが偽の情報をキャッシュしないようにする対策です。
2. 同じく【問題文】で「内部LAN1に接続されているPC及び内部LAN2に接続されているサーバの名前解決には、hostsファイルを用いている」とありますが、Web サイト閲覧の際はインターネット側のホスト名を解決するために DMZ 上の「DNS サーバ」を参照します。
3. 「DNSキャッシュポイズニング攻撃」とは、攻撃者が偽の IP アドレスを DNS サーバのキャッシュに注入し、本来のドメイン名と偽サーバの IP アドレスを紐付ける行為です。
4. その結果、Y 社の PC から Web アクセスを行うと、DNS サーバは偽 IP アドレスを返答し【図1】の通信経路で本来想定していないサーバへ接続してしまいます。
5. よって設問の問いに対し、「アクセスしたいWebサーバとは別のサーバにアクセスしてしまう」という結論になります。

誤りやすいポイント

• 「接続不能になる」と誤答しがちですが、実際には“別の”サーバに誘導される点が本質です。
• hosts ファイルを使っているから安全と思い込むケースがありますが、インターネット側ドメインの解決は DNS に依存します。
• キャッシュポイズニング＝サービス停止と短絡的に結び付けるのは誤りで、真正性の欠如が問題です。

FAQ

解答の論理構成

• 本文では、DNSキャッシュポイズニング攻撃への対策として
  「DNSサーバで、②名前解決の問合せにおいてDNSキャッシュポイズニング攻撃を受けやすい不適切な設定を行わない」
  と明示されています。
• DNSキャッシュポイズニングは、攻撃者が偽の応答パケットを正規の応答より先に送信し、キャッシュを書き換えることで成立します。成立条件は以下のとおりです。
  1. **取引ID（Transaction ID）**が一致していること
  2. 送信元ポート番号が一致していること
• 取引IDは 16bit で 65,536 通りしかなく、総当たりは現実的です。よって防御の決め手は送信元ポート番号を予測困難にすることです。
• ところが、「不適切な設定」として 固定ポート（例えば UDP/53）を使用し続ける設定を行うと、攻撃者はポート番号を簡単に推測でき、上記 1 と 2 の両方を短時間に満たせます。
• 製品サポート窓口が提示した“行わない設定”は、この固定ポート運用であるため、設問の解答は
  「送信元ポート番号を固定する設定」となります。

誤りやすいポイント

• 「再帰的問い合わせを許可すること」＝不適切設定と早合点しやすい
  → 本文では再帰許可は別途アクセス制御で対処し、②は“キャッシュポイズニング対策”の文脈です。
• 「DNSSEC を導入しないこと」と勘違いする
  → DNSSEC は根本対策として a に示される選択肢で、②で問われているのは既存環境での設定ミスです。
• 取引IDばかりに注目し、ポートランダマイズの重要性を見落とす
  → 16bit ID だけでは推測が容易であり、ポート番号の予測困難性が決定的な要素です。

FAQ

解答の論理構成

1. 問題文では、図5の指摘事項として
   「カタログWebサーバ及び受注Webサーバのドメイン名を使用したメール送信DNSサーバの設定によって c を行うこと」
   と要求しています。
2. 直後の会話で、M主任は迷惑メール対策として
   「送信側の DNS サーバに Sender Policy Framework（SPF） の設定を追加すれば対応できる」
   と説明しています。
3. SPF は、送信者メールアドレスのドメインと実際にメールを配送する MTA の IP アドレスを DNS レコードでひも付け、受信側で整合性を検証させる仕組みです。これは、DomainKeys Identified Mail（DKIM）や Authenticated Received Chain（ARC）などと並ぶ「送信ドメイン認証」技術群の一つです。
4. さらに Nさんが「c の方法の一つですね。」と応答していることから、c には SPF という個別技術名ではなく、SPF を含む包括的なカテゴリ名が入ると判断できます。
5. 以上より、c に入る適切な語は「送信ドメイン認証」となります。

誤りやすいポイント

• SPF をそのまま解答してしまう。SPF はあくまで「送信ドメイン認証」の代表例であり、会話文でも “方法の一つ” と位置付けられています。
• 「ドメイン認証」「ドメイン認証技術」など曖昧な用語を使用する。試験では正式名称「送信ドメイン認証」が求められます。
• DKIM と混同する。DKIM も送信ドメイン認証の一種ですが、DNS に公開鍵を置きメールヘッダへ署名する方式であり、会話で触れられている設定内容（SPF レコード）とは異なります。

FAQ

解答の論理構成

1. 【問題文】ではカタログWebサーバのドメイン名について
   「送信者メールアドレスとしてカタログWebサーバ及び受注Webサーバのドメイン名を使用したメールは送信しない。③その事実を踏まえて DNS サーバに SPF の設定を追加してくれ」
   と明記されています。
2. SPFは「そのドメイン名でメールを送信するサーバ」を TXTレコード で宣言する仕組みです。メールをまったく送らない場合は、送信を許可するサーバを1つも挙げずに -all（Fail）だけを記述するのが正式な手順です。
3. 記述形式は
   ドメイン名. IN TXT "v=spf1 -all"
   となります。
4. 解答群を照合すると「オ：catalog.y-sha.co.jp. IN TXT "v=spf1 -all"」だけが条件を満たします。
   他の選択肢（ア〜エ）は +ip4:x1.y1.z1.n を含み、送信サーバを許可してしまうため不適切です。
5. 以上から、解答は オ です。

誤りやすいポイント

• 「WebサーバのIPアドレスを SPF に書けば良い」と誤解し、x1.y1.z1.5 を含む選択肢を選んでしまう。Webサーバは SMTP を動かさないので許可対象にしてはいけません。
• +all と -all の違いを取り違える。+all は「誰でも送信可」と宣言するため、迷惑メール対策としては逆効果です。
• ベースドメイン（y-sha.co.jp）とサブドメイン（catalog.y-sha.co.jp）を混同し、メール用ドメインの設定を引用してしまう。

FAQ

解答の論理構成

1. 図6には「インターネット側からＹ社あてのメール受信　ＳＭＴＰを使用し、メールサーバ1で受信し、dである場合はメールサーバ2へ転送し、ほかの場合は拒否する。」と記載されています。
2. 同じ図6の直前には下線④として「メールサーバ1ではオープンリレー防止設定がされている」と明示されています。オープンリレーを防ぐには、自組織宛メールだけを転送し、それ以外は拒否する方式が一般的です。
3. 表3のメールアドレス欄には「y-sha.co.jp」が自社メール用ドメインであることが示されています。
4. 以上から、d に入る条件は「受信者メールアドレスのドメイン名が y-sha.co.jp」のみを許可し、他ドメイン宛は拒否する設定となります。

誤りやすいポイント

• 送信者（From）ではなく受信者（To）のドメイン名で制御する点を取り違える。
• サブドメイン「catalog.y-sha.co.jp」「order.y-sha.co.jp」を許可対象と誤解し、オープンリレー防止が不完全になる。
• “y-sha.co.jp” という表3の字句を解答に含める必要を見落とす。

FAQ

解答の論理構成

1. まず本文には、NDR（配送不能通知）を大量に送信してしまう恐れがある状況が示されています。
   • 引用：「送信者メールアドレスを偽って…送信されたら…偽られた送信者メールアドレスあてにNDRメールが届きます。」
2. 偽装メールが多発すると、NDRメールも大量に発信されます。
   • 引用：「⑤そうしたNDRメールが多いと、メールサーバ1がスパム発信源としてブラックリストに登録される可能性があり、対策が必要だね」
3. ブラックリスト入りすると、他組織のメールサーバは「スパム発信源からの通信」と判断し、正規のメールも受け付けなくなります。
4. したがって被害は「メールサーバ1から送信される正常なメールが受信側で拒否される」ことになります。
5. 以上より、模範解答の内容「メールサーバ1から送信される正常なメールが、ブラックリストを利用しているメールサーバで受信拒否される。」が導かれます。

誤りやすいポイント

• NDRメール自体がスパムだと誤解し、「NDRメールのみが拒否される」と答えてしまう。
• ブラックリスト登録により「Y社がメールを受信できなくなる」と逆の影響を書いてしまう。
• 被害を「情報漏えい」や「ウイルス感染」と勘違いし、本質である“正当メールの配送障害”を書き忘れる。

FAQ

解答の論理構成

1. 接続点（α）の端末は FW の外側、すなわち「すべて」に該当します。表5の項番1には
   「送信元: すべて / 問合せ方法: 非再帰的な問合せ / 問合せ対象ドメイン名: すべてのドメイン名 / 動作: 許可」
   とあり、非再帰的問合せは無条件で DNS サーバに到達できます。
2. 動作が許可された場合 DNS サーバは表6のアルゴリズムを実行します。表6の2行目には
   「キャッシュ領域に保持されているY社管理ドメイン名以外のドメイン名 … 情報を問合せ元に返答する。」
   と明示されており、再帰有無にかかわらずキャッシュ内の外部ドメイン情報は返答対象です。
3. よって α からの非再帰的問合せでも、もし対象ドメインがキャッシュに残っていれば回答が返り、名前解決に“成功”します。
4. 逆にキャッシュに無い外部ドメインは、表6の3行目「解決できずに、問合せ元にネームエラーを返答する。」となるため失敗します。
5. 以上より、成功する条件は「非再帰的な問合せで、キャッシュ領域に保持されているY社管理ドメイン名以外の名前解決を行った場合」となります。

誤りやすいポイント

• 再帰的問合せだけが問題だと考え、非再帰的問合せの許可ルールを見落とす。
• 表6の「キャッシュ領域に保持されている…」の記述を読み飛ばし、キャッシュ有無による挙動差を把握できない。
• ルールは上位から順に適用されることを忘れ、項番3の拒否が常に先に効くと誤解する。
• 「すべて」の送信元に α が含まれることを見逃し、DMZ 内からのアクセスだけが許可されていると誤認する。

FAQ

解答の論理構成

1. 表4の修正案では、「キャッシュDNSサーバ」→e の通信について
   「サービス：DNS」「動作：許可」 と定義する必要があります。
   つまり “e” にはキャッシュ DNS が名前解決先を問い合わせる「あて先」を入れます。
2. 追加されるキャッシュ DNS は “Y社以外の DNS サーバに問合せを行い、その結果を問合せ元に返答する”（表6より）役割を担います。
   したがって問い合わせ先は組織外の上位・権威 DNS であり、Y社ネットワーク外部に位置します。
3. 図1でネットワーク外部を示すのは “(a)” にラベル付けされた “インターネット” です。
   よって、キャッシュ DNS が通信を発するべきあて先 e は “(a) インターネット” となります。
4. これにより
   ・キャッシュ DNS から外部への再帰問い合わせが可能
   ・権威 DNS（「DNSサーバ」）には外部からの非再帰問い合わせのみを許可（表4 項番6）
   という二層構成が完成し、オープンリゾルバ対策 (2-a)「オープンリゾルバを禁止する」 に合致します。

誤りやすいポイント

• 「キャッシュ DNS だから DMZ 内で完結する」と考え (b) を選ぶミス
  → 再帰問い合わせ先は必ず外部なので DMZ ではありません。
• 「再帰問い合わせ＝内部 LAN から外部へ」と混同し (c) や (d) を選ぶミス
  → 表4 で問合せ元は既に「キャッシュDNSサーバ」と固定されています。
• 項番6と7の役割分担を読み飛ばし、両方ともインターネットからの受信と誤解
  → 項番6は“受信”、項番7は“送信”で方向が逆です。

FAQ

解答の論理構成

1. 問題の前提
   表7ではアクセス制御ルールの優先順位を「注　上から順に、最初に一致したルールが適用される。」と明示しています。したがって、最初の許可ルールで“誰に・何を”許すかが鍵です。
2. f の導出
   ルール1の目的は外部からの“非再帰的問合せ”で自組織ドメインの情報だけを提供し、他ドメインは扱わないようにすることです。これは「(2－a) オープンリゾルバを禁止する。」というDMZ対策基準に沿った措置です。
   したがって“問合せ対象ドメイン名”に入る語は、社外から問い合わせを受け付けても良い自社ドメインのみ、すなわち「Y社管理ドメイン名」となります。
3. g の導出
   ルール2はDMZ内サーバが権威情報を取得するためにDNSサーバへ問い合わせられるようにした例外です。問合せ元に該当するネットワークは「DMZ」に限定するのが自然です。
   これは審査指摘「⑥図1中の接続点（α）からDNSサーバに対して、Y社管理ドメイン名以外の名前解決を試みると、成功する場合があり…」を是正し、外部からの再帰的利用を遮断しつつ内部（DMZ）からは許可するという設計意図と一致します。
4. 結論
   よって
   ・f ＝ 「Y社管理ドメイン名」
   ・g ＝ 「DMZ」

誤りやすいポイント

• ルール1を“すべてのドメイン名”で許可してしまうとオープンリゾルバが温存されるため失点します。
• ルール2の問合せ方法を誤って“再帰的”と考えると、外部から再帰的問合せを受け付けてしまう設定になります。
• 表7は上位一致方式なので、後続の拒否ルールを見て安心し先頭ルールの緩さを見落とすミスが頻発します。

FAQ