17. Hardening de sistemas operativos: usuarios, permisos, servicios, parches y configuración base

17.1 Introducción

Un sistema operativo recién instalado no siempre está listo para un entorno productivo seguro. Puede incluir servicios que no se usan, configuraciones permisivas, cuentas innecesarias, permisos amplios o políticas de registro insuficientes.

El hardening de sistemas operativos busca reducir esa exposición. No se trata de bloquear todo, sino de configurar el sistema para que cumpla su función con el menor riesgo posible.

En este tema veremos usuarios, permisos, servicios, parches, configuración base, logging y validación. Los principios aplican tanto a servidores como a estaciones de trabajo, aunque los detalles cambian entre Windows, Linux y otros sistemas.

17.2 Qué es hardening de sistema operativo

Hardening significa endurecimiento. En un sistema operativo, consiste en aplicar configuraciones y controles para reducir superficie de ataque, limitar privilegios y mejorar trazabilidad.

Incluye acciones como:

• Eliminar o deshabilitar servicios innecesarios.
• Aplicar parches de seguridad.
• Configurar permisos mínimos.
• Proteger cuentas privilegiadas.
• Activar registros de auditoría.
• Restringir administración remota.
• Aplicar políticas de contraseñas y MFA cuando corresponda.
• Definir una configuración base estándar.

17.3 Principio de mínimo privilegio

El mínimo privilegio indica que cada usuario, servicio o proceso debe tener solo los permisos necesarios para cumplir su función. Este principio es central en hardening.

Aplicaciones prácticas:

• Usuarios cotidianos sin privilegios administrativos.
• Cuentas de administración separadas de cuentas de uso diario.
• Servicios ejecutándose con cuentas específicas y limitadas.
• Permisos de archivos asignados por necesidad.
• Acceso remoto restringido a grupos autorizados.
• Elevación de privilegios controlada y registrada.

17.4 Gestión de usuarios

Las cuentas de usuario son una puerta de entrada al sistema. Una cuenta innecesaria, compartida o con privilegios excesivos aumenta el riesgo.

Buenas prácticas:

• Eliminar o deshabilitar cuentas que no se usan.
• Evitar cuentas compartidas.
• Asignar cuentas individuales a administradores.
• Revisar cuentas inactivas.
• Aplicar MFA en accesos sensibles.
• Separar cuentas de administración y cuentas normales.
• Auditar creación, eliminación y cambios de cuentas.

17.5 Cuentas privilegiadas

Las cuentas privilegiadas tienen capacidad de cambiar configuraciones, instalar software, modificar permisos o acceder a información sensible. Deben protegerse con controles más estrictos.

17.6 Permisos de archivos y directorios

Los permisos definen quién puede leer, escribir, ejecutar o modificar recursos. Permisos demasiado amplios pueden permitir robo de datos, manipulación de archivos o ejecución no autorizada.

Buenas prácticas:

• Asignar permisos por grupos, no usuario por usuario cuando sea posible.
• Evitar permisos de escritura en rutas sensibles para usuarios comunes.
• Revisar permisos heredados.
• Controlar quién puede modificar scripts, binarios y configuraciones.
• Auditar cambios en archivos críticos.
• Eliminar accesos de cuentas que ya no necesitan permisos.

17.7 Servicios innecesarios

Cada servicio activo puede abrir puertos, consumir recursos, generar logs y agregar superficie de ataque. Si un servicio no es necesario, debería deshabilitarse o eliminarse.

Ejemplos de revisión:

• ¿El servidor necesita servicio de impresión?
• ¿Una estación necesita servidor web local?
• ¿Está activo un protocolo antiguo sin uso?
• ¿Hay servicios de prueba en producción?
• ¿Existen servicios escuchando en interfaces públicas?

Antes de deshabilitar, conviene validar dependencias para evitar interrupciones.

17.8 Puertos abiertos

Los puertos abiertos indican servicios escuchando conexiones. Un sistema endurecido debe exponer solo los puertos necesarios.

17.9 Parches y actualizaciones

Los parches corrigen vulnerabilidades, fallas y problemas de estabilidad. Un sistema sin parches puede quedar expuesto a ataques conocidos para los que ya existe solución.

Una gestión adecuada de parches incluye:

• Inventario de sistemas y versiones.
• Clasificación por criticidad.
• Priorización según exposición y riesgo.
• Pruebas en ambientes controlados cuando corresponda.
• Ventanas de mantenimiento.
• Plan de reversión.
• Verificación posterior.

17.10 Priorización de parches

No todos los parches tienen la misma urgencia. Conviene priorizar según riesgo real.

17.11 Configuración base

Una configuración base, o baseline, define el estado mínimo aceptable de seguridad para un sistema. Sirve para instalar, comparar, auditar y corregir configuraciones.

Puede incluir:

• Servicios permitidos.
• Políticas de usuarios y contraseñas.
• Configuración de firewall local.
• Parámetros de auditoría.
• Permisos mínimos.
• Configuración de actualizaciones.
• Herramientas de monitoreo o EDR requeridas.
• Protocolos deshabilitados.

17.12 Benchmarks y estándares

Existen guías de hardening que ayudan a definir configuraciones seguras. Un ejemplo muy usado son los benchmarks CIS. También pueden existir estándares internos de la organización.

