Cómo inventariar servicios instalados en un servidor Linux

Introducción

Inventariar los servicios instalados en un servidor Linux no consiste en copiar una lista de paquetes ni en ejecutar un único comando y guardar su salida. Un servidor puede contener cientos de paquetes, decenas de unidades de systemd, procesos temporales, sockets, contenedores, tareas programadas y aplicaciones instaladas manualmente. Solo una parte de esos elementos presta servicios reales a usuarios, aplicaciones o procesos empresariales.

La dificultad aparece cuando el servidor lleva años funcionando, ha pasado por varias personas, ha recibido migraciones, pruebas, scripts y cambios urgentes. Puede haber servicios habilitados que nadie utiliza, demonios que escuchan en red sin estar documentados, aplicaciones iniciadas desde cron, contenedores que no aparecen en el gestor de paquetes, binarios copiados en /usr/local y procesos críticos que dependen de una cuenta personal.

En ese contexto, preguntar “qué ejecuta este servidor” no se responde mirando únicamente systemctl. Hay que combinar varias fuentes: unidades de servicio, procesos, puertos, paquetes, contenedores, temporizadores, tareas programadas, archivos de configuración, usuarios técnicos, rutas de datos y dependencias externas.

Este artículo presenta un método práctico para construir un inventario fiable de servicios en Linux. El objetivo es identificar qué existe, qué está activo, cómo arranca, qué función cumple, qué recursos utiliza, qué datos trata, quién lo administra y qué ocurriría si se detuviera.

El enfoque está pensado para servidores de pequeñas empresas, VPS, máquinas virtuales, servidores web, plataformas WordPress, aplicaciones internas y entornos LMS donde la infraestructura debe poder mantenerse con pocos recursos y sin depender de la memoria de una sola persona.

Índice

• Qué es un inventario de servicios Linux
• Qué debe considerarse un servicio
• Diferencia entre paquete, proceso, servicio, socket y aplicación
• Preparar la revisión antes de ejecutar comandos
• Registrar la identidad y el contexto del servidor
• Inventariar servicios gestionados por systemd
• Distinguir servicios habilitados, activos y fallidos
• Analizar cada unidad de servicio
• Inventariar procesos en ejecución
• Identificar servicios que escuchan en red
• Revisar paquetes instalados sin confundirlos con servicios
• Detectar software instalado manualmente
• Inventariar contenedores y servicios aislados
• Revisar cron, timers y tareas programadas
• Identificar usuarios y cuentas técnicas
• Localizar configuración, datos y registros
• Registrar dependencias técnicas y empresariales
• Clasificar criticidad y estado
• Modelo de inventario recomendado
• Procedimiento completo paso a paso
• Cómo validar que el inventario representa la realidad
• Cómo detectar y retirar servicios obsoletos
• Qué partes conviene automatizar
• Ejemplo aplicado a un servidor web con LMS
• Errores frecuentes
• Lista de comprobación
• Preguntas frecuentes
• Conclusión

Qué es un inventario de servicios Linux

Un inventario de servicios Linux es una relación estructurada de los componentes que se ejecutan o pueden ejecutarse en un servidor para prestar una función técnica o empresarial.

Debe permitir responder preguntas como estas:

• ¿Qué servicios están instalados?
• ¿Cuáles están activos ahora?
• ¿Cuáles arrancan automáticamente?
• ¿Qué proceso ejecuta cada servicio?
• ¿Qué usuario y grupo utiliza?
• ¿Qué puertos abre?
• ¿Qué archivos de configuración necesita?
• ¿Dónde guarda sus datos y logs?
• ¿De qué otros servicios depende?
• ¿Qué aplicación o proceso empresarial sostiene?
• ¿Quién lo administra?
• ¿Cómo se comprueba su estado?
• ¿Cómo se reinicia y cómo se recupera?
• ¿Puede retirarse sin impacto?

La diferencia entre un inventario útil y una salida de comandos está en el contexto. Saber que existe nginx.service es solo el comienzo. El inventario debe indicar qué sitios publica, qué certificados utiliza, qué configuraciones carga, qué upstreams necesita, quién recibe las alertas y qué actividad se detendría si Nginx dejara de funcionar.

