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

解答の導き方

1. 外部からの指摘内容を確認する

• 表3には「送信元IPアドレスaaa.bbb.ccc.ddd」とあり、注に「aaa.bbb.ccc.dddは、図1中のプロキシサーバのIPアドレスである。」とあります。外部からは「プロキシサーバのIP（DMZ側のIP）からC&CサーバへTCP/443で接続があった」と報告されていることがまず読み取れます。
• この外向きのセッションが社内発であるかを確かめるには、インターネット境界で該当セッションを観測できる機器のログを確認するのが合理的です。図1でインターネットとDMZ／社内の間に位置するのはFW1です。さらに、表1のFW1のルールには該当する通信で「ログ取得」が「する」となっているため、外部に向けたセッションの有無（送信元IP/宛先IP/ポート/時刻）がFW1のログで確認できます。
  → ここから、P君が最初に確認したログはFW1であると導けます。

1. どの端末がその外向きセッションを発生させたかを特定する手順

• FW1のログで「送信元がプロキシサーバ（aaa.bbb.ccc.ddd）である」ことが確認できても、実際にその外向き接続のトリガになったのは社内の端末（プロキシ経由で要求を出した端末）です。どの端末がプロキシに接続してその要求を出したかを直接記録している機器はプロキシです。問題文に「プロキシサーバでは、各機器からの全てのアクセスについて、アクセスログを取得している。」と明記されています。
• プロキシのアクセスログは、リクエストを出した社内PCのIP（タイムスタンプ）を記録するため、そのログとDHCPや認証ログを突き合わせれば、どの端末・どの利用者が当該接続を起こしたかを特定できます（本文の調査手順や図2の調査結果と整合します）。
  → したがって、通信を開始した端末を特定するために確認したログは プロキシサーバ のログです。

• a に入る機器：FW1
• b に入る機器：プロキシサーバ

誤りやすいポイント

• FW1とFW2を取り違える
  図1の位置関係を見落として「内部側のFW2で確認すべき」と誤ることがあるが、外部から見えているセッションをまず確認する場所はインターネット境界にあるFW1です（ただしFW2も内部→プロキシのトラフィックを許可・ログ取得しているため補助的に参照可能である点は注意）。
• 送信元IPアドレスを「元の端末のIP」と誤認する
  外部に見えている送信元IPはプロキシやNATのIPであることが多く、必ずしも実際に操作した端末のIPではありません。今回も表3で送信元がプロキシサーバのIPとして示されています。
• HTTPSで中身が見えないから追跡不可能と考える
  HTTPSの通信内容は見えなくても、プロキシ接続（CONNECT）のログや接続タイムスタンプ、クライアントIPなどのメタ情報で発端端末は特定できます。問題文は「プロキシサーバでは...アクセスログを取得している」と明示しています。
• 単一ログだけで確定してしまうリスク
  特定にはプロキシログ、FWログ、DHCP、認証サーバ、W-APログなど複数ログを突き合わせるのが確実です。片方のログだけで結論を急ぐと誤結論を招きます。

FAQ

解答の論理構成

1. まず本文には「コピーは ①ファイル単位ではなくセクタ単位で全セクタを対象とした」と明記されています。
   • ファイル単位バックアップでは、ファイルシステムが“存在している”と認識するデータしか保存されません。
2. インシデント対応では、攻撃者が痕跡を消すためにファイルを削除・隠蔽している可能性が高いです。
   • 削除されたファイルは“未割当て領域（空きセクタ）”に残留している場合があります。
3. そこでセクタ単位の完全コピーを行えば、
   • ファイルシステムが把握していない 未割当て領域 や スラックスペース も含めて複製できます。
4. これにより、攻撃の痕跡となる「削除済みマルウェア／ログ／設定ファイル」を後からフォレンジックツールで復元・解析できるようになります。
5. 以上より、P君が想定した調査は
   1. “削除されたファイルの内容” を
   2. “空きセクタの情報からファイル復元ツールを用いて”
      調査することだと導けます。

誤りやすいポイント

• 「全セクタ＝バックアップを安全に取りたいだけ」と早合点し、フォレンジック目的を見落とす。
• “ログの完全性確保”と解答してしまい、削除ファイルという核心を外す。
• 手段を「イメージコピー」とだけ書き、具体的に“空きセクタの復元”を示さず減点される。

FAQ

解答の論理構成

1. 【問題文】には
   “② WPA2を使用していても、無線LANの通信が傍受されてしまうとBさんが利用しているタブレットPCのMACアドレスを攻撃者が知ることができる”
   とあり、攻撃者がMACアドレスを取得できる事実が示されています。
