Firewall e filtragem de tráfego

(Secção Tecnologia e Infraestrutura)

Resumo breve

O Faervol não é uma única caixa no perímetro, mas sim um modelo de filtragem camada de L3-L4 a L7: Segurança de nuvem/NACL, políticas de rede em Kubernetes, controle egress (saída), WAF e bot management em edge, e mTLS/fonte de verdade para o serviço Para o serviço. Para iGaming, a chave é proteger os fluxos de pagamento e provedores de jogos, geo-políticas, controle DNS e observabilidade (quem, onde, quando e porquê).

1) Objetivos e princípios

Default deny: por padrão, não é permitido, permitindo o mínimo necessário.
Defense-in-depth: políticas idênticas no perímetro, na nuvem, no cluster e no aplicativo.
Egress-first: tráfego de saída - o mesmo risco de entrada (PSP, provedores de jogos, correio, analista).
Identidade> endereço: sempre que possível, autorizamos a identidade (mTLS/Spiffe) em vez de IP nus.
Observação e auditoria: logs de soluções (allow/deny), traçados, correlação com incidentes.

2) Mapa de camadas de filtragem

1. Edge: CDN/WAF/DDoS/bot-proteção, regras L7, terminação TLS.
2. Nuvem: Security Groups/NACL/Firewall Rulas no nível VPC/subprodutos/VM.
3. Cluster: Kubernetes NetworkPolicy, serviço de mesh (Envoy/Istio) com filtros mTLS e L7.
4. Hostel: iptáveis/nftáveis/ufw, filtros eBPF da agência.
5. Aplicativo: rate-limit/idempotency/WAF in-app, listas de domínios para egress.
6. DNS: split-horizonte, allowlist resolvers, bloco de risco-domínios/tipos.

3) Perímetro: WAF, DDoS e gestão de bot

WAF: assinaturas de base + regras de custom sob API (esquema JSON, métodos/conteúdo-tipo).
Bots: escrutínio comportamental, device fingerprint, capcha dinâmica para anomalias.
L3/4 (Voolom/Sinaps) e L7 (HTTP floods) - Descartagem automática para edge.
Geo/ASN: Limitamos as regiões/sistemas autônomos para destinos de risco (por exemplo, painel Admin).

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) Nuvem: Security Groups e NACL

O Security Group (stateful) é um filtro por porta/protocolo/segmento.
NACL (stateless) - Filtragem de malha bruta de subretas.

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ática: para pagamentos manter individuais SG e egress-allowlist para diapositivos específicos PSP/provedores de jogos. Atualizações através de IaC e ciúmes.

5) Kubernetes: NetworkPolicy e serviço-mesh

NetworkPolicy limita o L3/4 dentro do cluster; por padrão, «todos falam com todos» - feche.

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 por todo o lado (autenticação de serviços de identidade, não IP).
• L7 filtragem (métodos/hosts/caminhos/cabeçalhos), circuito-breaker, outler-ejation.
• Políticas de Acesso da Conta de Serviço/Spiffe ID.

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) Feirinhas de hospedagem: 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; }
}
}

Os agentes eBPF (Cilium e etc.) oferecem políticas L3-L7 finas e visibilidade (flows, DNS, metadados HTTP).

7) Controle Egress e diretórios de destino

Domínios allowlist/IP para chamadas externas (PSP, correio, KYC, provedores de jogos).
Políticas DNS-pinning/SNI: apenas por meio de ressalvas confiáveis; proibir o IP bruto-egress.
VPC/VNet egress separados para contornos de pagamento, jogos e compartilhamento.
Procsi com inspeção TLS para tráfego não-PII; fluxos de pagamento - sem MITM, apenas mTLS/PII-safe direto.

8) TLS/mTLS e criptopolítica

TLS 1. 2 +, codificações modernas, OCSP stapling, HSTS.
mTLS dentro - vinculação ao Spiffe ID/certificação de serviço-acauntes.
Rotação regular de certificados e verificação de cadeias de confiança.
CORS/CSP no proxy L7 para cortar as fontes de ataque na frente.

9) Rate-limit e quotas L7

