Reforce a segurança do seu Ubuntu: melhores práticas para 2026

Vá direto para um resumo gerado por IA desta postagem do blog

Principais conclusões

O Ubuntu vem com recursos de segurança integrados e robustos: AppArmor, UFW e unattended-upgrades – mas as configurações padrão só oferecem proteção se você as configurar e mantiver ativamente.
A maioria das falhas de segurança no Ubuntu se resume a três fatores: kernels sem patches, práticas de segurança SSH inadequadas e a utilização de uma versão LTS após o fim do ciclo de vida sem um plano definido.
A aplicação de patches no kernel em tempo real permite aplicar correções críticas no kernel sem precisar programar uma reinicialização, o que é fundamental para cargas de trabalho 24 horas por dia, 7 dias por semana, nas quais o tempo de inatividade tem um custo elevado.
A criptografia de disco, o monitoramento da integridade dos arquivos e o registro de auditorias costumam ser ignorados em configurações básicas, mas fazem uma grande diferença quando algo dá errado.

O Ubuntu é executado em uma grande parcela dos servidores Linux do mundo, e essa popularidade é exatamente o motivo pelo qual vale a pena levar a sério a segurança do Ubuntu. Os invasores vão onde estão os alvos. A boa notícia: o Ubuntu oferece uma base sólida logo de fábrica. A notícia não tão boa: essa base pressupõe que você realmente irá configurá-lo, mantê-lo atualizado e ter um plano pronto para quando uma versão LTS deixar de receber suporte.

Este guia explica o que já está protegendo você, onde as ameaças reais costumam surgir e as poucas práticas que realmente fazem a diferença.

O que é o Ubuntu?

O Ubuntu é uma distribuição Linux baseada no Debian, mantida pela Canonical, lançada pela primeira vez em 2004. Hoje, é um dos sistemas operacionais para servidores mais amplamente implantados no mundo. É de código aberto, de uso gratuito e está disponível em duas versões principais: as versões com Suporte de Longo Prazo (LTS), que contam com cinco anos de suporte de segurança padrão, e as versões intermediárias, lançadas a cada seis meses, cada uma com nove meses de suporte.

Por que os usuários do Ubuntu devem se preocupar com segurança?

Porque o Ubuntu está em toda parte. Cargas de trabalho na nuvem, hosts de contêineres, laptops de desenvolvedores, dispositivos de borda. O Relatório sobre o Panorama do Código Aberto de 2026, da TuxCare, revelou que mais da metade dos usuários corporativos do Linux utilizam o Ubuntu em ambiente de produção — mais do que qualquer outra distribuição. Essa concentração o torna um alvo constante e de alto valor.

O Relatório Anual de Investigação sobre Violações de Dados (DBIR) da Verizon de 2026 revelou que a exploração de vulnerabilidades é atualmente o vetor de acesso inicial mais comum em violações, atingindo 31% — um aumento de 55% em relação ao ano anterior — e ultrapassando, pela primeira vez, o roubo de credenciais. No caso dos servidores Linux, as vulnerabilidades CVE sem patch são a via de acesso mais direta.

O risco aumenta rapidamente se você estiver operando além do período padrão de suporte da sua versão. Os registros de CVEs no Banco de Dados Nacional de Vulnerabilidades do NIST cresceram 263% entre 2020 e 2025, com quase 42.000 CVEs registrados somente em 2025 — e o próprio NIST alertou que esse volume continua aumentando. Um host Ubuntu em fim de vida (EOL) deixa de receber correções para praticamente todas elas. A lacuna entre “CVE publicado” e “seu sistema corrigido” já é grande o suficiente nas versões com suporte — em uma versão sem suporte, ela nunca se fecha.

Principais recursos de segurança do Ubuntu

As configurações padrão do Ubuntu não são ruins. Elas apenas estão incompletas. Veja a seguir o que vem instalado, o que está ativado por padrão e o que cada opção realmente oferece.