El inventario no debe limitarse a descubrir nombres técnicos: debe conectar cada servicio con su función, sus dependencias y su impacto.

Esta pieza complementa el inventario más amplio de servidores, aplicaciones y servicios. Allí se obtiene una visión empresarial del ecosistema completo; aquí se profundiza en una sola máquina Linux para conocer exactamente qué ejecuta.

Qué debe considerarse un servicio

En Linux, la palabra servicio suele asociarse a una unidad gestionada por systemd, pero un inventario operativo necesita un alcance más amplio.

Servicios gestionados por systemd

Son unidades con extensión .service que systemd inicia, detiene, supervisa o reinicia.

Servicios activados por socket

Algunos procesos no permanecen siempre activos. systemd escucha mediante una unidad .socket y arranca el servicio cuando llega una conexión.

Tareas periódicas

Un proceso ejecutado cada hora mediante cron o un timer puede ser tan crítico como un demonio permanente. Por ejemplo, una copia, una sincronización o una importación de matrículas.

Aplicaciones iniciadas manualmente

Puede haber procesos lanzados desde scripts, sesiones screen o tmux, perfiles de usuario o comandos ejecutados tras cada reinicio.

Contenedores

Docker, Podman u otras plataformas pueden ejecutar bases de datos, aplicaciones, colas y servicios web que no aparecen como paquetes tradicionales.

Servicios proporcionados por un servidor de aplicaciones

Un único proceso puede alojar varias aplicaciones. Por ejemplo, PHP-FPM puede mantener varios pools y un servidor Java puede publicar distintas aplicaciones.

Servicios de infraestructura

DNS, sincronización horaria, firewall, monitorización, copias, autenticación y registro centralizado también deben inventariarse aunque no sean visibles para usuarios finales.

El criterio práctico es sencillo: si un componente ejecuta trabajo, escucha peticiones, procesa datos, mantiene una función o puede afectar a la continuidad del servidor, debe aparecer en la revisión.

Diferencia entre paquete, proceso, servicio, socket y aplicación

Un paquete instalado no demuestra que exista un servicio activo. Un proceso activo no demuestra que deba arrancar tras reiniciar. Un puerto abierto no explica qué aplicación lo usa. Por eso, el inventario necesita cruzar varias fuentes.

Preparar la revisión antes de ejecutar comandos

La revisión debe realizarse con una cuenta autorizada y con acceso suficiente para consultar systemd, procesos, sockets y configuraciones. No es necesario modificar nada durante la fase de descubrimiento.

Trabajar primero en modo lectura

No conviene deshabilitar, detener o borrar servicios mientras todavía se está construyendo el inventario. Una unidad desconocida puede sostener una función indirecta.

Registrar fecha y alcance

La salida representa un momento concreto. Debe anotarse fecha, servidor, entorno y persona que realiza la revisión.

Incluir periodos representativos

Algunos procesos solo aparecen durante copias, cierres mensuales, campañas o tareas nocturnas. Una observación de cinco minutos puede no detectarlos.

Conservar evidencias

Las salidas pueden guardarse en una carpeta de auditoría con permisos restringidos. Debe evitarse incluir secretos, variables sensibles o contenidos de configuración completos sin necesidad.

No confiar en una única herramienta

Systemd no muestra por sí solo contenedores, cron de usuarios, binarios iniciados manualmente ni servicios remotos consumidos por la máquina.

Registrar la identidad y el contexto del servidor

Antes de inventariar servicios, conviene identificar inequívocamente la máquina.

hostnamectl
cat /etc/os-release
uname -a
systemd-detect-virt
uptime

La ficha inicial debería incluir:

• nombre de host;
• entorno: producción, pruebas o desarrollo;
• distribución y versión;
• kernel;
• tipo de virtualización;
• direcciones IP principales;
• fecha del último arranque;
• propietario funcional;
• responsable técnico;
• servicios empresariales que se espera encontrar.

Esta información evita mezclar resultados de máquinas parecidas y ayuda a detectar incoherencias. Por ejemplo, un servidor identificado como “base de datos” que también publica webs, ejecuta copias y aloja automatizaciones.

