実際、 habrahabr.ru / post / 157207に基づいてトピックを開きます
このトピックは興味深いものですが、いくつかの単純だが重要なポイントが残っていました。 なんて残念。 誰が何を気にします-私は尋ねます。
icmpの些細な分析を破棄すると、マテリアルの最も興味深い部分は、ターゲット（Windows、おそらく）システムがicmp-echoリクエストに応答するという主張（スクリーンショットで確認）になります。 確かに、スクリーンショットとテキストの間に矛盾がありますが、これをタイプミスと見なし、写真に焦点を合わせます。
絵は本当に面白いです、特にそうすべきではないと考えるとき。 かつて、宿敵を通してそのようなことを甘やかしている間、私はWinにとってこの焦点が機能しないことを明確に理解していました。 さらに驚いたことに、作者はスクリーンショットを偽造しませんでした。
実験を繰り返すことにしました。 ユーティリティを使用せずにNixコンソールから任意のパッケージを生成する最も簡単な方法：
arp -s ip ff：ff：ff：ff：ff：ff
ping ip
検索されたIPが応答していません。 tcpdumpを使用して、目的のタイプのパケットがインターフェイスを離れることを確認します。
すぐに疑問が生じました。 それとも被害システムですか？ 私の場合、Win XP SP3でした。 トピックの著者は、彼もまた確認しました...それは面白くなりました。 RDP経由で利用可能なシステムを見つけました。 ブロードキャストdst macを使用したicmpリクエストが届くと確信しました。 答えはありません。
私はWin 2008で実験を繰り返しました-結果はポジティブです。 私の頭の中にはいくつかの理論がありました（それらはトピックへのコメントで表明されました）が、すべてがはるかに単純であることが判明しました。
まあ、もちろんそれはオハイオ州です！
次世代のTCP / IPスタック。
technet.microsoft.com/en-us/network/bb545475.aspx
実際、XPには当てはまらなかったことが、Vista 7,2008の現実となった
Googleは、「驚き」に驚いた同じ実験者を見つける手助けをしました。
www.packetstan.com/2010/08/windows-lan-addressing-validation-and.html
...
驚いたことに 、Windows 7ホストは、ICMPエコー応答でブロードキャストLANアドレスに送信されたユニキャストエコー要求に応答します。
blog.taddong.com/2010/09/more-wpa2-hole-196-reflections-and.html
Joshは、 Windows Vistaおよび7はユニキャストIPアドレスに送信されたLANブロードキャストトラフィックを受け入れると述べました。 VMware Fusion 3.1.1（LAN）のWindows Vista SP2は、実際には、ブロードキャストおよびマルチキャストレイヤー2アドレスのICMP、TCP、またはUDPに対してこの種のトラフィックを受け入れることを確認しました。 最も驚くべき事実は、Windows Vistaおよび7がTCPブロードキャストトラフィックを受け入れることです。 新しいTCP / IPスタックの実装には、常に隠されたギフトを含めることができます！
Windows XP SP3（WLAN）は、使用されているレイヤー2アドレス、ブロードキャストまたはマルチキャストに関係なく、どのプロトコル（ICMP、TCPまたはUDP）でもそれを受け入れません。 それで、これはXPがVistaと7より「Hole 196に関してより安全 」であることを意味しますか？ ;）
彼らはここに何を書いていますか？ ブロードキャストMAC宛先を使用するTCPも機能しますか？ 確認してみましょう...繰り返しますが、手動でarpバンチを設定し、telnetでWin 2008のサーバーのオープン80ポートに設定します。 動作します。
23：53：53.179517 00：0c：29：22：71：6c> ff：ff：ff：ff：ff：ff 、ethertype IPv4（0x0800）、長さ74：10.xx.4.80.35261> 10.xx. 4.20.80：フラグ[S]、seq 759040421、win 5840、オプション[mss 1460、sackOK、TS val 2823711033 ecr 0、nop、wscale 7]、長さ0
23：53：53.180123 00：0c：29：81：23：05> 00：0c：29：22：71：6c、イーサタイプIPv4（0x0800）、長さ74：10.xx.4.20.80>10.xx。 4.80.35261：フラグ[S。]、seq 1483497967、ack 759040422、win 8192、オプション[mss 1460、nop、wscale 8、sackOK、TS val 64239843 ecr 2823711033]、長さ0
23：53：53.180405 00：0c：29：22：71：6c> ff：ff：ff：ff：ff：ff、 ethertype IPv4（0x0800）、長さ66：10.xx.4.80.35261> 10.xx. 4.20.80：フラグ[。]、Ack 1、勝利46、オプション[nop、nop、TS val 2823711033 ecr 64239843]、長さ0
そして他方では...まあ、それはうまくいくので、何ですか？ ところで、Linuxシステムを使用した同じ実験でも同じ結果が得られました。
しかし、白い斑点は少し少なくなりました。 誰にとってもそうですが、私にとっては悪くありません。 そして、はい、実験を促進しているトピックの著者に感謝します。
Ping-flooding攻撃：背後に残っているものまたは細心のメリット
All Articles