Quando algo corre mal

Módulo 10: Manter a segurança · Tempo de leitura: 11 minutos

Objetivo de aprendizagem: Depois desta lição, reconhece os sinais de um servidor comprometido, dá os primeiros passos sem destruir provas ou cópias de segurança, escolhe entre limpar e reinstalar, e sabe quando deve notificar uma violação de dados pessoais.

Conceitos-chave: incidente, sinais, isolar, snapshot como prova, registo do incidente, reinstalar, substituir chaves e palavras-passe, cópia de segurança limpa, dever de notificação de violações de dados (72 horas), Comissão Nacional de Proteção de Dados, plano de emergência

Reconhecer um incidente

Uma intrusão raramente se anuncia. Na maioria dos casos, nota-se algo "estranho". Sinais a levar a sério:

• Carga elevada sem motivo: o processador está constantemente a 100%, por exemplo devido a um cryptominer. Verifique com top ou htop qual é o processo e com que utilizador é executado.
• Processos ou serviços desconhecidos: um programa com um nome estranho, muitas vezes em /tmp, /dev/shm ou /var/tmp, ou um serviço ou temporizador systemd que não foi o utilizador a criar.
• Tráfego de saída que não faz sentido: o seu fornecedor informa que o servidor está a enviar spam ou a atacar outros servidores, ou os gráficos de rede no painel mostram picos.
• Novos utilizadores ou chaves: uma linha em ~/.ssh/authorized_keys que não reconhece, um utilizador em /etc/passwd com UID 0, uma nova linha em /etc/sudoers.d/.
• Ficheiros alterados: ficheiros PHP desconhecidos no seu site, um crontab alterado.
• Registos desaparecidos ou vazios: os atacantes gostam de apagar os seus rastos.

Alguns comandos para uma inspeção rápida:

