本來是一個美好的大週末，突然卻被一個突如其來的電話把我從美夢中驚醒，然而一切還不止這麼簡單......
本來剛開始瞭解到資訊是客戶的一臺RouteOS裝置掛了，聽到這個訊息時覺得自己應該可以很快解決，畢竟就是重啟一下的事情，然而真正登入到後臺才發現一切都沒這麼簡單......
後臺檢視作業系統狀態
唉，別提有多難過，後臺竟然發現系統剛剛啟動就立馬重啟了，而且反覆如此，陷入了死迴圈，因此第一時間判斷為此臺RouteOS被黑了（事實證明是我多慮了），看樣子是沒有辦法短時間恢復了，讓客戶切換業務吧，客戶涉及此臺裝置的業務路由進行切換。
初步分析
判斷為系統被黑後，開始檢視這臺裝置的監控資訊。
客戶提供的zabbix監控資料。
檢視我方後臺監控，發現CPU和記憶體使用率確實有異常，從客戶監控獲取不到資料的時間點開始，我方監控可以準確的顯示到改裝置的CPU使用率開始異常，與正常業務模型相比，變化明顯，記憶體使用率也開始從正常的百分之十以下的使用率突增到百分之七十以上，此刻心中更加確信此臺裝置是被黑了。
咋整，此時內心無比尷尬，因為這個客戶以前就已經被黑過一次了（RouteOS版本低，存在漏洞最終被攻擊），並且已經升級到了最新版本還購買了KEY，沒辦法硬著頭皮和客戶說吧。因為自己不太瞭解RouteOS系統，所以將故障升級，且料二線工程師告訴我沒辦法修復了，唉，忍著被捱罵的風險告訴客戶吧。
進一步獲取資訊
告訴了客戶系統可能被黑了以後，客戶說被黑的可能性不大，原因如下：
- 已經將作業系統升級至最新版本，且使用的不是破解版，還購買了key。
- 已經將所有登入方式關閉，只留下了web介面這種登入方式，可以登入的地址只開放給了客戶公司的公網地址，同時修改了預設埠。
- 密碼複雜度極高：20位以上隨機生成密碼。
目前從監控中看到的資訊，CPU和記憶體有異常，客戶表示它們的zabbix沒有監控到記憶體有變化，和客戶解釋因為客戶zabbix監控是使用snmp協議對此臺裝置進行監控的獲取不到資料是因為網路不通了導致，而我方監控是直接從宿主機獲取的日誌，所以可以監控到後續的資訊，但是根據客戶提供的資訊，被攻擊的風險確實不大，只能硬著頭皮搞了，嘗試下能不能修復系統。
修復系統
當前第一要務是先把作業系統啟動，確保可以穩定執行不會再一次重啟，後臺掛載修復映象後，進入修復模式，對這個系統也不瞭解，只能一步一步琢磨加上網上搜尋資料，看到有文章也遇到過類似的問題，RouteOS重啟的問題，可能和watchdog有關。
進入修復模式，將watchdog配置檔案進行備份，重啟發現系統正常了，確認了作業系統反覆重啟應該是watchdog配置導致，向客戶詢問有關watchdog的配置資訊。
後續經過確認客戶配置如下：
Watch Address: 公網閘道器地址
Ping Start After Boot: 00:01:00
Ping Timeout: 10s懷疑是客戶配置導致，新開了一臺RouteOS進行測試，將測試機的Watchdog配置和客戶相同後重啟，發現作業系統確實會一直重啟，確認了是因為配置導致作業系統不斷重啟，後續後臺重啟測試機的同時開始ping測試機的公網地址，到可以ping通時用時大約100s，懷疑是客戶作業系統不斷重啟的原因是因為系統啟動網路卡還未完全就緒，RouteOS watchdog就已經開始執行ping測試，測試10s發現與監控地址不通，直接重啟，如此反覆陷入死迴圈。
推翻最初分析
這樣就可以推翻最初被黑的分析了，至於監控到CPU和記憶體突增，就是作業系統反覆重啟導致的了，唉，通過一個一個目錄找檔案，到最終能把系統修復，不容易啊。
確認系統關機原因
系統反覆重啟的原因已經確認了，但是又是什麼原因導致最初系統會關機呢，這個同樣需要確認下，所以和客戶要了重啟時間段的日誌，獲取到有效資訊如下：
從日誌字面意思理解是watchdog程式出現了嚴重錯誤，導致watchdog不能ping設定的閘道器地址，最終重啟RouteOS。
為了確認下不是網路原因導致的，我在測試機上同樣配置了相關操作，watchdog檢測一個伺服器的地址，後續在伺服器上開啟防火牆禁止ICMP協議，RouteOS開始重啟，重啟後獲取日誌資訊如下：
好了，確認瞭如果是網路問題，會報timeout錯誤，至此修復了客戶的作業系統，並確認了作業系統最初重啟的原因，心累，不過是一次很好的學習體驗。