Go to Qiita Advent Calendar 2024 Top
LoginSignup
406
401

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

@MahoTakara(Maho Takara)

コンテナ・セキュリティ入門 脆弱性

Last updated at Posted at 2019-10-10

コンテナイメージのレジストリでは、脆弱性検査の実装が当たり前になっている。企業でKubernetesなどコンテナを使用するにあたって脆弱性対策がどれほど重要なものか理解するために、脆弱性検査や、関連する国際的な標準について整理した。

脆弱性（ぜいじゃくせい）とは

脆弱性とは、プログラムの動作の不備を悪用される情報セキュリティ上の弱点である。つまり、ソフトウェア上の問題が原因となって生じた欠陥であり、セキュリティホールとも呼ばれる。当然、ソフトウェア開発者は、脆弱性を産まないように細心の注意を払ってコード開発を進めるが、開発者が利用するオペレーティングシステムのライブラリやパッケージに含まれることもある。そのような事情から、開発者の責任範囲外に原因がある場合も多くある。

潜在的な脆弱性を突いた新たなクラッキングの手口が、時間の経過ともに発見される。そのことから、開発当初はコードに脆弱性は無いとされていても、時間経過とともに、新たな手口が発見され、継続的に対策が必要となる。

脆弱性が残されたソフトウェアを稼働させ続けると、脆弱性を突いた不正アクセスによって、データ漏洩やサービス停止などのリスクが高まる。例えば、知的財産の流出、お金の財産の不法取得、情報の改ざんなどが発生して、取引上の信用を失うなど、企業が大きな損害を被る結果となる。

例えば、インターネットとサーバーを接続する部分のファイアウォールなどで、不要なTCPポートの通信を遮断しているからといって、安心と考えてはいけない。アプリケーションのサービス提供用に外部に公開したポートへのアクセスを悪用して攻撃するためである。別の言い方をすると、ファイアウォールで通信を許可したポートを悪用して不正アクセスを実施するため、ソフトウェアの脆弱性対策は避けることができない。

脆弱性が発見されると、ソフトウェアの開発メーカー、オープンソースプロジェクトのコミュニティ、そして、OSSディストリビューターが、対策済みコードやパッケージを準備して配布する。その様なコードやパッケージが、リリースされたら、出来るだけ早い時期に適用して、脆弱性を取り除くことが望ましい。

近年はゼロデイ攻撃と呼ばれる脅威が増加する傾向にある。これは、対策済みプログラムを配布するまでの間に攻撃を展開するもので、脆弱性が公開されてから、メーカーやOSSコミュニティが修正プログラムを開発する事も多いため、公表された脆弱性の内容を確認して、対策が完了するまで監視などを強化するなど、注意が必要である。

コンテナは、OSのライブラリやパッケージなどから構成されるため、これまで通り脆弱性対策を実施するべきである。

脆弱性に関する国際的な標準

脆弱性が生じる原因は、様々であり、コードを開発するコミュニティや開発会社が、連携して対策する時に、問題の対象を区別して、問題の重大度、分類などを一致させるために、CVE、CVSS、CWEといった標準が利用される。ここではそれらについて整理する。

CVEとは

CVEは、Common Vulnerabilities and Exposures の略で、日本では、「独立行政法人 情報処理推進機構 セキュリティセンター」によって「共通脆弱性識別子CVE」として扱われている。これは組織的にセキュリティを改善するために、ソフトウェアまたはファームウェアの脆弱性の特定とカタログした無料の辞書である。これは 1999年に、連邦政府が後援する研究開発センターが運営するMITREによって開始された、非営利プログラムである。辞書の目的は、既に摘発された脆弱性の識別を標準化することである。つまり、CVE-IDを利用して、複数の技術的な情報源の間で、問題とする脆弱性を識別できる様にすることである。

CVSSとは

CVSSは、脆弱性に対するオープンで汎用的な評価手法であり、ベンダーに依存しない共通の評価方法を提供する。CVSSを用いると、脆弱性の深刻度を同一の基準で定量的に比較できる。また、ベンダー、セキュリティ専門家、管理者、ユーザ等の間で、共通の言葉で議論できる。

CWEとは

CWEは多種多様な脆弱性の種類を脆弱性タイプとして分類、それぞれCWE識別子（CWE-ID）を付与して階層を体系化する。上位層に近いほど抽象的な脆弱性タイプを表す。反対に、下位層にいくほど具体的な脆弱性タイプや個々の脆弱性を表す。
脆弱性タイプは、ビュー（View）、カテゴリー（Category）、脆弱性（Weakness）、複合要因（Compound　Element）の4種類に分類される。

参考資料

イメージに脆弱性が発見された時の対策

コンテナ・イメージに含まれるモジュールには、脆弱性を減らす努力が絶え間なく続けられ、改善されている。一度ビルドしたコンテナ・イメージも時間が経つごとに、脆弱性をもつモジュールが発見される。脆弱性に対する対策は、対策済みモジュールにアップデートしてコンテナ・イメージを再ビルドする事である。

信頼の置けるイメージの選択

コンテナに含まれるコードは、セキュリティにとって重要である。コンテナのイメージの大部分は、Linux OS、Webサーバー、SQLデータベース、プログラミング言語などのオープン・ソースのパッケージであり、それら各OSSプロジェクトはコンテナのイメージでも配布するため、利用者自身でイメージをビルドする必要も無い。しかし、外部の情報源からコードをダウンロードする際と同様に、コンテナ・イメージの提供元、作成者、そして、内部に悪質なコードが含まれないか確認しなければならない。

  • ベースイメージ、OSパッケージ、プログラム言語のパッケージ、アプリケーションのコードは、コンテナの実行環境にセキュリティの脅威を持ち込まないか？
  • アプリケーションが利用しているライブラリやモジュールなどは、最新であり、脆弱性は無いか？
  • OSなどのベースイメージ、ミドルウェアは最新を使用しており、脆弱性は無いか？
  • コンテナ・イメージの更新頻度は把握しているか、更新されたことを知る方法はあるか？

