最近はクラウド、特にマネージドサービスが増えてきて、 利用者が細かい内部動作まで気にしなくても活用できるようになっています。 ただ、その反面ブラックボックスが増えてきてしまい、 いざトラブルになったときに解析の手段が限られてしまっている側面もあります。
これまでの環境ではさまざまな解析のためのツールがありました。 例えばネットワーク解析ツールとしては、Wiresharkが有名です。 さまざまな場面で通信周りを疑う場合に、公私ともにお世話になったものです。
そんなWiresharkの技術を元に、クラウドセキュリティ・クラウドオブザーバビリティの分野に拡張したプロダクトに、sysdigがあります。 そして今度は、sysdigのWireshark版とも言うべき、Stratoshrakが登場しました。
https://sysdig.jp/blog/stratoshark-extending-wiresharks-legacy-into-the-cloud/
公式ブログでは、“Wiresharkのレガシーをクラウドへ拡張"と表現されています。
今回は、このStratosharkについてご紹介したいと思います。
Stratosharkのアーキテクチャとできること
StratosharkはWiresharkが元になっているだけあって、 GUIはWiresharkと同じインタフェースで情報を可視化することができます。
Wiresharkは通信パケットを可視化することができました。 一方、Stratosharkは以下の情報を執筆時点ではデフォルトで扱うことが可能です。
- AWSのCloudtrail
- Google CloudのCloud Audit Log
- Sysdigから取得したシステムコール情報
「デフォルトで」というのは、CloudtrailやCloud Audit Logの解析には、
falcodump
というものが使われており、これが他のeks audit logなどのプラグインもあるため、
カスタムビルドすれば対応させられると推察できるためです。
他のログへの対応は今後確認してみたいと思います。
そして、StratosharkはリモートでCloudTrailの証跡が保管されたS3バケットにアクセスしたり、 外部サーバで実行されているSysdigにSSH経由で接続し情報を取得したりすることができるので、 必ずしもクラウド上で実行する必要はなく、ローカルでも実行することができます。
また、リアルタイムの解析だけでなく、ダンプしたファイルなどをローカルに持ってきて解析することも可能です。

Stratosharkで解析する
まだ、Stratosharkには充実したドキュメントはありません。 ここからは私が試してみた内容を元に使いかたを紹介しようと思います。 今回は、ビルド済のWindows版v0.9.1を利用しました。
まず、Stratosharkを起動すると以下の画面が表示されます。

ここから解析したい内容を選ぶと初期設定画面が表示され、アクセス先など必要な設定をおこなった後に解析がスタートします。 2回目以降は、設定が保存されるので同様の設定で起動します。
設定を変更したいときには、各メニューの左側にある二重丸のようなアイコン(歯車?)をクリックします。 メニューバーにも設定変更の項目がなく、私はこの操作の発見にかなり苦戦しました。
CloudTrailの解析をおこなう
CloudTrailを解析したい場合は、CloudTrailの証跡が格納されたS3バケットを指定します。
いつもの、 s3:///
から始まる形式です。
S3バケットは、あまりに広めに指定してしまうとファイルのダウンロードが間に合わずタイムアウトエラーになってしまったので、 ある程度絞って実行するようにしましょう。 環境でのログ記録量にも依存するので目安は難しいですが、絞れるなら日単位、せいぜい月単位にしておいたほうが、 解析する上でも情報量が絞りこめてよいと思います。
実行時の権限ですが、クラウド上で実行している場合はアタッチしたインスタンスロールで実行されるので、 該当のS3バケットにアクセスできるように権限を付与しておきましょう。
外部から実行するときは、AWS CLIを実行する際にも参照される ~/.aws/
配下の config
や credentials
を読み込んで、
そのIAMユーザで実行することもできます。
実行することで、Wiresharkを利用したことがある人にはお馴染の以下のインタフェースでCloudTrailの各イベントを閲覧することができます。

画面上部のフィルタのダイアログがありますが、ここでイベントを絞りこむことができます。
CloudTrailのイベントはプリフィックスが ct
なので、例えば autoscaling.amazonaws.com
が実行したAPIだけに絞り込みたい場合には、
ct.user
が autoscaling.amazonaws.com
であるというフィルタを設定します。

