情報処理安全確保支援士 2009年 春期 午後1 問01
パケットログ解析に関する次の記述を読んで、設問1～3に答えよ。
A社は、従業員数500名の小売業者である。A社では、ネットワークの構築、運用を自社で行っている。ある朝、社内LANからインターネット上のWebページを閲覧しているときの応答が遅いといった苦情が寄せられ、システム管理部門のJ主任と運用担当のK君が調査を行うことになった。
〔原因調査と対処〕
J主任とK君は、Webページの閲覧状況の確認から始めることにした。
K君：ブラウザでインターネット上のWebページを閲覧しようとすると、図1に示す状態が長く続き、表示までに時間が掛かります。
J主任：なるほど、図1中のaを見ると、DMZ上のDNSサーバに問題があるようです。当社の社内ネットワークの構成は図2のとおりです。設置してあるパケットモニタの、該当する時間帯のログを解析してみましょう。
K君：パケットモニタYには、DNSクエリとそれに対応するDNSクエリレスポンスが多量に記録されていました。しかし、パケットモニタZには、DNSクエリを伴わないDNSクエリレスポンスが多量に記録されていました。パケットモニタZのログを図3に示します。
J主任：このようなログは、社内LAN上のPCがDNSクエリを送信するときに自身のIPアドレスをbのIPアドレスにcした場合に記録されます。
K君：不正なDNSクエリが多量にDMZ上のDNSサーバに送りつけられたことで、Webページを閲覧するときの応答が遅くなったのですね。確かに、すべての社内PCからの名前解決を、DMZ上のDNSサーバが担っていますから。
J主任：こういった通信はd攻撃と呼ばれています。至急、不正なパケットを棄却する設定をすべての部門のルータに適用してください。
K君：はい、分かりました。
J主任：こうした事象は、ウイルス感染によってよく引き起こされます。今回の事象以外にも、異常な通信が観測される可能性があります。社内LANに接続されているすべての部門のルータにパケットモニタを設置して、原因となっている社内PCを特定してください。
K君：ルータへの設定が終わり次第、パケットモニタによる調査を開始します。
J主任：ところで、図3中のeとfの記録から、DMZ上のDNSサーバが攻撃の踏み台に利用される危険性があることが分かります。①DNSサーバの不適切な設定も修正しておくべきですね。
K君：はい、分かりました。
〔異常PCの特定〕
K君は社内LANに接続されたすべての部門のルータの配下にパケットモニタを設置して、異常な通信の監視を開始した。
K君 ：図4がα部門に設置したパケットモニタのログです。
J主任 ：②図4中の(VI)に示した箇所に、通常の社内PCには見られない不審な通信挙動が記録されていますね。これはgにおけるアドレス探索に見られる特徴です。また、図4中の(VII)に示した箇所にも、不審な通信挙動が記録されていますね。(VII)に示す通信によって、③通信の異常な偏りが発生します。
K君 ：なるほど、a1.a2.a3.a4に該当する社内PCが、原因となっているPCですね。
J主任 ：こうした視点で、ほかの部門に設置したパケットモニタのログも確認してみましょう。
〔異常PCの対処と今後の対策〕
J主任とK君は、全部門のパケットモニタのログを調べた結果、IPアドレスがa1.a2.a3.a4のログだけに異常が見られたことから、このIPアドレスのPCへの対処を開始した。この対処として、通信プロセス名、実行ファイル名、通信のあて先のIPアドレスとポート番号を記録する通信プロセスモニタを、該当するPCに設定して監視を行った。
K君 ：該当するPCに設定した通信プロセスモニタのログから、起動していた④不審な通信プロセスを特定でき、それがウイルスであることが分かったので、その実行ファイルを削除しておきました。このPCではウイルス対策ソフトが起動しており、そのパターンファイルの自動更新も設定されていました。検知できないウイルスもあるのですね。
J主任 ：そのとおりです。昨今、次々と新たなウイルスが作られているので、完全な検知が難しくなっています。
K君 ：該当するPCにログインしたまま1日間操作しないで通信状況を監視したところ、DNSパケットだけでなくすべてのTCP/UDPパケットの発信が止まったことを確認しました。
J主任 ：それは変ですね。当社の設定では、操作しないPCでもPCにログインしていれば、⑤TCP/UDPパケットは自動的に発信されます。hostsファイルが改ざんされているのではないでしょうか。
K君：図5がhostsファイルです。確かに、ウイルス対策ソフトのパターンファイルの配布サイト情報が追加されているようです。
J主任：hostsファイルの改ざん以外にも、ほかの設定ファイルの改ざんや未知のウイルスへの感染の可能性があります。OSの再インストールで対処してください。
K君：：はい。分かりました
その後、J主任とK君は、ウイルスの感染経路を特定し、再発防止策を講じた。
設問1：〔原因調査と対処〕について(1)〜(4)に答えよ。
（1）本文中のaに該当する最も適切な箇所を図1中の(p)〜(r)から選び、記号で答えよ。
模範解答
a：(r)
解説
解答の論理構成
- 問題文には
“J主任：なるほど、図1中のaを見ると、DMZ上のDNSサーバに問題があるようです。”
とあります。 - “DMZ上のDNSサーバ”に問題があるかどうかをブラウザ上で判定できるのは、DNS名前解決の進行状況を示す部分です。
- 図1には (p)・(q)・(r) の3箇所がラベルされています。
- (p) は URL を入力する“アドレスバー”であり、ここは単にアクセス先を表示しているだけです。
- (q) は Web ページの“表示エリア”で、描画が終わっていない状態を示すだけで DNS か HTTP かまでは分かりません。
- (r) はブラウザ下部の“ステータスバー”で、アクセス時点の処理内容（例：名前解決中、応答待ちなど）を動的に表示します。
- DNS 処理が滞留しているかをユーザが確認できる唯一の表示部位は (r) であるため、a は (r) になります。
誤りやすいポイント
- URL 欄 (p) に “http://～” が残っているため「ここで止まっている」と早合点しやすい。
- 表示エリア (q) が空白なので「表示が遅い＝(q)」と短絡的に選んでしまう。
- ステータスバー (r) が視界の端にあるため、試験中に見落としやすい。
FAQ
Q: ステータスバーが非表示設定の場合はどう確認できますか？
A: 多くのブラウザではツールバー設定で再表示できますが、ネットワークトラブル調査時はパケットキャプチャやコマンドライン (nslookup, dig など) で直接確認する方が確実です。
A: 多くのブラウザではツールバー設定で再表示できますが、ネットワークトラブル調査時はパケットキャプチャやコマンドライン (nslookup, dig など) で直接確認する方が確実です。
Q: DNS の遅延と HTTP の遅延を画面だけで判別できますか？
A: ステータスバーに “名前を解決中” が長時間出る場合は DNS、“接続を待機中” や “応答を待機中” が長い場合は HTTP(またはTCP) の遅延と推測できます。
A: ステータスバーに “名前を解決中” が長時間出る場合は DNS、“接続を待機中” や “応答を待機中” が長い場合は HTTP(またはTCP) の遅延と推測できます。
Q: DMZ に DNS サーバを置く主な理由は何ですか？
A: 社外からも参照される可能性があるサービスを内部ネットワークと分離し、万一の侵害時に社内セグメントへの影響を抑えるためです。
A: 社外からも参照される可能性があるサービスを内部ネットワークと分離し、万一の侵害時に社内セグメントへの影響を抑えるためです。
関連キーワード: DNS, 名前解決、ステータスバー、DMZ, ブラウザ通信
設問1：〔原因調査と対処〕について(1)〜(4)に答えよ。
（2）本文中のbに入れる適切な字句を解答群の中から選び、記号で答えよ。また、本文中のcに入れる適切な字句を、5字以内で答えよ。
bに関する解答群
ア：DMZ上のDNSサーバ
イ：DMZ上のWebサーバ
ウ：インターネット上
模範解答
b：ウ
c：詐称
解説
解答の論理構成
- パケットモニタZでは「DNSクエリを伴わないDNSクエリレスポンスが多量に記録」されています。これは送信元アドレスが偽装され、レスポンスが本来の問い合わせ元ではない第三者へ返送される典型的な現象です。
- J主任は次のように説明しています。
「このようなログは、社内LAN上のPCがDNSクエリを送信するときに自身のIPアドレスをbのIPアドレスにcした場合に記録されます。」
ここで“自身のIPアドレス”を外部の被害者アドレスにすることで、レスポンスは外部へ飛び、パケットモニタZ（インターネット側）ではレスポンスだけが観測されます。 - したがって b は外部の被害者を示す「インターネット上」が妥当です。解答群から「ウ：インターネット上」を選択します。
- 「自身のIPアドレスを … にc」は、送信元アドレスを偽る行為でありネットワーク用語では“IPアドレスの詐称（スプーフィング）”と呼ばれます。
- よって
• b = ウ：「インターネット上」
• c = 「詐称」
誤りやすいポイント
- 「DMZ上のDNSサーバ」を選択してしまう
→ 攻撃側PCが“自分をDNSサーバに見せ掛ける”と誤読しやすいですが、目的はレスポンスを外部へ飛ばすことなので不適切です。 - 「Webサーバ」を選ぶ混乱
→ 図3で Web サーバ宛ての A レコードが含まれているため連想しやすいものの、送信元偽装の対象はあくまで“被害者”となる第三者の IP です。 - “偽装”と“詐称”の言葉選び
→ 試験では「詐称」が頻出表現です。誤って“偽装”や“変更”と書くと減点対象になります。
FAQ
Q: 送信元アドレスを偽るとなぜレスポンスだけが記録されるのですか？
A: DNSサーバはクエリの送信元アドレスへレスポンスを返します。偽装されたアドレスが外部の第三者であるため、レスポンスは社外に流れ出し、パケットモニタZ（外向きインターフェース）でのみ観測されるからです。
A: DNSサーバはクエリの送信元アドレスへレスポンスを返します。偽装されたアドレスが外部の第三者であるため、レスポンスは社外に流れ出し、パケットモニタZ（外向きインターフェース）でのみ観測されるからです。
Q: この挙動は具体的にどの攻撃に利用されますか？
A: DNSリフレクション／アンプ攻撃で使われます。小さな問い合わせで大きなレスポンスを大量に別のターゲットへ送り付け、帯域を枯渇させます。
A: DNSリフレクション／アンプ攻撃で使われます。小さな問い合わせで大きなレスポンスを大量に別のターゲットへ送り付け、帯域を枯渇させます。
Q: “詐称”を防ぐ根本対策は何ですか？
A: 送信元アドレス検証（Ingress／Egress フィルタリング）をルータで実装し、自ネットワークが正当なアドレス帯以外を発信しないようにすることです。
A: 送信元アドレス検証（Ingress／Egress フィルタリング）をルータで実装し、自ネットワークが正当なアドレス帯以外を発信しないようにすることです。
関連キーワード: IPスプーフィング、DNSリフレクション、Egressフィルタリング、送信元アドレス検証
設問1：〔原因調査と対処〕について(1)〜(4)に答えよ。
（3）本文中のdに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア：DNScachepoisoning
イ：DNSreflection
ウ：総当たり
エ：ファーミング
模範解答
d：イ
解説
解答の論理構成
- 【問題文】には
「パケットモニタZには、DNSクエリを伴わないDNSクエリレスポンスが多量に記録されていました。」
とあります。要求に対する応答だけが観測される典型例は、応答先アドレスが“偽装”されている場合です。 - さらに
「このようなログは、社内LAN上のPCがDNSクエリを送信するときに自身のIPアドレスをbのIPアドレスにcした場合に記録されます。」
と続き、送信元 PC が“IP アドレスを偽装（スプーフィング）”していることを示唆しています。 - スプーフィングされた DNS クエリを受け取った DNS サーバは、偽装されたアドレス（= 実際には第三者）へレスポンスを返します。攻撃者はクエリを送るだけで、DNS サーバを“踏み台”にして第三者へ大量のパケットを送り付けられ、帯域を枯渇させることができます。
- 【問題文】で J 主任が
「こういった通信はd攻撃と呼ばれています。」
と述べている攻撃手法は、DNS サーバを反射板に使い大量パケットを送り付ける“DNS reflection”攻撃に合致します。 - 解答群と照合すると、d に入る適切な語句は「イ：DNSreflection」です。
誤りやすいポイント
- 「DNScachepoisoning」を選択してしまう
‐ キャッシュポイズニングは DNS サーバ内部のキャッシュを書き換えて誤った名前解決を引き起こす攻撃であり、レスポンスだけが大量に流れる現象とは一致しません。 - 「ファーミング」を選択してしまう
‐ ファーミングは DNS 情報を改竄してユーザを偽サイトへ誘導する手口で、DoS 的な“反射”要素は持ちません。 - “総当たり”攻撃（ブルートフォース）と混同
‐ 単に大量パケットが見える＝ブルートフォースと短絡しがちですが、ここでは“レスポンスのみ観測”が決め手です。
FAQ
Q: DNS アンプ攻撃と DNS リフレクション攻撃は同じですか？
A: 一般的にはほぼ同義で使われます。大量の応答パケットで帯域を圧迫する点が共通していますが、“アンプ（増幅）”は応答サイズを拡大させるテクニックに焦点を当てた呼称です。
A: 一般的にはほぼ同義で使われます。大量の応答パケットで帯域を圧迫する点が共通していますが、“アンプ（増幅）”は応答サイズを拡大させるテクニックに焦点を当てた呼称です。
Q: ソース IP を偽装されたパケットを確実に遮断する方法は？
A: 送信元アドレスが組織内の範囲と矛盾するパケットを境界ルータで破棄する“アウトバウンドフィルタ（e.g.、BCP38）”が有効です。
A: 送信元アドレスが組織内の範囲と矛盾するパケットを境界ルータで破棄する“アウトバウンドフィルタ（e.g.、BCP38）”が有効です。
Q: DNS リフレクション攻撃を受けないために DNS サーバ側でできる対策は？
A: “オープンリゾルバ”を禁止し、外部からの不特定多数の再帰クエリを拒否する設定にします。これにより反射の踏み台になる危険を大幅に減らせます。
A: “オープンリゾルバ”を禁止し、外部からの不特定多数の再帰クエリを拒否する設定にします。これにより反射の踏み台になる危険を大幅に減らせます。
関連キーワード: DNSリフレクション、IPスプーフィング、アンプ攻撃、オープンリゾルバ
設問1：〔原因調査と対処〕について(1)〜(4)に答えよ。
（4）本文中のeに該当する適切な箇所を図3中の(I)、(Ⅱ)から、fに該当する適切な箇所を(Ⅲ)〜(V)からそれぞれ選び、記号で答えよ。また、本文中の下線①について、どのような修正を行うべきか。50字以内で述べよ。
模範解答
e：(Ⅱ)
f：(Ⅴ)
修正：インターネットからの A 社以外のドメイン上のアドレスに関する DNS クエリを拒否する。
解説
解答の論理構成
- 図3の送信元列にはすべて「p1.p2.p3.p4」が並び、脚注に「p1.p2.p3.p4：DMZ上のDNSサーバのIPアドレス」とあります。本文では「DMZ上のDNSサーバが攻撃の踏み台に利用される危険性があることが分かります」と述べ、eは“DMZ上のDNSサーバ”を指す列であることから (Ⅱ) ではなく (I) でもなく、あて先列 (Ⅱ) が攻撃の標的先である別のホスト群であるため、踏み台になっているサーバ自身を示す (I) ではなく (Ⅱ) が「危険性がある」側として適合します。【脚注：「p1.p2.p3.p4：DMZ上のDNSサーバのIPアドレス」】
- 図3詳細列 (III)〜(V) を見ると、(V) の2行は「Query response, A s1.s2.s3.s4」となっており、脚注には「s1.s2.s3.s4：インターネット上のIPアドレス」とあります。本文では「fの記録から、DMZ上のDNSサーバが攻撃の踏み台に利用される危険性がある」と述べています。A 社とは無関係な外部アドレスに対して “A” レコードを返している点が問題なので、外部ドメイン情報を返している (V) が該当します。
- 下線①「DNSサーバの不適切な設定」は、DMZ上のDNSサーバが社外から送られてくる権限外の名前解決要求にも応答していることが問題です。したがって修正内容は「インターネットから到着する、A 社のゾーン外の DNS クエリを受け付けないようにする」ことです。
誤りやすいポイント
- 送信元列 (I) をeに選んでしまう誤答が多いですが、踏み台となる「送り主」ではなく「応答相手」が危険性の対象である点に注意が必要です。
- 詳細列 (III) と (IV) はいずれも “A 社の Web サーバ” や “名前無し” を返しているだけなので、外部向け回答を示す (V) と区別できないと失点します。
- 「DNSサーバの不適切な設定」は単なるアクセス制御リスト追加ではなく、“社外からの権限外問い合わせを拒否”という DNS の権限制限を述べる必要があります。
FAQ
Q: どうして「あて先列」が踏み台利用の証拠になるのですか？
A: 攻撃者は自分が送った偽装クエリの戻り先を別ホストに設定します。DNSサーバはその通りに応答を送り、結果的に大量のトラフィックが別ホストへ流れるため、あて先列が被害側の IP を示していることが重要な証拠になります。
A: 攻撃者は自分が送った偽装クエリの戻り先を別ホストに設定します。DNSサーバはその通りに応答を送り、結果的に大量のトラフィックが別ホストへ流れるため、あて先列が被害側の IP を示していることが重要な証拠になります。
Q: “権限外のクエリ”とは具体的に何ですか？
A: DMZ 上の DNS サーバが管理しているのは A 社ドメインのみです。それ以外（例えば外部ドメイン）の名前解決要求を外部から受け取っても、本来は拒否するべきであり、それを許可してしまう設定が“権限外のクエリを許容している”状態です。
A: DMZ 上の DNS サーバが管理しているのは A 社ドメインのみです。それ以外（例えば外部ドメイン）の名前解決要求を外部から受け取っても、本来は拒否するべきであり、それを許可してしまう設定が“権限外のクエリを許容している”状態です。
Q: (III) と (IV) はなぜ問題にならないのですか？
A: (III) は「No such name」、(IV) は A 社内部の「q1.q2.q3.q4（DMZ上のWebサーバ）」に対する応答で、どちらも A 社が権限を持つ範囲内なので踏み台リスクの直接要因になりません。
A: (III) は「No such name」、(IV) は A 社内部の「q1.q2.q3.q4（DMZ上のWebサーバ）」に対する応答で、どちらも A 社が権限を持つ範囲内なので踏み台リスクの直接要因になりません。
関連キーワード: DNSリフレクション、権限外応答、アンプリフィケーション、アクセス制御、パケットモニタ
設問2：〔異常PCの特定)について、(1)、(2)に答えよ。
（1）本文中の下線②の不審な通信挙動について、30字以内で具体的に述べよ。また、本文中のgに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア：DNSamplification攻撃
イ：UDPポートスキャン
ウ：ゾーン転送
エ：迷惑メール送信
模範解答
不審な通信挙動：・名前解決のために3台以上のDNSサーバと通信している。
・A社以外のDNSサーバにMXレコードを問い合わせている。
g：エ
解説
解答の論理構成
-
不審な通信の具体像
- 図4(VI)には
「a1.a2.a3.a4｜b1.b2.b3.b4｜DNS｜Query, MX ipa.go.jp」
「a1.a2.a3.a4｜c1.c2.c3.c4｜DNS｜Query, MX jitec.ipa.go.jp」
「a1.a2.a3.a4｜d1.d2.d3.d4｜DNS｜Query, MX sec.ipa.go.jp」
といった MX レコード問い合わせが立て続けに記録されています。 - MX レコード問い合わせはメール配送先サーバを得るために行いますが、通常の社内 PC は自社 DNS（DMZ 上の DNS サーバ）だけを利用します。複数の外部 DNS サーバと直接通信するのは想定外です。
- したがって「A社以外のDNSサーバにMXレコードを問い合わせ、3台以上のDNSサーバと通信している」という点が不審な挙動となります。
- 図4(VI)には
-
g の選定
- 本文には「これはgにおけるアドレス探索に見られる特徴」とあります。
- 迷惑メール送信者は送信先ドメインの MX レコードを調べて配送可能アドレスを収集するため、多数の外部 DNS に MX 問い合わせを発生させます。
- よって解答群の「エ：迷惑メール送信」が最も適合し、g＝エ となります。
誤りやすいポイント
- UDP を使うため「UDPポートスキャン」と早合点する。MX 問い合わせは UDP 53/TCP 53 を使いますが、目的はスキャンではありません。
- DNS クエリが大量なので「DNSamplification攻撃」と連想する。増幅攻撃はリフレクタを狙うクエリであり、ここでは外部 DNS への単発問い合わせで増幅が起きていません。
- 「ゾーン転送」を想起する。ゾーン転送は AXFR／TCP 53 を使う大容量転送で、図4には MX クエリのみが記録されています。
FAQ
Q: なぜ MX レコードが標的になるのですか？
A: メールを直接配送するためには宛先ドメインの受信サーバ(IP/優先度)を知る必要があります。その情報が MX レコードに含まれるため、迷惑メール送信プログラムは真っ先に MX を問い合わせます。
A: メールを直接配送するためには宛先ドメインの受信サーバ(IP/優先度)を知る必要があります。その情報が MX レコードに含まれるため、迷惑メール送信プログラムは真っ先に MX を問い合わせます。
Q: 外部 DNS への直接問い合わせを防ぐには？
A: 社内 PC からの DNS トラフィックを DMZ 内 DNS だけに限定する ACL をルータに設定し、ポリシーベースで外部 53 番へのアクセスを遮断します。
A: 社内 PC からの DNS トラフィックを DMZ 内 DNS だけに限定する ACL をルータに設定し、ポリシーベースで外部 53 番へのアクセスを遮断します。
Q: 図4(VII) の NetBIOS 宛て TCP-SYN は何を示していますか？
A: 迷惑メールボットに多い「共有フォルダ探索」や LAN 内感染拡大のための NetBIOS ポートスキャンと考えられます。通信の偏りが発生するのは、この大量スキャンが原因です。
A: 迷惑メールボットに多い「共有フォルダ探索」や LAN 内感染拡大のための NetBIOS ポートスキャンと考えられます。通信の偏りが発生するのは、この大量スキャンが原因です。
関連キーワード: MXレコード、DNSクエリ、アドレス探索、迷惑メール、パケットモニタ
設問2：〔異常PCの特定)について、(1)、(2)に答えよ。
（2）本文中の下線③の通信の異常な偏りについて、該当するものを解答群の中から二つ選び、記号で答えよ。
解答群
ア：DNSクエリなしに通信を試みたあて先アドレス数の増加
イ：TCP-RSTパケット受信数の低下
ウ：コネクション接続成功率の低下
エ：平均パケットサイズの増加
模範解答
ア、ウ
解説
解答の論理構成
- 【問題文】では、図4の(VII)について
「図4中の(VII)に示した箇所にも、不審な通信挙動が記録されていますね。(VII)に示す通信によって、③通信の異常な偏りが発生します。」
と述べています。 - 図4(VII)の行は
「16｜…｜a1.a2.a3.a4｜e1.e2.e3.101｜Netbios｜TCP-SYN」など、 連続した IP アドレスへ TCP-SYN を送るだけで三方向ハンドシェイクが成立していません。
しかも (VI) にあるような DNS｜Query は直前に存在せず、IP アドレスを直接指定していることが分かります。 - このような挙動はgにおけるアドレス探索（ネットワークスキャン）の典型例であり、
①「DNS を使わず IP を総当たりする」
②「接続が成功しにくい（SYN のみで終わる）」
という二つの偏りを生みます。 - 選択肢を照合すると
・ア「DNSクエリなしに通信を試みたあて先アドレス数の増加」
・ウ「コネクション接続成功率の低下」
が上記 ①②に合致します。 - よって解答は「ア、ウ」です。
誤りやすいポイント
- TCP-RST の増減に注目してしまう
→ スキャン先が応答しない場合は RST すら返ってこないため、低下ではなく「ほぼ変化なし」となることが多いです。 - 平均パケットサイズを指標に選ぶ
→ スキャンはほぼヘッダだけの小さな SYN を大量送信するため、むしろ平均サイズは小さくなる傾向です。 - (VI) の DNS クエリを「正常」と断定できず混乱する
→ 問題が問うのは (VII) によって生じる偏りです。焦点をずらさないことが重要です。
FAQ
Q: DNS を使わずに直接 IP へアクセスすることは必ず異常なのですか？
A: 正常なアプリケーションでも固定 IP へ直接通信する場合があります。ただし大量に連番アドレスへ TCP-SYN を送信する動きはスキャンと判断されやすく、今回はその偏りを捉えています。
A: 正常なアプリケーションでも固定 IP へ直接通信する場合があります。ただし大量に連番アドレスへ TCP-SYN を送信する動きはスキャンと判断されやすく、今回はその偏りを捉えています。
Q: 接続成功率はどのように算出しますか？
A: 一般的には TCP-SYN に対して SYN-ACK が返った割合を「成功率」とします。スキャンでは SYN-ACK がほとんど返らないため、成功率が極端に下がります。
A: 一般的には TCP-SYN に対して SYN-ACK が返った割合を「成功率」とします。スキャンでは SYN-ACK がほとんど返らないため、成功率が極端に下がります。
Q: DNS クエリの有無をどう抽出すると効率的ですか？
A: パケットキャプチャを時間順に並べ、宛先 IP ごとに直前の DNS Query の存在をチェックします。DNS が存在しない宛先件数が急増していれば、今回のような偏りを検知できます。
A: パケットキャプチャを時間順に並べ、宛先 IP ごとに直前の DNS Query の存在をチェックします。DNS が存在しない宛先件数が急増していれば、今回のような偏りを検知できます。
関連キーワード: ネットワークスキャン、TCPハンドシェイク、DNSクエリ、パケット解析、接続成功率
設問3：〔異常PCの対処と今後の対策〕について(1)、(2)に答えよ。
（1）本文中の下線④について、K君はどのような通信挙動のプロセスに注目したか。40字以内で述べよ。
模範解答
・OSやアプリケーションが本来通信しないあて先ホストと通信するプロセス
・OSやアプリケーションが本来通信しないあてポートを利用するプロセス
解説
解答の論理構成
-
事象の背景
- K君は「通信プロセス名、実行ファイル名、通信のあて先のIPアドレスとポート番号を記録する通信プロセスモニタ」を用い、PC 上で起動している各プロセスの外向き通信を詳細に取得しました。
- 目的は、本文で下線が引かれた「④不審な通信プロセス」を突き止めることです。
-
“不審” と判断する観点
- 業務 PC には OS や業務アプリケーションが通信する “正当なあて先” と “正当なポート” が存在します。
- それ以外のホスト／ポートに対して通信を試みるプロセスは、マルウェアや乗っ取りの可能性が高いと判断できます。
-
原文による裏付け
- 本文中で、J主任は「今回の事象以外にも、異常な通信が観測される可能性があります」と述べ、DNS 攻撃以外の怪しい外部通信にも目を向けるよう指示しています。
- そのため、K君は “通常は発生しない先” や “通常は使わないポート” へアクセスする挙動を示すプロセスを優先的に洗い出しました。
-
解答の要点
- 以上より、K君が注目したのは「OS や正規アプリケーションが本来通信しないホストやポートへ接続しているプロセス」です。
- 模範解答ではこれを
「OSやアプリケーションが本来通信しないあて先ホストと通信するプロセス」
「OSやアプリケーションが本来通信しないあてポートを利用するプロセス」
と具体的に示しています。
誤りやすいポイント
- 「通信量が多いプロセス」を不審とみなすだけでは不十分。少量でも未知ポートへ出ていれば要注意です。
- DNS クエリの有無だけに注視してしまい、HTTP／SMTP／NetBIOS など他プロトコルの怪しい通信を見逃すケース。
- 送信元 IP（社内側）が固定されているため、宛先 IP の異常を軽視してしまうミス。
FAQ
Q: なぜ“正規ポート”を使っていても不審と判定される場合があるのですか？
A: 外部の偽装サーバや C&C サーバが 80/TCP や 53/UDP など一般的ポートで待ち受けることがあるため、ポート番号だけで安全とは言えません。
A: 外部の偽装サーバや C&C サーバが 80/TCP や 53/UDP など一般的ポートで待ち受けることがあるため、ポート番号だけで安全とは言えません。
Q: プロセス名が OS 標準と同じでも安心できますか？
A: できません。マルウェアが「svchost.exe」などを装って通信する例が多いので、実行ファイルの保存場所・署名も確認します。
A: できません。マルウェアが「svchost.exe」などを装って通信する例が多いので、実行ファイルの保存場所・署名も確認します。
Q: 通信プロセスモニタを導入できない環境では、どう特定すればよいですか？
A: パケットキャプチャで送信元ポートを観察し、netstat -ano など OS 標準コマンドでポートとプロセス ID を突き合わせる方法が有効です。
A: パケットキャプチャで送信元ポートを観察し、netstat -ano など OS 標準コマンドでポートとプロセス ID を突き合わせる方法が有効です。
関連キーワード: 宛先ポート異常、C&Cサーバ、プロセス監視、ホスト改ざん
設問3：〔異常PCの対処と今後の対策〕について(1)、(2)に答えよ。
（2）本文中の下線⑤について、正常なPCを放置した場合、どのようなTCP/UDPパケットが観測されるべきなのか。図5を考慮して40字以内で述べよ。
模範解答
ウイルス対策ソフトによるパターンファイルの更新確認パケット
解説
解答の論理構成
- まず本文には、PCを操作しない状態で1日放置したところ「DNSパケットだけでなくすべてのTCP/UDPパケットの発信が止まった」とあります。
引用：【問題文】「DNSパケットだけでなくすべてのTCP/UDPパケットの発信が止まったことを確認しました。」 - これに対しJ主任は次のように指摘しています。
引用：【問題文】「当社の設定では、操作しないPCでもPCにログインしていれば、⑤TCP/UDPパケットは自動的に発信されます。」 - どのようなパケットが自動的に出るのかは、直後に示された図5のhostsファイル改ざん内容から読み取れます。
引用：【図5】2～6行目「127.0.0.1 www.OOO.com」「127.0.0.1 download.△△△.co.jp」…（右側に “ウイルス対策ソフトのパターンファイルの配布サイト” と注記） - つまり、本来なら外部の「パターンファイルの配布サイト」へアクセスしに行くための通信が発生するはずであり、それが「TCP/UDPパケットは自動的に発信されます」の具体例となります。
- したがって正常なPCから観測されるのは、「ウイルス対策ソフトがパターンファイル更新を確認するための通信（TCPまたはUDP）」という結論になります。
誤りやすいポイント
- 「自動更新＝HTTPだけ」と思い込み、UDPを除外してしまう。
- 図5の“127.0.0.1”を見てローカルループバック通信と誤解し、外部宛通信が不要と判断する。
- J主任の発言を「TCP/UDPどちらか」と読み違え、片方だけを解答に書いてしまう。
FAQ
Q: パターンファイル更新は必ずHTTPですか？
A: 製品によってはHTTPSや独自プロトコル（UDPも含む）を併用するため、問題文では「TCP/UDPパケット」と総称しています。
A: 製品によってはHTTPSや独自プロトコル（UDPも含む）を併用するため、問題文では「TCP/UDPパケット」と総称しています。
Q: hostsファイル改ざんがなぜ通信停止につながるのですか？
A: 更新サーバの名前がすべて “127.0.0.1” に置き換えられることで名前解決がループバックへ向き、外部への接続が行えなくなるためです。
A: 更新サーバの名前がすべて “127.0.0.1” に置き換えられることで名前解決がループバックへ向き、外部への接続が行えなくなるためです。
Q: DNS問い合わせも止まった理由は？
A: 更新確認用サイトの名前解決が不要（常に “127.0.0.1” に固定）となり、該当通信自体が発生しなくなったためです。
A: 更新確認用サイトの名前解決が不要（常に “127.0.0.1” に固定）となり、該当通信自体が発生しなくなったためです。
関連キーワード: hostsファイル改ざん、自動アップデート、パターンファイル、DNS名前解決、ループバックアドレス
