Como ativar atualizações automáticas de segurança no Ubuntu

Firewall configurado, SSH com chave, fail2ban rodando — e um servidor que ninguém atualiza há oito meses. É a combinação mais comum em VPS esquecida: a defesa de perímetro está certa, mas o openssl ou o kernel carregam falhas já corrigidas e públicas. O caso clássico é o vazamento da Equifax em 2017, em que o patch do Apache Struts existia meses antes da invasão. No Ubuntu, o pacote unattended-upgrades resolve isso instalando os patches de segurança sozinho.

O que é o unattended-upgrades?

O que o unattended-upgrades faz no Ubuntu?

É um serviço do APT que baixa e instala atualizações automaticamente, em segundo plano, a partir de uma lista de repositórios que você autoriza — por padrão, só os de segurança. Ele roda por timers do systemd (apt-daily e apt-daily-upgrade), então não depende de cron manual.

Em instalações recentes do Ubuntu ele já costuma vir instalado e ativo, mas isso varia conforme a imagem (VPS de provedor, minimal, derivadas). Confira antes de supor.

Passo 1: instale e ative

sudo apt update
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

O último comando abre uma tela perguntando se deve instalar atualizações automaticamente. Responda Sim. Ele grava o arquivo /etc/apt/apt.conf.d/20auto-upgrades:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Os valores significam "a cada 1 dia": atualizar a lista de pacotes e rodar o unattended-upgrade.

Passo 2: escolha o que atualizar automaticamente

A configuração principal fica em /etc/apt/apt.conf.d/50unattended-upgrades. Abra com sudo nano e procure o bloco Allowed-Origins:

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}";
        "${distro_id}:${distro_codename}-security";
        "${distro_id}ESMApps:${distro_codename}-apps-security";
        "${distro_id}ESM:${distro_codename}-infra-security";
//      "${distro_id}:${distro_codename}-updates";
//      "${distro_id}:${distro_codename}-proposed";
//      "${distro_id}:${distro_codename}-backports";
};

Linhas com // no início estão desativadas. O padrão é deixar ativos só -security (e os canais ESM, se você usa Ubuntu Pro). Manter -updates comentado é a escolha conservadora: ele traz correções de bugs que não são de segurança e têm mais chance de mudar comportamento. Nunca habilite -proposed em servidor.

Atualização automática pode quebrar o servidor?

Pode, mas o risco é bem menor com só o canal de segurança, porque esses patches são pequenos e voltados a corrigir a falha sem mudar funcionalidade. Mesmo assim, em produção crítica, mantenha backup e teste em um ambiente de homologação. A regra 3-2-1 de backup vale aqui também.

Passo 3: defina reinício automático

Patches de kernel e de bibliotecas como a glibc só passam a valer depois do reboot. Quando um reinício é necessário, o sistema cria o arquivo /var/run/reboot-required. Para o unattended-upgrades cuidar disso em horário de baixo movimento, ajuste no mesmo arquivo:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";

Com isso o servidor só reinicia se for preciso, às 3h do fuso do servidor, e pula o reboot se houver usuário logado. Se você não pode aceitar nenhuma interrupção, deixe Automatic-Reboot "false" e agende uma janela de manutenção manual, checando o arquivo reboot-required toda semana.

Duas opções úteis no mesmo arquivo:

Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Mail "[email protected]";

A primeira limpa dependências que sobraram. A segunda envia relatório por e-mail, mas só funciona se o servidor tiver um MTA configurado (como postfix ou msmtp).

Passo 4: teste sem aplicar nada

sudo unattended-upgrade --dry-run --debug

O --dry-run simula a execução e mostra quais pacotes seriam atualizados, sem instalar. No modo debug você vê quais origens foram aceitas. Se aparecer algo como "Packages that will be upgraded", a configuração está funcionando. Para ver se os timers estão ativos:

systemctl list-timers apt-daily.timer apt-daily-upgrade.timer

Passo 5: confira os logs

sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log
ls /var/run/reboot-required

O log mostra cada execução, com os pacotes instalados e erros. Se o ls disser que o arquivo não existe, não há reboot pendente. Um servidor que acumula esse arquivo por semanas está com patches instalados mas ainda não aplicados no kernel em execução.

O que o unattended-upgrades não cobre

• Software fora do APT: binários baixados à mão, imagens Docker, pacotes pip/npm e snaps seguem outra lógica de atualização.
• Containers: o host é atualizado, mas as imagens dos containers precisam ser reconstruídas.
• Serviços que precisam de restart: sem reboot, um daemon pode continuar rodando a biblioteca antiga em memória. O pacote needrestart ajuda a listar o que reiniciar.
• Configuração insegura: patch não corrige senha fraca nem porta aberta à toa. Para isso, veja o tutorial do firewall UFW e o guia de fail2ban contra força bruta.

A lição maior

Muita invasão não usa falha nova: usa uma falha com correção publicada que ninguém instalou. Automatizar o patch de segurança tira essa decisão do esforço humano e a coloca numa rotina que roda sozinha. É o item mais barato da lista de hardening, e vale tanto quanto o SSH bem configurado.

Se quiser aprofundar o que acontece quando o patch não é instalado, leia como se proteger de ransomware.

Fontes consultadas

• Páginas de manual unattended-upgrade e comentários do arquivo 50unattended-upgrades (pacote Debian/Ubuntu)
• Documentação do Ubuntu Server sobre atualizações automáticas