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

解答の論理構成

1. 問題文の状況整理
   • 「DBサーバから製造管理サーバに対してFTP接続が行われ」
   • FWログ「1-233　送信元アドレス：192.168.0.2　宛先ポート：21/TCP　動作：許可」
   • FWログ「1-234　送信元アドレス：192.168.0.2　宛先ポート：60453/TCP　動作：許可」
     最初に制御用ポート21/TCPへ接続し、その直後に同じ送信元（192.168.0.2）から高位ポート60453/TCPへ接続している。
2. FTP転送モードの特徴
   • アクティブモード：クライアント→サーバへ21/TCPで制御接続を張った後、【サーバ】が20/TCPからクライアント高位ポートへデータ接続を張る。
   • パッシブモード：制御接続後、【サーバ】が待ち受けポート番号を通知し、【クライアント】がその高位ポートに接続を張る。
     したがって、通信方向は常にクライアント→サーバとなる。
3. ログと照合
   • 「1-234」はクライアント側である192.168.0.2（DBサーバ）がサーバ側192.168.1.145（製造管理サーバ）の高位ポート60453/TCPに接続。
   • これはパッシブモードの典型的なフローであり、アクティブモードで見られる20/TCPからの逆方向通信は記録されていない。
4. 結論
   以上より、aに入る語はFTPの「パッシブ」モードとなる。

誤りやすいポイント

• “高位ポートを使っていればアクティブ”と早合点する。アクティブはサーバ→クライアント方向の接続が必ず存在する点で見分ける。
• 20/TCP以外でもデータ転送が行われると勘違いし、アクティブ・パッシブの区別をポート番号だけで判断してしまう。
• ログに表示される「送信元／宛先アドレス」の向きを見落とし、通信方向を取り違える。

FAQ

解答の論理構成

1. 【問題文】には
   “SNMPv2cでpublicというb名を使って、機器のバージョン情報を取得し”
   と記載されています。
2. “SNMPv2c” は SNMP の旧バージョンであり、認証・アクセス制御に “コミュニティ名（community string）” を用います。
3. 代表的な既定値が “public／private” で、とりわけ “public” は読み取り専用アクセスに利用されるため、多くの機器でそのまま残りやすく攻撃者に悪用されがちです。
4. したがって “b” に入る語は SNMP のアクセス制御用キーワードである “コミュニティ” が適切です。

誤りやすいポイント

• “public” という語から “公開鍵” や “パスワード” を連想してしまい、設問趣旨を取り違える。
• SNMPv3 の認証・暗号機能と混同し、コミュニティ名が廃止されたと誤解する。
• “グループ名”“ドメイン名” と答えてしまい、SNMP 固有の用語に結び付けられない。

FAQ

解答の論理構成

1. srv の起動オプション確認
   表2「2-3」のコマンドラインは
   「./srv -c --mode bind 0.0.0.0:8080」で、モードが“bind”であることが明示されています。
   よって c には「バインド」を入れるのが自然です。
2. ①が“失敗”と判断できる根拠
   ・FW 受信側で 8080/TCP が拒否
   表1「1-3」は「送信元アドレス a0.b0.c0.d0」「宛先ポート 8080/TCP」「動作 拒否」であり、C&C 側からの接続要求が FW で遮断されたことを示します。
   ・srv が待受状態だったポートを確認
   表3「3-3」は「ローカルアドレス 0.0.0.0:8080」「状態 LISTEN」「PID 1275」、その親は表2「2-3」です。
   したがって「2-3 によって起動した 3-3 のポートへの通信が 1-3 で拒否されている」ため、①は接続失敗と判断できます。
3. ②が“成功”と判断できる根拠（参考）
   表2「2-4」は「./srv -c --mode connect a0.b0.c0.d0:443」。
   表3「3-4」は「192.168.0.1:54543 → a0.b0.c0.d0:443」「状態 ESTABLISHED」。
   表1「1-4」も同ポートで「動作 許可」。
   これらから connect モードでの再接続が成功したと分かります。