Um diagrama da defesa em camadas do ecossistema seguro do Ubuntu Linux.

Inicialização segura

O Secure Boot impõe uma cadeia de confiança durante o processo de inicialização, garantindo que apenas softwares assinados e confiáveis sejam carregados antes que os mecanismos de segurança do sistema operacional entrem em ação. No Ubuntu, todos os binários de inicialização pré-compilados são assinados com o certificado UEFI da Canonical. Isso é importante porque um bootloader ou firmware comprometido pode conceder a um invasor acesso no nível do kernel antes que o AppArmor, o UFW ou qualquer outro mecanismo de controle tenha a chance de agir. A maioria das instâncias em nuvem e das implantações modernas em hardware físico (bare-metal) dispõe do Secure Boot – vale a pena verificar se ele está realmente ativado, em vez de simplesmente presumir que sim.

AppArmor

O AppArmor é a estrutura de controle de acesso obrigatório (MAC) do Ubuntu, ativada por padrão. Ele restringe o que cada programa pode ler, gravar ou executar, independentemente das permissões dos arquivos, operando com base em perfis carregados para cada binário. O Ubuntu vem com perfis para serviços de alto risco, como CUPS, MySQL e Firefox.

Em comparação com o SELinux, é mais fácil criar regras para o AppArmor, o que é um dos motivos pelos quais a Canonical o escolheu. Dito isso, a maioria das equipes nunca cria um perfil personalizado além do que vem por padrão, o que deixa de aproveitar grande parte do potencial de cobertura.

O Ubuntu 24.04 também introduziu restrições de namespace para usuários sem privilégios, que limitam o que os processos podem fazer dentro de namespaces isolados sem permissões elevadas. Trata-se de um controle no nível do kernel que reduz a superfície de ataque para fugas de contêineres e contornamentos de sandbox — ativado por padrão e que vale a pena manter ativado.

Atualizações automáticas

O unattended-upgrades O pacote baixa automaticamente as atualizações de segurança dos repositórios do Ubuntu, sem necessidade de intervenção manual. Em uma instalação nova do servidor, ele vem habilitado apenas para o “security pocket”, o que é a configuração padrão correta.

Se você o substituir sem cuidado, ou desativá-lo porque uma reinicialização já causou uma falha na produção, estará, na prática, desativando o único mecanismo de controle automatizado mais eficaz do equipamento.

Uma coisa que vale a pena entender sobre como o Ubuntu lida com correções de segurança: em vez de forçar a atualização para a versão mais recente de um pacote, a equipe de segurança do Ubuntu utiliza o backporting de segurança — aplicando a correção específica à versão que já está instalada na sua versão do sistema. É por isso que o comando `apt upgrade` no Ubuntu 22.04 não vai, de repente, instalar uma versão completamente diferente do OpenSSL; ele instala a mesma versão, mas com a vulnerabilidade corrigida.

Preste atenção especial aos pacotes obtidos do repositório “universe” – ao contrário do “main”, que é mantido e recebe correções de segurança diretamente pela Canonical, os pacotes do “universe” são mantidos pela comunidade e nem sempre recebem correções de segurança em tempo hábil.

Cookies da UFW e da SYN

O Uncomplicated Firewall (UFW) é a interface padrão para o iptables/nftables, e o Ubuntu habilita os cookies SYN do TCP no kernel por padrão para mitigar ataques de inundação SYN. Os cookies SYN, por si só, não substituem um firewall, e o UFW não substitui os controles no nível da rede, mas, juntos, eles lidam com grande parte do tráfego de ruído de base sem exigir muito esforço.

Livepatch

O Canonical Livepatch aplica um subconjunto de correções de segurança do kernel sem a necessidade de reiniciar o host. É útil, mas tem um escopo mais restrito do que o marketing sugere. Ele abrange apenas kernels LTS com suporte, concentra-se em CVEs de gravidade alta e crítica e não afeta de forma alguma as bibliotecas do espaço do usuário.

