Esta parte sigue con el hardening de seguridad en Linux con algunas protecciones a nivel del sistema: parámetros de hardening del kernel, control de acceso SELinux, y registro de auditoría que rastrea todo lo que está sucediendo en tu sistema.

linux-hardening.webp


Control de Acceso Obligatorio SELinux

SELinux puede ser complicado pero es una excelente característica de seguridad del kernel que continúa bloqueando acciones no autorizadas en tu sistema.

Aunque puede ser desafiante de configurar, SELinux tiene excelentes valores predeterminados para las aplicaciones más comunes, así que para el 90% de los casos de uso ni siquiera notarás que SELinux está corriendo. Si SELinux está bloqueando algo en una configuración predeterminada, puedes agregar una excepción de política para permitir la acción. No deshabilites SELinux.


Verificar el Estado de SELinux

Primero, verifica que SELinux esté realmente habilitado y en modo enforcing.

# Verificar modo actual
getenforce
# Debería mostrar "Enforcing"

# Estado detallado
sestatus
# Muestra: estado de SELinux, tipo de política, modo

# Verificar si SELinux está denegando algo
ausearch -m avc -ts recent

El modo enforcing significa que SELinux bloquea activamente acciones no autorizadas. El modo permissive registra violaciones pero no las bloquea, lo cual es útil para depuración pero no proporciona protección real.


Entender los Contextos de SELinux

Cada archivo, proceso, puerto y usuario en SELinux tiene un contexto de seguridad (también llamado “label”). Estos contextos determinan qué puede acceder a qué. El formato es user:role:type:level, pero para la mayoría de los casos, solo te importa el campo type.

Por ejemplo, los archivos del servidor web deberían tener el tipo httpd_sys_content_t, y el proceso httpd corre con el tipo httpd_t. La política de SELinux permite que los procesos httpd_t lean archivos httpd_sys_content_t, pero no archivos user_home_t (que están en los directorios home de los usuarios). Esto significa que incluso si httpd está comprometido y corriendo como root, todavía no puede acceder a las claves SSH en /root/.ssh/ porque la política de SELinux lo niega.


Ver contextos de archivos y procesos.

# Mostrar contexto de archivo
ls -Z /var/www/html/index.html
# Salida: unconfined_u:object_r:httpd_sys_content_t:s0

# Mostrar contexto de proceso
ps -eZ | grep httpd
# Salida: system_u:system_r:httpd_t:s0 1234 ? 00:00:00 httpd

# Verificar contexto de servicios en ejecución
systemctl status httpd

Cuando creas o mueves archivos, podrían heredar el contexto incorrecto. Esta es la causa más común de denegaciones de SELinux. Por ejemplo, si copias un archivo desde tu directorio home a /var/www/html/, podría mantener el contexto user_home_t en lugar de obtener httpd_sys_content_t.


Corregir Problemas de Contexto

El comando restorecon restaura los contextos predeterminados basados en la ubicación del archivo.

# Restaurar contexto para un solo archivo
restorecon /var/www/html/index.html

# Restaurar recursivamente para un directorio
restorecon -Rv /var/www/html/

# Vista previa de lo que cambiaría sin aplicar
restorecon -Rvn /var/www/html/

Para contextos personalizados permanentes (como si estás alojando contenido web desde una ubicación no estándar), usa semanage fcontext.

# Agregar regla de contexto persistente para directorio web personalizado
semanage fcontext -a -t httpd_sys_content_t "/web/custom(/.*)?"

# Aplicar la nueva regla (restaura la política)
restorecon -Rv /web/custom/

# Ver reglas de contexto personalizadas
semanage fcontext -l | grep custom

Booleanos de SELinux

SELinux usa booleanos para alternar comportamientos específicos sin reescribir políticas, así que puedes encenderlos y apagarlos para escenarios específicos. La opción -P hace los cambios persistentes entre reinicios.

# Listar todos los booleanos
getsebool -a

