تقرير إدارة الثغرات

أُعد لـ: CyberTech Solutions

أُعد بواسطة: Victoria Simon

التاريخ: 10 أبريل 2024

---

1. الملخص التنفيذي

يعرض هذا التقرير النتائج المستخلصة من تقييم شامل للثغرات أُجري على البنية التحتية لنظام Linux وتطبيقات الويب لدى CyberTech Solutions باستخدام Nessus. شمل التقييم ما يلي:

• فحوصات ببيانات الاعتماد لخوادم Linux
• فحوصات ثغرات تطبيقات الويب
• إعداد التقارير الآلية
• إدارة التصحيحات عبر Ansible

تتضمن النتائج الرئيسية ثغرات حرجة في Nginx وإصدارات قديمة من OpenSSH. كما تم تقديم توصيات فورية للتصحيح وتقوية الأمان.

---

2. أهداف المختبر

1. إجراء فحوصات ثغرات ببيانات الاعتماد على أنظمة Linux.
2. تحديد وتحليل ثغرات تطبيقات الويب.
3. إعداد Nessus لإرسال التقارير تلقائيًا عبر البريد الإلكتروني.
4. تصحيح الثغرات باستخدام Ansible.
5. توثيق النتائج لمراجعة أصحاب المصلحة.

---

3. الأدوات والموارد المستخدمة

---

4. المنهجية

المهمة 1: إعداد الفحص ببيانات الاعتماد

1. إعداد SSH:

   • تثبيت OpenSSH (sudo apt install openssh-server).
   • إعداد Nessus ببيانات اعتماد SSH (اسم المستخدم: root، كلمة المرور: kali).
   • تفعيل رفع الصلاحيات عبر su.

   

2. نتائج الفحص:

درجة ثغرات SSH المفحوصة

التوصيات بعد الفحص ببيانات الاعتماد وتقييم الثغرات على خادم Linux والتطبيقات المستضافة، يُوصى باتخاذ خطوات المعالجة التالية لتحسين الوضع الأمني للمنظمة:

1. تصحيح النظام والبرمجيات: • ترقية OpenSSH إلى أحدث إصدار آمن لمعالجة الثغرات المعروفة. • تطبيق أحدث تصحيحات نواة Linux، بما في ذلك التحديثات العاجلة مثل CVE-2022-0185. • ترقية Node.js إلى الإصدار 18.20.1 أو أحدث للتخفيف من مخاطر مثل تهريب الطلبات (request smuggling) والعشوائية غير الآمنة وثغرات إدارة الذاكرة (مثل CVE-2024-27980 وCVE-2024-21891 وCVE-2024-21892). • تفعيل التحديثات التلقائية للتصحيحات أو التكامل مع نظام مركزي لإدارة التصحيحات لضمان تطبيق الإصلاحات الأمنية في الوقت المناسب.
2. تقوية خدمة SSH • تعطيل خوارزميات وأصفار SSH الضعيفة (مثل CBC وArcfour) وبروتوكولات MAC. • فرض المصادقة بالمفاتيح وتعطيل تسجيل الدخول بكلمة المرور حيثما أمكن. • إعداد منفذ SSH مخصص وتقييد الوصول إلى SSH باستخدام قواعد جدار الحماية أو TCP wrappers. • تقييد الوصول إلى عناوين IP محددة وتنفيذ المصادقة الثنائية (2FA) للاتصالات عن بُعد.
3. المستخدمون والتحكم في الوصول • تعطيل تسجيل دخول root عبر SSH واستخدام sudo لرفع الصلاحيات. • إزالة حسابات المستخدمين غير المستخدمة أو القديمة وفرض سياسات كلمات مرور قوية. • إعداد آليات قفل الحسابات لمنع هجمات القوة الغاشمة. • مراجعة مجموعات المستخدمين وصلاحياتهم لضمان تطبيق مبدأ الامتياز الأقل.
4. تقوية المضيف والشبكة • تعطيل الخدمات غير الضرورية وإغلاق المنافذ غير المستخدمة. • استخدام أدوات التقوية مثل Lynis أو OpenSCAP أو CIS Benchmarks لفرض أفضل الممارسات. • تنفيذ قواعد جدار الحماية للحد من التعرض للشبكة ومنع الحركة الجانبية.
5. المراقبة والتسجيل والكشف • تفعيل التسجيل التفصيلي لأحداث SSH وsudo وأحداث النظام. • دمج السجلات مع منصة SIEM للمراقبة والتنبيه في الوقت الفعلي. • مراقبة السلوك المشبوه وأنماط الوصول الشاذة.
6. أمان التطبيقات والتبعيات • تشغيل npm audit أو yarn audit لفحص وإصلاح تبعيات Node.js. • اختبار التطبيقات بانتظام باستخدام أدوات التحليل الديناميكي والثابت (DAST/SAST). • استخدام جدار حماية تطبيقات الويب (WAF) لمنع هجمات الويب المعروفة.
7. النسخ الاحتياطي والاستعادة • جدولة نسخ احتياطي منتظم للإعدادات والبيانات الحرجة. • اختبار إجراءات التعافي من الكوارث واستعادة النسخ الاحتياطية بشكل دوري.
8. التوعية الأمنية والحوكمة • إجراء تدريب أمني منتظم لمسؤولي الأنظمة والمطورين. • الحفاظ على تحديث السياسات والإجراءات الأمنية وتوثيق الأصول. • إجراء تقييمات دورية للثغرات واختبارات اختراق للحفاظ على الاستباقية.

