GH GambleHub

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).

Örnek (NGINX + ModSecurity, JSON-API için fikir):
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.

API için örnek (şartlı olarak YAML) SG:
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.
Örnek (Istio AuthorizationPolicy fikri):
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.

Contact

Bizimle iletişime geçin

Her türlü soru veya destek için bize ulaşın.Size yardımcı olmaya her zaman hazırız!

Entegrasyona başla

Email — zorunlu. Telegram veya WhatsApp — isteğe bağlı.

Adınız zorunlu değil
Email zorunlu değil
Konu zorunlu değil
Mesaj zorunlu değil
Telegram zorunlu değil
@
Telegram belirtirseniz, Email’e ek olarak oradan da yanıt veririz.
WhatsApp zorunlu değil
Format: +ülke kodu ve numara (örneğin, +90XXXXXXXXX).

Butona tıklayarak veri işlemenize onay vermiş olursunuz.