> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # الفحص الشبكي للثغرات Network Scan مع OpenVAS - URL: https://arabroot.io/articles/فحص-الثغرات-الشبكي-مع-openvas-greenbone-في-مختبر/ - Published: 2026-10-26T07:07:10.000Z - Updated: 2026-10-26T08:14:42.000Z - Description: شغلنا منصة Greenbone المجتمعية وفحصنا بها سيرفر Debian، فانتظرنا أربع ساعات قبل أول فحص ووجدنا نتائج حرجة كلها إنذارات خاطئة. - Author: فريق عرب رووت - Tags: الأدلة التقنية, الأمن السيبراني, الاستضافة الذاتية, Docker والحاويات, OpenVAS نعود إلى شركة الحجوزات السعودية الصغيرة التي بدأنا قصتها في [مقال Nuclei](https://arabroot.io/articles/%D9%81%D8%AD%D8%B5-%D8%A7%D9%84%D8%AB%D8%BA%D8%B1%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%B9%D8%B1%D9%88%D9%81%D8%A9-%D9%85%D8%B9-nuclei-%D9%81%D9%8A-%D9%85%D8%AE%D8%AA%D8%A8%D8%B1-%D9%85%D8%B9%D8%B2%D9%88%D9%84/). الفريق الآن يفحص خدماته المكشوفة كل أسبوع بملف KEV، ويعرف أن ثغرات Apache وGrafana أغلقت. لكن المدقق في اجتماع الاستعداد لضوابط الهيئة الوطنية للأمن السيبراني سأل سؤالاً آخر: «Nuclei يختبر الثغرات المشهورة التي كتبت لها قوالب، فماذا عن بقية ما يعمل على سيرفراتكم؟ خادم SSH، وخدمة FTP القديمة التي يستخدمها شريك لرفع الملفات، وإعدادات التشفير؟ هل فحصتم كل منفذ مفتوح بكل اختبار معروف؟». والجواب الأمين كان لا. فاقترح أحد المهندسين OpenVAS: الفاحص الشبكي مفتوح المصدر الذي يجرب عشرات الآلاف من اختبارات الثغرات على كل منفذ، ويخرج تقريراً مصنفاً يشبه ما يطلبه المدقق. وبدا القرار سهلاً، حتى بدأ التثبيت. في هذا المقال سوف نحكي ما حدث بالأرقام. شغلنا منصة Greenbone المجتمعية Community Edition على جهاز مختبر، وفحصنا بها سيرفر Debian يشبه سيرفرات الشركة، وقسنا كل مرحلة بالدقيقة: كم استغرق سحب ال Images، وكم انتظرنا حتى صار الفحص ممكناً، وكم استهلكت من القرص والذاكرة، ثم ماذا وجد الفحص فعلاً، ولماذا كان أخطر ما فيه أربع نتائج حرجة وعالية مخفية في الإعداد الافتراضي، وكلها إنذارات خاطئة. والهدف ليس أن نقول لك «استخدم OpenVAS» أو «لا تستخدمه»، بل أن تعرف ثمنه الحقيقي قبل أن تقرر. 📚 المواضيع في السلسلة: (1) إدارة الثغرات Vulnerability Management. (2) أدوات إدارة الثغرات مفتوحة المصدر. (3) مختبر عملي: اكتشف السيرفرات المتأثرة بثغرة. (4) فحص الثغرات المعروفة مع Nuclei. (5) الفحص الشبكي للثغرات مع OpenVAS (الموضوع الحالي). (6) إدارة نتائج الفحص مع DefectDojo. وسوف نناقش في هذا المقال ما يلي: - من أين جاء OpenVAS، وما الفرق بين الفاحص ومنصة Greenbone الكاملة، ولماذا تحتاج سبعة عشر Container. - الإذن والنطاق Scope، ولماذا فحصنا داخل شبكة Docker معزولة. - التثبيت بـ Docker Compose، وتغيير كلمة مرور المدير قبل أي شيء. - القياس الصادق: أكثر من أربع ساعات قبل أول فحص، وما الذي يحدث في كل مرحلة. - الهدف Target، والمهمة Task، وإعداد الفحص Full and fast، وتشغيلها عبر بروتوكول GMP. - قراءة التقرير Report: الخطورة Severity وجودة الكشف QoD، ونتائج OpenSSH الحرجة المخفية. - كيف أثبتنا أن النتائج الحرجة إنذارات خاطئة من متتبع ثغرات Debian. - الموارد: 43 GB من القرص وأكثر من 8 GiB من الذاكرة، والتغذية المجتمعية مقابل التجارية. - متى تختار OpenVAS ومتى يكفي Nuclei، وقائمة تحقق قبل التشغيل. ## من أين جاء OpenVAS، وما هي منصة Greenbone؟ قصة OpenVAS تبدأ من أداة أقدم اسمها Nessus، وكانت مفتوحة المصدر حتى عام 2005، ثم أغلق مطوروها الكود وحولوها إلى منتج تجاري. فأخذ مجتمع من المطورين آخر نسخة مفتوحة وطوروها باسم جديد هو OpenVAS، أي النظام المفتوح لتقييم الثغرات Open Vulnerability Assessment System، ثم صارت شركة Greenbone الألمانية الراعي الرئيسي للمشروع. ولهذا التاريخ أثر تراه حتى اليوم: فاختبارات الثغرات مكتوبة بلغة اسمها NASL ورثت من Nessus، وكل اختبار له معرف فريد OID، ويسمى الواحد منها Network Vulnerability Test واختصاراً NVT. والاسم المتداول OpenVAS يشير في الحقيقة إلى الفاحص وحده، أما المنتج الكامل الذي تثبته فهو [Greenbone Community Edition](https://www.greenbone.net/en/community-edition/?ref=arabroot.io)، وهو مجموعة أدوات تعمل معاً، ولكل منها عمل ورخصة: - **openvas-scanner:** الفاحص نفسه، يرخص بـ [GPL-2.0](https://github.com/greenbone/openvas-scanner?ref=arabroot.io)، وهو من ينفذ اختبارات الثغرات على الهدف، ويحفظ حالة الفحص الجاري في Redis. - **gvmd:** مدير الثغرات Greenbone Vulnerability Manager، يرخص بـ [AGPL-3.0](https://github.com/greenbone/gvmd/blob/main/COPYING?ref=arabroot.io)، يحفظ الأهداف والمهام والنتائج في قاعدة PostgreSQL، ويتكلم بروتوكولاً اسمه GMP تستطيع أن تبرمج به كل شيء. - **GSA:** مساعد الأمان Greenbone Security Assistant، وهو واجهة الويب التي تدير منها المنصة من المتصفح. - **بيانات التغذية Feed:** اختبارات الثغرات NVTs، وبيانات CVE وCPE من قاعدة NVD الأمريكية، ونشرات CERT الألمانية، وإعدادات الفحص الجاهزة، وتأتي كلها في Containers منفصلة. وتقول [وثائق التثبيت بالحاويات](https://greenbone.github.io/docs/latest/22.4/container/index.html?ref=arabroot.io) إن الحد الأدنى معالجان و4 GB من الذاكرة RAM و20 GB من التخزين، والموصى به 4 معالجات و8 GB و60 GB. واحفظ هذا الرقم الأخير، 60 GB، فسوف نرى بعد قليل أنه ليس مبالغة، بل أقرب إلى الواقع من الحد الأدنى. ## الإذن والنطاق Scope أولاً OpenVAS فاحص هجومي بمعنى الكلمة: يرسل اختبارات حقيقية على الخدمات، وبعضها قد يعطل خدمة هشة أو يملأ سجلاتها، فلا تشغله إلا على أنظمة تملكها أو معك إذن مكتوب بنطاق محدد، كما شرحنا بالتفصيل في [مقال Nuclei](https://arabroot.io/articles/%D9%81%D8%AD%D8%B5-%D8%A7%D9%84%D8%AB%D8%BA%D8%B1%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%B9%D8%B1%D9%88%D9%81%D8%A9-%D9%85%D8%B9-nuclei-%D9%81%D9%8A-%D9%85%D8%AE%D8%AA%D8%A8%D8%B1-%D9%85%D8%B9%D8%B2%D9%88%D9%84/). والفرق هنا أن OpenVAS أثقل وأوسع: فهو يمسح المنافذ أولاً ثم يجرب على كل منفذ مفتوح كل اختبار يناسبه، فعدد ما يرسله أكبر بكثير، ولذلك فإخطار فريق التشغيل وتحديد وقت الفحص أهم معه. وهناك أثر جانبي يجب أن يعرفه فريق المراقبة قبل الفحص: OpenVAS صاخب في السجلات. فهو يجرب الدخول إلى FTP، ويتفاوض مع SSH على كل الخوارزميات، ويطلب صفحات HTTP كثيرة لا وجود لها، فإذا كان عندك نظام كشف تسلل IDS أو منصة مراقبة مثل Wazuh فسوف تمتلئ بتنبيهات تشبه هجوماً حقيقياً. والحل ليس إطفاء المراقبة، بل أن تعرف عنوان الفاحص وتوقيت الفحص، فتميز تنبيهاته، وتستفيد منه في الوقت نفسه: فإذا لم تنبه المراقبة على فحص بهذا الصخب، فهي لن تنبه على مهاجم يفعل الشيء نفسه. وكل ما في هذا المقال نفذناه على هدف نملكه في شبكة Docker داخلية لا تصل إلى الإنترنت ولا إلى شبكة السيرفر المضيف، وربطنا واجهة الويب بالعنوان المحلي 127.0.0.1 فقط. وهذا الفحص الدوري جزء عملي من الضابط 2-10-3 في [الضوابط الأساسية للأمن السيبراني ECC-2:2024](https://cdn.nca.gov.sa/api/files/public/upload/86e09090-44e4-481f-bc28-355673607654%5FECC--2024-EN.pdf?ref=arabroot.io)، الذي يطلب التقييم الدوري للثغرات واكتشافها وتصنيفها بحسب الخطورة، وتقرير OpenVAS المصنف هو بالضبط نوع الدليل الذي يطلبه المدقق، بشرط أن تعرف كيف تقرؤه كما سيأتي. ## التثبيت بـ Docker Compose ننزل ملف Compose الرسمي من Greenbone، ونغير فيه اسم المشروع فقط، ثم نسحب ال Images: ```bash curl -f -L https://greenbone.github.io/docs/latest/_static/compose.yaml -o compose.yaml docker compose -f compose.yaml pull ``` وعدد ال Images سبعة عشر، وهو رقم يفاجئ من يراه أول مرة، لكن لكل مجموعة منها عمل واضح، والشكل التالي يبين المكونات مقسمة إلى ثلاث مجموعات، والهدف الذي سوف نفحصه: ![منصة Greenbone بثلاث مجموعات: بيانات التغذية Feed وقاعدة الإدارة gvmd والفاحص ospd-openvas، وهدف Debian بثلاث خدمات، كلها في شبكة Docker داخلية](https://arabroot.io/content/images/2026/10/openvas-lab-01-lab.webp) سبعة عشر Container للمنصة، والفاحص يرى الهدف كما يراه مهاجم على الشبكة - **مجموعة البيانات (عشر Containers):** vulnerability-tests تحمل اختبارات الثغرات NVTs، وscap-data تحمل قاعدة CVE وCPE من NVD، وnotus-data لفحص الحزم من الداخل، وcert-bund وdfn-cert لنشرات الطوارئ الألمانية، وdata-objects وreport-formats لإعدادات الفحص وقوالب التقارير. ولماذا Container لكل نوع بيانات؟ لأن Greenbone تحدث كل نوع بإيقاع مختلف، فتنزل Image جديدة للبيانات دون أن تلمس البرامج. وكل Container منها مهمته أن ينسخ بياناته إلى Volume مشترك ثم يبقى حياً. - **مجموعة الإدارة والويب:** pg-gvm وهي قاعدة PostgreSQL، وgvmd المدير، وGSA وgsad وnginx للواجهة. - **مجموعة الفحص:** ospd-openvas وopenvasd وهما الفاحص، وredis يخزن فيه الفاحص حالة الفحص. 🛑 ينشئ الملف الرسمي مستخدم admin بكلمة مرور admin، وهذا مناسب لمختبر معزول فقط. غير كلمة المرور فوراً قبل أي استخدام حقيقي، ولا تفتح المنفذ 443 أو 9392 على الإنترنت، فالواجهة مربوطة بالعنوان 127.0.0.1 في الملف الافتراضي، ولا تغير ذلك دون سبب، لأن من يدخل الواجهة يرى خريطة ثغرات شبكتك كاملة. ```bash docker compose -f compose.yaml up -d # غير كلمة مرور المدير قبل أي شيء: docker compose -f compose.yaml exec -u gvmd gvmd gvmd --user=admin --new-password='كلمة-مرور-قوية' ``` ## القياس الصادق: كم ينتظر الفريق قبل أول فحص؟ هنا بدأت المفاجأة التي لم يتوقعها فريق الشركة. فبعد `docker compose up -d` فتحت واجهة الويب، وظن الجميع أن الفحص يبدأ الآن، لكن إعداد الفحص الوحيد المهم، Full and fast، لم يكن موجوداً في القائمة أصلاً. والسبب أن المنصة لا تكون جاهزة حتى تحمل بيانات التغذية كاملة وتبني منها قاعدتها، وهذه عملية طويلة تمر بمراحل. قسنا كل مرحلة في المختبر على جهاز بثمانية معالجات و31 GB من الذاكرة، والشكل التالي يلخصها: ![رسم بأعمدة لمراحل التحضير: سحب 17 Image نحو 20 دقيقة، تشغيل المنصة نحو 15 دقيقة، نسخ بيانات SCAP نحو 11 دقيقة، بناء قاعدة SCAP 3 ساعات و40 دقيقة، ثم أول فحص ممكن](https://arabroot.io/content/images/2026/10/openvas-lab-02-feed-timeline.webp) الثقل في التحضير لا في الفحص: أكثر من أربع ساعات قبل أن يصبح الفحص ممكناً | المرحلة | التوقيت في المختبر (UTC) | المدة | | ---------------------------------------- | ------------------------ | ---------------------- | | سحب ال Images السبعة عشر | 20:22 إلى 20:42 | نحو 20 دقيقة ونصف | | تشغيل المنصة حتى تعمل كل الخدمات | 20:43 إلى 20:58 | نحو 15 دقيقة | | داخلها: نسخ بيانات SCAP الخام إلى Volume | حتى 20:56 | نحو 11 دقيقة لـ 8.2 GB | | بناء قاعدة SCAP في PostgreSQL | 20:59 إلى 00:40 | 3 ساعات و40 دقيقة | | إنشاء إعداد الفحص Full and fast | 00:48 | بعد اكتمال SCAP | أي أن الفريق انتظر أربع ساعات وست دقائق بين `up -d` ولحظة صار فيها الفحص ممكناً، وهذا دون حساب سحب ال Images. وفي الجدول أعلاه دروس يجب أن تعرفها قبل أن تجرب: - **نسخ البيانات غير بناء القاعدة:** Container اسمه scap-data ينسخ أولاً 8.2 GB من ملفات NVD الخام إلى Volume، وأكبر ملف فيها هو ثغرات سنة 2026 بحجم 3.28 GB وحده. ثم يأتي gvmd ويقرأ هذه الملفات ويبني منها قاعدة PostgreSQL، وهذه خطوة ثانية منفصلة وأبطأ بكثير، لأنها تفك كل سجل وتربطه بالمنتجات المتأثرة. - **البناء تسلسلي:** سجل gvmd يبين الترتيب: المنتجات CPE أولاً (نحو ثماني دقائق)، ثم سلاسل مطابقة المنتجات (نصف ساعة)، ثم ملفات CVE سنة بعد سنة، وملف 2026 وحده أخذ قرابة ساعة، ثم حساب درجات CVSS للمنتجات (ربع ساعة). وإعدادات الفحص لا تنشأ إلا بعد انتهاء كل ذلك، ولذلك بقيت قائمة الإعدادات فارغة أربع ساعات. - **الواجهة لا تخبرك بوضوح:** الصفحة تفتح وتبدو جاهزة، لذلك نسأل حالة التغذية مباشرة ولا نفترض الجاهزية لمجرد أن الواجهة تعمل. ولمعرفة أين وصلت التغذية نسأل gvmd عبر بروتوكول GMP بأداة gvm-cli، ونصلها بمقبس gvmd داخل ال Volume المشترك: ```bash docker run --rm -i -v sce-ov_gvmd_socket_vol:/run/gvmd \ registry.community.greenbone.net/community/gvm-tools \ gvm-cli --gmp-username admin --gmp-password 'كلمة-المرور' \ socket --socketpath /run/gvmd/gvmd.sock --xml '' ``` فإذا ظهر الوسم `` تحت نوع معين فهو ما زال يستورد، وعندما يختفي تكون التغذية جاهزة. وفي المختبر اكتملت تغذية الاختبارات NVT أولاً، ثم بقيت SCAP وCERT وGVMD\_DATA تستورد ساعات: ```text NVT SCAP CERT GVMD_DATA ``` وبعد اكتمال كل شيء تعرض صفحة حالة التغذية Feed Status في الواجهة إصدار كل نوع وتاريخه، وهذه الصفحة هي ما تريه للمدقق إذا سألك عن حداثة قاعدة ثغراتك: ![صفحة Feed Status في واجهة OpenVAS تعرض أربعة أنواع: NVT بإصدار 20261024T1320 وSCAP بإصدار 20261024T1203 بحالة Current، وCERT وGVMD_DATA بعمر ثلاثة أيام](https://arabroot.io/content/images/2026/10/openvas-lab-07-feed-status.webp) حالة التغذية بعد الاكتمال: اختبارات الثغرات وقاعدة SCAP بتاريخ 24 أكتوبر 2026 وقد يتساءل البعض: لماذا كل هذا البطء، والجهاز فيه ثمانية معالجات وذاكرة واسعة؟ والإجابة في طريقة البناء: gvmd يستورد ملفات NVD ملفاً بعد ملف في عملية واحدة، فيفك كل سجل CVE ويكتبه في PostgreSQL، ثم يربطه بكل منتج CPE متأثر به، وعدد هذه الروابط بالملايين. وراقبنا PostgreSQL أثناء البناء فكان ينفذ أمر `COPY` في جدول المنتجات المتأثرة لدقائق طويلة، والمعالج عنده قرابة 60% فقط، أي أن البطء في الكتابة والفهرسة لا في الحساب. ولذلك فالقرص السريع يفيد هنا أكثر من المعالجات الإضافية، وعلى سيرفر بقرص عادي قد يطول البناء أكثر من أرقامنا بكثير. والخبر الجيد أن هذا الانتظار الطويل يحدث مرة واحدة فقط. فالتحديثات اللاحقة تضيف الفرق فقط وتعمل في الخلفية، والقاعدة تبقى في ال Volume. لكن عليك أن تخطط له: ثبت المنصة مساء يوم وابدأ الفحص في اليوم التالي، ولا تثبتها صباح يوم التدقيق. ## بناء الهدف Target الهدف سيرفر Debian 12 جمدناه عند أرشيف snapshot.debian.org لتاريخ 3 أغسطس 2026، كما فعلنا في [مختبر الثغرات](https://arabroot.io/articles/%D9%85%D8%AE%D8%AA%D8%A8%D8%B1-%D8%A7%D9%83%D8%AA%D8%B4%D8%A7%D9%81-%D8%A7%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%AA%D8%A7%D8%AB%D8%B1%D8%A9-%D8%A8%D8%AB%D8%BA%D8%B1%D8%A9-cve-%D9%88%D8%A7%D8%B5%D9%84%D8%A7%D8%AD%D9%87%D8%A7/)، وثبتنا عليه ثلاث خدمات تشبه ما في سيرفرات الشركة: SSH للإدارة، وFTP للشريك الذي يرفع الملفات، وHTTP للموقع: ```dockerfile FROM debian:bookworm-20260803-slim ARG SNAP=20260803T000000Z ENV DEBIAN_FRONTEND=noninteractive RUN printf 'Types: deb\nURIs: http://snapshot.debian.org/archive/debian/%s\nSuites: bookworm bookworm-updates\nComponents: main\nSigned-By: /usr/share/keyrings/debian-archive-keyring.gpg\nCheck-Valid-Until: no\n' "$SNAP" > /etc/apt/sources.list.d/debian.sources \ && apt-get update \ && apt-get install -y --no-install-recommends openssh-server apache2 vsftpd ca-certificates \ && mkdir -p /run/sshd EXPOSE 22 21 80 CMD ["sh","/start.sh"] ``` ونسخ الخدمات المثبتة مهمة جداً لهذا المقال، فاحفظها، لأن الفاحص سوف يحاول التعرف عليها من رد كل خدمة Banner، وسوف نعود إليها عندما نقرأ التقرير: ```bash docker exec sce-ov-target dpkg-query -W -f='${Package} ${Version}\n' \ openssh-server apache2 vsftpd ``` ```text apache2 2.4.68-1~deb12u1 openssh-server 1:9.2p1-2+deb12u10 vsftpd 3.0.3-13+b2 ``` لاحظ النسخة `1:9.2p1-2+deb12u10`: رقم OpenSSH الأصلي هو 9.2p1، وهو إصدار قديم من 2023، لكن اللاحقة `deb12u10` تعني أن Debian أصدرت عليه عشرة تحديثات أمنية، كل منها ينقل إصلاحاً من إصدارات أحدث إلى هذه النسخة دون أن يغير رقمها. وهذه اللاحقة الصغيرة هي مفتاح قصة هذا المقال كلها. ## إنشاء الفحص وتشغيله الفحص في OpenVAS يقوم على ثلاثة أشياء منفصلة تجمعها مهمة واحدة، والشكل التالي يبين العلاقة بينها: ![مخطط خطوات الفحص: الهدف Target وإعداد الفحص Full and fast والفاحص OpenVAS Default تجتمع في المهمة Task، وتشغيلها ينتج التقرير Report المصنف بالخطورة، ثم يصدر XML إلى DefectDojo](https://arabroot.io/content/images/2026/10/openvas-lab-03-workflow.webp) الهدف وإعداد الفحص والفاحص ثلاثة أشياء منفصلة، تجمعها المهمة ولماذا هذا الفصل؟ لأنه يسمح لك أن تعيد الاستخدام: هدف واحد تفحصه بإعدادات مختلفة، وإعداد واحد تطبقه على أهداف كثيرة، ومهمة تعيد تشغيلها كل شهر فتقارن تقاريرها. ونفعل الخطوات هنا عبر GMP لأنها قابلة للتكرار والجدولة، ويمكن فعلها من الواجهة أيضاً. أولاً ننشئ الهدف بقائمة منافذ، ونختار «All TCP and Nmap top 100 UDP» لأنها تغطي كل منافذ TCP وأشهر مئة منفذ UDP: ```xml sce-ov-target 192.168.96.15 ``` ثم نأخذ معرفي الفاحص وإعداد الفحص. الفاحص الافتراضي اسمه «OpenVAS Default»، وإعداد الفحص المتوازن المعروف اسمه «Full and fast»: ```text scanner OpenVAS Default 08b69003-5fc2-4037-a479-93b440211c73 config Full and fast daba56c8-73ec-11df-a475-002264764cea ``` إعداد Full and fast لا يشغل كل الاختبارات على كل منفذ، بل يتعرف على الخدمة أولاً ثم يشغل الاختبارات المناسبة لها فقط، ويتجنب الاختبارات التي قد تعطل الخدمة، فهو السريع والآمن للاستخدام الدوري، على عكس إعدادات أخرى تجرب كل شيء وتستغرق أضعاف الوقت. ثم ننشئ المهمة ونشغلها: ```xml scan sce-ov-target ``` ```xml ``` بدأ الفحص الساعة 02:53 وانتهى 03:22 بتوقيت UTC، أي 28 دقيقة لسيرفر واحد بثلاث خدمات. وخلاله وصل الفاحص ospd-openvas إلى ثلاثة معالجات في ذروته، وهذا متوقع لأنه يشغل الاختبارات بالتوازي. و28 دقيقة لسيرفر واحد رقم يجب أن تضربه في عدد سيرفراتك عندما تخطط: عشرون سيرفراً قد تعني ساعات، فجدول الفحص الشهري ليلاً لا في ساعات العمل. ## ماذا يحدث داخل الفحص خلال 28 دقيقة؟ من الخارج يبدو الفحص شريط تقدم يتحرك من صفر إلى مئة، وفي سجلنا بقي الشريط عند 98% قرابة عشر دقائق قبل أن ينتهي، وظن أحد أعضاء الفريق أن الفحص علق. والحقيقة أن الفحص يمر بمراحل متتالية، وفهمها يشرح هذا التوقف ويشرح شكل التقرير أيضاً. ### المرحلة الأولى: هل الهدف حي؟ Alive Test قبل أي شيء يسأل الفاحص: هل يوجد جهاز على هذا العنوان أصلاً؟ والطريقة الافتراضية إرسال Ping، ويمكن تغييرها إلى محاولة اتصال TCP أو ARP كما في [توثيق اختبار الحياة](https://docs.greenbone.net/GSM-Manual/gos-22.04/en/scanning.html?ref=arabroot.io#alive-test). وتنبه Greenbone إلى أن هذا الاختبار قد يخطئ: فجدار ناري يمنع Ping يجعل جهازاً حياً يبدو ميتاً، فيتخطاه الفاحص كله ولا يظهر في التقرير شيء، وهي المشكلة نفسها التي رأيناها في Nuclei مع الأهداف المستبعدة. فإذا كان تقريرك عن سيرفر فارغاً تماماً، فأول سؤال: هل تخطاه اختبار الحياة؟ والحل في هذه الحالة خيار «Consider Alive» الذي يفترض أن الهدف حي ويكمل. ### المرحلة الثانية: مسح المنافذ Port Scan ثم يمر الفاحص على قائمة المنافذ التي اخترناها، كل منافذ TCP وأشهر مئة منفذ UDP، ليعرف أيها مفتوح. وهذه المرحلة سريعة على TCP وبطيئة على UDP، لأن UDP لا يرد غالباً حين يكون المنفذ مغلقاً، فينتظر الفاحص مهلة لكل منفذ. ولذلك فاختيار قائمة المنافذ قرار وقت: قائمة كل منافذ UDP قد تضاعف مدة الفحص، وأغلب الخدمات المهمة على TCP. ### المرحلة الثالثة: التعرف على الخدمة واختيار الاختبارات على كل منفذ مفتوح يحاول الفاحص أن يعرف ما الخدمة ونسختها، فيقرأ رد SSH ويعرف أنه OpenSSH 9.2p1، ويقرأ رد FTP ويعرف أنه vsftpd، ويطلب صفحة HTTP ويعرف أنه Apache. وهنا يظهر ذكاء إعداد Full and fast: فهو لا يشغل اختبارات Windows على سيرفر Linux، ولا اختبارات WordPress على موقع ليس فيه WordPress، بل يختار من عشرات آلاف الاختبارات ما يناسب الخدمات المكتشفة فقط. ونتائج السجل Log الاثنتان والعشرون في تقريرنا هي مخرج هذه المرحلة: «SSH Server type and version» و«HTTP Server type and version» و«CPE Inventory»، أي جرد ما وجده الفاحص. ### المرحلة الرابعة: تشغيل الاختبارات NVTs الآن يشغل الفاحص الاختبارات المختارة بالتوازي، وهنا وصل استهلاك ospd-openvas إلى ثلاثة معالجات. ونوعا الاختبارات اللذان شرحناهما في قسم جودة الكشف يعملان هنا: اختبارات تتصل بالخدمة وتجرب شيئاً وتقرأ الرد، مثل اختبار FTP الذي حاول الدخول دون تشفير فقبلته الخدمة، واختبارات تقارن رقم النسخة المكتشف في المرحلة الثالثة بقائمة النسخ المتأثرة، مثل كل اختبارات OpenSSH. والنوع الثاني سريع لأنه لا يرسل شيئاً جديداً، والنوع الأول أبطأ لأنه ينتظر ردوداً. ### المرحلة الأخيرة: الجمع والتقرير، ولماذا يقف الشريط عند 98% بعد انتهاء الاختبارات يرسل الفاحص النتائج إلى gvmd، الذي يحفظها في PostgreSQL ويربط كل نتيجة بسجلات CVE وCERT من قاعدة SCAP، ويحسب الخطورة. وبعض الاختبارات الأخيرة بطيئة بطبيعتها، مثل اختبارات تنتظر انتهاء مهلات الشبكة، فيبقى الشريط عند 98% دقائق. فلا تقم بإيقاف الفحص في هذه المرحلة، والسبب أنك تخسر النتائج التي لم تحفظ بعد، وانتظر حتى تصبح الحالة Done. ## قراءة التقرير Report فتح الفريق التقرير في الواجهة فرأى هذه الصورة في قائمة المهام: خطورة السيرفر 4.8، متوسطة Medium. ارتاح الجميع: لا شيء حرج. ![قائمة المهام في OpenVAS تعرض مهمة scan sce-ov-target بحالة Done وتقرير واحد وأعلى خطورة 4.8 متوسطة، مع ملاحظة أن الفلتر المطبق min_qod=70](https://arabroot.io/content/images/2026/10/openvas-lab-05-tasks.webp) قائمة المهام تقول إن أعلى خطورة 4.8 متوسطة، والفلتر في أسفل الصفحة يقول min\_qod=70 لكن انظر إلى السطر الصغير في أسفل الصورة: `min_qod=70`. هذا الفلتر الافتراضي يخفي كل نتيجة جودة كشفها أقل من 70%. فعندما أزلنا الفلتر وطلبنا كل النتائج، تغيرت الصورة تماماً: ![صفحة النتائج في OpenVAS بعد إزالة فلتر الجودة: 37 نتيجة، منها نتيجتان حرجتان 9.8 على OpenSSH على المنفذ 22 بجودة كشف 30 بالمئة](https://arabroot.io/content/images/2026/10/openvas-lab-08-results-qod0.webp) بعد إزالة فلتر الجودة: 37 نتيجة، وفي أعلاها نتيجتان حرجتان 9.8 على OpenSSH بجودة 30% والجدول التالي يجمع الصورتين بالأرقام، من التقرير نفسه بالفلترين: | الخطورة | كل النتائج (QoD 0) | الافتراضي (QoD 70 فأعلى) | | ------------- | ------------------ | ------------------------ | | حرجة Critical | 2 | 0 | | عالية High | 2 | 0 | | متوسطة Medium | 6 | 1 | | منخفضة Low | 5 | 3 | | سجل Log | 22 | 22 | | المجموع | 37 | 26 | فأي الصورتين هي الحقيقة؟ للإجابة يجب أن نفهم جودة الكشف. ### جودة الكشف Quality of Detection كل نتيجة في OpenVAS لها قيمة جودة كشف QoD بين صفر ومئة بالمئة، تصف مدى موثوقية الاكتشاف، و[يعرض التقرير افتراضياً](https://docs.greenbone.net/GSM-Manual/gos-22.04/en/reports.html?ref=arabroot.io) النتائج التي جودتها 70% فأعلى فقط. والشكل التالي يبين ما تعنيه القيم: ![رسم لجودة الكشف: اختبار مؤكد 95 بالمئة، كشف نشط 80 بالمئة، استنتاج من رد الخدمة 50 بالمئة قد يخطئ مع الإصلاح المنقول، تخمين عام 30 بالمئة تحت العتبة، مع خط العتبة الافتراضية 70 بالمئة](https://arabroot.io/content/images/2026/10/openvas-lab-04-qod.webp) الاختبار المؤكد أعلى ثقة من الاستنتاج من رقم النسخة، والعتبة الافتراضية 70% والفكرة بسيطة: الاختبار الذي يرسل طلباً ويؤكد الثغرة من الرد جودته عالية، أما الاستنتاج من رقم النسخة في رد الخدمة فجودته منخفضة، لأن الفاحص يرى ما تعلنه الخدمة لا ما هو مثبت فعلاً. والخطورة Severity في التقرير تتبع مقياس CVSS: حرجة من 9.0، وعالية من 7.0، ومتوسطة من 4.0، ومنخفضة حتى 3.9، وما قيمته صفر فهو سجل Log أي معلومة لا ثغرة، مثل «هذا السيرفر يشغل Apache». ### النتائج الحرجة المخفية: إنذارات خاطئة من رقم النسخة كل نتائج OpenSSH العالية والحرجة كانت بجودة 30%، ما عدا واحدة بجودة 50%. وعندما فتحنا تفاصيل نتيجة regreSSHion، وهي ثغرة تنفيذ أوامر عن بعد مشهورة في 2024، كان سبب الحكم مكتوباً بوضوح: ```text Installed version: 9.2p1 Fixed version: 9.8 Installation path / port: 22/tcp ``` أي أن الفاحص قرأ من رد SSH أن النسخة 9.2p1، وقارنها بالنسخة 9.8 التي أصلحت الثغرة في مشروع OpenSSH الأصلي، فحكم بأن السيرفر متأثر. لكنه لم ير اللاحقة `deb12u10`، لأن رد الخدمة لا يحملها. فذهبنا إلى المصدر الرسمي، متتبع الثغرات في Debian، وسألنا عن كل ثغرة: | نتيجة OpenVAS | الخطورة | CVE | أصلحتها Debian في | الهدف يشغل | | ------------------------------------ | ------- | -------------------------------------------------------------------------------------------- | ----------------- | ---------- | | OpenSSH 8.9 - 9.2 Restriction Bypass | 9.8 | [CVE-2023-28531](https://security-tracker.debian.org/tracker/CVE-2023-28531?ref=arabroot.io) | 1:9.2p1-2+deb12u2 | deb12u10 | | OpenSSH < 9.3p2 RCE | 9.8 | [CVE-2023-38408](https://security-tracker.debian.org/tracker/CVE-2023-38408?ref=arabroot.io) | 1:9.2p1-2+deb12u1 | deb12u10 | | regreSSHion | 8.1 | [CVE-2024-6387](https://security-tracker.debian.org/tracker/CVE-2024-6387?ref=arabroot.io) | 1:9.2p1-2+deb12u3 | deb12u10 | | Terrapin Attack | 6.5 | [CVE-2023-48795](https://security-tracker.debian.org/tracker/CVE-2023-48795?ref=arabroot.io) | 1:9.2p1-2+deb12u2 | deb12u10 | فالثغرات الأربع أصلحتها Debian بالنقل في تحديثات أقدم بكثير من النسخة المثبتة، أي أنها إنذارات خاطئة False Positives كلها. وهذه هي المشكلة نفسها التي رأيناها مع Redis في [مقال Nuclei](https://arabroot.io/articles/%D9%81%D8%AD%D8%B5-%D8%A7%D9%84%D8%AB%D8%BA%D8%B1%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%B9%D8%B1%D9%88%D9%81%D8%A9-%D9%85%D8%B9-nuclei-%D9%81%D9%8A-%D9%85%D8%AE%D8%AA%D8%A8%D8%B1-%D9%85%D8%B9%D8%B2%D9%88%D9%84/)، وشرحناها في [إدارة الثغرات](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D8%AB%D8%BA%D8%B1%D8%A7%D8%AA-vulnerability-management-%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA%D9%83/) باسم الإصلاح المنقول Backport، لكنها هنا أكبر: أربع نتائج من أخطر ما في التقرير. ومن هنا تفهم لماذا جعلت Greenbone العتبة الافتراضية 70%: فهي تخفي هذه الاستنتاجات الضعيفة حتى لا تغرق التقرير بإنذارات خاطئة على التوزيعات التي تنقل الإصلاحات، وهي أغلب توزيعات السيرفرات. والدرس العملي لك ذو وجهين: لا تخفض العتبة وتذعر من كل نتيجة حمراء، ولا تتجاهل ما تحت العتبة تماماً، فقد يكون سيرفراً لم يحدث فعلاً. والحل الأنسب أن تؤكد النتائج منخفضة الجودة من داخل السيرفر، بقراءة قائمة الحزم ومقارنتها بمتتبع التوزيعة، كما فعلنا بالضبط، أو بإعطاء OpenVAS صلاحية دخول للسيرفر عبر SSH، فيقرأ قائمة الحزم بنفسه بدل الاستنتاج من رد الخدمة، وهو ما يسمى الفحص الموثق Authenticated Scan. ### ماذا بقي من نتائج حقيقية؟ بعد استبعاد الإنذارات الخاطئة، بقيت نتائج صحيحة يجب أن يعمل عليها الفريق، وأهمها: - **FTP يقبل الدخول بنص واضح FTP Unencrypted Cleartext Login (4.8، جودة 70%):** وهذه نتيجة مؤكدة من السلوك، فالاختبار أرسل طلب دخول وقبلته الخدمة دون أن تطلب تشفير TLS أولاً، ورد السيرفر مكتوب في التفاصيل. ومعناها أن كلمة مرور الشريك الذي يرفع الملفات تمر في الشبكة مقروءة. والإصلاح إجبار TLS في vsftpd أو استبدال FTP بـ SFTP. - **خوارزميات MAC ضعيفة في SSH (2.6، جودة 80%):** السيرفر ما زال يقبل خوارزميات قديمة، والإصلاح تقييدها في إعداد sshd. - **كشف التوقيت TCP Timestamps وICMP Timestamp (2.6 و2.1):** معلومات تساعد المهاجم على تقدير مدة تشغيل السيرفر، وخطورتها منخفضة. والمفارقة التي توقف عندها الفريق أن أخطر نتيجة حقيقية في التقرير جاءت بخطورة 4.8 فقط، متوسطة، بينما جاءت أخطر الأرقام، 9.8، على إنذارات خاطئة. والسبب أن الخطورة تقيس الثغرة في المطلق، لا في سياق شركتك. ففي سياق شركة الحجوزات، خدمة FTP يستخدمها شريك يرفع ملفات الحجوزات، وكلمة مروره تمر بنص واضح عبر الإنترنت، فمن يستطيع أن يرى حركة الشبكة في أي نقطة بين الشريك والسيرفر يرى كلمة المرور ويدخل بها. وهذا أخطر على الشركة عملياً من ثغرة نظرية مصلحة في OpenSSH. لذلك لا تقم بترتيب الإصلاح بالرقم وحده، بل بالرقم مع السياق: هل الخدمة مكشوفة؟ هل تحمل بيانات حساسة؟ هل الثغرة مؤكدة أم مستنتجة؟ وهذه الأسئلة هي ما سنحولها في DefectDojo إلى أولوية ومهلة إصلاح، فقد ترفع خطورة نتيجة FTP يدوياً لأنها في سياقك أعلى مما يقوله الرقم. ولاحظ أن Apache 2.4.68 لم يظهر بأي ثغرة، لأنه حديث، وأن نتائج السجل الاثنتين والعشرين مفيدة رغم أنها ليست ثغرات: فهي جرد Inventory لما يعمل على السيرفر، مثل نوع الخادم وإصداره والخوارزميات التي يدعمها، وهذا الجرد قد يكشف خدمة لم يعرف أحد أنها تعمل. ![صفحة التقرير في OpenVAS بحالة Done ومدة الفحص 0:28 ساعة وسيرفر واحد مفحوص، والفلتر المطبق levels=chml min_qod=70 يعرض 4 من 37 نتيجة](https://arabroot.io/content/images/2026/10/openvas-lab-06-report.webp) التقرير: مدة الفحص 28 دقيقة، والفلتر الافتراضي يعرض 4 نتائج من 37 وهذه النتائج كلها، الصحيحة والخاطئة، سوف نصدرها بصيغة XML إلى DefectDojo في المقال القادم، حيث نسجل قرار الإنذار الخاطئ مع رابط متتبع Debian مرة واحدة، فلا يعود في كل فحص شهري. ## الفحص الموثق Authenticated Scan: الحل الصحيح للإنذارات الخاطئة رأينا أن أكبر مشكلة في تقريرنا أن الفاحص يرى رقم النسخة في رد الخدمة ولا يرى ما ثبتته التوزيعة فعلاً. وتحل Greenbone هذه المشكلة بما تسميه الفحص الموثق Authenticated Scan أو الفحوص المحلية Local Security Checks: تعطي الفاحص حساباً يدخل به السيرفر عبر SSH، فيقرأ قائمة الحزم المثبتة بنسخها الكاملة، مثل `1:9.2p1-2+deb12u10`، ويقارنها بنشرات التوزيعة نفسها بدل مقارنة الرقم الأصلي بنشرة المشروع. وهذا بالضبط ما فعلناه يدوياً حين ذهبنا إلى متتبع Debian، لكن الفاحص يفعله لكل حزمة في كل فحص. ويصف [توثيق Greenbone](https://docs.greenbone.net/GSM-Manual/gos-22.04/en/scanning.html?ref=arabroot.io#authenticated-scan) هذا الفحص بأنه يجمع نظرة المهاجم من الخارج مع نظرة من الداخل بحساب صالح، فيقرأ مستوى التحديثات ونسخ البرامج التي لا يراها الفحص البعيد، ويؤكد أن الفحوص المحلية لا تغير شيئاً على الهدف، وإنما تقرأ فقط، وإن كان الدخول نفسه يظهر في سجلات السيرفر. والإعداد في ثلاث خطوات: تنشئ اعتماداً Credential من نوع اسم مستخدم ومفتاح SSH، ثم تربطه بالهدف في خانة SSH Credential، ثم تشغل المهمة نفسها. ولهذا الحل ثمن يجب أن تزنه، فتوثيق Greenbone نفسه يضع ممارسات أمنية واضحة له: - **حساب مخصص بأقل صلاحية:** مستخدم عادي يكفي غالباً على Linux لقراءة قائمة الحزم، فلا تعط الفاحص حساب root، والسبب أن هذا الحساب صار مفتاحاً لكل سيرفراتك مخزناً في قاعدة الفاحص. - **لا تفحص نطاقات كاملة بالاعتماد:** يوصي التوثيق بعدم ربط اعتماد SSH بنطاق شبكة كامل، لأن أي جهاز دخيل في النطاق سوف يستقبل محاولة الدخول وقد يلتقط الاعتماد. - **الأنظمة الموثوقة فقط:** لا تستخدم الفحص الموثق على أنظمة يدخلها مستخدمون آخرون، فقد يراقب أحدهم الجلسة. ولم نشغل الفحص الموثق في هذا المختبر، فاقتصرنا على الفحص البعيد ليظهر الفرق كما يراه أغلب من يثبت OpenVAS أول مرة، والقرار العملي لشركة الحجوزات أن تضيفه على سيرفرات Linux الثلاثة بحساب قراءة مخصص، فتختفي أغلب الإنذارات الخاطئة من التقرير الشهري. ## الموارد Resources التي استهلكها هنا الرقم الذي غير رأي الفريق. قسنا الذاكرة بالأمر `docker stats` أثناء الفحص، وحجم ال Volumes بالأمر `du` بعد اكتمال التغذية: | المورد | القيمة في المختبر | | ----------------------- | ------------------------------------------------------------------------ | | قاعدة PostgreSQL pg-gvm | Volume بحجم 25.5 GB، وذاكرة 8.7 GiB أثناء الفحص أغلبها ذاكرة مؤقتة Cache | | بيانات SCAP الخام | Volume بحجم 10.4 GB | | اختبارات الثغرات وnotus | نحو 639 MiB و713 MiB | | ال Images السبعة عشر | قرابة 7 GB | | الفاحص ospd-openvas | حتى 398 MiB وثلاثة معالجات في الذروة | | gvmd وredis | نحو 553 MiB و372 MiB | أي أن المجموع على القرص قرابة 43 GB لفحص سيرفر واحد، قبل أن نحفظ أي تقرير، وأكبر جزء منه قاعدة PostgreSQL التي بنيت من بيانات NVD. وهذا يفسر لماذا توصي Greenbone بستين جيجابايت لا بعشرين. وفي المختبر انخفضت المساحة الحرة على قرص السيرفر المضيف بشكل واضح أثناء البناء. لذلك لا تشغل OpenVAS بجانب تطبيقاتك على سيرفر صغير، وخصص له آلة مستقلة بقرص واسع وذاكرة لا تقل عن 16 GB إذا أردت أن يبقى سريعاً. وقارن هذا بـ [Nuclei](https://arabroot.io/articles/%D9%81%D8%AD%D8%B5-%D8%A7%D9%84%D8%AB%D8%BA%D8%B1%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%B9%D8%B1%D9%88%D9%81%D8%A9-%D9%85%D8%B9-nuclei-%D9%81%D9%8A-%D9%85%D8%AE%D8%AA%D8%A8%D8%B1-%D9%85%D8%B9%D8%B2%D9%88%D9%84/) الذي يعمل بأقل من 1 GiB وبلا قاعدة بيانات، و[Wazuh](https://arabroot.io/articles/%D9%85%D8%AE%D8%AA%D8%A8%D8%B1-%D8%A7%D9%83%D8%AA%D8%B4%D8%A7%D9%81-%D8%A7%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%AA%D8%A7%D8%AB%D8%B1%D8%A9-%D8%A8%D8%AB%D8%BA%D8%B1%D8%A9-cve-%D9%88%D8%A7%D8%B5%D9%84%D8%A7%D8%AD%D9%87%D8%A7/) الذي احتاج نحو 4.4 GiB و16 GB. ## التشغيل اليومي: التحديث والنسخ الاحتياطي ### كيف تحدث التغذية بعد التحميل الأول؟ البيانات في الحاويات الجديدة تأتي داخل ال Images نفسها، فالتحديث يعني أن تسحب Images البيانات الأحدث وتعيد تشغيلها، فتنسخ الفرق إلى ال Volumes، ثم يستورد gvmd التغييرات. وتشرح [وثائق التحديث](https://greenbone.github.io/docs/latest/22.4/container/workflows.html?ref=arabroot.io#updating-the-greenbone-community-containers) الخطوتين: سحب ال Images ثم `up -d`. والتحديث اللاحق أسرع بكثير من الأول، لأن قاعدة SCAP موجودة ويضاف إليها ما تغير فقط. والقرار العملي أن تجدول التحديث يومياً في الليل، وأن تفحص بعده بساعات لا مباشرة، حتى لا يبدأ فحص وقاعدته في منتصف الاستيراد. وتذكر أن «حداثة» فحصك تقاس بتاريخ التغذية لا بتاريخ البرنامج: فالتقرير الذي أخرجناه يوم 26 أكتوبر بني على اختبارات بتاريخ 24 أكتوبر، أي أن أي ثغرة نشرت يوم 25 لا يعرفها الفاحص بعد. وهذا ما يجب أن يكتب في التقرير الذي تسلمه للمدقق. ### ماذا تنسخ احتياطياً؟ لا تقم بنسخ ال Volumes كلها، فـ 43 GB أغلبها بيانات تعيد Greenbone إنتاجها، وبيانات SCAP وVTs تأتي من التغذية مرة أخرى. أما ما لا يعود فهو ما صنعه فريقك: الأهداف والمهام والاعتمادات والتقارير السابقة وقرارات التجاوز Overrides، وكلها في قاعدة gvmd داخل PostgreSQL. والنسخة العملية أن تأخذ `pg_dump` لقاعدة gvmd، أو أن تصدر التقارير المهمة بصيغة XML وتحفظها في DefectDojo، الذي يصبح هو ذاكرة النتائج، ويبقى OpenVAS أداة فحص يمكن إعادة بنائها. ## التغذية المجتمعية والتجارية Community vs Enterprise الأدوات نفسها مفتوحة المصدر بالكامل، لكن بيانات التغذية نوعان. فالتغذية المجتمعية Community Feed مجانية، وهي ما استخدمناه، وتكفي للتعلم وللفرق الصغيرة. أما التغذية التجارية Enterprise Feed فاشتراك مدفوع تبيعه Greenbone مع أجهزتها الجاهزة، وبحسب [صفحة مقارنة التغذية](https://www.greenbone.net/en/feed-comparison/?ref=arabroot.io) تضيف اختبارات لمنتجات المؤسسات، وتغطية أسرع للثغرات الجديدة، واختبارات نشطة أكثر تقلل الإنذارات الخاطئة. وتعرض الشركة نسخة تجريبية مجانية لمدة 14 يوماً من منتجها التجاري للشركات الصغيرة، والسعر حسب الطلب كما في [صفحة مقارنة المنتجات](https://www.greenbone.net/en/product-comparison/?ref=arabroot.io). فإذا كنت تفحص سيرفراتك الخاصة فالتغذية المجتمعية مناسبة، وعليك أن تعرف أن بعض اختبارات المنتجات التجارية لن تكون لديك، وأن نسبة الاستنتاجات من رقم النسخة فيها أعلى، كما رأينا. ## متى تختار OpenVAS، ومتى يكفي Nuclei؟ بعد التجربة، كتب فريق الشركة هذا الجدول ليقرر: | السؤال | Nuclei | OpenVAS | | ---------------------------------------------- | ----------------------- | --------------------------- | | هل خدماتي المكشوفة متأثرة بثغرة مستغلة معروفة؟ | الأنسب، في أقل من دقيقة | يجيب، لكن بعد ساعات التحضير | | فحص كل منفذ بكل اختبار وإعداد | لا | الأنسب | | تقرير مصنف شامل للمدقق | يحتاج DefectDojo | جاهز في الواجهة | | إعدادات التشفير وخدمات قديمة مثل FTP | محدود | شامل | | الموارد | أقل من 1 GiB، بلا قاعدة | نحو 43 GB وأكثر من 8 GiB | | وقت التحضير | دقائق | أكثر من أربع ساعات أول مرة | | الإنذارات الخاطئة من رقم النسخة | في بعض القوالب | كثيرة تحت عتبة QoD | فقررت الشركة أن تبقي Nuclei أسبوعياً لأنه سريع وخفيف، وأن تشغل OpenVAS شهرياً على آلة مستقلة للفحص الشامل، وأن تضيف الفحص الموثق بـ SSH لاحقاً حتى تقل الإنذارات الخاطئة، وأن تجمع النتيجتين في DefectDojo. والأداتان لا تتنافسان، فكل منهما تجيب عن سؤال مختلف. ## مشكلات شائعة Common Problems وحلولها - **قائمة إعدادات الفحص فارغة ولا يظهر Full and fast:** بيانات التغذية لم تكتمل بعد، والإعدادات تنشأ بعد بناء قاعدة SCAP كاملة. تابع `` وسجل gvmd، وانتظر، فقد يستغرق ذلك ساعات في أول تشغيل. - **الفحص يبقى في الانتظار Queued:** اختبارات الثغرات لم تنته من التحميل في الفاحص، والرسالة `Loading VTs. Scans will be queued until VTs are loaded` في سجل ospd-openvas تعني أن تنتظر، وأعد تشغيل `ospd-openvas` إن طال الأمر كما في [دليل حل المشكلات](https://greenbone.github.io/docs/latest/22.4/container/troubleshooting.html?ref=arabroot.io). - **لا يمكن الدخول للواجهة ورسالة Connection refused على gvmd.sock:** أعد تشغيل `gvmd`، فغالباً واجه مشكلة في الوصول إلى PostgreSQL. - **التقرير يقول متوسطة والنتائج الحرجة غائبة:** الفلتر الافتراضي `min_qod=70` يخفيها، فاعرض النتائج بجودة أقل ثم أكد كل نتيجة من داخل السيرفر. - **نتائج حرجة على نسخة تعرف أنها محدثة:** جودة الكشف 30% تعني استنتاجاً من رقم النسخة، فتحقق من متتبع التوزيعة، أو فعل الفحص الموثق بـ SSH. - **القرص يمتلئ أثناء البناء:** قاعدة PostgreSQL وحدها وصلت 25.5 GB، فخصص أكثر من 50 GB قبل التشغيل. ## كيف تقدم التقرير للمدقق؟ عاد فريق الشركة إلى المدقق بالتقرير، والخطأ الذي كاد أن يقع فيه أن يسلم ملف PDF من 37 نتيجة كما هو. فالمدقق يقرأ «حرجة» فيسأل: لماذا لم تصلحوها؟ والفريق يعرف أنها إنذارات خاطئة لكن الملف لا يقول ذلك. والطريقة الأنسب أن يجيب التقرير عن البنود التي يذكرها الضابط 2-10-3 في ECC، وهي التقييم الدوري، والتصنيف بحسب الخطورة، والمعالجة بحسب التصنيف: - **التقييم الدوري:** تاريخ الفحص، وتاريخ التغذية التي بني عليها، والأهداف التي فحصت، وأي هدف تخطاه اختبار الحياة. - **التصنيف:** النتائج بكل مستويات الجودة، مع بيان الفلتر المستخدم، لا الفلتر الافتراضي وحده الذي يخفي أربع نتائج حرجة وعالية. - **المعالجة:** لكل نتيجة قرار: أصلحت ومتى، أو إنذار خاطئ مع رابط المصدر الذي يثبت ذلك، أو مقبولة مؤقتاً مع السبب وتاريخ المراجعة. والبند الثالث هو ما لا يفعله OpenVAS جيداً وحده، فقراراته تحفظ في Overrides داخل المنصة، ولا تتابع موعد الإصلاح ولا من يملكه. ولهذا ينتقل التقرير في المقال القادم إلى DefectDojo، الذي يحول القائمة إلى مهام لها مهلة إصلاح SLA، ويحفظ قرار الإنذار الخاطئ مع رابط متتبع Debian، ويعرض للمدقق في صفحة واحدة ما فتح وما أغلق ومتى. ## قائمة تحقق قبل تشغيل OpenVAS - آلة مستقلة بقرص لا يقل عن 50 GB وذاكرة لا تقل عن 8 GB، ويفضل 16 GB. - كلمة مرور المدير تغيرت، والواجهة على 127.0.0.1 أو خلف VPN. - وقت كاف لأول تحميل للتغذية، وخطة لا تضعه قبل التدقيق مباشرة. - ورقة نطاق موقعة، وإخطار فريق التشغيل، وفحص ليلي خارج ساعات العمل. - إعداد Full and fast للفحص الدوري، والفحص الموثق بـ SSH حيث أمكن. - قراءة النتائج بكل مستويات الجودة، وتأكيد ما تحت 70% من داخل السيرفر. - تصدير XML إلى DefectDojo، وتسجيل قرار الإنذار الخاطئ مع رابط المصدر. ## الخلاصة وصلنا لنهاية الموضوع، وأهم ما ظهر في المختبر: - OpenVAS فاحص شبكي شامل يجرب كل اختبار مناسب على كل منفذ، ويكمل Nuclei السريع والجرد من داخل السيرفر. - الثقل في التحضير لا في الفحص: أكثر من أربع ساعات قبل أول فحص، أغلبها بناء قاعدة SCAP في PostgreSQL، ثم 28 دقيقة فقط للفحص. - المنصة احتاجت قرابة 43 GB من القرص وأكثر من 8 GiB من الذاكرة لسيرفر واحد، فخصص لها آلة مستقلة. - الفلتر الافتراضي QoD 70 أخفى نتيجتين حرجتين ونتيجتين عاليتين على OpenSSH، وكلها إنذارات خاطئة لأن Debian نقلت إصلاحاتها. - جودة الكشف هي مفتاح قراءة التقرير، والتأكيد من داخل السيرفر أو الفحص الموثق يحل مشكلة الاستنتاج من رقم النسخة. - النتائج الحقيقية كانت أبسط وأهم: FTP يقبل كلمات المرور بنص واضح، وخوارزميات SSH قديمة. [![](https://arabroot.io/content/images/2026/10/nuclei-lab-cover-cover.webp)دليلفحص الثغرات المعروفة Known Vulnerabilities مع Nucleiشغلنا Nuclei على خدمات قديمة في شبكة Docker معزولة، فأصاب في ثغرات Apache وGrafana وأعطى أربعة إنذارات خاطئة على Redis.](https://arabroot.io/articles/%D9%81%D8%AD%D8%B5-%D8%A7%D9%84%D8%AB%D8%BA%D8%B1%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%B9%D8%B1%D9%88%D9%81%D8%A9-%D9%85%D8%B9-nuclei-%D9%81%D9%8A-%D9%85%D8%AE%D8%AA%D8%A8%D8%B1-%D9%85%D8%B9%D8%B2%D9%88%D9%84/)[![](https://arabroot.io/content/images/2026/10/defectdojo-lab-cover-cover.webp)دليلإدارة نتائج الفحص والثغرات مع DefectDojoاستوردنا نتائج Nuclei وOpenVAS الحقيقية إلى DefectDojo، فجمع التكرار وأغلق المصلح وحده، وكاد إعداد افتراضي واحد أن يفسد كل شيء.](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D9%86%D8%AA%D8%A7%D8%A6%D8%AC-%D8%A7%D9%84%D9%81%D8%AD%D8%B5-%D9%88%D8%A7%D9%84%D8%AB%D8%BA%D8%B1%D8%A7%D8%AA-%D9%85%D8%B9-defectdojo/)[![](https://arabroot.io/content/images/2026/10/vuln-tools-cover-cover.webp)دليلأدوات إدارة الثغرات Vulnerability Management مفتوحة المصدرأي أداة مفتوحة المصدر تجرد سيرفراتك وتطابقها مع الثغرات وتنبهك بالجديد، وماذا رأى Trivy وGrype فعلاً في ثغرات أكتوبر.](https://arabroot.io/articles/%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D8%AB%D8%BA%D8%B1%D8%A7%D8%AA-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1/)[![](https://arabroot.io/content/images/2026/10/vuln-lab-cover-cover.webp)دليلمختبر Lab: اكتشف السيرفرات المتأثرة بثغرة CVE جديدة وأصلحهافحصنا ثلاثة سيرفرات قديمة وسيرفراً محدثاً بأدوات Trivy وWazuh وسكربت تنبيه صغير، فظهر من يكتشف ثغرة الأسبوع ومن يفوته.](https://arabroot.io/articles/%D9%85%D8%AE%D8%AA%D8%A8%D8%B1-%D8%A7%D9%83%D8%AA%D8%B4%D8%A7%D9%81-%D8%A7%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%AA%D8%A7%D8%AB%D8%B1%D8%A9-%D8%A8%D8%AB%D8%BA%D8%B1%D8%A9-cve-%D9%88%D8%A7%D8%B5%D9%84%D8%A7%D8%AD%D9%87%D8%A7/)[![](https://arabroot.io/content/images/2026/10/security-oss-alternatives-cover-cover.webp)دليلحلول الأمن التجارية وبدائلها مفتوحة المصدر: متى توفر فعلاً؟لكل فئة من حلول الأمن التجارية الشائعة في السعودية بديل مفتوح المصدر، وهنا تعرف متى يوفر عليك فعلاً ومتى يكون التجاري أفضل.](https://arabroot.io/articles/%D8%AD%D9%84%D9%88%D9%84-%D8%A7%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%AC%D8%A7%D8%B1%D9%8A%D8%A9-%D9%88%D8%A8%D8%AF%D8%A7%D8%A6%D9%84%D9%87%D8%A7-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1/) ## تدريب عملي Practice - شغل المنصة على آلة اختبار، وسجل وقت كل مرحلة بمتابعة `` وسجل gvmd، وقارنها بأرقامنا. - افحص هدفاً تملكه، ثم اعرض النتائج بفلتر `min_qod=0`، واختر أعلى نتيجة جودتها منخفضة، وتحقق منها في متتبع ثغرات توزيعتك. ## سجل التحديثات - أكتوبر 2026: كتابة المقال وتنفيذ المختبر بين 25 و26 أكتوبر 2026 على Greenbone Community Edition مع openvas-scanner v23.52.3 وgvmd v26.42.0 وGSA v28.6.0 في شبكة Docker معزولة.