Linuxとクラウドの検出エンジニアリング - Defend for Containers (D4C) 入門

はじめに

Linuxシステムは、現代のインフラストラクチャ、特にコンテナやオーケストレーションプラットフォームが標準となっているクラウドネイティブ環境において、依然として重要な基盤となっている。ワークロードが長期稼働するホストから一時的なコンテナへと移行するにつれて、攻撃者の手口も変化する。かつてはディスク上に永続的な痕跡を残していたアクティビティは、ますます短命な実行時動作に限定されるようになり、従来のログソースでは捕捉が困難になっている。

したがって、このような環境における検出エンジニアリングは、実行時の可視性に大きく依存する。コンテナ内でプロセスがどのように実行されるか、ファイルがどのようにアクセスされるか、ワークロードがホストとどのように相互作用するかを理解することは、静的な指標やインシデント後の成果物に頼るよりも重要になります。

Elasticは、この種の検出作業をサポートするために、Linuxに特化した複数のテレメトリソースを提供しています。このシリーズの以前の記事では、AuditdとAuditd Managerを使用したホストレベルの可視性に焦点を当て、低レベルのシステムイベントを高精度の検出に変換する方法を示しました。この記事では、Elastic社のDefend for Containersに焦点を当てます。これは、コンテナ化されたLinuxワークロード向けに特別に構築されたランタイムセキュリティ統合ソリューションです。

この記事の目的は、Defend for Containersのすべての機能を文書化することではなく、検出エンジニアにとって実践的な出発点を提供することです。つまり、この統合によってどのようなデータが生成されるか、そしてそのデータをどのように分析すればよいかを示すことです。次のパートでは、それが現実的なコンテナ攻撃シナリオにどのように適用できるかを見ていきます。

Defend for Containersによる効率的な可視性

バージョン9.3.0でDefend for Containersがリリースされることをお知らせいたします。リリース。この統合により、コンテナセキュリティへのアプローチが合理化され、クラウドネイティブインフラストラクチャにおける可視性のための強固な基盤が提供されます。ユーザーは、最新のKubernetesの脅威やコンテナ固有の脆弱性から防御するためにカスタマイズされた一連の検出ルールを活用できます。Defend for Containersの登場に伴い、現実的なコンテナおよびKubernetesの脅威モデルに基づいて設計された、コンテナ固有の検出ルールセットが導入されました。

本稿執筆時点では、Defend for Containersルールセットは、偵察活動、認証情報アクセス試行、kubelet攻撃、サービスアカウントトークンの悪用、対話型プロセス実行、ファイルの作成と変更、インタープリタの悪用、エンコードされたペイロードの実行、ツールのインストール、トンネリング動作、複数の権限昇格ベクトルなど、一般的なコンテナ攻撃手法に対する基本的な対策を提供しています。重要な点として、既存のコンテナおよびKubernetes固有の検出ルールはすべてDefend for Containersと互換性を持つようになり、これまでホスト中心だったロジックがコンテナのランタイムテレメトリに直接作用できるようになりました。

これにより、Defend for Containersは、動作駆動型のランタイム検出に重点を置くLinux検出エンジニアにとって、実用的で即座に利用可能なデータソースとなります。この記事の残りの部分では、そのテレメトリが実際にどのように見えるか、そしてそれが現実世界のコンテナ攻撃シナリオにどのように適用できるかに焦点を当てます。

Defend for Containersの概要

Defend for Containersは、Linuxコンテナの実行状況を可視化するランタイムセキュリティ統合ソリューションです。静的イメージのスキャンや実行後のログに頼るのではなく、コンテナの動作をリアルタイムで監視することに重点を置いています。

大まかに言うと、Defend for Containersは、実行中のコンテナから、プロセス実行やファイルアクセスなど、セキュリティに関連するランタイムイベントを捕捉します。これらのイベントにはコンテナとオーケストレーションのコンテキストが付加され、Elasticsearchに送信されます。Elasticsearchでは、これらのイベントを分析し、検出ルールの入力として使用できます。

検出エンジニアリングの観点から見ると、Defend for Containersは、従来のLinuxの動作とコンテナ環境の交点に位置します。プロセス、システムコール、ファイルアクティビティは依然としてコアシグナルですが、現在はコンテナ、名前空間、ワークロードといった、短期間しか存在しない可能性のある対象に限定されています。

