Os Primeiros 30 Minutos: Lista de Verificação de Endurecimento de VPS

Um VPS novo recebe sua primeira sondagem SSH em minutos após obter um IP. Aqui está a sequência exata que executo em cada nova máquina — pronta para copiar e colar no Debian 13, com uma tabela de verificação no final.

Premissas: uma imagem Debian 13 nova do seu deploy VPSRento, você está logado como root via SSH, e o IP de exemplo é 185.220.101.14 — substitua pelo seu. Tempo total: cerca de meia hora. Siga os passos em ordem; o passo 2 pode bloquear você se for apressado.

1. Crie seu usuário sudo

Trabalhar como root é como erros de digitação viram incidentes. Crie um usuário real, dê a ele sudo, e faça tudo a partir daí:

Copy# create the user (you'll set a password — still useful for sudo)
adduser ops

# grant sudo
usermod -aG sudo ops

Tudo abaixo deste ponto roda como ops salvo indicação contrária.

2. Apenas chaves SSH — sem senhas, sem login root

Autenticação por senha é o maior buraco em uma máquina exposta à internet. Bots martelam a porta 22 com listas de credenciais o dia todo, todos os dias. Chaves tornam toda essa classe de ataque irrelevante. Na sua máquina local:

Copy# generate a keypair if you don't have one (ed25519, no passphrase tradeoff is yours)
ssh-keygen -t ed25519 -C "ops@atlas"

# push the public key to the server
ssh-copy-id [email protected]

Verifique se você consegue logar com a chave em um terminal novo terminal — ssh [email protected] — antes de tocar na configuração. Mantenha a sessão root existente aberta como sua rota de fuga. Então edite /etc/ssh/sshd_config:

Copy# /etc/ssh/sshd_config — the three lines that matter
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

Copy# validate the config, then reload (Debian 13 uses ssh.service)
sshd -t && systemctl reload ssh

prohibit-password em vez de um no plano para root de propósito: root ainda pode autenticar com uma chave da sua estação de trabalho, o que é ocasionalmente útil para recuperação via console do provedor — mas nenhuma senha funcionará jamais, para ninguém, de lugar nenhum. Confirme com sshd -T | grep -E 'passwordauthentication|permitrootlogin'.

3. Firewall: negar por padrão, permitir apenas o que você executa

O ufw do Debian é uma camada fina e sensata sobre nftables. A política é a segurança; as regras são apenas exceções a ela:

Copyapt update && apt install -y ufw

ufw default deny incoming
ufw default allow outgoing

# SSH stays open — add this BEFORE enabling
ufw allow 22/tcp comment 'SSH'

# whatever your box actually serves, e.g.:
ufw allow 80/tcp comment 'HTTP'
ufw allow 443/tcp comment 'HTTPS'

ufw enable
ufw status verbose

Cada porta que você abrir deve ter um nome e um motivo. Se você não consegue dizer para que serve uma porta, ela não ganha uma regra.

4. fail2ban: reduza os bots a um rastreamento lento

Com autenticação por senha desativada, força bruta já está morta — mas o fail2ban mantém seus logs legíveis e bane os scanners que cutucam todo o resto:

Copyapt install -y fail2ban

Copy# /etc/fail2ban/jail.local
[sshd]
enabled  = true
port     = ssh
maxretry = 5
findtime = 10m
bantime  = 1h

Copysystemctl enable --now fail2ban

# watch it work
fail2ban-client status sshd

5. Atualizações de segurança automáticas

A CVE sem correção é um risco maior que o reboot. O unattended-upgrades do Debian instala atualizações de segurança por conta própria:

Copyapt install -y unattended-upgrades

# answer Yes to auto-install updates
dpkg-reconfigure -plow unattended-upgrades

A configuração padrão em /etc/apt/apt.conf.d/50unattended-upgrades puxa apenas do repositório de segurança — que é o que você quer em um servidor: correções de segurança automaticamente, todo o resto quando você escolher.

6. Desligue o que você não executa

Cada serviço em execução é superfície de ataque que você precisa corrigir. Veja o que está realmente escutando:

Copy# who is listening, on what, as which process
ss -tulpn

# everything enabled at boot
systemctl list-unit-files --state=enabled

# example: you don't run a print server — nobody does
systemctl disable --now cups

A regra: se você não consegue dizer o que um listener faz, descubra antes de deixá-lo vivo. Em uma imagem VPSRento mínima deve haver muito pouco além de sshd e sua própria aplicação.

7. Opcional, mas recomendado: um plano de gerenciamento WireGuard

A versão mais forte de segurança SSH é um SSH que não enfrenta a internet. Rode WireGuard na máquina, permita SSH apenas dentro do túnel, e a porta 22 desaparece de todos os scanners do mundo:

Copyapt install -y wireguard

# /etc/wireguard/wg0.conf — minimal management tunnel
# [Interface] Address = 10.8.0.1/24, ListenPort = 51820

# open the tunnel, not the shell
ufw allow 51820/udp comment 'WireGuard'
ufw allow in on wg0 to any port 22 proto tcp comment 'SSH via WG'
ufw delete allow 22/tcp

systemctl enable --now wg-quick@wg0

Depois disso, você ssh [email protected] através do túnel, e o IP público responde em exatamente uma porta UDP. O passo a passo completo do WireGuard — chaves, peers, configurações de cliente, QR codes para celular — está no guia complementar.

A lista de verificação de 10 pontos

Percorra esta tabela após cada novo deploy, e novamente após cada serviço que você adicionar:

O item 10 merece uma frase: endureça primeiro, snapshot depois, nessa ordem — um snapshot de uma máquina limpa e endurecida é seu rollback para todo erro futuro. Snapshots offsite diários são um adicional de $1.99/mês na área do cliente. Trinta minutos de prevenção, um clique de seguro.