作者簡介：韓方

歡聚時代（YY直播）  安全中心總監

公司T4技術專家，10年以上安全領域的攻防研究和設計開發工作，對於平臺安全、應用安全、業務安全等安全領域有非常深入的研究，申請過多項安全領域相關技術專利，並發表過多篇安全領域學術文章。

曾先後主導設計和開發雲防 DDOS 系統、分散式 Web 入侵防禦系統、Linux 入侵防禦系統、移動安全加固系統、外掛對抗系統、機器人識別挑戰雲服務等安全領域對抗和防禦系統；熟悉網際網路安全技術體系，主導公司安全技術體系建設。

前言

在實際工作中，最難防的就是接近應用層的攻擊。比如針對直播私有協議的機器人，衝擊你的頻道服務、登陸服務、支付服務等等，量大了也會變成 DDoS攻擊。

越接近應用層，防禦和對抗難度越大、挑戰越大，誤傷越大。這需要結合大資料、機器學習、業務流量模型等知識來進行綜合應對，很複雜。偏底層則相對簡單，有比較成熟的技術方案，越往應用層越複雜，自然人和機器人的攻擊行為和正常行為就越難區分。

以上是給 DDoS 做一個補充。我們很難做的就是業務層的 DDoS，比如私有協議、YY 協議，還有我們的音訊、視訊協議。如果真有大量的衝擊，比如你只能支撐兩千萬的 PCU，如果超過兩千萬，你怎麼防禦？所以需要柔性可活的思路。

本文是來自於我在歡聚時代實際工作中的實踐，將分成以下3部分來講解：

1、Linux 下的安全形勢
2、Linux 下的攻擊手段
3、Linux 的防禦對抗

1、Linux下的安全形勢

每個網際網路公司或者每個公司後臺用的伺服器都不太一樣，在YY這種主營業務是純網際網路的公司，Linux 伺服器佔比很高，全網幾萬臺伺服器，Windows 只有幾百臺，剩下都是 Linux，越是網際網路公司用 Linux 的比例越高。

Linux 的安全形勢為什麼這麼複雜？

我早年畢業的時候在華為網路安全部，當時 Linux 還不是主流，那時使用的是其他系統，比如 Hp-Unix，Aix 等，當時的使用率並沒有這麼普遍。隨著網際網路業務和開源技術的飛速發展，Linux 越來越普及了，為什麼？

有一個重要原因就是Linux上面的開源應用非常多，包括技術框架，業務選型的技術框架等等，現在基於 Linux 的應用越來越多，導致 Linux 作業系統在整個伺服器領域的應用越來越廣。

當然，這麼多的應用在 Linux 作業系統上使用，帶來的安全問題也越來越多，下面列出的是給安全人員帶來巨大挑戰的漏洞們：

• Struts2 遠端程式碼執行漏洞通告(CVE-2017-5638)
• Linux 核心提權漏洞(Dirty Cow) (CVE-2016-5195)
• ElasticSearch 遠端執行程式碼安全漏洞(CVE-2014-3120)
• Bash 遠端執行命令漏洞(Bash破殼) (CVE-2014-6271)
• Nginx 遠端執行程式碼安全漏洞(CVE-2014-0088)
• MongoDB 匿名登入漏洞
• 心臟流血漏洞

1.1 漏洞危害

著名的 Struts2，我印象中這幾年鬧了幾撥，每撥都有幾百人升級業務、修復補丁，幾乎都要求24小時內修復。我們曾經有一個很重要的業務修復 Struts2 的時候，業務不相容，版本不能上線，最後老大們決定暫停業務，直到修復為止，這說明這些漏洞給整個平臺帶來影響很大。

Dirty cow 漏洞也很出名，在這邊很多伺服器也會中招，是在2016年非常出名的提權漏洞，還有 elastic search的漏洞等等很多這樣的漏洞。

2016年比較火的 DDoS 勒索，這個業務天天 DDoS 打你，那個業務，天天 DDoS 打你，直到給“保護費”為止，有的業務一天給500，有的業務甚至一天給2000……

看來黑產也是“講理”的…

MongoDB 的勒索也是很火的，幾乎每種事件都可以造成勒索，這就是 Linux 下的安全形勢。

