概要
Sysdigキャプチャーは、Sysdigの基本機能を拡張したもので、個々のシステムコールを読み取って情報を取得します。イベントが検出されると（コンテナのフェイル、HTTPエラーコード、メトリクスレベルの異常などのアプリケーションイベント、またはFalcoやSysdig Secureルールがトリガーされたなどのセキュリティイベント）、キャプチャーを取得するように設定することが可能です。Sysdig Monitorでは、メトリクスや イベントがバックエンドで分析され、キャプチャーを取得するための指示がエージェントによってピックアップされます。これは一般的に、実際のイベントトリガーとは非同期のキャプチャーになりますが、それでもアプリケーションのトラブルシューティングには非常に有効です。
Sysdig Secureでは、システムコールが入ってくると、エージェントがセキュリティルールを評価します。つまり、キャプチャーを行うかどうかの判断はほぼ即座に行われ、Sysdigエージェントのインメモリー・リング・バッファーを活用することができるのです。これは、セキュリティ・イベントの診断や、何が起こったかだけでなく、どのようにインシデントが起こったかを発見するのに非常に有効です。
Sysdig Monitor と Secure の両方において、あらゆるトラブルシューティングの目的でキャプチャーを手動で取得することも可能です。キャプチャーは常にホストベースで、カーネルレベルのシステムコール・アクティビティーをキャプチャーします。
このハンズオンラボは、Sysdig Monitor と Sysdig Secure の両方をベースにしています。各ラボにはヒントがありますが、キャプチャーを使用して調査することに自信がある場合は、ヒントを使用せずに答えや根本原因を発見してみてください。
このラボで使用するキャプチャーファイルを入手されたいお客様は、
sysdig.jpにてお問合せください。
https://sysdig.jp/company/contact-us/
Sysdig Inspectのインストール
さまざまなクラウドサービスには複雑さとランダム性があり、低レベルのシステムコールアクティビティを確実に生成できるように、このラボの目的のために、事前に作成したキャプチャーを用意しました。Sysdig Inspectのデスクトップ版でこれらを分析しますが、読み込み部分を除けば、ほぼ同じ操作感で分析できます。デスクトップアプリは、オフラインでキャプチャーを分析する場合や、S3やGlacierに長期保存する場合にも便利です。キャプチャーは、Sysdig Platformからダウンロードすることもできます。ドキュメントとダウンロードへのリンクはこちらです。https://github.com/draios/sysdig-inspect
参考までに、最新版のインストーラーを以下に載せておきます：
- MacOS installer: https://setns.run/install-inspect
- Windows installer: https://setns.run/install-inspect-windows
- Linux installer (RPM version): https://setns.run/install-inspect-rpm
- Linux installer (DEB version): https://setns.run/install-inspect-deb
一般的なヒント
該当するコンテナがわかっている場合は、コンテナセクションに移動して該当するコンテナをダブルクリックすることで、すぐにアクティビティをそのコンテナに絞り込むことができます。
検索対象を特定のコンテナに設定すると、左側のナビゲーションには、その単一のコンテナに関連する情報のみが表示されます。 ‘Sysdig Filter’ は、上部の ‘Overview’ を再度クリックするまで、検索を維持します。
また、何かをダブルクリックすることで、検索の上に検索を重ねることができ、探しているものを絞り込むことができます。
タイルをクリックしてアクティビティを重ね合わせ、下部のタイムナビゲータで特定の期間だけに絞り込むことができます。
特定のアクティビティタイルをクリックして開始すると、ナビゲーションや検索を開始しても、このタイルは下部に表示されたままになります。検索フィルターと連動して更新されるわけではありませんが、検索フィルターを構築する際に、時間軸を拡大して特定のアクティビティを見つけるのに役立つ方法です。
Readはオレンジ色、 writeは青色で表示されます。HTTPトラフィックの場合、読み込みとは、アプリケーション（Webサーバー）が外部から読み取ることで、例えば、リクエストが入ってくることを指します。書き込みは、アプリケーション（Webサーバー）が応答として書き戻すものです。そのため、書き込みにはレスポンスコードやレスポンスコンテンツ（Webサーバーの場合は一般にHTML、APIサーバーの場合はJSON/YAMLなど）が含まれます。
関連するI/Oストリームを持つアクティビティを探している、または見つけた場合、左側のI/Oストリーム、またはアクティビティの右側のI/Oストリームアイコンをクリックすると、そのアクティビティをさらに深く掘り下げることができます。ファイル・アクティビティの場合、I/Oストリーム・データの一部（全てではありませんが、デフォルトで4k程度）を再構築することができます。
ファイルI/Oストリームを読むことは、どのようなファイルが作成されているかを見るだけでなく、どのようなファイルにアクセスされているかを見るためにも有効です。これは、設定データやファイルを見るために使うことができる。’Printable ASCII’ に切り替えると、改行が正しく表示され、一般に読みやすくなることを確かめましょう。
I/Oストリームは、特定のI/Oストリームの左側にある情報を見ることで、どこから来たのかにリンクしています。これには、コンテナと特定のファイルの場所が含まれます。
圧縮されたアーカイブの一部として書き出された（または書き込まれた）ファイルを調べることができます。アーカイブをクリックするか、プロセススレッドを選択して’Files’をクリックしてください。
ミスをし、行き止まりになってしまう事もあるかと思います。上部の’Overview’をクリックし、下部の’Reset’をクリックすると元に戻ります。
Lab1: Monitor: HTTP 500
私たちはKubernetes上で動作するアプリケーションを監視しており、このアプリケーションはPrometheusメトリクスを通じて、そのアプリケーションの同時ユーザー数を公開しています。アプリケーションチームは、彼らがこれらのPrometheusメトリクスを公開していると約束してくれていますが、私たちはまだそれらを見ることができません。Sysdigを使用すると、HTTPエラーコードの数を確認し、それについて警告することができます。Prometheusエクスポーターを設定した後、多くのHTTP 500（内部サーバー）エラーメッセージを受信していることに気づいたので、そのようなイベントのキャプチャーを作成しました。
この問題を診断して、アプリケーションチームがPrometheus exporterを修正するために必要な情報を提供できますか。
ヒント：
これは HTTP エラーメッセージであるため、安全な場所から始めることができます。
これらのエラーメッセージの左側は、問題の特定のコンテナを見つけるのに役立つはずです。
完全なコンテナ名は必要ありません。以下のように、さまざまな検索演算子を使用して問題のコンテナを見つけることができます。
container.name contains “usercount”
ここから、このコンテナをさらに深く掘り下げ、 ‘I/O Streams’ ビューに切り替えて、このコンテナが行おうとしているファイルアクティビティを確認することができます。
サーバーがメトリクスを使用する場所にアクセスしようとしていますが、毎回 500 を返していることがわかります。おそらく ‘File Open Errors’ が、ファイル依存の問題を示すのに役立つと思います。
このキャプチャーは非常にシンプルですが、より負荷の高いシステムでは、ファイル・エラーをフィルターするために、「container.name contains “usercount”」フィルターを再度使用することができ、このタイルを最初にクリックしたときに表示されるフィルターの最後に ‘and’ を追加するだけです。
Lab2: Monitor: Pod CrashLoopBackoff
あなたの会社では、新しいWebアプリケーションを本番用Kubernetesクラスターにデプロイしています。このアプリケーションは、プロキシフロントエンドとしてNGINXコンテナを使用し、RESTバックエンドとして機能するFlaskコンテナへのユーザーリクエストを受信し中継しています。DevOpsチームはSysdig Monitorのアラートを受信し、環境内のPod crash/restart loopを通知されました。この状態（CrashLoopBackoffとして知られている）は、ほとんどのKubernetesユーザーにとってよく知られているエラーです。
これは、KubernetesのPodが短時間に連続してPodの再起動を経験していることを意味します。課題は何でしょうか？多くの異なる原因が考えられます。PodがCrashLoopBackoffの状態にある場合、アプリのパフォーマンスは著しく低下し、解決するまではサービス停止になる可能性もあります。ビジネスにとって良いことではありません。
アラートが発生すると、Sysdigは設定可能な数秒間のすべてのシステムコール情報を含むキャプチャーファイルを作成します。DevOpsチームはこのキャプチャーファイルを開き、Sysdig Inspectを使用して問題のトラブルシューティングを行います。
ヒント：
- プロセスやコンテナにフォーカスを当てたら、I/Oストリームをチェックして、そのプロセスが何をしようとしているのかを確認しましょう。
- クラッシュループの問題であることを考えると、常にdying/Killされる特定のコンテナはありますか？
- 私たちが発見したことから、プロセス別またはコンテナ別に表示をフィルタリングして、コンテナまたはプロセス表示のいずれかから試してみてください。
- container.name に “nginx” が含まれている
- proc.name = nginx
- プロセスやコンテナにフォーカスを当てたら、I/O ストリームをチェックアウトして、そのプロセスが何をしようとしているのかを見てみましょう。
Lab3: Secure: Terminal Shell in a Container
コンテナ内で Terminal shell が検出されたという Sysdig 通知を受け取り、問題のコンテナは ‘woocommerce’ と呼ばれています。Sysdig Secure イベントは、イベントの 10 秒前とイベントの 20 秒後にキャプチャーを作成するよう設定されています。
我々は、Shell 内で何が行われたかを正確に把握する必要があります。
ヒント：
- 疑わしい、または興味深い活動をタイムライン全体に重ね、最も相関性の高い領域にズームインします。
- シェルイベントをトリガーするために、いくつかのコマンドがユーザーによって実行されなければならないことをあなたはご存知でしょう。
- ‘README’ ファイルは簡単すぎます。簡単なオプションを使用せずに、何が行われているのかを理解するようにしてください。
Lab4: Secure: 機密情報の漏洩
このキャプチャーは、かなりノイズが多いので、もっと広範囲にフィルタリングを行う必要があります。エッジDLPシステムから、何らかのデータが抜き取られたと思われますが、何が、どのように抜き取られたのかが分からないため、どのように対応したらよいのか分かりません。あなたの仕事は、どのような（もしあれば）データが抜き取られたかを突き止めることです。
問題のアプリケーションは、信頼できる「ping」アプリケーションで、社内のチームが任意のホストにpingを打って、ローカルネットワークに問題があるかどうか、あるいはホストが停止しているかどうかを確認するために使用されています。
複数の疑わしい DLP アクティビティがトリガーされましたが、いくつわかりますか、またそれぞれの潜在的な影響は何でしょうか？
ヒント：
- pingアプリケーションを実行しているコンテナを探してみてください。
- データ漏洩の疑いがあることが分かっているので、ファイルの書き込みがないかどうか調べてください。
- 実行されたコマンドを調べ、不審な点がないか確認する。
- HTTPトラフィックは、何がアクセスされたかを示すのに役立つかもしれません。