نشانه های هک شدن سرور لینوکس و اولین اقدام ها

نشانه‌های هک شدن سرور لینوکس معمولاً این‌ها هستند: مصرف CPU بالا توسط پردازه‌ای ناشناس، ترافیک خروجی غیرعادی یا ایمیل اعتراض (Abuse) از دیتاسنتر، کاربر یا کلید SSH جدید، کرون‌جاب و سرویس ناشناخته و لاگ‌های پاک‌شده. اگر یکی از این‌ها را دیدید، سرور را ری‌استارت نکنید و چیزی پاک نکنید. ابتدا با دستورهای فقط‌خواندنی شواهد را جمع کنید، از لاگ‌ها نسخه بگیرید و بعد دسترسی شبکه سرور را محدود کنید.

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

نشانه‌های هک شدن سرور لینوکس

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

پیش از هر بررسی: این کارها را نکنید

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

راهنمای مشترک CISA درباره کشف و رفع فعالیت مخرب (AA20-245A) همین اشتباه‌ها را برمی‌شمارد: اقدام برای رفع مشکل پیش از جمع‌آوری داده، اطلاعات فرّار حافظه را از بین می‌برد و تماس با زیرساخت مهاجم ممکن است او را متوجه کند که شناسایی شده است. در این حالت مهاجم ممکن است ردپایش را پاک کند یا کار مخرب‌تری انجام دهد.

بررسی‌های فقط‌خواندنی روی سرور مشکوک

خروجی همه دستورها را روی سیستم خودتان ذخیره کنید، مثلاً با قابلیت ثبت نشست در ترمینال یا PuTTY، نه روی دیسک سرور. در نظر داشته باشید اگر مهاجم دسترسی root داشته، ممکن است دستورهایی مثل ps یا ls را هم دست‌کاری کرده باشد؛ پس خروجی تمیز به معنی سالم بودن سرور نیست.

چه کسی وارد شده و الان چه کسی متصل است؟

who
w
last -Fai | head -30
sudo lastb -Fai | head -30          # failed logins (util-linux; see note for Debian 13)
sudo journalctl -u ssh --since "7 days ago" | grep -E "Accepted|Failed"    # RHEL family: -u sshd

در خروجی journalctl به خطوط Accepted نگاه کنید: از چه IPی، با چه کاربری، در چه ساعتی و با password یا publickey. ورود موفق با password در حالی که فکر می‌کنید ورود با رمز بسته است، خودش یک یافته مهم است. در Debian 13 دستورهای last و lastb از بسته util-linux حذف شده‌اند؛ آنجا last از بسته wtmpdb می‌آید و برای ورودهای ناموفق lslogins --failed را به کار ببرید.

پردازه‌ها و فایل‌های اجرایی پاک‌شده

