Quais atualizações do Red Hat / CentOS devem ser aplicadas e em que cronograma?

Question

Estou inscrito na lista de discussão do CentOS-announce e li as definições das várias tags de gravidade, como Crítica, Importante, Moderada, Baixa, BugFix, etc., mas ainda não sei ao certo o que realmente precisa sair e o que pode esperar (já que preciso justificar uma interrupção em nosso trabalho regular para obter as atualizações).

Até agora, tentei obter atualizações críticas aplicadas em nossos ambientes de produção o mais rápido possível.

Qual é o cronograma normal de aplicação dessas atualizações? Eles acontecem com tanta frequência que claramente não podemos aplicá-los todos rapidamente porque eles precisam ser testados para garantir que não quebraram nossos sistemas.

Para o contexto, nós executamos principalmente um site e não há usuários extras no sistema, então eu normalmente não estou preocupado com 'exploits locais' tanto quanto eu estou preocupado com exploits remotos. Mas sinto que ainda estou no escuro sobre a melhor forma de aplicar essas atualizações.

Obrigado,

    

Answer 1

Eu gerencio vários sites diferentes para vários clientes, e geralmente isso é o que eu faço.

Primeiro, a principal prioridade das atualizações de segurança deve ser o próprio aplicativo da web . A grande maioria dos ataques terá como alvo seu site e o código que o executa, e isso precisa ser mantido seguro. Se você usa aplicações web de prateleira, este é um lugar onde eu consideraria atualizações automáticas , mas em nenhum caso eu deixaria uma atualização de segurança para algo como WordPress ou Drupal envelhecer mais de 24 horas antes de testá-lo e, provavelmente, lançá-lo.

Se o seu aplicativo da web for personalizado, certifique-se de que seus desenvolvedores estejam acompanhando os problemas de segurança, seja qual for a sua extensão. Este é um cenário em que sua organização deve estar fazendo DevOps para garantir que os desenvolvedores da Web e a TI estejam trabalhando bem juntos e que os problemas sejam resolvidos em tempo hábil.

Depois disso, as próximas atualizações críticas que considero são aquelas que "se tornam virais" e que você ouve sobre notícias nacionais, como Heartbleed, POODLE, etc., bem como atualizações de qualquer coisa no caminho crítico, como nginx e PHP para sites Drupal e WordPress. Eu aplico atualizações para eles assim que eles estiverem disponíveis. Eu também estou nas listas de discussão para os pacotes upstream (por exemplo, estou inscrito no openssl-announce) para que eu receba notificações de coisas realmente importantes o mais rápido possível.

Em seguida, aplico atualizações a todos os servidores voltados ao público (front-ends da Web, balanceadores de carga, etc.) e a todos os servidores de suporte (bancos de dados, etc.) uma vez por mês. Isso inclui qualquer segurança restante e atualizações de correção de bug. Em muitas organizações isso é feito trimestralmente, mas é minha opinião que sites públicos, especialmente aqueles que fazem comércio eletrônico, não devem ser deixados para apodrecer por tanto tempo. Eu quase sempre faço isso no fim de semana após o patch da Microsoft na terça-feira, o que é quase sempre tempo suficiente para ouvir sobre atualizações ruins da Microsoft (embora eu execute sistemas Linux, é mais fácil ter um fim de semana para atualizar tudo).

Finalmente, sento-me, relaxo e espero para ver o que quebra. Apesar de seus melhores esforços em testar atualizações, algo acabará dando errado. Assista seu sistema de monitoramento. Se algo quebrar que não esteja sendo monitorado, corrija-o e comece a monitorá-lo. Esteja preparado para reverter ( yum history undo é útil).

    

Answer 2

Para uma parte muito grande depende .

O óbvio é que as atualizações de segurança críticas são geralmente melhor instaladas o mais breve possível , mas apenas você conhece sua infraestrutura e plataforma. O que é o mais rápido possível é específico para você. Se você estiver executando um servidor da Web, algo recente como:

"CESA-2014:1919 Critical CentOS 7 firefox Security Update"

não é um problema para você. Não precisa correr. Se você está rodando 500 estações de trabalho CentOS, essa errata pode de fato ser crucial e você pode fazer uma atualização desse tipo sem qualquer teste mínimo ou mínimo. Essa decisão deve vir como resultado de uma avaliação de impacto / risco, possivelmente com a ajuda do seu funcionário de segurança. Por outro lado, para você, o risco pode ser mitigado porque todas as estações de trabalho são forçadas a usar um proxy da web que já bloqueia esse conteúdo mal-intencionado e 500 usuários altamente pagos não poderão trabalhar adequadamente de manhã. um risco inaceitável também. Então, o mais rápido possível significa após um teste cuidadoso.

Em contraste, muitas vezes correções de bugs não são importantes e podem esperar, a menos que seu ambiente sofra ativamente com esses bugs, então você pode querer resolver isso o mais rápido possível.

Isso era algo que o servidor Satellite da Red Hat ou o projeto do Spacewalk tornavam mais fácil, para cada sistema registrado você pode ver quais erratas e atualizações são aplicáveis, e também o contrário, para cada Errata você vê quantos sistemas são impactados. Muito melhor do que apenas uma lista de pacotes com possíveis atualizações pendentes

Algumas organizações nas quais trabalhei tinham aplicativos muito simples que permitiam que os servidores fossem corrigidos automaticamente. "Na Red Hat confiamos".
Outros tinham dois lançamentos internos onde todas as erratas seriam acumuladas e apenas atualizações críticas específicas e exploráveis remotamente seriam lançadas fora desse cronograma. E um ou dois que foram considerados críticos para o nosso set-up também. Na não-produção empurre as atualizações antes do início do dia útil, testando obrigatoriamente pela manhã, na produção não mais que 24 horas após o lançamento da atualização.