En resumen: un inventario TI de servidores web es una lista de todos los sitios web, portales, tiendas y servidores con los datos que se necesitan al instante ante un aviso de seguridad: dónde se ejecuta, con qué versión y modo de PHP, qué aplicación, quién es responsable y qué datos se verían afectados. Sin esta lista, toda reacción empieza buscando. Con ella, el cotejo ante un aviso como PHP2Shell lleva minutos en lugar de días.
La primera pregunta fue: ¿dónde se ejecuta PHP en nuestra empresa?
Cuando el proyecto PHP publicó los parches el 21 de octubre de 2026 y el BSI (Oficina Federal alemana para la Seguridad de la Información) recomendó actuar de inmediato, la indicación era clara: actualizar PHP y reiniciar todos los procesos. Sin embargo, para muchas empresas el primer paso no fue la actualización, sino hacer inventario. El sitio web principal era conocido. ¿Pero el portal de distribuidores? ¿La página de empleo en otro proveedor? ¿La landing page de una campaña de hace tres años? ¿La wiki interna?
La prensa especializada y los servicios de medición han dejado ver la magnitud del problema. Palo Alto Networks (Unit 42) contó más de 22,6 millones de instancias expuestas y potencialmente vulnerables. Entre ellas habrá muchos sistemas en los que sus propios operadores sencillamente ya no piensan.
Qué debe incluir un inventario TI de servidores web
Un inventario útil es una tabla con una fila por sitio web o aplicación. Estas columnas han demostrado su valor:
| Columna | Ejemplo | Para qué sirve |
|---|---|---|
| Dirección | tienda.ejemplo.de | asignación inequívoca |
| Finalidad e importancia | tienda online, crítica para las ventas | priorización |
| Proveedor o ubicación | servidor gestionado del proveedor X | a quién se llama |
| Servidor y sistema operativo | vServer, Debian | vía de actualización, fuentes de seguridad |
| Servidor web y modo de PHP | Nginx con PHP-FPM | riesgo, p. ej. mod_php |
| Versión de PHP y estado del paquete | 8.3, paquete con fecha | cotejo con los avisos |
| Aplicación y versión | Shopware, plugins | avisos del fabricante |
| Responsable interno / externo | dirección de TI / agencia Y | quién actúa |
| Datos procesados | cuentas de clientes, pedidos | obligaciones de notificación, urgencia |
| Copias de seguridad | diaria, externa, última prueba el … | restauración |
| Última prueba de parche | fecha y justificante | prueba ante terceros |
El modo de funcionamiento merece especial atención. En PHP2Shell, el equipo de PHP clasificó el riesgo como más alto en Apache con mod_php. Quien sabe qué sistemas se operan así puede abordarlos primero. La columna del estado del paquete es importante porque el número de versión mostrado suele seguir igual tras los backports; puede encontrar indicaciones en Comprobar correctamente la versión de PHP y el estado del parche.
Encontrar sistemas olvidados: cómo proceder
Los sistemas conocidos se registran enseguida. El verdadero trabajo son los desconocidos. Estas fuentes ayudan a localizarlos:
- Dominios y DNS: revisar todos los dominios de la empresa y sus subdominios. Cada entrada que apunte a un servidor web es un candidato.
- Facturas: la contabilidad conoce a todos los proveedores de alojamiento, registradores y servicios en la nube que cobran. A menudo es la lista más completa.
- Agencias y departamentos: marketing, ventas y personal encargan sitios web directamente con frecuencia. Pregunte.
- Servidores conocidos: en cada servidor, la configuración muestra qué sitios web sirve realmente.
- Dispositivos con interfaz web: NAS, routers y appliances incorporan a veces su propio PHP; véase PHP en NAS, routers y appliances.
Para el paso 4, en servidores Linux ayudan algunos comandos de solo lectura. Muestran los sitios web configurados, los servicios PHP y los pools de FPM:
# Sitios web configurados (Apache o Nginx)
apachectl -S 2>/dev/null
nginx -T 2>/dev/null | grep -E "^\s*server_name" | sort -u
# Servicios y procesos de PHP en ejecución
systemctl list-units --type=service | grep -iE "php|fpm|lsws|litespeed"
ps -eo user,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep | sort | uniq -c
# Pools de FPM en Debian y Ubuntu
ls /etc/php/*/fpm/pool.d/ 2>/dev/null
Si en un servidor se ejecutan varias versiones de PHP en paralelo, cada una debe figurar en la lista. Cada una debe actualizarse y reiniciarse por separado.
Registre también los sistemas que en realidad deberían apagarse. Precisamente ellos suelen seguir funcionando, llevan años sin actualizarse y se olvidan. Con una entrada «apagar antes de …» la tarea sigue visible.
Mantener el inventario actualizado
Un inventario vale lo que valga su última actualización. Tres reglas lo mantienen vivo. Primera: una persona es responsable y se le informa de cada sitio web nuevo, cada traslado y cada baja, incluso cuando el trabajo lo realiza una agencia. Segunda: una vez por trimestre se contrasta la lista con el DNS, las facturas y la configuración de los servidores. Tercera: el inventario forma parte del plan de emergencia y está disponible también fuera de la propia TI, por ejemplo impreso.
Para empresas con muchos sistemas distribuidos, como portales de distribuidores, configuradores y accesos de proveedores, Seguridad TI para la pyme y la industria describe los lugares típicos donde aparecen. Cómo integrar el inventario en el plan de emergencia se explica en Crear un plan de emergencia TI para servidores web.
Errores frecuentes en el inventario de servidores web
Muchos inventarios existen, pero no ayudan en caso de emergencia. Las causas se parecen:
- Solo servidores, sin sitios web: la lista nombra máquinas, pero no qué sitios web se ejecutan en ellas ni quién es responsable de ellos desde el punto de vista funcional. Ante una vulnerabilidad, nadie sabe qué departamento está afectado.
- Versión en lugar de estado del paquete: «PHP 8.3» dice poco tras PHP2Shell. Solo el estado del paquete y la fecha muestran si la corrección está incluida.
- Faltan sistemas externos: lo que se ejecuta en una agencia o en un servicio de plataforma se omite porque «allí no somos responsables». La responsabilidad sobre los datos se queda, sin embargo, en casa.
- Sin interlocutores: una entrada sin nombre ni teléfono del responsable hace perder tiempo en una emergencia.
- Acción puntual: el inventario se elabora en una semana de crisis y después no se vuelve a abrir. Al cabo de un año, una buena parte ya no es correcta.
Quien evita estos cinco puntos tiene, en el próximo aviso, una lista con la que realmente se puede trabajar.
¿Cómo ayuda PHP SOS en concreto?
- Registramos con usted todos los sitios web y servidores, también los olvidados, a través del DNS, las facturas, los proveedores y la configuración de los servidores.
- Determinamos para cada sistema el modo de funcionamiento, la versión de PHP y el estado real del paquete.
- Priorizamos los sistemas según accesibilidad, datos y modo de funcionamiento, e indicamos dónde hay que actuar primero.
- Donde PHP2Shell sigue abierto, cerramos la vulnerabilidad mediante la ayuda inmediata PHP2Shell y anotamos la prueba en el inventario.
Conclusión: un inventario es la medida de seguridad más discreta y, a la vez, más eficaz. Quien sabe qué se ejecuta puede actuar al instante ante el próximo aviso, en lugar de empezar buscando.
Preguntas frecuentes
¿Qué datos necesita como mínimo un inventario de servidores web?
Dirección del sitio web, servidor o proveedor de alojamiento, modo de funcionamiento de PHP, versión de PHP con el estado del paquete, aplicación con su versión, persona responsable interna y externa, tipo de datos procesados y ubicación de las copias de seguridad. Con estos datos se puede contrastar con rapidez cualquier nuevo aviso de seguridad.
¿Cómo encuentro sitios web de los que ya nadie sabe nada?
Por varias vías a la vez: la gestión de dominios y las zonas DNS, las facturas de proveedores de alojamiento y registradores, preguntas a agencias y departamentos, y la configuración de los servidores conocidos. Así suelen aparecer páginas de campañas antiguas, sistemas de pruebas y subdominios.
¿Quién debería mantener el inventario?
Una persona designada, normalmente en el departamento de TI o en la dirección de TI. Es importante que allí se comunique cualquier cambio en sitios web y servidores, incluso cuando lo haya encargado un departamento o una agencia.
¿Basta una tabla o hace falta un software?
Para la mayoría de las pymes basta una tabla bien mantenida. Un software compensa cuando se quieren registrar automáticamente muchos sistemas. Lo decisivo es que esté actualizado, no la herramienta.