cyber-decoy

أداة خادوع شبكية معبأة بحاويات (honeypot) تعلن عن خدمات SSH وRDP وSMB، وتراقب كل اتصال وارد باستخدام eBPF، وتقوم بعكس الوساطة (reverse-proxy) لكل جلسة إلى حاوية خادعة معزولة.

يفصل التصميم بين مهمتين:

1. المراقبة. تُرفق مصنف TC من eBPF بواجهة الوسيط (broker) لتسجيل كل SYN وارد عبر TCP، بما في ذلك عمليات الفحص ضد المنافذ التي لا يخدمها الخداع. وهذا يمنح رؤية كاملة لنشاط الاستكشاف.
2. التفاعل. وسيط عكسي من مساحة المستخدم في الوسيط يقبل الاتصالات على المنافذ المعلنة ويفتح اتصالًا مطابقًا لحاوية الخداع لتلك الخدمة، ويقوم بتمرير البايتات في كلا الاتجاهين وتسجيل الجلسة بالكامل.

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

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

flowchart TB
    A["المهاجم / الماسح الضوئي"]

    subgraph host["مضيف الخداع"]
        direction TB

        NIC["eth0 الوسيط<br/>منشورة: 22, 3389, 445"]

        subgraph brk["حاوية الوسيط"]
            direction TB
            E["مصنف TC من eBPF<br/>يسجل كل SYN<br/>يرى عنوان IP الحقيقي للمصدر"]
            P["وسيط عكسي<br/>CONNECT إلى الخلفية"]
            L["سجلات JSON منظمة"]
        end

        subgraph dec["decoynet (شبكة داخلية، لا مسار للمضيف)"]
            direction LR
            S["ssh-decoy<br/>OpenCanary ssh<br/>المنفذ 2222"]
            D["rdp-decoy<br/>OpenCanary rdp<br/>المنفذ 3389"]
            M["smb-decoy<br/>خادم Impacket SMB<br/>المنفذ 445"]
        end
    end

    A --> NIC
    NIC --> E
    NIC --> P
    E --> L
    P --> S
    P --> D
    P --> M

أربع حاويات في المجموع:

الحاوية	الدور	الشبكة
broker	الباب الأمامي العام: مراقبة eBPF بالإضافة إلى وسيط عكسي	edge + decoynet
ssh-decoy	وحدة ssh من OpenCanary (مصافحة حقيقية، تلتقط بيانات الدخول)	decoynet فقط
rdp-decoy	وحدة rdp من OpenCanary (محاكاة NLA، تلتقط أسماء المستخدمين)	decoynet فقط
smb-decoy	Impacket SimpleSMBServer (SMB2/3 حقيقي، يلتقط المصادقة)	decoynet فقط

تعيش الخداع على شبكة Docker داخلية (decoynet) بدون مسار إلى المضيف أو العالم الخارجي. فقط الوسيط يمكنه الوصول إليها. لا شيء يفعله المهاجم داخل الخداع يمكنه الوصول إلى شبكة المضيف مباشرة.

كيف يعمل توجيه eBPF

ينشر الوسيط المنافذ 22 و3389 و445 إلى المضيف، لذلك تصل الحزم الواردة إلى eth0 الخاصة بالوسيط. ثم يحدث شيئان لكل حزمة:

• برنامج إدخال TC من eBPF (broker/bpf/decoy.bpf.c) يقوم بتحليل رؤوس Ethernet وIP وTCP، ولكل محاولة اتصال جديدة (تم تعيين SYN، ولم يتم تعيين ACK) يكتب حدث conn_event إلى مخزن مؤقت حلقي: عنوان IP ومنفذ المصدر، منفذ الوجهة، أعلام TCP، وما إذا كان المنفذ خدمة معلنة. يتم تمرير الحزمة دون تغيير (TC_ACT_OK).
• الوسيط من مساحة المستخدم يقبل الاتصال على المستمع المطابق ويقوم بما يعادل CONNECT إلى الخدمة الخلفية لتلك الخدمة، ثم يعيد توجيه البايتات في كلا الاتجاهين.

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

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

تخطيط المستودع

cyber-decoy/
├── README.md
├── docker-compose.yml         # مجموعة من 4 حاويات
├── docker-compose.override.yml # تطوير محلي على macOS: بدون صلاحيات eBPF، إعادة تعيين المنفذ 22
├── Makefile                   # مساعدات build / up / down / bpf
├── LICENSE
├── scripts/
│   └── setup.sh               # فحوصات ما قبل التشغيل للمضيف
├── broker/
│   ├── Dockerfile             # يجمّع كائن eBPF + ثنائي Go
│   ├── config.yaml            # الخدمات المعلنة (قابلة للتكوين)
│   ├── go.mod
│   ├── main.go                # نقطة الدخول
│   ├── bpf/
│   │   └── decoy.bpf.c        # مصنف TC من eBPF
│   └── internal/
│       ├── config/config.go   # محمل الإعدادات
│       ├── proxy/proxy.go     # وسيط TCP عكسي
│       └── bpf/loader.go      # تحميل + إرفاق eBPF، دفق الأحداث
└── decoys/                     # الثلاثة جميعها تشغل OpenCanary
    ├── ssh/
    │   ├── Dockerfile
    │   └── opencanary.conf     # وحدة ssh، منفذ 2222
    ├── rdp/
    │   ├── Dockerfile
    │   └── opencanary.conf     # وحدة rdp، منفذ 3389
    └── smb/
        ├── Dockerfile          # عملية Python واحدة، غير جذر
        ├── smb_decoy.py        # Impacket SimpleSMBServer + تسجيل JSON
        └── requirements.txt    # impacket (مثبت الإصدار)

