"Aggiornamento yum" automatizzato per proteggere il server - pro e contro?


8

Sto pensando di aggiungere un cronjob in esecuzione yum -qy updatesu base regolare su alcune macchine che non ricevono una manutenzione regolare. L'obiettivo sarebbe quello di mantenere aggiornate le macchine per quanto riguarda le patch di sicurezza che altrimenti verrebbero applicate troppo tardi. Sto usando solo i repository di base CentOS.

Domande:

  • Nella tua esperienza, quanto "sicuro" sarebbe questo approccio? Dovrei aspettarmi aggiornamenti non riusciti di tanto in tanto? Circa quanto spesso questo approccio richiederebbe il riavvio?
  • Pro / contro o altri aspetti positivi di questo approccio?
  • Come si aggiornano le macchine utilizzando l'automazione?

2
sostituisci yum -qy con: / usr / bin / yum -R 120 -e 0 -d 0 -y aggiorna yum AND / usr / bin / yum -R 10 -e 0 -d 0 -y aggiorna
Adam Benayoun

Adam: Grazie per il tuo suggerimento. Potresti spiegare perché è meglio?
Knorv,

1
Prima aggiorni yum e poi aggiorni i pacchetti, -R significa che dà il massimo tempo di attesa del comando, il che significa che non scadrà se ho ragione. il -e e -d sono solo a livello di errore / debug
Adam Benayoun,

Non sono sicuro di "-R [tempo in minuti]" - "imposta il tempo massimo che yum attenderà prima di eseguire un comando - si randomizza nel tempo". Sembra che yum attenderà rand () * minuti prima di emettere un comando? Quello è buono? :-)
knorv

Risposte:


6

Dipende

Nella mia esperienza con CentOS è abbastanza sicuro poiché stai usando solo i repository di base CentOS.

Dovresti aspettarti aggiornamenti non riusciti di tanto in tanto ... sì ... allo stesso livello in cui dovresti aspettarti un disco rigido guasto o una CPU guasta di tanto in tanto. Non puoi mai avere troppi backup. :-)

La cosa bella degli aggiornamenti automatici è che vieni patchato (e quindi più sicuro) più velocemente di farlo manualmente.

Le patch manuali sembrano sempre essere spinte via o considerate come "bassa priorità" per tante altre cose, quindi se vuoi andare in modalità manuale TEMPO PROGRAMMAZIONE SUL CALENDARIO per farlo.

Ho configurato molte macchine per eseguire udpate auto yum (tramite cron job) e raramente ho avuto un problema. In effetti, non ricordo di aver mai avuto problemi con i repository BASE. Ogni problema che mi viene in mente (dalla parte superiore della mia testa, nella mia esperienza) è sempre stata una situazione di terze parti.

Detto questo ... Ho diverse macchine per le quali FACCIO MANUALMENTE gli aggiornamenti. Cose come i server di database e altri sistemi estremamente critici mi piace avere un approccio "pratico".

Il modo in cui l'ho capito personalmente è stato così ... Penso allo scenario "what if" e quindi provo a pensare a quanto tempo sarebbe necessario per ricostruire o ripristinare da un backup e cosa (se non altro) andrebbe perso .

Nel caso di più server Web ... o server il cui contenuto non cambia molto ... Vado avanti e faccio l'aggiornamento automatico perché il tempo necessario per ricostruire / ripristinare è minimo.

Nel caso di server di database critici, ecc ... Pianifico il tempo una volta alla settimana per esaminarli e correggerli manualmente ... perché il tempo impiegato per ricostruire / ripristinare richiede più tempo.

A seconda dei server che hai nella tua rete e di come viene implementato il tuo piano di backup / ripristino, le tue decisioni potrebbero essere diverse.

Spero che sia di aiuto.


6

Pro : il tuo server è sempre all'ultimo livello di patch, di solito anche contro exploit di 0 giorni.

