Seguridad en Linux: audita tu sistema paso a paso con Lynis

octubre 7, 2026 Alfonso Moreno | Sysadmin Senior 36 Visitas 12 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 2-3 horas para el switch a enforcing.
Requisitos: Root, kernel moderno, 2-4 semanas en permissive antes de enforcing.
Resultado: Sistema con MAC activo, logs en /var/log/audit/audit.log.
Troubleshooting: audit2allow, audit2why, setenforce 0 para emergencias.

Por qué necesitas auditar tu Linux (y por qué hacerlo tú mismo)

Si administras un servidor Linux — homelab, VPS, bare metal en producción — tarde o temprano te toca responder la pregunta incómoda: ¿qué tan expuesto está este sistema hoy? No la versión teórica de hace tres meses cuando lo configuraste, sino la realidad actual después de 200 actualizaciones, un cambio de SSH daemon, un nuevo contenedor corriendo con un socket Docker expuesto y un firewall que tocan tres personas distintas.

La auditoría manual es lenta, incompleta y olvida cosas. Lynis es la herramienta open source que resuelve eso: un escáner host-based que revisa la configuración del sistema contra perfiles como CIS, NIST y NSA, identifica debilidades reales y entrega un reporte accionable. Corre local, no abre puertos, no toca la red y no requiere agente. Mantenido por CISOfy (Michael Boelen) desde 2007, con la versión 3.1.7 publicada en junio de 2026.

Esta guía es la versión práctica para sysadmins: cómo instalar Lynis, cómo correr un audit completo, cómo interpretar el reporte y qué hacer con cada categoría de warning. Sin fluff, sin marketing, con comandos que puedes correr hoy.

Qué hace Lynis (y qué no hace)

Lynis corre en el host y analiza la configuración del sistema. No es un escáner de red como OpenVAS o Nessus: no busca servicios remotos, no hace fingerprinting de puertos ajenos. Su trabajo es mirar tu sistema desde adentro y decirte qué está mal configurado o expuesto.

Función	Sí	No
Auditoría de configuración local	✓
Detección de paquetes vulnerables (versiones instaladas)	✓
Hardening checks contra CIS/NIST	✓
Compliance testing (PCI, HIPAA, SOx)	✓
Escaneo de red / fingerprinting		✗
Explotación de vulnerabilidades		✗
Modificar la configuración (auto-hardening)		✗

El último punto es importante: Lynis reporta qué está mal, pero NO lo arregla. Tú decides qué endurecer. Esa separación es la diferencia con herramientas como Bastille (auto-hardening agresivo) y por eso Lynis es seguro de correr en producción: si rompe algo, fue tu decisión, no del script.

Instalación: tres métodos según tu distro

Lynis está disponible como paquete en la mayoría de las distribuciones, pero las versiones empaquetadas suelen estar desactualizadas. Para la versión más reciente, clonar el repo o descargar el tarball.

Método 1: paquete del sistema (rápido, versión vieja)

En Debian, Ubuntu, RHEL, Fedora y Arch existen paquetes oficiales. Útiles si solo quieres probarlo sin ensuciar el sistema.

# Debian / Ubuntu
$ sudo apt install lynis
# RHEL / Fedora / Rocky / AlmaLinux (requiere EPEL)
$ sudo dnf install epel-release
$ sudo dnf install lynis
# Arch / Manjaro
$ sudo pacman -S lynis
# Verificar versión
$ lynis --version
3.0.7  # versión vieja del paquete, no es la actual

El problema de los paquetes del sistema es la antigüedad. En Debian 12 stable vas a obtener Lynis 3.0.x, mientras que la versión actual de upstream es 3.1.7. Si necesitas los checks más nuevos (EOL de Debian 13, Fedora 43, RHEL 10, Ubuntu 26.04, NixOS y CachyOS, todos añadidos en 3.1.7) instala desde Git.

Método 2: clonar desde GitHub (recomendado)

Para producción, clona el repo. Así recibes las actualizaciones de la base de datos de controles sin esperar a que tu distro actualice el paquete.