很多搞安全的人接觸比較多，比較熟悉的漏洞是心臟流血，還有這個著名的 Dirty cow 提權，本質是 Linux 的記憶體的寫許可權管理 bug，導致不具有寫許可權的程序寫入許可權。

2016年年底出名的事件，我們國家浙江一個廠商躺槍了。這種案例很多，殭屍物聯網“肉雞”把半個美國都打癱瘓了。

1.2 Linux下的安全挑戰

業務版本快速迭代、業務開放、網路邊界複雜、開源元件多元化、技術架構複雜、標準化和規範化缺乏等等，這些都是挑戰。

前面介紹了 Linux 的開源元件用得比較多，同時在 Server 端用得比較廣。這邊總結了為什麼 Linux 下的安全挑戰比較多，可能和傳統制造業有些區別。

對於網際網路公司來說業務版本迭代很快，要有很好的安全防禦的理解。比如認證機制要設計好，鑑權機制要完善，其實設計完善是不容易的。往往老闆的指標是一週上線，想設計好並沒有那麼多的時間。業務迭代版本過於頻繁也給安全帶來很大的挑戰。

網際網路業務本來就很開放，像以前在華為有明顯的網路邊界，內部都是內網，網路邊界很明顯。網際網路業務本來就是對外，所以這就造成了業務整個邊界外延，整個都是開放的。機房幾十上百個，整個網路都是對外開放狀態。

網路邊界的複雜，網際網路講求分散式部署、高可用，一般5個點、10個點、20個點。分散式部署帶來網路邊界過於複雜，交叉認證。

開源元件多元化，開源元件很多，五花八門，例如快取中介軟體，這個哥們兒用這個架構，另一個用那個架構，一個公司有十幾個架構。如果在你公司沒有達到一定高度的時候，標準化、規範化沒有很完善的情況下，就更加複雜，挑戰更大。

同樣業務端也很複雜，很多還有 Windows 端、移動端、Web端，各種各樣的業務。今天這個功能上線，明天那個功能下線，所以技術架構是一點點積累，想做很標準的技術架構也不容易。

由於前面的版本迭代、網路邊界等，帶來標準化、規範化都是滯後的，像 BAT 可能做得好一點，但多數公司的標準化、規範化還是不太健全。

1.3 實際生產問題

上圖展示的都是 Linux 安全挑戰真實的案例，都是實實在在的工作中遇到的安全問題。

對於普通運維團隊或者安全團隊可能都比較常見的，像伺服器資源被佔用，但是不知道是哪個程序佔用；發現某個程序佔用資源，但是卻殺不死，或者殺死一會兒又啟動，因為它有守護或者自動拉起。還有金鑰洩露，這個很常見。

有些人把金鑰放在郵箱或者伺服器什麼地方存著，如果他的辦公機被入侵，他的郵箱被撞破，他的金鑰就洩露了。金鑰洩露不是最慘的，而是金鑰的密碼和他的郵箱密碼或者是跟他什麼 CSDN 的密碼用同一個，這個更慘。

大家說這是小概率事件，但是一千人，千分之一的概率發生就入侵了。還有業務被掛馬，這是 Web 業務中很常見的；還有 Redis 快取突然失效，導致 MySQL 扛不住，整個業務直接癱瘓，而且擴容不了，我只是說有這種可能性。

如果你的業務使用 Redis 快取，而且 Redis 是預設匿名，如果真的有人做 APT 研究你們，把你的 Redis 都幹掉了，業務就癱瘓了，大公司可能很長時間都恢復不起來。

作業系統 OOM，很多人說伺服器怎麼又 OOM？前兩天才剛重灌，為什麼又 OOM？因為有一個木馬不斷提權，一提權就崩，所以肯定有 OOM，這也是實際過程中的一個案例。

2、Linux下的攻擊手段

2.1 攻擊方式

做防禦首先要了解進攻的方式。這是一個真實的案例，瞭解攻防的人可以看到，這是典型的 Linux 匿名，Redis 預設匿名登陸，不需要使用者名稱、密碼。

