# Autoridades retiram sites da rede: o que as empresas podem aprender

> Autoridades desligaram sites por precaução devido ao PHP2Shell. O que está por trás, quando faz sentido desligar e como as empresas se podem preparar.

Fonte: https://phpsos.de/pt/blog/behoerden-webseiten-offline/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**Em resumo:** Após o alerta sobre o PHP2Shell, foram desligados sites na Alemanha, entre eles, segundo os media, o portal web da cidade de Mogúncia (Mainz) e páginas do governo regional do Hessen e do BKA (o Gabinete Federal de Polícia Criminal alemão). Tratou-se de precaução seguindo a recomendação do BSI (Gabinete Federal Alemão para a Segurança da Informação), e não de ataques confirmados. As empresas podem aprender daqui: um desligamento é uma opção legítima quando um patch não é possível de imediato, e funciona melhor quando está preparado.

## Sites desligados por causa do PHP: o que aconteceu a 21 de outubro

No dia das atualizações de segurança do PHP, numerosos sites públicos na Alemanha estavam inacessíveis. Segundo notícias dos media, a cidade de Mogúncia desligou por precaução o seu portal web central. Os serviços municipais continuaram contactáveis por telefone e por e-mail.

No Hessen, segundo a hessenschau, estiveram temporariamente offline, entre outras, páginas do governo regional, do BKA (Bundeskriminalamt) e das cidades de Kassel e Wiesbaden. A chancelaria falou de ajustes técnicos e não comunicou qualquer ataque. As páginas do governo regional voltaram a estar acessíveis ao fim da tarde. Segundo notícias, outros municípios, universidades e hospitais também retiraram serviços da rede por precaução.

