فحص الثغرات المعروفة Known Vulnerabilities مع Nuclei

تخيل شركة سعودية صغيرة تدير خدمة حجوزات عبر الإنترنت، فريقها خمسة عشر شخصاً، ولها ثلاثة سيرفرات افتراضية VPS مكشوفة على الإنترنت: موقع العملاء، ولوحة تحكم داخلية، وواجهة برمجة API للتطبيق. وفي اجتماع الاستعداد لمتطلبات الهيئة الوطنية للأمن السيبراني يسأل المدير سؤالاً بسيطاً: «أي من خدماتنا المكشوفة فيه ثغرة يستطيع أحد أن يستغلها اليوم؟». ولا أحد يعرف الجواب. الفريق يحدث الحزم بانتظام، لكن «نحدث بانتظام» ليست إجابة يقبلها مدقق، ولا تطمئن من يخشى أن تكون لوحة التحكم القديمة أو مكون نسيه أحدهم باب الدخول. وهذا بالضبط ما تجيب عنه أداة Nuclei: فحص سريع يسأل الخدمات المكشوفة سؤالاً محدداً، هل أنت مصاب بهذه الثغرة بعينها؟ ويجيب بتجربة السلوك لا بقراءة رقم النسخة.

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

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

• من أين جاء Nuclei، وما الفكرة التي يقوم عليها، ولماذا يختلف عن الفاحص الذي يقرأ رقم النسخة.
• الإذن المكتوب Authorization ونطاق الفحص Scope، ولماذا نبني المختبر على شبكة لا تصل إلى الإنترنت.
• بناء أهداف قديمة معروفة الثغرات مع نسخة مصلحة من كل منها للمقارنة.
• الفحص الأول وما ظهر فيه من أخطاء: ملف الاستثناءات المفقود ومشكلة أسماء الأهداف.
• القالب Template من الداخل: كيف يحكم، والفرق بين اختبار السلوك ومقارنة رقم الإصدار.
• اختيار نطاق الفحص: الفحص التلقائي وملف KEV، والفرق بينهما في الوقت وعدد الطلبات.
• فرز النتائج: الإصابة الصحيحة والإنذار الخاطئ والنتائج المكررة، ومشكلة Redis الواحدة في أحد عشر سطراً.
• كتابة قالب خاص Custom Template لما لا تعرفه القوالب العامة في تطبيقك.
• إعادة الفحص بعد الإصلاح، والموارد، ومتى تشغله، والرخصة والنسخة التجارية.

لماذا وجد Nuclei أصلاً؟ مشكلة رقم النسخة

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

ولذلك ظهر نهج آخر: بدل أن تسأل «ما رقم نسختك؟»، تسأل «هل تتصرف كخدمة مصابة؟». ترسل طلباً محدداً وتنظر في الرد: هل تسرب الخدمة ملف /etc/passwd؟ هل تقبل الأمر دون كلمة مرور؟ هل ترد بالرسالة التي ترد بها الخدمة المصابة فقط؟ هذا هو نهج Nuclei من شركة ProjectDiscovery، أداة مكتوبة بلغة Go تقرأ «قوالب Templates» كل قالب منها يصف ثغرة واحدة: ما الطلب الذي يرسل، وما الدليل الذي يبحث عنه في الرد. والقوالب يكتبها مجتمع واسع ويراجعها الفريق، وهي مستودع منفصل عن الأداة نموه أسرع بكثير، لأن كل ثغرة جديدة تحتاج قالباً جديداً بينما الأداة نفسها تستقر.

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

ولتضع Nuclei في مكانه بين أدوات السلسلة، قارنه بما سبق. ففي مختبر Trivy وWazuh كان الفاحص يقرأ قائمة الحزم من داخل السيرفر، فيرى كل حزمة مثبتة لكنه لا يعرف هل الخدمة مكشوفة فعلاً على الإنترنت ولا هل إعدادها آمن. وNuclei عكسه تماماً: لا يدخل السيرفر، ولا يرى حزمة واحدة، بل يقف موقف المهاجم ويسأل الخدمة من الخارج. ولذلك فالأداتان تكملان بعضهما: الجرد من الداخل يرى ما ثبت، والفحص من الخارج يرى ما ينكشف ويختبر ما يتصرف. من يكتفي بإحداهما يرى نصف الصورة، ومن يجمعهما في مكان واحد، وهو ما سنفعله مع DefectDojo في آخر السلسلة، يرى الخدمة من وجهيها.

قبل أي فحص: الإذن المكتوب ونطاق الفحص Scope

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

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

وتطلب الضوابط الأساسية للأمن السيبراني ECC-2:2024 من الهيئة الوطنية للأمن السيبراني في الضابط 2-10-3 تقييم الثغرات واكتشافها بشكل دوري وتصنيفها بحسب خطورتها، وفحص Nuclei المنتظم على خدماتك المكشوفة جزء عملي من هذا، بشرط أن تبقى نتائجه موثقة ونطاقه مأذوناً به.

ولتفهم لماذا يصر الفريق على هذا الفحص الدوري بدل الاكتفاء بالتحديث، تذكر أن إحدى الثغرات التي سنفحصها في المختبر، ثغرة مسار الملفات في Apache 2.4.49، أضيفت إلى قائمة الثغرات المستغلة فعلاً KEV بعد أيام قليلة من كشفها، لأنها استغلت على نطاق واسع على خوادم ويب مكشوفة لم تحدث في الوقت المناسب، كما تذكر صفحة ثغرات Apache. والفجوة بين «صدر الإصلاح» و«طبقنا الإصلاح على كل خدمة» هي بالضبط ما يملؤه الفحص: فالإصلاح موجود، لكن من يضمن أنه وصل إلى الخادم الذي أعده زميل غادر الفريق؟ الفحص يجيب عن هذا السؤال بدليل، لا بثقة.