Contro : qualsiasi codice in esecuzione sul tuo server che utilizza funzionalità rimosse nelle versioni successive, qualsiasi file di configurazione che modifica la sintassi e qualsiasi nuova "funzionalità" di sicurezza che impedisce l'esecuzione di codice che può essere sfruttato può causare l'interruzione senza di te delle cose in esecuzione su quel server sapendo fino a quando qualcuno ti chiama per un problema.

Procedura consigliata: chiedere al server di inviare un'e-mail quando deve essere aggiornato. Eseguire il backup o sapere come ripristinare gli aggiornamenti.


+1 - Consiglio vivamente di iscriversi alla mailing list di centos, fanno un ottimo lavoro nel spingere avvisi su patch e priorità prima di essere inviati ai repository.
Adam Benayoun,

3
Non ci sono patch contro exploit di 0 giorni, per definizione. Un exploit di 0 giorni è uno per il quale non esiste ancora una patch.
Mark R

Considero 0-day il giorno in cui viene scoperto / sfruttato / annunciato, e Redhat di solito corregge gravi vulnerabilità entro poche ore - che, per coincidenza, è ancora durante il giorno in cui è stato scoperto.
Karl Katzke,

2

Oltre a ciò che la maggior parte delle persone dice qui, consiglio vivamente di iscriversi alla mailing list di centos, pubblicano sempre e-mail sulle patch e sulle loro priorità prima di inviarle ai repository. È utile sapere in anticipo quali pacchetti devono essere aggiornati.

La mia configurazione consente a yum di aggiornare automaticamente il sistema una volta al giorno, faccio in modo che yum mi invii una mail con i pacchetti installati o aggiornati subito dopo. Ricevo anche posta quando yum ha un conflitto e ho bisogno di un intervento manuale (ogni 4 ore).

Fino ad ora, tutto funziona senza intoppi (da oltre 4 anni), l'unica volta che sono stato colto di sorpresa è stato quando yum ha aggiornato il kernel normale (ho virtualizzato il mio server) e ha cambiato il grub e ha spinto il kernel normale come predefinito, 2 settimane più tardi durante la manutenzione il mio sistema è stato riavviato e tutti i miei server virtuali sono stati disattivati ​​per alcuni minuti fino a quando non ho dovuto intervenire manualmente.

A parte questo, non ho davvero avuto problemi.


1

fintanto che non si dispone di pacchetti personalizzati e si utilizzano solo i repository Base di CentOS, dovrebbe essere abbastanza sicuro.

inoltre, un modo migliore per raggiungere questo obiettivo sarebbe usare yum-updatesd con do_update = yesset.


1
Il servizio yum-updatesd non è abbastanza maturo per un ambiente aziendale e il servizio potrebbe introdurre spese generali non necessarie. Userei: / usr / bin / yum -R 120 -e 0 -d 0 -y aggiorna yum AND / usr / bin / yum -R 10 -e 0 -d 0 -y aggiorna
Adam Benayoun

0

Suppongo che fintanto che si dispone di backup automatici non sarebbe un problema, a condizione che si possa vivere con i tempi di inattività del server.

Non ho provato questo; Non vorrei personalmente perché c'è un rischio significativo di rompere qualcosa o avere un insolito problema oscuro introdotto a causa di una correzione a monte. È ancora peggio se questo è un server che raramente attira l'attenzione, quindi se qualcosa va storto potresti non saperlo.

Se riesci a convivere con il server in questione per un periodo di tempo inattivo se / quando qualcosa si rompe, e hai un piano di risposta per ripristinare il sistema allo stato precedente e un sistema per inviarti aggiornamenti tramite registri o e-mail riportando quando e cosa è stato aggiornato (quindi sai che non è in uno stato bloccato o in attesa di una risposta a qualcosa che richiede un intervento) quindi puoi provarlo. Se è un server critico o qualcosa di importante ... Non vorrei rischiare.

I miei server non sono tuoi però :-)

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.