Falcoによるコンテナドリフト検出

By 清水 孝郎 - FEBRUARY 27, 2024

SHARE:

本文の内容は、2024年2月27日にNIGEL DOUGLASが投稿したブログ(https://sysdig.com/blog/container-drift-detection-with-falco/)を元に日本語に翻訳・再構成した内容となっております。

DIE は、不変のワークロードが実行時に変更されるべきではないという概念です。したがって、観察された変化はすべて、一般にドリフトとも呼ばれる悪意のあるアクティビティである可能性があります。コンテナドリフト検出は、不変性に関するセキュリティのベストプラクティスに従い、運用環境へのデプロイ後にコンテナが変更されないようにするだけで、実行時の攻撃を防ぐ簡単な方法を提供します。

コンテナセキュリティにおけるドリフトの先を見据える

Sysdig 2024クラウドネイティブセキュリティおよび使用状況レポートによると、Kubernetes ユーザーの約 25% がドリフトの振る舞いに関するアラートを受信して​​います。一方で、約4% のチームは、予期しない実行を自動的にブロックすることでドリフトコントロール ポリシーを最大限に活用しています。ドリフトを防ぐには、ドリフトをリアルタイムで検出できる必要があります。そこで必要となるのが、Falco の豊富なシステムコールの収集と分析です。Falco ルールがどのようにリアルタイムでドリフトを検出できるかを説明し、実際におけるドリフトコントロールのアドバイスをいくつか提供します。

コンテナ漂流検知

ファイルを開いたり書き込んだりする際のコンテナドリフト検出

このFalco ルールはかなり初歩的ですが、それでも意図された目的は達成されています。リストされているイベントタイプ、open、openat、openat2、creat を検索します。これは機能しますが、かなりあいまいなカーネルシグナルに依存しているため、Falco Engine バージョン 6 以降でのみ機能します。このルールは、 Falco Rules Maturity Frameworkのステーブルルールフィードにおいてデフォルトで有効になっています。

- rule: Container Drift Detected (open+create)
  desc: Detects new executables created within a container as a result of open+create.
  condition: >
    evt.type in (open,openat,openat2,creat) 
    and evt.rawres>=0
    and evt.is_open_exec=true 
    and container 
    and not runc_writing_exec_fifo 
    and not runc_writing_var_lib_docker 
    and not user_known_container_drift_activities 
  enabled: false
  output: Drift detected (open+create), new executable created in a container (filename=%evt.arg.filename name=%evt.arg.name mode=%evt.arg.mode evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info)
  priority: ERROR
  tags: [maturity_sandbox, container, process, filesystem, mitre_execution, T1059]Code language: PHP (php)

どの Falco ルールが Falco Maturity Framework のどのステータスにあるかを確認するには、このリンクを確認してください
maturity_stable は、ルールが実際の制作経験を持つ専門家による徹底的な評価を受けていることを示します。これらの実践者は、ルールがベストプラクティスを具体化し、最適な堅牢性を示し、攻撃者が Falco による検出をバイパスすることをより困難にしていると判断しました。

chmod によるコンテナドリフト検出

Unix および類似のオペレーティング システムでは、chmodコマンドとシステム コールを利用して、ファイルとディレクトリの両方を含むファイルシステム エンティティのアクセス権と特定のモード フラグ (setuid、setgid、スティッキー フラグなど) を変更します。

- rule: Container Drift Detected (chmod)
  desc: Detects when new executables are created in a container as a result of chmod.
  condition: >
    chmod 
    and container 
    and evt.rawres>=0 
    and ((evt.arg.mode contains "S_IXUSR") or
         (evt.arg.mode contains "S_IXGRP") or
         (evt.arg.mode contains "S_IXOTH"))
    and not runc_writing_exec_fifo 
    and not runc_writing_var_lib_docker 
    and not user_known_container_drift_activities 
  enabled: false
  output: Drift detected (chmod), new executable created in a container (filename=%evt.arg.filename name=%evt.arg.name mode=%evt.arg.mode evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info)
  priority: ERROR
  tags: [maturity_sandbox, container, process, filesystem, mitre_execution, T1059]Code language: PHP (php)

このFalco ルールは重大なノイズを生成する可能性がありますが、chmod の使用は悪意のあるインプラントのドロップと実行に頻繁に関連しています。したがって、このルールはデフォルトで無効になっており、成熟度マトリクスの“Sandbox” ルールフィード内に配置されますが、環境に合わせてより適切に機能するように微調整することができます。

新しいルール “Drop and execute new binary in container”  では、明確なカーネルシグナルを使用して、この TTP をより正確に検出できます。新しいルールを使用することをお勧めします。ただし、/tmp フォルダー内のファイルに対して chmod が使用されている場合など、環境に該当する場合は、このルールの方が監査に適している可能性があります。

新しいバイナリが落とされて実行された時にドリフトを検出する

コンテナの基本イメージに属さない実行可能ファイルが実行されているかどうかを検出するのが理想的です。ドロップと実行のパターンは、攻撃者が最初の足がかりを獲得した後に非常に頻繁に観察されます。プロセス is_exe_upper_layer フィルターフィールドは、overlayFS をユニオンマウントファイルシステムとして使用するコンテナランタイムにのみ適用されます。

- rule: Drop and execute new binary in container
  desc: Detects if an executable not belonging to a container base image is executed.
  condition: >
    spawned_process
    and container
    and proc.is_exe_upper_layer=true 
    and not container.image.repository in (known_drop_and_execute_containers)
  output: Executing binary not part of base image (proc_exe=%proc.exe proc_sname=%proc.sname gparent=%proc.aname[2] proc_exe_ino_ctime=%proc.exe_ino.ctime proc_exe_ino_mtime=%proc.exe_ino.mtime proc_exe_ino_ctime_duration_proc_start=%proc.exe_ino.ctime_duration_proc_start proc_cwd=%proc.cwd container_start_ts=%container.start_ts evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
  priority: CRITICAL
  tags: [maturity_stable, container, process, mitre_persistence, TA0003, PCI_DSS_11.5.1]Code language: PHP (php)

利用者は、提供されたテンプレートリスト known_drop_and_execute_containers を活用することができます。これには、基本イメージに含まれていないバイナリを実行する既知の許可されたコンテナイメージが含まれています。または、Kubernetesの設定で非本番のネームスペースを除外することによって、ルールをさらに調整することもできます。これにより、このルールにアプリケーションおよび環境固有の知識を適用することで、ノイズを削減できます。一般的なアンチパターンには、管理者やSREがアドホックなデバッグを行うことが含まれます。

Falco によるコンテナ漂流検出

ランタイムにおけるコンテナドリフト防止の強制

コンテナのドリフトをリアルタイムで検出することは、実行中のワークロードにおけるデータ盗難や資格情報へのアクセスのリスクを軽減するために重要です。Sysdig のレポートによると、本番環境で予防的なドリフトコントロール措置を有効にすると、インシデント対応の介入が必要な潜在的に悪意のあるイベントの量が約 9% 削減されるはずです。そこでFalco Talonが助けになります。

コンテナ漂流検知

Falco Talon は、Kubernetes 環境内の脅威を管理するための対応エンジンです。これは、Falco コミュニティによって提案されたソリューションを、コード不要の Falco ルール向けにカスタマイズされたソリューションで強化します。対応アクションを簡単に設定できるため、ミリ秒単位で侵害の兆候を防ぐことができます。

- action: Terminate Pod
  actionner: kubernetes:terminate
  parameters:
    ignoreDaemonsets: false
    ignoreStatefulsets: true

- rule: Drift Prevention in a Kubernetes Pod
  match:
    rules:
      - Drop and execute new binary in container
  actions:
    - action: Terminate Pod
      parameters:
        gracePeriods: 2Code language: JavaScript (javascript)

上記の「Falco rule Drop and execute new binary in container」のTalonルールドリフト防止では、Falcoルールに対する対応アクションを設定しています。したがって、ユーザーが実行中のコンテナを変更しようとすると、ポッドを即座に、かつ、グレースフリーに終了させることができ、クラウドネイティブの不変性の原則を維持します。ここでDIEコンセプトを覚えておくことが重要です。ランタイム中の定期的な変更がDIEと整合していない場合、ドリフト防止が有効になっていると、アラートの過剰負荷や頻繁なワークロードの中断による重大なシステムの混乱が発生する可能性があります。

Falco によるコンテナ漂流検出

コンテナのドリフト検出に応じてワークロードをシャットダウンするつもりがない場合は、コンテナ内でシェル スクリプトを実行して、最近ドロップされたバイナリを削除することもできます。または、Kubernetes ネットワークポリシーを適用して、疑わしい C2 サーバーからのネットワークリクエストを隔離することもできます。

まとめ

ランタイムにおけるコンテナでのドリフトコントロールはオプションの機能ではなく、ランタイムのセキュリティについて語る際にはむしろ必須の機能です。DIE の哲学を振り返ると、Kubernetes で不変のクラウドネイティブワークロードを保護するには、Falco に見られるようなリアルタイムアプローチが必要です。Falco ルールを活用して、ファイルの変更や予期しないバイナリの実行などの不正な変更を監視することで、組織は Falco Talon を通じて潜在的なセキュリティ侵害を検出し、自動的に軽減できます。不変性と継続的な監視を強調したコンテナセキュリティに対するこの積極的なアプローチは、悪意のあるアクティビティに対する防御を強化するだけでなく、最新のクラウドネイティブ アプリケーションの整合性とセキュリティを維持するためのベストプラクティスとも一致します。

さらに、コンテキスト認識フィルターのカスタマイズと適用を通じて、Falcoルールが特定の運用環境に適応できるため、誤検知を最小限に抑えながらルールの有効性を向上させることができます。このカスタマイズされたアプローチにより、セキュリティ対策を厳格、かつ、適切にする事で、セキュリティチーム間のアラート疲労につながる可能性のある不必要なアラートを回避できます。安全なコンテナ化環境への取り組みは進行中であり、警戒、コラボレーション、セキュリティにおけるベストプラクティスへの取り組みが求められます。