Registrazione SSH e gestione delle sessioni tramite AWS SSM

La configurazione di strumenti o script personalizzati per mantenere un registro SSH su Linux può essere noiosa e soggetta a errori.

Gli ingegneri possono utilizzare rootsh , screen o un'altra utilità per registrare l'attività dell'utente, ma se le autorizzazioni utente non sono impostate correttamente, un utente esperto può cancellare i registri di controllo per coprire le proprie tracce. Un'altra opzione sarebbe quella di impostare la registrazione a livello di kernel, ma l'esperienza necessaria per questo non è così comune.

Per fortuna, c'è un modo per registrare l'attività dell'utente senza scrivere nemmeno un singolo comando Linux! Avremo bisogno di questi servizi:

• EC2
• IAM (Gestione identità e accessi)
• Servizio di gestione delle chiavi (KMS)
• Log di CloudWatch (e/o S3)
• AWS Systems Manager (precedentemente noto come SSM)

Vediamo come impostare ciascuno di essi.

EC2 e IAM

L'avvio di un'istanza EC2 è normalmente abbastanza semplice, ma c'è un'attività chiave che deve essere eseguita durante l'avvio: dobbiamo allegare un ruolo IAM alla nostra istanza, altrimenti non saremo in grado di ottenere i risultati attesi dettagliati alla fine di questo articolo.

Il ruolo IAM che associamo alla nostra istanza EC2 deve avere la policy AmazonSSMManagedInstanceCore integrata , oltre a questa policy (allegata come inline o gestita dal cliente):

 { "Version": "2012-10-17", "Statement": [ { "Action": [ "logs:CreateLogStream", "logs:DescribeLogStreams", "logs:DescribeLogGroups", "logs:PutLogEvents" ], "Effect": "Allow", "Resource": "*" } ] }

A parte il ruolo IAM, generalmente utilizziamo questa configurazione dell'istanza EC2:

