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

解答の論理構成

• 境界装置である「FW」は、送信元ネットワークアドレス変換後の全アウトバウンド通信を把握できます。
  引用：
  「FWはステートフルパケットインスペクション型であり、NAPT機能を使用している。」
• さらに「許可した通信、拒否した通信ともにログを取得するように設定」され、そのログは「全てログ管理サーバに送信」されています。
  → 社外C&C宛通信の有無はFWログを検索すれば一元的に確認可能です。
• したがって、下線①「このIPアドレスから当該C&Cサーバへの通信が発生していたことも確認できた」を具体化すると、 FWのログで該当する送信元IP／宛先IP・ポートの記録を照合した、という手順になります。

誤りやすいポイント

• プロキシサーバのアクセスログだけを調べてしまう
  （マルウェアが「プロキシサーバを利用せずにC&Cサーバへの接続を試みる」ため、漏れが生じる）。
• 内部サーバやPCのパケットキャプチャを取ろうとする
  → 当時点では過去通信の証跡が残っていない可能性が高く非効率。
• NAT越しのグローバルアドレスとプライベートアドレスの対応を考慮し忘れ、送信元を特定できない。

FAQ

解答の論理構成

1. 送信元IPアドレスはインターネット側で観測されたグローバルIPです。
   【問題文】には「FWはステートフルパケットインスペクション型であり、NAPT機能を使用している」とあります。
   NAPT（PAT）では、社内の端末が外部へ出る際にFW自身のグローバルIPに変換されます。したがって当該IPはFWのものとなり、a には「FW」が入ります。
2. FWのログをたどると、HTTP通信を仲介した内部機器が判明します。
   【問題文】には「Webブラウザでのインターネットアクセスは、プロキシサーバを使用するよう設定されている」およびFWルール表で「項番4　プロキシサーバ → インターネット　HTTP, HTTPS　許可」と記載されています。
   つまり社内PCがHTTPで外部と通信する際は必ずプロキシサーバ経由になります。FWログに残る “宛先インターネット / 送信元内部” のHTTPはプロキシサーバしか該当しないため、b は「プロキシサーバ」です。
3. プロキシサーバのログから内部PCのプライベートIPがわかりますが、それだけでは機器を特定できません。
   【問題文】のIT資産管理サーバに「MACアドレス」を保管している旨と、DHCPの説明により、DHCPログに記録されたIP ⇔ MAC対応を参照すれば機器を一意に識別できます。
   よってDHCPログで突き合わせる情報、すなわち c は「MACアドレス」となります。

誤りやすいポイント

• FWがNATを行っている点を読み落とし、a を「L3SW」や特定サーバと誤答する。
• HTTP通信の経路を考慮せず、b を「L3SW」や「DHCPサーバ」としてしまう。プロキシを通らない通信はFWで直接遮断されることを確認する必要があります。
• DHCPログに残る情報をIPと同列に考え、c に「ホスト名」や「管理番号」を書くミス。DHCPが払い出すのはIP ⇔ MACの対応です。

FAQ

解答の論理構成

1. 図4には「マルウェア内にC&CサーバのFQDNが記述され、C&Cサーバへの接続に使用されていた。」とある。すなわち接続先はIPアドレスではなくFQDNで指定される。
2. 同じく図4の下線②で示される「プロキシサーバを利用せずにC&Cサーバへの接続を試みる」は、PCから外部FQDNへ直接HTTP通信を出そうとする動作である。
3. しかしL社PCのDNSサーバ設定は内部DNSサーバであり、FWの表2には内部DNSサーバやPCからインターネット側へ向かうDNS通信を許可するルールが存在しない。したがって外部FQDNの名前解決は失敗する。
4. DNS解決に失敗するとTCPセッション確立に必要なSYNパケットすら生成されないため、FWまでHTTP／HTTPSの通信は到達しない。
5. よって「DNSによる名前解決ができず、TCP/IP接続要求が出ないから」という解答になる。

