Segurança Linux: Como Fazer o Hardening de um Servidor em Produção

Um servidor Linux exposto na Internet recebe suas primeiras tentativas de invasão nos minutos seguintes à sua entrada no ar: varreduras de portas, tentativas de senha SSH, exploração de serviços mal configurados. A boa notícia é que um punhado de medidas simples elimina a imensa maioria desses ataques oportunistas. Neste guia, fazemos o hardening de um servidor passo a passo: SSH, firewall, fail2ban, atualizações automáticas, permissões, auditoria e monitoramento de portas. Cada seção traz os comandos exatos, testados em Debian/Ubuntu e Rocky Linux/Fedora. Um checklist de resumo encerra o artigo.

1. Hardening do SSH

O SSH é a principal porta de entrada do seu servidor e, portanto, o alvo número um. Três medidas são indispensáveis: autenticação por chaves, desativação do login como root e desativação das senhas.

Autenticação por chaves

# Na sua máquina local: gerar um par de chaves ed25519
ssh-keygen -t ed25519 -C "admin@poste-travail"

# Copiar a chave pública para o servidor
ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@serveur.exemple.com

# Verificar a conexão por chave ANTES de desativar as senhas
ssh -i ~/.ssh/id_ed25519 admin@serveur.exemple.com

Configuração do daemon SSH

Edite /etc/ssh/sshd_config (ou, melhor ainda, crie um arquivo em /etc/ssh/sshd_config.d/):

# /etc/ssh/sshd_config.d/10-durcissement.conf

# Proibir o login direto como root
PermitRootLogin no

# Desativar a autenticação por senha: somente chaves
PasswordAuthentication no
KbdInteractiveAuthentication no

# Limitar os usuários autorizados a se conectar
AllowUsers admin deploy

# Reduzir a janela de autenticação e o número de tentativas
LoginGraceTime 30
MaxAuthTries 3

# Desconectar sessões inativas após 15 minutos
ClientAliveInterval 300
ClientAliveCountMax 3

# Validar a sintaxe antes de recarregar: um erro pode deixar você trancado do lado de fora
sudo sshd -t

# Recarregar a configuração
sudo systemctl reload ssh     # Debian/Ubuntu
sudo systemctl reload sshd    # Rocky/Fedora

Mantenha sempre uma sessão SSH aberta enquanto testa a nova configuração em um segundo terminal. Se a nova sessão falhar, você pode corrigir o problema a partir da primeira.

Mudar a porta: útil, mas não suficiente

Mover o SSH da porta 22 para uma porta fora do padrão não protege contra um atacante direcionado, mas reduz drasticamente o ruído das varreduras automáticas nos seus logs.

# Dans /etc/ssh/sshd_config.d/10-durcissement.conf
Port 2222

Não se esqueça de abrir essa porta no firewall antes de recarregar o SSH e de informá-la depois na conexão: ssh -p 2222 admin@serveur.

2. Firewall: ufw e firewalld

O princípio: bloquear tudo na entrada por padrão e abrir somente as portas necessárias.

ufw (Debian/Ubuntu)

# Instalar e definir as políticas padrão
sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing

# IMPRESCINDÍVEL: autorizar o SSH antes de ativar o firewall
sudo ufw allow 2222/tcp comment 'SSH'

# Abrir as portas web
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'

# Restringir uma porta a um endereço IP de origem (ex.: banco de dados)
sudo ufw allow from 10.0.0.5 to any port 5432 proto tcp

# Ativar o firewall
sudo ufw enable

# Verificar as regras com seus números
sudo ufw status numbered

# Remover uma regra pelo número
sudo ufw delete 3

firewalld (Rocky Linux/Fedora)

# Verificar se o firewalld está ativo
sudo systemctl enable --now firewalld

# Listar a configuração da zona ativa
sudo firewall-cmd --list-all

# Abrir serviços de forma permanente
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https

# Abrir uma porta personalizada
sudo firewall-cmd --permanent --add-port=2222/tcp

# Remover um serviço aberto por padrão, se for desnecessário
sudo firewall-cmd --permanent --remove-service=cockpit

# Aplicar as mudanças permanentes
sudo firewall-cmd --reload

3. fail2ban: Banindo Atacantes

O fail2ban lê os logs, detecta tentativas repetidas de autenticação e bane o endereço IP infrator por meio do firewall.

# Instalação
sudo apt install fail2ban          # Debian/Ubuntu
sudo dnf install fail2ban          # Rocky/Fedora

Nunca modifique o jail.conf: crie o jail.local, que o sobrescreve.

