Nginxとphp-fpmが高負荷で失敗する：「ポート80でSYNフラッドが発生する可能性があります」および「104：ピアによって接続がリセットされました」

Question

私は非常に重い負荷のウェブサーバーを使用しています：

Ubuntu server nginx php-fpm + apc

昨日、私のサーバーで何か奇妙なことが起こりました。クラッシュして応答を停止し、再起動した後、Webページの読み込みが非常に遅くなり、ほとんどの場合「リクエストがタイムアウト」しました。

確認しました/var/log/syslogそして次のようなメッセージをたくさん見ました：TCP: Possible SYN flooding on port 80. Sending cookies.

ページのローカル読み込みには約2分かかります。

time wget -O /dev/null mysite.net --2012-12-21 13:17:15-- http://mysite.net/ Resolving ficbook.net... 85.254.49.180 Connecting to mysite.net|85.254.49.180|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1311 (1.3K) [text/html] Saving to: `/dev/null' 100%[========================================================================================================>] 1,311 --.-K/s in 0s 2012-12-21 13:19:18 (181 MB/s) - `/dev/null' saved [1311/1311] real 2m2.438s user 0m0.000s sys 0m0.000s

それが本当にSYNフラッド攻撃であるかどうかは私にはわかりません。もしそうなら、なぜクッキーが役に立たないのですか？ netstatからの情報は次のとおりです。

