Atomic Red Teamを使用してKubernetesでFalcoルールをテストする方法

本文の内容は、2022年5月31日に Jason Avery が投稿したブログ(https://sysdig.com/blog/atomic-red-team-falco/)を元に日本語に翻訳・再構成した内容となっております。

機能するかどうかを知るには、実際に使ってみるのが一番です。セキュリティ製品が実際に機能しているかどうかを確認することは、日常的なメンテナンスの基本的な作業です。このため、ATT&CKの手法に基づいて疑わしいイベントを生成するAtomic Red Teamのようなツールを使用し、Falcoがどのようにアラートをトリガーするかを確認することは非常に有効です。

Secure K8s with Falco and Atomic Red Team
このブログでは、Falcoのルールをテストするために、Kubernetesシステム上にAtomic Red Team環境をインストールし、実行する方法について説明します。

Atomic Red Teamとは？

Red Canaryは、さまざまなプラットフォームでATT&CKテクニックをテストするためのAtomic Red Teamリポジトリを維持しています。Mitre ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) は、サイバー攻撃を実際に観察して、既知の戦術や技術を分類するためのガイドラインです。

また、Powershellを使ってテストを実行するためのフレームワーク Invoke-AtomicRedTeam も公開されています。そう、PowershellはWindowsだけでなく、Linuxでも実行できるのです。

ATT&CKテクニックの各手法は、”T” の後に整数の識別子がついています（T1611 “Escape to Host”）。Atomic Red Teamは、ピリオドの後に整数を付けることで、各技法に対する異なるテストを示します（T1611.002）。各テストは、ダッシュと順序番号で定義された順序で異なる手法を持つことができます。つまり、テクニック T1560は ”収集データのアーカイブ”、T1560.002は ”収集データのアーカイブ: ライブラリ経由のアーカイブ “テストとT1560.002-001は具体的には、”Python（Linux）でbz2を使ってデータを圧縮する” テストです。

KubernetesでAtomic Red Teamを起動するための要件

今回のテスト環境では、KubernetesクラスターとFalcoのインストールが必要です。標準的なKubernetesインスタンスのインストール方法はこのブログでは取り上げませんが、Atomic Red TeamのDockerイメージの作成方法と、テスト実行に必要な依存関係をインストールする方法を説明します。

Falcoを使用したAtomic Red Teamの図

MinikubeとFalcoを使った簡単なラボ環境のインストール方法については、こちらの記事をご覧ください。

Root かテストユーザーか？

最初の調査では、テストを実行するために、sudoアクセス権を持つ非特権テストユーザーを作成しました。しかし、大半のテストはコマンドを実行するために昇格した特権を必要とすることがわかりました。一般ユーザーで実行すると、sudo を使用するためにテストケースを一括更新する必要があります。

ソースを使ったテストを容易にするために、Dockerイメージはrootで実行されます。

テストのメタデータをマイニングする

テストの成功や失敗をベンチマークして追跡するには、まずテストのメタデータを抽出して文書化する必要があります。

幸運なことに、Python には YAML ファイルを解析するモジュールがあり、JSON ファイルが解析されるのと同じように、YAML ファイルを使いやすい辞書に読み込んでくれます。ここでは、データを生成するための簡単な Python スクリプトを紹介します。出力されたatomic-parsed.tsvファイルは、お好みのスプレッドシートプログラムにインポートすることができます。

Atomic Red TeamのDockerfileをビルドする

Dockerイメージのビルドに慣れていない方のために、ここでその方法を説明します。まず、Dockerfile を作成する必要があります。これは Docker がイメージをどのようにビルドするかの指示書です。Atomic Red Teamのテストの多くは、追加のソフトウェアパッケージのインストールを必要とします。テストの時間と帯域幅を節約するために、パッケージの依存関係をDockerイメージに前もってインストールすることにします。

幸いなことに、私たちはすでにLinuxパッケージの依存関係をナビゲートしており、イメージと一緒にそれらをインストールする予定です。