2. これはIEEE 802.11の仕様上、暗号化対象が “フレーム本体（データ部分）” であり、送信元・宛先MACアドレスを含む “フレームヘッダ” は暗号化されないためです。
3. 従って、無線区間を受動的に傍受するだけでヘッダを読めるので、攻撃者は簡単に “MACアドレス” を取得できます。
4. 以上より、設問に対する理由は
   “MACアドレスが平文の状態で送信されるから”
   となります。

誤りやすいポイント

• 「WPA2はすべてのフレームを暗号化する」と思い込み、ヘッダも保護されると誤解する。
• “MACアドレスを隠すにはWPA2-Enterpriseが必要” など、認証方式とヘッダ暗号化を混同する。
• 暗号化対象を “パケット” と表現してpayloadとheaderの区別をあいまいにする。

FAQ

解答の論理構成

1. 総務部のW-APでは
   “・登録済みMACアドレスをもつ端末だけを接続可能とする接続制御”
   が行われています。したがって接続可否はMACアドレスに依存します。
2. W主任は
   “②WPA2を使用していても、無線LANの通信が傍受されてしまうとBさんが利用しているタブレットPCのMACアドレスを攻撃者が知ることができる”
   と説明しており、攻撃者は正規端末のMACアドレスを取得できます。
3. 問題の下線③は“攻撃者が、自分の無線LAN端末を総務部のW-APに接続可能にする方法”です。
4. 攻撃者が自端末の無線LANインタフェースに取得した正規端末のMACアドレスを設定（偽装）すれば、W-APの接続制御を通過できます。
5. 以上を踏まえ、模範解答は
   “端末の無線LANポートのMACアドレスを、総務部のW-APに登録済みのMACアドレスに変更する。”
   となります。

誤りやすいポイント

• WPA2の暗号を破ることが必須だと勘違いし、MACアドレス偽装に気付かない。
• 802.1X認証のバイパスを狙う攻撃と混同し、利用者ID／パスワードの窃取だけを書いてしまう。
• “MACアドレスの追加登録”と回答してしまい、既存登録との差し替え（偽装）を示さない。

FAQ

解答の論理構成

1. 問題文ではECBモードについて「仮にTCP/IPパケット全体をECBモードで暗号化した場合、cが繰り返して現れることになり、暗号の解読が容易になる」と示されています。
2. ECBモードは“同一の平文ブロック → 同一の暗号ブロック”という弱点があり、平文側に繰り返しパターンが存在すると容易に推測されます。
3. そこで下線部④が問い掛ける「パケットがもつある特徴」とは、パケット内に“毎回ほぼ同じ内容の部分”が存在する点だと考えるのが自然です。
4. TCP/IP通信では、送信元・宛先アドレスやポート番号、プロトコル番号などが格納される「IPヘッダ部」および「TCPヘッダ部」があります。端末間で継続的に通信する限り、これらヘッダの多くのフィールドは変化しにくく、同一のバイト列が複数パケットで繰り返し出現します。
5. よって、同じ端末間であれば「IPヘッダ部及びTCPヘッダ部は、同一のバイト列であることが多い」という特徴こそが、下線④で求められる答えとなります。

誤りやすいポイント

• 「ペイロード（データ部）が似通っている」と思い込み、ヘッダではなくデータ側を答えてしまう。ペイロードはアプリケーション毎に変動しやすく繰り返しパターンが保証されません。
• 「CRCやチェックサムが一定」と解釈してしまう。チェックサムはパケット毎に再計算されるため一定にはなりません。
• 「TCPシーケンス番号が増分で一定」など、増分値を“同一”と誤認してしまう。増分はブロック単位で見ればバイト列が変わるため繰り返しにはなりにくいです。

FAQ

解答の論理構成

1. ECBモードの性質を確認
   • 【問題文】「仮にTCP/IPパケット全体をECBモードで暗号化した場合、cが繰り返して現れる」とある。
   • ECBモードは“同じ平文ブロック → 同じ暗号ブロック”になるため、繰り返し現れるものは「同一の暗号ブロック」である。
   • よって c＝「同一の暗号ブロック」。
2. CTRモードの構造を確認
   • 【問題文】「CTRモードでは、暗号ブロックは、dとeの排他的論理和である。」とある。
   • 図3より、CTRモードは
     $e_i=m_i\oplus {\text{Enc}}_k(c+i-1)$
     で表される。ここで
     ・$m_i$ … 平文ブロック
     ・${\text{Enc}}_k(c+i-1)$ … カウンタ値を暗号化した値
   • したがって
     ・d＝「平文ブロック」
     ・e＝「カウンタ値を暗号化した値」。
