En resumen: Tras la alerta sobre PHP2Shell se desconectaron webs en Alemania, entre ellas, según los medios, el portal web de la ciudad de Maguncia y páginas del Gobierno regional de Hesse y de la BKA (Oficina Federal de Policía Criminal alemana). Fue una medida preventiva siguiendo la recomendación del BSI (Oficina Federal alemana para la Seguridad de la Información), no ataques confirmados. Las empresas pueden aprender de ello: una desconexión es una opción legítima cuando un parche no es posible de inmediato, y sale mejor cuando está preparada.
Webs desconectadas por PHP: lo que ocurrió el 21 de octubre
El día de las actualizaciones de seguridad de PHP, numerosos sitios web públicos no estaban accesibles en Alemania. Según los medios, la ciudad de Maguncia desconectó de forma preventiva su portal web central. Las oficinas siguieron localizables por teléfono y por correo electrónico.
En Hesse, según hessenschau, estuvieron temporalmente fuera de línea, entre otras, páginas del Gobierno regional, de la Oficina Federal de Policía Criminal (BKA) y de las ciudades de Kassel y Wiesbaden. La Cancillería del Estado habló de ajustes técnicos y no comunicó ningún ataque. Las páginas del Gobierno regional volvieron a estar accesibles por la tarde. Según los informes, otros municipios, universidades y clínicas también retiraron servicios de la red como medida preventiva.
El trasfondo es la recomendación del BSI sobre PHP2Shell: actualizar de inmediato y, si no es posible hacerlo enseguida, desconectar temporalmente de la red los servidores web afectados. Lo que aconseja el BSI en detalle lo resume la página Qué recomienda el BSI sobre PHP2Shell.
Desconectado no significa atacado con éxito
En comentarios y redes sociales, «fuera de línea» se convirtió enseguida en «hackeado». Según todo lo que se sabe, eso es falso. Las desconexiones fueron una medida de protección en un momento en que muchos administradores aún no conocían con seguridad el nivel de parcheo de sus servidores.
Para las empresas esta distinción es doblemente importante. Primero, hacia fuera: quien desconecta por precaución debería decirlo así y no callar. Segundo, hacia dentro: una desconexión no responde a la pregunta de si el servidor fue atacado antes. Solo detiene nuevos intentos. La búsqueda de indicios sigue siendo necesaria.
Un tercer punto se pasa por alto con frecuencia: una desconexión no debe destruir pruebas. Quien reinstala el servidor sin más para desconectarlo o borra los registros para ganar espacio se quita la posibilidad de aclarar después qué ocurrió antes de la desconexión. Es mejor redirigir el servidor web a una página de emergencia o bloquear el acceso desde fuera y dejar el propio servidor con todos sus registros sin modificar.
Por qué reaccionaron así precisamente los organismos públicos
Las autoridades suelen operar muchos sitios web a la vez: portal principal, portales especializados, servicios de formularios, páginas de oficinas y centros concretos. Con frecuencia intervienen varios proveedores de servicios. El día de la alerta, a muchas administraciones sencillamente no les era posible obtener en cuestión de horas un nivel de parcheo acreditado para cada sistema. La desconexión preventiva era en esa situación el camino más rápido para seguir la recomendación del BSI.
Para las empresas con un panorama informático crecido con los años, la situación suele ser parecida. La pregunta «¿Está todo parcheado?» no fracasa por la técnica, sino por la falta de visión de conjunto.
También es notable lo rápido que volvieron, según los informes, las páginas del Gobierno regional de Hesse: por la tarde del mismo día. Esto demuestra que una desconexión preventiva no tiene por qué durar días. Quien conoce sus sistemas y domina la vía de actualización puede parchear, comprobar y volver a ponerse en línea en pocas horas. La desconexión solo cubre entonces el tiempo hasta que hay claridad.
Cuándo tiene sentido una desconexión preventiva para las empresas
Las autoridades tienen una situación especial: muchos sitios web, a menudo mantenidos de forma distribuida, y una gran visibilidad pública. Pero la ponderación a la que se enfrentaron es la misma que en cualquier empresa. El siguiente resumen ayuda a decidir:
| Situación | Más bien desconectar | Más bien mantener en línea |
|---|---|---|
| Nivel de parcheo | poco claro o no confirmado | corregido y acreditado, procesos reiniciados |
| Versión de PHP | 8.1 o anterior sin backport confirmado | rama compatible en su versión actual |
| Modo de ejecución | Apache con mod_php | PHP-FPM parcheado con medidas provisionales aplicadas |
| Datos en el servidor | datos de clientes, inicios de sesión, datos de pago | contenidos puramente estáticos |
| Disponibilidad del proveedor | el parche solo es posible en unos días | parche previsto en breve |
La ponderación entre parchear, desconectar y esperar la profundiza el artículo ¿Parchear, desconectar o esperar?. Lo que es técnicamente posible como solución transitoria cuando aún falta la actualización figura en Medidas inmediatas sin parche.
Desconectar temporalmente una tienda o un portal de clientes cuesta ventas. Un servidor comprometido con datos de clientes puede costar bastante más, incluidas las obligaciones de notificación. Tome la decisión de forma consciente y déjela por escrito.
Cómo preparar una desconexión
Maguncia mostró lo que importa: la administración siguió localizable por otros canales. Eso solo funciona si está preparado. Estos pasos merecen la pena antes de que llegue la próxima emergencia:
- Tener lista una página de emergencia: una página HTML estática sin PHP, con una breve explicación, contacto por teléfono y correo electrónico y, si hace falta, indicaciones sobre pedidos o citas en curso.
- Fijar la vía de conmutación: ¿quién puede redirigir la web a la página de emergencia, mediante el servidor web, el DNS o un servicio previo? ¿Cuánto tarda?
- Aclarar la competencia de decisión: ¿quién puede ordenar una desconexión, también fuera del horario laboral?
- Conocer los servicios dependientes: ¿hay interfaces, aplicaciones o socios que dependan de la web? ¿A quién hay que informar de antemano?
- Definir los criterios de vuelta: parche acreditado, reinicio realizado, primera búsqueda de indicios sin resultado.
- Redactar el mensaje de antemano: dos o tres frases para clientes, socios y prensa.
Cómo comunicar hacia fuera en una situación así lo describe la guía sobre la comunicación de crisis.
¿Cómo ayuda PHP SOS en concreto?
- Base para decidir: determinamos el nivel de parcheo, el modo de ejecución y la situación de los datos de sus servidores y le damos una valoración clara de si procede una desconexión.
- Desconexión ordenada: conmutamos a una página de emergencia estática sin perder registros ni indicios.
- Parche y revisión: actualizamos PHP, reiniciamos todos los procesos y buscamos anomalías.
- Vuelta controlada: solo volvemos a poner la web en línea cuando los criterios acordados se cumplen y están documentados.
El procedimiento lo describe la ayuda inmediata ante PHP2Shell.
Conclusión
Las desconexiones de las autoridades no fueron una señal de pérdida de control, sino una medida de precaución consciente. Para las empresas esa es la verdadera lección: pasar a fuera de línea es una decisión legítima cuando el nivel de parcheo es incierto. Quien tiene preparadas la página de emergencia, la responsabilidad y los criterios de vuelta la toma en minutos en lugar de horas.
Preguntas frecuentes
¿Por qué se desconectaron webs de autoridades por PHP?
Ante PHP2Shell, el BSI recomienda actualizar de inmediato y, si no es posible hacerlo enseguida, desconectar temporalmente los servidores web de la red. Varias autoridades siguieron esta recomendación como medida preventiva hasta que sus sistemas estuvieron revisados y actualizados.
¿Una web desconectada significa que ha sido atacada con éxito?
No. Una desconexión preventiva es una medida de protección. La Cancillería del Estado de Hesse, por ejemplo, no comunicó ningún ataque, según hessenschau. Si un servidor estaba afectado antes de la desconexión solo lo aclara una revisión.
¿Cuánto tiempo debe permanecer desconectada una web?
Hasta que PHP esté en una versión corregida, todos los procesos de PHP se hayan reiniciado y una primera búsqueda de indicios no haya arrojado anomalías. No hay una duración fija; según los informes, las webs del Gobierno regional de Hesse volvieron a estar accesibles por la tarde del mismo día.
¿Qué muestro a los visitantes mientras la web está desconectada?
Lo mejor es una página de emergencia sencilla y estática, sin PHP, con una breve explicación y las vías de contacto por las que sigue siendo localizable. Debe estar preparada antes de que haga falta.