Logs y monitoreo
El SIEM que viste en el módulo anterior necesita algo para procesar: registros. Este módulo es sobre esa materia prima — dónde viven, cómo leerlos, y qué historia cuentan cuando sabés mirarlos bien.
Qué es un log
Un log (registro) es una línea de texto con marca de tiempo que un sistema escribe automáticamente cada vez que ocurre algo relevante: un login, un archivo que se abre, una conexión de red, un error. Individualmente cada línea parece poco, pero un sistema completo genera miles por minuto, y ahí está escondida toda la historia de lo que realmente pasó.
Un log es como la cinta de una caja registradora: cada operación queda anotada con hora exacta, aunque en el momento nadie la mire. Nadie revisa la cinta completa todos los días — pero el día que falta dinero en la caja, esa cinta es la única forma real de reconstruir qué pasó y cuándo.
Dónde viven los logs más importantes
Logs de SO
Windows Event Viewer o /var/log/ en Linux: logins, cambios de permisos, arranque de servicios.
Logs de firewall
Qué tráfico se permitió o bloqueó, entre qué IPs, por qué puerto.
Logs de servidor web
Cada petición HTTP recibida: IP de origen, método, URL pedida, código de respuesta.
Logs de autenticación
Cada intento de login, exitoso o fallido, con usuario y hora — clave para detectar fuerza bruta.
Anatomía de una línea de log
Casi todo log, sin importar el sistema que lo genera, comparte una estructura reconocible: marca de tiempo (cuándo), origen (qué sistema o proceso lo generó), severidad (info, warning, error, crítico) y mensaje (qué pasó exactamente). Aprender a identificar estas cuatro partes en cualquier log nuevo que veas, aunque el formato cambie, es la habilidad base de todo analista.
Jul 8 14:32:07 web01 sshd[2211]: Failed password for root from 203.0.113.44 port 51422 ssh2Leyendo esa línea con las cuatro partes en mente: Jul 8 14:32:07 (cuándo), web01 sshd (qué proceso, en qué máquina), y el mensaje te dice que alguien intentó loguearse como root con contraseña incorrecta, desde la IP 203.0.113.44. Una sola línea así no alarma a nadie — cien líneas iguales en un minuto, sí.
grep: tu primera herramienta real de análisis
Ya viste grep mencionado en Fundamentos. Acá es donde se vuelve indispensable: filtrar, entre miles de líneas de log, exactamente las que importan.
grep "Failed password" /var/log/auth.log | wc -lEste comando cuenta cuántos intentos de login fallidos hay en el log de autenticación. Combinado con más filtros (por IP, por usuario, por rango de fechas), grep te permite hacer a mano, en una máquina chica, exactamente el mismo tipo de búsqueda que un SIEM automatiza a gran escala.
Un atacante sabe que sus acciones generan logs, y parte de una intrusión sofisticada es intentar limpiarlos o evitarlos (algo que tocaste en Post-explotación). Por eso una buena práctica defensiva es enviar los logs a un servidor centralizado y separado, apenas se generan — si el atacante borra los logs locales de la máquina comprometida, la copia externa sigue intacta.
En tu máquina Linux (real o virtual), mirá el log de autenticación con sudo cat /var/log/auth.log (Debian/Ubuntu) o sudo cat /var/log/secure (CentOS/RHEL).
Filtrá solo los intentos fallidos: grep "Failed password" /var/log/auth.log.
Contá cuántas veces aparece la misma IP intentando y fallando: grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr.
Si alguna IP aparece decenas de veces en poco tiempo, eso es un indicio claro de un ataque de fuerza bruta — la misma lógica que un SIEM real usaría, pero hecha a mano por vos.
Ponete a prueba
1. ¿Cuáles son las cuatro partes típicas de una línea de log?
2. ¿Para qué sirve enviar logs a un servidor centralizado separado?
3. Ver muchas líneas de "Failed password" de la misma IP en poco tiempo generalmente indica...