Manual del estudiante — Module 2: Seguridad del Sistema y Configuración de Firewall
Manual del estudiante

# Linux Administration Essentials (Spanish Edition)

## Module 2: Seguridad del Sistema y Configuración de Firewall

LNX-001S

1-day course · 5 modules · beginner level

### Objetivos de aprendizaje

Al finalizar este módulo, usted podrá:

- Configurar y gestionar reglas de firewall utilizando ufw (Uncomplicated Firewall)
- Implementar políticas de seguridad para acceso SSH
- Configurar autenticación basada en claves SSH públicas/privadas
- Aplicar principios de endurecimiento básico del sistema Linux
- Monitorear intentos de acceso y eventos de seguridad mediante registros del sistema

# Lección 1: Fundamentos de Seguridad en Sistemas Linux

## Principios de Seguridad en Linux

La seguridad en sistemas Linux se basa en el modelo de defensa en profundidad, donde múltiples capas de protección trabajan juntas para mitigar riesgos. A diferencia de depender de una única medida de seguridad, este enfoque multicapa asegura que si un control falla, otros permanecen activos para proteger el sistema.

Los vectores de ataque más comunes en sistemas Linux incluyen:

- Acceso no autorizado SSH: Intentos de fuerza bruta contra servicios de acceso remoto
- Servicios expuestos innecesariamente: Puertos abiertos que no se utilizan activamente
- Escalación de privilegios: Explotación de vulnerabilidades para obtener acceso root
- Credenciales débiles: Contraseñas simples o predeterminadas que facilitan compromisos

## Modelo de Seguridad por Capas

Un sistema Linux bien asegurado implementa controles en múltiples niveles:

1. Capa de red: Firewall que filtra tráfico entrante y saliente
2. Capa de acceso: Autenticación robusta con claves SSH en lugar de contraseñas
3. Capa de autorización: Principio de mínimo privilegio para usuarios y procesos
4. Capa de auditoría: Registro detallado de eventos de seguridad para detección y análisis

El principio de mínimo privilegio establece que cada usuario, proceso o servicio debe tener únicamente los permisos necesarios para realizar sus funciones legítimas. Por ejemplo, un servidor web no necesita acceso root completo; debe ejecutarse con una cuenta de servicio limitada. Este principio reduce significativamente la superficie de ataque y limita el daño potencial de una brecha de seguridad.

## Implementación Práctica de Defensa en Profundidad

En este módulo, implementaremos defensa en profundidad mediante:

- Firewall (ufw): Primera barrera contra tráfico no autorizado
- Configuración SSH segura: Segunda barrera limitando cómo se puede acceder al sistema
- Autenticación con claves: Tercera barrera eliminando vulnerabilidad de contraseñas débiles
- Monitoreo de logs: Cuarta barrera detectando intentos de compromiso

Implementar estas capas de forma sistemática convierte un sistema vulnerable en una plataforma resistente a ataques comunes.

Diagrama ilustrado de las capas de seguridad en un sistema Linux mostrando firewall, autenticación SSH, control de acceso y registro de auditoría

Puntos para recordar

- La defensa en profundidad utiliza múltiples capas de seguridad en lugar de una única medida
- Los vectores de ataque comunes incluyen acceso SSH no autorizado y servicios expuestos
- El principio de mínimo privilegio limita permisos al nivel estrictamente necesario
- La seguridad efectiva requiere controles en red, acceso, autorización y auditoría

# Lección 2: Introducción al Firewall ufw

## ¿Qué es ufw?

ufw (Uncomplicated Firewall) es una interfaz simplificada para gestionar iptables, el framework de firewall de Linux. Diseñado para facilitar la configuración de reglas de firewall sin requerir conocimiento profundo de sintaxis compleja, ufw es la herramienta predeterminada en distribuciones como Ubuntu.

A diferencia de iptables, que requiere comandos extensos y detallados, ufw proporciona una sintaxis amigable:

    # Sintaxis iptables (compleja)
    iptables -A INPUT -p tcp --dport 22 -j ACCEPT

    # Sintaxis ufw (simplificada)
    ufw allow 22/tcp

## Filosofía de Funcionamiento

ufw opera bajo un modelo de políticas predeterminadas combinadas con reglas específicas. Las políticas predeterminadas establecen el comportamiento para tráfico que no coincide con ninguna regla específica:

- Política de entrada predeterminada: Generalmente configurada para denegar todo tráfico entrante
- Política de salida predeterminada: Generalmente configurada para permitir todo tráfico saliente
- Reglas específicas: Excepciones que permiten servicios necesarios (SSH, HTTP, etc.)

Este enfoque implementa el principio de "denegar todo por defecto, permitir explícitamente", una práctica fundamental en seguridad de redes.

## Comandos Básicos Esenciales

    # Verificar estado del firewall
    sudo ufw status verbose

    # Habilitar el firewall
    sudo ufw enable

    # Deshabilitar el firewall
    sudo ufw disable

    # Ver reglas numeradas
    sudo ufw status numbered

