Firewall i filtrowanie ruchu

(Sekcja: Technologia i infrastruktura)

Krótkie podsumowanie

Firewall nie jest jednym pudełkiem na obwodzie, ale warstwowym modelem filtrującym od L3-L4 do L7: cloud Security Groups/NACL, zasadami sieciowymi w Kubernetes, kontrolą wyjmowania, zarządzaniem WAF i bot na krawędzi oraz mTLS/source-truth for service-to-service. Dla iGaming, kluczem jest ochrona przepływów płatności i dostawców gier, geo-polityka, kontrola i obserwowalność DNS (kto, gdzie, kiedy i dlaczego).

1) Cele i zasady

Domyślne zaprzeczenie: domyślnie dopuszczamy wymagane minimum.
Defense-in-depth - Te same zasady dotyczące obwodu, chmury, klastra i aplikacji.
Egress-first: ruch wyjściowy jest takim samym ryzykiem jak wejście (PSP, dostawcy gier, poczta, analityka).
Tożsamość> adres: w miarę możliwości autoryzuj przez tożsamość (mTLS/Spiffe) zamiast gołego IP.
Obserwacja i audyt: dzienniki decyzji (zezwolenie/odmowa), ślady, korelacja z incydentami.

2) Mapa warstw filtracyjnych

1. Krawędź: CDN/WAF/DDoS/bot protection, zasady L7, zakończenie TLS.
2. Chmura: Grupy zabezpieczeń/NACL/Reguły zapory na poziomie VPC/podsieci/VM.
3. Klaster: Kubernetes, siatka serwisowa (Envoy/Istio) z filtrami mTLS i L7.
4. Host: iptables/nftables/ufw, agent eBPF filtry.
5. Zastosowanie: limit-rate/idempotence/WAF in-app, listy domen do wyjścia.
6. DNS: podział na horyzonty, rozdzielacze list dopuszczalnych, blok domen/typów ryzyka.

3) Obwód: WAF, DDoS i bot management

WAF: podstawowe podpisy + niestandardowe zasady dla API (schematy JSON, metody/rodzaj treści).
Boty: punktacja behawioralna, odcisk palca urządzenia, dynamiczna captcha dla anomalii.
DDoS: L3/4 (volum/synapsa) i L7 (powodzie HTTP) - automatyczne wyrzucanie na krawędzi.
Geo/ASN: ograniczamy regiony/systemy autonomiczne dla obszarów ryzykownych (na przykład panel administracyjny).

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) Chmura: Grupy bezpieczeństwa i NACL

Grupa zabezpieczeń (stacjonarna) - filtry według portu/protokołu/segmentu.
NACL (bezpaństwowiec) - szorstkie filtrowanie siatki podsieci.

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

Praktyka: w przypadku płatności należy zachować oddzielne UOIG i dopuszczalne listy dla określonych zakresów dostawców PSP/gier. Aktualizacje - poprzez IaC i przegląd.

5) Kubernetes: Polityka i siatka serwisowa

• polityka ogranicza L3/4 w ramach klastra; domyślnie „każdy rozmawia ze wszystkimi” - blisko.

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 jest wszędzie (uwierzytelnianie usługi przez tożsamość, nie IP).
• Filtrowanie L7 (metody/hosty/ścieżki/nagłówki), wyłącznik, wyrzut zewnętrzny.
• Zasady dostępu według konta serwisowego/identyfikatora Spiffe.

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) Zapory sieciowe: 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; }
}
}

Środki eBPF (Cilium itp.) zapewniają cienką politykę L3-L7 i widoczność (przepływy, DNS, metadane HTTP).

7) Spisy kontrolne i docelowe

Dopuszczalna lista domen/IP dla połączeń zewnętrznych (PSP, mail, KYC, dostawcy gier).
Polityka DNS pinning/SNI: rozwiązywać tylko za pomocą zaufanego rozdzielcy; zakazać surowego wyjścia IP.
Oddzielne wyjście VPC/VNet do płatności, gier i ogólnych obwodów.
Pełnomocnik z inspekcją TLS dla ruchu innego niż PII; przepływy płatnicze - bez MITM, wyłącznie bezpośrednie mTLS/PII bezpieczne.

8) Polityka TLS/mTLS i crypto

TLS 1. 2 +, nowoczesne szyfry, zszywanie OCSP, HSTS.
mTLS wewnątrz - powiązanie z identyfikatorem Spiffe/certyfikacją kont serwisowych.
Regularna rotacja certyfikatów i weryfikacja łańcuchów zaufania.
CORS/CSP na serwerze proxy L7 do cięcia źródeł atakujących z przodu.

9) Limit stawek i L7-quotas