المتطلبات

• مضيف Linux مع kernel 6.6 أو أحدث لمسار إرفاق eBPF من نوع TCX. على النوى الأقدم، لا يزال الوسيط يعمل؛ يتم تخطي مراقبة eBPF فقط (يسجل الوسيط تحذيرًا ويستمر).
• محرك Docker مع إضافة Compose (الإصدار v2.24+ إذا كنت تستخدم docker-compose.override.yml المرفق، والذي يعتمد على علامات !reset / !override).
• نظام ملفات BPF مركب: sudo mount -t bpf bpf /sys/fs/bpf.

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

تكتشف صورة الوسيط بنية البناء الخاصة به وتمرر الماكرو __TARGET_ARCH_* المناسب إلى clang، لذلك يتم بناؤه على كل من x86_64 و aarch64 (Apple Silicon، Graviton). لاحظ أن gcc-multilib غير مثبت عمدًا: إنها حزمة خاصة بـ x86 فقط وليس لها مرشح arm64، وإدراجها يكسر البناء على arm64 مع رمز خروج apt 100. فقط clang و libbpf-dev مطلوبان لتجميع كائن eBPF.

التطوير على macOS

يقوم Docker Desktop على macOS بتشغيل الحاويات داخل جهاز LinuxKit وليس على نواة المضيف، لذا فإن إرفاق eBPF من نوع TC/TCX لن يعمل بشكل عام هناك. هذا ليس قاتلاً: eBPF هو جهد أفضل حسب التصميم، لذا يسجل الوسيط ebpf disabled: attach failed ويعمل الوسيط العكسي وجميع الخداع الثلاثة بشكل طبيعي ويقومون بالتسجيل. يمكنك تطوير واختبار مسار الوسيط بالكامل محليًا، ثم الحصول على مراقبة eBPF حقيقية عند النشر على مضيف Linux.

يتم تحميل docker-compose.override.yml تلقائيًا ويجعل هذا الأمر ممتعًا: فهو يزيل صلاحيات eBPF (غير مفيدة في الجهاز الظاهري) ويعيد تعيين منفذ المضيف 22 إلى 2022، نظرًا لأن sshd الخاص بجهاز Mac يمتلك المنفذ 22.

docker compose up --build                    # تطوير محلي، يتم تطبيق التجاوز
docker compose -f docker-compose.yml up -d   # نشر حقيقي، يتم تجاوز التجاوز

قم بتشغيل فحص ما قبل التشغيل أولاً:

./scripts/setup.sh

بداية سريعة

# 1. بناء جميع الصور الأربع (يتم تجميع كائن eBPF داخل صورة الوسيط)
make build

# 2. تشغيل المجموعة
make up

# 3. مشاهدة ما يحدث
make logs

ثم قم باستكشافه من جهاز آخر (أو localhost لاختبار سريع):

ssh -p 22 user@DECOY_HOST          # يصل إلى خادع SSH
nc DECOY_HOST 3389                 # يصل إلى خادع RDP
nc DECOY_HOST 445                  # يصل إلى خادع SMB
nc DECOY_HOST 8080                 # غير معلن: يتم مراقبته بواسطة eBPF، لا وسيط

يقوم الوسيط بإصدار JSON لأحداث فحص eBPF والجلسات الموجهة عبر الوسيط؛ ويقوم كل خادع بإصدار أحداث JSON من OpenCanary. لمشاهدة وصول بيانات الدخول:

docker compose logs -f ssh-decoy | grep 4002

على عكس الركن المستند إلى الإعلان فقط، يكمل الآن ssh -p 22 user@DECOY_HOST تبادل مفاتيح حقيقي ويطلب كلمة مرور. يتم التقاط كل محاولة. تحقق من أن بصمة الخدمة تصمد تحت فحص الإصدار:

nmap -sV -p 22,3389,445 DECOY_HOST

الإيقاف باستخدام:

make down

التكوين

يتم تعريف الخدمات في broker/config.yaml. كل إدخال قابل للتبديل وإعادة التعيين بشكل مستقل:

services:
  - name: ssh
    enabled: true
    listen_port: 22
    backend: ssh-decoy:2222

لإضافة خدمة، أضف إدخالًا هنا، وانشر المنفذ في docker-compose.yml، وأضف حاوية خادعة. لتعطيل خدمة، قم بتعيين enabled: false (واختياريًا، قم بإزالة المنفذ المنشور).