Inventariar servicios gestionados por systemd

En la mayoría de distribuciones Linux actuales, systemd es la principal fuente para conocer servicios y su estado.

Listar unidades de servicio cargadas

systemctl list-units --type=service --all

Esta salida muestra unidades cargadas, estén activas, inactivas o fallidas. Es útil para observar el estado actual, pero no incluye necesariamente todas las unidades instaladas.

Listar archivos de unidad instalados

systemctl list-unit-files --type=service

Esta segunda vista permite descubrir servicios habilitados, deshabilitados, estáticos, enmascarados o generados.

Guardar una salida ordenada

systemctl list-unit-files --type=service --no-pager --no-legend \
  | sort

Revisar unidades personalizadas

Las ubicaciones habituales incluyen:

• /etc/systemd/system/, normalmente para unidades locales o sobrescrituras;
• /usr/lib/systemd/system/ o /lib/systemd/system/, según distribución;
• ~/.config/systemd/user/, para servicios de usuario.

Las unidades bajo /etc/systemd/system merecen especial atención porque suelen corresponder a aplicaciones propias, adaptaciones o servicios creados manualmente.

find /etc/systemd/system -maxdepth 2 -type f -o -type l

No debe asumirse que toda unidad de esa ruta es crítica, pero sí debe investigarse su origen y finalidad.

Distinguir servicios habilitados, activos y fallidos

Estas categorías responden a preguntas distintas.

Habilitado

Está configurado para iniciarse por una dependencia o durante el arranque correspondiente.

systemctl list-unit-files --type=service --state=enabled

Activo

Está ejecutándose o ha completado correctamente una acción de tipo puntual.

systemctl list-units --type=service --state=running

Fallido

Ha terminado con error y systemd conserva ese estado.

systemctl --failed

Deshabilitado

No arranca automáticamente por sí mismo, pero puede iniciarse manualmente, por una dependencia, por socket o por timer.

Estático

No tiene una sección de instalación que permita habilitarlo de forma convencional. Puede ser requerido por otras unidades.

Enmascarado

Está bloqueado para impedir su arranque. Debe registrarse el motivo, especialmente si se hizo para resolver una incompatibilidad.

Un inventario serio no clasifica un servicio como “no usado” solo porque aparezca deshabilitado o inactivo. Hay que comprobar activación por socket, timer, dependencia o ejecución ocasional.

Analizar cada unidad de servicio

Para una unidad concreta, systemctl status ofrece una primera visión:

systemctl status nginx.service

Para consultar propiedades estructuradas:

systemctl show nginx.service

Y para ver el archivo de unidad junto con sus sobrescrituras:

systemctl cat nginx.service

Campos que conviene registrar

• nombre de la unidad;
• descripción;
• estado de carga;
• estado activo;
• estado de habilitación;
• ruta del archivo de unidad;
• comando de inicio;
• usuario y grupo;
• directorio de trabajo;
• variables de entorno;
• dependencias Requires y Wants;
• orden de arranque;
• política de reinicio;
• límites de recursos;
• ruta de PID cuando proceda;
• último resultado;
• documentación asociada.

Comprobar dependencias de systemd

systemctl list-dependencies nginx.service

La relación mostrada por systemd es técnica. Después debe traducirse a dependencias operativas: DNS, certificados, base de datos, almacenamiento, red, servicios externos o tareas humanas.

Revisar logs recientes

journalctl -u nginx.service --since "7 days ago"

Los logs ayudan a confirmar si el servicio se utiliza, si reinicia, si falla y qué volumen de actividad presenta. No deben copiarse indiscriminadamente al inventario; basta con registrar ubicación, patrón de revisión y hallazgos relevantes.

Inventariar procesos en ejecución

Los procesos permiten descubrir software que no aparece claramente en systemd o que ha sido iniciado por otro mecanismo.

ps -eo pid,ppid,user,group,lstart,etime,cmd --sort=user,pid

También puede utilizarse una vista jerárquica:

ps -ef --forest

Qué observar

