Firewall і фільтрація трафіку

(Розділ: Технології та Інфраструктура)

Коротке резюме

Фаєрвол - це не один ящик на периметрі, а шарувата модель фільтрації від L3-L4 до L7: хмарні Security Groups/NACL, мережеві політики в Kubernetes, egress-контроль (вихід назовні), WAF і бот-менеджмент на edge, і mTLS/джерело-істинності для сервіс-к-сервісу. Для iGaming ключове - захист платіжних потоків і ігрових провайдерів, гео-політики, контроль DNS і спостережуваність (хто, куди, коли і чому).

1) Цілі та принципи

Default deny: за замовчуванням заборонено, дозволяємо мінімально необхідне.
Defense-in-depth: однакові політики на периметрі, в хмарі, в кластері і в додатку.
Egress-first: вихідний трафік - такий же ризик, як і вхідний (PSP, провайдери ігор, пошта, аналітика).
Ідентичність> адреса: там, де можливо, авторизуємо за ідентичністю (mTLS/Spiffe) замість голих IP.
Спостережуваність і аудит: логи рішень (allow/deny), трасування, кореляція з інцидентами.

2) Карта шарів фільтрації

1. Edge: CDN/WAF/DDoS/бот-захист, L7-правила, TLS-термінація.
2. Хмара: Security Groups/NACL/Firewall Rules на рівні VPC/підмереж/VM.
3. Кластер: Kubernetes NetworkPolicy, сервіс-меш (Envoy/Istio) з mTLS і L7-фільтрами.
4. Хост: iptables/nftables/ufw, агентські eBPF-фільтри.
5. Додаток: rate-limit/idempotency/WAF ін-апп, списки доменів для egress.
6. DNS: split-horizon, allowlist резольверів, блок ризик-доменів/типів.

3) Периметр: WAF, DDoS і бот-менеджмент

WAF: базові сигнатури + кастомні правила під API (JSON-схеми, методи/контент-type).
Боти: поведінковий скоринг, device fingerprint, динамічна капча при аномаліях.
DDoS: L3/4 (волюм/синапс) і L7 (HTTP floods) - автоматичне відкидання на edge.
Geo/ASN: обмежуємо регіони/автономні системи для ризикових напрямків (наприклад, адмін-панель).

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) Хмара: Security Groups и NACL

Security Group (stateful) - фільтри за портами/протоколами/сегментами.
NACL (stateless) - груба сітчаста фільтрація підмереж.

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

Практика: для платежів тримати окремі SG і egress-allowlist на конкретні діапозони PSP/провайдерів ігор. Оновлення - через IaC і рев'ю.

5) Kubernetes: NetworkPolicy і сервіс-меш

NetworkPolicy обмежує L3/4 всередині кластера; за замовчуванням «всі говорять з усіма» - закрийте.

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 всюди (автентифікація сервісів за ідентичністю, а не IP).
• L7-фільтрацію (методи/хости/шляхи/заголовки), circuit-breaker, outlier-ejection.
• Політики доступу за сервісним обліком/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) Хостові фаєрволи: 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; }
}
}

eBPF-агенти (Cilium тощо) дають тонкі L3-L7-політики і видимість (flows, DNS, HTTP-метадані).

7) Egress-контроль і каталоги призначення

Allowlist доменів/IP для зовнішніх викликів (PSP, пошта, KYC, провайдери ігор).
DNS-пінінг/SNI-політики: резолвить тільки через довірений резольвер; забороняти сирої IP-egress.
Роздільні VPC/VNet egress для платіжного, ігрового та загального контурів.
Проксі з TLS-інспекцією для не-PII трафіку; платіжні потоки - без MITM, тільки прямі мTLS/PII-safe.

8) TLS/mTLS і криптополітика

TLS 1. 2 +, сучасні шифри, OCSP stapling, HSTS.
mTLS всередині - прив'язка до Spiffe ID/сертифікація сервіс-акаунтів.
Регулярна ротація сертифікатів і перевірка ланцюжків довіри.
CORS/CSP на L7-проксі, щоб різати атакуючі джерела на фронті.

9) Rate-limit і L7-квоти

