---
title: "Atualizações automáticas de segurança no Ubuntu Server"
description: "Configure o Unattended Upgrades no Ubuntu 24.04: só patches de segurança, reinício agendado, needrestart, logs e simulação antes de confiar na rotina."
url: "https://streethosting.com.br/guias/vps/atualizacoes-automaticas-seguranca-ubuntu"
category: "vps"
slug: "atualizacoes-automaticas-seguranca-ubuntu"
datePublished: "2026-09-28"
dateModified: "2026-09-28"
author: "Equipe StreetHosting"
difficulty: "intermediario"
language: "pt-BR"
keywords:
  - "atualizacoes automaticas seguranca ubuntu"
  - "unattended-upgrades ubuntu 24.04"
  - "configurar unattended upgrades"
  - "reinicio automatico ubuntu server"
  - "needrestart ubuntu"
  - "atualizar vps ubuntu automaticamente"
---

# Como deixar a VPS Ubuntu aplicando patches de segurança sozinha

O Ubuntu já sabe instalar correções de segurança sem ninguém digitar apt upgrade. Este guia mostra como ligar, limitar o que entra, agendar o reinício e conferir se a rotina está de fato rodando.

> **Resposta rápida**
>
> Para ter **atualizações automáticas de segurança no Ubuntu**, use o pacote `unattended-upgrades` (já vem no Ubuntu Server), ative com `dpkg-reconfigure` e deixe só a origem de segurança liberada. Depois defina se e quando a VPS pode reiniciar sozinha, confira o que o needrestart vai reiniciar e teste com uma simulação antes de confiar. Os registros ficam em `/var/log/unattended-upgrades`.

## O que ele faz e o que não faz

Toda semana saem correções para OpenSSL, OpenSSH, sudo, kernel e outras peças que ficam expostas em uma VPS. Quando uma falha é publicada, a exploração automatizada costuma começar em poucos dias, e a janela entre o aviso e o ataque é exatamente o tempo que o servidor passa sem atualizar. O Unattended Upgrades fecha essa janela: uma vez por dia ele baixa a lista de pacotes, separa os que vêm das origens permitidas e instala sem pedir confirmação.

No Ubuntu Server 24.04 ele já vem instalado e, na maioria das imagens, ligado. Mesmo assim vale conferir, porque imagens personalizadas e instalações mínimas nem sempre trazem a mesma configuração. Três comandos mostram o estado atual:

```
systemctl list-timers 'apt-daily*'
cat /etc/apt/apt.conf.d/20auto-upgrades
apt-config dump APT::Periodic::Unattended-Upgrade
```

Os dois timers aparecem na lista: o `apt-daily.timer` atualiza a lista de pacotes e o `apt-daily-upgrade.timer` dispara a instalação. Se o último comando devolver o valor 1, a rotina está ligada. Também é importante saber o que ela não cobre, para não criar uma falsa sensação de segurança:

- **Versão do sistema:** passar do 24.04 para a próxima LTS é trabalho manual, com `do-release-upgrade` e backup antes.
- **Imagens Docker:** um container com Nginx antigo continua antigo até você baixar a imagem nova e recriar o container.
- **Dependências da aplicação:** pacotes instalados por npm, pip, Composer ou Maven têm ciclo próprio e ficam de fora.
- **Reinício:** por padrão a VPS não reinicia. A correção de kernel fica instalada, mas só passa a valer depois do reboot.
- **Repositórios de terceiros:** Docker, PostgreSQL oficial e PPAs ficam de fora até você incluir de propósito.

## Instalar e ativar

Se o pacote não estiver presente, instale e rode o assistente de configuração:

```
sudo apt update
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
```

Responda **Yes** quando ele perguntar se deve baixar e instalar atualizações estáveis automaticamente. O assistente grava o arquivo `/etc/apt/apt.conf.d/20auto-upgrades`, que funciona como interruptor geral:

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

O número é o intervalo em dias: 1 significa todo dia e 0 desliga. A terceira linha é opcional e limpa o cache de pacotes baixados uma vez por semana, o que ajuda em VPS com disco pequeno.

