چک‌لیست ماهانه‌ی سلامت سرور لینوکس: ۲۰ موردی که باید بررسی شود (همراه با دستورات)

بیشتر قطعی‌های سرور ناگهانی نیستند؛ فقط کسی نشانه‌هایشان را ندیده است. دیسکی که هر ماه ۵٪ پرتر می‌شود، گواهی SSL که دو هفته دیگر منقضی می‌شود، سرویسی که هفته‌هاست در حالت failed است و بکاپی که از سه ماه پیش اجرا نشده. این چک‌لیست ۲۰ موردی را جمع کرده که پیشنهاد می‌کنیم ماهی یک بار روی هر سرور بررسی کنید. دستورات برای Ubuntu 24.04 و دبیان نوشته شده‌اند و بیشترشان روی توزیع‌های دیگر هم با تغییر کوچک کار می‌کنند.

پیشنهاد: نتیجه‌ی هر بررسی را در یک جدول ساده ثبت کنید. مقایسه با ماه قبل، روندها (مثل رشد دیسک) را نشان می‌دهد.

بخش اول: به‌روزرسانی و کرنل

۱. آپدیت‌ها و وصله‌های امنیتی

sudo apt update
apt list --upgradable
# آیا آپدیت خودکار امنیتی فعال است و اجرا می‌شود؟
systemctl status unattended-upgrades
sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log

بسته‌های امنیتی عقب‌مانده، به‌خصوص OpenSSH، OpenSSL، کرنل، وب‌سرور و PHP، اولویت اول‌اند.

۲. نیاز به ری‌استارت

ls /var/run/reboot-required 2>/dev/null && cat /var/run/reboot-required.pkgs

اگر این فایل وجود دارد، بعضی وصله‌ها (معمولاً کرنل یا کتابخانه‌های پایه) تا ری‌استارت بعدی اعمال نشده‌اند. ری‌استارت را در پنجره‌ی زمانی کم‌ترافیک برنامه‌ریزی کنید.

۳. نسخه‌ی کرنل در حال اجرا

uname -r
dpkg -l 'linux-image-*' | grep ^ii

اگر کرنل در حال اجرا از جدیدترین کرنل نصب‌شده قدیمی‌تر است، سرور هنوز با کرنل وصله‌نشده کار می‌کند. کرنل‌های قدیمی بلااستفاده را هم با sudo apt autoremove پاک کنید تا پارتیشن /boot پر نشود.

بخش دوم: منابع

۴. فضای دیسک و inode

df -hT -x tmpfs -x devtmpfs
df -i -x tmpfs -x devtmpfs

هر پارتیشن بالای ۸۰٪ نیاز به بررسی دارد. پر شدن inode (مثلاً از میلیون‌ها فایل سشن یا کش کوچک) باعث خطای «No space left on device» می‌شود، در حالی که df -h هنوز فضای خالی نشان می‌دهد. اگر دیسک پر است، روش قدم‌به‌قدم را در رفع مشکل پر شدن دیسک در لینوکس ببینید.

۵. حافظه و Swap

free -h
swapon --show
# آیا OOM Killer پروسه‌ای را کشته است؟
journalctl -k --since "1 month ago" | grep -i "out of memory"

ستون available مهم است، نه free. مصرف مداوم Swap یا پیام‌های OOM یعنی سرور حافظه کم دارد یا سرویسی نشت حافظه دارد.

۶. بار سیستم (Load)

uptime
nproc
top -b -n 1 | head -n 20

Load Average را با تعداد هسته‌ها (nproc) مقایسه کنید. Load بالا با CPU کم‌مصرف معمولاً نشانه‌ی انتظار برای دیسک (I/O wait) است؛ ستون wa در top را ببینید.

بخش سوم: سرویس‌ها و لاگ‌ها

۷. سرویس‌های failed در systemd

systemctl --failed

هر سرویس failed را بررسی کنید: systemctl status نام-سرویس و journalctl -u نام-سرویس -n 50. سرویسی که لازم نیست را غیرفعال کنید تا هشدار کاذب نسازد.

۸. خطاهای ژورنال

journalctl -p err --since "1 month ago" --no-pager | tail -n 100
# خطاهای کرنل (دیسک، حافظه، شبکه)
journalctl -k -p warning --since "1 month ago" --no-pager | tail -n 50

به‌خصوص دنبال خطاهای I/O دیسک، خطاهای فایل‌سیستم و ری‌ست شدن کارت شبکه باشید.

۹. سلامت دیسک‌ها (SMART و RAID)

sudo apt install -y smartmontools
sudo smartctl -H /dev/sda
sudo smartctl -A /dev/sda | grep -Ei "reallocated|pending|uncorrectable"
sudo smartctl -a /dev/nvme0
# اگر RAID نرم‌افزاری دارید
cat /proc/mdstat

افزایش Reallocated یا Pending Sectors از ماه قبل، هشدار جدی است. روی سرور مجازی معمولاً به SMART دسترسی ندارید و این مورد مسئولیت ارائه‌دهنده است.

۱۰. چرخش لاگ‌ها

