Cowrie & Grafana Honeypot باستخدام Terraform على DigitalOcean

فيديو توضيحي

جدول المحتويات

• جدول المحتويات
• نظرة عامة على النظام
• التقنيات
• هيكل دليل المشروع
• متطلبات الأجهزة
• التثبيت والإعداد
• إدارة حالة Terraform
• أنبوب CI/CD
• هندسة النظام
• الملاحظات
• الاستخدام
• توثيق المشروع
  • تصميم الهندسة والمقايضات
  • شرح تنفيذ النظام
  • المشكلات والقيود التي واجهتنا
  • التحسينات المستقبلية
• اعتبارات الأمان
• المساهمون
• الترخيص

نظرة عامة على النظام

مجموعة مصائد SSH/Telnet منشورة على droplet من DigitalOcean باستخدام Terraform. يتم التقاط الهجمات بواسطة Cowrie، وتخزينها في Loki، وتصوّرها في Grafana مع خريطة عالمية حية لأصول الهجمات.

التقنيات

• DigitalOcean
• Terraform
• Docker
• Cowrie
• Loki
• Grafana
• Promtail
• DB-IP (تحميل City Lite)

هيكل دليل المشروع

---``` honeypot/ ├── cowrie/ │ └── etc/ │ ├── cowrie.cfg # Cowrie honeypot configuration │ └── userdb.txt # Accepted and rejected fake credentials ├── geoip/ │ └── .gitkeep # Placeholder - MMDB files are gitignored ├── grafana/ │ ├── provisioning/ │ │ ├── dashboards/ │ │ │ ├── dashboards.yml # Provisioning: dashboard provider │ │ │ └── honeypot-dashboard.json # Pre-built Attack Monitor dashboard │ │ └── datasources/ │ │ └── loki.yml # Auto-provisioned Loki datasource │ └── grafana.ini # Grafana server settings ├── loki/ │ └── config.yml # Loki single-binary config and retention ├── promtail/ │ └── config.yml # Promtail scrape and GeoIP pipeline ├── scripts/ │ ├── geoip-update.sh # Download or refresh GeoIP database │ └── setup-firewall.sh # Host UFW rules for honeypot ports ├── terraform/ │ ├── templates/ │ │ ├── cloud-init.yaml.tftpl # Droplet first-boot script (Terraform-templated) │ │ └── env.tftpl # .env lines embedded via Terraform │ ├── backend.tf # Terraform backend config │ ├── main.tf # Droplet, SSH key, firewall, cloud-init │ ├── outputs.tf # IPs and helpful post-apply values │ ├── terraform.tfvars.example # Example variable values (copy to terraform.tfvars) │ ├── variables.tf # Terraform input variables │ └── versions.tf # Terraform and provider version constraints ├── .env.example # Example environment file for manual setup ├── .gitignore # Ignored paths and files ├── .gitlab-ci.yml # CI/CD pipeline: fmt, validate, Checkov ├── docker-compose.yml # Docker Compose file for the honeypot stack ├── LICENSE # GPLv2 license ├── manual-deployment.sh # Legacy VM bootstrap without Terraform └── README.md # Project documentation

## متطلبات الأجهزة

> ملاحظة: تستند هذه المتطلبات إلى خطة DigitalOcean Basic Droplet اعتبارًا من مايو 2026 وهي الحد الأدنى من المتطلبات لتشغيل المشروع.

- المزود: DigitalOcean
- الخطة: Basic Droplet - 1 Intel vCPU
- الذاكرة العشوائية: 1 جيجابايت (+2 جيجابايت مبادلة)
- التخزين: 35 جيجابايت NVMe SSD
- نظام التشغيل: Ubuntu 24.04 LTS

## التثبيت والإعداد

>ملاحظة: بعد التثبيت، يُوصى بفتح محطة طرفية جديدة والتأكد من قدرتك على SSH عبر `ADMIN_SSH_PORT` (الافتراضي: 2022) قبل إغلاق جلستك الأصلية.

### نشر Terraform (موصى به)

1. قم بإنشاء رمز API لـ DigitalOcean بأذونات قراءة/كتابة:

- سجل الدخول إلى DigitalOcean وانتقل إلى Account > API > Tokens > Generate New Token.
- قم بتسمية الرمز الخاص بك (مثل "Cowrie Honeypot") وحدد أذونات "Full Access".
- انقر على "Generate Token" وانسخ قيمة الرمز إلى مكان آمن (لن تتمكن من رؤيته مرة أخرى).

2. قم بإنشاء زوج مفاتيح SSH على جهازك المحلي وانسخ مسار المفتاح العام.

3. انتقل إلى دليل `terraform` ثم انسخ وعدّل ملف المتغيرات:

> ملاحظة: يجب تكوين `do_token` و `ssh_public_key_path` و `grafana_admin_password` كحد أدنى في `terraform.tfvars` قبل التطبيق.```bash
cd terraform
cp terraform.tfvars.example terraform.tfvars

