أدوات الحماية من DDoS بين الخدمات المدارة وسيرفرك

هذا هو الجزء الأخير من سلسلة DDoS، ففي الجزء الأول شرحنا أنواع الهجوم، وفي الجزء الثاني أسقطنا هدفاً نملكه في مختبر معزول بثلاثة أنماط، وفي الجزء الثالث رتبنا طبقات الدفاع من حيث المبدأ. والآن نسمي الأدوات: الخدمات المدارة بأسعارها كما قرأناها في أكتوبر 2026، ثم الطبقة التي تبنيها على سيرفرك، ثم نعيد هجمات الجزء الثاني نفسها على الهدف نفسه بعد كل دفاع، ونقيس الفرق بأرقام قبل وبعد.

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

وسوف نناقش في هذا المقال ما يلي:

• الخدمات المدارة: Cloudflare وAWS Shield وAzure DDoS Protection وGoogle Cloud Armor وAkamai، وما تشمله كل خطة وسعرها.
• الطبقة على سيرفرك: nftables وXDP، وnginx، وHAProxy، والتخزين المؤقت، وCrowdSec، وFastNetMon.
• مختبر قبل وبعد: SYN Cookies، ومهل الترويسات وحد الاتصالات، وحد المعدل، وال Cache، وHAProxy، وnftables.
• أخطاء شائعة، منها خطأ وقعنا فيه في المختبر نفسه.

الخدمات المدارة: من يتحمل الحجم عنك

الخدمة المدارة هي الطريقة الوحيدة العملية لمؤسسة صغيرة أو متوسطة لتتحمل هجوماً حجمياً، لأنها تبيعك سعة شبكتها لا برنامجاً. والصورة التالية تبين أين تقف هذه الخدمات وأين تقف الأدوات التي على سيرفرك:

والجدول التالي يلخص ما قرأناه في صفحات الأسعار الرسمية في 12 أكتوبر 2026، والأسعار بالدولار الأمريكي وقد تتغير، فارجع إلى الصفحة قبل أي قرار:

والمصادر: خطط Cloudflare، وأسعار AWS Shield، وأسعار Azure DDoS Protection، وأسعار Cloud Armor حيث السعر بالساعة 0.274 دولار لـ Paygo و4.11 دولار لـ Annual، وضربناه في 730 ساعة. وقد شرحنا ما تقدمه Cloudflare مقارنة بالبدائل المفتوحة في خدمات Cloudflare وبدائلها، وطريقة إعدادها الصحيح في دليل إعداد Cloudflare.

وقد يتساءل البعض: لماذا أدفع 3,000 دولار شهرياً لـ Shield Advanced إذا كانت Cloudflare تحمي مجاناً دون حد؟ والإجابة أن السؤال ليس في الحماية من الحجم وحدها، فالخطط المتقدمة تبيع ثلاثة أشياء أخرى: فريق استجابة تتصل به أثناء الهجوم، وحماية من فاتورة التوسع التي تسبب بها الهجوم، وحماية لما ليس ويب مثل عناوين IP لسيرفرات وألعاب وخدمات UDP. فإذا كانت خدمتك موقع ويب يمر عبر ال Proxy فالخطة المجانية أو Pro تكفي غالباً، وإذا كانت بنية سحابية كاملة بعناوين عامة كثيرة وكلفة توقف عالية فالحساب مختلف.

الطبقة على سيرفرك

هذه الأدوات لا تتحمل الحجم، ولكنها توقف ما يتجاوز الطبقات الأمامية أو ما لا يمر بها أصلاً، وتحمي الموارد التي رأيناها تسقط في الجزء الثاني. وفيما يلي كل أداة وما تحمي، مع نقاط القوة والضعف:

• nftables: الجدار الناري في نواة Linux، ويحد معدل الاتصالات الجديدة لكل منفذ أو لكل عنوان ويسقط ما زاد. نقاط القوة: في النواة نفسها، سريع، ولا يحتاج برنامجاً إضافياً. نقاط الضعف: يعمل بعد أن تصل الحزمة إلى السيرفر، أي بعد الخط، وجدول تتبع الاتصالات نفسه مورد يمتلئ.
• XDP وeBPF: برامج صغيرة تعمل في مشغل بطاقة الشبكة قبل أن تبني النواة أي حالة للحزمة، فتسقط حركة الهجوم بأرخص تكلفة ممكنة، وعليها تبنى أدوات الشركات الكبيرة. نقاط القوة: أسرع إسقاط ممكن على السيرفر. نقاط الضعف: تحتاج دعماً من النواة والمشغل وصلاحيات على الجهاز نفسه، ولم نشغلها في هذا المختبر لأننا داخل Docker Desktop على جهاز افتراضي، وما زالت بعد الخط كذلك.
• nginx: مهل الترويسات والجسم ضد الهجمات البطيئة، وlimit_conn لحد الاتصالات لكل عنوان، وlimit_req لحد معدل الطلبات، وproxy_cache لحماية التطبيق. نقاط القوة: كلها سطور في ملف تعرفه، وقد شرحنا حد المعدل في دليل حماية HTTP. نقاط الضعف: الحد لكل عنوان يرفع كلفة الهجوم الموزع ولا يلغيها.
• HAProxy: جداول Stick Tables تحفظ عدادات لكل عنوان، مثل معدل الطلبات أو عدد الاتصالات، وترفض ما يتجاوز الحد، وتشارك الجداول بين أكثر من سيرفر. وقد شرحنا تثبيته في دليل HAProxy.
• التخزين المؤقت Varnish أو nginx: كل طلب يخدم من ال Cache لا يصل إلى التطبيق، وهو أقوى دفاع ضد إغراق الطبقة السابعة على الصفحات العامة، والفكرة مشروحة في مقال ال CDN.
• CrowdSec: يقرأ السجلات ويحظر العناوين بحسب سلوكها، ويشارك قوائم العناوين المسيئة بين مستخدميه، ومحركه برخصة MIT، وإعداده مشروح في دليل حماية HTTP. نقاط الضعف: يحظر بعد أن يرى السلوك في السجل، فهو للهجمات الصغيرة المستمرة لا للطوفان المفاجئ.
• FastNetMon: يراقب الحركة من بيانات الراوتر مثل NetFlow وsFlow، ويكتشف الهجوم الحجمي خلال ثوان، ويستطيع أن يعلن عبر BGP إسقاط الحركة إلى العنوان المهاجم عند المزود. ونسخة المجتمع منه برخصة GPL-2.0. وهو مناسب لمن يملك شبكته وراوتراته واتصالاً بمزوده، لا لمن يملك VPS واحداً.

مختبر قبل وبعد

نستعمل المختبر نفسه من الجزء الثاني: شبكة lab-ddos-net عليها internal: true بلا منافذ منشورة ولا إنترنت، والتطبيق البطيء بثمانية عمال، ومولد الحمل بأدواته، ولا نهاجم إلا الهدف الذي نملكه، وبالمعدلات المنخفضة نفسها. والملفات الإضافية في مجلد lab/ بجوار هذا المقال: إعداد nginx المحمي، وقواعد nftables، وإعداد HAProxy. وفي كل تجربة نطبق دفاعاً واحداً ونعيد الهجوم نفسه.

إيقاف إغراق SYN بتقنية SYN Cookies

في الجزء الثاني كان الهدف يعمل والإعداد tcp_syncookies=0، فارتفعت الاتصالات نصف المفتوحة إلى 511 وفشل خمسة من خمسة وعشرين اتصالاً حقيقياً. والآن نعيد إنشاء الهدف بالإعداد نفسه ولكن مع SYN Cookies، والتغيير داخل ال Container فقط بالخيار --sysctl، لأن هذا الإعداد للقراءة فقط بعد التشغيل:

docker run -d --name lab-ddos-nginx --network lab-ddos-net \
  --sysctl net.ipv4.tcp_syncookies=1 --sysctl net.ipv4.tcp_max_syn_backlog=16 \
  lab-ddos-target
# الهجوم نفسه من الجزء الثاني (المولد يسقط RST الخارج منه):
docker exec -d lab-ddos-gen bash -c 'timeout 12 hping3 -S -p 80 -i u1000 lab-ddos-nginx'
# عداد SYN Cookies في النواة على الهدف:
docker exec lab-ddos-nginx grep -o "SyncookiesSent [0-9]*" /proc/net/netstat

والمقارنة بين التجربتين كما يلي:

               syncookies=0              syncookies=1
DURING         SYN_RECV=511              SYN_RECV=511
legit          ok=20 fail=5              ok=25 fail=0
SyncookiesSent 0                         9436