Defend for ContainersはElastic Agentの一部としてデプロイされ、Elastic Securityと直接統合されます。有効化されると、コンテナのランタイムイベントの専用ストリームが提供され、KQLまたはES|QLを使用してクエリを実行したり、検出分析で直接利用したりすることができます。これにより、検出エンジニアは、クラウドネイティブワークロードの運用上の現実を考慮しながら、使い慣れた分析手法を適用できるようになります。

以降のセクションでは、Defend for Containersのイベントをより詳細に検証し、いくつかのコンテナ攻撃シナリオを通して、このデータが実際にどのように活用できるかを説明します。

コンテナの防御設定

Defend for Containersのランタイム可視性と分析機能を活用するには、まず統合をデプロイし、監視するイベントと、一致するアクティビティが検出されたときに実行するアクションを定義するポリシーを設定する必要があります。統合とその設定に関する詳細については、こちらをご覧ください。大まかに言うと、この構成は以下の要素から成り立っています。

Elastic Agent を介して Defend for Containers 統合を Kubernetes 環境にデプロイします。
コンテナの防御ポリシーを構成またはカスタマイズするには、どの操作を一致させるかを定義するセレクタと、実行するアクションを定義するレスポンスを使用します。
観測されたワークロードの挙動に基づいて、ポリシーを検証および改善する。

展開方法

Defend for ContainersはElastic Agentとの統合として提供され、Elastic Agentを利用してコンテナのランタイムテレメトリを収集し、Elastic Stackに転送します。Kubernetesワークロードの場合、Elastic SecurityのUIを介して統合をインストールし、その後、クラスタノードにエージェントを登録します。

基本的な導入フローは以下のとおりです。

Elastic SecurityのUIで、 Fleetに移動し、新しいエージェントポリシーを作成します（または、既存のポリシーに統合を追加します）。エージェントポリシーが作成されたら、そのポリシーに「Defend for Containers」の統合機能を追加できます。

統合に名前を付け、必要に応じてデフォルトのセレクターとレスポンスを調整します（利用可能なオプションについては、この出版物の後半で詳しく説明します）。「統合を追加」を選択すると、適切な統合が設定された新しいエージェントポリシーが利用可能になります。

今回のデモンストレーションでは、Kubernetesのデプロイ方法を活用します。このポリシーをワークロードにデプロイするには、[アクション] → [エージェントの追加] → [Kubernetes] に移動します。ここでは、Kubernetesマニフェストをコピーまたはダウンロードするための手順が示されています。

重要な注意点として、「以下のマニフェストには、本番環境に適さない可能性のあるリソース制限が含まれています。このマニフェストをデプロイする前に、 Kubernetes 上での Elastic Agent のスケーリングに関するガイドを確認してください。」という点にご注意ください。

サービスが機能するためには、Kubernetes YAML のsecurityContextの下に以下のcapabilities含める必要があります。

securityContext:
    runAsUser: 0
    capabilities:
      add:
        - BPF ## Enables both BPF & eBPF
        - PERFMON
        - SYS_RESOURCE

提供されたelastic-agent-managed-kubernetes.ymlマニフェストをコピーまたはダウンロードした後、必要に応じてマニフェストを編集し、以下のコマンドでマニフェストを適用できます。

kubectl apply -f elastic-agent-managed-kubernetes.yml

マニフェストにも記載されているとおり、デプロイメントの詳細については、「 Fleet で管理される Kubernetes 上で Elastic Agent を実行する」ガイドを参照してください。

Elastic Agentポッドのスケジュールが完了し、データがElasticsearchに流れ込み始めるまでお待ちください。

Elastic Agentはデプロイされると、Fleetへの接続を確立し、選択されたポリシーに登録し、Elastic Securityが利用できるDefend for Containersのテレメトリデータの送信を開始します。

次のセクションでは、統合構成オプションについて見ていき、利用可能な機能について詳しく見ていきます。

コンテナ保護ポリシー

Defend for Containersの設定の中核となるのはポリシーです。ポリシーは、どのような活動を監視すべきか、また一致する事象が発生した場合にどのように対応すべきかを規定する。政策は、2つの基本的な構成要素から成り立っています。

セレクタ：操作と条件を指定することで、関心のあるイベントを定義します。
応答：セレクタの条件が満たされたときに実行するアクションを定義します。

Defend for Containersのポリシーは、デプロイ前に編集することも、デプロイ後にElastic Security UIのポリシーエディタを使用して変更することもできます。

政策構造