المهمة 2: فحص تطبيق الويب

1. ثغرات Nginx:

• CVE-2021-23017 (CVSS 7.5): تجاوز سعة المخزن المؤقت في Nginx 1.15.5.

  • الاستغلال: حجب الخدمة عن بُعد (DoS) عبر طلب مُعد خصيصًا.
  • التصحيح: الترقية إلى Nginx ≥1.20.1.

• CVE-2022-41741 (CVSS 8.2): تلف في الذاكرة عبر HTTP/2.

• CVE-2025- 2254

  • يتوفر استغلال: نعم (وحدة Metasploit).

1. تحليل الثغرات:
   • سهولة الاستغلال: تعقيد منخفض (تتوفر استغلالات عامة).
   • تواريخ التصحيح:
     • CVE-2021-23017: تم التصحيح في يونيو 2021.
     • CVE-2022-41741: تم التصحيح في أكتوبر 2022.

المهمة 3: إعداد التقارير الآلية عبر البريد الإلكتروني

1. إعداد SMTP:

   • المضيف: smtp.gmail.com (المنفذ: 587، TLS).

   

   • استخدام كلمة مرور تطبيق Gmail للمصادقة.

   

   

   • تم إرسال بريد إلكتروني تجريبي بنجاح إلى أصحاب المصلحة.

   

   أرسل Nessus بريدًا إلكترونيًا، مما يعني أن الأمر نجح تمامًا.

المهمة 4: إدارة التصحيحات

1. Ansible Playbook:

   • إزالة إصدار Nginx القديم (/usr/local/nginx).
   • تثبيت أحدث إصدار من Nginx (apt: name=nginx state=latest).

   

   نص .yml لتحديث الإصدار القديم من Nginx

   • النتيجة: الترقية من Nginx 1.15.5 إلى 1.26.3.

   

---

---

5. التحليل والنتائج

أبرز الثغرات التي تم تحديدها

1. إصدارات NGINX القديمة

• CVE-2021-23017: استبدال بايت واحد في الذاكرة في محلل DNS (الخطر: تنفيذ تعليمات برمجية عن بُعد/تعطل النظام).
• استغلالات HTTP/2:
  • CVE-2019-9511, CVE-2019-9513, CVE-2019-9516: حجب الخدمة عبر التلاعب بالإطارات.
  • CVE-2018-16843, CVE-2018-16844, CVE-2018-16845: هجمات استنزاف المعالج/الذاكرة.
• CVE-2019-20372: كشف إصدار الخادم عبر ترويسات HTTP (تسريب معلومات).