Uma análise realista: O Livepatch não é uma solução abrangente para a aplicação de patches no kernel. Ele cobre um conjunto definido de vulnerabilidades CVE do kernel em kernels LTS compatíveis, e nada fora do kernel. Equipes que operam cargas de trabalho reforçadas, 24 horas por dia, 7 dias por semana, muitas vezes acabam complementando-o (ou substituindo-o completamente) por algo como o KernelCare, que cobre um conjunto mais amplo de vulnerabilidades CVE, com o LibCare estendendo a aplicação de patches em tempo real também às bibliotecas compartilhadas. Consulte a análise da TuxCare sobre as limitações do Livepatch para obter detalhes.

Criptografia de disco LUKS

O Ubuntu oferece suporte à criptografia completa do disco por meio do LUKS (Linux Unified Key Setup), e o momento mais fácil para ativá-la é durante a instalação. O instalador do Ubuntu oferece a opção “Criptografar a nova instalação do Ubuntu”, que configura um volume LVM criptografado. Uma vez ativada, o disco inteiro fica ilegível sem a senha, o que é importante em casos de roubo físico ou ao desativar o hardware.

Uma ressalva importante que os administradores de sistemas às vezes deixam passar: o LUKS protege os dados em repouso. Uma vez que o sistema é inicializado e o disco está desbloqueado, a criptografia não faz nada para impedir um invasor que já esteja no sistema. É por isso que a criptografia de disco não substitui a aplicação de patches no kernel e no espaço do usuário. Um sistema com um disco criptografado, mas com um kernel sem patches, ainda é totalmente vulnerável a explorações na memória. Os dois controles lidam com modelos de ameaça diferentes, e você precisa de ambos.

Caso você não tenha criptografado durante a instalação, o cryptsetup permite criptografar partições ou volumes individuais posteriormente, embora esse processo seja mais trabalhoso do que fazê-lo durante a instalação. A documentação da comunidade do Ubuntu explica o processo em detalhes.

Ameaças comuns à segurança dos sistemas Ubuntu

O Ubuntu é alvo constante de ataques. As ameaças abaixo são aquelas que realmente aparecem nos relatórios de incidentes, e não riscos teóricos.

CVEs não corrigidos no kernel e no espaço do usuário

As vulnerabilidades (CVEs) do kernel ganham destaque, mas a maioria das invasões no Ubuntu ocorre por meio de componentes do espaço do usuário sem patch: OpenSSL, glibc, sudo, polkit, CUPS. A cadeia de execução remota de código do CUPS de 2024 é um exemplo clássico. Ela estava presente nas instalações padrão em todas as versões do Ubuntu e não exigia nada além de acessibilidade à rede para ser explorada. Consulte o artigo da TuxCare sobre as vulnerabilidades do CUPS para obter uma análise técnica detalhada.

Ataques de força bruta e de credenciais via SSH

Qualquer servidor Ubuntu com a porta 22 aberta para a internet começa a registrar tentativas de ataque por força bruta poucos minutos após ficar online. Esses ataques são rudimentares, automatizados e implacáveis, e bastam apenas uma vez para terem sucesso contra uma senha fraca ou uma chave vazada.

Python e pilhas de bibliotecas mal configuradas ou desatualizadas

Os arquivos do Ubuntu incluem uma longa lista de pacotes Python, e interpretadores desatualizados são uma fonte constante de CVEs. Uma equipe que ainda utilize o Python 3.8 em produção estará, até 2026, executando um interpretador que já terá atingido o fim da vida útil (EOL) no código-fonte original. A TuxCare abordou o panorama das vulnerabilidades do Python no Ubuntu com certa profundidade, caso você queira compreender o escopo do problema.

Funcionando além do fim da vida útil

