AWS - CloudWatch Enum
Last updated
Last updated
学习和实践 AWS 黑客技术： 学习和实践 GCP 黑客技术：
CloudWatch 收集 监控和操作 数据，以日志/指标/事件的形式提供 AWS 资源、应用程序和服务的 统一视图。 CloudWatch 日志事件的 每行日志大小限制为 256KB。 它可以设置 高分辨率警报，并并排可视化 日志 和 指标，采取自动化行动，排除故障，并发现洞察以优化应用程序。
例如，您可以监控来自 CloudTrail 的日志。监控的事件包括：
对安全组和 NACL 的更改
启动、停止、重启和终止 EC2 实例
IAM 和 S3 中安全策略的更改
对 AWS 管理控制台的登录失败尝试
导致授权失败的 API 调用
在 CloudWatch 中搜索的过滤器：
命名空间是 CloudWatch 指标的容器。它有助于对指标进行分类和隔离，使管理和分析更容易。
示例：AWS/EC2 用于与 EC2 相关的指标，AWS/RDS 用于 RDS 指标。
指标是随时间收集的数据点，代表 AWS 资源的性能或利用率。指标可以从 AWS 服务、自定义应用程序或第三方集成中收集。
示例：CPUUtilization、NetworkIn、DiskReadOps。
维度是指标的一部分的键值对。它们有助于唯一标识指标并提供额外的上下文，最多可以与一个指标关联 30 个维度。维度还允许根据特定属性过滤和聚合指标。
示例：对于 EC2 实例，维度可能包括 InstanceId、InstanceType 和 AvailabilityZone。
统计信息是对指标数据进行的数学计算，以便随时间对其进行汇总。常见的统计信息包括平均值、总和、最小值、最大值和样本计数。
示例：计算一小时内的平均 CPU 利用率。
单位是与指标相关的测量类型。单位有助于为指标数据提供上下文和意义。常见单位包括百分比、字节、秒、计数。
示例：CPUUtilization 可能以百分比为单位，而 NetworkIn 可能以字节为单位。
CloudWatch 仪表板 提供可自定义的 AWS CloudWatch 指标视图。可以创建和配置仪表板，以在单一视图中可视化数据并监控资源，结合来自各种 AWS 服务的不同指标。
关键特性：
小部件：仪表板的构建块，包括图表、文本、警报等。
自定义：布局和内容可以根据特定监控需求进行自定义。
示例用例：
一个仪表板显示您整个 AWS 环境的关键指标，包括 EC2 实例、RDS 数据库和 S3 存储桶。
指标流 在 AWS CloudWatch 中使您能够近乎实时地持续流式传输 CloudWatch 指标到您选择的目标。这对于使用 AWS 之外的工具进行高级监控、分析和自定义仪表板特别有用。
指标数据 在指标流中指的是正在流式传输的实际测量或数据点。这些数据点代表 AWS 资源的各种指标，如 CPU 利用率、内存使用等。
示例用例：
将实时指标发送到第三方监控服务以进行高级分析。
将指标存档到 Amazon S3 存储桶中以进行长期存储和合规性。
CloudWatch 警报 监控您的指标并根据预定义的阈值执行操作。当指标突破阈值时，警报可以执行一个或多个操作，例如通过 SNS 发送通知、触发自动扩展策略或运行 AWS Lambda 函数。
关键组件：
阈值：触发警报的值。
评估周期：评估数据的周期数。
触发警报的数据点：触发警报所需的达到阈值的周期数。
操作：当警报状态被触发时发生的事情（例如，通过 SNS 通知）。
示例用例：
监控 EC2 实例的 CPU 利用率，如果超过 80% 持续 5 分钟，则通过 SNS 发送通知。
异常检测器 使用机器学习自动检测您的指标中的异常。您可以将异常检测应用于任何 CloudWatch 指标，以识别可能指示问题的正常模式的偏差。
关键组件：
模型训练：CloudWatch 使用历史数据训练模型并建立正常行为的标准。
异常检测带：指标预期值范围的可视化表示。
示例用例：
检测 EC2 实例中不寻常的 CPU 利用率模式，这可能表明安全漏洞或应用程序问题。
洞察规则 允许您使用 强大的数学表达式 来定义应采取行动的条件，以识别趋势、检测峰值或其他感兴趣的模式。这些规则可以帮助您识别资源性能和利用率中的异常或不寻常行为。
托管洞察规则 是 AWS 提供的预配置 洞察规则。它们旨在监控特定的 AWS 服务或常见用例，可以在无需详细配置的情况下启用。
示例用例：
监控 RDS 性能：启用一个针对 Amazon RDS 的托管洞察规则，监控关键性能指标，如 CPU 利用率、内存使用和磁盘 I/O。如果这些指标中的任何一个超过安全操作阈值，该规则可以触发警报或自动缓解措施。
允许 聚合和监控来自应用程序 和系统的日志，来自 AWS 服务（包括 CloudTrail）和 来自应用程序/系统（CloudWatch Agent 可以安装在主机上）。日志可以 无限期存储（取决于日志组设置）并可以导出。
元素：
CloudWatch 基本 每 5 分钟 聚合数据（详细 每 1 分钟 聚合）。在聚合后，它 检查警报的阈值 以确定是否需要触发一个。 在这种情况下，CloudWatch 可以准备发送事件并执行一些自动操作（AWS Lambda 函数、SNS 主题、SQS 队列、Kinesis 流）。
您可以在机器/容器内部安装代理，以自动将日志发送回 CloudWatch。
创建 一个 角色 并 将其附加 到具有允许 CloudWatch 收集实例数据的权限的 实例，并与 AWS 系统管理器 SSM 交互（CloudWatchAgentAdminPolicy & AmazonEC2RoleforSSM）
配置 并 启动 CloudWatch Agent
一个日志组有许多流。一个流有许多事件。在每个流内，事件保证是有序的。
cloudwatch:DeleteAlarms,cloudwatch:PutMetricAlarm , cloudwatch:PutCompositeAlarm拥有这些权限的攻击者可能会严重削弱组织的监控和警报基础设施。通过删除现有警报，攻击者可以禁用通知管理员关键性能问题、安全漏洞或操作故障的重要警报。此外，通过创建或修改指标警报，攻击者还可以用虚假警报误导管理员或静音合法警报，有效掩盖恶意活动并阻止对实际事件的及时响应。
此外，拥有**cloudwatch:PutCompositeAlarm**权限的攻击者将能够创建一个复合警报的循环或周期，其中复合警报A依赖于复合警报B，而复合警报B也依赖于复合警报A。在这种情况下，无法删除任何属于该循环的复合警报，因为总是还有一个复合警报依赖于您想要删除的警报。
以下示例显示了如何使指标警报失效：
此指标警报监控特定 EC2 实例的平均 CPU 利用率，每 300 秒评估一次指标，并需要 6 个评估周期（总共 30 分钟）。如果平均 CPU 利用率在这 4 个周期中的至少 4 个周期内超过 60%，则警报将触发并向指定的 SNS 主题发送通知。
通过将阈值修改为超过 99%，将周期设置为 10 秒，将评估周期设置为 8640（因为 8640 个 10 秒的周期等于 1 天），并将数据点设置为警报也为 8640，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:PutManagedInsightRuleInsight 规则用于检测异常、优化性能和有效管理资源。通过删除现有的 insight 规则，攻击者可以移除关键的监控能力，使系统对性能问题和安全威胁失去感知。此外，攻击者可以创建或修改 insight 规则，以生成误导性数据或隐藏恶意活动，从而导致错误的诊断和运营团队的不当响应。
潜在影响：难以检测和响应性能问题和异常，错误的信息决策，可能掩盖恶意活动或系统故障。
cloudwatch:DisableInsightRules, cloudwatch:EnableInsightRules通过禁用关键的洞察规则，攻击者可以有效地使组织对关键性能和安全指标失去警觉。相反，通过启用或配置误导性规则，可能会生成虚假数据，制造噪音，或掩盖恶意活动。
潜在影响：操作团队之间的混淆，导致对实际问题的响应延迟以及基于错误警报的不必要行动。
cloudwatch:DeleteMetricStream , cloudwatch:PutMetricStream , cloudwatch:PutMetricData拥有 cloudwatch:DeleteMetricStream , cloudwatch:PutMetricStream 权限的攻击者将能够创建和删除指标数据流，从而危及安全性、监控和数据完整性：
创建恶意流：创建指标流以将敏感数据发送到未经授权的目的地。
资源操控：创建具有过多数据的新指标流可能会产生大量噪音，导致错误警报，掩盖真实问题。
监控中断：删除指标流，攻击者将中断监控数据的持续流动。这样，他们的恶意活动将有效隐藏。
同样，拥有 cloudwatch:PutMetricData 权限，可以向指标流添加数据。这可能导致由于添加了大量不当数据而造成的拒绝服务，使其完全无用。
在给定的 EC2 实例上添加与 70% CPU 利用率相对应的数据的示例：
潜在影响：监控数据流的中断，影响异常和事件的检测，资源操控以及由于创建过多的指标流而导致的成本增加。
cloudwatch:StopMetricStreams, cloudwatch:StartMetricStreams攻击者将控制受影响的指标数据流的流动（如果没有资源限制，则每个数据流）。通过权限 cloudwatch:StopMetricStreams，攻击者可以通过停止关键指标流来隐藏其恶意活动。
潜在影响：监控数据流的中断，影响异常和事件的检测。
cloudwatch:TagResource, cloudwatch:UntagResource攻击者将能够添加、修改或删除CloudWatch资源的标签（目前仅限于警报和贡献者洞察规则）。这可能会干扰您组织基于标签的访问控制策略。
潜在影响：中断基于标签的访问控制策略。
下载 并 安装 代理 到 EC2 实例上（）。您可以从 EC2 内部下载它或使用 AWS 系统管理器自动安装，选择包 AWS-ConfigureAWSPackage
学习与实践 AWS 黑客技术： 学习与实践 GCP 黑客技术：
查看 !
加入 💬 或 或 关注 我们的 Twitter 🐦 .
通过向 和 GitHub 仓库提交 PR 来分享黑客技巧。
日志组
一组 共享相同保留、监控和访问控制设置的日志流
日志流
一系列 共享相同来源的日志事件
订阅过滤器
定义一个 匹配特定日志组中事件的过滤模式，将其发送到 Kinesis Data Firehose 流、Kinesis 流或 Lambda 函数
