اقدامات ضروری پس از هک شدن سرور مجازی VPS

یک VPS هک‌شده را پاکسازی نکنید

اگر VPS شما هک شد، مهم‌ترین تصمیمی که باید بگیرید پیش از اجرای هر دستوری است. برای پاکسازی ماشین تلاش نکنید. آن را در پنل ارائه‌دهنده ایزوله کنید، از دیسک به عنوان مدرک snapshot بگیرید، تمام اعتبارنامه‌هایی که روی آن بوده را تغییر دهید و سپس روی یک سرور تازه، از منابعی که به آن‌ها اعتماد دارید، سیستم را بازسازی کنید.

شما نمی‌توانید ثابت کنید که یک rootkit حذف شده است، زیرا ابزارهایی که برای اثبات آن استفاده می‌کنید، همان ابزارهایی هستند که مهاجم کنترلشان می‌کند.

این تمام استدلال است. مکانیزم پشت آن به این صورت است: مهاجمی که به دسترسی root رسیده، می‌تواند ps را جایگزین کند تا یک شناسه پردازش (PID) هرگز در خروجی آن ظاهر نشود. یک خط در /etc/ld.so.preload می‌تواند کد مهاجم را در هر برنامه داینامیک‌لینک‌شده‌ای در سیستم بارگذاری کند، بنابراین ls، ss و find همگی به شکلی هماهنگ دروغ می‌گویند. یک ماژول هسته قابل بارگذاری (LKM) می‌تواند فایل‌ها را در لایه فراخوانی‌های سیستم (system call) پنهان کند، به‌طوری که حتی یک فایل باینری که به‌تازگی دانلود شده نیز دیسک را تمیز ببیند. شما ماینر را حذف می‌کنید، نمودار مصرف CPU پایین می‌آید و سرور آرام می‌شود. «آرام بودن» دقیقاً همان چیزی است که یک backdoor فعال نیز نشان می‌دهد.

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

تأیید واقعی بودن نفوذ

بسیاری از سرورهایی که گزارش هک شدن دارند، در واقع هک نشده‌اند. هزاران تلاش ناموفق برای ورود SSH در روز، بخشی از نویز پس‌زمینه اینترنت است، زیرا هر آدرس IPv4 عمومی به‌طور مداوم اسکن می‌شود. خروجی lastb که پر از تلاش‌های root و admin است، تنها به این معناست که اسکنرها پورت شما را پیدا کرده‌اند. این به معنای ورود موفقیت‌آمیز کسی نیست.

این نشانه‌ها اما معنادار هستند:

• ورود موفقی که نمی‌توانید آن را توجیه کنید، مانند Accepted password for root from 203.0.113.7.
• وجود یک کلید در authorized_keys که شما آن را اضافه نکرده‌اید.
• دریافت اخطار سوءاستفاده از سمت میزبان (host) درباره ترافیک خروجی از سرور شما.
• فرآیندی با مصرف 100 درصد CPU که نامی مشابه یک thread هسته (kernel thread) دارد. ماینرهایی که از طریق سوکت‌های Redis و Docker در دسترس نفوذ کرده‌اند، معمولاً با نام‌هایی مانند kdevtmpfsi و kinsing گزارش می‌شوند.
• اتصالات خروجی به آدرس‌هایی که هیچ‌کدام از سرویس‌های شما از آن‌ها استفاده نمی‌کنند.

برای تشخیص جعل نام thread هسته، یک تست سریع وجود دارد. threadهای واقعی هسته در داخل کروشه نمایش داده می‌شوند و هیچ فایل اجرایی پشت آن‌ها نیست، بنابراین دستور sudo ls -l /proc/<pid>/exe برای آن‌ها با خطای No such file or directory مواجه می‌شود. اگر فرآیندی که با نام [kworker/0:2] نمایش داده می‌شود، دارای یک لینک exe باشد که به فایلی در مسیر /tmp اشاره می‌کند، آن فرآیند یک برنامه کاربری معمولی است که نام هسته را جعل کرده است.

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

قطع شبکه از سمت ارائه‌دهنده، نه از داخل سرور

