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

解答の論理構成

• 【問題文】では、LBのサービス稼働チェック結果が“down”になった時刻が表2に示されています。ここで「10:05:00」や「15:05:00」など複数回downが発生しており、まず“ある程度”時間帯を特定できます。
• しかし「特定のデータを受信するとWebサーバのCPUリソースが一時的に枯渇する」という脆弱性が説明されているため、攻撃が成功した瞬間はCPU使用率が異常上昇しているはずです。
• 図3「Webサーバ群のリソースグラフ」にはCPU使用率の折れ線が描かれ、時刻「11」「15」「19」付近で100％ ピークが確認できます。
• したがって、表2でdownが発生した前後と図3でCPUが100％ になった時刻を突き合わせれば、“ログ調査すべき分”をさらに絞り込めます。
• 以上より、G主任が図3に着目したのは「CPU使用率の急上昇という客観的指標により、平常時と異なる事象が起こった正確な時間を把握しやすい」ためです。

誤りやすいポイント

• 「イベント通知自体が攻撃の証拠」と短絡的に判断し、CPUグラフを無視する。
• 図3をメモリ使用量やネットワーク帯域のグラフと勘違いし、理由を誤って記述する。
• CPU使用率とdown時刻の相関を示さず、単に「図3で詳細が分かる」と曖昧に書いてしまう。

FAQ

解答の論理構成

1. 攻撃の特徴を把握
   本文には「脆弱性は、特定のデータを受信するとWebサーバのCPUリソースが一時的に枯渇する」とあります。
   さらにIDSの標準シグネチャは “HTTP POSTリクエストが300,000バイト以上” と記載されています。
   ⇒ 大量データを伴うPOSTを送ってくる送信元が疑わしい。
2. 被害発生時刻とログを突合
   表2によるとWebサーバがdownになった時刻は「11:01:00」「15:05:00」「18:51:00」「19:23:00」などです。
   表4のFW1ログを見ると、ほぼ同じ前後で
   ・「11:00:12」「15:04:54」「18:50:20」「19:22:43」に送信元IP「△△.123.123.123」から通信があり、 送信バイト数はいずれも「6,401,200」前後の極端に大きな値です。
   ⇒ 被害と高バイト通信が一致。
3. 他IPとの比較
   同じ表4には「○○.1.1.1」「○○.1.1.2」もありますが
   ・出現は1回ずつ
   ・送信バイト数は「301,201」「305,121」と300,000前後で小さめ
   ・該当時刻（13:21:06, 16:59:23）はWebサーバのdownが発生していません。
   ⇒ 継続的に過大データを送っているのは「△△.123.123.123」だけ。
4. よって遮断すべき攻撃元 IP
   攻撃の発生時刻と攻撃パターン双方に合致する送信元は
   表4の「△△.123.123.123」であるため、a は
   【模範解答】に示すとおり
   a：△△.123.123.123
   となります。

誤りやすいポイント

• IDSやWebサーバのアクセスログでは送信元がすべて「192.168.1.254」に見える点
  （LBでNATされているため）。FW1ログを見ないと外部IPを特定できません。
• バイト数が300,000以上ならすべて悪意と決めつける誤解。
  正常処理でも300,000付近の通信があり、継続性と被害時刻の相関が重要です。
• 「ステータスコード500」が出ているからといって送信元＝攻撃元と早合点すること。
  LBからWebサーバへの内部通信でも500が返るため、あくまでFW1の外部IPを確認します。

FAQ

解答の論理構成

1. 検知ルールの確認
   本文には「IDSでは、シグネチャAの検知基準が、標準設定の“HTTP POSTリクエストが300,000バイト以上”だった。」と記載されています。
   つまり300,000バイト超のPOSTがあれば、内容の良否にかかわらずIDSはログを出力します。
2. IDSが検知した6件の時刻を照合
   表3の [ 2 ] 13:21:06と [ 4 ] 16:59:23が該当時刻です。
   これらと同じ時刻のアクセスを表5・表6で探します。
