服务器 Gind.cn
  1. 服务器 Gind.cn
  3. Nginx和php-fpm在高负载下失败：“端口80可能发生SYN溢出”和“104：由对等端重置连接”
Intereting Posts
太多的TCP连接导致断开连接 服务器神秘停止允许通过共享访问 Nginx + WordPress：414 Request-URI太长 Bind9：Master-> Slave通知IPv6回退到IPv4 SSH无法加载主机密钥 如何通过SSH重新安装Ubuntu 文件传输我的网站从服务器到最新的一个最好的办法是什么？ networking浏览崩溃ESXi 5pipe理界面 重启后无法ping ubuntu服务器。 在哪里寻找可能的问题？ MariaDB安装错误 访问某些页面下载gzip文件，而不是显示它们 iproute2规则和iptables NAT …有什么区别？ 是否有理由使用tmpfs而不是zRAM？ 将networking位置从域更改为公共 Duplicity – 如何把密码input命令？

Nginx和php-fpm在高负载下失败：“端口80可能发生SYN溢出”和“104：由对等端重置连接”

我有相当沉重的Web服务器使用： 

Ubuntu server nginx php-fpm + apc

昨天我的服务器发生了一些奇怪的事情。 它崩溃，并停止响应，并在我重新启动后，网页开始加载非常缓慢，在大多数情况下“请求超时”。

我检查了/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 Flood攻击，我不是唯一的。 如果是这样，为什么cookies不起作用？ 这里是来自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，但它没有效果。 看来，该服务器是限制连接数，如果你看指标“每分钟命中”，看起来像这样：

在这里输入图像说明

昨天，在崩溃之前，一切正常。 我会appriciate什么信息或build议可能是什么问题或如何诊断它。

UPDATE

我很确定这不是一个攻击。 当我重新启动nginx时 – 一切都可以正常工作几个小时，然后，系统日志又充满了： 

 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

这发生在晚上，当负载达到一定数量的历史（约每秒800），并出现问题。

closuressyn cookie并调整backlog不起作用。

互联网充满了类似的说法，但没有find真正的答案。 请帮忙！

这听起来像你的上游服务器有什么问题，使nginx显得很慢。

当nginx显示缓慢，请求只需要代理到您的php-fpm + apc需要很长时间？ 你有没有试过定义一个非代理location ，看看是否有任何问题？

你的php-fpm + apc内存溢出，连接/文件描述符溢出或工作线程/进程溢出了吗？ 你在使用OpenVZ吗？ 还是其他任何可能被破解的内核级虚拟化？ 如果不是，你是否有任何其他进程或内存限制，你可能会打？ 你可以通过对运行你的php-fpm / apc的用户执行su检查限制，并在tcsh运行limit 。

你可能应该发布你的整个configurationnginx和php-fpm + apc，否则，这是一个很大的猜测游戏。 我不是一个PHP的家伙，但我的教育猜测是，你有一些连接或工作线程的限制，你的PHP的FPM + APC方，你的Nginx代理超过。

另外，我看到你突然有了一个好消息： 在发生之前的几天内，您是否做过最近的更改或升级？

是否有可能使用IPtables或nginx限制传入的连接？

我强烈build议你设置一些默认的Iptables链。 尝试删除SYN泛滥，并logging所有丢弃的数据包。 你甚至不知道你的networking层上发生了什么。

  • 停止淹没攻击，丢弃包裹
  • logging所有丢包
  • 请告诉我们这是怎么回事

最后，对于有networking分析经验的人来说，检测服务器崩溃并立即停止攻击很简单。