# Verificar booleano específico
getsebool httpd_can_network_connect

# Ejemplo
# Permitir que httpd haga conexiones de red salientes (para proxies inversos, llamadas a API)
setsebool -P httpd_can_network_connect on

Solucionar Problemas con Denegaciones de SELinux

Cuando SELinux bloquea algo, registra una “denegación AVC” en el log de auditoría. Estos mensajes son crípticos, pero audit2why los traduce a explicaciones legibles para humanos.

# Ver denegaciones recientes
ausearch -m avc -ts recent

# Explicar por qué se denegó el acceso
ausearch -m avc -ts recent | audit2why

Importante: No ejecutes ciegamente audit2allow e instales cualquier política que genere. Lee la denegación, entiende qué está siendo bloqueado, y determina si la aplicación realmente debería tener permitido hacer eso. A veces SELinux te está protegiendo de una aplicación mal configurada o comprometida.

Por ejemplo, si ves denegaciones de httpd intentando ejecutar archivos en /tmp/, la solución correcta no es permitirlo. La solución correcta es averiguar por qué httpd está intentando ejecutar archivos temporales y arreglar la configuración de la aplicación.


Auditar Actividad del Sistema

Es importante verificar qué está sucediendo en tu sistema. Qué puertos están abiertos, qué está corriendo, qué está siendo accedido.


Verificar Servicios de Red en Escucha

Verifica qué servicios están expuestos en la red. Cualquier puerto en escucha es un vector de ataque potencial.

# Mostrar todos los puertos TCP/UDP en escucha con información de proceso
ss -tulpn

# Alternativa usando lsof
lsof -i -P -n | grep LISTEN

# Mostrar solo puertos TCP en escucha
ss -tln

# Mostrar puertos en escucha con direcciones numéricas (sin búsquedas DNS)
netstat -tuln

La salida muestra qué puertos están vinculados a qué interfaces. Presta atención a:

  • Puertos escuchando en 0.0.0.0 (todas las interfaces) vs 127.0.0.1 (solo localhost)
  • Servicios inesperados que no recuerdas haber instalado
  • Números de puerto altos que podrían ser backdoors o configuraciones incorrectas

Para cada puerto en escucha, verifica:

  1. Qué servicio lo posee (ss -tulpn muestra el proceso)
  2. Si realmente necesitas que esté expuesto
  3. Si debería estar restringido a localhost en lugar de todas las interfaces

Si encuentras servicios en escucha que no reconoces, investiga antes de deshabilitar.

# Identificar qué paquete posee el binario
rpm -qf $(which servicename)

# Verificar qué hace el servicio
systemctl status servicename
man servicename

Auditd para Registro de Eventos del Sistema

El registro estándar del sistema con journald captura mensajes de servicio y errores, pero no rastrea eventos de seguridad detallados como accesos a archivos o intentos de autenticación. Eso es lo que hace auditd.

Auditd funciona a nivel del kernel. Puede rastrear virtualmente cualquier actividad del sistema (accesos a archivos, llamadas al sistema, conexiones de red, comandos de usuario).


Instalar y habilitar auditd.

# Ya debería estar instalado en RHEL/Fedora
dnf install audit

# Habilitar e iniciar servicio
systemctl enable --now auditd

# Verificar estado
systemctl status auditd

Configurar Reglas de Auditoría

Las reglas de auditoría definen qué eventos registrar. Puedes monitorear archivos específicos, directorios, llamadas al sistema o acciones de usuario. Las reglas se definen en /etc/audit/rules.d/audit.rules o /etc/audit/audit.rules.


Algunas reglas de auditoría útiles.

# Monitorear cambios en archivos de autenticación del sistema
-w /etc/passwd -p wa -k passwd_changes
-w /etc/shadow -p wa -k shadow_changes
-w /etc/group -p wa -k group_changes
-w /etc/sudoers -p wa -k sudoers_changes