Redis 還有幾個奇怪的功能我可以分享一下：Linux 有一個功能可以通過一個埠寫到本地檔案，如果我要寫一個檔案，而這個檔案是木馬，那就自動拉起了。如果寫入自己簽名的公鑰，用自己的私鑰解公鑰，自己解自己的，所以直接替換公鑰，就是通過 Redis。

有人問，你怎麼記錄下來這些呢？其實很多攻擊者都會去清除掉日誌，我們需要想些辦法讓他不能清除，保證審計可追溯，否則入侵之後就追溯不出到底是什麼原因。

所以黑客用 Dirty cow 提權，黑客上來就把自己的操作清除掉了，不讓你看見。你知道他要清除，你就想辦法不讓他侵掉，不然追查不到。

其實他入侵你的伺服器不是最終目的，最終的目的是擴大戰果，最簡單的方式是監聽和收集相關的通訊，再做一些掃描之類。如果這些機器有關於運維體系的指令碼、域名，可能都危險了。

2.2 滲透方式

以前給外面做分享，都覺得你說的攻擊方式發生概率不是很高。不說真實案例，大家就覺得真實概率不是很高；有了真實案例，大家覺得小概率事件還是會發生。

Linux 下面滲透的方式有這麼幾個步驟：

• 首先掃描，他知道你IP是否存活，前端是否有防火牆；
• 掃描之後嘗試滲透，看有哪些埠的許可權是什麼；
• 接下來看通過開源的應用或者滲透方式怎麼入侵，有哪些東西可以利用；
• 入侵之後，普通賬號怎麼提權到 root，最後怎麼擴大戰果。

這是 Linux 常用的滲透，掃描之類的，大家可以試一下。

2.2.1 SSH暴力破解

在很多公司規範裡面，SSH 不允許對外開放，要開放給跳板機，這都是有目的的。換個埠，很多預設掃描是指定的 22，這樣可以減少被發現的概率。

如果 SSH 登陸只認跳板機也可以防止被撞庫。大家想一想你們自己的密碼，和在公司用的密碼，伺服器的密碼和私鑰密碼和網際網路的密碼有多少是相同的？比如12306、京東等都有可能相同，人家一旦洩露了，密碼就洩露。所以這個撞庫的概率不能避免，因此要應對暴力破解。

2.2.2 檢視歷史命令（histroy）

黑客侵襲你的伺服器之後，histroy 給他提供很多線索，所以你的帳號退出之後 histroy 要清掉。

2.2.3 Redis入侵實戰

上圖演示了怎麼通過 Redis 寫入反彈 shell，黑客常用這種案例。Redis 預設就是匿名，他信任可信客戶端。所以這種機制導致你在使用上要整合很多認證機制和訪問控制，否則會非常危險。另外這個功能都是可以關閉的，servers 可以不要寫的，相當於安全極限。

Redis 匿名，如果公司沒有統一的規範和標準，一般作為開發人員來說，直接 Redis 是匿名最簡單、最高效，所以Redis匿名漏洞在網際網路環境中非常多。PoC工具也非常多，基本直接淪陷。

2.2.4 提權演示

這是 Linux 的音效卡核心提權的漏洞，我介紹兩個提權，這是其中一個，從普通使用者提權到 root。這是我錄的視訊，可以看一下。

真實案例的提權和這個一樣，沒有太多區別。既然開啟這個視訊，再給大家看看 Dirty cow 的提權，這是2016年最火的提權漏洞，80%的 Linux 會淪陷。

剛才給大家演示了兩個視訊，這是提權的過程，從普通使用者怎麼提到 root的。這種怎麼防禦後面會有介紹。要及時修復這些補丁，不要以為提權影響不大，其實影響很大的。root 能幹的事和普通帳號能幹的事差別很大。

給大家演示了 Dirty cow 的提權，其實最關鍵的漏洞在於Linux裡有一個記憶體管理寫許可權的 bug，導致不該具有寫許可權的程序它寫進去了。

我們寫的程式碼，根本產生的原因是很多執行緒競爭資源的時候，Linux bug 出現的概率非常高。所以要寫很多的執行緒通入經營資源，這裡面還用了一些東西的注入，後面會有介紹。本來不具有寫一個 password 許可權的，但是 Linux 寫許可權產生 bug 的時候，會導致你可以寫進去。