過去発見された攻撃の例

コンテナに含まれる脆弱性には、どのようなものがあるか理解しておく事は、重要性を理解して対策する上で大切な事である。そこで、過去発見された脆弱性の問題について挙げる。

Drown攻撃

DROWNと名付けられた脆弱性を悪用すると、攻撃者はTLS暗号化を解除し、パスワード、クレジットカード番号、企業秘密、財務データなどの機密通信を読み取ったり盗んだりできる、2016年3月の公開時に、ある測定では、すべてのHTTPSサーバーの33％が攻撃に対して脆弱であった。その後、修正プログラムの適用が進み、2019年現在、SSL LabsはHTTPSサーバーの1.2％が脆弱であると推定されている。

Dirty Cow攻撃

Dirty COWの脆弱性は、2007年9月からLinuxカーネルに存在し、2016年10月に発見および悪用された。この脆弱性は、Androidを含むすべてのLinuxベースのオペレーティングシステムに影響し非常に深刻。攻撃者はこの脆弱性を悪用してルート権限を取得できる。この脆弱性は、Linuxカーネル内のコピーオンライトのコードに存在する。コピーオンライト(Copy-On-Write)とは、最適化戦略の一つで、大きなデータの複製を要求されても、読み取り（Read)の間は、実際に何もせず複製元のデータを参照する。そして、データの書き換え（Write)が発生した時にコピーして書き換える。もし、複製しても書き換えが発生せずに解放してしまえば、メモリ領域の確保とメモリ上のデータのコピーの処理コストが無駄になってしまう。そこで、前述の様な戦略的な処理によって、処理速度を向上させ、CPU時間を抑えることができる。詳しくは、以下のリンクを参照されたい。

glibc脆弱性

glibcは、「GNU Project」による標準ライブラリlibcの実装である。libcはC言語の標準ライブラリ名であり、システムコールを始めとする基本的な部品を集めたライブラリである。C言語で書かれたプログラムの殆どがlibcを利用している。
そして、glibcは、libcを基に大幅に機能を追加したもので、UNIXが持つ特徴を継承したLinuxでは、glibcはLinuxシステムの根幹をなす。glibcはISO C、POSIX、Unix98の各標準にほぼ完全に準拠し、国際化APIも整っている。
この様な、過去からの経緯を持った glibc には、これまで数多くの脆弱性が発見されており、次のリンクから、脆弱性のリスト、CVE-ID, CWE-ID, Scoreなどを参照できる。2019年において発見されたものも少なくない事に注目しなければならない。

脆弱性データベース

脆弱性が発見されると、SE製品を開発や流通する各組織の脆弱性データベースに登録される。MITRE(マイター)は、米国政府の支援を受けた非営利の研究団体の名称で、CERT/CCやHP、IBM、OSVDB、Red Hat、Symantecなど80を超える主要な脆弱性情報サイトと連携して、脆弱性情報の収集と、重複のないCVEの採番に努めている。

アメリカ国立標準技術研究所 NISTが 管理している脆弱性情報データベース NVD がある。NVDは、CVEで採番された脆弱性情報の詳細情報をNVDで提供する。そして、CVSSによる危険度の採点が明記されていることが特徴である。

CVEにはCVE互換認定の制度があり、脆弱性検査ツールや脆弱性対策情報提供サービス等がCVE識別番号の正確な表示などと、他の機能要件を満たし、MITREへ申請するとCVE互換認定が受けられる。認定を受けると、CVEのロゴが使用でき、認定サイトのリストに掲載される。

日本では、JVN、JVN iPedia、MyJVNがCVE互換認定を受けている。

Red Hat の脆弱性データベースは、Red Hat Product Errataにあり、XMLなどのメタ情報として提供される。このデータの分類としてアドバイザリータイプ RHSA に脆弱性対応が含まれる。タイプ RHSA、RHBA、および RHEA アドバイザリーの説明がある。

脆弱性スキャン

