TCPシーケンス予測と最新のシステム/ネットワークでの卓越性
TCPシーケンス予測の経験について質問があります。誰かが手伝ってくれることを期待しています。
TCP Sequence Predictionの仕組みと、攻撃者がシーケンス番号を予測して偽のパケットを準備するなどして接続をハイジャックする方法を知っていますが、この時代の「現実の」環境でのこの種の攻撃はどの程度顕著であるか、またはそれが現代のシステム/ネットワークではもはや問題ではなくなったためファイアウォールルール、シーケンス番号のより安全な生成、macフィルタリングなどの対策の認識と実装？
あなたの助けは大いに感謝されます、ありがとう
TCPシーケンスの予測は2001年頃に話題になりましたが、ほとんどのベンダーはその頃にOSにパッチを当てています。 2001年9月の this CERT advisory を参照してください。さまざまなベンダーの声明が含まれています。基本的に、TCPシーケンス予測攻撃がシステムに対して機能する場合、そのシステムは10年以上のセキュリティ修正で更新されていません。これは、ほぼ確実に、はるかに大きなセキュリティ問題があることを意味します。
予測できないシーケンス番号を生成するために、実装は RFC 6528 で説明されている手法に従うことをお勧めします（これは古い RFC 1948 に取って代わります）。これはカスタムですPRNG MD5を使用しています。暗号学的に言えば、このPRNGややこしい：疑わしい堅牢性のハッシュ関数を使用する以外に、それも "間違っています"（これは Merkle-Damgård 構成です。キーを既知の入力と単純に連結する場合は注意が必要です。 [〜＃〜] hmac [〜＃〜] は代わりに、ビルディングエレメントとして使用されます）。全体的なスキームはそれほど高速ではありません（ 優れたストリーム暗号 のほうがはるかに優れています）。ただし、速度はそれほど重要な問題ではありません（ローエンドシステム）それでも、そのアルゴリズムミリオンを1秒あたり数回計算できます。着信SYN要求の処理はボトルネックであり、ハッシュではありません）本当に高い暗号強度は必要ありません、攻撃者は確率で「運がよければ」2-32とにかく、PRNGはそれ以上である必要はありません（暗号化アルゴリズムの一般的な目標は2です）-80 以下）。
概要：TCPシーケンス予測攻撃は過去のものです。知っておくと便利ですが、過去10年ほど維持されています。
個人的には、この脆弱性が存在する最新のシステムをまだ見つけていません。
すべてではないにしても、最新のオペレーティングシステムの多くは、 RFC 1948 によって提案されている予測不可能な初期シーケンス番号を使用するように修正されています。 RFC 1948は、ユーザーが定義したシーケンス番号攻撃を防ぐために特別に設計されました。これは元々2000年代の初めの問題であり、その結果、ほとんどの新しい開発にはリリース前にパッチが適用されています。
NmapはTCPシーケンス情報を提供し、システムがTCPシーケンス予測することがどれほど難しいかについて、経験に基づいた推測を行います。
これまでに、私が個人的にテストしたすべてのライブシステム（Windows 95またはNTマシンではない）は、Nmapによって「幸運」（「不可能」）と定義されています。
D3C4FFの答えに加えて、2番目のケースはもちろん次のとおりです。
エンドポイントの1つと同じサブネットにいる場合は、既存のTCPシーケンス番号を予測することによりストリームにストリームを送信します。
もちろんこれは、攻撃者が既存のTCPストリームで使用されているシーケンス番号を見ることができるという事実に依存します-これは初期シーケンス番号の予測についてではありません。
私は個人的にTCPこのスタイルでRSTインジェクションを使用して、ハウスメイトの音量を下げることを拒否した後、ハウスメイトのインターネットラジオをオフにしました。
この方法が広く普及していることについては、マルウェアの作者が利用できる攻撃の1つにすぎません。ルートキットを作成していて、内部ネットワークに大混乱をもたらしたい場合、TCPシーケンス予測は、私が検討する可能性のあるツールの非常に長いリストの1つにすぎません。