O Ubuntu LTS conta com cinco anos de suporte padrão. Após esse período, as correções de segurança são interrompidas, a menos que você utilize o Ubuntu Pro — que inclui a Manutenção de Segurança Expandida (ESM) e estende a cobertura por até dez anos a partir da data de lançamento original — ou um produto equivalente de terceiros. Muitas infraestruturas de produção ainda rodam o Ubuntu 18.04 ou versões anteriores, e esses servidores acumulam vulnerabilidades CVE não corrigidas a cada semana em que permanecem online.

Escalação de privilégios por meio de componentes vulneráveis

A escalada de privilégios local por meio do sudo, do polkit ou de falhas no kernel tem sido um tema recorrente no Ubuntu há anos. Essas vulnerabilidades geralmente partem de um ponto de entrada inicial com privilégios baixos (um usuário de aplicativo web comprometido, por exemplo) e podem transformar esse acesso em privilégios de root em questão de minutos. A TuxCare mantém um registro atualizado das vulnerabilidades recentes do Ubuntu que vale a pena verificar periodicamente.

Melhores práticas para melhorar a segurança do Ubuntu

A maior parte do que torna um servidor Ubuntu difícil de ser invadido consiste em um trabalho genuinamente monótono e repetitivo. As práticas abaixo oferecem o maior retorno pelo esforço investido.

Minimizar pacotes instalados

Cada pacote instalado no seu sistema é um código que pode conter vulnerabilidades. Um spooler de impressão que você esqueceu, uma ferramenta de desenvolvimento que ficou para trás, um serviço que veio junto com outro programa — qualquer um desses pode conter um CVE do qual você nunca ouviu falar, simplesmente porque não está acompanhando esses itens. A solução é chata, mas eficaz: reduza a lista de pacotes.

Comece verificando o que está realmente instalado:

apt list --installed 2>/dev/null | less

Compare com o que seu servidor realmente faz. É um servidor web? Ele não precisa de utilitários Bluetooth nem do CUPS. É um servidor de banco de dados? Provavelmente não precisa ter um agente de transferência de e-mail em execução. Remova o que você não precisa:

sudo apt remove --purge <package-name>

Dê continuidade com:

sudo apt autoremove

Já que está nisso, verifique o que está em escuta na rede:

ss -tlnp

Qualquer item dessa lista que não devesse estar lá merece ser investigado. Desative os serviços não utilizados com sudo systemctl disable --now <service>. Quanto menos o seu sistema estiver em execução, menos pontos vulneráveis haverá para serem explorados.

Aplique as correções de forma proativa – e não confie cegamente nas configurações padrão

Fluxograma comparativo entre os processos tradicionais e os processos “live” de aplicação de patches no kernel do Linux

Confirme se o `unattended-upgrades` está realmente em execução (systemctl status unattended-upgrades) e tirando do bolso de segurança.

Se você estiver executando cargas de trabalho 24 horas por dia, 7 dias por semana, nas quais reinicializações são onerosas, este é um dos poucos casos em que o problema é resolvido de forma eficaz. O KernelCare aplica patches no kernel em tempo real no Ubuntu sem a necessidade de reinicialização e abrange um conjunto mais amplo de CVEs do que o Livepatch.

Também vale a pena executar o comando `ubuntu-security-status` periodicamente – ele fornece um detalhamento claro sobre quais pacotes instalados estão cobertos pelo suporte padrão, quais exigem o Ubuntu Pro/ESM e quais têm atualizações de segurança pendentes disponíveis.

Bloquear o SSH

Desativar o login como root (PermitRootLogin no), desativar totalmente a autenticação por senha (PasswordAuthentication no), e exigem autenticação por chave.

Se não for possível aplicar uma lista de endereços IP permitidos (algo comum em ambientes com IPs dinâmicos ou funcionários remotos sem VPN), vale a pena dedicar tempo à configuração da autenticação de dois fatores no SSH. O pacote libpam-google-authenticator adiciona a autenticação de dois fatores (2FA) baseada em TOTP ao login via SSH com cerca de 15 minutos de trabalho. Mesmo que uma chave privada vaze, um invasor ainda precisará do código rotativo. Isso não substitui a autenticação apenas por chave, mas adiciona uma camada significativa para cenários de acesso de maior risco.