各ポリシーには、少なくとも1つのセレクタと少なくとも1つのレスポンスが含まれている必要があります。一般的なセレクタは、1つ以上の操作（プロセスイベントやファイルアクティビティなど）を指定し、条件（コンテナイメージ名、名前空間、ポッドラベルなど）を使用して範囲を絞り込みます。応答はセレクタを参照し、イベントが一致した場合に実行するアクションを示します。

デフォルトのDefend for Containersポリシーには、「脅威検出」と「ドリフト検出と防止」という2つのセレクターとレスポンスのペアが含まれています。

脅威検出: selectorという名前がallProcessesで、コンテナからのすべてのforkおよびexecイベントに一致します。

また、関連付けられたresponseのアクションはLogに設定されており、イベントが取り込まれて分析できることが保証されます。

ドリフト検出と防止： executableChangesという名前のセレクタは、 createExecutableとmodifyExecutable操作に一致します。

また、応答はアラートを作成するように構成されており（これらの操作をブロックするように変更することも可能です）。

これらはUI経由で変更できますが、内部的には、これらのポリシーは簡単に変更でき、あらゆるCI/CDフローで使用できるシンプルなYAML設定ファイルです。

process:
  selectors:
    - name: allProcesses
      operation:
        - fork
        - exec
  responses:
    - match:
        - allProcesses
      actions:
        - log
file:
  selectors:
    - name: executableChanges
      operation:
        - createExecutable
        - modifyExecutable
  responses:
    - match:
        - executableChanges
      actions:
        - alert

次に、いくつかのセレクターとレスポンスの例を見ていき、統合を好みに合わせて設定するためのオプションについて説明します。

セレクターのスニペット例

セレクタを使用すると、次のようなフィールドの条件に基づいて、きめ細かなマッチングを行うことができます。

containerImageFullName: docker.io/nginxのような完全な画像名 ;
containerImageName: 画像名の一部。
containerImageTag: 最新などの特定のタグ。
kubernetesClusterId: KubernetesクラスタID;
kubernetesClusterName: Kubernetesクラスタ名。
kubernetesNamespace: ワークロードが実行される名前空間。
kubernetesPodName: ポッド名（末尾のワイルドカードをサポート）。
kubernetesPodLabel: ラベルのキー/値ペア（ワイルドカード対応）。

selectors:
  - name: nodeExports
    file:
      operations:
        - createExecutable
        - modifyExecutable
      containerImageName:
        - "nginx"
      kubernetesNamespace:
        - "production"

In this example, the selector named nodeExports matches file events that create or modify executables within containers whose image names contain “nginx” and whose Kubernetes namespace begins with "production".

応答例の抜粋

応答は、選択条件が満たされたときに何が起こるかを決定します。一般的な行動には以下が含まれます。

log: イベントを分析用のテレメトリとして送信する。
alertElastic Securityでアラートを作成する。
block: 操作を防止します（サポートされている型の場合）。

responses:
  - name: alertAndBlockNodeExports
    matchSelectors:
      - nodeExports
    actions:
      - alert
      - block

ここで、 alertAndBlockNodeExportsという名前の応答は、以前に定義された nodeExports セレクタを参照し、アラートを生成すると同時に操作をブロックします。

ワイルドカードとマッチング

Selectors in Defend for Containers support trailing wildcards in string-based conditions (such as pod names or image tags). This allows broad matching without enumerating every possible value. The following fields do support wildcard matching:

For file selectors: kubernetesPodName, kubernetesPodLabel and targetFilePath.
For process selectors: kubernetesPodName, kubernetesPodLabel, processName and processExecutable.

For example, a kubernetesPodName selector of backend-* will match all pods whose names begin with backend-, while a kubernetesPodLabel condition such as role:api* matches label values that start with api.

このワイルドカード機能は、ワークロードが急速に拡大・変化する動的な環境において不可欠です。

Defend for Containersのセレクタは、単純な文字列照合に加えて、ファイルパスを照合する際にパスベースのワイルドカードセマンティクスもサポートしています。次のセレクタの例を考えてみましょう。