• procesos con tiempos de ejecución muy largos;
• binarios bajo /opt, /srv, /usr/local o directorios personales;
• procesos ejecutados como root sin necesidad aparente;
• intérpretes Python, Node.js, Java o PHP con scripts propios;
• sesiones screen o tmux que mantienen aplicaciones;
• procesos huérfanos o relanzados manualmente;
• agentes de monitorización, copia o seguridad;
• procesos que no corresponden a ningún servicio esperado.

Relacionar proceso y unidad

Para un PID concreto puede consultarse su cgroup:

cat /proc/PID/cgroup

También puede inspeccionarse información básica:

readlink -f /proc/PID/exe
tr '\0' ' ' < /proc/PID/cmdline
ls -ld /proc/PID/cwd

Estas comprobaciones deben realizarse con cuidado porque las líneas de comando y el entorno pueden contener datos sensibles.

El objetivo no es documentar cada proceso del kernel, sino detectar aplicaciones persistentes, agentes, demonios y componentes propios que deban formar parte del inventario.

Identificar servicios que escuchan en red

Un servicio que escucha en una interfaz de red puede estar expuesto a otras máquinas o a Internet. Debe conocerse qué proceso abre cada puerto y por qué.

sudo ss -lntup

Para incluir sockets Unix:

sudo ss -lxnp

Campos que deben registrarse

• protocolo;
• dirección de escucha;
• puerto;
• proceso y PID;
• interfaz: local, red interna o todas;
• servicio que lo utiliza;
• usuarios o sistemas autorizados;
• protección mediante firewall;
• cifrado o túnel;
• necesidad empresarial.

Diferenciar exposición local y externa

Un proceso escuchando en 127.0.0.1 solo acepta conexiones locales, salvo mecanismos adicionales. Un proceso en 0.0.0.0 o :: puede escuchar en todas las interfaces disponibles, aunque el firewall todavía pueda limitar el acceso.

No debe concluirse que un puerto es accesible desde Internet únicamente por la salida de ss. Hay que considerar firewall local, reglas perimetrales, NAT, VPN y redes del proveedor.

Los servicios expuestos deben contrastarse con las medidas descritas en cómo proteger un servidor Linux básico y, para la administración remota, con la auditoría y el hardening de SSH.

Revisar paquetes instalados sin confundirlos con servicios

El gestor de paquetes ayuda a identificar software y origen, pero su salida es mucho más amplia que el inventario de servicios.

Debian y Ubuntu

dpkg-query -W -f='${Package}\t${Version}\n'
apt-mark showmanual

RHEL, Rocky Linux, AlmaLinux y Fedora

rpm -qa --qf '%{NAME}\t%{VERSION}-%{RELEASE}\n'
dnf repoquery --userinstalled

Qué aporta esta revisión

• versión instalada;
• origen mediante repositorio;
• paquetes instalados manualmente;
• dependencias;
• software potencialmente obsoleto;
• componentes que dejaron archivos de unidad.

Qué no demuestra

• que el servicio esté activo;
• que arranque automáticamente;
• que se utilice;
• que su configuración sea la predeterminada;
• que no exista otra versión instalada manualmente.

Los paquetes deben utilizarse como una fuente de contraste. Si hay una unidad activa cuyo binario no pertenece a ningún paquete conocido, puede tratarse de software propio, una instalación manual o un componente eliminado de forma incompleta.

Detectar software instalado manualmente

Parte del software empresarial se instala fuera del gestor de paquetes. Puede encontrarse en:

• /usr/local/bin y /usr/local/sbin;
• /opt;
• /srv;
• directorios de aplicaciones;
• entornos virtuales de Python;
• instalaciones globales de npm;
• archivos JAR;
• binarios descargados;
• scripts en carpetas personales.

find /usr/local/bin /usr/local/sbin /opt /srv \
  -maxdepth 3 -type f -executable 2>/dev/null

La salida debe revisarse, no importarse automáticamente como inventario. Muchos archivos ejecutables son herramientas auxiliares y no servicios.

Preguntas para cada instalación manual

