Skip to content

Syslog operations — guía operativa profunda

Lee en tu idioma: English · Português · Español

Estado del alcance (post-congelación de alcance 2026-05-10) — Ver ARCHITECTURE.md para los 37 MÓDULOs canónicos + 7 Test Kinds + arquitectura de safety DOM/CPOS/PIE-PA. ADRs 0014, 0019-0025 cubren adiciones post-Freeze.

Audiencia: Operadores que ejecutan TLSStress.Art y necesitan investigar fallos de ejecuciones, correlacionar anomalías de métricas con eventos de dispositivos o extender el pipeline de syslog.

Este documento complementa SYSLOG_CORRELATION.es.md (introducción + setup). Lee aquel primero. Este archivo es la referencia operativa profunda — recetario de queries, patrones avanzados específicos por fabricante, presupuestos de performance, modelo de seguridad, recetas de troubleshooting.

Prerrequisito obligatorio — syslog solo sobre OOBI

El tráfico de syslog desde los elementos del laboratorio (Nexus 9000, NGFW DUT, hosts UCS) DEBE viajar sobre la red de gestión OOBI (out-of-band) — nunca sobre las VLANs del data plane.

Por qué: - El data plane lleva el tráfico de prueba (Synthetic personas 10.1.0.0/16, Cloned personas 10.2.0.0/16, browser-engine agents 172.16.0.0/16, synthetic-load agents 172.17.0.0/16). Paquetes de syslog en esas VLANs serían medidos POR el test bed como si fueran tráfico de prueba — invalidando las métricas por ciclo. - La subnet OOBI (default 192.168.90.0/24, VLAN 99) está reservada por diseño para tráfico de gestión — scrapes de Prometheus, SNMP, kubectl y syslog viven aquí. - Todos los elementos del laboratorio tienen sus IPs de gestión en OOBI; sus interfaces de data plane están downstream (hacia el NGFW desde el lado de las personas, hacia los agentes desde el lado del test-bed).

Enforcement: - Dos recursos NetworkPolicy (`syslog-oobi-only` + `syslog-deny-data-plane`) aplican esto a nivel de cluster — ver platform/observability/syslog-network-policy.yaml - El primero permite ingress de syslog solo desde el CIDR OOBI (192.168.90.0/24) - El segundo niega explícitamente ingress de syslog desde los CIDRs del data plane - Belt-and-suspenders por diseño — si una policy se debilita accidentalmente, la otra aún detiene la contaminación

Obligaciones del operador: 1. Al configurar el destino syslog de un dispositivo, SIEMPRE usa la dirección IP OOBI del destino (no su IP del data plane si la tiene) 2. Al configurar source-interface en dispositivos Cisco, SIEMPRE especifica mgmt0 / la interface de gestión 3. Periódicamente ejecuta una query de verificación (en el cookbook abajo) para confirmar que ningún syslog fuera de la red haya pasado 4. Si el laboratorio usa un CIDR OOBI no estándar, sobrescribe vía un overlay kustomize — no edites el manifiesto base

Anatomía del pipeline

                   OOBI network only (192.168.90.0/24)
   ┌────────────────────────────────────────────────────────────┐
   │                                                            │
┌──┴──────────┐  UDP/514   ┌─────────────────────┐             │
│ Nexus 9000  ├───────────▶│                     │             │
│ mgmt0       │            │  Promtail           │             │
└─────────────┘            │  syslog receiver    │             │
                           │                     │  Loki API   │
┌─────────────┐  UDP/514   │  - RFC 3164 + 5424  ├──────────▶┌─┴─────┐
│ NGFW DUT    ├───────────▶│  - port 1514 (pod)  │           │ Loki  │
│ mgmt iface  │  TCP/514   │  - port 30514 (NP)  │           └───┬───┘
└─────────────┘            │  - relabel pipeline │               │
                           │                     │           ┌───▼───┐
┌─────────────┐  UDP/514   │  Drops everything   │           │Grafana│
│ UCS host    ├───────────▶│  not from OOBI      │           └───────┘
│ rsyslog     │            │  (NetworkPolicy)    │
└─────────────┘            └─────────────────────┘

Recetario de queries Loki

Encuentra todos los eventos de un dispositivo, últimos 30 minutos

{app="tlsstress", device_hostname="nexus-1.lab.example.com"}

Encuentra eventos warning+ en todos los dispositivos NGFW en la última hora

{app="tlsstress", device_type="ngfw", severity=~"warning|err|crit|alert|emerg"}