3. 結論
   • c：「同一の暗号ブロック」
   • d：「平文ブロック」
   • e：「カウンタ値を暗号化した値」

誤りやすいポイント

• ECBモードの説明を「同一の平文ブロック」と書き換えてしまうミス。問われているのは暗号化後の結果。
• CTRモードのeを「カウンタ値」そのものと誤解するケース。暗号化後の値である点に注意。
• dとeの順序を逆に記入してしまう混同。

FAQ

解答の論理構成

• 本文では、ブラックリスト機能の可否を説明する場面で次の文が示されています。
  “HTTP通信の場合、プロキシサーバでは内容をfことができる。”
• HTTPは暗号化されていない平文通信です。したがってプロキシサーバはパケット内のリクエストヘッダや本文をそのまま確認できます。
  例：URLのパスやクエリ、POSTデータなどを把握可能。
• 続けて本文は、HTTPSでは「社内PCとWebサーバの間でTLSセッションが成立して暗号通信路が確立した後は、プロキシサーバでは内容をfことはできない」と述べています。
  HTTPSはTLSにより暗号化されるため平文読取りが不可能になることを示唆しています。
• したがって f には“暗号化されていないデータを確認する”という意味の語が入る必要があります。プロキシが行うのはデータの「閲覧・参照」よりも直接的に“中身を読む”行為であるため、「読み取る」が最も自然です。
• 以上より解答は
  f：読み取る

誤りやすいポイント

• 「解析する」「検査する」「確認する」など広義の言葉を選ぶと、後段の “内容をfことはできない” と接続した際に不自然になる場合があります。
• HTTPとHTTPSの違いを暗号化有無ではなくポート番号（80/443）の差とだけ捉え、文脈を読み落とすと適切な動詞を選べません。
• プロキシサーバがパケットを中継する位置情報に気を取られ、“取得する”や“保存する”とする誤答も発生しがちです。

FAQ

解答の論理構成

1. 問題文では
   “社内PCからプロキシサーバにCONNECTメソッドによって接続要求を送る時点では平文でWebサーバのg名とポート番号が渡される”
   と記載されています。
   HTTP CONNECTはTLSを張る前にCONNECT www.example.com:443 HTTP/1.1のように送信し、プロキシに対し接続先ホスト名とポート番号だけを明示します。したがって g には “ホスト” が入ることになります。
   ─ 選択肢「カ：ホスト」が合致します。
2. 続けて
   “実質的にブラックリストに登録できるのが、URLのg部とポート番号部だけであり、h部は指定できない”
   とあります。URL構文では
   https://ホスト:ポート/パス
   となるため、ホストとポート以外の部分は “パス” です。TLSセッション確立後は /download/evil.exeなどのパス情報が暗号化されるため、プロキシは参照できません。従って h には “パス” が入ります。
   ─ 選択肢「オ：パス」が該当します。
3. 以上より
   g：カ（ホスト）
   h：オ（パス）

誤りやすいポイント

• 「ドメイン名」「URL」などの語をそのまま当てはめてしまう。CONNECTで送られるのはドメイン名ではなくホスト名（FQDN）。
• パスを「リソース」「ファイル名」と早合点する。問題文ではURL構成要素の正式名称「パス」を求めている。
• HTTPSでもプロキシが“すべて”見ることができると誤解する。実際はCONNECT要求時点のヘッダだけで、本通信は暗号化される。

FAQ

解答の論理構成

• 下線⑤には「マルウェアが窃取した情報を社内PCから社外に送信する経路がFW1を経由したHTTPS以外にもあり」とある。
  すなわち、FW1のHTTPS‐復号とL7FW機能をすり抜ける “別ルート” を特定する必要があります。
• ルート①：無線LANからの直接脱出
  • 本文には「不審なW-APが、N社敷地外にあることを発見」とあり、攻撃者が自前のアクセスポイントを設置している事実が確認できます。
  • 感染PCがこのW-APへ接続すれば、通信はFW1／FW2を通らずインターネットへ到達できるため、情報送信経路になります。
  • したがって「攻撃者が用意したW-APに接続し、情報を送信する。」が成立します。
