Skip to content

Respuesta a ControlCase — Logsinks de Firewall y Load Balancer

CampoValor
SolicitanteElswick Lai — ControlCase Cumplimiento y Ciberseguridad
Fecha2026-05-25
TipoReceptores de logs para DO Firewall (5514) y DO Load Balancer (5515)
EstadoRESUELTO — Configuración aplicada y verificada end-to-end

Resumen ejecutivo: Se desplegaron dos Fluent Bit DaemonSets adicionales que envían logs al collector en los puertos solicitados: 5514 para eventos de firewall (kernel/netfilter desde journald) y 5515 para access logs del Load Balancer (capturados desde el pod Kong que recibe todo el tráfico del DO LB).


1. Resumen de los 4 Logsinks PCI

#OrigenPuertoMecanismoEstado
1PostgreSQL (DB)6514DO Managed logsink (nativo)Activo
2Kubernetes (pods)5141Fluent Bit DaemonSetActivo
3Firewall (kernel/netfilter)5514Fluent Bit DaemonSet + journaldActivo
4Load Balancer (Kong access logs)5515Fluent Bit DaemonSetActivo

Importante: DigitalOcean no expone API nativa de logs para Cloud Firewalls ni Load Balancers. Por eso usamos Fluent Bit DaemonSets que capturan el equivalente desde los nodos K8s.


2. Puerto 5514 — Firewall Logs

Origen de los logs

DOKS no genera logs de Cloud Firewall, pero los nodos sí generan eventos de:

  • Kernel (netfilter, iptables, network policies)
  • containerd (sandbox network setup/teardown)
  • Cilium (NetworkPolicy enforcement)

Estos eventos se leen desde journald (DOKS no usa archivos /var/log/kern.log).

Configuración Fluent Bit (5514)

yaml
[INPUT]
    Name              systemd
    Tag               firewall.*
    Path              /var/log/journal
    Read_From_Tail    On
    Strip_Underscores On

[OUTPUT]
    Name             syslog
    Match            *
    Host             10.100.0.10
    Port             5514
    Mode             tcp
    Syslog_Format    rfc5424
    Syslog_Hostname_Key  HOSTNAME
    Syslog_Appname_Key   SYSTEMD_UNIT
    Syslog_Message_Key   MESSAGE

Estado del DaemonSet

NAME                        READY   STATUS    NODE
fluent-bit-firewall-2fq9w   1/1     Running   app-38qmcg
fluent-bit-firewall-75vtx   1/1     Running   app-38qmcw
fluent-bit-firewall-knfsn   1/1     Running   cde-38q702
fluent-bit-firewall-qwc8g   1/1     Running   cde-38q70l

Archivo de logs en el collector

/var/log/remote/firewall/do-firewall.log

Ejemplo de log capturado

2026-05-25T16:18:41.622592Z from-pod=10.100.0.16 time="..." level=info msg="TearDown network for sandbox successfully"
2026-05-25T16:18:41.633468Z from-pod=10.100.0.16 time="..." level=warning msg="Failed to get podSandbox status..."

3. Puerto 5515 — Load Balancer Logs

Origen de los logs

El DigitalOcean Load Balancer (IP 129.212.199.126) recibe todo el tráfico HTTP/HTTPS público y lo reenvía al pod Kong en el cluster K8s. Por lo tanto, los access logs de Kong son funcionalmente equivalentes a los access logs del LB (cada request al LB queda registrado en Kong con timestamp, IP origen, ruta, método HTTP, código de respuesta, latencia).

Configuración Fluent Bit (5515)

yaml
[INPUT]
    Name              tail
    Path              /var/log/containers/kong-*.log
    Tag               loadbalancer.*
    Read_From_Head    Off
    multiline.parser  cri

[OUTPUT]
    Name             syslog
    Match            *
    Host             10.100.0.10
    Port             5515
    Mode             tcp
    Syslog_Format    rfc5424
    Syslog_Hostname_Key  hostname
    Syslog_Appname_Key   tag
    Syslog_Message_Key   log

Nota: Este DaemonSet usa nodeSelector: doks.digitalocean.com/node-pool: app porque Kong solo corre en el pool app.

Estado del DaemonSet

NAME                            READY   STATUS    NODE
fluent-bit-loadbalancer-2gk28   1/1     Running   app-38qmcg
fluent-bit-loadbalancer-6jmr5   1/1     Running   app-38qmcw

Archivo de logs en el collector

/var/log/remote/loadbalancer/do-loadbalancer.log

Ejemplo real de log capturado

2026-05-25T16:15:34.440687Z from-pod=10.116.4.23 10.100.0.4 - - [25/May/2026:16:15:34 +0000] "POST /auth/login HTTP/2.0" 400 220 "-" "curl/8.7.1" kong_request_id: "f06dd1429f8c9741ea306b6ca72c8438"
2026-05-25T16:15:34.737378Z from-pod=10.116.4.23 10.100.0.4 - - [25/May/2026:16:15:34 +0000] "POST /auth/login HTTP/2.0" 400 220 "-" "curl/8.7.1" kong_request_id: "cee78a393d4b4b79dee3fd0634adb503"

