گزارش اولیه آروان از حمله به سرویس‌های رایانش ابری در دیتاسنتر آسیاتک

در روزهای پایانی سال ۹۹، زیرساخت پردازش ابری آروان در دیتاسنتر آسیاتک، بزرگ‌ترین مرکز داده کشور، به ‌مدت ۳۰ ساعت خاموش شد. این خاموشی به ‌معنای قطع دسترسی کسب‌وکارهای بسیاری به اطلاعات بود. به‌گفته‌یآروان، حملات گسترده هکری به زیرساخت پردازش ابری در مرکز داده آسیاتک باعث شد دسترسی به این دیتاسنتر برای جلوگیری از آسیب به اطلاعات مشتریان قطع شود.

با گذشت یک هفته از حمله، آروان گزارش اولیه‌ی حمله و روند بازگرداندن سرویس‌های مشتریان رایانش ابری در دیتاسنتر آسیاتک (IR-THR-AT1) را منتشر کرده است. آروان هدف حملات به زیرساخت رایانش ابری خود را تخریب و حذف اطلاعات مشتریان ذکر کرده است و همچنین یادآور شده که «این حملات در فعالیت سایر محصولات آروان شامل DNS، CDN، ویدئو پلتفرم، فضای ذخیره‌سازی ابری، همچنین رایانش ابری در سایر دیتاسنتر‌های ابر آروان اختلالی ایجاد نکرده و در حدود ۱۶ درصد از مشتریان آروان را متأثر کرده است.»

در گزارش آروان می‌خوانیم:

نشانه‌هایی از این حملات در روزهای یک‌شنبه و دوشنبه ۲۴ و ۲۵ اسفند دیده و منجر به بروز اختلالات محدودی شد؛ اما با آغاز حملات گسترده و متفاوت جدید در شامگاه سه‌شنبه و آسیب‌رسانی به دیتای مشتریان در این دیتاسنتر، مجبور به قطع تمام دسترسی‌ها، به‌منظور جلوگیری از پیشروی آسیب‌رسانی شدیم.از تمام کسب‌وکارهای آسیب‌دیده در این مشکل، عذرخواهی می‌کنیم. آگاهیم که قطعی و اختلال سرویس در پیک ترافیکی شب عید، چه پیامدهایی برای آن‌ها به همراه داشته است و عمیقا بابت این اتفاق متأسفیم.در فرایند این بحران تلاش کردیم روند بروز مشکل و فرایند حل مسئله را از راه‌های ایمیل، پیامک، سایت و بلاگ، همچنین شبکه‌های اجتماعی ابر آروان به آگاهی کاربران برسانیم.ابر آروان به ‌علت اینکه همچنان در حال کالبدشکافی (Forensics) ابعاد نفوذ است، امکان به‌اشتراک‌گذاری اطلاعات فنی نوع حمله را ندارد. گزارش فنی نوع حمله پس از پایان فرایند کالبدشکافی با جزئیات کامل منتشر خواهد شد.

بر اساس گزارش آروان، در ساعت ۱۱:۳۳ یک‌شنبه ۲۴ اسفند، یک incident روی دو سوییچ در یک VPC در دیتاسنتر IR-THR-AT1 (آسیاتک) ابر آروان مشاهده شد و برآورد اولیه تیم فنی، اشکال سخت‌افزاری بود که با بازیابی سوییچ‌ها مشکل برطرف شد.

اما در ساعت ۴ صبح دوشنبه ۲۵ اسفند، دوباره اختلال روی سوییچ‌های IR-THR-AT1 اتفاق افتاد و به ‌دلیل تکرار الگو، احتمال حمله‌ی سایبری داده شد. در نتیجه، تیم‌های ابر آروان از این زمان تا ساعت ۷ صبح روز بعد، روی موضوع کار کردند و در چند ساعت اول موفق شدند سیستم را به حالت طبیعی برگردانند.