• ¿Quién la instaló?
• ¿De dónde procede?
• ¿Qué versión es?
• ¿Cómo se actualiza?
• ¿Cómo arranca?
• ¿Dónde está su configuración?
• ¿Qué datos conserva?
• ¿Existe repositorio o copia del instalador?
• ¿Puede reconstruirse?
• ¿Tiene soporte?

Este tipo de software suele concentrar deuda técnica porque puede quedar fuera de actualizaciones automáticas, inventarios y procedimientos estándar.

Inventariar contenedores y servicios aislados

Un servidor con Docker o Podman puede ejecutar numerosos servicios sin que cada uno tenga una unidad systemd independiente.

Docker

docker ps -a
docker images
docker network ls
docker volume ls

Podman

podman ps -a
podman images
podman network ls
podman volume ls

Qué registrar por contenedor

• nombre;
• imagen y etiqueta;
• finalidad;
• estado;
• política de reinicio;
• puertos publicados;
• redes;
• volúmenes;
• variables y secretos, sin copiar su contenido;
• límites de recursos;
• dependencias;
• ubicación del archivo Compose o definición;
• procedimiento de actualización;
• procedimiento de copia y restauración.

También deben revisarse contenedores detenidos. Pueden ser restos de pruebas, versiones anteriores o piezas necesarias para recuperación.

No inventariar solo contenedores

La unidad funcional puede estar compuesta por varios contenedores. Por ejemplo, una aplicación web, una base de datos, una cola y un proxy. El inventario debe agruparlos bajo el servicio que prestan y conservar también el detalle técnico.

Revisar cron, timers y tareas programadas

Las tareas programadas suelen ser invisibles hasta que fallan. Pueden realizar copias, limpiezas, importaciones, renovaciones, sincronizaciones o generación de informes.

Timers de systemd

systemctl list-timers --all

Para analizar uno concreto:

systemctl cat nombre.timer
systemctl status nombre.timer
systemctl status nombre.service

Cron del sistema

cat /etc/crontab
find /etc/cron.d /etc/cron.hourly /etc/cron.daily \
  /etc/cron.weekly /etc/cron.monthly -maxdepth 2 -type f

Cron de usuarios

sudo crontab -l
sudo crontab -u usuario -l

La revisión de crontabs de usuarios debe realizarse solo con autorización y siguiendo una lista de cuentas relevantes.

Qué documentar

• identificador de la tarea;
• frecuencia;
• usuario;
• comando o script;
• directorio de trabajo;
• entradas y salidas;
• log;
• duración esperada;
• tratamiento de errores;
• alerta;
• impacto si no se ejecuta;
• método de reejecución.

Una tarea que no permanece activa sigue siendo un servicio operativo si produce un resultado necesario.

Identificar usuarios y cuentas técnicas

Los servicios se ejecutan bajo identidades. El inventario debe mostrar qué cuentas pertenecen a personas, aplicaciones o componentes del sistema.

getent passwd

Para observar procesos agrupados por usuario:

ps -eo user,comm,pid,ppid --sort=user,comm

Información útil

• nombre de cuenta;
• tipo: humana, técnica o del sistema;
• servicio asociado;
• shell;
• directorio personal;
• grupos;
• capacidad de inicio de sesión;
• propietario;
• fecha de revisión;
• método de recuperación.

Las cuentas técnicas no deberían depender de la identidad personal de quien instaló el servicio. La creación y protección de administradores se desarrolla en cómo crear usuarios seguros en Linux.

Localizar configuración, datos y registros

Un servicio no puede considerarse inventariado si solo se conoce su nombre. Hay que saber qué necesita para reconstruirse y mantenerse.

Configuración

Las rutas habituales incluyen /etc, directorios propios bajo /opt o /srv, variables de entorno, archivos Compose y sobrescrituras de systemd.

Datos persistentes

Pueden encontrarse en:

• /var/lib;
• /srv;
• /var/www;
• volúmenes de contenedores;
• montajes externos;
• bases de datos;
• directorios de usuarios.

Registros

El servicio puede escribir en journald, /var/log, una base de datos, un sistema remoto o un volumen propio.

Archivos temporales y cachés