3. アクセスログの内容で正常／異常を判定
   ・表6(1) 13:21:06は ステータスコード200かつ 受信バイト数301,143
   ・表5(3) 16:59:23は ステータスコード200かつ 受信バイト数305,071
   どちらも
   ① IDSのしきい値300,000バイトをわずかに超えている
   ② HTTP応答が正常を示す200
   以上より、サイズ条件だけで “攻撃” と誤判断された正常通信であると分かります。
4. 攻撃と思われるログとの比較
   表5(1)(2)(4)、表6(2) は 受信バイト数6,401,*** かつ ステータスコード500。
   CPU枯渇を引き起こす異常終了（500）なので誤検知ではありません。
5. 結論
   誤検知を裏付けるログは
   「表5(3)、表6(1)」 となります。

誤りやすいポイント

• 受信バイト数だけを見てしまい、200と500の応答コードを見落とす。
• IDS検知時刻とWebサーバ時刻の突合せを怠り、行番号を取り違える。
• 「6,401,*** バイト」の大量通信を“サイズ大だから全部誤検知”と早合点する。
• シグネチャしきい値を「300KB未満」と読み誤り、選択を逆にする。

FAQ

解答の論理構成

1. IDSのシグネチャAは “HTTP POSTリクエストが300,000バイト以上” を条件にしており、これに該当するとアラートが出ます（設問文②）。
2. 実際の攻撃とみなせる通信は、 ・表5 [1] “6,401,124” バイト
   ・表5 [2] “6,401,011” バイト
   ・表5 [4] “6,401,162” バイト
   ・表6 (2) “6,401,181” バイト
   など “6,401,xxx” バイト級であり、Webサーバのステータスコードが “500” です。
3. ところがIDSが検知した中には、表3 [4] “16:59:23” に対応する表5 [3] のアクセスがあり、これは受信バイト数 “305,071” と閾値ぎりぎりである一方、ステータスコードは “200” と正常応答です。
4. ステータスコード “200” は処理成功、“500” は内部エラーであるため、同じシグネチャAで検知されても “200” 応答の通信は攻撃とは断定できず、誤検知と判断できます。
5. よって、解答は「該当通信は、Webサーバのステータスコードが200であるから」となります。

誤りやすいポイント

• 受信バイト数 “305,071” が閾値を超えているので攻撃と早合点し、応答コードを確認し忘れる。
• 表3（IDS）と表5・表6（Webサーバ）との時刻対応を取らずにログを個別に見てしまう。
• “500” を単なるエラー、“200” を成功と理解していても、シグネチャ条件だけを優先してしまう。
• FW1の送信バイト数 “305,121” とWebサーバの “305,071” を別通信と誤認する。

FAQ

解答の論理構成

1. b の導出
   • 本文では「ネットワークアドレス変換前のbを確認できるので、攻撃元の特定が容易になる」とあります。
   • 攻撃元を特定するにはNAT変換前に持っていた “誰から来たか” の情報、すなわち「送信元IPアドレス」が必要です。
   • したがって b には「送信元IPアドレス」が入ると判断できます。
2. c の導出
   • 続けて「ただし、LBへのc通言については監視できない」とあります。
   • LBは図2の説明で「SSLアクセラレータ機能」を持つ装置です。LBより外側にIDSを移すと、LBが復号する前の暗号化通信はIDSでは解読できません。
   • 暗号化通信でWebサイトが一般に使うプロトコルは “HTTPS（SSL/TLS）” です。
   • よって c には暗号化されたWeb通信を指す「https」（またはプロトコル名そのものを指す「SSL」）が入ります。
3. d の導出
   • 「IDSはLBが保有しているdを利用してc通信についても監視できるものにする」と記載されています。
   • HTTPSを復号してIDSが内容を解析するには、サーバ側の “秘密鍵” が必要です。LBがSSL終端である以上、LBはサイト証明書と対応する秘密鍵を保持しています。
   • したがって d には「秘密鍵」を入れるのが妥当です。