- name:
  targetFilePath:
    - /usr/bin/echo
    - /usr/sbin/*
    - /usr/local/**

この例では次のような処理が行われます。

/usr/bin/echo そのパスにあるバイナリファイルechoのみに一致します。
/usr/sbin/* /usr/sbinの直接の子であるすべてのものに一致します。
/usr/local/** /usr/local下のすべてを再帰的に一致させます。これには/usr/local/bin/somethingなどのパスも含まれます。

これらの区別により、ファイルベースのセレクタの範囲を正確に指定し、網羅性とノイズのバランスを取ることが可能になります。実際には、これらの機能により、検出エンジニアは、使用事例に応じて、過度に寛容なルールに頼ることなく、特定のバイナリ、ディレクトリ全体、または深いディレクトリツリーをターゲットにすることができる。

すべてをまとめる

ここまで、Defend for Containersのセレクタ、ワイルドカードのセマンティクス、イベントタイプ、そしてそれらが実行時に攻撃者の挙動をどのように明らかにするかについて見てきました。最後のステップは、これらの要素がポリシー内でどのように組み合わさって、実際の検出ロジックを表現するのかを理解することです。

次のポリシー断片を検討してください。

file:
  selectors:
    - name: binDirExeMods
      operation:
        - createExecutable
        - modifyExecutable
      targetFilePath:
        - /usr/bin/**
    - name: etcFileChanges
      operation:
        - createFile
        - modifyFile
        - deleteFile
      targetFilePath:
        - /etc/**
    - name: nginx
      containerImageName:
        - nginx

  responses:
    - match:
        - binDirExeMods
        - etcFileChanges
      exclude:
        - nginx
      actions:
        - alert
        - block

このポリシーでは、3つのセレクターを定義します。2つのセレクタ（ binDirExeModsとetcFileChanges ）は対象となるファイルシステムのアクティビティを記述し、3つ目のセレクタ（ nginx ）は除外するコンテナコンテキストを記述します。

レスポンスセクションでは、これらのセレクターを関連付けます。matchの下にリストされているセレクタは論理的にORとみなされます。つまり、どちらの条件でも応答をトリガーするのに十分です。excludeの下に記載されているセレクタは論理NOTとして機能し、コンテナイメージがnginxの場合に一致するイベントを削除します。

平易な言葉で言えば、この方針は以下の論理を表している。

/usr/binの下のどこかで実行可能ファイルが作成または変更された場合、あるいは/etcの下でファイルが作成、変更、または削除された場合で、そのアクティビティがnginxコンテナから発生していない場合は、アラートを生成してアクションをブロックします。

ブール形式では、これは次のように表現できます。

IF (binDirExeMods OR etcFileChanges) AND NOT nginx
→ alert + block

ここで、コンテナ保護ポリシーが真価を発揮します。クエリ言語で複雑な検出ロジックを記述する代わりに、セレクタを使用すると、動作を小さく再利用可能な構成要素に分解し、それらを宣言的に組み合わせることができます。パスベースのセレクタ、操作タイプ、コンテナコンテキスト、および除外条件を組み合わせることで、読みやすく保守しやすい、きめ細やかな検出ロジックを表現できます。

実際には、このモデルにより、検出エンジニアは脅威の仮説をポリシーロジックに直接変換できます。つまり、どのような動作が重要か、それがどこで発生するか、どのワークロードで発生するか、そしてそれが発生したときに何が起こるべきかを明確にすることができます。

政策の検証と改善

ポリシーが展開されたら、ブロックなどの積極的な対応を有効にする前に、実際のワークロードの動作に対してそのポリシーを検証することが極めて重要です。厳しすぎるポリシーはコンテナの正常な動作を妨げる可能性があり、寛容すぎるポリシーは望ましくない活動が見過ごされる可能性がある。

推奨されるワークフローは以下のとおりです。

デフォルトポリシーを監視モードで展開します（例：セレクターを使用してイベントをログに記録します）。
Elasticsearchに表示されるイベントを観察することで、通常のワークロードパターンを把握できます。
セレクターとレスポンスを段階的に厳格化し、ログのみ→アラート→ブロックの順で進め、各段階でテストを実施する。
本番環境に適用する前に、ステージング環境またはテスト環境のクラスターを使用して、ブロッキング動作を検証してください。

Defend for Containers ベータ版の制限事項

この記事執筆時点では、Defend for Containersはベータ版として提供されており、その機能とプラットフォームサポートはベータ版であることを反映しています。

Defend for Containersは、Amazon EKSとGoogle GKEを正式にサポートします。この統合機能はAzure AKSにデプロイできますが、この構成は公式にはサポートされていません。特に、AKSの導入環境では現在、ファイルイベントのテレメトリ機能が不足しているため、これらの環境におけるファイルベースの攻撃手法の検出範囲が制限されている。

現在のベータ版では、ネットワークイベントも捕捉されません。そのため、アウトバウンド接続、ネットワークの横方向移動、またはデータ漏洩に関連する検出は、Defend for Containersのテレメトリのみに依存するのではなく、ネットワークパケットキャプチャ統合やPacketbeat統合などの補完的なデータソースに頼る必要があります。

ファイルアクティビティに関して、Defend for Containersは、書き込み意図でファイルが開かれた場合にのみ、意図的にファイルオープンイベントをログに記録します。この設計上の選択により、ノイズが低減され、システムの状態を変化させる動作に焦点が当てられます。しかし、これは同時に、機密ファイルの読み取り専用アクセス（秘密情報の発見、設定情報のスクレイピング、アクセス失敗の試みなど）は、現時点では監視できないことを意味します。

この制限は、以下のような検出のユースケースに影響を与えます。

Kubernetesサービスアカウントトークンの検索と読み取り、
.envファイルまたは認証情報資料をスキャンしています。

これらは、将来のDefend for Containersのバージョンにおいて、高度な検出エンジニアリングのユースケースをサポートするために、より詳細なテレメトリが提供される可能性のある領域です。

Defend for Containersの事前構築済み検出ルールを有効にする

Defend for Containersには、一般的なコンテナ攻撃手法に対する基本的な対策を提供する、あらかじめ構築された一連の検出ルールが付属しています。統合が有効になると、これらのルールは追加の設定なしにElastic Securityから直接有効化できます。

あらかじめ用意されたルールを有効にすることをまず推奨します。これらのルールは、Defend for Containersのランタイムテレメトリと連携するように設計されており、コンテナ内での実行、ファイル変更、永続性、および侵害後の動作を網羅しています。そこから、ルールを拡張したり、環境固有のワークロードや脅威モデルに合わせて改良したりすることができる。

「データソース：Elastic Defend for Containers」でフィルタリングすると、この統合に関連付けられているすべてのルールを見つけることができます。

注:ルールが表示されない場合は、スタックがバージョン 9.3.0 で実行されていることを確認してください。これらのルールは9.3.0以降のバージョンでのみ展開されるためです。

ベータ版の重要な制限事項がすべて把握され、統合が展開され、事前構築済みの検出ルールがインストールおよび有効化され、動作するポリシーが確立されたら、次のステップは、Defend for Containers が生成するイベントのセマンティクスを調査することです。これには、検出ロジックで一般的に使用されるフィールド、パフォーマンスに関する考慮事項、およびこれらのイベントが Elastic Defend イベントとどのように異なるかなどが含まれます。

コンテナの防御イベントの分析

Defend for Containersがデプロイされ、ポリシーが設定されたので、次のステップは、それが生成するイベントを理解することです。Elastic DefendやAuditd Managerを扱う場合と同様に、Defend for Containersのテレメトリは、イベントの構造や検出エンジニアリングにとって最も重要なフィールドについてのメンタルモデルを構築することで、はるかに価値が高まります。

Defend for Containersは、複数のイベントタイプを生成します。中でも特に重要なのは、プロセスイベントとファイルイベントで、それぞれにコンテナ、ホスト、オーケストレーションのコンテキスト情報が付加されています。基盤となるシグナルはLinuxの動作に基づいているものの、Kubernetesとコンテナのメタデータを追加することで、ホストのみのテレメトリでは不可能な方法でアクティビティを分析できるようになります。

以下のセクションでは、実際のDefend for Containersイベントを参考にしながら、最も重要なフィールドグループとイベントタイプについて説明します。

共通フィールド

特定のイベントカテゴリについて詳しく説明する前に、Defend for Containersのテレメトリ全体に一貫して表示されるフィールドを理解しておくと役立ちます。これらのフィールドは、個々のランタイムアクションをポリシー、セレクタ、およびカーネル内部の基盤となる実行ポイントに結びつける、文脈的な接着剤の役割を果たします。

プロセスイベントとファイルイベントは詳細が異なりますが、以下に説明するフィールドはDefend for Containersのデータストリーム全体に存在し、検出結果の検証やポリシー動作のトラブルシューティングを行う際に最初に確認すべき箇所となることがよくあります。

コンテナ固有のコンテキストで防御する

Defend for Containersは、イベントの収集方法とポリシーの適用方法に関するいくつかの固有のフィールドを追加します。

cloud_defend.hook_pointフィールドは、カーネル内のどこでイベントが捕捉されたかを示します。示されている例では、 tracepoint__sched_process_forkやtracepoint__sched_process_execなどの値は、イベントがプロセスの作成と実行に関連付けられたカーネルトレースポイントから生成されたことを示しています。

cloud_defend.matched_selectorsフィールドは、アクティブなポリシー内のどのセレクタがイベントに一致したかを示します。この例では、値allProcessesは、このイベントがすべてのプロセスアクティビティを捕捉する広範なセレクタに一致したことを示しています。ポリシーを調整したり、アラートを調査したりする際に、このフィールドはイベントが捕捉された理由を理解するために不可欠です。

cloud_defend.package_policy_idとcloud_defend.package_policy_revisionフィールドは、イベントを特定のElastic Agentポリシーとその改訂版に紐付けます。これにより、時間の経過に伴う設定変更とイベントを関連付けたり、イベント発生時にどのバージョンのポリシーが有効だったかを確認したりすることが可能になります。

イベントメタデータ

Defend for Containersのイベントは、 Elastic Common Schemaの規則に従い、アクティビティの種類とライフサイクルを記述する標準的なイベントメタデータを含みます。

event.categoryフィールドは、 processやfileなどの高レベルのアクティビティの種類を識別し、通常は Defend for Containers データをフィルタリングする際に最初に使用されるフィールドです。event.actionフィールドは発生した事象を記述します。例えば、 forkまたはexecはプロセスアクティビティ、 open 、 creation 、 modification 、およびdeletionはファイルイベントです。

event.typeフィールドは、プロセス実行のためのstartのようなライフサイクルコンテキストを追加し、多くの場合、アクティビティの異なるフェーズを区別するためにevent.actionと組み合わせて使用されます。event.datasetフィールドは、 cloud_defend.processのような、Defend for Containers の元のデータストリームを示します。これは、データセットスコープのクエリや検出を作成する際に役立ちます。

event.id 、 event.ingested 、 event.kindなどの追加のメタデータフィールドは、検出ロジックではなく、主に相関関係、順序付け、トラブルシューティングに使用されます。

ホスト情報

Defend for Containersのイベントには、Elastic DefendやAuditd Managerと同様に、ホストの完全なコンテキストが含まれます。これにより、コンテナの実行時アクティビティを基盤となるKubernetesノードに関連付けることが可能になります。

host.nameフィールドはコンテナが実行されているノードを識別し、 host.os.*フィールドはディストリビューションやカーネルバージョンなどのオペレーティングシステムの詳細を提供します。host.architectureフィールドは CPU アーキテクチャを示しており、バイナリ実行やカーネル固有の動作を分析する際に重要となる場合があります。

特に便利なフィールドの1つはhost.pid_ns_inoで、これはPID名前空間を識別します。このフィールドを使用すると、コンテナのアクティビティをホストレベルのプロセスおよびカーネルのテレメトリと関連付けることができ、コンテナの脱出試行やノードレベルへの影響を調査する際に特に役立ちます。

クラウドネイティブ攻撃を分析する際には、ホストのコンテキストが非常に重要です。なぜなら、複数のコンテナが同じホストとカーネルを共有することが多く、コンテナの実行時動作は、その境界を超えて影響を及ぼす可能性があるからです。

コンテナとオーケストレーターのコンテキスト

Defend for Containersの最大の強みは、コンテナに関する高い認識能力にある。すべてのランタイムイベントには、コンテナとオーケストレーションのメタデータが付加され、何が、どこで、どのような権限で実行されているかというコンテキストでアクティビティを分析できるようになります。

コンテナレベルでは、 container.idやcontainer.nameなどのフィールドによって実行中のコンテナが一意に識別され、 container.image.name 、 container.image.tag 、およびイメージハッシュによってワークロードの発生元とバージョンが可視化されます。これは、想定されるユーティリティイメージと、予期せぬワークロードやアドホックなワークロードを区別するのに特に役立ちます。

リスク評価の重要なフィールドはcontainer.security_context.privilegedです。このフィールドは、コンテナが特権モードで実行されているかどうかを明示的に示します。特権実行が対話型シェルや広範なLinux機能などの他のシグナルと組み合わされると、検出されたあらゆる活動のリスクプロファイルは著しく増加します。

Defend for Containersは、イベントにオーケストレーションのコンテキストを追加する機能も備えています。orchestrator.cluster.name 、 orchestrator.namespace 、 orchestrator.resource.name （通常はPod名）などのフィールドは、ランタイム動作をKubernetesワークロードに結び付けます。orchestrator.resource.labelを介して公開されるラベルにより、検出にワークロードの意図と所有権を組み込むことがさらに可能になります。

検出エンジニアリングにおいて、このコンテキストは検出範囲を正確に絞り込むことを可能にします。

特定の名前空間（例： kube-system ）、
特権容器または高リスク容器、
機密ラベル付きのワークロード、
または、 netshoot 、 kubectl 、 curlなどの既知のユーティリティイメージ。

この拡張レイヤーにより、ファイルシステムパス、cgroup、または名前空間識別子から間接的に意図を推測することなく、コンテナ認識型の検出ロジックを直接表現できるようになります。

イベントを処理する

プロセス実行は、Defend for Containersが提供する最も重要なシグナルタイプの1つです。プロセスイベントは、コンテナ内のfork 、 exec 、およびendアクティビティをキャプチャし、実行時に実行がどのように展開されるかを理解するために重要な詳細な系統情報を公開します。

検出工学にとって特に重要な分野がいくつかある。process.nameとprocess.executableの組み合わせは、何がどこから実行されたかを特定し、 process.argsそれがどのように呼び出されたかについての情報を提供する。process.pid 、 process.start 、 process.end 、 process.exit_codeなどのフィールドはプロセスライフサイクルを記述し、タイミング分析や実行フローの再構築に役立ちます。process.entity_id 、複数の関連イベントにわたってプロセスを追跡できる安定した識別子を提供します。

Defend for Containersは、豊富な祖先情報も収集します。process.parent.*の下のフィールドは、直近の親プロセスを記述しており、予期しないバイナリによって生成されたシェルなど、疑わしい親子関係を検出することを可能にします。さらに、 process.entry_leader.*とprocess.session_leader.*プロセスツリー内の上位レベルのアンカーを提供します。

Elastic Defendと同様に、Defend for Containersはプロセスを個別のイベントではなくグラフとしてモデル化します。エントリリーダーは、コンテナ環境で特に役立ちます。これは、コンテナランタイムによって起動される最初のプロセス（たとえば、 containerd 、 runc 、またはコンテナのエントリポイントとして指定されたシェル）を表すことが多いためです。エントリリーダーに検出結果を固定することで、コンテナが多数の短命な子プロセスを生成する場合でも、プロセスツリーを一貫して解釈することが可能になります。

セッションリーダーフィールドは、対話型実行とセッション境界に関する追加情報を提供し、バックグラウンドサービスと対話型または攻撃者主導の活動を区別するのに役立ちます。

これらのフィールドを組み合わせることで、単一の実行にとどまらず、実行チェーン、系統、意図について推論する検出ロジックを表現することが可能になり、これは現実世界のコンテナ攻撃手法を検出するために不可欠です。

機能と特権のコンテキスト

Defend for Containers プロセスイベントの強力な機能の 1 つは、Linux の機能情報が含まれていることです。Defend for Containersは、各プロセスについて、有効な機能セットと許可された機能セットの両方を以下の方法で公開します。

process.thread.capabilities.effective
process.thread.capabilities.permitted

これらのフィールドは、ユーザーIDやコンテナの境界に関係なく、プロセスが実行時に実際に実行できる内容を記述します。

特権コンテナでは、プロセスは多くの場合、 CAP_SYS_ADMIN 、 CAP_SYS_MODULE 、 CAP_SYS_PTRACE 、 CAP_SYS_RAWIO 、 CAP_BPFなどの非常に機密性の高い機能を含む、幅広い有効な機能を公開します。これらの機能が存在すると、実行されるコマンドのリスクプロファイルが大きく変化します。なぜなら、これらの機能によって、ホストカーネルや他のワークロードに直接影響を与える可能性のあるアクションが可能になるからです。

検出工学の観点からすると、この状況は極めて重要である。これにより、検出は単純なプロセス名の照合を超え、影響について推論できるようになります。同じバイナリ実行であっても、最小限の機能セットで実行されるか、ホストレベルに近い権限で実行されるかによって、その影響は大きく異なる可能性がある。

実際には、能力データによって検出エンジニアは以下のことが可能になります。

過度に寛容なコンテナ内で実行されている疑わしいツールを特定する。
実行時動作と危険な機能の組み合わせとの相関関係を調べる。
表面的な活動ではなく、実際の悪用可能性に基づいてアラートの優先順位を付ける。

これは、コンテナからの脱出に関する研究において特に重要となる。なぜなら、特定の機能の有無が、エクスプロイトの有効性を左右することが多いからである。

対話型実行

process.interactiveフィールドは、プロセスが対話型セッションに関連付けられているかどうかを示します。コンテナ環境では、本番環境のワークロードにおいて対話型実行は比較的まれであり、侵害後やキーボード操作と強く相関することが多い。

Defend for Containers は、プロセスレベルだけでなく、 process.parent.interactive 、 process.entry_leader.interactive 、 process.session_leader.interactiveを含む関連する実行コンテキスト全体でのインタラクティビティも公開します。これにより、単一のプロセスフラグだけに頼るのではなく、実行チェーン全体が対話型であるかどうかを判断することが可能になります。

コンテナ内での対話型実行の一般的な例としては、 bashまたはshシェルの起動、 curl 、 kubectl 、またはbusyboxなどの対話型ユーティリティの実行、または侵害された Pod 内でのオペレーター主導の偵察などが挙げられます。これらの操作はデバッグ時には正当な場合もあるが、定常状態の運用ワークロードでは一般的ではない。

コンテナイメージ、名前空間、および権限コンテキストと組み合わせると、対話型実行は強力な異常信号となる。これにより、検出ロジックは、想定される自動化されたコンテナの動作と、手動による介入や攻撃者による探索により近い活動を区別できるようになります。

ファイルイベント

Defend for Containersのファイルイベントは、コンテナ内部のファイルシステムアクティビティをキャプチャし、さまざまな操作に対して発行されます。従来のファイル整合性監視とは異なり、これらのイベントは実行時を認識し、コンテナワークロードの範囲に限定されるため、ファイル変更がどのように、そしてなぜ発生するのかについてのコンテキストを提供します。

Defend for Containersは、書き込み意図を伴うファイルのオープン、コンテンツの変更、ファイルの作成、名前の変更、アクセス許可の変更、削除などのファイルアクティビティを検出できます。Defend for Containersは、書き込み指向の操作に重点を置くことで、受動的なファイルアクセスではなく、システム状態を変更する動作を重視します。

これにより、検出エンジニアは、変更の結果だけでなく、実行時のファイル使用パターンについても推論できるようになります。

ファイルベースの検出システムを構築する際には、いくつかのフィールドが特に重要になります。file.pathとfile.nameフィールドは影響を受けるファイルとその場所を識別し、 file.extensionバイナリ、スクリプト、および設定ファイルを区別するのに役立ちます。event.actionフィールドとevent.typeフィールドは、発生した操作と、それがイベントライフサイクルでどのように解釈されるべきかを記述します。

これらのフィールドを組み合わせることで、Defend for Containersは、バイナリの書き込みや機密ディレクトリ内のパーミッションの変更など、疑わしい変更パターンと、無害なファイルアクセスを区別することができます。

まとめる

他のデータソースと同様に、Defend for Containersのテレメトリは、プロセス、ファイル、コンテナ、オーケストレーションの各ドメインにわたるフィールドをどのように組み合わせるかを理解することで、真に価値のあるものとなります。Defend for Containersは、静的な指標に頼るのではなく、ランタイム動作、特権コンテキスト、ワークロードIDに基づいた検出エンジニアリングを可能にします。

まとめ

Elastic Stack 9.3.0 におけるコンテナの DefendLinuxの検出エンジニアリングの中核コンポーネントとして、コンテナランタイム検出が含まれています。明確なスコープ、ポリシー主導型の構成モデル、そしてコンテナ化されたワークロード向けに特別に設計されたランタイムテレメトリを特長としています。

この記事では、Defend for Containersのデプロイ方法、ポリシーモデルの構造、ランタイムイベントの生成方法、コンテナとオーケストレーションのコンテキストによるイベントの付加方法について解説しました。我々は、プロセスおよびファイルイベントの構造、機能メタデータ、対話型実行シグナル、およびワークロードを考慮した方法で検出結果を表現できるコンテナ固有のフィールドについて調査した。

重要なポイントは、効果的なコンテナ検出には、実行時動作をコンテキストの中で推論する必要があるということです。つまり、プロセス、ファイル変更、権限、ワークロードの識別情報を総合的に評価しなければなりません。Defend for Containersは、それを可能にするために必要なテレメトリ情報を提供します。

次の記事では、この基礎知識を基に、現実的なコンテナ攻撃シナリオを詳しく解説し、Defend for Containersのテレメトリが実際にどのように侵害の各段階を明らかにするのかを実証します。

Linuxおよびクラウド検出エンジニアリング - Defend for Containers (D4C) 入門