Conviene distinguir datos esenciales de cachés, temporales y archivos regenerables. Esta separación afecta a copias, recuperación y control de espacio.

Certificados y secretos

El inventario debe indicar ubicación y responsable, pero no copiar contraseñas, claves privadas o tokens. Los secretos deben permanecer en un sistema de custodia adecuado.

La documentación detallada de estas rutas puede enlazarse con cómo documentar correctamente un servidor Linux, mientras que el presente inventario conserva la visión de conjunto sobre qué servicios existen.

Registrar dependencias técnicas y empresariales

Un servicio rara vez funciona de forma aislada. Debe registrarse tanto de qué depende como qué otros componentes dependen de él.

Dependencias técnicas

• red;
• DNS;
• almacenamiento;
• base de datos;
• servicio de identidad;
• certificados;
• colas;
• otros procesos locales;
• API externas;
• montajes remotos.

Dependencias operativas

• persona que revisa alertas;
• proveedor que mantiene la aplicación;
• cuenta administrativa;
• procedimiento manual;
• licencia;
• renovación;
• ventana de mantenimiento.

Dependencias empresariales

Debe indicarse qué proceso queda afectado: venta, acceso al LMS, facturación, correo, copia, soporte, publicación web o trabajo interno.

El análisis de dependencias ayuda a detectar puntos únicos de fallo y se relaciona con cómo detectar cuellos de botella tecnológicos antes de que aparezcan.

Clasificar criticidad y estado

Todos los servicios no necesitan el mismo esfuerzo de documentación ni la misma prioridad.

Criticidad

• Crítica: su fallo detiene una función principal o afecta a clientes.
• Alta: bloquea una actividad importante, aunque exista alternativa limitada.
• Media: puede permanecer interrumpido temporalmente.
• Baja: su impacto es reducido o diferible.

Estado de ciclo de vida

• planificado;
• en pruebas;
• activo;
• degradado;
• sin propietario;
• pendiente de actualización;
• pendiente de retirada;
• retirado.

Confianza del inventario

Puede añadirse un campo específico:

• Verificado: se ha comprobado técnica y funcionalmente.
• Parcial: existe evidencia, pero faltan datos.
• Inferido: se sospecha su función por configuración o actividad.
• Desconocido: requiere investigación.

Esta clasificación evita presentar como certeza lo que todavía no se ha confirmado.

Modelo de inventario recomendado

La herramienta puede ser una hoja, una base ligera o un gestor de configuración. Lo importante es utilizar identificadores, campos definidos y enlaces hacia la documentación detallada.

Procedimiento completo paso a paso

1. Identificar la máquina. Registrar host, entorno, sistema operativo, IP y responsable.
2. Definir servicios esperados. Anotar qué funciones se cree que presta el servidor.
3. Listar unidades de systemd. Recoger servicios instalados, activos, habilitados y fallidos.
4. Revisar unidades personalizadas. Analizar especialmente las ubicadas bajo /etc/systemd/system.
5. Capturar procesos persistentes. Detectar software no vinculado claramente a una unidad.
6. Revisar puertos y sockets. Relacionar cada escucha con proceso y finalidad.
7. Contrastar paquetes. Identificar versiones, origen y software instalado manualmente.
8. Inventariar contenedores. Registrar imágenes, volúmenes, redes y definiciones.
9. Revisar timers y cron. Incluir tareas periódicas y procesos por lotes.
10. Relacionar usuarios técnicos. Saber con qué identidad trabaja cada componente.
11. Localizar configuración, datos y logs. Identificar qué debe copiarse y reconstruirse.
12. Mapear dependencias. Registrar requisitos locales, externos y humanos.
13. Asignar función empresarial. Traducir el componente técnico a su utilidad real.
14. Clasificar criticidad y estado. Priorizar investigación y documentación.
15. Validar con responsables. Confirmar que el servicio sigue utilizándose.
16. Resolver elementos desconocidos. Investigar antes de marcarlos como obsoletos.
17. Publicar la fuente oficial. Definir dónde se mantiene el inventario.
18. Integrar la actualización. Todo alta, cambio o retirada debe modificar el inventario.

