Xác định nguyên nhân của quá nhiều CLOSE_WAIT trong IIS

Tôi có một máy chủ windows đang chạy api web phục vụ ứng dụng Android và hôm nay tôi bắt đầu nhận được cảnh báo cho biết rằng máy chủ của tôi đã hết thời gian chờ.

Máy chủ này đang chạy phía sau Cloud Flare.

Khi tôi kết nối với máy chủ qua RDC, tôi nhận thấy rằng nó đang sử dụng 0% CPU nhưng có hơn 3200 kết nối như có thể thấy ở đây: kết nối

Lượng kết nối "bình thường" sẽ là khoảng gần 300. Vì vậy, nó gấp 10 lần.

Tôi nghĩ rằng nó đang bị tấn công và sau đó tôi đã kích hoạt chế độ "Tôi đang bị tấn công" từ cloudflare nhưng nó không hoạt động.

Tôi đã khởi động lại IIS bằng cách chạy iisreset và nó trở lại bình thường trong vài phút, sau đó số lượng kết nối bắt đầu tăng trở lại!

Tôi đã tham gia cuộc trò chuyện hỗ trợ của Cloud Flare và nhân viên hỗ trợ nói rằng anh ta không thấy điều gì bất thường và họ không thể làm gì được.

Máy chủ của tôi chỉ cho phép kết nối từ máy chủ CF.

Tôi quyết định kiểm tra xem những kết nối đó là gì và khi tôi chạy netstat, tôi đã nhận được điều này:

kết nối hoạt động

  Proto Địa chỉ địa phương Địa chỉ nước ngoài Bang
  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 ĐƯỢC THÀNH LẬP
  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 ĐÃ THÀNH LẬP
  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 ĐÃ THÀNH LẬP
  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 ĐÃ THÀNH LẬP
  TCP xxx:80 CF_IP_ADDRESS.211:35054 CLOSE_WAIT
  TCP xxx:80 CF_IP_ADDRESS.217:26940 ĐÃ THÀNH LẬP
  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

đây chỉ là một vài dòng được lấy từ 3622 dòng.

Điều thú vị là từ 3622 dòng này, 2992 có trạng thái CLOSE_WAIT này.

Như tôi đã nói, nếu tôi chạy iisreset, mọi thứ sẽ hoạt động như bình thường trong vài phút trước khi bắt đầu hết thời gian chờ đối với người dùng thực sự của ứng dụng.

Bộ phận hỗ trợ của CF cho biết họ không thể thấy bất cứ điều gì khác thường nên tôi không chắc liệu đây có phải là một cuộc tấn công hay không.

Máy chủ đang chạy IIS, nó có thể là một lỗi nào đó không? Có bất kỳ cuộc tấn công nào theo mô hình này và sẽ để lại nhiều kết nối CLOSE_WAIT không?

Bất kỳ trợ giúp sẽ được thực sự đánh giá cao.

Máy chủ đang chạy Windows Server 2016 và 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.