隨著IT技術(shù)和業(yè)務的發(fā)展及各式各樣安全漏洞的涌現(xiàn)，運維與安全這兩個專業(yè)日漸交融蝌诡，人們對運維安全的重視程度越來越高溉贿，于是逐漸出現(xiàn)了一個新的交叉領(lǐng)域叫“運維安全”。
黑客浦旱、白帽子忙于挖掘運維安全漏洞宇色，企業(yè)忙于構(gòu)建運維安全體系，一時間無數(shù)漏洞紛至沓來颁湖，座座堡壘拔地而起宣蠕。
作者立足自身多年運維安全實踐，也來探討一二甥捺。
本文將按照提出問題到回應答案的思路抢蚀，先拋出作者對運維安全的理解，并解釋重視運維安全的原因镰禾；接著根據(jù)在運維安全一線發(fā)現(xiàn)的工作陋習及企業(yè)面臨的常見問題皿曲，整理出通用運維安全問題分類；之后的下篇還將對癥下藥吴侦，提出一個好的運維安全形態(tài)：不僅在于工程師們的安全意識屋休，更在于一套相對完整的運維安全體系，從流程到技術(shù)备韧，點線面多位一體共同締造劫樟。
一、什么是運維安全？
我們先看一張維恩圖毅哗，現(xiàn)實中的業(yè)務听怕、運維捧挺、安全的關(guān)系是互相關(guān)聯(lián)虑绵、彼此依賴的：
從這張圖中，衍生出三個不同與安全相關(guān)的子專業(yè)：“運維+安全”闽烙、“安全+運維”翅睛、“業(yè)務+運維+安全”。在互聯(lián)網(wǎng)公司招聘崗位里黑竞，我們經(jīng)巢斗ⅲ看到的是運維安全工程師、安全運維工程師很魂，這兩個崗位比較好對號入座扎酷。而“業(yè)務+運維+安全”，通常被包含在安全工程師的崗位中遏匆，近年出現(xiàn)的應用運維安全工程師法挨，相比之下更符合“業(yè)務+運維+安全”的定位。
1幅聘、運維安全 = 運維 + 安全
運維安全研究的是與運維相關(guān)的安全問題的發(fā)現(xiàn)凡纳、分析與阻斷，比如操作系統(tǒng)或應用版本漏洞帝蒿、訪問控制漏洞荐糜、DDoS攻擊等。顯然葛超，運維安全立足于運維暴氏，從企業(yè)架構(gòu)上講通常屬于運維部門或基礎(chǔ)架構(gòu)部門，運維安全工程師的專業(yè)序列一般屬于運維工程師绣张。
2偏序、安全運維 = 安全 + 運維
安全運維研究的是安全系統(tǒng)或設(shè)備的運維，比如防火墻胖替、漏洞掃描器維護研儒、漏洞挖掘與應急響應等。這個也很明顯独令，安全運維屬于安全部門旗下端朵，安全運維工程師的專業(yè)序列也屬于安全工程師。
3燃箭、應用運維安全 = 業(yè)務 + 運維 + 安全
應用運維安全研究的是業(yè)務上的運維與安全冲呢，主要包括安全風險評估與安全方案規(guī)劃設(shè)計及其落地。組織架構(gòu)上該崗位有屬于安全部門的招狸，也有屬于業(yè)務部門的敬拓，對應的專業(yè)序列有屬于安全工程師的邻薯，也有屬于開發(fā)工程師。
通過對比“運維+安全”乘凸、“安全+運維”厕诡、“業(yè)務+運維+安全”三個子專業(yè)的不同，我們明確了運維安全的研究領(lǐng)域和崗位職責营勤×橄樱看到這里，可能大家會有疑問葛作，是什么導致運維安全現(xiàn)在這么“風光”寿羞？
二、為什么我們重視運維安全赂蠢？
可以說绪穆，2013-2014年是運維安全發(fā)展的一個分水嶺。這兩年特別之處在于作為互聯(lián)網(wǎng)基礎(chǔ)設(shè)施的幾大應用相繼被爆漏洞或被攻擊虱岂，例如Struts2遠程代碼執(zhí)行漏洞玖院、Openssl心臟滴血、Bash破殼漏洞量瓜，以及當時“史上規(guī)模最大的DDoS攻擊”導致大量.cn和.com.cn域名無法解析司恳。在這之后，企業(yè)對運維安全投入迅速加大绍傲，各種運維安全問題也引起廣泛關(guān)注扔傅。直到今天烫饼，運維安全已經(jīng)成為企業(yè)安全建設(shè)的重中之重猎塞。
1、漏洞百出的軟件供應鏈
struts2遠程代碼執(zhí)行漏洞
當年S2漏洞一出荠耽，整個互聯(lián)網(wǎng)一片哀嚎。下面是受影響的企業(yè)比藻，大家應該幾乎沒有不認識的吧？
openssl心臟滴血
跟S2漏洞一樣慢叨，殺傷力極強。
xcode開發(fā)的ios app感染木馬
研究者發(fā)現(xiàn)AppStore上的TOP5000應用有76款被感染。后來發(fā)現(xiàn)罪魁禍首是開發(fā)人員從非蘋果官方渠道下載xcode開發(fā)環(huán)境。
2轩拨、 運維安全漏洞占比明顯
自從某云離去以后践瓷，不得不說國內(nèi)互聯(lián)網(wǎng)安全態(tài)勢的共享逐步走向了封閉，不過借此機緣亡蓉，也涌現(xiàn)了很多商業(yè)公司晕翠。
即便是現(xiàn)在留下的某天某法某眼，能查詢到的統(tǒng)計分析數(shù)據(jù)其實也很有限寸宵。即便是某旦崖面，其用戶體驗也不夠好元咙，統(tǒng)計分析功能無法差強人意梯影。剩下的，各種研究報告也從來沒有把運維安全問題列入單獨的統(tǒng)計范疇庶香，所以這里借用2016年CNVD的統(tǒng)計甲棍，可以發(fā)現(xiàn)明顯屬于運維安全問題的網(wǎng)絡設(shè)備漏洞和操作系統(tǒng)漏洞，占比已超過20%赶掖，加上應用程序漏洞中包括的各種應用版本漏洞感猛，相信歸屬于運維安全領(lǐng)域的漏洞比例將極其可觀。
3奢赂、 運維安全漏洞利用性價比高
針對運維安全漏洞的攻擊屬于典型的“一兩撥千金”陪白，其ROI非常高：投入小、容易發(fā)現(xiàn)與利用膳灶、造成危害特別大咱士。
根據(jù)微軟的DREAD模型來衡量運維安全漏洞風險如下：
三、常見運維安全陋習
運維安全事件頻發(fā)轧钓，一方面固然是因為運維或安全規(guī)范空白或者沒有落地序厉，另一方面也在于運維人員缺乏強烈的運維安全意識，在日常工作中存在這樣那樣的安全陋習導致毕箍。
下面列出了14種坑弛房，大家可以試試對號入座，仔細想想曾幾何時自己是否也踩過同樣的坑而柑？
1文捶、修改iptables后沒有還原配置，甚至清空關(guān)閉iptables
出于測試需要臨時清空iptables可以理解媒咳，但是很多人會忘記還原粹排，也沒有設(shè)置自動還原機制。
iptables -F
2伟葫、腳本沒有檢查“*”恨搓、空格、變量
如果我們認可“不光用戶的輸入是不可信的，自己的輸入也是不可信”斧抱，這樣的坑就會少踩常拓。
rm -rf /var1/var1/var2
3、服務啟動默認監(jiān)聽全部地址
絕大部分應用默認配置便是如此辉浦，在沒有有效訪問控制的清空下開啟監(jiān)聽所有地址弄抬，離危險也就不遠了。
bind-address 0.0.0.0
4宪郊、給文件開放過大的權(quán)限時掂恕，任何人都能讀寫
這個跟phpinfo有點像，能給入侵者推一把弛槐。
chmod 777 script
5懊亡、用root啟動服務
對于大多數(shù)運維人員而言，一上機器就切到root乎串，后面用root啟動服務仿佛一氣呵成店枣。
nohup ./server &
6、嫌麻煩不配認證叹誉，也不配訪問控制
這個跟監(jiān)聽任意地址比較像鸯两，通常也是默認配置使然，使用者也沒有意識去加固长豁。
requirepass test
7钧唐、單機安裝docker之后忽略檢查iptables，導致docker修改iptables開放外網(wǎng)
docker技術(shù)給我們帶來的便利自不必言匠襟，但是docker帶來的安全風險卻一點也不少钝侠。而且，docker daemon默認是能控制宿主iptables的宅此，如果docker daemon使用tcp socket或者啟動的容器可被外部訪問机错，則連宿主一同淪陷也不在話下。比如下面一啟動容器則將tcp/443端口對外開放了：
docker restart
*nat
:PREROUTING ACCEPT [8435539:534512144]
:INPUT ACCEPT [1599326:97042024]
:OUTPUT ACCEPT [4783949:343318408]
:POSTROUTING ACCEPT [4783949:343318408]
:DOCKER - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A POSTROUTING -s 172.17.0.1/32 -d 172.17.0.1/32 -p tcp -m tcp --dport 443 -j MASQUERADE
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A DOCKER -d 172.23.0.3/32 ! -i br-1bf61a2fa2e7 -o br-1bf61a2fa2e7 -p tcp -m tcp --dport 443 -j ACCEPT
*filter
:INPUT ACCEPT [1599326:97042024]
:OUTPUT ACCEPT [4783949:343318408]
-A INPUT -s 10.0.0.0/8 -j ACCEPT
-A INPUT -s 127.0.0.1 -j ACCEPT
-A INPUT -j DROP
最后的規(guī)則被繞過
8父腕、sudo授權(quán)過大弱匪，導致自定義腳本提權(quán)
如果攻擊者可修改腳本內(nèi)容則提權(quán)易如反掌。
sudo script.sh
參考鏈接：
9璧亮、給開發(fā)或者QA授權(quán)root權(quán)限萧诫，他搞事你背鍋？
一直以來我們強調(diào)RBAC枝嘶，但是運維太忙帘饶，開發(fā)測試人員需求太多時，很多運維人員會直接授權(quán)他們root權(quán)限群扶，而他們對系統(tǒng)級訪問控制不甚了了及刻，因此造成的漏洞非扯瓶悖“ 可觀 ”。
dev@pro-app-01:/home/dev$su
root@pro-app-01:/home/dev#whoami
root
10缴饭、key/token/ssh私鑰保存在txt文件里暑劝，也有把個人ssh私鑰放在服務器的
op@pro-app-01:/home/op$ls ~/.ssh
id_rsa id_rsa.pub
11、把工作上的代碼對外發(fā)布
連著遇到實習生把項目代碼提交github了颗搂，回復的理由是git配錯了担猛。雖然不知真假，但我認為丢氢，至少他們是安全意識不足傅联。
git remote add origin https://github.com/secondwatchCH/EFS.gitgit push origin master
12、個人home目錄那么敏感疚察，也有人拿來直接托管服務蒸走，至少.bash_history泄露是跑不了
dev@pro-app-01:/home/dev$python -m HTTPSimpleServer
13、應用選型時沒有考慮安全風險
Apache Struts Version：Struts 2.5 - Struts 2.5.12 #線上業(yè)務使用受S2-052影響的S2版本
14稍浆、對軟件供應鏈安全沒有概念
從xcode事件到pip官方發(fā)現(xiàn)惡意ssh庫载碌，都在向我們昭示一個道理：軟件供應鏈安全風險極大猜嘱。目前比較運維人員中比較常見問題有：
ssh客戶端或者開發(fā)IDE從百度網(wǎng)盤下載
兩眼一閉衅枫，把github/pypi/dockerhub等網(wǎng)站下載的應用/庫/鏡像直接用到生產(chǎn)環(huán)境
未清理默認口令或者默認配置
四、常見運維安全問題
前面我們談到了運維操作上朗伶、思路上的一些陋習弦撩，或者安全意識不足的問題，下面結(jié)合漏洞分析和響應過的情況來看论皆，常見的運維安全問題主要可分為下面幾種：
1益楼、敏感端口對外開放
db或者cache屬于敏感應用，通常部署在內(nèi)網(wǎng)点晴，但是如果部署的機器有內(nèi)外網(wǎng)ip感凤，且默認監(jiān)聽地址為0.0.0.0的話，則敏感端口會對外開放粒督。如 MySQL / MongoDB / Redis / rsync / docker daemon api 等端口對外開放陪竿。
2、敏感應用無認證屠橄、空口令或者弱口令
同上族跛，如果敏感應用使用默認配置，則不會開啟認證锐墙，MySQL / MongoDB / Redis / rsync / supervisord rpc / Memcache 等應用無認證礁哄。有時貪圖測試方便，配置了弱口令或空口令溪北，則認證形同虛設(shè)桐绒。
3夺脾、敏感信息泄露，如代碼備份茉继、版本跟蹤信息劳翰、認證信息泄露
web.tar.gz/backup.bak / .svn/.git / config.inc.php / test.sql 等信息泄露隨處可見，人人知道危險馒疹，但是始終時不時會有人會踩坑佳簸。
4、應用默認配置未清除
jenkins script / apache server-status等默認功能未清理颖变，例如下圖可直接執(zhí)行命令：
5生均、應用系統(tǒng)打開debug模式
Django debug模式開啟暴露uri路徑，phpinfo()暴露服務器信息甚至webroot等腥刹，之后攻擊者便可借此進一步滲透马胧，很多白帽子應當有此同感，發(fā)現(xiàn)了sql注入但是寫不了webshell衔峰，如果能遇上個phpinfo()那是再好不過的事情了佩脊。
6、應用漏洞未及時升級
越是通用的應用垫卤，就越經(jīng)常爆出漏洞威彰。有句話說的好：不是因為黑客這個世界才不安全，而是因為不安全才會有了黑客穴肘，黑客去揭開那層假象歇盼，我們才發(fā)現(xiàn)有那么多不安全。于是Struts2评抚、OpenSSL豹缀、Apache、Nginx慨代、Flash等等CVE接踵而來邢笙。
7、權(quán)限管理松散
不遵循最小權(quán)限原則侍匙，給開發(fā)提供root權(quán)限或者給業(yè)務賬號授權(quán)admin權(quán)限氮惯。
8、DDoS攻擊
DDoS攻擊對于運維人員而言丈积，是再熟悉不過的安全問題了筐骇。我們都知道通過占滿帶寬、耗盡資源等方式可讓服務器無法響應正常請求江滨，說到底是資源對抗的一種攻擊方式铛纬。如果僅依賴服務器資源去抗，去過濾唬滑，如下圖告唆，在大流量棺弊、高并發(fā)之下，只會引來雪崩：
加上DDoS攻擊平臺大量存在擒悬，而且價格低廉模她，這就讓DDoS攻擊成為打壓競爭對手、報復、勒索等陰謀詭計者首選方式了。
9肢簿、流量劫持
還記得2015年小米、騰訊畜侦、微博、今日頭條等六家共公司聯(lián)合發(fā)表聲明呼吁電信運營商打擊流量劫持的報告嗎躯保？即便如此旋膳，現(xiàn)如今的互聯(lián)網(wǎng)江湖仍是暗流滾滾。下面介紹三種常見的流量劫持方式途事，這也是困擾運維安全人員多年的痼疾：
arp劫持 ： ARP協(xié)議的基本功能就是通過目標設(shè)備的IP地址验懊，查詢目標設(shè)備的MAC地址，以保證通信的進行尸变∫逋迹基于ARP協(xié)議的這一工作特性，黑客向?qū)Ψ接嬎銠C不斷發(fā)送有欺詐性質(zhì)的ARP數(shù)據(jù)包振惰，假冒目標IP進行ARP響應歌溉，從而實現(xiàn)中間人攻擊。
域名劫持 ： 通過劫持掉域名的DNS解析結(jié)果骑晶，將HTTP請求劫持到特定IP上，使得客戶端和攻擊者的服務器建立TCP連接草慧，而非和目標服務器直接連接桶蛔。
HTTP劫持/直接流量修改 ： 在數(shù)據(jù)通路上對頁面進行固定的內(nèi)容插入，比如廣告彈窗等漫谷。
10仔雷、案例
前面我們討論了很多運維安全陋習和問題分類，下面要講的舔示，則是大家再熟悉不過的幾個案例碟婆，且看運維安全漏洞如何“性價比”極高：
svn
部署web代碼時誤將.svn目錄上傳；
使用rsync上傳代碼時沒有exclude掉 .svn目錄惕稻，svn倉庫也沒有使用svn propedit svn:ignore <目錄或文件>的方式ignore掉不應當上傳的文件或目錄竖共；
攻擊者利用svn信息泄露利用工具Svn-Tool或者svn-extractor還原代碼。
rsync
rsync使用root用戶啟動俺祠，模塊沒有配置認證公给，還對外開放默認端口873借帘；
攻擊者利用rsync寫crontab任務成功反彈Shell，并種上了挖礦木馬淌铐。
Redis
Redis使用root用戶啟動肺然，沒有配置認證，還對外開放默認端口6379腿准；
攻擊者利用Redis寫ssh公鑰到root用戶的.ssh目錄成功登上機器际起；
一般部署Redis的機器都有內(nèi)網(wǎng)IP，攻擊者可借此進行內(nèi)網(wǎng)漫游了吐葱。
Kubernetes
K8S的API對外開放加叁，同時未開啟認證；
攻擊者調(diào)用API創(chuàng)建容器唇撬，將容器文件系統(tǒng)根目錄掛載在宿主根目錄它匕， 攻擊者利用寫crontab任務成功反彈Shell，并在宿主種上了挖礦木馬窖认；
有時候容器里跑著未編譯的代碼或者在淪陷的機器上可以拉到私有Docker鏡像倉庫的任意鏡像豫柬，后果將難以想象，如 下面K8S的API扑浸， 調(diào)用起來則非常簡單烧给。
那么，現(xiàn)在就該思考一個問題了：如何做好運維安全喝噪？中醫(yī)有句話叫對癥下藥础嫡。我們花大篇幅去剖析問題所在，也是想從問題入手酝惧，通過糾正或者培養(yǎng)良好的運維安全習慣榴鼎，結(jié)合完整的運維安全技術(shù)體系，才是問題的出路晚唇。