Este método puede aplicarse en varias pasadas. La primera busca cobertura; la segunda profundiza en los servicios críticos; la tercera resuelve elementos desconocidos y prepara retiradas.

Cómo validar que el inventario representa la realidad

Comparar varias fuentes

Una unidad de systemd debe contrastarse con procesos, puertos, logs, archivos, paquetes y uso empresarial.

Observar durante un periodo suficiente

Los servicios nocturnos, semanales o estacionales pueden no aparecer en una captura puntual.

Preguntar a usuarios y responsables

La evidencia técnica explica qué ocurre, pero no siempre por qué. Una exportación mensual puede parecer inactiva durante semanas y ser imprescindible al cierre.

Revisar reinicios

Tras un reinicio controlado, conviene verificar qué servicios vuelven, cuáles requieren intervención y qué procesos se iniciaron de forma no documentada.

Comprobar monitorización

Los servicios críticos deberían tener una comprobación que mida el resultado, no solo la existencia del proceso.

Probar recuperación documental

Otra persona autorizada debería poder localizar la ficha, entender la función, revisar el estado y encontrar el procedimiento de actuación.

Cómo detectar y retirar servicios obsoletos

Un inventario suele revelar servicios sin uso aparente. No deben eliminarse directamente.

Señales de posible obsolescencia

• servicio deshabilitado y sin actividad histórica;
• paquete sin configuración ni consumidores;
• puerto cerrado y proceso nunca iniciado;
• contenedor detenido desde hace meses;
• unidad personalizada sin propietario;
• logs vacíos o antiguos;
• aplicación sustituida;
• dependencia apuntando a un sistema retirado;
• cuenta técnica sin proceso asociado.

Proceso de retirada segura

1. Confirmar propietarios y usuarios.
2. Revisar dependencias directas e indirectas.
3. Conservar configuración, datos y evidencia necesaria.
4. Definir vuelta atrás.
5. Deshabilitar antes de desinstalar.
6. Observar durante un periodo acordado.
7. Retirar paquetes, unidades, cuentas y reglas asociadas.
8. Actualizar copias, monitorización y documentación.
9. Registrar fecha y motivo.

La retirada debe tratarse como un cambio técnico, no como una limpieza improvisada.

Qué partes conviene automatizar

La recolección técnica puede automatizarse parcialmente:

• unidades instaladas y activas;
• procesos;
• puertos;
• paquetes;
• contenedores;
• timers;
• versiones;
• uso de recursos;
• cambios desde la revisión anterior.

Sin embargo, no conviene automatizar sin validación:

• la función empresarial;
• la criticidad;
• el propietario;
• la decisión de retirada;
• el impacto de un fallo;
• la calidad del procedimiento de recuperación.

Una práctica útil consiste en generar una captura periódica y comparar diferencias. El cambio detectado debe revisarse: una nueva unidad, un puerto adicional o un contenedor distinto puede corresponder a una mejora autorizada o a una modificación no controlada.

La automatización del inventario debe integrarse en una infraestructura donde los cambios sean visibles y gobernables, como se explica en cómo diseñar una infraestructura preparada para automatización futura.

Ejemplo aplicado a un servidor web con LMS

Supongamos un servidor Linux que aloja una web comercial y una plataforma de formación.

Hallazgos posibles

• un segundo servidor web instalado pero inactivo;
• un contenedor de pruebas todavía escuchando en una interfaz interna;
• un cron de root que ejecuta una copia antigua además del timer actual;
• un servicio personalizado que depende de una ruta dentro del directorio personal de un antiguo técnico;
• un puerto de base de datos escuchando en todas las interfaces sin necesidad;
• una unidad fallida desde el último reinicio que nadie monitoriza.

El inventario permite transformar esos hallazgos en acciones concretas: documentar, corregir exposición, eliminar duplicidad, asignar propietario o preparar una retirada controlada.

Errores frecuentes

Guardar solo la salida de systemctl

No detecta todo el software, los contenedores, cron ni la función empresarial.

Confundir instalado con utilizado

Un paquete puede permanecer instalado sin prestar ningún servicio.

Mirar solo procesos activos