sudo du -sh /var/log
sudo du -sh /var/log/* | sort -h | tail
journalctl --disk-usage
sudo logrotate -d /etc/logrotate.conf 2>&1 | grep -i error

اگر ژورنال بیش از حد بزرگ است، سقف آن را با SystemMaxUse در /etc/systemd/journald.conf تعیین کنید.

بخش چهارم: امنیت و دسترسی

۱۱. پورت‌های باز

sudo ss -tulpn

هر پورتی که روی 0.0.0.0 یا [::] گوش می‌دهد از بیرون قابل دسترسی است، مگر فایروال جلویش را بگیرد. دیتابیس، Redis و پنل‌های مدیریتی نباید از اینترنت باز باشند. از یک سرور دیگر هم تست کنید؛ اگر Docker دارید، پورت‌های منتشرشده‌ی آن از UFW عبور می‌کنند (چک‌لیست امنیت Docker).

۱۲. کاربران و sudoers

# کاربرانی که شل ورود دارند
grep -vE "nologin|false" /etc/passwd
# کاربرانی با UID صفر (فقط root باید باشد)
awk -F: '$3 == 0 {print $1}' /etc/passwd
getent group sudo
sudo ls -la /etc/sudoers.d/
lastlog | grep -v "Never"

حساب کارمندان یا پیمانکارانی که دیگر همکاری ندارند را غیرفعال کنید و کلیدهای ~/.ssh/authorized_keys همه‌ی کاربران را مرور کنید.

۱۳. تنظیمات SSH

sudo sshd -T | grep -Ei "permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries|port "

حالت مطلوب: ورود با رمز خاموش، ورود root خاموش یا فقط با کلید. جزئیات را در راهنمای امن‌سازی SSH آورده‌ایم.

۱۴. تلاش‌های ناموفق ورود

journalctl -u ssh --since "1 month ago" | grep -c "Failed password"
journalctl -u ssh --since "1 month ago" | grep "Accepted" | tail -n 20
sudo lastb | head -n 20

تعداد زیاد تلاش ناموفق روی سرور اینترنتی طبیعی است؛ مهم‌تر، ورودهای موفق از IPها یا ساعت‌های غیرمنتظره است. اگر Fail2ban دارید، وضعیتش را با sudo fail2ban-client status sshd ببینید.

۱۵. Cron و Timerها

for u in $(cut -d: -f1 /etc/passwd); do sudo crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
ls -la /etc/cron.d /etc/cron.daily
systemctl list-timers --all

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

۱۶. فایروال

sudo ufw status verbose
sudo nft list ruleset | less

قوانین را با فهرست سرویس‌هایی که واقعاً باید باز باشند مقایسه کنید. قوانین موقتی که «برای تست» باز شده بودند را ببندید.

۱۷. انقضای گواهی‌های SSL

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate
# آیا گواهی تا ۳۰ روز دیگر معتبر است؟
openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -noout -checkend 2592000
sudo certbot renew --dry-run

فقط گواهی سایت اصلی را نبینید: زیردامنه‌ها، سرور ایمیل، پنل‌ها و APIهای داخلی هم گواهی دارند.

بخش پنجم: پایداری و بازیابی

۱۸. بکاپ و تست بازیابی

# آخرین بکاپ کی گرفته شده؟ (مسیر را با مسیر بکاپ خود عوض کنید)
ls -lt /backup | head
# برای restic
restic snapshots --latest 3

دیدن فایل بکاپ کافی نیست. هر ماه حداقل یک فایل یا یک دیتابیس را واقعاً روی یک سرور تست بازیابی کنید. بکاپی که بازیابی‌اش تست نشده، بکاپ نیست. همچنین بکاپ باید روی سرور یا مکانی دیگر باشد؛ روش آن را در بکاپ با Restic روی Object Storage توضیح داده‌ایم.

۱۹. همگام‌سازی زمان

timedatectl
# باید System clock synchronized: yes باشد

ساعت نادرست باعث خطای SSL، ترتیب غلط لاگ‌ها، مشکل در احراز هویت دومرحله‌ای و خطا در کلاسترها می‌شود.

۲۰. بازبینی هشدارهای مانیتورینگ

این مورد دستور واحدی ندارد، اما شاید مهم‌ترین باشد. هشدارهای ماه گذشته را مرور کنید:

• کدام هشدارها تکرار شده‌اند و علت ریشه‌ای‌شان رفع شده است؟
• کدام هشدارها کاذب‌اند و باید آستانه‌شان تنظیم شود؟ هشدار کاذب زیاد باعث نادیده گرفتن هشدار واقعی می‌شود.
• آیا حادثه‌ای رخ داده که هیچ هشداری برایش ارسال نشده؟ پس یک هشدار کم دارید.
• آیا هشدارها واقعاً به دست کسی می‌رسند (ایمیل، پیام‌رسان) و آن فرد هنوز در تیم است؟

اگر هنوز مانیتورینگ ندارید، راه‌اندازی مانیتورینگ با Prometheus و Grafana را ببینید.

خودکار کردن چک‌لیست

بیشتر این بررسی‌ها را می‌شود در یک اسکریپت ساده جمع کرد که خروجی‌اش هر ماه برایتان ایمیل شود، و بخشی از آن‌ها (دیسک، حافظه، سرویس‌ها، انقضای SSL) را بهتر است به‌جای بررسی ماهانه، به هشدار لحظه‌ای مانیتورینگ تبدیل کنید. موارد ۱۲، ۱۵، ۱۸ و ۲۰ اما به قضاوت انسانی نیاز دارند و نباید فقط به اسکریپت سپرده شوند.

جمع‌بندی

یک ساعت بررسی ماهانه برای هر سرور، هزینه‌ی کمی در برابر یک قطعی یا نفوذ دارد. مهم، استمرار است: چک‌لیستی که فقط یک بار اجرا شود، فقط وضعیت همان روز را نشان می‌دهد.

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