ランタイムセキュリティとFalcoを使い始める

本文の内容は、2021年11月15日にVíctor Jiménez Cerradaが投稿したブログ(https://sysdig.com/blog/intro-runtime-security-falco/）を元に日本語に翻訳・再構成した内容となっております。

クラウドネイティブなワークロードにランタイムセキュリティを実装する際の課題を克服するために、Falcoをどのように使い始めるかをご紹介します。

Two hands assembling the Falco logo
コンテナやクラウドを導入している方は、デプロイの自動化やスケーラビリティの向上などのメリットを享受していることでしょう。しかし、セキュリティに関しては、これは新しいルールを持つ全く新しい世界であり、従来のセキュリティツールでは追いつくことができないと感じているかもしれません。新しいパラダイムであるクラウドネイティブ環境には、新しいクラウドネイティブツールが必要です。

ではランタイムセキュリティに焦点を当てていきましょう。

コンテナは軽量で、同じホストマシン上で何百、何千ものコンテナを実行するのが一般的です。また、コンテナはブラックボックスであり、従来のホストベースのツールでは見えないことが多々あります。

最初の苦労は、このような事に悩みます。”コンテナ内でランタイム中に何が起こっているのか、どうやって知ることができるのか？” 結局のところ、見えないものをどうやって守るのか？

また、不審な動きを検知した場合、疑問に思うことがあります。「どうやって適切な状況を把握して対応すればいいのか？」例えば、そのアクティビティはどのコンテナで行われたのか？どのようなワークロードに関連しているのか？そして、そのイベントに対応する適切なチームは誰なのか？

Falcoのようなクラウドネイティブツールは、個々のコンテナが行っていることをすべて見ることができ、”おーい、ちょっと、ちょっと、このredisコンテナはネットワークの外に接続を繋いじゃダメなんじゃない？”とか、”なぜこのApacheサーバーでファイルが変更されたの？”といった疑わしい動作に簡単にフラグを立てることができます。

ここでは、ランタイムセキュリティについて簡単に紹介し、Falcoがどのように魔法をかけているか、Falcoを使い始めるのがいかに簡単かを明らかにします。

ランタイムセキュリティとは？

脆弱性が本番環境に到達しないようにブロックすることは、非常に心強いことだと思います。このような脆弱性の予防的発見は、通常、イメージスキャンツールで実現されます。

スキャンの結果がきれいであれば、安全だと思うかもしれません。結局のところ、”脆弱性のあるアプリケーションをデプロイしていないのに、どうやって攻撃されるのか？”ということになります。

しかし、すべての脆弱性が知られているわけではありません。アプリケーションが本番稼動した後に脆弱性が公開された場合、あなたはまだ知らないうちにリスクにさらされているかもしれません。さらに、すべての脆弱性をすぐに修正できるとは限らないので、それまでの間、既知の脆弱性を持つシステムを注意深く監視する必要があるかもしれません。ランタイムには様々なことが起こり得ます。

コンテナのランタイムセキュリティに焦点を当てると、いくつかのセキュリティ上の脅威は、その性質上、ランタイム中にのみ発生します。これには以下が含まれます。

ゼロデイ脆弱性：ソフトウェア開発者がこれまで知らなかった問題
特権の昇格の試み
不安定な動作やリソースの漏洩を引き起こすバグ

ランタイムセキュリティは、コンテナセキュリティの中でも最も複雑な側面の1つです。これは、使用するコンテナアプリケーションスタックの種類によって異なる、複数の動作が関係しているためです。しかし、ほとんどの場合、ランタイムセキュリティは、以下のものを保護することに基づいています。

コンテナランタイム：これは、コンテナを実際に実行するサーバー上のプロセスです。ランタイムソフトウェアが最新の状態であり、既知のセキュリティ脆弱性に対してパッチが適用されていることを確認する必要があります。
- コンテナランタイムの有名な例としては、containerd、CRI-O、Dockerなどがあります。
オーケストレーター：コンテナオーケストレータは、コンテナのデプロイと管理を行います。ほとんどのオーケストレータは、コンテナの権限を制限し、セキュリティリスクを最小限に抑えるためのさまざまなツールを提供していますが、オーケストレータレベルでのセキュリティ問題の検出に役立つサードパーティの監視・分析ツールも使用する必要があります。
- コンテナオーケストレーターという意味では、Kubernetesが最も代表的です。
ノード： ノードとは、コンテナをホストするサーバーのことです。ノードレベルでの侵害により、攻撃者が環境全体に影響を与えないようにするためには、ホストOS、ユーザーアカウント、ネットワーク構成、その他のリソースを保護する必要があります。
クラウド環境：コンテナをクラウドプラットフォームにでデプロイすることができます。例えば、AWS Fargateです。これらのプラットフォームでは、システムコールをエクスポートできるptraceのようなメカニズムが提供され始めており、セキュリティインシデントを回避するために、ツールを使ってコンテナ内で起こっていることを監視することができます。

これらすべてを保護するために、最も人気のあるOSSでクラウドおよびコンテナセキュリティに関するツールはFalcoです。Falcoは、クラウドネイティブにおけるランタイムセキュリティプロジェクトであり、デファクトのKubernetes脅威検出エンジンです。 Falcoは、インキュベーションレベルのプロジェクトとしてCNCFに参画した最初のランタイムセキュリティプロジェクトです。 Sysdigは2016年にFalcoを作成しました。これは、予期しないアプリケーションのビヘイビアを検出し、ランタイムにおいて脅威を警告するように設計されています。

Falcoの仕組みは？

Falcoは、カーネルのシステムコールを分析することで、コンテナ、ホスト、クラスターのアクティビティを深く可視化します。また、Kubernetes APIの監査イベントなど、他のデータソースも活用します。同様に重要なのは、FalcoがKubernetesアプリケーションのコンテキストを調査結果に加えることで、DevOps、セキュリティ、クラウドの各チームが、誰がどこで何をしたのかを正確に理解できるようにすることです。

Falcoのアーキテクチャ：複数のイベントソースがあり、イベントはポリシー評価者を通過し、アラートが生成され、通知チャネルを介して送信される

Falcoの仕組みを理解するには、まず3つの主要なコンポーネントを見てみる必要があります。

ユーザースペースプログラム：シグナルを処理し、Falcoドライバーからの情報を解析し、アラートを送信します。CLIツールを使用してFalcoと対話することができます。
設定：Falcoの実行方法、どのようなルールを行使するか、いつ警告を発するかなどを定義します。
ドライバー：Falcoを実行するには、ドライバーをインストールする必要があります。ドライバーは、Falcoのドライバー仕様に準拠し、システムコール情報のストリームを送信するソフトウェアです。現在、Falcoは以下のドライバーをサポートしています。
- (デフォルト) C++ライブラリのlibscapおよびlibsinspで構築されたカーネルモジュール
- 同じモジュールから構築されたeBPFプローブ
- ユーザースペースインストルメンテーション

Falcoのアーキテクチャーでは、システム情報を収集するカーネルモジュールとeBPFプローブがあります。そして、いくつかのライブラリが、Falcoに到達するまで、それらのイベントを処理します。

Falcoの特徴のひとつは、監視専用のツールであることです。1つまたは複数のチャンネルにアラートを送ることができますが、それだけでは何のアクションも起こせません。アラートチャンネルの例は以下の通りです。

標準出力
ファイル
Syslog
起動されたプログラム
HTTP[s]エンドポイント
gRPC API を介したクライアント

可能なFalco出力のリストは、別のオープンソースツールであるFalcosidekickによって拡張されます。詳しくは、Extend Falco outputs with Falcosidekickをご覧ください。

Falcoはルールを使って、与えられた条件のもとで疑わしい動作を検出します。たとえば、コンテナ内のbashは異常なことかもしれませんが、アラートをトリガーする条件（この場合はproc.nameがbashであること）にのみ注目する必要があります：

- rule: Detect bash in a container
  desc: You shouldn't have a shell run in a container
  condition: container.id != host and proc.name = bash
  output: Bash ran inside a container (user=%user.name command=%proc.cmdline %container.info)
  priority: INFO

このように、ルールに簡単な言葉を使うだけで、このような動作を簡単に検出できることがわかります。Falcoのルールについてもっと知りたい方は、ドキュメントのルールを見てみてください。

このルールがイベントを検出すると、出力オプションを設定している場合は、次のようなメッセージが表示されます。

20:07:06.837415779: Notice A shell was spawned in a container with an attached terminal (user=root container=1dab04047700 shell=bash parent=runc cmdline=bash terminal=34816 container_id=1dab04047700 image=docker.io/falcosecurity/falco) container=1dab04047700

これで完了です。ランタイムコンテナのアクティビティを確認し、潜在的なセキュリティイベントを検出することができました。

Falcoプロジェクトはどのくらいしっかりしているのでしょうか？

“わかった、わかった、Falcoは素晴らしい” – あなたの声を聞きます – “でも、このプロジェクトはどれくらいしっかりしているの？”

これは妥当な質問です。結局のところ、あるソリューションにコミットして、しばらくしてから別のものに移行したいと思う人はいないでしょう。ここでは、いくつかの興味深い事実を紹介します。

Falcoは、Linux Foundationの一部であるCNCF傘下のオープンソースプロジェクトです。

Falcoは広く採用されており、CNCFに参加して以来、プロジェクトの人気は4倍になっています。Falcoのイメージは3000万回以上ダウンロードされています。

さらに、Falco の github レポをフォローしているユーザーの数は、インキュベーション時の 2 倍になっています。

Falcoのエコシステム内の他のプロジェクトも繁栄しています。例えば、コミュニティによって開始されたFalcosidekickは、300万ダウンロードを達成したばかりです。

採用は至る所で行われており、Falcoは公式のCKS試験のカリキュラムの一部になっています。

Falcoの技術的なアーキテクチャは、最新の環境のニーズを満たすように慎重に設計されています。基盤となるeBPF技術により、Falcoはパフォーマンスにほとんど影響を与えず、極端なストレステストでもCPU使用率は他の製品の半分程度です。

Falcoは、ハイパフォーマンスな環境にも導入されています。ユーザーであるskyscannerは、「K8sクラスターにデーモンセットとしてFalcoを導入しても、サービスのパフォーマンスには何の悪影響も出ていない（信じてほしい、本当に壊そうとしたんだ）」と報告しています。

Falcoのウェブサイトを見れば、エンドユーザーのリストにビッグネームが並んでいることがわかります。

Falcoのユーザーには、shopify、skyscanner、Frame.io、GitLabなどが名を連ねています。

そして、私たちにとってさらに嬉しいことは、Gartnerに認められたことです。ガートナーのアナリストは、Falcoを使用する理由の中で、”Falcoは、Kubernetesのコンテキストアウェアネスにより、アプリケーションのデプロイメントにおける異常な振る舞いの検出を可能にする “と指摘しています。”[1]

Falcoは、活発なコミュニティを持つ強力なプロジェクトであり、ランタイムコンテナのセキュリティニーズを満たすための重要な候補であると考えるべきでしょう。

Falcoの最初のステップ

LinuxマシンにFalcoをインストールするには、カーネルモジュールをインストールして、次のように実行するだけで簡単です：

apt-get install -y falco

これだけです。

しかし、クラウドネイティブな世界では、ホストに直接アクセスできない場合や、他のアプリケーションと同じようにFalcoを導入したい場合があります。

ここでは、KubernetesのパッケージマネージャーであるHelmを使って、KubernetesクラスターにFalcoをインストールする方法と、利用可能なルールをカスタマイズする方法について説明します。

待って、これをテストするKubernetesクラスターがありません!

心配しないでください。私たちがサポートします。

指示に従ってMinikubeをインストールすれば、あっという間にシングルノードのKubernetesクラスターができあがります。

Minikubeを起動するには、次のようにします：

$ minikube start

そして、起動していることを確認するために簡単なテストを行います：

$ minikube kubectl -- get nodes
NAME       STATUS   ROLES                  AGE     VERSION
minikube   Ready    control-plane,master   6m18s   v1.22.2

ここからは、 kubectl クライアントがローカルにインストールされていると仮定して、コマンドを kubectl get nodesとするだけです。これらのコマンドを簡略化するためのエイリアスの作成方法については、minikube kubectl documentationを参照してください。 kubectl クライアントがインストールされていなければ、ここにアクセスして kubectl をあなたのマシンにインストールしてください。

Helmを使ってFalcoをKubernetesにデプロイしよう

そのためには、Helmがインストールされていることを確認します。

ここでは、コミュニティでサポートされているチャートを使ってFalcoをインストールします。

まず、 falcosecurity のチャートのリポジトリを追加し、アップデートします：

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

さて、いよいよ helm install コマンドを使ってFalcoをインストールします：

helm install falco falcosecurity/falco

コンテナが起動するまで数秒待ち、Falcoポッドを特定し、コンテナのログを見てみましょう：

$ kubectl get pods
`NAME READY STATUS RESTARTS AGE
`falco-467d7 1/1 Running 0 4m13s
$ kubectl logs falco-467d7
…
Wed Nov 3 15:05:17 2021: Falco initialized with configuration file /etc/falco/falco.yaml
Wed Nov 3 15:05:17 2021: Loading rules from file /etc/falco/falco_rules.yaml:
Wed Nov 3 15:05:17 2021: Loading rules from file /etc/falco/falco_rules.local.yaml:
Wed Nov 3 15:05:17 2021: Starting internal webserver, listening on port 8765
…

無事にFalcoがデプロイされたようですね

実際にFalcoを使ってみましょう。

さて、Falcoがデプロイされて動作しているので、不審な活動を検出できるかどうか見てみましょう。

コンテナは対話的にアクセスされることを想定していないため、コンテナが危険にさらされていることを示す最大の赤信号の1つは、ターミナルシェルが起動したときです。これが起こる正当な理由はありますが、通常はトラブルシューティングの作業に限られます。

Falcoには、このようなシナリオを検出するためのルールがデフォルトで有効になっています。この場合、関連するルールは “Terminal shell in container” です。

先ほどデプロイしたのと同じ falco Podを使って、その中でいくつかのコマンドを実行してみましょう。

$ kubectl exec -it falco-4gsbr -- /bin/bash
root@falco-4gsbr:/#

対象はどのPodでもよいのですが、ここでは、クラスターに確実に存在することがわかっているfalco Podを使用しています😉。

falcoのログを確認すると、警告が表示されます：

$ kubectl logs falco-4gsbr
…
16:37:58.199209616: Notice A shell was spawned in a container with an attached terminal (user=root user_loginuid=-1 k8s.ns=default k8s.pod=falco-4gsbr container=b1cfe2fbfcdd shell=bash parent=runc cmdline=bash terminal=34816 container_id=b1cfe2fbfcdd image=falcosecurity/falco) k8s.ns=default k8s.pod=falco-4gsbr container=b1cfe2fbfcdd
…

イベントがトリガーされたポッドとネームスペースについて、Falcoがコンテキスト情報を提供していることに注目してください(k8s.ns=default k8s.pod=falco-4gsbr container=b1cfe2fbfcdd)。

次のステップは？

Falcoが動作するようになったことで、いろいろな楽しみ方ができるようになりました。

例えば、ログとは別のチャンネルでアラートを送ることができます。このような効果を得るためには、falcosidekickプロジェクトをチェックするとよいでしょう。

下記サイトで旅を続けましょう：

Getting started with container runtime security using Falco webinar.
Falcoのハンズオンラボです。
このFalcoワークショップ、そしてこれらも。

また、Falco プロジェクトに参加したい場合は、Falco.org にアクセスしてください：

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

Falcoをベースにした商用版の製品はどうですか？

オープンソースのソリューションは、お客様のチームによるDIYの努力を必要とします。ツールを完全にコントロールすることができますが、すべてのコンポーネントの設定、構成、保守にも責任があります。

迅速な導入、低い管理費、高いスケーラビリティ、カスタマーサポート、その他のプレミアム機能を必要とするチームは、商用版の製品を好むかもしれません。

商用版の製品は、ランタイムセキュリティだけに焦点を当てるのではなく、複数のセキュリティユースケースに同時に対応することで、付加価値を高めています。

例えば、商用版の製品は、クラウドの設定ミス、ランタイムセキュリティイベント、およびイメージスキャンの結果をチェックできる単一のガラス窓を提供することができます。これらの情報が同じ場所にあることで、異なるダッシュボード間を行き来する必要がなくなり、インシデント対応やフォレンジックをより効率的に行うことが可能になります。

商用版の製品は、インフラのセキュリティ確保を容易にするだけでなく、クラウドのセキュリティ態勢を長期的に把握することも目的としています。

多くのセキュリティ製品は、コンプライアンス要件をすぐに満たせるように作られています。アプリケーションライフサイクルのすべての側面を把握することで、市販のツールは、コンプライアンスから外れている場所を教えてくれると共に、改善策を提示してくれます。

Sysdig SecureがFalcoのセキュリティを拡張し、アプリケーションライフサイクル全体の包括的なセキュリティワークフローを提供する方法をご覧ください。

まとめ

Falcoは、コンテナやKubernetesにランタイムセキュリティを実装するための堅実なオープンソースソリューションです。

Falcoのクラウドネイティブな設計により、最新のアプリケーション環境で発生するセキュリティイベントを迅速かつ効果的に解決するために必要なコンテキストを提供することができます。

Falcoの詳細を知りたい方は。

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

Sysdig Secureでは、他のオープンソースプロジェクトとともに、アウトオブボックスのルールでFalcoを拡張し、Kubernetesのセキュリティへの取り組みと管理をさらに容易にしています。30日間の無料トライアルに登録して、ご自身の目で確かめてください。

Sysdig Secure DevOps Platformは、コンテナ、Kubernetes、クラウドサービスを自信を持って実行するためのセキュリティを提供します。Sysdigでは、ビルドパイプラインの保護、ランタイム脅威の検出と対応、コンプライアンスの継続的な検証、クラウドインフラストラクチャーとサービスの監視とトラブルシューティングを行うことができます。今すぐお試しください！

[1] Gartner, “Open-Source Options for Threat Detection and Incident Response”, Anna Belak and Eric Ahlm, 1 December 2020.