誤りやすいポイント

• 「2-3」に付く -c オプションを “connect” と早合点し、モードを誤る。実際には --mode bind が決定打です。
• FW ログ「1-3」の“拒否”を「送信元からの誤ポートスキャン」と勘違いし、C&C との通信失敗である点を見落とす。
• 「bind＝待受、connect＝能動接続」の対比を忘れ、①②を逆に解釈してしまう。

FAQ

解答の論理構成

• 表2の 2-3 に「./srv -c --mode bind 0.0.0.0:8080」とあり、srv は最初にバインドモードで待受けた。
• しかし表3の 3-3 は LISTEN 状態のみで、表1に 8080/TCP の許可ログが無い（1-3 が 8080/TCP 拒否）。このため C&C サーバとの接続は失敗したと判断できる。
• 次に表2の 2-4 に「./srv -c --mode connect a0.b0.c0.d0:443」とあり、srv はコネクトモードで外部へ接続を試行。
• 表3の 3-4 は 192.168.0.1:54543 → a0.b0.c0.d0:443 が ESTABLISHED、かつ表1の 1-4 で同一通信が FW により許可されている。したがって C&C サーバとの接続に成功したと分かる。
• 以上から d は「コネクト」。また下線②の判断根拠は「2-4 によって開始された 3-4 の通信が 1-4 で許可されているから」と整理できる。

誤りやすいポイント

• srv の起動オプションの読み違え
  • bind と connect の両方に -c が付いているため、‐c をモード指定と誤解しやすい。実際は --mode の後ろが決定的。
• FW ログと netstat の対応付け不足
  • 表3の ESTABLISHED だけを見て接続成功と判断し、FW ログで許可されたかを確認し忘れる。
• ポート番号方向の混同
  • 送信元 54543/TCP がダイナミックポートであることを見落とし、誤って 443/TCP との内部待受けと解釈する。

FAQ

解答の論理構成

1. 攻撃ツールの仕様確認
   • 問題文では「・C&C（Command and Control）サーバから指示を受け、子プロセスを起動してポートスキャンなど行う。」と記載されています。
   • したがって“ポートスキャンを行う子プロセス”を探します。
2. C&C 接続に成功した親プロセスの特定
   • 表2(2-4)には「./srv -c --mode connect a0.b0.c0.d0:443」が PID「1293」で実行中です。
   • これは C&C サーバへ“接続する”コネクトモードなので、親プロセスと判断できます。
3. 子プロセスの探索
   • 同じ表2に PID「1365」で「./srv -s --range 192.168.0.1-192.168.255.254」が稼働しています。
   • コマンドラインオプション「-s」は “scan” を示し、範囲「192.168.0.1-192.168.255.254」から DMZ→工場LAN に対してポートスキャンを実施していると読み取れます。
   • さらに PPID が「1293」であり、上記親プロセスの子プロセスになっていることも確認できます。
4. 以上より「ポートスキャンを実行したプロセスのPID」は表2 の「1365」であると結論付けられます。

誤りやすいポイント

• 「1275」の ./srv -c --mode bind 0.0.0.0:8080 は“外部からの接続待ち受け”でありスキャンではない点を見落としやすいです。
• PPID を確認せずコマンド名だけで判断すると、C&C 親(1293)とスキャン子(1365)を取り違える恐れがあります。
• netstat の「SYN_SENT」行（3-5）はスキャンの一部ですが PID を直接示さないため、ここだけを根拠にすると誤答になりがちです。

FAQ

解答の論理構成

1. 問題文は、攻撃者が「DNSリクエストを発行して、ドメイン名△△△.comのDNSサーバからTXTレコードのリソースデータを取得し、リソースデータの内容をそのままコマンドとして実行する」と説明しています。
2. DNSプロトコルにおいて
   ・Ａレコードの RDATA は「IPv4 アドレス」固定
   ・TXTレコードの RDATA は「任意の文字列を格納できる」
   という仕様差があります。
