Em resumo: a monitorização de segurança de servidores significa observar de forma contínua os servidores web em busca de sinais de um ataque, em vez de reagir só quando os clientes se queixam. Vigiamos ficheiros, processos, inícios de sessão, ligações e registos dos seus servidores PHP e enquadramos cada anomalia de forma compreensível. Assim, reconhece os problemas mais cedo e, em caso de emergência, dispõe dos vestígios necessários.
Porque é que a monitorização de segurança de servidores conta precisamente agora
O PHP2Shell mostrou a rapidez com que uma vulnerabilidade nova se pode tornar uma ameaça para milhões de servidores. A Unit 42 contou mais de 22,6 milhões de instâncias expostas e potencialmente vulneráveis. Ao mesmo tempo, não existem indicadores de compromisso (IOCs) confirmados e publicados. Quem quer saber se algo se passa no seu próprio servidor tem de observar o comportamento.
Muitas intrusões só são descobertas tarde, muitas vezes por terceiros: um aviso do Google, um bloqueio do fornecedor de alojamento por envio de spam, uma indicação de um cliente. Até lá, os registos já foram muitas vezes rodados e os vestígios perdidos. A monitorização de segurança encurta esse tempo e garante que os registos ainda existem quando são precisos. Para a administração, isto significa sobretudo uma coisa: as decisões em caso de emergência assentam em factos, e não em suposições.
O que vigiamos
| Área | A que estamos atentos |
|---|---|
| Ficheiros | ficheiros PHP novos ou alterados, código executável em pastas de uploads, alterações em .htaccess e na configuração |
| Processos | comandos iniciados a partir de workers PHP, processos permanentes desconhecidos, workers que falham |
| Inícios de sessão | inícios de sessão SSH e no painel, contas de administrador novas no CMS, tentativas falhadas repetidas |
| Rede | ligações de saída invulgares, envio súbito de correio, portas abertas novas |
| Registos | padrões de pedidos anómalos, acumulação de erros, lacunas no registo |
| Nível de atualização | versões do PHP, do CMS e dos pacotes, comparadas com as atualizações de segurança conhecidas |
Como se podem verificar manualmente estes sinais, descreve-o Analisar registos do servidor web após um ataque. Para os acessos de administração, recomendamos adicionalmente as medidas de Proteger inícios de sessão de administração contra força bruta.
Como ajuda concretamente a PHP SOS?
- Registar a situação de partida: levantamos servidores, aplicações, registos existentes e a vigilância anterior e definimos o que é normal. Sem este estado de partida, não é possível reconhecer com segurança o que é anómalo.
- Configurar a vigilância: configuramos a verificação de integridade de ficheiros, o reencaminhamento de registos para um local de armazenamento separado e regras para as consequências típicas de ataques. Os registos ficam de modo a que um atacante no servidor web não os possa simplesmente apagar.
- Afinação: nas primeiras semanas, ajustamos as regras para que não seja inundado com falsos alarmes, por exemplo devido a atualizações regulares ou deployments.
- Comunicar e enquadrar: comunicamos as anomalias com enquadramento: o que foi observado, quão provável é um ataque e o que fazer a seguir.
- Reportar: a intervalos regulares, recebe um resumo com eventos, atualizações em aberto e recomendações.
Guarde os registos num sistema separado. No caso do PHP2Shell, a imprensa especializada aconselha a preservar os registos do servidor desde 20/10/2026. Quem os guarda de forma centralizada continua a tê-los mesmo que o servidor web tenha de ser reinstalado.
Como é um alerta nosso
Um aviso só serve se for compreendido. Por isso, cada alerta contém os mesmos elementos:
- O que foi observado? Por exemplo: na pasta de uploads de um site surgiu um ficheiro PHP novo e, pouco depois, um worker PHP estabeleceu uma ligação de saída para um endereço desconhecido.
- Como o enquadramos? Está comprovado o ficheiro novo e a ligação. É provável uma relação entre ambos. Desconhece-se se foram transferidos dados.
- O que já fizemos? Por exemplo, preservámos o ficheiro e, se combinado, colocámos o site em modo de manutenção.
- O que tem de decidir? Por exemplo, se o site fica offline até a causa estar esclarecida.
Os eventos inofensivos, como uma atualização regular de plugin, reconhecemo-los pela situação de partida e resumimo-los no relatório, em vez de o incomodar com cada um. Com o tempo, a vigilância passa a conhecer melhor os seus sistemas.
O que recebe e o que precisamos
Recebe uma vigilância configurada, com regras documentadas, alertas rastreáveis com recomendação de ação, relatórios regulares e um arquivo central dos registos. Num incidente confirmado, os dados fluem diretamente para a resposta a incidentes.
Precisamos de si:
- acesso de administrador aos servidores, para configurar agentes e o reencaminhamento de registos
- uma visão geral das aplicações, dos deployments planeados e das janelas de manutenção
- um interlocutor que receba os alertas e possa tomar decisões
- articulação com o seu encarregado da proteção de dados, porque os registos podem conter dados pessoais, como endereços IP
O que não prometemos
A monitorização não deteta todos os ataques. Os atacantes hábeis tentam passar despercebidos e algumas vulnerabilidades deixam poucos vestígios. A monitorização aumenta a probabilidade de se reparar cedo numa intrusão e assegura dados fiáveis. Não substitui nem as atualizações nem o hardening.
Também não fixamos prazos de reação de forma genérica; dependem do acompanhamento acordado. A monitorização desenvolve o seu benefício melhor como parte de um contrato de manutenção de segurança, em que atualizações, cópias de segurança e vigilância são regulados em conjunto.
Perguntas frequentes
Qual é a diferença entre monitorização normal e monitorização de segurança?
A monitorização normal verifica se um servidor está acessível e tem recursos suficientes. A monitorização de segurança está atenta a sinais de um ataque, por exemplo ficheiros executáveis novos, processos invulgares ou inícios de sessão estranhos. As duas complementam-se.
A monitorização deteta um ataque através do PHP2Shell?
Não existem indicadores de compromisso (IOCs) confirmados e publicados para o PHP2Shell. A monitorização pode, no entanto, tornar visíveis as consequências típicas de uma intrusão, como ficheiros PHP novos ou comandos iniciados a partir de um processo PHP. Não há garantia de êxito.
Tenho de instalar software no servidor para isso?
Na maioria dos casos, sim, por exemplo um agente para integridade de ficheiros e reencaminhamento de registos. As ferramentas que utilizamos são combinadas consigo e, se for o caso, com o seu fornecedor de alojamento, para que a operação e a proteção de dados estejam em ordem.
A monitorização de segurança funciona também em alojamento partilhado?
Apenas de forma limitada. Sem acesso a processos e a registos do sistema, resta sobretudo a vigilância de ficheiros e conteúdos a partir do exterior. Para uma vigilância completa é necessário um servidor próprio ou gerido.