# Crear directorio dedicado
$ sudo mkdir -p /opt/lynis
$ sudo git clone https://github.com/cisofy/lynis.git /opt/lynis
$ ls /opt/lynis/lynis
/opt/lynis/lynis
# Crear symlink para invocar desde cualquier lado
$ sudo ln -s /opt/lynis/lynis /usr/local/bin/lynis
$ lynis --version
3.1.7

Para actualizar a una versión nueva, solo git pull dentro de /opt/lynis. Lynis chequea su propia versión al inicio del scan y te avisa si está desactualizado.

Método 3: tarball de cisofy.com

Si el host no tiene acceso a Git o quieres una versión firmada, descarga el tarball desde cisofy.com/downloads/lynis y verifica la firma GPG del autor (Michael Boelen, key ID 26141F77A09D7F04).

$ wget https://downloads.cisofy.com/lynis/lynis-3.1.7.tar.gz
$ wget https://downloads.cisofy.com/lynis/lynis-3.1.7.tar.gz.sig
$ gpg --verify lynis-3.1.7.tar.gz.sig lynis-3.1.7.tar.gz
$ tar xzf lynis-3.1.7.tar.gz -C /opt/

Si la verificación GPG falla, NO instales el tarball. La firma asegura que el código es el publicado por Boelen y no una versión manipulada.

Cómo correr un audit completo

Lynis necesita ejecutarse como root para leer toda la configuración del sistema. Sin root pierde la mitad de los checks (los que tocan /etc/shadow, /var/log, /etc/sudoers). El comando es directo:

# Audit completo del sistema
$ sudo lynis audit system
# Lo que vas a ver al inicio
[ Lynis 3.1.7 ]
2007-2026 CISOfy - https://cisofy.com/lynis/
Enterprise support available (compliance, plugins, interface, tools)
[+] Initializing program
------------------------------------
  - Detecting OS...                           [ DONE ]
  - Checking profiles...                      [ DONE ]
  - Program update status...                  [ NO UPDATE ]
[+] System tools
------------------------------------
  - Scanning available tools...
  - Checking system binaries...
...

El audit completo dura entre 30 segundos y 5 minutos dependiendo del sistema. En un servidor con mucho software puede pasar de los 5 minutos. No lo interrumpas: cada categoría (KRNL para kernel, AUTH para autenticación, FILE para filesystem, NETW para red, PKGS para paquetes, etc.) se procesa en orden y los resultados parciales no se guardan.

Flags útiles para automatizar

Si vas a correr Lynis periódicamente (cron diario, pipeline de CI, post-provisioning), hay flags que cortan la salida y dejan solo lo accionable.

# Modo no interactivo (sin pausas para Enter)
$ sudo lynis audit system --quick
# Modo silencioso (solo warnings y suggestions, sin progress)
$ sudo lynis audit system --quiet
# Sin esperar NTP sincronizado (útil en contenedores)
$ sudo lynis audit system --no-colors --quick
# Forzar color (útil en logs que se procesan después)
$ sudo lynis audit system --colors
# Skip una categoría específica
$ sudo lynis audit system --skip-plugins --tests "AUTH-9"

Para correr Lynis dentro de un contenedor Docker, añade --no-colors y --quick. Sin esas flags, el audit puede colgarse esperando una confirmación interactiva que nunca llega.

Cómo interpretar el reporte

Al final del audit, Lynis imprime un resumen con tres bloques: Warnings (configuración insegura confirmada), Suggestions (recomendaciones de hardening no críticas) y un Hardening index (puntaje de 0 a 100). Además escribe dos archivos en /var/log/lynis/:

# Reporte legible por humanos
$ sudo cat /var/log/lynis-report.dat
# Log completo de la corrida (incluye pruebas individuales)
$ sudo less /var/log/lynis.log
# Buscar solo los warnings (líneas que empiezan con warning)
$ sudo grep -E '^[.*].*warning' /var/log/lynis.log

El Hardening index es el número que más miran los auditores. Se calcula en función de cuántos tests pasaron contra el total. Un servidor recién instalado con defaults suele estar entre 60 y 70. Después de hardening activo, 80+ es realista. 90+ es excelente y raro. El número NO es la métrica final: un servidor con hardening 95 pero un puerto SSH abierto a internet sigue siendo inseguro. Lynis es una guía, no un veredicto.

