情報処理安全確保支援士 2012年 秋期 午後1 問03

解答の論理構成

1. まず本文には「Y社は、メールサーバを含む情報システムを国内で運用している」とあります。したがって、通常は“JST（+0900）”のタイムスタンプになるはずです。
2. 図3のReceived:ヘッダには
   Received: from mail.y-sha.co.jp (localhost [127.0.0.1]) ...; Fri, 27 Jan 2012 9:37:58 +0100 (CET)
   とあり、「+0100 (CET)」というヨーロッパ時間が記録されています。国内運用で海外タイムゾーンは不自然であり、解答群「ア：Y社が国内で運用しているはずのメールサーバのタイムゾーンが、日本ではなく、海外になっている点」をbと判断できます。
3. さらに 1 本前のReceived:ヘッダには
   Received: from smtp.y-sha.co.jp (unknown [80.○○.◇◇.☆☆])
   となっており、括弧内の IP アドレス「80.○○.◇◇.☆☆」は Y 社のアドレス帯ではなく、ホスト名解析も“unknown”です。取引先ドメインの正規アドレスでないことは偽装の典型例なので、解答群「ウ：Y社のメールサーバのアドレスが、Y社のアドレスではなく、かつ、DNS参照が“unknown”になっている点」をaと判断します。
4. 以上より
   ・a＝「ウ」
   ・b＝「ア」
   が導かれます。

誤りやすいポイント

• 「NAT変換が無視されている」とする解答群「エ」は、両社ともグローバルアドレスで運用しており NAT の有無は判別できないため誤りです。
• 「中継サーバの隠蔽」を指摘する解答群「イ」は、Received:が3段残っているので“隠蔽”の裏付けが取れません。
• “unknown”表記を「逆引き DNS が登録されていないだけ」と誤解して軽視するミスが頻発しますが、取引先のメールサーバを名乗る以上、本来は正引き・逆引きとも整合しているはずです。

FAQ

解答の論理構成

• SPF が検証対象にするのは「SMTP でやり取りされる送信元情報」です。本文には
  “受信側のメールサーバが、c中の SMTP のdコマンドの引数で指定されたアイデンティティのうちドメイン名の部分を基に、DNSサーバに問合せを行い、SMTP 接続元の IP アドレスと比較します。”
  とあります。
• ここで “SMTP の○○コマンドの引数” と言えば、送信側が自分のメールアドレス（MAIL FROM:user@domain）を宣言する MAIL FROM が定番です。SPF 公式仕様も “The domain given in the SMTP MAIL FROM command is used for SPF evaluation.” と説明しています。
  よって d＝イ：MAIL FROM。
• MAIL FROM は「ヘッダ From:」ではなく SMTP セッションの制御情報に含まれ、ヘッダよりも外側でやり取りされるため「メールエンベロープ」に属します。選択肢オは “メールエンベロープ” なので c＝オ：メールエンベロープ。
• 以上より
  c：オ
  d：イ
  が正答になります。

誤りやすいポイント

• ヘッダ行の “From:” と MAIL FROM を混同し、dにヘッダを指定してしまう。
• 受信者を示す RCPT TO と SPF を結び付けて考え、dをウ：RCPT TO と誤答する。
• メールエンベロープという用語を知らず、本文中の “SMTP の○○コマンド” がエンベロープ制御情報であることを見落とす。
• EXPN／VRFY など管理目的のコマンドに惑わされるが、これらは通常の配送経路では使われないため SPF とは無関係。

FAQ

解答の論理構成

• SPF レコードは、送信側メールサーバが実際にインターネットへ接続するときに用いるグローバル IP アドレスを示す必要があります。
• 【問題文】には FW の説明として
  “社内とインターネットとの間の通信には、グローバルIPアドレス z.y.x.1 を NAT アドレスとして使用する。”
  と明記されています。
• さらに S主任は
  “z-sha.co.jp のゾーン情報を管理している DNS サーバに、図4に示す TXT レコードを登録します。当社のメールサーバの設定変更は不要です。”
  と述べており、DNS に登録する IP は NAT 後のアドレスであると分かります。
• 以上より、図4の e には “z.y.x.1” を入れるのが正解となります。

誤りやすいポイント

• 内部アドレスと外部公開アドレスの混同
  MX1 のプライベート IP を書いてしまうと SPF 検証に失敗します。
• サブネット表記（/32 など）の不要な追加
  記述例は “+ip4:アドレス” であり CIDR を付けない点に注意します。
• “MX1” “MX2” といったホスト名を直接書く誤答
  SPF は IP アドレスを指定する形式です。

FAQ

解答の論理構成

1. 事実確認
   • 本文には、Y社情報システム部から届いた問合せメールを読んだあと、 “A君がリンクをたどったところ、やはり心当たりのない社外サイトであった。”
     とあります。
2. 不適切とされた理由
   • 同じ段落で “A君はこの事態をセキュリティデスクに通報した。” とあるものの、 不審メールに含まれるリンクをクリックしてしまった行為自体がリスク要因になります。
   • そのため下線部 “①A君の対応は不適切でした。” が指摘するのは、リンクを開いた行為です。