> **Dica**
>
> Não confunda os dois arquivos. O `20auto-upgrades` diz se a rotina roda. O `50unattended-upgrades` diz o que ela instala e como se comporta. Para desligar tudo, basta zerar o primeiro.

## Escolher o que entra

O comportamento fica em `/etc/apt/apt.conf.d/50unattended-upgrades`. O bloco mais importante é o das origens permitidas. No Ubuntu 24.04 ele vem assim:

```
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";
};
```

A linha terminada em **security** é a que traz as correções de segurança. As duas linhas de ESM só têm efeito se a máquina estiver ligada ao Ubuntu Pro. A linha **updates**, comentada, traz correções de bugs que não são de segurança. Para servidor de produção, a recomendação é manter como está: segurança automática e o resto em uma janela planejada. Quem prefere tudo em dia pode descomentar a linha, sabendo que aumenta a chance de uma mudança de comportamento chegar sem aviso.

Repositórios de terceiros ficam de fora por padrão, e isso é proposital. Uma atualização do Docker Engine reinicia o daemon e, junto com ele, os containers. Uma troca de versão do banco pode exigir intervenção. Se mesmo assim quiser incluir um desses repositórios, descubra a origem com `apt-cache policy nome-do-pacote` e acrescente uma linha no bloco `Unattended-Upgrade::Origins-Pattern` com o valor `"origin=ORIGEM_DO_REPOSITORIO";`.

O caminho contrário é segurar um pacote. A lista de bloqueio aceita expressões regulares que casam com o começo do nome:

```
Unattended-Upgrade::Package-Blacklist {
    "postgresql-";
};
```

Use com parcimônia: pacote bloqueado também deixa de receber correção de segurança. Na maioria dos casos o que você quer controlar não é a atualização, e sim o reinício do serviço, que se resolve no needrestart, mais abaixo.

Para as demais opções, em vez de editar o arquivo original, crie um arquivo próprio que o apt lê depois dele, como `/etc/apt/apt.conf.d/52unattended-upgrades-local`. Opções simples definidas nele substituem as do arquivo original, e uma atualização do pacote não pergunta sobre conflito de configuração. Listas, como as origens e a de bloqueio, são somadas entre os arquivos.

## Reinício automático e horário

Correção de kernel, glibc ou systemd só vale depois de reiniciar. Quando isso acontece, o Ubuntu cria `/var/run/reboot-required` e lista os pacotes responsáveis em `/var/run/reboot-required.pkgs`. Com o reinício automático desligado, que é o padrão, a VPS fica com a correção instalada e inativa até alguém reiniciar.

Se o serviço aguenta alguns minutos fora do ar de madrugada, ligar o reinício é a escolha mais segura. Exemplo de arquivo local:

```
// /etc/apt/apt.conf.d/52unattended-upgrades-local
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";
```

O horário aceita **now**, um horário no formato hh:mm ou um atraso em minutos. Com hh:mm, o reinício fica agendado para a próxima vez que o relógio passar por aquele horário. Como a instalação roda de manhã por padrão, um reinício marcado para 04:00 acontece na madrugada seguinte.