في الإعداد أعلاه لاحظ التالي: عدد الاتصالات نصف المفتوحة بقي 511 في الحالتين لأن الجدول امتلأ فعلاً، ولكن مع SYN Cookies لم يفشل أي اتصال حقيقي، والسبب أن النواة عندما امتلأ الجدول توقفت عن الحجز وأرسلت 9436 رداً مختوماً، فأكمل الزائر الحقيقي مصافحته دون أن يحتاج مكاناً في الجدول. ولاحظ أيضاً أن هذا الإعداد مفعل افتراضياً في Linux، فقد عطلناه في الجزء الثاني عمداً لنرى الفرق، والدرس ألا يعطله أحد على سيرفرك.

إيقاف Slowloris بمهل الترويسات وحد الاتصالات

في الجزء الثاني أسقط Slowloris الخدمة تماماً، صفر من خمسة عشر. والآن نضيف إلى nginx ثلاثة أسطر فقط ونبقي عدد الاتصالات 16 كما كان، حتى تكون المقارنة عادلة:

client_header_timeout 5s;      # أغلق الاتصال الذي لا يكمل ترويساته خلال 5 ثوان
client_body_timeout   5s;
limit_conn_zone $binary_remote_addr zone=perip:10m;
# وداخل location /
limit_conn perip 8;            # ثمانية اتصالات متزامنة على الأكثر لكل عنوان

ونعيد الهجوم نفسه بستين اتصالاً بطيئاً، والمخرج سوف يكون كما يلي:

BEFORE: legit ok=15 fail=0
DURING t=7 : legit ok=15 fail=0
DURING t=13: legit ok=15 fail=0
AFTER : legit ok=15 fail=0

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

حد المعدل ضد إغراق الطبقة السابعة

نضع على المسار /limited/ حداً بعشرين طلباً في الثانية لكل عنوان مع هامش عشرة، ونرد على الزائد بالرمز 429:

limit_req_zone $binary_remote_addr zone=reqs:10m rate=20r/s;
limit_req_status 429;
location /limited/ {
  limit_req zone=reqs burst=10 nodelay;
  proxy_pass http://app;
}

أولاً نتأكد أن الاستعمال الطبيعي لا يتأثر، فنرسل أربعين طلباً من أربعة مستخدمين متوازين، ثم نغرق المسار بـ wrk:

docker exec lab-ddos-gen bash -c 'for w in 1 2 3 4; do (for i in $(seq 1 10); do curl -s -o /dev/null -w "%{http_code}\n" http://lab-ddos-nginx/limited/; done) & done; wait' | sort | uniq -c
docker exec lab-ddos-gen wrk -t1 -c6 -d5s http://lab-ddos-nginx/limited/

والمخرج سوف يكون كما يلي:

     40 200
  57657 requests in 5.00s, 18.23MB read
  Non-2xx or 3xx responses: 57550

في الإعداد أعلاه لاحظ التالي: الطلبات الأربعون الطبيعية نجحت كلها، أما الإغراق فأرسل 57657 طلباً في خمس ثوان، رد nginx على 57550 منها بالرمز 429، ووصل إلى التطبيق 107 طلبات فقط، وهي تقريباً عشرون في الثانية مع الهامش، أي أن التطبيق ذا الثمانية عمال لم يشعر بالإغراق. والحد هنا على عنوان المولد الواحد، وتذكر حده الذي شرحناه في الجزء الثالث: إذا جاء الإغراق من آلاف العناوين فكل عنوان يبقى تحت الحد.

التخزين المؤقت ضد الإغراق نفسه

في الجزء الثاني سقط التطبيق عند 38.54 طلباً في الثانية. والآن نضع على المسار /cached/ تخزيناً مؤقتاً لعشر ثوان، ونغرقه:

proxy_cache_path /tmp/ngxcache keys_zone=z:10m max_size=50m;
location /cached/ {
  proxy_cache z;
  proxy_cache_valid 200 10s;
  add_header X-Cache $upstream_cache_status;
  proxy_pass http://app;
}

والمخرج سوف يكون كما يلي، أول طلب MISS والثاني HIT، ثم الإغراق:

X-Cache: MISS
X-Cache: HIT
DURING cached flood legit ok=15 fail=0
  170423 requests in 15.07s, 22.43MB read
Requests/sec:  11309.54