ps auxww --sort=-%cpu | head -20
ps auxwwf
sudo ls -l /proc/*/exe 2>/dev/null | grep deleted
ps -o pid,user,lstart,cmd -p PID
sudo ls -l /proc/PID/exe /proc/PID/cwd
sudo cat /proc/PID/cmdline | tr '\0' ' '

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

اتصالات شبکه

sudo ss -tunap
sudo ss -tlnp
sudo ss -Htnp state established

دنبال اتصال‌های خروجی به IPهای ناشناس و پورت‌های غیرمعمول و پورت‌هایی باشید که روی آن‌ها گوش داده می‌شود اما خودتان باز نکرده‌اید. ستون آخر نام و PID پردازه را نشان می‌دهد تا بتوانید آن را با فهرست پردازه‌ها تطبیق دهید. IP مقصد را یادداشت کنید و آن را باز یا پینگ نکنید.

راه‌های ماندگاری: کرون، سرویس، کاربر و کلید

for u in $(cut -d: -f1 /etc/passwd); do sudo crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
sudo ls -la /etc/cron.d /etc/cron.daily /etc/cron.hourly
sudo ls -laR /var/spool/cron
systemctl list-timers --all
systemctl list-unit-files --type=service --state=enabled
ls -lt /etc/systemd/system | head -20
awk -F: '$3 == 0 {print $1}' /etc/passwd
sudo find / -xdev -name authorized_keys -exec ls -l {} \; -exec cat {} \; 2>/dev/null
cat /etc/ld.so.preload 2>/dev/null

مهاجم معمولاً راهی می‌سازد که پس از ری‌استارت یا حذف بدافزار دوباره برگردد. همه کرون‌جاب‌ها و تایمرها را با آنچه خودتان ساخته‌اید مقایسه کنید. فایل‌های unit تازه در ‎/etc/systemd/system، کاربری غیر از root با UID صفر و هر کلید SSH در authorized_keys که صاحبش را نمی‌شناسید، یافته‌های جدی هستند. فایل ‎/etc/ld.so.preload روی بیشتر سرورها وجود ندارد و اگر وجود دارد، محتوایش باید بررسی شود. در این مرحله هم چیزی را حذف نکنید.

فایل‌های تازه تغییرکرده و بسته‌های دست‌کاری‌شده

sudo find /etc /usr/bin /usr/sbin /usr/lib/systemd -xdev -type f -mtime -7 -ls 2>/dev/null
sudo find /tmp /var/tmp /dev/shm -type f -ls
sudo find /var/www -type f -name "*.php" -mtime -7 -ls

# Debian / Ubuntu (package: debsums)
sudo debsums -s
# RHEL / Rocky Linux / AlmaLinux: files whose digest differs from the package
sudo rpm -Va | grep -E "^..5"

زمان تغییر فایل را می‌توان جعل کرد، پس خروجی find راهنماست، نه مدرک قطعی. debsums و rpm -Va فایل‌های نصب‌شده را با اطلاعات پایگاه داده بسته‌ها مقایسه می‌کنند. در خروجی rpm حرف 5 در ستون سوم یعنی محتوای فایل تغییر کرده است و تغییر فایل‌های تنظیمات (با علامت c) معمولاً طبیعی است. مستندات debsums صریحاً می‌گوید این ابزار برای امنیت کاربرد محدودی دارد، چون مهاجمی که root دارد می‌تواند همان پایگاه داده را هم تغییر دهد. نصب debsums روی سرور مشکوک هم خودش دیسک را تغییر می‌دهد؛ اگر نصب نیست، این بررسی را به مرحله تحلیل روی نسخه دیسک موکول کنید.

حفظ شواهد: از لاگ‌ها و دیسک نسخه بگیرید

1. یک یادداشت زمانی شروع کنید: چه زمانی مشکوک شدید، چه دیدید و چه دستوری در چه ساعتی اجرا کردید. منطقه زمانی سرور را با timedatectl هم ثبت کنید.
2. اگر سرور مجازی است، پیش از هر تغییر از پنل دیتاسنتر یا هایپروایزر Snapshot بگیرید. در بعضی هایپروایزرها امکان ذخیره حافظه ماشین همراه Snapshot هم وجود دارد.
3. از لاگ‌ها نسخه بگیرید، هش آن را ثبت کنید و فایل را به سیستمی خارج از سرور منتقل کنید.
4. لاگ وب‌سرور، برنامه و دیتابیس را هم اگر در مسیری غیر از ‎/var/log هستند، به همین روش جمع کنید.

sudo tar czf /var/tmp/logs-$(hostname)-$(date +%F).tar.gz /var/log
sudo chown deploy /var/tmp/logs-*.tar.gz
sha256sum /var/tmp/logs-*.tar.gz

# On your own computer
scp deploy@SERVER_IP:/var/tmp/logs-*.tar.gz .
sha256sum logs-*.tar.gz

ژورنال systemd در ‎/var/log/journal است و همراه این آرشیو کپی می‌شود. نسخه اصلی را دست‌نخورده نگه دارید و تحلیل را روی کپی انجام دهید. اگر حادثه پیامد حقوقی، قراردادی یا بیمه‌ای دارد، پیش از هر اقدام دیگر با متخصص جرم شناسی دیجیتال و تحلیل حملات سایبری هماهنگ کنید تا شواهد به شکل قابل استناد جمع شوند.

ایزوله کردن سرور بدون پاک کردن شواهد

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

• اگر پنل دیتاسنتر فایروال شبکه یا Security Group دارد، همه ترافیک ورودی و خروجی را ببندید و فقط SSH از IP مدیریتی خودتان را باز بگذارید. این روش به فایروال داخل سرور که مهاجم ممکن است آن را تغییر دهد وابسته نیست.
• اگر فایروال شبکه در دسترس نیست، روی خود سرور همین محدودیت را اعمال کنید و بدانید مهاجم دارای root می‌تواند آن را برگرداند.
• اگر دیتاسنتر ایمیل Abuse فرستاده، پاسخ دهید که موضوع را بررسی و سرور را ایزوله کرده‌اید.

# Only if no provider-level firewall exists. Replace ADMIN_IP first, or you will lock yourself out.
sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow from ADMIN_IP to any port 22 proto tcp
sudo ufw enable

پاک‌سازی یا نصب مجدد؟

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

• همه رمزها و کلیدهایی که روی سرور بوده‌اند عوض شوند: کلیدهای SSH، رمز دیتابیس، توکن‌های API و رمز پنل‌ها. ساخت کلید تازه در آموزش SSH Key آمده است.
• راه نفوذ بسته شود: افزونه آسیب‌پذیر به‌روز یا حذف شود، ورود با رمز SSH بسته شود یا نرم‌افزار قدیمی وصله شود.
• دسترسی‌ها بازبینی شود و هر کاربر فقط حداقل دسترسی لازم را داشته باشد؛ مدیریت دسترسی در لینوکس را ببینید.
• بکاپ خارج از سرور و غیرقابل پاک شدن از سرور اصلی راه‌اندازی شود؛ بکاپ گیری سرور و بازیابی بحران جزئیات را پوشش می‌دهد.
• تا چند هفته ورودهای SSH، کرون‌جاب‌ها و ترافیک خروجی را با دقت بیشتری زیر نظر بگیرید.

سوالات متداول

آیا rkhunter یا ClamAV می‌تواند هک شدن را تأیید یا رد کند؟

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

بازگرداندن بکاپ دیروز کافی است؟

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

سرور را خاموش کنم یا روشن بگذارم؟

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

اگر سرور از دسترس خارج شده و نمی‌دانم علتش هک است یا خرابی چه کنم؟

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