Categorías de tests más comunes que disparan warnings

Después de correr Lynis en varios servidores, hay un patrón claro de qué warnings aparecen en la mayoría de las instalaciones. Los reconozco de memoria.

Categoría	Warning típico	Causa común
`AUTH-9282`	No password hashing rounds configured	`/etc/login.defs` sin `SHA_CRYPT_MIN_ROUNDS`
`FILE-6310`	World writable directories	Permisos heredados de templates viejos
`HRDW-7902`	USB storage not disabled	Servidor con `usb-storage` módulo cargado
`KRNL-5677`	Missing sysctl key	`net.ipv4.conf.all.rp_filter` sin valor 1
`NETW-3032`	IPv6 not fully configured	Servidor solo con IPv4 (warning si esperas dual-stack)
`PKGS-7346`	Optional package not installed	Falta `apt-show-versions` o equivalente
`SSH-7408`	Weak SSH configuration	`PermitRootLogin yes`, `PasswordAuthentication yes`

Cada warning en /var/log/lynis.log viene con un ID único y una sugerencia concreta. La sugerencia es accionable: te dice qué archivo tocar y qué valor poner. No es “considere endurecer SSH” — es “edite /etc/ssh/sshd_config y cambie PermitRootLogin a no“.

Qué hacer después del primer audit

El patrón correcto no es leer los 200 warnings de golpe y entrar en pánico. Es priorizar por categoría de riesgo.

Prioridad 1: SSH y autenticación

Los warnings de SSH-* y AUTH-* son los primeros que arreglo. SSH abierto a internet con PermitRootLogin yes es el vector de ataque número uno contra servidores Linux.

# Endurecer SSH (cambios mínimos viables)
$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
$ sudo sed -i 's/^#?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
$ sudo sed -i 's/^#?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
$ sudo sed -i 's/^#?PermitEmptyPasswords.*/PermitEmptyPasswords no/' /etc/ssh/sshd_config
$ sudo sshd -t  # dry-run, valida config sin reiniciar
$ sudo systemctl reload sshd
$ sudo lynis audit system --tests "SSH-7408,AUTH-9282"

El sshd -t antes del reload es crítico. Si rompes la config, sshd rechaza TODAS las conexiones nuevas al recargar — y si estás conectado por SSH, te quedas afuera. El -t solo valida, no recarga.

Prioridad 2: kernel y sysctl

Los warnings de KRNL-* suelen ser sysctls de red no configurados. La mayoría son hardenings de red (anti-spoofing, anti-smurf) que Debian y Ubuntu no activan por defecto.

# Crear archivo de sysctls endurecidos
$ sudo tee /etc/sysctl.d/99-hardening.conf <<EOF
# Anti IP spoofing
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
# No aceptar ICMP redirects (mitigar MITM)
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
# No enviar ICMP redirects
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
# Ignorar broadcast ICMP (smurf attacks)
net.ipv4.icmp_echo_ignore_broadcasts = 1
# Habilitar SYN cookies (SYN flood protection)
net.ipv4.tcp_syncookies = 1
EOF
$ sudo sysctl --system

Después de aplicar, corre Lynis otra vez apuntando solo a los tests de kernel. Si los warnings de KRNL-* desaparecieron, los sysctls quedaron activos. Si persisten, el kernel no acepta el parámetro (algunos sysctls requieren kernel específico).

Prioridad 3: filesystem y permisos

Los warnings de FILE-* (world writable, permisos de /etc/shadow, sticky bit en /tmp) son menos urgentes pero acumulan. Un find / -perm -o+w -type d 2>/dev/null te da la lista de directorios world-writable en tu sistema. La mayoría son legítimos (/tmp por diseño) pero algunos vienen de paquetes mal empaquetados.

# Listar directorios world-writable
$ sudo find / -perm -o+w -type d 2>/dev/null | head -20
# Excluir /tmp y /dev/shm (legítimos)
$ sudo find / -path /proc -prune -o -path /sys -prune -o -path /tmp -prune -o -path /dev/shm -prune -o -perm -o+w -type d -print | head
# Revisar permisos de archivos críticos
$ ls -l /etc/shadow /etc/passwd /etc/sudoers /etc/ssh/ssh_host_*

