‏شکار مهاجم توی Proxmox: چی رو باید لاگ کنی

نویسنده تو این پست سراغ موضوعی می‌ره که کم بهش پرداخته شده: تشخیص رفتار مهاجم توی Proxmox. با مهاجرت سازمان‌ها از VMware بعد از خرید Broadcom، Proxmox داره جای اون رو می‌گیره، ولی تیم‌های detection engineering هنوز مدل ذهنی روشنی از لاگ‌ها و نقاط کورش ندارن. بحث فقط دربارهٔ نصب Proxmox روی لینوکسه.

نکتهٔ اول اینه که Proxmox یه اپلاینس بسته نیست؛ روی یه لینوکس معمولی می‌شینه. یعنی تقریباً همهٔ playbookهای قدیمی و جاافتادهٔ حمله به لینوکس همچنان کار می‌کنن و detectionهای عمومی لینوکس هم همچنان مرتبطن. چیزی که فرق داره، لایهٔ خودِ PVEه.

برای دسترسی اولیه، احراز هویت از طریق realmها انجام می‌شه — دو تا پیش‌فرض PVE و PAM، به‌علاوهٔ LDAP. به گفتهٔ نویسنده، realmهای تنظیم‌شده رو می‌شه با یه درخواست GET بدون احراز هویت به مسیر /api2/json/access/domains/ شمرد، و realm پام حساب root خودِ هاست رو مستقیم وارد رابط گرافیکی می‌کنه. یعنی brute force حساب‌ها و کاوش API از همون اول روی میزه.

بعد از ورود، نوبت living off the landه. ابزار pvesh عملاً کلید همه‌چیزه: باهاش می‌شه منابع رو شمرد، تغییر داد و حتی یه ماشین مجازی مهمان رو با یه فراخوانی DELETE کامل پاک کرد — بدون اینکه مهاجم لازم باشه ابزاری بیاره. بدترین بخش ماجرا اینه که استفاده از pvesh اصلاً تو لاگ ممیزی pveproxy ثبت نمی‌شه و فقط از راه process execution و journald دیده می‌شه.

نویسنده پیشنهاد می‌ده استفادهٔ عادی از CLI رو مدل کنید: اینکه دستور از یه نشست SSH اومده یا از شل داخل رابط گرافیکی (که به تجربهٔ اون، ادمین‌ها بیشتر همین دومی رو ترجیح می‌دن)، تنوع ابزارهای PVE استفاده‌شده، و مسیری که دستور ازش اجرا شده. فایل‌های کانفیگ هم نقطهٔ سوءاستفاده‌ن؛ مثلاً مهاجم می‌تونه با IP set توی فایل فایروال کلاستر، کل ساب‌نت‌های ادمین رو بلاک کنه و تیم پاسخ به حادثه رو از سیستم بندازه بیرون.

برای پوشش لاگ، سه منبع لازمه: auditd برای سطح هاست، فایل access.log مربوط به pveproxy برای درخواست‌های API رابط گرافیکی (که با نوع درخواست HTTP دسته‌بندی می‌شن — مثلاً DELETE برای حذف منبع)، و journald برای تسک‌های نود و کلاستر. نویسنده تأکید می‌کنه بعضی رخدادها مثل ساخت و تغییر کاربر اصلاً تو journald نمیان و باید از منابع دیگه گرفته شن.

پیشنهادش اینه که به کانفیگ auditd آماده‌ای که استفاده می‌کنید، قواعد مخصوص PVE رو هم اضافه کنید:

## Proxmox VE
-w /etc/pve/ -p wa -k pve_config_changes
-w /usr/bin/pvesh -p x -k pve_shell_exec
-w /usr/sbin/pveum -p x -k pve_user_exec
-w /usr/share/perl5/PVE/ -p wa -k pve_core_perl_changes

پست یه بخش پایانی جنجالی هم داره: نویسنده معتقده نباید کار پژوهش تهدید و نوشتن detection رو به ابزارهای هوش مصنوعی سپرد، چون به نظرش سختیِ خودِ کار همون‌جاییه که تخصص و عمق ساخته می‌شه. لاگ‌های خام و نمونه‌های کامل برای آپلود تو SIEM هم تو پست خواهرِ این مطلب منتشر شده.

نکات کلیدی:

• Proxmox روی لینوکس معمولی می‌شینه، پس detectionهای عمومی لینوکس همچنان لازمن
• realmها با یه GET بدون احراز هویت قابل شمارش‌ان و realm پام حساب root هاست رو در معرض GUI می‌ذاره
• pvesh ابزار اصلی سوءاستفاده‌ست و توی لاگ pveproxy ثبت نمی‌شه — فقط process execution و journald
• سه منبع لاگ لازمه: auditd، access.log مربوط به pveproxy، و journald
• فایل فایروال کلاستر رو مهاجم می‌تونه برای بلاک کردن ساب‌نت ادمین‌ها دستکاری کنه