چند روز پیش روی یک سرور اجارهای -از یک دیتاسنتر معروف و محبوب داخلی،- نیاز فوری به کنسول داشتم. پنل KVM دیتاسنتر مثل دفعه قبل که چندماه پیش نیاز شده بود، کار نمیکرد. تا همینجا مشخص بود که مشکلات قبلی به عنوان رُخداد ثبت و پیگیری نشده. به هر حال بعد از سر و کله با پشتیبانی و عدم توفیق در حل مشکل، در نهایت گفتند: «یک IP پابلیک بده تا iLO بدیم.» مخالفت کردم (چون iLO پابلیک، از اون موردای خط قرمز هست) اما بهدلیل فوریت، پذیرفتم، با این قول که به محض اتمام کار کابل رو به صورت فیزیکی جدا میکنن.
اما اتفاقی که بعدش افتاد نگرانکنندهتر بود: دسترسی iLO به سرور یک مشتری دیگه داده شده بود! سریع با پشتیبانی تماس گرفتم، اطلاع دادم و اونها قول بررسی دادند، اما ساعتها گذشت و هنوز دسترسی پابرجا بود.
این تجربه صرفن یک خطای فردی یا «سوتی پشتیبانی» نبود. چنین رخدادی ریشه در معماری، فرآیند و فرهنگ عملیاتی در سازمانهای ما داره. سالهاست جستهوگریخته میشنویم شروع خیلی از رخنههای بزرگ داخل ایران از iLOهای پابلیک بوده؛ ترکیبی از پیکربندی غلط، پسوردهای ضعیف یا پیشفرض و آسیبپذیریهای شناختهشده. وقتی iLO روی اینترنت باز باشه، مهاجم در لایهی زیرین سیستمعامل کنترل میگیره: برق، بوت، کنسول، Virtual Media.
چرا این سناریو خطرناکه؟
- iLO روی اینترنت = مهاجم مستقیمن در Control Plane سختافزار.
- نفوذی فراتر از OS؛ حتی با Reinstall هم نفوذ باقی میمونه.
- سالهاست PoCهای متعددی برای Exploit روی iLO/iDRAC/IPMI در اینترنت وجود داره.
- بیشتر رخنههای دیتاسنتری که شنیدیم از همین مسیر شروع شدهاند: iLOهای پابلیک + پسوردهای ضعیف + Firmware قدیمی.
چی یاد بگیریم؟
- iLO باید همیشه در Mgmt VRF/VLAN داخلی باشد. هیچ استثنایی برای NAT به اینترنت وجود نداره.
- KVM Fail ≠ iLO Public. باید Runbook امن برای Break-Glass آماده و تستشده باشه.
- Process Failure > Tech Failure. وقتی Incident ثبت نشه و Controlهای ممیزی وجود نداشته باشه، دیر یا زود ضعف تبدیل به Breach میشه.
چی کار کنیم؟
برای Provider (دیتاسنتر):
- OOB Access فقط از طریق VPN + Bastion + MFA.
- Session Expiry و قطع خودکار دسترسی.
- Identity Verification قبل از هر دسترسی.
- Crash-Cart / KVM over VPN بهعنوان Failover رسمی.
- Audit & Logging اجباری برای تمام Sessionها.
برای Tenant (مشتری):
- External Scan دورهای روی IP Range.
- Credential Hygiene: بدون پیشفرض، Rotation منظم.
- Firmware Currency: هیچ iLO قدیمی نباشه.
- Runbook تستشده برای دسترسی کنسول در شرایط Fail.
- Log Forwarding از iLO به SIEM.
جمعبندی
iLO روی اینترنت یک خط قرمز است؛ نه یک راهحل موقت.
این Incident نشون داد مشکل اصلی «خرابی KVM» نبود؛ مشکل، نبود فرآیند و Runbook امن بود.
زیرساختی که Failover امن نداره، دیر یا زود به انتخابهای خطرناک مثل iLO Public کشیده میشه.