Pontos principais
- Aplique os patches de segurança rapidamente: servidores Linux sem patches são uma das principais causas de malware, violações de dados e falhas de conformidade.
- Desative o login como root e a autenticação SSH por senha em favor de pares de chaves SSH, e mantenha o próprio OpenSSH atualizado — uma falha de 2024 (regreSSHion) permitia acesso root sem autenticação em versões sem patch.
- Mantenha o sudo atualizado para proteger o root contra vulnerabilidades na opção chroot do sudo nas versões afetadas.
- Configure um firewall (firewalld ou ufw) para bloquear todo o tráfego, exceto o que for explicitamente permitido.
- Limite a quantidade de pacotes instalados e de serviços em execução para reduzir a superfície de ataque.
O hardening de servidor Linux consiste em fortalecer e proteger um servidor Linux contra vulnerabilidades e ameaças. Este artigo mostra os passos fundamentais para fazer o hardening de um servidor Linux em 2026 por meio de patches, controle de acesso, segurança do SSH e do sudo, firewalls e monitoramento.
Para ver este conteúdo na prática, assista ao nosso vídeo curto: Como proteger seu servidor Linux.
Nenhum risco de segurança é pequeno demais para ser ignorado
Infelizmente, até as menores vulnerabilidades podem virar ameaças sérias de segurança. Vale lembrar: qualquer código em execução no sistema pode conter falhas que permitam a invasores acessar um shell de comandos ou a usuários legítimos sem privilégios elevar seu acesso a superusuário.
Por menor que seja o nível de risco, o melhor é sempre resolver os riscos menores de segurança antes que eles se tornem grandes ameaças, seguindo um processo de hardening de servidores bem estabelecido. Com o hardening de servidor Linux, as equipes de TI reforçam suas defesas antes que surjam ameaças sérias, o que ajuda a evitar problemas graves logo de início.
Atualizações do sistema e patches de segurança
Atualizar o servidor Linux com frequência é essencial para manter a segurança e a saúde geral dele, sobretudo porque controles e práticas de segurança frágeis são explorados rotineiramente por agentes de ameaças, segundo a Cybersecurity & Infrastructure Security Agency (CISA). Softwares e sistemas operacionais são constantemente aprimorados para corrigir vulnerabilidades e pontos fracos.
Ao aplicar as atualizações rapidamente, você garante que falhas conhecidas de segurança sejam corrigidas, reduzindo o risco de exploração por ameaças cibernéticas. Além disso, as atualizações costumam trazer correções de bugs e melhorias de desempenho, resultando em um ambiente de servidor mais estável e eficiente. Deixar de atualizar com regularidade expõe o sistema a possíveis ataques e compromete sua integridade.
Os riscos de vulnerabilidades de software sem patch incluem:
- Malware: códigos maliciosos, como o ransomware, estão entre as maiores ameaças à segurança cibernética. Segundo a Cybersecurity Ventures, o cibercrime custou US$ 10,5 trilhões ao mundo em 2025 e continua crescendo.
- Violações de dados: o Cost of Data Breach Report de 2026 da IBM aponta que o custo médio global de uma violação de dados chegou a US$ 4,99 milhões neste ano, alta de 12% e novo recorde, impulsionada em grande parte por incidentes relacionados à IA.
- Problemas de conformidade: aplicar patches com regularidade ajuda a manter a conformidade com diversas exigências regulatórias, como PCI-DSS, HIPAA e GDPR.
- Queda de produtividade: software sem patch pode afetar a eficiência operacional e expor a organização a ameaças cibernéticas. Os patches não corrigem apenas vulnerabilidades de segurança: também resolvem bugs que prejudicam o desempenho.
Os patches valem também para as próprias ferramentas de segurança, não só para o sistema operacional e os aplicativos. Veja as seções sobre sudo e SSH mais adiante, com dois exemplos de 2025 em que as ferramentas de hardening recomendadas neste guia precisaram dos próprios patches.
Escolher as estratégias certas e as melhores práticas para o gerenciamento de patches do servidor é fundamental para manter um servidor Linux seguro. As distribuições Linux corporativas atuais costumam oferecer algum serviço de gerenciamento automatizado de patches, seja por assinatura paga, seja por esforço da comunidade. Os serviços pagos muitas vezes vão além de simplesmente aplicar patches nos arquivos do sistema: alguns incluem live patching do kernel em execução, o que mantém os sistemas corrigidos antes mesmo de precisar reiniciá-los.
Introdução aos gerenciadores de pacotes
Os gerenciadores de pacotes variam entre as distribuições, mas tendem a usar dois formatos principais: DEB e RPM. O DEB é usado em sistemas baseados em Debian e gerenciado pelo apt; RPM significa Redhat Package Manager e é gerenciado pelo dnf ou yum em sistemas baseados em Red Hat/Enterprise Linux, ou pelo zypper no SUSE. Todos os gerenciadores de pacotes facilitam instalar, atualizar e remover pacotes de software, além de resolver dependências.
Use os gerenciadores de pacotes para administrar softwares com eficiência e simplificar o processo de atualização. Todos os principais gerenciadores também têm suporte a repositórios remotos, o que permite centralizar o controle de atualizações e distribuições de software.
Configuração de atualizações automáticas para patches críticos de segurança
Configurar o servidor Linux para instalar automaticamente os patches críticos de segurança garante que as atualizações de alta prioridade sejam aplicadas rapidamente, sem intervenção manual, o que reduz a janela de vulnerabilidade e a carga sobre os administradores. As distribuições corporativas normalmente permitem configurar isso durante a instalação. Veja os pacotes de configuração abaixo; mas, se quiser configurar no sistema já existente:
Ubuntu: sudo apt install unattended-upgrades
Red Hat/CentOS: sudo yum install dnf-automatic
SUSE: sudo zypper install yast2-online-update-configuration -> abra o YaST, selecione Software -> Configuração da Atualização Online e ajuste conforme sua preferência.
Ainda assim, tenha cautela ao ativar atualizações automáticas: elas podem afetar a estabilidade do sistema ou exigir testes de compatibilidade. Os testes são especialmente importantes ao usar ferramentas de administração remota em massa, como Ansible ou Puppet, para atualizar servidores em um ambiente computacional heterogêneo.
Configuração da elevação de sudo e do acesso ao shell
Configurar corretamente as contas de usuário e as permissões é essencial para ter um sistema seguro que ainda assim permita o acesso certo. Permissões mal configuradas causam problemas, então o ideal é garantir que estejam corretas desde o início.
Usar o comando sudo em todo o seu potencial, com a configuração adequada em /etc/sudoers, permite limitar e conceder direitos de acesso root sem senha por aplicativo. Use sempre o comando visudo para editar o /etc/sudoers, pois ele mantém as permissões corretas nesse arquivo crítico:
sudo visudo
Faça alterações parecidas com estas, substituindo ninja pelo seu nome de usuário e ajustando a lista de comandos permitidos, separados por vírgula, ao seu caso de uso:
someuser ALL=(ALL:ALL) ALL
para
someuser ALL = NOPASSWD: /bin/systemctl restart nginx, /bin/kill, /usr/sbin/reboot
Depois salve e saia. Observe que o sudo lê o arquivo /etc/sudoers de baixo para cima, então, se suas alterações parecerem não surtir efeito, tente mover a linha editada para perto do fim do arquivo sudoers.
Configurar o sudo corretamente não basta: o próprio sudo precisa estar atualizado. Em meados de 2025, uma vulnerabilidade crítica (CVE-2025-32463, CVSS 9.3) permitia que qualquer usuário local sem privilégios chegasse ao root pela opção -R/--chroot do sudo, sem precisar de nenhuma regra no sudoers concedendo acesso. A falha afetou as versões 1.9.14 a 1.9.17 do sudo e foi corrigida na 1.9.17p1. Verifique sua versão e atualize se necessário:
sudo --version
Se estiver em uma versão afetada e não puder atualizar de imediato, desativar o recurso chroot (Defaults !use_chroot no sudoers) elimina esse caminho de ataque até que o patch seja aplicado.
Uma palavra sobre shells
Você pode definir o shell padrão de um usuário executando o comando chsh como root, ou em massa editando o arquivo /etc/passwd como root. Isso é útil e desejável em alguns casos, como ao mudar o shell padrão de uma conta exclusiva de FTP para /sbin/nologin — afinal, essa conta nunca deveria precisar executar comandos de terminal. Remover o acesso ao shell nesse caso reduz a possível superfície de ataque do sistema.
Proteção do acesso SSH com chaves e desativação do login como root
O Secure Shell (SSH) é um protocolo de rede padrão do setor que permite acesso remoto a um sistema em nível de linha de comando. Há uma convicção firme entre profissionais de tecnologia de que o acesso ao shell deve, por design, equivaler a “como se você estivesse local”, então é fundamental limitar o acesso SSH apenas aos usuários necessários e garantir que só os usuários certos possam executar ações como root.
Antes de tudo, confirme que seu servidor OpenSSH está atualizado. Em julho de 2024, uma vulnerabilidade crítica apelidada de “regreSSHion” (CVE-2024-6387) permitia execução remota de código em nível root, sem autenticação, em sistemas Linux baseados em glibc rodando OpenSSH 8.5p1 a 9.8p1. Sem nenhuma interação do usuário. A correção veio no OpenSSH 9.8p1. Confirme sua versão e atualize antes de confiar em qualquer uma das etapas de configuração abaixo:
ssh -V
Melhores práticas para proteger o acesso SSH a servidores Linux
Em geral, é uma boa ideia desativar por completo tanto o login como root via SSH quanto o acesso SSH por senha. Embora o texto da senha na autenticação por senha seja transmitido de forma criptografada pelas chaves de host SSH trocadas durante o handshake cliente/servidor anterior ao login, a senha ainda assim trafega por várias redes de alguma forma. Esse é mais um aspecto da superfície de ataque: se as chaves de host do seu servidor SSH foram geradas com um algoritmo antigo ou inseguro, por exemplo, suas senhas podem ser interceptadas.
Logins por chave SSH não são vulneráveis a esse tipo de ataque: só as chaves públicas são transmitidas em “texto puro”, e elas foram projetadas para distribuição pública. Assim como a chave privada em si, a frase secreta usada para desbloqueá-la no login por chave SSH não é transmitida pela rede.
Use chaves SSH para autenticação
Observe que os trechos de código abaixo trazem comentários do autor indicados por “##”, a título de instrução.
- Gere uma chave SSH com o comando ssh-keygen e a flag -t ed25519 — o Ed25519 é mais rápido e mais seguro que o formato RSA, mais antigo, e é o padrão do ssh-keygen desde o OpenSSH 9.5 (2023).
user@host:~> ssh-keygen -t ed25519 Generating public/private ed25519 key pair. Enter file in which to save the key (/home/user/.ssh/id_ed25519): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_ed25519 Your public key has been saved in /home/user/.ssh/id_ed25519.pub The key fingerprint is: SHA256:NjPk3GbSIL6wdITiSrEQ3U9uXqqaYJdtS62cwCahKoM user@host The key's randomart image is: +--[ED25519 256]--+ |.. . | | .. ... | |... .+o o | |..o. o+=.+ | | +. ooooS = | |o.o.o++o B | |=o *.=.. | |E.+.* + | |o.o. = | +----[SHA256]-----+ user@host:~>
- Copie sua chave pública para a plataforma de hospedagem online. Se ainda tiver acesso por senha ao servidor em questão, use o comando ssh-copy-id para configurar automaticamente os arquivos de configuração SSH da conta remota, com a chave SSH recém-gerada copiada para os lugares certos:
ssh-copy-id -i ~/.ssh/id_ed25519.pub remoteuser@remotehost
- Formas de usar chaves SSH para fazer login:
A) Direto na linha de comando:
ssh -i ~/.ssh/id_ed25519 remoteuser@remotehost:port
B) Usando o arquivo ~/.ssh/config (veja os passos abaixo)
- Edite o arquivo ~/.ssh/config com qualquer editor de texto. Faça isso com a conta/usuário que vai usar a configuração SSH para conectar remotamente.
- Adicione blocos no seguinte formato:
Host server1 ## Arbitrary label/handle for easy usage Hostname server1.example.com ## Real hostname/IP User remote_user_1 ## Remote Linux username Port 12345 ## Remote port, default 22 IdentityFile ~/.ssh/id_ed25519 ## NB! Private key file ForwardX11 yes ## Optional, forwards remote GUI apps Host server2 Hostname server2.example.com User remote_user_2 Port 34567 IdentityFile ~/.ssh/id_ed25519
Deve haver uma linha em branco entre os blocos. - Agora basta digitar:
ssh server1
Como todo o resto fica especificado sob aquele rótulo de bloco no arquivo .ssh/config, agora basta digitar ssh server1 para conectar. (Deve haver uma linha em branco entre os blocos.) Dica: se você adotou o autocompletar com Tab no Linux (o bash completion), vai gostar de saber que seu arquivo de configuração SSH se integra automaticamente ao sistema bash-completion da maioria das distribuições Linux modernas.
Desative o login como root e a autenticação por senha no SSH
- Tenha ABSOLUTA CERTEZA de que consegue fazer login com sua chave SSH. Se isso não estiver funcionando direito, você pode acabar bloqueado para fora do próprio sistema.
- Use seu editor favorito como root para alterar as linhas a seguir em /etc/ssh/sshd_config para estas configurações:
PermitRootLogin no ChallengeResponseAuthentication no PasswordAuthentication no KbdInteractiveAuthentication no
- Opcionalmente, faça o servidor SSH rodar em uma porta não padrão:
Port 12345
- Salve o arquivo e recarregue o serviço SSH:
sudo systemctl restart sshd
- Agora tente fazer login via SSH sem a chave SSH:
ssh remote_user_1@server1 [-p port]
Se não conseguir entrar sem especificar uma chave SSH, essa etapa foi concluída corretamente.
Implementação de um firewall em servidores Linux
Se você opera um servidor Linux de produção e sua distribuição já vem com um firewall pré-configurado, ótimo começo. Sempre que dados de um servidor de produção ficam expostos à internet, o melhor é protegê-los com um firewall. As variantes Enterprise Linux/Red Hat costumam vir com o firewalld, enquanto Debian/Ubuntu trazem o ufw (“Uncomplicated Firewall”). Consulte man firewall-cmd ou man ufw para detalhes.
Configuração de regras e políticas de firewall
Firewall: as regras e políticas, passados os detalhes, se resumem a “bloquear tudo, exceto o que eu permitir explicitamente” — e, de novo, isso normalmente já vem pré-configurado com padrões sensatos nos sistemas Linux modernos, principalmente nas variantes Enterprise Linux. Casos de uso não cobertos por esses padrões ficam fora do escopo deste documento.
Monitoramento e gerenciamento do firewall
- Tanto o firewalld quanto o ufw se integram aos principais sistemas de registro de logs, journald e/ou [r]syslog.
- Além das ferramentas de linha de comando firewall-cmd e ufw, outras interfaces de gerenciamento remoto, como Cockpit, WebMin e YaST, oferecem módulos para administrar o firewall. Outras ferramentas de gerenciamento remoto, como Ansible e Puppet, também têm módulos para configuração e gerenciamento automáticos do firewall.
Proteção dos serviços expostos à rede
Melhores práticas para proteger serviços expostos à rede:
- Mantenha o mínimo possível de código no sistema.
- Execute a menor quantidade possível de serviços.
- Não execute um serviço voltado ao público como root.
- Servidores não precisam de interface gráfica. Código supérfluo e serviços em execução = mais superfície de ataque.
- Os serviços Linux dependem de você proteger o sistema com certificados de criptografia. O Certbot/Let’s Encrypt tem o processo mais simples para gerar certificados de criptografia gratuitos.
- A maioria dos serviços Linux escuta em portas separadas para conexões seguras e inseguras; consulte as páginas man dos serviços para detalhes sobre segurança e outras opções de configuração.
- Use o comando ss para ver em quais portas o sistema está escutando (estejam elas bloqueadas ou não pelo firewall; a saída mostra as portas de escuta por processo): ss -tulpn
Importante: netstat, em que esse comando rodava antes, está obsoleto e muitas vezes já não vem instalado por padrão nas distribuições atuais (não está incluído nas instalações mínimas do RHEL 8+ nem em muitas baseadas em Debian). ss é o substituto mantido, lê o estado dos sockets direto do kernel e usa o mesmo esquema de flags mostrado acima.
Mantenha o hardening em dia
Fazer o hardening de um servidor Linux não é uma tarefa única: as configurações mudam com o tempo conforme usuários, softwares e regras de firewall se alteram, então vale incorporar alguns hábitos contínuos ao processo:
- Ative o controle de acesso obrigatório.
- Centralize os logs.
- Verifique se o hardening realmente surtiu efeito.
- Baseie sua lista de verificação em um padrão reconhecido.
- Faça revisões periódicas, não só na configuração inicial.
Instale apenas os pacotes de terceiros necessários
Limite a quantidade de pacotes ou aplicativos de terceiros instalados no servidor Linux. Como em qualquer download, mantenha bons hábitos de higiene cibernética para reduzir o risco de ameaças e deixar o servidor o mais saudável possível.
Uma dica simples e poderosa: instale pacotes de servidor vindos de fontes confiáveis e que serão usados com regularidade. Esse último ponto merece destaque! Mesmo que o pacote venha de um fornecedor confiável, ele continua sujeito a riscos se não for usado com frequência (sem falar no espaço que ocupa no servidor).
Use o fail2ban
O fail2ban é um utilitário de segurança autorregulado para Linux que verifica automaticamente o servidor em busca de ataques digitais automatizados e os bloqueia. A configuração do fail2ban é simples:
sudo apt install fail2ban -y
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo service fail2ban restart
Depois é só configurar o utilitário do seu jeito. De todo modo, o fail2ban avisa sobre múltiplas tentativas de login nos servidores remotos e bloqueia esses endereços. Com o tempo, dá para examinar os arquivos de log e ver a lista completa de IPs banidos.
Implemente a autenticação de dois fatores
A autenticação de dois fatores (2FA) é indispensável para proteger servidores Linux. Em essência, é um sistema de segurança que verifica o usuário duas vezes antes de liberar o acesso a um sistema ou conta.
Para configurar a 2FA no servidor Linux, comece instalando um pacote de autenticação. Dependendo do pacote escolhido, essa camada extra de segurança pode ir de uma chave de segurança a fatores de autenticação biométrica.
Trabalhe com uma empresa confiável de gerenciamento de endpoints
Você sempre pode verificar manualmente se há vulnerabilidades no servidor Linux. Ainda assim, pode ser mais econômico contar com uma empresa confiável de gerenciamento de endpoints, como a NinjaOne, para monitorar, gerenciar e dar suporte aos seus dispositivos Linux a partir de um painel único.
Para a segurança de servidores Linux, o minimalismo importa tanto quanto a ação
Nenhuma ação posterior substitui boas escolhas desde o começo — no mundo conectado à nuvem de hoje, a escolha da distribuição Linux do servidor e das soluções de gerenciamento remoto pesa mais do que nunca. O software de gerenciamento remoto para Linux integrado ao NinjaOne dá liberdade para gerenciar endpoints Windows, macOS e Linux em uma única plataforma, mantendo todos seguros e com os patches em dia.
É seguro dizer que a infraestrutura de tecnologia da maioria das PMEs inclui servidores Linux como parte da infraestrutura crítica. Se você tem um site, é bem provável que ele rode em um servidor Linux; se usa internet banking, é provável que ele dependa da segurança de dezenas de servidores Linux. Considerando que o próprio Android é (de forma grosseiramente simplificada) um kernel Linux com uma camada gráfica por cima, se você está lendo isto em um smartphone, a questão da segurança no Linux talvez esteja literalmente mais perto de você do que imagina.
