O que realmente ataca um servidor novo — e o que realmente o tira das suas mãos
Aponte um endereço IPv4 novo para a internet e tráfego não solicitado chega quase imediatamente. Não porque alguém notou você: todo o espaço de endereços é varrido continuamente, e um host que responde na porta 22 simplesmente entra em uma fila que já estava em andamento. No primeiro dia, um servidor novo típico registra entre algumas centenas e algumas dezenas de milhares de tentativas de autenticação SSH, quase todas contra root, admin, ubuntu, test e mais uma dúzia de nomes previsíveis, com senhas de uma lista que mudou muito pouco em uma década. Parece um ataque. É mais parecido com clima.
Essa distinção importa, porque é ela que decide quais controles merecem seus quinze minutos. A adivinhação de senha nesse volume não é reduzida ao desligar a autenticação por senha — ela é eliminada. Não sobra risco residual para gerenciar, nem ajuste fino, nem taxa para monitorar. Enquanto isso, as duas coisas que realmente tiram servidores pequenos das mãos de seus donos não têm nada de glamouroso: uma aplicação exposta à internet rodando uma versão com uma vulnerabilidade publicada meses atrás, e uma credencial vazada em outro lugar que ainda funcionava aqui. Nenhuma das duas é exótica, e nenhuma tem qualquer relação com a porta em que o SSH escuta.
Existe um terceiro modo de falha, e em um host que nunca perguntou quem você é, ele é o mais comum de todos. Você tranca a si mesmo para fora. Em um provedor convencional, isso é um chamado de suporte chato: você responde algumas perguntas, prova que é a pessoa do registro de cobrança, e alguém redefine o acesso para você. Aqui esse caminho não existe — não como uma escolha de política feita a contragosto, mas porque a identidade que seria verificada nunca foi coletada. O que existe em vez disso é um acesso vinculado à conta, e não a uma pessoa: um console de emergência KVM-over-VNC no painel, snapshots por hora com retenção de sete dias, e a capacidade de inicializar outra coisa completamente diferente. Isso é suficiente. E só é suficiente se você já tiver usado esses recursos uma vez antes de precisar deles.
Por isso, o checklist abaixo está ordenado por consequência, não por moda. Os controles que eliminam uma classe inteira de ataque vêm primeiro, os que apenas reduzem ruído vêm por último, e o passo que não custa nada e salva a sua noite — provar que você ainda consegue entrar — vem antes de todos eles.
| Com o que as pessoas se preocupam | Como isso chega na prática | O que impede | O que não impede |
|---|---|---|---|
| Adivinhação de senha por SSH | Varreduras automatizadas, milhares por dia, listas genéricas de usuários | PasswordAuthentication no — completamente | Uma porta não padrão; uma senha mais longa |
| Serviço com vulnerabilidade conhecida | Um scanner identifica o seu banner de versão semanas depois de o patch ser lançado | Atualizações de segurança automáticas mais uma política de reinicialização | Um firewall, se a porta precisa ficar aberta de qualquer forma |
| Credencial reutilizada ou vazada | Login válido já na primeira tentativa, de um endereço que você nunca viu | Autenticação somente por chave; credenciais únicas por serviço | Limitação de taxa — uma tentativa não é uma rajada |
| Serviço interno exposto | Banco de dados, cache ou endpoint de métricas vinculado ao endereço wildcard | Vincular ao loopback; negar por padrão o tráfego de entrada nas duas famílias | Achar que é privado só porque você nunca linkou para ele |
| Perder o próprio acesso | Você aplica o hardening, sai, e a mudança que fez estava errada | Uma segunda sessão aberta, um snapshot, um console testado | Confiança |
Construa a saída antes de fechar a porta
Esta é a sequência que deixa as pessoas na mão, e cada passo dela está correto isoladamente: editar a configuração do SSH, mudar a porta, desativar o login por senha, ativar um firewall, recarregar o daemon, fechar o terminal. O erro não está em nenhuma mudança individual. Está no fato de que a sessão em que você está digitando era a única evidência de que qualquer uma delas funcionou, e você a descartou antes de verificar.
A regra que torna todo o checklist seguro cabe em uma frase: mantenha a sessão que está funcionando aberta e comprove a mudança a partir de uma segunda sessão. Abra um novo terminal, conecte-se do zero, rode id, escale com sudo. Se isso funcionar, a mudança é real e a primeira sessão vira descartável. Se falhar, você ainda tem um shell com o qual desfazer a mudança. Isso vale para o firewall, para o sshd, para a chave de um novo usuário, e para qualquer outra coisa que possa barrar você na porta.
Antes de tudo isso, estabeleça a rota fora de banda. No painel da BitVPS, cada linha de servidor tem um botão Console que abre uma sessão KVM-over-VNC contra o display da máquina virtual. Não é um shell pela rede — é a tela e o teclado da própria máquina — por isso continua funcionando quando o sshd não inicia, quando o firewall descarta todo pacote de entrada, e quando a configuração de rede está errada. Abra-o uma vez, agora mesmo, em um servidor que você não quebrou. Confirme que recebe um prompt de login. Isso leva trinta segundos e é a diferença entre um erro e uma indisponibilidade total.
Tire um snapshot também. Eles são feitos a cada hora, com retenção de sete dias em todos os planos, e são restaurados em cerca de trinta segundos, o que reduz “colei a regra nft errada” de uma noite inteira de recuperação para um rollback. E, para mudanças sobre as quais você realmente tem dúvidas, um dead-man switch custa uma linha: systemd-run --on-active=10min /usr/sbin/ufw --force disable arma um timer que desfaz o firewall em dez minutos, a menos que você o cancele. Se as novas regras funcionarem, você cancela. Se elas trancarem você para fora, a máquina deixa você entrar de novo sem que você precise estar lá.
SSH: as quatro diretivas que fazem o trabalho — e o arquivo que se sobrepõe a elas
Gere a chave na sua própria máquina, nunca no servidor: ssh-keygen -t ed25519 -C "laptop-2026". O Ed25519 é o padrão certo em 2026 — chaves curtas, verificação rápida, nenhuma escolha de parâmetro para errar, e suportado por todo OpenSSH compilado na última década. RSA de 4096 bits não é inseguro, é simplesmente maior e mais lento sem ganho nenhum. Defina uma senha (passphrase) na chave privada; o ssh-agent faz com que você a digite apenas uma vez por sessão, e é a única coisa que fica entre um laptop roubado e todos os servidores que você tem.
Copie a metade pública para o servidor com o ssh-copy-id e confirme que consegue fazer login com ela antes de desativar qualquer coisa. Permissões importam, e o OpenSSH é rígido quanto a isso por design: ~/.ssh em 700, authorized_keys em 600, ambos pertencentes ao usuário. Uma chave que falha silenciosamente quase sempre é um problema de permissão, e o sshd -e -d em primeiro plano informa isso em uma única linha.
Depois disso, quatro diretivas em /etc/ssh/sshd_config fazem essencialmente todo o trabalho. Tudo o mais nesse arquivo é preferência.
| Diretiva | Defina como | O que ela faz | O que quebra se você errar |
|---|---|---|---|
PasswordAuthentication | no | Remove por completo as senhas como método de login — toda a enxurrada de força bruta deixa de ser apenas mais lenta e passa a ser impossível | Você fica trancado para fora se a sua chave nunca chegou a ser instalada de verdade. Teste primeiro, em uma segunda sessão |
KbdInteractiveAuthentication | no | Fecha a segunda porta para a mesma sala — o caminho keyboard-interactive do PAM ainda pode aceitar uma senha mesmo com a primeira diretiva ativada | Quebra configurações legítimas de dois fatores baseadas em PAM. Deixe ativado só se você usar uma |
PermitRootLogin | prohibit-password | O root ainda pode fazer login com uma chave (útil para automação), mas nunca com uma senha | no é mais rígido e funciona bem — desde que o seu usuário sudo funcione. Verifique isso primeiro |
PubkeyAuthentication | yes | O método que você está mantendo. Aqui, explícito é melhor que padrão | Nada, mas vale declarar para que uma edição futura não o remova silenciosamente |
AllowUsers / AllowGroups | seu usuário ou grupo | Opcional, e a linha opcional de maior valor — o daemon recusa qualquer outra conta antes mesmo da autenticação | Um erro de digitação nega todo mundo. Defina isso por último, e a partir de uma segunda sessão |
Agora a parte que pega até gente experiente de surpresa. No Debian 12, no Ubuntu 22.04 e em tudo que veio depois, o /etc/ssh/sshd_config começa com Include /etc/ssh/sshd_config.d/*.conf, e o OpenSSH usa o primeiro valor que obtém para cada palavra-chave. Imagens de nuvem vêm com arquivos drop-in nesse diretório — em geral um que define PasswordAuthentication yes — e, como o include fica bem no topo, esse drop-in vence a linha que você editou cuidadosamente duzentas linhas mais abaixo. O arquivo diz uma coisa e o daemon faz outra.
A solução é nunca confiar no arquivo. Pergunte ao daemon o que ele de fato resolveu: sshd -T | grep -Ei 'passwordauth|permitrootlogin|kbdinteractive|pubkeyauth' imprime a configuração efetiva depois que todo include, bloco match e padrão já foram aplicados. Esse único comando vale mais que o resto desta seção. Combine-o com sshd -t, que valida a sintaxe e sai com código diferente de zero em caso de erro, e só então rode systemctl reload ssh — um reload não interrompe as sessões existentes, então mesmo um reload malfeito deixa o seu shell atual vivo.
Quanto a mudar o SSH da porta 22: isso remove talvez 95% do volume dos seus logs e zero por cento do seu risco. Todo scanner que vale a pena temer varre as 65,535 portas, e os poucos que não fazem isso já não teriam como vencer a autenticação somente por chave de qualquer forma. Mude a porta se o ruído incomodar você ou se isso silenciar um alerta de monitoramento — mas não registre isso como um controle de segurança, e, se realmente mudar, mantenha-a abaixo de 1024, porque só processos privilegiados podem se vincular a essas portas, de modo que nada sem privilégio consegue ocupar a porta se o daemon algum dia parar.
O firewall: negar por padrão a entrada, e a metade que todo mundo esquece
Um firewall em um servidor de propósito único tem um único trabalho: fazer o conjunto de portas alcançáveis ser igual ao conjunto de portas para as quais você consegue apontar um motivo. Negar por padrão a entrada, permitir a saída, permitir de volta as conexões estabelecidas e relacionadas, e então abrir as duas ou três coisas que você realmente roda. Se você está no Debian ou no Ubuntu, o ufw resolve em quatro comandos e resolve certo; se você prefere ter um único arquivo de regras legível, o nftables é a resposta moderna dentro do próprio kernel — e é nele que o ufw escreve por baixo dos panos.
A ordem importa em exatamente um ponto: libere a sua porta SSH antes de ativar a política. ufw allow 22/tcp, depois ufw default deny incoming, depois ufw enable. Na ordem inversa, o passo de ativação derruba a sessão em que você está digitando — o que é sobrevivível se você seguiu a seção anterior e ainda tem um console, e do contrário é a forma clássica de encerrar a noite mais cedo do que o planejado.
A metade esquecida é o IPv6. Todo servidor aqui vem com um /64 roteado, e os serviços se vinculam às duas famílias por padrão. Um conjunto de regras escrito só com iptables governa o IPv4 e não diz absolutamente nada sobre o IPv6, então o banco de dados que você protegeu com tanto cuidado continua alcançável a partir de toda a internet pelo outro protocolo. O ufw cobre as duas quando IPV6=yes está definido em /etc/default/ufw (o padrão nas versões atuais — confira em vez de presumir), e o nftables contorna o problema de forma estrutural: um conjunto de regras table inet cobre as duas famílias com um único conjunto de regras. Se você só for escrever uma linha de configuração de firewall à mão, que seja essa.
Depois tem o Docker, que não chega bem a contornar o seu firewall — ele simplesmente chega por baixo dele. Publicar uma porta com -p 5432:5432 insere regras DNAT na tabela nat, e elas são avaliadas antes das cadeias de filtro que o ufw gerencia. O resultado é um container alcançável a partir da internet enquanto o ufw status mostra a porta como fechada, e todo ano isso surpreende gente rodando um banco de dados em um container atrás do que acreditava ser uma política de negar tudo. Publique para o loopback em vez disso — -p 127.0.0.1:5432:5432 — ou coloque o container em uma rede interna e alcance-o a partir de outro container pelo nome.
| O que você acredita | O que é verdade, na prática | Como conferir em um comando |
|---|---|---|
| “O firewall nega tudo que eu não liberei” | Verdade só para IPv4, se você só escreveu regras para IPv4 | ip6tables -L -n ou nft list ruleset |
| “O banco de dados não está exposto, ele está em um container” | Uma porta publicada é alcançável independentemente da política de filtro | docker ps --format '{{.Ports}}' |
| “Não há nada escutando nessa porta” | Algo reiniciou e se vinculou de novo depois da última vez que você olhou | ss -tulpn |
| “A porta está fechada, foi o que meu scan disse” | Um scan feito a partir da própria máquina testa o loopback, não a internet | Faça o scan a partir de um segundo host, ou do seu laptop |
O que está realmente escutando — o comando que acaba com a adivinhação
Um único comando responde a pergunta mais útil que existe sobre a exposição de um servidor: ss -tulpn. Ele lista todo socket TCP e UDP em escuta, junto com o processo que é o dono dele, e a coluna que importa é o endereço local. 127.0.0.1:5432 significa que só esta máquina pode se conectar. 0.0.0.0:5432 significa que qualquer endereço que alcance a máquina pode, sujeito apenas ao firewall. [::]:5432 significa a mesma coisa em IPv6, e é a linha que as pessoas passam batido.
Os culpados recorrentes são sempre os mesmos de sempre. O Redis, que durante a maior parte da sua história se vinculava de forma ampla e vinha sem autenticação. O PostgreSQL e o MySQL, quando um arquivo de configuração foi editado para aceitar conexões “vindas da aplicação” e a aplicação depois mudou de lugar. O MongoDB e o Elasticsearch, que juntos já renderam uma década de manchetes de exposição de dados exatamente por esse motivo. O Memcached, cujo listener UDP virou um amplificador de banda favorito. O node_exporter do Prometheus, que narra com prazer os detalhes internos do seu host para quem quer que pergunte. A API do Docker na porta 2375, que é execução remota de código disfarçada de interface REST. E um servidor de desenvolvimento que alguém subiu “só por um minuto” em um painel do tmux onze meses atrás.
A regra é simples e não exige nenhum julgamento: se um serviço não precisa ser alcançável a partir da internet, vincule-o ao loopback. Tudo que você pessoalmente precisa fazer com ele continua funcionando — ssh -L 5432:127.0.0.1:5432 user@server dá a você uma porta local que faz túnel pela conexão em que você já confia, e se várias máquinas precisam de acesso, uma interface WireGuard privada dá a elas uma faixa de endereços que nunca toca a internet pública. Nenhuma das duas opções custa nada, e as duas removem o serviço da superfície de ataque por completo, em vez de apenas defendê-lo.
Verifique de fora, não de dentro. Uma porta que a sua própria máquina relata como filtrada é apenas uma alegação sobre a sua pilha de loopback; uma porta que uma segunda máquina não consegue alcançar é evidência de verdade. Conecte-se a partir do seu laptop, ou de outro servidor, e confira tanto as portas que você espera que estejam abertas quanto uma que você espera que esteja fechada — um teste que só pode passar não é um teste.
| Serviço | Padrão típico | O que uma instância exposta entrega | A correção |
|---|---|---|---|
| Redis | Vínculo amplo, historicamente sem senha | Leitura/escrita completa, e um caminho bem conhecido para escrever arquivos como o usuário redis | Vincular ao loopback; definir requirepass; manter o protected-mode ativado |
| PostgreSQL / MySQL | Loopback, até alguém editar isso | Todo o seu conjunto de dados, se uma credencial for fraca ou reutilizada | Vincular ao loopback; alcançar via SSH ou WireGuard |
| API do Docker | Desligada — a menos que um tutorial tenha ligado | Execução de código equivalente a root no host | Nunca exponha; use SSH context em vez disso |
| node_exporter / métricas | Todas as interfaces, porta 9100 | Nomes de host, pontos de montagem, versões, processos em execução | Vincular ao loopback; coletar pela interface privada |
| Envio de e-mail, painéis administrativos web | Todas as interfaces, por necessidade | Uma superfície de adivinhação de senha que chaves não protegem | É aqui que a limitação de taxa realmente se encaixa |
Fail2ban e CrowdSec: o que eles valem depois que as senhas somem
Este é o item que a maioria dos checklists coloca lá no topo, e que a maioria dos operadores superestima — por isso vale a pena ser preciso. Com PasswordAuthentication no, uma tentativa de adivinhar a senha não pode ter sucesso — não “raramente”, não “com dificuldade”, mas nunca. Banir um endereço depois de cinco falhas não torna uma autenticação impossível ainda mais impossível. O que o fail2ban compra para você na camada SSH é um auth.log mais silencioso, marginalmente menos CPU gasta configurando conexões, e gráficos de monitoramento mais fáceis de ler. Esses são benefícios reais. São higiene operacional, não um controle de segurança, e classificá-los na categoria errada é como as pessoas acabam com um arquivo de log super protegido e uma aplicação sem patch.
Onde essa classe de ferramenta realmente ganha o seu lugar é em toda camada em que uma senha ainda existe: um formulário de login de uma aplicação web, uma porta de envio de e-mail, um admin do Nextcloud ou do WordPress, um servidor IMAP. Esses não podem ser trocados para autenticação por chave pública, então a adivinhação continua possível e a limitação de taxa é a defesa de verdade. O CrowdSec soma a isso um feed de reputação compartilhado, o que é genuinamente útil na camada HTTP — você se beneficia de endereços que outras pessoas já flagraram se comportando mal — e é quase irrelevante na camada SSH depois que as chaves passam a ser obrigatórias.
Vale a pena nomear duas ciladas em que as pessoas tropeçam nas próprias pernas. A primeira é se autobanir, geralmente enquanto testa alguma coisa às três da manhã; defina ignoreip para incluir suas próprias faixas, e lembre-se de que um endereço compartilhado ou carrier-grade NAT significa que banir “um atacante” também pode banir umas boas centenas de pessoas que não têm nada a ver com isso. A segunda é que a ferramenta precisa conseguir ler os logs que está filtrando: em distribuições que registram apenas no journal do systemd, o backend de arquivo padrão fica observando silenciosamente um arquivo que já não recebe mais nada, e a jail fica ali, com aparência saudável, sem fazer absolutamente nada.
A recomendação honesta: instale se o ruído incomodar você, configure para a camada de aplicação onde ele realmente importa, e não conte esse benefício duas vezes. Se você quer o mesmo silêncio sem nada para manter, MaxStartups e LoginGraceTime no daemon SSH, somados à autenticação somente por chave, já resolvem a maior parte do caminho — e não têm como trancar você para fora da sua própria máquina.
Patches: o controle chato que evita a maioria dos comprometimentos reais
Leia qualquer relato de incidente envolvendo um pequeno servidor exposto à internet, e o padrão se repete: a vulnerabilidade tinha um patch, o patch estava disponível havia semanas ou meses, e ninguém o aplicou. O catálogo Known Exploited Vulnerabilities da CISA é a leitura útil aqui, justamente porque não é uma lista de gravidade teórica — é uma lista de coisas sendo exploradas agora mesmo, no mundo real, e é dominada por problemas que já têm correção publicada. As atualizações automáticas de segurança são, por consequência, os quinze segundos de maior retorno de toda esta página.
No Debian e no Ubuntu, instale o unattended-upgrades, ative-o com dpkg-reconfigure -plow unattended-upgrades, e confirme que a origem de segurança é a que está selecionada em /etc/apt/apt.conf.d/50unattended-upgrades. Verifique se ele realmente faz alguma coisa com unattended-upgrades --dry-run --debug, que imprime exatamente quais pacotes ele aplicaria e por quê — a página da wiki do Debian é a referência. No Rocky e no Alma, o dnf-automatic com apply_updates = yes e o timer ativado faz o mesmo trabalho. Restringir ao repositório de segurança é proposital: é a configuração que quase nunca quebra nada, que é o único tipo de automação que as pessoas de fato deixam ligado.
Depois, decida sobre reinicializações, de forma explícita, porque é aqui que o controle costuma vazar. Instalar um novo pacote de kernel não substitui o kernel que está rodando, e substituir uma biblioteca compartilhada não reinicia os daemons que já mapearam a cópia antiga na memória. O needrestart, no Debian e no Ubuntu, lista com precisão quais serviços ainda seguram bibliotecas já deletadas; uma atualização de kernel exige reinicialização, ponto final, e live-patching é um recurso pago que não vai chegar a uma instância de $8.50. Ou você define Unattended-Upgrade::Automatic-Reboot com um Automatic-Reboot-Time discreto, ou coloca uma reinicialização mensal no seu calendário e trata isso como manutenção, não como incidente.
Por fim, saiba o que as atualizações automáticas não cobrem, porque é nessa lacuna que as pessoas se dão mal. Qualquer coisa instalada fora do gerenciador de pacotes é invisível para ele: um binário baixado de um release do GitHub, uma dependência de runtime de linguagem vinda do pip, do npm ou do cargo, um tema ou plugin dentro de uma aplicação web, e acima de tudo imagens de container. Um host que reporta zero atualizações pendentes pode estar rodando uma imagem base construída há dois anos, e nada na máquina vai avisar você disso. Se você roda containers, reconstruir e baixar de novo em uma programação regular faz parte do processo de aplicar patches, não é uma atividade separada.
| Sistema | Mecanismo | O que cobre | O que passa despercebido |
|---|---|---|---|
| Debian / Ubuntu | unattended-upgrades, só a origem de segurança | Pacotes da distribuição, aplicados toda noite | O kernel em execução e as bibliotecas mapeadas, até uma reinicialização |
| Rocky / Alma | dnf-automatic com apply_updates = yes | O mesmo, via um timer do systemd | A mesma lacuna de reinicialização; confira com dnf needs-restarting |
| Containers | Nada, por padrão | Nada | Tudo — a imagem fica congelada no momento do build |
| Dependências de linguagem | Nada, por padrão | Nada | A superfície de ataque real da sua aplicação |
Usuários, sudo, e as portas que se reabrem silenciosamente
Crie um usuário comum, adicione-o ao grupo sudo ou wheel, instale sua chave nele, e pare de fazer login como root. O motivo não é que root-com-chave seja perigoso em si — é que se trata de uma conta de fator único, com um nome universalmente conhecido e nenhum registro de qual humano a usou. Uma conta nomeada mais sudo produz uma trilha de auditoria, permite mais de um operador sem compartilhar uma credencial, e torna respondível a eventual pergunta “quem rodou aquilo”. Não entregue, porém, NOPASSWD para tudo e depois reutilize essa conta para um serviço web.
Serviços também não deveriam rodar como root, e o systemd torna a versão barata disso praticamente gratuita. Um drop-in criado com systemctl edit <unit> contendo NoNewPrivileges=yes, ProtectSystem=strict, ProtectHome=yes e PrivateTmp=yes confina um daemon comprometido a uma visão do sistema de arquivos somente leitura, sem caminho para escalar privilégios — quatro linhas, descritas na documentação do systemd.exec, que transformam muitas vulnerabilidades de aplicação de “root na máquina” em “um erro no log”. O systemd-analyze security dá uma nota para cada unit da máquina e diz quais delas valem os cinco minutos.
Mantenha o authorized_keys honesto. Uma chave por dispositivo, cada uma com um comentário nomeando o dispositivo, e apague qualquer coisa que você não consiga identificar. Releia o arquivo depois que qualquer ferramenta de provisionamento rodar, porque cloud-init, pipelines de imagem e painéis de controle costumam anexar suas próprias entradas, e uma chave que você não adicionou é uma chave que você não consegue revogar. O mesmo vale para contas: um usuário padrão deixado para trás por uma imagem, com uma senha definida por um script e nunca mais usada, é um login que você não está vigiando.
O item mais sutil desta lista é o encaminhamento de agente. ForwardAgent yes permite que um processo no host remoto use a sua chave privada local durante todo o tempo em que você estiver conectado — é exatamente para isso que ele foi projetado, e é por isso que o root de uma máquina que você não controla totalmente pode pegar emprestada a sua chave para alcançar todo outro servidor que confia nela. Use ProxyJump (ssh -J bastion target) em vez disso: ele dá a você o mesmo alcance fazendo túnel na conexão, e a sua chave nunca se torna utilizável no host intermediário. Se você precisar mesmo encaminhar um agente, faça isso por host em ~/.ssh/config, nunca de forma global.
Backups: o controle que transforma um dia ruim em uma tarde
Tudo o que veio antes reduz a probabilidade de um dia ruim. Os backups decidem quanto esse dia ruim vai custar, e em um provedor que deliberadamente não consegue identificar você, eles importam mais do que o normal: não existe caminho de suporte que reconstrua a sua máquina a partir da cópia de outra pessoa, não existe fluxo de recuperação de conta que discretamente entregue uma restauração para você, e não existe registro de cobrança com um número de telefone anexado a ele. Você só tem o que você mesmo copiou.
O formato que funciona não tem nada de emocionante. restic ou borg, criptografando no próprio servidor para que os dados já estejam ilegíveis antes de atravessar a rede, enviados para uma segunda máquina — e, de preferência, uma segunda jurisdição, o que é só marcar uma caixinha, e não um projeto à parte, quando o mesmo painel oferece Islândia, Países Baixos, Romênia e Suíça. Os snapshots por hora incluídos em todos os planos são uma primeira linha de defesa genuinamente boa e cobrem perfeitamente o caso “quebrei a configuração há uma hora”. Eles não cobrem um arquivo que você apagou há cinco semanas, e vivem na mesma infraestrutura que a coisa que protegem. Snapshots e backups resolvem problemas diferentes; use os dois.
Torne o repositório somente para acréscimo (append-only). Esse é o detalhe que separa um backup de uma simples cópia: um servidor comprometido guarda as credenciais do seu próprio destino de backup, e tudo que pode apagar vai receber a ordem de apagar. O borg serve --append-only e o rest-server --append-only do restic aplicam isso do lado de quem recebe, de modo que a máquina consegue escrever novos snapshots, mas não consegue remover os antigos. Faça a poda (prune) a partir de outro lugar, em uma programação regular, com uma credencial que o servidor nunca viu.
Duas últimas coisas, e as pessoas costumam pular as duas. A senha (passphrase) do repositório não pode viver só na máquina que ela protege — anote-a, guarde-a em um gerenciador de senhas em outro lugar, trate-a como a seed phrase que ela efetivamente é. E restaure o backup pelo menos uma vez. Um backup que você nunca restaurou é apenas uma hipótese; a forma mais comum de descobrir que uma regra de exclusão silenciosamente pulou o dump do banco de dados é durante a recuperação que você não pode se dar ao luxo de ver dar errado. Suba uma instância Starter, restaure nela, confira os dados, destrua-a. Isso custa $8.50 e uma hora, e é a única forma de o resto desta página deixar de ser uma primeira tentativa e virar um ensaio já testado.
Contra o que o hardening não protege você
Ele não protege o disco de quem está com o disco em mãos. Todo controle desta página presume que o sistema operacional está rodando e aplicando suas próprias regras; nenhum deles vale para uma máquina desligada cujo armazenamento foi copiado bit a bit. Esse é um problema diferente, com uma resposta diferente — veja criptografia de disco completo, desbloqueio remoto, e o que uma apreensão realmente recupera — e o resumo honesto é que hardening e criptografia defendem contra ameaças distintas, que não se sobrepõem. Fazer um não faz metade do outro.
Ele não conserta a aplicação que você roda. Um servidor pode passar em todas as verificações daqui e ainda assim ser perdido para um fórum desatualizado, um endpoint administrativo sem autenticação, um template engine que avalia entrada do usuário, ou um token commitado em um repositório público. O hardening do host reduz o raio de estrago de um comprometimento de aplicação — que é exatamente para isso que serve o confinamento com systemd visto acima — mas ele não audita o seu código, e a forma mais comum de um servidor pequeno ser tomado continua sendo alguma coisa que o próprio operador instalou.
Ele não muda quem sabe que você alugou a máquina. Uma caixa perfeitamente protegida, paga a partir de uma conta de exchange com identidade verificada, pedida com um e-mail pessoal, é uma caixa perfeitamente protegida com o seu nome escrito nela. A camada de segurança e a camada de identidade são independentes, e a segunda é decidida no checkout, não no shell — o quanto a hospedagem paga em cripto realmente é rastreável mostra onde esses vínculos de fato se formam.
E ele não faz nada contra a análise de tráfego. Um observador posicionado para vigiar as suas conexões aprende o formato delas — horário, volume, quem fala com quem — independentemente de quão bem os endpoints estejam configurados. Criptografia esconde o conteúdo, não a conversa, e nenhuma quantidade de ajuste fino no sshd muda isso.
O checklist, na ordem para executá-lo
Oito passos. Os quatro primeiros são os quinze minutos do título e eliminam categorias inteiras de risco; os quatro últimos levam mais tempo e são o que separa um servidor que você consegue defender de um que você apenas configurou. Cada linha inclui como você sabe que funcionou, porque um passo de hardening que você não verificou é um passo de hardening que você não deu.
| # | Passo | Como você sabe que funcionou |
|---|---|---|
| 1 | Abra o console do painel, confirme um prompt de login, tire um snapshot | Você viu o prompt em um servidor que não estava quebrado |
| 2 | Crie um usuário não root, instale sua chave ed25519, teste o sudo | Um segundo terminal faz login como esse usuário e escala privilégio |
| 3 | Desative a autenticação por senha e a keyboard-interactive | sshd -T reporta passwordauthentication no |
| 4 | Firewall com negação padrão de entrada cobrindo IPv4 e IPv6 | nft list ruleset mostra as duas famílias; um scan de outro host confirma |
| 5 | Audite os sockets em escuta, revincule serviços internos ao loopback | ss -tulpn não mostra nenhum vínculo wildcard que você não consiga justificar |
| 6 | Ative atualizações automáticas de segurança e uma política de reinicialização | unattended-upgrades --dry-run --debug seleciona a origem de segurança |
| 7 | Confine os serviços com systemd, organize o authorized_keys | As notas do systemd-analyze security melhoram; toda chave tem um nome |
| 8 | Backup criptografado, somente para acréscimo e fora do local, restaurado uma vez | Você restaurou em uma instância descartável e os dados estavam lá |
Nada disso é exótico, e esse é o ponto. Os controles que importam em um servidor pequeno são os que eliminam uma classe de problema, em vez de apenas gerenciá-la: nenhuma senha, nenhum listener inesperado, nenhum pacote sem patch, nenhuma cópia única dos dados. Tudo o mais é preferência, e preferência sai barato depois que as quatro mudanças estruturais estão no lugar e verificadas.
Se você está provisionando a máquina agora, em vez de só lendo com antecedência, a sequência cabe tranquilamente dentro da primeira sessão: implante uma instância, abra o console uma vez para comprovar que ele funciona, e rode os oito passos em ordem antes de instalar qualquer coisa. Um servidor protegido antes de ter qualquer serviço rodando não tem legado algum para contornar — que é a única vantagem que uma caixa nova tem, e ela dura cerca de um dia.