المختبر Lab: أهداف قديمة ونسخها المصلحة

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

وأهداف Apache وGrafana القديمة من مشروع vulhub الذي يجمع بيئات Docker لثغرات معروفة لأغراض التعلم. والآن ننشئ الشبكة بالخيار --internal، وهو أهم سطر في المختبر، لأن Docker لا يضع لهذه الشبكة أي طريق إلى الخارج، فلا يستطيع أي طلب من الفاحص أن يغادرها إلى الإنترنت أو إلى شبكة جهازك:

docker network create --internal sce-nu-lab
docker build -t sce-nu-httpd:2.4.49-vulhub lab/httpd
docker build -t sce-nu-httpd:2.4.66-samecfg lab/httpd-fixed
docker run -d --name sce-nu-apache        --network sce-nu-lab sce-nu-httpd:2.4.49-vulhub
docker run -d --name sce-nu-apache-fixed  --network sce-nu-lab sce-nu-httpd:2.4.66-samecfg
docker run -d --name sce-nu-grafana       --network sce-nu-lab vulhub/grafana:8.2.6
docker run -d --name sce-nu-grafana-fixed --network sce-nu-lab grafana/grafana:8.3.1
docker run -d --name sce-nu-redis         --network sce-nu-lab redis:7.4.6-alpine
docker run -d --name sce-nu-juice         --network sce-nu-lab bkimminich/juice-shop:v20.3.0

والملف lab/httpd-fixed/Dockerfile هو ملف vulhub نفسه بعد تغيير سطر FROM إلى httpd:2.4.66، والسبب أننا نريد أن يكون الفرق الوحيد بين التوأمين هو الإصدار وليس الإعداد، فلو اختلف الإعداد لما عرفنا هل اختفت النتيجة بسبب الإصلاح أم بسبب تغيير آخر. والشكل التالي يبين المختبر كاملاً وما قاله Nuclei عن كل هدف، وسوف نشرح كل خانة فيه في بقية المقال:

تشغيل Nuclei وتثبيت إصدار القوالب Templates

Nuclei ترخيصه MIT، وآخر إصدار وقت التجربة هو v3.11.1 بتاريخ 8 أغسطس 2026. أما القوالب فمستودع منفصل بترخيص MIT أيضاً ونشاطه أعلى بكثير، فآخر إصدار v10.5.1 صدر في 23 أكتوبر 2026 ويحتوي 14104 ملف YAML. والأداة تنزل آخر القوالب وحدها عند التشغيل، لكننا ننزل إصداراً محدداً لسببين مهمين لأي فحص جاد: الأول أن الشبكة المعزولة لا تصل إلى GitHub أصلاً، والثاني، وهو الأهم في الإنتاج، أن النتائج يجب أن تكون قابلة للتكرار Reproducible، فإذا تغيرت القوالب بين فحصين لن تعرف هل تغيرت خدماتك أم تغيرت الأداة، ولن تستطيع أن تقارن فحص هذا الأسبوع بالأسبوع الماضي.

curl -sL -o tpl.zip https://github.com/projectdiscovery/nuclei-templates/archive/refs/tags/v10.5.1.zip
unzip -q tpl.zip
docker pull projectdiscovery/nuclei:v3.11.1

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

وحجم ال Image بعد التنزيل 1.3 GB، والسبب أنها تحمل متصفح Chromium لقوالب headless التي تفحص صفحات تحتاج تنفيذ JavaScript، والقوالب نفسها 86 MB بعد فك الضغط. وقائمة الأهداف ملف نصي بسيط، سطر لكل خدمة بعنوانها ومنفذها:

http://apache.lab
http://apache-fixed.lab
http://grafana.lab:3000
http://grafana-fixed.lab:3000
http://juice.lab:3000
redis.lab:6379

الفحص الأول: الطريقة البسيطة ولماذا لا تكفي

الطريقة البسيطة التي يبدأ بها أغلب الناس أن تعطي Nuclei قائمة الأهداف وتتركه يشغل كل شيء، وهذا ما فعله الفريق في أول محاولة:

docker run --rm --name sce-nu-scan --network sce-nu-lab \
  -v "$PWD/nuclei-templates-10.5.1":/root/nuclei-templates:ro \
  -v "$PWD/lab":/lab:ro -v "$PWD/out":/out \
  projectdiscovery/nuclei:v3.11.1 -duc -ni \
  -l /lab/targets.txt -jsonl -o /out/full.jsonl -stats -si 60

وبعد دقيقتين من التشغيل كان سطر الإحصاءات Statistics كما يلي:

{"duration":"0:02:00","errors":"687","hosts":"6","matched":"0","percent":"0","requests":"8677","rps":"72","templates":"11265","total":"995388"}

في المخرج أعلاه لاحظ التالي، فكل رقم فيه يحمل درساً:

