J'ai un serveur Windows exécutant une API Web qui sert une application Android, et aujourd'hui, j'ai commencé à recevoir des alarmes indiquant que mon serveur expirait.

Ce serveur fonctionne derrière Cloud Flare.

Lorsque je me suis connecté au serveur via RDC, j'ai remarqué qu'il utilisait 0% de CPU mais avait plus de 3200 connexions comme on peut le voir ici : connexions

La quantité "normale" de connexion serait quelque chose de proche de 300. C'était donc 10 fois plus.

Je pensais qu'il était attaqué puis j'ai activé le "Je suis en mode attaque" de cloudflare mais cela n'a pas fonctionné du tout.

J'ai redémarré IIS en exécutant iisreset et il est revenu à la normale pendant quelques minutes, puis le nombre de connexions a recommencé à augmenter !

J'ai sauté dans le chat d'assistance de Cloud Flare et l'agent d'assistance a dit qu'il ne voyait rien d'anormal et qu'il ne pouvait rien faire.

Mon serveur n'autorise que les connexions à partir des serveurs CF.

J'ai décidé de vérifier quelles étaient ces connexions et quand j'ai lancé netstat, j'ai eu ceci :

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

ce ne sont que quelques lignes tirées de 3622 lignes.

La partie intéressante est que sur ces 3622 lignes, 2992 avaient ce CLOSE_WAIT comme état.

Comme je l'ai dit, si j'exécutais iisreset, tout fonctionnerait normalement pendant quelques minutes avant de commencer à expirer pour les véritables utilisateurs de l'application.

Le soutien des FC a dit qu'ils ne pouvaient rien voir d'anormal, donc je ne sais pas s'il s'agissait d'une attaque ou quoi.

Le serveur exécute IIS, cela pourrait-il être un bogue d'une manière ou d'une autre ? Y a-t-il une attaque qui suit ce modèle et laisserait beaucoup de connexions CLOSE_WAIT ?

Toute aide sera grandement appréciée.

Le serveur exécute Windows Server 2016 et IIS 10.

answer

OK, je posterai mes conclusions ici, juste au cas où quelqu'un en aurait besoin.

Environ 10 heures avant que ce problème ne se produise, j'avais exécuté la mise à jour de Windows et KB5005698 était installé. Cette mise à jour a été installée sur les 2 serveurs prenant en charge l'application Android.

Bizarrement, le problème a commencé en même temps sur les deux serveurs, c'est pourquoi j'ai d'abord soupçonné qu'il s'agissait d'une attaque.

Lorsque le serveur n'était plus en charge élevée, le problème s'est arrêté et j'ai décidé de migrer l'API Web de .net 5 vers .net 6, j'ai installé le bundle de serveurs et je l'ai déployé.

Comme le problème s'est arrêté avant la migration de la version .net, rien n'avait changé, je l'ai donc laissé là.

Il y a environ 4 heures, j'ai recommencé à recevoir des alarmes, mais cette fois, c'était parce que l'API Web renvoyait un http 500 excessif, mais le nombre de connexions était normal. J'ai donc décidé de revenir à la version .net 5 de l'application.

Dès que j'ai fait cela, le nombre de connexions a commencé à augmenter et a atteint 5 000 de plus en une minute à peine et les délais d'attente étaient gratuits ! J'ai continué à exécuter iisreset et le même schéma se reproduisait.

Je l'ai donc remplacé à nouveau par .net 6 et plus aucune connexion n'augmente, mais http 500 au bout d'un moment.

Il s'avère que le http 500 était un correctif de code facile, je l'ai donc corrigé et déployé à nouveau, en ciblant .net 6.

Donc, plus de connexions élevées et tout semble fonctionner correctement.

Je suis donc arrivé à la conclusion que le problème est avec KB5005698 et .net 5.

Le déploiement de la même application ciblant .net 6 a résolu le problème.

Après des milliers de mauvaises critiques et une perte de revenus, tout est de retour...

Leçon apprise... Je ne mettrai plus jamais à jour le serveur si je n'en ai pas besoin.

J'espère que cela aide quelqu'un.