Estas guías son útiles porque evitan empezar desde cero, pero deben adaptarse al contexto. Aplicar una configuración estricta sin pruebas puede romper servicios.

Uso recomendado:

• Tomar una guía como punto de partida.
• Validar impacto en laboratorio.
• Adaptar excepciones justificadas.
• Documentar desviaciones.
• Revisar cumplimiento periódicamente.

17.13 Firewall local

El firewall local del sistema operativo ayuda a limitar conexiones entrantes y salientes del propio host. Es una capa importante incluso cuando existe firewall de red.

Usos frecuentes:

• Bloquear conexiones entrantes innecesarias.
• Permitir administración solo desde redes autorizadas.
• Limitar comunicación entre estaciones de trabajo.
• Restringir servicios por perfil de red.
• Reducir movimiento lateral.

17.14 Logging y auditoría del sistema

Un sistema endurecido debe registrar eventos relevantes. Sin logs, investigar un incidente se vuelve mucho más difícil.

Eventos útiles:

• Inicios de sesión exitosos y fallidos.
• Uso de privilegios administrativos.
• Creación o eliminación de usuarios.
• Cambios de grupos y permisos.
• Instalación de servicios.
• Cambios en archivos críticos.
• Eventos del firewall local.
• Errores de seguridad relevantes.

17.15 Protección de administración remota

La administración remota es necesaria, pero debe estar controlada. SSH, RDP, WinRM, consolas web y herramientas de gestión no deberían estar abiertas sin restricciones.

Buenas prácticas:

• Permitir administración solo desde redes o bastiones autorizados.
• Usar MFA cuando sea posible.
• Deshabilitar acceso directo desde internet.
• Registrar sesiones administrativas.
• Limitar usuarios con permiso de acceso remoto.
• Usar cifrado y protocolos seguros.
• Revisar intentos fallidos y bloqueos.

17.16 Ejemplo práctico: servidor Linux

Un servidor Linux que ejecuta una aplicación web podría endurecerse con estas medidas conceptuales:

• Actualizar sistema y paquetes.
• Deshabilitar servicios no utilizados.
• Permitir solo puertos necesarios en firewall local.
• Restringir SSH a red administrativa o bastión.
• Usar cuentas individuales y evitar acceso directo como root cuando sea posible.
• Aplicar permisos mínimos sobre archivos de aplicación.
• Activar logs de autenticación, sistema y aplicación.
• Instalar agente de monitoreo o EDR si aplica.

17.17 Ejemplo práctico: servidor Windows

Un servidor Windows que presta un servicio interno podría endurecerse con estas medidas conceptuales:

• Aplicar actualizaciones de seguridad.
• Revisar grupos locales privilegiados.
• Deshabilitar servicios innecesarios.
• Configurar Firewall de Windows para permitir solo lo requerido.
• Restringir RDP a red administrativa o bastión.
• Activar auditoría de inicios de sesión y cambios administrativos.
• Aplicar políticas de contraseña y bloqueo.
• Instalar EDR o agente de seguridad corporativo.

17.18 Validación del hardening

Después de endurecer, hay que validar. No basta con aplicar una lista de cambios.

Formas de validación:

• Escaneo de puertos autorizados.
• Revisión de servicios activos.
• Comparación contra baseline.
• Verificación de logs.
• Pruebas de acceso con usuarios autorizados y no autorizados.
• Escaneo de vulnerabilidades.
• Revisión de permisos críticos.

17.19 Errores frecuentes

• Endurecer sin probar: puede romper servicios productivos.
• Aplicar parches sin plan de reversión: aumenta impacto si algo falla.
• Dejar servicios innecesarios: aumenta superficie de ataque.
• Usar cuentas compartidas: elimina trazabilidad.
• Permitir administración desde cualquier origen: expone accesos críticos.
• No registrar eventos: dificulta investigación.
• No revisar desviaciones: la configuración se degrada con el tiempo.

17.20 Lista de verificación inicial

• Inventariar sistema, versión, rol y responsable.
• Aplicar parches según criticidad y exposición.
• Eliminar o deshabilitar servicios innecesarios.
• Revisar cuentas locales e inactivas.
• Separar cuentas administrativas de cuentas de uso diario.
• Aplicar permisos mínimos en archivos y directorios.
• Configurar firewall local.
• Restringir administración remota.
• Activar logs y auditoría.
• Comparar contra una configuración base y documentar excepciones.

17.21 Ideas clave para recordar

• Hardening reduce superficie de ataque y mejora trazabilidad.
• El mínimo privilegio aplica a usuarios, servicios, permisos y administración.
• Los servicios innecesarios deben eliminarse o deshabilitarse.
• Los parches deben priorizarse por riesgo, exposición y criticidad.
• Una configuración base permite estandarizar y auditar.
• El hardening debe validarse y revisarse periódicamente.

17.22 Conclusión

El hardening de sistemas operativos es una capa esencial de defensa. Reduce puntos débiles, limita privilegios, mejora registros y dificulta que un atacante avance después de obtener acceso inicial.

En el próximo tema estudiaremos hardening de servidores y servicios expuestos: web, SSH, bases de datos, correo y DNS.