• العدد الكلي 995388 طلباً لستة أهداف، أي نحو 166 ألف طلب لكل هدف، وبسرعة 72 طلباً في الثانية كان الفحص سوف يستغرق قرابة أربع ساعات. وهذا الرقم وحده كاف لتعرف أن تشغيل كل القوالب ليس طريقة عمل، لأن أغلبها لمنتجات لا تملكها أصلاً: قوالب WordPress ولوحات تحكم لمنتجات لم تسمع بها، كلها تجرب على خدماتك الست بلا فائدة.
• 11265 قالباً وليس 11212 كما سوف نرى بعد قليل، والفرق هو المشكلة الأولى التي اكتشفناها.
• صفر نتائج بعد دقيقتين، مع أننا نعرف يقيناً أن Apache 2.4.49 مصاب، وهذه هي المشكلة الثانية، وهي الأخطر.

فأوقفنا الفحص لنفهم السببين قبل أن نكمل، لأن إكمال فحص مدته أربع ساعات لا يجد شيئاً ليس استكشافاً للثغرات بل إضاعة للوقت.

لماذا تحتاج ملف nuclei-ignore؟

في بداية السجل ظهر هذا السطر مرتين، ومن السهل أن تتجاهله لأنه لا يوقف الفحص:

[ERR] Could not read nuclei-ignore file: open /root/.config/nuclei/.nuclei-ignore: no such file or directory

والملف .nuclei-ignore موجود في جذر مستودع القوالب، وفيه الوسوم Tags التي يستثنيها Nuclei من الفحص الافتراضي إلا إذا طلبتها صراحة، وهي dos وfuzz وbruteforce وlocal وtxt-service، وقائمة ملفات معروفة بأنها تعطي إنذارات خاطئة. ومعنى غيابه خطير: عندما تنزل القوالب بنفسك وتضعها في مجلد خاص، لا يجد Nuclei هذا الملف، فيشغل قوالب الحرمان من الخدمة والتخمين على أهدافك دون أن تطلب ذلك، كما يذكر توثيق التشغيل في قسم استثناء القوالب. أي أنك تظن أنك تفحص فحصاً آمناً، وأنت في الحقيقة تجرب قوالب قد تعطل خدمة. والحل أن تنسخ هذا الملف إلى مجلد الإعدادات:

mkdir -p cfg
cp nuclei-templates-10.5.1/.nuclei-ignore cfg/
# ثم أضف إلى أمر docker run:  -v "$PWD/cfg":/root/.config/nuclei

وبعد ذلك صار عدد القوالب المحملة 11212 بدل 11265، أي أن 53 قالباً من النوع الخطر خرجت من الفحص الافتراضي. هذا الفرق الصغير في الرقم هو الفرق بين فحص آمن وفحص قد يسقط خدمة في الإنتاج.

رسالة no address found for host: النتيجة الصامتة الخطيرة

والسبب الثاني لغياب النتائج ظهر في سطر آخر في السجل:

[INF] Skipped apache.lab:80 from target list as found unresponsive permanently: cause="no address found for host"

وهذا محير، لأن الاسم يعمل من أي Container آخر في الشبكة نفسها، فالأمر getent hosts juice.lab أعاد العنوان مباشرة، وفحص هدف واحد بقالب واحد نجح. الذي ظهر لنا بعد التجربة أن المشكلة تحدث فقط عند فحص عدة أهداف معاً بأحد عشر ألف قالب في وقت واحد: بعض استعلامات DNS تفشل تحت الضغط في خادم Docker المدمج على الشبكة المعزولة، وعندها يحكم Nuclei على الهدف بأنه «لا يستجيب نهائياً» ويخرجه من الفحص كله، دون أن يتوقف الفحص أو يصرخ.

وهذه أخطر نتيجة ممكنة في أي أداة فحص، لأن التقرير النهائي يقول «لا توجد نتائج» والحقيقة أن الهدف لم يفحص أصلاً. تخيل أن هذا حدث على سيرفر حقيقي في شركة الحجوزات: يسلم الفريق تقريراً نظيفاً للمدقق، والسيرفر المصاب لم تلمسه الأداة. الحل أن تثبت الأسماء في ملف hosts داخل ال Container الفاحص فلا تعتمد على DNS تحت الضغط:

for c in apache apache-fixed grafana grafana-fixed juice redis; do
  echo "--add-host $c.lab:$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' sce-nu-$c)"
done | tr '\n' ' ' > hosts.flags

ثم نضيف $(cat hosts.flags) إلى أمر التشغيل. والدرس الأعم الذي خرجنا به: اجعل عادتك أن تبحث في سجل كل فحص عن كلمة Skipped قبل أن تقرأ النتائج، لأن الهدف المستبعد لا يظهر في ملف النتائج أبداً، وغيابه من النتائج يبدو كأنه نظافة وهو في الحقيقة عمى.

القالب Template من الداخل: كيف يحكم؟

قبل أن نختار نطاقاً أذكى، لنفتح قالباً ونفهم كيف يقرر، لأن هذا الفهم هو ما يسمح لك أن تثق بنتيجة وتشك في أخرى. القالب ملف YAML فيه وصف الثغرة، ثم قسم للطلبات التي ترسل، ثم «المطابقات Matchers» التي تقرر من الرد هل الهدف مصاب. وهناك نوعان من القوالب يجب أن تفرق بينهما دائماً، والشكل التالي يوضح الفرق:

