
بوابة تخفيف هجمات DDoS على الطبقة الرابعة ذات مرحلتين تكيفيتين باستخدام تحليل السلوك المروري، وتصنيف Random Forest، والتنفيذ على مستوى النواة عبر ipset/iptables.
خط الدفاع الأول
بوابة تخفيف هجمات DDoS الحجمية من الطبقة الرابعة التكيفية ذات المرحلتين.
المؤلف: Abdullah Armiyao
المشروع: إطار عمل تكيفي من مرحلتين لتخفيف هجمات DDoS الحجمية من الطبقة الرابعة في الزمن شبه الحقيقي باستخدام تحليل السلوك المروري

تستخدم معظم عمليات تخفيف DDoS حدودًا ثابتة: حجب أي شيء يرسل أكثر من عدد مُبرمج بشكل صارم من الحزم في الثانية. يفشل هذا في كلا الاتجاهين. ارتفاع شرعي في حركة المرور خلال فترة مزدحمة فيُحجب المستخدمون الحقيقيون، أو يبقى المهاجم تحت الحد بقليل فيمر.
يتعلم FLOD كيف تبدو حركة المرور الطبيعية لديك ويحرك حدود الكشف الخاصة به لتتوافق معها. يميز بين فيضان DDoS والحشد المفاجئ، وهو ارتفاع شرعي، دون أن يضبط أي شخص حدًا يدويًا.
يجلس مضمّنًا على بوابة بين مصدر حركة المرور والمضيفين المحميين، ويُسقط أو يُخنّق المصادر المخالفة في النواة.
تُسمّي لوحة التحكم العناوين التي حجبها كمهاجمين، حتى يتمكن من لا يعرف تخطيط الشبكة مسبقًا من تحديد المرسلين العدائيين. تُدرج العناوين المخنّقة بشكل منفصل، لأن التخنيق يُستخدم أيضًا كإجراء احترازي ويُطبّق على مجموعات كاملة دفعة واحدة.
المرحلة 1 هي مستشعر بلغة Rust على مسار الحزم. يلتقط كل حزمة متجهة إلى مضيف محمي، ويحسب المعدل وتنوع المصادر على نوافذ قصيرة، ويقارنها بخط أساس يحتفظ به بنفسه. يقوم بالعمليات الحسابية فقط، فيبقى بعيدًا عن مسار حركة المرور.
المرحلة 2 هي خدمة بلغة Python. تستقبل ملخصًا من المرحلة 1 مرة واحدة لكل
نافذة، وتصنفه باستخدام Random Forest، وتصدر إنفاذًا على مستوى النواة
عبر ipset وiptables. تعمل Isolation Forest إلى جانبها على كل
نافذة، موسومةً حركة المرور التي لا تشبه أي شيء تعلمه أي من النموذجين، وتُعرض
كحالة Anomalous منفصلة بدلًا من قيادة الإنفاذ. تخدم المرحلة 2 أيضًا
لوحة التحكم على الويب.
يرتبط الاثنان عبر مقبس نطاق Unix.
تُدرَّب النماذج على حركة مرور ملتقطة وموسومة، ويستمر النشر في التقاط المزيد. النوافذ التي يجدها Isolation Forest غير مألوفة، والنوافذ التي يصنفها Random Forest بثقة كـ DDoS، تُكتب إلى ملفات الالتقاط. تقوم مهمة دورية بإعادة تقييمها باستخدام Random Forest ونموذج ثانٍ مبني بشكل مختلف، وتُجهّز صفًا للتدريب فقط عندما يختار كلاهما نفس الفئة بثقة عالية وكان كلاهما قد دُرّب بعد التقاط الصف. تعرض صفحة مراجعة في لوحة التحكم الصفوف المجهزة، 500 في الصفحة، ويقرر شخص ما إن كان سيدمجها في بيانات التدريب أو يتجاهلها. لا شيء يصل إلى مجموعة التدريب من تلقاء نفسه.
يعمل FLOD على فيضانات الطبقة الرابعة الحجمية المرئية من رؤوس الحزم وحدها: المعدل، إنتروبيا عناوين IP المصدر، مزيج البروتوكولات، ومدى تركز حركة المرور على أكثر مصادرها ازدحامًا. عمليًا يعني ذلك الفيضانات التي تكون عالية الحجم و مركزة في آنٍ واحد، والقادمة من مجموعة محدودة من العناوين الحقيقية.
هناك أمر واحد خارج النطاق صراحةً، وآخر يُعالج جزئيًا:
هجمات طبقة التطبيق. لا يُحلَّل أي محتوى طلب، لذا فإن فيضانات الطلبات المنخفضة والبطيئة واستنزاف الاتصالات خارج ما يمكن لمجموعة ميزات تعتمد على الرؤوس وحدها ملاحظته.
انتحال المصدر العشوائي. تزوير عنوان مصدر جديد لكل حزمة يرفع الإنتروبيا بدلًا من خفضها، مما يعكس الإشارة التي تبحث عنها الميزات المعتمدة على العناوين. إنتروبيا منفذ المصدر، وتباين TTL، وتنوع بصمات TCP SYN ثابتة في ظل تزوير العناوين وتسد نقطة العمى هذه في الكشف، لكن كشف فيضان منتحل مشكلة أضيق من إيقافه: فحجب عنوان مزوّر لا يزال يعاقب من يملكه حقًا، لذا يبقى الإنفاذ الآمن ضد هذه الفئة مسألة مفتوحة. انظر الكشف والشرح.
git clone https://github.com/DevInBlack001/ddos-reduction-system.git
cd ddos-reduction-system
sudo bash scripts/install.sh --interface <IFACE> --victim-ips <IP1>,<IP2>
sudo systemctl enable --now ddos-stage2
sudo systemctl enable --now ddos-stage1
يقوم المثبّت ببناء المرحلة 1، ثم ينسخ كود المرحلة 2 وبيئة
بايثون الافتراضية الخاصة بها إلى /opt/flod/stage2 (مملوكة للمستخدم الجذر) ويُنشئ
الحساب الإداري هناك، لأن المرحلة 2 تعمل بصلاحيات الجذر ويجب ألا
تنفّذ أي شيء من نسخة الشيفرة التي لا يزال بإمكان حساب غير ذي امتيازات الكتابة إليها. الحالة القابلة للتغيير، وقاعدة البيانات، وإعدادات JSON، والنماذج المدرَّبة، توجد
في /var/lib/flod. أما نسخة الشيفرة نفسها فتُعدّ من الآن فصاعدًا مجرد مصدر فقط؛ إذ يؤدي إعادة تشغيل scripts/install.sh أو scripts/update.sh إلى تحديث
النسخة المثبّتة منها. راجع الأمان لمعرفة السبب.
توجد لوحة التحكم على المنفذ 8000، عبر HTTPS بمجرد أن تصبح شهادة التوقيع الذاتي الخاصة بالمثبّت جاهزة. التعليمات الكاملة، بما في ذلك تخطيط الشبكة الذي يعتمد عليه هذا، موجودة في الويكي.
كما يُعدّ المثبّت سلسلة أدوات بناء eBPF عندما يستطيع ذلك، بما يتوافق مع إصدار LLVM الذي توفّره توزيعتك. هذا الجزء اختياري: فبدونه لا يزال المستشعر يُبنى ويعمل على libpcap.
يمتلك المستشعر خلفيتَي التقاط. libpcap هو الافتراضي ويعمل
في أي مكان. ومع وجود سلسلة الأدوات، يقوم --capture-mode kernel بإحصاء الحزم
في مسار برنامج التشغيل عبر XDP وTC بدلًا من ذلك، مع إيقاظ مساحة المستخدم مرة واحدة لكل نافذة
بدلًا من مرة لكل حزمة. الكشف متطابق في كلتا الحالتين.
يُقاس ضبط الكشف بدلًا من تخمينه. يقرأ scripts/calibrate.py
سجل المستشعر نفسه، ويأخذ عينات من حركة المرور العادية، ويحدد أين
يجب أن تكون حدود الشذوذ على شبكتك.
لتجربته دون تثبيت أي شيء، شغّله من نسخة العمل:
sudo bash scripts/run.sh
يسأل عن كل قيمة يحتاجها، ويقدّم قيمة افتراضية لكل واحدة منها، ويسأل
عمّا إذا كان ينبغي بدء المرحلة 2 أيضًا. أضف --defaults لقبول كل شيء دون
أن يُسأل.
لتشغيل مجموعات الاختبار:
scripts/test.sh
الويكي، لتشغيل النظام:
| الصفحة | تغطي |
|---|---|
| التثبيت | المتطلبات، وموضع الشبكة، وأول تسجيل دخول |
| الإعدادات | أعلام المستشعر، وضبط الإنفاذ، والتنبيهات |
| دليل لوحة التحكم | كل صفحة في وحدة التحكم |
| استكشاف الأخطاء وإصلاحها | عندما لا يعمل شيء ما |
docs/، لفهمه أو تعديله: