HARDENING DE SISTEMAS: DE INSTALACIÓN POR DEFECTO A CONFIGURACIÓN BÁSICA SEGURA

Introducción

Los sistemas operativos modernos son potentes… y por defecto vienen con muchas cosas encendidas: servicios, puertos, cuentas, configuraciones “para que funcione todo”. Eso es cómodo para arrancar, pero es una mala idea para operar.

Hardening es convertir un “sistema recién instalado” en un sistema que hace solo lo necesario: ni más, ni menos. No es paranoia: es control. Cuanto menos expongas, menos tienes que defender.

Mini guía en 15 minutos (para empezar hoy)

Si necesitas impacto rápido, aquí está el 80/20:

1. Inventario mínimo: ¿qué rol cumple el servidor? (web, app, BD, bastion, CI…).
2. Apaga lo que sobra: servicios que no se usan, puertos no necesarios, usuarios antiguos.
3. Acceso: SSH por clave, sin root login, sin password si es posible; MFA donde aplique.
4. Actualiza: parches del sistema y paquetes críticos.
5. Logs: activa auditoría básica y centraliza logs (aunque sea simple).

Qué problemas reales evita el hardening

• Explotación de defaults: credenciales por defecto, paneles abiertos, servicios “de prueba”.
• Movimiento lateral: cuando un atacante entra por un punto, busca saltar a otros.
• Escalada de privilegios: permisos laxos y servicios con capacidades innecesarias.
• Persistencia: cuentas/servicios que permiten volver a entrar tras “limpiar”.
• Incidentes caros: lo barato aquí es prevenir; lo caro es recuperar operación.

Hardening no es un checklist suelto: es un sistema

El error típico es hacerlo “una vez” y olvidarlo. La versión profesional es:

• Baseline: defines el estándar por rol (web/app/db…).
• Automatización: lo aplicas con IaC/config management.
• Verificación: lo auditas con herramientas repetibles.
• Derivas justificadas: lo que no se pueda aplicar, se documenta con motivo.

Controles ISO/IEC 27002 relacionados

• A.8.9 – Gestión de la configuración (baseline, cambios controlados).
• A.8.10 – Eliminación o desactivación de funcionalidades innecesarias.
• A.8.11 – Gestión técnica de vulnerabilidades (patching + revisión continua).
• A.8.22 – Autenticación de usuarios (MFA, políticas robustas).

Casos de uso reales (lo que vemos en proyectos)

Caso 1: servidor Linux que aloja una API (Spring Boot + Docker)

Escenario típico pyme: un VPS o VM con Docker, un reverse proxy (Nginx/Traefik) y varios contenedores. El hardening útil aquí no es “cien reglas”: es evitar errores básicos.

• Firewall: solo 80/443 (y 22 solo desde IPs/VPN si se puede).
• SSH: claves, sin root login, fail2ban o equivalente.
• Docker: minimizar privilegios, evitar --privileged, separar redes.
• Logs y alertas: si cambia el tráfico o hay errores, se tiene que ver.
• Actualización: SO + Docker + imágenes base con frecuencia.

Caso 2: Windows Server (roles críticos: AD, ficheros, RDP)

El patrón común de incidente: RDP expuesto, credenciales débiles, cuentas “para siempre”, falta de auditoría. Hardening aquí suele pasar por MFA, restricciones de acceso, políticas y auditoría.

Caso 3: base de datos expuesta “sin querer”

Un clásico: PostgreSQL/MySQL accesible desde Internet por un Security Group mal puesto o una regla de firewall laxa. Hardening aquí es: no exponer. Y si hay que exponer (excepción), hacerlo con túnel y control.

Fases del hardening (versión pro, aplicable)

1. Instalación mínima: solo lo imprescindible para el rol.
2. Desactivación de servicios: lo que no se usa, se apaga.
3. Configuración segura: permisos mínimos, cifrado, logs, auditoría.
4. Patching: antes de producción y de forma continua.
5. Verificación: auditoría repetible (herramientas + checklist).
6. Monitorización: detección y alertas (si no, no existe).

Stack recomendado (OSS-first) para hardening reproducible

Este stack está pensado para pymes y equipos técnicos: prioriza open source y componentes muy usados. Si luego quieres “enterprise”, se puede escalar.

Ejemplo de “stack Gondor” para hardening en clientes (práctico)

Una forma realista de montar esto en un entorno típico con Docker y GitLab:

1. Repositorio GitLab con “baselines” por rol (linux-web, linux-app, db, docker-host).
2. Ansible con roles versionados (SSH, firewall, usuarios, sysctl, auditd, logs, fail2ban…).
3. CI que ejecuta “lint” y valida inventario/roles (y genera reporte).
4. Auditoría post-despliegue con Lynis/OpenSCAP y subida de resultados como artefactos.
5. Wazuh agent instalado para visibilidad (integridad de ficheros, logs críticos, alertas).

Mini ejemplo de pipeline (conceptual, GitLab CI)

stages: [lint, audit]

lint-ansible:
  stage: lint
  image: python:3.12
  script:
    - pip install ansible ansible-lint
    - ansible-lint .

audit-report:
  stage: audit
  image: debian:stable-slim
  script:
    - echo "Aquí se recogerían reportes de Lynis/OpenSCAP desde los hosts o como artefactos del despliegue"
  artifacts:
    when: always
    paths:
      - reports/
              

Lo importante no es el YAML exacto: es el concepto. Hardening sin evidencia y sin automatización se degrada con el tiempo.

Herramientas recomendadas (con criterio)

Auditoría de hardening

• Lynis (Linux): auditoría rápida y accionable para detectar gaps comunes.
• OpenSCAP (Linux): evaluación contra perfiles y políticas (compliance-as-code).
• CIS-CAT: útil si trabajas alineado a CIS y quieres reports estándar (según disponibilidad/licencia).

Automatización y consistencia

• Ansible: ideal para pymes y equipos mixtos (infra + apps), reproducible y versionable.
• PowerShell DSC: enfoque potente para Windows si quieres declarativo.
• Puppet/Chef/SaltStack: alternativas cuando hay escala o necesidades específicas.

Monitorización y detección

• Wazuh: HIDS + reglas + integridad de ficheros, muy útil para detectar cambios y eventos críticos.
• Fail2ban: reduce ruido de fuerza bruta sobre SSH/servicios expuestos.

Contenedores y supply chain

• Trivy: escaneo de imágenes y misconfigurations (muy útil con Docker).
• SBOM (CycloneDX, Syft/Grype): trazabilidad de lo que estás desplegando.

Opciones comerciales (cuando compensa pagar)

Si el entorno es grande, regulado o necesitas soporte/auditoría formal, herramientas como Tenable/Qualys pueden aportar valor. Pero en pymes, muchas veces el bloqueo real no es “la herramienta”, es el proceso.

Errores frecuentes (y por qué son trampas)

• 🚫 Imagen de laboratorio a producción: incluye debugging, credenciales, servicios extra.
• 🚫 “Dejo el puerto abierto por si acaso”: el “por si acaso” es un vector de ataque.
• 🚫 Hardening manual: a los 3 meses nadie sabe qué se tocó y por qué.
• 🚫 No auditar: sin medición, la configuración vuelve a degradarse.
• 🚫 Confundir hardening con parcheo: son cosas distintas; necesitas ambas.

Checklist práctica por capas

Sistema operativo

1. ✅ Usuarios mínimos, sin cuentas “sobrantes”.
2. ✅ SSH/RDP endurecido, sin acceso root/administrador directo.
3. ✅ Firewall activo con reglas por necesidad (deny-by-default donde se pueda).
4. ✅ Patching y repositorios controlados.
5. ✅ Logs + auditoría básica.

Servicios

1. ✅ Config segura por servicio (no defaults).
2. ✅ TLS si hay tráfico sensible.
3. ✅ Límites de rate / protección fuerza bruta cuando aplique.

Operación

1. ✅ Cambios versionados en Git.
2. ✅ Auditoría programada (mensual/trimestral).
3. ✅ Alertas mínimas (logins raros, cambios de ficheros críticos, nuevos servicios/puertos).

Reflexión final

La seguridad no es una capa adicional: es una configuración. Cada parámetro por defecto es una puerta que alguien dejó abierta. Hardening es cerrar las que no se necesitan… antes de que alguien las encuentre.

Conclusión

El hardening no se improvisa: se define, se automatiza y se audita. En Gondor ayudamos a organizaciones a crear baselines reales (por rol), automatizarlos y dejar evidencia, alineando seguridad técnica con marcos como ISO/IEC 27002, ENS y CIS.