27.Bitácoras (logs)

Una bitácora (log) es el registro automático de lo que pasa en un sistema: quién inició sesión y cuándo, quién intentó entrar y falló, qué se instaló, qué se borró, qué errores hubo.

Es como el libro de registro de visitantes en la entrada de una escuela: si algo se pierde, revisas quién entró, a qué hora y a dónde fue.

En términos técnicos

• Casi todo genera bitácoras: sistemas operativos, servidores web, bases de datos, firewalls, routers, aplicaciones y servicios en la nube.
• Cada evento tiene, como mínimo, fecha y hora, origen (equipo, usuario, IP), tipo de evento y resultado.
• Para que sirvan deben estar activadas, con la hora sincronizada (NTP), centralizadas (lejos del equipo que las genera) y conservadas el tiempo necesario.
• Se revisan a mano, con filtros o con un SIEM que las correlaciona y genera alertas.

¿Dónde las vas a encontrar?

En el Visor de eventos de Windows, en /var/log y journalctl de Linux, en los registros de acceso de Nginx o Apache, en el historial de inicios de sesión de Google o Microsoft 365, en show logging de un router Cisco y en la consola de cualquier servicio en la nube.

Un caso verosímil

Aparecen calificaciones modificadas en el sistema escolar. La dirección quiere saber quién lo hizo y desde dónde. El sistema sí tenía bitácora de cambios, pero se guardaba en el mismo servidor, solo una semana, y con la hora atrasada 40 minutos. Cuando se notó el problema, ya habían pasado dos semanas.

Qué se perdió

• La posibilidad de saber qué pasó y de demostrarlo.

Qué lo habría evitado

Conservar las bitácoras del sistema escolar al menos un ciclo escolar, enviarlas a otro servidor y sincronizar la hora. Con eso, la investigación habría tomado una tarde.

Qué registrar como mínimo

Eventos clave de Windows (registro de Seguridad)

Consultarlas

# Windows (PowerShell): últimos 20 inicios de sesión fallidos
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 20

# Linux: intentos fallidos de SSH
sudo grep "Failed password" /var/log/auth.log
sudo journalctl -u ssh --since today

# Cisco
R1# show logging

Por nivel

MITRE ATT&CK: los atacantes intentan borrarlas (T1070 — Indicator Removal, subtécnica de borrado de registros de eventos de Windows); mitigación M1047 — Audit.

• Protege las bitácoras: si están solo en el equipo atacado, se pueden borrar.
• Cuidado con los datos personales: las bitácoras también los contienen; aplícales las mismas reglas.
• No registres contraseñas ni datos de tarjetas en los logs de tus aplicaciones.
• Define cuánto tiempo guardarlas según la ley, la política y el espacio disponible.
• Revísalas de verdad: una bitácora que nadie mira solo sirve después del problema.

• NIST. SP 800-92 — Guide to Computer Security Log Management (2006) y su revisión en borrador SP 800-92 Rev. 1. https://csrc.nist.gov/pubs/sp/800/92/final
• Microsoft. Events to monitor (eventos de auditoría de seguridad de Windows). https://learn.microsoft.com/windows-server/identity/ad-ds/plan/appendix-l--events-to-monitor
• CISA y otras agencias. Best Practices for Event Logging and Threat Detection (2024).
• MITRE ATT&CK. T1070 — Indicator Removal. https://attack.mitre.org/techniques/T1070/