情報処理安全確保支援士 2017年 春期 午後1 問01
社内で発生したセキュリティインシデントに関する次の記述を読んで、設問1~3に答えよ。
D社は、従業員数100名のシステム開発会社である。D社のネットワーク構成を図1に示す。

D社のネットワークでは静的にIPアドレスが付与され、各セグメント間の通信はステートフルパケットインスペクション型のFWで制限されている。FWのフィルタリングルールを表1に示す。

従業員には、個人ごとにPCと利用者IDが割り当てられており、自身のPC上では、自身の利用者IDに対して管理者権限が付与されている。利用者IDは、LDAPサーバで一元管理されており、PCにログインする際、LDAPサーバで利用者認証が行われる。D社の顧客情報は全てCRMサーバに保管されており、営業業務に携わる従業員は、PCからWebブラウザでCRMサーバにアクセスして、顧客情報の登録・参照を行っている。
サーバ及びFWは、入退室管理されたサーバルーム内に設置されている。利用者ID作成などのサーバの運用は、サーバ管理者が、事前申請をした上で、管理用PCからSSHでサーバにログインして行っている。SSHでログインする際もPCにログインする際と同様に、LDAPサーバで利用者認証が行われる。
D社では、事前申請なしでCRMサーバへのSSHによるログインがあった場合、そのことを日次のバッチ処理によって顧客情報管理責任者であるN部長に電子メールで通知する仕組みを導入している。通知にはログイン時刻、SSHの接続元IPアドレス及び利用者IDが記載される。
〔セキュリティインシデントの発生〕
ある日、サーバ管理者のY主任の利用者IDで、管理用PCからCRMサーバにログインしたことを示す通知がN部長に届いた。N部長が、Y主任に確認したところ、その時間帯にはログインしていないとのことであった。
Y主任がCRMサーバのSSH認証ログを確認すると、身に覚えがない自分のログイン(以下、不審ログインという)の記録が残っていた。Y主任の報告を受けて、N部長は、不正侵入のセキュリティインシデント(以下、インシデントという)が発生したと判断し、インターネット接続を遮断した上で、セキュリティ専門業者Z社に調査を依頼した。
Z社のW氏が、サーバへの不正侵入の有無、侵入手口及び顧客情報窃取の有無に関する調査を進めることになった。
〔サーバへの侵入手口の調査〕
W氏は、まずサーバへの不正侵入の有無及び侵入手口の調査を行った。その調査結果を図2に示す。調査結果から、W氏は図3に示す手順でサーバへの不正侵入が行われていたと推測した。


図3の2の通信が盗聴されている時点では、FW、管理用PC及びAさんのPCのARPテーブルが、それぞれ表2~4に示すようになっていたとW氏は推測した。



図3の6の特定方法としては、管理用PCのIPアドレスを総当たりで推測することも考えられるが、そのような方法が採られた場合にFWのフィルタリングルールdによって記録されるはずのログが残っていなかった。このことから、①通信の盗聴によって管理用PCのIPアドレスが特定されたとW氏は推測した。
〔顧客情報窃取の有無の調査〕
続いて、W氏は顧客情報窃取の有無を調査した。CRMサーバの顧客情報を窃取する手口として三つ考えられたので、それぞれ調査を行った。
一つ目は、不正侵入されたCRMサーバからの直接の情報窃取である。調査した結果、CRMサーバからの直接の情報窃取はなかったと判断した。
二つ目は、AさんのPCからAさんがCRMサーバにアクセスした際の、AさんのPC又は通信からの情報窃取である。調査した結果、AさんはCRMサーバにはアクセスしていないことがFWのログ及び聞き取りから確認できた。
三つ目は、その他のPCからCRMサーバにアクセスした際の通信からの情報窃取である。D社内のWebブラウザの設定は、②サーバ証明書の検証に失敗した場合は接続しない設定にしている。このことから、CRMサーバにアクセスした際の通信からの情報窃取はなかったと判断した。
W氏は更に調査した結果、顧客情報の窃取はなかったとN部長に報告した。
〔セキュリティ対策の実施〕
Y主任は今回のインシデントを受けて、まず、マルウェアの駆除、ARPテーブルの初期化、全利用者IDのパスワード変更などの暫定対応を行った。その後、W氏の助言を受けながら、今回のように社内ネットワークに侵入された場合の被害拡大を防ぐために、社内ネットワークにおいて、二つのセキュリティ対策を実施することにした。
第一に、図3の8を防ぐために、図4のようにネットワーク構成を変更し、表5のようにFWのフィルタリングルールを変更することにした。これらの変更によって、3③図の6が行われることも防ぐことができる。また、④仮に図3の6とは異なる方法で管理用PCのIPアドレスが特定され、図3の8が試みられた場合でも、TCPコネクションの確立を防ぐことができる。
第二に、図3の4を防ぐために、LDAPサーバへの通信ではLDAP over TLSを利用することにした。


