Proteger uma VPS nova: o checklist

1. Instalar todas as atualizações

As imagens de nuvem muitas vezes têm semanas. Atualize tudo antes de instalar qualquer outra coisa, e reinicie se o kernel ou as bibliotecas básicas mudaram.

sudo apt update && sudo apt full-upgrade -y
[ -f /var/run/reboot-required ] && echo "reboot needed"

sudo dnf upgrade --refresh -y
sudo dnf needs-restarting -r

Na família RHEL, needs-restarting -r diz se é preciso reiniciar. Reinicie com sudo reboot e entre de novo.

2. Criar seu próprio usuário com sudo

Trabalhe com um usuário nominal com sudo, não como root: as ações ficam registradas em nome de alguém, e o login do root pode ser desligado no próximo passo.

sudo adduser deploy
sudo usermod -aG sudo deploy

sudo useradd -m deploy
sudo passwd deploy
sudo usermod -aG wheel deploy

Copie sua chave SSH para o usuário (ssh-copy-id deploy@SERVER_IP a partir do seu computador), entre com esse usuário em um segundo terminal e teste sudo -v. Depois confirme que só o root tem user ID 0 e que nenhuma conta tem senha vazia: o primeiro comando deve mostrar só root, e o segundo, nada.

awk -F: '$3 == 0 {print $1}' /etc/passwd
sudo awk -F: '$2 == "" {print $1}' /etc/shadow

3. Fechar o SSH

Só chaves, sem login do root, poucas tentativas por conexão. O passo a passo completo, com as verificações e a troca de porta, está em Como parar ataques de força bruta no SSH. A versão curta, depois que o login por chave estiver funcionando:

sudo tee /etc/ssh/sshd_config.d/00-hardening.conf > /dev/null <<'EOF'
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
MaxAuthTries 4
EOF
sudo sshd -t && echo "config OK"

sudo systemctl reload ssh

sudo systemctl reload sshd

4. Ativar o firewall

Bloqueie toda a entrada e depois libere só o que o servidor oferece. Aqui, SSH na 22 e um servidor web na 80 e na 443; tire o que você não usa.

sudo apt install -y ufw
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 verbose

sudo dnf install -y firewalld
sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

• No RHEL 9 e derivados, a zona padrão também permite o cockpit: remova com sudo firewall-cmd --permanent --remove-service=cockpit se você não usa, e depois recarregue.
• O Docker publica as portas dos containers com regras iptables próprias, que o ufw não enxerga: uma porta publicada com -p 8080:80 fica aberta mesmo que o ufw diga o contrário. Publique em 127.0.0.1:8080:80 quando só o proxy local precisa dela.
• A maioria dos provedores também tem um firewall de nuvem ou security group. Use-o como uma segunda camada, com as mesmas regras.

5. Ativar as atualizações de segurança automáticas

A maioria dos servidores comprometidos roda software para o qual já existia correção havia semanas. Deixe o servidor instalar sozinho as atualizações de segurança.

sudo apt install -y unattended-upgrades
sudo tee /etc/apt/apt.conf.d/20auto-upgrades > /dev/null <<'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
EOF
sudo unattended-upgrade --dry-run --debug 2>&1 | tail -n 20

Quais atualizações são instaladas é definido em /etc/apt/apt.conf.d/50unattended-upgrades (as de segurança no Ubuntu; as de segurança e as das point releases no Debian). As reinicializações automáticas ficam desligadas, a menos que você defina ali Unattended-Upgrade::Automatic-Reboot "true";.

sudo dnf install -y dnf-automatic
sudo sed -i -e 's/^upgrade_type.*/upgrade_type = security/' \
  -e 's/^apply_updates.*/apply_updates = yes/' /etc/dnf/automatic.conf
sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers dnf-automatic.timer

• O CentOS Stream não publica avisos de segurança, então lá upgrade_type = security não instala nada: use upgrade_type = default.
• O Fedora 41 e posteriores usam o dnf5: instale o dnf5-plugin-automatic e defina as mesmas opções em /etc/dnf/automatic.conf (veja man dnf5-automatic).
• Nenhuma das duas ferramentas reinicia por padrão. Programe uma reinicialização quando o kernel for atualizado.

6. Configurar backups que saiam do servidor

Um backup no mesmo servidor, ou só na mesma conta do provedor, vai embora junto com o servidor ou com a conta. Mantenha pelo menos uma cópia em outro lugar, criptografada, e teste uma restauração. Os snapshots do provedor são úteis como complemento, não como substituto.

O restic é uma opção simples: criptografado, com deduplicação, para SFTP, S3 e outros. Tem pacote no Debian e no Ubuntu, e no EPEL para a família RHEL. Troque BACKUP_HOST pelo seu servidor de backup; o restic pede uma senha do repositório, que você precisa guardar fora deste servidor.

