GH GambleHub

Firewall va trafikni filtrlash

(Bo’lim: Texnologiyalar va infratuzilma)

Qisqacha xulosa

Faervol - bu perimetri bo’yicha bitta quti emas, balki L3-L4 dan L7 gacha bo’lgan qatlamli filtrlash modeli: bulutli Security Groups/NACL, Kubernetes tarmoq siyosati, egress-control (chiqish), WAF va edge bo’yicha bot-menejment, va mTLS/servis uchun haqiqat manbai k-servis. iGaming uchun asosiy narsa - to’lov oqimlari va o’yin provayderlarini himoya qilish, geo-siyosat, DNS nazorati va kuzatish (kim, qayerda, qachon va nima uchun).


1) Maqsad va prinsiplar

Default deny: Andoza ravishda taqiqlangan, minimal ruxsat bering.
Defense-in-depth: perimetr, bulut, klaster va dasturda bir xil siyosatlar.
Egress-first: chiqish trafigi - kirish trafigi bilan bir xil xavf (PSP, o’yin provayderlari, pochta, tahlil).
Identifikatsiya> manzil: agar mumkin boʻlsa, yalang’och IP’lar o’rniga identifikatsiyaga (mTLS/Spiffe) ega bo’lamiz.
Kuzatish va audit: yechimlar loglari (allow/deny), trastirovkalar, hodisalar bilan korrelyatsiya.


2) Filtrlash qatlamlari xaritasi

1. Edge: CDN/WAF/DDoS/bot himoyasi, L7 qoidalari, TLS terminatsiyasi.
2. Bulut: Security Groups/NACL/Firewall Rules VPC/kichik tarmoqlar/VM darajasida.
3. Klaster: Kubernetes NetworkPolicy, mTLS va L7 filtrli servis-mesh (Envoy/Istio).
4. Xost: iptables/nftables/ufw, agentlik eBPF filterlari.
5. Ilova: rate-limit/idempotency/WAF in-app, egress uchun domenlar roʻyxati.
6. DNS: split-horizon, allowlist rezolver, blok risk-domen/tiplar.


3) Perimetri: WAF, DDoS va bot-menejment

WAF: asosiy belgilar + API uchun maxsus qoidalar (JSON-sxemalar, usullar/kontent-type).
Botlar: xulq-atvor skoringi, device fingerprint, anomaliyalarda dinamik kapcha.
DDoS: L3/4 (volyum/sinaps) va L7 (HTTP floods) - edge.
Geo/ASN: xavfli yo’nalishlar uchun hududlarni/avtonom tizimlarni cheklaymiz (masalan, ma’muriy panel).

Misol (NGINX + ModSecurity, JSON-API uchun g’oya):
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: Security Groups va NACL

Security Group (stateful) - portlar/protokollar/segmentlar bo’yicha filtrlar.
NACL (stateless) - kichik tarmoqlarning qo’pol filtrlanishi.

API uchun SG namunasi (shartli-YAML):
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

Amaliyot: to’lovlar uchun alohida SG va egress-allowlist o’yinlarni PSP/provayderlarning aniq diapazonlarida ushlab turish. Yangilanishlar - IaC va revyu orqali.


5) Kubernetes: NetworkPolicy va servis-mesh

NetworkPolicy klaster ichidagi L3/4 cheklaydi; Hamma hamma bilan gaplashadi degani - yoping.

Deny-all + ruxsatnoma faqat kerakli:
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 }]
Service mesh (Istio/Linkerd/Consul) qoʻshadi:
  • mTLS hamma joyda (IP emas, balki identifikatsiya xizmatlari).
  • L7-filtrlash (usullar/xostlar/yoʻllar/sarlavhalar), circuit-breaker, outlier-ejection.
  • Xizmat hisobi/Spiffe ID uchun foydalanish siyosati.
Misol (Istio AuthorizationPolicy gʻoyasi):
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) Xost fayllari: iptables/nftables/eBPF

nftables misoli (stateful, 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 agentlari (Cilium va boshqalar) ingichka L3-L7 siyosati va ko’rinishini beradi (flows, DNS, HTTP-meta ma’lumotlar).


7) Egress-nazorat va tayinlash kataloglari

Tashqi qo’ng’iroqlar uchun Allowlist domenlari/IP (PSP, pochta, KYC, o’yin provayderlari).
DNS-pinning/SNI-siyosati: faqat ishonchli rezolver orqali ajratish; xom IP-egress ni taqiqlash.
To’lov, o’yin va umumiy konturlar uchun alohida VPC/VNet egress.
Not-PII trafigi uchun TLS-inspeksiyasi bo’lgan proksi; to’lov oqimlari - MITMsiz, faqat to’g «ridan to’g» ri mTLS/PII-safe.


8) TLS/mTLS va kriptopolitika

TLS 1. 2 +, zamonaviy shifrlar, OCSP stapling, HSTS.
mTLS ichida - Spiffe ID/service-akkauntlarni sertifikatlash.
Sertifikatlarni muntazam ravishda rotatsiya qilish va ishonch zanjirlarini tekshirish.
CORS/CSP frontdagi hujum manbalarini kesish uchun L7-proksida.


9) Rate-limit va L7-kvotalar

IP/ASN/prefikslar bo’yicha Edge-limitlar; ilova limitlari - o’ziga xoslik bo’yicha (akkaunt/tenant/kalit).
Idempotency-keys to’lovlarning POST-operatsiyalari uchun, retrajlar dubl yaratmasligi uchun.
Leaky/Token bucket bilan jitter; degradatsiyada - «kulrang javoblar «/kapcha/sekinlashish.