Encuentra eventos relacionados con decryption en el NGFW (estilo Cisco ASA)

{app="tlsstress", device_type="ngfw"} |~ "(?i)(decrypt|ssl|tls)"

Encuentra eventos relacionados con decryption en Palo Alto

{app="tlsstress", device_type="ngfw"} | json | subtype="decryption"

Encuentra port flaps en Cisco Nexus

{app="tlsstress", device_type="nexus"}
  |~ "(?i)(port.*(flap|down|up))|interface.*state.*change"

Cuenta eventos por minuto por dispositivo, ordenado descendente

sum by (device_hostname) (
  rate({app="tlsstress"}[1m])
)

Encuentra eventos de kernel UCS (OOM, NIC reset, segfault)

{app="tlsstress", device_type="ucs", device_app="kernel"}
  |~ "(out of memory|oom-killer|segfault|nic.*reset|carrier (lost|down))"

Correlaciona con métrica — muestra logs de NGFW solo cuando latencia p99 > 500 ms

Esta es una query de dos stores — el lado de la métrica filtra cuándo mirar, el lado de los logs devuelve los eventos:

{app="tlsstress", device_type="ngfw", severity=~"warning|err|crit"}
Abre esta query en Grafana Explore split-pane junto a: 
histogram_quantile(0.99, sum by (le) (rate(web_agent_request_duration_seconds_bucket[1m])))
Usa el selector de time range para hacer zoom en el spike de latencia. La query de logs se estrechará a la misma ventana.

Detección de tráfico fuera de OOBI (vigilancia del operador)

Si todo está configurado correctamente, esta query devuelve 0 filas. Filas distintas de cero indican que un dispositivo está enviando syslog desde una interface no-OOBI — típicamente porque source-interface no fue seteado:

{app="tlsstress"} | json | __syslog_message_remote_addr !~ "192\\.168\\.90\\."

Si ves hits, encuentra el dispositivo infractor y ejecuta: - Cisco: show logging | include source → confirma source-interface mgmt0 seteado - Palo Alto: GUI → Device → Setup → Services → "Service Route Configuration" — Syslog debe usar la interface de gestión - Fortinet: config log syslogd setting → set source-ip <oobi-ip> confirmado

Deep-dive por fabricante — qué esperar en los logs

Cisco Nexus 9000 (NX-OS)

Tipos de mensaje comunes a reconocer:

Pattern Severity Significado
%ETHPORT-5-IF_DOWN_* notice Un puerto cayó. Busca IF_DOWN_LINK_FAILURE (cable / NIC) vs IF_DOWN_ADMIN_DOWN (iniciado por operador)
%ETH_PORT_CHANNEL-5-PORT_* notice Miembro de port-channel up/down. Subida en medio de la ejecución = potencial evento de redistribución de tráfico
%MAC-3-MAC_FLAP_DETECTED error MAC se movió entre puertos — típicamente indica un loop o un host con múltiples uplinks. Test bed degradado hasta resolver
%MTS_NOTIFICATION_AGENT-3-* error Eventos del message-bus interno de NX-OS; raros pero indican estrés de plataforma
%QUEUING-2-DROP critical Cola QoS dropeando tráfico. Ejecución es inválida para cualquier claim de throughput
%STM-2-LIMIT_REACHED critical Un límite de plataforma (route, MAC, ARP) alcanzado. Resetea el cluster si persiste

Logging level NX-OS recomendado: 5 (notification) para categorías generales, 4 (warning) para mts y monitor. Ver SYSLOG_CORRELATION.es.md para el snippet exacto de configuración.

Cisco FTD / ASA / Firepower

Pattern Severity Significado
%ASA-3-302014 error Connection teardown — para un test bed TLS, observa el campo Reason:. tcp reset by app-id frecuentemente significa intervención del decrypt-engine
%ASA-6-725001 info TLS handshake iniciado
%ASA-6-725002 info TLS handshake completado exitosamente
%ASA-6-725003 info Sesión TLS reanudada (session ticket / ID hit) — interesante para planes que demandan handshakes frescos
%ASA-3-725007 error TLS handshake falló. Cross-check con el campo Reason:
%ASA-6-302013 info TCP connection construida — útil para análisis de connection-rate
%ASA-4-411001 warning Cambio de estado de interface

Clases de logging recomendadas: crypto 5, ssl 5, connection 4. Rates más altos en connection (severity 6) generan demasiados eventos para que el laboratorio los ingiera cómodamente.