2. نتائج متعددة من إضافات Nessus

• معرفات الإضافات: 150154, 127907, 118956, 134220 تؤكد أن إصدارات NGINX غير مدعومة وعرضة للثغرات.

المخاطر الرئيسية:

• الأنظمة غير المصححة معرضة لبرامج الفدية واختراق البيانات.
• ثغرات الويب تعرض بيانات العملاء للاعتراض.

6. إجراءات حرجة لمعالجة أمان NGINX

1. ترقية NGINX إلى أحدث إصدار مستقر (≥1.20.1)
   • لماذا؟ للتخفيف من:
     • CVE-2021-23017 (تلف ذاكرة محلل DNS)
     • ثغرات حجب الخدمة عبر HTTP/2 (CVE-2019-9511, CVE-2018-16843 وغيرها)
     • كشف إصدار الخادم (CVE-2019-20372).
   • الإجراء:
     • عمل نسخة احتياطية من الإعدادات (nginx.conf)، ثم الترقية باستخدام مستودعات NGINX الرسمية.
     • التحقق من الإصدار بعد الترقية: nginx -v.
2. تعطيل أو تقوية HTTP/2
   • إذا لم تكن HTTP/2 ضرورية:
     • تعطيلها في إعداد NGINX (listen 443 ssl بدلاً من listen 443 ssl http2).
   • إذا كانت مطلوبة:
     • التأكد من تصحيح NGINX (بعد الترقية).
     • مراقبة السجلات بحثًا عن حركة HTTP/2 غير طبيعية (مثل التدفقات/الإطارات السريعة).
3. تنفيذ إدارة التصحيحات
   • أتمتة التحديثات: استخدام أدوات مثل unattended-upgrades (لينكس) أو Ansible.
   • جدولة المراجعات: فحوصات شهرية لتحديثات NGINX/نظام التشغيل.
4. التحقق من الإصلاحات بإعادة الفحص عبر Nessus
   • إعادة تشغيل Nessus (معرفات الإضافات: 150154, 127907 وغيرها) للتأكد من:
     • عدم الإبلاغ عن إصدار NGINX بعد الآن.
     • تصحيح ثغرات HTTP/2 (إذا كانت مفعلة).

خطوات تقوية إضافية

• إخفاء إصدار NGINX: إضافة server_tokens off; في nginx.conf.
• تقييد طرق HTTP: السماح فقط بـ GET و**POST** و**HEAD** إذا كان ذلك مناسبًا.
• مراقبة قواعد بيانات CVE: الاشتراك في النشرات الأمنية الخاصة بـ NGINX.

الجدول الزمني:

• فوري (24-48 ساعة): ترقية NGINX وتعطيل HTTP/2 (إن أمكن).
• متابعة (أسبوع واحد): تنفيذ إدارة التصحيحات + إعادة الفحص.

بعد المعالجة: توثيق التغييرات وتحديث خطط الاستجابة للحوادث لتشمل سيناريوهات استغلال HTTP/2/NGINX.

---

7. التحديات والحلول

---

8. الخلاصة

حدد التقييم ثغرات حرجة في البنية التحتية للويب لدى CyberTech بسبب إصدارات NGINX القديمة وثغرات CVE غير المصححة، مما يعرض المنظمة لهجمات حجب الخدمة وتلف الذاكرة وتسريب المعلومات. ولمعالجة هذه المخاطر، تُعد الترقيات الفورية وتقوية HTTP/2 وإدارة التصحيحات الآلية أمورًا أساسية.

يجب إجراء فحص متابعة بعد المعالجة للتحقق من الإصلاحات. كما أن الحفاظ على وضع أمني استباقي من خلال التحديثات والمراقبة المنتظمة سيساعد في تخفيف التهديدات المستقبلية وضمان المرونة على المدى الطويل.

---

10. المراجع

1. NIST NVD: https://nvd.nist.gov
2. توثيق Nessus: https://www.tenable.com
3. https://www.notion.so/Nessus-1cb5f18a0bc980cdb558d62702ab23e9?pvs=4