anna@web1:~$ top -o %CPU
anna@web1:~$ sudo ss -tunap | grep ESTAB
anna@web1:~$ sudo last -n 20
anna@web1:~$ awk -F: '$3 == 0 {print $1}' /etc/passwd
anna@web1:~$ sudo find /etc/systemd/system /etc/cron* -newer /etc/hostname -type f
anna@web1:~$ for u in /root /home/*; do sudo cat $u/.ssh/authorized_keys 2>/dev/null; done

last mostra quem iniciou sessão e quando, a linha awk mostra todas as contas com UID 0 (só deveria ser root), e a linha find procura units e ficheiros cron mais recentes do que um ficheiro criado durante a instalação.

Atenção: num servidor realmente comprometido, também estes comandos podem ter sido falsificados. Ajudam-no a suspeitar de algo, não a provar que está tudo limpo.

Os primeiros passos: calma, isolar, registar

O mais importante nos primeiros minutos é não apagar coisas em pânico. Siga esta ordem.

1. Inicie um registo. Anote em papel ou no seu portátil (não no servidor) o que vê, quando, e o que faz. Vai precisar disso mais tarde para encontrar a causa, para uma notificação, uma queixa ou o seu seguro. O NCSC neerlandês também o recomenda.

2. Isole o servidor. Impeça que continue a causar danos (spam, ataques, envio de dados) sem o desligar:

• na firewall do seu fornecedor (se existir), feche tudo exceto SSH a partir do seu próprio endereço; ou
• faça o mesmo no próprio servidor, através da consola;
• se não houver alternativa: desligue o servidor através do painel. Nesse caso, perde o conteúdo da memória.

3. Crie um snapshot. Um snapshot no painel regista o estado atual do servidor. É a sua prova e a sua fonte para investigar mais tarde como o atacante entrou, mesmo que reinstale o servidor depois.

4. Proteja as suas cópias de segurança. Verifique se as cópias de segurança fora do servidor continuam intactas e garanta que o servidor comprometido já não lhes consegue aceder (por exemplo, revogando a chave de acesso do servidor ao armazenamento de cópias de segurança). Os atacantes também tentam apagar ou cifrar cópias de segurança.

Limpar ou reinstalar?

A resposta tentadora é: remover o ficheiro suspeito, parar o cryptominer e pronto. Mas não sabe o que mais o atacante fez: uma segunda porta das traseiras, um programa alterado, uma chave adicional, um temporizador que repõe tudo. Num servidor onde alguém teve acesso root, já não se pode confiar.

Por isso, o conselho dos administradores de sistemas, e também do NCSC neerlandês, é: reinstalar os sistemas afetados e repor os seus dados a partir de uma cópia de segurança que não esteja ela própria infetada. Em concreto:

1. Uma instalação nova (reinstalar no painel, ou um servidor novo).
2. De imediato, a base deste curso: atualizações, utilizador normal com sudo, SSH com chaves novas, firewall (módulos 2 a 5).
3. Reinstalar as suas aplicações a partir de fontes oficiais, de preferência com os seus ficheiros compose ou notas (lição 10.4).
4. Repor os dados (base de dados, uploads) a partir de uma cópia de segurança anterior ao incidente. Não reponha código nem configuração às cegas: podem conter a porta das traseiras. Analise também com espírito crítico os dados repostos; um atacante pode estar dentro há mais tempo do que pensa.
5. Corrigir a falha por onde o atacante entrou. Caso contrário, volta a acontecer. O snapshot do passo 3 ajuda na investigação.

Substituir tudo o que possa ter sido exposto

Parta do princípio de que tudo o que estava no servidor está nas mãos do atacante:

• Chaves SSH: remova de todo o lado as chaves públicas que estavam no servidor e crie novos pares de chaves se havia chaves privadas no servidor.
• Palavras-passe de bases de dados, painéis de administração e utilizadores da sua aplicação.
• Chaves de API e tokens (email, pagamentos, armazenamento na cloud, armazenamento de cópias de segurança) em ficheiros .env e na configuração: revogue-os junto do serviço e substitua-os.
• Certificados: a chave privada do seu certificado estava no servidor. Peça a revogação do certificado e solicite um novo (com Let's Encrypt é rápido, lição 7.3).

Notificar: o RGPD e outros

Se havia dados pessoais no servidor (dados de clientes, contas, endereços de email), pode tratar-se de uma violação de dados pessoais. O RGPD (artigo 33.º) estabelece que o responsável pelo tratamento notifica a autoridade de controlo de uma violação de dados sem demora injustificada e, sempre que possível, até 72 horas após ter tido conhecimento da mesma. Em Portugal, é a Comissão Nacional de Proteção de Dados (CNPD). Alguns pontos a reter:

• não é necessário notificar se for improvável que a violação resulte num risco para os titulares dos dados; em caso de dúvida, notifique;
• se ainda não dispõe de toda a informação, notifique na mesma no prazo de 72 horas e complete mais tarde;
• as pessoas cujos dados foram expostos devem ser informadas se existir um risco elevado para elas;
• todas as violações de dados devem ser documentadas num registo próprio, mesmo que não tenha de as notificar.

Se gere o servidor para um cliente, normalmente é subcontratante: nesse caso, deve informar o cliente (o responsável pelo tratamento) sem demora injustificada, para que este possa notificar. Esta lição não constitui aconselhamento jurídico; em caso de dúvida, consulte o site da CNPD.

Além disso: comunique ao seu fornecedor os abusos cometidos a partir do seu servidor (muitas vezes já os detetou) e, em caso de ataque grave, apresente queixa à polícia. Se a sua organização estiver abrangida pelo Decreto-Lei n.º 125/2025 (transposição da NIS2), aplicam-se prazos de notificação próprios e mais curtos.

Preparar-se: o plano de emergência

Um incidente acontece sempre num mau momento. O que tiver tratado previamente poupa horas:

• Saiba como aceder à consola e ao botão de snapshot do seu fornecedor, e guarde os dados de acesso ao painel (com autenticação de dois fatores) num local fora do servidor.
• Saiba onde estão as suas cópias de segurança, como as repor e que funcionam (lição 8.2).
• Mantenha uma lista de todos os segredos guardados no servidor, para saber o que tem de substituir.
• Mantenha uma lista de contactos: o seu fornecedor, quem mais deve ser informado sobre o servidor (cliente, colega) e os contactos para uma notificação de violação de dados.

Na prática

No ecrã do VPS da WebOké encontra a consola, os snapshots, as cópias de segurança e o botão para reinstalar; noutros fornecedores, os nomes são semelhantes (console ou VNC, snapshot, rescue, reinstall). Este curso é de autoajuda: ninguém acompanha o seu servidor e ninguém resolve um incidente por si. É precisamente por isso que um plano de emergência que consiga executar sozinho é tão importante.

Resumo

• Sinais: carga inexplicável, processos, serviços ou chaves desconhecidos, tráfego de saída estranho, ficheiros e registos alterados ou desaparecidos.
• Primeiros passos: manter um registo, isolar o servidor, criar um snapshot como prova, proteger as cópias de segurança.
• Um servidor onde alguém teve acesso root não se limpa, reinstala-se; repõem-se os dados a partir de uma cópia de segurança limpa e corrige-se a falha.
• Substitua todas as chaves, palavras-passe, tokens e certificados que estavam no servidor.
• Dados pessoais afetados? Notifique a violação à CNPD, se possível no prazo de 72 horas, e documente todas as violações.

Questionário

Exercício

Exercício O10.3: O seu plano de emergência numa só página. Escreva para o seu próprio servidor um plano de emergência com no máximo uma página A4: como acede ao painel, à consola e aos snapshots; onde estão as suas cópias de segurança e como as repõe; que segredos estão no servidor; quem deve informar (e se tem de notificar em caso de violação de dados); e quais os cinco primeiros passos que dá perante a suspeita de uma intrusão. Guarde o plano fora do servidor.

Para saber mais

• Deixou de ter acesso ao seu VPS: o que fazer?
• Snapshots e cópias de segurança do seu VPS
• Associar uma ISO própria ou reinstalar o seu VPS
• NCSC neerlandês, Gehackt, wat nu? (fonte neerlandesa, em neerlandês): https://www.ncsc.nl/incidenten-en-herstellen/gehackt-wat-nu
• Comissão Nacional de Proteção de Dados (CNPD), notificação de violações de dados (formulário online): https://www.cnpd.pt/
• VPS: do primeiro início de sessão a um servidor seguro 9.1: Bloqueado: já não consegue aceder ao seu servidor
• VPS: do primeiro início de sessão a um servidor seguro 9.5: Foi pirateado? Os primeiros passos