2.2.5 程序注入

上圖演示的程式碼，我準備用 sinclude 注到這個裡面去，分別是兩個程序在跑。其實注入有幾個基本的，你要了解 Linux ELF 檔案格式，還有系統呼叫，還有 CPU 執行過程中的整個邏輯。

多執行緒之間的程序很關鍵，這個情況我現在遇到的不多，真正我們遇到被入侵事件中，核心態木馬的遇到不多，以前 Windows 有很多。我們自己有寫過這種木馬，所以這種情況我很少遇到過。只是之前在其他的領域確實遇到過幾次，所以給大家介紹這種。相當於 Windows 狀態下的一種木馬，在 Linux 情況下也存在，殺傷力還很大。

我介紹一下執行的原理，這些系統呼叫核心態的執行過程。你原來的執行過程是這樣的：我要把你 hook 掉，系統呼叫執行過程後我轉給你，無論是程序起用，檔案讀寫都被我控制了，可做的事情很多，而且隱蔽性很大很難找。

這是我們做的測試程式碼，首先建了目錄，目錄裡面寫了一些檔案進去，但是把核心態木馬加進去之後，你再進去，就沒有了。這種一般守護的時候比較有用，要隱藏木馬或者守護木馬檔案、程序檔案比較有用，你看不到的時候依然可以讀寫。

你明明在裡面 insmod 一個模組，但是看不到，它把你 insmod 核心模組 read 也給劫持了，所以你看不到它。

再演示一下這個程式碼，這很常見，伺服器中為什麼莫名其妙解析錯了？

Linux 有一個解析的配置，加了這個程式碼，其實我有注掉。但是載入了這個之後，我看的時候，普通運維人員、研發人員看不到。大家看百度還是會解到本地的，其實已經被本地劫持了，但是很難查。

我前面有介紹反彈喚醒的技術，一種是木馬主動向控制器去上報我自己的IP和埠，達到控制。

還有等待對方的喚醒，喚醒報文很講究，這個喚醒用 ICMP 報文載荷定製一個特殊的“key”報文，做一個特殊的字元喚醒。喚醒木馬，這是一個特殊的報文，完全可以喚醒我的木馬對那臺機器執行操作。“.168”這是典型的ICMP 喚醒的技術。再加上核心，應用很難發現。

3、Linux下的防禦對抗

我剛才介紹了很多 Linux 下的一些嗅探、注入、提權等機制。我們有針對性的瞭解這些機制，是為了保證業務穩定可靠的執行，肯定要有對應的防禦手段。

不管是否做到自動化，或者手動也好，總要有手段。不同的公司在不同的規模、不同的發展階段，策略不一樣。我先介紹一下我們現在的防禦想法、思路和進展情況。

3.1 立體防禦

漏洞掃描、入侵檢測、主動防禦、事件預警、行為審計、應急響應、標準規範等都是防禦策略。

我們防禦考慮不一定是通過某個環境，絕對的識別到這次入侵或者攔截到這次防禦。但是要層層設防，比如業務上線前，不可能像 CMMI 那種，有很多評審點，在網際網路公司裡面版本快速迭代，基本做不到CMMI的要求，沒有評審通過就不能上線，我覺得做不到。

如果真的拖慢了業務上線的速度，業務死了，安全團隊也沒有價值，所以，肯定是業務第一。

我覺得業務在上線的時候，我做非同步的時候做掃描，併發評估，儘可能不影響業務上線。包括 Redis 的匿名等，都可以做匿名，在構建的時候釋出一條線，還可以掃到另外一條線。

還有入侵檢測機制，被入侵的情況還是要有些預警或者防禦的手段。至少你要知道，全網可能幾百臺、幾千臺甚至幾萬臺伺服器，完全不知道狀況，那就沒辦法做後續相關的跟進了。

如果能做到更牛逼的防禦，比如主動防禦，這是大家最終的理想狀況，很多公司做不到。我曾經想過，木馬起動的時候，如果不在簽名的程序不讓它起，程式碼寫出來了，而且Demo 寫了但是不敢上線，因為我擔心出核心相容性問題，要背鍋，主動防禦這裡涉及到整個平臺的所有伺服器的相容，需要謹慎，是下一個里程碑。

