How TCP/IP connections work
Transmission Control Protocol/Internet Protocol (TCP/IP) は、現代のコンピューターネットワークの要となる技術です。 コンピュータがネットワークやインターネットを介して情報を要求したり受信したりする方法です（ほとんどの場合）。 TCP/IPには、エラーチェックや、欠落・破損したデータの再送信など、文字通りインターネットの信頼性と機能性を高める重要な機能が備わっています。
簡潔にするために、TCP/IP の接続プロセス全体については説明しません。
簡潔にするために、TCP/IP の接続プロセス全体については説明しませんが、最初の TCP 3 者間ハンドシェイク プロセスだけに焦点を当てます（これがこの記事の主題に関連するすべてです）。 ここで、TCP の 3 者間ハンドシェイクが登場します。 ハンドシェイクのプロセスにより、両ホストはネットワーク通信の送受信が正常に行われたことを確認し、アプリケーションデータの交換を想定してそれぞれのセッションを設定します。
図1）TCP 3ウェイハンドシェイク
図1では、クライアントがサーバーへのTCP接続を確立しています。 最初のステップは、クライアントがSYNパケットを送信することです。 このパケットには主に2つの役割があり、1つ目はリモートリソースに到達する能力をテストすることです。 このパケットが正常にルーティングされた場合、リモートクライアントがデータ交換のための接続ネゴシエーションプロセスを開始したいことをサーバーに伝えます。 サーバーは、SYN-ACK（Synchronization and Acknowledgment）パケットを発行して、接続を開始しているクライアントに返信します。 3ウェイハンドシェイクの最後の部分は、クライアントがSYN-ACKに対して最終的な確認応答（ACK）パケットで応答することです。
TCP通信を伝送する最も一般的な方法は、インターネット・プロトコル（IP）上で行われます。
この攻撃の仕組み
攻撃者は、SYNパケットのソースIPアドレスを偽装することで、このハンドシェークプロセスを武器にします。 このスプーフィングにより、サーバーはSYN-ACKパケットを犠牲者のIPに送信します。犠牲者のIPは、サーバーがセッションの初期化を要求したと信じ、リフレクターとして機能します。
図2）SYN-ACKの反射
図2では、この攻撃を非常にシンプルに視覚化しています。 しかし、これでは実際の攻撃シナリオがどのようなものかわかりません。 現実には、TCPは信頼性の低いネットワーク上で動作するように設計されています。つまり、たった1回のなりすましSYNがきっかけで、ハンドシェイクの最終ACKを受信しなかった場合、サーバーは複数のSYN-ACKを連続して送信することになります。 送信するSYN-ACKの数とその速さは設定可能な指標であるため、攻撃者が送信した偽装SYNパケットの量に関連して、標的となる被害者が受け取るSYN-ACKの数を正確に見積もることは困難です。
低帯域 vs 高PPS
SYN-ACK攻撃は、典型的なリフレクション攻撃ではありません。 UDP ベースのリフレクション攻撃の主な魅力の 1 つは、増幅率、つまり、攻撃者が送信しなければならないパケットのサイズに対して、被害者に到着するパケットのサイズです。 多くの場合、増幅率は元のリクエストの何倍にもなります。 例えば、CLDAPリフレクションの場合、結果として得られるパケットは、リフレクションを引き起こすために攻撃者が送信しなければならないパケットの約50〜70倍になります。
SYN-ACK リフレクションの場合、被害者に配信されるパケットのサイズは、攻撃者が送信したパケットとほぼ同じサイズになります。 ほぼ同じサイズ」というのは、攻撃者が最小限の長さのSYNパケットを送信している間に、攻撃者と被害者の間のネットワーク上のいくつかのルーターが、TCPパケットを修正して、最大セグメントサイズ（MSS）TCPオプションのような追加のリンク情報を追加し、被害者が観測するトラフィックの絶対的なサイズを大きくしている可能性があり、非常に高いからです。 このオプションでは、攻撃者が送信したものと比較して、パケットあたり4バイトが追加されます。
20:56:32.296905 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0xfa7c (correct), seq 1000, win 8192, urg 0, length 0
20:56:32.315637 IP (tos 0x0, ttl 124, id 4894, offset 0, flags , proto TCP (6), length 44)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x6e18 (correct), seq 3609252029, ack 1001, win 60720,
options , length 0
図. 3) SYN-ACK 4バイト増幅
この攻撃が脅威ではないということではありません。 アカマイのお客様に対するいくつかの協調的な攻撃の中で、反射した SYN-ACK トラフィックを使用した高パケット/秒（PPS）のフラッドが複数回観測されました。
攻撃者がコントロールできること、できないこと
SYN-ACK 攻撃者は、リフレクターの TCP 設定や TCP 接続の処理方法に依存しています。 つまり、攻撃者が被害者に反映できる内容は限られています。 アカマイの研究者は、インターネット上のマシンで公開されているいくつかの TCP 対応サービスに対してテストを行い、どのような TCP フラグ & オプションの組み合わせが最もインパクトのある攻撃シナリオにつながるかを確認しました。
TCP オプションとパディングされた SYN-ACKs
攻撃者は SYN-ACK パケットの内容をコントロールすることはできません。 水増しされたSYNフラッドは何年も前から見られていますが、水増しされたSYN-ACKというアイデアは、私たちが期待するものではありません。 現実にSYN-ACK攻撃が行われたとき、被害者のネットワークに到着したパケットの長さは44バイトと予測できました。 前述したように、このことから、攻撃者はオプションのない40バイトのSYNパケットを送信していた可能性が高く、MSSオプションは転送中のオンパスネットワーク機器によって設定されている可能性が高いことがわかります。
テストは、異なるバリエーションの TCP オプションを使用して実施しました。
テストは、さまざまなバリエーションのTCPオプションを使用して行われました。テストの目的は、確実に使用でき、インターネット上でランダムに選ばれたサーバーからより大きなSYN-ACKレスポンスを得られるオプションを特定できるようにすることでした。 攻撃者が使用してSYN-ACKを大きくすることができるオプションは、Maximum Segment Size (MSS)、Timestamp (TS)、Selective ACK (SAckOK)、Window Scale (WScale)、& TCP Fast Open (TFO)クッキーです。
有効なオプションを使用するだけで、攻撃者は最小のSYNパケットと比較して、約62%多くの帯域幅を消費することができます(72バイト vs. 44バイト)。 これらのオプションを利用すると、ヘッダーは増幅率を低下させます (10% の増幅が 6-7% になります)。しかし、MSS オプションは攻撃者が送信するかどうかにかかわらず転送中に設定されるため、MSS オプションを省略するだけで増幅を実現することができます。
20:51:46.333671 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0x1212 (correct), seq 1000, win 8192, urg 0, options
, length 0
20:51:46.351665 IP (tos 0x0, ttl 124, id 51260, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x1f6c (correct), seq 3436032873, ack 1001, win
60192, options , length 0
図. 4) TFOによるSYN-ACKのパディング
テスト時には、TS、SAckOK、WSCaleを活用することができました。 & TFO TCPオプション（およびNOPパディング）を利用して68バイトのSYNパケットを発行し、72バイトのSYN-ACKレスポンスを被害者に配信することができました（図4参照）。 ホストがTFOをサポートしていない場合でも、攻撃者は56バイトのSYNパケットを発行して、60バイトのSYN-ACKを被害者のネットワークに送り込むことができます（図5参照）。
21:12:24.647377 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 56)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0xab5d (correct), seq 1000, win 8192, urg 0, options
, length 0
21:12:24.665340 IP (tos 0x0, ttl 124, id 46598, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xfec2 (correct), seq 1309850370, ack 1001, win 60192,
options , length 0
図. 5) SYN-ACK paddingマイナスTFO
SYN-ACK Amplification
SYN-ACK攻撃を使用してごくわずかな増幅が可能ですが、割り当てられているが占有されていないIPスペース（IPはルーティング可能だが、現在はマシンが配備されておらず、ネットワークトラフィックを処理していないことを意味する）をターゲットにすることで、この増幅率を高めることができます。
通常のマシンがリフレクターから状態外のSYN-ACKを受信すると、図6に示すようにRSTパケットで応答します。 このRSTパケットをリフレクターが受信すると、リフレクター上のTCPセッションがキルされます。
21:33:15.173204 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0xfa7b (correct), seq 1000, win 8192, urg 0, length 0
21:33:15.191517 IP (tos 0x0, ttl 124, id 46635, offset 0, flags , proto TCP (6), length 44)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0xb751 (correct), seq 1209013908, ack 1001, win
60720, options , length 0
21:33:15.191558 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
図. 6) out of state SYN-ACK triggers a RST response
このSYN-ACKパケットが、割り当てられているが占有されていないIPアドレスに向けられている場合、SYN-ACKはルーティングされますが（途中でネットワーク機器に影響を与えます）、RSTを発行する実在のマシンには到達しません。 このRSTパケットの欠如により、リフレクターはSYN-ACKの配信失敗を想定し、再送を試みます。
テストでは、再送の試みの数は、通常、SYNを送信するたびに被害者に送信されるSYN-ACKパケットが5～7個になります。 攻撃者が40バイトのSYNを送信したと仮定すると、5～7個の44バイトのSYN-ACKが被害者のネットワークを通過することが予想されます。 パケットを7個受信したという最悪のケースでは、40バイトのリクエストが308バイトのパケットを生成して被害者の境界に到着することになり、増幅率は770％になります。 TCP オプション ヘッダーを使用してより大きな SYN-ACK を生成すると、攻撃者はこの数字を 56 バイトにし、結果として 420 バイトのトラフィックが反映され、増幅率は 750% になります。
21:12:24.647377 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 56) x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0xab5d (correct), seq 1000, win 8192, urg 0, options , length 0 21:12:24.665340 IP (tos 0x0, ttl 124, id 46598, offset 0, flags , proto TCP (6), length 60) y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xfec2 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:24.965713 IP (tos 0x0, ttl 124, id 46784, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xfd96 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:26.965689 IP (tos 0x0, ttl 124, id 47738, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xf5c6 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:30.965750 IP (tos 0x0, ttl 124, id 49898, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xe626 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:38.965701 IP (tos 0x0, ttl 124, id 53757, offset 0, flags , proto TCP (6), length 60)
p
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xc6e6 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:54.965710 IP (tos 0x0, ttl 124, id 61887, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x8866 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
図7.
TFO, padding, and amplification
TCP Fast Open (TFO) は、テストで観察された興味深いエッジケースをカバーするために、ここではより詳細に説明しています。 TFO クッキーを使用すると、より大きな応答 (SYN-ACK ごとに 12 バイト追加) をトリガすることができます。しかし、TFO の実装には見落としがあるため、これらの対策によって増幅係数が変化し、異なるシナリオでは、TFO を使用した攻撃の方が望ましい場合があります。
TFO を有効にしたリフレクターを利用しようとする攻撃者は、特定の状況下でのみそれが有効であると考えるでしょう。その状況とは、生きているマシンによって処理されていない IP スペースがない場合、攻撃者が反射された SYN-ACK パケットを RST パケットで応答する実際のマシンに向けなければならない場合、犠牲者のマシンから RST 応答を受信するとリフレクターが SYN-ACK の送信を停止するため、TCP の再送増幅は本質的に無意味です。
この提案をさらに望ましくないものにするために、TFOを有効にしているホストは、最初に発行されたパケット以降の追加のSYN-ACKパケットに、TFOクッキー用の12バイトのヘッダーオプションを含めません。 つまり、このシナリオでの増幅は、72バイトのパケットが連続して被害者を襲うことではないということです。 実際のテストでは、最初のSYN-ACKは72バイトですが、その後の5～6回の再送試行では、このTCPオプションが省略され、60バイトのパケットになることが確認されています。 この場合、72バイトのパケットは432バイトの反射となります。基本的に、最初のパケットの12バイトの追加だけが、TFOクッキーオプションを除いた反射と比較して、唯一の利点となります。
20:51:46.333671 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0x1212 (correct), seq 1000, win 8192, urg 0, options , length 0
20:51:46.351665 IP (tos 0x0, ttl 124, id 51260, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x1f6c (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:51:46.651887 IP (tos 0x0, ttl 124, id 51447, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x6bb0 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:51:48.651862 IP (tos 0x0, ttl 124, id 52323, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x63e0 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:51:52.651854 IP (tos 0x0, ttl 124, id 54181, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x5440 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:52:00.651876 IP (tos 0x0, ttl 124, id 58527, offset 0, flags , proto TCP (6), length 60)
p
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x3500 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:52:16.651862 IP (tos 0x0, ttl 124, id 2147, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xf67f (correct), seq 3436032873, ack 1001, win 60192, options , length 0
図8. 8) 最初の応答の後のTFOクッキーの省略
TFOが有効なホストは、標的となっている被害者のマシンからRSTを受信すると、ハンドシェイククッキーの測定値をリセットします。
攻撃者からの68バイトのリクエストが、72バイトのSYN-ACKが被害者に到着し、その後、被害者からリフレクターへのRSTパケットが続くと仮定すると、増幅係数はわずか4バイトです。 これが継続的に起こると、攻撃者を介してリフレクターで開始されるTCPセッションは、常にTFOクッキーオプションである追加バイトを含むSYN-ACKパケットになります。
20:54:41.611605 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x8762 (correct), seq 1000, win 8192, urg 0, options , length 0
20:54:41.629518 IP (tos 0x0, ttl 124, id 14354, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0x6ade (correct), seq 3714341928, ack 1001, win 60192, options , length 0
20:54:41.629548 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
20:54:42.664171 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0xc1bd (correct), seq 1000, win 8192, urg 0, options , length 0
20:54:42.682391 IP (tos 0x0, ttl 124, id 15171, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0x6d0a (correct), seq 3730789605, ack 1001, win 60192, options , length 0
20:54:42.682440 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
20:54:43.781512 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x7dde (correct), seq 1000, win 8192, urg 0, options , length 0
iv
20:54:43.800464 IP (tos 0x0, ttl 124, id 15726, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0xf5fe (correct), seq 3748251272, ack 1001, win 60192, options , length 0
20:54:43.800534 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
図. 9) RST後のTFOクッキーのインクルード
Mitigation concerns
SYN-ACKリフレクションのミティゲーションは厄介で、慎重に行わなければなりません。 この種の攻撃を過剰に緩和して、実運用ネットワーク上の実際のクライアントやTCPセッションに自業自得のダメージを与えることは非常に簡単です。 これらの影響を受けたセッションは、接続性の問題、パフォーマンスの低下、ネットワーク上の正当なホストやユーザーの遮断などにつながります。
多くの場合、TCP に影響を与える攻撃に対する過剰な緩和策は、被害者にとっても予想外の結果をもたらします。 例えば、SYNフラッドの場合、実際のサービスが接続性の問題を抱え始めると、ネットワーク全体に二次的な攻撃の波が押し寄せてくるように見えることがよくあります。 このような場合、「第二の波」は実際にはなく、一般的には実際のクライアント/ユーザーが正当な接続を確立しようとして失敗した結果です。これは、影響を受けたクライアントが確認できない SYN パケットの再送信を試み続けるため、通常よりも高い SYN パケットのうねりとなります。
SYN-ACK 攻撃の過剰な緩和は、特に実際のクライアントが正当な送信要求を行っているネットワークのポイントで緩和が行われている場合、問題や同様の結果を引き起こす可能性があります。 この問題やなりすまし機能に関連するその他の問題に実際に対処するには、IETF とネットワーク オペレータに目を向ける必要があります。 IETFはBCP38を公開しており、ネットワーク事業者がどのようにしてなりすましトラフィックのルーティングを識別し、防止するかを説明しています。
最後のまとめ
反射型 SYN-ACK 攻撃は新しいものではなく、実際には TCP 自体と同じくらい古いものです。 人気がないのは、他の UDP ベースの反射攻撃の方がはるかに厄介で影響力があり、一般的に攻撃者にとって優れたツールセットであることと関係があります。
とはいえ、古い攻撃はまだ痛みを伴うことがあり、反射型SYN-ACKも例外ではありません。
このような性質の攻撃に対する過剰な緩和の現実的な可能性を強調し、これらのタイプの攻撃に対抗する試みが、自ら招いた停止にならないようにすることが重要です……これは「言うは易く行うは難し」のタスクです。