في الإعداد أعلاه لاحظ التالي: المسار نفسه الذي كان سقفه 38.54 طلباً في الثانية خدم 11309 طلبات في الثانية، ونجحت كل الطلبات الحقيقية أثناء الإغراق، والسبب أن nginx رد من ال Cache ولم يصل إلى التطبيق إلا طلب واحد كل عشر ثوان. ولهذا أول سؤال في الدفاع عن الطبقة السابعة: أي مساراتي يمكن أن تخزن؟ والمسارات التي لا تخزن، مثل البحث والدخول، هي التي تحتاج حد المعدل.

جدول Stick Table في HAProxy أمام التطبيق

نبني HAProxy من المجلد lab/haproxy ونشغله في الشبكة المعزولة نفسها أمام التطبيق، بجدول يحفظ معدل الطلبات لكل عنوان خلال عشر ثوان، ويرفض بالرمز 429 كل عنوان تجاوز مئة طلب:

frontend fe
  bind :80
  stick-table type ip size 100k expire 30s store http_req_rate(10s)
  http-request track-sc0 src
  http-request deny deny_status 429 if { sc_http_req_rate(0) gt 100 }
  default_backend be
backend be
  server app lab-ddos-app:8080 maxconn 8

docker build -t lab-ddos-haproxy lab/haproxy
docker run -d --name lab-ddos-haproxy --network lab-ddos-net lab-ddos-haproxy

ونغرقه بـ wrk لمدة 12 ثانية، والمخرج سوف يكون كما يلي:

BEFORE flood: 200=15 429=0
DURING flood, legit from same source: 200=0 429=15
  193123 requests in 12.09s, 40.88MB read
  Non-2xx or 3xx responses: 193039

في الإعداد أعلاه لاحظ التالي: رفض HAProxy 193039 طلباً من 193123، ووصل إلى التطبيق 84 طلباً فقط. ولكن لاحظ السطر الثاني جيداً: الطلبات الحقيقية من العنوان نفسه رفضت كلها، وبقيت ترفض بعد الإغراق حتى تنتهي مدة الجدول، والسبب أن المولد والزائر هنا عنوان واحد. وهذا ما يحدث في الواقع عندما يكون المهاجم والزوار خلف عنوان مشترك، مثل شبكة شركة أو مزود جوال بعنوان CGNAT، فالحد لكل عنوان قد يحظر مكتباً كاملاً، ولهذا اجعل الحد أعلى من استعمال أكبر مكتب عندك، وراقب الرفض بعد التفعيل.

حد الاتصالات الجديدة في النواة مع nftables

آخر تجربة في النواة نفسها: نقبل 25 اتصالاً جديداً في الثانية على المنفذ 80 ونسقط الباقي مع عداد. والملف التالي في lab/target/nft-ddos.nft:

# لا تستعمل flush ruleset داخل Container: يمسح قواعد Docker نفسها ومنها توجيه DNS الداخلي 127.0.0.11
table ip ddos
flush table ip ddos
table ip ddos {
  chain input {
    type filter hook input priority 0; policy accept;
    tcp dport 80 ct state new limit rate 25/second burst 20 packets accept
    tcp dport 80 ct state new counter drop
  }
}

ونطبقه ثم نغرق المنفذ باتصال جديد لكل طلب:

docker exec lab-ddos-nginx nft -f /tmp/nft-ddos.nft
docker exec lab-ddos-gen wrk -t4 -c200 -d10s --timeout 2s -H "Connection: close" http://lab-ddos-nginx/stub
docker exec lab-ddos-nginx nft list chain ip ddos input

والمخرج سوف يكون كما يلي:

legit before: ok=15 fail=0
  217 requests in 10.02s, 53.83KB read
Requests/sec:     21.67
		tcp dport 80 ct state new counter packets 933 bytes 55980 drop
legit after: ok=15 fail=0

في الإعداد أعلاه لاحظ التالي: مئتا اتصال متواز لم تتجاوز 21.67 طلباً في الثانية، وأسقطت النواة 933 حزمة SYN زائدة قبل أن تصل إلى nginx أصلاً، وعادت الخدمة طبيعية بعد الإغراق. وهذا أرخص مكان للإسقاط على السيرفر بعد XDP، ولكن تذكر أن هذا كله بعد الخط.

الخطأ الذي وقعنا فيه مع flush ruleset في المختبر