誤りやすいポイント

• NAT後に見えるのは「192.168.1.254」などLBのIPであり、攻撃元のIPと混同しやすい。
• 「宛先IPアドレス」と誤記するケース。攻撃元の特定に必要なのは宛先ではなく送信元。
• HTTPSかSSLかで迷いがちだが、どちらも暗号化Web通信を指し文意が満たせば正解。
• 復号に必要な鍵を「公開鍵」「暗号鍵」と書いてしまう。実際に機密情報を保持するのは「秘密鍵」。

FAQ

解答の論理構成

1. 事象の整理
   【問題文】には、LBのイベント通知が発生した原因として
   「Webサーバプログラムで制限している最大同時セッション数が不足してイベント通知が発生した」
   と明記されています。
2. サービス稼働チェックとの関係
   監視対象IPアドレスがdown → upを1分周期で繰り返す（表2）ことから、Webサーバ自体が停止したわけではなく、一時的に応答不能になったと読み取れます。
3. 不要なイベント通知が生じる理由
   最大同時セッション数の上限に達すると、新規接続を受け付けず稼働チェックに失敗し、LBは “down” と判定します。その直後、既存セッションが捌ければ “up” に戻るため、実質的な障害ではないのにイベント通知が発生します。
4. Webサーバ設定変更による改善
   ③では「Webサーバの設定を変更の上、イベント通知すべき条件を変更」とあるため、上限値（最大同時セッション数）を増やす、または動的に調整する設定変更が想定されます。
5. 以上より、不要なイベント通知の原因をまとめると
   「Webサーバプログラムで制限している最大同時セッション数の不足」となります。

誤りやすいポイント

• 「CPUリソース枯渇」や「脆弱性攻撃」を原因と誤解する
  → これらは別タイミングのインシデントであり、③の文脈は平常時のイベント通知に焦点があります。
• 「LB側の閾値設定」を原因と書く
  → 表2・本文は明確にWebサーバ側の同時セッション上限を指摘しています。
• 「サービス稼働チェックの間隔不足」と記述する
  → 監視間隔は問題ではなく、応答不能を引き起こすリソース制限が根源です。

FAQ

解答の論理構成

1. 【問題文】には、下線部④として
   「攻撃を特定しやすくするために、FW1とWebサーバ群のログを関連付けられるようにログの出力内容と分析手順を見直す。」
   とある。
2. FW1はインターネット側の通信を受け、送信元IPをそのままログに記録する。一方、Webサーバ群はLB経由でアクセスを受けるため、Webサーバのアクセスログの送信元IPは表5･表6の「192.168.1.254」（LB側アドレス）になっている。
3. よって、FW1のログに記録されたグローバルIPと、Webサーバ側に記録された「192.168.1.254」とを突き合わせても攻撃元を特定できない。相関には、ロードバランサが受け取った“元々のクライアントIP”をWebサーバに伝達し、Webサーバがそれをログに残す仕組みが必要である。
4. その一般的な方法がHTTPヘッダ「X-Forwarded-For」の利用である。
   a) LBが受信時に「X-Forwarded-For: <クライアントIP>」を付加する。
   b) Webサーバ側でアクセスログにそのヘッダ値を出力する。
5. 以上より、設定変更が必要な機器は
   ・「LB」……ヘッダを追加する設定
   ・「Webサーバ群」……ヘッダをログに記録する設定
   となり、解答群では「ウ」と「オ」となる。

誤りやすいポイント

• 「FW1で何か設定すればよい」と誤認しやすいですが、FW1は既に正しい送信元IPを記録しており設定変更の対象外です。
• IDSへ流すSPAN設定と混同して「エ」を選ぶケースが見受けられますが、設問は“FW1とWebサーバ群のログの関連付け”に限定しています。
• 「X-Forwarded-For」をWebサーバ側だけで有効化しても、LBがヘッダを付けなければ値は空欄のままになり、相関できません。

FAQ