Hardening de VPS (Segurança e Hardening de Linux VPS)

1. Visão geral do conceito e problema sistêmico

Imediatamente após a inicialização de um servidor virtual (VPS) em provedores de nuvem como Hetzner, DigitalOcean ou AWS, a instância é alvo de varreduras por botnets globais nos primeiros 5 a 15 minutos. Por padrão, muitas imagens de SO vêm com autenticação por senha habilitada para o usuário root, portas de serviço abertas e ausência de proteções básicas contra ataques de força bruta.

Hardening de VPS é o conjunto de práticas de engenharia para reforçar a segurança do sistema operacional Linux, alinhado aos padrões CIS Benchmarks (Center for Internet Security). Os objetivos principais são:

• Minimizar a superfície de ataque (Attack Surface).
• Eliminar completamente o acesso via senha através de canais não seguros.
• Isolar a execução de processos que operam com privilégios de superusuário (Root).
• Configurar auditoria de eventos, correção automática de vulnerabilidades de dia zero (0-day) e filtragem de pacotes no nível do kernel.

Estado inicial do VPS (Alto risco):
[Internet] ---> [Porta 22: SSH (Root + Senha)] ---> [Comprometimento total do sistema]

Após o Hardening (Defesa em camadas):
[Internet] ---> [Firewall UFW (Default Deny)]
                     |
                     v
                [Fail2ban (Bloqueio de scanners)]
                     |
                     v
                [SSH: Apenas chaves Ed25519, sudo sem acesso root direto]
                     |
                     v
                [Atualizações automáticas (unattended-upgrades)]

2. Taxonomia arquitetural e modelo mental

O hardening é implementado em quatro planos de segurança isolados:

1. Nível de Autenticação e Controle de Acesso (Identity & Access):
   • Desativação completa do login direto como root via SSH (PermitRootLogin no).
   • Proibição da autenticação por senha (PasswordAuthentication no).
   • Criação de um usuário não privilegiado com obrigatoriedade de pertencimento ao grupo sudo.
   • Instalação de chaves criptográficas Ed25519.
2. Nível de Rede (Network Perimeter):
   • Habilitação do ufw com política de negar todo tráfego de entrada (default deny incoming).
   • Abertura apenas das portas estritamente necessárias (ex.: 2222/tcp, 80/tcp, 443/tcp).
   • Implantação do fail2ban para banir automaticamente hosts que geram requisições anômalas.
3. Nível de Sistema Operacional e Kernel (OS & Kernel):
   • Ajuste fino dos parâmetros sysctl para proteger a pilha de rede (proibição de redirecionamentos ICMP, proteção contra ataques SYN-flood).
   • Ativação de atualizações de segurança estendidas (unattended-upgrades).
4. Nível de Aplicação e Ambiente de Execução (Runtime Isolation):
   • Execução de contêineres Docker e agentes de IA sob UID/GID não privilegiados distintos, sem acesso ao /var/run/docker.sock.

3. Pipeline técnico e mecânica interna

Passo 1. Criação do usuário sudo e deploy da chave SSH

Após conectar-se ao servidor limpo usando a senha temporária de root, crie imediatamente um usuário de engenharia:

# Створення користувача deploy з домашньою директорією та zsh/bash
adduser --gecos "" deploy
usermod -aG sudo deploy

# Копіювання публічного ключа Ed25519
mkdir -p /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

Passo 2. Hardening do daemon OpenSSH (/etc/ssh/sshd_config.d/99-hardening.conf)

Crie um arquivo de configuração SSH isolado para evitar sobrescrita durante atualizações de pacotes:

# Зміна порту (опціонально, але рекомендовано)
Port 2222

# Повна заборона root-доступу та паролів
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no

# Дозвіл виключно надійних криптографічних ключів
PubkeyAuthentication yes
AuthenticationMethods publickey

# Захист сесій від зависання
ClientAliveInterval 300
ClientAliveCountMax 2

# Відключення небезпечних функцій перенаправлення
X11Forwarding no
AllowTcpForwarding yes

Teste a configuração antes de reiniciar o serviço:

# Валідація синтаксису (якщо порожній вивід — конфіг коректний)
sudo sshd -t
sudo systemctl restart sshd

Passo 3. Configuração dos parâmetros do kernel Linux (/etc/sysctl.d/99-security.conf)

# Захист від TCP SYN Flood атак
net.ipv4.tcp_syncookies = 1

# Заборона перенаправлення пакетів маршрутизації (захист від Man-in-the-Middle)
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

# Ігнорування підроблених ICMP-відповідей
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Заборона IP Source Routing
net.ipv4.conf.all.accept_source_route = 0

Aplique as alterações do kernel sem necessidade de reboot:

sudo sysctl --system

4. Cenários práticos de engenharia em produção

01. Hardening automatizado via Cloud-Init na Hetzner Cloud

Ao criar um servidor virtual via Terraform ou pelo painel da Hetzner, passa-se um script User Data (cloud-init). O servidor inicia já com o acesso root bloqueado, usuário pré-criado, regras UFW geradas e SSH configurado em porta não padrão, eliminando totalmente a janela de vulnerabilidade nos primeiros minutos de vida da máquina.

02. Atualização automática de patches de segurança do kernel sem intervenção

Configuração do pacote unattended-upgrades no Ubuntu:

sudo apt install unattended-upgrades update-notifier-common
sudo dpkg-reconfigure --priority=low unattended-upgrades

O servidor baixa e instala automaticamente atualizações críticas de segurança dos repositórios oficiais Security todas as noites, enquanto a utilidade needrestart reinicia serviços comprometidos sem exigir um reboot completo do sistema operacional.

03. Isolamento do tráfego interno do daemon Docker

O Docker tenta, por padrão, expor portas em todas as interfaces de rede (0.0.0.0). Durante o hardening, o arquivo /etc/docker/daemon.json é configurado para restringir o binding padrão:

{
  "iptables": true,
  "live-restore": true,
  "userland-proxy": false
}

Isso garante que serviços sem mapeamento explícito para localhost permaneçam dentro da ponte de rede virtual do Docker e não exponham portas na internet pública.

5. Armadilhas comuns, erros típicos e segurança

1. Bloqueio acidental (SSH Lockout): O erro mais comum entre engenheiros: fechar o acesso por senha e proibir o root, esquecendo de verificar se a chave pública funciona para o novo usuário ou se a nova porta foi liberada no UFW. Nunca feche a sessão inicial do terminal até confirmar o sucesso da conexão em uma aba paralela.
2. Armazenamento de senhas sudo em scripts ou .bash_history: Usar echo "password" | sudo -S ... em shell scripts ou digitar senhas diretamente no terminal resulta em vazamento em texto claro no histórico de comandos. Utilize sudo visudo para delegar comandos específicos sem senha (NOPASSWD) para contas de serviço especializadas em CI/CD.
3. Ignorar a segurança do console Out-of-band do provedor: Mesmo um servidor perfeitamente hardened pode ser comprometido se a conta no console do provedor de hospedagem (Hetzner Cloud Console, DigitalOcean Dashboard) estiver protegida apenas por uma senha simples, sem autenticação de dois fatores baseada em hardware (2FA / WebAuthn). O acesso ao console do provedor equivale ao acesso físico direto à placa-mãe do servidor.