ایزوله‌سازی اولویت اول است، زیرا تا زمانی که شخص دیگری به shell دسترسی دارد، هر گام بعدی بیهوده است. خواندن لاگ‌ها، تغییر کلیدها و بازیابی داده‌ها در حالی که یک مهاجم فعال در حال تماشا است، هیچ فایده‌ای ندارد.

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

دو دلیل وجود دارد که این کار را از داخل سرور انجام ندهید. فایروالی که در یک هسته (kernel) آلوده پیکربندی می‌کنید، توسط همان هسته اجرا می‌شود و کاربر root می‌تواند همان‌طور که شما nftables را می‌نویسید، آن را پاک کند. همچنین، sudo ip link set enp1s0 down از طریق SSH ابتدا نشست خود شما را قطع می‌کند و باعث می‌شود از ماشینی که در حال بررسی آن بودید، بیرون بمانید.

ترافیک خروجی را نیز مانند ترافیک ورودی مسدود کنید. یک reverse shell از داخل سرور شما به سمت مهاجم تماس می‌گیرد، بنابراین مسدود کردن ترافیک ورودی به تنهایی، باعث می‌شود اتصال برقرار شده همچنان به خوبی کار کند. اگر ارائه‌دهندهٔ شما فقط قوانین ورودی ارائه می‌دهد، گزینه‌های باقی‌مانده، جدا کردن رابط شبکه یا خاموش کردن instance است.

هنوز سیستم را reboot نکنید. ابتدا بررسی کنید که آیا /var/log/journal وجود دارد یا خیر. اگر این دایرکتوری وجود نداشته باشد، journald در حال نوشتن در /run/log/journal است که در حافظه (RAM) قرار دارد؛ بنابراین reboot کردن، سوابق نفوذ را پاک می‌کند. پردازش‌های در حال اجرا نیز با reboot ناپدید می‌شوند و خط فرمان آن‌ها اغلب واضح‌ترین مدرکی است که می‌توانید به دست آورید.

پیش از هر تغییری، از دیسک Snapshot بگیرید

در این سناریو، Snapshot و Backup وظایف متفاوتی دارند. Snapshotای که اکنون تهیه می‌کنید، نسخه‌ای از دیسکِ آسیب‌دیده است: این فایل مدرک شماست و تنها راهی است که اگر به‌اشتباه فایلی را بازنویسی کردید، بتوانید به وضعیت قبل بازگردید. Backupهای قدیمی‌تر شما، مسیر بازیابی (Recovery) هستند. اگر پنل ارائه‌دهندهٔ خدمات شما از این دو واژه به‌صورت غیردقیق استفاده می‌کند، ابتدا تفاوت Snapshotهای VPS با Backupهای واقعی را مطالعه کنید، زیرا قوانین نگهداری و رفتار بازیابی آن‌ها یکسان نیست.

پیش از آنکه دوباره وارد سیستم شوید، از طریق پنل ارائه‌دهندهٔ خدمات، Snapshot بگیرید. یک Snapshot زنده (Live) از نوع Crash-consistent است: یعنی دیسک را دقیقاً در همان لحظه ثبت می‌کند، درست مانند حالتی که برق سرور را قطع کنید. این برای تهیهٔ مدرک کافی است. آن را طوری نام‌گذاری کنید که کسی به‌اشتباه آن را Restore نکند. نامی صریح مانند COMPROMISED-do-not-restore-2026-08-12 سطح مناسبی از دقت را دارد. این Snapshot را تا پایان تحقیقات و بسته شدن هرگونه تیکت سوءاستفاده (Abuse ticket) با میزبان خود، نگه دارید.

نحوه دسترسی در صورت قطع شدن SSH

دو مسیر وجود دارد که هر دو در پنل ارائه‌دهنده سرویس قرار دارند. کنسول وب (VNC یا سریال) همانند اتصال مستقیم کیبورد به دستگاه عمل می‌کند. این کنسول زمانی که sshd از کار افتاده باشد، فایروال تنظیمات اشتباهی داشته باشد یا مهاجم پورت SSH را تغییر داده باشد، کارآمد است. احراز هویت در این کنسول با رمز عبور محلی انجام می‌شود؛ بنابراین اگر سرور فقط با کلید عمومی (key-only) پیکربندی شده باشد، ممکن است پیش از استفاده از کنسول نیاز به بازنشانی رمز عبور root داشته باشید.