Dica profissional: Execute o `lastb` periodicamente para analisar tentativas de login malsucedidas. Milhares de tentativas contra as contas `root` ou `admin` provenientes de um único ASN não constituem, na verdade, um ataque. Trata-se apenas de ruído de fundo. A solução é bloquear o acesso com autenticação apenas por chave e uma lista de IPs permitidos, em vez de perseguir IPs individuais.

Lista de verificação para o fortalecimento do SSH em servidores Ubuntu, que inclui configurações críticas de segurança.

Ativar o registro de auditoria e monitorá-lo

Instale o auditd e configure regras para eventos relevantes: alterações em arquivos no diretório /etc, chamadas do sudo, criação de novos usuários e carregamento de módulos do kernel. Logs que você não lê são inúteis. Envie-os para um servidor central de logs ou para um SIEM. O objetivo não é apenas cumprir as normas por cumprir; é detectar aquele evento de autenticação suspeito antes que se transforme em uma violação.

Combine o auditd com um monitor de integridade de arquivos como o AIDE (Advanced Intrusion Detection Environment). Enquanto o auditd registra o que aconteceu, o AIDE detecta o que mudou. Ele cria um banco de dados de referência do seu sistema de arquivos — hashes de arquivos, permissões, propriedade — e sinaliza desvios quando você executa uma verificação. Isso é particularmente útil para detectar atividades pós-invasão que não geram eventos de log evidentes: um binário substituído discretamente, uma biblioteca modificada, uma tarefa cron adicionada. Execute o comando `sudo aideinit` para criar a linha de base após uma instalação limpa e, em seguida, programe verificações regulares via cron. Assim como o monitoramento de logs, isso só é útil se alguém realmente analisar os resultados.

Se o seu ambiente tiver requisitos de conformidade, tanto os CIS Benchmarks quanto os DISA STIGs oferecem perfis de fortalecimento específicos para o Ubuntu que se alinham diretamente aos controles acima — o que é útil como uma lista de verificação estruturada, em vez de começar do zero.

Melhores práticas	Esforço	A lacuna na cobertura é eliminada
Atualizações automáticas de segurança	Baixo	As CVEs mais conhecidas no espaço do usuário
Aplicação de patches no kernel em tempo real	Baixa–Média	Vulnerabilidades CVE no kernel sem janelas de reinicialização
Autenticação apenas por chave SSH + fail2ban	Baixo	Força bruta, preenchimento de credenciais
auditd + registros centralizados	Médio	Detecção de atividades pós-invasão
Plano de saída do EOL (atualização ou ELS)	Alto	Tudo, mais cedo ou mais tarde

Planeje o fim da vida antes que ele chegue

Gráfico cronológico mostrando as datas de fim de vida útil (EOL) do Ubuntu LTS e a cobertura do ELS da TuxCare.

Cada versão LTS do Ubuntu tem uma data de fim de vida útil (EOL) publicada. Você tem três opções reais: atualizar diretamente para a próxima versão LTS, migrar as cargas de trabalho para uma versão compatível ou obter suporte estendido. A opção de “não fazer nada” torna-se o padrão quando as equipes ficam sem tempo, e essa é, sem dúvida, a pior opção.

As atualizações no local nem sempre são viáveis. Aplicativos legados, dependências de módulos do kernel, middleware certificado: qualquer um desses fatores pode impedir uma atualização sem complicações. É exatamente para essa situação específica que o Endless Lifecycle Support da TuxCare foi criado. Ele fornece patches de segurança contínuos para o Ubuntu 16.04, 18.04 e 20.04 pelo tempo que você realmente precisar deles, e não apenas até a data de fim de vida útil (EOL) definida pelo fornecedor.

