Em resumo: está afetado? Ligue-nos. Nós ajudamos. Se tem uma emergência de TI no servidor web e nenhum especialista à mão, contrate-nos com uma mensagem: assumimos o caso desde a primeira mensagem, trabalhamos remotamente, sem deslocações, e registamos tudo por escrito, até o incidente estar encerrado e documentado.
Não apague nada nem reinstale nada agora. Nem sequer como preparação para o prestador. O estado do sistema é o meio de prova mais importante. Comunicar uma emergência, e esclarecemos em conjunto os acessos e os papéis.
Está afetado? Quando é necessário um prestador de emergência
Nem toda a perturbação é um incidente de segurança. Um prestador para a emergência faz sentido quando se verifica pelo menos um destes pontos:
- O seu servidor web comporta-se de forma invulgar e ninguém na casa consegue identificar a causa.
- Há suspeita de código malicioso, de uma intrusão ou de fuga de dados.
- O fornecedor de alojamento bloqueou o serviço ou exige uma limpeza.
- A sua versão do PHP é antiga ou não está esclarecida, e não sabe se as vulnerabilidades PHP2Shell foram exploradas.
- A TI própria ou a agência não está contactável ou não tem experiência com incidentes.
A suspeita basta. Se consegue avançar sozinho ou precisa de apoio, pode ponderá-lo com a página Resolver sozinho ou chamar um prestador?.
O que fazer já
- Congelar o estado. Nenhuma alteração ao servidor, nenhuma ação de limpeza, nenhuma atualização às cegas.
- Listar os acessos. Que acessos de painel, SSH, CMS e base de dados existem, e quem os gere?
- Informar o fornecedor de alojamento. Peça-lhe que conserve registos e snapshots. Não omita nada que ele deva saber.
- Definir o decisor. Quem, na empresa, autoriza desligamentos, reinícios e alterações de palavras-passe?
- Esclarecer a situação dos dados. Existem no sistema dados pessoais, dados de pagamento ou segredos comerciais?
- Informar os envolvidos. O encarregado da proteção de dados e, se existir, o segurador de ciberriscos.
- Contratar o prestador. Ligue ou escreva-nos por WhatsApp. Assumimos o caso desde a primeira mensagem.
Como decorre a contratação
Uma emergência não suporta um processo contratual longo, mas também não suporta lacunas na responsabilidade e na proteção de dados. Por isso procedemos por esta ordem:
- Primeira conversa: ouvimos a situação e fazemos as poucas perguntas necessárias para uma primeira avaliação.
- Acertar o enquadramento: esclarecemos em conjunto que sistemas podemos verificar, quem decide e como nos comunicamos.
- Regular a proteção de dados: se acedermos a sistemas com dados pessoais, discutimos o acordo necessário de subcontratação do tratamento de dados. A página Subcontratação do tratamento de dados com acesso ao servidor explica os fundamentos.
- Configurar o acesso: dá-nos apenas os direitos necessários para o trabalho. Depois da conclusão, os acessos são de novo retirados.
- Trabalho e relatórios: damos notícias com pontos de situação e registamos os resultados por escrito.
Como comparar fornecedores em geral, explica-o Escolher um prestador de segurança informática: 12 perguntas. As obrigações contratuais em torno da segurança são tratadas em Contratos com prestadores: regular com clareza as obrigações de segurança.
Como ajuda concretamente a PHP SOS?
- Levantar a situação: o que aconteceu, que servidores estão em funcionamento, que versões do PHP e que modo de operação (PHP-FPM, mod_php, LiteSpeed) estão em uso?
- Preservar e fechar: preservamos registos, ficheiros e base de dados. Depois resolvemos a causa: patch, configuração ou bloqueio de acessos, com reinício de todos os processos PHP.
- Verificar e limpar: procuramos webshells, backdoors, cronjobs e acessos alheios e removemo-los, ou reconstruímos a partir de fontes limpas.
- Reforçar e relatar: recebe um relatório com cronologia, achados e recomendações. Nos incidentes maiores, passamos a uma resposta a incidentes.
Se por agora se trata apenas da vulnerabilidade do PHP e da prova do patch, serve a ajuda urgente PHP2Shell para empresas. Se existir código malicioso, o ponto de partida certo é a remoção de malware.
Como reconhece um prestador de emergência sério
Numa emergência, muitos recorrem ao primeiro fornecedor que aparece. Três perguntas ajudam a pôr ordem em minutos. Primeiro: preserva-se primeiro e só depois se altera? Quem «arruma» de imediato compromete o esclarecimento posterior. Segundo: o que foi encontrado e feito fica registado por escrito? Sem documentação, nem o segurador nem os encarregados da proteção de dados podem fazer algo com isso. Terceiro: são indicados os limites? Um fornecedor que declara tudo exequível antes de ter visto o sistema deve ser tratado com cautela.
Verifique também se o prestador compreende o seu modo de operação. PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed comportam-se de forma diferente ao aplicar patches, e depois da atualização todos os processos têm de ser reiniciados; caso contrário, o estado antigo continua a correr na memória.
O que um prestador de emergência não pode fazer
Vale a pena conhecer os limites de antemão. Nenhum prestador pode produzir retroativamente registos que nunca foram escritos ou que já foram substituídos. Quando faltam vestígios, indicamos abertamente as lacunas. Também ninguém pode assegurar que um sistema limpo nunca mais será atacado. E o aconselhamento jurídico não faz parte do nosso mandato: as questões sobre deveres de notificação, responsabilidade e seguros vão para o encarregado da proteção de dados, o advogado e o segurador; nós fornecemos-lhes os factos técnicos.
O que nos deve enviar
- breve descrição do incidente e do momento em que foi notado
- domínios e servidores afetados e, na medida do conhecido, a versão do PHP
- nome do fornecedor de alojamento e tipo de contrato (alojamento partilhado, vServer, servidor root, servidor gerido)
- uma pessoa de contacto com poder de decisão
- cópias de segurança existentes e o seu estado
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. Fala com um interlocutor fixo, trabalhamos remotamente em toda a Alemanha e na Europa e documentamos cada passo. Dizemos abertamente o que está comprovado e o que não está, e não fazemos promessas que nenhum prestador sério pode fazer. A nossa ordem é sempre a mesma: primeiro preservar, depois alterar, depois relatar.
Está afetado? Ligue-nos. Nós ajudamos.
Não continue à procura do prestador adequado enquanto o incidente decorre. Ligue ou escreva-nos por WhatsApp; assumimos o caso desde a primeira mensagem. Comunicar já uma emergência.
Perguntas frequentes
Como reconheço um bom prestador de emergência de TI?
Preserva os vestígios antes de alterar o que quer que seja, separa abertamente o que está comprovado do que é suposição, documenta cada passo e não promete milagres. Deve desconfiar de afirmações como «garantidamente tudo limpo», porque ninguém o pode assegurar com seriedade.
Que acessos precisa um prestador numa emergência de TI?
Em regra, acesso por SSH ou painel ao servidor, acesso ao backend do CMS e à base de dados, ou a sua autorização para falar com o fornecedor de alojamento. Dê apenas o que for necessário e registe quem recebeu que acesso e quando.
Preciso de um contrato de subcontratação do tratamento de dados para o acesso remoto?
Se um prestador acede a sistemas com dados pessoais, é em regra necessário um acordo de subcontratação do tratamento de dados. A avaliação cabe aos encarregados da proteção de dados ou aos advogados. Esclarecemos isso consigo logo no início.
Qual é a diferença entre resposta a incidentes e remoção de malware?
A remoção de malware limpa um sistema infetado. A resposta a incidentes é mais ampla: inclui a avaliação da situação, a contenção, a limpeza, a comunicação e o acompanhamento posterior, muitas vezes em vários sistemas.
O meu fornecedor de alojamento tem de ser envolvido?
Muitas vezes sim, por exemplo para snapshots, registos ou para levantar bloqueios. Articulamo-nos com o seu fornecedor de alojamento, desde que o autorize. O que pode ser verificado depende dos direitos que recebermos.