حالت Rescue گزینه بهتری است. این حالت یک سیستم‌عامل زنده (live) کوچک را بوت می‌کند که دیسک شما به آن متصل است اما در حال اجرا نیست؛ بنابراین دستورات شما قابل اعتماد هستند، چرا که کرنل و باینری‌های احتمالا آلوده اجرا نمی‌شوند. دیسک را در حالت فقط‌خواندنی (read-only) mount کنید.

lsblk -f
sudo mkdir -p /mnt/victim
sudo mount -o ro /dev/vda1 /mnt/victim

اگر lsblk به جای یک پارتیشن ساده، حجم‌های LVM (مدیریت حجم منطقی) را نشان می‌دهد، ابتدا آن‌ها را با sudo vgchange -ay فعال کنید و سپس دستگاهی را که در مسیر /dev/mapper/ ظاهر می‌شود، mount کنید.

هرگز برای بررسی وضعیت، با دستور chroot وارد دیسک mount شده نشوید. دستور chroot باینری‌های مهاجم را با دسترسی‌های شما اجرا می‌کند و این کار تمام دلایل بوت کردن در حالت Rescue را بی‌اثر می‌سازد.

جمع‌آوری شواهدی که هنوز قابل‌اعتماد هستند

این دستورات را در حالت rescue mode اجرا کنید، در حالی که دیسک به‌صورت read-only در مسیر /mnt/victim mount شده است. با لاگ‌های ورود به سیستم شروع کنید، زیرا زمان نفوذ را مشخص می‌کنند و با داشتن یک بازهٔ زمانی، بررسی سایر موارد آسان‌تر می‌شود.

sudo grep -aE 'Accepted (password|publickey)' /mnt/victim/var/log/auth.log
sudo last -f /mnt/victim/var/log/wtmp
sudo lastb -f /mnt/victim/var/log/btmp
sudo journalctl -D /mnt/victim/var/log/journal -u ssh --since "2026-07-01"

نبودن /var/log/auth.log به‌خودی‌خود مشکوک نیست. برخی از ایمیج‌های فعلی Ubuntu بدون rsyslog عرضه می‌شوند، بنابراین sshd لاگ‌ها را فقط به journal می‌فرستد، که همان چیزی است که خط journalctl -D می‌خواند. آنچه ارزش توجه دارد، وجود شکاف در لاگ‌هایی است که باید پیوسته باشند، یا فایل لاگی که حجم آن به صفر بایت رسیده است. پاک‌سازی لاگ‌ها رایج است و معمولاً ناشیانه انجام می‌شود.

سپس حساب‌های کاربری و کلیدها را بررسی کنید.

sudo find /mnt/victim/root /mnt/victim/home -name 'authorized_keys*' -exec ls -l {} +
sudo awk -F: '$3 == 0 {print $1}' /mnt/victim/etc/passwd
sudo lsattr /mnt/victim/root/.ssh/authorized_keys

خط awk تمام حساب‌هایی را که شناسه کاربری (UID) آن‌ها 0 است، چاپ می‌کند. هر چیزی غیر از root در خروجی، یک حساب root دوم است. الگوی find عمداً authorized_keys2 را نیز شامل می‌شود، زیرا OpenSSH به‌صورت پیش‌فرض هر دو نام فایل را می‌خواند و دومی به‌راحتی نادیده گرفته می‌شود. اگر lsattr در لیست ویژگی‌ها i را نشان دهد، فایل immutable (تغییرناپذیر) است: مهاجم این پرچم را تنظیم می‌کند تا تلاش شما برای حذف کلید آن‌ها با خطای Operation not permitted مواجه شود و مدیر سیستمِ خسته تصور کند که ویرایش با موفقیت انجام شده است.

ماندگاری (Persistence) در تعداد محدودی از مکان‌ها پنهان می‌شود، بنابراین همه آن‌ها را بررسی کنید.

sudo ls -lt /mnt/victim/etc/systemd/system
sudo ls -l /mnt/victim/etc/cron.d /mnt/victim/var/spool/cron/crontabs
sudo cat /mnt/victim/etc/ld.so.preload
sudo grep -rnE 'curl|wget|base64|/dev/tcp' /mnt/victim/etc/update-motd.d /mnt/victim/etc/rc.local /mnt/victim/root/.bashrc /mnt/victim/root/.profile

