Выявление причины слишком большого количества CLOSE_WAIT в IIS

У меня есть сервер Windows, на котором работает веб-API, который обслуживает приложение для Android, и сегодня я начал получать предупреждения о том, что мой сервер истекает.

Этот сервер работает за Cloud Flare.

Когда я подключился к серверу через RDC, я заметил, что он использует 0% ЦП, но имеет более 3200 подключений, как видно здесь: связи

«Нормальное» количество подключений было бы около 300. Так что это было в 10 раз больше.

Я подумал, что он атакован, а затем активировал «режим атаки» из cloudflare, но это вообще не сработало.

Я перезапустил IIS, запустив iisreset, и на несколько минут все вернулось в норму, а затем количество подключений снова начало увеличиваться!

Я зашел в чат поддержки Cloud Flare, и агент поддержки сказал, что не видит ничего необычного и ничего не может сделать.

Мой сервер разрешает только подключения с серверов CF.

Я решил проверить, что это были за соединения, и когда я запустил netstat, я получил следующее:

Активные соединения

  Протолокальный адрес Состояние внешнего адреса
  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 УСТАНОВЛЕН
  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 УСТАНОВЛЕН
  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 УСТАНОВЛЕН
  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 УСТАНОВЛЕН
  TCP xxx:80 CF_IP_ADDRESS.211:35054 CLOSE_WAIT
  TCP xxx:80 CF_IP_ADDRESS.217:26940 УСТАНОВЛЕН
  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.

OK I will post my findings here, just in case anyone needs it.

Around 10 hours before this issue started to happen, I had ran windows update and KB5005698 was installed. This update was installed on the 2 servers that support the android app.

Weirdly enough, the issue started at the same time on both servers, that's why I initially suspected it was an attack.

When the server wasn't on high load anymore, the issue stopped and I decided to migrate the web api from .net 5 to .net 6, I installed the server bundle and deployed it.

As the issue stopped before migrating .net version, nothing had changed so I just left it there.

Around 4 hours ago, I started getting alarms again, but this time it was because the web api was returning excessive http 500, but the number of connections were normal. So I decided to revert the app to the .net 5 version.

As soon as I did that, the number of connections started to increase and reached 5k more in just a minute and the timeouts were running free! I kept running iisreset and the same pattern was happening again.

So I swapped it again to .net 6 and no more connections increase but http 500s after a while.

Turns out the http 500 was an easy code fix so I fixed it and deployed again, targeting .net 6.

So no more high connections and everything seems to be working smoothly.

So I came to the conclusion that the issue is with KB5005698 and .net 5.

Deploying the same app targeting .net 6 fixed the problem.

After thousands of bad reviews and loss of revenue, it's all back again...

Lesson learned... I will never update the server again if I don't need to.

Hope it helps someone.