دليل

حماية FiveM من هجمات DDoS: ما الهجمات التي تصيب السيرفر وما الذي يوقفها

سيرفر FiveM سهل العثور عليه وسهل استهدافه: عنوانه موجود في قائمة السيرفرات، وفي سجل الاتصال لدى كل لاعب، وغالبًا في Discord. يشرح هذا الدليل الأنواع الثلاثة من الهجمات التي تصل إلى سيرفرات FiveM، وأيها توقفه شبكة فلترة وأيها عليك التعامل معه بنفسك، والإعدادات التي تسد هذه الثغرات. أسماء المتغيرات (convars) وقيمها الافتراضية مأخوذة من توثيق Cfx.re كما هو في نوفمبر 2026.

بقلم فريق Evorxaتاريخ النشر

كيف تُهاجَم سيرفرات FiveM

يستقبل FXServer حركة اللعب على منفذ واحد لكل من TCP وUDP، وهو 30120 افتراضيًا، كما يظهر في السطرين endpoint_add_tcp وendpoint_add_udp في ملف server.cfg النموذجي. ويخدم المنفذ نفسه أيضًا نقاط HTTP مثل /info.json و/players.json و/dynamic.json: يجلب العميل /info.json قبل أن ينضم، وتستعلم قائمة سيرفرات Cfx.re من السيرفر بشكل دوري عن بيانات مثل عدد اللاعبين. أما txAdmin، لوحة الويب التي تستخدمها معظم السيرفرات، فيستمع على المنفذ 40120 افتراضيًا. تستهدف الهجمات هذه الواجهات بثلاث طرق.

  1. هجمات إغراق UDP الحجمية على المنفذ 30120 أو على عنوان IP كله. الهدف هو ملء خط الشبكة الخاص بالسيرفر. وما إن يمتلئ الخط حتى لا يستطيع أي شيء على السيرفر المساعدة، لأن البيانات العبثية تصل قبل أن يتمكن أي إعداد من التدخل.
  2. إغراق الاتصالات: عدد كبير من اتصالات TCP أو محاولات الاتصال بالمنفذ 30120. تستهلك خانات الاتصال والذاكرة والمعالج، بينما قد يبدو خط الشبكة نفسه هادئًا.
  3. إغراق HTTP (الطبقة 7): طلبات تبدو سليمة إلى نقاط .json أو إلى صفحة تسجيل الدخول في txAdmin، وغالبًا ما تُرسَل عبر بروكسيات مفتوحة. كل طلب صغير، لكن الرد على آلاف منها في الثانية يُبقي السيرفر مشغولًا.

وهناك نوع رابع من الإساءة ليس هجوم DDoS لكنه يبدو كذلك: عميل متصل يُغرق السيرفر بأحداث الشبكة (network events) أو بتغييرات الحالة عبر الموارد (resources) الخاصة بك. يأتي ذلك عبر اتصال اللعبة العادي، لذلك لا يراه أي فلتر شبكة.

ما الذي تفعله الفلترة على حافة الشبكة وما الذي لا تفعله

فلترة DDoS على حافة الشبكة تعني أن حركة المرور المتجهة إلى عنوان IP الخاص بك تمر عبر شبكة تنقية قبل أن تصل إلى السيرفر. تملك هذه الشبكة سعة تفوق بكثير سعة خط سيرفر واحد، لذا تستطيع استيعاب هجوم إغراق حجمي، وإسقاط الحزم التي لا تشبه البروتوكول المستخدم على ذلك المنفذ، وتمرير الباقي.

ما تتعامل معه جيدًا

  • هجمات إغراق UDP وTCP الحجمية التي قد تملأ خط الشبكة لديك.
  • الحزم ذات المصدر المزيّف (spoofed) والحزم المشوّهة، وحركة المرور إلى منافذ لا تستخدمها.
  • الأعداد الكبيرة من الاتصالات القادمة من مصدر واحد، في حدود ما يستطيع الفلتر تمييزه.

ما لا تستطيع فعله نيابة عنك

  • حماية عنوان IP يصل إليه المهاجم من طريق آخر، مثل عنوان ثانٍ للسيرفر نفسه، أو بروكسي يمرّر الحركة إلى السيرفر الأصلي دون فلترة.
  • التمييز بين كل بوت ولاعب حقيقي عندما يتحدث البوت البروتوكول بشكل صحيح. يصل جزء من هذا الحمل إلى السيرفر رغم ذلك، ولهذا توجد الحدود على جانب السيرفر المذكورة أدناه.
  • إيقاف الإساءة من لاعبين متصلين بالفعل. إغراق الأحداث (event spam) والثغرات في الموارد مشكلة في السكربتات.
  • حماية خدمات تركتها مفتوحة: SSH، أو منفذ قاعدة بيانات، أو txAdmin مفتوحًا للعالم.

إعدادات server.cfg