El -path /proc -prune -o es necesario porque /proc tiene miles de pseudo-archivos world-writable legítimos y ensucian la salida. Sin el prune, find puede tardar minutos.

Automatizar Lynis en cron diario

Un audit mensual está bien para servidores estables. Para servidores que cambian seguido (despliegues, parches, nuevos contenedores), un audit diario vía cron es más útil. Lynis Enterprise tiene dashboard centralizado; con la versión community, parseas el lynis-report.dat y envías el resultado por Telegram, email o donde prefieras.

# Crontab diario a las 6 AM
$ sudo crontab -e
0 6 * * * /opt/lynis/lynis audit system --quick --no-colors > /var/log/lynis-cron.log 2>&1

Para alertas, el truco es extraer el puntaje de hardening del log y notificar si baja de un umbral. El puntaje aparece como Hardening index: [XXX] en la sección final.

# Extraer el hardening index
$ sudo grep 'Hardening index' /var/log/lynis.log | tail -1
Hardening index: [75]
# Comparar contra umbral (alerta si < 70)
$ SCORE=$(sudo grep 'Hardening index' /var/log/lynis.log | tail -1 | grep -oE '[0-9]+')
$ if [ "$SCORE" -lt 70 ]; then
    echo "Lynis score $SCORE - revisar hardening" | mail -s "Server audit alert" [email protected]
  fi

Si no quieres escribir el comparador a mano, hay scripts de terceros que parsean lynis-report.dat y generan diffs entre corridas. Útil para ver qué warning nuevo apareció desde el último audit (típicamente un nuevo paquete sin hardening aplicado).

Cuándo NO usar Lynis

Lynis es excelente para auditorías host-based de configuración, pero hay casos donde NO es la herramienta correcta.

Si necesitas un escaneo de red externo: usa OpenVAS, Nessus o Nuclei. Lynis no hace footprinting de servicios remotos.
Si quieres auto-hardening: usa Ansible, OpenSCAP o Bastille. Lynis solo reporta; no toca la configuración. Eso es una ventaja (no rompe el sistema) pero también una limitación si buscas remediación automática.
Si sospechas compromiso activo: Lynis no detecta rootkits. Para eso, herramientas como chkrootkit, rkhunter o AIDE (verificación de integridad de archivos). Puedes correrlas después de Lynis para cobertura complementaria.
Si tu sistema es crítico y no puedes correr root: Lynis pierde la mitad de los checks sin root. Los tests de /etc/shadow, /etc/sudoers, capacidades de procesos y sysctls no se ejecutan. Con un usuario sin privilegios el reporte es parcial y engañoso.

Conclusión: Lynis como base de un ciclo de hardening

Lynis no es la auditoría completa. Es el punto de partida que te dice qué mirar primero en cada servidor. Una vez que tienes el reporte inicial, el flujo real es: priorizar warnings por categoría de riesgo (SSH y auth primero, kernel después, filesystem al final), aplicar los fixes, re-correr Lynis para confirmar que el puntaje subió, y automatizarlo en cron para detectar regresiones.

Para un homelab con 2-3 servidores, basta con correr Lynis mensualmente y revisar los warnings nuevos. Para un entorno empresarial con 50+ servidores, necesitas Lynis Enterprise (la versión con dashboard centralizado y plugins privados) o una capa de automatización encima de la versión community que parsee los reportes y los centralice en un dashboard tipo Grafana.

La versión 3.1.7 de junio 2026 añade soporte para EOL de distribuciones modernas: Debian 13, Fedora 43, AlmaLinux, RHEL 10, Ubuntu 26.04, NixOS y CachyOS. Si tu distro está en la base de datos de EOL, Lynis te avisa antes de que tu sistema quede sin parches de seguridad. Eso solo ya justifica correrlo periódicamente.

Preguntas frecuentes

¿Por qué Seguridad en Linux: audita tu sistema paso a paso con Lynis es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Seguridad en Linux: audita tu?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Seguridad en Linux: audita tu?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Seguridad en Linux: audita tu y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Seguridad en Linux: audita tu?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.