سپس برای جلوگیری از حمله‌ی احتمالی، تغییراتی در شبکه‌ی مدیریتی دیتاسنترهای IR-THR-AT1 و IR-THR-MN1 و NL-AMS-SR1 انجام شد؛ اما کارشناسانی که به دیتاسنتر IR-THR-AT1 اعزام شده بودند به‌ دلیل خستگی، در اعمال تغییرات در شبکه‌ی این دیتاسنتر دچار اشتباه شدند و فقط بخشی از تغییرات را اعمال کردند.

آروان می‌گوید در ساعت ۵:۳۰ عصر سه‌شنبه ۲۶ اسفند، درحالی‌که تیم‌های امنیتی به هر دو دیتاسنتر برای بررسی دقیق اعزام شده بودند، به ‌شکل ناگهانی از طریق همان بخشی از شبکه‌ی مدیریتی که همچنان فعال بود، دیتاسنتر IR-THR-AT1 مورد حمله قرار می‌گیرد. این حملات در ساعت ۸ شب با حجم بسیار بالایی ادامه پیدا می‌کند و تعدادی از سرورهای ذخیره‌سازی و پردازشی با هدف حذف کامل اطلاعات مورد حمله قرار می‌گیرند. در ادامه می‌خوانیم:

با آغاز آسیب‌رسانی به دیتای مشتریان، تمام دسترسی‌ها به این دیتاسنتر قطع شد تا از توسعه‌ی آسیب‌رسانی جلوگیری شود؛ بلافاصله اینترنت و شبکه‌ی مدیریتی، هر دو به ‌شکل کامل قطع و علاوه ‌بر کارشناسان امنیتی، کارشناسان و اعضای تیم فنی به محل دیتاسنتر اعزام می‌شوند تا بدون نیاز به دسترسی از راه دور - که ریسک گسترش یا تکرار حمله را افزایش می‌داد - به بررسی موضوع بپردازند.

آروان با تحلیل اولیه برآورد کرده است که از مجموع بیش از ۹۷ درصد اطلاعات، حداقل یک نسخه از اطلاعات وجود دارد؛ اما به ‌دلیل توزیع‌شدگی سه‌ درصد اطلاعات حذف‌شده در تمام کلاستر، زیرساخت ذخیره‌سازی در خطر از دست رفتن کل اطلاعات قرار گرفت. 

در ادامه، کمیته‌ی بحرانی تشکیل شد و چهار تیم درصدد حل مشکل و اطلاع‌رسانی برآمدند:

• تیم یک: مسئول مراقبت از دیتاسنتر IR-THR-MN1 برای پیش‌گیری از اتفاق مشابه
• تیم دو: کار متمرکز روی استورج دیتاسنتر IR-THR-AT1 برای برگرداندن ۱۰۰ ترابایت اطلاعات و پایدارسازی کلاستر ذخیره‌سازی
• تیم سه: کار متمرکز روی کل زیرساخت رایانش ابری در IR-THR-AT1 تا به ‌محض رفع اشکال فضای ذخیره‌سازی، سرویس دوباره به مدار برگردد.
• تیم چهار: مسئول کالبدشکافی (Forensics) و ایمن‌سازی (Hardening)

آروان با پیش‌بینی آسیب به دیتای کاربران و زمان‌بر بودن بازگشت سرویس، از کاربران خواست برنامه Disaster Recovery خود را فعال کنند تا اگر از داده‌های خود نسخه‌ی پشتیبان تهیه کرده‌اند، با استفاده از آن در سایر دیتاسنترهای آروان یا دیگر فراهم‌کنندگان زیرساخت‌، سرویس خود را مجدد راه‌اندازی کنند.

آروان می‌گوید: «به‌رغم تأکید به «پشتیبان‌گیری اطلاعات حیاتی از سوی مشتری» در متن «شروط فنی استفاده از خدمات زیرساخت رایانش ابری آروان»، بسیاری از کاربران با آروان تماس گرفتند و اعلام کردند که نسخه‌ی پشتیبانی در دست ندارند.»

