Aquí tienes el análisis de los eventos SSH proporcionados, estructurado según tus requerimientos. ### 1. Línea de Tiempo (Timeline) | Timestamp (UTC) | Evento | Usuario | IP Origen | Puerto | Detalle Técnico | | :--- | :--- | :--- | :--- | :--- | :--- | | `08:00:01` | Fallo de contraseña | `admin` (inválido) | `203.0.113.42` | 51001 | Usuario no existe en el sistema. | | `08:00:08` | Fallo de contraseña | `root` (inválido) | `203.0.113.42` | 51002 | Usuario no existe en el sistema. | | `08:00:16` | Fallo de contraseña | `backup` | `203.0.113.42` | 51003 | Usuario válido, contraseña incorrecta. | | `08:00:31` | Fallo de contraseña | `backup` | `203.0.113.42` | 51004 | Usuario válido, contraseña incorrecta. | | **`08:00:42`** | **Acceso exitoso (Contraseña)** | **`backup`** | **`203.0.113.42`** | **51005** | **Autenticación por contraseña.** | | `08:00:43` | Sesión iniciada | `backup` (uid=1002) | - | - | PAM confirma apertura de sesión. | | `08:05:10` | Acceso exitoso (Clave pública) | `deploy` | `192.0.2.10` | 52001 | Autenticación por clave ED25519 (`LAB_EXAMPLE_KEY`). | --- ### 2. Hechos Observados vs. Hipótesis #### Hechos Observados (Datos duros del log) 1. **Origen común:** Las primeras cinco conexiones provienen de la misma IP: `203.0.113.42`. 2. **Secuencia de puertos:** Los puertos de origen incrementan secuencialmente (`51001` a `51005`) en intervalos regulares (aprox. 7-15 segundos entre intentos). 3. **Patrón de usuarios:** Se probaron primero usuarios genéricos/inválidos (`admin`, `root`) y luego uno específico (`backup`). 4. **Método de autenticación inicial:** El acceso exitoso a las 08:00:42 fue mediante **contraseña** (no clave pública). 5. **Segundo evento aislado:** A las 08:05:10, una IP diferente (`192.0.2.10`) accedió como `deploy` usando **clave pública**. #### Hipótesis (Interpretaciones posibles) * **Hipótesis A (Fuerza Bruta/Dict):** La secuencia rápida de fallos seguida de un éxito sugiere que el actor en `203.0.113.42` estaba ejecutando un script o herramienta de fuerza bruta/diccionario contra la cuenta `backup`. * **Hipótesis B (Contraseña débil):** Dado que solo hubo 2 fallos para `backup` antes del éxito, es posible que la contraseña fuera corta o común (ej. "password", "123456"), permitiendo el acceso en pocos intentos. * **Hipótesis C (Actividad Legítima vs. Maliciosa):** No se puede determinar si `203.0.113.42` es un atacante o un cliente legítimo con una conexión inestable que reintentó la autenticación, aunque el patrón de "usuarios inválidos primero" inclina hacia actividad automatizada/maliciosa. * **Hipótesis D (Independencia):** El login de `deploy` desde `192.0.2.10` podría ser completamente independiente del evento anterior, o podría ser parte de una campaña más amplia si ambas IPs están relacionadas. --- ### 3. ¿Qué demuestra y qué NO demuestra el login exitoso? #### Lo que SÍ demuestra: 1. **Autenticación válida:** El sistema aceptó las credenciales proporcionadas por `203.0.113.42` para el usuario `backup`. 2. **Sesión activa:** PAM confirmó que la sesión se abrió correctamente (uid=1002), lo que significa que el proceso SSHD no colapsó y el usuario tiene permisos de inicio de sesión. 3. **Dirección IP de origen:** El paquete TCP llegó desde `203.0.113.42` en ese momento específico. #### Lo que NO demuestra (Limitaciones): 1. **Identidad real del actor:** La IP `203.0.113.42` es la dirección de origen, pero no garantiza quién está detrás. Podría ser: * El atacante directo. * Un proxy o CDN. * Una máquina comprometida (botnet) usando esa IP como salida. * NAT (si es una red corporativa compartiendo IP pública). 2. **Intención:** No dice si el objetivo era robar datos, instalar malware, o simplemente probar la conectividad. 3. **Exclusividad de acceso:** No prueba que `backup` sea el único usuario comprometido; solo confirma que *ese* usuario fue usado en ese momento. 4. **Reputación de la IP:** Como se especificó, no debemos inferir si `203.0.113.42` es "mala" por su rango (aunque sea documentation range), sino por el comportamiento. --- ### 4. Siguientes Evidencias a Revisar Para profundizar en la investigación, se recomienda revisar: 1. **Logs de Comandos Ejecutados (`/var/log/auth.log` o `journalctl`):** * ¿Qué comandos ejecutó el usuario `backup` después de las 08:00:43? * Busca patrones como `whoami`, `ls -la /etc`, `curl | bash`, o acceso a `/home/`. 2. **Logs del Sistema (`syslog`/`dmesg`):** * ¿Hubo actividad inusual en el disco (I/O) o CPU justo después de las 08:00:43? * ¿Se crearon nuevos procesos o archivos temporales? 3. **Configuración de SSHD (`/etc/ssh/sshd_config`):** * ¿Está habilitada la autenticación por contraseña para todos los usuarios? (Idealmente, `backup` debería usar claves). * ¿Hay restricciones de IP permitidas (`AllowUsers`, `Match Address`)? 4. **Historial del Usuario `backup`:** * ¿Desde cuándo existe esta cuenta? * ¿Se ha usado antes desde otras IPs? * ¿Tiene permisos `sudo`? (Revisar `/etc/sudoers`). 5. **Correlación con el Login de `deploy` (`192.0.2.10`):** * ¿La clave pública `LAB_EXAMPLE_KEY` está registrada en `~/.ssh/authorized_keys` de `deploy`? * ¿Es una clave conocida por el equipo de DevOps o es nueva/sospechosa? 6. **Firewall / NetFlow:** * ¿Cuánto tiempo duró la sesión de `backup`? (¿Cerró a las 08:05? ¿Sigue abierta?). * ¿Hubo tráfico saliente desde el servidor hacia `203.0.113.42` o hacia otras IPs después del login? > **Nota final:** El rango `203.0.113.0/24` y `192.0.2.0/24` son rangos reservados para documentación (RFC 5737), lo que confirma que esto es un entorno de laboratorio o simulación, útil para probar hipótesis sin riesgo real.