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 raccoglie dati di monitoraggio e operativi sotto forma di log/metriche/eventi, fornendo una visione unificata delle risorse AWS, delle applicazioni e dei servizi. Gli eventi di log di CloudWatch hanno una limitazione di dimensione di 256KB per ogni riga di log. Può impostare allarmi ad alta risoluzione, visualizzare log e metriche affiancati, intraprendere azioni automatiche, risolvere problemi e scoprire informazioni per ottimizzare le applicazioni.
Puoi monitorare, ad esempio, i log di CloudTrail. Gli eventi monitorati includono:
Modifiche ai gruppi di sicurezza e NACL
Avvio, arresto, riavvio e terminazione delle istanze EC2
Modifiche alle politiche di sicurezza all'interno di IAM e S3
Tentativi di accesso non riusciti alla Console di gestione AWS
Chiamate API che hanno portato a un'autorizzazione non riuscita
Filtri per cercare in CloudWatch: https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html
Un namespace è un contenitore per le metriche di CloudWatch. Aiuta a categorizzare e isolare le metriche, rendendo più facile gestirle e analizzarle.
Esempi: AWS/EC2 per metriche relative a EC2, AWS/RDS per metriche RDS.
Le metriche sono punti dati raccolti nel tempo che rappresentano le prestazioni o l'utilizzo delle risorse AWS. Le metriche possono essere raccolte dai servizi AWS, da applicazioni personalizzate o da integrazioni di terze parti.
Esempio: CPUUtilization, NetworkIn, DiskReadOps.
Le dimensioni sono coppie chiave-valore che fanno parte delle metriche. Aiutano a identificare univocamente una metrica e forniscono contesto aggiuntivo, essendo 30 il numero massimo di dimensioni che possono essere associate a una metrica. Le dimensioni consentono anche di filtrare e aggregare le metriche in base a specifici attributi.
Esempio: Per le istanze EC2, le dimensioni potrebbero includere InstanceId, InstanceType e AvailabilityZone.
Le statistiche sono calcoli matematici eseguiti sui dati delle metriche per riassumerli nel tempo. Le statistiche comuni includono Media, Somma, Minimo, Massimo e ConteggioCampioni.
Esempio: Calcolare l'utilizzo medio della CPU su un periodo di un'ora.
Le unità sono il tipo di misura associato a una metrica. Le unità aiutano a fornire contesto e significato ai dati metrici. Le unità comuni includono Percentuale, Byte, Secondi, Conteggio.
Esempio: CPUUtilization potrebbe essere misurato in Percentuale, mentre NetworkIn potrebbe essere misurato in Byte.
Le dashboard di CloudWatch forniscono viste personalizzabili delle metriche di AWS CloudWatch. È possibile creare e configurare dashboard per visualizzare i dati e monitorare le risorse in un'unica vista, combinando diverse metriche da vari servizi AWS.
Caratteristiche principali:
Widget: Blocchi di costruzione delle dashboard, inclusi grafici, testo, allarmi e altro.
Personalizzazione: Layout e contenuto possono essere personalizzati per soddisfare esigenze di monitoraggio specifiche.
Esempio di caso d'uso:
Una singola dashboard che mostra metriche chiave per l'intero ambiente AWS, incluse le istanze EC2, i database RDS e i bucket S3.
I flussi di metriche in AWS CloudWatch ti consentono di trasmettere continuamente le metriche di CloudWatch a una destinazione a tua scelta in tempo quasi reale. Questo è particolarmente utile per il monitoraggio avanzato, l'analisi e dashboard personalizzate utilizzando strumenti al di fuori di AWS.
I dati metrici all'interno dei flussi di metriche si riferiscono alle misurazioni effettive o ai punti dati che vengono trasmessi. Questi punti dati rappresentano varie metriche come l'utilizzo della CPU, l'uso della memoria, ecc., per le risorse AWS.
Esempio di caso d'uso:
Inviare metriche in tempo reale a un servizio di monitoraggio di terze parti per un'analisi avanzata.
Archiviare metriche in un bucket Amazon S3 per lo stoccaggio a lungo termine e la conformità.
Gli allarmi di CloudWatch monitorano le tue metriche e intraprendono azioni basate su soglie predefinite. Quando una metrica supera una soglia, l'allarme può eseguire una o più azioni come inviare notifiche tramite SNS, attivare una politica di auto-scaling o eseguire una funzione AWS Lambda.
Componenti chiave:
Soglia: Il valore al quale l'allarme si attiva.
Periodi di valutazione: Il numero di periodi su cui i dati vengono valutati.
Punti dati per allarme: Il numero di periodi con una soglia raggiunta necessaria per attivare l'allarme.
Azioni: Cosa succede quando viene attivato uno stato di allarme (ad es., notificare tramite SNS).
Esempio di caso d'uso:
Monitorare l'utilizzo della CPU delle istanze EC2 e inviare una notifica tramite SNS se supera l'80% per 5 minuti consecutivi.
I rilevatori di anomalie utilizzano l'apprendimento automatico per rilevare automaticamente anomalie nelle tue metriche. Puoi applicare il rilevamento delle anomalie a qualsiasi metrica di CloudWatch per identificare deviazioni dai modelli normali che potrebbero indicare problemi.
Componenti chiave:
Addestramento del modello: CloudWatch utilizza dati storici per addestrare un modello e stabilire quale comportamento normale sembri.
Banda di rilevamento delle anomalie: Una rappresentazione visiva dell'intervallo di valori attesi per una metrica.
Esempio di caso d'uso:
Rilevare modelli di utilizzo della CPU insoliti in un'istanza EC2 che potrebbero indicare una violazione della sicurezza o un problema applicativo.
Le regole di insight ti consentono di identificare tendenze, rilevare picchi o altri modelli di interesse nei tuoi dati metrici utilizzando espressioni matematiche potenti per definire le condizioni in cui devono essere intraprese azioni. Queste regole possono aiutarti a identificare anomalie o comportamenti insoliti nelle prestazioni e nell'utilizzo delle tue risorse.
Le regole di insight gestite sono regole di insight preconfigurate fornite da AWS. Sono progettate per monitorare servizi AWS specifici o casi d'uso comuni e possono essere attivate senza necessità di configurazione dettagliata.
Esempio di caso d'uso:
Monitorare le prestazioni di RDS: Abilitare una regola di insight gestita per Amazon RDS che monitora indicatori chiave di prestazione come l'utilizzo della CPU, l'uso della memoria e il disco I/O. Se una di queste metriche supera le soglie operative sicure, la regola può attivare un avviso o un'azione di mitigazione automatica.
Consente di aggregare e monitorare i log delle applicazioni e dei sistemi dai servizi AWS (incluso CloudTrail) e da app/sistemi (CloudWatch Agent può essere installato su un host). I log possono essere archiviati indefinitamente (a seconda delle impostazioni del gruppo di log) e possono essere esportati.
Elementi:
Gruppo di log | Una collezione di flussi di log che condividono le stesse impostazioni di retention, monitoraggio e controllo accessi |
Flusso di log | Una sequenza di eventi di log che condividono la stessa fonte |
Filtri di sottoscrizione | Definiscono un modello di filtro che corrisponde agli eventi in un particolare gruppo di log, inviandoli a Kinesis Data Firehose stream, Kinesis stream o a una funzione Lambda |
CloudWatch base aggrega i dati ogni 5 minuti (quello dettagliato lo fa ogni 1 minuto). Dopo l'aggregazione, controlla le soglie degli allarmi nel caso debba attivarne uno. In tal caso, CloudWatch può essere preparato a inviare un evento e intraprendere alcune azioni automatiche (funzioni AWS Lambda, argomenti SNS, code SQS, flussi Kinesis).
Puoi installare agenti all'interno delle tue macchine/contenitori per inviare automaticamente i log a CloudWatch.
Crea un ruolo e allegalo all'istanza con permessi che consentano a CloudWatch di raccogliere dati dalle istanze oltre a interagire con AWS Systems Manager SSM (CloudWatchAgentAdminPolicy & AmazonEC2RoleforSSM)
Scarica e installa l'agente sull'istanza EC2 (https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip). Puoi scaricarlo dall'interno dell'EC2 o installarlo automaticamente utilizzando AWS Systems Manager selezionando il pacchetto AWS-ConfigureAWSPackage
Configura e avvia l'agente CloudWatch
Un gruppo di log ha molti flussi. Un flusso ha molti eventi. E all'interno di ciascun flusso, gli eventi sono garantiti in ordine.
cloudwatch:DeleteAlarms
,cloudwatch:PutMetricAlarm
, cloudwatch:PutCompositeAlarm
Un attaccante con questi permessi potrebbe compromettere significativamente l'infrastruttura di monitoraggio e allerta di un'organizzazione. Cancellando allarmi esistenti, un attaccante potrebbe disabilitare avvisi cruciali che notificano gli amministratori di problemi di prestazioni critici, violazioni della sicurezza o guasti operativi. Inoltre, creando o modificando allarmi metrici, l'attaccante potrebbe anche fuorviare gli amministratori con falsi avvisi o silenziare allarmi legittimi, mascherando efficacemente attività malevole e impedendo risposte tempestive a incidenti reali.
Inoltre, con il permesso cloudwatch:PutCompositeAlarm
, un attaccante sarebbe in grado di creare un ciclo di allarmi compositi, dove l'allarme composito A dipende dall'allarme composito B, e l'allarme composito B dipende anche dall'allarme composito A. In questo scenario, non è possibile eliminare alcun allarme composito che fa parte del ciclo perché c'è sempre un allarme composito che dipende da quell'allarme che si desidera eliminare.
L'esempio seguente mostra come rendere inefficace un allarme metrico:
Questo allarme metrico monitora l'utilizzo medio della CPU di un'istanza EC2 specifica, valuta la metrica ogni 300 secondi e richiede 6 periodi di valutazione (30 minuti in totale). Se l'utilizzo medio della CPU supera il 60% per almeno 4 di questi periodi, l'allarme si attiverà e invierà una notifica al topic SNS specificato.
Modificando la Soglia a più del 99%, impostando il Periodo a 10 secondi, i Periodi di Valutazione a 8640 (poiché 8640 periodi di 10 secondi equivalgono a 1 giorno) e i Datapoints to Alarm a 8640, sarebbe necessario che l'utilizzo della CPU fosse superiore al 99% ogni 10 secondi per tutto il periodo di 24 ore per attivare un allarme.
Impatto Potenziale: Mancanza di notifiche per eventi critici, potenziali problemi non rilevati, falsi allerta, soppressione di allerta genuine e potenzialmente rilevamenti mancati di incidenti reali.
cloudwatch:DeleteAlarmActions
, cloudwatch:EnableAlarmActions
, cloudwatch:SetAlarmState
Eliminando le azioni di allerta, l'attaccante potrebbe impedire che vengano attivati avvisi critici e risposte automatiche quando viene raggiunto uno stato di allerta, come notificare gli amministratori o attivare attività di auto-scaling. Abilitare o riabilitare in modo inappropriato le azioni di allerta potrebbe anche portare a comportamenti imprevisti, sia riattivando azioni precedentemente disabilitate sia modificando quali azioni vengono attivate, causando potenzialmente confusione e deviazione nella risposta agli incidenti.
Inoltre, un attaccante con il permesso potrebbe manipolare gli stati di allerta, essendo in grado di creare falsi allerta per distrarre e confondere gli amministratori, o silenziare allerta genuine per nascondere attività malevole in corso o guasti critici del sistema.
Se utilizzi SetAlarmState
su un allerta composita, l'allerta composita non è garantita a tornare al suo stato effettivo. Torna al suo stato effettivo solo una volta che uno dei suoi allerta figli cambia stato. Viene anche rivalutata se aggiorni la sua configurazione.
Impatto Potenziale: Mancanza di notifiche per eventi critici, potenziali problemi non rilevati, falsi allerta, soppressione di allerta genuine e potenzialmente rilevamenti mancati di incidenti reali.
cloudwatch:DeleteAnomalyDetector
, cloudwatch:PutAnomalyDetector
Un attaccante sarebbe in grado di compromettere la capacità di rilevare e rispondere a schemi o anomalie insolite nei dati delle metriche. Cancellando i rilevatori di anomalie esistenti, un attaccante potrebbe disabilitare meccanismi di allerta critici; e creando o modificandoli, sarebbe in grado di misconfigurare o creare falsi positivi per distrarre o sopraffare il monitoraggio.
L'esempio seguente mostra come rendere inefficace un rilevatore di anomalie metriche. Questo rilevatore di anomalie metriche monitora l'utilizzo medio della CPU di un'istanza EC2 specifica, e basta aggiungere il parametro “ExcludedTimeRanges” con l'intervallo di tempo desiderato per garantire che il rilevatore di anomalie non analizzi né avvisi su dati rilevanti durante quel periodo.
Impatto Potenziale: Effetto diretto nella rilevazione di schemi insoliti o minacce alla sicurezza.
cloudwatch:DeleteDashboards
, cloudwatch:PutDashboard
Un attaccante sarebbe in grado di compromettere le capacità di monitoraggio e visualizzazione di un'organizzazione creando, modificando o eliminando i suoi dashboard. Queste autorizzazioni potrebbero essere sfruttate per rimuovere la visibilità critica sulle prestazioni e sulla salute dei sistemi, alterare i dashboard per visualizzare dati errati o nascondere attività malevole.
Impatto Potenziale: Perdita di visibilità di monitoraggio e informazioni fuorvianti.
cloudwatch:DeleteInsightRules
, cloudwatch:PutInsightRule
,cloudwatch:PutManagedInsightRule
Le regole di insight sono utilizzate per rilevare anomalie, ottimizzare le prestazioni e gestire le risorse in modo efficace. Cancellando le regole di insight esistenti, un attaccante potrebbe rimuovere capacità di monitoraggio critiche, lasciando il sistema cieco a problemi di prestazioni e minacce alla sicurezza. Inoltre, un attaccante potrebbe creare o modificare regole di insight per generare dati fuorvianti o nascondere attività malevole, portando a diagnosi errate e risposte inappropriate da parte del team operativo.
Impatto Potenziale: Difficoltà nel rilevare e rispondere a problemi di prestazioni e anomalie, decisioni errate e potenzialmente nascondere attività malevole o guasti di sistema.
cloudwatch:DisableInsightRules
, cloudwatch:EnableInsightRules
Disabilitando le regole di insight critiche, un attaccante potrebbe effettivamente accecare l'organizzazione rispetto a metriche chiave di prestazioni e sicurezza. Al contrario, abilitando o configurando regole fuorvianti, potrebbe essere possibile generare dati falsi, creare rumore o nascondere attività malevole.
Impatto Potenziale: Confusione tra il team operativo, portando a risposte ritardate a problemi reali e azioni non necessarie basate su falsi allarmi.
cloudwatch:DeleteMetricStream
, cloudwatch:PutMetricStream
, cloudwatch:PutMetricData
Un attaccante con i permessi cloudwatch:DeleteMetricStream
, cloudwatch:PutMetricStream
sarebbe in grado di creare e cancellare flussi di dati metrici, compromettendo la sicurezza, il monitoraggio e l'integrità dei dati:
Creare flussi malevoli: Creare flussi metrici per inviare dati sensibili a destinazioni non autorizzate.
Manipolazione delle risorse: La creazione di nuovi flussi metrici con dati eccessivi potrebbe produrre molto rumore, causando allarmi errati, mascherando problemi reali.
Interruzione del monitoraggio: Cancellando i flussi metrici, gli attaccanti interromperebbero il flusso continuo di dati di monitoraggio. In questo modo, le loro attività malevole sarebbero efficacemente nascoste.
Allo stesso modo, con il permesso cloudwatch:PutMetricData
, sarebbe possibile aggiungere dati a un flusso metrico. Questo potrebbe portare a un DoS a causa della quantità di dati impropri aggiunti, rendendolo completamente inutile.
Esempio di aggiunta di dati corrispondenti al 70% di utilizzo della CPU su una data istanza EC2:
Impatto Potenziale: Interruzione nel flusso dei dati di monitoraggio, che influisce sulla rilevazione di anomalie e incidenti, manipolazione delle risorse e aumento dei costi a causa della creazione di flussi di metriche eccessivi.
cloudwatch:StopMetricStreams
, cloudwatch:StartMetricStreams
Un attaccante controllerebbe il flusso dei flussi di dati delle metriche interessate (ogni flusso di dati se non ci sono restrizioni sulle risorse). Con il permesso cloudwatch:StopMetricStreams
, gli attaccanti potrebbero nascondere le loro attività malevole fermando i flussi di metriche critiche.
Impatto Potenziale: Interruzione nel flusso dei dati di monitoraggio, influenzando la rilevazione di anomalie e incidenti.
cloudwatch:TagResource
, cloudwatch:UntagResource
Un attaccante sarebbe in grado di aggiungere, modificare o rimuovere tag dalle risorse di CloudWatch (attualmente solo allarmi e regole di Contributor Insights). Questo potrebbe interrompere le politiche di controllo degli accessi della tua organizzazione basate sui tag.
Impatto Potenziale: Interruzione delle politiche di controllo degli accessi basate su tag.
Impara e pratica il Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica il Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)