الأسئلة الشائعة
DDoS (حجب الخدمة الموزّع) هو أن تصبح الخدمة غير قابلة للوصول عندما ترسل أعداد كبيرة من الأجهزة المخترقة حركة متزامنة إلى الهدف نفسه. الهدف ليس سرقة البيانات بل إيقاف الخدمة؛ لذلك قد يبدو خادمكم عاملًا أثناء الهجوم بينما لا يستطيع مستخدموكم الاتصال به. وبما أن الحركة تأتي من آلاف العناوين المختلفة، فإن حجب عنوان IP واحد لا يُعد حلًا. تأتي الهجمات إما في صورة حركة الطبقة 3/4 القائمة على الحجم، وإما في صورة عاصفة طلبات تُولَّد في طبقة التطبيق (الطبقة 7).
لا تُبنى الحماية بجهاز واحد بل بطبقات: توجيه anycast وCDN الذي يوزّع الحركة، ومراكز scrubbing التي تنقّي الحركة المشبوهة قبل وصولها إلى الهدف، وقواعد WAF وتحديد المعدل التي تعمل في طبقة التطبيق، وعند الحاجة مرشّحات حسب IP أو الدولة. ولا يكفي أي منها بمفرده؛ فالعامل الحاسم هو السعة الإجمالية لهذه الطبقات وسرعة تفعيلها عند بدء الهجوم. ويقيس inDDoS هذه العتبات تحديدًا: فهو يجعل مرئيًا أي قاعدة تُفعَّل وبأي شدة، وأين تنكسر الحماية.
شراء حل حماية لا يعني أنه يعمل. فحدود الأجهزة، أو الإعداد الخاطئ، أو هجوم يتجاوز السعة - لا يظهر أي منها إلا تحت حركة حقيقية. والاختبار يجعل ما يلي قابلًا للقياس: عند أي شدة تنكسر حمايتكم، وما زمن تفعيلها، وحجم الانقطاع الذي يشعر به المستخدم. وبذلك يُوجَّه الاستثمار إلى الطبقة الصحيحة والسعة الصحيحة، فلا تجريب عشوائي عند وقوع الحادث. كما يتيح لكم تقرير الاختبار توثيق مرونتكم في عمليات التدقيق واتفاقيات العملاء.
الأعراض عادة واحدة: تطوّل زمن الاستجابة فجأة أو صيرورة الخدمة غير قابلة للوصول كليًا، وبلوغ النطاق الترددي واستخدام المعالج حد التشبّع، وتكرار الطلب نفسه من أعداد كبيرة من العناوين المختلفة، وقدوم الحركة من مناطق جغرافية غير متوقعة. وإذا ظهر أي من هذه العلامات، يجب أولًا فحص مصدر الحركة والمنافذ المستهدفة، ومقارنة سجلات طبقات الحماية بالفترة السابقة للهجوم. أما إعادة إنتاج السيناريو نفسه بطريقة مضبوطة فتُظهر بشكل قاطع ما إذا كان الوضع هجومًا وما إذا كانت الحماية قد فُعِّلت.
لا يمكن إجراء اختبارات DDoS بشكل قانوني إلا بموافقة خطية من مالك النظام المستهدف أو مديره المفوّض. وكل اختبار يُجرى دون إذن يقع في نطاق الجريمة السيبرانية. ويفرض inDDoS هذه القاعدة تقنيًا أيضًا: فلا يمكن تعريف اختبار قبل إثبات أن الأصول المستهدفة ملك لكم، ويتطلب بدء الاختبار موافقة منفصلة من المشغّل ومن مؤسستكم. وتُدار العملية كاملة وفق وثيقة تفويض موقّعة واتفاقية NDA.
لكي يكون الاختبار ذا معنى، يُجرى عادة في البيئة المباشرة وبطريقة مضبوطة. تُبقى شدة البداية منخفضة وتُرفع تدريجيًا. وبما أن مكوّن Monitor يقيس زمن استجابة الهدف لحظيًا، يمكن رؤية الاقتراب من نقطة الانكسار في الوقت الحقيقي. ويمكن إنهاء الاختبار بلمسة واحدة عبر زر الإيقاف الطارئ؛ كما يُغلق كل متجه تلقائيًا عند انتهاء المدة المحددة. ويُفضَّل في الأنظمة الحيوية اختيار نافذة صيانة أو بيئة مرآة.
يعتمد ذلك على عدد البوتات. فمع 50 بوت يمكن بلوغ 3 Gbps و500,000 مستخدم متزامن على L7، ومع 600 بوت يمكن بلوغ 36 Gbps و6,000,000 مستخدم متزامن. وتتوسع المنصة حتى 4,000 بوت؛ وتُخطَّط السعات عند هذا المستوى حسب الطلب. ويتراوح النطاق الترددي لكل بوت بين 1–60 Mbps حسب نوع الهجوم.
نعم. يمكن إدراج مناطق معينة أو استثناؤها في توزيع البوتات. وبذلك يمكن اختبار ما إذا كانت قواعد الترشيح الجغرافي وتوجيه CDN وإعداد scrubbing الإقليمي لديكم تعمل فعلًا.
نعم. المهاجمون الحقيقيون لا يستخدمون متجهًا واحدًا؛ بل يجمعون متجهات مختلفة لزيادة التأثير وتعقيد التخفيف. وinDDoS قادر على تشغيل متجهات متعددة في وقت واحد لمحاكاة هذا السلوك. فمثلًا يمكن تشغيل SYN Flood مع HTTP/S GET Flood معًا لإجهاد مسار الشبكة وطبقة التطبيق في الوقت نفسه.
يُولَّد التقرير تلقائيًا بمجرد انتهاء الاختبار. ويتضمن تحققًا من تنفيذ الاختبار، وهوية المشغّل، والنطاق الترددي المستخدم، وقيم PPS، وزمن استجابة الهدف، وذلك على شكل رسوم بيانية. ويمكن تحويله إلى PDF وأرشفته ومشاركته. كما تُفسّر Nesil Teknoloji هذه البيانات الخام؛ فتضيف مصفوفة اكتشافات مرتبة حسب الأولوية وخارطة طريق للتحسين.
تُحتسب نسبة زمن استجابة الهدف قبل الاختبار إلى زمن استجابته أثناء الاختبار، ويُشتق منها قيمة تجريبية في نطاق 1–10؛ وكلما ارتفعت القيمة زادت المرونة. وعند تكرار الاختبارات تُقارن هذه القيم، ويمكن تتبع أثر الضبط الدقيق الذي أُجري على آليات الدفاع على شكل اتجاه زمني.
نعم. يمكن لمؤسستكم بدء الاختبارات مباشرةً، أو لمشغّل مفوّض تلقّى التدريب. في نموذج ترخيص المنصة يُخصَّص للمؤسسة وصول إلى البوابة، ويخطط فريقكم للاختبارات بنفسه بعد التدريب. أما في نموذج الخدمة المُدارة فيتولى فريق Nesil Teknoloji العملية بأكملها.
نعم. إذا كان مستوى البوتات أقل من احتياجكم، يمكن الانتقال إلى باقة أعلى. ويكفي أن تتواصلوا مع فريق المبيعات لدينا لتغيير مدة الترخيص والنطاق.
نعم. بعد تسليم التقرير نقدّم عرضًا تقديميًا لفريقكم التقني، ونجيب عن أسئلتكم المتعلقة بالتقرير لمدة 30 يومًا، ونقدّم الاستشارة خلال عملية التحسين. كما نتيح خيار إعادة اختبار بسعر مخفّض لقياس ما إذا كانت التحسينات فعالة فعلًا.
يستغرق التنفيذ الفعلي للاختبار عادةً من بضع دقائق إلى ساعتين لكل سيناريو. وتتحدد المدة بعدد البوتات ومزيج المتجهات المختار وخطة التصعيد التدريجي (ramp-up)، وينتهي كل متجه تلقائيًا عند انقضاء مدته المحددة. أما المشروع من البداية إلى النهاية (التقييم المبدئي والتفويض والتنفيذ والتقرير) فيستغرق عادةً بضعة أيام عمل.
ليس بالضرورة؛ إذ يُجرى الاختبار بطريقة محكومة لإيجاد عتبة الانهيار دون التسبب في انقطاع. تبدأ الشدة منخفضة وتتصاعد تدريجيًا، ولأن مكوّن Monitor يقيس زمن استجابة الهدف لحظيًا، فإنك ترى الاقتراب من نقطة الانهيار مباشرةً. ويُنهي زر الإيقاف الطارئ الاختبار بلمسة واحدة، وينتهي كل متجه تلقائيًا عند انقضاء مدته. وللأنظمة الحرجة يمكن استخدام نافذة صيانة أو بيئة مطابقة.
نعم؛ يمكن اختبار الأنظمة الواقعة خلف هؤلاء المزوّدين، وهذا بالضبط ما يتيح التحقق من أن طبقة التخفيف ضد DDoS لدى المزوّد تعمل فعلًا. فحركة الهجوم الحقيقية تصل إلى حافة السحابة أو شبكة توصيل المحتوى (CDN)، وبذلك يُلاحظ مباشرةً سلوك التنظيف (scrubbing) وتحديد المعدل وقواعد WAF. غير أن معظم هؤلاء المزوّدين يطلبون إشعارًا أو إذنًا مسبقًا لاختبارات الحمل وDDoS؛ لذا نؤكّد معك سياسة الاختبار لدى المزوّد قبل البدء.
في معظم الحالات نعم؛ إذ يشترط كثير من المزوّدين مثل AWS وCloudflare إشعارًا مسبقًا أو إذنًا كتابيًا لاختبارات الهجوم المحاكى أو اختبارات الحمل. وأثناء تحديد نطاق الاختبار نحدّد أي مزوّد يطلب أي إشعار، ونُكمل الطلبات اللازمة في وقتها. وتضمن هذه الخطوة أن يبقى الاختبار متوافقًا مع عقدك ومع قواعد المزوّد على حد سواء.
اختبار الحمل يقيس أداء النظام تحت حركة مستخدمين مشروعة ومتوقعة، بينما يحاكي اختبار DDoS حركة هجوم خبيثة مصمّمة لاستنزاف الموارد والتغلّب على الحماية. ولا يتحقق inDDoS من السعة فحسب، بل مما إذا كانت طبقات التنظيف (scrubbing) وWAF وتحديد المعدل والتصفية تعمل فعلًا تحت الهجوم. والمخرج ليس منحنى أداء، بل درجة مرونة أمام DDoS من 1 إلى 10.
يُوصى بإجرائه مرة واحدة سنويًا على الأقل، إضافةً إلى تكراره عند أي تغيير مهم في البنية التحتية أو في إعدادات الحماية أو لدى المزوّد، وقبل فترات الحركة المرتفعة مثل الحملات والإطلاقات والانتخابات ومواسم الذروة. وإعادة الاختبار بعد أي معالجة أمر مهم لقياس التغيّر في درجة المرونة. ومع الطيّار الآلي (Autopilot) يمكن جدولة الاختبارات دوريًا وتشغيلها تلقائيًا دون انتظار مشغّل.
يصنّف المعهد التركي للمواصفات شركات اختبار الاختراق التي يدقّقها وفق معيار TS 13638/T2 بحسب كفاءتها، والفئة A هي أعلى درجات هذا التصنيف. وتحمل Nesil Teknoloji هذه الشهادة برقم TSE-STF-065، وهي صالحة حتى 03.04.2027.
بموجب اللائحة رقم 31881، يلزم الحصول على وثيقة تفويض من وزارة الصناعة والتكنولوجيا التركية للمشاركة في مناقصات اختبار الاختراق لدى المؤسسات الحكومية. ورقم وثيقة تفويض اختبار الاختراق لدى Nesil Teknoloji هو STB03-250، كما تحمل الشركة وثيقة تفويض المعلوماتية الحكومية رقم STB01-3242.
نعم. صدرت الشهادتان عن Sigmacert Global (SQR) تحت اعتماد IAF وTÜRKAK، ويمكن التحقق منهما عبر شاشة التحقق من الوثائق على asist.turkak.org.tr.
CREST (Council of Registered Ethical Security Testers) جهة اعتماد تُعدّ المرجع الدولي في اختبار الاختراق واختبارات الأمن الأخلاقية. وتتمتع Nesil Teknoloji بصفة Member Company في CREST.
يضم فريقنا التقني 9 أخصائيين في اختبار الاختراق معتمدين من TSE: 2 أول و3 معتمدون و4 مسجّلون. ويضم الفريق كذلك خبراء يحملون شهادات OSCP/OSCP+ وCEH وGPEN وCISM وCISA وCISSP وCIPP/E وترخيص التدقيق المستقل لنظم المعلومات الصادر عن SPK.