本文の内容は、2024年4月10日に JASON ANDRESS が投稿したブログ（https://sysdig.com/blog/honeypots-vcluster-and-falco-episode-ii)を元に日本語に翻訳・再構成した内容となっております。
これは、Falco、vcluster、その他のさまざまなオープンソース ツールを使用したハニーポットの構築に関するシリーズのパート 2 です。前回の記事については、「 vcluster と Falco を使用したハニーポットの構築: エピソード I 」を参照してください。
最後にヒーローたちと別れたとき
前回の記事では、高インタラクションのハニーポットについて議論し、vclusterを使用して、その独自のクラスター内に意図的に脆弱なSSHサーバーを構築しました。これにより、環境内の他のものに影響を与えることができなくなりました。次に、ホストにFalcoをインストールし、SSHサーバーを攻撃し、/etc/shadowを読み取るときに適切なルールがトリガーされるかどうかを確認するためにFalcoログを監視しました。
これはすべて素晴らしいことですが、これは単なる始まりにすぎません。今回は、ハニーポット内で何が起こっているかに反応できるように、ハニーポットに機能を追加します。これらの追加要素の一部は、将来さらに機能を追加するための基盤も構築します。
基本を超えていきましょう。ここからが楽しくなります。
私たちの欠点
前回の記事のセットアップには 2 つの大きな欠点がありました。他にもいくつかありますが、それらについては後ほど説明します。
まず、私たちのハニーポットの以前の反復では、実際のハードウェアの上に置かれたOS上で直接実行する必要がありました。これは、ハニーポットビットの最終的な拡散をサポートするためにハードウェアの軍隊をセットアップするのでない限り、うまくスケールしないため、有用性が限られます。当時、MinikubeとFalcoでこれを行うには、この方法しかありませんでした。幸いなことに、これはもはや当てはまりません。よりクラウドネイティブなアプローチで、AWSのEC2インスタンス上に構築することができるようになりました。クラウドへ行きましょう！
| 注: これから構築するハニーポットは、定義上、意図的に脆弱なシステムです。監視方法はまだあまり構築されていないため、インターネットに公開することはお勧めしません。 |
第２に、古いハニーポットは、ポッドの機密ファイルを調べたときに Falco ログに文句を言う以外、ほとんど何もしませんでした。これも修正できます。 Falcosidekick と Falco Talon を使用して、Falco ルールをトリップするときにハニーポットが実際に何かを実行できるようにします。
レスポンスエンジン
レスポンス エンジンは、EDR (エンドポイント検出および対応)、SIEM (セキュリティ情報およびイベント管理)、SOAR (セキュリティ オーケストレーション、自動化および対応)、および XDR (拡張検出および対応)のコンテキストでよく使用される用語です。詳細については、 「EDR vs. XDR vs. SIEM vs. MDR vs. SOAR」を参照してください。
これは、セキュリティの脅威に対する自動対応を実行するコンポーネントです。これはまさにこの場合に必要なツールです。
ハニーポットとの対話によって Falco ルールのいずれかに違反した場合、自動アクションを実行する必要があります。私たちの特別なケースでは、攻撃者が所有していたポッドをシャットダウンして、その場所にクリーンなポッドを再起動できるようにします。これには Falco Talon というツールを使用します。また、別のツールである Falcosidekick も含める予定です。これを使用すると、環境内で発生するイベントに応じて他のことを行うための柔軟性が将来的にはさらに高まります。
Falco Sidekick
Falcosidekick は、Falco を他の多くの興味深い部分と接続できるようにする優れたツールです。これを使用して、監視とアラートを実行したり、ログをさまざまなツールに送信したり、その他あらゆる種類のことを行うことができます。これは、イベントをFalco Talonに送信するために使用する接着剤の役割を果たす部分です。
Falco Talon
Falco Talon は、トリップした Falco ルールに対する実際の対応を実行するパーツです。Talonは、どのFalcoルールに対応し、それらがトリガーされたときに何をすべきかを定義する独自の内部ルールセットを持っています。
手を動かしましょう
早速始めて、いくつかのものを構築してみましょう。
今回は、AWS上のUbuntu Server 22.04 t3.xlarge EC2インスタンス上にハニーポットを構築します。もっと小さいインスタンスでもよいかもしれませんが、インスタンスに十分なリソースがないと、すべてがスピンアップできなくなる点があります。t2.microのような非常に小さなインスタンスは、ほぼ間違いなく、すべてが適切に機能するのに十分な馬力を持ちません。
理論的には、適切なアプリケーション ビットがすべて揃っていれば、これを同様のクラウド サービス上に構築して動作させることができるはずです。
前提条件として、次のツールを指定されたバージョン以降でインストールしておく必要があります。
残りの部分は、プロセスを進めながらインストールします。
Minikubeを起動する
1 – まず、Docker ドライバーを使用して minikube を起動します。動作を確認し、いくつかの依存関係をダウンロードします。
21 – 次に、minikube の Ingress アドオンを有効にします。これにより、間もなくインストールする SSH サーバーにアクセスできるようになります。
Falcoをインストールする
1 – 次に、Falco の Helm チャートにアクセスできるように、falcosecurity helm リポジトリを追加する必要があります。
4 – リポジトリを追加したら、更新して最新のチャートを取得します。
11 – kubectl を使用して、Falco が存在するネームスペースを作成します。これと同じネームスペースを、後で Sidekick と Talon にも使用します。
14 – では、Falcoのインストールを開始します。Falcoログのバッファリングを無効にしてイベントをより迅速に取得し、Falcoのインストール中にSidekickをインストールし、Web UIを有効にし、Sidekickの送信WebhookをTalonがリッスンするURLを指すように設定します。
💡注: Falco についてさらに詳しく知りたい場合は、Falco 101コースをご覧ください。
Falcoルールを更新
後ほど、SSHサーバーにアクセスできるようにポートフォワードを設定します。Falcoはこのことについて激しく反応し、”Redirect STDOUT/STDIN to Network Connection in Container “ルールを大量にトリガーされ、Falco ログで実際に関心のあるルールを確認したり、送信したりすることが困難になります。 Talon には追加イベントがたくさんあります。 そのルールを無効にしてみましょう。
私たちが無効にしているルールを確認したい場合は、ここのFalco ルール リポジトリで見つけることができます。
1 – ルールの変更を保持する一時ファイルを作成し、そこにcustomRulesセクションを挿入します。
2 – 次に、 override.yamlを追加します。
3 – 次に、Falco ルール ファイルの既存のルールをオーバーライドします。
4 – そして、Falcoにそれを無効にしたいことを伝えます。
6 – 次に、helm を使用して Falco をアップグレードし、作成したファイルをそれにフィードして、以前に持っていた残りの値を再利用するように指示します。
21 – 最後に、既存の Falco ポッドを削除して、ルールセットでルールが無効になった新しい Falco ポッドを取得します。
Falco Talonをインストールする
それではFalco Talonをインストールしましょう。
1 – 現在アルファ版であるため、Talon は標準の Helm リポジトリでは公開されていません。 GitHub から Talon リポジトリのクローンを作成して、helm チャートのコピーを取得します。
12 – Talon リポジトリをざっと見てみると、その Helm チャートと、その構成を保持するいくつかの yaml ファイルが確認できます。次の一連の手順でrules.yamlを変更します。
16 –さて、FalcoとSidekickと一緒にTalonをfalcoネームスペースに素早くhelmでインストールします。
Talon ルールと設定を更新する
先ほど説明したように、Talonのルールは別に設定する必要があります。今、 rules.yaml にあるものをちょっと覗いてみましょう
1 – ファイル内の各ルールは、”- name” で指定されており、いくつかの例があります。
21 – これは複製したい内容に沿ったルールですが、パラメーター セクションを削除することもできます。
これは、以前に Falco ルールを編集した方法と非常によく似た方法で機能します。
1 – 次に、 /tmp/falco-talon/deployment/helm/rules.yaml ファイルに一連の行をエコーします。Talonルールの名前を指定する必要があります（これは任意の名前です）、一致させたいFalcoルールを指定します（これはFalcoルールの特定の名前です）、そして一致した場合に取るアクションを指定します。この場合、ポッドを終了させます。
15 –Slackアラートを設定しないので、ここでTalonチャートディレクトリの values.yaml の出力の1つをコメントアウトする必要があります。もしこれをしなければ、何も害はありませんが、後でTalonのログにエラーが表示されるでしょう。
17 – もう一度、helmのアップグレードを行い、更新されたファイルを参照します。今回は-reuse-values引数を使ってhelmに既存の設定を残すように指示していないことに注意してください。これを行うと、 values.yaml への変更が含まれなくなります。
27 – 次に、既存のポッドを kill してリフレッシュする必要があります。
vcluster をインストールする
SSH サーバーを分離して実行できるように、vcluster をダウンロードしてセットアップします。
1 – ここでは、 GitHub リポジトリから最新の vcluster バージョンを取得するための環境変数を設定します。
3 – 次に、その環境変数を使ってダウンロードURLを作成します。
5 – curl を使用してファイルをダウンロードし、/usr/local/bin に移動します。
11 – 次に、vcluster のバージョンをチェックして、すべてが正しくインストールされていることを確認しましょう。
14 – 最後に、vclusterネームスペースを作成し、このネームスペースにすべてを置くようにします。
vcluster に SSH サーバーをインストールする
vcluster が動作するようになったので、ターゲットの SSH サーバーをインストールできます。
1 – まず、vcluster ネームスペースに SSH という名前の仮想クラスターを作成します。また、コンテキストを SSH クラスターに切り替えたことに注意しましょう。
14 – 次に、仮想クラスター内に SSH というネームスペースを作成します。
17 – SSH サーバーのチャートを取得できるように、securecodebox リポジトリを追加します。
20 – そして、簡単な更新を行って最新のチャートを取得します。
27 – ここでは、helm を使用して、意図的に脆弱な SSH サーバーをインストールします。
42 – 最後に、vcluster から切断します。これにより、コンテキストが minikube に戻ります。
すべてをテストしてみる
これですべてが構築されました。早速テストしてみましょう。
前回の記事の vcluster 参照図を思い出してください。
これは、私たちがこの作業を通してアーキテクチャーを視覚化する際に覚えておくと役に立つでしょう。
1 – vclusterネームスペース内のポッドを見てみましょう。ここに my-dummy-ssh-7955bc99c8-mwqxg-x-ssh-x-ssh というSSHサーバーがあります。今後の参考のためにメモしておきます。
10 – ここでは、SSH サーバーを公開するためにポートフォワードを設定します。
18 – 次に、sshpass を使用してサーバーに SSH 接続し、 /etc/shadow ファイルを読み取ることで、残りのイベントを開始します。現時点ではこれを手動で行っているため、厳密には sshpass は必要ありませんが、後でこれを自動化する予定なので、そのときに必要になります。
22 – ここで、ファイルの内容を確認できます。
ログを確認する
SSH サーバーに対する攻撃の結果、何が起こったのかを見てみましょう。
1 – Falco ポッドを見つけてその場所を保持するために環境変数を設定します。
3 – では、そのログを見てみましょう。冒頭のビットはFalcoが起動しているところです。ちなみに、先ほど作成したオーバーライドファイルがここに読み込まれているのがわかります。
18 – これが重要なところです。出力には “Warning Sensitive file opened for reading by non-trusted program (file=/etc/shadow) “とあります。
22 – それでは、Talon ログを見てみましょう。ここでは、Talon ポッドを見つけてログを取得するワンライナーをまとめます。 Talon ポッドが 2 つあり、必要なものはどちらにもある可能性があるため、両方からログを取得します。出力が両方からインターリーブされていることがわかります。
30 – ここでは、FalcoのイベントがTalonに伝わっているのがわかります。
32 – ここで、以前に作成した Talon ルールと一致しました。
33 – これは、実行されている Talon ルールのアクションです。
さて、クラスタを覗いて、私たちの努力の結果何が起こったか見てみましょう。先ほど述べたように、SSHサーバーポッドの名前は my-dummy-ssh-7955bc99c8-mwqxg-x-ssh-x-sshでした。
1 – vclusterネームスペースからポッドを再度取得してみましょう。SSHサーバーのポッド名は my-dummy-ssh-7955bc99c8-k8jgl-x-ssh-x-sshです。成功です！
8 – vclusterネームスペースのイベントを見て、my-dummy-sshをgrepして、気になる部分を探します。
14 – ここで、新しい SSH サーバーポッド my-dummy-ssh-7955bc99c8-k8jgl-x-ssh-x-ssh が起動しているのがわかります。
20 – 所有しているポッド my-dummy-ssh-7955bc99c8-mwqxg-x-ssh-x-ssh が強制終了されたことがわかります。。
これで終わりです。以下が私たちがやったことです：
- SSHサーバーポッドを攻撃しました
- Falco の ‘Sensitive file opened for reading by non-trusted program ’ルールが適用される
- Falcosidekick から Falco Talon への Webhook を使用してイベントを送信しました
- Falco Talon の ‘Sensitive file opened’ ルールをトリップしました
- 問題のあるポッドを終了しました
そして今、少しだけ自動化が進んでいます
上記のすべては、かなり多くの要素がありました。 これらすべてをスクリプトを実行するだけで実行できたら便利だと思いませんか？ はい、その通りです。 幸いなことに、私たちはまさにそれを行うことができます。
Sysdig TRTのGitHubレポで、 minhoney.sh ファイルをpull downしてください。これを実行可能ファイルに設定します。ハニーポットを起動するには、スクリプトを --buildit 引数で実行するだけです：
$ ./minhoney.sh --builditすべてを元に戻すには、 --burnit引数を指定してスクリプトを再度実行します。
$ ./minhoney.sh --burnit| 注: –burnit を指定して実行すると、スクリプトは今後の実行で問題を引き起こす可能性のあるもののクリーンアップを試みます。 Helm 内のすべてをアンインストールし、minikube 内のすべてを強制終了し、現在のユーザーが削除権限を持つ /tmp からすべてを削除します。この特定の目的のために構築されたシステムまたはインスタンス以外でこれを実行することはお勧めできません。私たちがあなたに警告しなかったとは言わないでくださいね、私たちはあなたに完全に警告しましたよ。 |
(今のところは) 以上です
一歩下がって、これまで説明してきたことをすべて確認してみましょう。
- SSHサーバーポッドを攻撃する
- Falco で ‘Sensitive file open for reading by untrusted program’ ルールを有効にする
- Falcosidekick から Falco Talon への Webhook を使用してイベントを送信しました
- Falco Talonで ‘Sensitive file open’ ルールを有効にしました
- 問題のあるポッドを終了しました
このシリーズの次のパートでは、これにさらにいくつかの部分を追加します。ログとアラート、さらにすべてを設定するための追加の自動化があれば便利です。また、攻撃対象をいくつか追加してこれをスケールアップします。
基本に関する前回のエピソードについては、「 vcluster と Falco を使用したハニーポットの構築: エピソード I 」を参照してください。