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


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 コンテナセキュリティと ？

4 よくあるご相談 コンテナを利用する上で 漠然とセキュリティへ 不安がある

● コンテナを使いたいが、セキュリティが不安 ○ 利用経験がない で、コンテナ特有 事情がわからない ● すでにコンテナを利用し始めているが、不正に侵入されな いか心配 ○ 具体的な脅威がわからない ○ ど ように侵入を防げ 良いかわからない ● コンテナ セキュリティ対応 イメージがつかない ○ 例え 、Amazon EC2 ようなVMだったらIDSやアンチマルウェ アソフトを入れるなど、イメージがつきやすい 5 よくあるご相談

6 コンテナを扱う上で、出てくる要素が多い コンテナ イメージ レジストリ Dockerfile ECR Fargate Kubernetes コンテナ ホスト コントロール プレーン データプレーン オーケストレーター コンテナ ランタイム CI/CD ECS EKS EC2 BuildKit

● 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 コンテナセキュリティにおけるフレームワーク

● コンテナライフサイクルに沿ってリスクと対応を整理 ○ イメージ リスク ○ レジストリ リスク ○ オーケストレーター リスク ○ コンテナ リスク ○ ホストOS リスク 8 NIST SP 800-190を紹介

● イメージ リスク ○ イメージ 脆弱性 ○ イメージ 設定 不備 ○ 埋め込まれたマルウェア ○ 埋め込まれた平文 機密情報 ○ 信頼できないイメージ 使用 ● レジストリ リスク ○ レジストリへ セキュアでない接続 ○ レジストリ内 古いイメージ ○ 認証・認可 不十分な制限 9 NIST SP 800-190を紹介

● オーケストレーター リスク ○ 制限 ない管理者アクセス ○ 不正アクセス ○ コンテナ間 ネットワークトラフィック 不十分な分離 ○ ワークロード 機微性レベル 混在 ○ オーケストレーターノード 信頼 ● コンテナ リスク ○ ランタイムソフトウェア内 脆弱性 ○ コンテナから 無制限 ネットワークアクセス ○ セキュアでないコンテナランタイム 設定 ○ アプリ 脆弱性 ○ 未承認コンテナ 10 NIST SP 800-190を紹介

● ホストOS リスク ○ 大きなアタックサーフェス ○ 共有カーネル ○ ホストOSコンポーネント 脆弱性 ○ 不適切なユーザーアクセス権 ○ ホストOSファイルシステム 改ざん 11 NIST SP 800-190を紹介

● イメージ ビルド時 リスクを想定 ● Log4Shellなどアプリケーション 脆弱性を含んだコンテナ イメージを作成し実行 ● アプリケーション 脆弱性を利用して、実行中 コンテナ 外部から任意 コードを実行されてしまう 12 コンテナ利用における脅威 シナリオ① Attacker Container 任意 コードを実行 アプリケーション 脆弱性を含んだコンテナ

● イメージ ビルド時 リスクを想定 ● Dockerfileに機密情報を直接書き込んだ上でイメージを作 成 ○ AWSアクセスキーやDB 接続・認証情報など ● 実行中 コンテナ外部からdocker historyコマンドで機密 情報が奪取されてしまう 13 コンテナ利用における脅威 シナリオ② Attacker Container docker history 機密情報を含んだ コンテナ

● コンテナ実行時 リスクを想定 ● なんらか 手段でコンテナ 接続経路や認証情報が奪取 され、docker/kubectl execコマンドで侵入される ● コンテナ上でコインマイナーなど不正なファイルをダウン ロードされ、実行されてしまう 14 コンテナ利用における脅威 シナリオ③ Attacker Container 侵入 ダウンロード Malware

15 コンテナライフサイクルを考える

16 コンテナライフサイクル フェーズを分類する

17 コンテナライフサイクルを踏まえた上で AWSサービスによる対応方法を考える

● 関連する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 コンテナライフサイクルに当て めて考える

ECRによるコンテナイメージ 脆弱性スキャン 20 https://dev.classmethod.jp/articles/ecr-repository-scan/ https://dev.classmethod.jp/articles/amazon-ecr-enhanced-scanning/

ECRにおけるレジストリ保護 21 https://dev.classmethod.jp/articles/ecr-lifecycle/ https://docs.aws.amazon.com/AmazonECR/latest/userguide/regi stry-permissions-create.html

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/ ※チェック項目やマネージドルール どんどんアップデートされている で、最新 情報 公式ドキュメントを参照

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/

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 ここで疑問 AWSサービスによる対応 みで充分か？