4. قم بتطبيق التهيئة وبدء النشر:

ملاحظة: يجب تثبيت Terraform على جهازك المحلي. راجع دليل تثبيت Terraform للحصول على التعليمات.```bash terraform init # Initialize Terraform and download providers terraform apply

5. إذا كان الاختبار - إعادة النشر مع الاستبدال:```bash
terraform apply -replace="digitalocean_droplet.honeypot" 

6. التنظيف - دمّر البنية التحتية عند الانتهاء:```bash terraform destroy

### النشر اليدوي (إصدار قديم)

1. أنشئ Droplet على DigitalOcean بمتطلبات الأجهزة المذكورة أعلاه ومفتاح SSH الخاص بك.

2. اتصل عبر SSH بـ Droplet أو استخدم لوحة التحكم على الويب من DigitalOcean وقم بتشغيل الأوامر التالية:```bash
ssh root@<your-droplet-ip> # If using DigitalOcean web console, skip this command
git clone https://gitlab.com/Oseguera12/cowrie-honeypot-digitalocean.git /opt/honeypot
cd /opt/honeypot
cp .env.example .env
nano .env
bash manual-deployment.sh

إدارة حالة Terraform

ملاحظة: بشكل افتراضي، يكتب Terraform الحالة في terraform/terraform.tfstate على جهازك المحلي. يحتوي هذا الملف على قيم إخراج حساسة (عنوان IP الخاص بالدروبلت، كلمة مرور Grafana، بصمة مفتاح SSH) ويجب ألا يتم تضمينه أبدًا في الالتزامات (commits). يغطي .gitignore كلًا من *.tfstate و *.tfstate.*.

مخاطر الحالة المحلية:

• فقدانها إذا ضاع الجهاز أو حُذف الملف
• لا يمكن مشاركتها بين أعضاء الفريق
• لا يوجد قفل — يمكن لتشغيل apply متزامنين أن يفسدا الملف

لأي شيء يتجاوز المختبر الشخصي، قم بالتبديل إلى خلفية (backend) عن بُعد. يحتوي terraform/backend.tf على تكوين DigitalOcean Spaces معلق (متوافق مع S3).

لتفعيل الخلفية البعيدة:

1. قم بإنشاء حاوية (bucket) من Spaces في حساب DigitalOcean الخاص بك
2. قم بإنشاء مفتاح وصول Spaces ضمن API > Spaces Keys
3. قم بتصدير المفاتيح كمتغيرات بيئة (لا تضعها في terraform.tfvars): ```bash export AWS_ACCESS_KEY_ID= export AWS_SECRET_ACCESS_KEY=
   root@kitploit:~

4. قم بإلغاء تعليق كتلة backend "s3" في terraform/backend.tf واملأ اسم الحاوية ونقطة نهاية المنطقة.
5. قم بتشغيل terraform init -migrate-state لنقل الحالة المحلية الحالية إلى Spaces.

خط أنابيب CI/CD

يقوم ملف .gitlab-ci.yml بتشغيل ثلاث وظائف في كل دفعة في مرحلة validate واحدة:

ملاحظة: يمنع terraform:fmt و terraform:validate خط الأنابيب عند الفشل. تم ضبط checkov:scan على allow_failure: true لأن بعض النتائج هي مقايضات مقصودة. قم بكبت النتائج المقبولة المحددة باستخدام تعليقات # checkov:skip=CKXXX المضمنة بدلاً من تعطيل الوظيفة بالكامل.

المخاطر المقبولة المعروفة

يطلق CKV_DIO_4 ("تأكد من أن مدخل جدار الحماية ليس مفتوحاً على مصراعيه") مرة واحدة ضد مورد digitalocean_firewall بالكامل. يتم كبته بتعليق واحد # checkov:skip=CKV_DIO_4: داخل كتلة المورد في terraform/main.tf. يوثق الجدول أدناه سبب تعمد كل منفذ مفتوح.

بنية النظام```mermaid