Edge-ліміти за IP/ASN/префіксами; прикладні ліміти - за ідентичністю (аккаунт/тенант/ключ).
Idempotency-keys для POST-операцій платежів, щоб ретраї не створювали дублів.
Leaky/Token bucket з джиттером; при деградації - «сірі відповіді «/капча/уповільнення.

10) DNS-безпека

Дозволені тільки корпоративні резольвери (VPC resolver/піднятий CoreDNS).
Split-horizon: внутрішні імена не резолвятся зовні.
Блок шкідливих TLD/категорій, заборона DoH/DoT з подів назовні.
Логування запитів і алертинг за аномаліями (нові домени, часті NXDOMAIN).

11) Логи, спостережуваність і тестування

Логи фаєрволів (allow/deny, правила, байти), WAF-аудит, DNS-логи → SIEM/SOAR.
Exemplars: метрики блокувань з'trace _ id'→ швидкий стрибок в трасу проблемного запиту.
Синтетика: регулярні перевірки доступності PSP/провайдерів ігор з потрібних регіонів.
Хаос-тести мережі: packet loss, RTT, DNS-помилки - перевіряємо реакцію правил і авто-ремедіації.

12) Автоматизація та IaC

Всі правила - як код (Terraform/Ansible/Helm/Kyverno/Gatekeeper).
Pull-request-рев'ю з політиками безпеки (OPA).
Версіонування та анотації: будь-яка зміна правил позначається на графіках.
Канарські зміни: розкатувати мережеві політики поступово (namespace/label, 5-10% подів).

13) Специфіка iGaming

Платіжні маршрути (PSP): окремі egress-групи, строгі allowlist, моніторинг кодів/таймаутів.
Провайдери ігор: whitelisting доменів CDN, захист від раптових редиректів.
Гео-правила: відповідність локальним обмеженням, блоки регіонів на edge.
Backoffice/KYC: доступ тільки з довірених мереж/через bastion + MFA.
Фрод: velocity-ліміти на L7 і «важкі» запити до API аномальних джерел.

14) Приклади швидких правил

UFW (хост)

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 (заборона нестандартних методів, ідея)

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) Чек-лист впровадження

1. Default deny на рівні хмари (SG/NACL), кластера (NetworkPolicy) і хостів.
2. Egress-allowlist до PSP/провайдерів, резольвим тільки через довірений DNS.
3. WAF/бот-менеджмент/DDoS на edge, L7-правила під REST/JSON і завантаження.
4. mTLS між сервісами, авторизація за ідентичністю (Spiffe/SA).
5. Rate-limit/quotas на edge і в додатку, idempotency-keys для платежів.
6. DNS-політики: заборона DoH/DoT, split-horizon, логування.
7. Логи і SIEM: централізований збір allow/deny/WAF/DNS, алерти за аномаліями.
8. IaC-процеси: код правил, PR-рев'ю, канарські розкатки, анотації.
9. Тести/хаос: RTT/loss/DNS-збої, перевірка fallback-маршрутів і авто-скриптів.
10. Регулярні ревізії: аудит невикористовуваних правил, ротація адрес PSP/CDN.

16) Анти-патерни

«Відкрити все і сподіватися на WAF» - периметр не врятує внутрішній трафік.
Відсутність egress-контролю - ламповий тунель назовні для витоків/С2.
Allow-all NetworkPolicy в Kubernetes - бічне переміщення гарантовано.
Фільтрація тільки по IP в світі динамічних CDN/PSP без контролю домену/DNS.
Єдина точка TLS-термінації без mTLS всередині - підміна сервісів.
Ручні правки правил в проді без IaC/аудиту - невідтворюваність і борги.
Логи фаєрвола «в нікуди» - без спостережуваності це просто «чорний ящик».

Підсумки

Ефективна фільтрація трафіку - це архітектурна тканина платформи: від edge-WAF і хмарних SG до NetworkPolicy і мTLS всередині кластера, з жорстким egress-контролем до PSP/провайдерів і управлінням через IaC. Така система знижує ризик витоків і атак, тримає платежі та ігри в рамках SLO і допомагає швидко розслідувати інциденти завдяки повному аудиту і спостережуваності.