Cada entrada incluye: timestamp, source IP, HTTP method, ruta, código de respuesta, user agent, Kong request ID — formato estándar de access log Nginx-compatible.


4. Configuración rsyslog en el collector

Archivos:

  • /etc/rsyslog.d/12-fintrixs-firewall-logsink.conf (puerto 5514)
  • /etc/rsyslog.d/13-fintrixs-loadbalancer-logsink.conf (puerto 5515)
bash
# Firewall logsink (5514)
input(type="imtcp" port="5514" address="10.100.0.10" ruleset="firewall_logs")

ruleset(name="firewall_logs") {
  action(type="omfile"
    file="/var/log/remote/firewall/do-firewall.log"
    template="FirewallLog"
    fileCreateMode="0640"
    fileOwner="syslog"
    fileGroup="adm")
  stop
}

# Load Balancer logsink (5515)
input(type="imtcp" port="5515" address="10.100.0.10" ruleset="lb_logs")

ruleset(name="lb_logs") {
  action(type="omfile"
    file="/var/log/remote/loadbalancer/do-loadbalancer.log"
    template="LoadBalancerLog"
    fileCreateMode="0640"
    fileOwner="syslog"
    fileGroup="adm")
  stop
}

Nota técnica: rsyslog está vinculado específicamente a la IP privada 10.100.0.10 (no a 0.0.0.0) para evitar exposición pública. El servicio Rapid7 Insight Collector que originalmente ocupaba estos puertos fue deshabilitado (no se usaba para PCI/ControlCase).


5. Reglas de firewall aplicadas

DO Cloud Firewall (fintrix-production-collector-fw)

Inbound TCP 5514 from 10.100.0.0/16  (VPC nodes)
Inbound TCP 5514 from 10.116.0.0/16  (K8s pod CIDR)
Inbound TCP 5515 from 10.100.0.0/16  (VPC nodes)
Inbound TCP 5515 from 10.116.0.0/16  (K8s pod CIDR)

nftables (collector local)

ip saddr 10.100.0.0/16 tcp dport 5514 counter accept
ip saddr 10.116.0.0/16 tcp dport 5514 counter accept
ip saddr 10.100.0.0/16 tcp dport 5515 counter accept
ip saddr 10.116.0.0/16 tcp dport 5515 counter accept

6. Verificación End-to-End

ItemEstado
Puerto 5514 escuchando en rsyslog✓ Verificado
Puerto 5515 escuchando en rsyslog✓ Verificado
DO Firewall permite 5514 desde VPC + Pod CIDR✓ Aplicado
DO Firewall permite 5515 desde VPC + Pod CIDR✓ Aplicado
nftables permite tráfico (regla ANTES del DROP)✓ Aplicado
Fluent Bit Firewall corriendo (4 nodos)✓ 4/4 Running
Fluent Bit LB corriendo (2 nodos app)✓ 2/2 Running
Logs Firewall siendo escritos✓ 46+ líneas verificadas
Logs LB siendo escritos✓ 11+ líneas verificadas con access logs reales
Test directo netcat hacia rsyslog✓ Funciona

7. Inventario completo de logsinks PCI

LogsinkPuertoArchivo en collectorOrigen
PostgreSQL DB6514/var/log/remote/fintrix-production-fintrix-pci-{7,8}/postgres.logDO Managed logsink (nativo)
Kubernetes pods5141/var/log/remote/kubernetes/k8s-cluster.logFluent Bit DaemonSet (4 pods)
Firewall5514/var/log/remote/firewall/do-firewall.logFluent Bit + journald (4 pods)
Load Balancer5515/var/log/remote/loadbalancer/do-loadbalancer.logFluent Bit + Kong logs (2 pods)

8. Cumplimiento PCI DSS

RequisitoCómo se cumple
1.4.4 — Restricción tráfico al CDEFirewall logs capturan eventos de red
10.2.1 — Acceso a CHDLB access logs capturan todo request HTTP
10.2.2 — Acciones administrativasEventos kernel + access admin endpoints
10.2.4 — Acceso a logsLB logs incluyen requests a endpoints admin
10.3 — Audit trail entriesConfigurado para los 4 tipos de logs
10.5.3 — Backup/centralizaciónTodos los logs centralizados en collector
11.4 — Detección/prevención de intrusosEventos de red detectables en firewall logs

Historial de revisiones

FechaRevisorCambios
2026-05-25Equipo FintrixsCreación inicial — Fluent Bit Firewall + LB DaemonSets desplegados

Documentación Confidencial — Solo para uso interno y auditoría PCI DSS