Um servidor Linux novo, exposto na internet sem configuração adicional, começa a receber tentativas de acesso não autorizado em minutos. Não é exagero. Logs de autenticação SSH de qualquer VPS recém-criada com senha habilitada mostram centenas de tentativas por hora, vindas de endereços distribuídos pelo mundo. Bots fazem esse trabalho de forma contínua e automática, testando combinações de usuário e senha em toda faixa de IP alocável. A questão não é se o seu servidor vai ser alvo — é se ele vai resistir quando chegar a vez dele.
Resumo rápido: Hardening de Linux é o conjunto de configurações que reduz a superfície de ataque de um servidor: desabilitar autenticação por senha, bloquear acesso root direto, configurar firewall, instalar ferramentas de detecção de intrusão e automatizar atualizações. Cada medida sozinha reduz risco. Combinadas, elas tornam a invasão suficientemente custosa para que o atacante siga em frente para um alvo mais fácil.
Por que a ameaça é maior do que parece
A imagem popular de invasão de servidor envolve um hacker experiente mirando especificamente na sua empresa. Na prática, a maior parte das invasões bem-sucedidas de servidores pequenos e médios não é assim. São bots automatizados que varrem blocos de IP em busca de portas abertas, testam credenciais comuns e exploram versões antigas de software com vulnerabilidades conhecidas.
O modelo é de volume: atacar milhares de servidores ao mesmo tempo com esforço mínimo por alvo. Quando encontram um aberto, entram, instalam um cryptominer, um relay de spam ou um nó de botnet, e seguem em frente. A sua empresa pode não ser o alvo final. Você é a porta de entrada.
O outro vetor que costuma surpreender é o erro interno: um desenvolvedor que faz chmod 777 -R /var/www para resolver um problema de permissão às pressas, deixando arquivos de configuração legíveis por qualquer processo. Ou uma porta de banco de dados aberta no firewall "temporariamente" para debug que nunca foi fechada.
SSH key-only: a primeira linha que não pode faltar
A porta 22 com autenticação por senha é o vetor de ataque mais explorado em servidores Linux. A solução é direta: desabilitar completamente a autenticação por senha e exigir chaves SSH.
O processo envolve três etapas. Primeiro, gere um par de chaves no seu computador local com ssh-keygen -t ed25519. Segundo, copie a chave pública para o servidor com ssh-copy-id. Terceiro, edite /etc/ssh/sshd_config e defina PasswordAuthentication no e PermitRootLogin no. Reinicie o serviço SSH.
A partir daí, sem a chave privada correspondente, ninguém entra via SSH independentemente de quantas combinações de senha testem. Os bots param de aparecer nos logs de autenticação em questão de minutos após a mudança, porque as tentativas retornam erro imediatamente sem processar a senha.
Dois cuidados práticos: não feche a sessão SSH atual antes de verificar que a nova chave funciona em outra sessão. E armazene o backup da chave privada em local seguro — perder a chave significa perder o acesso ao servidor.
Usuário non-root: separação de privilégios que protege o sistema
Operar o servidor diretamente como root é o equivalente a trabalhar em produção com usuário admin o tempo todo: qualquer erro de digitação, qualquer script malicioso executado inadvertidamente, qualquer vulnerabilidade explorada tem acesso irrestrito a todo o sistema.
O padrão correto é criar um usuário comum com nome não óbvio (evite ubuntu, admin, deploy — são os primeiros testados) e dar acesso sudo apenas para os comandos que esse usuário precisa. Para operações rotineiras, o usuário não precisa de sudo em nada. Para atualizações e manutenção, usa sudo com autenticação.
O PermitRootLogin no no sshd_config fecha o acesso root via SSH. Qualquer acesso ao root precisa passar pelo usuário intermediário com sudo, criando uma camada de auditoria.
Fail2ban e CrowdSec: detecção e bloqueio de intrusão
Mesmo com SSH key-only, é útil ter uma camada que detecta padrões anômalos e bloqueia automaticamente.
Fail2ban lê logs de autenticação e bloqueia IPs que excedem um número configurável de tentativas falhas em determinado período. Funciona para SSH, Nginx, Apache, Postfix e qualquer serviço que gera log de autenticação. A configuração padrão já protege SSH. Customizações permitem proteger painéis administrativos, APIs e qualquer serviço com autenticação.
CrowdSec é mais sofisticado: além de detectar ataques localmente, ele compartilha informações de IPs maliciosos com uma rede comunitária. Quando um IP ataca um servidor da rede CrowdSec, todos os outros servidores participantes aprendem sobre ele. É detecção de ameaça distribuída com overhead mínimo no servidor.
Os dois podem coexistir. Fail2ban para reação local rápida; CrowdSec para inteligência de ameaça coletiva.
UFW: firewall que a maior parte das pessoas nunca configura
Distribuições Linux modernas vêm com iptables disponível, mas a configuração direta do iptables é complexa o suficiente para dissuadir a maioria. O UFW (Uncomplicated Firewall) é uma interface que simplifica a criação de regras.
A configuração base é simples: nega todo tráfego de entrada por padrão, permite apenas as portas que os seus serviços precisam.
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp # SSH (ou a porta personalizada que você configurou)
ufw allow 80/tcp # HTTP
ufw allow 443/tcp # HTTPS
ufw enable
Qualquer porta que não está explicitamente liberada é bloqueada. Banco de dados (3306, 5432), Redis (6379), painéis administrativos — nada disso deve estar acessível pela internet. Se um serviço interno precisa se comunicar com outro, use rede Docker interna ou VPN, não abra a porta no firewall público.
O erro do chmod 777 e outros deslizes de permissão
Permissões de arquivo são o tipo de configuração que ninguém toca quando tudo funciona e todo mundo mexe quando tem problema. O resultado são servidores onde chmod 777 virou solução padrão para erro de permissão.
O problema do chmod 777 é que ele dá permissão de leitura, escrita e execução para qualquer usuário do sistema. Em um servidor web, isso significa que um arquivo de configuração com credenciais de banco de dados fica legível por qualquer processo que rode no servidor — incluindo código malicioso injetado via vulnerabilidade na aplicação.
O padrão correto: arquivos de configuração devem ser legíveis apenas pelo usuário que roda a aplicação (chmod 640 ou chmod 600). Diretórios web devem ter dono do serviço web, não root. Credenciais devem estar em variáveis de ambiente ou em arquivos de configuração fora do document root do servidor web.
A checagem periódica de arquivos com permissões excessivas é parte do hardening contínuo, não uma tarefa pontual — é o tipo de auditoria que o departamento de DevOps da MaxVision inclui no processo de entrega de servidor novo.
Atualizações automáticas: o patch que ninguém aplica
Boa parte das invasões bem-sucedidas explora vulnerabilidades com patch disponível há semanas ou meses. O ataque funciona porque o servidor nunca foi atualizado.
O Ubuntu e derivados têm o pacote unattended-upgrades que aplica atualizações de segurança automaticamente sem intervenção manual. Ele pode ser configurado para aplicar apenas patches de segurança (mais conservador) ou todas as atualizações disponíveis.
A resistência comum a atualizações automáticas é o medo de quebrar algo. Esse medo é legítimo para atualizações de versão major de pacotes, mas não para patches de segurança que corrigem vulnerabilidades sem alterar interfaces. A configuração padrão do unattended-upgrades aplica apenas os patches de segurança, que têm política conservadora de compatibilidade.
Para servidores de produção críticos onde qualquer mudança precisa ser testada, a alternativa é configurar alertas automáticos de atualização disponível e manter um processo de aplicação regular — semanal ou quinzenal — em horário de menor tráfego.
Tabela: vetor de ataque, proteção e esforço
| Vetor de ataque | Proteção | Esforço de implementação |
|---|---|---|
| Força bruta SSH com senha | SSH key-only + PermitRootLogin no | Baixo — 30 minutos |
| Acesso direto como root | Usuário non-root + sudo restrito | Baixo — 20 minutos |
| Tentativas de login repetidas | Fail2ban + CrowdSec | Baixo — 1 hora |
| Portas desnecessárias expostas | UFW com deny incoming por padrão | Baixo — 30 minutos |
| Exploração de software desatualizado | unattended-upgrades ativo | Baixo — 15 minutos |
| Permissões excessivas em arquivos | Auditoria de chmod e chown | Médio — 2-4 horas por servidor |
| Credenciais expostas em arquivos | Variáveis de ambiente + fora do webroot | Médio — depende do número de serviços |
| Ausência de detecção pós-intrusão | Auditd + OSSEC ou similar | Alto — requer configuração e análise contínua |
Backup criptografado: a última linha quando tudo mais falha
Hardening reduz a probabilidade de invasão. Não a elimina. Há cenários fora do controle de qualquer configuração de segurança: zero-days em software que você usa, credenciais comprometidas em outra camada, erro humano. Para esses cenários, o backup é o que determina se um incidente é recuperável ou catastrófico.
Backup útil para este contexto tem três propriedades:
Criptografado. Dados de backup não criptografados que vazam são tão problemáticos quanto o incidente original. Ferramentas como Restic criptografam os dados antes de enviá-los ao destino, seja um bucket S3, Backblaze B2 ou outro servidor.
Testado. Backup não testado é backup de decoração. O teste mínimo é restaurar periodicamente em um ambiente diferente e verificar que os dados estão íntegros e que a aplicação sobe.
Offsite. Backup no mesmo servidor que está comprometido não serve. O destino do backup precisa ser um local separado e com acesso restrito — preferencialmente somente escrita para a chave usada pelo processo de backup, de forma que um invasor que comprometa o servidor não consiga deletar os backups.
A regra 3-2-1 resume bem: três cópias dos dados, em dois tipos de mídia diferentes, com uma cópia em local físico diferente.
O que fazer imediatamente em um servidor novo
Para um servidor recém-criado, a ordem de operações que cobre o essencial:
Primeiro, atualiza todos os pacotes existentes antes de qualquer outra coisa. Segundo, cria usuário non-root com chave SSH configurada e verifica acesso antes de qualquer alteração no SSH. Terceiro, desabilita autenticação por senha e root no SSH. Quarto, configura UFW com regras mínimas. Quinto, instala e configura fail2ban para SSH. Sexto, ativa unattended-upgrades para patches de segurança. Sétimo, configura backup automatizado com Restic ou ferramenta equivalente para destino offsite.
Esse conjunto cobre os vetores mais explorados contra servidores Linux expostos na internet. Leva algumas horas na primeira vez, menos em servidores subsequentes quando o processo está documentado.
Perguntas Frequentes
Mudar a porta padrão do SSH de 22 para outra melhora a segurança?
Reduz o volume de tentativas nos logs porque a maioria dos bots testa apenas a porta 22. Mas não é uma medida de segurança real: qualquer scanner de portas encontra a porta alternativa em segundos. Trocar a porta é uma medida de conforto operacional — menos ruído nos logs — não uma defesa. Não substitui autenticação por chave nem fail2ban.
O servidor tem vulnerabilidade se eu não usar firewall mas fechar as portas nas configurações de cada serviço?
É melhor que nada, mas não é equivalente. Configurações de serviço podem ter bugs, ser sobrescritas por atualizações ou mal interpretadas. O firewall opera em camada diferente e não depende do comportamento do serviço. A defesa em profundidade recomenda os dois: fechar no nível do serviço e bloquear no firewall.
fail2ban ou CrowdSec: preciso de ambos?
Para a maior parte das operações, um dos dois é suficiente para começar. O fail2ban é mais simples de configurar e cobre o caso de uso básico. O CrowdSec tem mais recursos e a inteligência coletiva de ameaças, mas tem curva de aprendizado maior. A escolha depende do tempo disponível para configuração e da complexidade do ambiente.
Como saber se o servidor já foi comprometido?
Sinais comuns incluem: CPU ou banda de rede anormalmente altos sem explicação, processos desconhecidos rodando, novos usuários criados, entradas estranhas no crontab, arquivos novos em /tmp ou diretórios temporários. O comando last mostra logins recentes. O netstat -tlnp ou ss -tlnp mostra portas abertas e o processo associado. Para análise forense mais profunda, ferramentas como rkhunter e chkrootkit verificam sinais de rootkit.
Preciso de hardening mesmo em servidor de desenvolvimento ou staging?
Sim, mas o nível pode ser menor. Servidores de desenvolvimento frequentemente têm credenciais reais de banco de dados, tokens de API e acesso a ambientes de produção via SSH. Um servidor de staging comprometido pode ser a porta de entrada para produção. O mínimo — SSH key-only, UFW e atualizações automáticas — deve ser aplicado em qualquer servidor exposto na internet.
Conclusão
Hardening de Linux não é uma tarefa opcional para "quando sobrar tempo". É o requisito mínimo para qualquer servidor exposto na internet. As medidas básicas — SSH key-only, usuário non-root, fail2ban, UFW e atualizações automáticas — têm custo de implementação baixo e reduzem dramaticamente a superfície de ataque. O backup criptografado offsite garante que, no pior cenário, a recuperação é possível.
O erro mais comum não é não saber como fazer hardening: é não fazer porque parece complicado no início. Com processo documentado, um servidor novo pode sair do zero para hardened em algumas horas.
Infraestrutura que segue esse padrão — hardening documentado, backup testado em destino offsite, monitoramento ativo desde o primeiro servidor — é o que o departamento de DevOps da MaxVision entrega, com checklist de segurança e runbook de incidente em cada entrega. Quando quiser revisar o estado atual da sua operação, abra uma conversa.