構文やキーワードを覚える必要はありますが、実際には補完機能もついていますし、 イベントの詳細情報の各行を右クリックすると、その値を元にしたフィルタ作成支援の機能もついているので そこまで活用に苦労することはないと思います。
Sysdigを用いてインスタンスの解析をおこなう
次に、EC2インスタンスで実行されるシステムコール情報を取得します。
対象のOSはUbuntuを利用しています。
監視対象のセットアップ
監視対象の条件は2つあります。
- sysdigエージェント (OSS版で可) がインストールされていること
- SSH経由でStratosharkの実行環境からアクセスできること
Sysdigエージェントのインストール方法は公式のwikiがあるので、こちらを参照してください。
https://github.com/draios/sysdig/wiki/How-to-Install-Sysdig-for-Linux
Ubuntuの場合はサイトにも載っている以下のインストールコマンドで、簡単に導入することができました。
curl -s https://download.sysdig.com/stable/install-sysdig | sudo bash
なお、検証時点ではAmazon Linux 2023に対してインストールすることができませんでした。 また、AWS Marketplaceからコンテナイメージを入手することもできるのですが、そちらも起動時にエラーになってしまいました。 こちらは、今後に追加検証したいと思います。
キャプチャしたシステムコールの閲覧
さて、接続が成功すると以下のようにキャプチャしたシステムコールが流れてくるので、 たとえばファイルをオープンしたログなども得ることができます。

画面にはおさまってないですが、実行したコマンド、実行ユーザからプロセスツリーの情報なども得ることができ、 ほぼインスタンス上で発生した出来事がすべて網羅されて閲覧できると言ってよいでしょう。
もう、既に設定していますが、発生するシステムコールは非常に膨大です。 フィルタ無しで目的のログに辿りつくことは難しいでしょう。
Stratosharkを用いて解析をおこなう
さて、Stratosharkでシステムコールの情報を取ることができました。 これを使うとどのようなことがわかるのでしょうか?
システムコールの状況がわかれば、サーバの状況はすべてわかると言っても過言ではありません。 例えば、以下のような情報を取得することができます。
- 実行されたコマンド
- ファイルの入出力
- ネットワークのアウトバウンド/インバウンドの状況
これはコンテナであってもホストであっても変わりません。
以下の例では、コンテナが怪しい通信をしていると仮定して通信状況を調査している様子です。
connect
というイベントが外部接続を示すため、これを足掛かりにして、より詳細にどこに通信をしているのか、
他に怪しいことをしていないか、などを調査することができます。

他にも、例えば設定ファイルに記載されているはずの挙動と違っている、という場合に本当に該当のファイルを読みこんでいるのか、 などデバッグ用途にも活用することができるでしょう。
今回の検証時にはコンテナ名がうまく取得できずに空欄になってしまいましたが、 本来はコンテナ名で簡単にしぼりこむこともできるはずです。
注意点とまとめ
ここまで説明してきたStratosharkですが、注意点もいくつかあります。
- 監視用途や初めて発生した事象の調査では使いにくい
- アラートを出す仕組みがないことに加え、収集を実行しているタイミングのイベントしか取得することができません。
- イベントの収集時に事象を再現させる必要があります。syslogイベントをファイルにダンプしておいてあとから解析することはできます。
- もし、セキュリティイベントの監視をしたい場合には、商用製品のsysdig secureなどの利用を検討することになるでしょう。
- サーバ1台しか解析対象にできない
- 特定のサーバにアクセスするアーキテクチャであり、複数サーバのイベントを同時に解析することはできません。
- サーバ間の相互作用を調査したいケースもあると思うのですが、そのような解析はまだ難しそうです。
- イベント量がとにかく膨大である
- デフォルトではあらゆるシステムコールが収集されるので一気にイベントが流れていきます。 フィルタで絞り込んだり、最初から不要なイベントは収集しないようにしておく必要があります。
今回は、クラウドの詳細な解析に役立つStratosharkを紹介しました。 クラウドだけでなくsysdigエージェントが導入できる環境であれば、オンプレミスをはじめとする他の環境の解析にも役立つでしょう。
まだ出てきたばかりのOSSということで、正直荒削りのところもありますが、これから使い方含めこなれてくると考えられます。
今回の検証では触れなかったところを含め、引き続き私も見ていきたいと思います。
関連記事
- ついに来た ECSでタスクのリバランスを自動化
- 続・DistrolessコンテナでもEKSのデバッグを諦めない (EKS1.31対応版)
- DistrolessコンテナでもEKSでのデバッグを諦めない
- EKSのネットワーキングにディープダイブ
- EKSのVPC CNIでNetwork Policyを利用する
Share