• قالب يختبر السلوك Behaviour: يرسل طلباً ويبحث في الرد عن دليل لا يظهر إلا في الخدمة المصابة. مثلاً قالب ثغرة مسار الملفات في Apache يطلب مساراً ملتوياً، فإذا رد الخادم بمحتوى ملف النظام فالثغرة مؤكدة. هذه النتيجة جديرة بالثقة، ولا يخدعها الإصلاح المنقول، لأنها رأت الأثر بنفسها لا الرقم.
• قالب يقارن رقم الإصدار Version: يقرأ رد الخدمة Banner ويستخرج منه رقم النسخة، ثم يقارنه بشرط مثل «أقل من 8.2.2». هذه النتيجة سريعة لكنها قد تكون إنذاراً خاطئاً، لأن الإصلاح المنقول لا يغير الرقم، فيبقى القالب يحكم «متأثر» على خدمة مصلحة.

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

اختيار نطاق الفحص Scope

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

الفحص التلقائي Automatic Scan

بدلاً من كل القوالب، يستطيع Nuclei أن يتعرف أولاً على التقنيات في كل هدف بقوالب الكشف Detection وقاعدة wappalyzer، ثم يشغل القوالب التي تحمل وسوم هذه التقنيات فقط. فإذا رأى أن الهدف Grafana لم يشغل عليه قوالب WordPress، وهذا هو الخيار -as:

docker run --rm --name sce-nu-scan --network sce-nu-lab $(cat hosts.flags) \
  -v "$PWD/nuclei-templates-10.5.1":/root/nuclei-templates:ro \
  -v "$PWD/cfg":/root/.config/nuclei \
  -v "$PWD/lab":/lab:ro -v "$PWD/out":/out \
  projectdiscovery/nuclei:v3.11.1 -duc -ni \
  -l /lab/targets.txt -as -jsonl -o /out/as.jsonl -stats -si 30

وبداية السجل تبين كيف يفكر: يكتشف التقنيات أولاً ثم يقرر كم قالباً يشغل على كل هدف:

[INF] Found 5 tags and 2 matches on detection templates on http://apache.lab [wappalyzer: 4, detection: 3]
[INF] Found 3 tags and 4 matches on detection templates on http://juice.lab:3000 [wappalyzer: 0, detection: 4]
[INF] Found 3 tags and 3 matches on detection templates on http://grafana.lab:3000 [wappalyzer: 0, detection: 4]
[INF] Executing 302 templates on http://apache.lab
[INF] Executing 2 templates on http://juice.lab:3000
[INF] Executing 2272 templates on http://grafana.lab:3000

واستغرق الفحص 15 دقيقة و14 ثانية، وأرسل 23898 طلباً، وأعطى 23 نتيجة. وهذا تحسن هائل عن أربع ساعات، لكنه ما زال طويلاً لفحص يومي، والسبب أن Grafana وحده شغل عليه 2272 قالباً، وأن الهدف غير HTTP وهو Redis أبطأ الفحص كما سنرى.

ملف KEV: الثغرات المستغلة فعلاً في أقل من دقيقة

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

docker run --rm --name sce-nu-scan --network sce-nu-lab $(cat hosts.flags) \
  -v "$PWD/nuclei-templates-10.5.1":/root/nuclei-templates:ro \
  -v "$PWD/cfg":/root/.config/nuclei \
  -v "$PWD/lab":/lab:ro -v "$PWD/out":/out \
  projectdiscovery/nuclei:v3.11.1 -duc -ni \
  -l /lab/web.txt -profile kev -jsonl -o /out/kev.jsonl -stats

[INF] Templates loaded for current scan: 549
[INF] Scan completed in 48.440465728s. 3 matches found.
{"duration":"0:00:48","errors":"125","hosts":"5","matched":"3","requests":"8873","rps":"183","templates":"549"}

فأعطى 549 قالباً في 48 ثانية الثغرات الثلاث الحقيقية نفسها التي وجدها الفحص التلقائي في ربع ساعة، ولم يعط أي نتيجة على التوأمين المصلحين. لكنه لا يرى الباسورد الافتراضي في Grafana ولا المسار /metrics المكشوف، لأنها ليست ثغرات KEV. ومن هنا يتضح الإيقاع المناسب لفريق شركة الحجوزات: ملف KEV كل أسبوع وبعد كل نشرة كبيرة، والفحص التلقائي مرة في الشهر، وكلاهما في الوقت المكتوب في ورقة النطاق. والشكل التالي يجمع هذا الإيقاع وموضع Nuclei في دورة الثغرة:

فرز النتائج: الصحيح والخاطئ والمكرر

الآن نقرأ ما وجده الفحص التلقائي، ونفرزه، لأن قائمة النتائج الخام ليست عملاً بعد. الجدول التالي يجمع النتائج التي خطورتها أعلى من مجرد معلومة:

في النتائج أعلاه لاحظ ثلاثة دروس:

• التوأم المصلح لم يظهر بأي CVE: فلا شيء على apache-fixed.lab مع أن إعداده متساهل بالقدر نفسه، ولا شيء من ثغرة القراءة على grafana-fixed.lab. وهذا ما تريده من أداة تختبر السلوك، فهي لم تحكم من اسم المنتج، بل من تصرفه، فسكتت عن المصلح.
• الباسورد الافتراضي باق بعد الترقية: قالب grafana-default-login نجح على الإصدارين، لأن ترقية الإصدار لا تغير حساب admin الذي لم يغيره أحد. وهذا تذكير بأن «حدثنا الإصدار» لا تعني «أغلقنا كل النتائج»، فالإعداد الخاطئ يبقى بعد الترقية. هذه بالضبط النتيجة التي تفوت الفاحص الذي يقرأ رقم النسخة، ويراها Nuclei لأنه جرب الدخول.
• الهدف غير HTTP أبطأ الفحص: الهدف redis.lab:6379 ظهر في السجل اثنتين وستين مرة برسالة found unresponsive، لأن قوالب HTTP كانت تحاول الاتصال به وتفشل، وهذا ما أطال الفحص التلقائي. الدرس: افصل أهداف الشبكة عن أهداف HTTP وافحصها بوسم مخصص.

