GH GambleHub

جدار الحماية وتصفية حركة المرور

(القسم: التكنولوجيا والهياكل الأساسية)

موجز

جدار الحماية ليس صندوقًا واحدًا على المحيط، ولكنه نموذج تصفية متعدد الطبقات من L3-L4 إلى L7: مجموعات الأمن السحابي/NACL، وسياسات الشبكة في Kubernetes، والتحكم في الخروج، وإدارة WAF والروبوت على حافة الهاوية، و mTLS/source-truth للخدمة إلى الخدمة. بالنسبة إلى iGaming، فإن المفتاح هو حماية تدفقات الدفع ومقدمي الألعاب، والسياسة الجغرافية، والتحكم في DNS وإمكانية المراقبة (من وأين ومتى ولماذا).


1) الأهداف والمبادئ

رفض افتراضي: افتراضيًا، نسمح بالحد الأدنى المطلوب.
الدفاع في العمق - نفس السياسات على المحيط والسحابة والعنقود والتطبيق.
الخروج أولاً: حركة الإخراج هي نفس مخاطر الإدخال (PSP، مزودي الألعاب، البريد، التحليلات).
الهوية> العنوان: حيثما أمكن، إذن بالهوية (mTLS/Spiffe) بدلاً من IP العاري.
إمكانية الملاحظة والتدقيق: سجلات القرارات (السماح/الرفض)، والآثار، والارتباط بالحوادث.


2) خريطة طبقات الترشيح

1. الحافة: CDN/WAF/DDoS/حماية الروبوت، قواعد L7، إنهاء TLS.
2. السحابة: قواعد مجموعات الأمن/NACL/Firewall على مستوى VPC/subnet/VM.
3. المجموعة: Kubernetes NetworkPolicy, service mesh (Envoy/Istio) with mTLS and L7 filter.
4. المضيف: iptables/nftables/ufw، مرشحات العامل eBPF.
5. التطبيق: حد المعدل/الخصوصية/WAF داخل التطبيق، قوائم المجالات للخروج.
6. DNS: الأفق المنقسم، الحلول اللويزية، كتلة مجالات/أنواع المخاطر.


3) المحيط: WAF و DDoS وإدارة الروبوت

WAF: التوقيعات الأساسية + القواعد الجمركية لواجهة برمجة التطبيقات (مخططات JSON، الطرق/نوع المحتوى).
الروبوتات: التسجيل السلوكي، بصمة الجهاز، الكابتشا الديناميكية للحالات الشاذة.
DDoS: L3/4 (volum/synapse) و L7 (فيضانات HTTP) - التخلص التلقائي على الحافة.
Geo/ASN: نحد من المناطق/الأنظمة المستقلة للمناطق المحفوفة بالمخاطر (على سبيل المثال، لوحة إدارية).

مثال (NGINX + ModSecurity، فكرة JSON-API):
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

Security Group (stateful) - filters by port/protocol/section.
NACL (عديم الجنسية) - تصفية شبكية تقريبية للشبكات الفرعية.

مثال (بشروط YAML) SG لـ API:
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 المنفصلة و ext-allowists لنطاقات محددة من PSP/مزود اللعبة. التحديثات - عبر IaC والمراجعة.


5) Kubernetes: NetworkPolicy and Service Mesh

وتقيد سياسة الشبكة L3/4 داخل المجموعة ؛ افتراضيًا «الجميع يتحدث إلى الجميع» - قريب.

إنكار كل شيء + القرار ضروري فقط:
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 }]
تضيف شبكة الخدمة (Istio/Linkerd/Consul):
  • يوجد mTLS في كل مكان (مصادقة الخدمة حسب الهوية، وليس IP).
  • L7 الترشيح (الطرق/المضيف/المسارات/الرؤوس)، قاطع الدائرة، الطرد الخارجي.
  • سياسات الوصول حسب حساب الخدمة/معرف Spiffe.
مثال (Istio AfformiationPolicy):
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

مثال على nftables (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; }
}
}

وتوفر عوامل إي بي بي إف (Cilium، إلخ) سياسات L3-L7 رقيقة ورؤية (التدفقات، DNS، البيانات الوصفية HTTP).


7) أدلة التحكم في الخروج والوجهة

مجالات Allowlist/IP للمكالمات الخارجية (PSP، البريد، KYC، مزودي الألعاب).
سياسات تثبيت DNS/SNI: يتم حلها فقط من خلال جهاز حل موثوق به ؛ حظر خروج بروتوكول الإنترنت الخام.
خروج 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/البادئات ؛ حدود الطلب - حسب الهوية (الحساب/المستأجر/المفتاح).
مفاتيح الخصوصية لعمليات الدفع في POST بحيث لا تؤدي عمليات إعادة الدفع إلى تكرار.
دلو متسرب/رمزي مع نفث ؛ أثناء التدهور - «الإجابات الرمادية «/الكابتشا/التباطؤ.


10) أمن DNS