誤りやすいポイント

• 「HTTP通信が失敗＝FWで拒否ログが残る」と短絡するミス。実際はDNSフェーズで止まるためFWには全くログが残らない。
• プロキシを使わない＝直接IPアドレスで接続すると誤解するケース。問題文はFQDN利用を明記している。
• 「内部DNSが外部問い合わせをフォワードしているかも」と想定する誤読。表2に該当許可が無いことを見落としやすい。

FAQ

解答の論理構成

1. 既に実施した対策では「FWによる、当該C&Cサーバへの通信の遮断」を行ったが、 「IPアドレスを基にしたFWによる通信の遮断では、C&Cサーバへの通信を完全には遮断できない可能性」が示唆された。
   これはC&C側がIPを変更すれば再接続できてしまうためです。
2. セキュリティ専門会社の報告（図4）で、マルウェアは
   「マルウェア内にC&CサーバのFQDNが記述され、C&Cサーバへの接続に使用」し、 さらに接続手順として
   「Webブラウザのプロキシ設定を基に、プロキシサーバを利用して接続を試みる」
   と明記されています。つまり最終的にプロキシ経由で通信しようとします。
3. プロキシサーバは表1で
   「ブラックリスト型のURLフィルタリング機能をもつ」
   と説明されています。FQDNベースでアクセス制御できる機能が既にあるわけです。
4. そこで、マルウェアが用いる「五つの異なるFQDN」をブラックリストに登録すれば、 IP変更・多重化に影響されずに通信を遮断できます。
   この具体策を40字以内でまとめたものが
   「プロキシサーバでC&Cサーバへの通信のURLをブラックリストに設定する。」
   となります。

誤りやすいポイント

• FWのルール追加で十分と考え、FQDN変動やプロキシ経由通信を見落とす。
• プロキシの「URLフィルタリング」をホワイトリスト型と誤認し、設定方法を逆に書いてしまう。
• マルウェアがまず「プロキシサーバを利用せずに」接続を試みる点ばかりに注目し、既にFWで遮断できている事実を忘れて冗長な回答を書く。

FAQ

解答の導き方

1. 初期対応で、C&Cサーバに送信された情報に「L社のファイル配信サーバのホスト名、IT部のVさんに付与された当該サーバの利用者ID及びパスワード」が含まれていたことが判明しています。つまり攻撃者は、Vさんとしてファイル配信サーバにログインできる状態だったことになります。
2. 表1のファイル配信サーバの概要に「パッチの自動配信及びパッチの強制適用に利用されている。」とあります。つまりこのサーバを用いれば、多数のPCやサーバへ一括でファイルを配布できる機能があることが分かります。
3. 図4では「いずれも自ら感染を広げるタイプではない」とあり、マルウェア自身がネットワーク内で自律的に拡散することはありません。しかし、盗まれた認証情報でファイル配信サーバを操作すれば、マルウェア自身が広がらなくても、配信機能を使って社内にマルウェアを広げることができます。
4. 以上から、攻撃者が入手したファイル配信サーバの利用者ID及びパスワードを悪用して、当該サーバから悪性ファイルを配信し、社内へマルウェアを広げるおそれがあります。図5の下線④「最初のマルウェア感染後にファイル配信サーバから配信されたファイルの調査」は、こうした配信が行われていないかを確かめるための調査だと解釈できます。
5. したがって想定した攻撃は「ファイル配信サーバからマルウェアを拡散する攻撃」です。

誤りやすいポイント

• 「いずれも自ら感染を広げるタイプではない」を見落として、マルウェア自身が社内で自己拡散する攻撃と答えてしまう。自己拡散しないからこそ、配信の仕組みを悪用した拡散を疑う必要があります。
• 図3に、VさんがサーバにアクセスするためのID及びパスワードを当該PCに保管していなかったとあることから、認証情報は漏れていないと考えてしまう。実際には、ファイル配信サーバの利用者ID及びパスワードはC&Cサーバに送信されていました。
• ファイル配信サーバはパッチを配るだけのサーバだと考え、攻撃に使われる可能性を見落とす。パッチの自動配信・強制適用の仕組みは、悪用されれば社内全体へファイルを配布する経路になります。

