Skip to content

Correlación de syslog — TLSStress.Art

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. Esta es la vista del operador del laboratorio desde la perspectiva del propio laboratorio — lo que el Cisco Nexus 9000, el NGFW DUT y los hosts UCS dicen que ocurrió durante una ejecución, correlacionado con las métricas que el Dashboard ya muestra.

Sin esto: ves un pico de p99 a las 14:32 y tienes que hacer SSH en cada dispositivo para averiguar por qué. Con esto: abres un único dashboard de Grafana, ves el pico, y los eventos de log correspondientes de los tres dispositivos aparecen lado a lado.

Lo que esto NO es

No es un SIEM en el sentido de monitoreo de seguridad. Es una capa forense de ejecución de pruebas enfocada en correlación operacional. La retención de logs es corta (15 días por defecto), las consultas son específicas de la ejecución, y el ACL es el mismo ACL del Dashboard — no un flujo de trabajo endurecido de operaciones de seguridad.

Para monitoreo de seguridad real, su organización debe operar un SIEM separado (Splunk, Elastic, Cisco SecureX, etc.). Este stack no reemplaza eso.

Arquitectura

   ┌──────────────┐      UDP/TCP 514        ┌─────────────┐
   │  Cisco       │────────────────────────→│             │
   │  Nexus 9000  │  RFC 5424 syslog        │             │
   └──────────────┘                          │             │
                                             │             │
   ┌──────────────┐      UDP/TCP 514        │  Promtail   │   ┌──────┐
   │  NGFW DUT    │────────────────────────→│  syslog     │──→│ Loki │
   │  FTD/ASA/    │  RFC 3164 + 5424        │  receiver   │   └──────┘
   │  Palo/Forti  │                          │  Deployment │      │
   └──────────────┘                          │  in obs ns  │      │
                                             │             │      ▼
   ┌──────────────┐      UDP/TCP 514        │             │  ┌─────────┐
   │  UCS host    │────────────────────────→│             │  │ Grafana │
   │  rsyslog     │                          │             │  │ Explore │
   │  (Ubuntu)    │                          └─────────────┘  └─────────┘
   └──────────────┘                                                 │
                                                                    ▼
                                                          ┌────────────────────┐
                                                          │ TLSStress.Art —    │
                                                          │ Syslog Correlation │
                                                          │ dashboard          │
                                                          └────────────────────┘

Labels de Loki emitidos en cada evento:

Label Origen Valores de ejemplo
app external_label de Promtail tlsstress (siempre)
cluster external_label de Promtail web-agent-cluster
device_type Regex sobre el hostname nexus, ngfw, ucs
device_role Derivado de device_type switch, firewall, host
device_hostname Campo hostname de RFC 5424 nexus-1.lab.example.com
device_app Campo APP-NAME de RFC 5424 mts, eth_port_chan_mgr, kernel, decryptd
severity Severidad de RFC 5424 info, notice, warning, err, crit, alert, emerg
facility Facility de RFC 5424 local0, daemon, kern, etc.
channel Listener de Promtail syslog-udp, syslog-tcp

Apuntando cada dispositivo al endpoint de syslog

⚠️ Obligatorio: el syslog debe viajar solo por OOBI — nunca por el plano de datos. Esto se aplica con dos NetworkPolicy a nivel del cluster (syslog-oobi-only permite ingreso desde la CIDR 192.168.90.0/24; syslog-deny-data-plane deniega ingreso desde las CIDRs de personas/agentes). Enviar syslog por una VLAN del plano de datos permitiría que sea medido POR el test bed como si fuera tráfico de prueba, contaminando las métricas por ciclo. La justificación completa y las obligaciones del operador están en SYSLOG_OPERATIONS.es.md.

El Service de Promtail expone el NodePort 30514 (mapeado internamente al puerto syslog conocido 514). Los dispositivos envían a <any-cluster-node-ip>:30514 por UDP o TCP. Elija la IP de gestión OOBI de uno de los hosts UCS.

El puerto syslog estándar es 514. Usamos NodePort 30514 porque Kubernetes normalmente no permite puertos privilegiados por debajo de 1024. Si su política de operador prefiere el puerto 514 desde el lado del dispositivo, configure una regla NAT de firewall en el host UCS: <ucs-oobi-ip>:514 → <ucs-oobi-ip>:30514.

Cisco Nexus 9000 (NX-OS)

configure terminal

! Use RFC 5424 — modern, structured, easier for Promtail to parse
logging timestamp microseconds
logging origin-id hostname

! Forward to the Promtail receiver
logging server <ucs-mgmt-ip> 5 use-vrf management transport udp port 30514
! 5 = severity threshold (notifications and worse). Adjust to taste:
!   0 emergencies | 1 alerts | 2 critical | 3 errors
!   4 warnings   | 5 notifications | 6 informational | 7 debugging

! Logging buffer (so the Nexus retains last events even if syslog is down)
logging logfile messages 6 size 1048576

! Important categories for an NGFW test bed:
logging level mts 5
logging level monitor 5
logging level eth_port_channel_mgr 5
logging level pixm 5      ! port channel manager
logging level fcoe_mgr 4

end
write memory
show logging server

Verifique en el Nexus que el buffer de mensajes se está drenando: 

show logging last 20

Cisco FTD / ASA / Firepower

Para sintaxis ASA (FTD vía FlexConfig funciona de forma similar):