El comando `status verbose` muestra no solo las reglas activas, sino también las políticas predeterminadas y el estado de registro (logging), proporcionando una vista completa de la configuración actual del firewall.

Comparación visual entre flujo de tráfico sin firewall versus con firewall ufw activo mostrando tráfico bloqueado y permitido

Puntos para recordar

- ufw simplifica la gestión de iptables con sintaxis amigable para administradores
- Opera bajo el principio de denegar por defecto y permitir explícitamente
- Las políticas predeterminadas establecen comportamiento para tráfico no coincidente
- El comando status verbose proporciona vista completa de configuración actual

# Lección 3: Configuración de Reglas de Firewall con ufw

## Sintaxis de Reglas en ufw

Las reglas de ufw siguen una estructura lógica que especifica acción, servicio/puerto y protocolo. La sintaxis básica permite configurar rápidamente protecciones efectivas:

    # Permitir servicio por nombre
    sudo ufw allow ssh

    # Permitir puerto específico con protocolo
    sudo ufw allow 22/tcp

    # Denegar puerto específico
    sudo ufw deny 23/tcp

    # Permitir desde dirección IP específica
    sudo ufw allow from 192.168.1.100

    # Permitir puerto desde IP específica
    sudo ufw allow from 192.168.1.100 to any port 22

## Acciones de Reglas: Allow, Deny y Limit

Allow (Permitir): Acepta conexiones que coinciden con la regla. Usado para servicios legítimos que deben ser accesibles.

Deny (Denegar): Rechaza conexiones silenciosamente, sin enviar respuesta al origen. Esto hace que el puerto aparezca "cerrado" desde la perspectiva del atacante.

Limit (Limitar): Implementa protección contra ataques de fuerza bruta. Rechaza conexiones si una dirección IP realiza más de 6 intentos de conexión en 30 segundos:

    # Proteger SSH contra fuerza bruta
    sudo ufw limit ssh

La acción `limit` es especialmente valiosa para servicios de autenticación como SSH, donde múltiples intentos fallidos generalmente indican actividad maliciosa.

## Gestión de Reglas Existentes

    # Listar reglas con números
    sudo ufw status numbered

    # Eliminar regla por número
    sudo ufw delete 3

    # Eliminar regla por especificación
    sudo ufw delete allow 80/tcp

    # Reiniciar todas las reglas
    sudo ufw reset

## Orden de Procesamiento de Reglas

ufw procesa reglas en orden secuencial, de arriba hacia abajo. La primera regla que coincide con un paquete determina la acción. Por esto, reglas más específicas deben ubicarse antes que reglas generales:

    # Correcto: específico primero
    sudo ufw allow from 10.0.0.5 to any port 22
    sudo ufw limit ssh

    # Incorrecto: la regla limit procesaría primero
    # bloqueando potencialmente la IP específica

Diagrama de flujo ilustrado mostrando cómo ufw procesa paquetes entrantes contra reglas secuenciales hasta encontrar coincidencia

Puntos para recordar

- ufw soporta tres acciones principales: allow, deny y limit
- La acción limit proporciona protección automática contra ataques de fuerza bruta
- Las reglas se procesan secuencialmente, las más específicas deben ir primero
- Se pueden gestionar reglas mediante números o especificaciones completas

# Lección 4: Configuración Segura del Servicio SSH

## El Archivo sshd_config

El servicio SSH se configura mediante el archivo `/etc/ssh/sshd_config`, que controla todos los aspectos del comportamiento del servidor SSH. Las modificaciones a este archivo requieren reiniciar el servicio sshd para aplicarse:

    # Editar configuración SSH
    sudo nano /etc/ssh/sshd_config

    # Reiniciar servicio SSH
    sudo systemctl restart sshd

## Parámetros Críticos de Seguridad

PermitRootLogin: Controla si el usuario root puede conectarse vía SSH. La mejor práctica es establecer este valor en `no`:

    PermitRootLogin no

Permitir login root directo viola el principio de auditoría. Los administradores deben conectarse con cuentas personales y usar `sudo` para elevación de privilegios, creando registros claros de quién realizó qué acciones.

PasswordAuthentication: Determina si se acepta autenticación por contraseña. Deshabilitarla fuerza el uso de claves SSH:

    PasswordAuthentication no

Port: Cambia el puerto predeterminado (22) a uno no estándar, reduciendo ataques automatizados:

    Port 2222

ClientAliveInterval y ClientAliveCountMax: Controlan tiempo de espera de sesiones inactivas:

    ClientAliveInterval 300
    ClientAliveCountMax 2

Esta configuración desconecta sesiones inactivas después de 10 minutos (300 segundos × 2 intentos), previniendo que sesiones abandonadas permanezcan abiertas indefinidamente.

## Restricción de Acceso por Usuario

    # Permitir solo usuarios específicos
    AllowUsers admin desarrollo

    # Denegar usuarios específicos
    DenyUsers invitado temporal

    # Permitir solo grupos específicos
    AllowGroups ssh-users

Estas directivas implementan control granular sobre quién puede acceder al sistema vía SSH.