در نهایت دسترسی به اطلاعات در ساعت ۱۰:۳۰ صبح چهارشنبه، پس از حدود ۳۰ ساعت با فیکس ‌کردن و یکپارچه‌سازی داده در سطح کلاستر امکان‌پذیر شد. آروان می‌گوید این نقطه، سخت‌ترین کار تیم آغاز شد؛ چرا که آسیب و اختلال در سه ‌درصد اطلاعات می‌توانست سبب از بین رفتن کل کلاستر و بازیابی ناموفق شود. در نتیجه از این زمان، تیم بر اصلاح یکپارچگی داده متمرکز شد تا کلاستر بالا بیاید.

مشکل دوم آروان این بود که قطع ناگهانی سیستم‌عامل‌ها از استورج، به‌طور کلی سبب افزایش احتمال آسیب‌دیدگی می‌شود. این مشکلات تا ساعت ۴ صبح روز پنج‌شنبه ۲۸ اسفند حل شدند؛ کلاستر بالا آمد و کار تیم‌های دیگر هم تمام شد. سپس، به‌مرور دسترسی مشتریان به سرورهای ابری باز شد.

در اینجا مشکل دیگری پیش آمد؛ چرا که با باز شدن دسترسی به پاپ‌سایت و بررسی دقیق‌تر وضعیت ابرک‌ها، مشخص شد حذف کم‌تر از سه‌ درصد از اطلاعات کل دیتاسنتر، سبب تأثیرگذاری روی بخش گسترده‌ای از سرورهای ابری شده است. آروان می‌گوید:

میزان سکتورهای آسیب‌دیده در Block Storage متصل به ابرک، همچنین نوع فایل‌سیستم‌، سیستم‌عامل و پایگاه‌ داده‌ها سبب می‌شد که سطح آسیب‌پذیری طیف گسترده‌ای داشته باشد. در چنین موقعیتی، هر کدام از سیستم‌عامل‌ها رفتار متفاوتی دارند، از بین سیستم‌عامل‌های ویندوز و نسخ مختلف لینوکس و فایل‌سیستم‌هایشان، برخی ساده‌تر و برخی با سختی بیشتر ریکاوری می‌شوند. هم‌زمان با به‌کارگیری روش‌های بازیابی سیستم‌عامل‌ها، مقاله‌ی آموزشی آن‌ها نیز منتشر می‌شد.

آروان هنوز نمی‌تواند آمار دقیقی از سطح آسیب به ابرک‌ها اعلام کند؛ چرا که بخشی از ابرک‌ها بدون هیچ ‌اقدامی امکان استفاده داشتند، بخش دیگری با Reboot و در نهایت ترمیم boot loader به مرحله‌ی استفاده می‌رسیدند و برخی نیاز به ترمیم فایل‌سیستم یا ریکاوری‌های پیشرفته‌تر دارند.

در ادامه در مورد پاسخ‌گویی ۲۴ ساعته آروان به مشتریان می‌خوانیم: «از ظهر روز چهارشنبه، تمام خطوط تلفنی ابر آروان و تمام ظرفیت تیم پشتیبانی برای پاسخ‌گویی به مشتریان به‌ کار گرفته شده بودند. با بازگشایی دسترسی کاربران در صبح روز پنج‌شنبه، ظرفیت تیم پشتیبانی با حمایت تیم‌های فنی و تیم‌های کوچ ابری، چهار برابر شد.»

آروان می‌گوید حجم مشتریانی که تقاضای کمک داشتند به ‌حدی بالا بود که فرایند پاسخ‌گویی و حل مسئله‌ با کندی همراه شد و مشکلات پیش‌آمده در کلاستر نیز در مقاطعی، فرایند بازیابی را متوقف کرد.