Palo Alto (PAN-OS)

Logs PAN-OS son estructurados (CSV-ish) por defecto; el receiver Loki parsea el wrapping RFC 5424 pero el body permanece comma-separated. Usa | pattern o | logfmt en Loki para extraer campos.

Señal de campo Significado
subtype="decryption" + category="ssl-protocol-error" Decrypt falló — root cause en el campo info (típicamente cipher mismatch, versión no soportada, cert chain)
subtype="decryption" + category="successful" Decrypt exitoso — útil para confirmar que la policy realmente se dispara
subtype="ssl-error" Específicamente error del lado TLS desde la perspectiva del firewall
subtype="threat" + category="vulnerability" IPS hit durante la prueba — puede interrumpir conexiones legítimamente

Para el test bed TLS, los subtypes más accionables son decryption (siempre) y traffic para eventos action=block.

Fortinet (FortiOS)

FortiOS usa pares clave-valor. El parser logfmt de Loki extrae estos nativamente.

Pattern Severity Significado
logid=0103040045 warning Error de SSL handshake — campo reason= da detalle
logid=0103043200 info Sesión SSL establecida
logid=0103040040 error Sesión relacionada con TLS terminó anormalmente
logid=0419016384 warning IPS engine marcó tráfico

Filtro FortiOS recomendado: severity notification y set ssl enable (específicamente forwardea eventos de SSL-policy).

Host Ubuntu UCS (rsyslog)

Las señales host-level más útiles durante una prueba:

device_app Qué observar
kernel OOM-killer, segfault, errores de NIC, throttling — busca severity=err+
chronyd Eventos de clock-sync — correlaciona con thresholds de TIME_SYNC.es.md
kubelet Pod evictions, fallos de image pull durante la ejecución
containerd Restarts de container, errores de OCI runtime
iptables Drops de paquete en el firewall del host (poco común pero un camino rápido de diagnóstico)

Performance + retention

Presupuesto de event-rate

El receiver Promtail está configurado sin rate-limit por defecto. Capacidad empírica en un node K3s estándar:

Configuration Sustainable events/sec
Single-node, default resource limits (200m CPU / 256 Mi mem) ~5,000
Single-node, bumped to 1 CPU / 1 Gi ~25,000
Multi-node with Promtail per node ~5,000 per node

Para una sola ejecución de 30 min en un test bed totalmente cargado, espera ~50.000–200.000 eventos totales. Dentro del presupuesto para la config por defecto.

Si events/sec sostenido excede el presupuesto, Promtail aplica backpressure y el cliente syslog del dispositivo o hace buffer (Cisco IOS), dropea (UDP) o sostiene conexiones (TCP). Drops UDP son silenciosos — overflow TCP loguea un error en el dispositivo.

Retention de Loki

Retention por defecto en este stack: 15 días. Configura vía los Loki Helm values cuando montes el stack de observabilidad.

Para ejecuciones cuyos resultados necesitan retention permanente más allá de 15 días, dos opciones: 1. Exporta logs al final de la ejecución vía la Loki API → archiva a tu propio object storage 2. Espera el Test Run Report Phase 4 (planificado) — extractos de log seleccionados serán embebidos en el PDF firmado para registro forense permanente

Sizing de storage

Tamaño promedio de línea de log ~250 bytes incluyendo labels. 50.000 eventos/ejecución × 250 bytes ≈ 12 MB/ejecución. Con retention de 15 días y ~5 ejecuciones/día, espera ~900 MB / 15 días. El chunked storage de Loki comprime esto aún más (típicamente 4-6× compression).

Modelo de seguridad

Lo que el syslog stack HACE

  • Recibe syslog sobre UDP/TCP 514 solo desde la red OOBI
  • Forwardea a Loki con labels estructurados para query
  • Indexa labels (pequeño, rápido); NO indexa bodies completos de mensaje (grande, lento)
  • Carga los mismos labels de license/audience que Prometheus, así que tooling downstream license-aware ve la misma proveniencia