## Verificación de Configuración

Antes de reiniciar sshd después de cambios, verificar la sintaxis para evitar bloqueos:

    # Verificar sintaxis de configuración SSH
    sudo sshd -t

    # Si no hay errores, reiniciar servicio
    sudo systemctl restart sshd

Un error en sshd_config puede bloquear todas las conexiones SSH. Siempre mantener una sesión SSH abierta mientras se prueban cambios, proporcionando un "respaldo" en caso de error de configuración.

Ilustración de configuración SSH mostrando prácticas seguras versus inseguras lado a lado con indicadores visuales

Puntos para recordar

- El archivo sshd_config controla todos los aspectos de seguridad del servidor SSH
- Deshabilitar login root directo mejora auditoría y responsabilidad
- Desactivar autenticación por contraseña fuerza uso de claves SSH más seguras
- Siempre verificar sintaxis con sshd -t antes de reiniciar el servicio

# Lección 5: Autenticación SSH con Claves Públicas/Privadas

## Criptografía de Clave Pública

La autenticación SSH basada en claves utiliza criptografía asimétrica, donde se generan dos claves matemáticamente relacionadas:

- Clave privada: Permanece en el cliente, nunca se transmite, se protege con permisos restrictivos
- Clave pública: Se copia al servidor, puede compartirse libremente sin comprometer seguridad

Cuando un cliente intenta conectarse, el servidor envía un desafío cifrado con la clave pública. Solo el cliente con la clave privada correspondiente puede descifrar y responder correctamente, probando su identidad sin transmitir contraseñas por la red.

## Generación de Pares de Claves SSH

    # Generar par de claves RSA de 4096 bits
    ssh-keygen -t rsa -b 4096 -C "usuario@ejemplo.com"

    # Generar par de claves Ed25519 (más moderno)
    ssh-keygen -t ed25519 -C "usuario@ejemplo.com"

El algoritmo Ed25519 es preferido actualmente por su seguridad superior y mejor rendimiento con claves más pequeñas comparado con RSA.

Durante la generación, se solicita:

1. Ubicación del archivo: Predeterminado `~/.ssh/id_rsa` o `~/.ssh/id_ed25519`
2. Passphrase: Contraseña adicional que protege la clave privada

La passphrase añade una capa extra de seguridad: incluso si la clave privada se compromete, el atacante necesita la passphrase para usarla.

## Distribución de Claves Públicas

    # Método automático (recomendado)
    ssh-copy-id usuario@servidor.ejemplo.com

    # Método manual
    cat ~/.ssh/id_ed25519.pub | ssh usuario@servidor.ejemplo.com "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

El comando `ssh-copy-id` copia automáticamente la clave pública al servidor y establece permisos correctos.

## Gestión de Permisos de Archivos

Los permisos incorrectos en archivos SSH causan que el servicio rechace las claves por razones de seguridad:

    # En el cliente
    chmod 700 ~/.ssh
    chmod 600 ~/.ssh/id_ed25519
    chmod 644 ~/.ssh/id_ed25519.pub

    # En el servidor
    chmod 700 ~/.ssh
    chmod 600 ~/.ssh/authorized_keys

SSH es estricto con permisos porque archivos con permisos excesivos podrían ser modificados por otros usuarios, comprometiendo seguridad.

## Uso de ssh-agent para Gestión de Claves

    # Iniciar ssh-agent
    eval "$(ssh-agent -s)"

    # Agregar clave privada
    ssh-add ~/.ssh/id_ed25519

    # Listar claves cargadas
    ssh-add -l

El `ssh-agent` mantiene claves privadas en memoria desbloqueadas, solicitando passphrase solo una vez por sesión en lugar de en cada conexión.

Diagrama ilustrado del proceso de autenticación SSH con claves mostrando generación, distribución y proceso de desafío-respuesta

Puntos para recordar

- La autenticación por claves usa criptografía asimétrica con par de claves pública/privada
- Ed25519 es el algoritmo preferido actualmente sobre RSA tradicional
- Los permisos correctos en archivos SSH son críticos para que el servicio acepte claves
- ssh-agent simplifica gestión de múltiples claves con passphrase

# Lección 6: Monitoreo de Seguridad mediante Registros del Sistema

## Archivos de Registro Críticos para Seguridad

Linux mantiene registros detallados de eventos de seguridad en archivos específicos dentro de `/var/log/`:

auth.log (Ubuntu/Debian) o secure (RHEL/CentOS): Registra todos los eventos de autenticación y autorización:

    # Ver intentos de login SSH
    sudo tail -f /var/log/auth.log

    # Buscar intentos fallidos
    sudo grep "Failed password" /var/log/auth.log

    # Buscar autenticaciones exitosas
    sudo grep "Accepted" /var/log/auth.log

syslog: Registro general del sistema que incluye eventos de múltiples servicios:

    # Monitorear eventos en tiempo real
    sudo tail -f /var/log/syslog

    # Filtrar eventos específicos de SSH
    sudo grep sshd /var/log/syslog

