فایروال و فیلتر ترافیک

(بخش: تکنولوژی و زیرساخت)

خلاصه ای کوتاه

فایروال یک جعبه در محیط نیست، بلکه یک مدل فیلتر لایه ای از L3-L4 به L7 است: گروه های امنیتی ابر/NACL، سیاست های شبکه در Kubernetes، کنترل خروج، WAF و مدیریت ربات در لبه، و mTLS/source-truth برای سرویس به سرویس. برای iGaming، کلید حفاظت از جریان پرداخت و ارائه دهندگان بازی، سیاست جغرافیایی، کنترل DNS و قابلیت مشاهده (چه کسی، کجا، چه زمانی و چرا) است.

1) اهداف و اصول

به طور پیش فرض انکار: به طور پیش فرض، ما اجازه می دهیم حداقل مورد نیاز است.
دفاع در عمق - سیاست های مشابه در محیط، ابر، خوشه و برنامه.
خروج اول: ترافیک خروجی همان خطر ورودی است (PSP، ارائه دهندگان بازی، ایمیل، تجزیه و تحلیل).
هویت> آدرس: در صورت امکان، اجازه دادن به هویت (mTLS/Spiffe) به جای IP خالی.
قابلیت مشاهده و حسابرسی: گزارش های تصمیم گیری (اجازه/انکار)، ردیابی، ارتباط با حوادث.

2) نقشه لایه های فیلتراسیون

1. لبه: حفاظت CDN/WAF/DDoS/bot، قوانین L7، خاتمه TLS.
2. Cloud: Security Groups/NACL/Firewall Rules در سطح VPC/subnet/VM.
3. خوشه: Kubernetes NetworkPolicy، مش سرویس (Envoy/Istio) با فیلترهای mTLS و L7.
4. میزبان: iptables/nftables/ufw، فیلتر eBPF عامل.
5. کاربرد: rate-limit/idempotency/WAF در برنامه، لیست دامنه برای خروج.
6. DNS: split-horizon، allowlist resolvers، block of risk domains/types.

3) محیط: WAF، DDoS و مدیریت ربات

WAF: امضاهای اساسی + قوانین سفارشی برای API (طرح های JSON، روش ها/نوع محتوا).
رباتها: به ثمر رساند رفتاری، اثر انگشت دستگاه، captcha پویا برای ناهنجاری.
DDoS: L3/4 (volum/synapse) و L7 (HTTP flood) - دور ریختن خودکار در لبه.
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) ابر: گروه های امنیتی و NACL

گروه امنیتی (stateful) - فیلترها بر اساس پورت/پروتکل/بخش.
NACL (بدون حالت) - فیلتر کردن مش مش از زیر شبکه ها.

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

تمرین: برای پرداخت نگه دارید SGs جداگانه و خروج allowlists برای PSP خاص/محدوده ارائه دهنده بازی. به روز رسانی - از طریق IaC و بررسی.

5) Kubernetes: NetworkPolicy و مش سرویس

NetworkPolicy L3/4 درون خوشه را محدود می کند. به طور پیش فرض «همه با همه صحبت می کنند» - close.

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 (روش ها/میزبان ها/مسیرها/هدر ها)، قطع کننده مدار، تخلیه بیرونی.
• سیاست های دسترسی توسط حساب خدمات/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 نازک و دید (جریان، DNS، ابرداده HTTP) را فراهم می کنند.

7) دایرکتوری های کنترل و مقصد را کنترل کنید

Allowlist domains/IP برای تماس های خارجی (PSP، ایمیل، KYC، ارائه دهندگان بازی).
سیاست های DNS پینینگ/SNI: حل و فصل تنها از طریق یک حل کننده قابل اعتماد ؛ ممنوعیت IP-خروج خام.
VPC/VNet جداگانه برای پرداخت، بازی و مدارهای عمومی جدا کنید.
پروکسی با بازرسی TLS برای ترافیک غیر PII ؛ جریان پرداخت - بدون MITM، فقط mTLS/PII مستقیم.

8) TLS/mTLS و سیاست رمزنگاری

TLS 1. 2 +، رمزهای مدرن، مهر و موم OCSP، HSTS.
mTLS در داخل - اتصال به Spiffe ID/صدور گواهینامه حساب های خدمات.
چرخش گواهی به طور منظم و تایید زنجیره اعتماد.
CORS/CSP در پروکسی L7 برای کاهش منابع حمله در جلو.

9) نرخ محدود و L7-quotas

محدودیت های لبه توسط IP/ASN/پیشوندها ؛ محدودیت درخواست - با هویت (حساب/مستاجر/کلید).
کلید های idempotency برای عملیات پرداخت POST به طوری که بازپرداخت تکراری ایجاد نمی کند.
سطل نشتی/نشانه با لرزش ؛ در طول تخریب - «پاسخ خاکستری «/captcha/کاهش سرعت.