É um caminho mais comum do que as pessoas imaginam. A pesquisa de 2026 da TuxCare revelou que as organizações que enfrentavam o fim do ciclo de vida (EOL) de um software estavam praticamente divididas ao meio entre migrar e adquirir suporte de ciclo de vida estendido (ELS) – 41,7% em cada opção. Para muitas equipes, o ELS não é um plano alternativo; é o plano principal.

Eis um cenário que se repete com mais frequência do que se imagina. Uma equipe planeja uma atualização do Ubuntu 18.04 para o 22.04 seis meses antes do fim do suporte (EOL), depara-se com um problema de compatibilidade de módulo do kernel com um equipamento de um fornecedor e acaba mantendo a versão 18.04, sem suporte, por mais um ano, enquanto o departamento de compras resolve a questão. A cobertura do ELS existe exatamente para essa situação.

Recursos para a segurança do Ubuntu

Alguns sites que vale a pena conferir regularmente para se manter atualizado.

Avisos de segurança do Ubuntu

O feed de Avisos de Segurança do Ubuntu é a fonte oficial da Canonical para alertas CVE que afetam pacotes do Ubuntu, com detalhes sobre retroportabilidade e classificações de gravidade. Inscreva-se via RSS ou pela lista de e-mails. Os avisos são mantidos pela Equipe de Segurança do Ubuntu, grupo dedicado da Canonical responsável pela triagem de vulnerabilidades e pela emissão de correções de segurança em todas as versões do Ubuntu.

Catálogo de vulnerabilidades conhecidas e exploradas da CISA

O catálogo KEV da CISA rastreia as vulnerabilidades (CVEs) que estão sendo ativamente exploradas na prática. Compará-lo com as versões dos seus pacotes do Ubuntu é uma maneira rápida de priorizar quais correções devem ser aplicadas primeiro. Se uma entrada do KEV corresponder a um pacote instalado, essa será sua prioridade máxima.

r/Ubuntu e r/linuxadmin

Ambos os subreddits trazem à tona discussões sobre medidas de segurança no mundo real, análises pós-incidente e armadilhas para administradores de sistemas mais rapidamente do que a maioria dos blogs de fornecedores. A relação sinal-ruído varia, mas o tom é sincero.

Rastreador de CVEs do TuxCare

Se você estiver utilizando alguma versão coberta pelo ELS, como o Ubuntu 16.04, 18.04 ou 20.04, vale a pena adicionar o TuxCare CVE Tracker aos seus favoritos. Ele permite filtrar vulnerabilidades por gravidade, produto, componente e status da correção em todos os sistemas em fim de vida útil (EOL) suportados pela TuxCare e suas cadeias de dependências — para que você possa ver exatamente o que está exposto e quando a correção estará disponível. Você também pode se inscrever para receber notificações quando houver alterações no CVE ou no status da correção, o que é muito melhor do que ficar acompanhando manualmente os feeds de alertas em vários produtos em fim de vida útil.

Proteja os sistemas Ubuntu com a TuxCare

O fortalecimento do Ubuntu não é um projeto pontual. Trata-se de um cronograma de atualizações, um bloqueio do SSH, um plano de saída do fim da vida útil (EOL) e o hábito de verificar as configurações padrão em vez de confiar nelas.

Especificamente no que diz respeito às soluções de correção do kernel e cobertura de fim de vida útil (EOL), o KernelCare e o Endless Lifecycle Support da TuxCare preenchem as lacunas deixadas pelas ofertas padrão da Canonical. O KernelCare lida com a aplicação de patches no kernel sem reinicialização, com uma cobertura de CVE mais ampla do que o Livepatch. O ELS mantém o Ubuntu 16.04, 18.04 e 20.04 protegidos com patches de segurança pelo tempo que você precisar, mesmo após o término do período de suporte definido pela Canonical.

Resumo