netstat -tuna | grep :80 | grep SYN_RECV tcp 0 0 85.254.49.180:80 92.37.173.66:3214 SYN_RECV tcp 0 0 85.254.49.180:80 81.26.91.4:49471 SYN_RECV tcp 0 0 85.254.49.180:80 62.122.51.139:4940 SYN_RECV tcp 0 0 85.254.49.180:80 213.87.140.242:23259 SYN_RECV tcp 0 0 85.254.49.180:80 94.139.229.219:49827 SYN_RECV tcp 0 0 85.254.49.180:80 95.67.233.125:51267 SYN_RECV tcp 0 0 85.254.49.180:80 83.149.2.69:7051 SYN_RECV tcp 0 0 85.254.49.180:80 95.67.239.40:54497 SYN_RECV tcp 0 0 85.254.49.180:80 195.91.229.193:58981 SYN_RECV tcp 0 0 85.254.49.180:80 62.122.51.139:4925 SYN_RECV tcp 0 0 85.254.49.180:80 88.154.3.228:59086 SYN_RECV tcp 0 0 85.254.49.180:80 92.113.26.124:3887 SYN_RECV tcp 0 0 85.254.49.180:80 77.34.83.254:26963 SYN_RECV tcp 0 0 85.254.49.180:80 195.208.64.130:3542 SYN_RECV tcp 0 0 85.254.49.180:80 81.26.91.4:49480 SYN_RECV tcp 0 0 85.254.49.180:80 87.253.29.234:53130 SYN_RECV tcp 0 0 85.254.49.180:80 62.122.51.139:4939 SYN_RECV tcp 0 0 85.254.49.180:80 88.154.3.228:41696 SYN_RECV tcp 0 0 85.254.49.180:80 178.45.39.169:41758 SYN_RECV tcp 0 0 85.254.49.180:80 217.118.66.37:51534 SYN_RECV tcp 0 0 85.254.49.180:80 83.149.9.197:8249 SYN_RECV tcp 0 0 85.254.49.180:80 37.29.88.202:3531 SYN_RECV tcp 0 0 85.254.49.180:80 178.34.206.52:3409 SYN_RECV tcp 0 0 85.254.49.180:80 193.188.254.93:50317 SYN_RECV tcp 0 0 85.254.49.180:80 217.66.152.162:8883 SYN_RECV tcp 0 0 85.254.49.180:80 109.198.235.10:56382 SYN_RECV tcp 0 0 85.254.49.180:80 95.53.159.39:2256 SYN_RECV tcp 0 0 85.254.49.180:80 188.232.13.175:49819 SYN_RECV tcp 0 0 85.254.49.180:80 88.203.2.27:64080 SYN_RECV tcp 0 0 85.254.49.180:80 217.118.64.52:12382 SYN_RECV tcp 0 0 85.254.49.180:80 92.124.76.189:3416 SYN_RECV tcp 0 0 85.254.49.180:80 37.29.88.202:30532 SYN_RECV tcp 0 0 85.254.49.180:80 87.253.29.234:53131 SYN_RECV tcp 0 0 85.254.49.180:80 213.87.123.1:44943 SYN_RECV tcp 0 0 85.254.49.180:80 176.51.255.3:1642 SYN_RECV tcp 0 0 85.254.49.180:80 85.26.165.112:56906 SYN_RECV tcp 0 0 85.254.49.180:80 88.203.2.27:64081 SYN_RECV tcp 0 0 85.254.49.180:80 217.118.66.37:51533 SYN_RECV tcp 0 0 85.254.49.180:80 176.51.211.131:1699 SYN_RECV tcp 0 0 85.254.49.180:80 37.29.88.202:22233 SYN_RECV tcp 0 0 85.254.49.180:80 211.167.112.18:58353 SYN_RECV tcp 0 0 85.254.49.180:80 217.118.66.32:38640 SYN_RECV tcp 0 0 85.254.49.180:80 217.144.185.150:64421 SYN_RECV tcp 0 0 85.254.49.180:80 62.122.51.139:4928 SYN_RECV tcp 0 0 85.254.49.180:80 62.122.51.139:4927 SYN_RECV tcp 0 0 85.254.49.180:80 94.153.254.218:1084 SYN_RECV tcp 0 0 85.254.49.180:80 37.29.88.202:30384 SYN_RECV tcp 0 0 85.254.49.180:80 46.201.3.189:51032 SYN_RECV tcp 0 0 85.254.49.180:80 109.187.107.41:50565 SYN_RECV tcp 0 0 85.254.49.180:80 91.146.60.86:49266 SYN_RECV tcp 0 0 85.254.49.180:80 87.253.29.234:53134 SYN_RECV tcp 0 0 85.254.49.180:80 80.83.238.25:2515 SYN_RECV tcp 0 0 85.254.49.180:80 176.102.16.8:54291 SYN_RECV tcp 0 0 85.254.49.180:80 62.122.51.139:4918 SYN_RECV tcp 0 0 85.254.49.180:80 95.153.164.165:26752 SYN_RECV tcp 0 0 85.254.49.180:80 80.83.239.76:46519 SYN_RECV tcp 0 0 85.254.49.180:80 94.139.229.219:49826 SYN_RECV tcp 0 0 85.254.49.180:80 188.239.193.48:49418 SYN_RECV tcp 0 0 85.254.49.180:80 62.122.51.139:4919 SYN_RECV tcp 0 0 85.254.49.180:80 217.118.66.32:38639 SYN_RECV tcp 0 0 85.254.49.180:80 95.67.233.125:51266 SYN_RECV tcp 0 0 85.254.49.180:80 85.26.235.172:59092 SYN_RECV tcp 0 0 85.254.49.180:80 213.87.136.21:44804 SYN_RECV tcp 0 0 85.254.49.180:80 95.109.193.247:1206 SYN_RECV tcp 0 0 85.254.49.180:80 217.112.11.130:2714 SYN_RECV tcp 0 0 85.254.49.180:80 62.122.51.139:4941 SYN_RECV tcp 0 0 85.254.49.180:80 88.154.3.228:52640 SYN_RECV tcp 0 0 85.254.49.180:80 37.79.93.27:64801 SYN_RECV tcp 0 0 85.254.49.180:80 91.203.96.76:45132 SYN_RECV tcp 0 0 85.254.49.180:80 80.83.238.25:2513 SYN_RECV tcp 0 0 85.254.49.180:80 85.26.235.172:60092 SYN_RECV tcp 0 0 85.254.49.180:80 188.239.193.48:49416 SYN_RECV tcp 0 0 85.254.49.180:80 178.130.42.68:60373 SYN_RECV tcp 0 0 85.254.49.180:80 80.239.243.181:58110 SYN_RECV tcp 0 0 85.254.49.180:80 87.253.29.234:53128 SYN_RECV tcp 0 0 85.254.49.180:80 83.149.9.197:18870 SYN_RECV tcp 0 0 85.254.49.180:80 88.154.3.228:53380 SYN_RECV tcp 0 0 85.254.49.180:80 88.135.63.40:58845 SYN_RECV tcp 0 0 85.254.49.180:80 80.239.243.110:52234 SYN_RECV tcp 0 0 85.254.49.180:80 46.201.3.189:51028 SYN_RECV tcp 0 0 85.254.49.180:80 88.154.3.228:53457 SYN_RECV tcp 0 0 85.254.49.180:80 85.235.176.138:12101 SYN_RECV tcp 0 0 85.254.49.180:80 109.187.107.41:50567 SYN_RECV tcp 0 0 85.254.49.180:80 83.149.48.29:4172 SYN_RECV tcp 0 0 85.254.49.180:80 188.232.13.175:49820 SYN_RECV tcp 0 0 85.254.49.180:80 37.29.88.202:6651 SYN_RECV tcp 0 0 85.254.49.180:80 91.198.143.6:45591 SYN_RECV tcp 0 0 85.254.49.180:80 85.235.176.138:50667 SYN_RECV tcp 0 0 85.254.49.180:80 176.209.98.72:53653 SYN_RECV tcp 0 0 85.254.49.180:80 80.83.239.71:49701 SYN_RECV tcp 0 0 85.254.49.180:80 188.232.13.175:49817 SYN_RECV tcp 0 0 85.254.49.180:80 188.239.193.48:49417 SYN_RECV tcp 0 0 85.254.49.180:80 88.154.3.228:54175 SYN_RECV tcp 0 0 85.254.49.180:80 61.147.79.111:51039 SYN_RECV tcp 0 0 85.254.49.180:80 88.154.3.228:58854 SYN_RECV tcp 0 0 85.254.49.180:80 87.253.29.234:53135 SYN_RECV tcp 0 0 85.254.49.180:80 62.122.51.139:4938 SYN_RECV tcp 0 0 85.254.49.180:80 62.122.51.139:4942 SYN_RECV tcp 0 0 85.254.49.180:80 176.209.98.72:53662 SYN_RECV tcp 0 0 85.254.49.180:80 2.74.51.158:1092 SYN_RECV tcp 0 0 85.254.49.180:80 213.87.140.242:48178 SYN_RECV tcp 0 0 85.254.49.180:80 213.87.129.42:29549 SYN_RECV tcp 0 0 85.254.49.180:80 37.29.88.202:28428 SYN_RECV tcp 0 0 85.254.49.180:80 85.26.235.172:50983 SYN_RECV tcp 0 0 85.254.49.180:80 217.118.64.52:12381 SYN_RECV tcp 0 0 85.254.49.180:80 85.26.235.172:55459 SYN_RECV tcp 0 0 85.254.49.180:80 84.244.12.209:64975 SYN_RECV tcp 0 0 85.254.49.180:80 83.149.2.121:10768 SYN_RECV tcp 0 0 85.254.49.180:80 84.240.248.206:3494 SYN_RECV tcp 0 0 85.254.49.180:80 195.91.229.193:52428 SYN_RECV tcp 0 0 85.254.49.180:80 95.109.193.247:1202 SYN_RECV tcp 0 0 85.254.49.180:80 79.105.204.56:56822 SYN_RECV tcp 0 0 85.254.49.180:80 85.15.184.141:56335 SYN_RECV tcp 0 0 85.254.49.180:80 164.177.225.31:50584 SYN_RECV tcp 0 0 85.254.49.180:80 80.83.238.25:2511 SYN_RECV tcp 0 0 85.254.49.180:80 84.240.248.206:3493 SYN_RECV tcp 0 0 85.254.49.180:80 80.83.239.76:26950 SYN_RECV tcp 0 0 85.254.49.180:80 84.240.248.206:3495 SYN_RECV tcp 0 0 85.254.49.180:80 217.144.185.150:58141 SYN_RECV tcp 0 0 85.254.49.180:80 178.215.97.15:13346 SYN_RECV

