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

解答の論理構成

1. 開発部が運用部に伝えたタグ
   • 問題文より引用
     「運用部のHさんは、3月6日に開発部からタグ367を伝達され…」
     したがって、本来取得すべきイメージは「367」です。
2. ゲームサーバ1で実際に起動していたコンテナのタグ
   • 表2より引用
     「タグ351…3月6日 10時05分に終了」
     「タグ376…3月6日 10時14分に起動」
     10時05分時点で旧バージョン（351）が終了し、10時14分から稼働しているのは「376」です。
3. “誤って取得した”という状況
   • 問題文より引用
     「Hさんはゲームサーバ1での更新の際に誤ってタグaのゲームイメージを取得したことに気付いた。」
     10時14分に起動したタグが誤取得品と分かるため、a ＝「376」と決定できます。

誤りやすいポイント

• 「367」と「376」を読み違える
• コンテナIDとタグ番号を混同する
• 旧タグ「351」が終了しているので「351」を誤取得と勘違いする

FAQ

解答の論理構成

• 表2を見ると、タグ「376」のコンテナが「3月6日 10時14分に起動」しています。
• 図3には、「コードZは、呼び出し元プログラムの起動から3時間後に…攻撃者が用意した外部のサーバに接続して、指示された任意の命令を実行する。」と明記されています。
  ⇒ 10時14分＋3時間 ≒ 13時14分以降に攻撃者の命令が実行されたはずです。
• レジストリサーバのアクセスログでは、13時24分以降にゲームサーバ1が不審なAPI呼出し（項番4以降）を連続して行っています。
• Hさんの疑問「progという名称のファイルはタグaのゲームイメージに含まれていないのに、どうしてprogというプロセスが実行中だったのでしょうか。」に対し、K主任は下線①で「攻撃者がコードZに指示した命令が原因」と回答しました。
• 以上より、下線①は「コードZが外部サーバからprogを取り寄せて実行する」挙動で説明できます。
  よって解答は「progというファイルをダウンロードし、実行する命令」となります。

誤りやすいポイント

• 「コードZを実行する命令」と誤記する
  → コードZ自体は既にゲームイメージ内に混入済みで、攻撃者が指示したのは別のバイナリ(prog)の取得・実行。
• 「レジストリサーバへのAPI呼出し命令」と混同する
  → API呼出しはダウンロード後の prog が実施した活動と推測される。
• コマンドの目的に「削除」「改ざん」まで含めてしまう
  → 本設問は“prog 出現”の理由を問うのみ。

FAQ

解答の論理構成

• 【問題文】表1「ゲームサーバ1～4」の記述に
  「ゲームアプリはログを一時ディレクトリに出力する。 一時ディレクトリはコンテナ起動時に作成され、コンテナ終了時に消去される。」
  とある。
  ⇒ コンテナを終了するとログが物理的に削除されることが分かる。
• 会話中で K主任が
  「コンテナを終了すると、メモリ上のデータに加えてbも消失してしまいます。」
  と警告している。
  ⇒ 消失して困るデータは上記で示された “一時ディレクトリに出力されるログ”。
• したがって、b に入る語句は
  「一時ディレクトリ内のログ」
  となる。

誤りやすいポイント

• 「ゲームサーバ1～4」の説明を読み飛ばし、消えるのはプログラムファイルだと誤解する。
• “メモリダンプ”と並列に語られているため、b を “ディスクイメージ”などと勘違いする。
• 「一時ディレクトリ」を「/tmp などのホスト側領域」と誤認し、消えないと判断してしまう。

FAQ

解答の論理構成

1. 問題文には、K主任が「過去に、②対策情報が公開される前の脆弱性を悪用した攻撃がコンテナを介して行われ、コンテナエスケープと呼ばれるホストへの侵害が発生した事例があった」と述べています。
2. 「対策情報が公開される前の脆弱性を悪用した攻撃」は、パッチや回避策が公開される前に未知の脆弱性を突く行為を指します。
3. この特徴に該当する代表的な攻撃名称が「ゼロデイ攻撃」です。
4. したがって、下線②が示す攻撃の名称は「ゼロデイ攻撃」と判断できます。

誤りやすいポイント

• 「既知だが未対策の脆弱性」を意味するベンダーレスポンス待ちの攻撃と混同し、「Nデイ攻撃」などと書いてしまう。
• 「脆弱性情報公開後すぐの攻撃」と早合点し、「公開直後攻撃」「エクスプロイトコード公開攻撃」などと記述する。
• 「コンテナエスケープ＝攻撃名称」と誤認し、②に「コンテナエスケープ」と答えてしまう。

