Cómo crear tu propio sistema de inventario de servidores Linux: hardware, software, versiones, vulnerabilidades y actualizaciones

Idea central: el inventario de servidores Linux debe ser automático, repetible y verificable. No basta saber “cuántos servidores hay”; necesitas saber qué tienen instalado, qué versión ejecutan, qué parches faltan y qué riesgos deben corregirse primero.

Servidores Linux administrados
  ↓ SSH / Ansible / osquery / scripts
Recolector de inventario
  ↓
Base de datos SQLite o PostgreSQL
  ↓
Reportes:
  - hardware
  - software
  - versiones
  - parches pendientes
  - vulnerabilidades
  - criticidad
  ↓
Panel web o exportación CSV/HTML

CREATE TABLE servers (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  hostname TEXT NOT NULL,
  ip_address TEXT,
  environment TEXT,
  os_name TEXT,
  os_version TEXT,
  kernel TEXT,
  responsible TEXT,
  criticality TEXT,
  last_scan TEXT
);

CREATE TABLE hardware (
id INTEGER PRIMARY KEY AUTOINCREMENT,
server_id INTEGER,
manufacturer TEXT,
model TEXT,
serial_number TEXT,
cpu_model TEXT,
cpu_cores INTEGER,
ram_mb INTEGER,
bios_version TEXT,
FOREIGN KEY(server_id) REFERENCES servers(id)
);

CREATE TABLE packages (
id INTEGER PRIMARY KEY AUTOINCREMENT,
server_id INTEGER,
name TEXT,
version TEXT,
architecture TEXT,
source TEXT,
scan_date TEXT,
FOREIGN KEY(server_id) REFERENCES servers(id)
);

CREATE TABLE vulnerabilities (
id INTEGER PRIMARY KEY AUTOINCREMENT,
server_id INTEGER,
cve TEXT,
package_name TEXT,
installed_version TEXT,
fixed_version TEXT,
severity TEXT,
source TEXT,
scan_date TEXT,
FOREIGN KEY(server_id) REFERENCES servers(id)
);

# Identidad del equipo
hostnamectl
sudo dmidecode -t system
sudo dmidecode -t bios

# Hardware general

sudo lshw -json > hardware.json
lscpu
free -m
lsblk -o NAME,MODEL,SERIAL,SIZE,FSTYPE,MOUNTPOINTS

# Red

ip -brief address
ip route
lspci -nnk | grep -A3 -i ethernet

# Sistema operativo
cat /etc/os-release
uname -a
hostnamectl

# Debian / Ubuntu

dpkg-query -W -f='${binary:Package}\t${Version}\t${Architecture}\n' > packages.tsv
apt list --upgradable 2>/dev/null > updates.txt

# RHEL / Rocky / Alma / Fedora

rpm -qa --qf '%{NAME}\t%{VERSION}-%{RELEASE}\t%{ARCH}\n' > packages.tsv
dnf check-update || true

[linux_servers]
srv-web-01 ansible_host=192.168.1.10
srv-db-01  ansible_host=192.168.1.11
srv-app-01 ansible_host=192.168.1.12

[linux_servers:vars]
ansible_user=adminlinux
ansible_become=true

ansible linux_servers -i inventory.ini -m ansible.builtin.setup \
  --tree ./facts

-- Información del sistema
SELECT hostname, cpu_brand, physical_memory FROM system_info;

-- Kernel
SELECT version, arguments FROM kernel_info;

-- Paquetes Debian/Ubuntu
SELECT name, version, source, arch FROM deb_packages LIMIT 20;

-- Paquetes RPM
SELECT name, version, release, arch FROM rpm_packages LIMIT 20;

-- Puertos en escucha
SELECT pid, port, protocol, address FROM listening_ports;

-- Usuarios locales
SELECT username, uid, gid, shell FROM users;

# Escanear filesystem local
sudo trivy fs --format json --output trivy-results.json /

# Escanear solo vulnerabilidades y secretos

sudo trivy fs --scanners vuln,secret --format json --output trivy-security.json /

# Escanear una imagen de contenedor

trivy image --format json --output nginx-vulns.json nginx:latest

Precisión técnica: Trivy indica que basa el análisis de paquetes de sistema en advisories oficiales del proveedor y que no cubre por igual paquetes de terceros, repositorios externos o binarios compilados manualmente.