Las tareas periódicas y servicios activados por evento pueden no aparecer.

Ignorar sockets Unix

No todos los servicios escuchan mediante TCP o UDP.

No revisar cuentas de usuario

Una aplicación puede depender de un cron o servicio de usuario.

Documentar nombres sin finalidad

La lista no permite valorar impacto ni priorizar.

No registrar configuración y datos

El servicio aparece inventariado, pero no puede reconstruirse.

Copiar secretos al inventario

Debe registrarse la ubicación segura, no el contenido.

Deshabilitar servicios desconocidos durante la revisión

Puede provocar una interrupción difícil de relacionar.

No observar actividad histórica

Un servicio mensual puede parecer abandonado.

No incluir proveedores y servicios externos

La aplicación local puede depender de DNS, correo, API o almacenamiento externo.

No mantener el inventario

Una fotografía antigua crea falsa confianza.

Lista de comprobación

• ¿El servidor está identificado inequívocamente?
• ¿Se conoce su entorno y función?
• ¿Se han listado unidades cargadas e instaladas?
• ¿Se han separado servicios activos, habilitados, fallidos y enmascarados?
• ¿Se han revisado unidades personalizadas?
• ¿Se han analizado procesos persistentes?
• ¿Cada puerto y socket tiene una finalidad conocida?
• ¿Se han contrastado paquetes instalados?
• ¿Se ha buscado software manual en /usr/local, /opt y /srv?
• ¿Se han inventariado contenedores, imágenes, redes y volúmenes?
• ¿Se han revisado timers y cron?
• ¿Se conocen cuentas técnicas y servicios de usuario?
• ¿Cada servicio tiene configuración localizada?
• ¿Se conocen sus datos persistentes?
• ¿Se sabe dónde genera logs?
• ¿Se han identificado certificados y secretos sin copiarlos?
• ¿Se conocen dependencias locales y externas?
• ¿Cada servicio está asociado a una función empresarial?
• ¿Tiene propietario funcional y responsable técnico?
• ¿Está clasificado por criticidad?
• ¿Se conoce cómo se monitoriza?
• ¿Se sabe cómo se copia y restaura?
• ¿Existe un procedimiento para reiniciar o recuperar?
• ¿Los elementos desconocidos están marcados para investigar?
• ¿Las retiradas se realizan de forma controlada?
• ¿El inventario tiene fecha y nivel de confianza?
• ¿Se actualiza después de cada cambio?

Preguntas frecuentes

Conclusión

Inventariar servicios instalados en un servidor Linux exige combinar varias perspectivas. Systemd muestra unidades y estados; los procesos revelan qué se ejecuta; los sockets muestran qué escucha; los paquetes indican origen y versión; cron y timers descubren tareas periódicas; los contenedores añaden otra capa; y la revisión de usuarios, datos y configuraciones permite comprender cómo se mantiene cada pieza.

La salida de un comando es una evidencia, no un inventario terminado. El valor aparece cuando cada elemento técnico se relaciona con una función empresarial, un responsable, unas dependencias, una criticidad y un procedimiento de actuación.

La revisión debe comenzar en modo lectura, conservar fecha y alcance y evitar retirar servicios desconocidos. Los componentes aparentemente obsoletos necesitan validación, observación y una vuelta atrás preparada.

En una pequeña empresa, este inventario reduce dependencia de personas, facilita actualizaciones, mejora la seguridad, permite detectar exposiciones innecesarias y hace que una migración o recuperación sea mucho menos improvisada.

El sistema puede empezar con una hoja estructurada y unas pocas capturas técnicas. Lo importante es mantener identificadores, propietarios, estados y enlaces hacia la documentación completa.

Cuando el inventario se actualiza con cada cambio, el servidor deja de ser una caja negra acumulada durante años y se convierte en una infraestructura comprensible, auditable y mantenible.

ESTUDIO METADATOS desarrolla programas de formación online orientados a comprender y aplicar tecnología en entornos profesionales reales. Puedes consultar sus programas de formación tecnológica para profundizar en Linux, administración de sistemas, infraestructura, seguridad y continuidad operativa.