☰

确定 IIS 中 CLOSE_WAIT 过多的原因

tag-icon • tag-icon networking security iis denial-of-service cloudflare
确定 IIS 中 CLOSE_WAIT 过多的原因

我有一个运行 Web API 的 Windows 服务器，该 Web API 为 Android 应用程序提供服务，今天我开始收到警报，说我的服务器超时了。

该服务器在 Cloud Flare 后面运行。

当我通过 RDC 连接到服务器时，我注意到它使用了 0% 的 CPU，但有超过 3200 个连接，如下所示： 連接

“正常”连接数量应该接近 300。因此，它是 10 倍以上。

我以为它受到了攻击，然后我从 cloudflare 激活了“我受到攻击模式”，但它根本不起作用。

我通过运行 iisreset 重新启动了 IIS，几分钟后它就恢复正常了，然后连接数又开始增加！

我加入了 Cloud Flare 支持聊天，支持代理说他没有发现任何异常，他们无能为力。

我的服务器只允许来自 CF 服务器的连接。

我决定检查这些连接是什么，当我运行 netstat 时，我得到了以下信息：

Active Connections

  Proto  Local Address          Foreign Address        State
  TCP    xxx:80       CF_IP_ADDRESS.157:13824  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.157:17952  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.173:21754  ESTABLISHED
  TCP    xxx:80       CF_IP_ADDRESS.173:22890  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.173:24456  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.173:55678  ESTABLISHED
  TCP    xxx:80       CF_IP_ADDRESS.173:63352  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.195:31634  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.195:56504  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.195:62466  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.205:14264  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.205:37858  ESTABLISHED
  TCP    xxx:80       CF_IP_ADDRESS.205:47142  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.205:50318  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.205:57534  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.205:63570  ESTABLISHED
  TCP    xxx:80       CF_IP_ADDRESS.211:35054  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.217:26940  ESTABLISHED
  TCP    xxx:80       CF_IP_ADDRESS.217:29042  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.217:37898  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.217:39096  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.217:46002  CLOSE_WAIT
  TCP    xxx:80       CF_IP_ADDRESS.217:63860  CLOSE_WAIT

这只是从 3622 行中摘取的几行。

有趣的是，在这 3622 行中，有 2992 行处于 CLOSE_WAIT 状态。

正如我所说的，如果我运行 iisreset，一切都会正常工作几分钟，然后才开始对应用程序的真正用户超时。

CF 支持人员说他们没有发现任何异常，所以我不确定这是否是一次攻击或者其他什么。

服务器正在运行 IIS，这可能是一个错误吗？是否有任何攻击遵循这种模式并会留下大量 CLOSE_WAIT 连接？

任何帮助将非常感激。

该服务器运行的是 Windows Server 2016 和 IIS 10。

答案1

好的，我会在这里发布我的发现，以防有人需要它。

在这个问题发生前大约 10 小时，我运行了 Windows 更新，KB5005698已安装。此更新已安装在支持 Android 应用程序的 2 台服务器上。

奇怪的是，这个问题在两台服务器上同时出现，这就是我最初怀疑这是一次攻击的原因。

当服务器不再高负载时，问题就停止了，我决定将 Web API 从 .net 5 迁移到 .net 6，我安装了服务器包并进行了部署。

由于该问题在迁移 .net 版本之前就已经停止了，什么都没有改变，所以我就把它留在那里了。

大约 4 小时前，我又开始收到警报，但这次是因为 Web API 返回了过多的 http 500，但连接数正常。所以我决定将应用程序恢复到 .net 5 版本。

我刚这样做，连接数就开始增加，一分钟内就达到 5k 以上，超时也正常了！我继续运行 iisreset，同样的情况又出现了。

因此我再次将其换成.net 6，一段时间后，连接数不再增加，但 http 数量为 500。

事实证明 http 500 是一个简单的代码修复，所以我修复了它并再次部署，目标是.net 6。

因此不再需要高连接，一切似乎都运行顺利。

所以我得出的结论是，问题在于KB5005698和.net 5。

部署针对.net 6 的相同应用程序解决了该问题。

在经历了数千条差评和收入损失之后，一切又回到了原点......

学到教训了...如果不需要的话，我不会再更新服务器。

希望它能对某人有所帮助。

相关内容