## Uso de journalctl para Análisis Avanzado

`journalctl` es la herramienta moderna para consultar registros de systemd, proporcionando capacidades de filtrado superiores:

    # Ver todos los logs del servicio SSH
    sudo journalctl -u sshd

    # Logs SSH de la última hora
    sudo journalctl -u sshd --since "1 hour ago"

    # Logs SSH de hoy
    sudo journalctl -u sshd --since today

    # Seguir logs en tiempo real
    sudo journalctl -u sshd -f

    # Logs con prioridad de error o superior
    sudo journalctl -u sshd -p err

## Patrones de Ataque Comunes en Logs

Reconocer patrones sospechosos ayuda a identificar ataques:

Ataques de fuerza bruta SSH:

    Failed password for root from 203.0.113.42 port 45892 ssh2
    Failed password for admin from 203.0.113.42 port 45893 ssh2
    Failed password for user from 203.0.113.42 port 45894 ssh2

Múltiples intentos fallidos desde la misma IP indican ataque automatizado.

Escalación de privilegios con sudo:

    sudo: usuario : TTY=pts/0 ; PWD=/home/usuario ; USER=root ; COMMAND=/bin/bash

Monitorear comandos sudo ejecutados ayuda a detectar actividad no autorizada.

## Configuración de Rotación de Logs

Los archivos de registro crecen continuamente. La rotación automática previene que llenen el disco:

    # Ver configuración de rotación
    cat /etc/logrotate.d/rsyslog

La configuración típica rota logs semanalmente, mantiene 4 semanas de histórico y comprime archivos antiguos.

## Alertas Automatizadas con fail2ban

Aunque no forma parte de este módulo en detalle, `fail2ban` automatiza respuestas a patrones de ataque:

    # Instalar fail2ban
    sudo apt install fail2ban

    # Ver IPs bloqueadas
    sudo fail2ban-client status sshd

fail2ban analiza logs continuamente y actualiza reglas de firewall para bloquear automáticamente IPs con comportamiento malicioso.

Visualización de flujo de eventos de seguridad desde aplicaciones hasta archivos de registro y herramientas de análisis

Puntos para recordar

- auth.log registra todos los eventos de autenticación y autorización del sistema
- journalctl proporciona capacidades avanzadas de filtrado y búsqueda en logs de systemd
- Patrones como múltiples intentos fallidos desde una IP indican ataques de fuerza bruta
- La rotación automática de logs previene que archivos de registro llenen el disco

# Laboratorio: Configuración de Firewall UFW y Endurecimiento de Acceso SSH

Objetivo: Configurar un firewall básico con UFW, implementar autenticación SSH basada en claves públicas, y aplicar políticas de seguridad para proteger el acceso remoto al sistema

Tiempo estimado: 45 minutos

Plataforma: Ubuntu 22.04 LTS o superior

Requisitos previos:

- Sistema Ubuntu instalado con acceso sudo
- Acceso a terminal
- Editor de texto (nano o vim)
- Conexión de red activa
- Cliente SSH (para probar desde otra máquina o usar localhost)

## Procedimientos

### Paso 1: Verificar el estado actual del firewall UFW y comprobar si está instalado

Primero verificaremos si UFW está instalado y su estado actual. Ejecuta el siguiente comando:

    sudo ufw status verbose

Si UFW no está instalado, instálalo con:

    sudo apt update
    sudo apt install ufw -y

Resultado esperado:

Si UFW está inactivo verás:

    Status: inactive

Si está instalado correctamente, el comando no producirá errores.

✔ Verificación: Ejecuta `which ufw` y deberías ver la ruta `/usr/sbin/ufw`, confirmando que está instalado.

### Paso 2: Configurar las políticas predeterminadas del firewall para denegar tráfico entrante y permitir saliente

Establece políticas predeterminadas seguras antes de habilitar UFW. Esto bloqueará todo el tráfico entrante por defecto mientras permite el saliente:

    sudo ufw default deny incoming
    sudo ufw default allow outgoing

Estas políticas seguirán el principio de menor privilegio: negar todo excepto lo explícitamente permitido.

Resultado esperado:

    Default incoming policy changed to 'deny'
    (be sure to update your rules accordingly)
    Default outgoing policy changed to 'allow'
    (be sure to update your rules accordingly)

✔ Verificación: Ejecuta `sudo ufw status verbose` y verás las políticas predeterminadas listadas aunque UFW aún esté inactivo.

### Paso 3: Permitir conexiones SSH antes de habilitar el firewall para evitar perder acceso al sistema

CRÍTICO: Debes permitir SSH antes de activar UFW para no quedar bloqueado del sistema. Ejecuta:

    sudo ufw allow ssh

Esto permitirá conexiones en el puerto 22 (puerto predeterminado de SSH). Alternativamente, puedes ser más específico:

    sudo ufw allow 22/tcp

Resultado esperado:

    Rules updated
    Rules updated (v6)

Esto confirma que la regla se agregó tanto para IPv4 como IPv6.

