Firewall y filtrado de tráfico

(Sección: Tecnologías e Infraestructura)

Resumen breve

Faerwall no es una sola caja en el perímetro, sino un modelo de filtrado en capas de L3-L4 a L7: grupos de seguridad/NACL en la nube, políticas de red en Kubernetes, control egress (salida al exterior), WAF y bot management en edge, y mTLL S/fuente-verdad para servicio-a-servicio. Para iGaming, la clave es proteger los flujos de pago y los proveedores de juegos, las políticas geográficas, el control de DNS y la observabilidad (quién, dónde, cuándo y por qué).

1) Objetivos y principios

Por defecto deny: por defecto prohibido, permitimos lo mínimo necesario.
Defense-in-depth: las mismas políticas en el perímetro, en la nube, en el clúster y en la aplicación.
Egress-first: el tráfico de salida es el mismo riesgo que el de entrada (PSP, proveedores de juegos, correo, análisis).
Identidad> dirección: siempre que sea posible, autorizamos por identidad (mTLS/Spiffe) en lugar de IP desnuda.
Observación y auditoría: registros de soluciones (allow/deny), rastreos, correlación con incidentes.

2) Mapa de capas de filtrado

1. Edge: CDN/WAF/DDoS/bot protection, reglas L7, terminal TLS.
2. Nube: Grupos de seguridad/Reglas de Firewall/NACL a nivel de VPC/subredes/VM.
3. Cluster: Kubernetes NetworkPolicy, servicio de mesh (Envoy/Istio) con filtros mTLS y L7.
4. Host: iptables/nftables/ufw, filtros eBPF de agente.
5. Aplicación: rate-limit/idempotency/WAF in-app, listas de dominios para egress.
6. DNS: split-horizon, allowlist resolvers, bloque de dominios/tipos de riesgo.

3) Perímetro: WAF, DDoS y bot management

WAF: firmas básicas + reglas personalizadas bajo API (diagramas JSON, métodos/tipo de contenido).
Bots: puntuación conductual, device fingerprint, capcha dinámica en anomalías.
DDoS: L3/4 (volum/sinapsis) y L7 (HTTP floods) es un descarte automático en edge.
Geo/ASN: restringir las regiones/sistemas autónomos para destinos de riesgo (por ejemplo, panel de administración).

nginx
Разрешаем только JSON POST/GET на /api/
location /api/ {
limit_req zone=rl_api burst=50 nodelay;
if ($request_method!~ ^(GET    POST)$) { return 405; }
if ($http_content_type!~ "application/json") { return 415; }
proxy_pass http://api_upstream;
}
ModSecurity CRS + собственные правила modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/crs.conf;

4) Nube: Grupos de seguridad y NACL

Grupo de seguridad (stateful): filtros por puerto/protocolo/segmento.
NACL (stateless): filtrado de red grueso de subredes.

yaml security_group:
name: api-sg ingress:
- proto: tcp; port: 443; cidr: 0.0.0.0/0 # через CDN/WAF egress:
- proto: tcp; port: 443; cidr: 203.0.113.0/24  # PSP-X
- proto: tcp; port: 443; cidr: 198.51.100.0/24 # ProviderA
- proto: udp; port: 53; cidr: 10.10.0.10/32  # только наш DNS

Práctica: para los pagos, mantenga SG y egress-allowlist separados en las diapositivas específicas de PSP/proveedores de juegos. Actualizaciones - a través de IaC y rugido.

5) Kubernetes: NetworkPolicy y servicio de mesh

NetworkPolicy limita la L3/4 dentro del clúster; por defecto «todo el mundo habla con todo el mundo» - cerrar.

yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: { name: deny-all, namespace: prod }
spec:
podSelector: {}
policyTypes: [Ingress, Egress]
ingress: []
egress: []
---
Разрешаем API разговаривать с платежным сервисом и DNS apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: { name: api-allow-specific, namespace: prod }
spec:
podSelector: { matchLabels: { app: api } }
policyTypes: [Ingress, Egress]
egress:
- to:
- namespaceSelector: { matchLabels: { name: prod } }
podSelector: { matchLabels: { app: payments } }
ports: [{ protocol: TCP, port: 8080 }]
- to:
- ipBlock: { cidr: 10.10.0.10/32 }
ports: [{ protocol: UDP, port: 53 }]

• mTLS está en todas partes (autenticación de servicios por identidad, no IP).
• Filtrado L7 (métodos/hosts/paths/encabezados), circuit-breaker, outlier-ejection.
• Políticas de acceso de cuenta de servicio/ID de Spiffe.

yaml apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: { name: api-to-payments, namespace: prod }
spec:
selector: { matchLabels: { app: payments } }
action: ALLOW rules:
- from:
- source:
principals: ["spiffe://prod/ns/prod/sa/api-sa"]
to:
- operation:
methods: ["POST"]
paths: ["/deposit","/withdraw"]

6) Hosting Faervoles: iptables/nftables/eBPF

nft table inet filter {
sets {
psp { type ipv4_addr; elements = { 203.0.113.10, 203.0.113.11 } }
}
chains {
input { type filter hook input priority 0; policy drop;
ct state established,related accept iifname "lo" accept tcp dport {22,443} accept
}
output { type filter hook output priority 0; policy drop;
ct state established,related accept udp dport 53 ip daddr 10.10.0.10 accept  # только наш DNS tcp dport 443 ip daddr @psp accept    # egress к PSP
}
forward { type filter hook forward priority 0; policy drop; }
}
}

Los agentes eBPF (Cilium, etc.) proporcionan políticas L3-L7 sutiles y visibilidad (flows, DNS, metadatos HTTP).

7) Control de egresos y directorios de destino

