11. Registro y monitoreo de firewalls: logs, métricas, alertas y trazabilidad

11.1 Introducción

Una regla de firewall sin monitoreo puede proteger parcialmente, pero deja poca visibilidad. Cuando ocurre un incidente, los logs permiten reconstruir conexiones, bloqueos, cambios, accesos administrativos y eventos de seguridad.

El monitoreo de firewalls cumple dos funciones principales: defensa y operación. Desde seguridad, ayuda a detectar comportamiento sospechoso. Desde operación, permite saber si el firewall está sano, si tiene recursos suficientes y si las reglas funcionan como se esperaba.

En este tema veremos qué registrar, qué métricas observar, cómo definir alertas útiles y cómo mantener trazabilidad para auditoría e investigación.

11.2 Qué es un log de firewall

Un log de firewall es un registro generado por el dispositivo cuando ocurre un evento relevante. Puede ser una conexión permitida, un intento bloqueado, una alerta IPS, un cambio de configuración, un inicio de sesión administrativo o una falla del sistema.

Un log útil debe responder preguntas básicas:

• Qué ocurrió.
• Cuándo ocurrió.
• Desde dónde vino el tráfico o la acción.
• Hacia dónde iba.
• Qué regla o política se aplicó.
• Qué acción tomó el firewall.
• Qué usuario, aplicación o zona estuvo involucrada si está disponible.

11.3 Tipos de logs

No todos los logs tienen el mismo propósito. Conviene separar tipos de eventos para analizarlos mejor.

11.4 Campos importantes en logs de tráfico

Los logs de tráfico deben contener información suficiente para reconstruir una conexión. Cuantos más campos útiles tenga el log, más fácil será investigar.

11.5 Qué eventos conviene registrar

Registrar todo puede generar demasiado volumen, costos y ruido. Registrar poco puede dejar huecos durante una investigación. La clave es definir qué eventos son importantes para seguridad y operación.

Eventos recomendados:

• Tráfico bloqueado entre zonas sensibles.
• Accesos desde internet hacia servicios publicados.
• Tráfico desde DMZ hacia red interna.
• Accesos administrativos al firewall.
• Cambios de reglas, objetos, NAT, VPN y perfiles de seguridad.
• Eventos de IPS, malware, URL o reputación.
• Conexiones VPN exitosas y fallidas.
• Failover, reinicios, caída de interfaces y errores de sincronización.

11.6 Logs de cambios administrativos

Los cambios administrativos deben registrarse con especial cuidado. Un cambio en una regla puede abrir acceso indebido o cortar un servicio crítico.

Un log administrativo debería indicar:

• Usuario que realizó el cambio.
• Fecha y hora.
• Objeto o regla modificada.
• Valor anterior y valor nuevo, si la plataforma lo permite.
• Origen desde donde se conectó el administrador.
• Resultado de la acción.
• Ticket o referencia de cambio, si existe integración.

11.7 Métricas operativas

Además de logs, un firewall debe generar métricas. Las métricas ayudan a evaluar salud, capacidad y rendimiento.

11.8 Alertas útiles

Una alerta debe ayudar a actuar. Si todo genera alerta, el equipo termina ignorando señales importantes. Las alertas deben priorizarse por impacto, urgencia y confianza.

Alertas recomendadas:

• Inicio de sesión administrativo fallido repetidamente.
• Cambio de regla crítica o política global.
• Failover o pérdida de sincronización HA.
• Caída de túnel VPN crítico.
• Tráfico bloqueado inusual desde una zona sensible.
• Evento IPS de alta severidad.
• Aumento anormal de sesiones o uso de ancho de banda.
• Licencia, firmas o almacenamiento de logs en estado crítico.

11.9 Severidad y priorización

No todas las alertas son iguales. La severidad ayuda a decidir qué se atiende primero.

11.10 Centralización de logs

Guardar logs solo en el firewall es riesgoso. Si el equipo falla, se reinicia, queda comprometido o se llena el almacenamiento, puede perderse evidencia importante.

La centralización permite enviar logs a un servidor syslog, una plataforma SIEM, un data lake o una herramienta de monitoreo. Esto mejora retención, búsqueda, correlación y protección de evidencias.

Beneficios:

• Mayor retención histórica.
• Correlación con endpoints, servidores, identidad y nube.
• Alertas centralizadas.
• Menor riesgo de pérdida de evidencia.
• Consultas más rápidas durante incidentes.
• Soporte para auditoría y cumplimiento.

11.11 SIEM y correlación

Un SIEM, o sistema de gestión de eventos e información de seguridad, permite recibir, normalizar, correlacionar y alertar sobre eventos de múltiples fuentes.

Un log de firewall puede ser más valioso cuando se combina con otros datos. Por ejemplo, una conexión bloqueada puede correlacionarse con un usuario, un endpoint, una alerta EDR o un evento de autenticación.

Ejemplo de correlación:

1. Un usuario inicia sesión desde una ubicación inusual.
2. Su equipo intenta acceder a puertos administrativos.
3. El firewall bloquea tráfico hacia servidores críticos.
4. El EDR alerta sobre comportamiento sospechoso.
5. El SIEM agrupa eventos y eleva severidad.