脆弱性スキャナによって、既知の脆弱性を含むパッケージがコンテナ・イメージに含まれるか検査できる。しかし、この様なツールで全ての脆弱性が見つかるわけではないから過信は禁物である。一方、検査の結果で問題がリポートされても、必ずしもただちに対応しなければならない問題ではない。例えば、次の様な理由が考えられる。

  • 報告された脆弱性の有する機能を利用していないケース
  • コンテナ化している場合、必要最小のプロセスだけ動かすため、実用上問題が無い脆弱性であるケース
  • Linuxディストリビューター(Red Hatなど）が、バックポートして修正プログラムを提供しているケース

誤検知も検知されない事もあり得るので、脆弱性スキャナーを過信せず、依存するパッケージを減らすなど、コンパクトなイメージを作るのが望ましい。そうする事で、脆弱性を含む可能性を減らし、誤検知に時間を費やす時間を減らせる。

脆弱性スキャナー

様々なオープンソースのスキャナーや商用サービスが有るので、代表的と思われるものについて、以下にまとめる。

Docker Bench for Security

Docker Bench for Securityは、Dockerコンテナを本番環境にデプロイするために適切な一般的ベストプラクティスをチェックするスクリプト、検査はすべて自動化され、その内容は CIS Docker Benchmark v1.2.0の影響を受けている。これはコンテナ・イメージで提供されるので、誰でも簡単にdockerコンテナを評価でる。

このツールは、Dockerホストで実行して、Dockerホストの構成と稼働中のコンテナなどを検査するもので、次は、Kubernetesのマスターノードで実行した例である。分野ごとにシェルスクリプトが検査して、結果が表示される。

root@master:~# docker run -it --net host --pid host --userns host --cap-add audit_control \
>     -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
>     -v /etc:/etc:ro \
>     -v /usr/bin/docker-containerd:/usr/bin/docker-containerd:ro \
>     -v /usr/bin/docker-runc:/usr/bin/docker-runc:ro \
>     -v /usr/lib/systemd:/usr/lib/systemd:ro \
>     -v /var/lib:/var/lib:ro \
>     -v /var/run/docker.sock:/var/run/docker.sock:ro \
>     --label docker_bench_security \
>     docker/docker-bench-security
# ------------------------------------------------------------------------------
# Docker Bench for Security v1.3.4
#
# Docker, Inc. (c) 2015-
#
# Checks for dozens of common best-practices around deploying Docker containers in production.
# Inspired by the CIS Docker Community Edition Benchmark v1.1.0.
# ------------------------------------------------------------------------------

Initializing Tue Oct  8 00:25:51 UTC 2019

[INFO] 1 - Host Configuration
[WARN] 1.1  - Ensure a separate partition for containers has been created
[NOTE] 1.2  - Ensure the container host has been Hardened
[INFO] 1.3  - Ensure Docker is up to date
[INFO]      * Using 18.06.1, verify is it up to date as deemed necessary
[INFO]      * Your operating system vendor may provide support and security maintenance for Docker

< 中略 >  
## ここから、コンテナに実行状態が検査され、5.6では ssh が動いていないことが検査されている

[INFO] 5 - Container Runtime
[PASS] 5.1  - Ensure AppArmor Profile is Enabled
[PASS] 5.2  - Ensure SELinux security options are set, if applicable
[WARN] 5.3  - Ensure Linux Kernel Capabilities are restricted within containers
[WARN]      * Capabilities added: CapAdd=[NET_ADMIN] to k8s_kube-flannel_kube-flannel-ds-amd64-jg7jv_kube-system_13b64578-419d-49c6-a8e4-9f75be3e51de_0
[WARN] 5.4  - Ensure privileged containers are not used
[WARN]      * Container running in Privileged mode: k8s_kube-proxy_kube-proxy-f9xlx_kube-system_19248345-58a8-48f1-b0f5-b9e67e2a1219_0
[PASS] 5.5  - Ensure sensitive host system directories are not mounted on containers
[PASS] 5.6  - Ensure ssh is not run within containers

< 中略 >

[INFO] 6 - Docker Security Operations
[INFO] 6.1  - Avoid image sprawl
[INFO]      * There are currently: 9 images
[INFO] 6.2  - Avoid container sprawl
[INFO]      * There are currently a total of 19 containers, with 17 of them currently running

< 中略 >

[INFO] Checks: 105
[INFO] Score: 9

参考リンク

GitHub docker/docker-bench-security, https://github.com/docker/docker-bench-security

Clair (クレア/フランス語読みではクレール)

CoreOS (現 Red Hat) によって開発された Clair は、コンテナの脆弱性を静的に検査する。Clair は CNCFのプロジェクトの一つとして活動している。

Clair 主要な機能は以下２つである。

  • Clairは、Debianセキュリティバグトラッカー、Ubuntu CVEトラッカー、Red Hatなど、インターネット上の脆弱性情報のデータベースから既知の脆弱性情報を取得して、PostgreSQLに格納する。

  • Clairは、ファイルシステム上のコンテナイメージに、どのような OS やパッケージを含んでいるか読み取り、前述の脆弱性情報とを照合して、イメージの脆弱性レポートを作成する。

参考資料に書かれた記事から、Clairは何ができないのかを紹介する。

  • ソフトウェアそのものは解析しない：　Clair は ソフトウェアを管理している dpkg や rpm 等のパッケージ管理システムのファイルを解析
  • パッケージ管理されていないソフトウェアの脆弱性を検出しない： Clair が脆弱性を検出するのは、dpkg や rpm 等のパッケージマネージャーでインストールされたものに限られる。例えば、tarファイルをダウンロードして展開してソフトウェアは、スキャン対象にならず脆弱性も検出され無い。
  • 未知の脆弱性を検出しない： Clair が検出できるのは、CVE等で公開されている既知の脆弱性のみ。
  • GUIを提供しない：　Clair は コマンドで起動、設定ファイルはエディタで編集、操作は REST API で実行
  • 脆弱性を修正しない： Clair は、脆弱性の修正されたバージョンを教えるが、更新はしない。

Docker Hub に似た パブリックコンテナ・レジストリ Quay.io にも使用されている。
また、GitLabで、コンテナの脆弱性検査にも利用でき、設定例 https://docs.gitlab.com/ee/ci/examples/container_scanning.html が公開されている。

Clair の クライアントツールとして、clairctl, klar, reg, clair-scannerがあり、VMwareのHarborもClairクライアント として動作する。

参考リンク

Anchore (アンカー)

CVEデータとユーザー定義のポリシーを使用してコンテナーのセキュリティを検査するためのツールである。

アンカーエンジンは、オープンソースプロジェクトである。アンカーエンジンは、コンテナイメージの監査、分析、認定などの集中サービスを提供する。アンカーエンジンは、Dockerコンテナイメージとして提供され、単独、または Kubernetes や Doccker Swarm などのオーケストレーション環境で、実行できる。そして、ユーザーはRESTful API あるいは アンカーCLI を利用して、アンカーエンジンを操作できる。

ユーザーの環境でアンカーエンジンをデプロイすると、コンテナレジストリからイメージがダウンロードされ、ユーザーがカスタマイズ可能なポリシーによって、分析、評価され、セキュリティ、コンプライアンス、およびベストプラクティスの実施がチェックされる。

アンカーエンタープライズとアンカーエンジンの違い

アンカーエンタープライズは、オープンソースのアンカーエンジンに加えて以下のサポートする。

  • 可視化、ポリシー編集、レポート生成、ユーザー管理、プログラミング言語 Python, Ruby, Nodejs,
    Java のライブラリやパッケージの脆弱性データのフィード
  • APIのRBACサポート
  • 脆弱性とパッケージ・メタ情報の全てを供給するサービス
  • レッドハット、Debianなど情報源から脆弱性データの全てを、分析エンジンへ与える
  • インターネットと接続しない構築
  • 商用サポート 24時間/7日間 または 8時間x週5日

特に、企業向けのLinux利用で、レッドハットを利用する場合に、アンカーエンタープライズは有用と思う。

アンカーエンジンのユースケース

ユーザーの環境にアンカー・エンジンをデプロイすると、コンテナイメージは、レジストリからダウンロードされ、分析される。ユーザーがカスタマイズ可能なポリシーを評価して、セキュリティ、コンプライアンス、およびベストプラクティスの実施チェックを実行する。

CI/CDツールから、アンカーエンジンを RESTful API または、anchor-cli を実行して、コンテナビルド後に、自動的に脆弱性を検査することで、問題の早期発見が可能となる。これは必須のワークフローになると思う。

アンカーエンジンによる脆弱性検査の例

Kubernetesで試すより、Docker-Composeは簡単なので、簡易的な手法として実施する。筆者の環境では、アンカーエンジンを1時間くらい動かすとmacOSのDockerエンジンが応答を返さなくなり、Dockerの再起動が必要となる不安定な状態となった。単にメモリの割り当てが足りないと思うけど、本格的に利用するには、Kubernetesクラスタ上で、CICDと一緒に利用するのが望ましいと思われる。

まず最初に、Docker-Compose の YAML をコピーするためのディレクトリを作成して、アンカーエンジンのコンテナを実行して、コンテナの内部から、ローカルに Docker-Compose のYAMLファイルをコピーする。そして、使用済みのコンテナを削除する。

$ mkdir anchor
$ cd anchor
$ docker pull docker.io/anchore/anchore-engine:latest
latest: Pulling from anchore/anchore-engine
c8d67acdb2ff: Pull complete 
<中略>
Status: Downloaded newer image for anchore/anchore-engine:latest
docker.io/anchore/anchore-engine:latest

$ docker create --name ae docker.io/anchore/anchore-engine:latest
47b152d2427862c5ad9c7853b0e32a58e0ae5040224531af7de2e086182cdf65

$ docker cp ae:/docker-compose.yaml ~/work3/anchor/docker-compose.yaml
$ docker rm ae
ae

docker-composeコマンドでアンカーエンジンのシステムを起動する。

$ ls
docker-compose.yaml

$ docker-compose pull
Pulling anchore-db           ... done
Pulling engine-catalog       ... done
Pulling engine-analyzer      ... done
Pulling engine-policy-engine ... done
Pulling engine-simpleq       ... done
Pulling engine-api           ... done

$ docker-compose up -d
Creating network "anchor_default" with the default driver
Creating volume "anchor_anchore-db-volume" with default driver
Creating volume "anchor_anchore-scratch" with default driver
Creating anchor_anchore-db_1 ... done
Creating anchor_engine-catalog_1 ... done
Creating anchor_engine-simpleq_1       ... done
Creating anchor_engine-api_1           ... done
Creating anchor_engine-analyzer_1      ... done
Creating anchor_engine-policy-engine_1 ... done

起動を確認しておく。

$ docker-compose ps
            Name                           Command                       State                   Ports         
---------------------------------------------------------------------------------------------------------------
anchor_anchore-db_1             docker-entrypoint.sh postgres    Up                      5432/tcp              
anchor_engine-analyzer_1        /docker-entrypoint.sh anch ...   Up (health: starting)   8228/tcp              
anchor_engine-api_1             /docker-entrypoint.sh anch ...   Up (health: starting)   0.0.0.0:8228->8228/tcp
anchor_engine-catalog_1         /docker-entrypoint.sh anch ...   Up (health: starting)   8228/tcp              
anchor_engine-policy-engine_1   /docker-entrypoint.sh anch ...   Up (health: starting)   8228/tcp              
anchor_engine-simpleq_1         /docker-entrypoint.sh anch ...   Up (health: starting)   8228/tcp              
imac:anchor maho$ docker-compose exec engine-api anchore-cli system status
Service analyzer (anchore-quickstart, http://engine-analyzer:8228): up
Service policy_engine (anchore-quickstart, http://engine-policy-engine:8228): up
Service simplequeue (anchore-quickstart, http://engine-simpleq:8228): up
Service apiext (anchore-quickstart, http://engine-api:8228): up
Service catalog (anchore-quickstart, http://engine-catalog:8228): up

Engine DB Version: 0.0.11
Engine Code Version: 0.5.0

アンカーエンジン起動直後は、脆弱性データを持っていないので、ダウンロードが始まる。今回は簡単に試すために、docker-composeで立ち上げたコンテナから、anchore-cliコマンドを実行する簡易的な手段を選ぶ。

$ docker-compose exec engine-api anchore-cli system feeds list
Feed                   Group                  LastSync                          RecordCount
nvdv2                  nvdv2:cves             None                              0
vulnerabilities        alpine:3.10            2019-10-08T14:48:49.756530        1485
vulnerabilities        alpine:3.3             None                              0
vulnerabilities        alpine:3.4             None                              0
vulnerabilities        alpine:3.5             None                              0
vulnerabilities        alpine:3.6             None                              0

筆者の環境で、約1時間で脆弱性データのダウンロードが完了した。このアンカーエンジンは無料版なので、RHELなど、サポートにサブスクリプション契約が必要なものが含まれない。CentOS, Debian, Ubuntu などに限られることが解る。

imac:anchor maho$ docker-compose exec engine-api anchore-cli system feeds list
Feed                   Group                  LastSync                          RecordCount
nvdv2                  nvdv2:cves             None                              0
vulnerabilities        alpine:3.10            2019-10-08T14:48:49.756530        1485
vulnerabilities        alpine:3.3             2019-10-08T14:48:55.240451        457
vulnerabilities        alpine:3.4             2019-10-08T14:49:02.902517        681
vulnerabilities        alpine:3.5             2019-10-08T14:49:12.996332        875
vulnerabilities        alpine:3.6             2019-10-08T14:49:25.639193        1051
vulnerabilities        alpine:3.7             2019-10-08T14:49:40.640122        1253
vulnerabilities        alpine:3.8             2019-10-08T14:49:56.309720        1335
vulnerabilities        alpine:3.9             2019-10-08T14:50:14.736434        1428
vulnerabilities        amzn:2                 2019-10-08T14:50:25.915568        224
vulnerabilities        centos:5               2019-10-08T14:50:59.159077        1325
vulnerabilities        centos:6               2019-10-08T14:51:37.040844        1355
vulnerabilities        centos:7               2019-10-08T14:52:13.030123        898
vulnerabilities        centos:8               2019-10-08T14:52:18.913897        76
vulnerabilities        debian:10              2019-10-08T14:56:14.448113        21268
vulnerabilities        debian:11              2019-10-08T14:59:53.728597        17984
vulnerabilities        debian:7               2019-10-08T15:03:29.329481        20455
vulnerabilities        debian:8               2019-10-08T15:07:37.040421        22575
vulnerabilities        debian:9               2019-10-08T15:11:44.730702        21438
vulnerabilities        debian:unstable        2019-10-08T15:16:01.736180        22314
vulnerabilities        ol:5                   2019-10-08T15:16:44.124014        1239
vulnerabilities        ol:6                   2019-10-08T15:17:39.418314        1456
vulnerabilities        ol:7                   2019-10-08T15:18:28.390050        1038
vulnerabilities        ol:8                   2019-10-08T15:18:32.804512        68
vulnerabilities        ubuntu:12.04           2019-10-08T15:21:09.029691        14948
vulnerabilities        ubuntu:12.10           2019-10-08T15:22:05.408912        5652
vulnerabilities        ubuntu:13.04           2019-10-08T15:22:39.667026        4127
vulnerabilities        ubuntu:14.04           2019-10-08T15:25:51.886441        19685
vulnerabilities        ubuntu:14.10           2019-10-08T15:26:41.300071        4456
vulnerabilities        ubuntu:15.04           2019-10-08T15:27:41.424339        5831
vulnerabilities        ubuntu:15.10           2019-10-08T15:28:49.917239        6513
vulnerabilities        ubuntu:16.04           2019-10-08T15:32:06.318408        16802
vulnerabilities        ubuntu:16.10           2019-10-08T15:33:23.158525        8647
vulnerabilities        ubuntu:17.04           2019-10-08T15:34:40.605672        9157
vulnerabilities        ubuntu:17.10           2019-10-08T15:35:45.769257        7935
vulnerabilities        ubuntu:18.04           2019-10-08T15:37:20.472998        11054
vulnerabilities        ubuntu:18.10           2019-10-08T15:38:27.803139        8392
vulnerabilities        ubuntu:19.04           2019-10-08T15:39:24.065979        7593

アンカーエンジンによる脆弱性検査

脆弱性検査したいイメージを、レジストリから追加する。これも簡易的にコンテナ内で anchor-cli を実行する。

$ docker-compose exec engine-api anchore-cli image add docker.io/maho/web-nginx:11
Image Digest: sha256:e393398ce2cb232ee15104079dc5fe91cbd985ca013a4898816b628fbce7d9b8
Parent Digest: sha256:e393398ce2cb232ee15104079dc5fe91cbd985ca013a4898816b628fbce7d9b8
Analysis Status: not_analyzed
Image Type: docker
Analyzed At: None
Image ID: 359128981386754efdc61ed716b4f69544725e0554388d8046f1ceac2ae27062
Dockerfile Mode: None
Distro: None
Distro Version: None
Size: None
Architecture: None
Layer Count: None

Full Tag: docker.io/maho/web-nginx:11
Tag Detected At: 2019-10-08T22:21:27Z

イメージのリストを表示する。事前に、debian:7とdebian:8も追加していたので３つ表示された。analyzedと表示され、脆弱性検査が完了していることが読み取れる。

$ docker-compose exec engine-api anchore-cli image list
Full Tag                              Image Digest                                                                   Analysis Status        
docker.io/library/debian:7            sha256:81e88820a7759038ffa61cff59dfcc12d3772c3a2e75b7cfe963c952da2ad264        analyzed               
docker.io/library/debian:8            sha256:9bdad8283833c08697a4de37c6eb0e281598c0e47d09d8b3e1113b7137e27e38        analyzed               
docker.io/maho/web-nginx:11           sha256:e393398ce2cb232ee15104079dc5fe91cbd985ca013a4898816b628fbce7d9b8        analyzed

筆者が数ヶ月前にビルドしたNGINXのコンテナイメージの脆弱性検査のレポートをリストしてみる。脆弱性IDと詳細を説明したURLが表示されている。これは確かに有用なツールだ。コマンドとして脆弱性レポートを取れるのと、anchore-cli image wait とすることで、イメージの登録後、脆弱性検査が完了するまで、待機させることができるので、Jenkins の設定に追加することも簡単だ。

$ docker-compose exec engine-api anchore-cli image vuln docker.io/maho/web-nginx:11 all
Vulnerability ID        Package                                 Severity          Fix                      CVE Refs        Vulnerability URL                                                   
CVE-2018-20843          libexpat1-2.2.0-2+deb9u1                High              2.2.0-2+deb9u2                           https://security-tracker.debian.org/tracker/CVE-2018-20843          
CVE-2019-11068          libxslt1.1-1.1.29-2.1                   High              1.1.29-2.1+deb9u1                        https://security-tracker.debian.org/tracker/CVE-2019-11068          
CVE-2019-1547           libssl1.1-1.1.0j-1~deb9u1               Low               1.1.0l-1~deb9u1                          https://security-tracker.debian.org/tracker/CVE-2019-1547           
CVE-2019-11038          libgd3-2.2.4-2+deb9u4                   Medium            2.2.4-2+deb9u5                           https://security-tracker.debian.org/tracker/CVE-2019-11038          
CVE-2019-13117          libxslt1.1-1.1.29-2.1                   Medium            1.1.29-2.1+deb9u1                        https://security-tracker.debian.org/tracker/CVE-2019-13117          
CVE-2019-13118          libxslt1.1-1.1.29-2.1                   Medium            1.1.29-2.1+deb9u1                        https://security-tracker.debian.org/tracker/CVE-2019-13118          
CVE-2019-13627          libgcrypt20-1.7.6-2+deb9u3              Medium            None                                     https://security-tracker.debian.org/tracker/CVE-2019-13627          
CVE-2019-1543           libssl1.1-1.1.0j-1~deb9u1               Medium            1.1.0k-1~deb9u1                          https://security-tracker.debian.org/tracker/CVE-2019-1543           
CVE-2019-1563           libssl1.1-1.1.0j-1~deb9u1               Medium            1.1.0l-1~deb9u1                          https://security-tracker.debian.org/tracker/CVE-2019-1563           
CVE-2019-15903          libexpat1-2.2.0-2+deb9u1                Medium            2.2.0-2+deb9u3                           https://security-tracker.debian.org/tracker/CVE-2019-15903          
CVE-2019-5094           e2fslibs-1.43.4-2                       Medium            1.43.4-2+deb9u1                          https://security-tracker.debian.org/tracker/CVE-2019-5094           
CVE-2019-5094           e2fsprogs-1.43.4-2                      Medium            1.43.4-2+deb9u1                          https://security-tracker.debian.org/tracker/CVE-2019-5094           
CVE-2019-5094           libcomerr2-1.43.4-2                     Medium            1.43.4-2+deb9u1                          https://security-tracker.debian.org/tracker/CVE-2019-5094           
CVE-2019-5094           libss2-1.43.4-2                         Medium            1.43.4-2+deb9u1                          https://security-tracker.debian.org/tracker/CVE-2019-5094           
CVE-2005-2541           tar-1.29b-1.1                           Negligible        None                                     https://security-tracker.debian.org/tracker/CVE-2005-2541           
CVE-2007-5686           login-1:4.4-4.1                         Negligible        None                                     https://security-tracker.debian.org/tracker/CVE-2007-5686

参考資料

OpenSCAP

最初に、OpenSCAPの背景となるSCAPを簡単に説明する。米国政府省庁の情報セキュリティ対策への要求として、情報システムのセキュリティを強化することを義務付けた法律FISMA（Federal Information Security Management Act：連邦情報セキュリティマネジメント法）が2002年に施行された。これを含め関連の法遵守のため、OSなどの設定作業を手作業で行うと、設定ミスや設定者のセキュリティ知識の程度、判断の相違などからセキュリティが損なわれる可能性がある事などから、作業を自動化する事が効率牲・有効性の観点から求められた。このようなことから、NIST（National Institute of Standards and Technology）において、情報セキュリティ対策の自動化と標準化を目指したSCAP（Security Content Automation Protocol：セキュリティ設定共通化手順）の開発が行われた。

現在、SCAPは次の6つの標準仕様から構成される。

OpenSCAPとは、システム管理者と監査者がセキュリティベースラインの評価、測定、および実施を支援する複数のツールである。このツールは、上記の標準仕様に基づくように開発された。 SCAP関連のツールは、(RHEL7では)以下4種が提供され、OpenSCAPもその一つであある。Dockerコンテナを検査するツールoscap-dockerは、oscapの機能を使用している。

  • SCAP Workbench ： scap-workbench GUIツールは、システム上で、構成スキャンと脆弱性スキャン、そして、セキュリティーレポートの生成を実行できる。
  • OpenSCAP ： oscap コマンドは、ローカルシステムの構成スキャンと脆弱性スキャンを実行、セキュリティーコンプライアンスを検証、評価に基づいてレポートとガイドを生成する。
  • Script Check Engine (SCE) ： SCE は SCAPプロトコルの拡張機能であり、管理者がこれを使用して Bash、Python、Ruby などのプログラム言語を使って、セキュリティーチェックのコードを記述できる。SCEは、openscap-engine-sce パッケージで提供される。
  • SCAP Security Guide (SSG) ： The scap-security-guide パッケージは、Linux システム向けの最新のセキュリティ・ポリシーコレクションを提供する。このガイダンスは、セキュリティ強化に関する実践的なアドバイスのカタログで、該当する場合は、法規制要件に関連付けられる。

oscap-dockerの使用例

最初に、Security compliance of RHEL7 Docker containersの手順に沿って、環境をセットアップする。

ローカルに保存されたコンテナイメージのリストを表示する。

[root@rhel7 vagrant]# docker images
REPOSITORY                         TAG                 IMAGE ID            CREATED             SIZE
registry.access.redhat.com/rhel7   latest              bd0240457182        5 weeks ago         205 MB
docker.io/hello-world              latest              fce289e99eb9        9 months ago        1.84 kB

イメージ名を指定して、脆弱性レポートを作成する。 結果は --report cve-report.html にHTML形式で出力される。

[root@rhel7 vagrant]# oscap-docker image-cve registry.access.redhat.com/rhel7 --results cve-results.xml --report cve-report.html

次のスクリーンショットは、--report cve-report.htmlの指定により出力されたHTMLファイルをブラウザで表示したものである。

スクリーンショット 2019-10-09 15.57.35.png

こちらのオプションでは、セキュリティ評価を記述したOVALに従ってイメージを検査する。ここで指定したOVALでは、United States Government Configuration Baseline (USGCB / STIG) などのセキュリティ設定が遵守されていることをチェックする。

[root@rhel7 vagrant]# oscap-docker image registry.access.redhat.com/rhel7 oval eval --results oval-results.xml --report report.html /usr/share/xml/scap/ssg/content/ssg-rhel7-oval.xml

スクリーンショット 2019-10-09 15.56.58.png

ベースイメージにRHELを使用してない場合は、検査することができない。RHELのコンテナのベースイメージには、OpenSCAPに検査に必要なメタ情報が含まれるためと思われる。

[root@rhel7 vagrant]# oscap-docker image-cve docker.io/maho/web-nginx:11 --results web-nginx-results.xml --report web-nginx-report.html
<中略>

docker.io/maho/web-nginx:11 is not based on RHEL

参考資料

Dagda

既知の脆弱性、トロイの木馬、ウイルス、マルウェア、その他のDockerイメージ/コンテナ内の脅威の静的分析を実行し、異常なアクティビティを検出するためにDockerデーモンと実行中のDockerコンテナを監視するツールである。

Dagdaの内容を読むと、静的な脆弱性検査と、実行中コンテナの不審な動作にも対応する、大変優れたツールと思われる。しかし、出力はJSON形式で、Pythonのコードをコマンドラインから実行する。Dagdaは、ツールと呼ぶよりも、ソフトウェア部品と考えた方が良さそうだ。その後、Dagdaは、実行中のDockerコンテナの不審な振る舞いを監視するためにSysdig Falco に統合されている。さらに、CNCFの Sand Box プロジェクト Falco として登録された。

このDagdaは、脆弱性データとして、CVE（Common Vulnerabilities and Exposures）、BID（Bugtraq ID）、RHSA（Red Hat Security Advisories）、RHBA（Red Hat Bug Advisories）、そして、攻撃的セキュリティデータベース Exploit Database を MongoDBにインポートする。攻撃的セキュリティとは、攻撃者がどのような脆弱性を突いて攻撃をしかけてくるかを想定し、未然の策を講じておく、積極的な対策のことである。

次に、Dagdaは、OSパッケージやプログラミング言語の依存関係など、Dockerイメージにインストールされたソフトウェアに関する情報を取得し、MongoDBに保存された脆弱性情報と照合して、各製品とそのバージョンがないかどうかを確認する。Dagdaは、ClamAVをウイルス対策エンジンとして使用して、トロイの木馬（trojans)、ウイルス、マルウェア、およびDockerイメージとコンテナに含まれるその他の悪意のある脅威を検出する。

Dagdaは複数のコンテナベースイメージをサポート

  • Red Hat/CentOS/Fedora
  • Debian/Ubuntu
  • OpenSUSE
  • Alpine

Dagdaは、複数の依存関係を分析するために、OWASP依存関係チェック+ Retire.jsに依存する。

  • java
  • python
  • nodejs
  • js
  • ruby
  • php

さらなる発展として、Falco Operator として、Kubernetesの実行中のアプリケーションの不審な振る舞いを検知するためのリアリタイム監視 オペレータ として開発が進んでいる。

参考資料

Microscanner と Trivy

Microscannerはインターネット越しに利用できるサービスなので、インストールしたり環境を作らなくても即に利用できる、TrivyはOSSで、どちらもAquaが提供する。

MicroScannerは、開発者向けの無料の画像脆弱性スキャナであり、Aquaのクラス最高の商用スキャナーと同じ脆弱性データベースを使用して最高の結果が得られるとのこと。

MicroScannerとAquaの商用製品との主な違いは、Dockerfile内で指定されたビルドステップ中に実行されること。

ADD https://get.aquasec.com/microscanner /
RUN chmod +x microscanner
RUN microscanner <TOKEN>

MicroScannerが重大度の高い脆弱性を検出すると、ゼロ以外の終了コードを返し、イメージのビルドを失敗停止させる。そのため、CICDのパイプラインに組み込み安く、脆弱性検査結果もビルドログに出力される。

そして、同じAquaのGitHubリポジトリから、コンテナー用のシンプルで包括的な脆弱性スキャナ Trivyがある。この開発者は日本人。 このソフトウェアは、OSパッケージ（Alpine、RHEL、CentOSなど）およびアプリケーションの依存関係（Bundler、Composer、npm、yarnなど）の脆弱性を検出。バイナリをインストールして、コンテナのイメージ名を指定してスキャンするだけで、簡単に利用できる。以下の例は、コンテナイメージ python:3.4-alpineをスキャンする例である。

$ trivy python:3.4-alpine

参考資料

Twistlock

Twistlockはインターネット越しに利用できる商用サービス。各社クラウドサービスと連携した利用が想定され、AWS,Azure,GCPに加えて、IBM Cloud のサービスとも連携して利用可能。もちろん、Kubernetes と Docker、OpenShiftにも対応する優れたセキュリティ対策サービス。

デプロイからランタイムの範囲をカーバーするとのこと。そして、IBM Cloud セキュリティ・アドバイザーと連携して、問題を未然に防ぐ役割を果たす。

今年、Twistlockは、パロアルトネットワークスに買収された。

2019年7月9日 -パロアルトネットワークス（NYSE：PANW）、世界的なサイバーセキュリティのリーダー、それはツイストロックの買収を完了したことを発表しました、コンテナ・セキュリティのリーダー、そのプリズマ™クラウドのセキュリティを拡張します戦略。この買収により、ライフサイクル全体を通じて今日の最新のアプリケーションを保護する同社の能力がさらに向上し、組織は安全で信頼性が高くスケーラブルなイノベーションを提供できます。

参考資料

Vuls (バルス)

Vulsホームページと、GitHubを読んだ限り、とても優秀な日本製の脆弱性スキャナーである。どうして英語圏の資料から調べていくので、残念なことに、最初の公開から漏れてしまったが追加したい。
このソフトウェアは、コンテナ・イメージ用という訳ではなく、様々なLinuxディストリビューションが混在する運用環境下で、脆弱性のスキャンと対応を自動化するために開発された運用管理ツールで、次にあげるLinuxに対応できる点が、一つの特徴である。(Alpine、Ubuntu、Debian、CentOS、Amazon Linux、RHEL、Oracle Linux、SUSE Enterprise Linux、Raspbian、FreeBSD）そして、AWS,GCPなどのクラウド環境、オンプレミス、Dockerコンテナなどの複数の環境に対応する。Dockerコンテナ・イメージをスキャンする場合は、Trivyのライブラリを利用とのこと。

さらに、他のスキャナーに比べて、脆弱性を検知するための情報源を、より多く活用していることも、特徴である。

政府外郭団体のアラート情報

  • US-CERT 米国国土安全保障省(DHS)配下の情報セキュリティ対策組織、サイバー脅威、脆弱性の分析と削減、サイバー脅威警告情報の普及、インシデント対応活動のコーディネーション
  • JPCERT/CC 一般社団法人 JPCERTコーディネーションセンター、コンピュータセキュリティの情報を収集し、インシデント対応の支援、コンピュータセキュリティ関連情報の発信

脆弱性情報データベース

  • NVD NISTが管理している脆弱性情報データベース,CVEで命名された脆弱性情報の詳細情報をNVDで提供,CVSSによる危険度の採点
  • JVN(Japanese) JPCERT/CCと情報処理推進機構（IPA）が共同で管理している脆弱性情報データベース,日本の脆弱性情報に焦点
  • Exploit Database 侵入テストおよび脆弱性研究者が使用するために開発されたCVE互換データベース

OVAL (Open Vulnerability and Assessment Languag)

OVALは、文書による脆弱性対策情報を、機械処理可能なXMLベースのOVAL言語で記述したもので、ソフトウェアを提供する団体によって作成され配布される。

パッケージのセキュリティ情報

Linuxディストリビューションに含まれるミドルウェアなどのパッケージのセキュリティ情報

プログラム言語等の脆弱性データベース

  • WPVulnDB WordPress脆弱性データベース
  • Node.js Security Working Group Node.jsエコシステムのセキュリティ向上に取り組むワーキンググループ
  • Ruby Advisory Database Rubyライブラリに関連するすべてのセキュリティアドバイザリを収集するコミュニティの取り組み
  • Safety DB(Python) Pythonパッケージの既知のセキュリティ脆弱性のデータベース
  • PHP Security Advisories Database PHPプロジェクトおよびライブラリの既知のセキュリティ脆弱性の助言データベース
  • RustSec Advisory Database プログラミング言語 Rust(ラスト)の脆弱性の助言データベース

その他情報源

  • Changelog
  • Commands(yum, zypper, pkg-audit) RHSA/ALAS/ELSA/FreeBSD-SA

参考資料

その他の脆弱性スキャナー

Notary
Notaryは、Dockerイメージの署名フレームワークのデファクトスタンダードで、Dockerはオープンソース化して CNCF へ寄贈(2017)

Grafaes(ギリシャ語でスクライブ)
Grafaesは、IBMとGoogleによって開発された。ソフトウェアサプライチェーンを監査および管理するための統一された方法を提供するOSSのアーティファクトメタデータAPIであり、IBM Vulnerability Advisor に採用されている。

Banyanops Collector
Banyanopsコレクタは、コンテナイメージの内容を見るためのフレームワーク

Cilium (スゥリウム))
Ciliumは、BPFとLinuxカーネル技術によって、アプリケーションコードやコンテナ構成を変更せずにセキュリティポリシーを適用および更新できる。CoreOS(現 Red Hat)によって開発された。

コンテナビルド時に、脆弱性スキャンを実施

CICDパイプラインの中に、脆弱性スキャンを組み込むことで、問題を早期に発見して、対策することができる。ビルドステップが完了したら、脆弱性スキャンを実行して、レポートする。重大な脆弱性が発見された場合は、次のテストステップに進めることなく、脆弱性対策を実施する。前述のスキャナーの中にも、CLIから脆弱性検査を実行できて、重大な脆弱性が発見されると終了コードによってステップを異常終了できるものがある。

参考資料

上記の参考資料と重複もあるが、記事を書くにあたり参考にした資料なので、残しておきたいので以下に列挙する。

406
401
8

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
406
401

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?