وقبل أن نفرز النتائج، سؤال يواجه كل فريق صغير: بأي نتيجة نبدأ؟ خمس نتائج تبدو كثيرة حين لا يعرف أحد أيها يطفئ النار أولاً. القاعدة التي اتبعها فريق شركة الحجوزات بسيطة وتتبع منطق الخطورة مع قابلية الاستغلال: ابدأ بما هو عالي الخطورة ومؤكد السلوك ومكشوف على الإنترنت. فثغرتا Apache من هذا النوع، critical وhigh، واختبار سلوك، على خدمة يصل إليها الجميع، فهي أول ما يصلح في اليوم نفسه. ثم الباسورد الافتراضي في Grafana، فهو high وباب دخول مباشر لمن وجده. ثم المسار /metrics، وهو low لأنه تسريب معلومات لا اختراق مباشر، فيأتي بعد ذلك. أما النتائج التي خطورتها «معلومة» info فلا تصلح أصلاً، بل تقرأ لتعرف ما الذي تراه الأداة، مثل أن هذا الهدف Grafana وذاك Apache. وهذا الترتيب هو ما سيحوله DefectDojo لاحقاً إلى مهلة إصلاح SLA لكل خطورة، فتتحول القاعدة من اجتهاد إلى رقم أيام واضح.

مشكلة Redis واحدة في أحد عشر سطراً

لأن Redis ليس خدمة HTTP نفحصه بالوسم redis، وهو يجمع قوالب الشبكة وقوالب JavaScript الخاصة ب Redis، تسعة عشر قالباً في عشر ثوان، فأعطى إحدى عشرة نتيجة. وهنا يظهر درس القراءة كله في مثال واحد، والشكل التالي يفككه قبل أن نقرأ المخرج:

docker run --rm --name sce-nu-scan --network sce-nu-lab $(cat hosts.flags) \
  -v "$PWD/nuclei-templates-10.5.1":/root/nuclei-templates:ro \
  -v "$PWD/cfg":/root/.config/nuclei -v "$PWD/out":/out \
  projectdiscovery/nuclei:v3.11.1 -duc -ni \
  -u redis.lab:6379 -tags redis -jsonl -o /out/redis.jsonl

فحمل 19 قالباً وانتهى في عشر ثوان بإحدى عشرة نتيجة، وهي كما يلي بعد استخراجها من ملف JSONL:

CVE-2025-46818 high redis.lab:6379 7.4.6
redis-info info redis.lab:6379 redis_version:7.4.6
CVE-2025-46819 high redis.lab:6379 7.4.6
CVE-2025-46817 critical redis.lab:6379 7.4.6
redis-default-logins high redis.lab:6379
CVE-2025-49844 critical redis.lab:6379 7.4.6
exposed-redis high redis.lab:6379
redis-default-logins high redis.lab:6379
redis-default-logins high redis.lab:6379
redis-default-logins high redis.lab:6379
redis-default-logins high redis.lab:6379

للوهلة الأولى يبدو السيرفر في حالة سيئة جداً، فيه ثغرتان critical وثغرتان high ودخول افتراضي. لكن القراءة الصحيحة أن هنا مشكلة واحدة حقيقية، هي غياب المصادقة Authentication، تظهر في عدة أسطر، وملاحظات إصدار Redis 7.4.6 تقول صراحة إن هذا الإصدار نفسه يحتوي إصلاح الثغرات الأربع، وكذلك النشرة الأمنية للثغرة الأولى. فلماذا ظهرت إذاً؟

قالب يقارن رقم الإصدار فقط

عندما فتحنا القوالب الأربعة وجدنا أن كلاً منها يقرأ رقم الإصدار من رد Redis ثم يقارنه بشرط واحد:

grep -H "compare_versions" javascript/cves/2025/CVE-2025-468*.yaml javascript/cves/2025/CVE-2025-49844.yaml

javascript/cves/2025/CVE-2025-46817.yaml:          - compare_versions(version, ' <= 8.2.1')
javascript/cves/2025/CVE-2025-46818.yaml:          - compare_versions(version, ' < 8.2.2')
javascript/cves/2025/CVE-2025-46819.yaml:          - compare_versions(version, ' < 8.2.2')
javascript/cves/2025/CVE-2025-49844.yaml:          - compare_versions(version, ' < 8.2.2')

أي أن القالب يعرف إصلاح الفرع 8.2 فقط، ولا يعرف أن Redis أصدر الإصلاح نفسه في الفروع الأقدم المدعومة مثل 7.4.6، فكل Redis أقدم من 8.2.2 عنده متأثر. وهذه هي المشكلة نفسها التي شرحناها في إدارة الثغرات عن الإصلاحات المنقولة Backports، لكنها هنا في أداة يظن الناس أنها لا تقع فيها. وهذا بالضبط ما توقعناه في قسم القالب أعلاه: قالب يقارن الرقم فيخطئ، وقالب يختبر السلوك فيصيب. لذلك القاعدة العملية هي أن تفتح القالب قبل أن تصدق نتيجته، فإذا كانت مطابقته على رقم الإصدار فقط فتعامل معه كما تتعامل مع أي فاحص يقرأ الإصدار، وتحقق من نشرة المورد بنفسك. وإذا تأكدت أنها إنذار خاطئ فسجلها في أداة المتابعة مع السبب والرابط، ولا تقم بحذف القالب من الفحص، والسبب أنه صحيح على سيرفر 7.4.5 مثلاً.