هذه الأسطر مأخوذة من مرجع أوامر السيرفر. لا تكلّف شيئًا، وتجعل استيعاب هجمات إغراق الاتصالات وHTTP التي تتجاوز حافة الشبكة أقل كلفة.

server.cfg
# game traffic on one port, TCP and UDP (the defaults)
endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

# concurrent TCP connections allowed per IP (default 16)
net_tcpConnLimit 16

# block IPs whose HTTP requests carry a 'Via' header
set sv_requestParanoia 1

# hide player IP addresses from public reports
set sv_endpointPrivacy true

# leave RCON off unless you use it
#set rcon_password ""
  • net_tcpConnLimit يضع حدًا أقصى لاتصالات TCP المتزامنة لكل عنوان IP. القيمة الافتراضية 16. لا تخفّضها إلا إذا كنت متأكدًا من أنه لا يوجد لاعبون شرعيون يتشاركون عنوانًا واحدًا؛ فاللاعبون خلف راوتر واحد أو خلف NAT لدى شركة الاتصالات يتشاركون عنوان IP.
  • sv_requestParanoia تتراوح قيمته من 0 (معطّل، وهو الافتراضي) إلى 3. المستوى 1 يحظر عناوين IP التي ترسل ترويسة Via، وهي ترويسة تضيفها البروكسيات إلى الطلبات التي تمرّرها. المستوى 2 يحظر أيضًا الطلبات التي تحمل ترويسة Upgrade-Insecure-Requests، وهذا يشمل كل من يفتح إحدى نقاط .json في المتصفح. المستوى 3 يغلق المقبس (socket) أيضًا. ابدأ بالمستوى 1.
  • sv_endpointPrivacy true يُخفي عناوين IP الخاصة باللاعبين من التقارير العامة للسيرفر، حتى لا يصبح لاعبوك الهدف التالي.

تحصل السيرفرات العاملة على FiveM for GTAV Enhanced أيضًا على محددات معدل من نوع token bucket للمصافحات (handshakes) ونقاط HTTP وأحداث الشبكة (net events) وstate bags وRCON. لكل محدد معدل (rate، أي عدد الرموز في الثانية) ودفعة (burst، أي الحد الأقصى للرموز)؛ والطلب الذي لا يجد رمزًا متبقيًا يُقيَّد معدله. من القيم الافتراضية 4 في الثانية مع دفعة 10 لكل من http_info وhttp_players، و50 في الثانية مع دفعة 200 لـ netEvent. ويذكر المرجع أن هذه الأوامر حصرية لإصدار Enhanced.

server.cfg (Enhanced)
# FiveM for GTAV Enhanced only
# set rateLimiter_<name>_rate  <tokens per second>
# set rateLimiter_<name>_burst <maximum tokens>
set rateLimiter_netEvent_rate 100
set rateLimiter_netEvent_burst 400

لا تغيّرها إلا عندما يُظهر الكونسول محددًا يُسقط حركة مرور تعرف مصدرها. رفع netEvent لكي يعمل مورد مزدحم يمنح أيضًا العميل الذي يُغرق السيرفر مساحة أكبر.

قواعد الجدار الناري على السيرفر

أغلق كل ما لا يحتاجه اللاعبون. يحتاج اللاعبون المنفذ 30120 عبر TCP وUDP. وتحتاج أنت SSH وtxAdmin، ولا أحد غيرك يحتاجهما. على Ubuntu أو Debian مع ufw، أضف قاعدة SSH الخاصة بك قبل ufw enable، وإلا فستمنع نفسك من الدخول:

shell
# replace 203.0.113.10 with your own public IP
ufw default deny incoming
ufw default allow outgoing
ufw allow from 203.0.113.10 to any port 22 proto tcp
ufw allow 30120/tcp
ufw allow 30120/udp
ufw allow from 203.0.113.10 to any port 40120 proto tcp
ufw enable
ufw status verbose

لا تحظر الخوادم الخلفية لـ Cfx.re. تستعلم قائمة السيرفرات من سيرفرك انطلاقًا من العناوين المنشورة في static.cfx.re/ips.txt، وتقول Cfx.re إن أي جدار ناري صارم أو فلتر DDoS يجب أن يسمح بها كلها. تُضاف العناوين الجديدة قبل شهر على الأقل من بدء وصول الحركة منها، لذا زامن القائمة وفق جدول زمني منتظم.

منفذ txAdmin هو 40120 ما لم تغيّره عبر TXHOST_TXA_PORT، ولا يمكن أن يكون 30120، وفقًا لـ مرجع متغيرات البيئة في txAdmin. إذا كان عنوان IP الخاص بك يتغير كثيرًا، فأبقِ المنفذ 40120 مغلقًا تمامًا وادخل إلى اللوحة عبر نفق SSH:

shell
# open txAdmin through SSH instead of the internet
ssh -L 40120:127.0.0.1:40120 root@your-server-ip
# then browse to http://localhost:40120

على Windows Server توضع القواعد نفسها في Windows Defender Firewall: اسمح بالمنفذ 30120 عبر TCP وUDP من أي مكان، وبالمنفذين 3389 و40120 من عنوانك أنت فقط.

