作者介紹

林偉壕，網路安全DevOps新司機，先後在中國電信和網易遊戲從事資料網路、網路安全和遊戲運維工作。對Linux運維、虛擬化和網路安全防護等研究頗多，目前專注於網路安全自動化檢測、防禦系統構建。

網路入侵前、進行中與入侵後的安全防禦應該屬於全程聯動、環環相扣的，所以對於伺服器的安全檢測與阻斷，筆者認為需要有一套統一的安全審計系統實現。這裡的“審計”，並非一種亡羊補牢式的補救，而是融合了威脅發現、威脅分析和威脅消除的“三位一體”的安全防禦體系。

本文將從安全審計的初心、設計理念、實現方式、應用和延伸等5個方面解析伺服器安全審計系統的設計與實現之路。

一、為什麼要安全審計

就像一套系統需要有埠監控、服務監控一樣的道理，我們需要在伺服器上派駐自己的“哨兵”，實時瞭解伺服器安全風險狀態。它不同於其它的運維監控agent，而是“專崗專用”，專門做安全監控，在效能消耗、功能、實現方式上都會有傳統的運維監控agent不同。那麼，安全審計能給我們帶來什麼？為什麼“非它不可”？

1伺服器資訊收集

試想，一般的伺服器監控程式只收集硬體資訊、系統性能、服務狀態等資料，至於機器上執行什麼作業系統核心、跑什麼程序、開什麼埠、有什麼使用者、有什麼crontab，絕大部分監控程式通常無法收集，而這些資訊卻又隨時可能告訴我們伺服器可能發生的安全風險或威脅。

2日誌收集

一般的日誌收集關注的是業務資料，比如訪問成功率、pv、uv等資料，但是隱藏在訪問日誌裡的攻擊資料，又往往淹沒在正常訪問中，這時通過常規的日誌收集、分析程式是無法發現入侵資料的。

另外一種情況，如果伺服器被入侵，運氣好時還能去伺服器查詢到攻擊日誌，運氣不好的話，攻擊者直接刪除history、syslog，這時要做入侵回溯難度立馬上了一個level，所以，必須有實時日誌轉發，安全應急響應或監控程式時才能通過分析日誌及時發現系統入侵痕跡或檢查到使用者su/sudo記錄是否合法，或者機器被黑、故障發生前都做了什麼操作。

3訪問控制檢查

伺服器上跑的服務千差萬別，種類繁多，基本上運維很難通過了解服務配置、埠開放情況，更別提視覺化檢查、管理訪問控制了。因此，需要專門對iptables和常見服務的訪問控制是否安全合理進行審計，最好通過作業系統或者應用安全基線制訂了配置模板後，通過對比發現訪問控制疏漏，結合外部漏洞掃描程式雙管齊下。

4漏洞本地檢測

2016年過去不久，“髒牛漏洞”席捲超過95%的Linux系統，讓普通使用者想提權就提權，這樣的核心級漏洞，即便是BAT也頭大，那麼問題來了，如何及時發現這種遠端檢測不出來的本地漏洞，或者軟體包存在漏洞未及時升級的問題，是不是也得靠伺服器內部的“安全哨兵”去主動發現呢？

5異常流量發現

如果有一天，你的伺服器半夜流量爆了，不是被DDoS，而是出現入向大流量，那是咋回事？很明顯機器被黑，淪為別人DDoS的肉雞，而你卻一臉懵逼，查了半天不知道怎麼被入侵的。有時候，即便有流量監控，也只是做入向監控，更有甚者，機器淪為肉雞，還是運營商找IDC機房找到的機器，直接拔網線，這事在CNCERT底下也不是沒發生過。

上面介紹了為什麼“非安全哨兵不可”的原因，於是有同學說要不我找個開源的安全監控程式裝一下。但是，這些開源的安全監控程式，就這麼跑到你的生產環境，你做了程式碼審計了麼，程式對系統性能消耗怎樣，它的監控報警機制能否跟企業現有的運維監控報警機制結合，而不是發封郵件？當你有幾臺伺服器的時候可以手工安裝，可是當你有幾千臺幾萬臺甚至十萬臺伺服器，也還是手工安裝嗎？萬一以後出了新版本要更新呢？

二、設計怎樣的安全審計系統

所以，安全審計系統是需要被重新定義與設計的：它需要結合企業現有的運維體系，融合已有的批量部署手段、監控報警方式，通過組織程式碼審計、效能測試之後才能引入企業生產環境。此外，一旦部署規模上去了，對系統的排程、效能的考慮就要上升到架構上了。如何從企業實際情況觸發，結合業界經驗，去構建一套符合自己的安全審計系統顯得很有必要。

