نشانه‌های هک شدن سرور لینوکس و اقدامات فوری پس از نفوذ

چرا سرورها هک می‌شوند؟

بیشتر نفوذها کار هکرهای حرفه‌ای که شما را هدف گرفته‌اند نیست؛ ربات‌های خودکار کل اینترنت را اسکن می‌کنند و دنبال درهای باز می‌گردند. سه علت رایج‌تر از بقیه است: رمز عبور ضعیف برای SSH، نرم‌افزار به‌روزنشده (مثلاً یک افزونهٔ قدیمی وردپرس یا پنل مدیریتی آسیب‌پذیر) و سرویس‌هایی که بدون رمز روی اینترنت باز مانده‌اند، مثل Redis یا دیتابیس.

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

نشانه‌های رایج نفوذ

هیچ‌کدام از نشانه‌های زیر به‌تنهایی اثبات هک نیست، اما ترکیب چند مورد را جدی بگیرید:

• مصرف CPU همیشه بالا بدون این‌که بازدید سایت زیاد شده باشد؛ به‌خصوص پروسه‌ای با نام عجیب یا نامی شبیه پروسه‌های سیستمی مثل kworker اما زیر کاربر غیر root.
• افزایش ناگهانی ترافیک خروجی؛ سرور آلوده ممکن است به‌طور مداوم داده بفرستد یا در حمله شرکت کند.
• کاربران یا کلیدهای SSH ناشناس در /etc/passwd یا فایل authorized_keys.
• کرون‌جاب‌های عجیب که اسکریپتی را از اینترنت دانلود و اجرا می‌کنند.
• فایل‌های اجرایی تازه در مسیرهایی مثل /tmp، /var/tmp یا /dev/shm.
• ایمیل یا اخطار از ارائه‌دهنده دربارهٔ اسکن، اسپم یا حملهٔ خروجی از آی‌پی شما.
• تغییر فایل‌های سایت: صفحات اسپم، تغییر مسیر کاربران به سایت‌های دیگر یا فایل‌های PHP ناشناس در پوشهٔ آپلود.

بررسی سریع با دستورهای لینوکس

اگر شک دارید، این بررسی‌ها را به ترتیب انجام دهید. توجه کنید که روی سرور کاملاً آلوده، ابزارهای سیستم هم ممکن است دستکاری شده باشند؛ پس نتیجهٔ «تمیز» صددرصد قابل اتکا نیست.

۱. پروسه‌ها و مصرف منابع

top -o %CPU
ps auxf --sort=-%cpu | head -20
ls -l /proc/*/exe 2>/dev/null | grep deleted

خط آخر پروسه‌هایی را نشان می‌دهد که فایل اجرایی‌شان پس از اجرا پاک شده است؛ ترفندی رایج برای پنهان‌کاری بدافزارها.

۲. اتصال‌های شبکه

ss -tunap
ss -tnp state established

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

۳. کاربران، کلیدها و ورودها

awk -F: '$3==0 {print $1}' /etc/passwd
cat /root/.ssh/authorized_keys
last -a | head -20
lastb | head -20
grep "Accepted" /var/log/auth.log | tail -20

دستور اول کاربرانی را نشان می‌دهد که شناسهٔ صفر (همان دسترسی root) دارند؛ در حالت عادی فقط باید root نمایش داده شود. دستور grep "Accepted" ورودهای موفق را با آی‌پی مبدأ نشان می‌دهد؛ اگر آی‌پی ناآشنایی می‌بینید، زنگ خطر است.

۴. کرون‌جاب‌ها و سرویس‌ها

crontab -l; ls -la /etc/cron.* /var/spool/cron/crontabs 2>/dev/null
systemctl list-units --type=service --state=running
ls -lat /etc/systemd/system | head

دنبال خطوطی مثل curl ... | sh یا wget ... -O- | bash باشید. سرویس‌های systemd تازه با نام‌های بی‌معنا هم مشکوک‌اند. برای آشنایی با ساختار سالم کرون و سرویس‌ها، راهنمای کرون‌جاب را ببینید.

$ awk -F: '$3==0 {print $1}' /etc/passwdroot$ grep Accepted /var/log/auth.log | tail -3... sshd[...]: Accepted publickey for root from 203.0.113.10 ...$ ls -l /proc/*/exe 2>/dev/null | grep deleted$ crontab -lno crontab for root$ 

اگر نفوذ تأیید شد: اقدامات فوری