فایل /etc/ld.so.preload در یک سیستم استاندارد Ubuntu یا Debian وجود ندارد، بنابراین No such file or directory نتیجهٔ سالم است و هر محتوایی در آن نیازمند توجه شماست. یک فایل login که خروجی base64 -d را به یک shell هدایت (pipe) می‌کند نیز همین وضعیت را دارد: پیکربندی‌های قانونی نیازی به پنهان کردن متن خود ندارند.

جدول زمانی را بر اساس زمان تغییر (ctime) بسازید، نه زمان اصلاح (mtime).

sudo find /mnt/victim -xdev -newerct '2026-08-01' -type f -printf '%TF %TT %p\n' | sort

دستور touch زمان اصلاح را به هر مقداری که مهاجم بخواهد تغییر می‌دهد، بنابراین mtime به‌راحتی دروغ می‌گوید. زمان تغییر (ctime) با هر تغییری در inode به‌روز می‌شود و touch نمی‌تواند آن را به عقب برگرداند، بنابراین -newerct لیست صادقانه‌تری از آنچه اخیراً نوشته شده ارائه می‌دهد. این هنوز مدرک قطعی نیست، زیرا کاربر root می‌تواند ساعت سیستم را تغییر دهد یا مستقیماً در block device بنویسد.

یکپارچگی بسته‌ها ارزش یک دستور و یک هشدار را دارد. در یک سیستم زنده، sudo dpkg --verify برای هر فایل بسته‌بندی‌شده‌ای که checksum آن مطابقت ندارد، یک خط با 5 در ستون checksum چاپ می‌کند و sudo debsums -ac همین کار را با احتساب فایل‌های پیکربندی (هنگام نصب بسته debsums) انجام می‌دهد. نتیجه را فقط در یک جهت بخوانید. یک /usr/sbin/sshd تغییریافته، مدرک واقعی است. گزارش پاک، چیزی را ثابت نمی‌کند، زیرا همان حساب root که فایل باینری را جایگزین کرده، می‌تواند لیست‌های checksum را در /var/lib/dpkg/info/ بازنویسی کند. اسکنرهای rootkit مانند rkhunter و chkrootkit نیز از همین قاعده پیروی می‌کنند: یافتن مورد مشکوک اطلاعات ارزشمندی است، اما اجرای موفق و بدون خطا به معنای پاک بودن سیستم نیست.

پیش از انجام هرگونه اقدام مخرب، آنچه جمع‌آوری کرده‌اید را از روی ماشین کپی کنید.

sudo tar --ignore-failed-read -C /mnt/victim -czf /root/evidence-2026-08-12.tgz \
  var/log etc root/.ssh root/.bash_history home
sha256sum /root/evidence-2026-08-12.tgz

آن hash را در جایی خارج از سرور یادداشت کنید. اگر این موضوع به یک ادعای بیمه یا گزارش پلیس تبدیل شود، توانایی اثبات اینکه آرشیو از زمان جمع‌آوری تغییر نکرده است، تفاوت بین یک مدرک قانونی و مجموعه‌ای از فایل‌های بی‌ارزش است. حذف تصادفی فایل‌ها در حین بررسی امری عادی است و وجود snapshot به همراه این آرشیو، چیزی است که باعث می‌شود بتوانید از این شرایط عبور کنید. بازگرداندن یک rm اشتباه، بسیار دشوارتر از آن چیزی است که تصور می‌شود، همان‌طور که در بازیابی فایل‌های حذف‌شده با rm -rf توضیح داده شده است.

یافتن راهی که از آن نفوذ کرده‌اند

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

ورود با رمز عبور SSH. وجود یک خط Accepted password for root از آدرسی که نمی‌شناسید، به‌تنهایی پاسخ مسئله است. PasswordAuthentication را در /etc/ssh/sshd_config و در تمام فایل‌های موجود در /etc/ssh/sshd_config.d/ بررسی کنید. سرویس sshd از اولین مقداری که برای یک کلیدواژه دریافت می‌کند استفاده می‌کند و خط Include در اوبونتو در بالای فایل اصلی قرار دارد؛ بنابراین یک فایل پیکربندی که در مسیر قرار داده شده، بی‌سروصدا بر تنظیمی که شما در پایین فایل ویرایش کرده‌اید، غلبه می‌کند.