筆者認為，一套稱得上企業級的安全審計系統，至少應該考慮下面幾個方面：

1功能

安全審計至少應該包含日誌審計和系統安全審計，日誌審計可以收集任意應用程式的日誌，系統安全審計可以獲取伺服器系統核心版本、程序狀態、埠開放情況、使用者和crontab任務資訊、已安裝的軟體包版本及其配置，通過自定義解析方式去格式化、清理資料，這個我們稱為資料清洗。之後，將資料傳送到統一儲存，建立索引，方便用於後續的分析，這個我們稱為資料儲存。最後，各種需求方從統一儲存提供的介面獲取資料，進行各個維度的分析，然後產生統一報告，這個我們稱為資料分析。

考慮到功能迭代的需要，從架構到元件上，安全審計系統都應該具備易擴充套件性。

2運維

為了大規模部署和升級，同時掌握各元件執行狀態，安全審計系統需要具備易部署、易升級的特點。

3效能

毫無疑問，安全日誌分析，也屬於大資料的一個應用範疇。為了保證對大資料量的實時或離線處理，系統設計應當具備前瞻性，資料處理的效能應當是基本保證。

此外，一套合格的安全審計系統，應當至少包括以下幾個元件：

Client：

• 需要考慮部署、更新以及資料收集分析呈現等；
• 需要考慮客戶端是要c/s架構還是別的方式：使用Crontab或者Daemon；
• 需要考慮自研還是使用開源的，如果沒有自研能力，就要採用具備豐富的社群支援和擴充套件性的開源實現方案。

Collector:

• 採集器要求高效能、高可用，在海量日誌面前，採集器的效能是重中之重，一旦發現數據丟失，或者高時延，後面的資料越積越多，“木桶效應”會極其明顯。

Storage:

• 海量資料儲存，儲存容量要大，IO效能要高。

Analyzer:

• 資料分析這部分，最主要的還是常見報表輸出，比如可以針對伺服器資訊進行統計，輸出一份整體分析表格，方便決策。

Scheduler

• 這麼多元件上的任務排程以及配置推送，需要有一個“大腦”進行管理。當然，每個元件本身也可能是一套子系統，它也有自己的排程層，這兩者沒有衝突，反而使系統具備層次性，降低了系統耦合度。

為了方便後面介紹如何實現安全審計系統，下面提供一個安全審計系統的簡單架構圖。

其中，日誌審計通過記錄使用者命令和關鍵的系統syslog並轉發給日誌接收端，系統安全審計通過本地資訊收集和漏洞掃描將伺服器安全狀態報告發送到相應接收端。

接收端進行處理分析後將關鍵資訊生成報表並根據報警規則觸發報警。

三、如何實現安全審計系統

通過上面的簡單架構圖，我們可以看到它的技術選型方案，上面提到的主要元件都有覆蓋。

這裡可能會有人問一個路線選擇的問題：自研還是開源？筆者認為，任何不做二次開發，結合企業實際情況的開源應用本地化，都是耍流氓。所以，從實現成本上看，建議經過前期的開源方案調研後，結合企業情況做二次開發，是為上策。

1安全審計工具：Client

說起開源安全審計工具，業界最知名的恐怕就是Cisofy主導的Lynis和社群主導的Ossec，兩者各有千秋，是否一定要2選1，筆者認為這個沒有統一答案。當然，在本文中，會有一個對比，然後給出建議。

系統安全審計

Lynis：*nix系統上使用Shell編寫的系統安全審計工具

安裝方式：

Debian：apt-get install lynis

Ossec：支援全平臺的主機入侵檢測系統

安裝方式：

Debian:apt-get install ossec-hids/ossec-hids-agent

Windows: ossec-win32/64-agent.exe

功能對比

Lynis工作原理

Ossec工作原理

client功能展示

Lynis

Ossec

通過上面的對比，相信大家會發現，論功能和平臺相容性，Ossec優於Lynis，支援Windows上，而且畢竟Ossec是C/S架構，作為HIDS的實時性也會更好。

但是，如果你想審計Ossec，它是C寫的；如果你不想在自己伺服器跑agent，可它偏偏要跑。你怎麼選？所以，按筆者考慮，為了充分利用兩者的功能，將Lynis的自定義性強、效能消耗低、純Shell指令碼的優勢和Ossec的跨平臺性與實時性結合起來，可以在不同平臺分別部署，這裡會有一個異構問題，但是別忘了，兩者對應的方案有一個交接點，就是Lynis+ELK和Ossec+ELK，我們可以按平臺部署，比如Windows上部署Ossec，Linux上部署Lynis，將資料統一發送到ELK，剩下的實時日誌分析、預警就交給ELK來做了。