sudo apt install -y restic

sudo dnf install -y epel-release
sudo dnf install -y restic

sudo restic -r sftp:backup@BACKUP_HOST:/srv/restic/$(hostname) init
sudo restic -r sftp:backup@BACKUP_HOST:/srv/restic/$(hostname) backup /etc /home /root /var/www
sudo restic -r sftp:backup@BACKUP_HOST:/srv/restic/$(hostname) snapshots

Exporte os bancos de dados para um arquivo antes de o backup rodar (mysqldump --single-transaction, pg_dump) em vez de copiar os diretórios de dados com eles em execução. Depois prove que a restauração funciona:

sudo restic -r sftp:backup@BACKUP_HOST:/srv/restic/$(hostname) restore latest --target /tmp/restore-test --include /etc/hostname
cat /tmp/restore-test/etc/hostname

7. Configurar monitoramento e alertas

Você precisa saber, sem entrar no servidor, quando ele cai, quando o disco enche e quando alguém faz login ou o ataca. No mínimo:

• Uma verificação externa de disponibilidade do site ou serviço, feita de fora do seu provedor.
• Um alerta de espaço em disco e de serviços com falha.
• Um registro de quem fez login, e um alerta para ataques e para alterações em arquivos do sistema.

Até ter algo que faça isso por você, estes comandos mostram os logins recentes, os erros desde a inicialização e o espaço livre em disco:

last -n 20
sudo journalctl -p err -b --no-pager | tail -n 30
df -h /

8. Fechar as portas de que você não precisa

Liste o que está escutando. Um endereço 0.0.0.0 ou [::] significa todas as interfaces, ou seja, a internet, a não ser que o firewall barre.

sudo ss -tulpn

• Pare e desative os serviços que você não usa.
• Bancos de dados e caches usados só pelo próprio servidor escutam em localhost: bind-address = 127.0.0.1 para MySQL e MariaDB, listen_addresses = 'localhost' para PostgreSQL, bind 127.0.0.1 -::1 para Redis.
• Nunca exponha à internet a API do Docker (2375, 2376) nem um Redis sem senha: as duas são portas de entrada comuns para crypto miners.

sudo systemctl disable --now SERVICE_NAME

Depois verifique de fora, a partir de outra máquina com nmap instalado. Só as portas que você liberou no passo 4 devem responder.

nmap -Pn SERVER_IP

9. Manter o relógio sincronizado

Os logs de servidores diferentes só batem quando os relógios concordam, e TLS, códigos de dois fatores e a linha do tempo de um incidente dependem todos da hora certa. Verifique:

timedatectl

O que você quer ver é System clock synchronized: yes. Se disser que não:

sudo apt install -y systemd-timesyncd
sudo timedatectl set-ntp true

sudo dnf install -y chrony
sudo systemctl enable --now chronyd
chronyc tracking

10. Guardar os logs por tempo suficiente

Quando algo acontece, a primeira pergunta é o que aconteceu antes. Torne o journal do sistema persistente, com um limite de tamanho e um tempo de retenção escolhidos por você:

sudo mkdir -p /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/retention.conf > /dev/null <<'EOF'
[Journal]
Storage=persistent
SystemMaxUse=1G
MaxRetentionSec=1year
EOF
sudo systemctl restart systemd-journald
journalctl --disk-usage

• Dimensione o limite de acordo com o disco: 1 GB é mais do que suficiente para um servidor pequeno.
• Por quanto tempo você precisa guardar os logs depende dos seus contratos e obrigações (por exemplo, a notificação de incidentes da NIS2). Decida, registre por escrito e configure aqui.
• Logs guardados só no servidor podem ser apagados por quem invadir. Mande uma cópia também para outra máquina ou para um serviço de logs.
• Os arquivos em /var/log (servidor web, auth.log no Debian e no Ubuntu) são rotacionados pelo logrotate: o valor de rotate em /etc/logrotate.d/ define quantos arquivos antigos são mantidos.

Perguntas

O firewall do provedor basta, ou também preciso de ufw ou firewalld?

Use os dois quando puder. O firewall do provedor barra o tráfego antes de ele chegar ao servidor; o do servidor continua protegendo se as regras de nuvem forem alteradas por engano ou se o servidor mudar de lugar.

Atualizações automáticas são seguras em um servidor de produção?

As atualizações de segurança das versões estáveis dessas distribuições são pequenas e testadas, e bem menos arriscadas do que rodar com falhas conhecidas. Deixe as reinicializações automáticas desligadas e programe-as, e mantenha um backup testado.

Por quanto tempo devo guardar os logs?

Não existe um número único. Depende dos seus contratos e de normas como a NIS2, para as empresas que ela abrange. Defina um período, mantenha uma cópia longe do servidor e garanta que o servidor guarde pelo menos o suficiente para investigar as últimas semanas.