ネットワークスペシャリスト 2010年 午後1 問03

解答の論理構成

1. ア の判定
   – 会話文に「監視対象の Webサーバなどにインストールする ア 型 IDS」とあります。
   – 端末（OS）にエージェントを組み込む方式は「ホスト型 IDS」が定番です。
   – よって ア＝「ホスト」。
2. イ の判定
   – 文中に「一定のルールやパターンを使う イ 型」とあります。
   – IDS でパターンマッチング方式を指す語は「シグネチャ型」です。
   – よって イ＝「シグネチャ」。
3. ウ の判定
   – 「Webサーバへのアクセスを通じて不正な SQL が実行される ウ」と書かれています。
   – 不正 SQL 実行を狙う代表的攻撃は「SQLインジェクション」。
   – よって ウ＝「SQLインジェクション」。
4. エ の判定
   – 「Webフォームに不正なスクリプトを埋め込んで送る エ」と書かれています。
   – スクリプト注入型攻撃は「クロスサイトスクリプティング」。
   – よって エ＝「クロスサイトスクリプティング」。
5. オ の判定
   – 「通過パケットの TCP ヘッダの オ をセッションログとして保持しておき…到着順序に矛盾がないか確認する」と記述されています。
   – TCP で到着順序を確認するため FW が追跡する値は「シーケンス番号」。
   – よって オ＝「シーケンス番号」。

誤りやすいポイント

• 「ホスト型 IDS」を「エージェント型 IDS」と書き換えると原文語句の改変となり減点対象です。
• シグネチャ型とアノマリ型の対比を「パターンマッチング型／しきい値型」などと書くと設問の指定語句とズレます。
• SQLインジェクションとクロスサイトスクリプティングを逆に覚えていると、両方同時に失点します。
• ステートフルパケットインスペクションで追跡する TCP 情報を「ポート番号」や「ACK 番号」と誤記しがちです。ポートはアプリ識別、ACK は確認応答であり、順序整合性を評価するには「シーケンス番号」が必要です。

FAQ

解答の論理構成

• 【問題文】の表には、あて先ポート番号「80」に対して受信件数「8,976,340」、通過可否「可」と示されています。これは HTTP 通信を許可しているため FW を素通りしていることを意味します。
• ところが、H 君は「インターネットからのアクセスが2～3か月前から急増」と報告し、営業部員からは「Webサーバのレスポンスが以前より悪くなった」とクレームがありました。
• FW で不受理ポートをブロックしていても、「FW で通過が許可されているパケットを使った不正侵入は防御できない」（G 氏の発言）と明記されています。
• ポート「80」は正規業務（商品検索サービス）でも利用しているため遮断できず、短時間に「8,976,340」件ものリクエストが殺到している状況は、サービス不能を狙った典型的な DoS 攻撃と判断できます。
• 以上より、FW で防御できない不正アクセスの本質は「80 番ポートを悪用した大量リクエスト」による可用性の低下であり、設問の解答は「80番ポートに対するDoS攻撃」となります。

誤りやすいポイント

• ポート「1」〜「3」や「65534」「65535」へのアクセスを不正の本命と誤認し、ポートスキャンと答えてしまう。これらは通過が「否」であり FW が遮断済みです。
• DoS 攻撃の一種である「SYN Flood」「HTTP GET Flood」など具体名に置き換えてしまう。設問は原因の本質（DoS）を問うています。
• 「443」番ポート（受信件数「638」）と比較し増加幅が小さいと誤判断し、単なるアクセス増と考えてしまう。実数「8,976,340」は桁違いです。

FAQ

解答の論理構成

• 【問題文】には、G 氏の助言として「TCP ヘッダのチェックやしきい値の設定では識別できないような Webサーバへの攻撃」に対応する IDS が必要と示されています。
• 具体例として「不正な SQL が実行される ウ」および「Webフォームに不正なスクリプトを埋め込んで送る エ」が挙げられており、いずれも HTTP リクエストの本文や URL に含まれる“中身”を解析しなければ検知できません。
• つまり TCP ヘッダだけでなく、アプリケーション層の情報が格納される領域――すなわち「パケットのデータ部分（ペイロード）」に着目する必要があります。
• よって解答は「データ部分の内容」となります。

誤りやすいポイント

• TCP オプションやフラグなどヘッダ情報を答えてしまう。これらは既に「チェックで識別できない」と問題文で否定されています。
• 「HTTP ヘッダ」と限定してしまう。攻撃コードは本文にも載るため、ヘッダ限定では不十分です。
• “SQL 文”や“スクリプト”と具体例を答える。攻撃の種類ではなく、侵入検知が参照すべきパケット領域を問う設問です。

FAQ

解答の論理構成

