AWS - CloudWatch Enum
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
CloudWatchは、ログ/メトリクス/イベントの形で監視および運用データを収集し、AWSリソース、アプリケーション、サービスの統一ビューを提供します。 CloudWatchログイベントには、各ログ行のサイズ制限が256KBあります。 高解像度アラームを設定し、ログとメトリクスを並べて視覚化し、自動化されたアクションを実行し、問題をトラブルシューティングし、アプリケーションを最適化するための洞察を発見できます。
例えば、CloudTrailからのログを監視できます。監視されるイベント：
セキュリティグループおよびNACLの変更
EC2インスタンスの起動、停止、再起動、終了
IAMおよびS3内のセキュリティポリシーの変更
AWS Management Consoleへのログイン試行の失敗
認証に失敗したAPI呼び出し
CloudWatchで検索するためのフィルター: https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html
名前空間は、CloudWatchメトリクスのコンテナです。メトリクスを分類および分離するのに役立ち、管理および分析を容易にします。
例: EC2関連メトリクスのためのAWS/EC2、RDSメトリクスのためのAWS/RDS。
メトリクスは、AWSリソースのパフォーマンスまたは利用状況を表す時間をかけて収集されたデータポイントです。メトリクスは、AWSサービス、カスタムアプリケーション、またはサードパーティの統合から収集できます。
例: CPUUtilization、NetworkIn、DiskReadOps。
ディメンションは、メトリクスの一部であるキー-バリューのペアです。メトリクスを一意に識別し、追加のコンテキストを提供するのに役立ち、メトリクスに関連付けられるディメンションの最大数は30です。ディメンションは、特定の属性に基づいてメトリクスをフィルタリングおよび集約することも可能です。
例: EC2インスタンスの場合、ディメンションにはInstanceId、InstanceType、AvailabilityZoneが含まれる場合があります。
統計は、メトリクスデータに対して行われる数学的計算で、時間をかけて要約します。一般的な統計には、平均、合計、最小、最大、サンプル数が含まれます。
例: 1時間の間に平均CPU利用率を計算する。
単位は、メトリクスに関連付けられた測定タイプです。単位は、メトリクスデータにコンテキストと意味を提供するのに役立ちます。一般的な単位には、パーセント、バイト、秒、カウントが含まれます。
例: CPUUtilizationはパーセントで測定される場合があり、NetworkInはバイトで測定される場合があります。
CloudWatch Dashboardsは、あなたのAWS CloudWatchメトリクスのカスタマイズ可能なビューを提供します。データを視覚化し、リソースを単一のビューで監視するために、さまざまなAWSサービスからの異なるメトリクスを組み合わせてダッシュボードを作成および構成できます。
主な機能:
ウィジェット: グラフ、テキスト、アラームなど、ダッシュボードのビルディングブロック。
カスタマイズ: レイアウトとコンテンツは、特定の監視ニーズに合わせてカスタマイズできます。
例の使用ケース:
EC2インスタンス、RDSデータベース、S3バケットを含む、あなたのAWS環境全体の主要メトリクスを表示する単一のダッシュボード。
AWS CloudWatchのMetric Streamsは、CloudWatchメトリクスをほぼリアルタイムで選択した宛先に継続的にストリーミングすることを可能にします。これは、AWSの外部ツールを使用した高度な監視、分析、およびカスタムダッシュボードに特に便利です。
Metric Dataは、Metric Streams内でストリーミングされている実際の測定値またはデータポイントを指します。これらのデータポイントは、AWSリソースのCPU利用率、メモリ使用量など、さまざまなメトリクスを表します。
例の使用ケース:
高度な分析のために、リアルタイムメトリクスをサードパーティの監視サービスに送信する。
長期保存およびコンプライアンスのために、Amazon S3バケットにメトリクスをアーカイブする。
CloudWatch Alarmsは、メトリクスを監視し、事前定義された閾値に基づいてアクションを実行します。メトリクスが閾値を超えると、アラームはSNSを介して通知を送信したり、オートスケーリングポリシーをトリガーしたり、AWS Lambda関数を実行したりするなど、1つ以上のアクションを実行できます。
主なコンポーネント:
閾値: アラームがトリガーされる値。
評価期間: データが評価される期間の数。
アラームに必要なデータポイント: アラームをトリガーするために到達した閾値のある期間の数。
アクション: アラーム状態がトリガーされたときに何が起こるか（例：SNSを介して通知）。
例の使用ケース:
EC2インスタンスのCPU利用率を監視し、5分間連続して80%を超えた場合にSNSを介して通知を送信する。
Anomaly Detectorsは、機械学習を使用してメトリクスの異常を自動的に検出します。異常検出を任意のCloudWatchメトリクスに適用して、問題を示す可能性のある通常のパターンからの逸脱を特定できます。
主なコンポーネント:
モデルのトレーニング: CloudWatchは、過去のデータを使用してモデルをトレーニングし、正常な動作がどのようなものかを確立します。
異常検出バンド: メトリクスの期待される値の範囲を視覚的に表現したもの。
例の使用ケース:
セキュリティ侵害やアプリケーションの問題を示す可能性のあるEC2インスタンスの異常なCPU利用パターンを検出する。
Insight Rulesは、メトリクスデータ内のトレンドを特定し、スパイクやその他の興味深いパターンを検出するために、強力な数学的表現を使用してアクションを実行すべき条件を定義します。これらのルールは、リソースのパフォーマンスや利用状況における異常や異常な動作を特定するのに役立ちます。
Managed Insight Rulesは、AWSによって提供される事前構成されたインサイトルールです。特定のAWSサービスや一般的な使用ケースを監視するように設計されており、詳細な構成なしで有効にできます。
例の使用ケース:
RDSパフォーマンスの監視: CPU利用率、メモリ使用量、ディスクI/Oなどの主要なパフォーマンス指標を監視するAmazon RDSのための管理されたインサイトルールを有効にします。これらのメトリクスのいずれかが安全な運用閾値を超えた場合、ルールはアラートや自動的な緩和アクションをトリガーできます。
アプリケーションおよびシステムからのログを集約および監視することを可能にします。AWSサービス（CloudTrailを含む）およびアプリ/システムから（CloudWatch Agentをホストにインストールできます）。ログは無期限に保存できます（ロググループの設定に依存）し、エクスポートできます。
要素:
ロググループ
同じ保持、監視、およびアクセス制御設定を共有するログストリームのコレクション
ログストリーム
同じソースを共有するログイベントのシーケンス
サブスクリプションフィルター
特定のロググループ内のイベントに一致するフィルターパターンを定義し、それらをKinesis Data Firehoseストリーム、Kinesisストリーム、またはLambda関数に送信します。
CloudWatchの基本は、5分ごとにデータを集約します（詳細は1分ごとに行います）。集約後、アラームの閾値をチェックし、トリガーが必要かどうかを確認します。 その場合、CloudWatchはイベントを送信し、自動アクション（AWS Lambda関数、SNSトピック、SQSキュー、Kinesisストリーム）を実行する準備ができます。
マシン/コンテナ内にエージェントをインストールして、ログを自動的にCloudWatchに送信できます。
ロールを作成し、インスタンスに添付して、CloudWatchがインスタンスからデータを収集し、AWS Systems Manager SSMと対話できるようにする権限を付与します（CloudWatchAgentAdminPolicy & AmazonEC2RoleforSSM）。
エージェントをダウンロードし、EC2インスタンスにインストールします（https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip）。EC2内からダウンロードするか、AWS Systems Managerを使用して自動的にインストールできます。パッケージAWS-ConfigureAWSPackageを選択します。
CloudWatchエージェントを構成し、起動します。
ロググループには多くのストリームがあります。ストリームには多くのイベントがあります。そして、各ストリーム内のイベントは順序が保証されています。
cloudwatch:DeleteAlarms,cloudwatch:PutMetricAlarm , cloudwatch:PutCompositeAlarmこの権限を持つ攻撃者は、組織の監視およびアラートインフラストラクチャを大きく損なう可能性があります。既存のアラームを削除することで、攻撃者は管理者に重要なパフォーマンスの問題、セキュリティ侵害、または運用の失敗を通知する重要なアラートを無効にすることができます。さらに、メトリックアラームを作成または変更することで、攻撃者は誤ったアラートで管理者を誤導したり、正当なアラームを無効にしたりすることができ、悪意のある活動を隠蔽し、実際のインシデントに対する迅速な対応を妨げることができます。
さらに、cloudwatch:PutCompositeAlarm 権限を持つ攻撃者は、複合アラームAが複合アラームBに依存し、複合アラームBも複合アラームAに依存するような複合アラームのループまたはサイクルを作成することができます。このシナリオでは、サイクルの一部である複合アラームを削除することは不可能です。なぜなら、削除したいアラームに依存する複合アラームが常に存在するからです。
以下の例は、メトリックアラームを無効にする方法を示しています：
このメトリックアラームは、特定のEC2インスタンスの平均CPU使用率を監視し、300秒ごとにメトリックを評価し、6つの評価期間（合計30分）を必要とします。平均CPU使用率がこれらの期間のうち少なくとも4つで60%を超えると、アラームがトリガーされ、指定されたSNSトピックに通知が送信されます。
閾値を99%を超えるように変更し、期間を10秒に設定し、評価期間を8640に設定すると（8640期間の10秒は1日になります）、アラームをトリガーするには、CPU使用率が24時間全体で10秒ごとに99%を超える必要があります。
潜在的な影響: 重要なイベントの通知がない、潜在的に検出されない問題、偽のアラート、正当なアラートの抑制、実際のインシデントの検出を見逃す可能性。
cloudwatch:DeleteAlarmActions, cloudwatch:EnableAlarmActions , cloudwatch:SetAlarmStateアラームアクションを削除することで、攻撃者はアラーム状態に達したときに管理者への通知や自動スケーリング活動のトリガーなど、重要なアラートや自動応答が発動するのを防ぐことができます。不適切にアラームアクションを有効化または再有効化することも、以前に無効化されたアクションを再活性化したり、どのアクションがトリガーされるかを変更したりすることで、予期しない動作を引き起こし、インシデント対応に混乱や誤解を招く可能性があります。
さらに、権限を持つ攻撃者はアラーム状態を操作し、管理者を混乱させるために偽のアラームを作成したり、進行中の悪意のある活動や重大なシステム障害を隠すために正当なアラームを無効にしたりすることができます。
SetAlarmState をコンポジットアラームで使用すると、コンポジットアラームが実際の状態に戻ることは保証されません。子アラームのいずれかが状態を変更したときにのみ、実際の状態に戻ります。また、設定を更新すると再評価されます。
潜在的な影響: 重要なイベントに対する通知の欠如、潜在的な未検出の問題、偽のアラート、正当なアラートの抑制、そして実際のインシデントの検出を見逃す可能性。
cloudwatch:DeleteAnomalyDetector, cloudwatch:PutAnomalyDetector攻撃者は、メトリックデータの異常パターンや異常を検出し、応答する能力を妨害することができる。既存の異常検出器を削除することで、攻撃者は重要なアラート機構を無効にでき、作成または変更することで、監視を混乱させたり圧倒させたりするために、誤設定や偽のポジティブを作成することができる。
以下の例は、メトリック異常検出器を無効にする方法を示しています。このメトリック異常検出器は、特定のEC2インスタンスの平均CPU使用率を監視しており、単に「ExcludedTimeRanges」パラメータを希望の時間範囲で追加するだけで、その期間中に異常検出器が関連データを分析または警告しないことを保証するのに十分です。
潜在的影響: 異常なパターンやセキュリティ脅威の検出に直接的な影響があります。
cloudwatch:DeleteDashboards, cloudwatch:PutDashboard攻撃者は、ダッシュボードを作成、変更、または削除することによって、組織の監視および視覚化機能を妨害することができます。この権限は、システムのパフォーマンスと健康に関する重要な可視性を削除したり、ダッシュボードを変更して不正確なデータを表示させたり、悪意のある活動を隠したりするために利用される可能性があります。
潜在的な影響: 監視の可視性の喪失と誤解を招く情報。
cloudwatch:DeleteInsightRules, cloudwatch:PutInsightRule ,cloudwatch:PutManagedInsightRuleインサイトルールは、異常を検出し、パフォーマンスを最適化し、リソースを効果的に管理するために使用されます。既存のインサイトルールを削除することで、攻撃者は重要な監視機能を取り除き、システムをパフォーマンスの問題やセキュリティの脅威に対して盲目にする可能性があります。さらに、攻撃者はインサイトルールを作成または変更して誤解を招くデータを生成したり、悪意のある活動を隠したりすることができ、診断の誤りや運用チームからの不適切な対応を引き起こす可能性があります。
潜在的な影響: パフォーマンスの問題や異常を検出し対応するのが難しくなり、誤った意思決定を引き起こし、悪意のある活動やシステムの障害を隠す可能性があります。
cloudwatch:DisableInsightRules, cloudwatch:EnableInsightRules重要なインサイトルールを無効にすることで、攻撃者は組織を主要なパフォーマンスおよびセキュリティメトリクスから効果的に盲目にすることができます。逆に、誤解を招くルールを有効にしたり構成したりすることで、偽のデータを生成したり、ノイズを作成したり、悪意のある活動を隠すことが可能になるかもしれません。
潜在的な影響: オペレーションチームの混乱を招き、実際の問題への対応が遅れ、誤ったアラートに基づく不必要な行動を引き起こす。
cloudwatch:DeleteMetricStream , cloudwatch:PutMetricStream , cloudwatch:PutMetricDatacloudwatch:DeleteMetricStream 、cloudwatch:PutMetricStream の権限を持つ攻撃者は、メトリックデータストリームを作成および削除でき、セキュリティ、監視、データの整合性が損なわれます：
悪意のあるストリームの作成: メトリックストリームを作成して、機密データを不正な宛先に送信します。
リソースの操作: 過剰なデータを持つ新しいメトリックストリームの作成は、多くのノイズを生み出し、誤ったアラートを引き起こし、真の問題を隠す可能性があります。
監視の中断: メトリックストリームを削除することで、攻撃者は監視データの継続的な流れを妨害します。このようにして、彼らの悪意のある活動は効果的に隠されます。
同様に、cloudwatch:PutMetricData の権限を持つことで、メトリックストリームにデータを追加することが可能になります。これにより、不適切なデータの量が原因でDoSが発生し、完全に無用になります。
EC2インスタンスにおけるCPU使用率の70%に対応するデータを追加する例：
潜在的な影響: 監視データの流れの中断、異常やインシデントの検出に影響を与え、リソースの操作や過剰なメトリックストリームの作成によるコストの増加。
cloudwatch:StopMetricStreams, cloudwatch:StartMetricStreams攻撃者は、影響を受けたメトリックデータストリームの流れを制御します（リソース制限がない場合はすべてのデータストリーム）。権限 cloudwatch:StopMetricStreams を使用することで、攻撃者は重要なメトリックストリームを停止することにより、自らの悪意のある活動を隠すことができます。
潜在的な影響: 監視データの流れの中断が発生し、異常やインシデントの検出に影響を与える。
cloudwatch:TagResource, cloudwatch:UntagResource攻撃者はCloudWatchリソース（現在はアラームとContributor Insightsルールのみ）からタグを追加、変更、または削除することができます。これにより、タグに基づく組織のアクセス制御ポリシーが中断される可能性があります。
潜在的影響: タグベースのアクセス制御ポリシーの中断。
AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する: HackTricks Training GCP Red Team Expert (GRTE)
