mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-13 13:26:31 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-basic-information/REA
This commit is contained in:
Translator
@@ -10,7 +10,7 @@ Ogni evento registrato contiene:
|
||||
|
||||
- Il nome dell'API chiamata: `eventName`
|
||||
- Il servizio chiamato: `eventSource`
|
||||
- Il tempo: `eventTime`
|
||||
- L'ora: `eventTime`
|
||||
- L'indirizzo IP: `SourceIPAddress`
|
||||
- Il metodo dell'agente: `userAgent`. Esempi:
|
||||
- Signing.amazonaws.com - Dalla Console di gestione AWS
|
||||
@@ -24,7 +24,7 @@ I log di CloudTrail possono essere **aggregati tra account e tra regioni.**\
|
||||
CloudTrail consente di utilizzare **l'integrità del file di log per poter verificare che i tuoi file di log siano rimasti invariati** da quando CloudTrail li ha consegnati a te. Crea un hash SHA-256 dei log all'interno di un file di digest. Un hash sha-256 dei nuovi log viene creato ogni ora.\
|
||||
Quando si crea un Trail, i selettori di eventi ti permetteranno di indicare il trail da registrare: eventi di gestione, dati o approfondimenti.
|
||||
|
||||
I log vengono salvati in un bucket S3. Per impostazione predefinita, viene utilizzata la crittografia lato server (SSE-S3), quindi AWS decripterà il contenuto per le persone che hanno accesso, ma per ulteriore sicurezza puoi utilizzare SSE con KMS e le tue chiavi.
|
||||
I log vengono salvati in un bucket S3. Per impostazione predefinita viene utilizzata la crittografia lato server (SSE-S3), quindi AWS decripterà il contenuto per le persone che hanno accesso, ma per ulteriore sicurezza puoi utilizzare SSE con KMS e le tue chiavi.
|
||||
|
||||
I log sono memorizzati in un **bucket S3 con questo formato di nome**:
|
||||
|
||||
@@ -88,15 +88,15 @@ La Cronologia Eventi di CloudTrail ti consente di ispezionare in una tabella i l
|
||||
Le informazioni sono memorizzate nello stesso bucket dei log di CloudTrail in: `BucketName/AWSLogs/AccountID/CloudTrail-Insight`
|
||||
|
||||
### Security
|
||||
|
||||
| CloudTrail Log File Integrity | <ul><li>Valida se i log sono stati manomessi (modificati o eliminati)</li><li><p>Utilizza file di digest (crea hash per ogni file)</p><ul><li>SHA-256 hashing</li><li>SHA-256 con RSA per la firma digitale</li><li>chiave privata di proprietà di Amazon</li></ul></li><li>Richiede 1 ora per creare un file di digest (eseguito all'ora ogni ora)</li></ul> |
|
||||
| Control Name | Implementation Details |
|
||||
| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| CloudTrail Log File Integrity | <ul><li>Valida se i log sono stati manomessi (modificati o eliminati)</li><li><p>Utilizza file di digest (crea hash per ogni file)</p><ul><li>SHA-256 hashing</li><li>SHA-256 con RSA per la firma digitale</li><li>chiave privata di proprietà di Amazon</li></ul></li><li>Richiede 1 ora per creare un file di digest (eseguito all'ora ogni ora)</li></ul> |
|
||||
| Stop unauthorized access | <ul><li><p>Utilizza politiche IAM e politiche del bucket S3</p><ul><li>team di sicurezza —> accesso admin</li><li>auditori —> accesso in sola lettura</li></ul></li><li>Utilizza SSE-S3/SSE-KMS per crittografare i log</li></ul> |
|
||||
| Prevent log files from being deleted | <ul><li>Restringi l'accesso all'eliminazione con IAM e politiche del bucket</li><li>Configura l'eliminazione MFA di S3</li><li>Valida con la Validazione del File di Log</li></ul> |
|
||||
|
||||
## Access Advisor
|
||||
|
||||
AWS Access Advisor si basa sugli ultimi 400 giorni di log di AWS **CloudTrail per raccogliere le sue informazioni**. CloudTrail cattura una cronologia delle chiamate API AWS e degli eventi correlati effettuati in un account AWS. Access Advisor utilizza questi dati per **mostrare quando i servizi sono stati accessi l'ultima volta**. Analizzando i log di CloudTrail, Access Advisor può determinare quali servizi AWS un utente IAM o un ruolo ha accesso e quando è avvenuto tale accesso. Questo aiuta gli amministratori AWS a prendere decisioni informate su **come affinare le autorizzazioni**, poiché possono identificare i servizi che non sono stati accessi per lunghi periodi e potenzialmente ridurre autorizzazioni eccessivamente ampie basate su modelli di utilizzo reali.
|
||||
AWS Access Advisor si basa sugli ultimi 400 giorni di log di AWS **CloudTrail per raccogliere le sue informazioni**. CloudTrail cattura una cronologia delle chiamate API AWS e degli eventi correlati effettuati in un account AWS. Access Advisor utilizza questi dati per **mostrare quando i servizi sono stati ultimi accessi**. Analizzando i log di CloudTrail, Access Advisor può determinare quali servizi AWS un utente IAM o un ruolo ha accesso e quando è avvenuto tale accesso. Questo aiuta gli amministratori AWS a prendere decisioni informate su **come affinare le autorizzazioni**, poiché possono identificare i servizi che non sono stati accessi per lunghi periodi e potenzialmente ridurre autorizzazioni eccessivamente ampie basate su modelli di utilizzo reali.
|
||||
|
||||
> [!TIP]
|
||||
> Pertanto, Access Advisor informa sulle **autorizzazioni non necessarie concesse agli utenti** in modo che l'amministratore possa rimuoverle
|
||||
@@ -150,7 +150,7 @@ Per ulteriori informazioni su questa specifica tecnica, controlla [https://rhino
|
||||
|
||||
I Honeytokens sono creati per **rilevare l'esfiltrazione di informazioni sensibili**. Nel caso di AWS, sono **chiavi AWS il cui utilizzo è monitorato**, se qualcosa attiva un'azione con quella chiave, allora qualcuno deve aver rubato quella chiave.
|
||||
|
||||
Tuttavia, i Honeytokens come quelli creati da [**Canarytokens**](https://canarytokens.org/generate)**,** [**SpaceCrab**](https://bitbucket.org/asecurityteam/spacecrab/issues?status=new&status=open)**,** [**SpaceSiren**](https://github.com/spacesiren/spacesiren) utilizzano un nome account riconoscibile o utilizzano lo stesso ID account AWS per tutti i loro clienti. Pertanto, se riesci a ottenere il nome dell'account e/o l'ID dell'account senza far creare alcun log a Cloudtrail, **potresti sapere se la chiave è un honeytoken o meno**.
|
||||
Tuttavia, i Honeytokens come quelli creati da [**Canarytokens**](https://canarytokens.org/generate)**,** [**SpaceCrab**](https://bitbucket.org/asecurityteam/spacecrab/issues?status=new&status=open)**,** [**SpaceSiren**](https://github.com/spacesiren/spacesiren) utilizzano un nome account riconoscibile o usano lo stesso ID account AWS per tutti i loro clienti. Pertanto, se riesci a ottenere il nome dell'account e/o l'ID dell'account senza far creare alcun log a Cloudtrail, **potresti sapere se la chiave è un honeytoken o meno**.
|
||||
|
||||
[**Pacu**](https://github.com/RhinoSecurityLabs/pacu/blob/79cd7d58f7bff5693c6ae73b30a8455df6136cca/pacu/modules/iam__detect_honeytokens/main.py#L57) ha alcune regole per rilevare se una chiave appartiene a [**Canarytokens**](https://canarytokens.org/generate)**,** [**SpaceCrab**](https://bitbucket.org/asecurityteam/spacecrab/issues?status=new&status=open)**,** [**SpaceSiren**](https://github.com/spacesiren/spacesiren)**:**
|
||||
|
||||
@@ -185,7 +185,7 @@ Controlla ulteriori informazioni nella [**ricerca originale**](https://medium.co
|
||||
|
||||
#### Non generare un log
|
||||
|
||||
La tecnica più efficace per questo è in realtà una semplice. Usa semplicemente la chiave che hai appena trovato per accedere a qualche servizio all'interno del tuo account attaccante. Questo farà sì che **CloudTrail generi un log all'interno del TUO account AWS e non all'interno di quello delle vittime**.
|
||||
La tecnica più efficace per questo è in realtà una semplice. Basta utilizzare la chiave che hai appena trovato per accedere a qualche servizio all'interno del tuo account attaccante. Questo farà sì che **CloudTrail generi un log all'interno del TUO account AWS e non all'interno di quello delle vittime**.
|
||||
|
||||
Il fatto è che l'output mostrerà un errore che indica l'ID dell'account e il nome dell'account, quindi **sarai in grado di vedere se si tratta di un Honeytoken**.
|
||||
|
||||
@@ -206,7 +206,7 @@ In questo modo, un **attaccante può ottenere l'ARN della chiave senza attivare
|
||||
|
||||
Alcuni servizi AWS **genereranno un'infrastruttura** come **Database** o **cluster Kubernetes** (EKS). Un utente **che parla direttamente a quei servizi** (come l'API Kubernetes) **non utilizzerà l'API AWS**, quindi CloudTrail non sarà in grado di vedere questa comunicazione.
|
||||
|
||||
Pertanto, un utente con accesso a EKS che ha scoperto l'URL dell'API EKS potrebbe generare un token localmente e **parlare direttamente con il servizio API senza essere rilevato da Cloudtrail**.
|
||||
Pertanto, un utente con accesso a EKS che ha scoperto l'URL dell'API EKS potrebbe generare un token localmente e **parlare direttamente con il servizio API senza essere rilevato da CloudTrail**.
|
||||
|
||||
Ulteriori informazioni in:
|
||||
|
||||
@@ -224,7 +224,7 @@ aws cloudtrail delete-trail --name [trail-name]
|
||||
```bash
|
||||
aws cloudtrail stop-logging --name [trail-name]
|
||||
```
|
||||
#### Disabilita il logging multi-regione
|
||||
#### Disabilita la registrazione multi-regione
|
||||
```bash
|
||||
aws cloudtrail update-trail --name [trail-name] --no-is-multi-region --no-include-global-services
|
||||
```
|
||||
@@ -236,7 +236,7 @@ aws cloudtrail put-event-selectors --trail-name <trail_name> --event-selectors '
|
||||
# Remove all selectors (stop Insights)
|
||||
aws cloudtrail put-event-selectors --trail-name <trail_name> --event-selectors '[]' --region <region>
|
||||
```
|
||||
Nel primo esempio, viene fornito un selettore di eventi singolo come un array JSON con un singolo oggetto. Il `"ReadWriteType": "ReadOnly"` indica che il **selettore di eventi dovrebbe catturare solo eventi di sola lettura** (quindi CloudTrail insights **non controllerà eventi di scrittura** ad esempio).
|
||||
Nel primo esempio, viene fornito un selettore di eventi singolo come un array JSON con un singolo oggetto. Il `"ReadWriteType": "ReadOnly"` indica che il **selettore di eventi dovrebbe catturare solo eventi di sola lettura** (quindi CloudTrail insights **non controllerà eventi di scrittura**, ad esempio).
|
||||
|
||||
Puoi personalizzare il selettore di eventi in base alle tue esigenze specifiche.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## CloudWatch
|
||||
|
||||
**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.\
|
||||
**CloudWatch** **colleziona** dati di monitoraggio e operativi **sotto forma di log/metriche/eventi**, fornendo una **visione unificata delle risorse AWS**, delle applicazioni e dei servizi.\
|
||||
CloudWatch Log Event ha 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.
|
||||
|
||||
@@ -39,9 +39,9 @@ Le dimensioni sono coppie chiave-valore che fanno parte delle metriche. Aiutano
|
||||
|
||||
### Statistiche
|
||||
|
||||
Le statistiche sono calcoli matematici eseguiti sui dati delle metriche per riassumerli nel tempo. Le statistiche comuni includono Media, Somma, Minimo, Massimo e Conteggio dei campioni.
|
||||
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 la media dell'utilizzo della CPU su un periodo di un'ora.
|
||||
- **Esempio**: Calcolare l'utilizzo medio della CPU su un periodo di un'ora.
|
||||
|
||||
### Unità
|
||||
|
||||
@@ -53,37 +53,37 @@ Le unità sono il tipo di misura associato a una metrica. Le unità aiutano a fo
|
||||
|
||||
### Dashboard
|
||||
|
||||
**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.
|
||||
**CloudWatch Dashboards** 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 specifiche esigenze di monitoraggio.
|
||||
- **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.
|
||||
- Un'unica dashboard che mostra metriche chiave per l'intero ambiente AWS, incluse le istanze EC2, i database RDS e i bucket S3.
|
||||
|
||||
### Metric Stream e Dati Metrici
|
||||
|
||||
**I Metric Streams** 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 le dashboard personalizzate utilizzando strumenti al di fuori di AWS.
|
||||
**Metric Streams** 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 monitoraggio avanzato, analisi e dashboard personalizzati utilizzando strumenti al di fuori di AWS.
|
||||
|
||||
**I Dati Metrici** all'interno dei Metric Streams 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.
|
||||
**Dati Metrici** all'interno dei Metric Streams 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 la conservazione a lungo termine e la conformità.
|
||||
- Inviare metriche in tempo reale a un servizio di monitoraggio di terze parti per analisi avanzate.
|
||||
- Archiviare metriche in un bucket Amazon S3 per lo stoccaggio a lungo termine e la conformità.
|
||||
|
||||
### Allarme
|
||||
|
||||
**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.
|
||||
**CloudWatch Alarms** 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 l'allarme**: Il numero di periodi con una soglia raggiunta necessaria per attivare l'allarme.
|
||||
- **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**:
|
||||
@@ -92,7 +92,7 @@ Le unità sono il tipo di misura associato a una metrica. Le unità aiutano a fo
|
||||
|
||||
### Rilevatori di anomalie
|
||||
|
||||
**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.
|
||||
**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**:
|
||||
|
||||
@@ -101,33 +101,33 @@ Le unità sono il tipo di misura associato a una metrica. Le unità aiutano a fo
|
||||
|
||||
**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.
|
||||
- Rilevare modelli di utilizzo della CPU insoliti in un'istanza EC2 che potrebbero indicare una violazione della sicurezza o un problema dell'applicazione.
|
||||
|
||||
### Regole di Insight e Regole di Insight Gestite
|
||||
|
||||
**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 base alle quali devono essere intraprese azioni. Queste regole possono aiutarti a identificare anomalie o comportamenti insoliti nelle prestazioni e nell'utilizzo delle tue risorse.
|
||||
**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 sotto le quali 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.
|
||||
**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 soglie operative sicure, la regola può attivare un avviso o un'azione di mitigazione automatica.
|
||||
- Monitoraggio delle prestazioni 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 soglie operative sicure, la regola può attivare un avviso o un'azione di mitigazione automatica.
|
||||
|
||||
### CloudWatch Logs <a href="#cloudwatch-logs" id="cloudwatch-logs"></a>
|
||||
|
||||
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 Log Group) e possono essere esportati.
|
||||
|
||||
**Elementi**:
|
||||
|
||||
| **Log Group** | Una **collezione di flussi di log** che condividono le stesse impostazioni di retention, monitoraggio e controllo degli accessi |
|
||||
| Term | Definizione |
|
||||
| ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **Log Stream** | 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 log group, inviandoli a Kinesis Data Firehose stream, Kinesis stream o a una funzione Lambda |
|
||||
| **Log Group** | Una **collezione di log stream** che condividono le stesse impostazioni di retention, monitoraggio e controllo degli accessi |
|
||||
| **Log Stream** | Una sequenza di **eventi di log** che condividono la **stessa fonte** |
|
||||
| **Subscription Filters** | Definiscono un **modello di filtro che corrisponde agli eventi** in un particolare log group, inviandoli a Kinesis Data Firehose stream, Kinesis stream o a una funzione Lambda |
|
||||
|
||||
### Monitoraggio e Eventi di CloudWatch
|
||||
### CloudWatch Monitoring & Events
|
||||
|
||||
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 attivare uno.\
|
||||
In tal caso, CloudWatch può essere pronto a inviare un evento e intraprendere alcune azioni automatiche (funzioni AWS lambda, argomenti SNS, code SQS, Kinesis Streams)
|
||||
CloudWatch **base** aggrega i dati **ogni 5 minuti** (quella **dettagliata** 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, Kinesis Streams)
|
||||
|
||||
### Installazione dell'Agente
|
||||
|
||||
@@ -135,9 +135,9 @@ Puoi installare agenti all'interno delle tue macchine/contenitori per inviare au
|
||||
|
||||
- **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](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
|
||||
- **Configura** e **avvia** il CloudWatch Agent
|
||||
|
||||
Un log group ha molti flussi. Un flusso ha molti eventi. E all'interno di ciascun flusso, gli eventi sono garantiti in ordine.
|
||||
Un log group ha molti stream. Uno stream ha molti eventi. E all'interno di ogni stream, gli eventi sono garantiti in ordine.
|
||||
|
||||
## Enumerazione
|
||||
```bash
|
||||
@@ -216,7 +216,7 @@ aws events list-event-buses
|
||||
|
||||
### **`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 critici di prestazioni, 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.
|
||||
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 avvisi falsi 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.
|
||||
```bash
|
||||
@@ -227,7 +227,7 @@ aws cloudwatch put-composite-alarm --alarm-name <value> --alarm-rule <value> [--
|
||||
L'esempio seguente mostra come rendere inefficace un allarme metrico:
|
||||
|
||||
- Questo allarme metrico monitora l'utilizzo medio della CPU di una specifica istanza EC2, 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 punti dati per l'allarme a 8640, sarebbe necessario che l'utilizzo della CPU fosse superiore al 99% ogni 10 secondi per l'intero periodo di 24 ore per attivare un allarme.
|
||||
- Modificando la soglia per essere superiore al 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 punti dati per l'allarme a 8640, sarebbe necessario che l'utilizzo della CPU fosse superiore al 99% ogni 10 secondi per l'intero periodo di 24 ore per attivare un allarme.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Original Metric Alarm" }}
|
||||
@@ -285,7 +285,7 @@ L'esempio seguente mostra come rendere inefficace un allarme metrico:
|
||||
|
||||
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 allarmi per distrarre e confondere gli amministratori, o silenziare allarmi genuini per nascondere attività malevole in corso o gravi guasti di sistema.
|
||||
Inoltre, un attaccante con il permesso potrebbe manipolare gli stati di allerta, essendo in grado di creare falsi allarmi per distrarre e confondere gli amministratori, o silenziare allarmi genuini per nascondere attività malevole in corso o guasti critici del sistema.
|
||||
|
||||
- Se utilizzi **`SetAlarmState`** su un allarme composito, l'allarme composito non è garantito a tornare al suo stato effettivo. Torna al suo stato effettivo solo una volta che uno dei suoi allarmi figli cambia stato. Viene anche rivalutato se aggiorni la sua configurazione.
|
||||
```bash
|
||||
@@ -302,7 +302,7 @@ Un attaccante sarebbe in grado di compromettere la capacità di rilevare e rispo
|
||||
aws cloudwatch delete-anomaly-detector [--cli-input-json <value> | --namespace <value> --metric-name <value> --dimensions <value> --stat <value>]
|
||||
aws cloudwatch put-anomaly-detector [--cli-input-json <value> | --namespace <value> --metric-name <value> --dimensions <value> --stat <value> --configuration <value> --metric-characteristics <value>]
|
||||
```
|
||||
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.
|
||||
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.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Original Metric Anomaly Detector" }}
|
||||
@@ -323,7 +323,7 @@ L'esempio seguente mostra come rendere inefficace un rilevatore di anomalie metr
|
||||
```
|
||||
{{#endtab }}
|
||||
|
||||
{{#tab name="Rilevatore di Anomalie con Metriche Modificate" }}
|
||||
{{#tab name="Modified Metric Anomaly Detector" }}
|
||||
```json
|
||||
{
|
||||
"SingleMetricAnomalyDetector": {
|
||||
@@ -364,7 +364,7 @@ aws cloudwatch put-dashboard --dashboard-name <value> --dashboard-body <value>
|
||||
|
||||
### **`cloudwatch:DeleteInsightRules`, `cloudwatch:PutInsightRule`, `cloudwatch:PutManagedInsightRule`**
|
||||
|
||||
Le regole di insight vengono 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à dannose, portando a diagnosi errate e risposte inappropriate da parte del team operativo.
|
||||
Le regole di insight vengono utilizzate per rilevare anomalie, ottimizzare le prestazioni e gestire le risorse in modo efficace. Eliminando 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à dannose, portando a diagnosi errate e risposte inappropriate da parte del team operativo.
|
||||
```bash
|
||||
aws cloudwatch delete-insight-rules --rule-names <value>
|
||||
aws cloudwatch put-insight-rule --rule-name <value> --rule-definition <value> [--rule-state <value>]
|
||||
@@ -374,7 +374,7 @@ aws cloudwatch put-managed-insight-rules --managed-rules <value>
|
||||
|
||||
### **`cloudwatch:DisableInsightRules`, `cloudwatch:EnableInsightRules`**
|
||||
|
||||
Disabilitando regole di insight critiche, un attaccante potrebbe effettivamente rendere cieca 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.
|
||||
Disabilitando 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.
|
||||
```bash
|
||||
aws cloudwatch disable-insight-rules --rule-names <value>
|
||||
aws cloudwatch enable-insight-rules --rule-names <value>
|
||||
@@ -383,11 +383,11 @@ aws cloudwatch enable-insight-rules --rule-names <value>
|
||||
|
||||
### **`cloudwatch:DeleteMetricStream` , `cloudwatch:PutMetricStream` , `cloudwatch:PutMetricData`**
|
||||
|
||||
Un attaccante con i permessi **`cloudwatch:DeleteMetricStream`** , **`cloudwatch:PutMetricStream`** sarebbe in grado di creare e eliminare flussi di dati metrici, compromettendo la sicurezza, il monitoraggio e l'integrità dei dati:
|
||||
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**: Eliminando i flussi metrici, gli attaccanti interromperebbero il flusso continuo di dati di monitoraggio. In questo modo, le loro attività malevole sarebbero efficacemente nascoste.
|
||||
- **Manipolazione delle risorse**: La creazione di nuovi flussi metrici con dati eccessivi potrebbe produrre molto rumore, causando allarmi errati e 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.
|
||||
```bash
|
||||
|
||||
Reference in New Issue
Block a user