✔ Verificación: Ejecuta `sudo ufw show added` para ver las reglas pendientes que se aplicarán al habilitar UFW.

### Paso 4: Habilitar el firewall UFW y confirmar su activación

Ahora activa UFW con el siguiente comando:

    sudo ufw enable

Se te pedirá confirmación ya que esto puede interrumpir conexiones SSH existentes. Escribe `y` y presiona Enter.

Luego verifica el estado:

    sudo ufw status numbered

Resultado esperado:

    Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
    Firewall is active and enabled on system startup

Al verificar el estado:

    Status: active

         To                         Action      From
         --                         ------      ----
    [ 1] 22/tcp                     ALLOW IN    Anywhere
    [ 2] 22/tcp (v6)                ALLOW IN    Anywhere (v6)

✔ Verificación: El firewall debe estar activo y mostrar la regla SSH. Verifica que puedes mantener tu sesión SSH actual sin desconexión.

### Paso 5: Generar un par de claves SSH para autenticación basada en claves públicas

Genera un par de claves SSH (pública y privada) usando el algoritmo Ed25519, que es más seguro y eficiente:

    ssh-keygen -t ed25519 -C "tu_email@ejemplo.com"

Cuando se te solicite:

- Enter file: Presiona Enter para aceptar la ubicación predeterminada `~/.ssh/id_ed25519`
- Enter passphrase: Ingresa una contraseña segura (opcional pero recomendado para mayor seguridad)
- Enter same passphrase again: Confirma la contraseña

Si prefieres usar RSA (compatible con sistemas más antiguos):

    ssh-keygen -t rsa -b 4096 -C "tu_email@ejemplo.com"

Resultado esperado:

    Generating public/private ed25519 key pair.
    Enter file in which to save the key (/home/usuario/.ssh/id_ed25519):
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /home/usuario/.ssh/id_ed25519
    Your public key has been saved in /home/usuario/.ssh/id_ed25519.pub
    The key fingerprint is:
    SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx tu_email@ejemplo.com
    The key's randomart image is:
    +--[ED25519 256]--+
    |    ..o          |
    |   . + o         |
    ...
    +----[SHA256]-----+

✔ Verificación: Verifica que las claves se crearon: ```bash ls -la ~/.ssh/ ``` Deberías ver `id_ed25519` (clave privada) y `id_ed25519.pub` (clave pública).

### Paso 6: Configurar la clave pública para permitir autenticación sin contraseña

Para este laboratorio, copiaremos la clave pública al archivo `authorized_keys` del mismo usuario para demostrar el proceso:

    mkdir -p ~/.ssh
    cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys
    chmod 700 ~/.ssh
    chmod 600 ~/.ssh/authorized_keys

Estos comandos:

1. Crean el directorio `.ssh` si no existe
2. Añaden la clave pública al archivo de claves autorizadas
3. Establecen los permisos correctos (700 para el directorio, 600 para el archivo)

Nota: En un entorno real, usarías `ssh-copy-id usuario@servidor_remoto` para copiar tu clave a otro servidor.

Resultado esperado:

Los comandos no producen salida si tienen éxito. El archivo authorized_keys se crea o actualiza silenciosamente.

✔ Verificación: Verifica los permisos y contenido: ```bash ls -la ~/.ssh/authorized_keys cat ~/.ssh/authorized_keys ``` Deberías ver permisos `-rw-------` y el contenido de tu clave pública.

### Paso 7: Crear una copia de respaldo del archivo de configuración SSH antes de modificarlo

Siempre crea respaldos antes de modificar archivos de configuración críticos:

    sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

Verifica que el respaldo se creó:

    ls -lh /etc/ssh/sshd_config*

Resultado esperado:

    -rw-r--r-- 1 root root 3.3K Jan 15 10:30 /etc/ssh/sshd_config
    -rw-r--r-- 1 root root 3.3K Jan 15 10:45 /etc/ssh/sshd_config.backup

✔ Verificación: Ambos archivos deben existir y tener tamaños similares.

### Paso 8: Modificar la configuración SSH para deshabilitar el login root remoto

Edita el archivo de configuración SSH:

    sudo nano /etc/ssh/sshd_config

Busca la línea que contiene `PermitRootLogin` (usa Ctrl+W en nano para buscar). Puede estar comentada con `#`. Modifícala para que quede:

    PermitRootLogin no

Asegúrate de eliminar el `#` al inicio si existe. Esta configuración previene que el usuario root inicie sesión directamente vía SSH, una práctica de seguridad recomendada.

Guarda el archivo con Ctrl+O, presiona Enter, y sal con Ctrl+X.

Resultado esperado:

El editor mostrará el archivo de configuración. No hay salida hasta que guardes y cierres.

✔ Verificación: Verifica el cambio: ```bash sudo grep '^PermitRootLogin' /etc/ssh/sshd_config ``` Debe mostrar: ``` PermitRootLogin no ```

### Paso 9: Configurar autenticación basada en claves públicas y deshabilitar autenticación por contraseña

Edita nuevamente el archivo de configuración SSH:

    sudo nano /etc/ssh/sshd_config