# Instalar scanner
sudo apt install openscap-scanner scap-security-guide

# Ver información de un contenido SCAP

oscap info archivo-datastream.xml

# Evaluar un perfil y generar resultados

sudo oscap xccdf eval 
--profile perfil-seguridad 
--results resultados.xml 
--report reporte.html 
archivo-datastream.xml

# SBOM de un directorio de aplicación
syft /opt/mi-aplicacion -o cyclonedx-json=sbom-app.json

# SBOM de una imagen de contenedor

syft nginx:latest -o spdx-json=sbom-nginx.spdx.json

# SBOM de filesystem

sudo syft / -o syft-json=sbom-server.json

# Debian / Ubuntu
sudo apt update
apt list --upgradable 2>/dev/null

# Ver si requiere reinicio

test -f /var/run/reboot-required && cat /var/run/reboot-required

# RHEL / Rocky / Alma / Fedora

sudo dnf check-update || true
needs-restarting -r || true

# openSUSE / SLES

zypper list-updates

#!/usr/bin/env bash
set -euo pipefail

OUTDIR="${1:-./inventory-$(hostname)-$(date +%F)}"
mkdir -p "$OUTDIR"

hostnamectl > "$OUTDIR/hostnamectl.txt"
cat /etc/os-release > "$OUTDIR/os-release.txt"
uname -a > "$OUTDIR/kernel.txt"
lscpu > "$OUTDIR/cpu.txt"
free -m > "$OUTDIR/memory.txt"
lsblk -o NAME,MODEL,SERIAL,SIZE,FSTYPE,MOUNTPOINTS > "$OUTDIR/disks.txt"
ip -brief address > "$OUTDIR/network.txt"
systemctl list-units --type=service --state=running > "$OUTDIR/services-running.txt"

if command -v dpkg-query >/dev/null 2>&1; then
dpkg-query -W -f='${binary:Package}\t${Version}\t${Architecture}\n' > "$OUTDIR/packages.tsv"
apt list --upgradable 2>/dev/null > "$OUTDIR/updates.txt" || true
fi

if command -v rpm >/dev/null 2>&1; then
rpm -qa --qf '%{NAME}\t%{VERSION}-%{RELEASE}\t%{ARCH}\n' > "$OUTDIR/packages.tsv"
fi

if command -v trivy >/dev/null 2>&1; then
sudo trivy fs --format json --output "$OUTDIR/trivy-results.json" / || true
fi

tar -czf "$OUTDIR.tar.gz" "$OUTDIR"
echo "Inventario generado: $OUTDIR.tar.gz"

import sqlite3
import sys
from datetime import datetime
from pathlib import Path

if len(sys.argv) != 4:
print("Uso: python3 import_packages.py inventario.db SERVER_ID packages.tsv")
sys.exit(1)

db_path = sys.argv[1]
server_id = int(sys.argv[2])
packages_file = Path(sys.argv[3])
scan_date = datetime.utcnow().isoformat()

conn = sqlite3.connect(db_path)
cur = conn.cursor()

cur.execute("""
CREATE TABLE IF NOT EXISTS packages (
id INTEGER PRIMARY KEY AUTOINCREMENT,
server_id INTEGER,
name TEXT,
version TEXT,
architecture TEXT,
source TEXT,
scan_date TEXT
)
""")

with packages_file.open("r", encoding="utf-8", errors="ignore") as f:
for line in f:
parts = line.strip().split("\t")
if len(parts) >= 3:
name, version, arch = parts[0], parts[1], parts[2]
cur.execute("""
INSERT INTO packages
(server_id, name, version, architecture, source, scan_date)
VALUES (?, ?, ?, ?, ?, ?)
""", (server_id, name, version, arch, "package-manager", scan_date))

conn.commit()
conn.close()

print("Paquetes importados correctamente")

Matriz simple de prioridad

1. Crítico: servidor expuesto a Internet + CVE crítica + exploit conocido o parche disponible.
2. Alto: servidor interno crítico + paquete vulnerable usado por servicio activo.
3. Medio: vulnerabilidad corregible en servidor no expuesto, sin explotación conocida.
4. Bajo: laboratorio, paquete no usado o hallazgo pendiente de validación.

Medidas mínimas de protección

