Em resumo: se é um DDoS ou um ataque informático, vê-se pelos vestígios. Um DDoS gera muitíssimos pedidos e torna o site lento ou inacessível, mas não altera nada. Um exploit precisa muitas vezes de poucos pedidos e deixa ficheiros, contas, processos ou ligações novos. A classificação correta decide se tem de travar carga ou conter um incidente.
A diferença em palavras simples
Um ataque DDoS (Distributed Denial of Service) é como uma multidão que bloqueia a entrada de uma loja. Ninguém entra, mas na loja nada é roubado. O objetivo é sobrecarregar o seu site ou servidor, para que os clientes verdadeiros já não passem.
Um exploit é, em contrapartida, uma intrusão por uma porta aberta. O atacante aproveita uma fragilidade, por exemplo no PHP, no CMS ou numa extensão, para executar código no seu servidor. Pode acontecer discretamente, sem que o site fique mais lento. As consequências vão de páginas de spam ao roubo de dados e à tomada do servidor.
Para a gestão, a diferença é decisiva: um DDoS é um problema de disponibilidade, que termina com o ataque. Um exploit bem-sucedido é um incidente de segurança, que permanece até ser encontrado, limpo e documentado.
DDoS ou ataque informático: os sinais em comparação
A tabela seguinte ajuda na primeira classificação. Não substitui uma análise, mas mostra onde deve olhar primeiro.
| Característica | Mais provavelmente DDoS | Mais provavelmente exploit ou intrusão |
|---|---|---|
| Disponibilidade | lento ou em baixo | muitas vezes normal |
| Pedidos no registo | muitíssimos, muitas vezes uniformes | poucos pedidos, dirigidos |
| Ficheiros | inalterados | ficheiros PHP novos ou alterados |
| Contas | inalteradas | novos administradores, palavras-passe alteradas |
| Processos | servidor web e PHP em carga total | processos desconhecidos, mineração, envio de spam |
| Rede | muito tráfego de entrada | ligações de saída invulgares |
| Depois do fim | tudo como antes | os vestígios permanecem |
Atenção às sobreposições: a procura em massa de uma vulnerabilidade pode parecer um pequeno DDoS. Era exatamente isso que se esperava em torno do PHP2Shell, quando os atacantes procuravam servidores vulneráveis. Uma carga elevada também pode, portanto, significar que alguém está precisamente a tentar entrar.
Primeiras verificações no servidor
Os comandos seguintes não alteram nada no sistema e dão uma visão rápida. Em caso de suspeita de intrusão, guarde os registos antes de fazer intervenções maiores.
# Carga e tempo de atividade
uptime
# Ligações resumidas e as contrapartes mais frequentes
ss -s
ss -tn state established | awk 'NR>1 {print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head
# Endereços de cliente mais frequentes no registo de acessos (adapte o caminho)
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# Ficheiros PHP alterados nos últimos 7 dias
find /var/www -type f -name '*.php' -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
# Processos com maior carga de CPU
ps aux --sort=-%cpu | head -15
Na vista geral das ligações, a quarta coluna mostra a contraparte. Muitas ligações de poucos endereços ou um aumento para um múltiplo do valor normal indicam sobrecarga. Ficheiros PHP novos em diretórios de uploads ou de cache, processos do utilizador do servidor web com nomes estranhos ou ligações de saída para destinos desconhecidos indicam antes uma intrusão. Encontra uma lista detalhada em Sinais de comprometimento após o PHP2Shell.
Porque é que uma carga elevada também pode ser uma manobra de diversão
Acontece que os atacantes geram uma sobrecarga enquanto, ao mesmo tempo, entram de forma dirigida. A equipa fica então ocupada com a disponibilidade, e os verdadeiros vestígios perdem-se no ruído dos registos. Por isso, aplica-se: mesmo que um DDoS seja evidente, verifique após o seu fim os ficheiros, as contas e as ligações de saída.
No caso do PHP2Shell acresce que, segundo o php.net e as empresas de segurança, não há Indicators of Compromise publicados e confirmados. A deteção assenta na análise de comportamento. Um servidor que esteve sem patch durante o período de varreduras a partir de meados de outubro deve, por isso, ser verificado independentemente da carga observada.
Outra variante são os e-mails de extorsão, em que se ameaça com um ataque DDoS caso não se pague. Guarde tais mensagens, não pague sem consultar especialistas e considere uma queixa junto do ponto de contacto central para cibercrime (ZAC, na Alemanha). Informe em paralelo o seu fornecedor de alojamento, para que se possam preparar medidas de proteção. Como analisar os registos para isso, está no guia Analisar os registos do servidor web após um ataque.
O que fazer nas primeiras horas
Em caso de suspeita de DDoS:
- Informar o fornecedor de alojamento ou o centro de dados; aí há muitas vezes filtros à frente do servidor.
- Ativar ou reforçar um serviço de proteção intermédio ou uma WAF com virtual patching.
- Definir limites de taxa no servidor web e proteger especialmente páginas dispendiosas como a pesquisa ou o carrinho de compras.
- Conservar os registos, para que o ataque possa ser reconstituído mais tarde.
Em caso de suspeita de intrusão:
- Não apagar nada e não reinstalar o servidor antes de os registos e os ficheiros afetados estarem guardados.
- Atualizar o PHP para uma versão corrigida e reiniciar todos os workers, se ainda não tiver sido feito.
- Se a atualização não for possível de imediato, retirar o site temporariamente da rede, como o BSI recomenda.
- Renovar as credenciais a partir de um dispositivo limpo, não a partir do servidor possivelmente afetado.
- Mandar verificar se dados pessoais podem estar afetados; nesse caso, podem estar a correr prazos de notificação.
Em ambos os casos ajuda uma nota curta e objetiva para o fornecedor de alojamento e os prestadores de serviços: desde quando existe o problema, que sites estão afetados, o que observou e o que já foi alterado. Registe também quem tomou que decisão. Esta cronologia poupa tempo na análise e é mais tarde valiosa para o seguro, a proteção de dados e o balanço interno. Se não for claro se existe sequer um ataque, trate a situação preventivamente como um incidente, até prova em contrário.
Como ajuda concretamente a PHP SOS?
- Classificamos a situação remotamente com base na carga, nos registos, nos ficheiros e nas ligações e dizemos-lhe com o que provavelmente está a lidar.
- Em caso de sobrecarga, aplicamos filtros, limites de taxa e regras de proteção intermédias até o ataque abrandar.
- Em caso de suspeita de intrusão, assumimos a resposta a incidentes estruturada: guardar, conter, encontrar a causa, limpar.
- No fim, documentamos o que aconteceu e que medidas foram aplicadas, até o incidente estar concluído.
Perguntas frequentes
Um ataque DDoS pode roubar dados?
Um ataque DDoS puro visa a disponibilidade, não os dados. Não altera ficheiros nem lê bases de dados. Mas pode ocorrer em simultâneo com uma tentativa de intrusão, por isso vale a pena, ainda assim, olhar para ficheiros e contas.
Como reconheço que o meu site foi pirateado?
Indícios típicos são ficheiros PHP novos ou alterados, contas de administrador desconhecidas, redirecionamentos para sites alheios, ligações de saída inesperadas e processos que não condizem com a sua aplicação. Um único sinal não é prova, vários em conjunto são um sinal sério.
Um CDN ou uma WAF ajuda contra os dois tipos de ataque?
Contra ataques baseados em volume, um serviço intermédio costuma ajudar bem. Contra exploits, as regras só funcionam se reconhecerem o padrão. No PHP2Shell, a própria Cloudflare alerta que regras baseadas apenas nos dados do pedido não são suficientes.
Tenho de comunicar um ataque DDoS?
Depende do caso concreto e do seu setor. Sem acesso a dados pessoais, a obrigação de notificação do RGPD em regra não se aplica, mas podem existir obrigações específicas do setor. Esclareça-o com o seu encarregado da proteção de dados ou com um advogado.