これらの対策はN部長によって承認され、今回と同様のインシデントに対する社内ネットワークのセキュリティ耐性が高まることになった。
設問1:サーバへの侵入手口の調査について、(1)〜(3)に答えよ。
(1)表3中のa及び表4中のb、cに入れる適切な字句を、図1中の機器のMACアドレスから選び、(ア)〜(キ)の記号で答えよ。
模範解答
a:力
b:オ
c:エ
解説
解答の論理構成
- 表2では、IPアドレス「192.168.0.1」と「192.168.0.200」の両方に同一のMACアドレス「xx:xx:xx:aa:aa:02」が対応しています。これはARPポイズニングによってFWが誤ったMACアドレスを学習させられた結果です。図1中で「xx:xx:xx:aa:aa:02」に割り当てられている記号は(カ)です。
- ARPポイズニング型のMITMでは、攻撃PCは
・管理用PCに対して「192.168.0.254(FW)のMACは自分」
・FWに対して「192.168.0.1(管理用PC)のMACは自分」
と偽情報をばらまきます。したがって、管理用PCのARPテーブル(表3)は「192.168.0.254 → (カ)」となり、a=(カ)です。 - 攻撃PC(AさんのPC)のARPテーブル(表4)は、通信を中継するために本来の対応表を保持します。すなわち、
・「192.168.0.1 → (オ)」(管理用PCの実MAC)
・「192.168.0.254 → (エ)」(FWの実MAC)
となるので、b=(オ)、c=(エ)です。
誤りやすいポイント
- 同じMACアドレスが二つのIPアドレスに対応している表2の異常を見落とし、ARPポイズニングに気付けない。
- 「192.168.0.254」はFWのIPだからMACは(エ)だと短絡的に考え、aを誤って(エ)としてしまう。
- 表3と表4のどちらが“攻撃側”のARPテーブルなのかを取り違え、b・cを逆に記入してしまう。
FAQ
Q: ARPポイズニングでは必ずMACアドレスが重複しますか?
A: はい。攻撃者は第三者のIPアドレスに自分のMACアドレスを対応付けて通知するため、同一MACに複数IPがひも付く異常が発生します。これが検知ポイントになります。
A: はい。攻撃者は第三者のIPアドレスに自分のMACアドレスを対応付けて通知するため、同一MACに複数IPがひも付く異常が発生します。これが検知ポイントになります。
Q: どうして攻撃PCは自分のARPテーブルに正しい対応を入れる必要があるのですか?
A: MITMで通信を中継するには、受け取ったフレームを本来の宛先に転送しなければなりません。そのため攻撃PC自身は正しいMAC対応表を持ち、正常な送信を行います。
A: MITMで通信を中継するには、受け取ったフレームを本来の宛先に転送しなければなりません。そのため攻撃PC自身は正しいMAC対応表を持ち、正常な送信を行います。
Q: FWのログに痕跡が残らない理由は?
A: 管理用PCのIPアドレスを盗聴で把握したため、総当たりのIPスキャンを実施しておらず、FWのフィルタリングルール「5」で記録されるはずの異常パケットが生成されなかったからです。
A: 管理用PCのIPアドレスを盗聴で把握したため、総当たりのIPスキャンを実施しておらず、FWのフィルタリングルール「5」で記録されるはずの異常パケットが生成されなかったからです。
関連キーワード: ARPポイズニング、MACアドレス詐称、Man-in-the-Middle、ステートフルファイアウォール、SSH認証
設問1:サーバへの侵入手口の調査について、(1)〜(3)に答えよ。
(2)本文中のdに入れる適切なフィルタリングルールを、表1中の項番1〜5から選び、数字で答えよ。
模範解答
d:5
解説
解答の論理構成
- 問題文には「そのような方法が採られた場合にFWのフィルタリングルールdによって記録されるはずのログが残っていなかった」とあります。
- つまり、総当たりでIPアドレスを探す通信があれば“ログを記録する”設定のルールに該当するはずです。
- 表1で“ログの記録”が「する」かつ不審者が発生源である「PC セグメント」から宛先「サーバセグメント」への試行を網羅的に拒否するのは、項番「5」の
・送信元「PC セグメント」
・宛先「サーバセグメント」
・サービス「全て」
・動作「拒否」
・ログの記録「する」
です。 - よってdに入る数字は「5」となります。
誤りやすいポイント
- 「通信が拒否される=ログが残らない」と早合点し、ログが「しない」のルールを選んでしまう。
- 送信元が「PC セグメント」でも特定サーバ宛て(LDAP や CRM)なら項番「2」「3」が適用されると勘違いし、スキャンの全パケットがそれらに当たると誤認する。
- ルールの適用順を意識せず、上位ルールで許可されなかったパケットが下位の“全て拒否”に落ちる流れを見落とす。
FAQ
Q: 総当たりスキャンでも項番「1」のようなインターネット向け許可ルールに該当する可能性はありますか?
A: ありません。送信先が「サーバセグメント」内なので、宛先条件が異なり項番「1」にはマッチしません。
A: ありません。送信先が「サーバセグメント」内なので、宛先条件が異なり項番「1」にはマッチしません。
Q: 項番「2」や「3」は“ログの記録”が「しない」または「する」ですが、これらが選択肢にならない理由は?
A: スキャン対象はネットワーク上の複数IPであり、必ずしも「LDAP サーバ」や「CRM サーバ」のIPとは限りません。フィルタに掛からない通信は項番「5」で捕捉されます。
A: スキャン対象はネットワーク上の複数IPであり、必ずしも「LDAP サーバ」や「CRM サーバ」のIPとは限りません。フィルタに掛からない通信は項番「5」で捕捉されます。
Q: もし攻撃者が管理用PCのIPを一度で正確に推測した場合、FWログは残りますか?
A: 項番「5」に該当しない(=正確な宛先が「サーバセグメント」ではない)場合は残らない可能性がありますが、問題文では“総当たりで推測”した場合を想定しており、そこではログが残ると説明しています。
A: 項番「5」に該当しない(=正確な宛先が「サーバセグメント」ではない)場合は残らない可能性がありますが、問題文では“総当たりで推測”した場合を想定しており、そこではログが残ると説明しています。
関連キーワード: ステートフルパケットインスペクション、フィルタリングルール、ARPポイズニング、ログ管理、IPスキャン
設問1:サーバへの侵入手口の調査について、(1)〜(3)に答えよ。
(3)本文中の下線①について、攻撃者が管理用PCのIPアドレスを特定するために盗聴したのはどのような通信か。送信元、宛先及びサービスを、それぞれ解答群の中から選び、記号で答えよ。
解答群
ア:ARP
イ:AさんのPC
ウ:FW
エ:HTTP over TLS
オ:LDAP
カ:LDAPサーバ
キ:SSH
ク:インターネット
ケ:管理用PC
模範解答
送信元:ケ
宛先:カ
サービス:キ
解説
解答の論理構成
- 攻撃者は「図3の6」で管理用PCのIPアドレスを突き止めています。問題文には「①通信の盗聴によって管理用PCのIPアドレスが特定された」と明記されています。
- 盗聴対象の通信は、PCセグメント内を流れる“管理用PCとサーバ間”のパケットです。通信相手として最も頻繁にやり取りがあるのは、利用者認証のために管理用PCが接続する「LDAPサーバ」です。
- 原文引用:「管理用PCからSSHでサーバにログインして行っている。SSHでログインする際も…LDAPサーバで利用者認証が行われる。」
- サービス種別は「SSH」です。LDAPサーバに対して利用者認証を行う際、SSHでサーバに接続していることが前段で示されています。
- 以上より、盗聴された通信は
- 送信元:ケ(管理用PC)
- 宛先 :カ(LDAPサーバ)
- サービス:キ(SSH)
となります。
誤りやすいポイント
- ARPフレームを選びたくなる
→ ARPポイズニングは「盗聴を可能にする下準備」に過ぎず、IPアドレスの手掛かりを与えるのはARPではなくIP層以上の実際の業務通信です。 - 「HTTP over TLS」を選んでしまう
→ 管理用PCはWebブラウザではなくSSHクライアントでサーバを保守します。ブラウザ通信はユーザPCとCRMサーバの経路であり、管理用PCのIPを含みません。 - 送信元・宛先を逆に回答
→ IPヘッダには必ず送信元IPが入るため、攻撃者は“管理用PCが送った”パケットを盗聴する必要があります。宛先が管理用PCでは情報が取れません。
FAQ
Q: LDAPサーバへの認証なら「LDAP」ポートを盗聴するのでは?
A: D社では「LDAPサーバ」自身のメンテナンス接続をSSHで行っています。したがって管理用PC→LDAPサーバ間はSSH通信です。
A: D社では「LDAPサーバ」自身のメンテナンス接続をSSHで行っています。したがって管理用PC→LDAPサーバ間はSSH通信です。
Q: 攻撃者がCRMサーバ宛のSSHを盗聴してもIPは分かるのでは?
A: もちろんCRMサーバ宛のSSHでも送信元IPは判明します。ただし管理用PCが日常的に最も多くコンタクトするのはLDAPサーバなので、効率よく盗聴できる経路としてLDAPサーバ宛が想定されています。
A: もちろんCRMサーバ宛のSSHでも送信元IPは判明します。ただし管理用PCが日常的に最も多くコンタクトするのはLDAPサーバなので、効率よく盗聴できる経路としてLDAPサーバ宛が想定されています。
Q: FWログが残っていなかったのはなぜ重要?
A: 総当たりでIPを探していればFWの「PCセグメント→サーバセグメント 全て 拒否」のルールで“多数の拒否ログ”が残るはずです。ログが無かったことが「盗聴でIPを知った」根拠になっています。
A: 総当たりでIPを探していればFWの「PCセグメント→サーバセグメント 全て 拒否」のルールで“多数の拒否ログ”が残るはずです。ログが無かったことが「盗聴でIPを知った」根拠になっています。
関連キーワード: ARPポイズニング、SSH、パケット盗聴、IPアドレス偽装、フィルタリングルール
設問2:
本文中の下線②について、このような設定にすることは、AさんのPCに侵入した攻撃者によって行われるどのような攻撃への対策になるか。攻撃名を10字以内で答えよ。また、攻撃に際して詐称される対象の機器名を図1中から選び、答えよ。
模範解答
攻撃名:中間者攻撃
機器名:CRMサーバ
解説
解答の論理構成
-
問題文は、社内ブラウザの共通設定として
「②サーバ証明書の検証に失敗した場合は接続しない設定にしている」
と明記しています。これは TLS 通信時に証明書が正当でなければ接続そのものを拒否するという意味です。 -
攻撃者が A さんの PC を踏み台にして通信を盗聴・改ざんする手順を図3で示しており、手順8では
「AさんのPC上で管理用PCのIPアドレスを詐称して,LDAPサーバ及びCRMサーバのSSHポートにアクセス」
が実行されています。HTTPS(HTTP over TLS)でも同様に IP や DNS 情報を詐称し、偽サーバを名乗って被害者 PC と本物サーバの間に割り込むことが典型的です。 -
このときブラウザがサーバ証明書を厳格に検証すれば、偽サーバは正当な証明書を提示できないため接続が成立しません。従って、②の設定は
攻撃者が「通信を盗聴」し「詐称」したサーバを経由させる
図3の流れ(1→2→6→8)を根本的に防ぐ働きをします。 -
図1で HTTPS を用いてアクセスするサーバは「CRM サーバ」であり、被害者 PC にとって最終的に偽装される対象も CRM サーバです。
-
以上より、
・攻撃名:中間者攻撃(Man-in-the-Middle)
・詐称される機器名:CRMサーバ
が妥当な解答になります。
誤りやすいポイント
- サーバ証明書の検証は「盗聴」だけでなく「改ざん」も防ぐ点を見落としやすい。
- 「フィッシング」や「ARPポイズニング」と直接答えてしまうと、TLS 層での対策との因果が説明できない。
- 詐称対象を「LDAPサーバ」と誤答するケースが多いが、HTTPS を利用するのは CRM サーバなので要注意。
FAQ
Q: ARP ポイズニングが成功しても TLS が張られていれば安全でしょうか?
A: 攻撃者が正当な証明書を用意できなければ安全です。②の設定で不正証明書を拒否するため、セッションは確立しません。
A: 攻撃者が正当な証明書を用意できなければ安全です。②の設定で不正証明書を拒否するため、セッションは確立しません。
Q: 自己署名証明書を使っている社内サーバの場合はどうなりますか?
A: 信頼済みルートに登録していない自己署名証明書では検証に失敗し、②の設定なら接続できません。正規の内部 CA を運用する必要があります。
A: 信頼済みルートに登録していない自己署名証明書では検証に失敗し、②の設定なら接続できません。正規の内部 CA を運用する必要があります。
Q: DNS キャッシュポイズニングへの効果はありますか?
A: 偽の DNS 応答で攻撃者サーバに誘導されても、証明書が一致しないか失効していれば接続を拒否できるため、一定の防御効果があります。
A: 偽の DNS 応答で攻撃者サーバに誘導されても、証明書が一致しないか失効していれば接続を拒否できるため、一定の防御効果があります。
関連キーワード: TLS, サーバ証明書, PKI, 中間者攻撃, ARPポイズニング
設問3:セキュリティ対策の実施について、(1)、(2)に答えよ。
(1)本文中の下線③について、防ぐことができる理由を35字以内で具体的に述べよ。
模範解答
PCセグメント内に管理用PCとサーバ間の通信が流れなくなるから
解説
解答の論理構成
-
攻撃者が管理用 PC の IP を把握できた理由
- 「図3の6」で「通信を盗聴して,管理用PCのIPアドレスを特定する」とあります。
- 当初は管理用 PC が「PCセグメント」に置かれていたため、同セグメントにいる感染 PC からARPポイズニングで盗聴できました。
-
ネットワーク構成変更後の状態
- 「図4」で管理用 PC は新設された「サーバ管理セグメント」に移動しています。
- PC セグメントとサーバ管理セグメント間は FW で「6 PCセグメント サーバ管理セグメント 全て 拒否」と明示的に遮断されています(表5)。
-
結果として盗聴経路が消失
- 管理用 PC と各サーバ間の SSH 通信はサーバ管理セグメント内だけを流れ、PC セグメントの L2SW を経由しません。
- よって、PC セグメント内にいる攻撃 PC はその通信を取得できず、「通信を盗聴して,管理用PCのIPアドレスを特定する」行為自体が不可能になります。
-
まとめ
- 管理用 PC とサーバ間のパケットが PC セグメントに流れなくなるため、③の攻撃(図3の6)は発生しません。
誤りやすいポイント
- FW ルールの「6」は遮断であり、許可と見間違える。
- 「図3の8」の防止理由と「図3の6」の防止理由を混同する。
- 管理用 PC を別セグメントに置いてもARPポイズニングを完全に防げないと誤解し、FW の遮断効果を見落とす。
- VLAN 分割と物理セグメント分割を同一視し、通信経路の違いを説明できない。
FAQ
Q: 管理用 PC が別セグメントでも MAC なりすましで盗聴される可能性は?
A: PC セグメントとサーバ管理セグメント間が FW でレイヤ3遮断されています。ARP はブロードキャストが届かず、なりすまし自体が成立しません。
A: PC セグメントとサーバ管理セグメント間が FW でレイヤ3遮断されています。ARP はブロードキャストが届かず、なりすまし自体が成立しません。
Q: PC セグメントの PC から管理用 PC へ直接 Ping を打ったら?
A: 表5 の「6 PCセグメント サーバ管理セグメント 全て 拒否」により ICMP も遮断され、到達しません。
A: 表5 の「6 PCセグメント サーバ管理セグメント 全て 拒否」により ICMP も遮断され、到達しません。
Q: サーバ管理セグメント側から PC セグメントへ戻る通信は?
A: 表5 の「9 サーバ管理セグメント PCセグメント 全て 拒否」で逆方向もブロックされています。
A: 表5 の「9 サーバ管理セグメント PCセグメント 全て 拒否」で逆方向もブロックされています。
関連キーワード: ネットワーク分離、ARPポイズニング、パケット盗聴、フィルタリングルール
設問3:セキュリティ対策の実施について、(1)、(2)に答えよ。
(2)本文中の下線④について、TCPコネクション確立開始時のSYNパケットとSYN-ACKパケットはそれぞれどのような経路をたどるか。図4中の経路を通過する順に選び、(A)〜(C)の記号で答えよ。
模範解答
SYNパケット:(C) → (A)
SYN-ACKパケット:(A) → (B)
解説
解答の論理構成
-
攻撃者は PC セグメントから SSH で “図3の8” を試みます。図4では PC が存在するのは (C) であり、宛先の LDAP サーバや CRM サーバはサーバセグメント (A) です。
したがって、最初に送信される SYN パケットは (C)→(A) の経路をたどります。 -
CRM サーバ((A) 内)が受け取った SYN パケットの送信元 IP アドレスは「管理用PC」のものに詐称されています。CRM サーバはこの IP アドレスが属するサーバ管理セグメント (B) を宛先と判断して SYN-ACK パケットを返します。よって応答は (A)→(B) の経路になります。
-
表5 には
- 「5 PCセグメント → サーバセグメント 全て 拒否」
- 「6 PCセグメント → サーバ管理セグメント 全て 拒否」
が設定されています。攻撃者が (C) から (A) に送った SYN パケットはルール5で拒否されるので TCP セッションは確立しません。質問は“確立開始時のパケットがどの経路を進むか”だけを問うているため、結果として
• SYN:(C) → (A)
• SYN-ACK:(A) → (B)
が正答になります。
誤りやすいポイント
- 「送信元 IP=管理用PC」の詐称に惑わされ、SYN パケットを (B) 発と誤認する。物理的な送信元は (C) である点に注意が必要です。
- SYN-ACK の返送先は“IPアドレスを見て”決まるため (B) 行きですが、FW を経由せず (A) 内だけで完結すると誤解しやすい。
- 表5のルール番号を確認せず、旧ルール(表1)の動作で考えてしまう。設問は変更後の構成を前提としています。
FAQ
Q: 表5のルール6があるのに攻撃者の SYN パケットは (C)→(A) へ届くのでは?
A: 物理的には FW に到達しますが、ルール6で拒否されるため TCP セッションは張られません。設問は“どの経路を通過するか”を聞いているだけなので (C)→(A) が答えになります。
A: 物理的には FW に到達しますが、ルール6で拒否されるため TCP セッションは張られません。設問は“どの経路を通過するか”を聞いているだけなので (C)→(A) が答えになります。
Q: SYN-ACK は FW を通過しますか。
A: はい。CRM サーバは宛先 IP を見て「サーバ管理セグメント (B) 宛」と判断し、FW を経由して (B) へ送ります。ただし管理用PCが応答しないため 3-way ハンドシェイクは完了しません。
A: はい。CRM サーバは宛先 IP を見て「サーバ管理セグメント (B) 宛」と判断し、FW を経由して (B) へ送ります。ただし管理用PCが応答しないため 3-way ハンドシェイクは完了しません。
Q: なぜ (A)→(C) ではないのですか。
A: SYN-ACK の宛先は送信元 IP に依存します。詐称された IP は (B) に属するので (A)→(B) になります。実際の送信元セグメントは考慮されません。
A: SYN-ACK の宛先は送信元 IP に依存します。詐称された IP は (B) に属するので (A)→(B) になります。実際の送信元セグメントは考慮されません。
関連キーワード: ARPポイズニング、IPスプーフィング、ファイアウォール、TCPハンドシェイク


