生產伺服器的高危操作有哪些？

01-12

自己在應急響應中不小心把一台生產伺服器搞down了，索性重啟後問題解決了。嚇出一身冷汗，起因是安裝了一個軟體。由於自己對運維知識相對短缺，請教下互聯網一線運維人員，什麼樣的操作是高危操作，好讓自己有個紅線意識。
———————————————————————————————————————————
主要一些看似風險很低，但又高危的操作，神馬rm -rf /*啥的，我還是知道的。比如這次的安裝軟體可能和雲伺服器和內核衝突等等。類似這種平時看似很安全，但在生產伺服器上可能會導致問題的操作。

你好，和運維相關，我是做雲安全的

分享幾個我經歷過的生產伺服器比較嚴重或者奇異的事故吧

1.如前面答主提到的，如果是虛機，做好快照鏡像

eg.有次有台物理機的網卡驅動出了問題，別的應用直接遷到另一台繼續跑，可惜某項目組的備份策略在之前自己停了，所以斷了挺久的。

這個更多的是規範的執行能力，但有時候項目組是大爺你懂的....

2.從網路安全的角度考慮，web伺服器別放根目錄，以非root用戶運行，對許可權理解得比較好的話給這個用戶所需的最小許可權。

eg. 有天某項目tomcat 在演示環境放了一天，結果manager密碼被人爆破出來了，上傳了可執行命令的木馬，要命的是這台當時著急著用root 跑的tomcat....

還有次類似的，也是用root跑的jboss被java反序列化漏洞getshell了，對方打了個whoami，然後回顯了一個 "root" ；不敢想像當時那個人愉悅的表情..... 這個工具網上可以找，也可以直接用我存著的鏈接：http://pan.baidu.com/s/1bpmHpGN 密碼：nrqt

3. 壓力測試，CC，在測試環境做足，別在生產環境

eg.某 ruby on rails 項目組，不知道怎麼搞的，新買了一套web掃描設備，對著生產環境就開掃，MongoDB沒事，但是直接後台資料庫集群大量死鎖，因為該集群是和項目組B共用的，導致B也發生了問題。最後DBA們分析的結果怎麼樣了不清楚，但是可能和同一session的並發數有關，講道理這個是應該提前做限制的。

4.補充3，準備工作多在開發、測試預發布環境做足了，生產環境不會有太大的問題的。涉及到DB的操作，千萬小心。生產環境一般不去SSH或者ldap等，需要拉日誌什麼的提前用logstash 轉儲到專門的文件伺服器。需要啟停服務，編寫腳本也好，手動打命令也好，一定要確認前進程已經徹底close了， ps -ef里沒有了，再啟。

eg. 又是tomcat，統一用saltstack維護的啟停腳本，絕大部分都ok，就一個項目組的三台一直zabbix報警，看回顯， Tomcat started . 無Exception。再看進程... 原進程和後開的進程都在...

從此修改了相關腳本...加了更嚴密的判斷邏輯，也加了監控報警的進程相關策略。

5. 又是安全相關，有的項目組用docker的，部分主機漏掃的不管docker里的情況，特別是如果項目組給你之前為了方便有很多匿名可上傳/讀寫/run操作的情況，留心一下。

6.如果公司業務比較龐雜，管理還在建設中，記得把所有項目用的域名統一管理好.....

eg. 域名沒續費導致服務不可用... 到處找問題，ping虛機沒問題，內網訪問埠一切都正常，然後發現是dns... 當年做域名備案和繳費的人早已離職....續費提醒郵件都不知道哪裡收...

7. java調用shell/執行命令等類似的，不要寫 kill，整個jvm可能會崩。也注意如果標準輸出和錯誤輸出沒有導向文件或null， java進程會撐爆卡死。

eg. 來源於自己真實開發的案例... 要麼就自信把分配內存改大點

8.小tips，對於各種安全爬蟲，機器自動化攻擊行為，改改伺服器banner，省很多心。讓zoomeye這些搜索引擎摸不清你到底是啥，也就不好進行對應的攻擊。

eg. 自己整理的：

tomcat版本隱藏：

1.替換 .../lib/catalina.jar 里 org/apache/catalina/util/ServerInfo.properties相應欄位

2.配置文件 .../conf/server.xml

nginx版本隱藏

1.替換 .../bin/nginx (或在源碼中 ../scr/core/nginx.h 修改後重新編譯)

2.配置文件 .../nginx.conf

http { ... server_tokens off; }

apache版本隱藏

1.配置文件 .../httpd.conf或 .../extra/httpd-default.conf

ServerTokens Prod

ServerSignature Off

php版本隱藏

1. 配置文件php.ini

expose_php Off

等等

-----------------------------------------------------------------------------------------------------------------------

小許可權，細邊界，能內網/專線就內網/專線。

eg. 供其他應用調用api介面的完全可以放內網，資料庫更不用說了，通過nginx反代出去的限制好路徑。萬一要重啟，確定好順序。等等。

差不多結合自己工作中了解的案例就這麼些吧.~

最後...聽說運維兄弟們逢年過節都是這樣的...

哈哈~辛苦了！

和老外合作的時候，一定要把 done (搞定了) 和 down (掛了) 的發音區分清楚。不要問我是怎麼知道的。。。

sudo rm -rf /

用的阿里雲，root密碼在我手上，當時想要用公鑰私鑰登錄，禁止密碼登錄。

首先禁止密碼登錄，修改了ssh配置文件中

PasswordAuthentication no

一切順利，接下來拷貝公鑰，結果拷貝公鑰的時候，手抖了，按了下鍵盤，導致公鑰加了點東西，當時沒發現，等我興緻勃勃的保存，退出終端，重新登錄的時候，見證奇蹟的時刻到來了：

我登錄不進去了，由於關閉了密碼驗證，用密碼登錄禁止了，不行了，當時正好周末，只能等上班後，打阿里雲客服電話，讓他們修改了=_=

不怪我，只能怪冬天太冷了，凍手。。。

去年夏天高溫加柳絮和灰塵把空調半夜整停機了，高壓線就泡在漾出來的空調冷凝水裡面。

年前機房的施耐德UPS自燃了，估計和不能說名字的人離職有關。

十年前生產高峰期（深夜）停電，運維部值班人員全體被鎖到電梯裡面。

不要在伺服器上安裝編譯環境，裝軟體盡量使用官方提供的二進位包，如果一定要編譯，請在本地環境編譯後再打包上傳

不要同時登錄測試環境和生產環境

輸完一條命令停三秒看一下

備份，備份，備份

話說rm -rf / 這個梗最早起源於一個自動化shell腳本，原文大概是這樣的 rm -rf /$path 結果某種邏輯異常導致$path值為空

看到某些伺服器的ID燈亮著的時候不要很瀟洒地去按，要睜大眼睛，不然就手滑按到電源按鈕了

上班第一天和同事去機房巡檢的時候就把一台伺服器誤關機了，幸虧是測試環境，要是生產環境可以直接走人了

APPSCAN把一個奇怪的框架給掃刪除了，然後15分鐘迅速恢復，好在是UAT環境

那到底做不做備份呢

整機櫃的內網，沒做帶寬現在，導致一台機器，把整個內網堵死

1.rm -rf /*/*

2.upgrade

3.修改系統或者軟體相關的文件和配置

做任何操作都要想著能夠回滾才會做。

人工版本控制 /捂嘴

安全掃描

不做備份，還有就是別把項目放到系統盤