ブログ

AWS FargateをFalcoがサポート

AWS FargateをFalcoがサポート

本文の内容は、2020年4月8日にSysdigのLoris Degioanniが投稿したブログ(https://sysdig.com/blog/falco-support-on-aws-fargate/)を元に日本語に翻訳・再構成した内容となっております。

本日、Sysdigの製品ラインでFargateをサポートするためのAmazonとのパートナーシップを発表できることを非常に嬉しく思います。また、コンテナ用の世界で最も人気のあるランタイムセキュリティツールであるFalcoがまもなくFargateで動作するようになることも発表しました。これは重要なマイルストーンです。 初めて、Fargateユーザーはディープインストルメンテーションができる利点を享受します。これにより、ワークロードの安全性、信頼性、効率が向上します。

このブログ投稿では、この問題がなぜ重要であり、AmazonとSysdigがそれをどのように解決したかを説明します。また、Fargateで実行されているFalcoも垣間見ていきましょう。

まず、最初から始めましょう。

ディープインストルメンテーションとは何ですか? なぜそれが必要なのですか?

ディープインストルメンテーションは、実行中のプロセスを細かいレベルで監視する機能です。これにより、ファイルを開く、ディスクへのデータの読み取りまたは書き込み、ネットワーク接続の確立、ネットワークデータの送受信など、個々のアクションを確認できます。

アプリケーションの安全性と安定性を維持するために重要な多くの重要なクラスのツールには、ディープインストルメンテーションが必要です。ランタイムワークロードの保護、トラブルシューティング、EDR、根本原因の調査、依存関係のマッピング、ファイルの整合性の監視はすべて、ディープインストルメンテーションに依存しています。

Falco -クラウドネイティブランタイムセキュリティ

Falcoは、ディープインストルメンテーションを必要とするツールの非常に良い例です。 Falcoは、アプリケーションの異常なアクティビティを検出するように設計されたビヘイビアアクティビティモニターです。Falcoを使用すると、1組のルールを使用して、コンテナ、アプリケーション、ホスト、およびネットワークアクティビティをすべて1か所で継続的に監視および検出できます。FalcoはCNCFプロジェクトであり、Kubernetesのデファクトランタイムセキュリティツールです。 FalcoはSysdig Secureの中核にもなっています。

現在、FargateユーザーはFalcoを実行してワークロードを保護することはできません。これは、AWSチームがコンテナセキュリティ調査で指摘したギャップであり、AWS FargateでのFalcoサポートのさまざまなオプションについて話し合うために私たちと緊密に協力しました。

現在のディープインストルメンテーションアプローチ

ディープインストルメンテーションについて話す場合、考慮すべき2つの重要な要素があります。それは、精度とオーバーヘッドです。

この問題にはいくつかのアプローチがあります。 このブログ投稿では、Linuxとコンテナで群を抜いて最も人気のある3つについて説明します。

1. LD_PRELOAD

この手法は、環境変数LD_PRELOADを使用して、オペレーティングシステムにlibc動的ライブラリの異なるバージョンをロードするように指示することで構成されています。Libcは、open()やconnect()などのカーネル関数を呼び出すために、ほとんどのプログラムで使用されています。LD_PRELOADでロードされたバージョンには、これらの関数とそのパラメーターへのすべての呼び出しを記録するための追加のインスツルメンテーションが含まれる場合があります。

LD_PRELOADは非常に効率的ですが、正確ではありません。その理由は、静的にリンクされたCプログラムやgoで記述されたものなど、多くのプログラムはlibc動的ライブラリを使用せず、カーネルを直接呼び出しないためです。LD_PRELOADは、これらのタイプのプログラムを完全に認識しません。さらに、LD_PRELOADはユーザーレベルの手法であるため、たとえば、アセンブリコードで直接システムコールを呼び出すなど、意欲的な攻撃者に簡単に騙される可能性があります。

2. ptrace

ptraceは、Linuxカーネルによってエクスポートされる最も高度な(そして複雑な!)システムコールの1つです。これにより、適切な特権を持つプロセスが、別のプロセスを一時停止、イントロスペクト、変更、およびコントロールすることが可能になります。定期的に使用する多くのツールは、ptraceに基づいています。たとえば、GNUデバッガであるgdbがその1つです。

ptraceの優れた機能の1つはPTRACE_SYSCALLです。これにより、プロセスはシステムコールの実行時に別のプロセスを停止し、システムコールの引数を取得できます。ファイルI/Oやネットワークなど、OSによって公開されるサービスはシステムコールを介してアクセスされるため、これはディープインストルメンテーションの涅槃であり、straceなどのツールの実装に使用されます。

ptraceは非常に正確ですが、効率的ではありません。言語とスタックに依存しないため、正確です(システムコールはどの言語でも同じです)。また、情報はオペレーティングシステムカーネルによって生成されるため、カーネルがだまされることはありません(少なくとも簡単にはできません)。ただし、PTRACE_SYSCALLを使用することは、システムコールごとにデバッガブレークポイントを設定することと同じです。 とても正確ですが、速くはありません。

3. カーネルインストルメンテーション

この手法は、カーネルモジュールに基づいた従来の(そしてより侵襲的な)メソッド、またはカーネル内でコードを安全に実行できる仮想マシンに基づいたeBPFのようなより現代的で侵襲性の低い方法で、カーネルに至ることで構成されます。

カーネルインストルメンテーションは効率的で正確です。カーネルでアクションを収集することでオーバーヘッドを最小限に抑えることができるため、効率的です。私たちが知っているように、「カーネルは決して嘘をつかない」ので正確です。

このため、Falcoはこの手法に基づいています。 また、Sysdigの商用製品であるSysdig SecureSysdig Monitorもこの手法に基づいています。

Fargateでは何が問題になるのでしょうか?

Fargateは、AWSユーザーに大きな価値を提供します。仮想マシンを忘れて、コンテナをプロビジョニングするだけです。Amazonが基盤となるホストを処理するため、一連のLinuxインスタンスを維持およびアップグレードする代わりに、ソフトウェアの作成に集中できます。

しかし、Fargateのディープインストルメンテーションは困難でした:

  • Fargateは設計上、ホストへのアクセスを公開しないため、Fargateではカーネルインストルメンテーションはできません。
  • ptraceはFargateでは使用できません
  • これらの制限があるため、LD_PRELOADが唯一可能なアプローチであり、以前に説明した侵襲性と精度の欠如に基づいて理想的とは言えません。

しかし、状況は変わります!

ビッグニュース! Fargateがptraceをサポート

はい、あなたの読みは正しいです。Amazonは本日、ptraceのサポートを含むFargateプラットフォームの新しいバージョン(1.4)のリリースを発表しました

これはゲームチェンジャーです。これで、gdbのようなデバッガー(ついに!)とstraceのようなトラブルシューティングツールを使用できるようになるだけでなく、ついにディープインストルメンテーションのための強固なフレームワークが存在するようになるので、Fargateで利用できるツールが増えることを期待しています。

AmazonとSysdigの密接な関係のおかげで、この機能の仕様についてAWSチームと協力する機会があり、リリース前にテストすることができました。これにより、ptraceを使用してFargateを完全にサポートするようにFalcoを拡張する機会が得られました。

FargateにおけるFalcoサポートの紹介

Fargateで稼働しているFalcoのプレビューです。

私のタスクのJSON設定で、SYS_PTRACE機能を追加しています。これは、Dockerコンテナに対して従来から有効にできる標準のLinux機能の1つです。

20200409b-2.png

次に、タスク内でubuntuコンテナを実行します。このデモのために、手動でコンパイルしたバージョンのFalcoを実行します。カーネルモジュールを使用する代わりにptraceを使用してイベントを収集するように指示する-uコマンドラインフラグを使用してFalcoを実行します。

./falco -u -r ../../../rules/falco_rules.yaml

他のシェルでバイナリファイルを変更してみます。

touch /bin/cat

ほらほら、ファルコは疑わしい活動について知らせてくれます。

20200409b-3.gif

ちょっと待って。 あなたはptraceが遅いと言ったでしょう!

はい、ptraceは低速です。straceなどのツールを本番環境で使用すると、監視対象のアプリケーションにかなりのオーバーヘッドが発生するため、処理が困難になります。しかし、Sysdigではパフォーマンスを非常に重視しています(本番環境でワークロードを実行するとき、ユーザーにとってそれがどれほど重要であるかを理解しています)。したがって、実際のパフォーマンスに落ち着くとは期待していませんよね? :-)

Amazonが早期アクセスをさせてくれたのおかげで、一連の最適化に取り組む機会がありました。その結果、ptraceを使用するテクノロジーが実現しますが、実質的なオーバーヘッドを追加することなく、カーネルインスツルメンテーションのすべての機能を実現できます。これは近い将来にユーザー向けにリリースする予定ですので、ご期待ください。

最近の投稿

カテゴリー

アーカイブ

ご質問・お問い合わせはこちら

top