Translated ['src/pentesting-cloud/aws-security/aws-basic-information/REA

This commit is contained in:
Translator
2025-02-11 17:15:35 +00:00
parent eb8a4062d7
commit 11a5e8184f
29 changed files with 184 additions and 170 deletions

View File

@@ -10,7 +10,7 @@ Ogni evento registrato contiene:
- Il nome dell'API chiamata: `eventName`
- Il servizio chiamato: `eventSource`
- L'ora: `eventTime`
- Il tempo: `eventTime`
- L'indirizzo IP: `SourceIPAddress`
- Il metodo dell'agente: `userAgent`. Esempi:
- Signing.amazonaws.com - Dalla Console di gestione AWS
@@ -55,7 +55,7 @@ Tuttavia, anche se puoi salvare tutti i log nello stesso bucket S3, non puoi agg
### Cloudtrail da tutti gli account org in 1
Quando crei un CloudTrail, è possibile indicare di attivare CloudTrail per tutti gli account nell'org e ottenere i log in un solo bucket:
Quando crei un CloudTrail, è possibile indicare di attivare cloudtrail per tutti gli account nell'org e ottenere i log in un solo bucket:
<figure><img src="../../../../images/image (200).png" alt=""><figcaption></figcaption></figure>
@@ -185,9 +185,9 @@ Controlla ulteriori informazioni nella [**ricerca originale**](https://medium.co
#### Non generare un log
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**.
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 di attaccante. Questo farà sì che **CloudTrail generi un log all'interno del TUO account AWS e non all'interno 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**.
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 è un Honeytoken**.
#### Servizi AWS senza log
@@ -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:
@@ -244,12 +244,12 @@ Puoi personalizzare il selettore di eventi in base alle tue esigenze specifiche.
```bash
aws s3api put-bucket-lifecycle --bucket <bucket_name> --lifecycle-configuration '{"Rules": [{"Status": "Enabled", "Prefix": "", "Expiration": {"Days": 7}}]}' --region <region>
```
### Modificare la Configurazione del Bucket
### Modifica della Configurazione del Bucket
- Eliminare il bucket S3
- Modificare la policy del bucket per negare qualsiasi scrittura dal servizio CloudTrail
- Aggiungere una policy di lifecycle al bucket S3 per eliminare gli oggetti
- Disabilitare la chiave kms utilizzata per crittografare i log di CloudTrail
- Elimina il bucket S3
- Cambia la policy del bucket per negare qualsiasi scrittura dal servizio CloudTrail
- Aggiungi una policy di lifecycle al bucket S3 per eliminare gli oggetti
- Disabilita la chiave kms utilizzata per crittografare i log di CloudTrail
### Ransomware Cloudtrail
@@ -264,7 +264,7 @@ Questo è fondamentalmente un **ransomware S3-KMS** spiegato in:
**Ransomware KMS**
Questo è un modo più semplice per eseguire l'attacco precedente con requisiti di autorizzazione diversi:
Questo è il modo più semplice per eseguire l'attacco precedente con requisiti di autorizzazione diversi:
{{#ref}}
../../aws-post-exploitation/aws-kms-post-exploitation.md

View File

@@ -41,21 +41,21 @@ Le dimensioni sono coppie chiave-valore che fanno parte delle metriche. Aiutano
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.
- **Esempio**: Calcolare la media dell'utilizzo della CPU su un periodo di un'ora.
### Unità
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.
- **Esempio**: CPUUtilization potrebbe essere misurata in Percentuale, mentre NetworkIn potrebbe essere misurata in Byte.
## Funzionalità di CloudWatch
## Caratteristiche di CloudWatch
### Dashboard
**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**:
**Caratteristiche chiave**:
- **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.
@@ -66,14 +66,14 @@ Le unità sono il tipo di misura associato a una metrica. Le unità aiutano a fo
### Metric Stream e Dati Metrici
**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.
**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 dashboard personalizzati utilizzando strumenti al di fuori di 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 analisi avanzate.
- Archiviare metriche in un bucket Amazon S3 per lo stoccaggio a lungo termine e la conformità.
- 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à.
### Allarme
@@ -107,11 +107,11 @@ Le unità sono il tipo di misura associato a una metrica. Le unità aiutano a fo
**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.
**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**:
- 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.
- 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 l'I/O del disco. Se una di queste metriche supera soglie operative sicure, la regola può attivare un avviso o un'azione di mitigazione automatizzata.
### CloudWatch Logs <a href="#cloudwatch-logs" id="cloudwatch-logs"></a>
@@ -122,18 +122,18 @@ Consente di **aggregare e monitorare i log delle applicazioni** e dei sistemi da
| ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **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 |
| **Subscription Filters** | Definiscono un **modello di filtro che corrisponde agli eventi** in un particolare log group, inviandoli a un flusso Kinesis Data Firehose, a un flusso Kinesis o a una funzione Lambda |
### CloudWatch Monitoring & Events
### Monitoraggio e Eventi di CloudWatch
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)
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)
### Installazione dell'Agente
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)
- **Crea** un **ruolo** e **allega** ad esso l'**istanza** con permessi che consentono 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** il CloudWatch Agent
@@ -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 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.
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.
```bash
@@ -254,7 +254,7 @@ L'esempio seguente mostra come rendere inefficace un allarme metrico:
```
{{#endtab }}
{{#tab name="Allerta metrica modificata" }}
{{#tab name="Modified Metric Alarm" }}
```json
{
"Namespace": "AWS/EC2",
@@ -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 guasti critici del 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 gravi guasti di 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
@@ -293,11 +293,11 @@ aws cloudwatch disable-alarm-actions --alarm-names <value>
aws cloudwatch enable-alarm-actions --alarm-names <value>
aws cloudwatch set-alarm-state --alarm-name <value> --state-value <OK | ALARM | INSUFFICIENT_DATA> --state-reason <value> [--state-reason-data <value>]
```
**Impatto Potenziale**: Mancanza di notifiche per eventi critici, potenziali problemi non rilevati, falsi allarmi, soppressione di allarmi genuini e potenzialmente rilevamenti mancati di incidenti reali.
**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 configurare in modo errato o creare falsi positivi per distrarre o sopraffare il monitoraggio.
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.
```bash
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>]
@@ -323,7 +323,7 @@ L'esempio seguente mostra come rendere inefficace un rilevatore di anomalie metr
```
{{#endtab }}
{{#tab name="Modified Metric Anomaly Detector" }}
{{#tab name="Rilevatore di Anomalie con Metriche Modificate" }}
```json
{
"SingleMetricAnomalyDetector": {