آنچه باید بدانید
- مصرف بالای CPU به تنهایی اثبات نفوذ نیست؛ شواهد لازم را نگه دارید.
- مهار آسیب فعال را از مسیر مدیریت مطمئن و با حفظ دسترسی بازیابی انجام دهید.
- منبع نفوذ را ببندید، اطلاعات افشاشده را تعویض و از خروجی قابل اعتماد بازیابی کنید.
نشانه را از نتیجه جدا کنید
افزایش مصرف CPU، فرآیند ناآشنا یا هشدار ایمیل خروجی نیاز به بررسی دارد، اما هیچ‌کدام به تنهایی نفوذ را ثابت نمی‌کند. پشتیبان‌گیری، اسکن امنیتی و واردسازی معتبر نیز منابع مصرف می‌کنند. زمان شروع، تغییر اخیر و قابلیت مشتری که تحت تأثیر است را ثبت کنید. این راهنمای عملی نوامبر ۲۰۲۶ از رویکرد پاسخ به رخداد NIST SP 800-61 نسخهٔ سوم استفاده می‌کند که در ۲۰۲۵ منتشر شده است؛ ادعای کشف ضعف تازه ندارد.
مسئول و محیط کار مطمئن مشخص کنید
با دستگاه پاک و پنل تأییدشدهٔ میزبان کار کنید. یک نفر تصمیم‌های فنی و در صورت امکان فردی دیگر اطلاع‌رسانی مشتری را هماهنگ کند. زمان‌ها را با منطقهٔ زمانی یکسان ثبت کنید. اگر احتمال نفوذ وجود دارد، ابزار و گزارش همان سرور را مدرک مستقل سلامت نگیرید. لاگ ارائه‌دهنده، پایش بیرونی و گزارش قبلی برنامه دید دوم می‌سازند.
آسیب فعال را مهار کنید
اگر داده در حال تخریب است یا سرور به سامانه‌های دیگر حمله می‌کند، محدودسازی آسیب اولویت دارد. کنترل شبکه در سطح میزبان ممکن است از آزمایش داخل سیستم‌عامل مشکوک مناسب‌تر باشد. دسترسی کنسول را حفظ و وابستگی‌ها را قبل از تغییر قانون شبکه شناسایی کنید. مهار می‌تواند سرویس را قطع کند؛ تصمیم را آگاهانه بگیرید و وعدهٔ رسیدگی همیشگی بدون قطعی ندهید.
پیش از حذف فایل، توقف فرآیند یا ریبوت، مشخص کنید بررسی به چه شواهدی نیاز دارد. اطلاعات موقت ممکن است از بین برود و پاک‌سازی عجولانه، مسیر ورود را پنهان کند. فرد مجاز می‌تواند اطلاعات اتصال، فرآیند و لاگ و در صورت نیاز Snapshot جمع کند. Snapshot نه تصویر کامل حافظه است و نه نسخهٔ پاک بازیابی. دسترسی به شواهد را محدود کنید؛ شاید اطلاعات مشتری یا کلید داشته باشند.
خط زمانی و دامنهٔ اثر را بسازید
- ورود مدیریتی، درخواست برنامه و انتشار کد را نزدیک اولین نشانه با هم مقایسه کنید.
- کاربران، کارهای زمان‌بندی‌شده، تعریف سرویس، اطلاعات ورود تازه و فایل غیرمنتظره را بررسی کنید.
- ببینید فرآیند آسیب‌دیده به کدام کلید API، حساب پایگاه‌داده، ایمیل و اطلاعات پشتیبان دسترسی خواندن داشته است.
- فایل را با خروجی انتشار مطمئن مقایسه کنید، نه فقط زمان تغییر. فهرست آرام فرآیندها، نبود ماندگاری نفوذ را ثابت نمی‌کند.
از منبع شناخته‌شده بازیابی کنید
برای نفوذ تأییدشده، ساخت نمونهٔ جایگزین از تصویر معتبر و خروجی برنامهٔ بررسی‌شده اغلب مرز بازیابی روشن‌تری دارد. پیش از بازگرداندن ترافیک، علت ورود را پیدا و اصلاح کنید. پشتیبان را جداگانه آزمایش کنید، دادهٔ برگشتی را بررسی و اطلاعات در معرض خطر را از دستگاه پاک به ترتیب مشخص تعویض کنید. در غیر این صورت، بازیابی شاید دسترسی مهاجم را حفظ کند.
شرط بازگشت به سرویس را تعیین کنید
کنترل دسترسی، اصلاح مسیر ورود، داده، پایش و راه بازگشت باید بررسی شوند. بعد از انتقال، درخواست بیرونی و ترافیک خروجی را زیر نظر بگیرید. ابهام باقی‌مانده را با مسئول پیگیری ثبت کنید. برای آمادگی، نگهداری لاگ امنیتی و تمرین بازیابی جداگانه را بخوانید. سرور جایگزین را با چک‌لیست امنیت VPS لینوکس بررسی کنید.
منابع و مطالعهٔ بیشتر
گزارش این مطلب بر پایهٔ منابع اصلی زیر است. توصیه‌های اجرایی، راهنمای عمومی کیاوا هستند و باید با شرایط پروژه تطبیق داده شوند.
تجربهٔ شما، ادامهٔ این مطلب.
پرسشی دارید یا این راهنما را امتحان کرده‌اید؟ تجربه‌تان را بنویسید.
این گفت‌وگو با شما شروع می‌شود.
پرسش خوب یا تجربهٔ کوتاه شما می‌تواند به خوانندهٔ بعدی کمک کند.
گفت‌وگو 0
تازه‌ترین دیدگاه‌ها