FAQ

解答の論理構成

• 【問題文】表3 項番4 は
  13:24　GET　/index.html　404 Not Found
  という汎用パスへのアクセスであり、攻撃者は“サイトトップ”に相当する URI を試しています。
• 同じく【問題文】には「レジストリサーバ…HTTPSでアクセスするREST APIを実装している。当該REST APIに認証・認可機能は設定されていないが、API呼び出しはログに記録される。」とあります。
• 汎用的な /index.html へのリクエストに対し、通常の Web サーバなら HTML を返すか 403/200 などになりますが、Docker Registry などの API 専用サーバは静的ファイルを持たず 404 を返します。また、その 404 レスポンスには Docker-Distribution-API-Version: registry/2.0 等、レジストリ特有の HTTP ヘッダが付くのが一般的です。
• 会話文の下線③「そのレスポンスの内容から…コンテナイメージが登録されているサーバだと判断」とあるため、攻撃者は 404 ステータス“だけ”ではなく、レスポンスヘッダに含まれる固有情報を根拠にしています。
• 以上より、回答は「レジストリサーバに固有のレスポンスヘッダ」となります。

誤りやすいポイント

• 404 Not Found という“ステータスコード”を答えてしまう。404 は一般 Web サーバでも返るため判定根拠になりません。
• /v2/_catalog や /v2/… といった後続 API 呼び出し URI を答える。これらは「攻撃者がレジストリと確信した後」の操作であって判定時点の情報ではありません。
• 「Docker という文字列が含まれるボディ」などと推測で記述する。問題は“レスポンスの内容”のうち“レジストリサーバに固有”と明示しており、具体的値を書く必要はありません。

FAQ

解答の論理構成

1. 事実確認
   • 表3のアクセスログでは、項番8から46まで「PUT /v2/gameapp/manifests/…」が続き、注記2に「リクエストURIの末尾の数値が1ずつ減っていく」とあります。
   • K主任は「レジストリサーバ上のタグ341から379までのゲームイメージが上書きされた可能性があります」と指摘しています。
2. 被害範囲の特定
   • 攻撃者が「上書き登録」を行ったのはタグ341〜379。
   • これらのイメージにはマルウェア（コードZやprog）が混入している恐れがあるため、残しておくと二次被害が拡大します。
3. 必要な対処の導出
   • 「被害の拡大を防止する」には、汚染されたイメージを利用不能にする必要があります。
   • レジストリサーバ内で実施できる最も直接的な操作は「削除」です。
4. 結論
   • よって④で指示すべき内容は「上書きされたイメージを削除する。」となります。

誤りやすいポイント

• 「アクセス制御を強化する」「レジストリサーバを停止する」だけでは、既に登録済みの不正イメージが残存し、内部者や自動ジョブが誤って取得するリスクが解消されません。
• 「タグを付け直す」「バックアップから復元する」など復旧系の作業は削除後に行う工程であり、④の“対処”としては優先順位が下がります。
• 上書きされたタグ範囲を誤認し、全イメージを削除するなど過剰対応をしてしまうケースも注意が必要です。

FAQ

解答の論理構成

1. まず、設問は「ゲームサーバ1は攻撃者からの攻撃の指示をIPアドレスcのサーバから受け取っていた」ことを前提に、cに入る値を問うています。
2. 【問題文】には、ゲームサーバ1の通信先を示す決定的な記述があります。
   • 「Hさんが同日の業務用FWのログを確認したところ、ゲームサーバ1はインターネット上のIPアドレスa3,b3,c3,d3及びレジストリサーバに対してだけ接続していた。」
     ここで攻撃者側と疑われる唯一の外部接続先が「a3,b3,c3,d3」です。
3. さらに後段の会話でも、Hさんが「IPアドレスcのサーバ」と表現しており、攻撃者の指令サーバ＝業務用FWログに残った外部IPという文脈が成立します。
4. 以上より、cに入るべき値は業務用FWログに記録されていた外部IPアドレスそのもの、すなわち「a3.b3.c3.d3」となります。
5. 模範解答も「c：a3.b3.c3.d3」と示しており、論理的整合が取れます。

誤りやすいポイント

