SYN Cookieを使用してDOS攻撃を実行する
私のソフトウェアセキュリティクラスでは、次の質問がありました。
あなたは、大規模なネットワーク（たとえば、64,000以上のIPアドレス）を所有するプロバイダーのシステム管理者です。 SYN Cookieを使用してWebサーバーにDOS攻撃を実行する方法を示します。
いたるところを検索したところ、DOS攻撃を防ぐためにSYN Cookieが使用されていることがわかりました。しかし、この質問は攻撃を実行するように言われました（私は教授と確認しました、それはタイプミスではありません）。誰かが私にいくつかの指針を示して、正しい方向に進むことができますか？
「インターネット」が知る限り、SYN Cookieによって有効化される特定の攻撃ベクトルはありません。私が考えることができる最高のものを以下に説明します：
最初に、SYN Cookieについて説明します（詳細が重要です）。 SYN cookie は SYNフラッド 攻撃を緩和する方法です。
SYNフラッドの要点は、接続を開くためにstateを維持することは負荷が高いことです（どこかでRAMを使用するため）。SYNフラッドでは、攻撃者は状態を維持しない：彼はSYNを送信したがそれを忘れた;一方、サーバーはSYNを記憶している。
SYN cookieはサーバーのチートです：単にそれらも忘れてしまいます。代わりに、TCP SYNへの応答で送信するシーケンス番号（ACK + SYNパケット）で覚えるべきすべてのものをエンコードします。通常のクライアントがそれに応答すると、そのシーケンス番号を送信します。同じシーケンス番号（実際には1だけ増加）を持つ独自のACK。これにより、サーバーは覚えておく必要がなかったデータを回復できます。ATCPシーケンス番号は32ビットなので、サーバー32ビット内の「状態」に適合する必要があります。SYNCookieは、タイムスタンプに5ビット、MSSに3ビット、24ビットの「暗号関数の出力」を使用するように定義されています。これらの24ビットは、実際には [〜＃〜] mac [〜＃〜] サーバーのIPアドレス、クライアントのIPアドレス、両方のポート番号（サーバー側とクライアント側）、およびタイムスタンプで計算されます。
結果は、サーバーがのように見える ACK + SYN（Cookieを含むもの）への応答であるACKを受信した場合、サーバーmustを3番目の要素と見なします。 TCPハンドシェイクのようになり、完全に開いた接続にリソースを割り当てます。これは、Cookieの値が正しい場合にのみ発生します（サーバーが再計算したときに、送信された値と一致します） ACK）。攻撃者は現在の時刻を知っており、MSS値の3ビットエンコーディングを推測/監視できるため、24ビットの不明ビットがあります。Cookie値が適切に計算されている場合（この場合、暗号化ハッシュまたは同等のもの） ）の場合、攻撃者は正しいCookie値にヒットする確率が1600万分の1（正確には16777216）になり、これにより攻撃者の可能性が大幅に制限されます。
SYN Cookie処理に関連するCPUコストについては、いくつかの議論がありました。基本的なCore2 x86 CPUが単一のコアを使用して、毎秒800万のMD5ハッシュを喜んで計算することを考慮してください。攻撃者がそのようにDoSを実行するのは困難です（そのサーバーに毎秒800万以上のパケットを送信する必要があります...）。
できることは次のとおりです：
- 攻撃者は通常のSYNを送信し、サーバーからACK + SYNを受信します。 ACK + SYNには、攻撃者が使用した送信元アドレスとポートの有効なCookieが含まれています。 Cookieは1分ほど有効です（タイムスタンプは通常64秒に1回変更されるため）。
- 攻撃者は同じ送信元アドレスとポートを使用して繰り返し送信しますtwoパケット：
- 上記で取得したACKとCookie、および有効なHTTPリクエストをエンコードするいくつかの適用可能なデータ（「プッシュ」）を含むパケット。
- rSTを行う2番目のパケット。
最初のパケットを受信すると、サーバーはそれがTCPハンドシェイクの有効な3番目のパケットであると想定する必要があります。次に、データを読み取り、HTTP要求を処理します。HTTPサーバーソフトウェアが要求を考慮している間（そして、これがかなりのリソースを必要とする可能性があります。特に、リクエストがPOSTおよび/またはgzipでHTTPレベルの圧縮をリクエストする場合）、ターゲットカーネルはRSTを読み取り、ソケットをクローズと見なします- HTTPサーバーは、HTTP応答を送信しようとすると（ただし、その前にではなく）、書き込みエラーを受け取ります。
接続が閉じているため、送信元アドレス+ポートは再び「空き」と見なされ、クライアントからの次のACK +プッシュも同様に行われます。
64000のIPアドレスは、攻撃者が「レーダーの下を飛ぶ」ための方法としてここに来ます。単一のIPアドレスからの接続の繰り返しは、適切なファイアウォールによって検出され、早い段階で（ターゲットWebサーバーに到達する前に）ブロックされる可能性があります。悪意のある管理者は64000のアドレスを「所有」しているため、任意の64000アドレスからの接続をシミュレートできます。攻撃者は最初のSYNを使用してCookieを取得し、そのアドレスから100個程度のACK + Push、RSTペアを送信します。効果を上げるために、彼は一度に100のアドレスでそれを行い、定期的に新しいアドレスを取得しました。彼は64000個のアドレスを操作するため、アドレスを再利用するまでに少し時間がかかります。
そのシナリオでは、SYN Cookieを使用しない同じ設定と比較した場合、SYN Cookieは次の深刻な影響を及ぼします。これにより、攻撃者はほとんどの場合ACK + SYNを待たなくて済みます。これにより、DoSに対する従来の対策の1つが無効になります。つまり、SYNに応答するときに少しのレイテンシが追加されます。
これはまだ納得できません。ここでのSYN Cookieは、攻撃者の能力を大幅に増大させるものではありません。アドレスが64000の場合、攻撃者はSYN Cookieの有無にかかわらず、100万の接続（またはサーバーの観点から見たところ少なくとも開いているように見える）の接続を維持でき、Webサーバーが抵抗することはありませんthat。
SYN Cookieは、メモリとCPUの間のトレードオフです。それらを使用するときに使用するメモリが少ないので、シーケンス番号で使用する値を計算するためにより多くのCPUを使用しています。悪用される可能性のある実装バグがない限り、どのDOSでもこれに焦点を当てると思います。
ネットワークのサイズについての言及は、彼がSYNCookiesの基本的な制限を利用することを望んでいることを示唆しています。 65,536個のIPアドレス（/ 16個のIP範囲）は、利用可能なTCPポートの数と一致しますが、そこに悪用可能なものがあるかどうかを知るためのSYNCookiesの詳細についてはよく知りません。
余談ですが、SYNフラッドは通常、スプーフィングされた送信元アドレスを使用して行われます。なぜなら、あなたは気にせず、実際には応答を望まないからです。したがって、DDoS試行で65,536以上のIPアドレスを使用するために、実際に/ 16を制御する必要はありません。/16もファイアウォールでブロックするのが非常に簡単で、そのほとんどがDDoSの試みに関連しているかどうかを非常に簡単に識別できます。
克服しなければならない最初の課題は、ターゲットをsyn-cookieモードにすることです。 syn-cookiesがオンになっている（そして、少なくとも一部のディストリビューションではデフォルトがオフになっている）場合でも、TCPキューの長さを超えている必要があります。これがwosは、syn-cookieがない場合にDoSを引き起こします。これには、最初に大量のSYNトラフィックを送信する必要があります。
調べてみる ウィキペディアの説明 サーバーはIPアドレスとポートを介して暗号関数を計算する必要があり、この関数の戻り値は24ビットの長さでなければなりません。 IPアドレスは32ビットで、ポートは16ビットであるため、衝突が発生する必要があります。 （つまり、2つの異なるIPアドレスとポートの組み合わせは同じ値を返します。）16ビットに相当するIPアドレス空間（最初の16ビットは同じ）を制御し、16ビットのソースポートを使用できる場合、すべてを生成できるはずです。シーケンス番号に含めることができる暗号関数の値。これを1秒以内に実行できる場合は、サーバーがそのタイムスタンプのすべての可能なSyn-Cookieを送信したことを意味します。
衝突があったとしても、それがDoSを引き起こすとは思いません。 DoS試行の一部であった別の接続と衝突した場合でも、正当な接続には、最終的なACKに有効なシーケンス番号が含まれます。
悪用される可能性があると私が見ることができる他の唯一の部分は、最大セグメントサイズです。これは、サーバーが8つの異なる値しか選択できないことを意味するために、3ビットしか設定されていません。サーバーに8つ以上の個別の値を選択するように強制できる場合、既存のリストにないMSS値を必要とする新しい接続がドロップされる可能性があります。これは、実装に依存し、syn-cookiesがどのように機能するかについて基本的なことは何もありません。
結局、私が見ることができる唯一のことは、それらすべての暗号化操作を行わなければならないことによって引き起こされる余分なCPUです。
従来、SYN DOSはSYN ... SYN ... SYN ... SYN ...を送信することで実行されます。
一般的なTCP使用パターンは、SYNを送信し、SYN/ACKを待機してからACKを送信することです。したがって、サーバーがSYNを受信すると、SYN/ACKを送信してACKを待機します。しかし、攻撃された場合はSYN/ACKを破棄し、さらにSYNを送信するだけです。サーバーはSYN/ACKで忠実に応答しますが、そのバッファーは開いている待機中の接続で徐々に満たされます。最後に、バッファーがいっぱいになり、接続は受け入れられなくなります。サーバーが使用できなくなります。
さらに良いことに、攻撃者はその送信元アドレスを偽装しているため、すべてのSYNが異なるアドレスから送信されているように見えます。 SYN/ACKもランダムなアドレスに送信されます（サーバーは無許可のSYN/ACKパケットを破棄します）。
少し広い範囲の検索で、私はこれを見つけました： http://tools.ietf.org/html/rfc4987 -SYN Floodsの説明です。