Syn Cookieを無効にしようとしましたが、効果がありませんでした。そのサーバーは接続数を制限しているようです。「1分あたりのヒット数」の指標を見ると、次のようになっています。

enter image description here

昨日、クラッシュする前は、すべてがうまくいきました。何が問題であるか、またはそれを診断する方法についての情報やアドバイスを提供します。

[〜＃〜] update [〜＃〜]

私はそれが攻撃ではないと確信しています。 nginxを再起動すると、すべてが数時間機能し、その後、syslogは次のものでいっぱいになります。

Possible SYN flooding on port 80 Possible SYN flooding on port 9000

そしてnginxエラーログは最初に104のエラーをたくさん取得します：

2013/01/08 20:28:24 [error] 959#0: *2387458 recv() failed (104: Connection reset by peer) while reading response header from upstream

そして110：

2013/01/08 21:27:19 [error] 30349#0: *760749 upstream timed out (110: Connection timed out) while connecting to upstream

これは、負荷が一定量の履歴（1秒あたり約800）に達し、問題が発生した夜に発生します。

Syncookieをオフにしてバックログを調整しても効果はありません。

インターネットも同様の主張でいっぱいですが、本当の答えは見つかりません。助けてください！

cnst · Accepted Answer

アップストリームサーバーに問題があり、nginxの表示が非常に遅くなっているようです。