flowchart TB internet((Internet))

subgraph tf["Terraform"] fw[DigitalOcean Cloud Firewall] droplet[Ubuntu 24.04 droplet] fw --> droplet end

subgraph compose["Docker Compose on droplet"] cowrie["Cowrie honeypot — SSH on port 22, Telnet on port 23"] promtail[Promtail with GeoIP labels] loki[Loki log store] grafana["Grafana — host :3000"] cowrie -->|JSON logs from ./data/cowrie-logs| promtail --> loki --> grafana end

internet -->|22/23 honeypot| fw internet -->|Admin SSH :2022| fw internet -->|Grafana :3000| fw droplet --> compose

## الملاحظات

بيانات تم جمعها على مدى 5 أيام من النشر المباشر (2026-05-05 إلى 2026-05-09):

| المقياس                | القيمة |
|------------------------|--------|
| إجمالي الاتصالات       | 41,700 |
| محاولات تسجيل الدخول   | 15,400 |
| عمليات تسجيل الدخول الناجحة | 868    |
| الأوامر المنفذة        | 836    |
| الملفات التي تم تنزيلها | 6      |
| عدد البلدان المصدرة الفريدة | 106    |

### أهم البلدان المهاجمة

| البلد             | عدد الاتصالات |
|-------------------|---------------|
| ألمانيا           | 9,768         |
| هولندا             | 9,110         |
| الولايات المتحدة  | 7,706         |
| المملكة المتحدة   | 3,858         |
| سنغافورة          | 1,770         |
| بلجيكا            | 1,422         |

### أنماط بيانات الاعتماد

اسم المستخدم الأكثر شيوعًا كان `root` بـ 3,866 محاولة، يليه `admin` (728) و`user` (494)، مما يعكس الماسحات الآلية التي تستهدف بيانات الاعتماد الافتراضية وحسابات الخدمات المعروفة. كلمة المرور الأكثر شيوعًا كانت `123456` (1,480 محاولة) تليها `123` و`12345`، وهو ما يتوافق مع أدوات القوة الغاشمة القائمة على القواميس.

### سلوك المهاجم داخل الصدفة المزيفة

نجحت 868 محاولة تسجيل دخول ضد مجموعة بيانات الاعتماد المزيفة. من تلك الجلسات، تم تنفيذ 836 أمرًا. الأمر الأكثر شيوعًا كان `uname -s -v -n -r -m` (360 عملية تنفيذ) — وهو أمر قياسي لتحديد بصمة النظام يتم تشغيله بواسطة البرامج النصية الآلية لمرحلة ما بعد الاستغلال لتحديد نظام التشغيل ومعمارية الهدف قبل نشر حمولة. تضمنت الأوامر الأخرى المرصودة `export HISTFILE=/dev/null` لتعطيل تسجيل سجل الصدفة، و`export HISTSAVE=/dev/null`، مما يشير إلى أن المهاجمين يحاولون بنشاط إخفاء آثارهم حتى داخل ما يعتقدون أنه نظام تم اختراقه.

### الخلاصة الأساسية

حجم حركة المسح الآلي — 41,700 اتصال في 5 أيام من 106 دولة — يؤكد أن أي خدمة SSH متاحة للعموم تواجه محاولات قوة غاشمة مستمرة في غضون ساعات من التعرض. النمط السلوكي المتمثل في تشغيل `uname` فورًا متبوعًا بأوامر قمع السجل يتوافق مع أطر عمل ما بعد الاستغلال الآلية التي تعمل بأقل قدر من التدخل البشري.

## الاستخدام

### استخدام لوحة Grafana

