Práticas recomendadas para manter as máquinas Ubuntu EC2 atualizadas

12

Na sequência da recente heartbleed vulnerabilidade do OpenSSL, eu gostaria de manter minhas máquinas EC2 atualizados em uma base regular. A abordagem ingênua seria definir um trabalho cron de hora em hora para atualizações de segurança ( sudo apt-get update && sudo unattended-upgrade).

Existe algum risco de fazer isso? Existe um mecanismo de atualização recomendado para máquinas EC2?

unattended-upgrades

— Adam Matan
fonte

13

O pacote de atualizações autônomas é a maneira padrão de aplicar automaticamente importantes correções de bugs e patches de segurança no Ubuntu.

Eu recomendo instalar isso em todos os sistemas Ubuntu:

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

Você não precisa criar seu próprio trabalho cron. O pacote instala um para você.

Você pode editar a configuração padrão se desejar alterar seu comportamento: https://help.ubuntu.com/lts/serverguide/automatic-updates.html

— Eric Hammond
fonte

Alguma opinião sobre a conveniência de fazer isso em um servidor de produção? Fico nervoso por aplicar alterações silenciosamente e arriscar a possibilidade de a atualização falhar ou apresentar problemas.

— Ianjs 14/04/19

3

Por "todo" eu também quis dizer sistemas de produção. Eu aplico automaticamente os patches de segurança do Ubuntu há muitos anos e não consigo me lembrar de nenhum problema sério. Fico nervoso por ter um servidor de produção sentado sem correções para problemas de segurança conhecidos e arriscar a possibilidade de explorá-los. Dito isso, cada situação tem necessidades diferentes; portanto, é melhor você passar por uma rigorosa fase de testes para cada patch. Esteja ciente, porém, de que eles são liberados o tempo todo, para que você esteja ocupado.

— Eric Hammond

1

Eu não aconselho isso, a menos que você tenha uma configuração redundante / cluster. Os procedimentos de atualização do Ubuntu não são fáceis, eu parei os serviços várias vezes e, mais recentemente, até um setor de inicialização quebrado ... E não fazemos nada de especial - apenas o Apache como proxy reverso e aplicativos Tomcat.

— dualed

1

Temos usado unattended-upgradesde 2015 a 2020 sem problemas. Temos uma pequena configuração (no DigitalOcean) com:

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

Com base no bom desempenho passado, fazer atualizações dessa maneira parece mais seguro do que não fazê-lo. Mas isso não é necessariamente uma garantia para o futuro!

Pode não ser uma boa ideia apache, com base nos relatórios de outros usuários e na minha experiência anterior de apacheatualizações. [Veja acima e aqui ]

Com unattended-upgrades, a intervenção manual ainda será necessária quando a versão se aproximar da EOL .

(Além da pergunta: na minha experiência com TWiki, WordPress e Jenkins, manter esses aplicativos atualizados é realmente uma preocupação maior do que o próprio sistema operacional, embora, é claro, devêssemos realmente fazer as duas coisas. Para ter tranqüilidade, você pode colocar aplicativos voltados para a Internet em sandbox como processos não raiz em execução em um contêiner do Docker.)

Mas como você perguntou sobre as melhores práticas , a abordagem principal recomendada na documentação da AWS é:

Crie e inicie novas instâncias para substituir suas instâncias online atuais. Em seguida, exclua as instâncias atuais.

As novas instâncias terão o conjunto mais recente de patches de segurança instalados durante a instalação.

(Fevereiro de 2020)

Isso pode ser feito como parte de uma estratégia de implantação azul esverdeado . A vantagem aqui é que você pode executar testes no seu novo servidor antes de mudar o tráfego. Se seus testes forem completos, em teoria suas atualizações poderão ser totalmente automatizadas, verificadas antes de serem lançadas e sem tempo de inatividade.

Outras vantagens:

Os testes podem fornecer um aviso avançado se a atenção humana for necessária (ao contrário unattended-upgrades, quando os avisos vierem dos usuários apenas quando o problema estiver ativo!)
Se o seu sistema ficar comprometido ou você decidir mudar de provedor, essa abordagem deverá facilitar a implantação de uma nova implantação. Sua estratégia de implantação é com script, em vez de memória antiga.

Mas é claro que há mais configuração necessária para essa abordagem do que simplesmente instalar unattended-upgradese mais complexidade; portanto, ainda há espaço para erros.

A AWS também menciona a execução do "Update Stack dependencies command", que parece ser sua maneira oficial de fazer algo semelhante unattended-upgrades. Parece que pode ser acionado a partir da interface de Instâncias, mas não tenho certeza se pode ser automatizado.

— joeytwiddle
fonte