本系列文章詳細介紹使用 .net core 和 WPF 開發 升訊威線上客服與營銷系統 的過程。本產品已經成熟穩定並投入商用。
線上演示環境：https://kf.shengxunwei.com 注意：演示環境僅供演示交流與評估，不保證 7x24 小時可用。
系統公開發表不久之後，遭到了一次來自不明人士的蓄意攻擊。（當你努力作一件事的時候，你永遠不知道有些人會怎麼想）
本篇詳細介紹問題的定位和處理過程。
問題發現
21日上午，收到報警，伺服器 CPU 使用率持續超過 80%。我嘗試遠端桌面連線，非常卡，連線伺服器後發現 CPU 佔用率 100%。檢視工作管理員，客服系統後臺服務佔用了 CPU，
重新啟動客服系統後臺程式 ，CPU 佔用率恢復正常。檢視網路監控資料並沒有大的網路流量流入流出，初步推測是對客服系統所使用的通訊埠的攻擊行為。
更換系統所使用的監聽埠後繼續觀察。
23日晚間，再次收到 CPU 使用率報警，檢視發現依然是客服系統後臺服務 100% 佔用了 CPU。重啟服務後恢復正常。幾小時後，我遠端伺服器檢視，發現 CPU 佔用率穩定在 50%，看來攻擊者為了避免引起我的注意，改進了攻擊手段，降低了攻擊強度。
相同的版本，部署在我的客戶的伺服器上執行的環境則是一切正常，持續執行了兩週沒有任何異常情況，而且客戶正式使用的環境，使用強度比我的演示環境要大的多。
在工作管理員裡，雖然能看到是客服系統後臺服務佔用了 CPU，但是無法檢視佔用的具體原因。
問題定位
在我第一次發現問題，更換埠，消停兩次之後，再次發生的攻擊行為，看起來是和我槓上了。
-
首先，在攻擊行為發生時，建立客服系統後臺服務的 Dump 檔案，注意區分 x86 和 x64。
-
安裝 WinDbg 或 WinDbg Priview ，Windows 10 推薦使用 WinDbg privew，使用 WinDbg 開啟 Dump 檔案。
第一次開啟時，會自動下載所需的 PDB 檔案，等待下載完成後，即可載入除錯資訊，如下圖：
-
執行 reload 命令
-
執行 loadby sos clr 命令
-
執行 !tp 命令
顯示出 CPU 佔用率 51%。
-
接下來，我們要找到造成 CPU 佔用具體的執行緒和位置，使用 !runaway 命令。定位到執行緒 41 長時間佔用 CPU。
-
使用命令 ~41s 進入執行緒。接著使用 !clrstack 命令顯示呼叫堆疊。
如圖，根據呼叫堆疊顯示的資訊，非常明確的指示出，Socket 埠接收資料時，大量佔用了 CPU。
結合系統的其它日誌，判斷攻擊者通過連線 TCP 埠，高強度，大量的傳送垃圾資料，導致伺服器 CPU 高負荷執行，企圖拖垮伺服器。明確攻擊位置和原因之後，就好辦了，在 Socket 埠連線和監聽時，加入安全反制的機制，重新部署上線。
不久，抓到了一個國內 IP ，此 IP 發起了攻擊行為，系統自動切斷了連線並拉黑了此 IP 地址。隨後的幾天中，攻擊者使用了國外代理髮起攻擊行為，先後抓到了兩個不同國家的 IP，使用相同的方式發起攻擊行為。雖然攻擊者切換了國外代理，但最初的國內 IP 已經暴露。
28日夜，攻擊者使用了一個位於荷蘭的 IP ，再次發起攻擊，伺服器在識別到攻擊行為後，幾秒鐘內切斷了連線。
其實我並不認為目前我所做的一點點工作能夠對業內其它做同型別軟體的企業產生什麼影響，我推測發起攻擊行為的人只是普通的技術人員。正如我上文說的：當你努力作一件事的時候，你永遠不知道有些人會怎麼想。
我也沒有以某種方式運營這個系統的計劃。
在接下來的文章中，我將具體解構服務端程式的結構和設計、客服端程式的結構和設計，敬請關注。