本文の内容は、2021年9月1日にDaniella Pontesが投稿したブログ(https://sysdig.com/blog/indicators-compromise-kubernetes/）を元に日本語に翻訳・再構成した内容となっております。
このブログでは、Kubernetes環境の監視データを使って、Kubernetesにおけるセキュリティ侵害指標(IoC)を検出する方法を学びます。
Kubernetesのセキュリティ確保は困難です。設定の柔軟性、大規模なクラスター、エフェメラルコンテナ、増え続けるサービスエコシステムは、攻撃対象を広げてしまう複雑な環境を生み出します。複雑さはセキュリティの天敵であるため、敵対者は優位に立ちます。攻撃を容易にする設定ミスだけでなく、複雑さの裏に隠れている異常な活動にも注意しなければなりません。
組織は通常、Kubernetesのセキュリティと監視のために別々のツールを持っていますが、これらのツールは互いに連携していないことが多く、結果的にデータがサイロ化し、環境を無防備にしてしまいます。皮肉なことに、監視システムは様々なメトリクスやイベントを継続的に監視しているため、悪意のある攻撃の兆候を早期に検知することが多いのです。セキュリティ侵害の兆候を把握し、セキュリティ問題に迅速に対応するためには、セキュリティチームも監視データにアクセスできることが重要です。
ここでは、Kubernetes環境でIoC（Indicators of Compromise：セキュリティ侵害指標）として機能する、注意すべきさまざまな種類の監視アラートについて確認してみましょう。
Kubernetesにおけるセキュリティ侵害指標
Kubernetesにおけるセキュリティ侵害指標 トップ１０は、Sysdigのお客様がKubernetesのデプロイメントをどのように監視しているか、またセキュリティに影響を与える可能性のあるKubernetesのメトリクスをどのように監視しているかを分析してまとめたものです。また、SysdigをKubernetesのセキュリティツールとして使用し、ランタイムの脅威を検出したり、IoCである可能性のある異常なアクティビティを警告している様子も観察しました。１．コンテナのメモリ/CPUスパイク
コンテナのメモリやCPUのスパイクは、リソースハイジャックの初期症状としてよく知られています。リソースハイジャックとは、攻撃者がユーザーのコンピューティングリソースにアクセスし、リソースを大量に消費する悪意のある活動を行うことです。ビットコインやイーサリアムなどの暗号通貨は、ネットワーク上のトランザクションを検証するために、リソースを大量に消費する計算を行います。攻撃者にとって理想的な環境は、無防備なKubernetesクラスター内で、簡単に複数のコンテナを起動して作業を行うことができることです。次のPromQLクエリーは、各ワークロードのCPU使用率を提供します：
sum (rate (container_cpu_usage_seconds_total{container=~".+"}[1w]))
by (container) / ignoring (container) group_left
sum( machine_cpu_cores{}) * 100とはいえ、CPU/メモリのスパイクだけがクリプトマイニングの兆候ではありません。クリプトマイニングは、既存のプロセスがリソースを奪い合うようになった場合、そのプロセスをKillすることもあります。確信を持つためには、プロセスキルイベントの存在を確認することで、侵害が発生していることを知ることができます。
暗号通貨攻撃がどのように機能するか、またどのように検知するかについての例は、「クリプトマイナー攻撃 – WordPressのポッドを標的としたSysrv-Helloボットネット」の記事をご覧ください。
Sysdig MonitorでCPUとメモリの使用状況を監視する２． 異常なアウトバウンドネットワークトラフィック
普通でないアウトバウンドネットワークトラフィックは、異常を表します。これはKubernetesで一般的に監視されている指標であり、例えば、流出やボットネットのゾンビとして使用されている感染したホストなど、侵害の発覚の指標となる可能性があります。Kubernetesにおける異常な接続の検出は複雑です。なぜなら、誰が誰と話しているのか（そしてその理由）を追跡することは、分散したコンテナ化されたサービスでははるかに困難だからです。ツールは、コンテナ、ホスト、Kubernetesノード、サービス、およびプロセスを完全なコンテキスト（ネームスペース、デプロイメント、ポッド、プロセスなど）で検出し、特定のポッドやサービスに出入りするすべてのネットワーク接続を可視化するリアルタイムのトポロジーマップを作成できる必要があります。
Sysdig Monitorにおけるネットワーク・トラフィックのトポロジー・マップそして、特定のサービスが特定のアウトバウンドIPアドレスに行った接続を監視し、in/outの合計バイト数を観察することで、異常なトラフィックを検出することができます。
異常なネットワーク・トラフィックを検知するアラートの作成３．クラスター管理者ロールへのアタッチ
攻撃者は、クラスター管理者のロールにアタッチしてクラスター内で特権昇格を行うなど、特定のアクションを取ることができます。Kubernetesでは、よく練られた攻撃は通常、ある程度の特権昇格から始まり（例：2018年のTesla、WeightWatchersのセキュリティインシデント）、コマンドの実行やネットワークを通じたラテラルムーブメントが続きます。
この侵害の指標をキャッチする方法の1つは、オンプレミスまたはクラウドの複数のkubernetesクラスターにおいて、ルートユーザーで実行されているすべてのイメージの平均値を示すトポロジーマップを用意することです。これらは潜在的な権限昇格のポイントです。
Sysdig Monitorにおけるrootで実行されているコンテナのトポロジー・マップさらに、特権を持つコンテナが起動したときに警告するポリシー・ルールがあれば、検知能力をさらに高めることができます。
Sysdig Secureのルール・ライブラリ４．Kubernetesのユーザーの異常な活動
異常なユーザーアクティビティは、攻撃者の行動を明らかにし、侵害の指標となる初期の兆候となることもあります。管理者がトラブルシューティングを行うためにコンテナ内でシェルを開くなど、特定のユーザーアクティビティが正当なアクションである可能性はありますが、インタラクティブなユーザーアクティビティはすべて疑わしいものです。ユーザーのインタラクティブな活動はアンチパターンであり、何か悪意のある行為が行われていることを示している可能性があります。行動の経過を確認し、観察された敵の行動経路に該当するかどうかを検証することで、攻撃の確信度を高め、誤検知を防ぐことができます。例えば、異常なアカウントの行動を監査し、特定の期間にアクセスしたポッド、実行したコマンド、接続を監視することで、侵害の兆候をより明確に示すことができます。異常な行動を観察することは、アカウントの乗っ取りだけでなく、インサイダー攻撃にも当てはまります。
コマンドの引数を含むユーザーコマンド、pid、ディレクトリなどのシステムアクティビティを可視化し、それらをkubectlのユーザーセッションと相関させるセキュリティツールを使用することで、異常な行動を検知することができます。ゼロトラスト・アプローチでは、予想されるアクティビティの非常に厳しいリストを構築し、リスト外のものにはフラグを立てることができる、きめ細かなランタイム検出を利用します。これにより、既知および未知の攻撃プロファイルからの保護が可能になります。
Sysdig Secureのアクティビティ監査留意すべきもう一つの重要な点は、敵対者は通常、コンテナをKillすることで自分の存在や行動の痕跡を隠そうとするということです。コンテナがなくなった後も、ツールがアクティビティ監査を維持するようにしてください。
５．異常なインバウンドトラフィック
サービス拒否（DoS）攻撃に関連した異常な量のインバウンドトラフィックは、注意すべき侵害のもう一つの指標となります。Kubernetes環境では、APIサーバーへのDoS攻撃により、サーバーがリクエストを処理できなくなったり、パフォーマンスが低下したりします。典型的なDoS攻撃の1つは、サーバーのすべてのプロセス容量を消費するために膨大な量のリクエストを生成します（例：SYNフラッディング）。そのため、Kubernetes APIサーバへの攻撃を検知するための重要な指標として、異常なインバウンドトラフィックが挙げられます。
Kubernetes APIサーバのインバウンドトラフィックのサイズは、クラスターサイズとワークロードに依存します。そのため、大量のデプロイが発生したときなどは、インバウンドトラフィックが急増するはずです。それにもかかわらず、これらのユニークな状況のうち、Kubernetes APIサーバーのトラフィック状況を監視し、トラフィックが急増した特定のサービスを特定することが必要です。Kubernetes APIサーバーの受信トラフィックサイズを姿勢監視し、コンテナ名や特定の閾値を超えたかどうかなどの詳細を簡単に把握できるようにしましょう。
詳細は、”Detecting the Kubernetes API server DoS vulnerability (CVE-2019-1002100) “をご覧ください。
Sysdig Monitorのイベント６．ファイルシステムまたはディレクトリの予期せぬ変更（FIM）
ファイルシステム（FS）やディレクトリの予期せぬ変更は、攻撃者がシステム上で悪意のあるコードを実行している兆候である可能性があります。このため、セキュリティチームはこれらの攻撃を発見するために、ファイル整合性監視（FIM）を導入する必要があります。攻撃者は、ホストに手を加えた痕跡をシステムファイルや設定に残します。このような変化を確認することで、組織は侵害されたシステムをより迅速に特定することができます。
例えば、攻撃者は、ホストのファイルシステムから/etc/をコンテナ内の/mnt/etc/にマウントしたコンテナを作成します。そして、コンテナ内の/mnt/etc/以下のファイルに書き込むことで、ホスト上の/etc以下のファイルに書き込むことができるのです。このような行為は、MITRE、NIST、SOC2など、多くのセキュリティ標準やフレームワークでIOCとしてフラグが立てられているため、ランタイムセキュリティツールには、このような行為を検出するためのルールがすでに作成されていることが理想的です。
Sysdig Secureのルール・ライブラリ次のステップとして、攻撃者はパケット・スニフィング・ソフトウェアをインストールして、ネットワーク上を移動するクレジットカードデータを採取することができます。攻撃者はバイナリ名を変更することで簡単に検出を避けることができるため、特定のハーベスト・ツールを検出できる可能性は低いですが、ハーベスト・ツールを格納しているシステムの予期せぬ変更を検出することで、悪意のある動作を検出できる可能性は十分にあります。
侵害が発生した場合、敵対者の行動方針と侵害の影響範囲を理解することが重要です。そのため、フォレンジック機能を備えていることを確認してください。攻撃前後のコンテナの活動をすべて記録し、コンテナがなくなった後も、起こったことすべて（実行したコマンド、触ったファイル、行った接続など）をチームが分析できるようにする必要があります
Sysdig Inspectで変更されたファイルを閲覧これについては、「ファイル整合性監視のベスト・プラクティス」の記事で詳しく説明しています。
７．DNSリクエストの異常、または特定のホストからのDNSリクエストの大きなスパイク
DNSトラフィックの異常は、MITRE ATT&CKマトリックスのCommand and Control（例：C&CまたはC2）戦術の下で、潜在的な手法として認識されています。このトラフィックの固有のパターンは認識することができ、侵害を特定するための非常に標準的な手法です。特定のホストからのDNSリクエストが大幅に急増していることは、潜在的に悪意のある活動の良い指標となります。外部ホストへのDNSリクエストのパターンを監視し、geoIPやレピュテーションデータと比較し、適切なフィルタリングを実装することで、DNSを介したC&C戦術を特定し、緩和することができます。
1つのアプローチとして、Kubernetesのcorednsリクエスト数を含むcorednsメトリクスの監視があります。これは、環境のメトリクスデータを監視することで、攻撃の兆候を明らかにするためのインテリジェンスを提供できるという良い例です。
Sysdig MonitorでDNSのスパイクを探るFalcoによるDNSの解決についての詳細
８．異常なHTTPレスポンスサイズ
異常なHTTPレスポンス・サイズは、流出の兆候である可能性があります。例えば、攻撃者が機密性の高いクレジットカードのデータを保持するPCIスコープのネームスペースにあるWebアプリケーションにアクセスした場合、データを流出させるHTTPレスポンスは通常のリクエストよりも大きくなるでしょう。http_response_size_byteなどのメトリクスを使って、Kubernetesのデプロイメントで異常なHTTPレスポンスサイズを監視し、データの流出を検知することができます。
Sysdig MonitorでHTTPリクエストサイズを探る９．未知のバイナリプロセスが生成される
コンテナにはいくつかのセキュリティ上の利点がありますが、その1つは通常よく知られているプロセスのセットを実行することです。そのため、未知のバイナリプロセスが生成されたことを検出することは、侵害の指標となり、遂行やラテラルムーブメントのテクニックの兆候となります。このような侵害行為を検出するには、ランタイムの保護と、コンテナのランタイムに対するきめ細かな可視性が必要です。コンテナ内で実行されることが予想されるプロセスは、イメージプロファイリングによって手動または自動で簡単に定義することができます。プロセスのリストが定義されたら、次はそれをコンテナのランタイムポリシールールとして含めるだけで、生成された未知のバイナリプロセスを検出することができます。
Sysdig Secureのイメージプロファイルによる異常なプロセスの検出ここでは、未知のプロセス生成を検出するルールの例を紹介しています：
Sysdig Secureのルールライブラリしかし、検出することだけがすべてではありません。タイムリーな通知と修復（感染したコンテナのKill、停止、一時停止など）のほかに、透明性とインテリジェンスの向上のために監査可能な証拠が必要です。リアルタイムの検知、修復、監査という完全なワークフローをカバーするツールがあることを確認してください。
１０．HTTP 403および404エラーコードのスパイク
HTTP リクエストが連続して失敗し、403-forbidden または 404-unknown レスポンスが返された場合、これは侵入の試みであり、初期アクセス TTP の指標となります。侵入者は、制限されたエリアへのアクセスやフィンガープリントの実行を試みている可能性があります。エラーを含む HTTP メトリクスを監視し、エラーコードの数が急激に増加した場合には警告を出すようにしてください。
Sysdig MonitorでのHTTPリクエストのステータスコードの監視まとめ
セキュリティインシデントは孤立した出来事ではありません。セキュリティインシデントは、限界を超え、境界を突破し、予期せぬインタラクション（プロセスや接続の開始、アカウントやパーミッションの変更など）を利用し、リソース消費の障害（CPU、メモリ、帯域幅など）を引き起こします。セキュリティインシデントは、行動や影響が異常で、悪意のある存在や手順を示す指標の痕跡を残します。侵害を発見するため、あるいは侵害を試みるためには、複合的な兆候に注意を払う必要がありますが、それを可能な限り迅速に行うことができます。このブログでは、Kubernetesにおけるセキュリティ侵害指標トップ１０と、Kubernetes環境での監視でメトリクスやイベントにセキュリティアプローチに含めることで、どのようにそれらを検出できるかを共有しました。
侵害の初期指標を検出することは重要ですが、セキュリティインシデントを防ぐことが望ましいでしょう。だからこそ、セキュリティはコードから本番までのソフトウェア開発ライフサイクル（SDLC）全体に不可欠なものでなければならず、Secure DevOpsのカルチャーを完全に取り入れることができるのです。IaC（Infrastructure as Code）上でセキュリティポリシーを事前に実施し、CI/CDパイプラインにセキュリティを統合し、ランタイムでドリフトや脅威を継続的にチェックすることで保護を強化します。
Sysdig Secure DevOpsでは、単一のセキュリティおよびモニタリング・イベント・ストアから、ワークロードとクラウド・インフラストラクチャーにおいて統合された可視性を得ることができます。脅威、設定ミス、運用上の問題、コンプライアンス上のリスクをデプロイ前や本番環境で正確に警告し、詳細な活動記録を使って対応します。アウトオブボックスのインテグレーション機能により、既存のワークフローに簡単に組み込むことができます。わずか数分で使い始めることができます！
今すぐ無料トライアルをお申し込みください！