Busca y modifica/añade las siguientes líneas:

    PubkeyAuthentication yes
    PasswordAuthentication no
    ChallengeResponseAuthentication no
    UsePAM yes

ADVERTENCIA: Asegúrate de que tu clave pública esté configurada correctamente (paso 6) antes de deshabilitar PasswordAuthentication, o quedarás bloqueado.

Para este laboratorio y por seguridad, puedes dejar `PasswordAuthentication yes` hasta confirmar que la autenticación por clave funciona.

Resultado esperado:

El archivo se guarda sin errores.

✔ Verificación: Verifica las configuraciones: ```bash sudo grep -E '^(PubkeyAuthentication|PasswordAuthentication|ChallengeResponseAuthentication)' /etc/ssh/sshd_config ```

### Paso 10: Configurar tiempo de espera de sesión inactiva SSH

Continúa editando `/etc/ssh/sshd_config` y añade configuraciones para cerrar sesiones inactivas:

    sudo nano /etc/ssh/sshd_config

Añade al final del archivo:

    ClientAliveInterval 300
    ClientAliveCountMax 2

Estas configuraciones:

- `ClientAliveInterval 300`: Envía un mensaje de mantenimiento cada 300 segundos (5 minutos)
- `ClientAliveCountMax 2`: Permite 2 mensajes sin respuesta antes de desconectar
- Resultado: Desconexión tras 10 minutos de inactividad (300 × 2 = 600 segundos)

Guarda y cierra el archivo.

Resultado esperado:

El archivo se actualiza sin errores.

✔ Verificación: Verifica la configuración: ```bash sudo grep -E '^ClientAlive' /etc/ssh/sshd_config ``` Debe mostrar ambas líneas configuradas.

### Paso 11: Validar la configuración SSH y reiniciar el servicio para aplicar los cambios

Antes de reiniciar, valida que no haya errores de sintaxis en la configuración:

    sudo sshd -t

Si no hay errores, no mostrará ninguna salida. Si hay errores, corríge los antes de continuar.

Luego reinicia el servicio SSH:

    sudo systemctl restart sshd

Verifica que el servicio esté activo:

    sudo systemctl status sshd

Resultado esperado:

El comando `sshd -t` no produce salida si la configuración es válida.

Al verificar el estado:

    ● ssh.service - OpenBSD Secure Shell server
         Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
         Active: active (running) since Mon 2024-01-15 11:00:23 UTC; 5s ago
    ...

✔ Verificación: El servicio debe mostrar `Active: active (running)` en color verde. Tu sesión SSH actual debe permanecer conectada.

### Paso 12: Probar la autenticación SSH con clave pública

Abre una nueva terminal (NO cierres la sesión actual) y prueba conectarte usando la clave privada:

    ssh -i ~/.ssh/id_ed25519 localhost

Si configuraste una passphrase al crear la clave, se te solicitará. Ingresa la passphrase (no la contraseña del usuario).

Deberías conectarte sin que se solicite la contraseña del usuario del sistema.

Resultado esperado:

    Enter passphrase for key '/home/usuario/.ssh/id_ed25519':
    Welcome to Ubuntu 22.04.3 LTS (GNU/Linux 5.15.0-91-generic x86_64)
    ...
    Last login: Mon Jan 15 11:05:32 2024 from ::1

✔ Verificación: Si te conectas exitosamente sin ingresar la contraseña del usuario (solo la passphrase de la clave si la configuraste), la autenticación por clave funciona correctamente.

### Paso 13: Revisar los registros de autenticación para verificar eventos de acceso SSH

Examina los registros de autenticación para ver los intentos de conexión SSH:

    sudo tail -n 30 /var/log/auth.log

Para filtrar solo eventos SSH:

    sudo grep 'sshd' /var/log/auth.log | tail -n 20

También puedes usar journalctl para ver logs del servicio SSH:

    sudo journalctl -u ssh -n 20 --no-pager

Resultado esperado:

Verás entradas como:

    Jan 15 11:05:32 ubuntu sshd[12345]: Accepted publickey for usuario from ::1 port 54321 ssh2: ED25519 SHA256:xxx...
    Jan 15 11:05:32 ubuntu sshd[12345]: pam_unix(sshd:session): session opened for user usuario(uid=1000) by (uid=0)

✔ Verificación: Debes ver entradas `Accepted publickey` que confirman autenticación exitosa con clave pública, no `Accepted password`.

### Paso 14: Agregar reglas adicionales al firewall para permitir servicios específicos

Añade reglas para permitir tráfico HTTP y HTTPS (útil si vas a configurar un servidor web):

    sudo ufw allow http
    sudo ufw allow https

O especifica los puertos directamente:

    sudo ufw allow 80/tcp
    sudo ufw allow 443/tcp

Para limitar intentos de conexión SSH (prevenir ataques de fuerza bruta), usa:

    sudo ufw limit ssh

Esto limitará las conexiones: si un cliente intenta conectarse más de 6 veces en 30 segundos, se bloqueará temporalmente.