• ルート②：社内メール経由
  • 表1には「項番6内部メールサーバ → 外部メールサーバSMTP許可」と明示され、FW1上でSMTPが恒常的に許可されています。
  • マルウェアが内部メールサーバを踏み台にし、自動的に “窃取情報を添付したメール” を外部メールサーバへ送信すれば、HTTPS復号の対象外であり検知困難です。
  • これが「内部メールサーバを利用して攻撃者にメールを送信する。」という経路です。
• 以上より、要求された「二つの具体例」はモデル解答のとおり正当であると論証できます。

誤りやすいポイント

• FW1／FW2のどちらを通過するかを混同し、社内PC→プロキシ→FW1以外の経路を見落とす。
• SMTPは“平文メール”と決めつけ、暗号化（SMTPS）なら検知できると誤解する。実際にはFW1のHTTPS復号はSMTPには無関係。
• DMZからの送信（外部メールサーバやプロキシサーバ）を「社内PCが直接使えない」と思い込み、攻撃者が内部メールサーバを経由できる事実を見逃す。

FAQ

解答の論理構成

1. 問題文（図5の説明）には
   “FW1が発行した自己署名証明書を i として全ての社内PCに登録する。”
   とあります。ここでFW1は社内PCと外部Webサーバとの間に入り込み、TLSセッションを中継・復号するため、自らが発行する証明書を“信頼できるもの”としてPC側に認識させる必要があります。
2. 信頼できる証明書として登録する場合、一般には「ルートCA（Certification Authority）証明書」をOSやブラウザの“信頼済みストア”に格納します。問題文の別箇所にも、 “FW1には、FW1の製造元によって安全性が確認されたCAのディジタル証明書だけが、信頼されたルートCAのディジタル証明書としてインストールされている。”
   とあり、信頼の対象が“CAのディジタル証明書”であることが示されています。
3. よって、i には「信頼するCAのディジタル証明書」と入れることで、FW1が自己署名した証明書をCA証明書として登録し、以降FW1が動的に発行するサーバ証明書を社内PCが検証可能になる仕組みを正確に表せます。

誤りやすいポイント

• “自己署名証明書”という語だけを拾い、「自己署名サーバ証明書」と答えてしまう。登録すべきは“CA証明書”であり、サーバ証明書ではありません。
• “ルート証明書”とだけ書いてしまい「何のルートか」が曖昧になる。CAを明示しないと意図が伝わりにくく減点されがちです。
• ブラウザ側にインポートする対象を“公開鍵”と誤認するケース。TLSでは公開鍵そのものではなく“ディジタル証明書”を信頼ストアに登録します。

FAQ

解答の論理構成

1. 表5の項番1には、制約の原因として【問題文】「図4の流れの中で、FW1は、社内PCがもっているクライアント証明書に対応した秘密鍵を利用することができない。」とあります。
2. 秘密鍵が使えないということは、TLSハンドシェイクで社内PCがクライアント証明書を提示しなければならないタイプの通信（いわゆる相互認証）が対象であると分かります。
3. FW1は中継型でTLSを二重終端しますが、社内PCの秘密鍵は保持していません。そのため相互認証が要求される外部Webサーバに対しては復号処理を適用できず、例外扱いにする必要があると読み取れます。
4. よってjに入る通信の種類は「クライアント証明書の提示が必要な外部Webサーバにアクセスする」となります。

誤りやすいポイント

• 「サーバ証明書に不備がある場合」と混同し、サーバ証明書関連の項目をjと勘違いする。
• 制約の原因だけを見て「秘密鍵が使えない＝復号不可」と理解できず、単に「HTTPS通信」と答えてしまう。
• 相互認証＝VPNと誤解し、Webアクセスでのクライアント証明書利用を想起できない。

FAQ

解答の論理構成

1. 表5の項番3には、 “FW1には、FW1の製造元によって安全性が確認されたCAのディジタル証明書だけが、信頼されたルートCAのディジタル証明書としてインストールされている。”
   とあります。
2. つまり、FW1が信頼していないCAで署名されたサーバ証明書を提示する外部Webサーバへ接続すると、FW1はその証明書を検証できず復号処理を中断します。
3. したがってkには、 “FW1の製造元によって安全性が確認されていないCAが発行したサーバ証明書を使用した外部Webサーバにアクセスする。”
   が入ります。

誤りやすいポイント

• “自己署名証明書を使う場合”と混同しやすいですが、設問は“信頼されていないCAが発行した証明書”を指しています。
• “クライアント証明書”の有無を理由にしてしまうミス。項番3の原因はCA信頼性であり、クライアント証明書は無関係です。
• “FW1が証明書を生成するケース”と誤解しやすいですが、制約の対象は外部Webサーバ側の証明書です。

FAQ