Best practice per l'aggiornamento delle macchine Ubuntu EC2

12

A seguito della recente vulnerabilità al cuore di OpenSSL, vorrei mantenere le mie macchine EC2 aggiornate regolarmente. L'approccio ingenuo consisterebbe nell'impostare un cron job orario per gli aggiornamenti di sicurezza ( sudo apt-get update && sudo unattended-upgrade).

Ci sono dei rischi nel farlo? Esiste un meccanismo di aggiornamento consigliato per le macchine EC2?

unattended-upgrades

— Adam Matan
fonte

13

Il pacchetto di aggiornamenti automatici è il modo standard per applicare automaticamente importanti correzioni di errori e patch di sicurezza in Ubuntu.

Consiglio di installarlo su ogni sistema Ubuntu:

sudo apt-get update &&
sudo apt-get install unattended-upgrades

Non è necessario creare il proprio cron job. Il pacchetto ne installa uno per te.

È possibile modificare la configurazione predefinita se si desidera modificarne il comportamento: https://help.ubuntu.com/lts/serverguide/automatic-updates.html

— Eric Hammond
fonte

Qualche idea sull'opportunità di farlo su un server di produzione? Mi rende nervoso applicare le modifiche in modo silenzioso e rischiare la possibilità che l'aggiornamento non riesca o presenti problemi.

— ianjs,

3

Per "ogni" intendevo anche sistemi di produzione. Sto applicando automaticamente le patch di sicurezza di Ubuntu da molti anni e non ricordo alcun problema serio. Mi rende nervoso avere un server di produzione seduto lì senza patch per problemi di sicurezza noti e rischiare la possibilità di sfruttarli. Detto questo, ogni situazione ha esigenze diverse, quindi potresti essere meglio passare attraverso una fase di test rigorosa per ogni patch. Tieni presente, tuttavia, che vengono rilasciati continuamente, quindi sarai occupato.

— Eric Hammond,

1

Non lo consiglio a meno che non si disponga di una configurazione ridondante / cluster. Le procedure di aggiornamento di Ubuntu non sono all'altezza, ho interrotto i servizi più volte e di recente anche un settore di avvio interrotto ... E non facciamo nulla di speciale - solo Apache come proxy inverso e applicazioni Tomcat.

— raddoppiato il

1

Usiamo unattended-upgradesdal 2015 al 2020 senza problemi. Abbiamo una piccola configurazione (su DigitalOcean) con:

nginx
mysql-server
php5-fpm php5-curl php5-mysql

Basato su buone prestazioni passate, fare gli aggiornamenti in questo modo sembra più sicuro che non farlo. Ma questa non è necessariamente una garanzia per il futuro!

Potrebbe non essere una buona idea apache, in base ai rapporti di altri utenti e alla mia esperienza passata di apacheaggiornamenti. [Vedi sopra, e qui ]

Con unattended-upgrades, l'intervento manuale sarà ancora richiesto quando il rilascio si avvicina a EOL .

(A parte la domanda: nella mia esperienza con TWiki, WordPress e Jenkins, mantenere queste app aggiornate è in realtà una preoccupazione maggiore rispetto al sistema operativo stesso, anche se ovviamente dovremmo davvero fare entrambe le cose. Per la tranquillità, è possibile eseguire il sandboxing di app rivolte a Internet come processi non root in esecuzione all'interno di un contenitore Docker.)

Ma poiché hai chiesto informazioni sulle migliori pratiche , l'approccio principale raccomandato nella documentazione di AWS è:

Crea e avvia nuove istanze per sostituire le tue attuali istanze online. Quindi eliminare le istanze correnti.

Le nuove istanze avranno installato l'ultimo set di patch di sicurezza durante l'installazione.

(Febbraio 2020)

Questo può essere fatto come parte di una strategia di distribuzione blu-verde . Il vantaggio qui è che puoi eseguire test sul tuo nuovo server prima di passare il traffico. Se i test sono accurati, in teoria i tuoi aggiornamenti possono essere completamente automatizzati, verificati prima di essere pubblicati e senza tempi di inattività.

Altri vantaggi:

I test possono darti un avviso avanzato se è necessaria l'attenzione umana (al contrario unattended-upgrades, quando gli avvisi arrivano dai tuoi utenti solo quando il problema è vivo!)
Se il tuo sistema viene compromesso o decidi di cambiare provider, questo approccio dovrebbe semplificare l'implementazione di una nuova distribuzione. La tua strategia di distribuzione è basata su script, piuttosto che memoria antica.

Naturalmente, per questo approccio sono necessarie più impostazioni rispetto alla semplice installazione unattended-upgradese una maggiore complessità, quindi c'è ancora spazio per gli errori.

AWS menziona anche l'esecuzione del "comando stack Dipendenze aggiornamento", che sembra essere il loro modo ufficiale di fare qualcosa di simile unattended-upgrades. Sembra che possa essere attivato dall'interfaccia delle loro istanze, ma non sono sicuro che possa essere automatizzato.

— joeytwiddle
fonte