Firewall and traffic filtering
(Section: Technology and Infrastructure)
Brief summary
Firewall is not one box on the perimeter, but a layered filtering model from L3-L4 to L7: cloud Security Groups/NACL, network policies in Kubernetes, egress control, WAF and bot management on edge, and mTLS/source-truth for service-to-service. For iGaming, the key is to protect payment flows and game providers, geo-politics, DNS control and observability (who, where, when and why).
1) Goals and principles
Default deny: by default, we allow the minimum required.
Defense-in-depth - Same policies on perimeter, cloud, cluster, and application.
Egress-first: output traffic is the same risk as input (PSP, game providers, mail, analytics).
Identity> address: where possible, authorize by identity (mTLS/Spiffe) instead of bare IP.
Observability and audit: decision logs (allow/deny), traces, correlation with incidents.
2) Map of filtration layers
1. Edge: CDN/WAF/DDoS/bot protection, L7 rules, TLS termination.
2. Cloud: Security Groups/NACL/Firewall Rules at the VPC/subnet/VM level.
3. Cluster: Kubernetes NetworkPolicy, service mesh (Envoy/Istio) with mTLS and L7 filters.
4. Host: iptables/nftables/ufw, agent eBPF filters.
5. Application: rate-limit/idempotency/WAF in-app, domain lists for egress.
6. DNS: split-horizon, allowlist resolvers, block of risk domains/types.
3) Perimeter: WAF, DDoS and bot management
WAF: basic signatures + custom rules for API (JSON schemes, methods/content-type).
Bots: behavioral scoring, device fingerprint, dynamic captcha for anomalies.
DDoS: L3/4 (volum/synapse) and L7 (HTTP floods) - automatic discarding on edge.
Geo/ASN: we limit regions/autonomous systems for risky areas (for example, an admin panel).
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) Cloud: Security Groups and NACL
Security Group (stateful) - filters by port/protocol/segment.
NACL (stateless) - rough mesh filtering of subnets.
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
Practice: for payments keep separate SGs and egress-allowlists for specific PSP/game provider ranges. Updates - via IaC and review.
5) Kubernetes: NetworkPolicy and Service Mesh
NetworkPolicy restricts L3/4 within the cluster; by default "everyone talks to everyone" - close.
Deny-all + resolution only necessary: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 }]
Service mesh (Istio/Linkerd/Consul) adds:
- mTLS is everywhere (service authentication by identity, not IP).
- L7 filtering (methods/hosts/paths/headers), circuit-breaker, outlier-ejection.
- Access policies by service account/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) Host firewalls: iptables/nftables/eBPF
Example of nftables (statefull, deny-all):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; }
}
}
eBPF agents (Cilium, etc.) provide thin L3-L7 policies and visibility (flows, DNS, HTTP metadata).
7) Egress control and destination directories
Allowlist domains/IP for external calls (PSP, mail, KYC, game providers).
DNS pinning/SNI policies: resolve only through a trusted resolver; prohibit raw IP-egress.
Separate VPC/VNet egress for payment, gaming and general circuits.
Proxy with TLS inspection for non-PII traffic; payment flows - no MITM, direct mTLS/PII-safe only.
8) TLS/mTLS and crypto policy
TLS 1. 2 +, modern ciphers, OCSP stapling, HSTS.
mTLS inside - binding to Spiffe ID/certification of service accounts.
Regular certificate rotation and verification of trust chains.
CORS/CSP on the L7 proxy to cut attacking sources at the front.
9) Rate-limit and L7-quotas
Edge limits by IP/ASN/prefixes; application limits - by identity (account/tenant/key).
Idempotency-keys for POST payment operations so that retrays do not create duplicates.
Leaky/Token bucket with jitter; during degradation - "gray answers "/captcha/deceleration.
10) DNS security
Only corporate resolvers (VPC resolver/raised CoreDNS) are allowed.
Split-horizon: Internal names do not resolve from the outside.
Block harmful TLD/categories, ban DoH/DoT from the hearths out.
Logging requests and alert by anomalies (new domains, frequent NXDOMAIN).
11) Logs, observability and testing
Firewall logs (allow/deny, rules, bytes), WAF audit, DNS logs → SIEM/SOAR.
Exemplars: lock metrics with 'trace _ id' → a quick jump into the problem query trace.
Synthetics: regular checks on the availability of PSP/game providers from the right regions.
Network chaos tests: packet loss, RTT, DNS errors - check the reaction of rules and auto-remediation.
12) Automation and IaC
All rules are like code (Terraform/Ansible/Helm/Kyverno/Gatekeeper).
Pull-request-review with security policies (OPA).
Versioning and Annotation-Marks any rule change on graphs.
Canary changes: roll out network policies gradually (namespace/label, 5-10% of pitches).
13) The specifics of iGaming
Payment routes (PSP): individual egress groups, strict allowlist, code/timeout monitoring.
Game providers: whitelisting CDN domains, protection against sudden redirects.
Geo-rules: compliance with local restrictions, blocks of regions on the edge.
Backoffice/KYC: access only from trusted networks/via bastion + MFA.
Fraud: velocity limits on L7 and "heavy" requests to the API of abnormal sources.
14) Examples of quick rules
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 (prohibition of non-standard methods, 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) Implementation checklist
1. Default deny at the level of the cloud (SG/NACL), cluster (NetworkPolicy) and hosts.
2. Egress-allowlist to PSP/providers, resolved only through trusted DNS.
3. WAF/bot management/DDoS on edge, L7 rules for REST/JSON and downloads.
4. mTLS between services, identity authorization (Spiffe/SA).
5. Rate-limit/quotas on edge and in the app, idempotency-keys for payments.
6. DNS policies: DoH/DoT prohibition, split-horizon, logging.
7. Logs and SIEM: centralized collection allow/deny/WAF/DNS, alerts for anomalies.
8. IaC processes: rule code, PR review, canary rolls, annotations.
9. Tests/chaos: RTT/loss/DNS failures, checking fallback routes and auto-scripts.
10. Regular audits: audit of unused rules, rotation of PSP/CDN addresses.
16) Anti-patterns
"Open everything and hope for WAF" - the perimeter will not save internal traffic.
No egress control - tube tunnel outwards for leaks/C2.
Allow-all NetworkPolicy in Kubernetes - lateral movement is guaranteed.
IP-only filtering in the dynamic CDN/PSP world without domain/DNS control.
The only TLS termination point without mTLS inside is service substitution.
Manual rule changes in sales without IaC/audit - non-reproducibility and debts.
Firewall logs "to nowhere" - without observability it is just a "black box."
Results
Efficient traffic filtering is the architectural fabric of the platform: from edge-WAF and cloud SG to NetworkPolicy and mTLS within the cluster, with tight egress control to PSP/providers and management via IaC. Such a system reduces the risk of leaks and attacks, keeps payments and games within the SLO and helps to quickly investigate incidents through full audit and surveillance.