Quem define a hora da instalação é o `apt-daily-upgrade.timer`: por padrão às 6h, com atraso aleatório de até 60 minutos, no fuso da VPS. Muitas VPS saem de fábrica em UTC, e 6h em UTC são 3h em Brasília. Acerte o fuso com o guia de [timezone e locale na VPS](https://streethosting.com.br/guias/vps/configurar-timezone-locale-vps-brasil) e, se quiser outro horário, sobrescreva o timer:

```
sudo systemctl edit apt-daily-upgrade.timer

# conteúdo a colocar no editor que abrir:
[Timer]
OnCalendar=
OnCalendar=*-*-* 03:30
RandomizedDelaySec=15m
```

A linha **OnCalendar=** vazia limpa o horário original antes de definir o novo. Confira o resultado com `systemctl list-timers 'apt-daily*'`.

| Opção | O que faz | Sugestão para VPS |
| --- | --- | --- |
| Automatic-Reboot | Reinicia sozinho quando uma atualização exige | true, se o serviço tolera alguns minutos fora |
| Automatic-Reboot-WithUsers | Reinicia mesmo com alguém logado via SSH | true em servidor sem uso interativo |
| Automatic-Reboot-Time | Horário do reinício, na próxima ocorrência | Madrugada, longe do pico de acesso |
| Remove-Unused-Kernel-Packages | Apaga kernels antigos depois da troca | true, para não lotar o disco de boot |
| Remove-New-Unused-Dependencies | Remove dependências que a própria atualização deixou sobrando | true (já é o padrão) |
| Mail e MailReport | Envia relatório por email | Só quando algo mudar, se houver envio de email configurado |

> **Atenção**
>
> Antes de ligar o reinício, garanta que tudo sobe sozinho no boot: serviço systemd habilitado, PM2 com startup configurado, containers com política de restart. Um reinício agendado só vira queda quando a aplicação depende de alguém iniciar à mão. O guia de [PM2 e systemd no boot](https://streethosting.com.br/guias/vps/configurar-pm2-startup-systemd-vps) mostra como resolver isso.

## needrestart e serviços reiniciados

Nem toda atualização precisa de reboot. Quando uma biblioteca como o OpenSSL é atualizada, os processos que já estavam rodando continuam com a versão antiga carregada na memória. O needrestart detecta esses processos depois do apt e reinicia os serviços afetados.

No Ubuntu 24.04 o comportamento padrão mudou: ele reinicia os serviços automaticamente, tanto no apt manual quanto nas execuções automáticas. No 22.04, o apt manual abria uma tela perguntando o que reiniciar, e a execução automática só listava, sem mexer em nada.

Para a maioria dos serviços isso é ótimo, porque a correção passa a valer na hora. O problema aparece em processos que não gostam de reinício fora de hora: banco de dados no meio de uma migração, servidor de jogo com jogadores online, worker com fila em memória. Exclua esses serviços com um arquivo em `/etc/needrestart/conf.d/`:

```
# /etc/needrestart/conf.d/50-local.conf
$nrconf{override_rc}{qr(^postgresql)} = 0;
$nrconf{override_rc}{qr(^minecraft)} = 0;
```

Cada linha é uma expressão regular aplicada ao nome da unidade systemd. Os serviços excluídos continuam com a biblioteca antiga até você reiniciar à mão, na janela que escolher. Para ver o que está pendente a qualquer momento, rode `sudo needrestart -r l`, que só lista. A mesma saída avisa quando o kernel em execução é mais antigo que o instalado, sinal de que falta um reboot.

## Testar e conferir os registros

Antes de confiar na rotina, rode uma simulação. Ela percorre as origens, mostra o que seria instalado e não muda nada no sistema:

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

Na saída, procure a linha **Allowed origins are**, que deve listar as origens que você liberou, e a lista de pacotes que seriam atualizados. Se nada casar com as origens, a mensagem diz que não há pacotes para atualizar sem supervisão. As execuções reais ficam registradas em três lugares:

- `/var/log/unattended-upgrades/unattended-upgrades.log`: resumo de cada execução, com pacotes instalados e erros.
- `/var/log/unattended-upgrades/unattended-upgrades-dpkg.log`: saída completa do dpkg, útil quando um pacote falha na instalação.
- `/var/log/apt/history.log`: histórico de tudo o que o apt instalou, automático ou manual.

Para receber o relatório por email, defina `Unattended-Upgrade::Mail "voce@seu-dominio.com.br";` e `Unattended-Upgrade::MailReport "on-change";` no arquivo local. Isso exige um programa de envio configurado na VPS. Sem ele, a alternativa é o monitoramento: um alerta quando o arquivo `reboot-required` existir há mais de alguns dias ou quando o log parar de ser atualizado. O guia de [análise de logs na VPS Linux](https://streethosting.com.br/guias/vps/analisar-logs-vps-linux) ajuda a filtrar esses registros, e o de [monitoramento 24 horas](https://streethosting.com.br/guias/vps/monitorar-vps-24-horas) mostra como transformar isso em alerta.

## Boas práticas em produção

Atualização automática é uma das peças do [checklist de segurança para servidor Linux](https://streethosting.com.br/guias/infraestrutura/checklist-seguranca-servidor-linux), não a única. Ela funciona melhor quando o resto está no lugar:

- [ ] Backup automático rodando e restauração testada antes de ligar a rotina
- [ ] Só a origem de segurança liberada; o resto em janela planejada
- [ ] Horário de instalação e de reinício fora do pico de uso
- [ ] Aplicação configurada para subir sozinha depois do boot
- [ ] Serviços sensíveis excluídos no needrestart e reiniciados à mão
- [ ] Imagens Docker e dependências da aplicação com rotina própria
- [ ] Log conferido toda semana ou alerta configurado

O backup vem primeiro porque é ele que transforma uma atualização problemática em um susto de dez minutos. O guia de [backup automático com Restic e cron](https://streethosting.com.br/guias/vps/automatizar-backup-vps-restic-cron) cobre a parte de agendar, guardar fora da VPS e testar a restauração.

Duas observações sobre o ciclo de vida. O Ubuntu Pro, gratuito para uso pessoal em até cinco máquinas, libera as origens ESM e o Livepatch, que aplica correções críticas de kernel sem reiniciar. Ele estica o intervalo entre reboots, mas não elimina a necessidade deles. E o Ubuntu 24.04 recebe atualizações de segurança padrão até abril de 2029. Depois disso, sem Ubuntu Pro, a origem de segurança para de receber pacotes e a rotina continua rodando sem ter o que instalar. Planeje a troca de versão antes dessa data.

## Onde rodar

Tudo isso pressupõe controle do sistema: acesso root, kernel próprio para instalar e reiniciar, e um console para acompanhar o boot se algo der errado. Uma VPS com virtualização KVM entrega os três. Em containers compartilhados, o kernel pertence ao host e a correção dele não depende de você, como explica a comparação entre [KVM e LXC](https://streethosting.com.br/guias/vps/kvm-vs-lxc-diferenca).

As [VPS da StreetHosting](https://streethosting.com.br/vps) são KVM, com root, datacenter em São Paulo, AntiDDoS incluso e ativação em até 60 segundos. A linha Xeon começa em R$ 23,00 por mês com 2 vCPU, 2 GB de RAM e 20 GB NVMe, o suficiente para um site ou uma API pequena mantida em dia pela rotina deste guia. A linha Ryzen 9 9950X começa em R$ 39,00 com 1 vCPU, 2 GB DDR5 e 20 GB NVMe e sobe até 14 vCPU e 64 GB por R$ 814,00, para aplicações que precisam de clock alto e memória rápida.

## Perguntas frequentes

### O Ubuntu já vem com atualização automática de segurança?

Na maioria das instalações do Ubuntu Server 24.04, sim: o pacote vem instalado e a execução diária já vem ligada. Imagens personalizadas de provedores podem vir diferentes, então confira os timers do apt e os arquivos em /etc/apt/apt.conf.d antes de assumir que está tudo ativo.

### Atualização automática pode derrubar meu servidor?

Pode, mas o risco é pequeno quando só a origem de segurança está liberada, porque essas correções mudam o mínimo possível. O risco real vem do reinício de serviços e da própria VPS. Agende o horário, exclua serviços sensíveis no needrestart e tenha backup testado antes de ligar a rotina.

### Preciso reiniciar a VPS depois das atualizações?

Só quando a atualização mexe no kernel ou em bibliotecas centrais do sistema. Nesses casos o Ubuntu marca o reinício como pendente e avisa na mensagem de login do SSH. Você pode reiniciar à mão em uma janela planejada ou ligar o reinício automático com horário definido.

### Como sei se as atualizações automáticas estão funcionando?

Leia o log do Unattended Upgrades, que fica dentro de /var/log, e confira a data da última execução e os pacotes instalados. Para testar a configuração sem instalar nada, rode o comando de atualização automática em modo de simulação, com as opções dry run e debug.

### Devo liberar também as atualizações que não são de segurança?

Em servidor de produção, prefira não. A origem updates traz correções de bugs e pequenas mudanças de comportamento que merecem uma janela planejada. Em ambiente de teste ou máquina pessoal, liberar tudo simplifica a manutenção.

## Guias relacionados

- [Checklist de segurança para servidor Linux do zero ao seguro](https://streethosting.com.br/guias/infraestrutura/checklist-seguranca-servidor-linux.md)
- [Como ajustar o fuso horário e o idioma da VPS para o Brasil](https://streethosting.com.br/guias/vps/configurar-timezone-locale-vps-brasil.md)
- [Como configurar backup automático da VPS com restic e cron](https://streethosting.com.br/guias/vps/automatizar-backup-vps-restic-cron.md)
- [Como analisar logs de uma VPS Linux com journalctl e grep](https://streethosting.com.br/guias/vps/analisar-logs-vps-linux.md)
- [Como monitorar uma VPS 24 horas: métricas, alertas e uptime](https://streethosting.com.br/guias/vps/monitorar-vps-24-horas.md)

## Produtos citados

- https://streethosting.com.br/vps
- https://streethosting.com.br/vps/ryzen
- https://streethosting.com.br/vps/xeon

## Dados estruturados

```json
[
  {
    "@context": "https://schema.org",
    "@type": [
      "Article",
      "TechArticle"
    ],
    "headline": "Como deixar a VPS Ubuntu aplicando patches de segurança sozinha",
    "name": "Atualizações automáticas de segurança no Ubuntu Server",
    "abstract": "O Ubuntu já sabe instalar correções de segurança sem ninguém digitar apt upgrade. Este guia mostra como ligar, limitar o que entra, agendar o reinício e conferir se a rotina está de fato rodando.",
    "description": "Configure o Unattended Upgrades no Ubuntu 24.04: só patches de segurança, reinício agendado, needrestart, logs e simulação antes de confiar na rotina.",
    "datePublished": "2026-09-28",
    "dateModified": "2026-09-28",
    "author": {
      "@type": "Organization",
      "name": "Equipe StreetHosting"
    },
    "publisher": {
      "@type": "Organization",
      "name": "StreetHosting",
      "url": "https://streethosting.com.br"
    },
    "inLanguage": "pt-BR",
    "mainEntityOfPage": {
      "@type": "WebPage",
      "@id": "https://streethosting.com.br/guias/vps/atualizacoes-automaticas-seguranca-ubuntu"
    }
  },
  {
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
      {
        "@type": "Question",
        "name": "O Ubuntu já vem com atualização automática de segurança?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Na maioria das instalações do Ubuntu Server 24.04, sim: o pacote vem instalado e a execução diária já vem ligada. Imagens personalizadas de provedores podem vir diferentes, então confira os timers do apt e os arquivos em /etc/apt/apt.conf.d antes de assumir que está tudo ativo."
        }
      },
      {
        "@type": "Question",
        "name": "Atualização automática pode derrubar meu servidor?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Pode, mas o risco é pequeno quando só a origem de segurança está liberada, porque essas correções mudam o mínimo possível. O risco real vem do reinício de serviços e da própria VPS. Agende o horário, exclua serviços sensíveis no needrestart e tenha backup testado antes de ligar a rotina."
        }
      },
      {
        "@type": "Question",
        "name": "Preciso reiniciar a VPS depois das atualizações?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Só quando a atualização mexe no kernel ou em bibliotecas centrais do sistema. Nesses casos o Ubuntu marca o reinício como pendente e avisa na mensagem de login do SSH. Você pode reiniciar à mão em uma janela planejada ou ligar o reinício automático com horário definido."
        }
      },
      {
        "@type": "Question",
        "name": "Como sei se as atualizações automáticas estão funcionando?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Leia o log do Unattended Upgrades, que fica dentro de /var/log, e confira a data da última execução e os pacotes instalados. Para testar a configuração sem instalar nada, rode o comando de atualização automática em modo de simulação, com as opções dry run e debug."
        }
      },
      {
        "@type": "Question",
        "name": "Devo liberar também as atualizações que não são de segurança?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Em servidor de produção, prefira não. A origem updates traz correções de bugs e pequenas mudanças de comportamento que merecem uma janela planejada. Em ambiente de teste ou máquina pessoal, liberar tudo simplifica a manutenção."
        }
      }
    ]
  }
]
```