1. Acceso restringido: solo administradores, seguridad y responsables autorizados.
2. Autenticación fuerte: MFA si hay panel web.
3. Cifrado: HTTPS, disco cifrado o base cifrada según criticidad.
4. Backups: respaldos periódicos y restauración probada.
5. Auditoría: registrar quién consulta o exporta información.
6. Retención: definir cuánto tiempo guardar históricos.
7. Separación: no guardar claves SSH privadas ni contraseñas dentro del inventario.

# Ejecutar todos los días a las 02:30
30 2 * * * /opt/inventory/collector.sh /var/inventory/$(hostname)-$(date +\%F)

• Crear una hoja Excel que nadie actualiza.
• No registrar fecha del último escaneo.
• Guardar solo IP y hostname, sin software ni versiones.
• No distinguir producción, pruebas, desarrollo y laboratorio.
• No asociar cada servidor a un responsable.
• No cruzar vulnerabilidades con criticidad del activo.
• No proteger el inventario como información sensible.
• No registrar reinicio requerido después de parches.
• No incluir contenedores, runtimes ni aplicaciones instaladas manualmente.
• No validar resultados falsos positivos o paquetes de terceros.

Checklist para implementar tu sistema

1. Definir alcance: servidores físicos, virtuales, cloud, contenedores y ambientes.
2. Crear modelo de datos: servidores, hardware, paquetes, servicios, CVE y parches.
3. Configurar acceso SSH: usuario de inventario, sudo limitado y llaves protegidas.
4. Recolectar facts: Ansible para hardware, OS, kernel, red y paquetes.
5. Agregar osquery: consultas SQL para usuarios, procesos, puertos y paquetes.
6. Escanear vulnerabilidades: Trivy, OpenSCAP u OSV-Scanner según el caso.
7. Generar SBOM: Syft para aplicaciones, contenedores o filesystem.
8. Guardar en base de datos: SQLite al inicio, PostgreSQL para producción.
9. Crear reportes: HTML, CSV, dashboard o API.
10. Automatizar: cron, systemd timer, CI/CD o Ansible programado.
11. Proteger: permisos, cifrado, backups, auditoría y control de accesos.
12. Revisar mensualmente: calidad de datos, servidores faltantes y métricas de remediación.

¿Puedo empezar sin una herramienta empresarial?

Sí. Puedes empezar con Ansible, scripts Bash, SQLite y reportes HTML. Luego puedes migrar a PostgreSQL, API, dashboard y autenticación avanzada.

¿Necesito instalar agentes en todos los servidores?

No necesariamente. Con Ansible puedes recopilar facts por SSH sin instalar Ansible en los nodos administrados. Para monitoreo continuo o consultas programadas, osquery como agente puede ser útil.

¿Qué herramienta uso para vulnerabilidades?

Trivy es práctico para escaneos rápidos de filesystem, contenedores y paquetes; OpenSCAP es fuerte para cumplimiento y baselines; OSV-Scanner ayuda con dependencias de aplicaciones y lockfiles.

¿Debo registrar seriales y BIOS?

Sí, especialmente en inventario de hardware, garantía, soporte y firmware. Pero esos datos deben protegerse porque pueden ser sensibles.

¿Cada cuánto ejecutar el inventario?

Para servidores críticos, al menos diariamente o después de cada cambio. Para entornos estables, semanal puede ser suficiente. Lo importante es detectar rápidamente servidores sin escaneo reciente.

• Comandos básicos que debes aprender para administrar tu servidor Linux
• Por qué los servidores usan Linux: ventajas para empresas y administradores TI
• Guía completa de redes en Linux: comandos, diagnóstico, configuración y solución de problemas
• Cómo saber qué procesos se ejecutan en Linux: guía completa para identificar, controlar, detener procesos sospechosos
• Cómo saber si tu Linux está bien protegido: 30 comprobaciones de seguridad que puedes realizar ahora mismo
• Ciberseguridad en Linux: 50 herramientas gratuitas para proteger servidores y estaciones

Cierre editorial

Un servidor no inventariado es un punto ciego. Y un punto ciego en Linux puede convertirse en una vulnerabilidad, una caída o una mala decisión de mantenimiento. Automatizar el inventario no es burocracia: es la base para administrar mejor, parchear a tiempo, reducir riesgos y demostrar control real sobre la infraestructura.