情報処理安全確保支援士 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