Linee guida per le AMI Linux condivise

Utilizza le linee guida seguenti per ridurre la superficie di attacco e migliorare l'affidabilità delle AMI create.

Importante

Nessun elenco delle linee guida di sicurezza può essere esaustivo. Crea le tue AMI condivise con attenzione considerando in quale posizione potresti esporre dati sensibili.

Se stai creando AMI per Marketplace AWS, consulta le migliori pratiche per la creazione di AMI nella Guida per il Marketplace AWS venditore per le linee guida, le politiche e le migliori pratiche.

Per ulteriori informazioni sulla condivisione sicura delle AMI, consulta gli articoli seguenti:

• Articolo relativo alla condivisione e all'utilizzo sicuri delle AMI pubbliche

• Articolo relativo ai requisiti di pulizia e ai controlli di base per la pubblicazione delle AMI pubbliche

Aggiornare gli Strumenti AMI prima di usarli

Per le AMI supportate da instance store, ti consigliamo di scaricare e aggiornare gli strumenti di creazione delle AMI Amazon EC2 prima di usarli. In questo modo, le nuove AMI basate sulle AMI condivise disporranno degli strumenti AMI più recenti.

Per Amazon Linux 2, installare il pacchetto aws-amitools-ec2 e aggiungere gli strumenti AMI al PATH con il seguente comando. Per Amazon Linux AMI, aws-amitools-ec2 il pacchetto è già stato installato per impostazione predefinita.

[ec2-user ~]$ sudo yum install -y aws-amitools-ec2 && export PATH=$PATH:/opt/aws/bin > /etc/profile.d/aws-amitools-ec2.sh && . /etc/profile.d/aws-amitools-ec2.sh

Aggiorna gli strumenti AMI con il comando seguente:

[ec2-user ~]$ sudo yum upgrade -y aws-amitools-ec2

Per altre distribuzioni, assicurati di disporre degli strumenti AMI più recenti.

Disabilitazione degli accessi remoti basati su password per l'utente root

L'uso di una password root fissa per le AMI pubbliche rappresenta un rischio per la sicurezza che può diventare noto rapidamente. Anche fare affidamento sul fatto che gli utenti modifichino la password dopo il primo accesso lascia aperta una piccola possibilità di potenziali usi illeciti.

Per risolvere questo problema, disabilita gli accessi remoti basati su password per l'utente root.

Per disabilitare gli accessi remoti basati su password per l'utente root

1. Aprire il file /etc/ssh/sshd_config con un editor di testo e individuare la riga seguente:

   #PermitRootLogin yes

2. Modificare la riga in:

   PermitRootLogin without-password

   Il percorso di questo file di configurazione potrebbe essere diverso a seconda della distribuzione o se OpenSSH non è in esecuzione. In questo caso, consultare la relativa documentazione.

Disabilitazione dell'accesso root locale

Quando utilizzi AMI condivise, ti consigliamo, come best practice, di disabilitare gli accessi root diretti. Per farlo, accedi all'istanza in esecuzione ed esegui il comando seguente:

[ec2-user ~]$ sudo passwd -l root

Nota

Questo comando non ha alcun impatto sull'uso di sudo.

Rimozione delle coppie di chiavi dell'host SSH

Se intendi condividere un'AMI derivata da un'AMI pubblica, rimuovi le coppie di chiavi dell'host SSH esistenti posizionate in /etc/ssh. Ciò costringe SSH a generare nuove coppie di chiavi SSH uniche quando qualcuno avvia un'istanza utilizzando la tua AMI, migliorando la sicurezza e riducendo la probabilità di attacchi "». man-in-the-middle

Rimuovi tutti i file di chiave seguenti presenti sul sistema.

• ssh_host_dsa_key

• ssh_host_dsa_key.pub

• ssh_host_key

• ssh_host_key.pub

• ssh_host_rsa_key

• ssh_host_rsa_key.pub

• ssh_host_ecdsa_key

• ssh_host_ecdsa_key.pub

• ssh_host_ed25519_key

• ssh_host_ed25519_key.pub

Puoi rimuovere in sicurezza tutti questi file con il comando seguente.