Limites Edge para IP/ASN/prefixados; os limites de aplicação são de identidade (conta/tenante/chave).
Idempotency-keys para as transações de pagamentos POST para que os retais não criem dublês.
Leaky/Token bucket com jitter; quando a degradação é «respostas cinzentas «/capcha/desaceleração.

10) Segurança DNS

Apenas ressalvas corporativas (VPC resolver/ CoreDNS levantado) são permitidas.
Split-horizonte: Os nomes internos não falam do lado de fora.
Bloco de TLD/categorias prejudiciais, proibição de DoH/DoT de poda para fora.
Loging e alerting por anomalias (novos domínios frequentes NXDOMAIN).

11) Logs, observabilidade e testes

Logs de faervas (allow/deny, regras, bytes), auditoria WAF, logs DNS → SIEM/SOAR.
Excempars: métricas de bloqueio com 'trace _ id' → um salto rápido na pista de consulta problemática.
Sintética: Verificações regulares de disponibilidade PSP/provedores de jogos das regiões certas.
Testes de caos da rede: packet loss, RPT, erros DNS - Verificamos a resposta das regras e remunções automáticas.

12) Automação e IaC

Todas as regras são como um código (Terraform/Ansable/Helm/Kyverno/Gatekeeper).
Pull-request com políticas de segurança (OPA).
Versionagem e anotação: qualquer mudança de regra é marcada em gráficos.
Alterações de canário: desbloquear as políticas de rede gradualmente (namespace/label, 5% a 10% de ferramentas).

13) Especificidades iGaming

Rotas de pagamento (PSP): grupos egress individuais, allowlist rigoroso, monitoramento de códigos/temporizadores.
Provedores de jogos whitelisting domínios CDN, proteção contra redits repentinos.
Regras geo: conformidade com limitações locais, blocos de regiões em edge.
Backoffice/KYC: Acesso somente a partir de redes de confiança/basition + MFA.
Frod: Os limites velocity para L7 e os pedidos «pesados» para a API de fontes anormais.

14) Exemplos de regras rápidas

UFW (anfitrião)

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 (proibição de métodos não convencionais, ideia)

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) Folha de cheque de implementação

1. Default deny em nuvem (SG/NACL), cluster (NetworkPolicy) e hosts.
2. Egress-allowlist para os provedores PSP/Exchange apenas através do DNS de confiança.
3. WAF/bot gestão/DDoS em edge, regras L7 sob REST/JSON e download.
4. mTLS entre os serviços, autorização de identidade (Spiffe/SA).
5. Rate-limit/cotas em edge e no aplicativo, idempotency-keys para pagamentos.
6. Políticas DNS: proibição de DoH/DoT, split-horizonte, loging.
7. Logi e SIEM: coleta centralizada allow/deny/WAF/DNS, alertas para anomalias.
8. Processos IaC: código de regras, revezamento PR, localizações canárias, anotações.
9. Testes/Caos: RPT/loss/falhas DNS, verificação de rotas fallback e auto-script.
10. Revisões regulares: auditoria de regras não utilizadas, rotação de endereços PSP/CDN.

16) Anti-pattern

«Abrir tudo e esperar pela WAF» - o perímetro não salvará o tráfego interno.
Falta de controle egress - túnel de lâmpadas para fora para vazamentos/C2.
Allow-all NetworkPolicy em Kubernetes - deslocamento lateral garantido.
Filtrar apenas por IP no mundo CDN/PSP dinâmico sem controle de domínio/DNS.
O único ponto de terminação TLS sem mTLS dentro é a troca de serviços.
Edições manuais de regras de venda sem IaC/auditoria - impermeabilização e dívidas.
O logi do faervol para o nada. Sem observabilidade, é só uma caixa preta.

Resumo

A filtragem eficiente do tráfego é um tecido arquitetônico da plataforma, desde edge-WAF e SG na nuvem até mTLS dentro de um cluster, com rígido controle egress para provedores e gerenciamento PSP via . Este sistema reduz o risco de vazamentos e ataques, mantém pagamentos e jogos dentro do SLO e ajuda a investigar rapidamente os incidentes através de uma auditoria completa e observabilidade.