في أول نسخة من قواعد nftables بدأنا الملف بالأمر flush ruleset كما في كثير من الأمثلة، فعملت القواعد، ولكن عندما أعدنا تحميل nginx بعد ذلك ظهر الخطأ التالي:

nginx: [emerg] host not found in upstream "lab-ddos-app:8080" in /etc/nginx/nginx.conf:20
;; connection timed out; no servers could be reached

والسبب أن flush ruleset يمسح كل قواعد الشبكة في ال Container، ومنها القواعد التي يضعها Docker نفسه لتوجيه خادم DNS الداخلي على العنوان 127.0.0.11، فتوقف ال Container عن معرفة أسماء جيرانه. والحل أن تضيف جدولك الخاص وتفرغه هو فقط بـ flush table ip ddos كما في الملف أعلاه، والقاعدة نفسها على أي سيرفر عليه Docker أو أدوات أخرى تضع قواعدها: لا تمسح ما لم تكتبه أنت.

النتائج في جدول واحد

تنظيف المختبر

docker rm -f lab-ddos-haproxy
docker image rm lab-ddos-haproxy
docker compose -p lab-ddos down -v --rmi local

نحذف بالاسم فقط ما أنشأناه، ولا نستعمل أي أمر تنظيف شامل حتى لا نمس Containers وImages مشاريع أخرى على الجهاز.

أخطاء شائعة

• شراء أداة على السيرفر لصد الهجوم الحجمي: الخط يمتلئ قبل أن تعمل، والحل عند المزود أو خدمة مدارة.
• ترك عنوان السيرفر مكشوفاً خلف ال CDN: المهاجم يتجاوز كل الطبقات، فاقفل السيرفر على مزود الحماية.
• تعطيل SYN Cookies: مفعلة افتراضياً، ولا يوجد سبب لتعطيلها على سيرفر ويب.
• زيادة عدد الاتصالات بدل ضبط المهل: المهاجم البطيء يفتح اتصالات أكثر بالتكلفة نفسها.
• حد معدل منخفض على كل المسارات: يحظر الزوار الحقيقيين الذين تطلب صفحاتهم عشرات الملفات، فضعه على المسارات الغالية.
• حد لكل عنوان دون التفكير في العناوين المشتركة: مكتب كامل خلف عنوان واحد قد يحظر كما رأينا في HAProxy.
• flush ruleset على سيرفر عليه Docker: يمسح قواعد Docker ومنها DNS الداخلي، فامسح جدولك فقط.

الخلاصة

• ما هو أكبر من خطك لا توقفه إلا خدمة مدارة أو مزودك، وCloudflare تحمي دون حد في كل خططها، وShield Advanced وCloud Armor Enterprise Annual بنحو 3,000 دولار شهرياً لمن يحتاج فريق استجابة وحماية من الفاتورة.
• على السيرفر: nftables وXDP للحزم، وSYN Cookies للمصافحة، والمهل وlimit_conn للهجمات البطيئة، وlimit_req وال Cache وHAProxy للطبقة السابعة، وCrowdSec للسلوك المستمر، وFastNetMon لمن يملك شبكته.
• في المختبر حولت SYN Cookies فشل 5 من 25 إلى صفر، والمهل مع limit_conn حولت Slowloris من صفر إلى 15 من 15، وال Cache رفع المسار من 38.54 إلى 11309 طلب/ث.
• الحد لكل عنوان يحظر الزوار الذين يشاركون المهاجم عنوانه، فارفعه فوق استعمال أكبر مكتب عندك وراقب الرفض.
• لا تمسح قواعد لم تكتبها: flush ruleset أوقف DNS الداخلي في Docker عندنا.

وبهذا نكون قد أنهينا السلسلة: فهمنا الهجوم، وقسناه على ما نملك، ورتبنا الطبقات، وقسنا أثر كل دفاع بأرقام قبل وبعد.

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

سجل التحديثات

• أكتوبر 2026: كتابة المقال، والتجربة داخل شبكة Docker معزولة على Docker Engine 29.8.0 ونواة WSL2، بهدف nginx 1.27.5 مع nftables 1.1.1 وHAProxy 2.9.15 وتطبيق Python 3.12، ومولد فيه hping3 3.0.0 وslowhttptest 1.8.2 وwrk 4.1.0، والأسعار من صفحات Cloudflare وAWS وAzure وGoogle Cloud الرسمية والرخص من مستودعي CrowdSec وFastNetMon كما قرئت في 12 أكتوبر 2026.