Nginxが遅いように見える場合、リクエストがphp-fpm + apcにプロキシされている場合にのみ、リクエストに長い時間がかかりますか？プロキシされていないlocationを定義し、それが問題を示すかどうかを確認してみましたか？

Php-fpm + apcのメモリ不足、接続/ファイル記述子、またはワーカースレッド/プロセスが不足していますか？ OpenVZを使用していますか？または、設計によって壊れている可能性のある他のカーネルレベルの仮想化はありますか？そうでない場合、ヒットする可能性のある他のプロセスまたはメモリの制限はありますか？ php-fpm/apcを実行するユーザーにsuを実行し、limitでtcshを実行することで、制限を確認できます。

おそらく、nginxとphp-fpm + apcの構成全体を投稿する必要があります。そうしないと、大きな推測ゲームになります。私はphpの人ではありませんが、私の知識に基づいた推測では、php-fpm + apc側に、nginxプロキシが超えている何らかの接続またはワーカースレッドの制限があります。

また、ある日突然物事がどのように下り坂になったのかについての素晴らしいグラフがあると思います。それが起こる前の数日以内に最近の変更またはアップグレードを行いましたか？

Garfield Carneiro · Answer

IPtables または nginx を使用して着信接続のレート制限を行うことは可能ですか？

mate64 · Answer

デフォルトのIptablesチェーンをセットアップすることを強くお勧めします。 SYNフラッディングをドロップし、ドロップされたすべてのパケットをログに記録してください。ネットワーク層で一体何が起こっているのかさえわかりません。

氾濫した攻撃を止め、パッケージをドロップします
ドロップされたすべてのパケットをログに記録する
これで何が起こるかについて私たちを更新してください

最後に、ネットワーク分析の経験がある人がサーバーのクラッシュを検出し、攻撃をすぐに停止するのは簡単です。