النتيجة الصحيحة الوحيدة مكررة خمس مرات

أما القالبان exposed-redis وredis-default-logins فصحيحان، فالسيرفر يقبل الأوامر دون باسورد. لكن redis-default-logins ظهر خمس مرات، وعند قراءة الحقل meta في كل سطر تجد أن الفرق هو قيمة الباسورد التي جربها القالب من قائمته، فكل قيمة مجربة سطر مستقل:

{"Host":"redis.lab","Port":"6379","passwords":"iamadmin"}
{"Host":"redis.lab","Port":"6379","passwords":"admin"}
{"Host":"redis.lab","Port":"6379","passwords":"password"}
{"Host":"redis.lab","Port":"6379","passwords":"root"}
{"Host":"redis.lab","Port":"6379","passwords":""}

والسبب أن Redis بدون باسورد يقبل أي قيمة، فنجحت المحاولات الخمس. فإذا عددت النتائج بعدد الأسطر فسوف تجد في التقرير 11 نتيجة على Redis، والحقيقة مشكلة واحدة هي غياب المصادقة Authentication، وأربعة إنذارات خاطئة، وسطر معلومات. وهذا الفرز، تحويل أحد عشر سطراً إلى مشكلة واحدة قابلة للإصلاح، هو بالضبط العمل الذي سوف نتركه لأداة DefectDojo في المقال القادم، فهي تزيل التكرار Deduplication بين الأسطر المتشابهة وتحفظ قرار الإنذار الخاطئ.

ماذا يحدث إذا أضفنا الباسورد؟ تجربة

لنتأكد من فهمنا، أجرينا تجربة «ماذا يحدث إذا»: شغلنا Redis نفسه بباسورد عشوائي، ثم أعدنا الفحص بالوسم نفسه:

docker run -d --name sce-nu-redis-auth --network sce-nu-lab redis:7.4.6-alpine \
  redis-server --requirepass "$(openssl rand -hex 16)"

redis-detect info redis-auth.lab:6379

فاختفت كل النتائج إلا سطر الكشف. ولاحظ أن الإنذارات الخاطئة الأربعة اختفت أيضاً، ليس لأن القالب صار أذكى، وإنما لأنه لم يعد يستطيع قراءة رقم الإصدار دون باسورد. فلو كان عندك Redis 7.4.5 متأثر فعلاً وعليه باسورد فلن يقول Nuclei عنه شيئاً، وهذا حد آخر لأي فحص من الخارج، يكمله الجرد Inventory من داخل السيرفر كما في مختبر Trivy وWazuh. لا أداة تكفي وحدها.

قالب خاص Custom Template لتطبيقك

بقيت خدمة لم تعط شيئاً: تطبيق Juice Shop، فالفحص التلقائي شغل عليه قالبين فقط. والسبب أن القوالب العامة تعرف المنتجات المشهورة، أما تطبيق الشركة الخاص فلا يعرفه أحد غير فريقها. لكن الفريق يعرف أخطاء الإعداد التي تكررت عنده، مثل مجلد نسخ احتياطية Backup مكشوف بقائمة ملفات، فيكتب لها قالباً مرة واحدة ويضيفه إلى الفحص الدوري. وفي Juice Shop المسار /ftp يعرض قائمة ملفات فيها نسخ احتياطية .bak وملف كلمات مرور بامتداد .kdbx، والقالب التالي يكتشف هذا النوع من القوائم في أي تطبيق من تطبيقاتنا:

id: exposed-backup-listing

info:
  name: Directory listing that exposes backup or secret files
  author: arabroot
  severity: high
  description: |
    A web path returns a directory listing that contains backup copies (.bak, .old, .sql)
    or credential stores (.kdbx). Written for our own lab, adapt the paths to your apps.
  tags: exposure,backup,listing,internal

http:
  - method: GET
    path:
      - "{{BaseURL}}/ftp"
      - "{{BaseURL}}/backup"
      - "{{BaseURL}}/backups"

    stop-at-first-match: true
    matchers-condition: and
    matchers:
      - type: status
        status:
          - 200
      - type: word
        part: body
        words:
          - "listing directory"
          - "Index of /"
        condition: or
      - type: regex
        part: body
        regex:
          - '[\w.-]+\.(bak|old|sql|kdbx)"'

    extractors:
      - type: regex
        part: body
        group: 1
        regex:
          - 'title="([\w.-]+\.(?:bak|old|sql|kdbx))"'

في القالب أعلاه لاحظ التالي، فهو يشرح منطق المطابقات الذي يحميك من الإنذارات الخاطئة:

• الشرط matchers-condition: and يعني أن الشروط الثلاثة يجب أن تتحقق معاً: رد 200، وصفحة قائمة ملفات، وفيها اسم ملف بامتداد حساس. وبهذا لا يحكم القالب على أي صفحة 200 بأنها مشكلة، وتفاصيل أنواع الشروط في توثيق Matchers.
• ال Extractor يخرج أسماء الملفات نفسها إلى النتيجة، فيعرف من يقرأ التقرير ماذا يحذف دون أن يفتح الصفحة، وهذا يوفر وقت الفرز.
• القالب يقرأ فقط ولا يرسل أي شيء يغير حالة التطبيق، وهذا ما يجب أن تلتزم به في قوالبك على الإنتاج: قالبك جزء من فحص آمن.