سرویسی که بدون احراز هویت منتشر شده است. Redis روی پورت 6379، Docker API روی پورت 2375، یا دیتابیسی که به جای 127.0.0.1 به 0.0.0.0 متصل شده است. Docker معمولاً غافلگیرکننده است. انتشار پورت یک کانتینر، قوانین DNAT (ترجمه آدرس شبکه مقصد) را درج می‌کند که پیش از زنجیره‌های ufw ارزیابی می‌شوند؛ بنابراین ufw status ممکن است گزارش دهد که یک پورت مسدود است، در حالی که کانتینر پشت آن به کل اینترنت پاسخ می‌دهد. پیش از بازسازی، این موضوع را درک کنید: چرا پورت‌های منتشر شده توسط Docker از ufw عبور می‌کنند که ترتیب قوانین و نحوه اصلاح آن را پوشش می‌دهد.

یک برنامه وب وصله‌نشده. لاگ دسترسی وب‌سرور را در حوالی اولین زمان مشکوک بررسی کنید تا یک درخواست POST به مسیر آپلود یا مسیر مدیریت پیدا کنید، سپس فایل‌های موجود در ریشه وب (web root) را که زمان تغییر آن‌ها با آن زمان مطابقت دارد، جستجو کنید. یک فایل PHP سرگردان در دایرکتوری uploads، نتیجه کلاسیک این نوع نفوذ است.

نشت اعتبارنامه (Credential). یک کلید که در یک مخزن (repository) کامیت شده، توکنی که در یک چت کپی شده، یا یک فایل .env که توسط یک وب‌سرور با پیکربندی نادرست به عنوان فایل استاتیک سرو شده است. اتوماسیون باعث می‌شود این کار به‌راحتی و به‌صورت تصادفی رخ دهد؛ این همان دلیلی است که برای دور نگه داشتن اسرار از عوامل هوش مصنوعی و فایل‌های پیکربندی آن‌ها مطرح می‌شود.

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

چرخش تمام اعتبارنامه‌هایی که ماشین به آن‌ها دسترسی داشته است

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

• تمام کلیدهای خصوصی SSH ذخیره‌شده روی سرور، به‌علاوه تمام حساب‌های کاربری در جاهای دیگر که به کلید عمومی متناظر اعتماد داشته‌اند.
• هر کلیدی که با استفاده از ssh -A به داخل ماشین منتقل کرده‌اید. قابلیت Agent forwarding یک سوکت در مسیر /tmp ایجاد می‌کند و کاربر root در آن ماشین می‌تواند تا زمانی که نشست شما باز است، از آن برای احراز هویت به عنوان شما در هر جای دیگری که کلیدتان پذیرفته می‌شود، استفاده کند.
• توکن‌های API موجود در فایل‌های .env، در خطوط Environment= مربوط به systemd، در پیکربندی CI و در اعتبارنامه‌های ارائه‌دهنده سرویس.
• رمزهای عبور پایگاه داده و حساب‌های کاربری برنامه‌هایی که از آن‌ها استفاده می‌کنند.
• کلیدهای خصوصی TLS (امنیت لایه انتقال) که سرور در اختیار داشته است. گواهی را مجدداً صادر کرده و گواهی قدیمی را ابطال کنید.
• رمز عبور حساب کاربری میزبانی (hosting) خود را تغییر دهید و احراز هویت دو مرحله‌ای را فعال کنید. آن پنل می‌تواند تمام سرورهای شما را بازسازی، snapshot و از طریق کنسول مدیریت کند، بنابراین آن نقطه، مرز واقعی امنیت شماست.
• هر رمز عبوری که در یک نشست shell روی آن میزبان تایپ شده است، زیرا کاربر root می‌تواند نشست ترمینال را در لحظه ثبت و ضبط کند.

اگر رمز عبوری که روی آن ماشین استفاده شده در جای دیگری نیز کاربرد دارد، آن را در آنجا نیز تغییر دهید. استفاده مجدد از رمز عبور، همان روشی است که باعث می‌شود یک VPS نفوذپذیر به یک حساب ایمیل هک‌شده تبدیل شود.

