Firewall și filtrarea traficului

(Secțiunea: Tehnologie și infrastructură)

Scurt rezumat

Firewall nu este o cutie pe perimetru, ci un model de filtrare stratificat de la L3-L4 la L7: cloud Security Groups/NACL, politici de rețea în Kubernetes, control de ieșire, WAF și gestionarea bot pe margine și mTLS/sursă-adevăr pentru service-to-service. Pentru iGaming, cheia este de a proteja fluxurile de plăți și furnizorii de jocuri, geo-politică, controlul DNS și observabilitatea (cine, unde, când și de ce).

1) Obiective și principii

Negare implicită: în mod implicit, permitem minimul necesar.
Apărare în profunzime - Aceleași politici privind perimetrul, norul, clusterul și aplicația.
Egress-first: traficul de ieșire este același risc ca și intrarea (PSP, furnizorii de jocuri, mail, analytics).
Identitate> adresa: acolo unde este posibil, autorizați prin identitate (mTLS/Spiffe) în loc de IP goale.
Observabilitate și audit: jurnale de decizie (permitere/negare), urme, corelație cu incidentele.

2) Harta straturilor de filtrare

1. Edge: protecție CDN/WAF/DDoS/bot, reguli L7, terminare TLS.
2. Cloud: Grupuri de securitate/Reguli NACL/Firewall la nivelul VPC/subnet/VM.
3. Cluster: Kubernetes NetworkPolicy, mesh service (Envoy/Istio) cu filtre mTLS și L7.
4. Gazdă: iptables/nftables/ufw, filtre agent eBPF.
5. Aplicație: rate-limit/idempotency/WAF in-app, liste de domenii pentru ieșire.
6. DNS: split-orizont, lista de permisiuni, bloc de domenii/tipuri de risc.

3) Perimetru: WAF, DDoS și gestionarea bot

WAF: semnături de bază + reguli personalizate pentru API (scheme JSON, metode/tip de conținut).
Roboți: notare comportamentală, amprentă digitală a dispozitivului, captcha dinamică pentru anomalii.
DDoS: L3/4 (volum/sinapsă) și L7 (inundații HTTP) - aruncarea automată pe margine.
Geo/ASN: limităm regiunile/sistemele autonome pentru zonele riscante (de exemplu, un panou de administrare).

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: Grupuri de securitate și NACL

Security Group (statful) - filtre după port/protocol/segment.
NACL (apatrizi) - filtrarea cu ochiuri brute a subrețelelor.

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

Practică: pentru plăți păstrați SG-uri separate și liste de permisiune de ieșire pentru anumite game de furnizori de PSP/jocuri. Actualizări - prin intermediul IaC și revizuire.

5) Kubernetes: NetworkPolicy și Service Mesh

NetworkPolicy restricționează L3/4 în cadrul clusterului; în mod implicit „toată lumea vorbește cu toată lumea” - aproape.

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 este peste tot (autentificare serviciu de identitate, nu IP).
• Filtrare L7 (metode/gazde/căi/antete), circuit-breaker, outlier-ejection.
• Politici de acces prin contul de serviciu/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) firewall-uri gazdă: 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; }
}
}

Agenții eBPF (Cilium etc.) oferă politici de L3-L7 subțiri și vizibilitate (fluxuri, metadate DNS, HTTP).

7) Directoare de control și destinație de ieșire

Allowlist domenii/IP pentru apeluri externe (PSP, mail, KYC, furnizorii de jocuri).
Politicile DNS pinning/SNI: rezolvați numai printr-un rezolvator de încredere; interzice ieșirea IP brută.
Ieșire separată VPC/VNet pentru plată, jocuri și circuite generale.
Proxy cu inspecție TLS pentru trafic non-PII; fluxurile de plată - nu MITM, mTLS direct/PII-safe numai.

8) Politica TLS/mTLS și cripto

TLS 1. 2 +, cifruri moderne, capse OCSP, HSTS.
mTLS în interior - legarea la Spiffe ID/certificarea conturilor de servicii.
Rotirea regulată a certificatelor și verificarea lanțurilor de încredere.
CORS/CSP pe proxy-ul L7 pentru a tăia sursele de atac din față.

9) Limita de rată și L7-quotas