FAQ

解答の導き方

1. 追加調査3では、最初のマルウェア感染後にVさんの利用者IDで当該PCからアクセスされたサーバとして、ファイル配信サーバ以外に「NTPサーバ、DHCPサーバ兼内部DNSサーバ及びプロキシサーバの3台が確認できた」とあります。つまり、この3台の利用者ID及びパスワードは、マルウェアに感染した当該PCで入力されていたことになります。
2. 初期対応で、C&Cサーバに送信された情報に「ファイル配信サーバのホスト名、IT部のVさんに付与された当該サーバの利用者ID及びパスワードが含まれていた」と判明しており、図4では当該PCに「キーロガー」が残っていたとあります。当該PCで入力された認証情報は、実際に窃取されて外部に流出していたわけです。同じPCから入力された3台のサーバのパスワードも、窃取された可能性を否定できません。
3. 3台の操作ログを確認した結果では「不正な操作が行われた形跡はなかった」とありますが、形跡がないことは、認証情報が窃取されていないことを意味しません。既に窃取された認証情報は、今後いつでも悪用され得ます。
4. これら3台はサービス停止ができないため、サーバを停止して対処することはできません。サービスを止めずに直ちに効果を出す対策として、Vさんの利用者IDを無効化し、そのIDによる認証を防ぐことが有効です。初期対応でファイル配信サーバに対して実施した「ファイル配信サーバ上での当該利用者IDの無効化」と同じ措置です。

誤りやすいポイント

• ログに「不正な操作が行われた形跡はなかった」ことだけで安全と判断する。認証情報が窃取されていれば、今後悪用される可能性がある点を見落としやすいです。
• 重要サーバを停止して再構築することを考えてしまう。3台はサービス停止ができないと明記されているので、サーバを動かしたまま実行できる対策を答えます。
• パスワードの変更だけを答えてしまう。本問は、初期対応と同様に、窃取されたおそれのある利用者IDそのものを使えなくする対策を問うています。

FAQ

解答の論理構成

1. 問題文は、ログが二重に保存されている仕組みを示しています。
   ――「各サーバは、アクセスログ、操作ログ、ミドルウェアのログ及びアプリケーションプログラムのログをログ管理サーバに送信するとともに、各サーバ上でも直近3か月分のログを保存している。」
   この一文から、①サーバ自身のローカルログと②「ログ管理サーバ」に集約された同一内容のログが存在すると分かります。
2. 「ログ管理サーバ」は改ざんを受けにくい環境です。
   ――「syslog受信に必要なポート以外は全て閉じ、リモートからアクセスできないようにしている。」
   すなわち、ローカルログより信頼度が高く、改ざん検知の“対照データ”として適切です。
3. M部長の問いは「⑥これら3台のサーバ上のログに対する改ざんの痕跡が残っていないことを確認」でした。
   ログ改ざんの有無を調べる最も確実な方法は、信頼できるコピーと突き合わせて整合性を検証することです。ここで使えるコピーが②に当たるログ管理サーバ上のログです。
4. したがって、回答は「ログ管理サーバに保存されているログとの比較」となります。
   ローカルログと中央集約ログを照合し差異を抽出することで、改ざんの挿入・削除・変更を検知できます。

誤りやすいポイント

• ハッシュ値や電子署名の話題に飛びつき、問題文に存在しない前提で回答してしまう。
• 「syslogサーバの設定確認」だけを答え、比較という具体的な確認手順を落とす。
• ログ管理サーバ側も改ざんされる可能性を考え過ぎて、設問の想定外の複雑な対策を記述してしまう。

FAQ