چک‌لیست بازسازی

1. یک سرور جدید از روی ایمیج توزیع سیستم‌عامل ایجاد کنید. از snapshot سرور آسیب‌دیده یا بازگردانی کامل فایل‌سیستم root استفاده نکنید.
2. بسته‌ها را از مخازن رسمی توزیع نصب کنید. هرگز فایل‌های binary را از دیسک قدیمی کپی نکنید.
3. فقط داده‌ها را از نسخه‌ پشتیبانی که تاریخ آن پیش از اولین شواهد در timeline شماست، بازیابی کنید. این شامل dumpهای دیتابیس، فایل‌های آپلود شده و وضعیت برنامه است. فایل‌های /etc، /usr و فایل‌های unit قدیمی را رها کنید.
4. رمزها و کلیدهای تغییریافته (rotated secrets) را به‌صورت دستی وارد کنید. فایل قدیمی .env را کپی نکنید.
5. محتوای وب بازیابی‌شده را بررسی کنید تا فایل‌هایی که در بازهٔ زمانی نفوذ اضافه شده‌اند شناسایی شوند؛ این کار را پیش از ارائهٔ مجدد محتوا انجام دهید.
6. پیش از اتصال به اینترنت، امنیت سرور را تأمین کنید: استفاده از SSH فقط با کلید، ایجاد یک حساب کاربری غیر-root برای فعالیت‌های روزمره، تنظیم فایروال با سیاست پیش‌فرض deny برای ترافیک ورودی، و عدم انتشار سرویس‌ها بیش از حد نیاز. مراحل ده دقیقه اول روی یک VPS جدید را دنبال کنید، سپس امن‌سازی صحیح SSH را انجام دهید و در نهایت نصب fail2ban روی Ubuntu 24.04 را برای کاهش تلاش‌های ورود غیرمجاز اضافه کنید. برای هر سرویس حساب کاربری با حداقل دسترسی در نظر بگیرید تا در صورت نفوذ بعدی، دسترسی root به خطر نیفتد.
7. سرور قدیمی را خاموش کنید و snapshot آن را تا زمان پایان تحقیقات و بسته شدن هرگونه تیکت سوءاستفاده، نگه دارید.
8. سیستم پشتیبان‌گیری را اصلاح کنید. اگر مرحله 3 بر اساس حدس و گمان بوده است، درس اصلی این است که تاریخچهٔ پشتیبان‌گیری شما برای رسیدن به پیش از زمان نفوذ کافی نبوده است. پشتیبان‌های نسخه‌بندی‌شده در خارج از سرور با دوره نگهداری طولانی، نقطه بازیابی مطمئنی برای دفعات بعد فراهم می‌کنند: پشتیبان‌گیری با restic روی VPS هر دو قابلیت را به شما می‌دهد.

اگر نمی‌توانید زمان دقیق نفوذ را تعیین کنید، نمی‌توانید پشتیبان مطمئنی انتخاب کنید. در این صورت، فقط داده‌هایی را بازیابی کنید که می‌توانید با چشم بررسی کنید: یک dump از SQL که قابل خواندن باشد، یا دایرکتوری تصاویری که می‌توانید لیست کنید. هر فایل اجرایی را مشکوک تلقی کرده و آن را مجدداً از مخازن نصب کنید.

معنای اخطاریه سوءاستفاده از سوی میزبان شما

بیشتر افراد زمانی متوجه می‌شوند که سرورشان هک (compromised) شده است که از سوی ارائه‌دهنده خدمات خود اخطاریه دریافت می‌کنند، نه از طریق مانیتورینگ شخصی. میزبان‌ها ترافیک خروجی را مشاهده می‌کنند: حملات brute force از طریق SSH به شبکه‌های دیگر، ارسال اسپم روی پورت 25، یا مشارکت در یک حمله reflection. تیکت ارسالی معمولاً شامل زمان‌بندی‌ها (timestamps)، پورت‌ها و نمونه‌ای از جریان‌های ترافیکی به همراه یک مهلت زمانی بر حسب ساعت است.

