情報処理安全確保支援士 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)に答えよ。
問題文を見る模範解答
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:
問題文を見る模範解答
攻撃名:中間者攻撃
機器名: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ポイズニングで盗聴できました。
-
ネットワーク構成変更後の状態
-
結果として盗聴経路が消失
- 管理用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)に答えよ。
問題文を見る模範解答
SYNパケット:(C) → (A)
SYN-ACKパケット:(A) → (B)
解説
解答の導き方
-
図4の記号対応を確認する
図4では (A) がサーバセグメント、(B) がサーバ管理セグメント、(C) がPCセグメントを示しています。したがって経路を答える際はこれらの意味を踏まえます。 -
送信元/宛先のIPと実際の送信点を整理する
図3の手順8にある「AさんのPC上で管理用PCのIPアドレスを詐称して、LDAPサーバ及びCRMサーバのSSHポートにアクセスし、Y主任のユーザーIDとパスワードでログインする。」という記述から、実際にパケットを送っている端末はAさんのPC(物理的にはPCセグメント、図4の(C))である一方、パケットのIPヘッダ上の送信元IPは管理用PCのIP(図4で管理用PCが置かれるサーバ管理セグメント、(B) に属する)に偽装していることが分かります。つまり、パケットは物理的には (C) から発生し、IPヘッダ上の送信元は (B) のアドレスになっています。 -
SYNパケットの経路を考える(クライアント→サーバ)
TCP接続確立の開始はクライアント側から送るSYNパケットなので、攻撃者がAさんのPC上で作成したSYNは物理的にPCセグメントからサーバ(CRM等)があるサーバセグメントへ向かいます。図4の接続構成に従えばこれは (C) → (A) の経路を通ることになります。さらに、今回の対策後のフィルタ設定を見ると、表5の項番5は送信元が「PCセグメント」、宛先が「サーバセグメント」、動作が「拒否」となっており、PCセグメントからサーバセグメントへの通信は拒否されるため、SYNはFWで破棄されて接続確立が阻止されます。 -
SYN-ACKパケットの経路を考える(サーバ→クライアント)
サーバは受け取ったSYNに対し、IPヘッダの送信元アドレス(ここでは詐称された管理用PCのIP)宛てに応答(SYN-ACK)を返します。ルーティングは宛先IPに基づいて行われるため、宛先が管理用PCのIPであればサーバ側からはサーバ管理セグメントへ送られます。図4で管理用PCが位置するのは (B) ですから、応答は (A) → (B) の経路をたどります。重要な点は、応答パケットは「実際にパケットを送ったPCの物理的な位置」ではなく「パケットに書かれた宛先IP」に向かって返るということです。 -
結論(経路)
上の整理により、SYNパケットは (C) → (A)、SYN-ACKパケットは (A) → (B) の経路をたどると判断できます。したがって、SYNを送った攻撃者が物理的に (C) にいても、応答は偽装されたIPの属する (B) に向かうため、攻撃者側で手動に応答を受け取れなければTCP三者間ハンドシェイクは完了しません。
誤りやすいポイント
- 応答は送信時の物理経路を逆向きにたどると誤解する(ルーティングは宛先IPで決まる点を忘れる)。
- 送信元IPを詐称すると必ず攻撃者に応答が返ると考える(詐称先のネットワークに返るのが通常)。
- フィルタの該当項番を誤認する(PC→サーバを拒否するのは表5の項番5、PC→サーバ管理セグメントを拒否するのは項番6など、項番の混同)。
- ステートフルFWの挙動(セッション状態の有無)と単純なパケット転送を混同する。FWがどの情報(送信元インタフェース、送信元IPなど)で判定するかを明確にしないと誤答しやすい。
- ARPやMACの情報(物理層の情報)とIPルーティングの決定を混同する。
FAQ
Q: なぜサーバからの応答(SYN-ACK)は(A)→(B)になるのですか?
A: サーバはSYNのIPヘッダに書かれた送信元IP(ここでは詐称された管理用PCのIP)宛てに返信します。返信のルーティングは宛先IPに基づくため、該当IPが属するサーバ管理セグメントへ送られ、図4上では (A)→(B) になります。
A: サーバはSYNのIPヘッダに書かれた送信元IP(ここでは詐称された管理用PCのIP)宛てに返信します。返信のルーティングは宛先IPに基づくため、該当IPが属するサーバ管理セグメントへ送られ、図4上では (A)→(B) になります。
Q: 攻撃者が送ったSYNが通過してサーバがSYN-ACKを送った場合、攻撃者はそれを傍受できませんか?
A: 通常はできません。SYN-ACKは宛先IP(詐称された管理用PCのIP)が属するセグメントへ送られるため、物理的にPCセグメントにいる攻撃者には届きません。ただし、そのセグメントの通信を別途盗聴できる(例えばARPポイズニング等で中継できる)状況であれば傍受可能です。今回の対策では表5の項番5・6などでPCセグメントからの直接到達を遮断しており、単純な詐称では接続確立できないように設計されています。
A: 通常はできません。SYN-ACKは宛先IP(詐称された管理用PCのIP)が属するセグメントへ送られるため、物理的にPCセグメントにいる攻撃者には届きません。ただし、そのセグメントの通信を別途盗聴できる(例えばARPポイズニング等で中継できる)状況であれば傍受可能です。今回の対策では表5の項番5・6などでPCセグメントからの直接到達を遮断しており、単純な詐称では接続確立できないように設計されています。
Q: どのFWルールでSYNが拒否されるのですか?
A: 表5の項番5が送信元「PCセグメント」、宛先「サーバセグメント」、動作「拒否」となっており、PCセグメントからサーバセグメントへの全通信を拒否します(項番6はPCセグメント→サーバ管理セグメントを拒否します)。これにより、図3のようなC発の不正接続試行を直接防止します。
A: 表5の項番5が送信元「PCセグメント」、宛先「サーバセグメント」、動作「拒否」となっており、PCセグメントからサーバセグメントへの全通信を拒否します(項番6はPCセグメント→サーバ管理セグメントを拒否します)。これにより、図3のようなC発の不正接続試行を直接防止します。
関連キーワード: ARPポイズニング、IPアドレス詐称、ステートフルパケットインスペクション、TCP三者間ハンドシェイク、ARPテーブル