• 「a3,b3,c3,d3」を“4つの別々の値”と読み違え、複数回答だと誤解するケース。実際は1つのグローバルIPアドレスをカンマ区切りで示しただけです。
• レジストリサーバへの通信を攻撃者指令だと勘違いしてしまい、内部サーバのIPを解答してしまうミス。
• 「攻撃者が送った命令」＝C2通信と結び付けられず、FWログ確認の重要性を見落とすこと。

FAQ

解答の論理構成

1. 問題文では、Hさんが攻撃指令の送信元を示して次のように述べています。
   ― 「dはマルウェア感染によって攻撃者の制御下となったコンピュータで構成されますが」
   ここで、dが「複数のマルウェア感染端末が攻撃者に遠隔操作されている集団」であることが明示されています。
2. その特徴を満たす用語は「ボットネット」です。ボット（乗っ取られた端末）がネットワーク化され、攻撃者に一斉指令を受けて不正通信や攻撃を行う集合体を指します。
3. 解答群を照合すると、 ア：ゼロトラストネットワーク … セキュリティ設計思想
   イ：ダークウェブ … 特定プロトコル上の匿名ネットワーク
   ウ：ハニーポット … 誘惑型の擬似ターゲット
   エ：ボットネット … 乗っ取られた端末群（問題文の説明と合致）
4. よって、d に入る適切な語は「エ：ボットネット」です。

誤りやすいポイント

• 「ダークウェブ」を選択する誤り
  匿名性が高いネットワークという連想で選びやすいですが、問題文の「マルウェア感染したコンピュータが集合」という説明と一致しません。
• 「ハニーポット」を選択する誤り
  攻撃者を誘い込むための擬似環境であり、「攻撃者の制御下で動く端末群」とは逆の立場です。
• ボットネット＝ＤＤｏＳ攻撃限定と思い込む誤り
  ボットネットは DDoS だけでなくスパム送信・暗号資産マイニング・情報窃取など多目的に利用されます。定義を広く捉える必要があります。

FAQ

解答の論理構成

1. Hさんは「IPアドレスcへの接続を業務用FWで拒否する」と提案しました。
2. これに対し K主任は「それだけでは、攻撃者が同種の方法で攻撃の指示をしたときに⑤対策として有効でない場合があります」と指摘しています。
3. 業務用FWで 1 つの IP アドレスだけを遮断する方法は、遮断対象が固定であることが前提です。
4. しかし、攻撃者は C2（Command & Control）サーバを容易に変更できるため、別の IP アドレスを使えば再び通信できてしまいます。
5. したがって「⑤有効でない場合」とは、攻撃者がcとは異なる IP アドレスを用いて同じ種類の攻撃指示を行う場合です。

誤りやすいポイント

• 「業務用FWで拒否する」＝完全封じ込めと早合点し、攻撃者の IP 変更という基本的な回避手段を見落とす。
• ⑤の主語を「業務用FW」や「C2 サーバ」などにしてしまい、「どのような場合か」という設問意図から外れる。
• 「別ドメイン」「別ポート」などと答え、FW が IP アドレス単位で制御している点を忘れる。

FAQ

解答の論理構成

1. 登録 API を誰が使うのかを確認
   【問題文】表1「ソースコードサーバ」には
   「その後、ゲームアプリのコンテナイメージ…を新たに生成し、レジストリサーバに登録する。」
   とあり、ゲームイメージを“登録・上書き”できるのはソースコードサーバだけです。
2. 実際のログでも裏付け
   表3 項番3 では
   「ソースコードサーバ 11:29 PUT /v2/gameapp/manifests/379 201 Created」
   と、ソースコードサーバだけが正規の PUT（登録）を行っています。
3. 制限対象を決定
   Hさんの提案
   「呼出し元IPアドレスをeのIPアドレスからだけに制限」
   は、上記 1・2 に合致するソースコードサーバの IP アドレスを指すはずです。
4. 解答
   解答群のうちソースコードサーバに該当する記号は「オ」であるため
   e：オ となります。

誤りやすいポイント

• PUT をゲームサーバでも行うと誤解し「エ」を選ぶ。ゲームサーバは取得(GET)のみです。
• レジストリ自体を指定すると思い込み「キ」を選ぶ。レジストリは“受信側”であり呼出し元ではありません。
• FW や LB が API 制限に関係すると連想し「ウ」「ア」を選ぶ。これらは制御装置であって登録処理の発信者ではありません。

FAQ