10) DNS xavfsizligi

Faqat korporativ rezolverlarga ruxsat berilgan (VPC resolver/koʻtarilgan CoreDNS).
Split-horizon: ichki nomlar tashqarida yigʻilmaydi.
Zararli TLD/toifalar bloki, DoH/DoT tovoqlarni tashqariga chiqarishni taqiqlash.
Soʻrovlarni loglash va anomaliyalar boʻyicha alerting (yangi domenlar, tez-tez NXDOMAIN).


11) Logi, kuzatuv va test

(allow/deny, qoidalar, baytlar), WAF-audit, DNS-loglar → SIEM/SOAR.
Exemplars:’trace _ id’bilan qulflash metrikasi → muammoli soʻrov trassasiga tez sakrash.
Sintetika: kerakli hududlardan PSP/o’yin provayderlarini muntazam tekshirish.
Tarmoqning xaos-testlari: packet loss, RTT, DNS xatolari - qoidalar va avto-remediatsiyaning reaktsiyasini tekshiramiz.


12) Avtomatlashtirish va IaC

Barcha qoidalar kod kabi (Terraform/Ansible/Helm/Kyverno/Gatekeeper).
Xavfsizlik siyosatchilari bilan pull-request-revyu (OPA).
Version va izohlar: qoidalarning har qanday o’zgarishi grafiklarda belgilanadi.
Kanar oʻzgarishlari: tarmoq siyosatini bosqichma-bosqich yoyish (namespace/label, 5-10% pod).


13) iGaming xususiyatlari

To’lov yo’nalishlari (PSP): alohida egress-guruhlar, qat’iy allowlist, kod/taymaut monitoringi.
O’yin provayderlari: CDN domenlarini whitelisting, to’satdan tahrirlashdan himoya qilish.
Geo-qoidalar: mahalliy cheklovlarga muvofiqlik, edge.
Backoffice/KYC: faqat ishonchli tarmoqlardan/bastion + MFA orqali foydalanish.
Frod: L7 uchun velocity-limitlar va anormal manbalarning API uchun «og’ir» so’rovlar.


14) Tezkor qoidalar misollari

UFW (xost)

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 (nostandart usullarni taqiqlash, g’oya)

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) Joriy etish chek-varaqasi

1. Bulut (SG/NACL), klaster (NetworkPolicy) va xostlar darajasida default deny.
2. Egress-allowlist PSP/provayderlarga faqat ishonchli DNS orqali yuboriladi.
3. WAF/bot-menejment/DDoS edge, L7-qoidalar REST/JSON ostida va yuklab olish.
4. mTLS, identifikatsiya bo’yicha avtorizatsiya (Spiffe/SA).
5. Rate-limit/quotas edge va ilovada, idempotency-keys to’lovlar uchun.
6. DNS siyosati: DoH/DoT, split-horizon, loging taqiqlanadi.
7. Logi va SIEM: markazlashtirilgan yig’ish allow/deny/WAF/DNS, anomaliyalar bo’yicha alertlar.
8. IaC-jarayonlar: qoidalar kodi, PR-revyu, kanareykali prokatlar, izohlar.
9. Testlar/xaos: RTT/loss/DNS muvaffaqiyatsizliklari, fallback marshrutlari va avto skriptlarni tekshirish.
10. Muntazam taftishlar: foydalanilmayotgan qoidalar auditi, PSP/CDN manzillarini rotatsiya qilish.


16) Anti-patternlar

«Hamma narsani ochish va WAFga umid qilish» perimetri ichki trafikni saqlab qolmaydi.
Egress-nazoratning yo’qligi -/C2 oqishi uchun lampali tunnel.
Allow-all NetworkPolicy in Kubernetes - yon tomonga harakatlanish kafolatlangan.
Faqat DNS/domen nazorati boʻlmagan dinamik CDN/PSP uchun filtrlash.
mTLSsiz yagona TLS-terminatsiya nuqtasi - xizmatlarni almashtirish.
IaC/auditsiz mahsulotdagi qoidalarni qo’lda tuzatish - qayta tiklanmaslik va qarzlar.
Firewall loglari «hech qaerga» - kuzatilmasa, bu shunchaki «qora quti».


Yakunlar

Trafikni samarali filtrlash - bu platformaning arxitektura matosi: edge-WAF va bulutli SG dan NetworkPolicy va mTLSgacha klaster ichida, PSP/provayderlarga qattiq egress nazorati va IaC orqali boshqarish. Bunday tizim sizib chiqish va hujumlar xavfini kamaytiradi, SLO doirasidagi toʻlovlar va oʻyinlarni ushlab turadi hamda toʻliq audit va kuzatuv orqali hodisalarni tezda tekshirishga yordam beradi.

Contact

Biz bilan bog‘laning

Har qanday savol yoki yordam bo‘yicha bizga murojaat qiling.Doimo yordam berishga tayyormiz.

Integratsiyani boshlash

Email — majburiy. Telegram yoki WhatsApp — ixtiyoriy.

Ismingiz ixtiyoriy
Email ixtiyoriy
Mavzu ixtiyoriy
Xabar ixtiyoriy
Telegram ixtiyoriy
@
Agar Telegram qoldirilgan bo‘lsa — javob Email bilan birga o‘sha yerga ham yuboriladi.
WhatsApp ixtiyoriy
Format: mamlakat kodi va raqam (masalan, +998XXXXXXXX).

Yuborish orqali ma'lumotlaringiz qayta ishlanishiga rozilik bildirasiz.