Em resumo: Os ataques automatizados a servidores web decorrem em vagas: programas varrem a Internet à procura de servidores acessíveis, classificam-nos com base em características externas e experimentam em massa vulnerabilidades conhecidas como o PHP2Shell. O tamanho da empresa não desempenha qualquer papel. Oferecem proteção um PHP com patch, uma superfície de ataque pequena e uma monitorização que note depressa os acertos bem-sucedidos.
O ponto de partida: “Quem se interessaria pelo nosso site?”
Esta pergunta ouvimo-la muitas vezes depois do PHP2Shell, sobretudo de empresas mais pequenas. A resposta honesta: provavelmente ninguém pessoalmente. Mas, em vulnerabilidades deste tipo, isso também não é necessário. Os ataques são executados por programas que não procuram nomes, mas oportunidades.
O BSI (Gabinete Federal Alemão para a Segurança da Informação) contava, no PHP2Shell, com uma exploração rápida e em larga escala. A Cloudflare relatou tentativas de ataque e que os atacantes alteravam os seus padrões para contornar regras de proteção. Ambas as coisas condizem com o que acontece regularmente em vulnerabilidades críticas em software muito difundido.
Como decorrem os ataques automatizados a servidores web
As campanhas automatizadas seguem em geral um padrão semelhante. O resumo seguinte descreve as fases em termos gerais, sem pormenores de ataque:
| Fase | O que acontece | O que ajuda contra isso |
|---|---|---|
| Procurar | Programas verificam grandes intervalos de endereços ou diretórios públicos, como registos de certificados, à procura de servidores web acessíveis | poucos sistemas acessíveis ao público, inventário de todos os endereços |
| Classificar | As respostas são analisadas: servidor web, versão do PHP, CMS, caminhos típicos | ocultar indicações de versão, remover ficheiros desnecessários |
| Experimentar | Vulnerabilidades conhecidas são testadas em massa, muitas vezes sem classificação prévia | PHP atualizado, reinício, WAF como camada adicional |
| Fixar-se | Em caso de sucesso, é deixada uma porta traseira, por exemplo uma webshell ou uma tarefa cron | permissões de escrita restritas, sem execução de PHP em pastas de uploads |
| Aproveitar | O servidor é usado, por exemplo, para spam, criptomineração, redirecionamentos ou roubo de dados | monitorização de processos, ficheiros e ligações de saída |
Importante é a terceira linha. Muitas campanhas nem sequer se dão ao trabalho de classificar os servidores com precisão antes. Experimentam simplesmente tudo o que é acessível. Por isso, a discrição por si só não protege.
Porque é que os ataques vêm em vagas
As campanhas automatizadas raramente decorrem uma vez e nunca mais. É típico um padrão em vagas. A primeira vaga segue-se logo após a divulgação de uma vulnerabilidade, muitas vezes ainda com ferramentas pouco maduras. Vêm mais vagas quando os atacantes melhoram as suas ferramentas ou as adaptam às regras de proteção. A Cloudflare observou exatamente isso no PHP2Shell: padrões de ataque alterados para contornar as regras.
Para si, isto significa: um servidor que atravessou a primeira vaga sem danos não está seguro de forma duradoura enquanto não tiver o patch. E um servidor acabado de montar passa a ser alvo a partir do momento em que está acessível. Quem, por exemplo, manda emitir um novo certificado TLS torna o nome visível em registos públicos de certificados, que também os scanners analisam. Um sistema novo só deve, por isso, ir para a rede quando já estiver atualizado.
Porque é que as pequenas empresas são igualmente afetadas
Para os ataques automatizados não conta o valor de um alvo individual, mas a quantidade. O servidor de uma pequena empresa oferece capacidade de cálculo, um domínio com boa reputação, um envio de correio e, por vezes, dados de clientes. Para os atacantes, isso é suficiente.
Acresce: as empresas mais pequenas não têm muitas vezes uma TI própria que aplique as atualizações de imediato. Os seus servidores permanecem vulneráveis durante mais tempo e acabam por isso com mais frequência nas listas de resultados dos scanners. Quem aplica o patch primeiro sai dessas listas.
Outro ponto é a cadeia de fornecimento. Muitos sites pequenos estão em servidores de agências ou de pequenos fornecedores de alojamento, nos quais correm dezenas de projetos de clientes lado a lado. Para os atacantes, um servidor destes é particularmente compensador, porque um único acerto afeta muitos sites em simultâneo. O seu risco depende então não só da sua própria diligência, mas também da do seu prestador de serviços.
Varrimentos nos seus registos são normais e não são prova de uma intrusão. Um ataque bem-sucedido revela-se por outros vestígios: novos ficheiros, processos estranhos, contas desconhecidas, ligações de saída invulgares.
O que pode verificar por si próprio
Uma olhadela aos registos mostra com que intensidade o seu servidor é varrido. Os comandos seguintes apenas leem e não alteram nada:
# Os dez endereços com mais pedidos no registo de acessos atual
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10
# Pedidos respondidos com "não encontrado", por frequência
awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# O servidor revela a sua versão do PHP no cabeçalho?
curl -sI https://www.example.de/ | grep -i "x-powered-by"
Muitos pedidos a caminhos inexistentes são o típico ruído de varrimentos. Deve ficar mais atento se, a esses pedidos, se seguirem de repente respostas bem-sucedidas, se em pastas de uploads forem chamados ficheiros que não conhece ou se o utilizador do servidor web iniciar processos que de outro modo nunca inicia. Indicadores de deteção confirmados especificamente para o PHP2Shell não existem até agora; a avaliação assenta, por isso, nestes comportamentos invulgares. Como analisar os registos com mais profundidade é descrito no guia Analisar registos do servidor web. Se a terceira consulta mostrar uma versão do PHP, vale a pena a definição expose_php = Off; os antecedentes encontram-se em Ocultar indicações de versão.
As camadas de proteção pela ordem certa
- Atualizar o PHP e reiniciar: Sem este passo, todas as outras medidas ficam remendos.
- Reduzir a superfície de ataque: desligar sites não utilizados, sistemas de teste e microsites antigos ou colocá-los atrás de uma autenticação.
- Regras na periferia: Uma Web Application Firewall com um conjunto de regras mantido, por exemplo o OWASP Core Rule Set com ModSecurity, trava uma parte das tentativas.
- Travar tentativas repetidas: Ferramentas como o Fail2ban bloqueiam endereços que geram um número invulgar de erros. Contra varrimentos distribuídos, isto ajuda apenas de forma limitada.
- Monitorizar: Manter debaixo de olho os processos do utilizador do servidor web, os novos ficheiros PHP e as ligações de saída, para que um acerto bem-sucedido não passe semanas despercebido.
Como ajuda concretamente a PHP SOS?
- Levantar a superfície de ataque: Apuramos quais dos seus sistemas são acessíveis do exterior e o que revelam sobre si.
- Aplicar patches e reforçar: Atualizamos o PHP, reiniciamos e reduzimos indicações de versão, permissões de escrita e serviços desnecessários.
- Regras e bloqueios: Configuramos regras WAF e mecanismos de bloqueio adequados à sua aplicação.
- Monitorização contínua: Comunicamos processos, ficheiros e ligações invulgares antes de um acerto se tornar um incidente.
Como é isso em funcionamento contínuo é descrito em Monitorização de segurança para servidores web.
Conclusão
Os ataques automatizados não perguntam a quem pertence um servidor. Perguntam apenas se é vulnerável. A melhor resposta a isso é pouco espetacular: aplicar o patch depressa, oferecer pouco, olhar com atenção. Quem o faz continua a ser varrido, mas deixa de ser encontrado.
Perguntas frequentes
As pequenas empresas são alvo de ataques automatizados?
Sim. Os varrimentos automatizados verificam servidores acessíveis sem olhar a quem os opera. Se por trás está um grupo empresarial ou uma oficina, é indiferente para o software. O decisivo é se o servidor parece vulnerável.
Como reconheço varrimentos nos meus registos?
Típicos são muitos pedidos a caminhos que nem existem no seu site, muitas vezes de endereços variáveis e com identificações invulgares. Tais entradas são normais e não são ainda prova de um ataque bem-sucedido, mas mostram que o seu servidor está a ser verificado.
Ajuda ocultar a versão do PHP?
Torna um pouco mais difícil aos scanners classificar o seu servidor de forma direcionada e é uma boa definição de base. Não protege, porém, de ataques que experimentam simplesmente todos os servidores. A atualização continua a ser obrigatória.
Posso impedir completamente os varrimentos?
Não. Todo o servidor acessível ao público é varrido regularmente. O objetivo não é impedir varrimentos, mas garantir que não encontram nada: software atualizado, pouca superfície de ataque e uma monitorização que comunique anomalias.