آروان با تصور اینکه کلاستر ذخیره‌سازی در روز پنج‌شنبه ۲۸ اسفند پایدار شده است، محاسبه‌ی مدت‌زمان در دسترس نبودن سرویس را به نسبت هزینه‌ی ماهانه‌‌ی هر یک از مشتریان انجام داد و مبلغ آن را محاسبه و بالاتر از سقف جبران خسارت تعهدشده، به کیف پول کاربران واریز کرد. همچنین مبلغی که در روزهای قطعی از کیف پول کاربران کم شده بود، به حساب آن‌ها برگردانده شد.

علاوه‌بر این‌ها، فضای ذخیره‌سازی ابری تا پایان فروردین ۱۴۰۰ به‌ شکل رایگان در اختیار تمام مشتریان دیتاسنتر IR-THR-AT1 ابر آروان قرار گرفت تا در فرایند پشتیبان‌گیری با مشکل فضای ذخیره‌سازی مواجه نباشند.

البته ابر آروان پس از تجربه‌ی این اتفاق و عدم پشتیبان‌گیری دیتا از سوی تعداد بالایی از مشتریان، در تلاش است مجموعه اقدامات پیشگیرانه‌ای را به ‌منظور سهولت تهیه‌ی نسخه پشتیبان‌ از سوی مشتریان در آینده فراهم کند. بااین‌حال در روزهای بعد، مشخص شد که کلاستر ذخیره‌سازی با مشکلاتی همراه است؛ در نتیجه محاسبه مجدد برای برخی مشتریان، پس از حل مشکل، دوباره انجام خواهد شد.

در روز جمعه ۲۹ اسفند، حجم درخواست تعداد زیادی از کاربران برای درست کردن فایل‌سیستم یا پشتیبان‌گیری دیتا و ریکاور کردن کلاستر ذخیره‌سازی در یک فشار زمانی کوتاه صورت گرفته بود؛ آن هم درحالی‌که کلاستر هم موفق به تهیه‌ی سه نسخه از تمام داده‌ها نشده بود؛ به‌علاوه، برای ساخت ابرک‌های جدید برای انتقال اطلاعات روی آن نیاز به فضای بیشتر بود و در نتیجه باید ظرفیت کلاستری که به‌سختی آسیب‌دیده بود نیز افزایش پیدا می‌کرد. در نتیجه، ۴۰۰ ترابایت استورج به کلاستر اضافه شد.

روز دوشنبه ۲ فروردین، آروان با شکست تلاش‌های تیم‌های تخصصی مختلف، سعی کرد با Patch کردن مشکل نرم‌افزاری کلاستر و هم‌زمان افزایش منابع، مشکل را حل کند. آروان می‌نویسد:

به‌طور خلاصه می‌توان گفت مشکل اصلی کلاستر ذخیره‌سازی تأثیر تسلسل دو مشکل ReMirroring-Storm و یک Memory Leak در لایه‌‌ی نرم‌افزاری Ceph در شرایط خاص است، این مشکل هم‌افزا سبب به اغما رفتن کلاستر می‌شود. با موفقیت‌آمیز بودن این فرایند، آروان کد اصلاحی را به ‌شکل متن‌ باز منتشر خواهد کرد.

این فرایند برای ریکاوری همچنان در حال انجام است؛ به‌علاوه یک تیم در حال برنامه‌ریزی برای راه‌اندازی کلاستر جدید و انتقال دیتاهای ممکن از کلاستر آسیب‌دیده به کلاستر جدید است. آروان پیش‌بینی می‌کند این روال با توجه به حجم کار زیرساختی، تا پایان هفته‌ی اول فروردین ادامه پیدا کند.

زمانی‌که مشکل کلاستر ذخیره‌سازی حل شود، آروان به مشتریان اطلاع‌رسانی می‌کند تا اقدامات مرتبط با پشتیبان‌گیری را انجام بدهند. ابر آروان می‌گوید مجموعه اقداماتی برای پیش‌گیری از بروز حوادث این‌چنینی در دست انجام دارد که پس از حل مشکل تمام مشتریان و رسیدن به وضعیت پایدار در گزارش تکمیلی، آن‌ها را اطلاع‌رسانی می‌کند.