Em resumo: se vários sites de clientes da sua agência estão afetados, raramente é acaso; trata-se, na maioria das vezes, de um servidor partilhado, de um acesso partilhado ou da mesma versão do PHP. Se está afetado, contacte-nos de imediato. Damos-lhe uma panorâmica, contemos o incidente remotamente, limpamos os sistemas e entregamos-lhe relatórios para os seus clientes.
Não apague nada nem reinstale nada agora. Mesmo que a pressão dos clientes seja grande: sem registos e ficheiros preservados, não se consegue esclarecer a causa nem provar o que não foi afetado. Comunicar uma emergência, e assumimos o caso desde a primeira mensagem.
Está afetado? Sinais quando sites de clientes foram hackeados
Enquanto agência, vê padrões que os operadores individuais nunca notam. Apontam para um incidente comum:
- Vários sites de clientes mostram ao mesmo tempo os mesmos sintomas: redirecionamentos, conteúdos de spam, avisos no navegador.
- A mesma conta de administrador desconhecida ou o mesmo ficheiro suspeito aparece em clientes diferentes.
- O fornecedor de alojamento comunica abuso ou carga invulgar numa conta em que estão muitos projetos.
- Clientes telefonam porque o seu site é alvo de aviso na Google, e, numa verificação cruzada, encontra outros sites no mesmo estado.
- Um programador ou ex-colaborador tinha acesso a muitos projetos, e um acesso foi extraviado.
- Trabalhos de manutenção através de uma ferramenta central, por exemplo deployment, cópias de segurança ou um serviço de atualização, alteraram um site em que não tocou.
- Gere muitos sites em versões do PHP cujo nível de patch não consegue comprovar para cada uma.
Desde o PHP2Shell, acresce que a vulnerabilidade está no próprio interpretador PHP. Uma atualização do CMS, por exemplo do WordPress, não a fecha; o decisivo é o ambiente de execução PHP que realmente serve os sites.
O que fazer já
- Listar os sites afetados: domínio, servidor, conta de alojamento, versão do PHP, CMS, responsáveis. Os casos suspeitos também entram.
- Procurar pontos em comum: mesmo servidor? Mesmos acessos? Mesmo plugin? Mesmo caminho de deployment?
- Isolar os sites em risco: pôr em modo de manutenção os sites que entregam ativamente código malicioso. Não apagar.
- Mandar preservar registos e estado: pedir ao fornecedor de alojamento que conserve os registos; preservar os registos de deployment próprios.
- Verificar os acessos centrais: quem tem acesso ao painel de alojamento, ao SSH, ao Git, ao gestor de palavras-passe e ao deployment? Alterações só depois de acordo.
- Informar os clientes com contenção: primeiro apenas o que está comprovado. Não indicar uma causa antes de ela estar apurada.
- Contactar-nos: ligue ou escreva-nos por WhatsApp.
Como ajuda concretamente a PHP SOS?
- Levantar a situação: fazemos consigo uma panorâmica de todos os sites e servidores e ordenamo-los por urgência: código malicioso entregue ativamente, suspeita de fuga de dados, provavelmente apenas sem patch.
- Preservar e fechar: preservamos cada sistema afetado antes de alterar o que quer que seja e fechamos a porta de entrada comum: acessos, nível do PHP, reinício de todos os processos.
- Verificar e limpar: procuramos sistematicamente em todos os sites os mesmos vestígios, removemos webshells e backdoors e restauramos de forma limpa. Pormenores em Remoção de malware e webshells.
- Reforçar e relatar: separamos os sites uns dos outros onde fizer sentido e entregamos, por cliente, um breve relatório que pode transmitir, bem como um relatório global para si.
Trabalhamos remotamente, sem deslocações, em toda a Alemanha e na Europa. Se desejar, em segundo plano para a sua agência, como descrito na página Agências e white label.
Porque é que nas agências caem muitas vezes vários sites ao mesmo tempo
Quem gere muitos projetos num servidor poupa custos, mas troca isolamento por comodidade. Se tudo corre sob o mesmo utilizador e o mesmo pool de processos PHP, o código de um site hackeado pode ler e alterar os ficheiros dos vizinhos. Não é um caso exótico, mas o padrão em muitas configurações. Como separar corretamente os pools, descreve-o Isolar pools PHP-FPM.
A isto juntam-se os acessos partilhados: uma chave SSH para todos os projetos, uma conta de alojamento com todos os domínios, as mesmas palavras-passe para staging e produção. Aqui vale o princípio dos privilégios mínimos. Mais sobre isto em Direitos do utilizador do servidor web.
Também conta a cadeia de fornecimento: plugins, temas e bibliotecas vêm de terceiros, o fornecedor de alojamento responde pela plataforma, a agência pela operação. Onde passam esses limites e onde surgem lacunas, trata-o Cadeia de fornecimento: agência e fornecedor de alojamento.
Inventário, versões do PHP e comunicação com os clientes
O problema mais frequente nestas situações é a falta de panorâmica: que site corre em que servidor com que versão do PHP, e quem é responsável? Sem esta lista, não se consegue dizer quem é afetado pelo patch e quem não é. Como construir um tal registo, mostra-o Inventário de sites e servidores. Se várias versões do PHP correm em paralelo, ajuda ainda Várias versões do PHP num servidor.
Perante os clientes conta a clareza. Não tem de saber tudo, mas não deve embelezar nada: o que está comprovado, o que ainda está a ser verificado, o que faz a seguir? Encontra ajuda para a redação em Informar os clientes após um incidente. Se dados pessoais estiverem afetados, podem ser relevantes deveres de notificação nos termos do Art. 33 do RGPD. Trata-se de uma informação geral; a avaliação cabe aos encarregados da proteção de dados e ao advogado. Se o incidente se alargar para além de sites individuais, passamos a uma resposta a incidentes estruturada.
O que nos deve enviar
- uma lista dos domínios afetados e dos presumivelmente afetados
- informações sobre o servidor e o alojamento por projeto, na medida do conhecido
- versões do PHP e CMS ou lojas em uso
- os acessos que nos pode conceder e as funções na equipa
- indicações sobre o que foi alterado ou publicado por último
- nome do interlocutor para decisões e para a comunicação com os clientes
Porquê a PHP SOS
Trabalhamos com qualidade Made in Germany e, há mais de 25 anos, estamos especializados em segurança informática com a nossa rede de parceiros de profissionais de cibersegurança. Tem um interlocutor para todos os projetos afetados, trabalhamos remotamente e documentamos, por sistema, o que foi encontrado e feito. Não prometemos milagres. O que não se consegue comprovar, designamo-lo como desconhecido, para que perante os seus clientes não diga mais do que sabe.
Está afetado? Ligue-nos. Nós ajudamos.
Se vários dos sites dos seus clientes apresentam anomalias, a pressão do tempo é dupla: técnica e na relação com os seus clientes. Contacte-nos agora: ligue ou escreva-nos por WhatsApp. Assumimos o caso desde a primeira mensagem e ficamos até o incidente estar encerrado e documentado. Comunicar já uma emergência
Perguntas frequentes
Porque é que muitas vezes vários sites de clientes são afetados ao mesmo tempo?
Com frequência, os sites partilham um servidor, uma conta de alojamento, o mesmo processo PHP ou as mesmas credenciais. Se um atacante entra num ponto, pode mover-se lateralmente. Um PHP vulnerável afeta, além disso, todos os sites que o utilizam.
Devo informar os clientes de imediato?
Depende da situação e do contrato. Esclareça primeiro que sites estão realmente afetados, para não informar com suposições. Havendo dados pessoais, são possíveis deveres de notificação; o enquadramento cabe aos encarregados da proteção de dados ou ao advogado.
Quem responde se o site de um cliente foi hackeado?
Depende dos seus contratos, do âmbito do acompanhamento e do que se passou. Não prestamos aconselhamento jurídico sobre isso. Um relatório rigoroso sobre a causa e as medidas ajuda nesse esclarecimento.
Podem trabalhar em nome da nossa agência, sem que o cliente final nos veja?
Se desejar, trabalhamos em segundo plano para a sua agência e entregamos relatórios que pode transmitir aos seus clientes. Os pormenores discutimo-los antecipadamente.
Basta limpar os sites dos clientes um a um?
Na maioria das vezes, não. Se a causa estiver no servidor partilhado, num acesso partilhado ou numa versão do PHP sem patch, os problemas reaparecem depois da limpeza individual. A causa tem de ser resolvida também.