مهم‌ترین اصل: سروری که هک شده را دیگر قابل اعتماد ندانید. مهاجم ممکن است در جاهایی درِ پشتی گذاشته باشد که پیدا کردنشان بسیار سخت است. ترتیب پیشنهادی:

1. محدود کردن دسترسی: با فایروال فقط آی‌پی خودتان را برای SSH مجاز کنید و ترافیک خروجی غیرضروری را ببندید. اگر سرور در حال حمله به دیگران است، آن را خاموش کنید.
2. گرفتن نسخهٔ پشتیبان از داده‌ها: فقط داده‌ها (دیتابیس، فایل‌های آپلودی، تنظیمات مهم) را به جای دیگری منتقل کنید؛ نه فایل‌های اجرایی و اسکریپت‌ها. ابزار rsync در این مرحله کاربردی است: آموزش بکاپ با rsync.
3. عوض کردن همهٔ رمزها و کلیدها: رمز root، رمز دیتابیس، کلیدهای API ذخیره‌شده روی سرور، رمز پنل‌ها و کلیدهای SSH. فرض کنید هر رازی که روی سرور بوده لو رفته است.
4. نصب مجدد سیستم‌عامل: سرور تازه بسازید یا سیستم‌عامل را از نو نصب کنید؛ سپس برنامه‌ها را از منبع رسمی نصب و داده‌ها را پس از بررسی برگردانید.
5. پیدا کردن علت ورود: اگر علت را پیدا نکنید، سرور جدید هم به همان روش هک می‌شود. لاگ‌های ذخیره‌شده، نسخهٔ افزونه‌ها و سرویس‌های باز را بررسی کنید.

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

جلوگیری از نفوذ دوباره

پس از بازسازی، این موارد را پیش از هر کار دیگری انجام دهید:

• ورود SSH را فقط با کلید ممکن کنید و ورود با رمز را ببندید. آموزش آن در کلید SSH و تغییر پورت آمده است.
• Fail2ban را برای مسدود کردن خودکار تلاش‌های ناموفق نصب کنید.
• فایروال را طوری تنظیم کنید که فقط پورت‌های لازم باز باشند؛ راهنمای UFW را ببینید.
• سرویس‌هایی مثل Redis، MySQL و پنل‌های مدیریتی را فقط روی 127.0.0.1 یا شبکهٔ خصوصی گوش بدهید.
• به‌روزرسانی‌های امنیتی خودکار را فعال کنید و افزونه‌ها و پنل‌ها را به‌روز نگه دارید.
• نسخهٔ پشتیبان منظم و خارج از سرور داشته باشید.

فهرست کامل‌تر را در چک‌لیست امنیت سرور جدید پیدا می‌کنید.

پایش مداوم برای تشخیص زودهنگام

هرچه نفوذ زودتر کشف شود، خسارت کمتری دارد. چند ابزار ساده کمک می‌کنند:

• هشدار مصرف منابع: ابزارهای مانیتورینگ مثل Uptime Kuma یا Netdata را طوری تنظیم کنید که هنگام مصرف غیرعادی خبر دهند.
• بررسی دوره‌ای ورودها: یک کرون‌جاب ساده می‌تواند ورودهای موفق روز گذشته را برایتان ایمیل کند.
• بررسی یکپارچگی فایل‌ها: ابزارهایی مثل AIDE تغییرات فایل‌های سیستمی را ثبت می‌کنند.
• اسکنر بدافزار: ابزارهایی مثل rkhunter و ClamAV برخی بدافزارهای شناخته‌شده را پیدا می‌کنند، هرچند جایگزین اقدامات پیشگیرانه نیستند.

چه چیزهایی را پس از بازسازی بازبینی کنیم؟

پس از راه‌اندازی سرور جدید، چند روز اول را با دقت بیشتری پایش کنید. نمودار مصرف CPU و ترافیک را روزانه ببینید و با الگوی عادی مقایسه کنید. اگر داده‌ها را از نسخهٔ پشتیبان برگردانده‌اید، فایل‌های آپلودی سایت را بررسی کنید که فایل اجرایی یا اسکریپت PHP ناشناسی همراهشان برنگشته باشد؛ مهاجمان معمولاً درِ پشتی را در پوشهٔ آپلود پنهان می‌کنند.

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

در نهایت، یک سند کوتاه از اتفاقی که افتاد بنویسید: چه زمانی کشف شد، راه ورود چه بود و چه اقدامی انجام شد. این سند در حادثهٔ بعدی، زمان واکنش را بسیار کوتاه‌تر می‌کند.

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