前言
運維安全是企業安全保障的基石，不同于Web安全、移動安全或者業務安全，運維安全環節出現問題往往會比較嚴重。
一方面，運維出現的安全漏洞自身危害比較嚴重。運維服務位于底層，涉及到服務器，網絡設備，基礎應用等，一旦出現安全問題，直接影響到服務器的 安全；另一方面，一個運維漏洞的出現，通常反映了一個企業的安全規范、流程或者是這些規范、流程的執行出現了問題，這種情況下，可能很多服務器都存在這類 安全問題，也有可能這個服務還存在其他的運維安全問題。
本文一方面希望幫助甲方覆蓋一些盲點，另一方面也能夠為白帽子提供一些漏洞挖掘的方向和思路。
Attack Surface
一圖勝千言，下圖是個人近期總結的一些常見的運維風險點。
運維安全對抗發展
攻防對抗本身就是不平等的，防御是一個面，而攻擊者只需要一個點。要防住同一level的攻擊，需要投入的防御成本是巨大的。 在攻防對抗的各個level，高level的攻擊手段是可以隨意貫穿低level的防御層面。
救火
對于很多小公司(其實也包括很多大公司)，對待安全漏洞的態度基本上都是遇到一個坑，填一個坑，這種純“救火”的態度無法保障運維安全，只會像打地鼠一樣，疲于奔命。
然而大部分公司都處在這個level——填坑救火(不救火的公司沒有討論的必要)。一方面是公司自身的安全意識不強；另一方面是小公司的安全資源配備有限。
漏網之魚 VS 建設 + 運營
不同于小公司，一些大公司，特別是互聯網公司，安全發展已經逐漸的從“救火”進入到“建設”的階段。
從甲方的角度而言，這個過程是艱辛的，長久的。
在企業進入安全“建設”的階段時，運維安全漏洞會呈指數級下降，一些常見和普通的問題不再出現。
這個時候，對抗點會集中在一些比較邊緣的點。包括不常見的服務端口，依賴第三方服務的問題，又或者是一些合作方服務器安全漏洞等情況。
通常情況下，造成這些安全問題并非是安全技術的缺陷，更多的是安全規范、標準流程覆蓋不全的情況，如新業務、三方業務、收購的業務，運維體系還沒有統一，運維安全建設沒有及時跟上；即使在安全規范和流程覆蓋完全的情況下，在具體的執行上也會出現一系列問題。安全規范和標準流程越多，越容易出現執行上的問題。
這兩類問題是建設時期比較典型的情況。很多時候，領導都會有這樣的疑問，我們的規范、流程已經推到各個部門，看起來各個部門也按照標準執行了，為什么還會有這么多“漏網之魚”?
于是，如何主動的發現這些漏網之魚也是一個急迫的需求。
這個時候需要安全運營的介入，安全運營在戴明環中扮演的量C/A的角色，定期check安全規范、流程標準的執行情況，然后推動安全問題的Fix，找到根本原因，一方面不斷的完善規范和流程，另一方面不斷的提升運維安全的覆蓋面。
比較常見的就是安全掃描，通過定期掃描發現的問題，反推流程和規范的執行；當然，通過白帽子報告的漏洞，確定是流程和規范的原因后，進行反推也是一種有效的方式。
“新”漏洞 VS 預警 + 響應
天下武功，唯快不破
在運維安全提醒建設到相對完善的情況下，通常情況下，企業是相對安全的。但是，一旦有新漏洞的出現(在國內，有exp發布的漏洞往往就等于新漏洞)，拼的就是響應速度。
一方面是需要安全運營對這些嚴重漏洞的快速預警；另一方面就是安全專家的技術功底了。在沒有官方補丁發布的情況下，如何通過一些hack技巧進行防御也是非常重要的。
比如最近幾年比較大的安全事件，如2013年7月17日的struts2漏洞，2014年4月7日的心血漏洞，就算是國內甲方最強安全團隊BAT也是難于幸免。 這一level，甲方非常難做，唯一能保障的就是在中招后提示響應和修復的速度。
人 安全意識 VS 安全教育
在整個運維安全的對抗中，人這一塊尤為重要，運維安全做的越好，這塊越發重要。
安全規范和標準可以落實到各個部門，以流程的方式強制執行。但是運維人員安全意識的問題，很難進行控制。
最簡單的就是弱口令，弱口令，弱口令!
各種系統的弱口令，各種后臺的弱口令，各種服務的弱口令。這么多年了從來沒有斷過。
很多運維有些“壞”習慣。
比如直接在web目錄進行web文件備份、nohup后臺運行程序。這樣會導致備份文件、程序執行的日志泄露；又或者隨便開一個web服務下日志或者傳數據，如python -m SimpleHTTPServer，這樣就直接把目錄映射到所有用戶，如果是根目錄，影響就更大了；當然，還有些運維喜歡把自動化腳本上傳到git，腳本這東西，密碼就在里面，一不小心就直接泄露了密碼。
京公網安備 11010502049343號