Atomic Red のテストの YAML を調整する必要がある場合、ビルドプロセスの間にテストを上書きしていきます。次のセクションで、なぜそうしたいのかを説明します。 atomic-red-team/atomics にあるテストの YAML をイメージビルドディレクトリの適切な atomic-overrides サブディレクトリにコピーし、修正を加えます。 atomic-override/ ディレクトリのファイルは、ソースを置き換えます。

以下は、UbuntuベースのイメージをビルドするためのDockerfileです。また、ビルドディレクトリにサポートファイルをダウンロードすることになります。

なお、tsharkはインストール自動化の問題でインストールされていないので、テスト用T1040はtcpdumpで代用可能です。機能的には、テスト用として同等です。

Dockerfileができたので、いよいよイメージのビルドです。ビルドディレクトリからビルドコマンドを実行します（ dockerの実行にはsudo 権限が必要な場合があります）。

docker build -t atomic_red_docker:latest .

docker.io のアカウント (無料) を持っていて、イメージをリモートで保存したい場合は、プッシュする前にイメージに適切なタグを付ける必要があります：

docker login
docker tag atomic_red_docker:latest MyRemoteRepo/atomic_red_docker:latest
docker push MyRemoteRepo/atomic_red_docker:latest

うまくいけば、イメージがアップロードされ、Kubernetesが利用できるようになります。

既知テスト問題のトラブルシューティング

ほとんどのソフトウェアと同様に、バグや環境のばらつきによって、特定のテストケースの実行に問題が発生することがあります。Atomic Red Teamのリポジトリで提供されているテストの中には、コードの問題や望ましくない効果を引き起こすものがあるかもしれません。上記のDockerfileでは、ローカルで微調整を行い、 atomic-overrides ディレクトリからDockerイメージに追加することができます。

例えば、T1574.006 “Hijack Execution Flow: LD_PRELOAD” には、その -CleanUp 関数で sed を使用した表現の問題があることがわかりました。私たちは修正を提出し、それがマージされました。