# Monitorear configuración de SSH
-w /etc/ssh/sshd_config -p wa -k sshd_config_changes

# Rastrear uso de sudo
-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=-1 -F key=sudo_commands

# Monitorear eliminación de archivos por usuarios
-a always,exit -F arch=b64 -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=-1 -k file_deletion

# Vigilar directorios críticos
-w /etc/ -p wa -k etc_changes
-w /boot/ -p wa -k boot_changes

La bandera -w vigila un archivo o directorio. La bandera -p especifica los permisos a monitorear:

  • r - lectura
  • w - escritura
  • x - ejecución
  • a - cambio de atributo

Agrega tus reglas personalizadas a /etc/audit/rules.d/custom.rules.

# Crear archivo de reglas personalizadas
vim /etc/audit/rules.d/custom.rules

# Recargar reglas de auditoría
augenrules --load

# O reiniciar auditd
service auditd restart

# Verificar que las reglas estén cargadas
auditctl -l

Hardening del Kernel

Puedes configurar el kernel de Linux con sysctl para mejorar su seguridad, networking y rendimiento.


Protección de Memoria

El filesystem /proc expone direcciones de memoria del kernel y otra información sensible. Por defecto, cualquier proceso puede leer estos, lo que ayuda a los atacantes a evitar la randomización del diseño del espacio de direcciones.


Ocultar Punteros del Kernel

El parámetro kernel.kptr_restrict controla el acceso a direcciones de puntero del kernel.

# 0 = Mostrar punteros del kernel (predeterminado, inseguro)
# 1 = Ocultar de usuarios sin privilegios, mostrar a root
# 2 = Ocultar de todos, incluyendo root

kernel.kptr_restrict=2

Configurar esto en 2 oculta los punteros del kernel de todos, lo cual es más seguro. Sin embargo, algunas herramientas de monitoreo de rendimiento (como perf) necesitan acceso a símbolos del kernel para funcionar correctamente. Si tienes problemas con herramientas de depuración, configúralo en 1 en su lugar, lo que oculta los punteros de usuarios regulares pero permite acceso a root.


Restringir Acceso a Logs del Kernel

Los logs del kernel (accesibles vía dmesg) pueden filtrar información sensible sobre hardware, direcciones del kernel y configuración del sistema. Restringe el acceso solo a root.

# Prevenir que usuarios regulares lean el buffer del kernel
kernel.dmesg_restrict=1

Esto debería estar habilitado por defecto en sistemas modernos, pero vale la pena verificarlo, especialmente en instalaciones antiguas o kernels personalizados.


Parámetros de Seguridad de Red

Varios parámetros de networking del kernel mejoran la seguridad contra ataques comunes basados en red:


Protección contra SYN Flood

Los SYN floods son un tipo de ataque de denegación de servicio que explota el handshake de tres vías de TCP. Habilitar SYN cookies permite al kernel manejar SYN floods sin mantener estado para cada intento de conexión.

# Habilitar SYN cookies
net.ipv4.tcp_syncookies=1

Esto usualmente está habilitado por defecto, pero verifica que esté configurado. No hay desventajas reales con las SYN cookies en kernels modernos.


Filtrado de Ruta Inversa (Anti-Spoofing)

El filtrado de ruta inversa verifica que los paquetes entrantes realmente vengan de la red que dicen venir. Esto previene ataques de IP spoofing.

# Habilitar filtrado de ruta inversa estricto en todas las interfaces
net.ipv4.conf.all.rp_filter=1
net.ipv4.conf.default.rp_filter=1

El modo 1 es estricto (descarta paquetes si la ruta de retorno no coincide con la interfaz entrante. El modo 2 es flexible) solo verifica si la IP de origen es enrutable. Para la mayoría de los sistemas, el modo estricto es apropiado. Si estás haciendo enrutamiento asimétrico (el tráfico entra por una interfaz y sale por otra), podrías necesitar el modo flexible.