10) امنیت DNS

فقط حل کننده های شرکتی (حل کننده VPC/CoreDNS مطرح شده) مجاز هستند.
Split-horizon: نام های داخلی از خارج حل نمی شوند.
مسدود کردن TLD/دسته های مضر، ممنوعیت DoH/DoT از قلب خارج.
ثبت درخواست ها و هشدار توسط ناهنجاری ها (دامنه های جدید، NXDOMAIN مکرر).

11) سیاهههای مربوط، مشاهده و آزمایش

سیاهههای مربوط به فایروال (اجازه/انکار، قوانین، بایت)، حسابرسی WAF، سیاهههای مربوط به DNS → SIEM/SOAR.
Exemplars: معیارهای قفل با «trace _ id» → پرش سریع به ردیابی پرس و جو مشکل.
Synthetics: بررسی منظم در دسترس بودن ارائه دهندگان PSP/بازی از مناطق مناسب.
تست هرج و مرج شبکه: از دست دادن بسته، RTT، خطاهای DNS - بررسی واکنش قوانین و خودکار اصلاح.

12) اتوماسیون و IAc

همه قوانین مانند کد (Terraform/Ansible/Helm/Kyverno/Gatekeeper) هستند.
Pull-request-review with security policies (OPA) را انتخاب کنید.
Versioning and Annotation-Marks هر گونه تغییر قانون در نمودار.
تغییرات قناری: سیاست های شبکه را به تدریج گسترش دهید (فضای نام/برچسب، 5-10٪ از زمین ها).

13) ویژگی های iGaming

مسیرهای پرداخت (PSP): گروه های خروجی فردی، allowlist دقیق، نظارت بر کد/زمان.
ارائه دهندگان بازی: لیست سفید دامنه CDN، حفاظت در برابر تغییر مسیر ناگهانی.
قوانین جغرافیایی: انطباق با محدودیت های محلی، بلوک های مناطق در لبه.
Backoffice/KYC: دسترسی فقط از شبکه های قابل اعتماد/از طریق bastion + MFA.
تقلب: محدودیت سرعت در 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

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. به طور پیش فرض در سطح ابر (SG/NACL)، خوشه (NetworkPolicy) و میزبان ها انکار می شود.
2. خروج allowlist به PSP/ارائه دهندگان، حل و فصل تنها از طریق DNS مورد اعتماد است.
3. مدیریت WAF/bot/DDoS در لبه، قوانین L7 برای REST/JSON و دانلود.
4. mTLS بین خدمات، مجوز هویت (Spiffe/SA).
5. نرخ محدود/سهمیه در لبه و در برنامه, idemotency-کلید برای پرداخت.
6. سیاست های DNS: ممنوعیت DoH/DoT، تقسیم افق، ورود به سیستم.
7. سیاهههای مربوط و SIEM: مجموعه متمرکز اجازه/انکار/WAF/DNS، هشدار برای ناهنجاری.
8. فرآیندهای IaC: کد قانون، بررسی PR، رول قناری، حاشیه نویسی.
9. تست/هرج و مرج: خرابی RTT/loss/DNS، بررسی مسیرهای برگشت و اسکریپت های خودکار.
10. ممیزی منظم: ممیزی قوانین استفاده نشده، چرخش آدرسهای PSP/CDN.

16) ضد الگوهای

«باز کردن همه چیز و امید برای WAF» - محیط ترافیک داخلی را نجات دهد.
بدون کنترل خروج - تونل لوله به سمت خارج برای leaks/C2.
Allow-all NetworkPolicy در Kubernetes - حرکت جانبی تضمین شده است.
فیلتر کردن فقط IP در جهان CDN/PSP پویا بدون کنترل دامنه/DNS.
تنها نقطه پایانی TLS بدون mTLS در داخل جایگزینی سرویس است.
تغییرات قانون دستی در فروش بدون IaC/حسابرسی - غیر قابل تکرار و بدهی.
گزارش فایروال «به هیچ وجه» - بدون مشاهده آن فقط یک «جعبه سیاه» است.

نتایج به دست آمده

فیلتر ترافیک کارآمد ساختار معماری پلت فرم است: از لبه WAF و ابر SG به NetworkPolicy و mTLS در داخل خوشه، با کنترل خروج شدید به PSP/ارائه دهندگان و مدیریت از طریق IaC. چنین سیستمی خطر نشت و حملات را کاهش می دهد، پرداخت ها و بازی ها را در SLO نگه می دارد و از طریق ممیزی و نظارت کامل به بررسی سریع حوادث کمک می کند.