Verifica las reglas:

    sudo ufw status numbered

Resultado esperado:

    Rule added
    Rule added (v6)

Al verificar el estado:

    Status: active

         To                         Action      From
         --                         ------      ----
    [ 1] 22/tcp                     LIMIT       Anywhere
    [ 2] 80/tcp                     ALLOW       Anywhere
    [ 3] 443/tcp                    ALLOW       Anywhere
    [ 4] 22/tcp (v6)                LIMIT       Anywhere (v6)
    [ 5] 80/tcp (v6)                ALLOW       Anywhere (v6)
    [ 6] 443/tcp (v6)                ALLOW       Anywhere (v6)

✔ Verificación: Todas las reglas deben aparecer numeradas y activas para IPv4 e IPv6.

### Paso 15: Monitorear eventos de seguridad en tiempo real usando journalctl

Usa journalctl para ver logs del sistema en tiempo real, enfocándote en eventos relacionados con seguridad:

Para seguir logs de SSH en tiempo real:

    sudo journalctl -u ssh -f

Presiona Ctrl+C para detener.

Para ver eventos de autenticación con prioridad de advertencia o superior:

    sudo journalctl -p warning -n 50 --no-pager

Para ver todos los intentos de autenticación del día actual:

    sudo journalctl --since today | grep -i 'authentication\|failure\|failed'

Resultado esperado:

El comando con `-f` mostrará logs en tiempo real conforme ocurran. Verás eventos como:

    Jan 15 11:15:45 ubuntu sshd[12567]: Connection from 192.168.1.100 port 45678
    Jan 15 11:15:47 ubuntu sshd[12567]: Accepted publickey for usuario from 192.168.1.100

✔ Verificación: Los comandos deben ejecutarse sin errores y mostrar eventos de autenticación recientes. Si no hay actividad reciente, los resultados pueden estar vacíos.

## Solución de problemas

Problema: Después de habilitar UFW, se pierde la conexión SSH y no se puede acceder al servidor
Solución: Esto ocurre cuando no se permitió el puerto SSH antes de activar UFW. Si tienes acceso físico o por consola: 1) Accede directamente a la máquina, 2) Ejecuta `sudo ufw allow 22/tcp`, 3) Ejecuta `sudo ufw reload`. Si no tienes acceso físico, necesitarás usar la consola de gestión de tu proveedor de hosting. **Prevención**: Siempre ejecuta `sudo ufw allow ssh` ANTES de `sudo ufw enable`.
Problema: El comando 'ssh-keygen' genera un error 'Permission denied' al intentar crear las claves
Solución: Verifica que el directorio `~/.ssh` exista y tengas permisos de escritura. Ejecuta: `mkdir -p ~/.ssh && chmod 700 ~/.ssh`. Si el problema persiste, verifica el espacio en disco con `df -h`. También asegúrate de estar ejecutando el comando como usuario normal, no como root.
Problema: Después de configurar autenticación por clave, aún se solicita la contraseña del usuario al conectarse
Solución: Verifica: 1) Los permisos del directorio `~/.ssh` deben ser 700: `chmod 700 ~/.ssh`, 2) Los permisos de `authorized_keys` deben ser 600: `chmod 600 ~/.ssh/authorized_keys`, 3) Verifica que `PubkeyAuthentication yes` esté configurado en `/etc/ssh/sshd_config`, 4) Revisa los logs: `sudo tail /var/log/auth.log` para ver mensajes de error específicos, 5) Asegúrate de usar la clave correcta con `ssh -i ~/.ssh/id_ed25519 usuario@servidor`.
Problema: Al reiniciar el servicio SSH con 'systemctl restart sshd', aparece un error y el servicio no inicia
Solución: Hay un error de sintaxis en `/etc/ssh/sshd_config`. Ejecuta `sudo sshd -t` para validar la configuración. Verás mensajes específicos sobre el error (línea incorrecta, directiva desconocida, etc.). Corrige el error o restaura el respaldo: `sudo cp /etc/ssh/sshd_config.backup /etc/ssh/sshd_config`. Luego reinicia: `sudo systemctl restart sshd`.
Problema: El comando 'sudo ufw status' muestra 'Status: inactive' incluso después de ejecutar 'sudo ufw enable'
Solución: Esto puede ocurrir si UFW no está configurado para iniciarse al arrancar el sistema. Ejecuta: `sudo systemctl enable ufw` para habilitar el inicio automático, luego `sudo systemctl start ufw` para iniciarlo inmediatamente. Verifica con `sudo systemctl status ufw` que el servicio esté activo. Si persiste, verifica que no haya otro firewall (como iptables directo o firewalld) en conflicto.

## Ejercicio de desafío

### Configuración Avanzada de Seguridad SSH y Firewall

Implementa las siguientes mejoras de seguridad adicionales sin instrucciones paso a paso:

1. Cambiar el puerto SSH del predeterminado (22) a un puerto personalizado (por ejemplo, 2222):

   - Modifica la configuración de SSH
   - Actualiza las reglas del firewall UFW para permitir el nuevo puerto
   - Elimina la regla del puerto 22 antiguo
   - Prueba la conexión en el nuevo puerto