3. まとめ
   • 添付ファイルを開かなかった点は適切でしたが、リンクをクリックするという別の入口を自ら作ってしまったため、攻撃者の意図する不審サイトへアクセスしてしまいました。
   • 従って解答は「メール中の社外サイトのリンクをたどった」となります。

誤りやすいポイント

• “添付ファイルを開かなかったから大丈夫” と判断し、リンククリックを軽視する。
• “Y社からの連絡だから安全” と取引先名を過信してしまう。
• メール本文のリンク先 URL を確認せずにブラウザで開いてしまう。

FAQ

解答の論理構成

• 【問題文】では、標的型攻撃の流れとして「(C)感染したPC及びサーバのアクセス権を入手して情報収集を行います。このとき、ウイルスの活動によって異常なトラフィックが発生したり、PC又はサーバが異常な振る舞いをしたりすることもあります。」と明示しています。
  ここで注目すべきキーワードは「異常なトラフィック」です。アクセス権取得後に内部で大量通信が行われると推測でき、通信量の変化を捉える監視が効果的と判断できます。
• さらに下線②として「PC又はサーバの監視強化」を検討するとあり、監視対象は“内部にあるPC／サーバ”であることが確定します。
• 異常トラフィックを早期検知する専用装置・ソフトウェアは一般に「ネットワークモニタ」または「NIDS（Network Intrusion Detection System）」と呼ばれ、内部セグメントに設置するのが典型です。
• 以上から、 • システム名称：「ネットワークモニタ」
  • 設置場所：社内LAN上（PCやサーバの直近で観測できる位置）
  • 監視すべき事象：トラフィックの急激な増加
  が最も素直に導出できます。

誤りやすいポイント

• 監視対象を「インターネット境界（FW前段）」と誤解し、設置場所をDMZにしてしまう。問題文は内部拡散フェーズ(C)への対策と明示しているため内部LANが正解です。
• 監視事象を「不審サイトへのアクセス」などURL単位にしてしまう。本文で強調されているのは量的異常（大量通信）であり、通信先は模倣される可能性があるため量的変化を捉える方が汎用的です。
• システム名を「IDS」だけにすると、ネットワーク型かホスト型かが判別しづらく減点対象になりやすいので「ネットワークモニタ」と明示するほうが安全です。

FAQ

解答の論理構成

1. 下線③には「当社のネットワーク設定で既に遮断できる通信もあります」とあります。これは Z 社が元々実装している “外部との通信を制限する仕組み” を指します。
2. その仕組みが何かを特定するため、問題文冒頭の構成図を確認します。図1では社外側（インターネット）と社内側の境界に「FW」が配置され、FW に直接接続している社内機器は「PRX」と「MX1」だけです。PC や MX2 は FW へ直接は接続していません。
3. つまり、FW が “PRX と MX1 以外の機器に対してはインターネット通信を許可していない” というポリシーを実装しているため、想定外のバックドア通信の大半は FW で遮断できます。
4. したがって、40 字以内で具体的に述べると「FWはPRXとMX1からだけインターネットとの通信を許可している。」が妥当となります。

誤りやすいポイント

• PC が直接インターネットへ出られると誤解し、「プロキシのみ制限」と答えてしまう。
• MX2 を DMZ 側と勘違いし、「MX2 も許可」と書いてしまう。
• FW ではなく PRX で通信制御していると読み違え、機器名を取り違える。

FAQ

解答の論理構成

• 背景確認
  本文には「ウイルスがWebアクセスの通信パターンを模倣して行う通信については、現在のところ防げません。これに関しては、④更なる対策を検討していきます。」とあります。
  つまり、HTTP／HTTPS を装ったバックドア通信が FW を通過してしまう点が課題です。
• 既存設備の把握
  会話の前半で「PRXにウイルス対策ソフトを導入しており」と説明されていますが、現状の PRX は“ファイルのウイルススキャン”が主目的で、通信先 URL／IP の妥当性までは見ていません。
• 求められる機能
  攻撃者は「Webアクセスの通信パターンを模倣」してくるため、 • 宛先 URL／IP が悪性かどうかを判別
  • シグネチャ（ブラックリスト／レピュテーション）に基づき通信を遮断
  ――といった高度な Web フィルタリングが必要になります。
• 解答に至る論理
  以上より、④更なる対策としては「PRX にシグネチャベースの Web フィルタ機能を追加し、怪しい宛先への通信を止める」ことが最も自然な回答となります。

誤りやすいポイント

• FW のポリシー追加と答えてしまう
  HTTP／HTTPS を一律遮断すれば業務も止まり、現実解ではありません。
• PC へのパーソナル FW 設定と書く
  個別端末任せでは運用負荷が高いうえ、攻撃者に無効化される恐れがあります。
• IDS/IPS をLAN側に置くと答える
  IDS/IPS だけでは暗号化通信の内容を解釈できず、シグネチャ型 Web フィルタ導入の意図とずれます。

FAQ