O contexto é a recomendação do BSI sobre o PHP2Shell: atualizar de imediato e, se isso não for possível de imediato, retirar temporariamente da rede os servidores web afetados. O que o BSI recomenda em pormenor está resumido na página [O que o BSI recomenda sobre o PHP2Shell](https://phpsos.de/pt/compliance/bsi-empfehlungen/).

## Desligado não significa pirateado

Em comentários e redes sociais, “offline” transformou-se depressa em “pirateado”. Segundo tudo o que se sabe, isso é falso. Os desligamentos foram uma medida de proteção num momento em que muitos operadores ainda não conheciam com segurança o nível de patch dos seus servidores.

Esta distinção é duplamente importante para as empresas. Em primeiro lugar, para o exterior: quem se desliga por precaução deve dizê-lo, e não calar. Em segundo lugar, para o interior: um desligamento não responde à pergunta sobre se o servidor foi atacado antes. Apenas pára novas tentativas. A verificação de vestígios continua a ser necessária.

Um terceiro ponto é muitas vezes ignorado: um desligamento não pode destruir vestígios. Quem simplesmente reinstala o servidor para o desligar ou apaga registos para libertar espaço perde a possibilidade de esclarecer mais tarde o que aconteceu antes do desligamento. É melhor redirecionar o servidor web para uma página de emergência ou bloquear o acesso a partir do exterior e deixar o próprio servidor, com todos os registos, inalterado.

## Porque é que foram precisamente as entidades públicas a reagir assim

As autoridades exploram muitas vezes vários sites em simultâneo: portal principal, portais especializados, serviços de formulários, páginas de serviços e instituições individuais. Frequentemente estão envolvidos vários prestadores de serviços. No dia do alerta, para muitas administrações foi simplesmente impossível obter em poucas horas um nível de patch comprovado para cada sistema. O desligamento preventivo foi, nessa situação, o caminho mais rápido para seguir a recomendação do BSI.

Para empresas com um panorama de TI que cresceu ao longo do tempo, a situação é muitas vezes semelhante. A pergunta “Está tudo com patch?” não falha por causa da técnica, mas por falta de visão de conjunto.

Notável é também a rapidez com que as páginas do governo regional do Hessen voltaram, segundo notícias: ainda ao fim da tarde desse mesmo dia. Isto mostra que um desligamento preventivo não tem de durar dias. Quem conhece os seus sistemas e domina a via de atualização consegue aplicar o patch, verificar e voltar a ficar online em poucas horas. O desligamento serve então apenas para cobrir o tempo até haver clareza.

## Quando faz sentido um desligamento preventivo numa empresa

As autoridades têm uma situação especial: muitos sites, muitas vezes com gestão distribuída, e grande visibilidade pública. A ponderação que enfrentaram é, no entanto, a mesma de qualquer empresa. O resumo seguinte ajuda na decisão:

| Situação | Desligar, de preferência | Deixar online, de preferência |
|---|---|---|
| Nível de patch | pouco claro ou não confirmado | corrigido e comprovado, processos reiniciados |
| Versão do PHP | 8.1 ou mais antiga sem backport confirmado | ramo suportado no estado atual |
| Modo de operação | Apache com mod_php | PHP-FPM com patch e com medidas provisórias aplicadas |
| Dados no servidor | dados de clientes, credenciais, dados de pagamento | conteúdos puramente estáticos |
| Disponibilidade do prestador de serviços | patch só possível dentro de dias | patch agendado em breve |

A ponderação entre aplicar o patch, desligar e esperar é aprofundada no artigo [Aplicar o patch, desligar ou esperar?](https://phpsos.de/pt/blog/patchen-abschalten-abwarten/). O que é tecnicamente possível como transição enquanto falta a atualização encontra-se em [Medidas imediatas sem patch](https://phpsos.de/pt/php2shell/sofortmassnahmen-ohne-patch/).

> **Importante:**
> Desligar temporariamente uma loja ou um portal de clientes custa receitas. Um servidor comprometido com dados de clientes pode custar bastante mais, incluindo obrigações de notificação. Tome a decisão de forma consciente e registe-a por escrito.

## Como preparar um desligamento

Mogúncia mostrou o que importa: a administração continuou acessível por outros canais. Isso só é possível se estiver preparado. Estes passos compensam antes de chegar a próxima emergência:

1. **Ter uma página de emergência pronta:** uma página HTML estática sem PHP, com uma breve explicação, contacto telefónico e por e-mail e, se necessário, indicações sobre encomendas ou marcações em curso.
2. **Definir a via de comutação:** quem pode redirecionar o site para a página de emergência, através do servidor web, do DNS ou de um serviço intermédio? Quanto tempo demora?
3. **Clarificar a competência de decisão:** quem pode ordenar um desligamento, mesmo fora do horário de expediente?
4. **Conhecer os serviços dependentes:** há interfaces, aplicações ou parceiros que dependam do site? Quem tem de ser informado antecipadamente?
5. **Definir os critérios de regresso:** patch comprovado, reinício feito, primeira verificação de vestígios sem resultados.
6. **Pré-formular a mensagem:** duas a três frases para clientes, parceiros e imprensa.

Como comunicar para o exterior numa situação destas é descrito no guia de [comunicação de crise](https://phpsos.de/pt/compliance/krisenkommunikation/).

## Como ajuda concretamente a PHP SOS?

- **Base de decisão:** Apuramos o nível de patch, o modo de operação e a situação dos dados dos seus servidores e damos-lhe uma avaliação clara sobre se um desligamento é aconselhável.
- **Desligamento ordenado:** Mudamos para uma página de emergência estática, sem perder registos ou vestígios.
- **Patch e verificação:** Atualizamos o PHP, reiniciamos todos os processos e verificamos se há comportamentos invulgares.
- **Regresso controlado:** Só voltamos a pôr o site online quando os critérios acordados estiverem cumpridos e documentados.

O procedimento é descrito na [ajuda imediata PHP2Shell](https://phpsos.de/pt/leistungen/php2shell-soforthilfe/).

## Conclusão

Os desligamentos das autoridades não foram um sinal de perda de controlo, mas uma medida de precaução deliberada. Para as empresas, esta é a verdadeira lição: ficar offline é uma decisão legítima quando o nível de patch não é claro. Quem tiver preparado página de emergência, responsabilidade e critérios de regresso toma-a em minutos e não em horas.


## Perguntas frequentes

**Porque é que sites de autoridades foram desligados por causa do PHP?**  
No caso do PHP2Shell, o BSI recomenda a atualização imediata e, se esta não for possível de imediato, retirar temporariamente os servidores web da rede. Várias autoridades seguiram esta recomendação por precaução, até os seus sistemas estarem verificados e atualizados.

**Um site desligado significa que foi pirateado?**  
Não. Um desligamento preventivo é uma medida de proteção. A chancelaria do Hessen, por exemplo, não comunicou, segundo a hessenschau, qualquer ataque. Só uma verificação esclarece se um servidor foi afetado antes de ser desligado.

**Durante quanto tempo deve um site ficar offline?**  
Até o PHP estar numa versão corrigida, todos os processos PHP terem sido reiniciados e uma primeira verificação de vestígios não ter dado resultados invulgares. Não há uma duração fixa; segundo notícias, as páginas do governo regional do Hessen voltaram a estar acessíveis ao fim da tarde desse mesmo dia.

**O que mostro aos visitantes enquanto o site está offline?**  
O melhor é uma página de emergência simples e estática, sem PHP, com uma breve explicação e os contactos pelos quais continua acessível. Deve estar preparada antes de ser necessária.

## Fontes

- [hessenschau: Zahlreiche Behörden-Webseiten in Hessen abgeschaltet](https://www.hessenschau.de/panorama/sicherheitsluecke-zahlreiche-behoerden-webseiten-in-hessen-abgeschaltet-v2,sicherheitsprobleme-hacker-webseiten-100.html)
- [ZDFheute: Sicherheitslücke bei PHP](https://zdfheute.de/politik/sicherheitsluecke-php-webseiten-onlinedienste-cybersicherheit-bsi-100.html)
- [BSI: Gabinete Federal Alemão para a Segurança da Informação](https://www.bsi.bund.de/)