2. Configurar restricciones de acceso SSH por dirección IP:

   - Usa UFW para permitir conexiones SSH solo desde una dirección IP específica o rango de red
   - Ejemplo: `192.168.1.0/24` o tu dirección IP pública actual

3. Implementar fail2ban para protección contra ataques de fuerza bruta:

   - Instala y configura fail2ban
   - Configura una cárcel (jail) para SSH que banee IPs después de 3 intentos fallidos
   - Verifica que fail2ban esté monitoreando los logs de SSH
   - Simula intentos de login fallidos y confirma que la IP se banea temporalmente

4. Crear un script de monitoreo de seguridad:

   - Escribe un script bash que genere un reporte diario con:
     - Número de intentos de autenticación SSH fallidos
     - Últimas 10 IPs que se conectaron exitosamente
     - Estado actual del firewall y reglas activas
     - Espacio en disco usado en `/var/log`
   - Guarda el reporte en `/var/log/security-report-$(date +%Y%m%d).txt`

Pista: Investiga los archivos de configuración en `/etc/ssh/`, comandos de UFW avanzados, la documentación de fail2ban, y comandos como `awk`, `grep`, `sort`, `uniq` para procesar logs.

Verificación de éxito: Debes poder conectarte SSH en el nuevo puerto, fail2ban debe estar bloqueando IPs después de intentos fallidos, y tu script debe generar un reporte legible con información de seguridad relevante.

# Preguntas de práctica

1. ¿Cuál es la principal ventaja del modelo de defensa en profundidad en seguridad de sistemas Linux?

A) Reduce el número de controles de seguridad necesarios

B) Proporciona múltiples capas de protección donde el fallo de una no compromete todo el sistema

C) Elimina completamente la necesidad de actualizaciones de seguridad

D) Permite desactivar el firewall para mejorar rendimiento

2. ¿Qué acción realiza el comando 'sudo ufw limit ssh'?

A) Bloquea completamente todas las conexiones SSH

B) Limita las conexiones SSH solo a direcciones IP locales

C) Rechaza conexiones si una IP realiza más de 6 intentos en 30 segundos

D) Permite solo 6 conexiones SSH simultáneas en total

3. ¿Por qué es importante deshabilitar 'PermitRootLogin' en la configuración SSH?

A) El usuario root no puede ejecutar comandos remotamente

B) Mejora la auditoría al requerir que administradores usen cuentas personales y sudo

C) Previene que el sistema tenga un usuario root

D) Aumenta la velocidad de las conexiones SSH

4. ¿Cuál es la diferencia principal entre clave pública y clave privada en autenticación SSH?

A) La clave pública se usa para cifrar y la privada para descifrar

B) La clave privada se comparte con servidores y la pública permanece en el cliente

C) La clave pública puede compartirse libremente mientras la privada nunca se transmite

D) Ambas claves deben mantenerse secretas y nunca compartirse

5. ¿Qué comando se utiliza para verificar la sintaxis del archivo sshd_config antes de reiniciar el servicio?

A) sudo sshd --check

B) sudo sshd -t

C) sudo systemctl validate sshd

D) sudo ssh-config test

6. ¿Qué archivo de registro contiene información específica sobre eventos de autenticación y autorización en sistemas Ubuntu/Debian?

A) /var/log/messages

B) /var/log/auth.log

C) /var/log/security

D) /var/log/sshd.log

7. ¿Cuál es el propósito de usar 'ssh-agent' en la gestión de claves SSH?

A) Genera automáticamente nuevas claves SSH cada día

B) Comparte claves privadas entre múltiples usuarios

C) Mantiene claves privadas en memoria desbloqueadas, solicitando passphrase solo una vez por sesión

D) Elimina la necesidad de usar passphrase en claves privadas

8. Al configurar reglas de firewall con ufw, ¿por qué es importante el orden en que se agregan las reglas?

A) ufw ordena automáticamente las reglas por prioridad, el orden no importa

B) Las reglas se procesan secuencialmente y la primera coincidencia determina la acción

C) El orden solo afecta la visualización, no el procesamiento

D) Las reglas más generales siempre deben ir antes que las específicas

# Resumen del módulo

Este módulo cubrió aspectos fundamentales de seguridad en sistemas Linux, comenzando con el modelo de defensa en profundidad y sus múltiples capas de protección. Se exploró la configuración del firewall ufw, incluyendo sintaxis de reglas, acciones (allow, deny, limit) y gestión de políticas predeterminadas. Se profundizó en la configuración segura de SSH mediante el archivo sshd_config, destacando parámetros críticos como PermitRootLogin y PasswordAuthentication. Se explicó la autenticación SSH basada en claves públicas/privadas, incluyendo generación con ssh-keygen, distribución de claves y gestión de permisos. Finalmente, se abordó el monitoreo de seguridad mediante archivos de registro como auth.log y syslog, así como el uso de journalctl para análisis avanzado de eventos del sistema.