Lo que el syslog stack NO hace

  • NO autentica al sender (UDP y TCP unauthenticated). Cualquiera en la red OOBI puede enviar eventos. Mitigación: NetworkPolicy restringe a OOBI; la OOBI en sí debe estar controlada por acceso a nivel de switch
  • NO encripta syslog en tránsito. RFC 5425 (syslog-over-TLS) es soportado por Promtail pero no habilitado por defecto — el setup requiere certs compartidos. Si tu compliance demanda encryption, abre un issue y priorizaremos la config RFC 5425
  • NO redacta contenido sensible. Muchos dispositivos loguean detalles de sesión, ARP tables, etc. que no son estrictamente secretos pero pueden exceder tu policy de operator audience. Audita antes de exportar datos de Loki fuera del laboratorio
  • NO se integra con un SIEM. Esta es una capa de TEST FORENSICS, no de security operations

Threat model

Threat Mitigación
Atacante en OOBI envía syslog falso Acceso a OOBI es la superficie de ataque — fuera del scope de este producto
Dispositivo comprometido envía syslog malicioso NetworkPolicy + dashboards basados en label limitan el blast radius al log-store; sin exec desde el contenido del log
Datos sensibles logueados accidentalmente Problema del lado del operador — revisa las clases de logging del dispositivo en SYSLOG_CORRELATION.es.md antes de habilitar
Origen fuera de OOBI bypassa NetworkPolicy NetworkPolicy es enforzada por el CNI; si tu CNI no implementa NetworkPolicy (algunos CNIs bare-metal), prueba con kubectl describe networkpolicy y confirma que la policy reporta como enforced

Audit trail

Cada evento syslog en Loki carga: - El hostname del dispositivo originador (campo RFC 5424, validado contra el estado de NTP-sync del dispositivo en el momento de la recepción — pero solo de forma laxa) - El receive time (lado Promtail, seteado desde el clock del cluster) - Los labels incluyendo app=tlsstress, license, audience

Si el clock del origen está mal por más de unos segundos (según TIME_SYNC.es.md), los timestamps de los eventos son engañosos. Cruza las alertas de time-sync antes de tratar los timestamps de syslog como forenses.

Runbooks operativos

"Veo un spike de p99 a las 14:32"

1. Open: TLSStress.Art — Syslog Correlation (Lab Elements) dashboard
2. Set time range to 14:30–14:35
3. Look at the side-by-side panel — note any log volume spike
4. Click into the live syslog stream panel
5. Look for warning+ events from any device in that window
6. Drill into the per-device deep-dive panel for the noisy device
7. If NGFW shows decryption errors → check TLS Decrypt Probe state
   (TLSStress.Art — TLS Decrypt Mode dashboard)
8. If Nexus shows port flaps → check Topology Correlation dashboard
9. If UCS shows kernel/OOM → check Test-Bed Infrastructure Health

"Quiero confirmar que ningún syslog está fugando fuera de OOBI"

1. Run the off-OOBI detection query in Grafana Explore (cookbook above)
2. If any rows return:
   a. Identify the device by __syslog_message_hostname
   b. Run "show logging | include source" (Cisco) or equivalent
   c. Reconfigure source-interface to mgmt0
3. Re-run the query — should return 0 rows

"Promtail está dropeando eventos"

Síntomas: spikes en métricas promtail_syslog_target_* O query Loki devuelve menos eventos que lo esperado.

1. kubectl logs -n observability deploy/promtail-syslog --tail=100
   Look for: "syslog target full" / "channel buffer full"
2. If buffer full:
   - Increase Promtail resource limits (default 200m CPU / 256Mi mem)
   - Or shard: run Promtail per-node with stable hash on device_hostname
3. If a specific device floods:
   - Check the device's logging level (lower from 7=debug to 5=notice)
   - Add a `drop` action in the relabel pipeline for that hostname

"Query Loki está lenta"

1. Query MUST start with a label matcher (e.g. {app="tlsstress"})
2. Avoid free-text grep on multi-day ranges — use device_type/severity to narrow
3. Use logfmt/json parsers AFTER label filtering, not before
4. Time range > 7 days requires the chunk-cache to be hot;
   first-query-of-the-day is slow, subsequent queries are fast

Mejoras futuras

Rastreadas para iteración futura:

  • RFC 5425 syslog-over-TLS (encryption) — generación de cert controlada por operador + chrony del cert con cert-manager
  • Syslog autenticado vía shared key (Cisco IOS soporta esto vía logging server <ip> mac) — combina con el modelo de relay
  • Redacción selectiva en el ingest (ej.: enmascarar strings con forma de tarjeta de crédito antes de que lleguen a Loki)
  • Discovery LLDP/CDP de neighbors → auto-generar labels device_role (planificado, módulo separado)
  • Test Run Report Phase 4 — embeber extractos de log seleccionados en el PDF firmado

Relacionados