情報処理安全確保支援士 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）サーバから指示を受け、子プロセスを起動してポートスキャンなど行う」とあります。したがって、srv本体とは別に「ポートスキャンを行う子プロセス」が稼働しているはずです。
2. FWログでポートスキャンが発生していることを確認する
   調査結果に「受付サーバから工場LANのIPアドレスに対してポートスキャンが行われた」とあるため、受付サーバ上にポートスキャン実行プロセスが存在すると考えます。
3. 表2（ps出力）でsrvのプロセス群を確認する
   表2の該当行は次の通りです（コマンドラインの要旨を示します）。
   • 項番2-3：PID「1275」 コマンド「./srv -c --mode bind 0.0.0.0:8080 2>&1」
   • 項番2-4：PID「1293」 コマンド「./srv -c --mode connect a0.b0.c0.d0:443 2>&1」
   • 項番2-5：PID「1365」 コマンド「./srv -s --range 192.168.0.1-192.168.255.254」
   ここで、1365のコマンドはスキャン対象範囲を示すオプション「--range」を含んでおり、ポートスキャンを行う子プロセスであることが強く示唆されます。
4. 表3（netstat出力）でソケット状態とPIDの対応を確認する
   表3の項番3-4に「ローカル192.168.0.1:54543 → 外部a0.b0.c0.d0:443状態ESTABLISHED PID 1293」とあり、これはC&Cサーバとの確立済み接続（PID 1293）です。一方、項番3-5に「外部アドレス192.168.253.124:21、状態『SYN_SENT』、PID『1365』」とあります。SYN_SENTは送信側が接続試行中である状態で、複数の宛先に向けた同時のSYN_SENTはポートスキャンの典型的な痕跡です。
5. 総合判断
   ・srvは子プロセスでポートスキャンを行う（手順1）。
   ・表2でポートスキャン用途を示すコマンドを持つプロセスはPID「1365」である（手順3）。
   ・表3でPID「1365」が多数の宛先に対して接続試行（SYN_SENT）を行っていることが確認できる（手順4）。

誤りやすいポイント

• netstatの「SYN_SENT」のみに頼らないこと。表3にはPID列がありPIDでプロセスを特定できますが、netstat単独だと一時的な接続や権限不足で見落とす場合があります。必ずpsのコマンドライン（表2）や開始時刻と照合してください。
• LISTEN／ESTABLISHED／SYN_SENTの意味を取り違えないこと。LISTENは待ち受け（bindモード）、ESTABLISHEDは確立済み（C&C接続など）、SYN_SENTは接続試行（スキャンの兆候）です。
• C&C接続プロセス（ここではPID「1293」）と実際にスキャンを行う子プロセス（PID「1365」）を混同しないこと。コマンドラインのオプションを必ず確認してください。
• FWログだけで実行プロセスを特定しないこと。FWログは通信の発着を示しますが、どのプロセスが発行したかはホスト側のps/netstatで確認する必要があります。

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