• Il sistema operativo è Amazon Linux 2, perché per impostazione predefinita viene fornito con AWS Systems Manager Agent (SSM Agent) installato. (Anche le distribuzioni Ubuntu, che sono anche un'opzione.)
• Il tipo di istanza è t3.micro (ma va bene qualsiasi tipo).
• Il gruppo di sicurezza predefinito assegnato da AWS al VPC funzionerà, poiché non è necessaria una porta SSH aperta per questo esercizio.

Possiamo iniziare a configurare KMS senza attendere l'avvio dell'istanza EC2.

KMS

Abbiamo bisogno di una chiave KMS se vogliamo che tutti i log di sessione consegnati a CloudWatch vengano archiviati crittografati. Andiamo al servizio KMS e creiamo una chiave.

Ti consigliamo di assegnare un amministratore in modo che la chiave possa essere gestita da utenti diversi dall'utente root dell'account AWS, ma se altri non avranno bisogno dell'accesso, possiamo saltare il passaggio 3.

Qui abbiamo scelto l'utente IAM "admin" come amministratore chiave, ma siamo liberi di scegliere qualsiasi utente o ruolo. Possiamo anche scegliere di disabilitare l'autorizzazione all'eliminazione della chiave per l'amministratore.

Non assegneremo alcun utente a questa chiave perché vogliamo che questa chiave venga utilizzata solo dal servizio CloudWatch Logs per le operazioni di crittografia e decrittografia dei log SSH.

Nella pagina Revisione, dovremo modificare la policy della chiave generata dal servizio di gestione delle chiavi perché non include le autorizzazioni per CloudWatch Logs per utilizzare la chiave. Lo sostituiremo con questa politica:

 { "Version": "2012-10-17", "Statement": [ { "Sid": "Enable IAM User Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT_ID:root" }, "Action": "kms:*", "Resource": "*" }, { "Sid": "Allow access for Key Administrators", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT_ID:user/USERNAME" }, "Action": [ "kms:Create*", "kms:Describe*", "kms:Enable*", "kms:List*", "kms:Put*", "kms:Update*", "kms:Revoke*", "kms:Disable*", "kms:Get*", "kms:Delete*", "kms:TagResource", "kms:UntagResource", "kms:ScheduleKeyDeletion", "kms:CancelKeyDeletion" ], "Resource": "*" }, { "Sid": "Allow access to CloudWatch Log", "Effect": "Allow", "Principal": { "Service": "logs.REGION.amazonaws.com" }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "*", "Condition": { "ArnLike": { "kms:EncryptionContext:aws:logs:arn": "arn:aws:logs:REGION:ACCOUNT_ID:*" } } } ] }

Assicurati di sostituire tutti i segnaposto:

• ACCOUNT_ID diventa il nostro ID account AWS.
• USERNAME diventa il nome utente dell'amministratore selezionato nel passaggio 3. Se abbiamo rinunciato a tale passaggio, qui rimuoviamo il secondo blocco di istruzioni (quello con "Sid": "Allow access for Key Administrators" ).
• REGION diventa il codice identificativo regionale a cui stiamo distribuendo i servizi (ad esempio, us-west-1 ).

Con ciò, KMS è pronto per l'uso.

Gruppo di log CloudWatch

Successivamente abbiamo bisogno di un gruppo CloudWatch Log (e/o un bucket S3, vedi sotto) in cui l'agente SSM può inviare i log di sessione SSH. Creiamolo.

Nota il campo ARN della chiave del servizio di gestione delle chiavi: AWS ci fornisce il valore necessario qui dopo la creazione della chiave nel passaggio 5 della sezione del servizio di gestione delle chiavi.

(Se in precedenza non abbiamo associato la policy corretta alla nostra chiave KMS, consentendo al servizio CloudWatch Logs di utilizzare la chiave, a questo punto riceveremo un errore relativo alla chiave KMS.)

 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::BUCKET_NAME/*" }, { "Effect": "Allow", "Action": [ "s3:GetEncryptionConfiguration" ], "Resource": "*" }, { "Effect": "Allow", "Action": "kms:GenerateDataKey", "Resource": "*" } ] }

Ora che abbiamo configurato un punto in cui archiviare i log, CloudWatch Logs, un bucket S3 o entrambi, siamo pronti per attingere alle sessioni SSH.

Gestore di sessione di AWS Systems Manager

Questo è il passaggio chiave finale, in cui configuriamo l'accesso sicuro alla nostra macchina Linux per il monitoraggio e la registrazione delle sessioni SSH. Inizieremo dalla dashboard di Session Manager.

Nella dashboard, fai clic sul pulsante bianco "Configura preferenze" nella casella in alto a destra "Avvia una sessione" per abilitare la registrazione della sessione.

Nella pagina Preferenze, troveremo più sezioni che potremmo esplorare, ma il nostro obiettivo sarà lo streaming dei log di sessione SSH su CloudWatch o S3 per consentirci di vedere rapidamente cosa sta succedendo all'interno della nostra macchina Linux.

Subito dopo la sezione "Registrazione di CloudWatch", c'è una sezione "Registrazione S3" in cui possiamo selezionare il bucket.

Una volta configurata la registrazione SSH, possiamo eseguire SSH nella nostra macchina Linux ed eseguire alcuni comandi per vedere se l'attività viene acquisita o meno.

Quindi, iniziamo una sessione. Nella stessa pagina, troveremo una scheda "Sessioni" in cui possiamo iniziare una sessione. Facendo clic sul pulsante "Avvia sessione" verrà visualizzato un elenco di macchine EC2 su cui è possibile avviare una sessione:

Se non vediamo la nostra istanza EC2 Linux nell'elenco, dovremmo controllare se è in uno stato di esecuzione e ha le autorizzazioni IAM associate che abbiamo descritto in precedenza.

Gestione di un agente SSM Errore "Non supporta lo streaming dei registri".

Nel caso in cui riceviamo un errore che dice che la versione dell'agente SSM installata sulla nostra macchina EC2 non supporta lo streaming dei log CloudWatch, non preoccuparti. C'è un modo indolore per risolvere questo problema.

Per aggiornare l'agente SSM, dobbiamo passare a Run Command nel pannello di sinistra del servizio AWS Systems Manager .

Una volta che siamo lì, possiamo fare clic sul pulsante arancione "Esegui un comando", che porta a una nuova pagina in cui possiamo inserire alcuni parametri.

Inizieremo selezionando AWS-UpdateSSMAgent dall'elenco.

Una volta selezionato, scorreremo verso il basso fino a visualizzare la sezione "Obiettivi". Lì dobbiamo selezionare l'istanza EC2 su cui vogliamo aggiornare l'agente SSM, quindi premere il pulsante "Esegui" alla fine. Questo ci invierà a una pagina in cui possiamo monitorare lo stato di avanzamento dell'aggiornamento.

L'aggiornamento dell'agente non dovrebbe richiedere più di cinque minuti. Una volta fatto, dovremmo essere in grado di creare una sessione di nuovo in Session Manager.

A questo punto, dovremmo avviare una sessione SSH.

Dopo aver eseguito alcuni comandi, andiamo al gruppo di log di CloudWatch Logs (o al nostro bucket S3, non mostrato) e confermiamo che l'attività è in corso di registrazione.

Ora abbiamo una configurazione, con la crittografia a riposo abilitata, che registra ogni comando eseguito nella nostra macchina Linux.

Ogni comando, infatti, potrebbe essere più di quello che vogliamo: eventuali secret forniti o generati durante la sessione verranno registrati in CloudWatch o S3 e potranno essere visti da chiunque abbia i permessi richiesti. Per evitarlo, possiamo usare stty -echo; read passwd; stty echo; stty -echo; read passwd; stty echo; per ogni segreto che dobbiamo fornire durante la sessione.

Un'ottima soluzione di registrazione AWS SSM/SSH con piccoli avvertimenti

Session Manager è uno strumento utile per ottenere l'accesso remoto alle nostre macchine virtuali in AWS senza dover aprire la porta 22. Infatti, non possiamo generare log SSH in questo modo se utilizziamo il port forwarding o una connessione SSH diretta, come Session Manager note di documentazione.

Tuttavia, la combinazione di Session Manager con la registrazione delle sessioni è una soluzione affidabile per il controllo e il monitoraggio dell'attività all'interno delle macchine virtuali. Inoltre, non ci viene addebitato l'utilizzo del servizio Session Manager. Paghiamo solo per la nostra istanza EC2 e CloudWatch Logs o un bucket S3 per l'archiviazione dei log.

Per i lettori che preferiscono i tutorial video, ho trattato un po' più a fondo una procedura molto simile su YouTube.

Ulteriori letture sul blog di Toptal Engineering:

• Caso di studio: perché utilizzo l'infrastruttura cloud AWS per i miei prodotti