A maioria dos servidores Linux comprometidos que eu analiso não caiu por uma técnica sofisticada. Caiu por senha de SSH fraca, por serviço exposto que ninguém lembrava que estava ligado, ou por pacote desatualizado que tinha correção publicada havia meses.
Isso é uma boa notícia. Significa que a maior parte do risco de uma pequena empresa se resolve com um punhado de medidas que cabem em uma tarde de trabalho, sem comprar nada.
Por onde começar: o que realmente reduz risco
Existe uma tentação, quando se fala em endurecimento, de sair aplicando dezenas de ajustes de um guia genérico. O resultado costuma ser um servidor difícil de operar e com a mesma superfície de ataque de antes.
A ordem abaixo é por retorno sobre esforço. Se você parar no item 4, já terá eliminado a maior parte do que eu encontro em incidentes reais.
1. Feche a porta da frente: SSH
SSH é o vetor mais explorado em servidor exposto à internet. Bots varrem a porta 22 continuamente, testando credenciais.
Edite /etc/ssh/sshd_config:
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
AllowUsers seu_usuarioAntes de reiniciar o serviço, garanta que sua chave pública já está em ~/.ssh/authorized_keys e abra uma segunda sessão para testar. Trocar autenticação por senha sem ter a chave funcionando é a forma clássica de se trancar do lado de fora.
ssh-copy-id -i ~/.ssh/id_ed25519.pub seu_usuario@servidor
sudo sshd -t
sudo systemctl reload sshdO sshd -t valida a sintaxe antes de aplicar. Use sempre. Um erro de digitação no arquivo de configuração derruba o serviço.
2. Desligue o que você não usa
Todo serviço escutando é uma porta que alguém pode bater. Liste o que está exposto:
sudo ss -tulpn | grep LISTENA pergunta para cada linha é direta: eu sei por que isso está aqui? Se a resposta demorar, provavelmente é resíduo de instalação. Bancos de dados escutando em 0.0.0.0 quando só a própria máquina os consome são o achado mais comum.
3. Firewall com política de negação
Firewall que libera tudo e bloqueia exceções está invertido. O correto é negar por padrão e abrir o necessário.
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80,443/tcp
sudo ufw enable
sudo ufw status verboseSe o servidor tem IP fixo de administração, restrinja o SSH a ele: sudo ufw allow from SEU.IP.FIXO to any port 22. Essa única linha elimina praticamente toda a força bruta automatizada.
4. Atualização automática de segurança
Correção que existe mas não foi aplicada não protege ninguém. Em Debian e Ubuntu:
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgradesDeixe as atualizações de segurança automáticas e as demais sob controle manual. Atualização automática de tudo em servidor de produção é como trocar pneu com o carro andando.
5. Contenha a força bruta
Mesmo com chave, vale limitar tentativas:
sudo apt install fail2ban
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd6. Saiba o que aconteceu depois
Endurecer sem registrar é apostar que nada vai passar. Garanta que os registros sobrevivem e que alguém os lê. Se você já tem um coletor central, aponte para lá. Se ainda não tem, o caminho está descrito em Implementação e Configuração de um SIEM no SOC.
No mínimo, verifique a retenção:
sudo journalctl --disk-usage
sudo nano /etc/systemd/journald.conf # Storage=persistentChecklist de conferência
| Item | Como confirmar |
|---|---|
| Login de root por SSH desativado | sudo sshd -T | grep permitrootlogin |
| Autenticação por senha desativada | sudo sshd -T | grep passwordauthentication |
| Firewall ativo e negando por padrão | sudo ufw status verbose |
| Nenhum serviço inesperado escutando | sudo ss -tulpn | grep LISTEN |
| Atualizações de segurança automáticas | systemctl status unattended-upgrades |
| Registros persistentes | sudo journalctl --disk-usage |
O que fica de fora deste guia, e por quê
Não incluí SELinux, AppArmor em modo estrito nem auditoria detalhada com auditd. São camadas legítimas e valiosas, mas exigem manutenção contínua. Em uma empresa sem equipe de segurança dedicada, essas medidas costumam ser desligadas no primeiro incidente operacional, e aí o esforço vira zero.
Prefiro seis medidas que continuam de pé daqui a um ano a vinte que serão desfeitas na primeira sexta-feira difícil. Quando houver alguém para cuidar, aí sim vale subir a régua.
O erro mais caro
É achar que endurecimento é projeto com data de fim. Servidor novo entra na rede, alguém libera uma porta para resolver um problema urgente, um serviço é instalado para um teste e fica. A superfície de ataque volta a crescer sozinha.
Coloque a conferência do checklist acima em uma rotina trimestral. Leva quinze minutos por servidor e é a diferença entre estar protegido e ter estado protegido uma vez.