● 必要となる対応内容 、ケースバイケース ○ 重視したい脅威やリスク 、企業や組織ごとに異なる ○ セキュリティポリシーにもよる ● ここで挙げたも 、あくまでもマネージドサービス ○ 導入や管理 手間が省けるが、カバーできない範囲もある ○ 特に「コンテナランタイム 保護」 部分 、現状で AWS サービスだけで 対応できない ● 比較的少額と いえ有料 サービスもある で、もっと気 軽に試してみたい 26 AWSサービスによる対応 みで充分か？

27 本日 テーマ OSS ツールを活用して コンテナセキュリティを実現しよう

28 2つ ツールを紹介

● Trivy 、コンテナイメージ 脆弱性スキャンツール ● Falco 、ランタイム保護を提供するツール ● どちらもLinux Foundationが提供するKubernetesセキュリ ティ認定試験 カリキュラムに組み込まれている ○ Certified Kubernetes Security Specialist (CKS) ○ コンテナセキュリティにおいてデファクトスタンダードなツールと 言える 29 TrivyとFalcoについて

30 Kubernetes認定試験 FAQに記載がある https://docs.linuxfoundation.org/tc-docs/certification/faq-cka-ckad-cks

31 コンテナライフサイクルに当て める

32

● 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

● 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/

● コンテナイメージをスキャンしてみる $ 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 コンテナイメージ 脆弱性スキャン

● 出力する脆弱性を重大度でフィルタリングする $ 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 コンテナイメージ 脆弱性スキャン

● 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 コンテナイメージ 脆弱性スキャン

● 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/

● イメージ ビルド時 リスクを想定 ● Log4Shellなどアプリケーション 脆弱性を含んだコンテナ イメージを作成し実行 ● アプリケーション 脆弱性を利用して、実行中 コンテナ 外部から任意 コードを実行されてしまう 40 (再掲) コンテナ利用における脅威 シナリオ① Attacker Container 任意 コードを実行 アプリケーション 脆弱性を含んだコンテナ

● 古いバージョン 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

● 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 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 update' should always be followed by ' install' in the same RUN statement. The instruction 'RUN update' should always be followed by ' 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

● 出力に従って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

● イメージ ビルド時 リスクを想定 ● Dockerfileに機密情報を直接書き込んだ上でイメージを作 成 ○ AWSアクセスキーやDB 接続・認証情報など ● 実行中 コンテナ外部からdocker historyコマンドで機密 情報が奪取されてしまう 45 (再掲) コンテナ利用における脅威 シナリオ② Attacker Container docker history 機密情報を含んだ コンテナ

● 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

● コンテナイメージをビルドし、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 脅威シナリオ②に対する対応策

● CodeBuild Buildspec 中でTrivyを実行する ○ イメージをECRにpushする前にスキャンや設定チェックを実行 する 48 CI/CDへ 組み込み: CodePipeline https://aws.amazon.com/jp/blogs/containers/scanning-images-with-trivy-in-an-aws-codepipeline/

● 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/

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

● 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/

● Trivyを利用することで、コンテナイメージスキャンや Dockerfile設定チェックを容易に導入できる ○ CI/CDパイプラインへ 組み込みも容易 ○ 他にも機能が豊富 ● Kubernetesであれ 、オーケストレーター保護も可能 ● 近年、サプライチェーンセキュリティ 文脈から注目されて いるSBOM 作成も可能 ○ Software Bill Of Materials ○ ソフトウェアに含まれる依存関係やライブラリ 種類などをリス ト化したも 52 Trivyに関するまとめ

53

● Sysdig社が中心となって開発されているOSS ○ 現在 CNCF（Cloud Native Computing Foundation）に寄贈され ている ● ランタイムセキュリティを提供するツール ○ ランタイムにおける振る舞いを動的にスキャンし、異常な振る 舞いを検知する ○ コンテナに限らず、ホスト ランタイム保護なども可能 ● 振る舞い 検知に注力したツールである ○ 異常な振る舞い 検知に加えて防止まで実施したい場合 、 商用製品であるSysdig Secureを導入する必要がある 54 Falcoと ？ https://falco.org/ https://github.com/falcosecurity/falco

● ホストやコンテナランタイムで発生したイベントを動的にス キャンして、あらかじめ用意したルールに適合するかどう かフィルタリングする ○ ルールに合え アラートを出力する ● プリセットなルールがいくつか用意されている で、すぐに 使い始められる ● 独自 カスタムルールも設定できる で、企業や組織 セキュリティポリシーに応じた対応が可能 55 Falcoが提供する機能

56 Falcoを実際に動かしてみる

● 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/

● 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環境で実行してみる

● 別 ターミナルから不正な操作を実行してみる ○ /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= user_loginuid=-1 command=touch /bin/surprise file=/bin/surprise parent=sudo pcmdline=sudo touch /bin/surprise gparent=bash container_id=host image=)

● 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

● プリセットなルールによって不正な操作が検出された - 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

