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 и помогает быстро расследовать инциденты благодаря полному аудиту и наблюдаемости.