1. まず、本文には「しきい値の設定が低すぎたときにも警告が発生する」(下線①) とあります。
2. これはアノマリ型 IDS の特性を説明しており、正常な通信量でもしきい値を超えれば警告が出ることを示しています。
3. したがって弊害は、実際には問題のない通信まで“異常”と判定される、いわゆる誤検知（False Positive）の増加です。
4. 以上より、「不正な通信だけでなく適正な通信も異常として検知されてしまう」という解答になります。

誤りやすいポイント

• 「警告が発生する」＝即座に遮断と短絡し、サービス停止を弊害と書いてしまう。
• アノマリ型 IDS とシグネチャ型 IDS の混同。「低いしきい値＝検知漏れ」と逆に解釈してしまう。
• “アラートが多発して運用負荷が上がる”とだけ書き、適正通信を誤検知する点を明示しない。

FAQ

解答の論理構成

• 【問題文】には、FW を 2 台並列に配置し「ステートフルフェールオーバの機能」を使うと記述されています。さらに「②営業部員は、FWが切り替わったことを意識せずに営業支援システムを継続利用できる」とあり、切替え時に通信経路を変えずに同じ論理アドレスで応答できる仕組みが不可欠であることが読み取れます。
• 利用端末が FW1／FW2 のどちらに到達しても同一機器に見えるようにするには、第3層（IP）と第2層（MAC）の “仮想” アドレスを 2 台で共有し、アクティブ側のみが応答します。
• したがって、FW1 から FW2 へ同期・引継ぎされる代表的な情報は
  ① 「仮想IPアドレス」 … OSI 第3層
  ② 「仮想MACアドレス」 … OSI 第2層
• どちらも 10 文字以内で表現でき、設問条件を満たします。

誤りやすいポイント

• ルーティングテーブルやセッションテーブルを書いてしまう
  → いずれも OSI 第4層以上の論点、設問は「第3層以下」を要求。
• 物理ポート番号を回答してしまう
  → 物理層情報は通常自動同期の対象外、切替え透過性には寄与しません。
• 「IP アドレス」とだけ書く
  → 仮想化していることがポイント。「仮想」を付けないと片系固有のアドレスと区別できません。

FAQ

解答の論理構成

1. 【問題文】は、切替直後でも「営業部員は、FWが切り替わったことを意識せずに営業支援システムを継続利用できる」と述べています。これは通信の “途中切断” を感じさせないことを意味します。
2. その仕組みとして、新FWが備える「ステートフルフェールオーバ」が紹介され、さらに「管理情報をFW1からFW2に一定間隔で複製」すると書かれています。
3. では“管理情報”とは何か。同じ段落の直前で、新FWが「通過パケットの TCP ヘッダの オ をセッションログとして保持」すると説明されています。
4. つまり、利用中セッションの状態（シーケンス番号やフラグなど）をリアルタイムに複製することで、FW2が途中から通信を監視・中継できます。
5. 【設問】は②を実現するのに「必要な管理情報」を問うているため、答えは “切替直前までFW1が保持していたセッションログ” となります。特にWAN側の端末は「モバイル端末」と明記されているので、対象セッションも具体的に示すことで解答の焦点が合います。

誤りやすいポイント

• “設定情報” と “セッション情報” の混同
  ルールベースの設定（ACLやNAT表）だけでは通信継続は保証できません。動的に変化するセッション状態を複製しなければ途切れます。
• “全利用者” と “モバイル端末” の区別
  シームレス切替が特に問題となるのはインターネット側と接続したモバイル端末です。社内PCはLAN内で再接続が容易なため、焦点を誤ると失点します。
• “ステートフル” という語だけを書いてしまう
  キーワードは必要ですが、何を複製しているのか（セッションログ）を明示しないと採点基準を満たしません。

FAQ

解答の論理構成

1. まず【問題文】では、ステートフルフェールオーバによって
   　「②営業部員は、FWが切り替わったことを意識せずに営業支援システムを継続利用できる」
   　と述べられ、障害発生時の自動切替では業務を止めずに済むことが示されています。
2. 一方、切替後に復旧した FW1 へ戻す際については、
   　「FWを戻すときは、手動の作業を必要とする設定とした。したがって、この切り戻し時、営業部員は営業支援システムを継続利用できないこととなる。」
   　と明記されています。
3. したがって、手動切り戻しではサービス停止が避けられず、運用上の留意点は “営業支援システムを止めてから作業する” という一点に集約されます。
4. 以上より解答は「営業支援システムの利用を一時制限して、切り戻し作業を行う。」となります。

誤りやすいポイント

• 自動切替と手動切戻しを混同し、どちらも無停止と思い込む。
• 「営業部員は継続利用できない」という記述を読み飛ばし、通知やログ取得など別の運用を答えてしまう。
• “一時制限” を “完全停止” と誤解し、利用者全員のログアウトなど過剰な手順を盛り込む。

FAQ