HOME»情報処理安全確保支援士掲示板»平成30年度 秋 午後1 問2 設問1
投稿する
横から失礼します。
ARPの情報が書き換わるのは、GARPの受信と自信が送出したARPリクエストに対するリプライを受け取った場合です。
キャプチャーすればわかりますが、指定ブロードキャストのPingの宛先が同一セグメント内の場合、L2の宛先にff-ff-ff-ff-ff-ffをセットするのでARPを送出しません。
ご説明ありがとうございます。
昔、それでARPリストが書き変わるって言ってた記事を見た記憶があるんですが、その記事の前提条件はよくわかりません。
ARPリクエストを選んだ解釈は、hisashiさんはなにかありますか?
平成30年度 秋 午後1 問2 設問1 [0832]
ガルガルさん(No.1)
M君は、無線LANのパケットをキャプチャしたところ、6台のPCが、(d)リクエストをブロードキャストで送信して、同一セグメント内のPCを探索していることを確認した。
↓
d=ARP
が解答になっています。
私は、ECHOリクエストが答えだと思いました。
これについて以下のどちらの解釈が正しいでしょうか?
[解釈]
1.ECHO(PING)リクエストでも稼働中のホストPCを探索することができるが、ブロードキャスト宛てのPINGは拒否している場合が多いため有効ではない。そのためARPが答えである。
2.DHCPを導入しているため、ホストに対応したIPアドレスは変動する。
そのためにECHOリクエストではなく、ARPを使用するのが正しい。
↓
d=ARP
が解答になっています。
私は、ECHOリクエストが答えだと思いました。
これについて以下のどちらの解釈が正しいでしょうか?
[解釈]
1.ECHO(PING)リクエストでも稼働中のホストPCを探索することができるが、ブロードキャスト宛てのPINGは拒否している場合が多いため有効ではない。そのためARPが答えである。
2.DHCPを導入しているため、ホストに対応したIPアドレスは変動する。
そのためにECHOリクエストではなく、ARPを使用するのが正しい。
2022.03.22 21:42
GinSanaさん(No.2)
★SC ブロンズマイスター
この投稿は投稿者により削除されました。(2022.03.23 14:38)
2022.03.23 14:38
GinSanaさん(No.3)
★SC ブロンズマイスター
この投稿は投稿者により削除されました。(2022.03.23 14:49)
2022.03.23 14:49
GinSanaさん(No.4)
★SC ブロンズマイスター
この投稿は投稿者により削除されました。(2022.03.23 14:49)
2022.03.23 14:49
GinSanaさん(No.5)
★SC ブロンズマイスター
結局、pingの場合、気配斬りじゃないけど、そこにいるのはわかるがお前は誰だ?って状態じゃないですか。MACアドレスがわからないから。
それだったら、ひたすらARPリクエスト飛ばしますよね。同一セグメントに感染させるにはレイヤ2(だからL2SWで繋がっている)の通信でよくて、それにはMACアドレスがわかればいい・・・となれば、ほしい目的はMACアドレスだろ?ってので、ARPが答えになるんじゃないですか(久々にこの問題見たので、今の解釈はこんな感じです)。
結局変動してもARPリクエストやpingを1つずつずらしてひたすら飛ばしたら使われているIPアドレス自体はわかるから、
そこが重要ではないと思いはします。
RARPサーバがないから引っこ抜いたMACアドレスからRARPでは逆引きできないですが・・・。
そのセグメントが仮に192.168.1.0/24として、
それだったら、ひたすらARPリクエスト飛ばしますよね。同一セグメントに感染させるにはレイヤ2(だからL2SWで繋がっている)の通信でよくて、それにはMACアドレスがわかればいい・・・となれば、ほしい目的はMACアドレスだろ?ってので、ARPが答えになるんじゃないですか(久々にこの問題見たので、今の解釈はこんな感じです)。
>DHCPを導入しているため、ホストに対応したIPアドレスは変動する
>そのためにECHOリクエストではなく、ARPを使用するのが正しい。
結局変動してもARPリクエストやpingを1つずつずらしてひたすら飛ばしたら使われているIPアドレス自体はわかるから、
そこが重要ではないと思いはします。
RARPサーバがないから引っこ抜いたMACアドレスからRARPでは逆引きできないですが・・・。
そのセグメントが仮に192.168.1.0/24として、
ping 192.168.1.255
をしてからarp -a
をするとARPテーブルがごっそり書き換えられたりはします。まあ、問題文を見る限り、そんなことはしてないんですけどね。2022.03.23 14:49
hisashiさん(No.6)
★SC ブロンズマイスター
>そのセグメントが仮に192.168.1.0/24として、
>ping 192.168.1.255
>をしてから
>arp -a
>をするとARPテーブルがごっそり書き換えられたりはします。
横から失礼します。
ARPの情報が書き換わるのは、GARPの受信と自信が送出したARPリクエストに対するリプライを受け取った場合です。
キャプチャーすればわかりますが、指定ブロードキャストのPingの宛先が同一セグメント内の場合、L2の宛先にff-ff-ff-ff-ff-ffをセットするのでARPを送出しません。
2022.03.23 20:11
GinSanaさん(No.7)
★SC ブロンズマイスター
この投稿は投稿者により削除されました。(2022.03.23 20:23)
2022.03.23 20:23
GinSanaさん(No.8)
★SC ブロンズマイスター
>ARPの情報が書き換わるのは、GARPの受信と自信が送出したARPリクエストに対するリプライを受け取った場合です。
>キャプチャーすればわかりますが、指定ブロードキャストのPingの宛先が同一セグメント内の場合、L2の宛先にff-ff-ff-ff-ff-ffをセットするのでARPを送出しません。
ご説明ありがとうございます。
昔、それでARPリストが書き変わるって言ってた記事を見た記憶があるんですが、その記事の前提条件はよくわかりません。
ARPリクエストを選んだ解釈は、hisashiさんはなにかありますか?
2022.03.23 20:23
hisashiさん(No.9)
★SC ブロンズマイスター
私は解釈1に近いです。
ガルガルさんのおっしゃるとおり指定ブロードキャストに応答する機器は、
非常に少ないです。対象がPCならなおさらのことで、ブロードキャストのechoリクエストは、探索には不向きです。それと、前述のとおりARPの情報も取得できないので、あまり意味がないと思います。
ガルガルさんのおっしゃるとおり指定ブロードキャストに応答する機器は、
非常に少ないです。対象がPCならなおさらのことで、ブロードキャストのechoリクエストは、探索には不向きです。それと、前述のとおりARPの情報も取得できないので、あまり意味がないと思います。
2022.03.23 21:49
昭和62年さん(No.10)
(聞かれていないですが)私は、シンプルに
「ECHO」リクエスト:なんでICMPを省略するのだろうという違和感
「ARP」リクエスト:違和感なし
→「ARP」を選択
「ECHO」リクエスト:なんでICMPを省略するのだろうという違和感
「ARP」リクエスト:違和感なし
→「ARP」を選択
2022.03.23 21:57
pixさん(No.11)
★SC ダイヤモンドマイスター
横から失礼します。
JPERT/CCよりICMP ECHOリクエスト ブロードキャストには応答しないほうが
良いというガイドラインがでております。
又、ICMP ECHOリクエスト ブロードキャストはSmurf攻撃で用いられる手法であり、
本問の環境ではIDS機能をもつNSMセンサに補足される可能性が大きいです。
JPERT/CCよりICMP ECHOリクエスト ブロードキャストには応答しないほうが
良いというガイドラインがでております。
又、ICMP ECHOリクエスト ブロードキャストはSmurf攻撃で用いられる手法であり、
本問の環境ではIDS機能をもつNSMセンサに補足される可能性が大きいです。
2022.03.23 22:19
GinSanaさん(No.12)
★SC ブロンズマイスター
この投稿は投稿者により削除されました。(2022.03.23 22:37)
2022.03.23 22:37
GinSanaさん(No.13)
★SC ブロンズマイスター
たしかにICMP Echo broadcastはNSMセンサにかかりにいくようなものでしたね。
2022.03.23 22:48
pixさん(No.14)
★SC ダイヤモンドマイスター
鋭い指摘ありがとうございます。
本環境でしたら、ぎりぎりNSMに補足されるかされないか判断は難しいです。
ですが、同一セグメント内にIDSがある環境でしたら、確実に補足対象に
なると思われます。
故にマルウェアが隠密でPCを探索する目的であれば、補足リスクの
高いECHOよりARPの方が目標の遂行に適していると思われます。
本環境でしたら、ぎりぎりNSMに補足されるかされないか判断は難しいです。
ですが、同一セグメント内にIDSがある環境でしたら、確実に補足対象に
なると思われます。
故にマルウェアが隠密でPCを探索する目的であれば、補足リスクの
高いECHOよりARPの方が目標の遂行に適していると思われます。
2022.03.23 23:00
GinSanaさん(No.15)
★SC ブロンズマイスター
消してしまった質問(後で考えたらなんかアホなこと聞いちゃったかと思って消してしまった)
私も、同一セグメント内にIDSがある環境でしたら、確実に捕捉されるからやらないかな、とは思ったんですが、今回はL3SWにくっついてるから、一瞬そっちまで届くかな?とか思って聞いてみました。ご回答ありがとうございます。ARPのほうがリスクが少ないですね、やはり。
10.100.130.0/24のある1端末から仮にping 10.100.130.255を飛ばしたとして、L3SWにくっついているNSMセンサまで届きますか?(私は届かないと思っている)
私も、同一セグメント内にIDSがある環境でしたら、確実に捕捉されるからやらないかな、とは思ったんですが、今回はL3SWにくっついてるから、一瞬そっちまで届くかな?とか思って聞いてみました。ご回答ありがとうございます。ARPのほうがリスクが少ないですね、やはり。
2022.03.23 23:38
昭和62年さん(No.16)
ARPのほうがばれるリスクが少ないから、ARPが正答である
って完全に犯罪者の観点じゃないですか
そういう試験じゃないと思うのですが....
って完全に犯罪者の観点じゃないですか
そういう試験じゃないと思うのですが....
2022.03.24 20:31
GinSanaさん(No.17)
★SC ブロンズマイスター
まあIPAで記述式だったらこんな回答はまず求めてないでしょうけど、
SmurfのくだりでICMP Echo Broadcastが捕捉されやすいという話があって、もしかしたら本件のネットワーク構成ではNSMには届かないかもしれない、しかし一般的にはリスキーだから使わないか
で話を止めただけで、リスキーだからARPが正答だ、とまでは行き着かないんじゃないですか。本筋ではないからです。
2択で言っているようなもんじゃないか、と言われれば、そうなんですが。
SmurfのくだりでICMP Echo Broadcastが捕捉されやすいという話があって、もしかしたら本件のネットワーク構成ではNSMには届かないかもしれない、しかし一般的にはリスキーだから使わないか
で話を止めただけで、リスキーだからARPが正答だ、とまでは行き着かないんじゃないですか。本筋ではないからです。
2択で言っているようなもんじゃないか、と言われれば、そうなんですが。
2022.03.24 22:34
GinSanaさん(No.18)
★SC ブロンズマイスター
完全に犯罪者の観点がIPAでは求められていないか?というと、たまに
令和元年秋PM2問1の設問1(1)みたいに「この処理をしないと攻撃者の意図に反してどういうことが起こるか?」みたいな記述もあるにはあるので、これに限らず犯罪者の観点も考えないわけではなく、相手だったらどう動くだろう?みたいなことは問題文を読みながら考えたりはしますね。それが問題の設問として要求されるかはまた別の話ですが・・・。
令和元年秋PM2問1の設問1(1)みたいに「この処理をしないと攻撃者の意図に反してどういうことが起こるか?」みたいな記述もあるにはあるので、これに限らず犯罪者の観点も考えないわけではなく、相手だったらどう動くだろう?みたいなことは問題文を読みながら考えたりはしますね。それが問題の設問として要求されるかはまた別の話ですが・・・。
2022.03.24 22:54
ガルガルさん(No.19)
皆様ご回答ありがとうございます。
頂いた内容を自分なりにかみ砕きつつ問題文を再度読み返しております。
そのため返事はもう少し後になるかと思います・・・・
頂いた内容を自分なりにかみ砕きつつ問題文を再度読み返しております。
そのため返事はもう少し後になるかと思います・・・・
2022.03.24 23:06
hisashiさん(No.20)
★SC ブロンズマイスター
前回、ブロードキャストでない理由は述べましたが、ARPが回答になる明確な理由は書いてないので、思ったことを記します。
ARPリクエストでの探索を検知したのは、(a)スキャンの試行の結果だと思います。(a)のスキャンでは、IPアドレス範囲の最後までスキャンが完了した場合、5分間待機した後、IPアドレス範囲の先頭からスキャンを繰り返すとあるので、この時点でブロードキャストの可能性はなくなります。
ARPキャッシュに存在しないIPアドレスに対しては、SYNパケット送出の前に必ず、ARPリクエストが走ります。
それを5分間隔で実施していることとDHCPのリース期間を考慮し、定期的にARPリクエストが無線を飛び交ったと予想されます。
これによるARPリクエストをキャプチャして、今回の問題を発見したという経緯かと思います。
ARPリクエストでの探索を検知したのは、(a)スキャンの試行の結果だと思います。(a)のスキャンでは、IPアドレス範囲の最後までスキャンが完了した場合、5分間待機した後、IPアドレス範囲の先頭からスキャンを繰り返すとあるので、この時点でブロードキャストの可能性はなくなります。
ARPキャッシュに存在しないIPアドレスに対しては、SYNパケット送出の前に必ず、ARPリクエストが走ります。
それを5分間隔で実施していることとDHCPのリース期間を考慮し、定期的にARPリクエストが無線を飛び交ったと予想されます。
これによるARPリクエストをキャプチャして、今回の問題を発見したという経緯かと思います。
2022.03.24 23:21