11.12 Retención de logs

La retención define cuánto tiempo se conservan los logs. Debe equilibrar necesidades de investigación, cumplimiento, costos y volumen.

Factores para definir retención:

• Requisitos legales o regulatorios.
• Tiempo promedio de detección de incidentes.
• Capacidad de almacenamiento.
• Valor forense de los eventos.
• Criticidad de la zona o servicio.
• Necesidad de auditoría histórica.

Los logs críticos, como cambios administrativos o accesos a servicios sensibles, suelen requerir mayor retención que eventos de bajo valor.

11.13 Sincronización horaria

La hora correcta es esencial. Si cada sistema tiene una hora distinta, correlacionar eventos se vuelve difícil o imposible.

Los firewalls deben usar NTP o un mecanismo equivalente para mantener hora sincronizada. También conviene definir zona horaria, formato de tiempo y consistencia entre plataformas.

11.14 Trazabilidad

La trazabilidad es la capacidad de reconstruir qué ocurrió y quién estuvo involucrado. En firewalls, implica poder seguir una conexión, una alerta o un cambio administrativo desde su origen hasta su resultado.

Una buena trazabilidad requiere:

• Logs completos y centralizados.
• Usuarios administrativos individuales, no compartidos.
• Sincronización horaria.
• Integración con identidad cuando sea posible.
• Registro de cambios antes y después.
• Conservación suficiente de evidencias.

11.15 Ejemplo práctico: intento de acceso bloqueado

Supongamos que el firewall registra muchos bloqueos desde una estación de trabajo hacia el puerto 445/TCP de varios servidores.

Lectura defensiva:

• El puerto 445/TCP suele asociarse a SMB.
• El origen es una estación de usuario.
• Los destinos son múltiples servidores.
• La regla de segmentación bloqueó el tráfico.
• El patrón puede indicar escaneo, malware o herramienta no autorizada.

Acciones recomendadas: revisar el endpoint, correlacionar con EDR, verificar usuario autenticado, buscar otros intentos similares y confirmar si existe una necesidad legítima.

11.16 Ejemplo práctico: cambio sospechoso

Supongamos que aparece una regla nueva permitiendo cualquier origen hacia una red de servidores por cualquier puerto. El log administrativo muestra que fue creada fuera del horario habitual.

Preguntas inmediatas:

• ¿Quién creó la regla?
• ¿Desde qué dirección se conectó?
• ¿Existe ticket o aprobación?
• ¿La cuenta tenía MFA?
• ¿La regla recibió tráfico?
• ¿Se modificaron otros objetos o políticas?

Este ejemplo muestra por qué los logs administrativos son tan importantes como los logs de tráfico.

11.17 Tableros de monitoreo

Un tablero ayuda a visualizar estado y actividad. No reemplaza alertas ni análisis, pero permite observar tendencias.

Elementos útiles en un tablero:

• Estado de HA y enlaces.
• Uso de CPU, memoria, sesiones y ancho de banda.
• Principales reglas con más tráfico.
• Principales fuentes bloqueadas.
• Eventos IPS por severidad.
• VPN activas y fallidas.
• Cambios administrativos recientes.
• Top destinos salientes por volumen.

11.18 Errores frecuentes

• No registrar cambios administrativos: dificulta saber quién modificó la política.
• Guardar logs solo localmente: aumenta el riesgo de pérdida de evidencia.
• Alertar por todo: genera fatiga y reduce atención a eventos importantes.
• No sincronizar hora: complica correlación e investigación.
• No revisar logs permitidos: el tráfico autorizado también puede ser malicioso.
• Retener logs por muy poco tiempo: impide investigar incidentes descubiertos tarde.
• No monitorear salud del equipo: un firewall saturado puede fallar como control defensivo.

11.19 Lista de verificación inicial

• Activar logs de tráfico en reglas críticas.
• Registrar cambios administrativos y accesos al firewall.
• Enviar logs a una plataforma central.
• Sincronizar hora mediante NTP.
• Definir retención según riesgo y cumplimiento.
• Crear alertas para eventos críticos, no para todo.
• Monitorear CPU, memoria, sesiones, interfaces, HA y VPN.
• Correlacionar logs de firewall con identidad, servidores y endpoints.
• Revisar periódicamente reglas con mucho tráfico o muchos bloqueos.
• Probar que las alertas llegan a responsables reales.

11.20 Ideas clave para recordar

• Los logs permiten investigar, auditar y mejorar controles.
• No alcanza con bloquear: hay que saber qué se bloqueó y por qué.
• Las métricas operativas muestran si el firewall está sano y con capacidad suficiente.
• Las alertas deben ser accionables y priorizadas.
• Centralizar logs reduce pérdida de evidencia y mejora correlación.
• La trazabilidad depende de logs completos, hora sincronizada y cuentas individuales.

11.21 Conclusión

El registro y monitoreo de firewalls transforma decisiones de filtrado en evidencia útil. Sin logs, métricas y alertas, la organización puede tener reglas correctas pero poca capacidad para detectar, investigar y responder.

En el próximo tema iniciaremos el bloque de IDS/IPS con una introducción a sus diferencias, ubicación, capacidades y limitaciones.