يُسمح فقط بحلول الشركات (VPC resolver/CoreDNS).
انقسام الأفق: الأسماء الداخلية لا تحل من الخارج.
حظر فئات TLD/الضارة، وحظر DoH/DoT من الموقد.
طلبات قطع الأشجار والتنبيه حسب الحالات الشاذة (مجالات جديدة، NXDOMAIN متكررة).


11) السجلات وقابلية الملاحظة والاختبار

سجلات جدار الحماية (السماح/الرفض، القواعد، البايت)، تدقيق WAF، سجلات DNS → SIEM/SOAR.
النماذج: مقاييس القفل مع «trace _ id» → قفزة سريعة في تتبع استعلام المشكلة.
المواد التركيبية: عمليات فحص منتظمة لتوافر PSP/مزودي الألعاب من المناطق الصحيحة.
اختبارات فوضى الشبكة: فقدان الحزم، أخطاء RTT، DNS - تحقق من رد فعل القواعد والمعالجة التلقائية.


12) الأتمتة و IaC

جميع القواعد مثل الرمز (Terraform/Ansible/Helm/Kyverno/Gatekeeper).
مراجعة سحب الطلب مع السياسات الأمنية (OPA).
الإصدار والتعليق - علامات أي تغيير في القاعدة على الرسوم البيانية.
تغييرات الكناري: طرح سياسات الشبكة تدريجياً (مساحة الاسم/الملصق، 5-10٪ من الملاعب).


13) تفاصيل iGaming

طرق الدفع (PSP): مجموعات الخروج الفردية، الصارم، مراقبة الرمز/المهلة.
مزودو الألعاب: تحديد مجالات CDN في القائمة البيضاء، والحماية من عمليات إعادة التوجيه المفاجئة.
القواعد الجغرافية: الامتثال للقيود المحلية، كتل المناطق على الحافة.
Backoffice/KYC: الوصول فقط من الشبكات الموثوقة/عبر معقل + MFA.
الاحتيال: حدود السرعة على L7 والطلبات «الثقيلة» لواجهة برمجة التطبيقات للمصادر غير الطبيعية.


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. Ext-alowist to PSP/providers، تم حلها فقط من خلال DNS الموثوق بها.
3. WAF/إدارة الروبوت/DDoS على حافة الهاوية، قواعد L7 لـ REST/JSON والتنزيلات.
4. MTLS بين الخدمات، تصريح الهوية (Spiffe/SA).
5. حد السعر/الحصص على حافة الهاوية وفي التطبيق، مفاتيح الخصوصية للمدفوعات.
6. سياسات DNS: حظر وزارة الصحة/وزارة التجارة، تقسيم الأفق، قطع الأشجار.
7. الجذوع و SIEM: جمع مركزي يسمح/يرفض/WAF/DNS، تنبيهات للحالات الشاذة.
8. عمليات IaC: رمز القاعدة، مراجعة العلاقات العامة، قوائم الكناري، الشروح.
9. الاختبارات/الفوضى: فشل RTT/lost/DNS، والتحقق من الطرق الاحتياطية والنصوص التلقائية.
10. مراجعة الحسابات المنتظمة: مراجعة القواعد غير المستخدمة، تناوب عناوين PSP/CDN.


16) الأنماط المضادة

«افتح كل شيء وأمل لـ WAF» - لن يوفر المحيط حركة المرور الداخلية.
لا يوجد تحكم بالخروج - نفق أنبوب للخارج leaks/C2.
اسمح للجميع NetworkPolicy في Kubernetes - الحركة الجانبية مضمونة.
تصفية IP فقط في عالم CDN/PSP الديناميكي بدون تحكم في المجال/DNS.
نقطة إنهاء TLS الوحيدة بدون mTLS بالداخل هي استبدال الخدمة.
تغييرات في القاعدة اليدوية في المبيعات بدون شهادة التأهيل/مراجعة الحسابات - عدم قابلية الاستنساخ والديون.
سجلات جدار الحماية «إلى أي مكان» - بدون إمكانية الملاحظة فهي مجرد «صندوق أسود».


النتائج

الترشيح الفعال لحركة المرور هو النسيج المعماري للمنصة: من edge-WAF و cloud SG إلى NetworkPolicy و mTLS داخل المجموعة، مع تحكم صارم بالخروج إلى PSP/المزودين والإدارة عبر IaC. يقلل مثل هذا النظام من مخاطر التسريبات والهجمات، ويحتفظ بالمدفوعات والألعاب داخل SLO ويساعد على التحقيق السريع في الحوادث من خلال التدقيق والمراقبة الكاملة.

Contact

اتصل بنا

تواصل معنا لأي أسئلة أو دعم.نحن دائمًا جاهزون لمساعدتكم!

بدء التكامل

البريد الإلكتروني — إلزامي. تيليغرام أو واتساب — اختياري.

اسمك اختياري
البريد الإلكتروني اختياري
الموضوع اختياري
الرسالة اختياري
Telegram اختياري
@
إذا ذكرت تيليغرام — سنرد عليك هناك أيضًا بالإضافة إلى البريد الإلكتروني.
WhatsApp اختياري
الصيغة: رمز الدولة + الرقم (مثال: +971XXXXXXXXX).

بالنقر على الزر، فإنك توافق على معالجة بياناتك.