حتماً به این تیکت پاسخ دهید، حتی اگر تنها پاسخ شما این باشد که سرور ایزوله شده و در حال بازسازی است. ارائه‌دهندگان در صورت بی‌پاسخ ماندن تیکت، سرور را null-route یا معلق می‌کنند که این کار باعث تبدیل شدن حادثه امنیتی شما به یک قطعی کامل (outage) می‌شود. سپس از آن‌ها بخواهید لاگ‌های خام (raw log lines) مربوط به گزارش را در اختیار شما قرار دهند. آن زمان‌بندی‌ها خارج از ماشین شما ثبت شده‌اند، بنابراین تنها بخشی از جدول زمانی هستند که مهاجم قادر به تغییر آن‌ها نبوده است و اغلب تاریخ نفوذ را دقیق‌تر از هر فایلی روی دیسک نشان می‌دهند.

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

چه زمانی باید از یک متخصص کمک گرفت

• سرور حاوی داده‌های شخصی متعلق به افراد دیگر بوده است. طبق مقررات عمومی حفاظت از داده‌ها (GDPR)، نقض داده‌های شخصی باید بدون تأخیر غیرموجه و در صورت امکان ظرف 72 ساعت پس از آگاهی از آن، به مرجع نظارتی گزارش شود. تشخیص اینکه آیا این بازه زمانی آغاز شده است یا خیر، یک کار حقوقی است، نه وظیفه مدیر سیستم.
• داده‌های کارت پرداخت در محدوده نفوذ قرار داشته‌اند. شبکه‌های پرداخت کارت، استفاده از یک بازرس قانونی تأییدشده را الزامی می‌دانند و بررسی‌های شخصی شما می‌تواند به روند پرونده آسیب برساند.
• تقاضای اخاذی وجود دارد یا داده‌های شما رمزگذاری شده‌اند.
• ماشین می‌توانسته به ماشین‌های دیگر دسترسی داشته باشد: یک شبکه داخلی، یک هایپروایزر، یا یک CI runner که دارای اعتبارنامه‌های محیط production است. یک میزبان آلوده در یک گروه، تا زمانی که خلاف آن ثابت نشود، یک حادثه برای کل گروه محسوب می‌شود.
• شما برای ارائه به بیمه یا مراجع قانونی به شواهد نیاز دارید. در مرحله snapshot متوقف شوید، یک image کامل از دیسک بگیرید و ثبت کنید که چه کسی و در چه زمانی با آن کار کرده است.

برای یک VPS تکی که سرویس‌های شخصی شما را اجرا می‌کند و داده‌های شخص دیگری روی آن نیست، دستورالعمل بالا تمام کاری است که باید انجام دهید. در سطح ارائه‌دهنده سرویس، آن را ایزوله کنید. برای شواهد snapshot بگیرید. آنچه را که هنوز قابل اعتماد است جمع‌آوری کنید. همه چیز را تغییر دهید (Rotate) و سیستم را از نو و به‌صورت پاک بازسازی کنید.

FAQ

آیا می‌توانم به‌جای بازسازی یک VPS هک‌شده، آن را پاک‌سازی کنم؟

خیر، با اطمینان نمی‌توان این کار را انجام داد؛ زیرا در این صورت از سیستمِ آلوده می‌خواهید که وضعیت خودش را گزارش کند. یک ps جایگزین‌شده می‌تواند یک پردازش را مخفی کند، یک خط در /etc/ld.so.preload می‌تواند کد مخرب را به تمام ابزارهای داینامیک که اجرا می‌کنید تزریق کند و یک ماژول کرنل می‌تواند فایل‌ها را از دید تمام برنامه‌ها به‌طور هم‌زمان پنهان نگه دارد. شما می‌توانید شواهدی از آلودگی پیدا کنید، بنابراین نتیجه مثبت معتبر است. اما نمی‌توانید عدم وجود آلودگی را اثبات کنید، بنابراین نتیجه «پاک بودن» معتبر نیست. پاک‌سازی تنها زمانی قابل‌دفاع است که سرور حاوی هیچ دادهٔ مهمی نباشد و بپذیرید که ممکن است دوباره مورد نفوذ قرار گیرد.

آیا باید سرور آلوده را خاموش کنم یا بگذارم روشن بماند؟

