ระบุสาเหตุของ CLOSE_WAIT มากเกินไปใน IIS

ฉันมีเซิร์ฟเวอร์ windows ที่ใช้ web api ที่ให้บริการแอพ android และวันนี้ฉันเริ่มได้รับสัญญาณเตือนว่าเซิร์ฟเวอร์ของฉันหมดเวลา

เซิร์ฟเวอร์นี้ทำงานอยู่เบื้องหลัง Cloud Flare

เมื่อฉันเชื่อมต่อกับเซิร์ฟเวอร์ผ่าน RDC ฉันสังเกตเห็นว่ามันใช้ 0% ของ CPU แต่มีการเชื่อมต่อมากกว่า 3200 ดังที่เห็นที่นี่: การเชื่อมต่อ

จำนวนการเชื่อมต่อ "ปกติ" จะใกล้เคียงกับ 300 ดังนั้นจึงเพิ่มขึ้น 10 เท่า

ฉันคิดว่ามันกำลังถูกโจมตี จากนั้นฉันก็เปิดใช้งาน "ฉันอยู่ภายใต้โหมดการโจมตี" จาก cloudflare แต่มันไม่ทำงานเลย

ฉันรีสตาร์ท IIS โดยเรียกใช้ iisreset และกลับมาเป็นปกติเป็นเวลาสองสามนาที จากนั้นจำนวนการเชื่อมต่อก็เริ่มเพิ่มขึ้นอีกครั้ง!

ฉันเพิ่มเข้าไปในแชทสนับสนุนของ Cloud Flare และเจ้าหน้าที่สนับสนุนบอกว่าเขาไม่เห็นอะไรผิดปกติและพวกเขาไม่สามารถทำอะไรได้

เซิร์ฟเวอร์ของฉันอนุญาตการเชื่อมต่อจากเซิร์ฟเวอร์ CF เท่านั้น

ฉันตัดสินใจตรวจสอบว่าการเชื่อมต่อเหล่านั้นคืออะไร และเมื่อฉันรัน netstat ฉันได้รับสิ่งนี้:

การเชื่อมต่อที่ใช้งานอยู่

  Proto Local 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 ตั้งค่าแล้ว
  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.