AWS - CloudWatch Enum
Last updated
Last updated
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
CloudWatch sammelt Überwachungs- und Betriebs-daten in Form von Protokollen/Metriken/Ereignissen und bietet eine einheitliche Sicht auf AWS-Ressourcen, Anwendungen und Dienste. CloudWatch Log-Ereignisse haben eine Größenbeschränkung von 256KB pro Protokollzeile. Es kann Hochauflösungsalarme einstellen, Protokolle und Metriken nebeneinander visualisieren, automatisierte Aktionen durchführen, Probleme beheben und Erkenntnisse gewinnen, um Anwendungen zu optimieren.
Sie können beispielsweise Protokolle von CloudTrail überwachen. Überwachte Ereignisse:
Änderungen an Sicherheitsgruppen und NACLs
Starten, Stoppen, Neustarten und Beenden von EC2-Instanzen
Änderungen an Sicherheitsrichtlinien innerhalb von IAM und S3
Fehlgeschlagene Anmeldeversuche bei der AWS Management Console
API-Aufrufe, die zu fehlgeschlagener Autorisierung führten
Filter zur Suche in CloudWatch: https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html
Ein Namespace ist ein Container für CloudWatch-Metriken. Er hilft, Metriken zu kategorisieren und zu isolieren, was die Verwaltung und Analyse erleichtert.
Beispiele: AWS/EC2 für EC2-bezogene Metriken, AWS/RDS für RDS-Metriken.
Metriken sind Datenpunkte, die über die Zeit gesammelt werden und die Leistung oder Nutzung von AWS-Ressourcen darstellen. Metriken können aus AWS-Diensten, benutzerdefinierten Anwendungen oder Drittanbieter-Integrationen gesammelt werden.
Beispiel: CPUUtilization, NetworkIn, DiskReadOps.
Dimensionen sind Schlüssel-Wert-Paare, die Teil von Metriken sind. Sie helfen, eine Metrik eindeutig zu identifizieren und bieten zusätzlichen Kontext, wobei 30 die maximale Anzahl von Dimensionen ist, die mit einer Metrik verknüpft werden können. Dimensionen ermöglichen auch das Filtern und Aggregieren von Metriken basierend auf spezifischen Attributen.
Beispiel: Für EC2-Instanzen könnten Dimensionen InstanceId, InstanceType und AvailabilityZone umfassen.
Statistiken sind mathematische Berechnungen, die auf Metrikdaten durchgeführt werden, um sie über die Zeit zusammenzufassen. Häufige Statistiken sind Durchschnitt, Summe, Minimum, Maximum und SampleCount.
Beispiel: Berechnung der durchschnittlichen CPU-Auslastung über einen Zeitraum von einer Stunde.
Einheiten sind der Messungstyp, der mit einer Metrik verbunden ist. Einheiten helfen, Kontext und Bedeutung zu den Metrikdaten bereitzustellen. Häufige Einheiten sind Prozent, Bytes, Sekunden, Anzahl.
Beispiel: CPUUtilization könnte in Prozent gemessen werden, während NetworkIn in Bytes gemessen werden könnte.
CloudWatch Dashboards bieten anpassbare Ansichten Ihrer AWS CloudWatch-Metriken. Es ist möglich, Dashboards zu erstellen und zu konfigurieren, um Daten zu visualisieren und Ressourcen in einer einzigen Ansicht zu überwachen, indem verschiedene Metriken aus verschiedenen AWS-Diensten kombiniert werden.
Hauptmerkmale:
Widgets: Bausteine von Dashboards, einschließlich Grafiken, Text, Alarme und mehr.
Anpassung: Layout und Inhalt können an spezifische Überwachungsbedürfnisse angepasst werden.
Beispielanwendung:
Ein einzelnes Dashboard, das wichtige Metriken für Ihre gesamte AWS-Umgebung anzeigt, einschließlich EC2-Instanzen, RDS-Datenbanken und S3-Buckets.
Metrikstreams in AWS CloudWatch ermöglichen es Ihnen, CloudWatch-Metriken kontinuierlich in nahezu Echtzeit an ein Ziel Ihrer Wahl zu streamen. Dies ist besonders nützlich für fortgeschrittene Überwachung, Analysen und benutzerdefinierte Dashboards mit Tools außerhalb von AWS.
Metrikdaten innerhalb von Metrikstreams beziehen sich auf die tatsächlichen Messungen oder Datenpunkte, die gestreamt werden. Diese Datenpunkte repräsentieren verschiedene Metriken wie CPU-Auslastung, Speichernutzung usw. für AWS-Ressourcen.
Beispielanwendung:
Echtzeitmetriken an einen Drittanbieter-Überwachungsdienst für eine erweiterte Analyse senden.
Metriken in einem Amazon S3-Bucket für die langfristige Speicherung und Compliance archivieren.
CloudWatch-Alarme überwachen Ihre Metriken und führen Aktionen basierend auf vordefinierten Schwellenwerten aus. Wenn eine Metrik einen Schwellenwert überschreitet, kann der Alarm eine oder mehrere Aktionen ausführen, wie z. B. Benachrichtigungen über SNS senden, eine Auto-Scaling-Richtlinie auslösen oder eine AWS Lambda-Funktion ausführen.
Hauptkomponenten:
Schwellenwert: Der Wert, bei dem der Alarm ausgelöst wird.
Bewertungszeiträume: Die Anzahl der Zeiträume, über die Daten bewertet werden.
Datenpunkte zum Alarm: Die Anzahl der Zeiträume mit einem erreichten Schwellenwert, die erforderlich sind, um den Alarm auszulösen.
Aktionen: Was passiert, wenn ein Alarmzustand ausgelöst wird (z. B. Benachrichtigung über SNS).
Beispielanwendung:
Überwachung der CPU-Auslastung einer EC2-Instanz und Senden einer Benachrichtigung über SNS, wenn sie 80 % für 5 aufeinanderfolgende Minuten überschreitet.
Anomalie-Detektoren verwenden maschinelles Lernen, um automatisch Anomalien in Ihren Metriken zu erkennen. Sie können die Anomalieerkennung auf jede CloudWatch-Metrik anwenden, um Abweichungen von normalen Mustern zu identifizieren, die auf Probleme hinweisen könnten.
Hauptkomponenten:
Modelltraining: CloudWatch verwendet historische Daten, um ein Modell zu trainieren und festzustellen, wie normales Verhalten aussieht.
Anomalieerkennungsband: Eine visuelle Darstellung des erwarteten Wertebereichs für eine Metrik.
Beispielanwendung:
Erkennung ungewöhnlicher CPU-Auslastungsmuster in einer EC2-Instanz, die auf einen Sicherheitsvorfall oder ein Anwendungsproblem hinweisen könnten.
Insight-Regeln ermöglichen es Ihnen, Trends zu identifizieren, Spitzen zu erkennen oder andere Muster von Interesse in Ihren Metrikdaten mithilfe von leistungsstarken mathematischen Ausdrücken zu definieren, unter welchen Bedingungen Aktionen ergriffen werden sollten. Diese Regeln können Ihnen helfen, Anomalien oder ungewöhnliches Verhalten in der Leistung und Nutzung Ihrer Ressourcen zu identifizieren.
Verwaltete Insight-Regeln sind vorkonfigurierte Insight-Regeln, die von AWS bereitgestellt werden. Sie sind darauf ausgelegt, spezifische AWS-Dienste oder häufige Anwendungsfälle zu überwachen und können ohne detaillierte Konfiguration aktiviert werden.
Beispielanwendung:
Überwachung der RDS-Leistung: Aktivieren Sie eine verwaltete Insight-Regel für Amazon RDS, die wichtige Leistungsindikatoren wie CPU-Auslastung, Speichernutzung und Festplatten-I/O überwacht. Wenn eine dieser Metriken sichere Betriebsgrenzen überschreitet, kann die Regel eine Warnung oder eine automatisierte Minderungshandlung auslösen.
Ermöglicht das Aggregieren und Überwachen von Protokollen aus Anwendungen und Systemen von AWS-Diensten (einschließlich CloudTrail) und von Apps/Systemen (CloudWatch-Agent kann auf einem Host installiert werden). Protokolle können unbegrenzt gespeichert werden (abhängig von den Einstellungen der Protokollgruppe) und können exportiert werden.
Elemente:
Protokollgruppe
Eine Sammlung von Protokollstreams, die dieselben Aufbewahrungs-, Überwachungs- und Zugriffskontrolleinstellungen teilen
Protokollstream
Eine Sequenz von Protokolldaten, die die gleiche Quelle teilen
Abonnementfilter
Definieren ein Filtermuster, das Ereignisse in einer bestimmten Protokollgruppe übereinstimmt, senden sie an Kinesis Data Firehose-Stream, Kinesis-Stream oder eine Lambda-Funktion
CloudWatch grundlegend aggregiert Daten alle 5 Minuten (die detaillierte macht das jede Minute). Nach der Aggregation überprüft es die Schwellenwerte der Alarme, um festzustellen, ob einer ausgelöst werden muss. In diesem Fall kann CloudWatch bereit sein, ein Ereignis zu senden und einige automatische Aktionen durchzuführen (AWS-Lambda-Funktionen, SNS-Themen, SQS-Warteschlangen, Kinesis-Streams).
Sie können Agenten in Ihren Maschinen/Containern installieren, um automatisch die Protokolle an CloudWatch zurückzusenden.
Erstellen Sie eine Rolle und fügen Sie sie der Instanz mit Berechtigungen hinzu, die es CloudWatch ermöglichen, Daten von den Instanzen zu sammeln, zusätzlich zur Interaktion mit dem AWS Systems Manager SSM (CloudWatchAgentAdminPolicy & AmazonEC2RoleforSSM).
Laden Sie den Agenten herunter und installieren Sie ihn auf der EC2-Instanz (https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip). Sie können ihn von innerhalb der EC2 herunterladen oder automatisch mit dem AWS Systems Manager installieren, indem Sie das Paket AWS-ConfigureAWSPackage auswählen.
Konfigurieren und starten Sie den CloudWatch-Agenten.
Eine Protokollgruppe hat viele Streams. Ein Stream hat viele Ereignisse. Und innerhalb jedes Streams sind die Ereignisse in der Reihenfolge garantiert.
cloudwatch:DeleteAlarms,cloudwatch:PutMetricAlarm , cloudwatch:PutCompositeAlarmEin Angreifer mit diesen Berechtigungen könnte die Überwachungs- und Alarmierungsinfrastruktur einer Organisation erheblich untergraben. Durch das Löschen vorhandener Alarme könnte ein Angreifer entscheidende Benachrichtigungen deaktivieren, die Administratoren über kritische Leistungsprobleme, Sicherheitsverletzungen oder betriebliche Ausfälle informieren. Darüber hinaus könnte der Angreifer durch das Erstellen oder Ändern von Metrik-Alarmen auch Administratoren mit falschen Alarmen in die Irre führen oder legitime Alarme zum Schweigen bringen, wodurch böswillige Aktivitäten effektiv maskiert und rechtzeitige Reaktionen auf tatsächliche Vorfälle verhindert werden.
Darüber hinaus könnte ein Angreifer mit der Berechtigung cloudwatch:PutCompositeAlarm eine Schleife oder einen Zyklus von zusammengesetzten Alarmen erstellen, bei dem zusammengesetzter Alarm A von zusammengesetztem Alarm B abhängt und zusammengesetzter Alarm B auch von zusammengesetztem Alarm A abhängt. In diesem Szenario ist es nicht möglich, einen zusammengesetzten Alarm, der Teil des Zyklus ist, zu löschen, da es immer noch einen zusammengesetzten Alarm gibt, der von dem Alarm abhängt, den Sie löschen möchten.
Das folgende Beispiel zeigt, wie man einen Metrikalarm unwirksam macht:
Dieser Metrikalarm überwacht die durchschnittliche CPU-Auslastung einer bestimmten EC2-Instanz, bewertet die Metrik alle 300 Sekunden und erfordert 6 Bewertungsperioden (insgesamt 30 Minuten). Wenn die durchschnittliche CPU-Auslastung in mindestens 4 dieser Perioden 60 % überschreitet, wird der Alarm ausgelöst und sendet eine Benachrichtigung an das angegebene SNS-Thema.
Durch die Änderung des Schwellenwerts auf mehr als 99 %, das Setzen der Periode auf 10 Sekunden, der Bewertungsperioden auf 8640 (da 8640 Perioden von 10 Sekunden 1 Tag entsprechen) und der Datapoints to Alarm auf ebenfalls 8640, wäre es erforderlich, dass die CPU-Auslastung über 99 % alle 10 Sekunden während des gesamten 24-Stunden-Zeitraums liegt, um einen Alarm auszulösen.
Potenzielle Auswirkungen: Fehlende Benachrichtigungen für kritische Ereignisse, potenziell unentdeckte Probleme, falsche Alarme, Unterdrückung echter Alarme und möglicherweise verpasste Erkennungen realer Vorfälle.
cloudwatch:DeleteAlarmActions, cloudwatch:EnableAlarmActions, cloudwatch:SetAlarmStateDurch das Löschen von Alarmaktionen könnte der Angreifer kritische Warnungen und automatisierte Reaktionen daran hindern, ausgelöst zu werden, wenn ein Alarmzustand erreicht wird, wie z.B. die Benachrichtigung von Administratoren oder das Auslösen von Auto-Scaling-Aktivitäten. Das unangemessene Aktivieren oder Wiederaktivieren von Alarmaktionen könnte ebenfalls zu unerwartetem Verhalten führen, entweder durch die Reaktivierung zuvor deaktivierter Aktionen oder durch die Änderung, welche Aktionen ausgelöst werden, was potenziell zu Verwirrung und Fehlleitungen bei der Vorfallreaktion führen kann.
Darüber hinaus könnte ein Angreifer mit der Berechtigung Alarmzustände manipulieren, indem er falsche Alarme erstellt, um Administratoren abzulenken und zu verwirren, oder echte Alarme zum Schweigen bringt, um laufende böswillige Aktivitäten oder kritische Systemausfälle zu verbergen.
Wenn Sie SetAlarmState bei einem zusammengesetzten Alarm verwenden, ist nicht garantiert, dass der zusammengesetzte Alarm in seinen tatsächlichen Zustand zurückkehrt. Er kehrt nur dann in seinen tatsächlichen Zustand zurück, wenn einer seiner untergeordneten Alarme den Zustand ändert. Er wird auch neu bewertet, wenn Sie seine Konfiguration aktualisieren.
Potenzielle Auswirkungen: Fehlende Benachrichtigungen für kritische Ereignisse, potenzielle unentdeckte Probleme, falsche Alarme, Unterdrückung echter Alarme und möglicherweise verpasste Erkennungen echter Vorfälle.
cloudwatch:DeleteAnomalyDetector, cloudwatch:PutAnomalyDetectorEin Angreifer könnte die Fähigkeit zur Erkennung und Reaktion auf ungewöhnliche Muster oder Anomalien in den Metrikdaten gefährden. Durch das Löschen vorhandener Anomalie-Detektoren könnte ein Angreifer kritische Alarmmechanismen deaktivieren; und durch das Erstellen oder Ändern dieser könnte er entweder Fehlkonfigurationen vornehmen oder falsche Positivmeldungen erzeugen, um die Überwachung abzulenken oder zu überwältigen.
Das folgende Beispiel zeigt, wie man einen Metrik-Anomalie-Detektor unwirksam macht. Dieser Metrik-Anomalie-Detektor überwacht die durchschnittliche CPU-Auslastung einer bestimmten EC2-Instanz, und allein durch das Hinzufügen des Parameters „ExcludedTimeRanges“ mit dem gewünschten Zeitbereich wäre es ausreichend, um sicherzustellen, dass der Anomalie-Detektor während dieses Zeitraums keine relevanten Daten analysiert oder warnt.
Potenzielle Auswirkungen: Direkte Auswirkungen auf die Erkennung ungewöhnlicher Muster oder Sicherheitsbedrohungen.
cloudwatch:DeleteDashboards, cloudwatch:PutDashboardEin Angreifer könnte die Überwachungs- und Visualisierungsfähigkeiten einer Organisation gefährden, indem er deren Dashboards erstellt, ändert oder löscht. Diese Berechtigungen könnten genutzt werden, um die kritische Sichtbarkeit auf die Leistung und Gesundheit von Systemen zu entfernen, Dashboards so zu ändern, dass falsche Daten angezeigt werden, oder böswillige Aktivitäten zu verbergen.
Potenzielle Auswirkungen: Verlust der Überwachungsansicht und irreführende Informationen.
cloudwatch:DeleteInsightRules, cloudwatch:PutInsightRule, cloudwatch:PutManagedInsightRuleInsight-Regeln werden verwendet, um Anomalien zu erkennen, die Leistung zu optimieren und Ressourcen effektiv zu verwalten. Durch das Löschen vorhandener Insight-Regeln könnte ein Angreifer kritische Überwachungsfähigkeiten entfernen, wodurch das System blind für Leistungsprobleme und Sicherheitsbedrohungen bleibt. Darüber hinaus könnte ein Angreifer Insight-Regeln erstellen oder ändern, um irreführende Daten zu generieren oder böswillige Aktivitäten zu verbergen, was zu falschen Diagnosen und unangemessenen Reaktionen des Betriebsteams führen würde.
Potenzielle Auswirkungen: Schwierigkeiten bei der Erkennung und Reaktion auf Leistungsprobleme und Anomalien, fehlerhafte Entscheidungsfindung und möglicherweise das Verbergen bösartiger Aktivitäten oder Systemausfälle.
cloudwatch:DisableInsightRules, cloudwatch:EnableInsightRulesDurch das Deaktivieren kritischer Einsichtsregeln könnte ein Angreifer die Organisation effektiv blind für wichtige Leistungs- und Sicherheitsmetriken machen. Umgekehrt könnte es durch das Aktivieren oder Konfigurieren irreführender Regeln möglich sein, falsche Daten zu erzeugen, Lärm zu erzeugen oder bösartige Aktivitäten zu verbergen.
Potenzielle Auswirkungen: Verwirrung im Operationsteam, was zu verzögerten Reaktionen auf tatsächliche Probleme und unnötigen Maßnahmen aufgrund falscher Alarme führt.
cloudwatch:DeleteMetricStream , cloudwatch:PutMetricStream , cloudwatch:PutMetricDataEin Angreifer mit den Berechtigungen cloudwatch:DeleteMetricStream , cloudwatch:PutMetricStream wäre in der Lage, Metrikdatenströme zu erstellen und zu löschen, was die Sicherheit, Überwachung und Datenintegrität gefährdet:
Bösartige Streams erstellen: Metrikströme erstellen, um sensible Daten an unbefugte Ziele zu senden.
Ressourcenmanipulation: Die Erstellung neuer Metrikströme mit übermäßigen Daten könnte viel Lärm erzeugen, was zu falschen Alarmen führt und wahre Probleme maskiert.
Überwachungsstörung: Durch das Löschen von Metrikströmen würden Angreifer den kontinuierlichen Fluss von Überwachungsdaten stören. Auf diese Weise wären ihre bösartigen Aktivitäten effektiv verborgen.
Ähnlich wäre es mit der Berechtigung cloudwatch:PutMetricData möglich, Daten zu einem Metrikstrom hinzuzufügen. Dies könnte zu einem DoS führen, aufgrund der Menge an unzulässigen Daten, die hinzugefügt werden, wodurch es völlig nutzlos wird.
Beispiel für das Hinzufügen von Daten, die 70 % der CPU-Auslastung über eine gegebene EC2-Instanz entsprechen:
Potenzielle Auswirkungen: Störung des Flusses von Überwachungsdaten, die die Erkennung von Anomalien und Vorfällen, die Manipulation von Ressourcen und die Kostensteigerung aufgrund der Erstellung übermäßiger Metrikströme beeinträchtigt.
cloudwatch:StopMetricStreams, cloudwatch:StartMetricStreamsEin Angreifer würde den Fluss der betroffenen Metrikdatenströme kontrollieren (jeder Datenstrom, wenn es keine Ressourcenbeschränkung gibt). Mit der Berechtigung cloudwatch:StopMetricStreams könnten Angreifer ihre bösartigen Aktivitäten verbergen, indem sie kritische Metrikströme stoppen.
Potenzielle Auswirkungen: Störung des Flusses von Überwachungsdaten, die die Erkennung von Anomalien und Vorfällen beeinträchtigt.
cloudwatch:TagResource, cloudwatch:UntagResourceEin Angreifer könnte in der Lage sein, Tags von CloudWatch-Ressourcen (derzeit nur Alarme und Contributor Insights-Regeln) hinzuzufügen, zu ändern oder zu entfernen. Dies könnte die Zugriffssteuerungsrichtlinien Ihrer Organisation, die auf Tags basieren, stören.
Potenzielle Auswirkungen: Störung der tag-basierten Zugriffskontrollrichtlinien.
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