日誌審計

不管是Windows還是Linux，它們都支援rsyslog，所以可以將各自日誌轉發到syslog。當然，Ossec本身就是支援Windows日誌審計的，所以這裡的日誌審計我們主要考慮Linux平臺，實現上很簡單，就是修改rsyslog與profile配置。

syslog配置：將指定Facility的syslog轉發

使用者行為日誌：記錄使用者執行命令

功能展示

下圖可看到使用者執行命令已被記錄並轉發：

上圖可以發現syn flooding攻擊報警，下圖可以發現kernel level的報警也被觸發，用於硬體報警也不錯呢。

2收集、儲存與分析：collector-storager-analyzer

ELK(Logstash-Elacsticsearch-Kibana)是目前日誌處理最著名的方案之一，因為方案開源而且功能非常豐富，同時有Elastic公司背後支援，前景非常不錯。這裡的日誌收集、儲存與分析就是用這套架構來實現。

核心功能：儲存、分析、展示系統

依賴：

logstash-2.3.2

elasticsearch-2.3.2

zookeeper

kafka

kibana_4.5.1

資料處理流圖：

下面是各種角色說明：

• Logstash：收集，分為shiper/receiver等多種角色
• ElasticSearch：儲存，支援實時查詢（索引）與api
• Kibana：UI，用於資料分析和展示
• Kafka：分散式訊息釋出訂閱系統，用於處理活動流資料和運營指標資料的訊息快取中介軟體
• ZooKeeper：排程，分散式應用程式可以基於它實現同步服務，配置維護和命名服務等

ELK效果展示

但是，這樣就夠了嗎？有沒有發現少了什麼？細心的讀者會發現在一開始的架構圖裡還有Hadoop的身影。那麼，為什麼要用Hadoop？

因為ELK的方案優勢在於事實日誌檢索，但是對於非實時的、可以離線分析的資料，其實並不需要一直放在ELK上，畢竟Kibana的前端效能並不怎麼好，我們可以另闢蹊徑，從Hadoop走出一條資料離線批處理，用於海量資料分析的新道路。

下面給出一個Hadoop的應用案例，結合Python的mrjob庫可以做自定義分析。

Hadoop離線分析日誌

from mrjob.job import MRJob

from mrjob.step import MRStep

import heapq

class UrlRequest(MRJob):

def steps(self):

return (MRStep(mapper=self.mapper,

reducer=self.reducer_sum

),

MRStep(reducer=self.reducer_top10)

)

Hadoop功能展示

3任務排程與後臺管理：Scheduler

Python+Flask+Bootstrap

這裡使用flask提供restful api供報告的增刪查改：

#根據name獲取資源中的某一個

@app.route(‘/language/<string:name>’)

#POST建立資源

@app.route(‘/language’, methods=[‘POST’])

#PUT，PATCH 更新資源

#PUT動作要求客戶端提供改變後的完整資源

#PATCH動作要求客戶端可以只提供需要被改變的屬性

#在這裡統一使用PATCH的方法

@app.route(‘/language/<string:name>’, methods=[‘PUT’, ‘PATCH’])

#DELETE刪除

@app.route(‘/language/<string:name>’, methods=[‘DELETE’])

由於Scheduler需要自己寫，為了做到高可用、高效能，建議使用HAProxy/Nginx+Keepalived的方案實現Scheduler，不需要程式碼上的支援，只是部署上使用wsgi加一層轉發而已。

下面以Nginx為例提供配置模板：

location / {

proxy_connect_timeout 75s;

proxy_read_timeout 300s;

try_files @uri @gunicorn_proxy;

}

location @gunicorn_proxy {

log_format postdata ‘$remote_addr – $remote_user [$time_local] ‘

‘”$request” $status $bytes_sent ‘

‘”$http_referer” “$http_user_agent” “$request_body”‘;

access_log /home/test/var/log/access.log  postdata;

proxy_read_timeout 300s;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header Host $http_host;

proxy_redirect off;

proxy_pass http://127.0.0.1:8001;

}

核心功能：排程系統展示

4運維工具：opsys

可以使用Puppet/Ansible/Saltstack，考慮到實時性和擴充套件性，建議使用Puppet或者Saltstack，Ansible更適合初始化等重複性較少的工作。

Puppet

把相關功能模組化，接入時只需要include相關類即可。

• lynis class：*nix系統安全審計
• logaudit class：日誌安全審計
• ossec class：windows系統安全審計

四、如何應用安全審計系統

1定期安全檢測報告

定期將伺服器審計報告發送給相關人員，讓他們保持對伺服器安裝態勢的瞭解。另外，如果發現了安全風險，也可以讓他們一併處理，形成一個良性的互動。

