A primeira hora: uma superfície de ataque menor.

Verifique e preserve o acesso

Confirme a identidade do servidor por um canal confiável e adicione a sua chave pública SSH. Crie um usuário administrativo nomeado. Mantenha a sessão original aberta enquanto testa a nova e registre o método de recuperação antes de alterar a autenticação.

Aplique patches e reduza a exposição

Instale as atualizações de segurança suportadas e reinicie se necessário. Reveja os serviços em escuta e permita apenas as portas necessárias na firewall, incluindo IPv6. Remova daemons não utilizados e evite expor uma base de dados publicamente apenas para facilitar a configuração.

Separe utilizadores e segredos

Execute aplicações com as suas próprias contas. Coloque a configuração privada fora do diretório web público e exclua-a do controlo de versões. Use privilégios de base de dados restritos e credenciais separadas para produção e experiências.

Deixe um caminho de recuperação funcional

Configure a rotação de logs, alertas de disco e um backup separado. Reinicie uma vez para verificar se a aplicação inicia corretamente. Registre o que mudou para que a configuração possa ser reconstruída em uma imagem limpa.

Verifique antes de encerrar a sessão

Abra uma segunda conexão usando a nova conta, verifique a elevação administrativa e teste o firewall a partir de outro cliente. Confirme se o serviço retorna após a reinicialização. Mantenha a rota de recuperação do provedor documentada para que uma regra de rede equivocada não exija uma recuperação improvisada.

Uma lista de verificação do primeiro dia

Reveja os sockets abertos, os eventos de autenticação recentes, o estado das atualizações, a idade das cópias de segurança e o uso do disco. Verifique se a configuração privada e os metadados de controlo de versões não podem ser obtidos através de HTTP. Utilize o menor conjunto de ferramentas instaladas que suporte a carga de trabalho real.

ss -lntup
df -h
free -h
systemctl --failed

Faça alterações de acesso em uma ordem reversível

Primeiro confirme a rota do console ou de resgate e verifique a chave de host SSH por um canal confiável do provedor. Instale a chave pública para um administrador nomeado e, em seguida, abra uma segunda conexão e teste a elevação de privilégios. Valide a sintaxe da configuração SSH antes de recarregar o serviço. Aplique alterações de firewall somente depois que a rota SSH pretendida estiver permitida. Desative um método de autenticação antigo depois que o substituto funcionar a partir de uma sessão nova, incluindo qualquer fluxo de segundo fator necessário.

• Inspecione a configuração efetiva e os snippets incluídos; uma definição num ficheiro pode não ser a política final.
• Verifique tanto a autenticação por palavra-passe como a política interativa por teclado ao rever um modelo de início de sessão baseado em chaves.
• Uma porta SSH não padrão pode reduzir o ruído de fundo, mas não substitui chaves verificadas, limites de acesso ou atualizações.
• Use o nome do serviço e o procedimento de recarga da sua distribuição. Mantenha a sessão original até que a nova política seja comprovada.

# Validate before applying a changed SSH configuration.
sudo /usr/sbin/sshd -t
# Read effective settings; adapt user, host and client address to the test.
sudo /usr/sbin/sshd -T -C user=admin,host=server.example,addr=198.51.100.10

Documentação oficial: OpenSSH: manual de configuração do servidor

Comprove a firewall a partir do exterior do host

Revise o firewall da rede do provedor e o firewall do convidado como controles separados. Teste o serviço pretendido via IPv4 e IPv6 a partir de outra máquina autorizada. Uma conexão local prova apenas que um processo está escutando. Não bloqueie cegamente todos os pacotes ICMP: a operação normal da rede também precisa de tráfego de controle adequado. Verifique as portas publicadas pelo contêiner em relação às regras reais, pois a exposição da aplicação pode não corresponder à política que você achava que um front end de firewall aplicava.

• Se SSH falhar, inspecione as restrições de endereço de origem, a interface de escuta e o firewall do provedor antes de alterar as chaves repetidamente.
• Se HTTPS falhar, verifique DNS, o listener do processo e o firewall local/proxy, nessa ordem.
• Antes do primeiro conjunto de dados de produção, verifique o estado das atualizações, um reinício limpo, os alertas de disco e uma cópia de segurança restaurável de forma independente.
• Defina um fuso horário documentado e verifique a sincronização horária. Não adicione configurações arbitrárias de swap ou de registo sem verificar as necessidades de memória e de retenção da carga de trabalho.

Documentação oficial: Ubuntu Server: administração de firewall