> ملاحظة: يتم تعيين بيانات اعتماد لوحة التحكم في ملف terraform.tfvars أو .env (للنشر اليدوي)

يمكن الوصول إلى لوحة التحكم على:```
http://<your-droplet-ip>:3000

تسجيل الدخول باستخدام admin / <GRAFANA_ADMIN_PASSWORD>.

بيانات اعتماد مقبولة لـ Cowrie honeypot

cowrie/etc/userdb.txt - يحتوي على بيانات الاعتماد المقبولة لـ honeypot.

• قم بتحرير هذا الملف لضبط بيانات اعتماد honeypot

• تسجيلات الدخول المقبولة تنقل المهاجم إلى shell وهمي حيث يتم تسجيل جميع الأوامر

• الإدخالات المرفوضة يتم تسجيلها كمحاولات فاشلة

توثيق المشروع

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

تصميم البنية والمقايضات

لماذا الاستضافة السحابية؟

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

لماذا DigitalOcean؟

• على الرغم من توفر مزودين آخرين مثل AWS و GCP و Azure، إلا أن DigitalOcean يوفر خيارًا أكثر تكلفة لهذا المشروع. نظرًا لأن honeypot يجب أن يظل متصلاً بالإنترنت ويرسل البيانات داخل وخارج Droplet على مدار الساعة، فإن نموذج تسعير DigitalOcean ساعد في الحفاظ على التكاليف قابلة للتنبؤ. هذا لا يأخذ في الاعتبار عروض المزودين الآخرين، مثل الاعتمادات المجانية أو الخصومات للمستخدمين الجدد أو الالتزامات طويلة الأجل.

لماذا Terraform؟

• البديل، manual-deployment.sh، مخصص للمستخدمين الذين ليس لديهم خبرة مع Terraform أو يفضلون عدم استخدامه. يتطلب هذا المسار توفير Droplet والاتصال به واستنساخ المستودع وتشغيل البرنامج النصي. يسمح Terraform بالتكرار بشكل أسرع: تعديل قاعدة التعليمات البرمجية وإعادة النشر دون تكرار كل خطوة يدوية من جهازك المحلي. كما يسهل هدم البنية التحتية والبدء من جديد. إذا نما المشروع من honeypot واحد إلى honeynet، فإن Terraform يتوسع بشكل أكثر نظافة من التوفير اليدوي أو البرنامج النصي القديم وحده.

لماذا Cowrie؟

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

لماذا Loki؟

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

لماذا Grafana؟

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

لماذا Promtail؟

• Promtail هو مرسل سجلات Loki المعروف (Grafana Alloy هو الخليفة الأحدث). Promtail خفيف على ذاكرة الوصول العشوائي ويدعم مراحل خط الأنابيب (تحليل JSON، GeoIP، التصنيفات) التي تتوافق مع هذا المشروع. البدائل مثل Fluentd أو Logstash كانت ثقيلة جدًا لـ Droplet بسعة 1 جيجابايت.

لماذا GeoIP؟

• تحتاج خرائط الهجمات إلى سياق المدينة والبلد من عناوين IP المصدر. يستخدم المشروع DB-IP City Lite عبر scripts/geoip-update.sh: لا يتطلب حسابًا أو مفتاح API، مما يحافظ على سهولة النشر لأي شخص يستنسخ المستودع. تقوم مرحلة GeoIP المضمنة في Promtail بقراءة ملف MMDB المحلي وإضافة تصنيفات للوحة Geomap في Grafana.

دليل تنفيذ النظام

نظرة عامة خطوة بخطوة لما يحدث عند إعداد honeypot باستخدام Terraform أو برنامج النشر اليدوي.

Terraform (موصى به)

على جهازك:

1. قم بتكوين terraform/terraform.tfvars: رمز API، مسار مفتاح SSH العام، كلمة مرور Grafana، عنوان URL/فرع المستودع، manage_do_firewall اختياري
2. قم بتشغيل terraform init: يقوم بتثبيت موفر DigitalOcean محليًا
3. قم بتشغيل terraform apply: يقوم Terraform ببناء خطة، ثم يقوم بإنشاء أو تحديث الموارد

في DigitalOcean:

4. يتم تحميل مفتاح SSH العام إلى حسابك
5. يتم إنشاء Droplet من متغيرات Terraform الخاصة بك:
   • الصورة (Ubuntu) والحجم والمنطقة تأتي من droplet_image و droplet_size و region إلخ.
   • يتم إرفاق مفتاح SSH من الخطوة 4
   • يتم تعيين user_data إلى cloud-init المقدم: عند التمهيد الأول، يحصل الجهاز الافتراضي على منفذ SSH الإداري، و repo_url / repo_branch من git، ونسخة مشفرة بـ base64 من .env المُنشأ (كلمة مرور Grafana و ADMIN_SSH_PORT من env.tftpl)
6. جدار الحماية السحابي (فقط عندما يكون manage_do_firewall صحيحًا):
   • يقوم Terraform بإنشاء جدار حماية DigitalOcean ويربطه مع هذا الـ Droplet
   • TCP وارد: منفذ SSH الإداري الخاص بك، 22، 23، و 3000 (راجع terraform/main.tf)
   • صادر: TCP/UDP واسع و ICMP حتى يتمكن الـ Droplet من تحديث الحزم وسحب الصور وتنزيل بيانات GeoIP

على الـ Droplet، يتم تشغيل cloud-init تلقائيًا:

7. Cloud-config: package_update / package_upgrade، ثم تثبيت الحزم المدرجة (curl، git، ufw، …). في وقت مبكر من التمهيد، يقوم write_files بإنشاء /root/honeypot.env (ملف env.tftpl المقدم من Terraform كـ base64: كلمة مرور Grafana، ADMIN_SSH_PORT، إلخ.)
8. برنامج bootstrap runcmd (الترتيب في terraform/templates/cloud-init.yaml.tftpl): تعيين iptables / ip6tables إلى الخلفيات القديمة
9. Swap: ملف 2 جيجابايت إذا كان مفقودًا (/swapfile، fstab، swappiness)

داخل Docker Compose:

18. يبدأ Loki ويجب أن يجتاز فحص الصحة (/ready على المنفذ 3100 داخل الحاوية؛ على المضيف فقط 127.0.0.1:3100)
19. ينتظر Promtail و Grafana حتى يصبح Loki سليمًا (depends_on في docker-compose.yml)، ثم يبدأان
20. يمكن لـ Cowrie البدء بشكل مستقل: ينشر المنفذين 22 و 23 للمضيف داخل الحاوية ويكتب سجلات JSON تحت data/cowrie-logs لـ Promtail

الإعداد اليدوي (قديم)

يقوم المستخدم بإنشاء الجهاز الافتراضي، ويتصل عبر SSH، ويشغل البرنامج النصي من المستودع المستنسخ.

يقوم manual-deployment.sh بما يلي:

1. تحميل والتحقق من .env
2. تحديث النظام: apt update & apt upgrade
3. تثبيت الحزم: الأدوات بالإضافة إلى ufw و iptables
4. تكوين swap: ملف 2 جيجابايت إذا كان مفقودًا
5. تثبيت Docker: المحرك + إضافة Compose، تمكين الخدمات
6. تكوين SSH: sshd على ADMIN_SSH_PORT وتعطيل ssh.socket
7. تكوين جدار الحماية: scripts/setup-firewall.sh
8. تكوين GeoIP: scripts/geoip-update.sh و cron شهري
9. بدء المكدس: docker compose pull / up -d، ثم ينتظر البرنامج النصي لفحوصات صحة Loki و Grafana ويطبع ملخصًا

المشكلات التي تمت مواجهتها

قيود الأجهزة

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

الحلول التي تم النظر فيها:

• التوسع الرأسي للحصول على المزيد من الموارد
• لوحة معلومات مخصصة بعدد أقل من اللوحات لتقليل الحمل على قاعدة البيانات
• تحديد عدد الأجهزة التي يمكنها الوصول إلى لوحة المعلومات في نفس الوقت
• تجميع السجلات في قاعدة بيانات منفصلة لتقرأ منها لوحة المعلومات لتقليل الضغط على قاعدة البيانات الرئيسية

القرار:

• التوسع إلى Droplet أكبر قليلاً مع أداء أفضل

المقايضات:

• على الرغم من زيادة التكلفة بحوالي 1-2 دولار شهريًا، إلا أن الموارد المتاحة تضاعفت. سمح الوصول إلى تخزين NVMe SSD وذاكرة وصول عشوائي أكبر مقارنة بـ Basic Droplet بلوحة معلومات أكثر استقرارًا وأداءً أفضل. تجنب ذلك قضاء الوقت في إنشاء لوحة معلومات مخصصة بعدد أقل من اللوحات وتجربة أقل استجابة.

الدروس المستفادة:

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

مشكلات انتهاء المهلة

• عند محاولة الاتصال عبر SSH بـ Droplet للوصول الإداري، كانت الاتصالات تنتهي مهلتها. بشكل منفصل، فشل docker compose up لأن المنفذ 22 كان قيد الاستخدام بالفعل ولا يمكن ربطه بواسطة Cowrie.

الحلول التي تم النظر فيها:

• كان sshd قد تم تكوينه بشكل خاطئ أو يستمع على المنفذ الخطأ
• كانت قواعد جدار الحماية تمنع منفذ SSH الإداري بعد نقله
• كانت عملية أخرى تشغل المنفذ 22 بالفعل

القرار:

• تصحيح ترتيب العمليات: يتم نقل sshd إلى ADMIN_SSH_PORT (الافتراضي 2022) وإعادة تشغيله أولاً، ثم يتم إيقاف وتعطيل ssh.socket لتحرير المنفذ 22 ليقوم Docker بربطه لـ Cowrie. يتم تطبيق قواعد UFW بعد كلتا الخطوتين للسماح بمنفذ الإدارة الجديد.

المقايضات:

• لا توجد مقايضات وظيفية. كان هذا إصلاحًا للتكوين والترتيب.

الدروس المستفادة:

• من المهم أن تكون على دراية بأي خدمات تحتاج إلى تحرير موارد محددة بترتيب معين قبل أن تبدأ. في هذه الحالة على Ubuntu 24.04، ssh.socket هو وحدة مقبس systemd تحتفظ بالمنفذ 22 للتنشيط عند الطلب عبر SSH. يجب إيقافه وتعطيله قبل أن يتمكن Docker من ربط المنفذ 22 للمضيف لـ Cowrie. إذا كان لا يزال نشطًا، يفشل docker compose up مع "address already in use".

التحسينات المستقبلية

وظيفة GeoIP

• GeoIP على مستوى المدينة تقريبي. تعتمد لوحات الخريطة على قاعدة بيانات DB-IP وقد تفوّت بعض عناوين IP أو تسميها بشكل خاطئ (الهواتف المحمولة، VPNs، بيانات قديمة). يمكن توسيع المكدس لاحقًا بقاعدة بيانات مختلفة أو خط أنابيب إثراء للحصول على ثقة أعلى في الجغرافيا.

Grafana HTTPS

• يعمل Grafana حاليًا عبر HTTP. سيكون التحسين المستقبلي هو وضعه خادم وكيل عكسي (nginx أو Caddy) مع شهادة TLS، مما سيسمح أيضًا بتقييد منفذ Grafana على localhost والوكيل عبر المنفذ 443.

وظيفة الخادم الوكيل

• لجعل honeypot يبدو أكثر شرعية، يمكن توجيهه عبر خادم في منطقة مختلفة. هذا سيجعل من الصعب على المهاجمين تحديده كـ honeypot بناءً على عنوان IP الخاص به أو موقعه الجغرافي.

الاعتبارات الأمنية

• يستخدم Grafana HTTP. المنفذ 3000 بدون TLS يعني أن بيانات الاعتماد تنتقل بنص واضح.
• يستمع Loki فقط على 127.0.0.1 (غير مكشوف)
• تم إدراج terraform.tfvars في gitignore ويجب ألا يتم الالتزام به أبدًا
• يعمل Cowrie كمستخدم غير مميز داخل حاويته
• يجب وضع Grafana خلف وكيل عكسي مع HTTPS إذا تم كشفه خارج بيئة اختبار

المساهمون

• Oseguera12

الترخيص

رخصة جنو العمومية العامة الإصدار 2.0 (GPLv2) راجع نص الترخيص الكامل في ملف LICENSE.