Limite de margine prin IP/ASN/prefixe; limitele cererii - prin identitate (cont/chiriaș/cheie).
Tastele de idempotență pentru operațiunile de plată POST, astfel încât retraiele să nu creeze duplicate.
Găleată de scurgere/Token cu jitter; în timpul degradării - „răspunsuri gri „/captcha/decelerare.

10) securitate DNS

Sunt permise numai rezolvatoarele corporative (VPC resolver/CoreDNS ridicat).
Split-orizont: numele interne nu se rezolvă din exterior.
Blocați TLD/categorii dăunătoare, interziceți DoH/DoT din vatră.
Cereri de logare și alertă prin anomalii (domenii noi, frecvente NXDOMAIN).

11) Jurnale, observabilitate și testare

Jurnalele firewall (permite/nega, reguli, octeți), auditul WAF, jurnalele DNS → SIEM/SOAR.
Exemplare: măsurătorile de blocare cu 'trace _ id' → un salt rapid în urma interogării problemei.
Sintetice: verificări periodice privind disponibilitatea furnizorilor de PSP/jocuri din regiunile potrivite.
Testele haosului în rețea: pierderea pachetelor, erorile RTT, DNS - verificați reacția regulilor și remedierea automată.

12) Automatizare și IaC

Toate regulile sunt ca un cod (Terraform/Ansible/Helm/Kyverno/Gatekeeper).
Pull-request-review cu politici de securitate (OPA).
Versioning și adnotare-Marchează orice schimbare de regulă pe grafice.
Modificări canare: implementați treptat politicile de rețea (namespace/etichetă, 5-10% din terenuri).

13) Specificul iGaming

Rute de plată (PSP): grupuri individuale de ieșire, listă de permisiuni strictă, monitorizare cod/timeout.
Furnizori de jocuri: whitelisting domenii CDN, protecție împotriva redirecționărilor bruște.
Geo-reguli: respectarea restricțiilor locale, blocuri de regiuni la limită.
Backoffice/KYC: acces numai din rețele de încredere/prin bastion + MFA.
Fraudă: limite de viteză pe L7 și cereri „grele” către API de surse anormale.

14) Exemple de reguli rapide

UFW (gazdă)

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 (interzicerea metodelor non-standard, idee)

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

Limita ratei NGINX

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 verificare a implementării

1. Neagă implicit la nivelul cloud (SG/NACL), cluster (NetworkPolicy) și gazde.
2. Lista de permisiuni pentru PSP/furnizori, rezolvată numai prin DNS de încredere.
3. WAF/bot management/DDoS pe margine, reguli L7 pentru REST/JSON și descărcări.
4. mTLS între servicii, autorizație de identitate (Spiffe/SA).
5. Rate-limit/cote pe margine și în aplicație, idempotency-chei pentru plăți.
6. Politici DNS: interzicerea DoH/DoT, divizarea orizontului, exploatarea forestieră.
7. Jurnale și SIEM: colectarea centralizată permite/neagă/WAF/DNS, alerte pentru anomalii.
8. Procesele IaC: codul regulii, revizuirea PR, rulouri canare, adnotări.
9. Teste/haos: RTT/pierdere/eșecuri DNS, verificarea rutelor de rezervă și auto-scripturi.
10. Audituri periodice: auditul regulilor neutilizate, rotirea adreselor PSP/CDN.

16) Anti-modele

„Deschideți totul și sperați pentru WAF” - perimetrul nu va salva traficul intern.
Nici un control de ieșire - tunel tub spre exterior pentru leaks/C2.
Permiteți-toate NetworkPolicy în Kubernetes - mișcarea laterală este garantată.
Filtrarea numai IP în lumea dinamică CDN/PSP fără control domeniu/DNS.
Singurul punct de terminare TLS fără mTLS în interior este înlocuirea serviciului.
Modificări manuale ale regulilor în vânzări fără IaC/audit - non-reproductibilitate și datorii.
Firewall jurnalele „nicăieri” - fără observabilitate este doar o „cutie neagră”.

Rezultate

Filtrarea eficientă a traficului este structura arhitecturală a platformei: de la edge-WAF și cloud SG la NetworkPolicy și mTLS în cadrul clusterului, cu control de ieșire strâns la PSP/furnizori și management prin IaC. Un astfel de sistem reduce riscul de scurgeri și atacuri, menține plățile și jocurile în cadrul SLO și ajută la investigarea rapidă a incidentelor prin audit și supraveghere completă.