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 recopila datos de monitoreo y operación en forma de registros/métricas/eventos proporcionando una vista unificada de los recursos de AWS, aplicaciones y servicios. Los eventos de registro de CloudWatch tienen una limitación de tamaño de 256KB en cada línea de registro. Puede establecer alarmas de alta resolución, visualizar registros y métricas lado a lado, tomar acciones automatizadas, solucionar problemas y descubrir información para optimizar aplicaciones.
Puede monitorear, por ejemplo, registros de CloudTrail. Eventos que se monitorean:
Cambios en Grupos de Seguridad y NACLs
Iniciar, detener, reiniciar y terminar instancias EC2
Cambios en Políticas de Seguridad dentro de IAM y S3
Intentos de inicio de sesión fallidos en la Consola de Administración de AWS
Llamadas a la API que resultaron en autorización fallida
Filtros para buscar en cloudwatch: https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html
Un namespace es un contenedor para métricas de CloudWatch. Ayuda a categorizar e aislar métricas, facilitando su gestión y análisis.
Ejemplos: AWS/EC2 para métricas relacionadas con EC2, AWS/RDS para métricas de RDS.
Las métricas son puntos de datos recopilados a lo largo del tiempo que representan el rendimiento o la utilización de los recursos de AWS. Las métricas pueden ser recopiladas de servicios de AWS, aplicaciones personalizadas o integraciones de terceros.
Ejemplo: CPUUtilization, NetworkIn, DiskReadOps.
Las dimensiones son pares clave-valor que son parte de las métricas. Ayudan a identificar de manera única una métrica y proporcionan contexto adicional, siendo 30 el número máximo de dimensiones que se pueden asociar con una métrica. Las dimensiones también permiten filtrar y agregar métricas en función de atributos específicos.
Ejemplo: Para instancias EC2, las dimensiones pueden incluir InstanceId, InstanceType y AvailabilityZone.
Las estadísticas son cálculos matemáticos realizados sobre los datos de métricas para resumirlos a lo largo del tiempo. Las estadísticas comunes incluyen Promedio, Suma, Mínimo, Máximo y Conteo de Muestras.
Ejemplo: Calcular la utilización promedio de CPU durante un período de una hora.
Las unidades son el tipo de medida asociado con una métrica. Las unidades ayudan a proporcionar contexto y significado a los datos de la métrica. Las unidades comunes incluyen Porcentaje, Bytes, Segundos, Conteo.
Ejemplo: CPUUtilization podría medirse en Porcentaje, mientras que NetworkIn podría medirse en Bytes.
CloudWatch Dashboards proporcionan vistas personalizables de sus métricas de AWS CloudWatch. Es posible crear y configurar paneles para visualizar datos y monitorear recursos en una sola vista, combinando diferentes métricas de varios servicios de AWS.
Características Clave:
Widgets: Bloques de construcción de paneles, incluyendo gráficos, texto, alarmas y más.
Personalización: El diseño y el contenido se pueden personalizar para adaptarse a necesidades específicas de monitoreo.
Ejemplo de Caso de Uso:
Un solo panel que muestra métricas clave para todo su entorno de AWS, incluyendo instancias EC2, bases de datos RDS y buckets S3.
Metric Streams en AWS CloudWatch le permiten transmitir continuamente métricas de CloudWatch a un destino de su elección en casi tiempo real. Esto es particularmente útil para monitoreo avanzado, análisis y paneles personalizados utilizando herramientas fuera de AWS.
Metric Data dentro de Metric Streams se refiere a las mediciones o puntos de datos reales que se están transmitiendo. Estos puntos de datos representan varias métricas como utilización de CPU, uso de memoria, etc., para recursos de AWS.
Ejemplo de Caso de Uso:
Enviar métricas en tiempo real a un servicio de monitoreo de terceros para análisis avanzado.
Archivar métricas en un bucket de Amazon S3 para almacenamiento a largo plazo y cumplimiento.
CloudWatch Alarms monitorean sus métricas y realizan acciones basadas en umbrales predefinidos. Cuando una métrica supera un umbral, la alarma puede realizar una o más acciones, como enviar notificaciones a través de SNS, activar una política de autoescalado o ejecutar una función de AWS Lambda.
Componentes Clave:
Umbral: El valor en el que se activa la alarma.
Períodos de Evaluación: El número de períodos sobre los cuales se evalúan los datos.
Puntos de Datos para la Alarma: El número de períodos con un umbral alcanzado necesario para activar la alarma.
Acciones: Lo que sucede cuando se activa el estado de la alarma (por ejemplo, notificar a través de SNS).
Ejemplo de Caso de Uso:
Monitorear la utilización de CPU de la instancia EC2 y enviar una notificación a través de SNS si supera el 80% durante 5 minutos consecutivos.
Anomaly Detectors utilizan aprendizaje automático para detectar automáticamente anomalías en sus métricas. Puede aplicar la detección de anomalías a cualquier métrica de CloudWatch para identificar desviaciones de patrones normales que podrían indicar problemas.
Componentes Clave:
Entrenamiento del Modelo: CloudWatch utiliza datos históricos para entrenar un modelo y establecer cómo se ve el comportamiento normal.
Banda de Detección de Anomalías: Una representación visual del rango esperado de valores para una métrica.
Ejemplo de Caso de Uso:
Detectar patrones inusuales de utilización de CPU en una instancia EC2 que podrían indicar una brecha de seguridad o un problema de aplicación.
Insight Rules le permiten identificar tendencias, detectar picos u otros patrones de interés en sus datos de métricas utilizando expresiones matemáticas poderosas para definir las condiciones bajo las cuales se deben tomar acciones. Estas reglas pueden ayudarle a identificar anomalías o comportamientos inusuales en el rendimiento y la utilización de sus recursos.
Managed Insight Rules son reglas de insight preconfiguradas proporcionadas por AWS. Están diseñadas para monitorear servicios específicos de AWS o casos de uso comunes y se pueden habilitar sin necesidad de una configuración detallada.
Ejemplo de Caso de Uso:
Monitoreo del Rendimiento de RDS: Habilitar una regla de insight administrada para Amazon RDS que monitorea indicadores clave de rendimiento como utilización de CPU, uso de memoria y disco I/O. Si alguna de estas métricas supera los umbrales operativos seguros, la regla puede activar una alerta o una acción de mitigación automatizada.
Permite agregar y monitorear registros de aplicaciones y sistemas de servicios de AWS (incluyendo CloudTrail) y de aplicaciones/sistemas (CloudWatch Agent se puede instalar en un host). Los registros pueden ser almacenados indefinidamente (dependiendo de la configuración del Grupo de Registros) y pueden ser exportados.
Elementos:
CloudWatch básico agrega datos cada 5 minutos (el detallado lo hace cada 1 minuto). Después de la agregación, verifica los umbrales de las alarmas en caso de que necesite activar una. En ese caso, CloudWatch puede estar preparado para enviar un evento y realizar algunas acciones automáticas (funciones de AWS lambda, temas de SNS, colas de SQS, Kinesis Streams)
Puede instalar agentes dentro de sus máquinas/contenedores para enviar automáticamente los registros de vuelta a CloudWatch.
Crear un rol y adjuntarlo a la instancia con permisos que permitan a CloudWatch recopilar datos de las instancias además de interactuar con el administrador de sistemas de AWS SSM (CloudWatchAgentAdminPolicy & AmazonEC2RoleforSSM)
Descargar e instalar el agente en la instancia EC2 (https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip). Puede descargarlo desde dentro de la EC2 o instalarlo automáticamente usando AWS System Manager seleccionando el paquete AWS-ConfigureAWSPackage
Configurar y iniciar el Agente de CloudWatch
Un grupo de registros tiene muchos flujos. Un flujo tiene muchos eventos. Y dentro de cada flujo, los eventos están garantizados en orden.
cloudwatch:DeleteAlarms,cloudwatch:PutMetricAlarm , cloudwatch:PutCompositeAlarmUn atacante con estos permisos podría socavar significativamente la infraestructura de monitoreo y alertas de una organización. Al eliminar alarmas existentes, un atacante podría deshabilitar alertas cruciales que notifican a los administradores sobre problemas críticos de rendimiento, brechas de seguridad o fallos operativos. Además, al crear o modificar alarmas métricas, el atacante también podría engañar a los administradores con alertas falsas o silenciar alarmas legítimas, enmascarando efectivamente actividades maliciosas y evitando respuestas oportunas a incidentes reales.
Además, con el permiso cloudwatch:PutCompositeAlarm, un atacante podría crear un bucle o ciclo de alarmas compuestas, donde la alarma compuesta A depende de la alarma compuesta B, y la alarma compuesta B también depende de la alarma compuesta A. En este escenario, no es posible eliminar ninguna alarma compuesta que sea parte del ciclo porque siempre hay una alarma compuesta que depende de esa alarma que deseas eliminar.
El siguiente ejemplo muestra cómo hacer que una alarma de métrica sea ineficaz:
Esta alarma de métrica monitorea la utilización promedio de CPU de una instancia EC2 específica, evalúa la métrica cada 300 segundos y requiere 6 períodos de evaluación (30 minutos en total). Si la utilización promedio de CPU supera el 60% durante al menos 4 de estos períodos, la alarma se activará y enviará una notificación al tema SNS especificado.
Al modificar el Umbral para que sea más del 99%, establecer el Período en 10 segundos, los Períodos de Evaluación en 8640 (ya que 8640 períodos de 10 segundos equivalen a 1 día), y los Puntos de Datos a Alarma en 8640 también, sería necesario que la utilización de CPU estuviera por encima del 99% cada 10 segundos durante todo el período de 24 horas para activar una alarma.
Impacto Potencial: Falta de notificaciones para eventos críticos, problemas potencialmente no detectados, alertas falsas, suprimir alertas genuinas y potencialmente detecciones perdidas de incidentes reales.
cloudwatch:DeleteAlarmActions, cloudwatch:EnableAlarmActions, cloudwatch:SetAlarmStateAl eliminar acciones de alarma, el atacante podría prevenir alertas críticas y respuestas automáticas de ser activadas cuando se alcanza un estado de alarma, como notificar a los administradores o activar actividades de escalado automático. Habilitar o re-habilitar acciones de alarma de manera inapropiada también podría llevar a comportamientos inesperados, ya sea reactivando acciones previamente deshabilitadas o modificando qué acciones se activan, lo que podría causar confusión y desvío en la respuesta a incidentes.
Además, un atacante con el permiso podría manipular los estados de alarma, siendo capaz de crear falsas alarmas para distraer y confundir a los administradores, o silenciar alarmas genuinas para ocultar actividades maliciosas en curso o fallos críticos del sistema.
Si usas SetAlarmState en una alarma compuesta, la alarma compuesta no garantiza volver a su estado real. Regresa a su estado real solo una vez que cualquiera de sus alarmas hijas cambie de estado. También se reevaluará si actualizas su configuración.
Impacto Potencial: Falta de notificaciones para eventos críticos, problemas potencialmente no detectados, alertas falsas, suprimir alertas genuinas y potencialmente detecciones perdidas de incidentes reales.
cloudwatch:DeleteAnomalyDetector, cloudwatch:PutAnomalyDetectorUn atacante podría comprometer la capacidad de detección y respuesta a patrones inusuales o anomalías en los datos métricos. Al eliminar detectores de anomalías existentes, un atacante podría deshabilitar mecanismos críticos de alerta; y al crearlos o modificarlos, podría desconfigurarlos o crear falsos positivos para distraer o abrumar la supervisión.
El siguiente ejemplo muestra cómo hacer que un detector de anomalías de métricas sea ineficaz. Este detector de anomalías de métricas monitorea la utilización promedio de CPU de una instancia EC2 específica, y solo al agregar el parámetro “ExcludedTimeRanges” con el rango de tiempo deseado, sería suficiente para garantizar que el detector de anomalías no analice ni alerte sobre ningún dato relevante durante ese período.
Impacto Potencial: Efecto directo en la detección de patrones inusuales o amenazas de seguridad.
cloudwatch:DeleteDashboards, cloudwatch:PutDashboardUn atacante podría comprometer las capacidades de monitoreo y visualización de una organización al crear, modificar o eliminar sus paneles. Estos permisos podrían ser utilizados para eliminar la visibilidad crítica sobre el rendimiento y la salud de los sistemas, alterar los paneles para mostrar datos incorrectos o ocultar actividades maliciosas.
Impacto Potencial: Pérdida de visibilidad de monitoreo e información engañosa.
cloudwatch:DeleteInsightRules, cloudwatch:PutInsightRule, cloudwatch:PutManagedInsightRuleLas reglas de insight se utilizan para detectar anomalías, optimizar el rendimiento y gestionar recursos de manera efectiva. Al eliminar reglas de insight existentes, un atacante podría eliminar capacidades críticas de monitoreo, dejando al sistema ciego ante problemas de rendimiento y amenazas de seguridad. Además, un atacante podría crear o modificar reglas de insight para generar datos engañosos o ocultar actividades maliciosas, lo que llevaría a diagnósticos incorrectos y respuestas inapropiadas por parte del equipo de operaciones.
Impacto Potencial: Dificultad para detectar y responder a problemas de rendimiento y anomalías, toma de decisiones mal informadas y potencialmente ocultar actividades maliciosas o fallos del sistema.
cloudwatch:DisableInsightRules, cloudwatch:EnableInsightRulesAl deshabilitar reglas de información críticas, un atacante podría cegar efectivamente a la organización sobre métricas clave de rendimiento y seguridad. Por el contrario, al habilitar o configurar reglas engañosas, podría ser posible generar datos falsos, crear ruido u ocultar actividad maliciosa.
Impacto Potencial: Confusión entre el equipo de operaciones, lo que lleva a respuestas retrasadas a problemas reales y acciones innecesarias basadas en alertas falsas.
cloudwatch:DeleteMetricStream , cloudwatch:PutMetricStream , cloudwatch:PutMetricDataUn atacante con los permisos cloudwatch:DeleteMetricStream , cloudwatch:PutMetricStream podría crear y eliminar flujos de datos de métricas, comprometiendo la seguridad, la monitorización y la integridad de los datos:
Crear flujos maliciosos: Crear flujos de métricas para enviar datos sensibles a destinos no autorizados.
Manipulación de recursos: La creación de nuevos flujos de métricas con datos excesivos podría producir mucho ruido, causando alertas incorrectas y enmascarando problemas reales.
Interrupción de la monitorización: Al eliminar flujos de métricas, los atacantes interrumpirían el flujo continuo de datos de monitorización. De esta manera, sus actividades maliciosas estarían efectivamente ocultas.
De manera similar, con el permiso cloudwatch:PutMetricData, sería posible agregar datos a un flujo de métricas. Esto podría llevar a un DoS debido a la cantidad de datos inapropiados añadidos, haciéndolo completamente inútil.
Ejemplo de agregar datos correspondientes a un 70% de utilización de CPU en una instancia EC2 dada:
Impacto Potencial: Disrupción en el flujo de datos de monitoreo, afectando la detección de anomalías e incidentes, manipulación de recursos y aumento de costos debido a la creación de flujos de métricas excesivos.
cloudwatch:StopMetricStreams, cloudwatch:StartMetricStreamsUn atacante controlaría el flujo de los flujos de datos de métricas afectados (cada flujo de datos si no hay restricción de recursos). Con el permiso cloudwatch:StopMetricStreams, los atacantes podrían ocultar sus actividades maliciosas al detener flujos de métricas críticos.
Impacto Potencial: Disrupción en el flujo de datos de monitoreo, afectando la detección de anomalías e incidentes.
cloudwatch:TagResource, cloudwatch:UntagResourceUn atacante podría agregar, modificar o eliminar etiquetas de los recursos de CloudWatch (actualmente solo alarmas y reglas de Contributor Insights). Esto podría interrumpir las políticas de control de acceso de su organización basadas en etiquetas.
Impacto Potencial: Disrupción de las políticas de control de acceso basadas en etiquetas.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Grupo de Registros
Una colección de flujos de registros que comparten la misma retención, monitoreo y configuraciones de control de acceso
Flujo de Registros
Una secuencia de eventos de registro que comparten la misma fuente
Filtros de Suscripción
Definen un patrón de filtro que coincide con eventos en un grupo de registros particular, enviándolos a Kinesis Data Firehose stream, Kinesis stream o una función Lambda
