OSSで始めるコンテナセキュリティ / Container Security with OSS tools

クラスメソッド株式会社が主催するイベント DevelopersIO 2022 で発表した「OSSで始めるコンテナセキュリティ」の登壇資料です。
https://classmethod.jp/m/developers-io/

資料内のURLは、PDFをダウンロードするとクリックで遷移できます。

「コンテナセキュリティってなんかいろいろあるけど、結局なにからやればいいの？」という方向けに、コンテナセキュリティの全体像や概要を解説しつつ、コンテナセキュリティに対応するためのOSSを紹介するセッションです。

Transcript

1. OSSで始めるコンテナセキュリティ
 2022/7/26
 AWS事業本部コンサルティング部 寺岡慶佑

2. 2 発表者紹介 寺岡 慶佑（と ち） • 2020年11月クラスメソッド入社 • 前職: Webサービス開発・運用 ◦ Amazon ECS/EKSを用いた構成 • 好きなAWSサービス ◦ AWS App Runner ◦ Amazon EKS • 2022 APN ALL AWS Certifications Engineer • 2021 APN AWS Top Engineer • 趣味 ◦ 紅茶、ビール @toda_kk
3. 3 コンテナセキュリティと ？
4. 4 よくあるご相談 コンテナを利用する上で 漠然とセキュリティへ 不安がある
5. • コンテナを使いたいが、セキュリティが不安 ◦ 利用経験がない で、コンテナ特有 事情がわからない • すでにコンテナを利用し始めているが、不正に侵入されな いか心配 ◦ 具体的な脅威がわからない ◦ ど ように侵入を防げ 良いかわからない • コンテナ セキュリティ対応 イメージがつかない ◦ 例え 、Amazon EC2 ようなVMだったらIDSやアンチマルウェ アソフトを入れるなど、イメージがつきやすい 5 よくあるご相談
6. 6 コンテナを扱う上で、出てくる要素が多い コンテナ イメージ レジストリ Dockerfile ECR Fargate Kubernetes コンテナ ホスト コントロール プレーン データプレーン オーケストレーター コンテナ ランタイム CI/CD ECS EKS EC2 BuildKit
7. • NIST SP 800-190 アプリケーションコンテナセキュリティガイ ド ◦ https://www.ipa.go.jp/files/000085279.pdf ◦ コンテナ利用における脅威と対策をまとめたも • CIS Docker Benchmarks ◦ https://www.cisecurity.org/benchmark/docker ◦ Docker利用におけるセキュリティベンチマーク • MITRE ATT&CK Containers Matrix ◦ https://attack.mitre.org/matrices/enterprise/containers/ ◦ 攻撃者 視点に立って脅威を整理したも 7 コンテナセキュリティにおけるフレームワーク
8. • コンテナライフサイクルに沿ってリスクと対応を整理 ◦ イメージ リスク ◦ レジストリ リスク ◦ オーケストレーター リスク ◦ コンテナ リスク ◦ ホストOS リスク 8 NIST SP 800-190を紹介
9. • イメージ リスク ◦ イメージ 脆弱性 ◦ イメージ 設定 不備 ◦ 埋め込まれたマルウェア ◦ 埋め込まれた平文 機密情報 ◦ 信頼できないイメージ 使用 • レジストリ リスク ◦ レジストリへ セキュアでない接続 ◦ レジストリ内 古いイメージ ◦ 認証・認可 不十分な制限 9 NIST SP 800-190を紹介
10. • オーケストレーター リスク ◦ 制限 ない管理者アクセス ◦ 不正アクセス ◦ コンテナ間 ネットワークトラフィック 不十分な分離 ◦ ワークロード 機微性レベル 混在 ◦ オーケストレーターノード 信頼 • コンテナ リスク ◦ ランタイムソフトウェア内 脆弱性 ◦ コンテナから 無制限 ネットワークアクセス ◦ セキュアでないコンテナランタイム 設定 ◦ アプリ 脆弱性 ◦ 未承認コンテナ 10 NIST SP 800-190を紹介
11. • ホストOS リスク ◦ 大きなアタックサーフェス ◦ 共有カーネル ◦ ホストOSコンポーネント 脆弱性 ◦ 不適切なユーザーアクセス権 ◦ ホストOSファイルシステム 改ざん 11 NIST SP 800-190を紹介
12. • イメージ ビルド時 リスクを想定 • Log4Shellなどアプリケーション 脆弱性を含んだコンテナ イメージを作成し実行 • アプリケーション 脆弱性を利用して、実行中 コンテナ 外部から任意 コードを実行されてしまう 12 コンテナ利用における脅威 シナリオ① Attacker Container 任意 コードを実行 アプリケーション 脆弱性を含んだコンテナ
13. • イメージ ビルド時 リスクを想定 • Dockerfileに機密情報を直接書き込んだ上でイメージを作 成 ◦ AWSアクセスキーやDB 接続・認証情報など • 実行中 コンテナ外部からdocker historyコマンドで機密 情報が奪取されてしまう 13 コンテナ利用における脅威 シナリオ② Attacker Container docker history 機密情報を含んだ コンテナ
14. • コンテナ実行時 リスクを想定 • なんらか 手段でコンテナ 接続経路や認証情報が奪取 され、docker/kubectl execコマンドで侵入される • コンテナ上でコインマイナーなど不正なファイルをダウン ロードされ、実行されてしまう 14 コンテナ利用における脅威 シナリオ③ Attacker Container 侵入 ダウンロード Malware
15. 15 コンテナライフサイクルを考える
16. 16 コンテナライフサイクル フェーズを分類する
17. 17 コンテナライフサイクルを踏まえた上で AWSサービスによる対応方法を考える
18. • 関連するAWSサービスと機能を羅列してみる ◦ Amazon ECRによる、コンテナイメージ 脆弱性スキャン ▪ 基本スキャン / 拡張スキャン ◦ Amazon ECRにおける、レジストリ保護 ▪ コンテナイメージ ライフサイクルポリシー ▪ レジストリ アクセスポリシー、暗号化 ◦ AWS Security HubやAWS Configによる、マネージドサービス 構成管理 ▪ ECR、ECS、EKSに関するチェック項目やマネージドルール ◦ Amazon Inspectorによる、Amazon EC2 脆弱性検知 ◦ Amazon GuardDutyによる、Amazon EKS 監査ログ監視 ▪ EKSクラスターにおける脅威 発生を検知 18 AWSサービスによる対応方法を考える
19. 19 コンテナライフサイクルに当て めて考える
20. ECRによるコンテナイメージ 脆弱性スキャン 20 https://dev.classmethod.jp/articles/ecr-repository-scan/ https://dev.classmethod.jp/articles/amazon-ecr-enhanced-scanning/
21. ECRにおけるレジストリ保護 21 https://dev.classmethod.jp/articles/ecr-lifecycle/ https://docs.aws.amazon.com/AmazonECR/latest/userguide/regi stry-permissions-create.html
22. Security Hub、Configによる構成管理 22 https://dev.classmethod.jp/articles/amazon-inspector-v2-released/ https://dev.classmethod.jp/articles/notify-inspector-v2-findings-usi ng-chatbot/ ※チェック項目やマネージドルール どんどんアップデートされている で、最新 情報 公式ドキュメントを参照
23. InspectorによるEC2 脆弱性検知 23 https://dev.classmethod.jp/articles/amazon-inspector-v2-released/ https://dev.classmethod.jp/articles/scanning-ecs-container-instance s-with-amazon-inspector-v2/
24. GuardDutyによるEKS 監査ログ監視 24 https://dev.classmethod.jp/articles/guardduty-for-eks-protection/ https://dev.classmethod.jp/articles/privileged-container-guardduty- event-on-amazon-eks/
25. 25 ここで疑問 AWSサービスによる対応 みで充分か？
26. • 必要となる対応内容 、ケースバイケース ◦ 重視したい脅威やリスク 、企業や組織ごとに異なる ◦ セキュリティポリシーにもよる • ここで挙げたも 、あくまでもマネージドサービス ◦ 導入や管理 手間が省けるが、カバーできない範囲もある ◦ 特に「コンテナランタイム 保護」 部分 、現状で AWS サービスだけで 対応できない • 比較的少額と いえ有料 サービスもある で、もっと気 軽に試してみたい 26 AWSサービスによる対応 みで充分か？
27. 27 本日 テーマ OSS ツールを活用して コンテナセキュリティを実現しよう
28. 28 2つ ツールを紹介
29. • Trivy 、コンテナイメージ 脆弱性スキャンツール • Falco 、ランタイム保護を提供するツール • どちらもLinux Foundationが提供するKubernetesセキュリ ティ認定試験 カリキュラムに組み込まれている ◦ Certified Kubernetes Security Specialist (CKS) ◦ コンテナセキュリティにおいてデファクトスタンダードなツールと 言える 29 TrivyとFalcoについて
30. 30 Kubernetes認定試験 FAQに記載がある https://docs.linuxfoundation.org/tc-docs/certification/faq-cka-ckad-cks
31. 31 コンテナライフサイクルに当て める
33. • Aqua Security社が中心となって開発されているOSS ◦ 元 日本 個人開発 OSSだった • 元 コンテナイメージ 脆弱性スキャンが主な機能だった が、現在に 他にも機能が豊富 ◦ DockerfileやIaCツール 設定チェック（Lint）機能 ◦ ファイルシステムやGitリポジトリを指定したスキャンも可能 • Kubernetesであれ 、オーケストレーター保護も可能 ◦ 実行中 クラスターを丸ごとスキャンできる 33 Trivyと ？ https://aquasecurity.github.io/trivy/dev/ https://github.com/aquasecurity/trivy https://knqyf263.hatenablog.com/entry/2019/08/20/120713
34. • Trivyをインストールする 34 コンテナイメージ 脆弱性スキャン $ rpm -ivh https://github.com/aquasecurity/trivy/releases/download/v0.30.2/trivy_0.30.2_Linux-64bit.rpm $ apt-get install trivy $ yum install trivy $ brew install aquasecurity/trivy/trivy $ docker run aquasec/trivy https://aquasecurity.github.io/trivy/dev/getting-started/installation/
35. • コンテナイメージをスキャンしてみる $ trivy image nginx:latest 2022-07-26T05:55:58.469Z INFO Vulnerability scanning is enabled 2022-07-26T05:55:58.469Z INFO Secret scanning is enabled 2022-07-26T05:55:58.470Z INFO If your scanning is slow, please try '--security-checks vuln' to disable secret scanning 2022-07-26T05:55:58.470Z INFO Please see also https://aquasecurity.github.io/trivy/0.30.2/docs/secret/scanning/#recommendation for faster secret detection 2022-07-26T05:56:11.940Z INFO Detected OS: debian 2022-07-26T05:56:11.940Z INFO Detecting Debian vulnerabilities... 2022-07-26T05:56:12.061Z INFO Number of language-specific files: 0 nginx:latest (debian 11.4) Total: 149 (UNKNOWN: 0, LOW: 93, MEDIUM: 23, HIGH: 26, CRITICAL: 7) 35 コンテナイメージ 脆弱性スキャン https://aquasecurity.github.io/trivy/dev/docs/vulnerability/scanning/image/
36. • スキャン結果 出力イメージ 36 コンテナイメージ 脆弱性スキャン
37. • 出力する脆弱性を重大度でフィルタリングする $ trivy image --severity HIGH,CRITICAL nginx:latest 2022-07-26T05:57:02.030Z INFO Vulnerability scanning is enabled 2022-07-26T05:57:02.030Z INFO Secret scanning is enabled 2022-07-26T05:57:02.030Z INFO If your scanning is slow, please try '--security-checks vuln' to disable secret scanning 2022-07-26T05:57:02.030Z INFO Please see also https://aquasecurity.github.io/trivy/0.30.2/docs/secret/scanning/#recommendation for faster secret detection 2022-07-26T05:57:02.039Z INFO Detected OS: debian 2022-07-26T05:57:02.039Z INFO Detecting Debian vulnerabilities... 2022-07-26T05:57:02.075Z INFO Number of language-specific files: 0 nginx:latest (debian 11.4) Total: 33 (HIGH: 26, CRITICAL: 7) 37 コンテナイメージ 脆弱性スキャン
38. • ECRに保存されたイメージをスキャンしてみる $ aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com $ trivy image 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/dvwa:latest 2022-07-26T05:58:00.004Z INFO Vulnerability scanning is enabled 2022-07-26T05:58:00.005Z INFO Secret scanning is enabled 2022-07-26T05:58:00.005Z INFO If your scanning is slow, please try '--security-checks vuln' to disable secret scanning 2022-07-26T05:58:00.005Z INFO Please see also https://aquasecurity.github.io/trivy/0.30.2/docs/secret/scanning/#recommendation for faster secret detection 2022-07-26T05:58:00.345Z INFO Detected OS: debian 2022-07-26T05:58:00.345Z INFO Detecting Debian vulnerabilities... 2022-07-26T05:58:00.527Z INFO Number of language-specific files: 0 2022-07-26T05:58:00.821Z WARN This OS version is no longer supported by the distribution: debian 9.5 2022-07-26T05:58:00.822Z WARN The vulnerability detection may be insufficient because security updates are not provided 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/dvwa:latest (debian 9.5) Total: 2114 (UNKNOWN: 13, LOW: 353, MEDIUM: 694, HIGH: 740, CRITICAL: 314) 38 コンテナイメージ 脆弱性スキャン
39. • OSパッケージだけでなく、プログラミング言語パッケージ 脆弱性もスキャンできる ◦ Ruby、Python、PHP、Node.js、.NET、Java、Go、Rust 39 コンテナアプリケーション 脆弱性スキャン https://aquasecurity.github.io/trivy/dev/docs/vulnerability/detection/os/ https://aquasecurity.github.io/trivy/dev/docs/vulnerability/detection/language/
40. • イメージ ビルド時 リスクを想定 • Log4Shellなどアプリケーション 脆弱性を含んだコンテナ イメージを作成し実行 • アプリケーション 脆弱性を利用して、実行中 コンテナ 外部から任意 コードを実行されてしまう 40 (再掲) コンテナ利用における脅威 シナリオ① Attacker Container 任意 コードを実行 アプリケーション 脆弱性を含んだコンテナ
41. • 古いバージョン Elasticsearchイメージをスキャン ◦ Log4Shell（CVE-2021-44828） 検出されないも 、Log4j 別 脆弱性（CVE-2021-44832）が検出された ◦ ベンダーから公式に提供されるコンテナイメージ 日々更新さ れていくため、脆弱性情報も更新される ◦ $ trivy image docker.elastic.co/elasticsearch/elasticsearch:7.16.2-amd64 （中略） Java (jar) Total: 17 (UNKNOWN: 1, LOW: 2, MEDIUM: 9, HIGH: 5, CRITICAL: 0) 41 脅威シナリオ①に対する対応策 https://dev.classmethod.jp/articles/amazon-inspector-container-image-scan-log4shell/ https://www.creationline.com/lab/aquasecurity/47375 https://www.creationline.com/lab/aquasecurity/47868
42. • Trivyで コンテナイメージ 脆弱性スキャンだけでなく、 Dockerfile 設定に不備がないかチェックできる • ビルトインポリシーとして aquasecurity/defses を利用 ◦ カスタムポリシーを作成して適用することも可能 FROM ubuntu:latest RUN apt-get update RUN apt-get install curl wget EXPOSE 22 42 Dockerfile 設定チェック https://aquasecurity.github.io/trivy/dev/docs/misconfiguration/scanning/ https://aquasecurity.github.io/trivy/dev/docs/misconfiguration/policy/builtin/ Dockerfile
43. • ディレクトリを指定して設定チェックを実行する 43 Dockerfile 設定チェック $ trivy config ./ （中略） MEDIUM: Specify a tag in the 'FROM' statement for image 'ubuntu' When using a 'FROM' statement you should use a specific tag to avoid uncontrolled behavior when the image is updated. See https://avd.aquasec.com/misconfig/ds001 Dockerfile:1 1 [ FROM ubuntu:latest HIGH: Specify at least 1 USER command in Dockerfile with non-root user as argument Running containers with 'root' user can lead to a container escape situation. It is a best practice to run containers as non-root users, which can be done by adding a 'USER' statement to the Dockerfile. See https://avd.aquasec.com/misconfig/ds002 MEDIUM: Port 22 should not be exposed in Dockerfile Exposing port 22 might allow users to SSH into the container. See https://avd.aquasec.com/misconfig/ds004 Dockerfile:6 6 [ EXPOSE 22 HIGH: The instruction 'RUN <package-manager> update' should always be followed by '<package-manager> install' in the same RUN statement. The instruction 'RUN <package-manager> update' should always be followed by '<package-manager> install' in the same RUN statement. See https://avd.aquasec.com/misconfig/ds017 Dockerfile:3 3 [ RUN apt-get update HIGH: '-y' flag is missed: 'apt-get install curl wget' 'apt-get' calls should use the flag '-y' to avoid manual user input. See https://avd.aquasec.com/misconfig/ds021 Dockerfile:4 4 [ RUN apt-get install curl wget
44. • 出力に従ってDockerfileを修正し、再度チェックする ◦ Dockerfileを修正 ◦ 再度Trivyで設定チェック ▪ 警告なしで終了 $ trivy config ./ 2022-07-24T10:31:44.612Z INFO Misconfiguration scanning is enabled 2022-07-24T10:31:44.855Z INFO Detected config files: 1 44 Dockerfile 設定チェック FROM ubuntu:22.04 RUN apt-get update && apt-get install -y curl wget USER ubuntu Dockerfile
45. • イメージ ビルド時 リスクを想定 • Dockerfileに機密情報を直接書き込んだ上でイメージを作 成 ◦ AWSアクセスキーやDB 接続・認証情報など • 実行中 コンテナ外部からdocker historyコマンドで機密 情報が奪取されてしまう 45 (再掲) コンテナ利用における脅威 シナリオ② Attacker Container docker history 機密情報を含んだ コンテナ
46. • AWSアクセスキーなどを書き込んだDockerfileを用意 FROM ubuntu:22.04 COPY app.sh / RUN chmod +x /app.sh ENTRYPOINT ["/app.sh"] 46 脅威シナリオ②に対する対応策 Dockerfile export AWS_ACCOUNT_ID=123456789012 export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY app.sh
47. • コンテナイメージをビルドし、Trivyでスキャンを実行 ◦ trivy configコマンドで 機密情報 スキャンに対応していない で、trivy imageコマンドを実行する必要がある $ docker build -t aws-secrets-image . $ trivy image aws-secrets-image （中略） /app.sh (secrets) Total: 3 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 1, CRITICAL: 2) CRITICAL: AWS (aws-access-key-id) AWS Access Key ID /app.sh:4 4 [ export AWS_ACCESS_KEY_ID=******************** HIGH: AWS (aws-account-id) AWS Account ID /app.sh:3 3 [ export AWS_ACCOUNT_ID=************ CRITICAL: AWS (aws-secret-access-key) AWS Secret Access Key /app.sh:5 5 [ export AWS_SECRET_ACCESS_KEY=**************************************** 47 脅威シナリオ②に対する対応策
48. • CodeBuild Buildspec 中でTrivyを実行する ◦ イメージをECRにpushする前にスキャンや設定チェックを実行 する 48 CI/CDへ 組み込み: CodePipeline https://aws.amazon.com/jp/blogs/containers/scanning-images-with-trivy-in-an-aws-codepipeline/
49. • Aqua Security社 AWSパートナーであり、Trivyによる実行 結果をSecurity Hubによって管理することも可能 49 補足: Security Hubと 統合も可能 https://aws.amazon.com/jp/blogs/security/how-to-build-ci-cd-pipeline-container-vulnerability-scanning-trivy-and-aws-security-hub/
50. name: build jobs: build: name: Build runs-on: ubuntu-20.04 steps: - name: Checkout code uses: actions/checkout@v2 - name: Build an image from Dockerfile run: | docker build -t my-app:${{ github.sha }} . - name: Run Trivy vulnerability scanner uses: aquasecurity/trivy-action@master with: image-ref: 'my-app:${{ github.sha }}' format: 'table' exit-code: '1' ignore-unfixed: true vuln-type: 'os,library' severity: 'CRITICAL,HIGH' • Trivy ActionがAqua Security社から提供されている 50 CI/CDへ 組み込み: GitHub Actions https://github.com/aquasecurity/trivy-action .github/workflows/build.yaml
51. • Kubernetesクラスター上 コンテナをスキャンし、脆弱性 や機密情報 有無、設定チェックができる • CLI 他に、Trivy-OperatorをKubernetesクラスター内に常 駐させることで定期的なスキャンが実現できる $ trivy k8s –report=summary cluster-name 51 Kubernetesオーケストレーター保護 https://aquasecurity.github.io/trivy/dev/docs/kubernetes/cli/scanning/ https://github.com/aquasecurity/trivy-operator https://aquasecurity.github.io/trivy-operator/v0.1.5/
52. • Trivyを利用することで、コンテナイメージスキャンや Dockerfile設定チェックを容易に導入できる ◦ CI/CDパイプラインへ 組み込みも容易 ◦ 他にも機能が豊富 • Kubernetesであれ 、オーケストレーター保護も可能 • 近年、サプライチェーンセキュリティ 文脈から注目されて いるSBOM 作成も可能 ◦ Software Bill Of Materials ◦ ソフトウェアに含まれる依存関係やライブラリ 種類などをリス ト化したも 52 Trivyに関するまとめ
54. • Sysdig社が中心となって開発されているOSS ◦ 現在 CNCF（Cloud Native Computing Foundation）に寄贈され ている • ランタイムセキュリティを提供するツール ◦ ランタイムにおける振る舞いを動的にスキャンし、異常な振る 舞いを検知する ◦ コンテナに限らず、ホスト ランタイム保護なども可能 • 振る舞い 検知に注力したツールである ◦ 異常な振る舞い 検知に加えて防止まで実施したい場合 、 商用製品であるSysdig Secureを導入する必要がある 54 Falcoと ？ https://falco.org/ https://github.com/falcosecurity/falco
55. • ホストやコンテナランタイムで発生したイベントを動的にス キャンして、あらかじめ用意したルールに適合するかどう かフィルタリングする ◦ ルールに合え アラートを出力する • プリセットなルールがいくつか用意されている で、すぐに 使い始められる • 独自 カスタムルールも設定できる で、企業や組織 セキュリティポリシーに応じた対応が可能 55 Falcoが提供する機能
56. 56 Falcoを実際に動かしてみる
57. • Falcoをインストールする $ sudo rpm --import https://falco.org/repo/falcosecurity-3672BA8F.asc $ sudo curl -s -o /etc/yum.repos.d/falcosecurity.repo https://falco.org/repo/falcosecurity-rpm.repo $ sudo yum -y install kernel-devel-$(uname -r) $ sudo yum -y install falco 57 Amazon Linux 2 on EC2環境で実行してみる https://falco.org/docs/getting-started/installation/
58. • Falcoを実行してみる ◦ 動作確認 ため 一時的な実行 $ sudo falco Mon Jul 26 06:00:00 2022: Falco version 0.32.1 Mon Jul 26 06:00:00 2022: Falco initialized with configuration file /etc/falco/falco.yaml Mon Jul 26 06:00:00 2022: Loading rules from file /etc/falco/falco_rules.yaml: Mon Jul 26 06:00:00 2022: Loading rules from file /etc/falco/falco_rules.local.yaml: Mon Jul 26 06:00:00 2022: Starting internal webserver, listening on port 8765 58 Amazon Linux 2 on EC2環境で実行してみる
59. • 別 ターミナルから不正な操作を実行してみる ◦ /bin 以下にファイル作成 操作を実行 • 上記 不正なコマンドが実行されたイベントを検知し、実 行ログが出力される $ sudo touch /bin/surprise 59 Amazon Linux 2 on EC2環境で実行してみる $ sudo falco Mon Jul 26 06:00:00 2022: Falco version 0.32.1 Mon Jul 26 06:00:00 2022: Falco initialized with configuration file /etc/falco/falco.yaml Mon Jul 26 06:00:00 2022: Loading rules from file /etc/falco/falco_rules.yaml: Mon Jul 26 06:00:00 2022: Loading rules from file /etc/falco/falco_rules.local.yaml: Mon Jul 26 06:00:00 2022: Starting internal webserver, listening on port 8765 06:00:05.421034435: Error File below a known binary directory opened for writing (user=<NA> user_loginuid=-1 command=touch /bin/surprise file=/bin/surprise parent=sudo pcmdline=sudo touch /bin/surprise gparent=bash container_id=host image=<NA>)
60. • Falco 起動時に設定ファイルがロードされる ◦ /etc/falco/falco.yaml • ルール設定ファイルが別にあり、Falco 設定ファイルで ルール設定ファイル リストを指定している • デフォルトで 下記 ように指定されている https://falco.org/docs/configuration/ https://falco.org/docs/rules/ 60 ルール 設定ファイル rules_file: - /etc/falco/falco_rules.yaml - /etc/falco/falco_rules.local.yaml - /etc/falco/rules.d /etc/falco/falco.yaml
61. • プリセットなルールによって不正な操作が検出された - macro: bin_dir condition: fd.directory in (/bin, /sbin, /usr/bin, /usr/sbin) - rule: Write below binary dir desc: an attempt to write to any file below a set of binary directories condition: > bin_dir and evt.dir = < and open_write and not package_mgmt_procs and not exe_running_docker_save and not python_running_get_pip and not python_running_ms_oms and not user_known_write_below_binary_dir_activities output: > File below a known binary directory opened for writing (user=%user.name user_loginuid=%user.loginuid command=%proc.cmdline file=%fd.name parent=%proc.pname pcmdline=%proc.pcmdline gparent=%proc.aname[2] container_id=%container.id image=%container.image.repository) priority: ERROR tags: [filesystem, mitre_persistence] 61 不正な操作 検出を定義したルール /etc/falco/falco_rules.yaml
62. • カスタムルールを設定することで、プリセットなルールを上 書きできる ◦ 独自にファイルパスを指定することも可能 - rule: Write below binary dir desc: an attempt to write to any file below a set of binary directories condition: > bin_dir and evt.dir = < and open_write and not package_mgmt_procs and not exe_running_docker_save and not python_running_get_pip and not python_running_ms_oms and not user_known_write_below_binary_dir_activities output: > File below a known binary directory opened for writing (user=%user.name user_loginuid=%user.loginuid command=%proc.cmdline file=%fd.name parent=%proc.pname pcmdline=%proc.pcmdline gparent=%proc.aname[2] container_id=%container.id image=%container.image.repository) priority: NOTICE tags: [filesystem, mitre_persistence] 62 ルールを変更してみる /etc/falco/falco_rules.local.yaml
63. • 別 ターミナルから不正な操作を実行してみる ◦ 先ほどと同じコマンドを実行する • 実行ログが ERROR から NOTICE に変わっている 06:10:00.630082418: Notice File below a known binary directory opened for writing (user=root user_loginuid=-1 command=touch /bin/surprise2 file=/bin/surprise2 parent=sudo pcmdline=sudo touch /bin/surprise2 gparent=sh container_id=host image=<NA>) $ sudo touch /bin/surprise2 63 変更したルールを動作確認してみる
64. • コンテナ実行時 リスクを想定 • なんらか 手段でコンテナ 認証情報が奪取され、 docker/kubectl execコマンドなどで侵入される • コンテナ上でマイニングツールなど不正なファイルをダウ ンロードされ、実行されてしまう 64 (再掲) コンテナ利用における脅威 シナリオ③ Attacker Container 侵入 ダウンロード Malware
65. • コンテナ内部へ shellアクセスを検知する ◦ docker execコマンド 実行 ◦ shellアクセスを検知 $ sudo docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 1d524a3860c1 nginx "/docker-entrypoint.…" 31 seconds ago Up 30 seconds 80/tcp test-nginx $ sudo docker exec -it test-nginx /bin/bash root@1d524a3860c1:/# 65 脅威シナリオ③に対する対応策 06:11:00.369783385: Notice A shell was spawned in a container with an attached terminal (user=root user_loginuid=-1 test-nginx (id=1d524a3860c1) shell=bash parent=runc cmdline=bash terminal=34816 container_id=1d524a3860c1 image=nginx)
66. • コンテナ外部から ファイルダウンロードを検知する ◦ パッケージ管理ツールやファイルダウンロード 実行 ◦ 実行やファイルダウンロードを検知 66 脅威シナリオ③に対する対応策 11:11:20.346614943: Error Package management process launched in container (user=root user_loginuid=-1 command=apt install wget container_id=1d524a3860c1 container_name=test-nginx image=nginx:latest) 11:11:30.690053716: Notice Ingress remote file copy tool launched in container (user=root user_loginuid=-1 command=wget -P /tmp/ https://www.google.com parent_process=bash container_id=1d524a3860c1 container_name=test-nginx image=nginx:latest) root@1d524a3860c1:/# apt install wget root@1d524a3860c1:/# wget -P /tmp/ https://www.google.com
67. 67 Falcoを実際に動かしてみる Falcoをコンテナとして実行してみる
68. • Dockerコンテナとして実行してみる ◦ 別 ホスト上で実行する ◦ 動作確認 ため -it オプションで一時的な実行 $ docker run -it --rm \ --privileged \ -v /var/run/docker.sock:/host/var/run/docker.sock \ -v /dev:/host/dev \ -v /proc:/host/proc:ro \ -v /boot:/host/boot:ro \ -v /lib/modules:/host/lib/modules:ro \ -v /usr:/host/usr:ro \ -v /etc:/host/etc:ro \ falcosecurity/falco:latest 68 Falcoをコンテナとして実行してみる https://falco.org/docs/getting-started/running/
69. • Dockerコンテナとして実行してみる ◦ Falco起動 前に、ホストにDriverがインストールされる 69 * Setting up /usr/src links from host * Running falco-driver-loader for: falco version=0.32.1, driver version=2.0.0+driver * Running falco-driver-loader with: driver=module, compile=yes, download=yes ================ Cleaning phase ================ * 1. Check if kernel module 'falco' is still loaded: - OK! There is no 'falco' module loaded. * 2. Check all versions of kernel module 'falco' in dkms: - There are some versions of 'falco' module in dkms. * 3. Removing all the following versions from dkms: 2.0.0+driver - Removing 2.0.0+driver... ------------------------------ Deleting module version: 2.0.0+driver completely from the DKMS tree. ------------------------------ Done. - OK! Removing '2.0.0+driver' succeeded. [SUCCESS] Cleaning phase correctly terminated. ================ Cleaning phase ================ * Looking for a falco module locally (kernel 5.10.118-111.515.amzn2.x86_64) * Trying to download a prebuilt falco module from https://download.falco.org/driver/2.0.0%2Bdriver/x86_64/falco_amazonlinux2_5.10.118-111.515.amzn2.x86_64_1.ko * Download succeeded * Success: falco module found and inserted Falcoをコンテナとして実行してみる
70. 70 Falcoをコンテナとして実行してみる • Dockerコンテナとして実行してみる ◦ Driverインストール後、Falcoが起動する 2022-07-26T15:15:00+0000: Falco version 0.32.1 2022-07-26T15:15:00+0000: Falco initialized with configuration file /etc/falco/falco.yaml 2022-07-26T15:15:00+0000: Loading rules from file /etc/falco/falco_rules.yaml: 2022-07-26T15:15:01+0000: Loading rules from file /etc/falco/falco_rules.local.yaml: 2022-07-26T15:15:01+0000: Starting internal webserver, listening on port 8765
71. • 別 ターミナルから不正な操作を実行してみる ◦ 先ほどと同様 • 不正な操作を検知し、実行ログが出力される $ sudo touch /bin/surprise 71 Falcoをコンテナとして実行してみる 2022-07-26T16:15:00+0000: Falco version 0.32.1 2022-07-26T12:15:00+0000: Falco initialized with configuration file /etc/falco/falco.yaml 2022-07-26T12:15:00+0000: Loading rules from file /etc/falco/falco_rules.yaml: 2022-07-26T12:15:01+0000: Loading rules from file /etc/falco/falco_rules.local.yaml: 2022-07-26T12:15:01+0000: Starting internal webserver, listening on port 8765 2022-07-20T12:16:00.519875924+0000: Error File below a known binary directory opened for writing (user=root user_loginuid=-1 command=touch /bin/surprise file=/bin/surprise parent=sudo pcmdline=sudo touch /bin/surprise gparent=sh container_id=host image=<NA>)
72. • カスタムルール設定ファイルを含んだコンテナイメージを ビルドして起動する - rule: Write below binary dir desc: an attempt to write to any file below a set of binary directories condition: > bin_dir and evt.dir = < and open_write and not package_mgmt_procs and not exe_running_docker_save and not python_running_get_pip and not python_running_ms_oms and not user_known_write_below_binary_dir_activities output: > File below a known binary directory opened for writing (user=%user.name user_loginuid=%user.loginuid command=%proc.cmdline file=%fd.name parent=%proc.pname pcmdline=%proc.pcmdline gparent=%proc.aname[2] container_id=%container.id image=%container.image.repository) priority: NOTICE tags: [filesystem, mitre_persistence] 72 カスタムルールを適用する falco_rules.local.yaml FROM falcosecurity/falco:latest COPY falco_rules.local.yaml /etc/falco/ Dockerfile
73. • カスタムルール設定ファイルを含んだコンテナイメージを ビルドして起動する • カスタムルールが適用されたFalco コンテナイメージが 実行される $ docker build -t custom-falco:latest . $ docker run -it --rm \ --privileged \ -v /var/run/docker.sock:/host/var/run/docker.sock \ -v /dev:/host/dev \ -v /proc:/host/proc:ro \ -v /boot:/host/boot:ro \ -v /lib/modules:/host/lib/modules:ro \ -v /usr:/host/usr:ro \ -v /etc:/host/etc:ro \ custom-falco:latest 73 カスタムルールを適用する
74. 74 Falco コンテナとして実行できる コンテナオーケストレーターで Falcoを実行する
75. • Falcoを利用するECSタスク定義を作成する ◦ カスタムルール設定を含んだコンテナイメージを利用 • ECSサービスをDAEMONタイプとして実行する ◦ 各EC2（ECSコンテナインスタンス）にFalcoが配置される 75 ECS on EC2環境で実行してみる
76. 76 ECS on EC2環境で実行してみる { "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole", "taskRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole", "requiresCompatibilities": [ "EC2" ], "containerDefinitions": [ { "name": "test-falco", "image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/custom-falco:v1", "privileged": true, "logConfiguration": { "logDriver": "awslogs", "options": { "awslogs-group": "/ecs/test-falco-ec2-task", "awslogs-region": "ap-northeast-1", "awslogs-stream-prefix": "ecs" } } } ] } ECSタスク定義（一部抜粋）
77. 77 ECS on EC2環境で実行してみる { "volumes": [ { "name": "host-docker-sock", "host": { "sourcePath": "/var/run/docker.sock" } }, { "name": "host-dev", "host": { "sourcePath": "/dev" } }, { "name": "host-proc", "host": { "sourcePath": "/proc" } }, { "name": "host-boot", "host": { "sourcePath": "/boot" } }, { "name": "host-lob-modules", "host": { "sourcePath": "/lib/modules" } }, { "name": "host-usr", "host": { "sourcePath": "/usr" } }, { "name": "host-etc", "host": { "sourcePath": "/etc" } } ], "containerDefinitions": [ { "mountPoints": [ { "containerPath": "/host/var/run/docker.sock", "sourceVolume": "host-docker-sock"}, { "containerPath": "/host/dev", "sourceVolume": "host-dev" }, { "containerPath": "/host/proc", "sourceVolume": "host-proc", "readOnly": true }, { "containerPath": "/host/boot", "sourceVolume": "host-boot", "readOnly": true }, { "containerPath": "/host/lib/modules", "sourceVolume": "host-lob-modules", "readOnly": true }, { "containerPath": "/host/usr", "sourceVolume": "host-usr", "readOnly": true }, { "containerPath": "/host/etc", "sourceVolume": "host-etc", "readOnly": true } ] } ] } ECSタスク定義（一部抜粋）
78. • Falco アラート CloudWatch Logsへ 出力も可能 ◦ CloudWatch Alertなどを使った通知設定も可能 78 ECS on EC2環境で実行してみる
79. • FalcoコンテナをDaemonSetとして実行する • 公式からHelm Chartが用意されている $ helm repo add falcosecurity https://falcosecurity.github.io/charts $ helm repo update $ helm install falco falcosecurity/falco --namespace falco --create-namespace $ kubectl get all -n falco NAME READY STATUS RESTARTS AGE pod/falco-4ds47 1/1 Running 0 120s pod/falco-qtgb9 1/1 Running 0 120s NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/falco 2 2 2 2 2 <none> 118s 79 EKS on EC2環境で実行してみる https://falco.org/docs/getting-started/deployment/ https://github.com/falcosecurity/charts/tree/master/falco https://github.com/falcosecurity/deploy-kubernetes/tree/main/kubernetes/falco/templates • マニフェストをapplyして実行することも可能
80. 80 注意点 Fargateで 利用について
81. • Fargateで DAEMONタイプ / DaemonSet がサポートされ ていない • 同一コンテナ上でアプリケーションと一緒にFalco（および pdig）を起動する必要がある ◦ Falcoで Sidecarで 起動がサポートされていない ◦ falcosecurity/kilt を利用するとSidecarとして起動できるようだ が…… • ptraceを利用するため、タスク定義でLinux Capabilitiesとし て SYS_PTRACE を許可する必要がある ◦ ptraceでイベントを取得するためにpdigというツールを利用する 81 Fargate環境におけるFalco 利用方法
82. • Kernel moduleモード（デフォルト） ◦ Linuxカーネルからシステムコール 実行イベントを取得する モード • eBPF probeモード ◦ eBPFを利用してシステムコール 実行イベントを取得するモー ド • Userspace instrumentationモード ◦ 実行イベントをユーザー空間から取得するモード ◦ 2022年7月現在で 、ptraceを利用するpdig みをサポート ▪ ptrace 、他プロセス 制御を提供するシステムコール 82 Falco 実行モード https://falco.org/docs/event-sources/drivers/ https://falco.org/blog/choosing-a-driver/
83. 83 eBPFと ？ https://event.cloudnativedays.jp/cnsec2022/talks/1461
84. 84 Fargateにおけるプロセス分離 設計 https://d1.awsstatic.com/whitepapers/AWS_Fargate_Security_Overview_Whitepaper.pdf
85. • Fargate コンテナプロセス 、Firecracker MicroVMによっ てカーネルレベルで隔離されている • カーネル空間に対して不正にアクセスできないように、 Linux Capabilitiesが制限されている ◦ Privileged Containerが実行できない ◦ デフォルトで許可されているCapabilities 一覧 ▪ https://github.com/moby/moby/blob/master/oci/caps/defaults.go ◦ Fargateで タスク定義から SYS_PTRACE み追加可能 • FalcoをFargateで利用する場合 、pdigによってptraceを 利用してランタイムイベントを取得する 85 Fargateにおけるプロセス分離 設計
86. • pdigから同一コンテナ上 プロセスを指定してイベントを 取得する ◦ pdig ${command} / pdig -p ${process_id} • Falcoで そ イベントをルールベースで評価しアラートを 発生させる仕組み ◦ falco -u --pidfile /var/run/falco.pid 86 pdig 注意点 https://github.com/falcosecurity/pdig
87. • pdig falcosecurity/libs という別 モジュールに依存して いる ◦ 2022年7月現在、libs アップデートにpdigが追いついていない ため、READMEに記載 手順で pdigを実行できない • もしpdigを利用したい場合 、ソースコードからコンパイル する必要がある ◦ 具体的な利用イメージ 、下記リポジトリが参考になる ▪ kris-nova/falco-trace ▪ paavan98pm/ecs-fargate-pv1.4-falco • ContainersFromTheCouch: https://www.youtube.com/watch?v=OYGKjmFeLqI ▪ tomoyamachi/falco-on-distroless-fargate 87 pdig 注意点
88. • ランタイム 振る舞いを動的にスキャンして、異常な振る 舞いを検知できる ◦ ECS / EKS いずれ 環境でも導入可能 • プリセットなルールが用意されているため導入が容易 ◦ カスタムルールも設定可能 • 少なくとも現状で 、Fargateで 利用 正直厳しい ◦ FargateでeBPFなどがサポートされることに期待 ▪ https://github.com/aws/containers-roadmap/issues/1027 88 Falcoに関するまとめ https://falco.org/ https://github.com/falcosecurity/falco
89. 89 まとめ
90. • コンテナライフサイクルに沿ってリスクを整理し、各フェー ズにおける対応を検討することが有効 ◦ イメージ リスク ◦ レジストリ リスク ◦ オーケストレーター リスク ◦ コンテナ リスク ◦ ホストOS リスク • まず OSSツールを用いて、気軽にコンテナセキュリティを 始めてみよう • AWS マネージドサービスも活用することで多角的なコン テナセキュリティが実現できる 本セッション まとめ 90
91. 91 コンテナライフサイクル フェーズに応じた対応
92. 92 コンテナライフサイクル フェーズに応じた対応
93. コンテナセキュリティ全般 • [AWS Black Belt Online Seminar] コンテナセキュリティ入門 ◦ https://aws.amazon.com/jp/blogs/news/aws-black-belt-online-seminar- container-security-introduction/ • Liz Rice “Container Security” (O'Reilly Media) ◦ https://www.oreilly.com/library/view/container-security/978149205669 0/ 93 参考資料
94. Dockerfile • Dockerfile ベスト・プラクティス ◦ https://docs.docker.jp/develop/develop-images/dockerfile_best-practic es.html • Dockerfile ベストプラクティス Top 20 – Sysdig ◦ https://sysdig.jp/blog/dockerfile-best-practices-2/ Falco • Loris Degioanni, Leonardo Grasso “Practical Cloud Native Security with Falco” (O'Reilly Media) ◦ https://www.oreilly.com/library/view/practical-cloud-native/978109811 8563/ 94 参考資料
95. 95 Amazon ECS • Best Practices - Security - Amazon Elastic Container Service ◦ https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/se curity.html • Securing your Amazon ECS applications: Best practices ◦ https://speakerdeck.com/toricls/securing-your-amazon-ecs-applications- best-practices Amazon EKS • EKS Best Practices Guides ◦ https://aws.github.io/aws-eks-best-practices/ 参考資料
96. 96 ちなみに コンテナセキュリティに対応した 商用製品 ？
97. • Aqua Enterprise • Snyk Container • Trend Micro Cloud One ◦ Container Security ◦ Workload Security 97 コンテナセキュリティに対応した商用製品
98. 98 コンテナセキュリティに対応した商用製品
99. 99 クラスメソッド セキュリティパートナー https://classmethod.jp/partner/category/security/