ونتحقق من صحة القالب قبل استخدامه بالخيار -validate، ثم نشغله:

docker run --rm --network sce-nu-lab $(cat hosts.flags) -v "$PWD/lab":/lab:ro \
  projectdiscovery/nuclei:v3.11.1 -duc -ni -validate -t /lab/custom/exposed-backup-listing.yaml
docker run --rm --network sce-nu-lab $(cat hosts.flags) -v "$PWD/lab":/lab:ro \
  projectdiscovery/nuclei:v3.11.1 -duc -ni -t /lab/custom/exposed-backup-listing.yaml \
  -u http://juice.lab:3000 -u http://apache.lab -u http://grafana.lab:3000

[INF] All templates validated successfully
[WRN] Loading 1 unsigned templates for scan. Use with caution.
[exposed-backup-listing] [http] [high] http://juice.lab:3000/ftp ["coupons_2013.md.bak","incident-support.kdbx","package-lock.json.bak","package.json.bak"]

فوجد الملفات الأربعة على Juice Shop، ولم يعط شيئاً على Apache وGrafana. والتحذير unsigned templates طبيعي، لأن القوالب الرسمية موقعة رقمياً كما في توثيق توقيع القوالب، وقالبنا غير موقع. وهذا التحذير مفيد في الحقيقة: لا تقم بتشغيل قالب غير موقع نزلته من مكان لا تعرفه، والسبب أن القالب برنامج يرسل طلبات باسمك، وقوالب code تستطيع أن تنفذ أوامر على جهازك أنت، فمصدر القالب جزء من أمنك.

خيارات تجعل الفحص آمناً

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

كم يحتاج Nuclei من الموارد Resources؟

قسنا الفاحص بالأمر docker stats كل عشرين ثانية أثناء الفحص الكامل على جهاز فيه ثمانية معالجات:

• الذاكرة RAM: بين 590 و876 MiB، أغلبها القوالب المحملة في الذاكرة.
• المعالج CPU: حتى 3.5 معالج في بداية الفحص، ثم أقل من معالجين.
• القرص Disk: 1.3 GB لل Image و86 MB للقوالب، ولا قاعدة بيانات تحملها.
• وقت التحميل: قرابة دقيقة قبل أول طلب لتحميل أحد عشر ألف قالب من مجلد مشترك مع Windows، فإذا كنت تفحص كثيراً فضع القوالب في Volume لتسريع ذلك.

أي أن Nuclei يعمل على أي جهاز، ولا يحتاج سيرفراً مستقلاً كما يحتاج Wazuh أو OpenVAS، وهذا جزء من سبب شعبيته: تضعه في أنبوب CI/CD أو تشغله من جهازك دون بنية تحتية.

وهذه الخفة تفتح باباً عملياً لشركة الحجوزات: بدل أن يتذكر أحد تشغيل الفحص، يصبح خطوة في خط النشر. فعند كل إصدار جديد لموقع العملاء، يشغل خط CI/CD فحص KEV على بيئة الاختبار، فإذا ظهرت نتيجة عالية الخطورة توقف الإصدار قبل أن يصل للإنتاج. وهذا يحول الفحص من حدث شهري يقلق الجميع إلى حارس صامت يعمل مع كل تغيير، وهو أقرب ما يكون لروح الضابط 2-10 في ECC: لا فحص لمرة واحدة قبل التدقيق، بل تقييم دوري مستمر. والشرط الوحيد أن تثبت إصدار القوالب في الخط أيضاً، وتحدثه عمداً في خطوة منفصلة، حتى لا يفشل الإصدار يوماً بسبب قالب جديد لا بسبب كودك.

إعادة الفحص بعد الإصلاح

بعد الإصلاح نعيد الفحص بالأسماء نفسها، وفي المختبر وجهنا الأسماء apache.lab وgrafana.lab وredis.lab إلى التوائم المصلحة، فكان الفحص التلقائي على أهداف HTTP الثلاثة ثلاث دقائق بدلاً من ربع ساعة لأن Redis لم يعد في القائمة، والنتيجة كما يلي:

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

الرخصة والنسخة التجارية

الأداة والقوالب بترخيص MIT، فلا يوجد أي قيد على الاستخدام التجاري أو الداخلي. أما ProjectDiscovery فتبيع منصة سحابية اسمها Neo، وبحسب صفحة الأسعار في 25 أكتوبر 2026 فيها خطة مجانية بمقعد واحد واستخدام محدود، وخطة Pay as you go تبدأ من 200 دولار للمقعد شهرياً حتى خمسة مقاعد (أو 2100 دولار سنوياً للمقعد)، وخطة Enterprise بسعر حسب الطلب. وهذه المنصة للفرق التي تريد جدولة وتقارير مشتركة وأتمتة دون أن تبنيها بنفسها، أما فحص خدماتك بالأوامر في هذا المقال فلا يحتاجها، وشركة الحجوزات في قصتنا تكفيها الأداة المجانية مع DefectDojo للمتابعة.

مشكلات شائعة Common Problems وحلولها

