【まとめ】SYNフラッド (Flood) 攻撃とSYN Cookie
趣旨
SYNフラッド攻撃について、その概要と対策をまとめています。
Linuxを想定しておりますが、他のシステムでも大体似たような仕組みになっておりますので、参考になるかと思います。
1.前提解説
本題に入る前に、TCPと3wayハンドシェイクについて解説します。
既に理解されている方は飛ばしていただいて構いません。
1-1.TCPとは?
TCPは、IPの上位層であるトランスポート層で動作するプロトコルです。IPアドレスでのやり取りからHTTP,FTPなどのアプリケーション層(OSI参照モデルではセッション層以上)でのやり取りへ橋渡しする役割を持ちます。
その橋渡しの目印として、ポート番号を用います。
ポート番号とは、各アプリケーションごとに割り当てられている番号です。
マンション同士の郵便配達を例にとれば、IPアドレスは建物の住所、ポート番号はその建物内の部屋番号を示しています。
TCPは、この部屋番号へデータ(郵便)を届け、アプリケーション層にバトンタッチするためのプロトコルということになります。
もう少し詳しく知りたい方は下記のリンクが参考になるかと思います。
TCP/IPとは?通信プロトコルの階層モデルを図解で解説
1-2. 3wayハンドシェイクとは?
TCPでは、データ転送の通信の前に、3wayハンドシェイクという通信を行います。
相手と正常に通信できるか確認し、コネクションを築いたうえでデータを転送することで、通信の信頼性が担保されます。
流れは下図の通りです。
通信が3回発生することから、3wayハンドシェイクと呼ばれます。
SYN,ACKはフラグと呼ばれるもので、TCPで転送される前にデータのヘッダ部分(TCPヘッダ)へ差し込まれます。
SYNが通信の開始を示し、ACKが応答を示します。
有効の場合は1、無効は0です。
サインのようなものと理解していただくと分かりやすいかと思います。
ノード内部の動きも見てみましょう。
PC-2は、Linuxで動いている想定です。
①の情報を受け取ったPC-2は、SYN-Backlogという記憶領域に一時的に保存しておきます。
③の応答を受け取ってコネクションが確立すると、SYN-BacklogからTCP Backlogへ移行します。
以上が、前提解説です。
2. SYNフラッド攻撃とは?
さて本題です。
SYNフラッド(Flood)攻撃とは、上記の3wayハンドシェイクを悪用したDDos攻撃の一種です。
DDos攻撃とは、ある特定のノードに対し、複数のノードから大量のデータ・通信等を送りつけることで、ノード内の記憶領域を圧迫させ、正常な運用を妨げるサイバー攻撃です。
SYNフラッド攻撃では、まず攻撃対象のノードに対し、「SYNパケットの送信 ⇒ 未応答」を大量に繰り返します。
厳密に言うと、攻撃者側はIPを偽装している場合が多いため、SYN+ACKパケットすら受信しません。
相手からの応答を待っている状態はHalf-Open状態と呼ばれ、情報はSYN-Backlogに保持されたままです。
攻撃者からの応答を待っているうちに、SYN-Backlogの容量が圧迫されていき、結果的に正規のクライアントと通信ができなくなってしまいます。
図解します。
まず以下のやり取りが繰り返されます。
①の通信で得た攻撃者の情報は、Half-Open状態のため、SYN-Backlogに格納されたままです。
やがてSYN-Backlogの容量が圧迫され、正規クライアント(PC-1)とのやり取りができなくなります。
3. SYNフラッド攻撃は身近なもの
他のサイバー攻撃と比べ、SYNフラッド攻撃の件数は非常に多いようです。
CDNetworksが2018年に発表したレポートでは、DDos攻撃の中で一番多く、全体の42%を占めたと報告しています。
最多のDDoS攻撃は「SYNフラッド」、CDNetworksが2018年第1四半期の動向を発表
また、AWSが2020年に行った調査「AWS Shield 脅威ランドスケープレビュー : 2020 年の振り返り」では、SYNフラッド攻撃をはじめとするトランスポート層でのDDos攻撃数が、アプリケーション層での件数を上回ったと報告しています。
そのトランスポート層でのDDos攻撃のうち、SYNフラッド攻撃は2番目に多く、13.8% を占めています。
上記の調査から、SYNフラッド攻撃は、他のDDos攻撃と比べ、対策が急務であることが分かります。
SYN Cookieとは?
SYNフラッド攻撃の対策として様々な機能が挙げられますが、最もメジャーなのがSYN Cookieです。
SYN Cookieとは、SYNパケットで得た情報をハッシュ化し、SYN+ACKパケットのシーケンス番号に含めることで、正規クライアントのみに記憶領域を割り当てる機能です。
正常な稼働が不可能になる直接的な要因は、SYN-Backlogが圧迫されてしまうことでした。
つまり、攻撃を受けてもSYN-Backlogが圧迫されなければ、正常な稼働は可能であるわけです。
※ 帯域等は一旦度外視しています。
そこで考えられたのが、SYN-Cookieです。
SYNパケットを受信した場合、通常はSYN-Backlogへ格納しますが、SYN-Cookieでは行いません。
代わりに、SYNパケットの情報をハッシュ化して、SYN+ACKパケットのシーケンス番号に割り当てます。確認応答番号には、このシーケンス番号を流用(※)するよう設定します。
※ ハッシュ値は時間経過で変わるため、実際に送られてくるのは、元の値の近似値です。
ACKパケットが送信されてきたら、シーケンス番号からハッシュ値を解読し、正しい応答通信であることを確認して、初めて記憶領域(TCP-Backlog)に割り当てます。
上記にも記載した通り、攻撃者はIPを偽装している場合が多いため、SYN+ACKパケットを受信せず、ACKパケットを送信することができません。
よって、記憶領域で保持・圧迫されることなく、正常な稼働を維持することができます。
図解すると以下の通りです。
まず正規クライアントとのやり取りです。
ACKパケットを受信してから、記憶領域に割り当てます。
次に攻撃者とのやり取りです。
ACKパケットを受信しないため、記憶領域に割り当てられません。
まとめ
以上が、SYNフラッド攻撃とSYN Cookieの紹介でした。
次の記事では、Linuxをはじめ、AWS,Cisco,F5などの各サービスの対策機能・設定方法を紹介しますので、こちらもぜひ読んでみてください。
【サービス別】SYNフラッド (Flood) 攻撃 対策機能
Discussion