ابتدا دسترسی شبکهٔ آن را از طریق پنل ارائه‌دهنده قطع کنید، سپس آن را به اندازه‌ای روشن نگه دارید که بتوانید یک snapshot بگیرید و پردازش‌های در حال اجرا را بررسی کنید. خاموش کردن سرور، لیست پردازش‌ها را از بین می‌برد و اگر /var/log/journal وجود نداشته باشد، کل لاگ‌ها را پاک می‌کند؛ زیرا در این حالت journald لاگ‌ها را در حافظه و تحت /run می‌نویسد. با این حال، اگر سرور در حال حمله به شبکه‌های دیگر است و راهی برای مسدود کردن ترافیک خروجی آن ندارید، آن را خاموش کنید. متوقف کردن آسیب، اولویت بالاتری نسبت به حفظ شواهد دارد.

چگونه بفهمم مهاجم چه زمانی وارد سیستم شده است؟

قدیمی‌ترین خط در Accepted password یا Accepted publickey را که نمی‌توانید توجیه کنید، در /var/log/auth.log یا در journal پیدا کنید. آن را با لیست تغییرات زمان، یعنی find / -xdev -newerct 'YYYY-MM-DD' -type f، تطبیق دهید؛ چرا که جعل ctime دشوارتر از mtime است. سپس هر دو را با برچسب‌های زمانی موجود در تیکت سوءاستفاده (abuse ticket) ارائه‌دهندهٔ خود مقایسه کنید؛ این زمان‌ها خارج از ماشین ثبت شده‌اند و قابل‌تغییر نیستند. نسخه‌ پشتیبانی را انتخاب کنید که قدیمی‌تر از اولین تاریخ در میان این سه مورد باشد. اگر هیچ‌کدام با هم مطابقت ندارند، فرض کنید نفوذ قدیمی‌تر از تاریخچهٔ پشتیبان‌گیری شماست و فقط داده‌هایی را بازیابی کنید که می‌توانید بازرسی کنید.

آیا نسخه‌های پشتیبان من پس از نفوذ برای بازیابی امن هستند؟

داده‌ها معمولاً با بازرسی امن هستند، اما فایل‌های سیستمی خیر. نسخه‌ پشتیبانی که پس از نفوذ گرفته شده، حاوی backdoor است؛ بنابراین بازیابی کل فایل‌سیستم root، مهاجم را نیز بازمی‌گرداند. مخزن پشتیبان را نیز بررسی کنید: اگر اعتبارنامه‌های دسترسی به آن روی سرور آلوده ذخیره شده باشد، ممکن است تاریخچه پاک یا تغییر یافته باشد؛ این همان دلیلی است که استفاده از مقصدهای پشتیبان‌گیری با قابلیت فقط-افزودنی (append-only) یا مبتنی بر pull را توجیه می‌کند. داده‌های برنامه را بازیابی کنید و سپس نرم‌افزارها را دوباره از مخازن توزیع (distribution repositories) نصب کنید.

آیا باید به کسی اطلاع دهم که VPS من مورد نفوذ قرار گرفته است؟

همیشه به تیکت سوءاستفاده (abuse notice) میزبان خود پاسخ دهید. فراتر از آن، بستگی به این دارد که داده‌های چه کسی روی ماشین بوده است. داده‌های شخصی متعلق به دیگران می‌تواند منجر به وظیفهٔ قانونی برای گزارش‌دهی شود، مانند اطلاع‌رسانی 72 ساعته به مقام نظارتی طبق GDPR. اگر اعتبارنامه‌های کاربران روی سرور ذخیره شده بود، به آن کاربران اطلاع دهید تا بتوانند رمزهای عبور خود را در جاهای دیگر تغییر دهند. اگر کلیدهای موجود در سرور، دسترسی به سیستم‌های شخص ثالث (مانند میزبان کد یا حساب ابری) را مجاز می‌کردند، به آن ارائه‌دهندگان اطلاع دهید تا بتوانند سوءاستفاده‌های احتمالی را بررسی کنند. یک سرور کاملاً شخصی که حاوی داده‌های هیچ‌کس دیگری نیست، هیچ تعهدی فراتر از پاسخ به تیکت سوءاستفاده ندارد.