2檢測內容

危險命令報警

message:chattr OR message:”touch -r” OR message:”pty.spawn” OR message:”nc -l” OR message:”*etc*passwd” OR message:SimpleHTTPServer OR message:http.server OR message:”ssh -D” OR message:”bash -i” OR message:”useradd”

系統漏洞檢測：認證、檔案系統瀏覽、應用漏洞、啟動服務、防火牆、rsync服務、Webserver、資料庫、檔案系統許可權、核心檢查、SSH配置等。

3跟現有CMDB/運維監控結合

獲取漏洞機器IP、應用型別、歸屬資訊用於確定報警與檢查報告的分發

系統自監控與外部監控，用於保證系統自身的可用性和效能監控。

4與埠掃描、漏洞掃描結合

比如“髒牛漏洞”的批量檢測，可通過收集所有伺服器作業系統核心進行對比

5任意日誌分析

webserver access.log分析，從中發現SQL注入或者getshell的敏感語句，推薦方案有Nginx+Hadoop或者Nginx+ELK。

蜜罐日誌分析，在企業內外網部署蜜罐後，用來收集攻擊特徵庫，做情報收集。推薦方案有：Beeswarm+ELK。

五、延伸和擴充套件

1功能迭代

• 這套解決方案無疑在功能上屬於集大成者，但還需要優化使用者體驗、降低客戶端的異構性，這可以通過二次開發Lynis或者Ossec來實現。

• 是否推送修復補丁或者只提供修復方案。這個涉及到系統定位問題，本文一開始我們提到這套架構應該是“檢測+分析+阻斷”的“三位一體”方案，但現有的方案需要在檢測與分析之後人工去做阻斷，所以這套系統還需要進行擴充套件，比如與閘道器聯動，將符合攻擊特徵的資料流直接拋棄，或者與黑名單系統聯動，將自己發現的攻擊特徵上報黑名單系統，然後其他應用系統呼叫黑名單系統作為本地過濾的依據。這裡web應用可以使用web application firewall（WAF），db應用可以使用Mycat等db proxy進行流量攔截。

2構建安全知識庫

通過這套系統，我們會發現很多系統、應用級別的漏洞，如何高效修復漏洞會是下一個亟待解決的問題。解決方案就是依賴業界經驗和企業實戰經驗構建安全知識庫，提供統一的安全基線、安全配置模板以及漏洞修復方案。然後依賴企業自動化運維框架去推送配置、升級系統或者應用。

對於安全知識庫，之前我們可以用“某雲”（已停擺），現在可以去https://github.com/hanc00l/wooyun_public上下載離線知識庫進行研究。也可以結合公開的安全基線標準去構建自己的安全知識庫和配置模板。

當然，終極大法還是爬蟲：Python+Scrapy，通過搜尋引擎把你想要的知識庫爬取下來。也參考方案：http://www.cnblogs.com/buptzym/p/5320552.html

3結合威脅情報快速檢測和響應最新漏洞

毫無疑問，這套方案注重於內部風險發現或者是站在內部去發現問題，所要構建全面的安全風險與威脅防禦方案，還需要依賴外部掃描系統，還需要與CVE等公開漏洞庫進行聯動，甚至需要獲取最新的威脅情報資源，在類似之前的MongoDB勒索問題大規模爆發之前，提前做好防禦措施，不管是批量檢測應用配置，還是批量掃描系統，只要能提前做好準備，其實都是一種勝利。

所以下面就外部掃描系統、自建CVE庫和威脅情報收集提供一些解決方案，最終還是希望與這套伺服器安全審計系統進行聯動，實現安全風險與威脅的“檢測+分析+阻斷”的“三位一體”的目標。

• 外部掃描系統

  openvas：https://github.com/mikesplain/openvas-docker

• 自建CVE庫

  cve search：https://github.com/cve-search/cve-search

• 開源威脅情報

  OSTrICa：https://github.com/Ptr32Void/OSTrICa

這三套解決方案的具體應用會在以後的文章詳細介紹，結合企業應用場景來講，敬請期待。

參考資料

• OSSEC: http://ossec.github.io/
• FreeBuf: http://www.freebuf.com/articles/system/21383.html
• Lynis: https://cisofy.com/lynis/
• ELK: https://www.elastic.co/webinars/introduction-elk-stack
• PUPPET: https://puppet.com/
• wooyun_public: https://github.com/hanc00l/
• OPENVAS:https://github.com/mikesplain/openvas-docker
• OSTrICa:https://github.com/Ptr32Void/OSTrICa
• Mycat:https://github.com/MyCATApache/Mycat-doc

文章來自微信公眾號：DBAplus社群