configure terminal
logging enable
logging timestamp
logging buffer-size 1048576
logging buffered notifications

! Forward
logging trap notifications
logging host <data-iface> <ucs-mgmt-ip> 17/30514
! 17 = UDP. Use 6/30514 for TCP.

! For decryption diagnostics specifically (the events we care about
! most for THIS test bed):
logging class crypto 5
logging class ssl 5
logging class connection 4

end
write memory
show logging

Para FTD vía FMC: navegue a Devices → Platform Settings → Syslog, configure: - Server: <ucs-mgmt-ip> UDP/30514 - Severity: notifications - Categories: connection, crypto, SSL, intrusion

Palo Alto (PAN-OS)

! Enter configure mode
configure

! Define syslog server profile
set shared log-settings syslog tlsstress server tlsstress \
    transport UDP port 30514 server <ucs-mgmt-ip> facility LOG_LOCAL3 format BSD

! Forward system log (device events, not traffic)
set shared log-settings system match-list tlsstress-system filter "All Logs" \
    send-syslog [ tlsstress ]

! Forward decryption / SSL log specifically
set shared log-settings system match-list tlsstress-decrypt filter "(subtype eq decryption)" \
    send-syslog [ tlsstress ]

commit

Fortinet (FortiOS)

config log syslogd setting
    set status enable
    set server "<ucs-mgmt-ip>"
    set port 30514
    set mode udp
    set facility local3
    set source-ip "<ngfw-mgmt-ip>"
    set format default
end

config log syslogd filter
    set severity notification
    set ssl enable
end

Host UCS (Ubuntu rsyslog)

/etc/rsyslog.d/50-tlsstress.conf:

# Forward auth + kernel + system messages to the TLSStress.Art syslog endpoint
*.notice;auth.info @<ucs-mgmt-ip>:30514
# Use double-@ for TCP delivery (more reliable for high-volume logs):
# *.notice;auth.info @@<ucs-mgmt-ip>:30514

Luego: 

sudo systemctl restart rsyslog
sudo logger -t tlsstress-test "syslog forwarding test from $(hostname)"

Abra Grafana Explore, consulte {device_hostname="<your-host>"} — el mensaje de prueba debe aparecer en menos de 5 segundos.

Verificando el pipeline de extremo a extremo

Después de configurar al menos un dispositivo:

# 1. Confirm the Promtail pod is up:
kubectl get pods -n observability -l app=promtail-syslog
# expect: 1 Running

# 2. Confirm the Service is reachable from the device side:
kubectl get svc -n observability promtail-syslog
# note the NodePort — should be 30514

# 3. From the device (or a UCS host), send a test message:
logger -n <ucs-mgmt-ip> -P 30514 -d -t tlsstress-test "smoke from $(hostname)"

# 4. Tail Loki via the dashboard or via Grafana Explore:
#    Query: {app="tlsstress", device_hostname=~".+"}
# expect: the test message appears within 5 seconds.

El dashboard de Grafana

TLSStress.Art — Syslog Correlation (Lab Elements) se incluye con el overlay de kustomize. Tiene:

  1. Resumen de alto nivel — eventos por minuto por tipo de dispositivo; volumen de logs por host; distribución de severidad (solo warning+)
  2. Métricas + logs lado a lado — gráfico de líneas del p99 de latencia de agentes a la izquierda, stream en vivo de syslog (warning+) a la derecha. Los picos de latencia se alinean con ráfagas en el stream de logs.
  3. Análisis profundos por dispositivo — paneles separados para eventos de Nexus (warning+), eventos del NGFW (info+ para capturar coincidencias de decrypt-rule y logs de connection deny), kernel/systemd de UCS (warning+).

Use los filtros device_type y severity en la parte superior del dashboard para acotar el foco durante una ejecución.

Patrones comunes a observar durante una ejecución

Síntoma Qué buscar en los logs
Handshakes TLS fallando intermitentemente Eventos decryption del NGFW con severidad notice+; busque "no decryption profile matched"
Pod de persona en CrashLoopBackOff UCS device_app=kernel + severity=err+; busque OOM-killer, NIC reset, segfault
Pico de p99 sin error del agente Advertencias device_app=eth_port_chan_mgr del Nexus (port flap, MAC move); alertas de queue-depth de QoS del Nexus
TLS Decrypt Probe dice "off" NGFW device_app=decryptd (o equivalente del fabricante); busque "decryption disabled on interface"
La ejecución aborta con alerta de fleet readiness Contraste con los logs de connection-deny del NGFW en el mismo timestamp

Retención y almacenamiento

La retención por defecto de Loki en este stack es de 15 días. Las evidencias específicas de la ejecución más allá de eso necesitan exportarse a un almacenamiento de auditoría separado. El Test Run Report (Fase 4 futura) incrustará extractos de logs seleccionados como parte del PDF firmado para registro forense permanente.

Comportamiento en air-gap

En una instalación air-gapped, el reenvío de syslog funciona internamente al laboratorio — Promtail, Loki y Grafana corren dentro del cluster. Sin dependencia externa. Lo único que el operador debe verificar es que UDP/TCP 514 desde dispositivo-a-Promtail esté desbloqueado por cualquier ACL interno de firewall.

Si el laboratorio tiene un firewall Cisco entre la red de gestión y el UCS, asegure que el ACL permita tráfico hacia <ucs-mgmt-ip>:30514 (o 514 si usa NAT redirect).

Relacionados