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 collecte des données de surveillance et opérationnelles sous forme de journaux/métriques/événements fournissant une vue unifiée des ressources AWS, des applications et des services. Les événements de journal CloudWatch ont une limite de taille de 256 Ko par ligne de journal. Il peut définir des alarmes à haute résolution, visualiser les journaux et les métriques côte à côte, prendre des actions automatisées, résoudre des problèmes et découvrir des informations pour optimiser les applications.
Vous pouvez surveiller par exemple les journaux de CloudTrail. Les événements qui sont surveillés :
Changements dans les groupes de sécurité et les NACL
Démarrage, arrêt, redémarrage et terminaison des instances EC2
Changements dans les politiques de sécurité au sein d'IAM et S3
Tentatives de connexion échouées à la console de gestion AWS
Appels API ayant entraîné un échec d'autorisation
Filtres pour rechercher dans CloudWatch : https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html
Un espace de noms est un conteneur pour les métriques CloudWatch. Il aide à catégoriser et isoler les métriques, facilitant leur gestion et leur analyse.
Exemples : AWS/EC2 pour les métriques liées à EC2, AWS/RDS pour les métriques RDS.
Les métriques sont des points de données collectés au fil du temps qui représentent la performance ou l'utilisation des ressources AWS. Les métriques peuvent être collectées à partir des services AWS, d'applications personnalisées ou d'intégrations tierces.
Exemple : CPUUtilization, NetworkIn, DiskReadOps.
Les dimensions sont des paires clé-valeur qui font partie des métriques. Elles aident à identifier de manière unique une métrique et fournissent un contexte supplémentaire, le nombre maximum de dimensions pouvant être associées à une métrique étant de 30. Les dimensions permettent également de filtrer et d'agréger les métriques en fonction d'attributs spécifiques.
Exemple : Pour les instances EC2, les dimensions peuvent inclure InstanceId, InstanceType et AvailabilityZone.
Les statistiques sont des calculs mathématiques effectués sur les données de métriques pour les résumer au fil du temps. Les statistiques courantes incluent Moyenne, Somme, Minimum, Maximum et Compte d'échantillons.
Exemple : Calculer la moyenne d'utilisation du CPU sur une période d'une heure.
Les unités sont le type de mesure associé à une métrique. Les unités aident à fournir un contexte et une signification aux données de métriques. Les unités courantes incluent Pourcentage, Octets, Secondes, Compte.
Exemple : CPUUtilization peut être mesuré en Pourcentage, tandis que NetworkIn peut être mesuré en Octets.
Les tableaux de bord CloudWatch fournissent des vues personnalisables de vos métriques AWS CloudWatch. Il est possible de créer et de configurer des tableaux de bord pour visualiser les données et surveiller les ressources dans une vue unique, combinant différentes métriques de divers services AWS.
Fonctionnalités clés :
Widgets : Éléments de base des tableaux de bord, y compris des graphiques, du texte, des alarmes, et plus encore.
Personnalisation : La mise en page et le contenu peuvent être personnalisés pour répondre à des besoins de surveillance spécifiques.
Exemple de cas d'utilisation :
Un tableau de bord unique affichant les métriques clés pour l'ensemble de votre environnement AWS, y compris les instances EC2, les bases de données RDS et les compartiments S3.
Les flux de métriques dans AWS CloudWatch vous permettent de diffuser en continu les métriques CloudWatch vers une destination de votre choix en quasi temps réel. Cela est particulièrement utile pour la surveillance avancée, l'analyse et les tableaux de bord personnalisés utilisant des outils en dehors d'AWS.
Les données de métriques à l'intérieur des flux de métriques font référence aux mesures ou points de données réels qui sont diffusés. Ces points de données représentent diverses métriques comme l'utilisation du CPU, l'utilisation de la mémoire, etc., pour les ressources AWS.
Exemple de cas d'utilisation :
Envoi de métriques en temps réel à un service de surveillance tiers pour une analyse avancée.
Archivage des métriques dans un compartiment Amazon S3 pour un stockage à long terme et une conformité.
Les alarmes CloudWatch surveillent vos métriques et effectuent des actions basées sur des seuils prédéfinis. Lorsqu'une métrique dépasse un seuil, l'alarme peut effectuer une ou plusieurs actions telles que l'envoi de notifications via SNS, le déclenchement d'une politique d'auto-scaling ou l'exécution d'une fonction AWS Lambda.
Composants clés :
Seuil : La valeur à laquelle l'alarme se déclenche.
Périodes d'évaluation : Le nombre de périodes sur lesquelles les données sont évaluées.
Points de données à alerter : Le nombre de périodes avec un seuil atteint nécessaire pour déclencher l'alarme.
Actions : Ce qui se passe lorsqu'un état d'alarme est déclenché (par exemple, notifier via SNS).
Exemple de cas d'utilisation :
Surveiller l'utilisation du CPU d'une instance EC2 et envoyer une notification via SNS si elle dépasse 80 % pendant 5 minutes consécutives.
Les détecteurs d'anomalies utilisent l'apprentissage automatique pour détecter automatiquement les anomalies dans vos métriques. Vous pouvez appliquer la détection d'anomalies à n'importe quelle métrique CloudWatch pour identifier les écarts par rapport aux modèles normaux qui pourraient indiquer des problèmes.
Composants clés :
Entraînement du modèle : CloudWatch utilise des données historiques pour entraîner un modèle et établir à quoi ressemble un comportement normal.
Bande de détection d'anomalies : Une représentation visuelle de la plage de valeurs attendue pour une métrique.
Exemple de cas d'utilisation :
Détecter des modèles d'utilisation du CPU inhabituels dans une instance EC2 qui pourraient indiquer une violation de sécurité ou un problème d'application.
Les règles d'insight vous permettent d'identifier des tendances, de détecter des pics ou d'autres modèles d'intérêt dans vos données de métriques en utilisant des expressions mathématiques puissantes pour définir les conditions sous lesquelles des actions doivent être prises. Ces règles peuvent vous aider à identifier des anomalies ou des comportements inhabituels dans la performance et l'utilisation de vos ressources.
Les règles d'insight gérées sont des règles d'insight préconfigurées fournies par AWS. Elles sont conçues pour surveiller des services AWS spécifiques ou des cas d'utilisation courants et peuvent être activées sans nécessiter de configuration détaillée.
Exemple de cas d'utilisation :
Surveiller la performance RDS : Activer une règle d'insight gérée pour Amazon RDS qui surveille les indicateurs de performance clés tels que l'utilisation du CPU, l'utilisation de la mémoire et les E/S de disque. Si l'une de ces métriques dépasse des seuils opérationnels sûrs, la règle peut déclencher une alerte ou une action d'atténuation automatisée.
Permet de regrouper et surveiller les journaux des applications et des systèmes des services AWS (y compris CloudTrail) et des applications/systèmes (L'agent CloudWatch peut être installé sur un hôte). Les journaux peuvent être stockés indéfiniment (selon les paramètres du groupe de journaux) et peuvent être exportés.
Éléments :
Groupe de journaux | Une collection de flux de journaux qui partagent les mêmes paramètres de conservation, de surveillance et de contrôle d'accès |
Flux de journaux | Une séquence d'événements de journaux qui partagent la même source |
Filtres d'abonnement | Définir un modèle de filtre qui correspond aux événements dans un groupe de journaux particulier, les envoyer à un flux Kinesis Data Firehose, un flux Kinesis ou une fonction Lambda |
CloudWatch de base agrège les données toutes les 5 minutes (la détaillée le fait toutes les 1 minute). Après l'agrégation, il vérifie les seuils des alarmes au cas où il faudrait en déclencher une. Dans ce cas, CloudWatch peut être préparé à envoyer un événement et à effectuer certaines actions automatiques (fonctions AWS lambda, sujets SNS, files d'attente SQS, flux Kinesis)
Vous pouvez installer des agents à l'intérieur de vos machines/conteneurs pour envoyer automatiquement les journaux à CloudWatch.
Créer un rôle et l'attacher à l'instance avec des autorisations permettant à CloudWatch de collecter des données des instances en plus d'interagir avec AWS Systems Manager SSM (CloudWatchAgentAdminPolicy & AmazonEC2RoleforSSM)
Télécharger et installer l'agent sur l'instance EC2 (https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip). Vous pouvez le télécharger depuis l'intérieur de l'EC2 ou l'installer automatiquement en utilisant AWS Systems Manager en sélectionnant le package AWS-ConfigureAWSPackage
Configurer et démarrer l'agent CloudWatch
Un groupe de journaux a plusieurs flux. Un flux a plusieurs événements. Et à l'intérieur de chaque flux, les événements sont garantis d'être dans l'ordre.
cloudwatch:DeleteAlarms,cloudwatch:PutMetricAlarm , cloudwatch:PutCompositeAlarmUn attaquant avec ces permissions pourrait considérablement compromettre l'infrastructure de surveillance et d'alerte d'une organisation. En supprimant des alarmes existantes, un attaquant pourrait désactiver des alertes cruciales qui notifient les administrateurs de problèmes de performance critiques, de violations de sécurité ou de pannes opérationnelles. De plus, en créant ou en modifiant des alarmes métriques, l'attaquant pourrait également induire les administrateurs en erreur avec de fausses alertes ou faire taire des alarmes légitimes, masquant ainsi efficacement des activités malveillantes et empêchant des réponses rapides à des incidents réels.
De plus, avec la permission cloudwatch:PutCompositeAlarm, un attaquant serait en mesure de créer une boucle ou un cycle d'alarmes composites, où l'alarme composite A dépend de l'alarme composite B, et l'alarme composite B dépend également de l'alarme composite A. Dans ce scénario, il n'est pas possible de supprimer une alarme composite qui fait partie du cycle car il y a toujours une alarme composite qui dépend de cette alarme que vous souhaitez supprimer.
L'exemple suivant montre comment rendre une alarme de métrique inefficace :
Cette alarme de métrique surveille l'utilisation moyenne du CPU d'une instance EC2 spécifique, évalue la métrique toutes les 300 secondes et nécessite 6 périodes d'évaluation (30 minutes au total). Si l'utilisation moyenne du CPU dépasse 60 % pendant au moins 4 de ces périodes, l'alarme se déclenchera et enverra une notification au sujet SNS spécifié.
En modifiant le seuil pour qu'il soit supérieur à 99 %, en réglant la période à 10 secondes, les périodes d'évaluation à 8640 (puisque 8640 périodes de 10 secondes équivalent à 1 jour), et les points de données à alarme à 8640 également, il serait nécessaire que l'utilisation du CPU soit supérieure à 99 % toutes les 10 secondes pendant toute la période de 24 heures pour déclencher une alarme.
Impact potentiel : Manque de notifications pour des événements critiques, problèmes potentiellement non détectés, fausses alertes, suppression d'alertes authentiques et détections potentiellement manquées d'incidents réels.
cloudwatch:DeleteAlarmActions, cloudwatch:EnableAlarmActions, cloudwatch:SetAlarmStateEn supprimant les actions d'alarme, l'attaquant pourrait empêcher des alertes critiques et des réponses automatisées d'être déclenchées lorsqu'un état d'alarme est atteint, comme notifier les administrateurs ou déclencher des activités d'auto-scaling. Activer ou réactiver inappropriément des actions d'alarme pourrait également entraîner des comportements inattendus, soit en réactivant des actions précédemment désactivées, soit en modifiant les actions déclenchées, ce qui pourrait causer de la confusion et une mauvaise orientation dans la réponse aux incidents.
De plus, un attaquant ayant la permission pourrait manipuler les états d'alarme, étant capable de créer de fausses alarmes pour distraire et confondre les administrateurs, ou de faire taire de véritables alarmes pour cacher des activités malveillantes en cours ou des pannes critiques du système.
Si vous utilisez SetAlarmState sur une alarme composite, l'alarme composite n'est pas garantie de revenir à son état réel. Elle ne revient à son état réel que lorsque l'un de ses alarmes enfants change d'état. Elle est également réévaluée si vous mettez à jour sa configuration.
Impact potentiel : Manque de notifications pour des événements critiques, problèmes potentiellement non détectés, fausses alertes, suppression d'alertes réelles et détections potentiellement manquées d'incidents réels.
cloudwatch:DeleteAnomalyDetector, cloudwatch:PutAnomalyDetectorUn attaquant pourrait compromettre la capacité de détection et de réponse à des modèles ou des anomalies inhabituels dans les données métriques. En supprimant des détecteurs d'anomalies existants, un attaquant pourrait désactiver des mécanismes d'alerte critiques ; et en les créant ou en les modifiant, il pourrait soit mal configurer, soit créer de faux positifs afin de distraire ou de submerger la surveillance.
L'exemple suivant montre comment rendre un détecteur d'anomalies de métriques inefficace. Ce détecteur d'anomalies de métriques surveille l'utilisation moyenne du CPU d'une instance EC2 spécifique, et il suffirait d'ajouter le paramètre “ExcludedTimeRanges” avec la plage horaire souhaitée pour s'assurer que le détecteur d'anomalies n'analyse ni n'alerte sur des données pertinentes pendant cette période.
Impact potentiel : Effet direct sur la détection de modèles inhabituels ou de menaces à la sécurité.
cloudwatch:DeleteDashboards, cloudwatch:PutDashboardUn attaquant pourrait compromettre les capacités de surveillance et de visualisation d'une organisation en créant, modifiant ou supprimant ses tableaux de bord. Ces autorisations pourraient être utilisées pour supprimer une visibilité critique sur la performance et la santé des systèmes, modifier les tableaux de bord pour afficher des données incorrectes ou cacher des activités malveillantes.
Impact potentiel : Perte de visibilité de surveillance et informations trompeuses.
cloudwatch:DeleteInsightRules, cloudwatch:PutInsightRule ,cloudwatch:PutManagedInsightRuleLes règles d'analyse sont utilisées pour détecter des anomalies, optimiser les performances et gérer les ressources efficacement. En supprimant les règles d'analyse existantes, un attaquant pourrait éliminer des capacités de surveillance critiques, laissant le système aveugle aux problèmes de performance et aux menaces de sécurité. De plus, un attaquant pourrait créer ou modifier des règles d'analyse pour générer des données trompeuses ou cacher des activités malveillantes, entraînant des diagnostics incorrects et des réponses inappropriées de l'équipe des opérations.
Impact potentiel : Difficulté à détecter et à répondre aux problèmes de performance et aux anomalies, prise de décision mal informée et potentiel dissimulation d'activités malveillantes ou de pannes système.
cloudwatch:DisableInsightRules, cloudwatch:EnableInsightRulesEn désactivant des règles d'insight critiques, un attaquant pourrait effectivement aveugler l'organisation sur des métriques clés de performance et de sécurité. Inversement, en activant ou en configurant des règles trompeuses, il pourrait être possible de générer des données fausses, de créer du bruit ou de dissimuler une activité malveillante.
Impact potentiel : Confusion au sein de l'équipe des opérations, entraînant des réponses retardées aux problèmes réels et des actions inutiles basées sur de fausses alertes.
cloudwatch:DeleteMetricStream , cloudwatch:PutMetricStream , cloudwatch:PutMetricDataUn attaquant avec les permissions cloudwatch:DeleteMetricStream, cloudwatch:PutMetricStream serait capable de créer et de supprimer des flux de données métriques, compromettant la sécurité, la surveillance et l'intégrité des données :
Créer des flux malveillants : Créer des flux métriques pour envoyer des données sensibles vers des destinations non autorisées.
Manipulation des ressources : La création de nouveaux flux métriques avec des données excessives pourrait produire beaucoup de bruit, entraînant des alertes incorrectes, masquant de véritables problèmes.
Perturbation de la surveillance : En supprimant des flux métriques, les attaquants perturberaient le flux continu de données de surveillance. De cette manière, leurs activités malveillantes seraient efficacement cachées.
De même, avec la permission cloudwatch:PutMetricData, il serait possible d'ajouter des données à un flux métrique. Cela pourrait entraîner un DoS en raison de la quantité de données inappropriées ajoutées, rendant le flux complètement inutile.
Exemple d'ajout de données correspondant à une utilisation du CPU de 70 % sur une instance EC2 donnée :
Impact potentiel : Disruption dans le flux de données de surveillance, impactant la détection des anomalies et des incidents, manipulation des ressources et augmentation des coûts en raison de la création de flux de métriques excessifs.
cloudwatch:StopMetricStreams, cloudwatch:StartMetricStreamsUn attaquant contrôlerait le flux des flux de données de métriques affectés (chaque flux de données s'il n'y a pas de restriction de ressource). Avec la permission cloudwatch:StopMetricStreams, les attaquants pourraient cacher leurs activités malveillantes en arrêtant des flux de métriques critiques.
Impact potentiel : Perturbation du flux de données de surveillance, impactant la détection des anomalies et des incidents.
cloudwatch:TagResource, cloudwatch:UntagResourceUn attaquant pourrait ajouter, modifier ou supprimer des balises des ressources CloudWatch (actuellement uniquement des alarmes et des règles Contributor Insights). Cela pourrait perturber les politiques de contrôle d'accès de votre organisation basées sur des balises.
Impact potentiel : Perturbation des politiques de contrôle d'accès basées sur des balises.
Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE) Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)
