Se identifică cauza prea multor CLOSE_WAIT în IIS

Am un server Windows care rulează un API web care servește o aplicație Android și astăzi am început să primesc alarme care spun că serverul meu expiră.

Acest server rulează în spatele Cloud Flare.

Când m-am conectat la server prin RDC, am observat că folosea 0% din CPU, dar avea mai mult de 3200 de conexiuni, așa cum se poate vedea aici: conexiuni

Cantitatea „normală” de conexiune ar fi ceva aproape de 300. Deci a fost de 10 ori mai mult.

Am crezut că este atacat și apoi am activat modul „Sunt sub atac” din cloudflare dar nu a funcționat deloc.

Am repornit IIS rulând iisreset și a revenit la normal pentru câteva minute, apoi numărul de conexiuni a început să crească din nou!

Am accesat chat-ul de asistență Cloud Flare și agentul de asistență a spus că nu vede nimic ieșit din comun și că nu pot face nimic.

Serverul meu permite doar conexiuni de la serverele CF.

Am decis să verific care sunt acele conexiuni și când am rulat netstat, am primit asta:

Conexiuni active

  Proto Adresă Locală Stat Adresă străină
  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

acestea sunt doar câteva rânduri luate din 3622 de linii.

Partea interesantă este că din aceste 3622 de linii, 2992 au avut acest CLOSE_WAIT ca stat.

După cum am spus, dacă aș rula iisreset, totul ar funcționa normal timp de câteva minute înainte de a începe să expire pentru utilizatorii autentici ai aplicației.

Suportul CF a spus că nu au putut vedea nimic ieșit din comun, așa că nu sunt sigur dacă acesta a fost un atac sau ce.

Serverul rulează IIS, ar putea fi o eroare cumva? Există vreun atac care urmează acest model și ar lăsa o mulțime de conexiuni CLOSE_WAIT?

Orice ajutor ar fi cu adevărat apreciat.

Serverul rulează Windows Server 2016 și 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.