はじめに
クラウド環境においてサーバを運用するにあたり、ネットワークの料金に関して、インバウンドの通信は基本的に無料であるものの、アウトバウンドについては有料となる料金モデルが一般的です。
Webサーバをインターネットで公開する場合、正規ユーザーの通信に加え、世界中のボットなどから大量の接続試行を受けることになります。
SYNフラッド攻撃を受けると、攻撃者が多数のSYNパケットを送信し、TCPの3ウェイ・ハンドシェイクを完了させないため、WebサーバはSYN-ACKを送信及び再送し続けることになります。そのため、このSYN-ACKの送信及び再送はアウトバウンド通信として課金対象となり、攻撃の規模や継続時間によっては意図しないネットワークコストの増加を招く結果になります。
本記事はサーバのセキュリティ対策として、SYNフラッド攻撃対策をテーマに、接続確立前の段階で通信を制御することで、不要なSYN-ACKの送信を抑制し、結果としてネットワークに関するアウトバウンドのコストを抑制する方法について記載しています。
背景
筆者は数年前からGoogle CloudのCompute Engineを用いて、Webサーバを運用しています。
基本的に無料枠内で使用しているため、料金は発生していませんでした。しかし、2025年は「5分で理解するfail2ban」の記事に書いている通りに海外からの大量のアクセスによって、アウトバウンドのデータ量が無料枠を超える意図しない料金が発生しました。
その後、fail2ban導入以降はまた無料枠内での利用が続いていましたが、2025年11月の利用分について、またしても意図しない料金が発生しました。
確認したところ、これまでと同じくVM インスタンスからの下りネットワークの通信が原因であり、アウトバウンドのデータ量が無料枠である1GBを超えたためです。
以下は2025年11月分のレポートより、SKU ID：03A5-1B2A-3485（Network Internet Data Transfer Out from Americas to South America）でフィルタしたものですが、11月の後半頃からコストが発生してました。
SYNフラッド攻撃対策
予算アラートを設定していたため、料金の発生はすぐに気づくことができました。
調査
Nginxのアクセスログを確認したところ、出力されたログについてアクセスが普段より多いなどの異常は確認できませんでした。
そこで、ssコマンドを実行して通信状況を確認したところ、以下のようなState列がSYN-RECVとなっている通信の存在が大量に確認できしました。
- 出力例
SYN-RECV 0 0 <Local IP>:443 <REDACTED>.51.45:26268
SYN-RECV 0 0 <Local IP>:443 <REDACTED>.61.24:53677
SYN-RECV 0 0 <Local IP>:443 <REDACTED>.53.8:8394
SYN-RECV 0 0 <Local IP>:443 <REDACTED>.50.54:27168
SYN-RECV 0 0 <Local IP>:443 <REDACTED>.51.13:8636
SYN-RECV 0 0 <Local IP>:443 <REDACTED>.56.201:14024
SYN-RECV 0 0 <Local IP>:443 <REDACTED>.57.37:56274
SYN-RECV 0 0 <Local IP>:443 <REDACTED>.54.9:60691
SYN-RECV 0 0 <Local IP>:443 <REDACTED>.54.102:45973
SYN-RECV 0 0 <Local IP>:443 <REDACTED>.59.252:11163
...
また、これらの通信の多くは、ブラジルを送信元とするIPアドレスから発生していて、同一送信元から40以上の接続試行が確認できました。
上記を踏まえて、SYNフラッド攻撃と判断し、対応を検討しました。
SYNフラッド攻撃は、多くの場合、送信元IPアドレスが偽装されています。また、サーバは接続要求を行っているクライアントに対してTCPのSYN-ACKパケットを返送し、その後クライアントからのACKパケットを受信するまで、SYN-RECV状態として接続情報を保持したまま待機します。この状態ではTCP接続は確立しておらず、いわゆるハーフオープンな状態となります。
このような半開接続が大量に発生すると、TCPスタックで管理するSYN backlogが上限に達し、新たな接続要求を正常に処理できなくなるため、サーバは正規ユーザーからの通信に対しても応答できなくなります。
対策
SYNフラッド攻撃に関する基本的な対策は、SYN cookiesの有効化やSYN backlogの値を増やすことですが、通信の制御については考慮が必要です。
例えば、fail2banは出力されたログの内容を基に動作するため、コネクションが確立されていない通信については、機能しません。
従ってカーネルのネットワーク機能を用いて通信を制御し、不審な新規接続試行を早い段階で抑制します。具体的には、iptablesやnftablesによって新規SYNパケットの送信レートを制限し、あわせてTCPスタックのSYN-RECV状態の再送回数を調整することで、不要な通信やリソース消費を最小限に抑えます。
新しい接続試行のレートを制御するためには、以下のコマンドを実行します。（※バーストの値は環境に合わせて設定）
$ sudo iptables -A INPUT -p tcp --syn -m limit --limit 10/s --limit-burst 20 -j ACCEPT
$ sudo iptables -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j DROP
OS再起動後も同じ設定を適用させたい場合は、以下の設定ファイルを編集します。
- /etc/iptables/rules.v4
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 10/sec --limit-burst 20 -j ACCEPT
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j DROP
カーネルパラメータのnet.ipv4.tcp_synack_retriesは、サーバ側でACKメッセージを受信しないときに、SYN-ACKメッセージを送信する再試行の回数です。
デフォルト値は5で設定されていますが、チューニングすることで、このようなSYN-ACKの再送に関する通信を抑制します。
$ sudo sysctl -w net.ipv4.tcp_synack_retries=2
OS再起動後も同じ設定を適用させたい場合は、以下の設定ファイルを編集します。
/etc/sysctl.conf
net.ipv4.tcp_synack_retries = 2
おわりに
本記事で記載している対策を実施した結果、SYNフラッド攻撃そのものは引き続き観測されているものの、接続確立前の段階で不要な通信を抑制できるようになったため、ネットワークのコストを抑えることに成功し、またクラウドの無料枠内での運用を継続できています。
なお、対策としてVPC のファイアウォール機能を使用して、送信元IPアドレスをブロックする方法も考えられますが、SYNフラッド攻撃では送信元IPアドレスが偽装されているケースが多く、個別のIPアドレスをブロックしてもその効果は短期的です。