1. <em id="vzzs9"></em>
      <tbody id="vzzs9"></tbody>

    2. <span id="vzzs9"></span>
      <progress id="vzzs9"></progress>
      首頁 網絡安全如何打造一個全程聯動、環環相扣的安全審計系統?

      如何打造一個全程聯動、環環相扣的安全審計系統?

      運維派隸屬馬哥教育旗下專業運維社區,是國內成立最早的IT運維技術社區,歡迎關注公眾號:yunweipai
      領取學習更多免費Linux云計算、Python、Docker、K8s教程關注公眾號:馬哥linux運維

      作者介紹

      林偉壕,網絡安全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

      功能對比

      如何打造一個全程聯動、環環相扣的安全審計系統?插圖1

      Lynis工作原理

      Lynis

      Ossec工作原理

      Ossec

      client功能展示

      Lynis

      client

      Ossec

      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轉發

      ‘echo \’kern.*;security.*;auth.info;authpriv.info;user.info @x.y.z.com:514 \’> /etc/rsyslog.d/logaudit.conf && /etc/init.d/rsyslog force-reload’

      用戶行為日志:記錄用戶執行命令

      ‘echo “export PROMPT_COMMAND=\'{ echo \”HISTORY:PID=\$\$ PPID=\$PPID SID=\$\$ USER=\${USER} CMD=\$( history 1 | tr -s [[:blank:]] |cut -d\” \” -f 3-100)\” ; } | logger -p user.info \'”> /etc/profile.d/logger_userlog.sh; source /etc/profile.d/logger_userlog.sh’

      功能展示

      下圖可看到用戶執行命令已被記錄并轉發:

      如何打造一個全程聯動、環環相扣的安全審計系統?插圖6

      如何打造一個全程聯動、環環相扣的安全審計系統?插圖7

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

      如何打造一個全程聯動、環環相扣的安全審計系統?插圖8

      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效果展示

      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功能展示

      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;

      }

      核心功能:調度系統展示

      如何打造一個全程聯動、環環相扣的安全審計系統?插圖12

      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與端口掃描、漏洞掃描結合

      比如“臟牛漏洞”的批量檢測,可通過收集所有服務器操作系統內核進行對比

      如何打造一個全程聯動、環環相扣的安全審計系統?插圖13

      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社群

      本文鏈接:http://www.abandonstatusquo.com/21992.html

      網友評論comments

      發表評論

      您的電子郵箱地址不會被公開。

      暫無評論

      Copyright ? 2012-2022 YUNWEIPAI.COM - 運維派 京ICP備16064699號-6
      掃二維碼
      掃二維碼
      返回頂部
      久久久久亚洲国内精品|亚洲一区二区在线观看综合无码|欧洲一区无码精品色|97伊人久久超碰|一级a爱片国产亚洲精品