• رسالة Could not read nuclei-ignore file: انسخ الملف .nuclei-ignore من مجلد القوالب إلى مجلد الإعدادات، وإلا تعمل قوالب dos وbruteforce دون أن تطلبها.
• رسالة no address found for host ثم Skipped: الهدف خرج من الفحص كله، فثبت الأسماء بالخيار --add-host أو استخدم العناوين، وابحث عن Skipped في كل سجل قبل أن تثق بنتيجة فارغة.
• رسالة access to helper file ... denied: ظهرت لنا عندما وضعنا القوالب في مسار غير /root/nuclei-templates، لأن Nuclei لا يسمح بقراءة ملفات المساعدة من خارج مجلد القوالب الافتراضي، فاربط القوالب على هذا المسار.
• الفحص يستغرق ساعات: لا تشغل كل القوالب، واستخدم -profile kev أو -as أو وسوماً محددة بحسب ما تملكه.
• هدف غير HTTP يبطئ الفحص التلقائي: افصل أهداف HTTP عن أهداف الشبكة، وافحص الأخيرة بوسوم مثل -tags redis.
• نتيجة CVE على إصدار تعرف أنه مصلح: افتح القالب، فإذا كانت المطابقة على رقم الإصدار فقط فقد تكون إنذاراً خاطئاً بسبب الإصلاح المنقول، وأكد من داخل السيرفر.

قائمة تحقق قبل كل فحص

• ورقة نطاق موقعة فيها العناوين والوقت ومن يتصل به والممنوعات.
• إصدار قوالب مثبت، وملف .nuclei-ignore في مكانه.
• أسماء الأهداف مثبتة، وخطة للبحث عن Skipped في السجل بعد الفحص.
• نطاق مناسب: KEV أسبوعياً، تلقائي شهرياً، وقالب الثغرة بعينها بعد كل نشرة كبيرة.
• حد سرعة -rl على الإنتاج، وإخطار فريق التشغيل.
• مخرج JSONL موجه إلى DefectDojo للمتابعة وإزالة التكرار.
• قوالب خاصة لأخطاء الإعداد المتكررة في تطبيقاتك، تقرأ ولا تغير.

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما ظهر في المختبر:

• Nuclei يختبر السلوك لا رقم النسخة، فرأى ثغرات Apache وGrafana المؤكدة ورأى الباسورد الافتراضي الذي يفوت الفاحص التقليدي، وسكت عن النسخ المصلحة.
• ملف KEV أعطى الثغرات الحقيقية الثلاث في 48 ثانية، وهو أنسب فحص دوري سريع لخدماتك المكشوفة.
• تشغيل كل القوالب كان سوف يرسل قرابة مليون طلب لستة أهداف، فاختر النطاق بحسب ما تملكه وما يهمك.
• القوالب التي تقارن رقم الإصدار أعطت أربعة إنذارات خاطئة على Redis مصلح، فافتح القالب قبل أن تصدق نتيجته.
• مشكلة Redis الحقيقية الواحدة ظهرت في أحد عشر سطراً، والفرز وإزالة التكرار عمل لا تقوم به الأداة، بل DefectDojo.
• الهدف الذي يخرج من الفحص بسبب خطأ اتصال لا يظهر في النتائج، فاقرأ السجل قبل أن تقول «لا توجد ثغرات».
• تطبيقك الخاص لا تعرفه القوالب العامة، فاكتب قوالب لأخطائك المتكررة وأضفها إلى الفحص.

دليلأدوات إدارة الثغرات Vulnerability Management مفتوحة المصدرأي أداة مفتوحة المصدر تجرد سيرفراتك وتطابقها مع الثغرات وتنبهك بالجديد، وماذا رأى Trivy وGrype فعلاً في ثغرات أكتوبر.دليلمختبر Lab: اكتشف السيرفرات المتأثرة بثغرة CVE جديدة وأصلحهافحصنا ثلاثة سيرفرات قديمة وسيرفراً محدثاً بأدوات Trivy وWazuh وسكربت تنبيه صغير، فظهر من يكتشف ثغرة الأسبوع ومن يفوته.دليلالفحص الشبكي للثغرات Network Scan مع OpenVASشغلنا منصة Greenbone المجتمعية وفحصنا بها سيرفر Debian، فانتظرنا أربع ساعات قبل أول فحص ووجدنا نتائج حرجة كلها إنذارات خاطئة.دليلإدارة نتائج الفحص والثغرات مع DefectDojoاستوردنا نتائج Nuclei وOpenVAS الحقيقية إلى DefectDojo، فجمع التكرار وأغلق المصلح وحده، وكاد إعداد افتراضي واحد أن يفسد كل شيء.دليلاختبار الاختراق المصرح به: المنهجية والإذن والتقريريواجه مسؤول نظم طلب المستشفى باختبار اختراق سنوي، فنرافقه وهو يفهم الإذن والنطاق وقواعد الاشتباك وبنية التقرير قبل أن يبدأ.

تدريب عملي Practice

• اكتب ورقة نطاق لخدماتك المكشوفة على الإنترنت، ثم شغل -profile kev عليها مع -rl 30 في الوقت المتفق عليه، وابحث في السجل عن Skipped قبل أن تثق بالنتيجة.
• اختر خطأ إعداد تكرر في تطبيقاتكم، مثل ملف .env مكشوف أو لوحة إدارة بلا دخول، واكتب له قالباً يقرأ فقط، وتحقق منه بالخيار -validate، ثم أضفه إلى فحصك الشهري.

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

• أكتوبر 2026: كتابة المقال وتنفيذ المختبر يوم 25 أكتوبر 2026 على Nuclei v3.11.1 مع القوالب v10.5.1 في شبكة Docker معزولة.