Capítulo 17 — Infraestructura crítica y seguridad sectorial: herramientas
Mapa de la lección
Lección 17 publicada. Mapa, ejemplo, EX049.
flowchart TD
N0["Resultados de aprendizaje y conexión"]
N1["17.1 Qué registrar"]
N2["17.2 La hora"]
N3["17.3 Registros estructurados y syslog"]
N4["17.4 Normalización"]
N5["17.5 Herramientas en las que se puede confiar"]
N6["17.7 Actividad práctica: normalizador"]
N7["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX049"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje y conexión"]
N1["17.1 Qué registrar"]
N2["17.2 La hora"]
N3["17.3 Registros estructurados y syslog"]
N4["17.4 Normalización"]
N5["17.5 Herramientas en las que se puede confiar"]
N6["17.7 Actividad práctica: normalizador"]
N7["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX049"]
[Resultados de aprendizaje y conexión]
|
v
[17.1 Qué registrar]
|
v
[17.2 La hora]
|
v
[17.3 Registros estructurados y syslog]
|
v
[17.4 Normalización]
|
v
[17.5 Herramientas en las que se puede confiar]
|
v
[17.7 Actividad práctica: normalizador]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX049]
Resultados de aprendizaje y conexión
Al terminar este capítulo, usted debería ser capaz de:
- configurar los sistemas para que produzcan registros que respondan a preguntas operativas y de seguridad;
- mantener los relojes sincronizados y registrar la hora en un formato único y sin ambigüedad;
- normalizar los registros de distintas fuentes en una estructura común;
- escribir y probar una herramienta pequeña para poder confiar en su salida, y saber cuándo usar en su lugar una ya existente.
La monitorización (capítulo 19), la resolución de problemas (capítulo 20) y la evaluación (capítulo 23) dependen de los registros. La mayoría de los fallos de registro no se deben a productos que faltan, sino a aspectos básicos que faltan: una fuente que nunca reenvió, una marca de tiempo sin zona horaria, un analizador que descarta en silencio las líneas que no entiende.
17.1 Qué registrar
Registre lo que necesitará para responder a las preguntas que le harán: quién inició sesión, desde dónde y con qué resultado; qué configuración cambió; qué aceptó, rechazó y puso en cuarentena el retransmisor, con recuentos; qué flujos cruzaron los límites de zona; cuándo se iniciaron, se detuvieron o fallaron los servicios. La guía del NIST sobre la gestión de registros cubre la planificación, la generación, la transmisión, el almacenamiento y el análisis de los registros (NIST SP 800-92). Reenvíe los registros fuera del equipo con prontitud (no puede confiarse en que un equipo comprometido o averiado conserve sus propios registros) y vigile que el reenvío continúe.
17.2 La hora
Ordenar los eventos entre sistemas exige una hora acordada. Sincronice cada equipo con una fuente de hora de confianza mediante NTP (RFC 5905); en LANTERN, los retransmisores toman la hora de dos servidores internos y la sirven a las estaciones. Registre las marcas de tiempo en un formato con desfase explícito, como los definidos en el RFC 3339, y conviértalas a UTC para el análisis. Vigile el propio desfase del reloj: un equipo cuya fuente de hora ha fallado deriva de forma lenta y silenciosa.
17.3 Registros estructurados y syslog
El protocolo syslog, RFC 5424, define un mensaje con prioridad (instalación y gravedad), versión, marca de tiempo, nombre de equipo, nombre de aplicación, ID de proceso, ID de mensaje, datos estructurados (parámetros clave–valor entre corchetes) y un mensaje de texto libre. Los datos estructurados son lo que hace que los registros puedan buscarse: src="192.0.2.44" user="root" puede contarse y filtrarse; la misma información enterrada en prosa debe adivinarse con patrones. Los dispositivos antiguos suelen enviar el formato BSD anterior, sin año ni zona horaria; registre esas fuentes como de menor calidad y conviértalas con cuidado.
17.4 Normalización
Un normalizador convierte el formato de cada fuente en un registro común: hora UTC, equipo, aplicación, gravedad y campos con nombre como src, user, dst, dport o action. Así, las reglas posteriores (capítulo 19) se escriben una sola vez. Un normalizador debe contar lo que no puede analizar e informar de ello: los descartes silenciosos son la forma en que un sistema de monitorización se queda ciego ante la única fuente que cambió de formato. La línea en formato BSD del retransmisor en la noche resuelta muestra por qué: sin un recuento de líneas no analizadas, simplemente habría desaparecido.
La línea del quiosco sin ninguna marca de tiempo es el otro caso: el normalizador debe marcarla, no ponerle la hora de llegada.
17.5 Herramientas en las que se puede confiar
Los implementadores escriben herramientas pequeñas constantemente. La confianza en la salida de una herramienta procede de: una declaración clara de lo que trata y lo que no; pruebas con casos erróneos y límite (capítulo 3); recuentos de entradas, salidas y rechazos que cuadren; una salida determinista para la misma entrada; y el control de versiones. Escriba su propia herramienta cuando la tarea sea pequeña y concreta; use una herramienta consolidada y mantenida cuando la tarea sea general (un recopilador syslog completo, una biblioteca TLS, una base de datos). No escriba nunca su propia criptografía: use la de la biblioteca estándar.
17.6 Ejemplo resuelto: los registros de una noche (sintético)
El Lab 17 analiza siete líneas del retransmisor, el cortafuegos, el historiador y el quiosco de las cocheras. Seis se analizan y una no: una línea en formato BSD de la propia aplicación del retransmisor, que revela que un componente de LANTERN nunca se configuró con el formato acordado. Una línea no tiene ninguna marca de tiempo (la del quiosco). La línea del historiador lleva +01:00; convertida a UTC son las 22:02:11, antes de los eventos de SSH, no después, como sugiere su hora local. Ordenada en UTC, la noche se lee así: error de cuota de disco del historiador a las 22:02, un inicio de sesión legítimo de un administrador a las 22:14, dos inicios de sesión fallidos como root desde una dirección externa a las 22:15 y un flujo Modbus de la red corporativa a PS-04 a las 22:16 desde la misma estación de trabajo usada para el inicio de sesión del administrador.
17.7 Actividad práctica: normalizador
Lab 17 (guárdelo como lab17.py y ejecútelo con python3 lab17.py):
# Lab 17 - normalizing RFC 5424-style syslog lines into JSON records (offline, standard library only)
# Synthetic log lines from the relay, historian and firewall. Simplified parser for teaching, not a full RFC 5424 implementation.
import json, re
from datetime import datetime, timezone
LINE = re.compile(r"<(?P<pri>\d{1,3})>1 (?P<ts>\S+) (?P<host>\S+) (?P<app>\S+) (?P<proc>\S+) (?P<msgid>\S+) (?P<sd>-|\[.*?\]) ?(?P<msg>.*)")
SEV = ["emerg", "alert", "crit", "err", "warning", "notice", "info", "debug"]
lines = [
'<86>1 2026-10-11T22:14:03.120Z rly-01 sshd 812 AUTH [meta src="10.40.3.7" user="b.lind"] Accepted publickey',
'<84>1 2026-10-11T22:15:40.004Z rly-01 sshd 813 AUTH [meta src="192.0.2.44" user="root"] Failed password',
'<84>1 2026-10-11T22:15:41.917Z rly-01 sshd 813 AUTH [meta src="192.0.2.44" user="root"] Failed password',
'<134>1 2026-10-11T22:16:00.000Z fw-hub filter - FLOW [flow src="10.40.3.7" dst="10.20.0.11" dport="502" act="allow"]',
'<131>1 2026-10-11T23:02:11+01:00 hist-01 histsvc 4410 DBERR - write failed: disk quota',
'Oct 11 22:17:00 rly-01 relay: legacy BSD-format line',
'<13>1 - kiosk-depot app - - - no timestamp supplied',
]
SDPARAM = re.compile(r'(\w+)="((?:[^"\\]|\\.)*)"')
out, bad = [], 0
for raw in lines:
m = LINE.fullmatch(raw)
if not m:
bad += 1; print("UNPARSED:", raw[:40]); continue
pri = int(m["pri"])
rec = {"ts": None if m["ts"] == "-" else m["ts"], "host": m["host"], "app": m["app"],
"facility": pri // 8, "severity": SEV[pri % 8], "msgid": m["msgid"], "msg": m["msg"]}
rec.update(dict(SDPARAM.findall(m["sd"])))
if rec["ts"]: # normalize every timestamp to UTC so sources can be ordered together
rec["ts_utc"] = datetime.fromisoformat(rec["ts"]).astimezone(timezone.utc).strftime("%Y-%m-%dT%H:%M:%S.%f")[:-3] + "Z"
out.append(rec)
for r in sorted(out, key=lambda r: r.get("ts_utc") or ""):
print(r.get("ts_utc"), r["host"], r["severity"], r.get("src", "-"), r["msg"] or r["msgid"])
print(json.dumps(out[1], sort_keys=True))
print(f"parsed {len(out)}, unparsed {bad}, missing timestamp {sum(r['ts'] is None for r in out)}")
Salida esperada (Python 3.13.5):
UNPARSED: Oct 11 22:17:00 rly-01 relay: legacy BSD
None kiosk-depot notice - no timestamp supplied
2026-10-11T22:02:11.000Z hist-01 err - write failed: disk quota
2026-10-11T22:14:03.120Z rly-01 info 10.40.3.7 Accepted publickey
2026-10-11T22:15:40.004Z rly-01 warning 192.0.2.44 Failed password
2026-10-11T22:15:41.917Z rly-01 warning 192.0.2.44 Failed password
2026-10-11T22:16:00.000Z fw-hub info 10.40.3.7 FLOW
{"app": "sshd", "facility": 10, "host": "rly-01", "msg": "Failed password", "msgid": "AUTH", "severity": "warning", "src": "192.0.2.44", "ts": "2026-10-11T22:15:40.004Z", "ts_utc": "2026-10-11T22:15:40.004Z", "user": "root"}
parsed 6, unparsed 1, missing timestamp 1
Compruebe dos cosas en la salida. Primero, el recuento de líneas no analizadas es 1, la línea en formato BSD de la aplicación del retransmisor, que es un fallo de configuración en un componente de LANTERN, no ruido. Segundo, la línea +01:00 del historiador, convertida a UTC, queda a las 22:02:11, antes del inicio de sesión del administrador de las 22:14 y de los inicios de sesión fallidos como root de las 22:15, y no después. Ordenado así, el flujo Modbus de la red corporativa a PS-04 de las 22:16 sigue a un inicio de sesión de administrador desde la misma estación de trabajo, que es la secuencia que la regla B marcará más adelante.
17.8 Errores frecuentes y límites
- Registrarlo todo en el nivel de depuración, lo que llena los discos (capítulo 1) y oculta los eventos que importan.
- Registros guardados solo en el equipo que los produjo.
- Marcas de tiempo sin zona horaria; mezclar la hora local y UTC en un mismo análisis.
- Analizadores que descartan las líneas no analizables sin contarlas.
- Suponer que el reenvío de registros sigue funcionando porque funcionaba el mes pasado.
- Construir una herramienta casera donde existe una mantenida, o criptografía casera en cualquier caso.
El analizador del laboratorio es una simplificación didáctica del RFC 5424: no trata todas las secuencias de escape ni varios elementos de datos estructurados. Informa de lo que no puede analizar, que es la propiedad que más importa.
Ejercicios — capítulo 17
EX049 — Corrija el formato del retransmisor. Objetivo: tratar una fuente que no se ajusta al formato. Entradas: la línea no analizada del Lab 17. Restricciones: dos opciones. Pasos: (1) describa la corrección en el origen (cambio de configuración en el retransmisor); (2) describa la adición de un segundo analizador para el formato BSD; (3) indique cuál haría primero y por qué, y qué no puede recuperar el analizador BSD. Evidencia esperada: media página. Rúbrica: 3 = corregir primero en el origen (es nuestro propio componente, bajo control de cambios) y el analizador BSD como alternativa para dispositivos de terceros; las líneas BSD carecen de año y de zona, así que el analizador debe suponerlos y marcar los registros como de menor calidad; 2 = una opción; 1 = «ignorarla»; 0 = nada.
EX050 — Orden de los eventos. Objetivo: ver el efecto de las zonas horarias. Entradas: la salida del Lab 17. Restricciones: ninguna. Pasos: (1) enumere los eventos en el orden de sus marcas de tiempo escritas, sin tener en cuenta los desfases; (2) enumérelos en orden UTC; (3) explique cómo un investigador que usara el primer orden malinterpretaría el evento del historiador. Evidencia esperada: dos listas y una explicación. Rúbrica: 3 = el evento del historiador aparece el último en el orden escrito (23:02) pero el primero en UTC (22:02); el investigador podría vincular erróneamente el error de cuota de disco con los inicios de sesión fallidos; 2 = listas correctas, explicación escasa; 1 = una lista; 0 = nada.
EX051 — Cuente lo que descarta. Objetivo: añadir una autocomprobación a la herramienta. Entradas: el Lab 17. Restricciones: solo la biblioteca estándar. Pasos: (1) añada una comprobación de que el número de líneas de entrada es igual a las analizadas más las no analizadas y termine con un error en caso contrario; (2) añada un recuento por equipo de las líneas no analizadas; (3) explique por qué un sistema de monitorización debería alertar cuando aumenta el recuento de líneas no analizadas de un equipo. Evidencia esperada: código, salida y explicación. Rúbrica: 3 = invariante aplicada, recuentos por equipo impresos (rly-01: 1), explicación de que un cambio de formato en una fuente deja ciegas las reglas en silencio; 2 = parcial; 1 = no ejecutado; 0 = nada.
Síntesis del capítulo
Registre lo que necesitará para responder, reenvíelo fuera del equipo y compruebe que el reenvío continúa. Sincronice los relojes, registre la hora con desfases explícitos y analice en UTC. Normalice las fuentes en una estructura única, cuente todo lo que no pueda analizar y construya herramientas pequeñas con pruebas e invariantes para que pueda confiarse en su salida; use herramientas consolidadas para los trabajos generales y no invente nunca criptografía.
Siga estudiando — capítulo 17 de 30
← Capítulo 16 · Índice de capítulos del curso · Capítulo 18 →
Continúe con la siguiente lección escrita.