3. よって TXT レコードならシェルコマンドを含む文字列をそのまま返却でき、スクリプトが実行してしまうため攻撃が成立します。
4. 以上より解答は「TXTレコードには任意の文字列を設定できるから」となります。

誤りやすいポイント

• Ａレコードでも文字列を書けると勘違いし、DNSパケット全体に注目してしまう。
• TXTレコードの用途を SPF など制御用データ限定と捉え、「任意性」の高さを見落とす。
• “コマンドが実行される理由”ではなく“なぜ DNS がそのデータを渡せるか”という論点を外す。

FAQ

解答の論理構成

1. 受付サーバ上では既に不審プロセス「logd」が稼働している。本文では
   「Mさんが受付サーバを更に調査したところ、logdという名称の不審なプロセスが稼働していた。」
   と記載されている。
2. Mさんは解析用に「図2のURLからlogdのファイルをダウンロード」しようとしたが、U課長は下線部
   「④ダウンロードしたファイルは解析対象として適切ではない」
   と指摘した。
3. 図2のリソースデータは DNS TXT レコードにより動的に提供されるワンライナーで、攻撃者が任意のタイミングで内容を更新できる。したがってダウンロード時点で取得できるファイルは、 ・現在受付サーバで稼働し問題を引き起こしている logd
   ・侵入当初にダウンロードされた logd
   と同一とは限らない。
4. 解析対象とすべきは、侵害を受けた環境で実際に稼働している実物ファイルであり、外部サーバから改めて取得したファイルではない。そこで本文は
   「Mさんは、調査対象とするlogdのファイルをfから取得して、マルウェア対策ソフトベンダーに解析を依頼した。」
   と続く。
5. 以上より、U課長の指摘は「ダウンロードしたファイルは稼働中のファイルと内容が異なる恐れがある」という趣旨となる。

誤りやすいポイント

• 「URLが同じ＝同じファイル」と思い込み、動的ペイロードや版違いのリスクを失念しやすい。
• ハッシュ値確認を怠り、入手元の真正性・同一性を検証せずに解析対象を決定してしまう。
• DNS TXT 経由のコマンド実行に着目できず、攻撃者がファイルを随時差し替え可能である事実を見落とす。

FAQ

解答の論理構成

• 【問題文】には「Mさんは、logdのファイルについてハッシュ値を調べたが、情報が見つからなかったので、マルウェア対策ソフトベンダーに解析を依頼する必要があるとU課長に伝えた」とあります。
• その後の手順として「Webブラウザで図2のURLからlogdのファイルをダウンロードし…と考えていたが、U課長から、④ダウンロードしたファイルは解析対象として適切ではないとの指摘を受けた」と記載されています。
• ダウンロード版が不適切と指摘された理由は、攻撃者が同一 URL で別の無害ファイルや改ざんファイルを供給する可能性があり、“稼働していた実物”と同一である保証がないからです。
• したがって「調査対象とするlogdのファイル」は“すでに感染しているホスト”から取得しなければ、攻撃時点の正確なバイナリを確保できません。
• 感染が確認されたホストは「受付サーバ」であり、【問題文】は「srvという名称の不審なプロセスが稼働」「logdという名称の不審なプロセスが稼働」といずれも受付サーバ上で起きていることを示しています。
• よって f に入るサーバ名は「受付サーバ」となります。

誤りやすいポイント

• URL から再ダウンロード＝同一ファイルと早合点する
  攻撃者が差し替える恐れを見落とすと失点します。
• 「ログ管理サーバ」や「DBサーバ」と推測する混同
  logd が実際に稼働していたのは受付サーバだけです。
• “感染源＝C&Cサーバ”と誤解し、外部サイト名を書いてしまう
  問われているのは取得場所ではなく“どの自社サーバから採取するか”です。

FAQ