# /etc/fail2ban/jail.local
[DEFAULT]
# Banir por 1 hora após 5 falhas em 10 minutos
bantime  = 1h
findtime = 10m
maxretry = 5
# Nunca banir seus próprios endereços
ignoreip = 127.0.0.1/8 ::1 203.0.113.10

[sshd]
enabled = true
port    = 2222

# Ativar e verificar
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

# Desbanir um endereço banido por engano
sudo fail2ban-client set sshd unbanip 198.51.100.7

# Hardening progressivo: dobrar a duração a cada reincidência
# (adicionar em [DEFAULT] do jail.local)
# bantime.increment = true
# bantime.maxtime   = 1w

4. Atualizações Automáticas

A maioria dos comprometimentos explora vulnerabilidades que já foram corrigidas. Automatize, no mínimo, as atualizações de segurança.

Debian/Ubuntu: unattended-upgrades

# Instalação e ativação
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

# Verificar a configuração
cat /etc/apt/apt.conf.d/20auto-upgrades
# APT::Periodic::Update-Package-Lists "1";
# APT::Periodic::Unattended-Upgrade "1";

# Testar em simulação
sudo unattended-upgrade --dry-run --debug

No arquivo /etc/apt/apt.conf.d/50unattended-upgrades, você pode ativar a reinicialização automática em horários de baixo uso:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

Rocky/Fedora: dnf-automatic

sudo dnf install dnf-automatic

# Em /etc/dnf/automatic.conf: aplicar apenas as atualizações de segurança
# upgrade_type = security
# apply_updates = yes

sudo systemctl enable --now dnf-automatic.timer

5. Permissões e umask

Verificar os arquivos sensíveis

# Os arquivos de senhas devem ser estritamente protegidos
ls -l /etc/shadow
# Esperado: -rw-r----- root shadow (640) ou mais restritivo

# Encontrar arquivos com permissão de escrita para todos (perigosos)
sudo find / -xdev -type f -perm -0002 -not -path "/proc/*" 2>/dev/null

# Encontrar binários setuid (para auditar regularmente)
sudo find / -xdev -type f -perm -4000 2>/dev/null

# As chaves SSH privadas devem estar em 600
chmod 600 ~/.ssh/id_ed25519
chmod 700 ~/.ssh

umask: as permissões padrão

O umask determina as permissões removidas dos novos arquivos. Com um umask de 022, um arquivo é criado com 644; com 027, com 640 (nenhum acesso para “outros”).

# Verificar o umask atual
umask

# Endurecer para novos arquivos: adicionar em /etc/profile.d/umask.sh
echo "umask 027" | sudo tee /etc/profile.d/umask.sh

umask	Arquivo criado	Diretório criado	Uso
022	644 (rw-r—r—)	755 (rwxr-xr-x)	Valor padrão clássico
027	640 (rw-r-----)	750 (rwxr-x---)	Servidor com hardening (recomendado)
077	600 (rw-------)	700 (rwx------)	Dados estritamente privados

6. auditd: Rastreando Ações Sensíveis

O auditd registra eventos do sistema no nível do kernel: acessos a arquivos críticos, chamadas de sistema, execuções de comandos.

# Instalação
sudo apt install auditd audispd-plugins   # Debian/Ubuntu
sudo dnf install audit                     # Rocky/Fedora
sudo systemctl enable --now auditd

Regras úteis em /etc/audit/rules.d/durcissement.rules:

# Monitorar qualquer modificação em contas e no sudo
-w /etc/passwd -p wa -k comptes
-w /etc/shadow -p wa -k comptes
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers

# Monitorar a configuração do SSH
-w /etc/ssh/sshd_config -p wa -k sshd

# Rastrear os comandos executados como root (arquitetura 64 bits)
-a always,exit -F arch=b64 -F euid=0 -S execve -k commandes_root

# Carregar as regras e verificar
sudo augenrules --load
sudo auditctl -l

# Pesquisar eventos por chave
sudo ausearch -k sudoers --start today

# Relatório resumido das autenticações
sudo aureport -au --summary

7. Monitoramento de Portas: ss e nmap

Visão interna com o ss

# Todas as portas TCP e UDP em escuta, com o processo associado
sudo ss -tulpn

# Somente as portas TCP em escuta
sudo ss -tlnp

# Conexões estabelecidas para o exterior
ss -tn state established

Cada linha de ss -tulpn deve corresponder a um serviço que você conhece e que instalou deliberadamente. Uma porta desconhecida em escuta merece investigação imediata.

Visão externa com o nmap