[ec2-user ~]$ sudo shred -u /etc/ssh/*_key /etc/ssh/*_key.pub

avvertimento

Le utilità di eliminazione sicura, come shred, potrebbero non rimuovere tutte le copie di un file dai supporti di archiviazione. I file system di journaling (tra cui il file system ext4 predefinito di Amazon Linux), snapshot, backup, RAID e la cache temporanea potrebbero creare delle copie nascoste dei file. Per ulteriori informazioni, consulta la documentazione di shred.

Importante

Se dimentichi di rimuovere le coppie di chiavi dell'host SSH esistenti dall'AMI pubblica, il nostro processo di controllo di routine invia una notifica a te e a tutti gli utenti che eseguono le istanze della tua AMI informandovi del potenziale rischio per la sicurezza. Dopo un breve periodo di tolleranza, contrassegneremo l'AMI come privata.

Installazione delle credenziali di chiave pubblica

Dopo aver configurato l'AMI per impedire l'accesso tramite password, devi assicurarti che gli utenti possano accedervi mediante un altro meccanismo.

Amazon EC2 consente agli utenti di specificare un nome di coppia di chiavi pubblica-privata al momento dell'avvio dell'istanza. Se viene specificato un nome della coppia di chiavi valido alla chiamata API RunInstances (o tramite gli strumenti API della riga di comando), la chiave pubblica (la porzione della coppia di chiavi che Amazon EC2 conserva sul server in seguito alla chiamata a CreateKeyPair o a ImportKeyPair) viene resa disponibile per l'istanza tramite una query HTTP sui metadati dell'istanza.

Per accedere tramite SSH, l'AMI deve recuperare il valore di chiave al momento dell'avvio e aggiungerlo a /root/.ssh/authorized_keys (o all'equivalente per gli altri account utente sull'AMI). Gli utenti possono avviare le istanze dell'AMI con una coppia di chiavi e accedere senza bisogno di una password root.

Molte distribuzioni, tra cui Amazon Linux e Ubuntu, utilizzano il pacchetto cloud-init per inserire le credenziali di chiave pubblica per un utente configurato. Se la distribuzione in uso non supporta cloud-init, puoi aggiungere il codice seguente a uno script di avvio del sistema (come /etc/rc.local) per inserire la chiave pubblica specificata al momento dell'avvio per l'utente root.

Nota

Nell'esempio seguente, l'indirizzo IP http://169.254.169.254/ è un indirizzo locale del collegamento ed è valido solo dall'istanza.

IMDSv2

if [ ! -d /root/.ssh ] ; then
        mkdir -p /root/.ssh
        chmod 700 /root/.ssh
fi
# Fetch public key using HTTP
TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key > /tmp/my-key
if [ $? -eq 0 ] ; then
        cat /tmp/my-key >> /root/.ssh/authorized_keys
        chmod 700 /root/.ssh/authorized_keys
        rm /tmp/my-key
fi

IMDSv1

if [ ! -d /root/.ssh ] ; then
        mkdir -p /root/.ssh
        chmod 700 /root/.ssh
fi
# Fetch public key using HTTP
curl http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key > /tmp/my-key
if [ $? -eq 0 ] ; then
        cat /tmp/my-key >> /root/.ssh/authorized_keys
        chmod 700 /root/.ssh/authorized_keys
        rm /tmp/my-key
fi

Questa procedura è applicabile a tutti gli utenti e non è necessario limitarla all'utente root.

Nota

Il nuovo raggruppamento di un'istanza basata su tale AMI include la chiave con la quale è stata avviata. Per impedire l'inclusione della chiave, è necessario eliminare il file authorized_keys o escluderlo dal nuovo raggruppamento.

Disabilitazione dei controlli DNS sshd (facoltativo)

La disabilitazione dei controlli DNS sshd indebolisce leggermente la sicurezza sshd. Tuttavia, in caso di errori della risoluzione DNS, gli accessi SSH continueranno a funzionare. Se non disabiliti i controlli sshd, gli errori della risoluzione DNS impediranno tutti gli accessi.

Per disabilitare i controlli DNS sshd

1. Aprire il file /etc/ssh/sshd_config con un editor di testo e individuare la riga seguente:

   #UseDNS yes

2. Modificare la riga in:

   UseDNS no

Nota

Il percorso di questo file di configurazione può essere diverso a seconda della distribuzione o se OpenSSH non è in esecuzione. In questo caso, consultare la relativa documentazione.

Protezione dell'utente

Ti sconsigliamo di archiviare dati sensibili o software sulle AMI che condividi. Gli utenti che avviano un'AMI condivisa potrebbero ricompilarla e registrarla come di loro proprietà. Segui queste linee guida per evitare rischi della sicurezza spesso sottovalutati:

• Ti consigliamo di utilizzare l'opzione --exclude directory su ec2-bundle-vol per saltare le directory e le sottodirectory contenenti informazioni segrete che non desideri includere nel bundle. In particolare, escludi tutte le coppie di chiavi SSH pubbliche/private di proprietà dell'utente e i file authorized_keys SSH durante il raggruppamento dell'immagine. Le AMI pubbliche di Amazon archiviano questi elementi in /root/.ssh per l'utente root e in /home/user_name/.ssh/ per gli utente normali. Per ulteriori informazioni, consulta ec2-bundle-vol.

• Elimina sempre la cronologia della shell prima di effettuare il raggruppamento. Se tenti di effettuare più di un caricamento del bundle nella stessa AMI, la cronologia di shell (interprete di comandi) conterrà la tua chiave di accesso. L'esempio seguente riporta l'ultimo comando eseguito prima del raggruppamento effettuato dall'istanza.

  [ec2-user ~]$ shred -u ~/.*history

  avvertimento

  Le limitazioni dell'utilità shred descritte nell'avviso riportato sopra si applicano anche in questo caso.

  Tieni presente che bash scrive la cronologia della sessione corrente sul disco al momento dell'uscita. Se ti disconnetti dall'istanza dopo avere eliminato ~/.bash_history e ripeti l'accesso, scoprirai che ~/.bash_history è stato ricreato e contiene tutti i comandi eseguiti durante la sessione precedente.

  Oltre a bash, anche altri programmi scrivono la cronologia sul disco; presta attenzione e rimuovi o escludi i file e le directory dot non necessari.

• Il raggruppamento di un'istanza in esecuzione richiede la chiave privata e il certificato X.509. Inserisci queste e altre credenziali in un percorso non incluso nel bundle (come l'instance store).