Güvenlik duvarı ve trafik filtreleme
(Bölüm: Teknoloji ve Altyapı)
Kısa özet
Güvenlik duvarı, çevrede bir kutu değil, L3-L4'den L7'ye katmanlı bir filtreleme modelidir: Bulut Güvenlik Grupları/NACL, Kubernetes'teki ağ ilkeleri, çıkış kontrolü, WAF ve bot yönetimi ve mTLS/Hizmet-hizmet için kaynak-gerçeği. IGaming için anahtar, ödeme akışlarını ve oyun sağlayıcılarını, jeo-politikayı, DNS kontrolünü ve gözlemlenebilirliği (kim, nerede, ne zaman ve neden) korumaktır.
1) Hedefler ve ilkeler
Varsayılan reddetme: varsayılan olarak, gereken minimum değere izin veriyoruz.
Derinlemesine savunma - Çevre, bulut, küme ve uygulama ile ilgili aynı politikalar.
Çıkış-ilk: çıkış trafiği giriş ile aynı risktir (PSP, oyun sağlayıcıları, posta, analitik).
Kimlik> adres: mümkünse, çıplak IP yerine kimlik (mTLS/Spiffe) tarafından yetkilendirin.
Gözlemlenebilirlik ve denetim: karar günlükleri (izin ver/reddet), izler, olaylarla korelasyon.
2) Filtrasyon katmanlarının haritası
1. Kenar: CDN/WAF/DDoS/bot koruması, L7 kuralları, TLS sonlandırma.
2. Bulut: VPC/alt ağ/VM düzeyinde Güvenlik Grupları/NACL/Güvenlik Duvarı Kuralları.
3. Küme: Kubernetes NetworkPolicy, mTLS ve L7 filtreli servis ağı (Envoy/Istio).
4. Ana bilgisayar: iptables/nftables/ufw, ajan eBPF filtreleri.
5. Uygulama: rate-limit/idempotency/WAF in-app, çıkış için domain listeleri.
6. DNS: split-horizon, allowlist çözümleyiciler, risk alanları/türleri bloğu.
3) Çevre: WAF, DDoS ve bot yönetimi
WAF: temel imzalar + API için özel kurallar (JSON şemaları, yöntemler/içerik türü).
Botlar: davranışsal puanlama, cihaz parmak izi, anomaliler için dinamik captcha.
DDoS: L3/4 (volum/sinaps) ve L7 (HTTP taşması) - kenarda otomatik atma.
Geo/ASN: Riskli alanlar için bölgeleri/özerk sistemleri sınırlandırıyoruz (örneğin, bir yönetici paneli).
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) Bulut: Güvenlik Grupları ve NACL
Güvenlik Grubu (durumsal) - port/protokol/segmente göre filtreler.
NACL (stateless) - alt ağların kaba örgü filtrelenmesi.
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
Uygulama: ödemeler için ayrı SGs ve çıkış-allowlists belirli PSP/oyun sağlayıcı aralıkları için tutmak. Güncellemeler - IaC aracılığıyla ve gözden geçirin.
5) Kubernetes: NetworkPolicy ve Servis Ağı
NetworkPolicy küme içindeki L3/4 kısıtlar; varsayılan olarak'herkes herkesle konuşur "- yakın.
Deny-all + çözünürlük sadece gerekli: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 }]
Servis ağı (Istio/Linkerd/Consul) şunları ekler:
- mTLS her yerdedir (IP ile değil, kimlik ile servis kimlik doğrulaması).
- L7 filtreleme (yöntemler/ana bilgisayarlar/yollar/başlıklar), devre kesici, aykırı değer çıkarma.
- Hizmet hesabı/Spiffe ID ile politikalara erişin.
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) Ana bilgisayar güvenlik duvarları: iptables/nftables/eBPF
Nftables örneği (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 ajanları (Cilium, vb.) ince L3-L7 politikaları ve görünürlük (akışlar, DNS, HTTP meta verileri) sağlar.
7) Çıkış kontrolü ve hedef dizinleri
Harici aramalar için Allowlist etki alanları/IP (PSP, posta, KYC, oyun sağlayıcıları).
DNS sabitleme/SNI politikaları: yalnızca güvenilir bir çözümleyici aracılığıyla çözümleme; Ham IP çıkışını yasaklar.
Ödeme, oyun ve genel devreler için ayrı VPC/VNet çıkışı.
PII olmayan trafik için TLS incelemesi ile proxy; Ödeme akışları - MITM yok, yalnızca doğrudan mTLS/PII güvenli.
8) TLS/mTLS ve kripto politikası
TLS 1. 2 +, modern şifreler, OCSP zımbalama, HSTS.
mTLS inside - hizmet hesaplarının Spiffe ID/sertifikasyonuna bağlanması.
Düzenli sertifika rotasyonu ve güven zincirlerinin doğrulanması.
Cephede saldıran kaynakları kesmek için L7 proxy'deki CORS/CSP.
9) Oran sınırı ve L7-quotas
IP/ASN/öneklerine göre kenar sınırları; Uygulama sınırları - kimliğe göre (hesap/kiracı/anahtar).
POST ödeme işlemleri için idempotency-anahtarları, böylece geri ödemeler kopyalar oluşturmaz.
Jitter ile Leaky/Token kova; Bozulma sırasında - "gri cevaplar "/captcha/yavaşlama.
10) DNS güvenliği
Yalnızca kurumsal çözümleyicilere (VPC çözümleyici/yükseltilmiş CoreDNS) izin verilir.
Split-horizon: Dahili isimler dışarıdan çözümlenmez.
Zararlı TLD/kategorileri engelleyin, DoH/DoT'yi ocaklardan çıkarın.
Günlüğe kaydetme istekleri ve anomalilere göre uyarı (yeni alanlar, sık NXDOMAIN).
11) Günlükler, gözlemlenebilirlik ve test
Güvenlik duvarı günlükleri (izin ver/reddet, kurallar, baytlar), WAF denetimi, DNS günlükleri - SIEM/SOAR.
Exemplars: 'trace _ id'ile metrikleri kilitleyin - sorunlu sorgu izine hızlı bir şekilde atlayın.
Sentetikler: Doğru bölgelerden PSP/oyun sağlayıcılarının kullanılabilirliği konusunda düzenli kontroller.
Ağ kaos testleri: paket kaybı, RTT, DNS hataları - kuralların ve otomatik iyileştirmenin reaksiyonunu kontrol edin.
12) Otomasyon ve IaC
Tüm kurallar kod gibidir (Terraform/Ansible/Helm/Kyverno/Gatekeeper).
Güvenlik politikaları (OPA) ile Pull-request-review.
Sürüm Oluşturma ve Açıklama - Grafiklerdeki kural değişikliklerini işaretler.
Kanarya değişiklikleri: Ağ politikalarını kademeli olarak dağıtın (ad alanı/etiket, sahaların %5-10'u).
13) iGaming'in özellikleri
Ödeme yolları (PSP): bireysel çıkış grupları, sıkı allowlist, kod/zaman aşımı izleme.
Oyun sağlayıcıları: CDN alanlarını beyaz listeye ekleme, ani yönlendirmelere karşı koruma.
Coğrafi kurallar: yerel kısıtlamalara uygunluk, kenardaki bölge blokları.
Backoffice/KYC: Yalnızca güvenilir ağlardan/bastion + MFA üzerinden erişim.
Dolandırıcılık: L7 üzerindeki hız sınırları ve anormal kaynakların API'sına'ağır "istekler.
14) Hızlı kural örnekleri
UFW (sunucu)
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 (standart dışı yöntemlerin yasaklanması, fikir)
yaml typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router до роутера — Lua/Match для блокировки методов not in [GET,POST,OPTIONS]
NGINX hız sınırı
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) Uygulama kontrol listesi
1. Bulut (SG/NACL), küme (NetworkPolicy) ve ana bilgisayarlar düzeyinde varsayılan reddetme.
2. PSP/sağlayıcılara çıkış-allowlist, sadece güvenilir DNS ile çözüldü.
3. WAF/bot yönetimi/DDoS kenarda, REST/JSON ve indirmeler için L7 kuralları.
4. Hizmetler arasında mTLS, kimlik yetkilendirme (Spiffe/SA).
5. Edge ve uygulamada rate-limit/kotalar, ödemeler için idempotency-anahtarları.
6. DNS politikaları: DoH/DoT yasağı, bölünmüş ufuk, günlük kaydı.
7. Günlükleri ve SIEM: merkezi toplama izin/inkar/WAF/DNS, anormallikler için uyarılar.
8. IaC süreçleri: kural kodu, PR incelemesi, kanarya ruloları, ek açıklamalar.
9. Testler/kaos: RTT/kayıp/DNS arızaları, geri dönüş yollarının ve otomatik komut dosyalarının kontrol edilmesi.
10. Düzenli denetimler: kullanılmayan kuralların denetimi, PSP/CDN adreslerinin döndürülmesi.
16) Anti-desenler
"Her şeyi aç ve WAF için umut et" - çevre iç trafiği kurtarmayacak.
Çıkış kontrolü yok - leaks/C2 için dışarı doğru tüp tüneli.
Kubernetes'te Allow-all NetworkPolicy - yanal hareket garanti edilir.
Etki alanı/DNS kontrolü olmadan dinamik CDN/PSP dünyasında yalnızca IP filtreleme.
İçinde mTLS olmayan tek TLS sonlandırma noktası hizmet ikamesidir.
IaC/denetim olmadan satışlarda manuel kural değişiklikleri - tekrarlanamazlık ve borçlar.
Güvenlik duvarı "hiçbir yere" kaydeder - gözlemlenebilirlik olmadan sadece bir'kara kutu'dur.
Sonuçlar
Verimli trafik filtreleme, platformun mimari yapısıdır: edge-WAF ve bulut SG'den NetworkPolicy'ye ve küme içindeki mTLS'ye, PSP/sağlayıcılara sıkı çıkış kontrolü ve IaC üzerinden yönetim. Böyle bir sistem sızıntı ve saldırı riskini azaltır, ödemeleri ve oyunları SLO içinde tutar ve tam denetim ve gözetim yoluyla olayları hızlı bir şekilde araştırmaya yardımcı olur.