Faça uma varredura do seu servidor a partir de outra máquina para ver o que um atacante realmente enxerga:

# Varredura das 1000 portas TCP mais comuns
nmap serveur.exemple.com

# Varredura completa de todas as portas TCP com detecção de versão
nmap -p- -sV serveur.exemple.com

# Varredura UDP das portas comuns (lenta, requer root)
sudo nmap -sU --top-ports 50 serveur.exemple.com

Varra apenas máquinas que pertencem a você ou para as quais você tenha autorização por escrito.

Desativar serviços desnecessários

# Listar os serviços ativos
systemctl list-units --type=service --state=running

# Desativar e parar um serviço supérfluo
sudo systemctl disable --now cups

8. O Princípio do Privilégio Mínimo

Cada processo, usuário e serviço deve dispor apenas dos direitos estritamente necessários para a sua função.

# Criar um usuário de sistema sem shell para um serviço de aplicação
sudo useradd --system --no-create-home --shell /usr/sbin/nologin monapp

# Limitar o sudo a um comando específico em vez de ALL
# Em /etc/sudoers.d/deploy (via visudo -f):
# deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart monapp

No nível do systemd, coloque seus serviços em sandbox no arquivo de unidade:

# Trecho de /etc/systemd/system/monapp.service
[Service]
User=monapp
# Impedir a aquisição de novos privilégios
NoNewPrivileges=true
# Sistema de arquivos somente leitura, exceto exceções
ProtectSystem=strict
ReadWritePaths=/var/lib/monapp
# /home inacessível
ProtectHome=true
# /tmp privado
PrivateTmp=true

# Medir a exposição de um serviço (pontuação de 0 a 10, quanto menor, melhor)
systemd-analyze security monapp.service

Por fim, mantenha o SELinux (Rocky/Fedora) ou o AppArmor (Debian/Ubuntu) ativados: eles confinam serviços comprometidos.

# Verificar o estado do SELinux
getenforce
# Esperado: Enforcing

# Verificar o estado do AppArmor
sudo aa-status

9. Checklist de Hardening

Medida	Comando de verificação	Estado esperado
SSH somente por chaves	sudo sshd -T | grep passwordauthentication	passwordauthentication no
Login como root proibido	sudo sshd -T | grep permitrootlogin	permitrootlogin no
Firewall ativo	sudo ufw status ou sudo firewall-cmd --state	active / running
Entradas bloqueadas por padrão	sudo ufw status verbose	deny (incoming)
fail2ban em execução	sudo fail2ban-client status sshd	jail sshd ativa
Atualizações de segurança automáticas	systemctl status unattended-upgrades ou dnf-automatic.timer	ativo
Nenhuma porta inesperada	sudo ss -tulpn	apenas os serviços conhecidos
Nenhum arquivo world-writable	find / -xdev -type f -perm -0002	lista vazia
umask endurecido	umask	0027
auditd em funcionamento	sudo auditctl -l	regras carregadas
SELinux/AppArmor ativo	getenforce / aa-status	Enforcing / perfis carregados
Serviços supérfluos desativados	systemctl list-units --type=service --state=running	lista mínima

Boas práticas

• Teste cada alteração no SSH em uma segunda sessão antes de fechar a primeira: é a sua rede de segurança contra o auto-bloqueio.
• Abra a porta SSH no firewall antes de ativá-lo, nunca depois.
• Adicione seus endereços IP de administração em ignoreip do fail2ban para nunca banir a si mesmo.
• Nunca desative o SELinux ou o AppArmor para “resolver” um problema: corrija a política em vez disso.
• Audite as portas em escuta (ss -tulpn) após cada instalação de software.
• Repita o checklist completo após cada atualização major do sistema.
• Externalize seus logs para um servidor remoto: um atacante que obtém root apaga os rastros locais.
• A segurança é um processo, não um estado: agende uma revisão trimestral deste checklist.

Conclusão

Fazer o hardening de um servidor Linux não exige ferramentas exóticas nem orçamento: SSH restrito a chaves, um firewall em lista de permissões, fail2ban, atualizações automáticas, permissões estritas, auditd e uma revisão regular das portas bastam para afastar quase todos os ataques oportunistas que varrem a Internet o tempo todo. O fio condutor de todas essas medidas é o princípio do privilégio mínimo: todo acesso que não é indispensável é um acesso a ser removido.

Aplique o checklist da seção 9 em cada um dos seus servidores, automatize-o nos seus scripts de provisionamento e você partirá de uma base sólida, que as medidas avançadas (SELinux refinado, logging centralizado, detecção de intrusão) virão reforçar em seguida.