إبقاء عنوان IP الأصلي مخفيًا

لا تنفع الفلترة إلا إذا كانت حركة الهجوم مضطرة إلى المرور عبرها. عندما تكون الحماية على عنوان IP الخاص بالسيرفر نفسه، تُفلتَر كل حزمة متجهة إلى ذلك العنوان ويصبح الإخفاء أقل أهمية. أما عندما تضع بدلًا من ذلك بروكسي منفصلًا أمام السيرفر، فيجب أن يبقى العنوان الحقيقي (الأصل، أو origin) سرًا، لأن المهاجم الذي يعرفه يستطيع تجاوز البروكسي.

يصف دليل إعداد البروكسي من Cfx.re نوعين من البروكسي: بروكسي HTTPS لنقطة الاتصال (connect endpoint)، وبروكسي TCP وUDP خام على منافذ مطابقة لحركة اللعب. عندما يكون الاثنان قائمين، تمنع هذه المتغيرات FXServer من الإعلان عن عنوانه الخاص:

server.cfg
# stop the server list from advertising the real IP
set sv_forceIndirectListing true

# the hostname the server list backend should query
set sv_listingHostOverride "play.example.com"

# your proxy addresses in CIDR notation (trusted for X-Real-IP)
set sv_proxyIPRanges "198.51.100.7/32"

# the UDP endpoint players are given: the proxy, not the origin
set sv_endpoints "198.51.100.7:30120"

ينضم اللاعبون بعد ذلك عبر connect "https://play.example.com/"؛ ويشير الدليل إلى أن اسم المضيف المجرد مثل play.example.com يتحول بدلا من ذلك إلى http://play.example.com:30120/. ثم أغلق مصادر التسريب المعتادة:

  • سجلات DNS القديمة. إذا كان أحد النطاقات قد أشار يومًا مباشرة إلى السيرفر الأصلي، فافترض أن العنوان معروف وغيّره بعد تشغيل البروكسي.
  • الخدمات الأخرى على عنوان IP نفسه: موقع ويب، أو بوت Discord، أو قاعدة بيانات، أو سيرفر بريد.
  • الموارد التي تتصل بواجهات API أو webhooks خارجية. تخرج تلك الطلبات من عنوان IP الأصلي، ويراها من يدير الطرف الآخر.
  • عناوين connect المباشرة التي نُشرت في Discord أو في المنتديات قبل انتقالك إلى ما وراء البروكسي.

ما الذي تسأل عنه الاستضافة قبل الشراء

  1. هل الفلترة مفعّلة دائمًا، أم تبدأ بعد اكتشاف الهجوم؟ إذا كانت تبدأ لاحقًا، فكم من الوقت تستغرق؟
  2. هل تغطي UDP على منافذ الألعاب، أم حركة الويب أساسًا؟ يحتاج FiveM إلى فلترة UDP على المنفذ 30120 دون كسر المصافحة (handshake).
  3. ما سعة الفلترة، وماذا يحدث عند تجاوزها؟ بعض المزودين يوجّهون عنوان IP إلى مسار فارغ (null-route)، مما يُخرج سيرفرك عن الخدمة حتى يتوقف الهجوم.
  4. هل يوجد أمام السيرفر جدار ناري تتحكم فيه أنت، لكل منفذ وبروتوكول؟
  5. هل يمكنك أن ترى متى وقع الهجوم وما حجمه؟ من دون ذلك لا تستطيع التمييز بين هجوم وخلل في أحد الموارد.
  6. هل يتبقى ما يكفي من سرعة المعالج في الخيط الواحد (single-thread) ومن RAM للسيرفر نفسه؟ الحماية لا تفيد سيرفرًا وصل إلى حده أصلًا.

FiveM على Evorxa

تقع سيرفرات Evorxa خلف Shield، نظام فلترة DDoS الخاص بـ Evorxa، بسعة تنقية تبلغ 3 Tbps. تعمل السيرفرات في منطقة واحدة هي Eygelshoven بهولندا؛ ومواقع حافة CDN التابعة لـ Shield منفصلة عن منطقة السيرفرات هذه. تعرض صفحة استضافة FiveM خططًا بأنوية مشتركة (VPS) وبأنوية مخصصة عالية التردد (VDS)، مدفوعة مسبقًا شهريًا أو لستة أشهر أو سنويًا، مع صلاحيات root كاملة لتطبيق الإعدادات المذكورة أعلاه.

المصادر

المعلومات في هذا الدليل مأخوذة من هذه الصفحات.

  1. توثيق Cfx.re: أوامر السيرفر (convars ومحددات المعدل)
  2. توثيق Cfx.re: إعداد البروكسي
  3. توثيق Cfx.re: عناوين IP الثابتة (ips.txt)
  4. Cfx.re: ملف server.cfg نموذجي
  5. txAdmin: إعداد متغيرات البيئة