Checklist de hardening do Ubuntu Server 24.04 em instalação nova

Todo host Ubuntu 24.04 que se junta à nossa frota gerenciada passa pelo mesmo passe de hardening antes que qualquer carga seja permitida nele. Os defaults da imagem cloud são decentes — não eram decentes cinco anos atrás — mas «decente» não é baseline de segurança. Existe um pequeno conjunto de mudanças que materialmente movem o modelo de ameaça, e um conjunto ainda menor de adições que pegam o incidente raro quando algo passa mesmo assim.

Esta é a checklist que rodamos como role Ansible em cada novo host.

O passe da primeira hora

# SSH — só chaves, restringir ciphers, desabilitar root + password
sed -i 's/^#PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/^#PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
cat >> /etc/ssh/sshd_config.d/00-hardening.conf <<EOF
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
EOF
systemctl restart ssh
 
# UFW — deny por padrão, permitir só o necessário
ufw default deny incoming
ufw default allow outgoing
ufw allow from <bastion-cidr> to any port 22
ufw enable
 
# fail2ban — jail de brute force SSH
apt install -y fail2ban
systemctl enable --now fail2ban

Depois disso, o host só é acessível via o bastion, só com chaves SSH, só em ciphers modernos.

O artigo completo cobre:

• Perfis AppArmor em modo enforce (os defaults que deveriam estar ligados)
• Configuração do auditd — integridade de arquivos para /etc, /usr/sbin, monitoramento de syscalls
• O passe de hardening de sysctl do kernel (net.ipv4.tcp_syncookies, rp_filter, etc.)
• needrestart para pegar bibliotecas que precisavam de reboot-após-upgrade
• chrony para sincronização de tempo (porque Kerberos e TLS dependem dele)
• O beacon de inventário que auto-registra o host com nosso config management

Rodamos essa checklist em cada host Ubuntu 24.04 no dia zero.