Deshabilitar Reenvío de IP

A menos que tu sistema sea un router, el reenvío de IP debería estar deshabilitado.

# Deshabilitar reenvío IPv4
net.ipv4.ip_forward=0

# Deshabilitar reenvío IPv6
net.ipv6.conf.all.forwarding=0

Esto previene que tu sistema enrute paquetes entre interfaces de red, lo cual podría ser explotado para evitar reglas de firewall o conducir ataques de man-in-the-middle.


Deshabilitar IPv6 (Si No lo Estás Usando)

Si no estás usando IPv6, deshabilítalo completamente para reducir la superficie de ataque.

# Deshabilitar IPv6 en todas las interfaces
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1

Ten en cuenta que esto rompe aplicaciones que intentan vincularse a direcciones IPv6. La mayoría de las aplicaciones manejan esto con gracia, pero algunas (como ciertos conectores de bases de datos) podrían fallar. Prueba exhaustivamente antes de implementar esto en producción.


Ignorar Redirecciones ICMP

Las redirecciones ICMP le dicen a los hosts que usen una ruta diferente para ciertos destinos. Aceptar estas desde redes no confiables puede ser usado para ataques de man-in-the-middle.

# Ignorar mensajes de redirección ICMP
net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.default.accept_redirects=0
net.ipv6.conf.all.accept_redirects=0
net.ipv6.conf.default.accept_redirects=0

# No enviar redirecciones ICMP (si no es un router)
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.send_redirects=0

Aplicar Configuraciones de Sysctl

Crea un archivo de configuración sysctl personalizado para todos tus parámetros de hardening.

# Crear configuración de hardening
sudo tee /etc/sysctl.d/99-hardening.conf << EOF
# Protección de memoria
kernel.kptr_restrict=2
kernel.dmesg_restrict=1

# Seguridad de red
net.ipv4.tcp_syncookies=1
net.ipv4.conf.all.rp_filter=1
net.ipv4.conf.default.rp_filter=1
net.ipv4.ip_forward=0
net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.default.accept_redirects=0
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.send_redirects=0

# Seguridad IPv6 (si usas IPv6)
net.ipv6.conf.all.forwarding=0
net.ipv6.conf.all.accept_redirects=0
net.ipv6.conf.default.accept_redirects=0
EOF

# Cargar las nuevas configuraciones
sudo sysctl -p /etc/sysctl.d/99-hardening.conf

# Verificar que las configuraciones estén aplicadas
sysctl -a | grep kptr_restrict
sysctl -a | grep dmesg_restrict
sysctl -a | grep tcp_syncookies

Las configuraciones en /etc/sysctl.d/ persisten entre reinicios. El prefijo 99- asegura que este archivo se carga después de otras configuraciones sysctl, así que tus configuraciones tienen precedencia. Este es un buen enfoque porque lo agregamos en el directorio drop-in en lugar de escribirlo directamente en /etc/sysctl.


¡Usa Siempre una VPN!

Usa siempre una VPN pagada (o auto-alojada) para todas tus conexiones.


Servicios VPN Comerciales

Cuando usas una VPN estás confiando en el proveedor de VPN en lugar de tu ISP. Proveedores como Mullvad o ProtonVPN son buenas opciones ya que son zero-knowledge y amigables con la privacidad.


VPN Auto-Alojada (Tailscale/Headscale)

Para algunas conexiones también recomiendo Headscale o Tailscale, que crea una VPN mesh entre todos mis dispositivos. Su propósito no es ocultar el tráfico sino crear conexiones seguras entre mis dispositivos sin importar en qué red estén.


¿Qué Sigue?

Estas son las formas más comunes de asegurar un sistema Linux, sin embargo la seguridad es un proceso sin fin y siempre hay nuevas vulnerabilidades y cambios sucediendo así que mantén esta práctica actualizada.

La seguridad perfecta no existe, así que sigue con ello.