Allowlist dominios/IP para llamadas externas (PSP, correo, KYC, proveedores de juegos).
DNS-pinning/SNI-Policy: resuelva sólo a través de un resólver de confianza; Prohibir el crudo IP-egress.
VPC/VNet egress separados para el pago, el juego y los circuitos generales.
Proxy con inspección TLS para tráfico no PII; flujos de pago - sin MITM, sólo mTLS/PII-seguro directo.

8) TLS/mTLS y criptopolítica

TLS 1. 2 +, cifrados modernos, OCSP stapling, HSTS.
mTLS en el interior - enlace a Spiffe ID/certificación de servicio-acounts.
Rotación regular de certificados y comprobación de cadenas de confianza.
CORS/CSP en un proxy L7 para cortar fuentes de ataque en el frente.

9) Rate-limit y L7-cupos

Límites edge para los prefijos IP/ASN; los límites de aplicación son por identidad (cuenta/tenant/clave).
Idempotency-keys para transacciones de pago POST para que los retiros no generen tomas.
Leaky/Token bucket con jitter; en la degradación - «respuestas grises «/capcha/ralentización.

10) Seguridad DNS

Sólo los resólveres corporativos (resolver VPC/CoreDNS elevado) están permitidos.
Split-horizon: los nombres internos no resuelven fuera.
Bloque de categorías de TLD perjudiciales, prohibición de DoH/DoT de podas hacia el exterior.
Lógica de consultas y alertas de anomalías (nuevos dominios frecuentes de NXDOMAIN).

11) Registros, observabilidad y pruebas

Registros de faervoles (allow/deny, reglas, bytes), auditoría WAF, registros DNS → SIEM/SOAR.
Exemplars: métricas de bloqueo con 'trace _ id' → un salto rápido a la pista de una consulta problemática.
Sintética: verificaciones regulares de la disponibilidad de PSP/proveedores de juegos de las regiones deseadas.
Pruebas de caos de la red: packet loss, RTT, errores DNS - comprobar la respuesta de las reglas y auto-remediación.

12) Automatización e IaC

Todas las reglas son como código (Terraform/Ansible/Helm/Kyverno/Gatekeeper).
Pull-request-rugir con políticas de seguridad (OPA).
Versificación y anotaciones: cualquier cambio de reglas se marca en los gráficos.
Cambios canarios: desenrollar progresivamente las políticas de red (namespace/label, 5-10% de las podas).

13) Especificidad de iGaming

Rutas de pago (PSP): grupos egresos individuales, estrictos allowlist, monitoreo de códigos/temporizadores.
Proveedores de juegos: whitelisting dominios CDN, protección contra redirecciones repentinas.
Reglas geográficas: cumplimiento de restricciones locales, bloques de regiones en edge.
Backoffice/KYC: acceso sólo desde redes de confianza/a través de bastión + MFA.
Frod: velocity-limites en L7 y solicitudes «pesadas» a la API de fuentes anómalas.

14) Ejemplos de reglas rápidas

UFW (host)

bash ufw default deny incoming ufw default deny outgoing ufw allow 22/tcp ufw allow 443/tcp ufw allow out to 10.10.0.10 port 53 proto udp ufw allow out to 203.0.113.0/24 port 443 proto tcp

Istio EnvoyFilter (prohibición de métodos no estándar, idea)

yaml typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router до роутера — Lua/Match для блокировки методов not in [GET,POST,OPTIONS]

NGINX rate-limit

nginx limit_req_zone $binary_remote_addr zone=rl_api:10m rate=10r/s;
server {
location /api/ { limit_req zone=rl_api burst=50 nodelay; proxy_pass http://api; }
}

15) Lista de verificación de implementación

1. Default deny a nivel de nube (SG/NACL), clúster (NetworkPolicy) y hosts.
2. Egress-allowlist a PSP/proveedores, resolvim sólo a través de DNS de confianza.
3. WAF/bot management/DDoS en edge, reglas de L7 bajo NAT/JSON y descargas.
4. mTLS entre servicios, autorización por identidad (Spiffe/SA).
5. Rate-limit/quotas en edge y en app, idempotency-keys para pagos.
6. Políticas de DNS: prohibición de DoH/DoT, split-horizon, lógica.
7. Registros y SIEM: recopilación centralizada de allow/deny/WAF/DNS, alertas de anomalías.
8. Procesos iaC: código de reglas, rugido PR, ranuras canarias, anotaciones.
9. Pruebas/caos: fallas RTT/loss/DNS, comprobación de rutas fallback y scripts de auto.
10. Revisiones periódicas: auditoría de reglas no utilizadas, rotación de direcciones PSP/CDN.

16) Anti-patrones

«Abrir todo y esperar en WAF» - el perímetro no salvará el tráfico interno.
Sin control egress - túnel de lámpara hacia fuera para fugas/C2.
Allow-all NetworkPolicy en Kubernetes - movimiento lateral garantizado.
Filtrado sólo por IP en un mundo de CDN/PSP dinámico sin control de dominio/DNS.
El único punto de terminación TLS sin mTLS dentro es el reemplazo de servicios.
Correcciones manuales de reglas en venta sin IaC/auditoría - No reproducibilidad y deudas.
Los registros de faerwall «a ninguna parte» - sin ser observados es simplemente una «caja negra».

Resultados

La filtración eficiente del tráfico es el tejido arquitectónico de la plataforma: desde edge-WAF y cloud SG hasta NetworkPolicy y mTLS dentro del clúster, con un control egress estricto a PSP/proveedores y administración a través de IaC. Este sistema reduce el riesgo de fugas y ataques, mantiene los pagos y juegos dentro de SLO y ayuda a investigar los incidentes rápidamente gracias a una auditoría y vigilancia completas.