Atualização yum automatizada para manter o servidor seguro - prós e contras?


8

Estou pensando em adicionar um cronjob yum -qy updateem execução regularmente em algumas máquinas que não recebem manutenção regular. O objetivo seria manter as máquinas atualizadas com relação às correções de segurança que seriam aplicadas tarde demais. Estou apenas usando os repositórios base do CentOS.

Questões:

  • Na sua experiência - quão "segura" seria essa abordagem? Devo esperar atualizações com falha de vez em quando? Aproximadamente com que frequência essa abordagem exigiria reinicializações?
  • Prós / contras ou outras dicas com essa abordagem?
  • Como você mantém suas máquinas atualizadas usando a automação?

2
substitua yum -qy por: / usr / bin / yum -R 120 -e 0 -d 0 -y atualize yum AND / usr / bin / yum -R 10 -e 0 -d 0 -y atualização
Adam Benayoun

Adam: Obrigado pela sua sugestão. Você poderia explicar por que isso é melhor?
knorv

11
Primeiro você atualiza o yum e atualiza os pacotes; o -R significa que ele fornece o tempo máximo de espera do comando, o que significa que não atingirá o tempo limite se eu estiver certo. o -e e -d são apenas nível de erro / debug
Adam Benayoun

Eu não tenho certeza sobre "-R [tempo em minutos]" - "define a quantidade máxima de tempo que você espera antes de executar um comando - ele aleatoriamente ao longo do tempo". Parece que o yum vai esperar rand () * minutos antes de emitir um comando? Isso é bom? :-)
knorv

Respostas:


6

Depende

Na minha experiência com o CentOS, é bastante seguro, pois você usa apenas os repositórios base do CentOS.

Você deve esperar atualizações com falha de vez em quando ... sim ... no mesmo nível que você deve esperar uma falha no disco rígido ou uma CPU com falha de vez em quando. Você nunca pode ter muitos backups. :-)

O bom das atualizações automatizadas é que você é corrigido (e, portanto, mais seguro) mais rápido do que manualmente.

Os patches manuais sempre parecem ser adiados ou considerados "de baixa prioridade" para muitas outras coisas; portanto, se você for para o modo manual, marque o horário no seu calendário para fazê-lo.

Eu configurei muitas máquinas para fazer atualizações automáticas do yum (via tarefa cron) e raramente tive um problema. Na verdade, não me lembro de ter tido um problema com os repositórios BASE. Todo problema em que consigo pensar (de cabeça para baixo, na minha experiência) sempre foi uma situação de terceiros.

Dito isto ... Eu tenho várias máquinas para as quais eu manualmente faço as atualizações. Coisas como servidores de banco de dados e outros sistemas extremamente críticos Gosto de ter uma abordagem "prática".

O jeito que eu pessoalmente descobri foi assim ... Penso no cenário "e se" e tento pensar em quanto tempo levaria para reconstruir ou restaurar a partir de um backup e o que (se alguma coisa) seria perdido .

No caso de vários servidores da Web ... ou servidores cujo conteúdo não muda muito ... eu vou em frente e faço a atualização automática porque a quantidade de tempo para reconstruir / restaurar é mínima.

No caso de servidores de banco de dados críticos, etc ... eu agito o tempo uma vez por semana para examiná-los e corrigi-los manualmente ... porque o tempo necessário para reconstruir / restaurar consome mais tempo.

Dependendo dos servidores que você possui em sua rede e como seu plano de backup / recuperação é implementado, suas decisões podem ser diferentes.

Espero que isto ajude.


6

Pro : seu servidor está sempre no nível de patch mais recente, geralmente mesmo contra explorações de 0 dia.

Contras : Qualquer código em execução no servidor que use recursos removidos em versões posteriores, qualquer arquivo de configuração que mude a sintaxe e quaisquer novos "recursos" de segurança que impeçam a execução do código que pode ser explorado podem causar a interrupção das coisas em execução no servidor sem você sabendo disso até que alguém lhe ligue com um problema.

Prática recomendada: solicite ao servidor que envie um email quando precisar ser atualizado. Faça backup ou saiba como reverter atualizações.


+1 - Eu recomendaria fortemente que se inscrevesse na lista de e-mails do centos, eles fazem um ótimo trabalho ao enviar avisos sobre patches e prioridades antes de serem enviados para os repositórios.
23611 Adam Benayoun

3
Não há patches contra explorações de 0 dia, por definição. Uma exploração de 0 dias é aquela para a qual ainda não há patch.
MarkR

Considero 0 dia como o dia em que é descoberto / explorado / anunciado, e o Redhat geralmente corrige vulnerabilidades graves em algumas horas - o que é, coincidentemente, ainda durante o dia em que foi descoberto.
22413 Karl Karlzzz

2

Além do que a maioria das pessoas disse aqui, eu recomendo que se inscreva na lista de discussão do centos, eles sempre postam e-mails sobre patches e suas prioridades antes de enviá-los para os repositórios. É útil saber com antecedência o que os pacotes precisam ser atualizados.

Minha configuração está permitindo que o yum atualize o sistema automaticamente uma vez por dia. Faço o yum me enviar um e-mail com os pacotes instalados ou atualizados logo após. Também recebo emails quando yum está em conflito e precisa de intervenção manual (a cada 4 horas).

Até agora, tudo estava funcionando sem problemas (há mais de 4 anos), a única vez em que fui pego de surpresa foi quando o yum atualizou o kernel regular (virtualizei meu servidor) e alterei o grub e o empurrei como padrão por duas semanas. mais tarde, durante a manutenção, meu sistema foi reinicializado e todos os meus servidores virtuais foram desativados por alguns minutos, até que tive que intervir manualmente.

Fora isso, eu realmente não tive nenhum problema.


1

contanto que você não possua nenhum pacote personalizado e esteja usando apenas os repositórios Base do CentOS, deve ser bastante seguro.

Além disso, uma maneira melhor de conseguir isso seria usar yum-updatesd com do_update = yesset.


11
O serviço yum-updatesd não é maduro o suficiente para um ambiente corporativo e o serviço pode apresentar sobrecarga desnecessária. Eu usaria: / usr / bin / yum -R 120 -e 0 -d 0 atualização -y yum e / usr / bin / yum-R10 -e 0 -d 0 atualização -y
Adam Benayoun

0

Suponho que, desde que você tenha backups automatizados, não seria uma preocupação, desde que você possa viver com o tempo de inatividade do servidor.

Eu não tentei isso; Eu não gostaria pessoalmente, porque há um risco significativo de quebrar alguma coisa ou ter um problema obscuro incomum introduzido por causa de uma correção inicial. É ainda pior se este é um servidor que raramente chama atenção, por isso, se algo der errado, talvez você não saiba.

Se você puder viver com o servidor em questão inoperante por um período de tempo, se / quando algo ocorrer, e tiver um plano de resposta para restaurar o sistema ao estado anterior, bem como um sistema para enviar atualizações por logs ou e-mail informando quando e o que foi atualizado (para que você saiba que não está em um estado parado ou aguardando uma resposta a algo que requer intervenção), você pode experimentá-lo. Se é um servidor crítico ou algo importante ... eu não gostaria de arriscar.

Meus servidores não são seus :-)

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.