微調整または回避したいかもしれないテストの一つに、T1070.004-4 があります。このテストでは、ファイルシステム全体が削除されます。簡単に言うと、 rm -fr /*となります。コンテナを再作成してファイルシステムを元の状態に戻すことはできますが、複数のテストケースがあるテストシーケンスでは予期せぬ中断を引き起こす可能性があります。これについては、テストのオーバーライドとして、YAML の定義で rm コマンドを echo 文に置き換えるだけでよいでしょう。同様に、Technique T1529には、テスト対象のシステムをシャットダウンしたりリブートしたりする様々なメソッドがあります。そのため、こちらも日常的なテストではスキップした方がいいかもしれません。

T1048、T1048.002、T1048.003、T1105、および T1110.004 のような流出、ファイル転送、およびクレデンシャルスタッフィングテストは、通信するリモートホストを必要とします。これらのテストを実施するには、セカンダリシステムが必要な場合があります。一部のテスト構成が必要な場合があり、 pwsh 内からパラメータで定義できます。

いくつかのテストは、もはや利用できないパッケージを必要としたり、auditd や systemd は、Ubuntu のようなディストロで利用できないシステム機能を必要とする場合があります。テスト T1053.001, T1053.006, T1543.002, T1562.001 はテストのためにこれらの機能に依存しています。

KubernetesのYAMLをビルドする

このイメージをKubernetesから実行するには、Deploymentとして、またはJobとしての2つの方法があります。手動でテストを実行したり、一般的にAtomic Red Teamで遊びたい場合は、デプロイメントオブジェクトタイプを使用する必要があります。単にテストの実行を日常的に自動化したいのであれば、Job の種類とシンプルなフロントエンドのスクリプトを使って、必要なテストを実行することができます。

デプロイメントオブジェクト（手動テスト）については、この YAML ファイルをコピーして、リモートの Docker イメージの場所に更新してください。なお、特権的なセキュリティコンテキストは、T1611.002で使用するために意図的に設定されています。

自動テストのために、シンプルなPowershellフロントエンドスクリプトがDockerfileに追加され、ID参照によるテストを自動化するようになりました。あとは、Job kind の YAML に実行したいテストを指定するだけです。YAMLが適用されると、Kubernetesがコンテナを作成し、選択したテストを開始します。

Atomic Red Teamを手動でテストする方法

テストを手動で実行するには、実行中のコンテナでシェルを実行します（最初にポッド名を取得します）。

kubectl exec -ti <pod name> -- /bin/bash

コンテナ内に入ったら、 “pwsh.” でPowershellを起動します。次に、Atomic Red Teamのモジュールをロードします：

Import-Module "~/AtomicRedTeam/invoke-atomicredteam/Invoke-AtomicRedTeam.psd1" -Force

ここで、実行したいテストIDのスプレッドシートを確認します。この例では、T1037.004 “Boot or Logon Initialization Scripts” を使用することにします。また、 -ShowDetails オプションを使用すると、テストの詳細な情報を得ることができます。

Invoke-AtomicTest T1037.004 -ShowDetails

まず最初に、テスト条件が正しいことを確認するために、あらゆる前提条件を取得します：

Invoke-AtomicTest T1037.004 -GetPreReqs

完了したら、テストを実行します。このテストでは、/etc/rc.common および /etc/rc.local ファイルを変更しようとします。

Invoke-AtomicTest T1037.004

いくつかのテストは、設定パラメータを設定する必要があります。手動でテストする場合、 -PromptForInputArgs オプションを使用して、モジュールが任意のパラメータに対してプロンプトを設定することができます。

Invoke-AtomicTest T1037.004 -PromptForInputArgs

次のテストに移る、あるいは作業を終了する準備ができたら、他のテストの実行に問題が発生する可能性を避けるために、テストを -CleanUpしたくなるでしょう。

Invoke-AtomicTest T1037.004 -CleanUp

ハンズオン – Falco

Falcoは、独自のコンテナとしてインストールし、Atomic Red Teamのコンテナ環境での活動を監視することができます。Falcoのインストールには様々な方法がありますが、私たちはHelmを使用してインストールすることにしました。FalcoのGitHubリポジトリにはインストール方法が詳しく書かれていますし、Falcoのブログの説明にも従えます。簡単に言うと、3つのコマンドが必要です。

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm install falco falcosecurity/falco

これだけです。Falcoコンテナはインストールを開始し、追加の必要なインタラクションなしにログを取り始めるでしょう。

Falcoのルールがトリガーされたことを確認する

Invoke-AtomicTestからいくつかのテストが完了したら、検出されたイベントを見るためにFalcoのログをチェックします。

Falco の出力 Atomic Red Team

Falco のログがどのように設定されたかに応じて、ログはログアグリゲータまたは他の通知システムに送られるかもしれません。不明な場合は、常に kubectl logs <falco pod>でローカルのFalcoログを直接確認することができます。ログが表示されるまでには数分かかるかもしれませんし、Falco のログキューイングがどのように動作するかのために、バーストで表示されるかもしれません。

追加のテストを実行することで、ログをキューに通すことができます。テストを実行した後、Falco ログがまだ空であれば、Falco イベントジェネレータを使用して、 Falco インストールの機能性と性能をテストしてみることができます。

快適なテストを

組織は、悪者を捕まえるための最高のツールと技術を持っているかもしれませんが、保護が機能していることを確認し、あらゆるカバーギャップを見つけるために、環境をテストすることは常に良い考えです。

Atomic Red TeamのMitre ATT&CKテクニックレプリケーションスイートは、コンテナ内でFalcoのインストールを安全な方法でテストするのに役に立ちます。

その後、もしあなたがFalcoについてもっと知りたいのであれば。

まずはFalco.orgをご覧ください。
GitHubでFalcoプロジェクトをチェックしてください。
Falco コミュニティに参加する。
Falco Slackでメンテナーと交流する。
ツイッターで @falco_org をフォローする。