所以我覺得有些東西可以做一些妥協。比如木馬檔案的自動化隔離，檢測是一條思路，如果主動防禦可以自動隔離掉，不讓有任何寫許可權、啟動許可權當然會更好。

預警，出了事情要知道，不要等到業務保障或者使用者投訴到客服。業務已經癱瘓了，你還不知道什麼原因？一查，好像兩臺伺服器被入侵，很多資料被刪了。所以要提前預警，優先於業務保障之前及時掌握安全狀況。

行為審計，剛才我介紹的入侵的案例，沒有行為審計。很多入侵事件不一定找到入侵路徑，很多同學出問題找不到原因最喜歡的是“重灌作業系統”。其實重灌並沒有任何意義，因為漏洞依然存在，重灌是沒有任何意義的，還是要想辦法溯源，找到入侵路徑在哪裡。

應急響應，要有應急響應的機制，因為你將來不是絕對安全，一定有漏洞，一定有弱點，每種方式要做出相應的預案。

規範化和標準化，不同公司發展階段不同，其實它程度也不一樣。

3.2 防禦實戰

3.2.1 漏洞掃描

我們這邊可能會有內部的自動化掃描，如果業務存在漏洞，會直接觸發一封郵件，要求24小時修復，給剩餘的修復時間。

相關的自動化預警，我們做得並不完善，只是把著名的開源軟體做到，其實我們還做不到那麼完善。

3.2.2 入侵檢測

入侵檢測，如果發現有可疑的程序，我們會直接預警出來，避免對業務造成影響。

3.2.3 行為模式審計

行為模式審計，這是我們發生入侵的事件，曾經有一個帳號，這個預警是把歷史資訊清掉。這對我們來說是很可疑的，最終是這個人的私鑰丟了，所以這就是一起突發安全事件。

我們這邊有惡意IP的識別，外掛、機器人之類的會收錄下來，你歷史上攻擊過我們或者衝擊我們服務的ip，我們會收錄下來。如果你服務和黑產進行通訊，我們都會預警。這裡面可能誤報，但是我們肯定會跟進這個事。

3.2.4 應急響應

剛才我提到應急響應要有應急預案。剛才講 DDoS 也是一樣，DDoS 一定有一個防禦的上限，比如120G，比如你併發處理能力是1萬，如果超過1萬，怎麼辦？到底是攻擊還是由於活動造成的陡增？都要有預案。對今天講的 Linux 的入侵，攻防，最主要入侵事件要找到入侵路徑。

即使找不到也要推出幾種可能性，而且這幾種可能性要有針對性的修復或者改進，否則你單純的重灌作業系統，我覺得完全沒戲，只是給後面安全問題留下更大的坑。

3.2.5 標準規範

規範化、標準化，這需要跟公司的企業文化、公司的發展階段，跟公司整體要搭。我們正在持續努力中，對我們來說推進挑戰也是很多，有些可以推，有些也不容易。

我們每出一次安全事件都借這個安全事件推動很多規範，以事件為導向推動安全規範相對容易一些。所以這需要下點功夫，而且要結合公司自己的運維體系、釋出體系、監控體系做這個事。

小結

安全永遠沒有絕對的安全，永遠存在漏洞。這時候你和業務一定要有平衡，不要為了絕對安全而影響業務。不能絕對說存在問題、存在風險，這個業務不能上線，這種決策還是要評估一下。

我覺得業務做起來，安全才有更大的機會，完全阻礙業務版本的迭代，其實安全也會有問題。畢竟業務發展起來，平臺大了，安全才有更大的產出。

另外就是效率，安全和效率永遠有衝突，你讓他登陸跳板機，伺服器不能交叉認證，再回跳板機，再跳伺服器，很多人就怒了。幾十上百臺伺服器天天維護，太麻煩了。

安全和效率之間的衝突，有些要做平衡，有些還是要堅持。需要持續的改進，我認為 PDCA 這種模型非常適合 Linux 的攻防對抗去持續改進、持續 check。

文章來自微信公眾號：高效運維