Granice krawędzi według prefiksów IP/ASN/; limity aplikacji - według tożsamości (konto/najemca/klucz).
Klucze idempotencji dla operacji płatności POST, dzięki czemu przekładki nie tworzą duplikatów.
Wyciek/wiadro Token z jitter; podczas degradacji - „szare odpowiedzi „/captcha/opóźnienie.

10) Bezpieczeństwo DNS

Dozwolone są tylko osoby zajmujące się rozdzielczością (VPC resolver/uprawiane w trybie EDNS).
Split-horizon: Nazwy wewnętrzne nie rozstrzygają się z zewnątrz.
Zablokować szkodliwe TLD/kategorie, zakaz DoH/DoT z przesłuchań.
Rejestrowanie żądań i ostrzeganie przez anomalie (nowe domeny, częste NXDOMAIN).

11) Rejestry, obserwowalność i badania

Dzienniki zapory (zezwalaj/zaprzeczaj, zasady, bajty), audyt WAF, dzienniki DNS → SIEM/SOAR.
Przykłady: mierniki blokady z 'trace _ id' → szybki skok do problemu zapytania śladu.
Syntetyka: regularne kontrole dostępności dostawców PSP/gier z odpowiednich regionów.
Testy chaosu sieciowego: utrata pakietów, RTT, błędy DNS - sprawdź reakcję zasad i auto-naprawy.

12) Automatyzacja i IaC

Wszystkie zasady są jak kod (Terraform/Ansible/Helm/Kyverno/Gatekeeper).
Pull-request-review z polityką bezpieczeństwa (OPA).
Wersioning i Annotation-Marks każda zmiana reguły na wykresach.
Zmiany kanaryjskie: stopniowe wprowadzanie zasad sieci (obszar nazw/etykieta, 5-10% boisk).

13) Specyfika iGaming

Trasy płatności (PSP): indywidualne grupy wyjściowe, ścisła lista dopuszczalna, monitorowanie kodu/timeout.
Dostawcy gier: whitelisting domeny CDN, ochrona przed nagłymi przekierowaniami.
Zasady geograficzne: zgodność z lokalnymi ograniczeniami, bloki regionów na krawędzi.
Backoffice/KYC: dostęp tylko z zaufanych sieci/przez bastion + MFA.
Oszustwo: ograniczenia prędkości w odniesieniu do L7 i „ciężkich” wniosków do API o nieprawidłowych źródłach.

14) Przykłady szybkich zasad

UFW (gospodarz)

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 (zakaz niestandardowych metod, pomysł)

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

Limit stopy 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 kontrolna wdrażania

1. Domyślne zaprzeczenie na poziomie chmury (SG/NACL), klastra (Wizyta Zasad) i hostów.
2. Lista Egress do PSP/dostawców, rozwiązana tylko za pomocą zaufanego systemu DNS.
3. Zarządzanie WAF/bot/DDoS na krawędzi, zasady L7 dla REST/JSON i pliki do pobrania.
4. mTLS między usługami, autoryzacja tożsamości (Spiffe/SA).
5. Limit stawek/kwoty na krawędzi i w aplikacji, idempotence-klucze do płatności.
6. Zasady DNS: DoH/DoT prohibition, split-horizon, logowanie.
7. Dzienniki i SIEM: scentralizowana kolekcja pozwalają/zaprzeczają/WAF/DNS, wpisy dla anomalii.
8. Procesy IaC: kod reguły, przegląd PR, rolki kanaryjskie, adnotacje.
9. Testy/chaos: awarie RTT/loss/DNS, sprawdzanie tras awaryjnych i auto-skryptów.
10. Regularne audyty: audyt niewykorzystanych zasad, rotacja adresów PSP/CDN.

16) Anty-wzory

„Otwórz wszystko i nadzieję na WAF” - obwód nie uratuje ruchu wewnętrznego.
Brak kontroli wyjścia - tunel rurowy na zewnątrz dla leaks/C2.
Zezwalaj na wszystkie Polityki w Kubernetes - ruch boczny jest gwarantowany.
Filtrowanie tylko IP w dynamicznym świecie CDN/PSP bez sterowania domeną/DNS.
Jedynym punktem zakończenia TLS bez mTLS wewnątrz jest zastąpienie usługi.
Ręczne zmiany reguł sprzedaży bez IaC/audytu - brak odtwarzalności i długów.
Dzienniki zapory „do niczego” - bez obserwowalności jest to tylko „czarna skrzynka”.

Wyniki

Efektywne filtrowanie ruchu jest strukturą architektoniczną platformy: od krawędzi-WAF i chmury SG, po Politykę i mTLS w ramach klastra, z ścisłą kontrolą zagęszczenia do PSP/dostawców i zarządzania za pośrednictwem IaC. Taki system zmniejsza ryzyko wycieków i ataków, utrzymuje płatności i gry w ramach SLO i pomaga szybko badać incydenty poprzez pełny audyt i nadzór.