● カスタムルールを設定することで、プリセットなルールを上 書きできる ○ 独自にファイルパスを指定することも可能 - 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

● 別 ターミナルから不正な操作を実行してみる ○ 先ほどと同じコマンドを実行する ● 実行ログが 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=) $ sudo touch /bin/surprise2 63 変更したルールを動作確認してみる

● コンテナ実行時 リスクを想定 ● なんらか 手段でコンテナ 認証情報が奪取され、 docker/kubectl execコマンドなどで侵入される ● コンテナ上でマイニングツールなど不正なファイルをダウ ンロードされ、実行されてしまう 64 (再掲) コンテナ利用における脅威 シナリオ③ Attacker Container 侵入 ダウンロード Malware

● コンテナ内部へ 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 脅威シナリオ③に対する対応策 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 Falcoを実際に動かしてみる Falcoをコンテナとして実行してみる

● 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/

● 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 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

● 別 ターミナルから不正な操作を実行してみる ○ 先ほどと同様 ● 不正な操作を検知し、実行ログが出力される $ 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=)

● カスタムルール設定ファイルを含んだコンテナイメージを ビルドして起動する - 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

● カスタムルール設定ファイルを含んだコンテナイメージを ビルドして起動する ● カスタムルールが適用された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 Falco コンテナとして実行できる コンテナオーケストレーターで Falcoを実行する

● Falcoを利用するECSタスク定義を作成する ○ カスタムルール設定を含んだコンテナイメージを利用 ● ECSサービスをDAEMONタイプとして実行する ○ 各EC2（ECSコンテナインスタンス）にFalcoが配置される 75 ECS on EC2環境で実行してみる

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 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タスク定義（一部抜粋）

● Falco アラート CloudWatch Logsへ 出力も可能 ○ CloudWatch Alertなどを使った通知設定も可能 78 ECS on EC2環境で実行してみる

● 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 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 注意点 Fargateで 利用について

● Fargateで DAEMONタイプ / DaemonSet がサポートされ ていない ● 同一コンテナ上でアプリケーションと一緒にFalco（および pdig）を起動する必要がある ○ Falcoで Sidecarで 起動がサポートされていない ○ falcosecurity/kilt を利用するとSidecarとして起動できるようだ が…… ● ptraceを利用するため、タスク定義でLinux Capabilitiesとし て SYS_PTRACE を許可する必要がある ○ ptraceでイベントを取得するためにpdigというツールを利用する 81 Fargate環境におけるFalco 利用方法

● 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 eBPFと ？ https://event.cloudnativedays.jp/cnsec2022/talks/1461

84 Fargateにおけるプロセス分離 設計 https://d1.awsstatic.com/whitepapers/AWS_Fargate_Security_Overview_Whitepaper.pdf

● 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におけるプロセス分離 設計

● pdigから同一コンテナ上 プロセスを指定してイベントを 取得する ○ pdig ${command} / pdig -p ${process_id} ● Falcoで そ イベントをルールベースで評価しアラートを 発生させる仕組み ○ falco -u --pidfile /var/run/falco.pid 86 pdig 注意点 https://github.com/falcosecurity/pdig

● 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 注意点

● ランタイム 振る舞いを動的にスキャンして、異常な振る 舞いを検知できる ○ ECS / EKS いずれ 環境でも導入可能 ● プリセットなルールが用意されているため導入が容易 ○ カスタムルールも設定可能 ● 少なくとも現状で 、Fargateで 利用 正直厳しい ○ FargateでeBPFなどがサポートされることに期待 ■ https://github.com/aws/containers-roadmap/issues/1027 88 Falcoに関するまとめ https://falco.org/ https://github.com/falcosecurity/falco

89 まとめ

● コンテナライフサイクルに沿ってリスクを整理し、各フェー ズにおける対応を検討することが有効 ○ イメージ リスク ○ レジストリ リスク ○ オーケストレーター リスク ○ コンテナ リスク ○ ホストOS リスク ● まず OSSツールを用いて、気軽にコンテナセキュリティを 始めてみよう ● AWS マネージドサービスも活用することで多角的なコン テナセキュリティが実現できる 本セッション まとめ 90

91 コンテナライフサイクル フェーズに応じた対応

92 コンテナライフサイクル フェーズに応じた対応

コンテナセキュリティ全般 ● [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 参考資料

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 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 ちなみに コンテナセキュリティに対応した 商用製品 ？

● Aqua Enterprise ● Snyk Container ● Trend Micro Cloud One ○ Container Security ○ Workload Security 97 コンテナセキュリティに対応した商用製品

98 コンテナセキュリティに対応した商用製品

99 クラスメソッド セキュリティパートナー https://classmethod.jp/partner/category/security/

No content